Hi @Pedro_Liberal, okay I had a look at the room size setting. In the app if I set in Auto Mode Settings a size there, it does appear to be polling and reading it. I cant see any code changes that would affect this since the initial addition of the binding. It does seem to show that setting once the next request for an update is done from OpenHab. Moving on to the Air Quality bit, (bear with me please long explanation here). I only use the ppm25 as that’s reflective of the units display, however I do remember seeing the value change when my wife made the house fog like when cooking and the unit went red with a 7000 approx ppm25 one time it did actually go up by 2. I don’t remember the limit’s of what increase that basic range - but the ppm ranges were large from memory and I hadn’t seen it change in normal use until then. (I’m not suggesting to put the unit next to a bonfire to determine how they map ppm to the air quality range ).
Given the basic polling behaviours have not changed in the binding since its initial release, here’s the bits I’ve seen before (slightly long story - sorry). OpenHab interacts in our house with our POE switches using a binding I wrote (but have not published because it screen scrapes the ssh login of the switch and I have not had time to tune its threading up). Its use actually highlight’s two possible causes to me if your not seeing data updates:
First try setting in the openhab console:
log:set TRACE org.openhab.binding.vesync
This will enable trace output (but don’t post with the token on forums - the protocol’s not the best).
What you can see is the data then openhab is reading via the binding from the VeSync cloud servers, which their units talk to. An example response from their cloud servers would be:
01:50:25.241 [DEBUG] [vesync.internal.api.VeSyncV2ApiHelper] - Got OK response {“traceId”:“1685148624848”,“code”:0,“msg”:“request success”,“module”:null,“stacktrace”:null,“result”:{“traceId”:“1685148624848”,“code”:0,“result”:{“enabled”:true,“filter_life”:80,“mode”:“manual”,“level”:2,“air_quality”:1,“air_quality_value”:5,“display”:true,“child_lock”:false,“configuration”:{“display”:true,“display_forever”:true,“auto_preference”:{“type”:“efficient”,“room_size”:452}},“extension”:{“schedule_count”:0,“timer_remain”:0},“device_error_code”:0}}}
The reason I go to this depth is because:
-
I have seen this system when the POE switches binding I mention, starts up it blocks threads for a while until it finds its position in reading and interpretation the data. So when something else is blocking the binding from working I would not see the trace output like above. As something is taking all the resources, in my case during the start-up for a min or so for this binding completely irrelevant to the VeSync one, which can stop it doing anything. So is it trying to get the information would be the first bit to check.(If it doesn’t appear to be requesting data try disabling bindings one by one may indicate which one is behaving less than ideally).
-
If you can see it requesting fresh responses, then the issue will be between vesync’s cloud servers and the devices. (If the app is showing correct data - that’s a whole new bag of worm’s as it means there must be something else going on like proxy caching). However when our POE switch shuts down some of our WiFi units the Air filters never used to reconnect to a different unit with the same SSID that remained on for IOT gear. A quick way to test is whether the app is reflective and openhab is not of the current state, and whether you can still control the devices from the app.If they are not then it maybe a wifi issue, keeping the link to the units.
I suspect however from what you have described the its air quality is the natural ranging applied by vesync, and room sizing could be firmware related possibly to the device? Going forward’s:
I’d suggest:
-
Check the traces from the binding
A) Is it polling at the intervals set - if not what binding when turned off allows it to poll in a timely manner
B) If you look at the channels for the air quality and room size should mirror those responses from VeSync’s servers. If they don’t there is a binding issue, but I suspect they are not giving the data from test’s here.
C) If the device shows different values from the responses from VeSync’s server’s then its likely some WiFi issue, but you would likely notice that on the app.
Hopefully that will narrow it down. P.S your best leaving the poll rates at the defaults set - just in case you have changed them. The device’s still have a lag on pushing their data to VeSync, and air quality shouldn’t change that much at speed
Hopefully the above helps, thanks for the good spot with the timerRemain channel! I’ve got a draft MR for that one - on hold pending further reading on the last bits on this thread tomorrow, and any other bits that may need looking at.
Thanks again