I have two sensors where they need a reasonably fast refresh rate to make them work properly. They are a Frient motion sensor pro and a Sonoff temperature and humidity sensor. In both cases it is the measurement that I need to refresh quickly that is refreshing very slowly, while the others refresh quickly. For example, I have set up the motion sensor so that it automatically switches on some lights if the illumination is below 8 lux. However, it only refreshes, if I am lucky, about once an hour. The humidity sensor is used to switch a bathroom fan on and off. Again, the humidity sometimes only refreshes after two or three hours, often meaning that the fan runs when it doesn’t need to.
I have looked for alternative drivers and tested them, but I am getting the same results. There is no setting for these refresh rates and I can see no way to refresh manually. I am using them with an Aeotec Smartthings hub. Sensors that only refresh after an hour or more seem to be almost pointless. Is there anything I can do about this?
For your Sonoff temperature and humidity device have you tried the “ZigBee Temperature and Child Thermostat Mc” driver.
It lets me set the Humidity reporting interval (with a 5 min. minimum) and the humidity reportable change (with a 1% minimum) for my Tuya devices. But it might be different for Sonoff devices.
There is also a “ZigBee Motion Sensor Mc” driver that may or may not help.
When testing a device with different drivers, there are several details to consider:
The device periodic report interval settings are configured during the device installation.
If you change from one driver to another, the configuration will not be executed again in the new driver and will continue to work the same as with the previous driver.
If the new driver has preferences to adjust periodic reports as my ZigBee Temperature and Child Thermostat Mc, not all devices accept the configuration changes, for several reasons:
If they are battery-powered devices, they are usually asleep and do not receive the configuration messages sent by the driver. There are exceptions such as Aeotec (samjin) sensors, which, although they sleep, listen to the radio and always accept configuration changes, but this causes them to consume more battery than sonoff sensors, for example. My sonoff used as a thermostat and sending reports every 5 minutes or changes of 0.1Âşc or 1% humidity has been on the same battery for 2 years and is at 75%
If the devices are sleeping, they must be woken up before sending the new configuration from the device preferences.
In some cases it is necessary to change the preference in settings and then put the device in pairing mode and in the app add a new device with the search nearby option. This causes the device to reinstall, the driver sends the configuration with the new values ​​that are in preferences and the device accepts them. Sonoff sensor case. Routines, scenes or settings are not lost
For Frient illuminance sensor, with my ZigBee Motion Sensor Mc driver, is configured to send changes of 1 lux or every 30 minutes if there are no changes of 1 lux before.
To configure it you have to pair it directly with the driver, it is not worth changing the driver
I have done some more research and, in combination with these answers, it sounds like I need to try re-pairing and maybe use a different driver. I wasn’t aware of Mariano’s Temperature and Child thermostat driver, so I will download that. I have the motion sensor driver and simply swapping to that has had an immediate effect on the refresh rate for illuminance. I will report back when there has been time for this to settle down.
I have quite a few of those Sonoff temperature/humidity sensors, with and without display, from their current “P” suffix series. They did make me nervous at first because they seemed slow in sending updates, but after observing them for a while I found they’re actually completely OK.
Here’s why:
Using the generic driver in Smartthings, their update rate is actually dynamic. They send updates very frequently when temperature or humidity changes rapidly, and slow down to once an hour or even less when nothing much happens.
I use these sensors to control heating, and things work very well. I also haven’t had a single disconnect in over a year, and reconnects after total power loss in the house have also been flawless.
(I had also tried Aqara’s P series sensors, and these actually are slow, steadily reporting once an hour no matter what happens.)
My sensor seems to go up dynamically, but sticks and doesn’t go back down. Clearly, when someone has a shower, the humiditiy increases rapidly, but in a very small shower room with a fairly powerful fan, the humidity will go down in less than 3 hours, which in several cases recently it hasn’t. And it used to work really well.
That’s odd. Like I said, mine have been running on SmartThings and the generic driver straight out of the box. Both models immediately send data when the humidity changes by at least 1%, my data log shows they do this within a minute when conditions change rapidly. In steady conditions they go hours without sending new data.
I have SNZB-02P and SNZB-02D. I have never had the original SNZB-02.
The stock driver report configuration may seem dynamic, but it is the standard zigbee configuration, which depends on 3 parameters sent to the device in the attribute configure_reporting command:
Minimum interval: minimum time interval between reports. A new report is never sent until this interval is met
Maximum interval: A new report is sent when this time is met. The App will not show a new event in the device history if there is no change in value with respect to the previous report. It can be seen in the CLI logs or in the app graphs, such as temperature and humidity, even if it is equal to the previous one.
Reportable change: This value makes the device send a new report when there is a change with respect to the previous value that is equal to or greater than the configuration value. It is sent even if the maximum interval has not been met.
The default settings for Lua libraries for humidity are minimum: 30 sec, maximum: 3600 sec and reportable change: 1%
These fixed settings in different capabilities, which may be good for most users, may not be for others.
That is why there are drivers that can modify them, although there are also devices that do not support configurations other than those that are set by default in their firmware.
I am currently using the Zigbee motion sensor Mc. Looking at the most recent history, at 21.50 it reported 5 illuminance changes and at 21.51 it reported 7. After that it reported a couple at 21.52. However, after it had been dark in the room for 5 minutes, it didn’t report any illuminance changes and therefore didn’t switch on the lights automatically when my wife went into the room, even though the light level in there was certainly, based on past experience, below the threshold set.
The driver was installed after resetting and re-pairing the device and was the one automatically installed at that time. There were four motion detected events after the time of the last illuminance report without the lights coming on. There are no settings for illuminance in the driver. Do I just need to keep re-pairing until it works properly?
I believe the SNZB-02 identifies itself as a TH01.
The TH01 and SNZB-02P are explicitly handled by the stock driver and the reportable change for humidity is 3% with the min / max being 10 seconds / 2 hours. I’m not clear why 10 seconds is used given the guidelines appear to suggest that drivers should only be generating one event per minute unless the device is being manually operated at a faster rate.
I believe the SNZB-02D currently pairs with a generic fingerprint and isn’t explicitly handled so presumably uses the defaults.
As a follow-up to the recent history reporting, there was finally an illuminance report at 22.11 showing a reduction to 4 lux, which it would have been at for the entire time since soon after the report 20 minutes previously of 11 lux. As a result, movements since then have triggered the routine to turn on the lights.
These and other configuration changes were introduced a while ago to try to reduce battery consumption, I think.
But as with all the modifications made in the doConfigure lifecycles, they only apply to devices when the device is paired with the new version of the driver.
If @Peter-M had his device installed before the release of that version of the driver with configuration changes, his devices will continue to work with the previous configuration until he reinstalls it.
If you want to keep that configuration that sends reports of all changes >= 1% in humidity and >= 0.1Âşc in temperature, do not reinstall it.
If you do, it will report changes >= 3% and >= 0.5Âşc or any minor change when the 2 hour interval is up.
Hence, with the same driver there are users who see one behavior and others see a different one.
If the device is OK and paired near the hub, the configuration is usually successful. The only way to check this is to view the configuration process in the CLI pairing logs of the device, where you can see the configuration that is sent and the response of the device to that command. If the response is successful, then it should work with those configuration values.
It may also have something to do with the way the routine is made. If you uses a lux range or if it is as a precondition or as a trigger condition.
Smartthings have also introduced event filters in the App, which mainly affect temperature. I don’t know if it affects illuminance as well. They are filters that only affect the events that are shown in the device history and do not affect the triggers of the routines. This can make it difficult to debug the operation when looking at the app’s event history.
Also the handling of the app cache is causing it to sometimes take a long time to update the value that is seen in the App, you can even see different values ​​in the mosaic and in the details view, at least that is what I see in this latest version of the Android app.
Try pairing device with this driver version.
I changed the illuminance minimum interval report from 60 sec to 1 sec, same as the Firmware lua defaults for illuminance
───────────────────────────────────────────────────
Name Zigbee Motion Sensor Mc
Version 2024-09-18T08:46:27.268433486
───────────────────────────────────────────────────
Mine indeed do report at 1% humidity change and 0.1°C temperature change. Battery consumption on the SNZB-02P is absolutely minimal, still reporting 100% after almost a year. I wouldn’t see a need for further power saving, I’ll prefer the original settings.
The -02D, running the display, obviously has a little more battery consumption, but these have been running even longer and the battery reports almost full still - on the display, not reported in the app.
The -02D runs on humidity-temperature profile where the -02P runs on humidity-temp-battery.
