apostolakisl

So this appears to be the story. 1) backup PG2 2) delete the PG2 nodes you plan on moving to PG3 3) restore the PG3 node server using the PG2 backup 4) restart the NS's you're migrating, perhaps twice before they show up in ISY. Definitely not an elegant process.

What if I is already on PG3? Will I need to delete it from there and add it again?

So if I delete the node from PG2, it will not delete the configuration from ISY? Right now, both PG2 and PG3 claim to be managing the same node. Before manually "stopping" the PG2 version, both said "connected". PG2 below PG3 below

This may be answered elsewhere, but I can't find it. I am trying to migrate nodes over from PG2 to PG3. I have loaded lots of nodes on pg2 with many of them there as curiosities that I really don't care to pay to move to pg3. I am starting by moving over what is free and then will buy what I actually want. Anyway, I restored a pg2 backup in pg3 using the button that says it does that. Example, Blue Iris now shows on pg3, but it still is on pg2. Do I at this point delete it from pg2? Or will that delete the node from ISY even though it is still on PG3? The NS configuration page on ISY AC shows that the node is configured for PG3 with port 3000 as the port and other stuff that is c/w it talking to PG3. I stopped the Blue Iris NS on PG2 and restarted it in PG3 and PG3 shows connected. So now what? Delete from PG2? After restarting PG2, it still shows connected to Blue Iris, I would expect it to say unmanaged.

Of course I set it up. PG3 node lost connection to ISY, not to Roomba. The log still showed data flowing in from Roomba. The AC was getting no updates, so the values stayed as they were. After an AC restart, the fields were left unpopulated. Other PG3 nodes were still connected to ISY.

Its own built in schedule. As I mentioned, I don;t know how they work that, it could be on the cloud or it could saved directly to the unit. I suppose I could shut my internet off at 1am when it is scheduled to run and see if it runs.

It started from its own schedule. It runs at 1am every night. Not sure where the initiating event for a scheduled cleaning comes from, I would bet that is saved on the roomba itself, but it might come from the cloud in which case it would functionally be the same as starting it from the phone app.

I appear to have a similar issue. Roomba was running, but AC showed it was in charger. I closed/reopened AC and it is not populating Roomba. Roomba log in PG3 shows a continuous flow of data as you would expect from a running Roomba without any errors. I tried using commands from the AC and Roomba does not respond nor does the log show anything except the flow of info from Roomba. In other words, it appears the the NS has lost its connection to ISY. I then restarted the NS (just the NS, not polyglot or polisy or isy) and all is now working correctly. I do not know why the NS would lose its link to ISY. I haven't made any changes to ISY or any NS's since the last reboot.

open a ticket. they will probably send you a flash chip to recover your polisy. mine did something similar.

My 2413S works just fine on Polisy using the RJ45 to DB9 cable as shipped from Smarthome and included with the 2413S PLM. You can not use a standard ethernet cable, none of the RJ45 jacks on Polisy are serial AFAIK. If you no longer have that cable as included with the original purchase, you can pick them up online for about $10. I assume the pinout is standard. If not, I'm sure you can get the pinout from Michel and make your own. @Tim McDermott

I think these two program would do what you like. Of course, you will not be able to use "fast on" to actually turn the light on. It will always go back to where it was before. tes - [ID 008E][Parent 0093] If 'Kitchen / Kitchen-3 Cans L' is switched Fast On Then Set 'Kitchen / Kitchen-3 Cans L' On '$stest %' Else - No Actions - (To add one, press 'Action') test - [ID 0006][Parent 0093] If 'Kitchen / Kitchen-3 Cans L' Status is Off Or 'Kitchen / Kitchen-3 Cans L' Status is not Off Then Wait 1 second $stest = 'Kitchen / Kitchen-3 Cans L' Status Else - No Actions - (To add one, press 'Action')

Yes, looks like it went down at 1am CDT. A bunch of people from around the world commenting. This is why I hate cloud services! Hopefully they didn't go bankrupt too.

yes, just saying though, that Elk makes tasks available in its api or nothing would be able to trigger tasks via the internet.

OK, that confirms then that the api does include task control since ekeypad can access it.

Nothing I couldn't do from ISY, but I had Elk before I had ISY and I programmed a number of things in there, some of which are quite complex, like my sprinkler function. I could move it over to ISY, but that would be a lot of work. And gladly, I did not do that because I would then have had a whole bunch of work converting from Elk module to Elk NS. While ISY is very stable, Elk is insanely stable, and when it comes to some things, I would rather have them running on Elk.

I suspected this was the case since I know it worked a couple weeks ago and I saw an update just happened about a week ago. I also keep my roomba on a vlan that is less secure and punched a hole in the firewall so it can talk to Polisy. The new PG3 roomba node server is challenging since it autodiscovers roomba only, no manual option, so I had to temporarily move polisy to the roomba vlan. I can firewall roomba from wan, but without the app, you can never make any setting changes to roomba. Maybe I never will need to?

Actually, I would say I am 99% sure that the API has access to tasks since I am pretty sure when I used to have an Elk phone app, I could run tasks from it.

I have an i7 (not sure about the plus part) and other than not getting the x,y,theta values, it seems to work.

I haven't tied the PG3 node server yet. But the answer is no to PG2. Also no to the Elk Module for ISY. I assume the API has them available, but I don't know. @JimboAutomates

This was also the case with the original ISY Elk module. There is a workaround. As you mentioned, outputs. Specifically, phantom outputs (outputs that don't actually have an Elk output module attached). Use the higher end of the range of outputs, like in the 100s, just in case you decide to buy a bunch of Elk output boards and use up all the lower numbers. Then in Elk you'll need to write a rule that says "whenever output x turns on, then activate task y". In ISY, you will need to write a program, IF . . whatever you want to trigger the task. Then turn output x on for 1 second.

Not a big deal. But I am about 99% certain that this worked when I had it installed the first time before the fiasco with moving to IoP. I also saw that my roomba did a firmware update a few days ago, so not sure if that is the reason. I don't know that it really matters to see x,y,theta. Since the Roomba seems to know where it is going in the house, I assume it has the values internally. Here is a portion of the log anyway. 2022-04-29 14:16:32,387 Thread-13461 udi_interface ERROR roomba-poly:_update900SeriesProperties: Error updating X Position on Roomba: 'pose' 2022-04-29 14:16:32,388 Thread-13461 udi_interface ERROR roomba-poly:_update900SeriesProperties: Error updating Y Position on Roomba: 'pose' 2022-04-29 14:16:32,389 Thread-13461 udi_interface ERROR roomba-poly:_update900SeriesProperties: Error updating Theta Position on Roomba: 'pose' 2022-04-29 14:16:32,387 Thread-13461 udi_interface ERROR roomba-poly:_update900SeriesProperties: Error updating X Position on Roomba: 'pose' 2022-04-29 14:16:32,388 Thread-13461 udi_interface ERROR roomba-poly:_update900SeriesProperties: Error updating Y Position on Roomba: 'pose' 2022-04-29 14:16:32,389 Thread-13461 udi_interface ERROR roomba-poly:_update900SeriesProperties: Error updating Theta Position on Roomba: 'pose' 2022-04-29 14:16:32,640 Thread-1 udi_interface INFO roomba:process_q: Received Roomba Data: wifistat, b'{"state":{"reported":{"signal":{"rssi":-57,"snr":19,"noise":-76}}}}' 2022-04-29 14:16:32,640 Thread-1 udi_interface INFO roomba:process_q: Received Roomba Data: wifistat, b'{"state":{"reported":{"signal":{"rssi":-57,"snr":19,"noise":-76}}}}' 2022-04-29 14:16:32,645 ThreadPoolExecutor-0_1 udi_interface INFO roomba:update_state_machine: current_state: Charging, current phase: charge, mission: clean, mission_min: 352, recharge_min: 0, co-ords changed: False 2022-04-29 14:16:32,645 ThreadPoolExecutor-0_1 udi_interface INFO roomba:update_state_machine: current_state: Charging, current phase: charge, mission: clean, mission_min: 352, recharge_min: 0, co-ords changed: False 2022-04-29 14:16:32,646 ThreadPoolExecutor-0_1 udi_interface INFO roomba:update_state_machine: updated state to: Charging 2022-04-29 14:16:33,646 Thread-1 udi_interface INFO roomba:process_q: Received Roomba Data: wifistat, b'{"state":{"reported":{"signal":{"rssi":-58,"snr":19,"noise":-77}}}}' 2022-04-29 14:16:32,646 ThreadPoolExecutor-0_1 udi_interface INFO roomba:update_state_machine: updated state to: Charging 2022-04-29 14:16:33,646 Thread-1 udi_interface INFO roomba:process_q: Received Roomba Data: wifistat, b'{"state":{"reported":{"signal":{"rssi":-58,"snr":19,"noise":-77}}}}' 2022-04-29 14:16:33,651 ThreadPoolExecutor-0_0 udi_interface INFO roomba:update_state_machine: current_state: Charging, current phase: charge, mission: clean, mission_min: 352, recharge_min: 0, co-ords changed: False 2022-04-29 14:16:33,651 ThreadPoolExecutor-0_0 udi_interface INFO roomba:update_state_machine: current_state: Charging, current phase: charge, mission: clean, mission_min: 352, recharge_min: 0, co-ords changed: False 2022-04-29 14:16:33,653 ThreadPoolExecutor-0_0 udi_interface INFO roomba:update_state_machine: updated state to: Charging

Elk has naming restrictions and only organizes them by zone number. ISY organizes alphabetically and doesn't really have naming restrictions. So after I uploaded Elk into ISY, I renamed things with longer names and names that would alphabetize logically. In short, I would not want the node server to rewrite my changes back to what is on Elk. Of course I would have no objection to it having that as an option that I could turn off.

I would stick with static IP's (actually I would do DHCP with reserved address for Polisy set in your router). It is good to have ISY/Polisy always at the same IP. But as Mr Bill said, I would not open any ports in your router firewall. The portal is very cheap and bypasses the risk of opening ports. Especially now that Polisy will be the destination of that port forward and polisy I suspect could be more capable of wreaking havoc (vs ISY) if someone got control of it.

If you do a "run then" and "run else" does it turn the light on/off? Does the program summary page show the last time it ran (on its own, not from you doing a run then/else) and was that last run time appropriately true/false and at the correct time? Also, I see you have set conditions for the program folder. The green line on it means it is currently true. So, what are those conditions and could they be false when the program is supposed to run.

I finally got the pg3 roomba node working again. I am quite certain my i7 used to report x/y/theta position, but now it does not. It shows error in the log and 0's across the admin console. Is there something wrong with my roomba or did something change with the roomba software? I see there was an update to the software 2 days ago.