Please update the driver to the latest dev. branch version (the link in the second post). The changes in this update are:
removed degrees symbol from the logs;
temporary commented out minTempAlarm maxTempAlarm minHumidityAlarm maxHumidityAlarm; removed temperatureScaleParameter,
Max Temp and Humi reporting time for 'TS0601_Haozee' is converted to minutes;
humiditySensitivity and temperatureSensitivity bug fixes;
This device (_TZE200_locansqn) does not have a configurable minimum reporting time for temp and humidity, only the maximum reporting period can be set up. So I would expect the T and H to be updated as soon as the change is greater than the sensitivity threshold values. As there was a bug in this setup, please try to change the configurable parameters again.
There is one big uncertainty, however... As this is a battery-powered device, It is not known at this time whether it accepts the parameters changes at any time, or only when it is 'awake'. If simply changing the settings and clicking on 'Save' does not have any effect, please try pushing shortly the pair button at the same time when you change the settings. Some AA/AAA batteries powered devices accept the incoming Zigbee commands all the time, but we don't know for this one.
One more clarification for the others that may be following this thread:
When a preference parameter is changed outside of the user input (change the value and then click on the Save button), HE web page is not updated immediately. The same applies to the State Variables values. The user must often press F5 in the browser to update the currently shown values.
In this driver, 'preferences' like temperature and humidity sensors, maximum reporting periods, etc.. are updated also when the device itself reports these parameter values - usually when the batteries are removed and reinserted again. You will need to press F5 to refresh the device web page to be sure that the parameters shown on the screen are the actual values at the moment.
If you change a parameter from the device WEB UI, and after refreshing the page later you see that the old values have returned back - this means, that the parameter change was not successful for some reason (most probably the device was not awake at the time of the parameter change). When and whether the device will report back the parameters to HE depends solely on the device firmware and the behavior is different for the different devices. As said, the best chance to detect such a discrepancy is after battery removal and reinsertion a few seconds later.
Using the production version I noticed the temp and humidity values always revert to .6 and 6% respectively, but the max reporting time retains my settings.
Installed the development branch version, then had to redo the temp and humidity values again. Hopefully they will hold this time.
Just wondering when the device sends the settings values and they differ from the user defined values, could resending them at this time help make them stick? Also rather than replace the user settings put out a paragraph that the settings are inactive.
My hub is set for F, and two devices are reporting events in F, one is on C. Any ideas?
Update: one device already reverted to default setting, however this time both reporting times changed from 1800 to 7200
Update2: the device reporting C changed to F, All devices reverted to default settings.
Holding the button for 5 seconds factory resets the device and it requires a re-pairing. However I will give it a try
Ok held the button for less than 5 seconds, clicked save preferences, First time temp setting immediately reverted to 6, second time temp max reporting time, they all held on the third try. Will check later.
I have just uploaded an update of the dev. branch version 1.0.8 2022/08/08 8:59 PM, where you can check also the offsets for the temperature and the humidity readings.
This is an option that I can explore, but I foresee problems in this approach, There is no guarantee that the second transmission will be successful, I must be sure this will not create an endless loop.
A better working approach would be to implement something similar to what I did in the "Zigbee Reporting Configuration" driver a long time ago, although it became rather complex and I never finished it the way I wished to be.
A much simpler to implement configuration option is to make sure that the configured parameters are sent to the device in the moment when it is re-paired again to HE. I will test this later tonight, usually, all Zigbee sleepy devices accept configuration commands that are sent immediately after the pairing!
Installed, the offsets are a great addition will set them later
Perhaps set a state field with a terxt message when there is a settings mismatch, then display it on the device page as a paragraph rather than override the user's settings.
Agreed. Should a loop be possible it must be controlled, limited and ultimately ended. I guess this would depend on how often and when the device sends its current settings.
That would be a very good solution, but the code that overrides the user's settings must be removed.
Updated the settings on two devices that were not done earlier today. Like the first device, a few rounds of updates, clicking the device's button, and changing the overridden settings was required to get various settings to stick on the device page.
The first device I did earlier today was holding it's settings
@arnb last update for today, timestamp 2022/08/08 9:50 PM
Now the preference parameters are sent very quickly when the device is paired to HE.
I tested it with another thermometer and it works for me 100% now.
Set the preferred parameters, press Save, and the changed values are stored.
Pair the device again to HE, the stored parameters are sent to the device and accepted.
I prefer to keep it this way for now. Removing the code that overrides the 'desired' parameters with the actual/real parameter values that are sent by the device will bring another problem - the user thinks that the device will operate as configured in the Preferences section, but it will not, because the parameters were actually not accepted and are not in effect.
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.
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 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.
