How to detect HTTP Binding is timing out?

I have a simple HTTP Device (smartDEN Garage Opener) which uses HTTP Binding with GET stateMethod/commandMethod to control my garage door.

Everything works and I have no problem controlling the device.

The only issue which bugs me - it seems like an overlook that HTTP Binding lacks the ability to return device online/offline status, similarly to Network Binding.

Essentially, HTTP Binding is a Network Binding with a servicedevice thing - it should be able to detect a physical device presence by connecting to, let say, http port 80… Except it can’t as there is no online channel like in the Network Binding to detect if device is online or offline.

We have a timeout and refresh parameters but if GET/PUT/POST method times out, then what? HTTP Binding still returns last successfully read state and you can’t say if the device responded or not.

You can physically disconnect your device from the network and your HTTP Binding thing will still show as Online. Which is just wrong.

Now… I know I can use Network Binding to test if the device is online (and I do). And I also can use a rule like this (which I also do):

rule "Garage Device Online Status"
  Time cron "*/3 * * * * ?"
  var sStatus = "Online"
  if (sendHttpGetRequest("", 1000) === null) {
    sStatus = "Offline"

But why put additional overhead to openhab (threads and everything), when we can keep things simple and not create that extra overhead, especially if you run your openhab on a not very powerful Linux NAS. And why would I need my HTTP Binding to connect to my device every 5 seconds to request status and in addition I have to ping it every 3 seconds to see if it’s alive?

So my question is - is there any way to detect if HTTP Binding request times out?

And if not - can a channel online, similar to Network Binding, be added to HTTP Binding (in addition to the only url channel)? I do realise this is more like a feature request, but… how do you submit those?.

Thanks all for your input

1 Like

Create an issue on GitHub, in the add-ons repository.

Make sure your title starts with [http] to categorise is as being for the HTTP Binding.

It requires some refactoring but in general it‘s possible. I just forgot to implement that when submitting the binding

That is the real issue, I would say. A failed transaction should end up with an Item state UNDEF, as in “I don’t know”.
But because of the vagaries of HTTP transactions, some users might want that to be optional.

Talk of ‘online’ state is I think a bit inappropriate here. The best that HTTP can can offer, is “it was alive last time I talked to it” which is not quite the same thing.

An alternative approach is to provide two datetime channels, one for “last read success” and one for “last read failure”. Users can monitor changes to Items optionally linked to these channels and construct any error management scheme they desire.

I‘m not sure about UNDEF. There is no new value. That‘s all we can say. IMO there is a good chance it didn‘t change. Especially speaking about IoT devices that are very often slow and requests may timeout more frequently than for websites.

That’s why I’m suggesting it needs to be optional - choose against your circumstances. Like a channel option, postUndefOnFailure=true

If you’re going to retain old values on timeout, there’s nothing of interest about online/offline indicators either.

I think having online channel is definitelly not inappropriate - take a look at the Network Binding when used with servicedevice thing. It’s exactly the same.

But sure, adding also the lastseen DateTime channel (as in Network Binding) would be even better.

Of course if J-N-K decide to implement those he can call them whatever he wants. But I would stick with the same names for consistency with Network Binding.

github Feature Request rasied

lastSeen isn’t the same… This binding isn’t the same. It’s purpose is data transfer, there will be errors where the remote service is active but a transfer error occurs - e.g. wrong password, say. How should lastSeen be set then?

It is the same in terms of TCP connection to port 80 for example (basic Session Layer 5 in OSI model). The lastseen is when was the last time you successfully connected to port 80. If you can do that, means your physical device is online.

HTTP specific protocol errors or any such application (Layer 7) specific errors have nothing to do with can you connect to the device or not. Wrong password does not mean you can’t talk to the device. It means you give it a wrong password and it responds with “wrong password” :wink:. But it is alive, you connected to it and you are talking to it.

Yes indeed. This is my point that the HTTP binding is not for basic presence detection. Who cares if the device/service exists if you cannot get/put the data you want.

What do you mean who cares?!? Of course you care - you would want to know when you issue commands to your device if it’s online or off-network, right?

Currenlty HTTP Binding does not give you any indication of that - you issue “read temperature” command and you get back 25 degrees. But you don’t know if this is real 25 degrees now, or the device is dead and your are just getting 25 degrees from 3 hours ago, when it was alive.

I certainly would want to know if my garage door is really open or closed, when I issue “open garage door” command to my device.

That’s why I’m suggesting a real indicator of failed transfer is of more use here than a ‘lastseen’ style presence detector which you’ve just told us is useless here.

Hey man, whatever “indicator of failed transfer” J-N-K decide to give us, I’ll be happy with it. Currently there is none. That’s my whole point here…

Hi, any news @J-N-K about this? @dinkop how do you do it nowadays?

I have an http smartplug that I can get status by http, and send on/off also by GET Http (appending on and off to the url), and is giving me problems not knowing when the SmartPlug turns dead disconnected from the poweroutlet.

Thank you very much for your work.


Just use HTTP binding from Smarthome/J library, not from the standard openhab distro:

That’s where J-N-K implemented the online detection.

thanks for this tip.
Using the add-on you forget about the HTTP binding and configure your http stuff through the add-on? or these are 2 software that need to work together?


Uninstall the openHAB Version and install the other version.