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

🧰 Built-In Apps and Drivers
1

Hello there,
I have 2 sonoff temp.hum sensors connected with my habitat.
After seeing that release 2.3 is giving me option to change default config I've tried to change it straight away.

I've tested all options and it seems to not work at all, no matter what I've putt in configuration.

After changing options I've tested:

  • rebooting hub
    -put device in discovery mode and enable pairing
    -push "configure" button on device page (I still do not know what it is responsible for)

Is it a bug? Am I alone with this problem. I will love to have temp report every 10 mins, not the default 0,5 degree change :frowning:

2

I'm seeing similar... I disabled the temp option (not impt to my use) and changed humidity to 2%, but I'm not seeing any reporting behavior changes in the logs - logs still look like they always have (temp & humidity every ~5 mins or so).

Not my first rodeo with dealing with new parameters from an updated driver, so I'm confident I've properly done the Save Pref, Configure button sequence etc - I haven't gone as far as exclude / re-include but I feel like I've tried everything else. :man_shrugging:

3

This feature was added based on community reports that these parameters could be changed, either that information was incorrect, or this functionality is based on firmware versions.

4 Likes
4

I'm wondering now from where can I download newer firmware to make it work. Anyone have a clue?

5

I'm testing the Sonoff SNZB-02's reporting capabilities now. I used @kkossev's parameter driver to set the temperature reporting frequency to as low as minimum = 1 second, delta = 0.01C. The device will accept that change but the minimum report frequency ends up being 10 seconds. So anything less than 10 seconds will just be interpreted as 10.

@kkossev's driver queues up the change to the reporting frequency so the next time the device wakes up and reports any data at all, the reporting frequency changes are sent to the device. I'm not sure how the updated built in driver handles the device being asleep at the time of the configuration change. My testing shows that pressing the button on the device doesn't wake it up.

I modified @kkossev's driver to query the device for its current reporting configuration the next time it checks in and to log that value. I'll do a test where I set the report configuration to something and make sure it sticks, Then I'll switch to the new built in driver and set the report config to something else and wait for a check in for the changes to be sent to the device. Then I'll switch back to my modified @kkossev driver and see if that configuration was actually received.

4 Likes
6

Here's the results from a test:

Step 1:
Using the parameter driver, I set the reporting configuration for temperature: min = 60s, max 120s, delta .5C (60, 120, 50).
I let the device configure, and then queried the reporting configuration and it confirmed the same values.
Read Reporting Configuration clusterId: 0402 status: 00 direction: 00 attr: 0000 datatype: 29 min: 003C max: 0078 delta: 0032
min = 60s, max = 120s, delta = 50 (.5C)

Step 2:
Changed to built in driver. Set temperature to "every 5 minutes". Pressed "save preferences" and then "configure". Logs showed that the device reported the report configuration had been saved.

2021-11-25 10:43:02.359 am inforeporting configuration for Temperature Measurement (cluster 0x0402) suceeded
2021-11-25 10:43:02.355 am debugdescMap: [raw:catchall: 0104 0402 01 01 0040 00 BF61 00 00 0000 07 01 00, profileId:0104, clusterId:0402, clusterInt:1026, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:BF61, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:01, data:[00]]

Changed to parameter driver and queried cluster 0x402's reporting to see what the built in driver had sent:
Read Reporting Configuration clusterId: 0402 status: 00 direction: 00 attr: 0000 datatype: 29 min: 012C max: 012C delta: 07D0

min = 300s, max = 300s, delta = 2000 (20 deg C). So this is in line with the "every 5 minutes" setting from the built in driver (min/max both 5 minutes) although a 20 deg delta seems an odd choice but since min/max are so low it shouldn't matter. But.... I waited for multiples of 5 minutes and never got a temperature update..... So it seems the device is waiting for a 20C change before sending anything? The max update setting appears to not matter, either because min/max are the same or some other bug/design issue?

Step 3:
Then went back to built in driver, and set to "On 0.25C change". Pressed "save preferences" and then "configure". Device got changes.
2021-11-25 10:59:16.738 am inforeporting configuration for Temperature Measurement (cluster 0x0402) suceeded

Changed to parameter driver and queried cluster 0x402's reporting again:
Read Reporting Configuration clusterId: 0402 status: 00 direction: 00 attr: 0000 datatype: 29 min: 012C max: A8C0 delta: 0032
min = 300, max = 43200, delta = .5C?
So when using "on 025C change", the parameters appear to be min = 5 minutes, max = 60 hours (!) and delta as .5C? I'm going to retest this in case I did something wrong as the delta should be 25 not 50.

Step 4:
Then went back to built in driver, and set to "On 1C change". Pressed "save preferences" and then "configure". Device got changes.
2021-11-25 11:26:02.335 am inforeporting configuration for Temperature Measurement (cluster 0x0402) suceeded

Changed to parameter driver and queried cluster 0x402's reporting again:
Read Reporting Configuration clusterId: 0402 status: 00 direction: 00 attr: 0000 datatype: 29 min: 0001 max: FD20 delta: 0064
min = 1s, max = 64800s (!) and delta = 1C.

In this configuration, temperature updates seem to be coming in at most at 2F intervals, which would be about right for a 1C delta.

Some side comments:

  • While testing the settings with the built in driver and doing a "save preferences" (and sometimes )"configure" button wouldn't always report in the logs the "reporting configuration for Temperature Measurement (cluster 0x0402) suceeded". I didn't figure out if "configure" was even needed, or if sometimes it would cancel the pending "save preferences" or if it was just waiting for the device to wake up to check in for parameter changes. Some guidance here would be appreciated. When setting a new reporting interval, is "save preferences" enough to get that change to the device the next time it wakes up?
  • "succeeded" in the built in driver log message is misspelled.
3 Likes
7

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.

4 Likes
8

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.

9

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.

2 Likes
10

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

11

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...

2 Likes
12

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

2 Likes
13

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!

1 Like
14

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.

3 Likes
15

:frowning: 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"

16

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

3 Likes
17

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:
  1. Remove the battery, wait 30-60 seconds for the device to discharge. Have the battery ready to reinsert quickly.
  2. Click "Save preferences".
  3. 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....

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!

3 Likes
18

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

19

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

Thanks.

20

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

2 Likes