brians

After using Z-Wave a bit more... I have I want to update some of my advice after working with Z-Wave and Polisy, IoP. Do not use GE Enbrighten wall switches - they take 2-3 seconds to report their status back to the ISY/IoP. . A Leviton using Hail and query program is way faster than a GE. Exception is the GE wall motion switch updates fast less than a second. This is same issue using ISY994i and 500 series module, not specific to IoP. I recommend ZooZ Zen71 switches. They send status almost instantly. Zooz tends to have firmware support and updates also. If you have error updating OTW firmware on the S2 Zooz stick, it is defective and needs to be replaced. Updating firmware on the stick does not affect any of its included/associated devices from the IoP. If replacing a S2 stick using in Polisy, use the Silicon Labs Z-Wave PC Controller software and do a NVM Backup to a zip file from the old stick first. Then on the new stick do a restore, otherwise you will have to exclude/include all of your z-wave devices into the new stick. If you want you can periodically backup the Z-Wave stick using a PC whenever doing significant Z-Wave changes - until UD makes a backup feature in IoP. To perform OTA firmware update using the Silicon Labs software Z-Wave PC Controller software, uncheck the S2 etc. security option boxes when including the device to the controller... otherwise you will get an error when updating OTA. All the z-wave info is stored on the S2 stick... you can take it out of Polisy and place in your PC and see all the associated devices/nodes in the software - even send on/off commands to devices you have added in IoP. Because of this, you should theoretically be able to update the firmware of any IoP Z-Wave device by shutting down polisy, removing stick and placing temporarily in PC, and then running OTA on the device. I have not tested it but it seems like it should work, otherwise have to do the exclude/include, update on a PC, then include back on IoP (or try replace failed node.. I had that work once). (I have two S2 sticks so I can easily do, if you only have one you will have to get creative). UD plans to do OTA so one day this will not be necessary.

I experimented mine and had a combination of about 11 programs, 4 variables that would allow full updating of LED and status updates of local LEDs from other devices. I thought I had working and would go up to it and turn on/off a button and had it linked with another z-wave appliance module and a keypadlinc key... turning any of these devices on/off would update everything else including the Zen32 button. But I don't know if it was something with my programs or limitation of timing in ISY but every now and then I would encounter a race condition where it would go into a loop turning my test device on/off and I would have to intervene and disable programs. The main issue with Zen32 is that every button press has its own on/off state and it affects the reported on/off state of the binary switch back to ISY. It does not actually turn the relay on/off just the state. A query will read the correct state however and ISY will then get updated to the actually true on/off state of the relay. I attempted to work around this by doing a query of that binary switch whenever any of the five buttons were pressed, and I think that is where the issue was this method being unreliable. Even if it worked, this meant that the big button could never be used in a scene, because it would constantly be toggled on/off by buttons being pressed before my query would set it back to the actual state. I also set the relay to not turn on/off from the physical switch via parameter. I had a program that when press button 5 it turned the relay on/off... sorta a dumb roundabout way but all of this seemed to work 95% of the time and surprisingly turned on or off half second of pressing the switch. A drawback of this method is you lose control of a light in emergency if ISY is offline so this limits its use. I would periodically test the Zen32 using my programs, by pressing buttons on/off and would work, but every so often it would get carried away and start looping programs. I am not sure if ISY is not updating it correctly or reading incorrect on/off states from other buttons because other hubs don't seem to have this issue. I think it is because a custom device handler can be written to work around this and/or by looking at multiple z-wave events at once and making a decision, where the ISY everything is "locked" to a node and can only trigger programs/scenes off one z-wave node event at a time - what I am meaning is it is currently not possible for the ISY to ignore updating the binary switch node if it receives a control on from any of the other four buttons 1-4 (which happen to update that node internally in Zen32). I ended up returning it. If they isolated the binary switch from showing on/off from the rest of the buttons then I would have kept it and recommended this switch. Right now do not waste time or money on it and wait for something else.

I just updated mine from ssh and was 121 updates. Process took about 5 min. then I reboot. Only 4 or so look specific to Polisy (ie. pg3 3.0.56) and rest are regular FreeBSD updates. pg3 3.0.56 has more noticeable blue showing store production. What is difference between production and non production store (is latter for testing?)

@Javi, I deleted and re-installed and is working again. Just need to get rid of a foot or so of snow on my lawn before fully testing

I would like the PG2 web interface moved to a different port for PG2 only, then reconfigure the default page for a general Polisy page with the update and admin features... and could have links to PG2 and PG3.... or maybe just swap PG2 and PG3 for now, and add the settings to PG3. It seems strange to have deprecated PG2 as the default page, and have to use it for things like network configuration and to check for Polisy updates for PG3 etc.

The pg2 web interface check for updates and update seems to be same as sudo. It upgrades everything including pg3. It doesn’t seem to restart services so reboot after.

Yes and the customizations can be used for email also without making a new one... just make the subject suitable for pushover and it ignores the body which can be more detailed in the email. I only do this for real critical things like leaks and alarms.

I just tried... the send sys short with params seems to work good so far but have only tried one... Gonna start converting to that method now!

The program was not yellow, the program would run fine because in the same program it emails me besides sending me a pushover notification. I don't have an actual screenshot because I fixed the few that were an issue, but the line in the program where it has the Send Message didn't show anything. Here is a current screenshot of one of the programs and where I have highlighted in yellow it was just blank until I selected the line and update, save program. The reason I discovered this is because I was getting emails but no phushover notifications. I am moving everything away from the old messages... for one it is a big process if need to change anything - restart Node server, restart IoP etc. Other methods are instant and support variables.

@JimboAutomatesI just noticed that the predefined short messages did not appear to be working after the update. I discovered that I had to go edit the programs that use those and just update the line that had Send. Seems that adding in the Send Sys Short option broke a reference in existing programs that were set to Send and showed nothing and did not send.

Gonna attempt to write some programs to make functional but not sure what I want to use for at this time since I have 6 switchlincs already and sort of used to those. Having the main button state get triggered by all the other buttons really makes it not realistic to use in a spot where it controls a load using its relay unless I don’t care about its status in the controller. Maybe mine is not functioning correct - can someone else confirm it works this way.

I’m on 3.0.55

@JaviNot sure when it happened but the Opensprinkler Node server seems broken after some update I did. I do not check on it all the time because we still have snow, but I just noticed that I get a message to Please set or check open sprinkler password and IP Address. I tried removing/adding the Node server and the fields ipaddress and password do not appear as default. I tried adding via custom parameters and still does not work.

Also shows 1952 in event viewer LOL!

I checked and confirm I do have the new version and is working good even though the reported version is incorrect

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?