I’m trying to get the HTTP Binding to work using a String as its input instead of a switch item to allow me to have 4 states. The item takes the form of
String Test { http=">[state1:POST:http://URL1] >[state2:POST:http://URL2] >[state3:POST:http://URL3] >[state4:POST:http://URL4]" }
Unfortunately nothing happens with the http binding when the String changes, although I can see the change in my sitemap…
Is this possible with this binding? If not can I do it using a number and a translation rule or do I have to stick to switches?
I think you might be seeing the difference between state updates versus sending commands. In a rule or script, if you do Test.sendCommand("state1"), it should perform an HTTP POST to http://URL1.
The other concept is the state of the item Test, which is the item’s current value. Changing an item’s state will not cause the HTTP binding to execute your HTTP POSTs, but sending the item a command will. So, if in your sitemap you have a Switch mapped to different buttons, pressing a button sends a command to the item. From scripts and rules, you can send commands to String items if want.
That fixed it, thanks very much!
FYI I’m using this to control my Ecobee via IFTTT, hopefully as a means to get round my frequent request timed out problems. I’ve had intermittent communication issues since the latest style iphone app and web interface appeared and I think its down to latency.
I also see “Read timed out” failures against the Ecobee API more often than I think should happen, and like you I think it increased in recent months. The binding waits up to 10 seconds for a request to time out, which seems like already a long time to wait. I would add a configurable timeout to the binding except the next question would be how long to wait, which is kind of like asking how long is a piece of string.
Ecboee’s integration to IFTTT is solid and easy to use, but it lacks tons of features that the API (and binding) expose.
Please let me know if you think there is anything you see as lacking in the Ecobee binding, and thanks for reporting back!
…Forgot to mention: the nightly build version of the binding calms down the logging to openhab.log so each read timeout (or other network failure) does not dump a stracktrace into the log, unless DEBUG logging level is set.
You kindly gave me a copy of the reduced logging binding which is a great help.
Testing so far tonight I find the command gets to IFTTT very quickly, however that’s where the system stops.
Tomorrow I’ll see whether using the Ecobee Openhab binding works any better, although it then relies on a message making if from here to Canada at the same time my stat is connected. Curiously enough the other AC using Sensibo worker perfectly via IFTTT so I suspect the result will point to Ecobees servers being a bit average
I have a very vague suspicion that Ecobee has sold so many ecobee3 units that they may be hitting server scalability limits. I have nothing to base this on other than the sense that their API seems less responsive than it used to be. A victim of their own success maybe? And since every web access goes through their API in some way or another IFTTT would be no better than the openHAB Ecobee binding, and even potentially worse due to contention, unless Ecobee implemented some kind of throttling depending on the client, which I doubt.
That could make sense, I’ll keep an eye open for when the timeouts occur as we’re in a different timezone to the main Ecobee markets it could provide a clue about whats going on. I was concerned about relying on something in the cloud when I bought it…
I only see it miss the occasional polling cycle due to a read timeout, never consecutively. And I think Ecobee is upgrading their infrastructure to address demand. So if you have reliable Internet, you won’t regret a cloud-base tstat. (I’ve been relying on remote access to a Nest since 2012 and I’ve had zero connectivity problems.)
I don’t get any problems with my Sensibo controls, however they are relatively new. Its possible that I suffer from Latency as a ping right now from the stat to Ecobee’s servers is running at between 990 and 1010ms. That’s in the middle of the night when they shouldn’t have any load. Interestingly pinging the same site from my desktop takes 212ms and from the Pi takes 211-213ms
I see from the binding page that the polling is now every 3 minutes. When sending commands does the binding have to wait until its next 3 minute polling cycle or are they instant? IFTTT is taking around 20-30 seconds before commands appear at the Ecobee website
Sending commands to Ecobee is instantaneous from the binding to the API, but it may take an average of polling interval/2 for any changes to appear back in the binding, since it waits for the normal polling cycle to pull changes back over. (I say “may take” because some kinds of changes are item state updates which are reflected in openHAB when they are made, while others would be action/function calls that need a poll to reflect state changes back into the binding.)
My pings from the RPi2 running openHAB and Ecobee binding to api.ecobee.com take usually 121ms right now; there is definitely something odd with a one-second ping latency.
How long does your stat take to ping - I’ve got a SmartSi and the ping is found in settings > wifi > diagnostics
Ah, pinging from the tstat is what you meant. I am presently at a tremendous distance from both my SmartSi and ecobee3 tstats, so unless I can reach that information from the web portal, I can’t tell you that at the moment.
No worries, let me know whenever - who knows what I would have tried by then 
Ok, I’m having the same issue, but I can’t seem to get it to work after trying to decipher this:
My item:
Switch TV_Power "TV" <television> (gLivingRoom) {http=">[CHANGED:POST:http://URL:PORT/path?remote=samsung&code=KEY_POWER]" }
My sitemap entry for this item:
Frame label="TV" {
Switch item=TV_Power label="TV Power" mappings=[ON="ON Label", OFF="Off"]
}
But, when I hit either one of the buttons (ON or OFF), nothing seems to happen. Based on @watou’s comment above, it sounds like I need to use a rule to actually send the command?
I tried Item TV_Power received update in a rule, which then did a sendCommand( TV_Power, ON ) and yea, I had a bad time. The event.log and openhab.log were filled in 2 seconds and I had to restart the service and update the rule so it didn’t do that.
Um, and I mean “Nothing seems to happen” as in, I don’t see anything in the logs on the http listener, nor do I see anything entered in the event.log nor openhab.log when I hit the button in my sitemap.
In the UI, when you press the button labeled “ON Label”, this will send a the ON command to the TV_Power item. But your HTTP binding config string says CHANGED, which refers to the state of the item changing. Instead of CHANGED you want to say * or ON, which means that whenever either any or the ON command is sent to the item, perform the HTTP POST to the URL you specified. Since you are trying to command the television, you want the HTTP binding to respond to commands being sent, not item state changes.
Also make sure the TV accepts HTTP POST methods. It might accept only GET methods, I don’t know.
Son of a… I’ve been banging my head on the desk for several days, but that worked! Thanks!!
I built a web server on a raspberry pi with lirc and used the GPIO pins to fire IR leds. So the POST is to the pi.
1 Like