Ecobee set program hold

Hopefully Ecobee improves the network or server-side issues so API calls come back more quickly. I think they have sold so many units that their services might be under heavy load (just a wild guess).

Ironically its been playing up for the last hour of so. I thought I’d broken it as I’d restored the Pi from an image taken earlier in the day and I did eventually end up reauthorising the App.
However just now it has taken 23 seconds from clicking hold on the ecobee web page to when it stopped showing the update bars, then it was around 1:30 from hold press to it showing in the webpage, then finally at 3:25 the thermostat reflected the update. During the last few updates the binding has timed out every time with it taking 10 seconds from querying message to stack dump.
How long can you make the timeout take? With the performance right now it needs to be measured in minutes!!!

Just had a thought, would it be possible to put a timeout parameter in openhab.cfg alongside the polling time?

Can it be anything that is set that is below the the polling time? I’ll then set it ridiculously high and see at what point it stops working. I was amazed that the setting I did from the web actually went through at all, but it did, and it took me 8 minutes to reauthorize the app! I think when it had the huge slowdown they were either doing something on their servers that was causing a massive disk queue or they were being attacked.
Mine has gone back into timing out every time and the last successful communication was a full retrieve that took 12 seconds which is pretty close to the 15 second timeout. Its timed out on the last 4 cycles.

OK, I’m testing a change to add ecobee:timeout to openhab.cfg. If it seems to improve matters, I will share a JAR to you and you can tell me if it helps.

Thanks very much - that was fast!

Hi Kevin,

Please see my pull request including links to JARs for testing. Please report back here or on the PR itself at github to report if this change is in fact helpful. If it is, I will merge it and update the wiki.

Continuing the discussion from [Solved] Many errors in the log for Ecobee Binding:

Greetings,

I am using the example in your wiki page. Seems to work ok except for the “item=desiredTemp”

When I try to change the setpoint, I get this openhab warning:

[WARN ] [.w.internal.servlet.CmdServlet] - Received unknown command ‘Uninitialized’ for item ‘desiredTemp’

Any suggestion on how to proceed?

Thanks,

RB

I think the problem is because the desiredTemp item was never getting an initial value for the Setpoint UI control. Since this setpoint is being simulated by openHAB, it needs a way to populate its state. I just now added this rule to the wiki page; it’s untested so please let me know if you try it and it does or does not work.

rule PopulateDesiredTemp
when
  Item desiredHeat changed OR
  Item desiredCool changed
then
  if (hvacMode.state.toString == "heat" && desiredHeat.state instanceof DecimalType) {
    desiredTemp.postUpdate(desiredHeat.state)
  } else if (hvacMode.state.toString == "cool" && desiredCool.state instanceof DecimalType) {
    desiredTemp.postUpdate(desiredCool.state)
  }
end

I didn’t know anyone was looking at that wiki page yet!

Regards,
John

John,

I am a copycat, not a programmer. I am finding great value looking at your wiki page and other postings, but I can’t say I always understand them or apply them correctly. I have tried your PopulateDesiredTemp rule. The program is not working the way I want it to, but I don’t know if it is because of the rule.

  1. Once installing the rule, I had to manually change the desiredHeat in order to get the desiredTemp to initialize. Can you say how often the desiredHeat and/or the desiredCool items would be expected to change without manual intervention? I would think maybe they would change only when the currentClimateRef would change them, but in my particular case, desiredHeat and desiredCool remain the same across many currentClimateRef changes.

  2. Once the desiredTemp item was initialized, I could make incremental changes to the desiredTemp setting in OpenHab only (and in OpenHab the desiredHeat or desiredCool items would also update accordingly) but those changes never made it to the Ecobee. After some time the desiredTemp (and desiredHeat/desiredCool setting) would be re-initialized with what I believe would be an update from Ecobee with the original setting. I am not clear if this is the case, but it appears the desiredTemp setting was never pushed to Ecobee. Any idea what might be happening here?

If you replace “changed” with “received update” in the new rule, it will trigger much more often. I’m pressed for time at the moment but I will add more later.

If you change what triggers the new rule to trigger when those items are updated (not just changed), then it ought to fill in a valid value for the desiredTemp item no less often than 15 minutes, but sooner if you made a manual change. The Ecobee API reports that there is a change in runtime or settings, and the binding will pull back all the objects that your items are bound to. In that case, even if the desiredHeat and desiredCool didn’t change, they will still trigger the received update rule(s).

That’s odd. In my installation I can confirm that desiredHeat and desiredCool items are changing when the program changes to a new comfort setting (aka climate).

The TempHold rule should trigger when you change the desiredTemp setpoint in the UI (which sends a command to the item in openHAB), and then sends the command on to the heat or cool item, depending on if your thermostat is current in heat or cool hvacMode. If it’s in auto or off mode, it should write a WARN log message. Does anything interesting appear in your openhab.log file?

You could add logInfo calls to your rules to see when they are triggered, which might help diagnose what is happening with your rules. Please let me know if I can help.

Regards, John

I still don’t have it working. I set your items/sitemap and rules in a clean openhab install and . . .

  1. the Item ‘desiredTemp’ still does not automatically populate. I think there is something not working in the ‘OR’ statement. After I change statement in the “PopulateDesiredTemp” rule to to show only: “When Item desiredHeat received update”, then the desiredTemp does populate in Heat mode. If I change it to “When Item desiredCool received update”, then the desiredTemp does populate in Cool mode.

  2. Thereafter I can change the set point for desiredTemp, but all that happens is the desiredTemp is increased or decreased. After a few minutes desiredTemp is re-populated with the original desiredHeat or desiredCool setting. There is nothing in the log to indicate openhab ever tried to execute a rule to change the desired thermostat setting.

WRT desiredHeat and desiredCool remaining the same across currentClimateRef changes, that is the way I set it up. They will change when I set them to. I was really asking about the PopulateDesiredTemp rule and how triggering on a change might effect a longer population time vs triggering on an update. Triggering on an update works, only after I remove the OR statement.

BTW - there seems to be a typo in the sitemap: hvac_mode should be hvacMode

Thanks,

RB

I’m sorry the example has been causing problems. I should have marked the wiki page as a draft before giving it a thorough workout. I thought that, because it wasn’t in the sidebar table of contents, no one was going to find it until it was ready – I was wrong!

I’ve made changes that seem to have it working now. The setpoints weren’t changing because the rule was quietly failing before it got to the ecobeeSetHold action call. Apparently the rule language does not like the construct

val DecimalType desiredCoolTemp = desiredCool.state instanceof DecimalType ? desiredCool.state as DecimalType : new DecimalType(90)

so I broke it into a simple if/else block.

Also, the rule engine does not like

when
  Item desiredHeat received update OR
  Item desiredCool received update
then...

so I broke it into two rules with no OR in the when section. That seems like a bug in the rule engine.

Please review the changes I just made to the wiki page and let me know if it starts working for you. Thanks!

Greetings,

I have become somewhat adept at searching the internet for thing about which I have interest. I was very happy to find you Ecobee Examples wiki page. I have gotten your example to work - somewhat, but still have issues. I think I have isolated the problem to the “TempHold” rule, but don’t know what will fix it.

When I change desiredTemp with hvacMode in “heat”, the change to desiredHeat is made on the ecobee - but only when “heat” is the first case in the TempHold switch. The log shows:

Executing rule 'TempHold’
desiredHeat received command 67.0
attempt to update non-outbound item skipped [itemName=desiredHeat, newState=67.0]
Executing rule 'Populate desiredTemp from desiredHeat'
Executing rule 'HeatHold'
Setting heat setpoint to 67.0
Attempting to call Ecobee function 'SetHoldFunction[type=setHold,params={coolHoldTemp=770, heatHoldTemp=670}]' using Item 'desiredHeat'

However, when I change desiredTemp with hvacMode in “cool” the change to the desiredCool is not made on the ecobee. The log shows only:

Executing rule 'TempHold’

On the other hand if I make the first case in the TempHold switch to case “cool”, I can use the example to made changes to the desiredCool when hvacMode is “cool” but can no longer make changes to the desiredHeat when hvacMode is “heat”. If you know more about what to do with this, I will be pleased to copy it.

Thanks again,

RB

What you’re describing strongly suggests I got the language syntax wrong. Here is a different version of TempHold, with some punctuation removed to match other switch examples:

rule TempHold
when
  Item desiredTemp received command
then
  switch hvacMode.state.toString {
    case "heat" : desiredHeat.sendCommand(receivedCommand)
    case "cool" : desiredCool.sendCommand(receivedCommand)
    case "auto" ,
    case "off"  : logWarn("TempHold", "in " + hvacMode.state.toString + " mode, single setpoint ignored")
  }
end

Please let me know if this does or doesn’t help.

Greetings,

I now have your example running as expected -thank you very much. I appreciate your ecobee binding and examples. With these, I can proceed to make modifications for my purposes. It is my intent not to be asking you questions about why my own modifications won’t work.

Anyway - thanks again - great product.

RB

Thanks very much—I appreciate the positive feedback! If you build something incredible with the Ecobee support, please let us learn about it.

Regards,
John