Hi all,
I am a newbie and i am trying to setup a zwave network controlled by OH2 and Raspberry3.
I started with OH1 and everything worked fine.
So I moved to OH2 to prepare myself to the next version.
But there is something I can’t do in OH2:
I used to control my things with URL sending commends to them via a web browser:
Example: http://ip:8080/CMD?FibaroDimmer=50
But now I am not able to do it in OH2.
Can someone tell me the new http syntax to send command to my things?
Check out the REST API documentation. Go to the OH2 dashboard (ie www.yourOH2server:8080) an click on REST API. Then take a look at the items interfaces…
Hi Chris,
I have used that interface, and it works, but it’s not what I was trying to
say.
Apologies for my English. …
So, in V1.8 there was a way to send a command to an item using a Web
browser URL, writing in the webbrowser address bar* the url http://ip:8080/CMD?.
In V2 this command (CMD) seems to be gone.
I know that in V2 there is the REST interface and the PUT command, but I
have a device that can only send GET url commands and that is programmed to
send those commands to OH1.
And I wanted to use the same in V2.
Ok, understood - you want to use EXACTLY the same command for OH2 as OH1. This isn’t possible - the API has changed for OH2 and you will need to update the device to make it compatible. Or, you would need to write an OH2 binding to support the device.
Hi Chris,
It’s not a question of writing a binding.
It’s a question of controlling the item.
I am using an universal remote to control my house. This remote can send
http GET requests but not POST/PUT requests.
Is there any chance that for backward compatibility the CMD command could
be implemented?
I believe that this command is used by many other users that will have the
same issues that I have when they upgrade to V2.
Normally backwards compatibility is always guaranteed. …
Sure - I understand that. My point was that the REST API for OH2 is not the same as OH1. If I understand correctly, you stated that you have a device that can only use the OH1 interface - given this is different, one option is to write a binding (or another REST interface bundle) to support this device.
No - that is definitely not normal. When any software changes major versions, this means that backward compatibility is NOT guaranteed. Version 1 to version 2 is definitely a major version change and many new APIs are implemented across the system.
… which we try to do for openHAB 2. But you should note that the CMD servlet has NEVER BEEN an official API, but just an internal servlet of the ClassicUI - and the official REST API of openHAB 2 is still compatible with openHAB 1.
Having said this, the Classic UI still has this servlet, only its url has changed to http://localhost:8080/classicui/CMD?<itemname>=<command>. So if you have this UI installed, you can still do similar things as before, but you should note that this is still no official API and never will be - because doing state changes through HTTP REST is completely against and RESTful concepts and a very bad design!
just to belatedly echo this - to maximise compatibility with other devices/programs it would be v helpful if this function could be retained in the classicui.
I too was using the unoffical CMD servlet from openhab1 and I’d like to use openhab2’s REST interface directly if possible.
I run 2 openhab instances because of physical separation. The one instance sends a few commands to the other instance in a openhab rule
I’m was using: sendHttpGetRequest("http://serverip:8080/classicui/CMD?EllisWorking=ON")
but when trying to use the official Openhab2 REST interface with something like:
sendHttpPutRequest(“http://serverip:8080/EllisWorking/state”, “text/plain”,“ON”)
I only get errors that seem to be related to the method’s signature (e.g. The name ‘plain’ cannot be resolved to an item or type.) . Any help would be appreciated.
Nevermind: I just found a solution:
I was able to use the POST command w/ REST api instead. The command: sendHttpPostRequest("http://myserverip:8080/rest/items/EllisWorking", "text/plain", "OFF")
did the job.
The need for an OpenHab2 API for legacy devices exists. In a perfect world, all devices are capable of properly formatting POST requests. The problem is that many legacy devices in use may be able to issue a GET in the form of calling a web hook, but are not capable of properly formatting a POST request. An IFTTT recipe could be a workaround, but is not always dependable or responsive. It also is a security issue for many who prefer to keep the smart home systems isolated.
There is a need to provide an interface for these devices and while that is not the purpose of Classic UI, it provides the means to do so. Would it be horrible to establish an equivalent to the CMD applet capability for legacy device support, or are users supposed to abandon devices simply because it’s not the latest? Kind of political correctness that tends to alienate users.
I agree - there are (new and old) devices (I own one) that can only do a GET without any data except URL parameters, so the REST interface isn’t usable for those devices. Keeping the CMD interface is useful and needed to integrate those devices with my OH install.
The BasicUI has this implemented as well. Both of them also serve the abstract TOGGLE command. I am using this to toggle the Lights from Kodi using a infrared remote (fake MCE).