Sorry, I am now not sure if I have fully understood your idea... What do you mean by ".. display it on the device page as a paragraph" ?
I understand and agree the user must know the settings are not actually stored on the device, but overriding the user settings forced me to constantly reenter my settings at least 15 or 20 times. Consider 4 code created user preferences, one for each device setting, in Current States. I really dislike my settings getting changed.
1 Like
Ok, I understand what you mean… will think about it.
One way:
1 Like
Frequent temperature reporting. Temperature sensitivity is set at 0.3C or 0.54F. However it's reporting at 0.1F changes.
Update: If I remember correctly a .3C delta temperature change would be x 1E not 0003 shown in the trace.
0x1Е would be 3.0 degrees, if the sensitivity is represented as a tenth of the number ( scale 10 ).
Looking at the code I see this comment that I have written months ago and now I don't remember where I got this information from ( probably while sniffing the traffic from Tuya gateway) :
So it seems like 0.3 C delta is represented as 0.3 * 10 * 2 = 6
In your case, 0.3 C delta may be actually 0.15 C
So, if you configure 0.6 degrees temperature sensitivity in the preferences, this will be actually 0.3 C sensitivity. Does it make sense? Probably it will be better to test with higher values of the delta, as these are too low and are in the range of the measurement error of the sensor.
[quote="kkossev, post:107, topic:88093"]
Does it make sense?
[/quote].
Not to me.
This is what I have in my keypad driver. If I remember you were working on a driver to change temperature reporting around that time.
Oct 30, 2021 v1.0.6 change configure, increase temperature reporting to stop doing a RM refresh every 5 minutes on the keypads.
zigbee.configureReporting(0x0402,0x00,0x29,30,3600,0x0008)
30=minimum reporting before reporting a change in seconds
3600=maximum reporting time in seconds to next report, 1 hour
changed 0064 to 0008 to get more reporting 64=1C or 1.8F, 8=.125C or .18F
The above is for a device that uses the standard ZCL specifications, Tuya makes up its own commands. I am now pretty sure that this formula where the delta is multiplied by 20 comes from a sniffed traffic between Tuya Zigbe GW and some of the Tuya sensors that I have, will repeat the test when I have the time in the next few days.
Does your device have a buzzer of some kind? Does anything change on the LCD screen when the default 'maximum humidity' value of 60% is exceeded?
I'll adjust my setting upward and see what happens while I wait for your test results
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
