oberkc

Are you still using Insteon hub for Alexa integration, along with ISY? I expect that you will soon run into complications with this. ISY will probably not recognize links between your Insteon devices and hub, so there is risk that those links could get overwritten. Management of ISY and another hub among your Insteon devices can require some pretty serious attention to details. I suggest following the advice of @Javi. Splurge for the portal access and this will get you Alexa integration with all the devices in your ISY. After that, remove your hub from the system. I suspect you will find this easier to manage, long term. An added benefit is that the portal makes using the phone app for the ISY easier and more reliable and secure. Of course, you have to be willing to go through the learning curve with this new setup along with refreshing all your Insteon/zwave devices in the Alexa app and reprogram your routines and device names.

I do not believe that one is limited to the "dedicated smart home buttons" to interact the the hue emulator. I recall that other buttons of the remote could also be configured, via the harmony app, to control devices you have linked to the hub. Unfortunately, those buttons and devices would need to be associated to a specific activity, unlike the dedicated smart home buttons, and would only work when the activity was running. Shutting off (or changing) activities would result in the included devices also shutting off. You might be able to fool around with the activity startup and shutdown sequences, however.

initial feedback from ticket was to remove dongle and restart Polisy. Given that I had performed this step earlier, I decided to restart policy by temporarily unplugging power supply. This seems to have restored access to Polisy via launcher. UD feedback is focused on power supply for Polisy. Apparently, there are 1.5amp and 1.0 amp versions. Mine is the latter. Apparently, the lower power supply can result in these kinds of problems, I guess. I have since added dongle back and, again, temporarily unplug Polisy. Things now appear to be working. Next step, try to add a zwave device.

good suggestion. I have tried. Same results. Have also tried moving zwave stick to other USB port, and removing zwave stick altogether. None of these steps restores access to the ISY-on-polisy. Other thoughts?

I tried adding a new zooz zwave stick to my ISY-on-polisy. I plugged the dongle into a USB port on the back of the Polisy. I used launcher to open ISY on the Polisy. I enabled zwave. I restarted the ISY (followed by a couple of beeps from the Polisy). Result: I no longer can find the ISY on Polisy using the launcher. Additional: I can log into Polisy from a web browser and all seems normal from there. I can ssh into the Polisy. I tried to manually add the polisy-isy to the launcher and no success. I also notice that when I launch the ISY finder, it takes a noticeably-longer time to find my normal ISY, and takes a much longer time to launch the admin console once found. Thoughts?

I have a (perhaps several) zwave switch that does not trigger a "control" condition. The only way that I know that this is true is because I created a program that had the zwave control condition, and it did not trigger, despite the fact that the status changed in the ISY (pretty clear that the ISY and zwave switch were communicating.). It sure sounds as if your node created here is the same, and that "status" is your most likely option. The problem, of course, is that "status" conditions, unlike "control" conditions, trigger a program upon any change in status, including off>>>on and on>>>off. Given this, if your status changes to off, then your program would trigger and it would evaluate false, and it would run the ELSE path. If it were to do so during a wait or at a repeat, it would effectively halt the remaining commands. To get around this you have a couple of obvious choices. One choice would be to include some command in the ELSE path to execute any time the program triggers FALSE. Unfortunately, it would be difficult to exactly duplicate what you have in your THEN path, and you would also run those commands even if it were triggered after the current THEN path had concluded. Perhaps a better way to deal with this problem is to break your current program into two programs, such as: if status rainmachine node is ON then run second program (THEN path) Second program: if nothing then do everything that was in original program The first program would only call the second program when status changes from OFF>>>ON and the second program is not triggered by anything (other than the first program) so it would likely run to completion. Of course, if the status changes from off>>>on while the second program is waiting or repeating, then it would get interrupted and start again from the beginning, but this is no different than your current program and is, I assume, acceptable to you.

I would try gLarsen suggestion. I am not sure what your rain device is. Is it insteon? Something else? In my experience, not all devices trigger a switched-on condition. Some only respond to status conditions. If that works, be aware that a change of status could halt your program right in the middle of a weight or repeat action. You may have to adjust your program to account for that possibility.

Perhaps, but I am trying to reconcile that statement with the ISY Advanced User Guide (see a couple of attachments) which suggest (to me) that associations are part of the ISY capability and with the response from @Michel Kohanim below.

That is my understanding, as well The only thing that I have come across is the web page for the Z-wave alliance: https://products.z-wavealliance.org This page provides, among other things, a list of certified devices and their features. Unfortunately, I am not confident in the accuracy of this. If I read it correctly, the Jasco switches (of which I own a few) have association capabilities. Despite this, I remain unable to create an association with these devices. As best I can tell, the zwave feature which allows direct communication and links between two or more zwave devices is known as "associations", which I assume is analogous to Insteon "scenes". I have not seen the term "scene" in my research of the zwave protocol. Perhaps someone could clear this up if I misunderstand.

On 5.3.2. Is the association capability only available with the latest version? Yes. I have clicked on the primary node, along with various other nodes, including those called "basic scene control".

I guess none of my devices supports either. I have a good number of GE/Jasco switches and outlets. I have a smaller number of Leviton switches. I have yet to come across a zwave device or node that gives me an option to choose these scene or association options. Is there a particular brand or model that support these link types?

Apparently, this is an option. Polisy, in addition to hosting the polyglot node server function, doubles also as an ISY-994. So....both can be present on the Polisy box. Or, continue to use a separate box for the ISY-994 function and the Polisy box for the node servers. I am still a little fuzzy on the pros and cons of either approach. My separate system has been rock solid so I am not convinced that there is a noticeable reliability improvement. Furthermore, you may loose a few functions on the Polisy-hosted ISY-994 (IR comes to mind). On the positive side, I understand that the single-box approach may be faster. I also perceive that the single-box approach is the one supported by universal devices going forward and wonder how long the separate ISY box will be supported. At this point, I am in no hurry to move over to a single-box system, but I am starting to play around with the ISY on Polisy, having just ordered a z-wave stick. I must admit that I am not excited about putting in a bunch of hours to move over to the single box and fear that this is what it will take.

I must admit that everything looks good as far as I can tell. Yes, it appears to me also that your keypad buttons are, indeed, sending ON commands. It also appears to me that your scenes are set up correctly (notwithstanding a few non-insteon link types). The only thing that is coming to mind at this point is the possibility that the links are not written to the individual devices. Have you tried "restore device" option for your keypads and other devices within that scene?

I am certainly no expert at Reading the event viewer. Still, I find it easy, at least, to see if commands are being seen by the isy. For example, if you press one of your keypad buttons a, it's not too hard to see whether you are getting an on or off command. I definitely would like to confirm that your buttons are all configured in non toggle (on) mode.

Good. Perhaps, then, I misunderstand. When you press Button A on keypad2 or keypad3, even the button A does not come on? This suggests to me that they are in non-toggle (off) mode or that there is some type of failure. In my experience, if a keypad button is in non-toggle (off) mode, they will flash when pressed, transmit an OFF command, then stay off. If a keypad button is in non-toggle (on) mode and pressed, it will flash, transmit an ON command, and stay on. If you confirm that they are, in fact, in non-toggle (on) mode, yet don't stay on when pressed, this is a problem with the keypad, itself. Either the ISY is not configuring it properly, or there is some type of failure in the keypad. I would check, again, that these buttons are in non-toggle (on) mode. A secondary check would be to open the ISY event viewer and observe what commands are coming when you press the keypad buttons A. Is the ISY seeing an ON command or OFF command? What does the ISY show as status for keypad buttons A when each is pressed?

And, given that some of the A buttons do not come ON when you press them, it makes me suspect that they are in "non-toggle-off" mode. Do they flash a couple of times when you press them? Given what you state that you want, I would ensure that ALL buttons A are in non-toggle-ON mode. Based upon the four .pdf files you attached, it appears that the scene settings are correct. My best guess is that some of your controller buttons are not all configured properly for non-toggle-ON mode. Based, also, upon my impression from your matrix for keypad1, I cannot help but wonder if you are having some communication problems somewhere. I also cannot help but notice that some of your link types are "command" rather than "Insteon". I would have guessed that all should be "Insteon".

yes, the same on mine. While small, individual scenes work fine (mostly), larger scenes seem to be taking longer as z-wave becomes a larger part. I can, and have, live with it but it makes me pause at the idea of a total transition to z-wave.

I have tried some experiments with Zwave devices and nodes, but have never successfully been able to create a z-wave scene (aka association). While I have Zwave devices within the ISY scenes, the link "type" as shown in the scene definition is alway "default" and I have never seen a link type "z-wave basic" between any zwave devices or nodes that I have tried.

Well, one thing that was not obvious from the post was whether this was a 6- or 8-button keypad. On the 6-button, "A" is not the load controller.

I thought the same thing, and have twice recommended checking the responder levels for all the controller devices within the scene. I am not sure that the message is getting through amongst all the other tangential thoughts.

Except that non-toggle sounds like the best approach to meet the stated needs (button A always "turns ON the scene"...the only stated requirement for pressing button A). Yes, there may be unstated requirements and yes there may be future requirements and expansion, but my intention was to address why the solution did not meet stated requirements, rather than question the requirements.

Unfortunately, your attachment showed only the responder levels for each device when the "scene" is controlled (ie, ISY/PLM is controller device). As I suggested earlier (perhaps with insufficient clarity) you also need to check responder levels for the other controller devices. Remember, this is still an Insteon system, and controller/responder relationships are established between individual Insteon devices. Each device you have established as a controller will have controller/responder levels that may or may not be the same as for the scene and for the other controller devices. You must ensure all responder levels for each of the controller device is correct. Do this by selecting each of the controller devices within the scene and observing/confirming responder devices for the other devices in the scene. Yes, one can do this, but it does not necessarily explain why the approach by SESamuels is not working. And, if one does not need the extra flexibility, then one has multiple scenes where one is otherwise sufficient.

Assuming it is not something such as communication errors (does not sound like it to me), I would confirm a few things.... Sounds about right. I suggest checking the responder levels for both buttons A. Mouse-Click on the scene name...what are the responder levels for the various devices in the scene? Mouse-Click on each of the two scene controller buttons...are the responder levels the same? Are they what you expected? Remember that scene controllers are also responders to other scene controllers. Also sounds correct. Make sure that this is true not only for scene#1 (when selected in the device listing) but also for when any other controller in that scene (two buttons A) is selected. Remember, responder levels within a given scene can be different for each and any controller within that scene. Which leads me to a question...does button A keypad 1 cause anything to happen to any of the keypad 2 buttons? Which leads me to: how do you determine that scene#1 "does not turn on". Does button A of keypad 2 not turn on? What must be ON for you to declare scene#1 to be ON? Are there light fixtures involved? To what Insteon device(s) are those fixtures attached?

I have a couple of Leviton zwave switches. I can add them as scene controllers. Unfortunately, I am unable to create scenes directly linked (link type: zwave) but only via the ISY (link type: default) to other zwave devices. The scenes function fine, but I assume would cease to do so absent the ISY-994 controller (unlike Insteon).

I wonder if one of those Itach WF2IR-type devices, along with a network resource, could be made to work. I am (unfortunately) uncertain whether they can receive IR, or just transmit.