AKAPADIA

I'm having trouble with my Zooz Zwave door open/close battery operated sensors. (Aside: I'm having to reinstall all my Zwave devices due to some sort of corruption while running 5.6.2 and have managed to restore thermostats and wall switches), but the open/close sensors don't work. Don't work => I can remove and add them back to the Zwave network, but then when I query the state I get nothing but a Request Failed dialog box. Anyone have insight into whether this is 5.6.3 related?

I reinstalled some thermostats and wall switches and they work ok. My battery operated Zooz open/close sensors, however, don't seem to work even after delete and reinstall. So I'm wondering if there is a breaking change in the new 5.6.3 update.

Thanks @Techman. Running the latest, 5.6.3, PG3x .36.

Thanks @Techman. Interestingly, after the power on recycle the errors have become more weird. When I query a light switch for its state, I get the dialog box picture attached. After the reboot, it seems to be querying all devices and saying "device xy is not awake" - it seems to think all the devices are asleep.

I just confirmed that deleting and readding one ZWave device works - but I am dismayed that I have to do that and update all the programs to use the new node values ...

No, I get a full ZWave menu; where would I see that message of not responding?

Thank you @landolfi. To be clear, though, mine stopped working before the upgrade. I did the upgrade as a last ditch effort to resolve.

The problem happened with 5.6.2. I am running a Polisy with ZMatter ZWave. One of the things I did to try and fix it was upgrade to the latest firmware and so I am now running 5.6.3. I did not have a ZWave backup - I didn't realize that I needed to do that separately from backing everything else up, unfortunately. Does this mean I have to delete and reinstall all my dozens of ZWave devices and fix up the programs manually :-(? Even if I have to reinstall the devices, if I could preserve the node ID it would be very useful

A weird thing occurred this evening while I was out of the house. I got a bunch of notifications on my UD Mobile app that nodeservers were going offline. Various systems stopped working that depended on the nodeservers. I got home and went to the admin console and noticed that all my programs had disappeared. The top level node was empty. I restored from a backup but the ZWave devices are missing. When I click and do a Query on a ZWav devices I get an error dialog "TCP client read response failed". Other devices just say "Request Failed" I tried healing the ZWave network and rebooting and updating the system to the latest firmware, disabling and reenabling zwave support in IoX, rebooting and restarting the system, but the zwave functionality remains broken. Nothing in the zway.log jumped out at me. The failure has affected switches, thermostats, open/close sensors, pretty much everything. When I reboot I get a long system busy dialog and then a bunch of zwave device not awake messages. Would appreciate any suggestions on what to do here.

Tried rebooting the router, didn't help. Could successfully sign into the UD portal, and shows the ISY off line Yet, I do know the ISY is online because some programs seem to be running, such as my startup program. Will try a support ticket next.

Thanks @DennisC. Tried the shutdown (safely, thru the portal). Waited 10 minutes before plugging back in. Haven't logged in but the debug.log still showing the same error message. To be clear, I did do the upgrade using the admin console "Upgrade Packages". It's only after the reboot that hosed things did I try the sudo pkg install commands, because there didn't seem any other way to retry the upgrade. Even before this, I've tried both reboot and shutdown several times, to no avail.

Following the instructions, the upgrade worked for me and the .18 version and 5.5.7 came up just fine. After that just to be sure I was launching off a clean slate, I rebooted the Polisy. After that, PG2 and PG3 come up, but ISY seems hosed. Looking at the debug.log I see: 129:initPolyglot()) 2023-02-27 14:55:32 - Error| udx [T:34389175808] failed retrieving creds from udx. Retry 29 (../src/udx/UDXComm.cpp@129:initPolyglot()) 2023-02-27 14:55:34 - Error| udx [T:34389175808] failed retrieving creds from udx. Retry 30 (../src/udx/UDXComm.cpp@129:initPolyglot()) 2023-02-27 14:55:36 - Error| udx [T:34389175808] failed retrieving creds from udx. Retry 31 (../src/udx/UDXComm.cpp@129:initPolyglot()) Eventually it gives up and says it's bailing out and that the client failed to initialize I have tried sudo pkg install -r udi pkg sudo /usr/local/etc/udx.d/static/udxops.sh upgrade.polisy Both don't show any more changes are required. Something does seem to be running though as I have a startup program in ISY that seems to run as it sends me an SMS saying it ran and that it concluded. However, nothing else seems to work. Anyone have any ideas on what's up? Thank you for any pointers. This is the second upgrade mess I seem to have got myself in after the upgrade to 5.5.x. I am losing confidence in my ability to do upgrades in spite of trying my hardest to follow the steps exactly. I am running Polisy with a ZMatter board inside of it.

For the record for this thread support says this is a bug and will be fixed in 5.5.7 (in thread linked above). Thank you @tmorse305 for drawing my attention to the Eisy thread.

Fantastic, thank you for that update!

I think so - it's comprehensively described like I did in my forum post. I turned to the forum because the support request didn't go anywhere.

FWIW, I posted a support ticket, but was told I couldn't be helped with the issue.

I'm seeing the same behavior with my Polisy PRO. Link to all the things I tried: Multiple new 8 button Keypadlink #2334-2 showing up with only 4 nodes in Polisy IoX v5.5.6

I have an 8 year old Keypadlink (KPL) that started failing, so I tried to replace it with a new one I have been keeping in spare. I was surprised to find that it only showed up in IoX (running on a Polisy PRO with firmware 5.5.6) with 4 nodes, the -1, -B, -C and -D nodes (E-H missing). I tried a different spare KPL and saw the same effect. I tried numerous things: - remove and readd, with and without reboots of Polisy - remove and readd, with and without KPL factory resets - remove and readd, with auto-detect and also with explicit selection of device that's being added (i.e. 2334-2) - remove and readd, with KPL factory reset and force setting KPL in 8 button mode (pull out air gap switch, hold down A+H buttons, push back switch, wait 3 seconds, wait for beep) Since this is happening with two distinct KPLs, I don't suspect the KPLs. I'm adding the XRay output for this device as an attachment in case that helps. Would appreciate any ideas very much, as I do need an 8 button scene controller in this particular location and there are no ZWave equivalents I know of (would be happy to take recommendations, if any, for ZWave or Zigbee equivalents).

I messed around with the ELKRP - just logged in and deleted the problematic zone and readded it and it seems to have unstuck it. So this seems like an ELK issue..

JFYI, I have restarted the Node server and rebooted the polisy multiple times but it doesn't help. In the previous version (3.8.8), every so often (every few weeks) I would bump into this situation where output cmds would stop being honored (even though they would return HTTP 200). I had to reboot the Polisy device to fix. Now, the reboot doesn't work. Also, there is nothing in the Node server log even when set to DEBUG.

I have a browser based repro where in one window I do a GET on 192.168.1.213:8080/rest/nodes/n003_output_14/cmd/DOF and in another window a GET on 192.168.1.213:8080/rest/nodes/n003_output_14/ abd the output remains On: <nodeInfo> <node flag="0" nodeDefId="output"> <address>n003_output_14</address> <name>HVAC-Bed 2</name> <family instance="3">10</family> <parent type="1">n003_controller</parent> <type>4.3.2.1</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>n003_controller</pnode> </node> <properties> <property id="ST" value="100" formatted="On" uom="78"/> <property id="TIME" value="0" formatted="0 seconds" uom="58"/> </properties> </nodeInfo> This is working for other Output zones. This only started breaking after I upgraded.

After upgrade to 3.4.9 from 3.8.8, DON/DOFF to Output zone don't stick. The zone status remains what it was before.

@webminster, any other programs that do network calls can cause problems with programs that have nothing to do with the network in my experience. Suggest disabling all network programs and seeing if problems go away and then selectively enabling network programs one by one if they do until you find the problem.

@Michel Kohanim, but why would three network calls with a 1 second timeout introduce delays of up to 30-40 seconds? That's the part that I found unintuitive.

@Michel Kohanim, yes, this is a Scene that targets a KPL button; I'm turning the scene off. This exact same program worked for years with the ISY. It fails on the Polisy. It failed just now again tonight. The program keeps running as if the timer has either been refreshed or has not run out and the admin console shows that the program is running (green icon) even after the timer should have fired.