oberkc

I don't know if it is, simply, that I don't have the correct zwave devices or whether it is a bug in the ISY software or something else. I would sure like to hear of someone who has actually seen those options on their ISY and which zwave devices they use.

None of my zwave devices in scenes include such options, unfortunately. In the varios threads on this, I do not recall anyone claiming to have seen this option.

I use a little scratch awl to pull out the tab. I find a small screwdriver best to reset the tab.

I know I use them a LOT. I get a few misfires from time-to-time, but not anywhere near enough to be a problem.

This is consistent with my understanding regarding direct commands (device-to-device) but I understand this not to be the case with scenes. I suspect that is the point being made by larryllix.

Not any more. Ugh.

I don't know that there is anything added to the main page that would result from having a network resource. Of course, any network resource that you add would show up under the "configuration" tab of the admin console>>>network tab>>>network resources. Once you create a working network resource, they are available only by invoking by programs. They can be added to a program via action: networking>>>resource>>>pick-the-one-you-want.

Not true, but it might be easier if you did. You would need the hue hub, in addition to any hue devices. If you did not have a Polisy, you would control hue bulbs via a "network resource", which is an add-on (download the software) to the ISY. Once you have the network module downloaded, you would need to create a network resource for any action you would like to take regarding the bulb. One resource to turn on. One resource to turn off. Resources for any color or brightness change. There would be a learning curve and time commitment to this approach. If you had the Polisy, you would avoid the network resource approach and add a "node server" for the hue hub. I think of the node server as the intermediary between the hue hub and ISY. The node server syncs and communicates with the hue hub and, on the other end, the ISY. Once the node server is in place, the ISY list of devices would include any hue bulb that you have and you could then use in programs and scenes just as you would with any other Insteon or z-wave device.

No. Best option I can think is to identify a device within that scene that would only come on when the scene is on (however you define this) and go off only when the scene is off. Use that device as a condition in your program.

If your lights are dimmable and compatible with the fanlinc (and it sounds as if they are) then this would work as well. I have seen multiple mentions around here about how dimmer devices can modify the waveform of the electrical power, even full on, that it might have the potential for damage to loads that are not dimmable. But...it sounds as if this is not a concern in your case. Sure. I cannot think of any reason why not.

Where is the electrical box in which the inlinelinc is installed? Would it be a problem to replace the inlinelinc with an Insteon switch? Would a switch in this location be a visual or functional problem? The fanlinc is a dimmer control. Would this be an issue for your existing lighting?

Repair your old ones, or Ebay, or something like that. I have two spares, so I am hoping that will last me long enough, but for many devices I am moving to zwave and may try lutron in the future. I believe those to be wifi antennas. Technically, I do not believe that "Polisy" works with zwave or zigbee (or Insteon PLM). All work, however, with the ISY-994. Of course, you can now run the ISY software on the Polisy box, so perhaps that is what you ask. Z-wave will run on ISY-994 without a PLM. I believe the same to be true with zigbee, though I am uncertain whether there is zigbee support on a Polisy-hosted ISY-994 or whether this is limited to the dedicated ISY-994 hardware. I don't believe that zigbee and z-wave can be used simultaneously. I also understand that support for zigbee devices to be relatively limited.

No, I did not think so. It sounds as if you have looked at options and are making an informed decision. Good luck and enjoy.

I must admit to being curious what you think Hubitat can do with Z-wave that the ISY cannot? It sounded as if you have decided to avoid using the ISY mobile app. To be thorough, which app (there are three or four, if I recall) do you view as too complicated? Are you using habitat for Alexa integration of z-wave devices and integration with mobile devices? Sure sounds to me as if you are creating quite the complicated setup.

No problems, YET. Was not worried about initial install. Was more worried about down-the-road, as devices misbehave (as they can do from time-to-time) and troubleshooting and maintenance activities are needed. But...if your prefer to keep the two hubs, it is certainly possible to keep it working if you are aware of the potential issues and manage it.

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.

Perhaps. Yes, I also understand that PLM's are repeaters. Upon further reflection, I have experienced where direct links between two devices working, but communication with the PLM has failed. You are probably correct, however, that the inverse of my experience (PLM>>>device works, but device>>>device does not) may not be assumed. I may have made too broad an extrapolation.

The only amendment I would make to this is that a query could tend to be an indicator of communication problems, but only between the PLM and queried device. It may not be a good indicator of communication between two devices.

If your devices are having trouble communicating with each other, there is little you can do in the settings and configuration to help. This problem must be solved before you can go much further. - do you have many Insteon devices? (There is benefit to a certain number of devices to act as repeaters for the Insteon signals.) - is your PLM plugged into an outlet or circuit with lots of other electronic devices? (Power supplies...UPS...printers...computers....all could disrupt communication to the PLM.)

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.