Dashboard / Virtual Thermostat problem continues with updated code
@mike.maxwell , From what you described does that mean the virtual thermostat device will continue to show as blue and cooling when it is turned off, because there is no adjustment to set points required to move to this mode?
The thermostat driver doesnt have any coloring to the attributes...
So the mode will be off, and operating state will be idle.
This is easy to test, install the virtual thermostat and mess around with it using the device details page.
When working these sorts of issues its best to start with the device/driver combo, then work up through the automations and then the dashboards.
On my system (until recently) Virtual Thermostat changes to Blue when operatingState is set by Virtual Thermostat to Cooling, Red when heating. Setting mode to cool or heat does not change color until operating state changes.
How is that being done?
What driver is being used?
It's done by HE System Virtual Thermostat driver. I don't know when it does this since the code is not available to users.
Please post a screen shot of that driver, include the current device states and the type field from the device information section.
The colors may be controlled by the dashboard's CSS, based upon the operatingState value.
Ok i have tested the virtual thermostat driver using the driver ui and it works as expected.
So the issue is in the automations and or dashboard side.
I would start with the apps first and be sure the virtual driver states follow what the app is telling it to do...
1 Like
I believe I understand what is occurring after reviewing these events
- The virtual thermostat's current temperature changes and is lower
- My app's calculated dew point was reached, issuing an off command
- The Virtual thermostat responds the the off command, setting the operating state to Idle
- The Virtual thermostat responds to the real temperature change, and since the current temperature is higher than the thermostat cooling setpoint, it changes the operating state to cooling with the Mode now set to Off
Kindly confirm this is what the code in the virtual thermostat does in steps 3 and 4.
I suspect a simple delay in my Dew Point app when a thermostat temperature induced dew point temperature change requires a cool or off command, will correct this issue.
4 doesnt happen, if the thermostat mode is off it stays off and the operating state stays idle irrespective of temp changes, just like a real thermostat.
I would install a test virtual thermostat and familiarize yourself with how it works using the driver ui, then wire it up to your apps.
Mike: Thank you, I appreciate you digging into and testing the Virtual Thermostat code.
Adding a 200 millisecond delay when a thermostat temperature change causes my Dew Point app to issue a cool or off command, cured the anomaly.
Agreed, but in this case there were two simultaneous threads executing and changing one resource, results may be unpredictable without serialization. The 200 millisecond delay is not serialization, but should allow the Virtual Thermostat to complete its temperature change processing before my code issues the cool or off command, effectively serializing the processing and eliminating the anomaly.
The current temperature change event log for off
If it's of any use, I recently made a change to my thermostat driver for Mitsubishi units to change my calls to check current state (attribute) values after @peterbrown77.pb experienced issues when adjusting mode and set points in quick succession, not sure if it was through RM or the thermostat app. I included the second parameter of true in the device.currentValue call, which I believe forces the value to be read from the database instead of from cache.
For me it was sending RM thermostat commands of "heat 27c auto..." that had problems until @sburke781 updates for his Mitsubishi drivers. I believe these rm thermostat commands work fine now without needing to send through 3 seperate lines.
Edit: I posted not realising this fell outside the original Mitsubishi threads... So hopefully it's in context
1 Like
Thanks @peterbrown77.pb, I at least felt it may have some relevance, but I could be wrong. Thanks for confirming where you were adjusting your thermostat.
Well I replied too soon. I continue getting weird results. Set the thermostat to off() My code does not adjust the thermostat operating state. When it's changed from a dashboard it's always correct.
I remember something dealing something like this on the other platform. There was the value set when the app started, versus the value that was currently in the field.
So on HE I need to use the true parameter to get the latest real actual current value?
I would want to have this confirm by HE staff, but my understanding is that in 99% of cases no, but if you have values being set in rapid succession the cache can lag ever so slightly, whilst not being visible to the human eye.
I'm unable to find HE documentation for getCurrentValue.
Under Device I found command: getDataValue, but not sure if that's that same as getCurrentValue.
At this juncture I'm considering writing a workaround that executes 1/2 to 1 second after issuing the on or cool commands checking and correcting whatever weirdness may occur that's outside my control For example: When mode is off and operating state is cooling; change operating state to idle.
