We all have to thank @kkossev for that "snippet" of a driver.
It should be more publicized, even though not all zigbee device conform to using it.
2 Likes
The humidity reporting configuration has failed, I will look at the code later this week.
But even if the reporting configuration is confirmed by the device, it doesn't necessarily mean it will actually work. A lot of devices simply acknowledge the command, without actually doing anything.
2 Likes
That seems to be the case, it is still reporting every change of 0.1-0.2F
It makes a nice chart but I would rather have it report less often if the battery will last 2x longer.
1 Like
I agree! I even see it reporting when there is a 1% change in humidity, which means that when the sensor's humidity reporting jitters 1%, I get a report!
I would MUCH rather see it reporting a 5% humidity change, and a 0.5 deg F change.
That would make a little more sense to me.
Strange that so many of you are not seeing the FW version being reported..... wonder what is different? The driver is the same, so something else?
Thank You all for helping out!
Wish I knew what the debug entries meant and how to read it...
Can you test the sensor with this driver? ( ignore the 'Tuya' and the 'clock' in the driver name..). Please use the development branch version from the second link in that thread. This driver have a much more detailed debug logs, so hopefully, we will be able to understand whether the reporting intervals and the thresholds are actually accepted or not.
You can always return later back to the stock driver that you are using at the moment.
Thanks.
What information should I look for, or post here, that would be of interest?
1 Like
Please install the latest dev. branch version - direct URL. Click on Initialize button. Enable the Debug logging and the 'Advanced options' in the Preferences section. Then change the reporting parameters (min, max, delta) and click on the Save button.
Search in the live logs that follow for a Reporting Configuration Response ... text.
ok thanks!
I will do this a little later... kinda tied up at the moment...
My bad, I forgot to mention that currently these devices, that do not have a fingerprint defined are skipped in the reporting configuration code..
You need to manually force 'Zigbee NON-Tuya' model in the preferences :
Ok that generated a TON of logs. I filtered it down to just the config response and here is all the results. Seems like the device is taking it? I will have to see if it actually honors it.
I changed one of the values again and refreshed, this seems to this it is OK as well
I am going to keep it on this driver for a bit just in case the default driver is somehow reconfiguring it incorrectly. I assume this driver will record the temp and humidity readings that the device sends.
1 Like
This is a 2 day view, does not appear to be any change in the reporting frequency. Zoomed in smaller it looks like it reports on every 0.2F change.
@kkossev does this mean the device is basically saying OK I got your configuration but I don't care and will keep doing whatever I want?
Yes.
The temperature reporting configuration was confirmed on 01/15 at 11:31 AM to be :
- 1 degree Celsius minimum temperature change needed to trigger immediate reporting
- 60 seconds minimum between two consecutive reports (the temp. change must be > 1 degree C !)
- 3600 seconds (1 hour) maximum time period without temperature updates. If the temperature was changed less than 1 degree, the sensor should anyway send the temperature reading after 1 hour.
None of the above configurations can be seen on the graph! : (
I think that these devices have only the absolutely minimum functionality implemented. The SoC that is used in this device already has the complex ZCL functions implemented, including the processing of the Zigbee reporting configuration command, storing the parameters internally, and reporting back the stored parameters to the Zigbee coordinator on request. But there is not any piece of custom code written to take the reporting configuration in account.... They simple use the hardcoded sensitivity and reporting intervals.
1 Like
Well it was worth investigating anyway, thanks, and I have learned a little more about Zigbee.
Now to see how long the batteries last with this furious reporting.
2 Likes
Well I have seen that also, so thank you for confirming this.
Sad that these sensors do not honor any changes, but fake out anything sent to them.
Seems kind of "crappy" that they don't allow changes as I do like the display..... oh well it was worth the try!
Thanks!
I agree!
If nothing else, it was worth the effort to learn about Zigbee and these sensors.
Thanks all for your help and information!
1 Like
Not OP, but piggybacking.
Iām looking to put temp monitors in 2 locations with extreme weather (upper Midwest garage and three season porch). I have plugs available if the cold weather will affect batteries too much. Will these ThirdReality work okay? I do have some Thirdreality motion sensors. Prefer zigbee.
As long as your temps are expected to stay in range. Looks like they only go down to 14F according to the specs. The AAA batteries should hold up pretty good. I had a contact sensor on the outside of my freezer that took a CR2032 that would always read 1% due to the cold, replaced it with a Third Reality one and it works great.
