apostolakisl

Yeah, I saw that if I fly up to Columbus, OH they have one in stock.

I guess it depends on what you are trying to do. A KPL has either 6 or 8 buttons, a switch has 2. There are multiple commands you can issue with those 2 buttons, fast on/off, dim down/up, and on/off. But I am not sure how this helps a quadriplegic since I would assume buttons are of no use to this friend. And I am confused on why you would need to change switches at this point. No, there is no way to control Insteon with an ISY994 without a serial plm. If you buy a Polisy and run ISY on Polisy, you can use usb or serial plm's, so more options, but you must have one.

Am I missing something here, but are Raspberry Pi's now rare? I think I paid $30 for my last one, now it appears they are all like $300. My father in law has an Insteon Hub he used with SH and I see from this thread he can hook it up to a RPi running HA. So I was like, great, I'll pick up a rpi for him. But what the heck?

You can spend $500 to $1000 for a serial PLM on ebay, or buy a $379 polisy and use your current usb plm, and sell your 994 on ebay for maybe $200. Of course by buying the polisy, you will also be future proofed for at least a decade.

I agree. I would recommend doing what I did above because it carries over all your configurations for the nodes you do want to move over and it leaves any non-qualified nodes (ones you didn't pay for) as unmanaged. But it is quite a goofy process.

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.