I am starting to migrating to OH3, but there are some things that I haven’t managed to understand yet.
One is the http://localhost:8080/classicui/CMD?<itemname>=<command> API.
I know it wasn’t supposed to be an official API, but as a matter of facts it has become very popular among users, especially for legacy or IoT units.
So assuming that classic UI will be removed, what is the new way of accessing items using an HTTP GET request?
As this was never supported officially and ClassicUI has been removed, you need to use REST api calls.
Please check the developer tools menu in MainUI.
You can test the calls and will see how a proper curl command would look like.
I know that (I wrote it in my first post), but according to my search only in this forum, there are plenty of topics covering this API and many users that are using this “non-official” feature.
As you know there are units that do not support POST requests but just simple HTTP GET requests.
What is the solution?
In addition to the fact that the CMD GET request doesn’t exist any more, you also have to deal with authentication now too. So even if it were supported, you’d have to enable and use BasicAuth or create an access token and configure your calling scripts to use that. Maybe that’s what went wrong with your attempts in conf/html?
I’ve not tried to do this sort of thing on OH 3 yet but I did something like this in my OAuth2 using just OH Rules and myopenhab.org. But I’m certain this will be behind the authentication/authorization in OH 3 which needs to be taken into account.
Keep in mind though that you are not accessing the Item with that call. You are commanding the Item. You can still access and see the Item’s state using a GET request.
I doubt you will find many if any of those posts to be less than two years old.
I wrote a helper for a device with a limited action url support.
It accepts GET requests to update items and can deal with the OH3 API token.
It uses PUT to update openhab items (PUT /rest/items/itemname/state) -> like “postUpdate” in rules
But it would be quite easy to also support POST requests (POST /rest/items/itemanme) -> like “sendCommand” in rules
I just replaced classicui with basicui and it seems to work fine for me. I’ve been using basicui instead of classicui even with OH2.5.x and it continues to work for me with OH3. I just hope by pointing this out it does not result in it being removed in the next update. It might be worth a try since it is straight forward to implement and test.
This is an example of a command that I use in my DemoPAD remote whereby I use OH3 as a broker between DemoPAD and a Shelly switch, since DemoPAD does not have a driver for Shelly but OH3 does.
GET /basicui/CMD?vBay1GarageLight=OFF HTTP/1.1\x0D\x0AHost: 192.168.x.yyy\x0D\x0A
Thanks for your answer. You have been very kind.
I will try them out and let you know.
Well, this is exactly the typical answer that doesn’t help the community to solve its problem.
It’s very easy to say “Use OH2” or “It might stop working at anytime” instead of understanding that some users have some needs and try to solve them out. Sorry to be so hard.
Just for your information, I have contributed with donations to this project and also developed some changes in a binding.
As a matter of fact, two users have already replied in just few hours with their solution, so I think that this “unofficial” feature is more used that you think.
This worked for me too.
I am integrating an Auerswald PBX with the CMD servlet. Dialing a special phone number triggers the PBX to call a so called “action URL” on the Rest API of OH. It is just calling a URL, without POST/GET syntax and no authentication.
Worked great in OH2 times, and continues to work on OH3, but I am aware that this is kind of a dirty solution built on a unofficial feature and may break in the future without notice.
I am also wondering if this is a backdoor, imposing a security issue because it bypasses OH3 authentication. There is no Basic Auth or API token coded into the action URL and it sends commands to OH.
The security model for OH 3 is to protect administration functions behind authentication and authorization. Day-to-day use is not protected. Sending commands to Items counts as day-to-day so it is not a violation of OH3’s security model. If you want to protect even the day-to-day stuff, you have to put OH behind a reverse proxy.