RRalston

Hi, I have experience with Zooz, but not Aeotec, though I suspect this may be the same or very similar. Go to X-Ray for the device and select DH Command Classes, then hit Go. A lot of data will come back, but look for a section called: Command Class 134 0x86 VERSION Within that section look for two values: .data.applicationMajor .data.applicationMinor

I know nothing about Kwikset 620 Zwave 700 deadbolts, but doesn't it seem plausible that particular lock is malfunctioning? It's apparently communicating and accepting commands, but it still has to convert those commands into a mechanical action. It may make sense to contact Kwikset support as well.

First, I agree, a simple way to comment out line(s) of code would be nice, but I have used the following method with success. Check out the last comment in this thread:

I submitted a support ticket and found out the BIOS update is indeed a separate process and requires a monitor & keyboard connected to the eISY to complete. However, I also determined the intended method is not currently working as designed, but Michel provided a work around, which I completed successfully. If you really want to get this BIOS update installed, I suggest you open a support ticket for specific guidance. Michel is very helpful and responsive. Rob

I submitted a ticket, and Benoit was able to reproduce. Per Benoit, the fix will be in the next PG3x release.

I submitted a ticket, and Benoit was able to reproduce. Per Benoit, the fix will be in the next PG3x release.

That makes sense. I indicated in my initial post I didn't know which component was the problem. Anyway I submitted a ticket and logs.

I will open a support ticket for this and the VUE plugin.

Hi Bob, Thanks for the response. What you say makes sense, but it is not my experience. Stopping the node server shows Disconnected in PG3x, but Connected in AC. Only the reinstall behaves as expected. I will open a ticket to work through this. Rob

Updated without issue. BIOS security update is stated in release notes. Is that update automatically included in the "Upgrade Packages" operation, or are we supposed to know to also push the "Upgrade BIOS" button? sysconfig.txt makes no mention of BIOS version, so a bit difficult to know BIOS status. Thank you.

So this is interesting. I received notification about the Python 3.2.4 update. I had time, so I quickly did a "re-install all" to get this update. During the reinstall, I received a VUE disconnected notification email, then about 30 seconds later, received a connected notification email (per my programs). After that I stopped the VUE plugin again to test, but still no notification for that. Thought this info might be helpful to whoever would look into this issue:

Hello, I am on eISY v5.7.0_5 and PG3x v3.2.15 and VUE Version: 1.0.26 [Production] Trying to create notifications for a couple of node servers when they may be stopped and disconnected. What I have found is that the status for VUE and one other always shows "Connected" in the eISY AC, when I manually stop the plugins. Not sure if this is a plugin, PG3x or eISY issue, but my notifications are never triggered. Rob

Hello, I am on eISY v5.7.0_5 and PG3x v3.2.15 and Climacell Version: 2.0.1 [Production] Trying to create notifications for a couple of node servers when they may be stopped and disconnected. What I have found is that the status for Climacell and one other always shows "Connected" in the eISY AC, when I manually stop the plugins. Not sure if this is a plugin, PG3x or eISY issue, but my notifications are never triggered. Rob

I think you may be having trouble with a service called mDNS [multicast DNS], which uses port 5353 IN/OUT to create local records to simulate a DNS server on the local network. I found this was causing me trouble related to the eisy.local:8443 name resolution. If you have a local host firewall, it may be blocking these ports and services. Windows svchost.exe is directly involved with this. You can search for mDNS and find many articles, but here is a reasonable post: https://stevessmarthomeguide.com/multicast-dns/ Rob

I removed this as I realized it was for wrong PG version

Just saw this post, so I did an IoX restart as suggested by Chris. This did not fix the nodes for the device. Rob

I think everyone is misunderstanding my post about DHCP. I am well aware it now defaults to DHCP and is not intended to be changed to static. I have a reservation to meet that need. If you look again at the picture I posted, you will see the IP Address acquired is 0.0.0.0. It should show the DHCP assigned address. Support has confirmed and indicated the fix will be released, possibly tonight.

I am on eISY, v 5.7.0 for both. And yes, I think OTA could use a big tweak. Thanks, Rob

Thanks for the suggestion. Apparently the device did not get upgraded in spite of what the UI said. After performing the Synchronize | Update with Interview, the device was removed and put back but without the sub nodes. It was removed from programs. What value does the Sychronize process have if it breaks things? I am confused as to the steps to properly correct this now. Do I have to remove the Z-Wave device and add it again, then fix my programs? Is that how it will always be for all OTA updates?

I have 5 Zooz ZSE42 Leak Detectors with out of date firmware. To be careful, since OTA is new, I chose one that is the least critical to test OTA with. To start, I verified the firmware version to be 1.40, using X-ray, DH Device : Integer DATA devices.12.data.applicationMajor = 1 (0x00000001) Integer DATA devices.12.data.applicationMinor = 40 (0x00000028) I wanted to update to v 1.50, so I downloaded "ZSE42_V01R50_US.zip" and extracted contents. Not knowing how this process was going to work, and how the UI would handle communications issues with a battery operated device which is not always listening I plowed forward: NOTE: I did not wake the device manually during this process, as I kind of assumed things would error out if it wasn't listening. Hmmm, it finished? So that is interesting, but re-inspecting the version info via X-ray, shows it is still on 1.40. OK, this is new stuff, so let me wake it up before attempting the upgrade. Well, that did no good, as the UI sits at "Starting upgrade..." or something similar. Never shows any fragment transfers now. Hitting the stop upgrade button doesn't really do anything and it never gets out of that mode, unless I reboot the eISY. Contacting Zooz support, they tell me I have to keep waking it up during the upgraded process for it to complete. Well, that is pretty stupid design, but let me try that....several times. I cannot make sense out of this, and will not try to upgrade anything else until OTA is more robust. In addition to the above, the device still appears to be woking and reporting in regularly (the automatic wake up and listen process), but it is either no longer reporting its battery level, or the Admin Console is no longer displaying the battery level, as it does for all the other 4 ZSE42 devices I have not tried to upgrade. So I am wondering what others are seeing with OTA, in particular Zooz devices. Thanks, Rob

I am also seeing all programs disabled after some reboots. It happened immediately after the upgrade that was supposed to have it fixed, and then subsequently after reboots done out of frustration with OTA updates not working. I will post about OTA and Zooz separately, but my problem is with a Zooz ZSE42 Leak Detector (battery operated). Also, I have notice that on the configuration page, the DHCP IP parameters are no longer displayed. I will submit a ticket about that. This has been a strange update.

I have used "${sys.program.#.name}" for that purpose. But I have also found in many cases, just using the "Default" email content yields a lot of good information.

For ZooZ devices, I have found the Firmware version information using X-Ray and the "DH Device" query. it is listed like this: Integer DATA devices.8.data.applicationMajor = 1 (0x00000001) Integer DATA devices.8.data.applicationMinor = 30 (0x0000001e) I have checked 5 devices and this info is consistent with the version info provided on the device when received.