Yes it does, but nothing happened when raised the humidity to 99 by breathing into it.
I don't understand how the button info at that link is related to this issue.
Earlier this evening, prior to going out for a few hours, I set the temperature sensitivity to 1.2 degrees C. It did not work as expected, as shown for one device on the image below. I've taken the three sensors offline until this can be resolved. Some of the temperature reports are seconds apart. Humidity also reports more often than wanted or expected.
The link was to another driver that @thebearmay has posted which uses a 'Paragraph' preference input to show some instructions on the device web page:
I can modify this driver to work in a similar way - instead of silently replacing the preferences parameters values that created a lot of confusion (sorry about this!), the current states may display " * needUpdate : YES" or something similar to alert the user that there are discrepancies between the values of the parameters entered and the actual values echoed back from the device.
On the multiple temperature events - I see now I have left an 'isStateChange = true' flag in the temperature and humidity events which is not needed and is wrong, will be removed in the next update. This will prevent the frequent temperature updates to be shown on the 'Events' page, but the fact that these are sent over the air remains... which means that the threshold of 1.2 degrees Celsius is actually not in effect. But let's wait until I have the chance to sniff again what exactly sends Tuya GW when changing the T/H sensitivity for a similar device and whether the sensor behaves the same way with SmartLife app. I won't be surprised if the 'sensitivity' parameters are used simply for filtering out the display results in Tuya mobile app, but the device actually continues to send T/H updates much more frequently than needed.
I think I have enough evidence to support my theory now - the item is still stable after making the changes.
It started going wrong after I removed my Tuya and Zignito repeater power outlets from the Hub #1 system that the temp/hum sensor was on. The reason I did that was as follows:
I had bought an Aqara vibration sensor, knowing in advance it might have trouble staying paired, but wanting to experiment anyway. In fact it stayed paired beautifully for many days. But I noticed after getting it that other things were going wrong. Other end devices were dropping off and needing their batteries removed and put back to reboot them. And the Zignito plug every now and then would not respond to turn on, and needed powering up and down.
Then I looked at the routing and discovered that over 50% of all my end devices were routing through it, from all corners of the house, even bypassing my hub that was between them!
So I took the Zignito plug out of service, and the same with the Tuya one that KKossev had suggested was pretty much the same thing under different branding. It was just after that the Tuya temp/hum started dropping out every day and losing its screen.
Anyway by this time I had my hub #2 and had transferred the Aqara sensor to it along with a couple of Tradfri plugs for repeaters. So I transferred the Tuya temp/hum to hub #2 and it's been fine since! It obviously didn't like my SmartThings plugs which are the only thing the rest of the hub #1 end devices bother with even though I do have a couple of other brand repeaters
I shall declare Tuya and Zignito as Aqara-like in nature.
Yes something like that is preferable to changing the user's defined values.
Hopefully something will change, or these things make a return trip to China or perhaps get sold on Ebay. When I had three of them on the system yesterday morning my zigbee network was going offline.
Will try this next time
Make sure you update the driver before doing the next tests.
Will do, let me know when it's available
Yes, this is the thread on GitHub.
The driver update (dev. branch) is available now.
1 Like
Installed latest driver. It helps a lot, better would be having that on the device's page. Hopefully the user temp sensitivity setting can be adjusted to match the device's reality.
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
