"Added temperature and humidity reporting options to Sonoff Zigbee Temperature/Humidity Sensor." is not working

mike.maxwell · November 25, 2021, 5:19pm

Thanks for the spell check.
Per zigbee spec devices should check for pending commands every 7 seconds at most, so Hubitat will not retry after trying to get a response for 7 seconds. If the device isn't checking in at this interval or sooner that would explain why these parameters aren't being set.

Reporting preference changes are sent when save preferences is clicked for zigbee devices.

Depending on the driver, configure can reset reporting to defaults (not respecting preferences), so one should not run configure after saving preferences.

If the periodic settings aren't reporting at requested intervals, then this a bug in the device firmware as it should report at max interval no matter the delta setting.

szymanski.robert89 · November 25, 2021, 5:33pm

any ideas how to work around this? Maybe save preferences and then in this 7 sec window click the button on sensor to force refresh? I just like to send it once and leave it. For me default 0,5 degree change is unacceptable.

coreystup · November 25, 2021, 5:41pm

Is there a log I can see in Hubitat to look at the details of zigbee checkins/packets themselves? Or would I need a zigbee equivilent to a Zniffer to see that data? From my experiments, it appears as though the device is NOT checking in within 7 seconds when reporting is set outside of that window. If I set the device to min 10s, delta 0.01C (so that it sends temperature updates super often), and then switch to the built in driver and "set preference" i can pretty much be assured I'll catch it within a checkin/report window and the preferences will be sent and I see confirmation of that in the logs. But if the reporting window is 5 minutes, a "set preferences" will likely miss the 7 second checkin window and Hubitat discards the pending preferences update.

Excellent, good to know. I couldn't figure out what was doing what - especially if the pending preference updates are being discarded due to missing the 7 second window.

My testing is showing that max doesn't seem to matter. I'll keep testing, but it appears to only care about min and delta. I'll try some other options over the next few days if its worth trying to figure it out.

mike.maxwell · November 25, 2021, 5:47pm

There isn't, to debug this sort of thing you really need to setup a zigbee sniffer, i use a conbee stick and wireshark.

mike.maxwell · November 25, 2021, 5:52pm

You could try the following:
Remove the device battery, insert the device battery and at the same time click save preferences in the driver a few times.
Hopefully the device will stay awake long enough to receive the configuration commands.

These inexpensive Chinese zigbee devices are challenging as they are seldom certified and frequently take liberties regarding zigbee profile compliance...

coreystup · November 25, 2021, 6:00pm

Ordered! I've needed one anyway to help debug other issues. Thanks!

coreystup · November 25, 2021, 6:24pm

Would HE consider adding a Device Details->Data "dateCode" value to the built in driver for the device's date code during the initial join? Might help when comparing logs/behavior (provided Sonoff are updating the value across possible firmware/production changes)

zigbee.readAttribute(0x0000, 0x0006)  // Date Code

My test device is returning Date Code: 20201026 for example.

Another thing that would have helped me debug and figure out how the "set preferences" actions worked....
Add logging to setPreferences() action where it says what the min/max/delta values its requesting the report changes to be. Something like
debug Configuring reporting cluster 0x402 attribute 0x0000 min = 300, max = 300, delta = 2000
That would clue me in that A) pushing setPreferences is the thing that causes the actual action to occur and "configure" is not needed or may clear/reset things and B) the values that are actually getting passed to the device. Then I know what I'm looking for in patterns, etc.

Thanks!

coreystup · November 26, 2021, 5:32am

I figured out the bug/workaround for this issue. If you set the min/max to the same value, it does not send a report at the max, but only at the delta (with min applied). If you set the min to 1 second less than the max, it will do the expected behavior of sending a report at the max interval regardless of delta, but never more than the min value with delta.

So for instance in my test with "Every 5 minutes", where it sets it to (300, 300, 2000), you get no results (likely until you hit a 20C delta anyway)

Set it to (299, 300, 2000) and you get a result back from the device every 300 seconds regardless of delta.

szymanski.robert89 · November 26, 2021, 10:17am

should I use custom driver for this? I do only have options: 0,25, 0,5, 1, 5, C change and 5,10,30, 60 minutes plus "no selection" and "disable"

mike.maxwell · November 26, 2021, 2:40pm

interesting, I'll update the driver, thanks for investigating!

coreystup · November 27, 2021, 10:54pm

I updated to 2.3.0.113 and the issues with min/max being the same value and causing the device never to update have been fixed. For the "Every 5 minute" temp/humidity setting, the parameters are being passed as (300, 301, 20C/20%) and I'm getting results every 5 minutes for both temperature and humidity regardless of delta.

Some notes:

The device does not do any DATA REQUEST checkins on the standard 7 second interval at all. The only way to get it data is either during pairing, or if it happens to be sending result data during that window which is only likely if you have the reporting interval of one of the parameters down to 10 seconds or so.
So this means the easiest way to change the reporting frequency parameters is to re-pair the device. No need to delete the existing device. Put the hub into zigbee pairing mode. Press and hold the device button for 5 seconds and the LED will flash 3 times to indicate its in pairing mode. Once pairing is complete, the device will keep checking for more data and thus will get all the parameters as configured.
The button does nothing other than for the "press and hold for 5 seconds" to re-pair action. Any other button press sequences (I tried all the obvious ones) seemed to have no effect.
Pulling the battery and reinserting WILL cause it to communicate, sending a device announcement, then a copy of all of its reported values, and then doing a data request to get any responses. HOWEVER, you'll need to leave the battery removed for about 30-60 seconds as I believe it has a cap or something that needs to discharge fully. Quicker removal/replacement of a battery results in no communication.
Knowing this, if you wanted to get an updated configuration to the device without going thru re-pairing, you could:

Remove the battery, wait 30-60 seconds for the device to discharge. Have the battery ready to reinsert quickly.
Click "Save preferences".
Within 7 seconds of the UI refreshing after the save, reinstall the battery. The device should go thru its power up sequence and receive the latest reporting parameters.

Another interesting tidbit:
ST's driver was recently updated with another Sonoff SNZB-02 labeled device, although the fingerprint is slightly different. Instead of reporting as a "TH01", it reports as as "SNZB-02P". And an additional "in cluster" is the polling cluster (0x0020) - maybe the "02P" is for polling? So there's a chance that a later model of the SNZB-02 is moving towards ZigBee 3.0 compliance. We shall see if anyone gets their hands on one....

github.com

SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/smartthings/smartsense-temp-humidity-sensor.src/smartsense-temp-humidity-sensor.groovy

/**
 *  SmartSense Temp/Humidity Sensor
 *
 *  Copyright 2014 SmartThings
 *
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License
 *  for the specific language governing permissions and limitations under the License.
 *
 */
import physicalgraph.zigbee.zcl.DataType

metadata {
	definition(name: "SmartSense Temp/Humidity Sensor", namespace: "smartthings", author: "SmartThings", runLocally: true, minHubCoreVersion: '000.017.0012', executeCommandsLocally: false, ocfDeviceType: "oic.d.thermostat") {
		capability "Configuration"

This file has been truncated. show original

Thanks again to @mike.maxwell and @kkossev for working thru the fun of the SNZB-02! And thanks to Conbee for my shiny new Zigbee sniffer!

szymanski.robert89 · November 28, 2021, 7:35am

I can confirm that putting sensor in paring mode is syncing the preferences

vallee-michel · January 18, 2022, 1:08pm

Hi, a bit new to HE. Where could I find this driver (2.3.0.113)?

Thanks.

mike.maxwell · February 28, 2022, 8:06pm

this is a platform version number, any platform version greater than or equal to this version will have the mentioned fix.

anthony · July 18, 2022, 4:47am

Apologies for bumping this. This was a very interesting read. Are you still getting the expected behavior on platform 2.3.2.139? I have two of these sensors (testing before deploying the other 7) that are not respecting the reporting frequency after following the re-pair procedure. I do get logs indicating the reporting frequency settings were updated once I re-pair, but am still only getting reports based on the default deltas (0.5C/1rh).

coreystup · July 18, 2022, 6:26pm

I'm on 2.3.2.135 currently. My sensors are still reporting correctly, but I've not tried or needed to re-pair them for quite a while.

anthony · July 18, 2022, 7:48pm

Thanks. Do you mind sharing the modified driver you used that reports the configuration from the sensor?

rdstov · October 9, 2022, 9:16pm

How can we utilize the built in driver for the SNZB-02 to determine if its still online? I have been using the OOHLA Labs driver, presence detection. I much prefer the built in driver. However, I do note that these tend to randomly go offline, and I have a notifier based on presence. Does the build in driver have a way to determine if the SNZB-02 is still reporting?

HobbesIL · November 17, 2022, 6:25am

I am on the most current version, spent all night till I found this thread. Pulled the battery, let it sit for a few min, hovered over SAVE PREF and has been working like a charm all day. No more issues and I can see constant activity on my dashboard on my tablet. This is a very obscure fix for a cheap knock off bit of kit but I needed 8 sensors and I went cheap. They are all working and reporting now in real time with no issues. Sending the config during wake up time worked like a charm. Thank you for the effort and sharing this with us.

myagizorhan · March 14, 2024, 9:54am

Hi,
I couldn't change the interval values. I could when I did you said, so so thanks.

There is a option to change the interval values for sonoff SNZB-02 etc.
You blow on the sensor. Increase the temp or humidity. The device will start comminication. You can change the interval values at the moment. I tried, this is successful.