Can anyone help me by writing a Sensibo Binding? I have it working using command lines to issue GET and PUT commands using HTTPS in JSON format, but a Binding would be way easier for those following later. As my copy of OPENHAB can’t use HTTPS, I can’t use the Exec or HTTP binding to do this directly. Sensibo has released API examples in both Python and YAML but my knowledge of scripting is small so I can’t do this myself. I have 3 POD’s so I can test things.
Sensibo allows any Infra Red operated AC to be operated over the net using a self adhesive add on POD.
Personally, I think adding HTTPS support to the HTTP binding would be far preferable to creating yet another binding to interact with what amounts to an HTTP REST API.
It may or may not be a suitable case of using the HTTP binding (if it supported HTTPS). REST APIs may use OAuth2 or some other authorization mechanism that requires token management, there may be specific requirements to follow redirects, rate limit queries, complex semantics needed in order to get states for item bindings, translate responses in ways that don’t map well, etc. Or, like you say, it might be perfectly suitable. (I don’t know this API.)
Anyway, their Indiegogo video was entertaining.
I’d go with that, and it is weird how it doesn’t simply work. Command prompt on the same box called from OH works, but anything inside OH with HTTPS doesn’t, 2 sites so far. I can even talk to OH incoming via HTTPS.
The Sensibo server uses 256Bit Encryption and an APIKey in the command line to get access. Chrome on Windows talks to it with no errors and all the certificates are signed. The IFTTT Maker channel is also broken, but it allows you to drop into standard HTTP
I am of course outside the US so maybe there are cryptography restrictions hidden in there, but I can’t find them.
The big problem is I think the HTTP binding doesn’t support HTTPS. Having “simply added” HTTPS support to code that only implemented HTTP in the past, I can say it is not trivial. And since HTTPS is not implemented in the HTTP binding, the fact that HTTPS works for connecting to openHAB or other tools can talk HTTPS has no bearing on on the HTTP binding.
The problem I’ve seen with the Maker IFTTT channel is that while it will support HTTPS, it will only do so for servers using certificates signed by a trusted certificate authority. OpenHAB, Mosquitto, and a lot of these similar servers have self signed certificates which the Maker Channel will not trust.
Don’t forget that HTTPS serves two purposes. The most obvious is that any communication you have with the server is confidential (i.e. encrypted). The second less well known but equally important purpose is that the server you are talking to is indeed the who you believe it to be and not an imposter. This is done through certificates and the certificate authority is a third party who confirms that the server is who it says it is. Otherwise it is as if the server is saying “trust me”. It is this second part of HTTPS that is tricky to get right.
Perhaps this is a simple question, but how come it works from a linux command line curl on the same box? I’ve not told curl to specifically ignore security
curl implements HTTPS, the HTTP binding does not. The two are completely different code and they have nothing to do with each other. Even though they do a lot of the same things, HTTPS is really almost a completely different protocol. Just because a tool supports one does not automatically make it able to support the other. And the fact that one tool on your computer supports HTTPS has no bearing on whether other tools on your computer will support it.
Thanks for the clarification. I was just assuming that HTTPS was broken on my system with the Handshaking error.
I’ll stick with using the command prompt