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
