Dashboard Thermostat Anomaly

Ok, that seems fair. I wouldn't want to explore my comment too far without more input from.Hubitat staff

The fugly anomaly killer routine works. Should other issues show up I'll add them here.

void anomalyKiller()
	{
//	log.debug 'anomalyKiller entered'
	controlStats.each
		{
		if (it.currentThermostatMode == 'off' && it.currentThermostatOperatingState == 'cooling')
			{
//			log.debug "anomaly dry with cooling found for ${it.name}"
			it.setThermostatOperatingState('idle') //if this does not work issue the off()
//			it.off()				
			}
		}
	}	

Moving on!

To the HE staff. Kindly share your expertise by letting us know which of the following commands provide the absolute latest value setting for a device setting when the command is executed from an app. (Using thermostatMode for this example)

  1. dvc.currentValue("thermostatMode")

  2. dvc.currentValue("thermostatMode", true)

  3. dvc.currentThermostatMode()

  4. Not sure this event exists, but just in case it does
    dvc.currentThermostatMode(true)

Tagging @bravenel @mike.maxwell

1 Like

All of those return the same thing. What are you trying to do that makes you think this matters? dev.currentThermostatMode will always be the latest value. You should be aware that many thermostats are slow to report changes, but that has nothing to do with this.

Thank you for responding.

Just attempting to understand the best format to use.

I remember on ST there was the cached value created at the start of the task, and the actual current value that could have been changed by another thread. I had no idea if that carried over to HE.

Whatever caching is happening does not affect these methods. They always return the current value of the attribute.

3 Likes