OK, I have excluded the temperature and humidity alarms settings for your device only, that's why the warnings... Ignore them for now - the important is to make sure the sensitivity settings for the temperature and the humidity are working.
It appears humidity is working. I'm not sure about temperature.
Based upon the temp and humidity logs, the device seems quieter
1 Like
The device is very sensitive to temperature and relative humidity changes. Holding it, thus raising the temperature and effectively changing the relative humidity, triggers an event flurry. It's hands off for now while I monitor the device.
I've noticed temperature and humidity reports are always sent together, if one changes they are both sent, making it difficult to understand if the settings are actually being honored.
I've kept my hands off the device for a while and it's stabilized. Based on the event reports I feel humidity works, however temperature reporting seems way off based upon my 1C sensitivity setting. The log warnings stopped, so I have no idea what the device is actually using for temperature sensitivity.
Having a command to get the current device settings could be helpful figuring out what is going on.
The day before we pushed this device below the minimum sensitivity limits, I think this is the reason why it was sending temperature updates so frequently. In Tuya SmartLife app the minimum sensitivity/delta setting for the temperature in my other model sensor is limited to 0.5 deg C. I don't know what is the T sensitivity limit for your device, but I will limit it to 0.25 deg C to prevent the possibility to make it go berserk again.
Your device is of a type ''deep sleeping' Zigbee battery-powered device. It does not listen and respond to any commands while it sleeps, except it gets awake itself by sensing temperature or humidity changes. Even then, there is no known command to query Tuya devices parameters (for these Tuya devices that use the proprietary cluster EF00).
However, this device sends all parameters when the battery is removed and inserted again. You can look at the debug logs at that time, these logs that say "... reported by device..." are the real settings.
For me, the latest logs seem OK. It is common for other Tuya sensors to send both the temperature and the humidity readings at the same time when one of the two measurements has changed. Obviously, there is no 'minimum time between reports' protection in the device firmware, so I hope that limiting the sensitivity parameter to 0.25 C will prevent any enormous frequent events to be sent flooding the Zigbee network.
Some of the warnings logs that you posted seem strange, obviously, the code that compares two different types of parameters (number vs decimal) as integer values fail. I should be able to test and fix this with my sensor, so please wait for the next update.
After several days of communication with an AliExpress seller, just got this picture:
It is still difficult for me to understand the correct procedure, but I will test it firs with my Tuya GW and SmartLife app. This is what the seller is saying:
"hi， we can change it from F to C in the LCD display or APP"
"hi, you need to press the button to active the change if you want to change it from C to F
or waiting the temperature humidity update after 1-2 hours."
"hi, you can pair it again if the LCD won't change or push the pair button for 1 time."
1 Like
The device is very chatty sometimes reporting multiple fluctuating humidity reports within seconds of each other. This would destabilize my dew point controlled home cooling system.
A software provided device minimum time for both humidity and temperature would be helpful for me, and perhaps others. Any thoughts of doing this? It would be simple: if the report is within n seconds (default 30) of the prior report, ignore it. It's not perfect, but better than what's occurring.
Regarding the "instructions" for changing the display to F: It would be great if you figure it out, I can't. Thank you for taking the time to contact the vendor.
That's exactly what I was thinking about too 
1 Like
My current thought would be to use a queue, one each for temp and humidity
(perhaps serialize processing at this point)
-
If current time - last report time (seconds) => min_report time: delete runin queue; post report (in that order)
-
Otherwise queue it (runIn overwrite - defaults to true which cancels the previous scheduled) with the time set to min_report - (curr report time - last report time)
(unserialize here)
- when queue executes it posts the saved value, temp or humidity
This way the latest report is gently posted.
1 Like
Great idea, I am implementing it now.
The only thing I don't know how to do is to send the delayed event with the original timestamp (the time when the event actually happened). Even if this was possible, it may be confusing to see a timestamp from the past on the top of the events list. Yesterday I added 'physical/digital' flag for the events, so these delayed events will have a 'digital' event type to distinguish them from these events which are sent in real-time.
1 Like
I was just playing with some code for this. I had to figure out how to serialize the code in Groovy, but then I notced you already did that.
I don't think it's possible to post the real event time on a delayed event, and from my perspective it does not matter. You could always put this data into descriptionText of sendEvent.
sendEvent(name:"Humidity", value: "48", descriptionText: "original time stamp here")
1 Like
Just updated the driver, timestamp "2022/08/10 9:24 PM"
Tested with my sensor, seems to be working OK for now.
Probably the same approach can be used for the 'Maximum time between reports' configuration for all other temp/humi sensors that do not support this configuration in the firmware. It will be useful mostly when collecting graphs data.
1 Like
How would this work with Maximum time between reports? Did you mean Minimum?
No, I mean the maximum time period without temperature or humidity change, after which the sensor is supposed to send an T or H event. Similar to the battery reporting - send battery level event every 12 hours, even if no change.
These 'minimum reporting time' and 'maximum reporting time' terms and their meaning are rather confusing, I will try now to find the official Zigbee Cluster Library definitions.
Just noticed the device has singleThreaded: true, plus it's using synchronized on some code. Are both necessary?
I understand the reporting time definitions. Just surprised some Tuya devices don't support Maximum reporting time, besides not supporting Minimum reporting time 
To be honest, I am not quite sure whether singleThreaded: true is necessary.
There should be no other explicit 'synchronized' modifiers inside the code.. The only reference is to the Tuya-specific time synchronization - this is a custom magic Tuya command, that makes the date and time displayed on the LCD possible.
You are correct just once in your code. I was using it on the code I was playing with for queuing Humidity.
Also while comparing versions I came upon this error decomal should be decimal
9: [input: [name: "minReportingTimeTemp", type: "decomal", title: "Minimum time between temperature reports", description: "Minimum time between temperature reporting, seconds", defaultValue: 10, range: "1..3600",
1 Like
1 Like
In routine sendDelayedEventHumi: should it issue
state.lastHumi = now()
Same thought on the Temperature processing
1 Like
