oberkc

This program would, under certain circumstances, cause a "loop". For example, if your keypad link device is currently off, and you ask Alexa to turn it on (forcing an execution of the THEN action), the program would trigger itself and run again. I must admit I don't see the value of this program. Basically, it seems that it is saying "if a device is on, then turn it on, otherwise turn it off". I would handle this with a scene. Put all switches in the scene that you want to control the device. When you ask Alexa to turn on/off the device, create a routine that responds by turning on/off the scene.

Done

I had no programs or scenes with the original nodes. I did not have a need to migrate anything, so I did not (and, I am sure, it is too late). Lots of errors in the log. They continue every few seconds. See screen shot in attachment. Linked instructions say to "keep" 8080 port, but I have changed it to 8081. Also tried 8082. No change in status. Based on linked migration instructions, I ssh into polisy and tried the command: cd /var/polyglot/pg3/ns/uuid_n/config. I replaced UUID with that found in the ISY launcher and n=2 (slot for hue emulator. From that, I receive error "no such file or directory". I have double checked again the ISY host, port, user, and password. Host and port matches that found from the IoP admin console under "help>about". User and password match those that I use to login to IoP admin console (they are NOT admin/admin). Screen Shot 2023-02-01 at 1.23.21 PM.pdf Screen Shot 2023-02-01 at 1.18.42 PM.pdf Screen Shot 2023-02-01 at 1.50.50 PM.pdf

I have never been successful linking my Harmony Hub to the Hue Emulator on PG3/IoP (was working on PG2/ISY). I have decided to try again. Now, the Hue Emulator node on IoP admin console shows ISY connected as false. Additionally, none of my spokens show as nodes in the node server details>configuration table. Since last try, I have migrated all my system to IoP and the ISY no longer exists on my network. As best I can tell, ISY host/port/user/password are all correct in the node server configuration. I am not sure if this is relevant, but PG2 is still accessible, and still has hue emulator node server on it, but everything is showing disconnected. I am unable to delete any node server on PG2 (I presume because it is not connected to the ISY any longer). Suggestions?

S0, apparently.

I am not even sure how I would determine this. Suggestions?

I seem to be. When I manually unlocked it, the Amin panel changed status, then when manually locking it changed again. I have not done much more exhaustive testing than that, however.

I can't answer this question, but I can tell you that my BE469 added just fine. In fact, it came over from the ISY-994 backup files. The synch/interview process took care of the rest. Don't give up.

I have just migrated my system from the legacy ISY-994 to the polisy (not the EISY) but I understand EISY and Polisy are same in this regard. Zwave switches that could formerly act as scene controllers no longer do so. I submitted a ticket for this issue, and was told (loosely) that they are aware of the problem and that an update is coming that should help. Hopefully, we will have good z-wave capability soon.

I thought I would share a few highlights from my experience migration from ISY to Polisy. I have not had the smoothest experience lately with making updates to my system, and have been very hesitant to make this migration, but decided it was time to take the risk. I attempted to follow the instructions from the wiki, but found a few instances where the instructions could not be followed to the letter due to them directing to choose options from the admin console that did not exist in mine. Regardless, I believe I followed the intent of the instructions. My migration was using the existing PLM, from the ISY. Highlights from the process: - "most" of the Insteon devices came over. A few are missing (so far, I am missing a lamplinc and fanlinc, but am still sorting this out and may find more). Scenes that formerly contained the missing devices are no longer working from the admin console. Some controller devices within those scenes might still trigger the missing Insteon devices. Some don't. I assume that the links between Insteon devices remain, but the ISY link records no longer match. - zwave devices all came over but required the individual "sync and interview" process to work. Perhaps, if I had waited a day or three, this might have happed automatically, but I chose to force it on each individual device. All wired devices came through this, but sometimes with missing nodes or missing functionality (a z-wave switch that I could formerly use as a scene controller no longer worked as such...the ISY did not recognize a status change when the switch was manually toggled). I was unable to transfer any battery-operated z-wave device, with two exceptions: a door lock, and an alarm. No motion sensors. No door sensors. I was unable to force the door and motion sensors to respond to the interview request. I could exclude, then include them but, like the previously-mentioned switch, the ISY would not react to a status change when a door is opened or the motion señsor saw activity. This rendered those devices of no use. - Portal migration worked well. Alexa spokens, as best I can tell, all transitioned. - PG3 did not migrate properly. In this case, however, I am willing to assume this was a self-inflicted wound. Prior to the migration, I had PG3 working with the ISY, as well as with an unmigrated IoP. I cannot say (don't recall) that I had all node servers in the same slots, however. After I made the transition, the former nodes (I use Hue, Roku, Sonos, Harmony, and a few others) appeared in the admin console as before, but none worked. After attempting a few things, I ended up clearing PG3, clearing the node servers from the admin console, and re-adding to PG3. This also meant re-populating a few scenes and programs with the "new" nodes, but this is mostly working at this point. - most interesting to me: I have at least one case where I have an ISY scene connected to Alexa. This scene originally included several keypad buttons and two fanlincs. The scene is, I assume, typical for fan control. Button A = off. B = Low, C = medium, D = High. It has worked flawlessly since creation. Sometime between the time I last used it and now (I assume as the result of the migration), the fan scene ceased working. I can no longer control the fan from the KPL, nor can I control it from the admin console. Not only is one of the two fanlincs missing from the scene definition, it is completely missing from the device list. Despite all this, both fanlincs still respond to Alexa commands. I cannot even come up with a theory about how this is possible. - I thought I had successfully updated to 5.5.5 on IoP, prior to migration. After migration, however, the admin console for IoP shows 5.5.4. Did I imagine things? I guess I will never know for sure.

since AM is before PM, your time interval will never be true. I believe the "next day" option is still viable. Try: IfFrom 5:30:00 PMTo 5:30 AM (Next Day) <<<<<<AND Hallway Motion Sensor 1 is On Yes, these programs will run every time it is triggered by an event. The only question is whether it runs THEN or ELSE.

It also appears that, after migration to IoP, I cannot get any of my battery-operated zwave devices to respond to an interview. As an experiment, I successfully excluded one of the battery zwave devices (a door sensor, in this case) and added it back in. It was missing a node or two, and no longer had an On/Off status available on any of the nodes. Not much good. For now, I guess I will wait to see if anything happens over time. Perhaps there is an update that may address this some day.

Fair enough. Of course, the instructions here were limited to z-wave migration. I was performing entire -994 > IoP migration.

Is not the thread you referenced the one we are in, and currently corresponding?

Thanks. I would have assumed something like that. I also assume what is now called "Backup" is what was formerly called "Full". Unfortunately, these are the types of details that cause me some loss of confidence. This wiki page has been recently quoted as the latest migration process, which includes updating to ISY 5.3.4 (step 1, which cannot be done with 300 series z-wave dongle). Things can go wrong when one gets careless with the details.

I am, after so many difficulties in recent times, getting the ambition to make the transition to IoP from the legacy -994. I am trying to follow the instructions on the wiki and want to be sure to be precise. In step three of the wiki is: Wiki step 3: "Backup your 994's Z-Wave dongle (Admin Console | Z-Wave | Utilities | Backup | Full)" Unfortunately, I see no "Utilities" option under Z-Wave, nor do I see a "Full" option. Yes, I am on 5.3.4. Is this a problem? Why do the instructions not match my admin panel options?

As far as I know, there is no direct access to “works with alexa” devices. Alexa devices do not show up in the ISY device listing, and status is not directly tracked. Having said this, one can trigger alexa routines via the ISY. My memory is a little vague on this, but some ISY devices can be added to alexa as “sensors”, as can ISY variables. Such “sensors” can be used as a trigger in alexa to force n lexa rotuine to activate. I use this method to control alexa announcements via ISY programs, but anything that can be done via an elexa routine cna be triggered via ISY including, I assume, controlling alexa-enabled devices.

Does it appear that your ISY is operating normally? Programs working? No funny lights on the ISY front panel? In my IoX launcher, the format for the URL is http://myISYaddress:myISYport/desc I am hopeful that you know your ISY address and port. Regardless, my IoX has alway found my ISY and polisy and I do not recall having to add them manually. There have been times when I had to reboot one or both, and times when it seemed that removing IoX and re-installing (including the clearing of the Java cache) was helpful. You might try this.

I may have missed it, but I saw no stated requirement for this to run on the "last" day of each month.

Yes, I think this is something you should do. IIRC, the additional of calendar variables was one of the big reasons I was excited to make the update to 5.X. Without it, your options are quite a bit more limited (and potentially more time consuming than making the software migration.

I assume that one is skilled enough to recognize the number of days in each month, and that some have 31, some have 30, one has 28 (and sometimes 29). I also assume that one recognizes that if one picks some number greater than 31, such a program will never trigger, that if one picks a number such as 29, 30, or 31, it will only trigger on some of the months. I would like to think that if one is trying to create computer programs using Boolean logic, that such person can figure the simpler parts out on their own.

I would be more inclined to create a variable to keep track of the day of month. Once each day (I do mine in the 3am cleanup program), run a program that includes a step: $dayofmonthvariable = [Current Day of Month] Create a program such as: if $dayofmonthvariale = some number then turn on Insteon module wait for some period of time turn of Insteon module else nothing The program, above, will work only for periods of time less than 24 hours. 24 hours after this program runs true, the day of month variable will change, become false, and halt any wait state.

I suppose you could test his theory by watching the program log while you execise the various keypad buttons. Does the program run twice, first true, then false?

Mine showed the migration option also on 5.5.2

I am waiting as well. I dont have an immediate need to move from the -994 at this point, so until that changes or I am more confident that the zwave migration path is less rocky, I will stay with the trusty ISY.