That's correct. I'm using an app called Demand Manager that will slowly raise the temps over the peak-hour time period and shut the AC off completely if too much power has been consumed in an hour. It does this by raising the temp to a max threshold so the AC will turn back on again if the temp gets too high.
Let me take a look - you might be able to do this with the current setup - can you post me a screenshot of the expanded HA statestream MQTT topic tree for the device - it will be in statestream/climate/device/.. and look like this..
That looks like the target temperatures might be reversed 
I'll take a quick look now as I'm bored with the other thing I'm working on.
Here you go!
.. and it begins ;-), even different within HA, based on integration I suppose.
You have no target_temp_high , target_temp_low or target_temp_step values - are these the setpoints?
or are min_temp and max_temp the setpoints ? Those look like emergency overrides to me...
what is current_temperature cf temperature ?
I have no 'hvac_action' which I'm guessing is what it's doing 'now'. It is in state (mode) 'cool' but is actually currently 'idle'- that's useful to you but my thermostat doesn't even provide that extra info... it's useful info too.
I need to find some info on what supported_features = 5 are ...
temperature is the setpoint, confusingly enough.
current_temperature is the room temp
hvac_action is going to be one of something like: idle, fan-only, heating, cooling, off
hvac_action is important for the automations to work and it's also super useful when plotting visualizations of how everything's working because you can see the operating state vs temp, power consumption, etc
I think that's the total number of states for hvac_action. I'm looking for a list of those now
I'm going to take this to PM if that's OK - if you have additional info please PM me , but I'll be in contact anyway very shortly with more questions... still not certain of the difference between state and hvac_action.
1 Like
Couple updates / bug corrections to the latest version that I found.
@@ -2207,7 +2207,7 @@ def synchDevices() {
mqtt.publishMsg (sTopic+'/refresh','false',1,true)
mqtt.publishMsg (sTopic+'/refresh/$datatype','boolean',1,true)
mqtt.publishMsg (sTopic+'/refresh/$settable','true',1,true)
-mqtt.publishMsg (sTopic+'/refresh/$name',dev.displayName,1,true)
+mqtt.publishMsg (sTopic+'/refresh/$name',it.displayName,1,true)
mqtt.publishMsg (sTopic+'/refresh/$retained','true',1,true)
^ "dev" should be "it"
@@ -4908,7 +4908,7 @@ def colourDevices(evt, name=null,type=null, state=null, device=null) {
if (atomicState.lastDev== "$name [$state]") atomicState.lastDev=''
else {
dType = device.getTypeName()
-if (dType.startsWith("Virtual")) // only allow commands to MQTT from virtuals
+if (dType != null && dType.startsWith("Virtual")) // only allow commands to MQTT from virtuals
{
^ Ran across a few devices where getTypeName was returning a null (forget what though). Add quick check for nulls
@@ -4936,6 +4936,7 @@ def colourDevices(evt, name=null,type=null, state=null, device=null) {
if (xType=='hue') prop='color'
if (xType=='saturation') prop='color'
if (xType=='hsv') prop='color'
+if (xType=='color') prop='color'
if (xType=='colorMode') prop='color-mode'
^ Missing "color" xType - needs to be added for color change devices (some)
@@ -6957,7 +6958,7 @@ def commandP(name, state, payload, fullPayload, cmd, topic, json) { // 'set' com
else if (hue < 0) hue = 0
}
sat = -1
-if (payload[1] != null) {
+if (payload.size > 1 && payload[1] != null) {
float s = Float.parseFloat(payload[1]) + 0.5
sat = (int)(s)
if (sat > 100) sat = 100
@@ -6972,7 +6973,7 @@ def commandP(name, state, payload, fullPayload, cmd, topic, json) { // 'set' com
}
*/
// (Untested change request)
-if (payload[2] != null) {
+if (payload.size > 2 && payload[2] != null) {
^ Add check for "payload" size before attempting to read array size
1 Like
Thanks Jeff.. which version or repository is this against
pre2 beta3e is the latest..
I am also slightly worried I'm about to mess up something in HA discovery by removing the appended suffixes from some multi attribute devices..
OOOH just realised this is the public thread so please don't post a link here to the dev repository
xAPPO/MQTT - "beat 3d" - commit 99ef9df (latest)
That's great thanks as always for the fixes..
Hey @kevin! I saw in some earlier posts there may be some issues with shades. I tried adding windows shades from HE to MQTT and it prohibits MQTT app from starting. I can see the shades show up in my MQTT broker, but the app fails to start. I'm using 3x Ikea shades.
It ends with this error message:
I can see it in MQTT:
I'm using this IKEA Driver for the Shades:
Any thoughts? As you know I love your app! 
What version of my app are you running ?
What is line # 4469 ?
I will be offering my own 'dumb' drivers soon to replace each l the 'smart' HE virtual drivers including thermostats, garage doors and shades, as they do their own things... but this isn't that solution.
When people do post a bug report can you let me know what version you are running (from the mqtt broker). There's a few different versions out there.
Please note I can only provide support for bugs reported against the current release version (or if you have access) the current pre release version.
For the upcoming 'release' (not beta) version I hope to support Hubitat Package Manager but I do need you to already be using beta3 prior to that.
2 Likes
Sorry about that!
I have no clue what line that error is referencing.
Nice! I'm looking forward to that! I love HPM!
@kevin, in your code it is:
HAtype="cover"subscribe to events from
Which looks to me like extraneous text.
Ooops if that is the code it should just be
HAtype="cover"
.. but that's a strange error message ...
Figured. I checked github and it's there too.
