
wmcneil
Members-
Posts
219 -
Joined
-
Last visited
Everything posted by wmcneil
-
Update: The new power supply did not solve the problem. The isy service restarted several times early this morning, then when I manually initiated a 'query all', the box crashed and generated a *.core file (and then restarted), which the UD folks are debugging now.
-
The UD folks are helping me with the ticket I opened. Debug is not complete yet, but a couple of points that may help others: I have a rather old polisy. It shipped with a 12VDC 1amp power supply. One of the things I am trying currently is the use of a 12VDC 2amp supply. This was at the suggestion of UD. (I am using the ZMatter card in the polisy.) I have a program with an empty 'if' section and an email notification in the 'then' section. I have the "run at startup" option selected for this program. This causes the email notification to occur whenever the ISY service on the polisy box restarts. What UD has clarified is that the restart of the ISY service does necessarily been the box has rebooted. "Random" ISY service restarts should not be happening, nor should "random" reboots. In my case, I have been experiencing "random" ISY service restarts, not "random" reboots. Time will tell if the different power supply affects the behavior.
-
@kzborayYes, there was a reboot issue resolved in a firmware version prior to 5.5.9 , so the reboot issue I am experiencing is something different. I realized today that the reboot is frequently happening not long after a query all is issued, so that may be a hint. I do have a ticket open and am waiting for UD response.
-
@kzboray, I've been getting spontaneous reboots of my polisy about once a day or so. Luckily so far, there has not been any loss of functionality. I'm running IoX 5.5.9 , and am waiting for the next IoX code release and hoping it fixes the problem.
-
There is a bug with IoX not recognizing that a device has woken up, and therefore not performing writes to the device which are pending. I have a ticket open concerning this for my Zooz ZSE29 motion sensor, and in the last update to that ticket (about a month ago) UD was working to understand why the bug is occurring. I don't know if this same bug could apply to the Aeotec Water Sensor Pro 7 or not.
-
There is discussion from myself and others about Zooz ZSE29 in the support thread for IoX 5.5.7 release. I have a ticket open, and thought I would open a new thread and give an update: My ZSE29 is hardware version 1.0 At the suggestion of UD, I did more testing, and confirmed the following: * Wake-up does not occur due to motion detection. Wake-up occurs at power-on, and at the wake-up interval, which is set by default to 4 hours. Once woken up, the device stays awake for 10 seconds. The wake up interval value does not appear to be configurable in any way. There is no difference in behavior for battery powered vs continuous DC power supply. I did a test where I initiated a write changes from the AC immediately after having applied power to the ZSE29. The writes did complete for this scenario, as evidenced by the green 1011 icons in the AC going away after just a few seconds. Even with the default wake up interval of 4 hours, the write changes should have been written at the first wake up event. UD is continuing to investigate why IoX code is not performing the write when the wake up happens.
-
- 2
-
-
My ZSE29 is HW version 1.0, which does not support firmware version updates.
-
Good suggestion, unfortunately did not work. I kept the motion sensor triggering while attempting a write changes, and got the same result. Also on the wake up node, I changed the keep awake setting to on, tried the write again, and got the same result.
-
The device is connected to continuous 5V power. Selecting Write Changes causes the icons to change to WRITING briefly, then they return to 1011 and appear to be stuck there. I do have a ticket open.
-
Thanks for the info. I have excluded/included my zse29 several times. If I select no security options, the motion sensor node gets added. The motion sensor node is now working (reports status ON in the AC when motion is detected), but the motion sensor and all of the other nodes show the green outstanding write icon (has 1011 digits in it) that does not go away (has not gone away after 24 hours or so.)
-
Yes. Writes still seem to be stuck. Doing a synchronize/update or synchronize/replace with interview (after having previously done an exclude/include) actually causes several of the associated nodes to disappear, including the motion sensor node.
-
Thanks @brians and @DennisC for the suggestions. I tried excluding/including with no security options checked. That resulted in more associated nodes, and the AC is showing the IOW icon for all the associated nodes (seems to be stuck trying to write). I still have blank status for the Motion Sensor node, and when I try a query on it I get an error popup window. I also tried turning compatability mode off, then rebooted polisy. When reboot was finished, I tried a query of the motion sensor node, and got a TCP client read response failed. I am wondering if the zse29 hardware has gone bad. I only have one of them.
-
Updated both my polisy/ZMatter systems to 5.5.7 . The IoX spurious reboot problem appears to be gone. I do continue to have a problem with my Zooz Zse29 outdoor motion sensor. It is continuously connected to a 5V power supply. I did an exclude, and a secure include. The primary device shows three values in the AC: V1 Alarm Type, V1 Alarm level, Battery Level. All three values are blank. When I attempt a query in the AC, I get a pop up window that says Error Request Failed. I will open a ticket.
-
I opened a ticket. Michel responded and stated that this is a known issue and a fix is hoped for by tomorrow.
-
I've updated and migrated my home polisy/5.5.0/pg3_3.1.17/zooz_zst10 to 5.5.6/pg3_3.1.17/ZMatter. After manually initiating an update and interview for each of my zwave devices they all seem to be working. But, the polisy keeps rebooting itself. The time between reboots seems to varying from around 15 minutes to 60 minutes. PG3 is reporting that 3.1.18 is available, but the AC update does not cause 3.1.18 to be installed (or at least it is not being reported as installed in the web browser) sudo pkg info udx reports 3.3.6_3 sudo pkg info isy reports 5.5.6 sudo pkg info pg3 reports 3.1.17_1
-
Started with polisy/5.5.5/pg3 1.1.17 I did an upgrade packges using AC button. After 4 beeps power cycled polisy. AC showed 5.5.6 , but PG3 was not started. I tried a couple of polisy reboots. PG3 still not started. Then I opened an SSH and ran the update command that @brians posted. That resulted in the same package update shown in @brians post, and now PG3 is running.
-
polisy/5.5.5 : AC authentication working only for https, not http
wmcneil replied to wmcneil's topic in IoX Support
I had done a reboot not too long before I was trying to authenticate, so that could be a strong hint. -
Polisy/5.5.5 , Today suddenly when I attempt login to AC using the http link in IoX Finder, my user/password will not authenticate (I tried admin/admin and that was not working either). This happened every time I tried over the course of about 15 minutes. When I tried the https link in IoX Finder, authentication worked correctly. Given all the other churn going on with ZMatter, and eisy, I thought I would mention this in a form post, in the hope it helps someone else. I'm not going to open a ticket at this point, as there are so many other more pressing issues at the moment.
-
In the AC, right click the sensor / ZWave / Set Configuration parameter use the pull down to select parameter number 64, then click on Query
-
My Multisensor 6 is now displaying farenheit in the AC. I am running Polisy/5.5.5/ZMatter. After verifying that parameter 64 was configured to a value of 2, I had to do an update with interview to get this working. The AC started displaying farenheit immediately after the update with interview completed.
-
5.5.3/ZMatter: lock REST commands no longer working
wmcneil replied to wmcneil's topic in IoX Support
UD provided the solution in my ticket. The REST API is slightly different for ZMatter zwave than it is for the original zwave: original zwave: http://uname:password@IP:port/rest/zwave/node/... ZMatter zwave: http://uname:password@IP:port/rest/zmatter/zwave/node/... EX: http://uname:password@IP:port/rest/zmatter/zwave/node/ZY002_306/security/user/2/delete- 1 reply
-
- 1
-
-
5.5.3/ZMatter: Kwikset 914 deadbolt lock. The following two rest commands no longer work. When entered in a web browser no data is returned and eventually the browser displays "the connection was reset. http://uname:password@IP:port/rest/zwave/node/ZY###_###/security/user/2/delete http://uname:password@IP:port/rest/zwave/node/ZY###_###/security/user/2/set/code/WXYZ ZY###_### is the address of the Access Control Alarm that is associated with the ZWave lock. I have opened a ticket.
-
Any code you have that was accessing the lock primary device / User Number can be changed to now access the lock Access Control Alarm associated device / User Number
-
I am experiencing the same problem - status never updates. gocontrol GD00Z-8 garage door controller, 5.5.3, ZMatter. Did you file a ticket? If I issue an open comand or a close command, it works, but my programs that are using the status value do not work, of course.
-
Thanks for the update, appreciate it.