brians

Not sure when this happened, but today I checked updates in PG3 and there were 8 updates. I am now on PG3 3.0.55 Rebooting entire Polisy after updating I notice IoP is not working correctly with Z-Wave. I troubleshoot a while and determine that something in my custom query program on startup is causing the issue. I narrow it down to when I query my Yale Z-Wave lock it fails (maybe bad communication) and then all future Z-Wave query or control on any other device fails after this. I have to restart the entire Polisy for Z-Wave to work again. This is repeatable and I have restarted Polisy about half a dozen times while troubleshooting this. Not sure if this has anything to do with updates I did today, or not, but the regular Query All program has been running at 3am and my Z-Wave continued to work. I will see tomorrow if Query All breaks Z-Wave when I let it run overnight at 3am. Querying a Z-Wave device and having it fail should not cause Z-Wave to fail requiring Polisy reboot. EDIT: Z-Wave worked this morning and the Query All did run. I also did manually query the lock again and I did not experience the same issue. I was working on this remotely and maybe the lock got into a weird state... the lock continued to report lock/unlocks yesterday. I still don't think Z-Wave entirely should have been affected unless maybe the lock was spamming the network after its query.

I tried restarting the Node server several times and it does not update and is stuck on 3.2.4. Even restarted PG3.

I have the Zen32 for testing and noticed that the four buttons have an internal on/off state regardless if you set the LED to stay on or off. When pressing any of the four buttons it also changes the state of the binary switch but does not actually turn on/off the relay... just the state changes in ISY on-off-on-off etc. The large button turns on/off the relay with each press. However, if you turn on the relay on with large button, then press any of the other buttons, the switch will toggle and make IoP the binary switch as off.. this causes the state to get confused with what is actual and what IoP things... also if you have the binary switch in a scene, it will get triggered upon any button press. You can however make the large button not control the relay at all and just use the entire zen32 as a controller via programs which seems to work ok. All the buttons can trigger a program using control on, even the big button and there is no internal state in this case - buttons always report on when pressed. I suggest upgrading to firmware 10.20 (mine came with 10.00) which allows you to adjust parameter 23 = 1 (documentation on this is incorrect in manual) to turn off the blinking of LEDs whenever a parameter is set - eg. you can change color of LEDs in programs via parameters, and make LED always on or off. Normally when you do this, the main LED blinks to acknowledge, but Parameter 23 makes it silent. One thing I noticed is that If LED is always set on the big button LED always stays on, but the other little buttons if set always on still blink a couple times when pressing them. Is this equivalent to an Insteon switchlink relay? No! not even close. Maybe a different z-wave controller can use it better but at this time, IoP does not work very well with it unless using program hacks. If the internal relay state didn't get messed up by other button states, it would make it much better and could actually use as a switch with extra buttons for programs... but currently is not functional as an actual relay switch - disable the relay using a parameter and just use as a 5 button controller via programs.

I usually set the parameters in programs already instead of doing it all in the NR... I just keep the NR simple. This way they are all similar and I can choose to use the quick custom method currently in PG3 dashboard, or NR and rest of the setup remains consistent. I don't think setting up a NR resource is any more difficult than a customization once you do a couple, but customization makes more sense and would not have the IP address hard-coded in case Polisy IP changes. Here is my Network Resource for Alarm Disarmed - Brian It uses the Envisalink DSC Node server, and I have a Yale Assure Z-Wave lock. The only things I change are top Protocol Information and the Body at lower left. Here is the program that calls it... The only difference would be in the program would call use a customization instead of a Network Resource.

I am fine you releasing it... that is a nice feature. I currently prefer network resources because I can add in variables etc. and this will make it much easier to do and keep track of.

Same here. The Native Links does not seem to do anything.

From how I understand how it works is the Z-Wave controller (meaning the USB dongle in this case) determines the node number when including a z-wave device. ISY uses that number for its nodes/devices and you can rename them to something more friendly. However the ISY does not use this friendly name other than for our benefit to keep things organized and recognizable, and uses the actual node number of the device to reference internally (programs etc). I am wondering if there could be one more level of naming reference in between the one used internally and the z-wave node number... a better explanation for what I am referring to is maybe a zwave node alias. This way you could put any z-wave node ID into an internal ISY node-slot of your choosing. This may just not be possible or realistic to do because of they way ISY is designed to work with Z-Wave and the amount of work required and bugs introduced may not justify the benefits. Maybe it just isn't possible at all.

Ok, what I meant was - I thought you were mainly using your ISY994i and have your only polisy for testing (what I meant as test polisy).

I believe you are running a test Polisy, if so why don't you try taking out the S2 stick and put in your PC. Then try to do the associations based on the info from my links above. The controller and device associations are all store on the stick so you should be able to change settings direct in the PC Z-Wave Controller app. Keep note of the node ID numbers in ISY for reference in the program.

Anyone who has used Z-Wave probably has run into the issue when they have to exclude and re-include the same device, the Node ID increments to the next available number. This number is picked by the actual Z-Wave controller itself (not ISY) and the number is stored in its NVRAM. This results in gaps. Eg. if you currently have the following devices on ISY... If you exclude Light3 and re-include it, rename it, the ID will change to: And the devices will be like this on ISY... Programs and scenes break because they reference the old ZW003, so the resolution is to manually go through all the programs and change to the new device which is ZW005. Z-Wave has a limit of 232 devices, after reaching that limit, it will start at 1 (2 actually, the controller is 1) again and start filling in the gaps. I suppose you could exclude/include the device 232 or so more times to get the counter back where it was but this is not realistic. Now I wonder if it is possible for UD to change the way Z-Wave nodes are created by adding in a reference table. There would be 232 entries and when you add a Z-Wave device you would pick a free slot to add, which would contain the actual Node ID. ISY would instead use the slot number in the table and convert back/forth to/from the Z-Wave controller. UD aready seems to do this for node servers (only has 25 slots)... it is possible to add/remove a Node server from polyglot back into the same slot number and all programs work as before (not sure about scenes because I have not tried this). Initial migration to this method for existing users would be some work however. Any thoughts if this is possible?

I think what UD would like to do is make this all seamless using their existing scenes, but I am guessing that the main problem they are probably running into is the various devices out there which may be difficult to query/set the associations in a standard way; probably why other hubs have a "driver" model, or a scene association utility, or just don't bother with direct association and encourage you to use the "central scene" method via the controller?!? I can see another issue if one has a direct association on a switch with another device, then exclude/include it and node ID changes. Actually this will break Z-Wave scenes and programs in ISY anyways because they use the Z-wave Node ID for creating/naming the device.

This is interesting reading... https://drzwave.blog/tag/z-wave/ https://drzwave.blog/2021/02/01/controlling-flirs-via-associations/ I have another S2 stick on its way which I will use to experiment with some switches in order to learn more about this.

I just got a Zen32 and the binary switch node turns on/off no matter what button I press... the relay or any of the four smaller buttons. This means that if I turn on the big relay, and then press another button it sets it off (doesn't actually change the physical relay state) so this is not good for programs. Each button actually seems to have an individual on/off state which all share one node in ISY. Maybe is older firmware because parameter 23 doesn't appear to work... I am putting in a ticket to Zooz for this firmware.

Just click the red x to left of each device and delete.

Ahh ok. Wonder what was the model of switches that work! Someone here has tried a zooz zen71 without success.

Please explain how you have done this, what model of switches, and what IAW means.

@BuzzhazzI am curioius how you are going to purchase Insteon for new home when there are no Insteon products available. If Insteon was still available and 100% certain of its fate, yes I would definitely get a Polisy and use IoP. For switches and lighting, Insteon and IoP/ISY is superior to Z-Wave in setup and manageability. Supplement Insteon network with Z-Wave devices that are not available with Insteon (which is what I do - I run 2413S, have two brand new 2413U as backup, and an Insteon stick also as backup so I am good regarding failing PLM) If you cannot get Insteon, as far as alternatives to Insteon, Z-Wave seems to be the only other DIY product that one could use in a system with a local hub/controller (not talking about cloud stuff like Google, Amazon, Homekit, "Matter", or the cheap switches/bulbs purchase from Costco etc.).

Disable program1 temporarily then try run program2 and see what happens. can also try changing the variable manually to 0 and if changes back there is some other program setting it.

I remember I suggested to turn off query on restart in other thread. The IoP needs to know status of Lights to turn on or off. Run the query all. I wrote my own query program that is faster when I’m testing and tell it to run on startup. Basically I just added all my devices in and query.

Is this a brand new install or did you restore from an ISY backup? If you have a lot of Insteon devices, try disabling query at restart. It takes a very long time and ties up the ISY during this process. Also confirm the S2 dongle works... what happens when you insert into a Windows PC? Do you see it in device manager? Does your Insteon PLM connect to Polisy by USB or serial?

Seems like other systems can do this. https://www.support.getzooz.com/kb/article/591-how-to-program-your-zen34-remote-switch-on-home-assistant/ However from what I see others showing how to do things in HA (eg YouTube videos) it seems that they just do everything through the controller and spend most of time messing with yaml LOL. Also read that can get confusing when programming setting associations. The only reason I would use is a virtual 3-way maybe. Also seems limit of 5 associations per device i wonder if possible to temporarily put the zwave stick in a windows pc and use other software to like the zwave controller to setup associations. It seems it is independent of the main controller

Follow up after a few days of running the 7.17.2 firmware on S2 stick. I have 20 Z-Wave devices currently on my network. All Z-Wave Plus or higher (eg. 500 series or higher). 41 Insteon devices currently on my network. Seems my Z-Wave network is more stable and responsive but it could be just in my mind. I added back my ZEN25 double plug, which before seems to have been causing lots of traffic on the network and so far I no longer experience the problem - that issue was in the release notes regarding floods of traffic which seemed to be what I was experiencing. Maybe if someone else here has a ZEN25 on older firmware they can let me know if they experience any issues like I did. I haven't seen any typical communication errors for a long time when opening the Administrative Console, even when previously on 7.15 firmware - except when I would include the ZEN25 within a few hours it would cause issue on my network therefore had been sitting in a box unused.

@KCraterGet the Zooz Zen17 because you can separate the inputs from the outputs. I have a couple... one senses a pump motor via dry contact output AC sensor. Another is on my garage door and senses door closed via reed switch, and I use relay out on that for garage button control. Zen17 can do two simultaneous inputs and should work for what you want. To clarify... I can touch a paperclip between the two connections on either of the two the inputs and I can see it almost instantly update the ISY. I have moved to IoP but had working on ISY994i with 500 series Z-Wave before.

Ok thanks, the way it currently works is fine!

I noticed they are selling the Zooz Z-Wave stick for $19 with Polisy. That is cheap for a stick!