OH3: CMD API (aka: classicui/CMD=)

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?

I tried the JavaScript script route in /conf/html but it doesn’t seem to be working called from my units.


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.

1 Like

Thanks for your reply, but my units do not support POST requests.
So REST API is not an option.

Many users have raised this question in the past and they have been suggested to use the http://localhost:8080/classicui/CMD?<itemname>=<command> API.

Now that this API has been removed in version 3, another option should be given or many setups will never work.

1 Like

As said, this was never an official optio, but a leftover from jetty server. There will be no other option than using REST.

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?

1 Like

Open a feature request. If this will be denied, there is no solution inside openHAB.

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.

You can of course continue to use OH2

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

1 Like

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

1 Like

Please bear in mind you are using it at your own risk. It might stop working without any announcement, as it is not a feature.

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.

Nothing you must excuse for, I can handle such answers :slight_smile:

Yes, my answer is not solving YOUR issue, but for openHAB, this is not an issue.
It was already mentioned 2015 and later, not to use the CMD servlet :

Thanks for your donations, we really appretiate it. But should this change my opinion? No, don’t think so.

This works! Thanks.

1 Like

Here is another user interested…

Yeah, but even ideomaticly from HTTP perspective it’s wrong for a GET request to change something. GETs are just for reading, POST, PUT and other ones are allowed to change things - but not GET

So I also would advise you to strive for a proper solution than to stick to the old stuff that once used to work (but never was supposed to work).


Hi Stefan,
I agree with you 100%.
But unfortunately there are legacy devices that have only this option (GET) to interact with openHAB.

1 Like

True. I have my Mobotix Camera configured that way to send information and events via http/get. Only the latest models support http/post but not older ones.

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. :astonished:

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.