Zooz firmware version

🛎️ Get Help
21

Actually you didn't follow the instructions because if you had, you would have posted the logging results after running the last test when it didn't work...

If you follow the instructions EXACTLY as written then the driver will log a "requesting firmware" message when it requests it and seeing all the log messages during the test will show whether the driver isn't requesting the report, the device isn't sending it, or the driver isn't storing the value when it's reported.

Since this is something that's difficult to re-create that information is crucial if there's a bug in the driver that Hubitat can fix...

22

Nope.

It didn't bother me that I can't see firmware version, and I don't really need it for any particular reason. I was just curious to see if mine did report or not to maybe assist John2020. I posted to support his position that some apparently don't report firmware version for some reason or another.

My sensors are all attached to the ceiling, so I really didn't want to climb up just to try and get them to report firmware version. Maybe the next time I change the battery I will do so.

23

That's great and I love the support. The devices do report firmware though. They definitely (all versions of the firmware) support that command class and do respond to the request if they are awake. The troubleshooting steps are for you to help us determine if we need to ask (@ mention) the HE devs to take a look at this to fix a potential bug in the official driver. It would be great if either of you were able to follow those steps exactly and report back the findings.

That's great.

1 Like
24

When I get my new sensor later this week I will preform the steps and let you know what happens. It will be interesting if I get different results from different sensors.

1 Like
25

When including in-place, mine wouldn't report firmware version and sometimes humidity even after several inclusion, exclusion, factory reset, inclusion cycles. With sensor in hand I walked over to the hub (a couple of rooms over) did a factory reset once again then performed the inclusion - it included much faster and everything showed up. Now if there was only some way to get it to wake up faster than 3-5 minutes to report humidity/temp/lux it might actually be useful. As a motion sensor it is great.

26

@gd_brock battery-powered devices take great pains to optimize battery life so often only report on a change of condition by a certain value, percentage etc. You may be able to change the minimum values that it takes to trigger a report but battery life will be affected. I would check the manual for your sensor and see if there are device parameters that can be altered. If there are, you can change the driver for the device to the basic Z-wave tool
You will need to remember the need to press Configure any time you change drivers and will need to know how to get your battery-powered device to stay awake for an extended time (check your manual). Did I forget to add, battery life will be affected?

27

The device only takes measurements at 3 minute intervals so even with it set to the most sensitive thresholds there's no way to make it report more often than that.

The built-in driver supports all of the configuration parameters.

That might be true with that basic Z-wave tool, other custom drivers, or zigbee devices, but most of the built-in drivers keep track of the settings so if you make a change it knows which settings are out of sync and automatically sends those changes to the device the next time the device wakes up.

Pressing configure can actually hinder the sync process for a lot of the built-in z-wave drivers because it makes the device send all of the configuration parameters to the device instead of just the ones that were changed.

I don't believe I've seen any battery devices go back to sleep while commands are still being sent to it and the last command all drivers send to a device tells it to go back to sleep so I've never seen a device with an option to "stay awake for an extended time".

A lot of z-wave devices allow you to adjust how often it wakes up, but that's not necessary because almost all battery z-wave devices can be manually woken up.

A lot of the built-in z-wave drivers log the instructions for manually waking the device up when you change a setting and save, but most manufacturers also include those instructions in the manual.

1 Like
28

And so he would set Parameter32 to 7? You need to know what parameter to change and what to change it to.
Configure was not necessary and perhaps as you said, could be detrimental in some cases.
Zwave parameter changes do get queued for the next time a device communicates, but I have seen them get missed. Triggering the device to wake is usually done with the tamper switch, reconnecting batteries (in the manual). Having them awake to receive parameter changes means you can also check to make sure they were received and changed before switching the driver back.
As for waking up a battery device, I have never seen that other than for FLiRS so I would love to see some documentation for that. Seriously.

29

No.. The Zooz 4-in-1 only has parameter numbers 1 - 7 and even if there was a 32 you wouldn't have to know that when using the built-in driver because the setting fields are labeled and list the supported values.

The hub doesn't cache the commands and automatically send them the next time the device wakes up, that's something the driver has to do.

With the built-in driver, it requests reports after sending the changes and logs (when debug logging enabled) the setting names and values reported by the device so you can easily see if they changed. Most of the built-in z-wave drivers do this...

That basic z-wave tool is great for devices that aren't supported by Hubitat or dedicated drivers that aren't fully implemented, but it's not necessary for most of the built-in drivers.

Documentation for what?

If you were referring to my comment about battery devices not going to sleep while commands are being sent to them, I said "I don't believe I've seen", I didn't say it's a z-wave specification or that it doesn't happen.

I just know that I've written handlers for a lot of battery z-wave devices and after the driver receives the wake up notification from the device and starts sending commands back to it that are spaced less than 1 second apart, I can't think of any devices that would fall back to sleep before it finished.

If that's not what you were referring to then please elaborate.

30

I'm not trying to argue with you. You know the specific device and the driver, I don't. If the built-in driver exposes all the available parameters, great. Since the poster didn't seem to know how to change how often something reported, I assumed that not everything was exposed. and therefore I suggested what I did. I was offering a very generic response, that, knowing nothing about a specific device, would work in a generic way to explore what might be available as far as unexposed settings are concerned.
I really did not want this to escalate into a shoving match and in fact quite the opposite. I would like to PM you with some ideas.

2 Likes
31

krlaframboise I checked out your driver while I was troubleshooting so thanks for your efforts.

I really don't want to hijack the thread since it is about firmware version so I'll be brief. I understand about the 3-5 minutes. What makes it less than ideal for me is that it won't report H/T/L while motion is active. I wanted to use this in a bathroom with humidity and fan control as part of my solution and it is hard not to have motion when someone in the bathroom taking a shower or bath.

32

Unless you're referring to my SmartThings DTH then that's Hubitat's driver you tried, but I'm very familiar with that device and I've written a lot of handlers/drivers.

I'm assuming the original poster is all set since he didn't provide the information needed to determine which part of the firmware process isn't working, and that information was crucial to potentially solve the problem for him and others in the future, so I wouldn't worry about hijacking the thread...

I've never noticed that issue before, but it sends light, temp, and humidity reports at the same time whenever any of them exceed their threshold setting (at 3 minute intervals) and sometimes all 3 of the reports don't make it to the hub.

I'm wondering if the device is actually sending the reports while motion is active, but some are getting dropped and the ones making it to the driver are being suppressed because their values haven't changed.

It's probably not that, but you can easily rule it out by enabling debug logging and seeing if it logs any sensor multilevel reports in between the motion active and motion inactive log entries. Keep in mind that debug logging turns off after 30 minutes...

33

I just installed my new Zooz 4-in-1 sensor and have followed the steps that Kevin indicated. Looking at the log I see one instance requesting the firmwareVersion in the log just after including it, however it does not respond with the firmwareVersion. Here is my log as requested.

dev:1292020-03-14 17:41:52.744 debugThe changes will be synced the next time the device wakes up.  You can force the device to wake up immediately by using a paperclip to push the recessed button on the bottom of the device.

dev:1292020-03-14 17:41:52.710 warnTemperature, Light, Humidity, and Battery will be requested the next time the device wakes up.
dev:1292020-03-14 17:41:52.708 debugrefresh...
dev:1292020-03-14 17:41:47.580 debugThe changes will be synced the next time the device wakes up. You can force the device to wake up immediately by using a paperclip to push the recessed button on the bottom of the device.
dev:1292020-03-14 17:41:47.543 warnTemperature, Light, Humidity, and Battery will be requested the next time the device wakes up.
dev:1292020-03-14 17:41:47.542 debugrefresh...
dev:1292020-03-14 17:41:02.319 infoHallway Sensor 2: syncStatus is 1 Pending Change
dev:1292020-03-14 17:41:02.310 debugThe changes will be synced the next time the device wakes up. You can force the device to wake up immediately by using a paperclip to push the recessed button on the bottom of the device.
dev:1292020-03-14 17:40:54.272 debugLED Indicator Mode (Param #7) = 4
dev:1292020-03-14 17:40:54.195 debugConfigurationReport(configurationValue:[4], parameterNumber:7, size:1) scaledConfigurationValue: 4
dev:1292020-03-14 17:40:52.252 debugLight Change Trigger (Param #4) = 10
dev:1292020-03-14 17:40:52.165 debugConfigurationReport(configurationValue:[10], parameterNumber:4, size:1) scaledConfigurationValue: 10
dev:1292020-03-14 17:40:50.213 debugHumidity Change Trigger (Param #3) = 10
dev:1292020-03-14 17:40:50.136 debugConfigurationReport(configurationValue:[10], parameterNumber:3, size:1) scaledConfigurationValue: 10
dev:1292020-03-14 17:40:48.181 debugTemperature Change Trigger (Param #2) = 10
dev:1292020-03-14 17:40:48.097 debugConfigurationReport(configurationValue:[10], parameterNumber:2, size:1) scaledConfigurationValue: 10
dev:1292020-03-14 17:40:46.160 debugMotion Sensitivity (Param #6) = 3
dev:1292020-03-14 17:40:46.083 debugConfigurationReport(configurationValue:[3], parameterNumber:6, size:1) scaledConfigurationValue: 3
dev:1292020-03-14 17:40:44.170 debugMotion Retrigger Interval (Param #5) = 15
dev:1292020-03-14 17:40:44.090 debugConfigurationReport(configurationValue:[15], parameterNumber:5, size:1) scaledConfigurationValue: 15
dev:1292020-03-14 17:40:42.113 debugWake Up Interval = 14400 Seconds
dev:1292020-03-14 17:40:42.081 infoHallway Sensor 2: syncStatus is Syncing...
dev:1292020-03-14 17:40:42.072 debugWakeUpIntervalReport(nodeid:1, seconds:14400)
dev:1292020-03-14 17:40:40.920 infoHallway Sensor 2: battery is 100%
dev:1292020-03-14 17:40:40.918 debugBatteryReport(batteryLevel:100)
dev:1292020-03-14 17:40:37.981 infoHallway Sensor 2: illuminance is 38lux
dev:1292020-03-14 17:40:37.972 debugSensorMultilevelReport(precision:2, scale:0, sensorType:3, sensorValue:[28, 131], size:2, scaledSensorValue:72.99)
dev:1292020-03-14 17:40:35.954 infoHallway Sensor 2: humidity is 40.24%
dev:1292020-03-14 17:40:35.945 debugSensorMultilevelReport(precision:2, scale:0, sensorType:5, sensorValue:[15, 184], size:2, scaledSensorValue:40.24)
dev:1292020-03-14 17:40:33.981 infoHallway Sensor 2: temperature is 69.46°F
dev:1292020-03-14 17:40:33.970 debugSensorMultilevelReport(precision:2, scale:0, sensorType:1, sensorValue:[8, 33], size:2, scaledSensorValue:20.81)
dev:1292020-03-14 17:40:31.890 infoHallway Sensor 2: tamper is detected
dev:1292020-03-14 17:40:31.885 debugNotificationReport(v1AlarmType:7, v1AlarmLevel:255, reserved:0, notificationStatus:255, notificationType:7, event:3, sequence:false, eventParametersLength:1, eventParameter:[3])
dev:1292020-03-14 17:40:31.640 debugRequesting Battery Report
dev:1292020-03-14 17:40:31.619 debugRequesting Illuminance Report
dev:1292020-03-14 17:40:31.600 debugRequesting Humidity Report
dev:1292020-03-14 17:40:31.579 debugRequesting Temperature Report
dev:1292020-03-14 17:40:31.559 debugRequesting Tamper Report
dev:1292020-03-14 17:40:31.527 debugsyncDevice()...
dev:1292020-03-14 17:40:31.452 debugDevice Woke Up
dev:1292020-03-14 17:40:26.770 infoHallway Sensor 2: motion is active
dev:1292020-03-14 17:40:26.766 debugNotificationReport(v1AlarmType:7, v1AlarmLevel:255, reserved:0, notificationStatus:255, notificationType:7, event:8, sequence:false, eventParametersLength:1, eventParameter:[8])
dev:1292020-03-14 17:33:38.373 debugRequesting Battery Report
dev:1292020-03-14 17:33:38.352 debugRequesting Illuminance Report
dev:1292020-03-14 17:33:38.333 debugRequesting Humidity Report
dev:1292020-03-14 17:33:38.310 debugRequesting Temperature Report
dev:1292020-03-14 17:33:38.290 debugRequesting Tamper Report
dev:1292020-03-14 17:33:38.280 debugRequesting Motion Report
dev:1292020-03-14 17:33:38.229 debugsyncDevice()...
dev:1292020-03-14 17:33:28.101 debugDevice Woke Up
dev:1292020-03-14 17:31:11.868 debugRequesting Battery Report
dev:1292020-03-14 17:31:11.847 debugRequesting Illuminance Report
dev:1292020-03-14 17:31:11.826 debugRequesting Humidity Report
dev:1292020-03-14 17:31:11.805 debugRequesting Temperature Report
dev:1292020-03-14 17:31:11.785 debugRequesting Tamper Report
dev:1292020-03-14 17:31:11.776 debugRequesting Motion Report
dev:1292020-03-14 17:31:11.726 debugsyncDevice()...
dev:1292020-03-14 17:31:01.607 debugDevice Woke Up
dev:1292020-03-14 17:30:16.110 infoHallway Sensor 2: syncStatus is 7 Pending Changes
dev:1292020-03-14 17:30:16.102 debugThe changes will be synced the next time the device wakes up. You can force the device to wake up immediately by using a paperclip to push the recessed button on the bottom of the device.
dev:1292020-03-14 17:30:11.954 warndescription logging is: true
dev:1292020-03-14 17:30:11.952 warndebug logging is: true
dev:1292020-03-14 17:30:11.951 infoupdated...
dev:1292020-03-14 17:27:06.052 debugRequesting Firmware Version
dev:1292020-03-14 17:27:06.050 debugRequesting Battery Report
dev:1292020-03-14 17:27:06.048 debugRequesting Illuminance Report
dev:1292020-03-14 17:27:06.047 debugRequesting Humidity Report
dev:1292020-03-14 17:27:06.045 debugRequesting Temperature Report
dev:1292020-03-14 17:27:06.043 debugRequesting Tamper Report
dev:1292020-03-14 17:27:06.041 debugRequesting Motion Report
dev:1292020-03-14 17:27:05.892 debugsyncDevice()...
dev:1292020-03-14 17:26:57.741 warnAll the settings will be sent to the device the next time it wakes up.
dev:1292020-03-14 17:26:57.737 infoZooz 4-in-1 Sensor: syncStatus is Resync All
dev:1292020-03-14 17:26:57.610 warnconfigure...
dev:1292020-03-14 17:26:57.452 warninstalled...

34

I see that you clicked the refresh button twice (step #7), but that's where the logging stops and steps 8-11 will provide the logs that I'm looking for.

Assuming you haven't done anything with the device since you stopped at step #7 and it's been less than 30 minutes since you started, you can continue on to step #8.

35

Yes, I modified and installed your ST driver.

I didn't know that debug logging turns off after 30 minutes - good to know. I gave it a try turning on the lights then kept motion mostly active for the next 8 minutes. No multi sensor reports while active. Soon after I left the room allowing it to go inactive the report came through.

36

My ST DTH doesn't, but all the built-in Hubitat drivers do.

That's really odd, what firmware version do you have? If you're using my ST DTH then it's probably in the "Current States" section on the right instead of the data section at the bottom.

37

I continued Kevin's steps with #8 and still no firmwareVersion reported. Attached is the device details and log entries.

Screenshot from 2020-03-14 19-32-43
Screenshot from 2020-03-14 19-32-431017×388 14.4 KB 

dev:1292020-03-14 19:31:02.560 debugVersionReport(zWaveLibraryType:3, zWaveProtocolVersion:4, zWaveProtocolSubVersion:54, applicationVersion:32, applicationSubVersion:2)

dev:1292020-03-14 19:31:00.480 infoHallway Sensor 2: battery is 100%
dev:1292020-03-14 19:31:00.476 debugBatteryReport(batteryLevel:100)
dev:1292020-03-14 19:30:58.456 infoHallway Sensor 2: illuminance is 37lux
dev:1292020-03-14 19:30:58.451 debugSensorMultilevelReport(precision:2, scale:0, sensorType:3, sensorValue:[27, 248], size:2, scaledSensorValue:71.60)
dev:1292020-03-14 19:30:56.444 infoHallway Sensor 2: humidity is 38.33%
dev:1292020-03-14 19:30:56.435 debugSensorMultilevelReport(precision:2, scale:0, sensorType:5, sensorValue:[14, 249], size:2, scaledSensorValue:38.33)
dev:1292020-03-14 19:30:54.441 infoHallway Sensor 2: temperature is 69.97°F
dev:1292020-03-14 19:30:54.431 debugSensorMultilevelReport(precision:2, scale:0, sensorType:1, sensorValue:[8, 61], size:2, scaledSensorValue:21.09)
dev:1292020-03-14 19:30:52.373 infoHallway Sensor 2: tamper is clear
dev:1292020-03-14 19:30:52.370 debugNotificationReport(v1AlarmType:7, v1AlarmLevel:255, reserved:0, notificationStatus:255, notificationType:7, event:0, sequence:false, eventParametersLength:1, eventParameter:[3])
dev:1292020-03-14 19:30:50.356 infoHallway Sensor 2: motion is active
dev:1292020-03-14 19:30:50.352 debugNotificationReport(v1AlarmType:7, v1AlarmLevel:255, reserved:0, notificationStatus:255, notificationType:7, event:8, sequence:false, eventParametersLength:1, eventParameter:[8])
dev:1292020-03-14 19:30:50.139 debugRequesting Firmware Version
dev:1292020-03-14 19:30:50.136 debugRequesting Battery Report
dev:1292020-03-14 19:30:50.133 debugRequesting Illuminance Report
dev:1292020-03-14 19:30:50.129 debugRequesting Humidity Report
dev:1292020-03-14 19:30:50.126 debugRequesting Temperature Report
dev:1292020-03-14 19:30:50.123 debugRequesting Tamper Report
dev:1292020-03-14 19:30:50.120 debugRequesting Motion Report
dev:1292020-03-14 19:30:50.100 debugsyncDevice()...
dev:1292020-03-14 19:30:50.039 debugDevice Woke Up

38

Looking at this again I see that the Firmware Version is now reported.

39

Thank you for providing those logs.

It looks like the device starts syncing the configuration parameters multiple times during inclusion which results in the firmware report getting lost.

That's somewhat common, but the driver should request it automatically the next time it wakes up and it seems to only request it when it's forced so that appears to be a bug in the driver.

The weird thing is that I thought their latest firmware was 20.14.

This product has been around long enough where I doubt they made any breaking changes in 32.2, but let me know if you run into any issues with it...

40

I just noticed that your device is joined secure so you must have the "Secure Join" setting in the Z-Wave Details screen set to "All Devices".

Devices joined secure generate a lot more traffic and tend to be a little less reliable on Hubitat so unless there's a reason you need it joined secure then I recommend changing that setting back to "Locks / Garage Doors" and joining the device again.