You get help quickly if you ask and describe your problem in detail…
what exactly is my problem
what exactly have I already tried
where exactly were the problems. Is it a understanding Problem. Is it a configuration problem. Is my rule crashing. Do I get a syntax error… Something like that.
Or back to your broad question. Is there perhaps an easier way than the one I have chosen.
The more detailed information about the exact situation, the more likely there are to be helpful answers
Unfortunately, all 3 questions listed were not addressed in your post. That’s why it’s difficult to answer them directly with a concrete solution.
A valid question could also be… I’ve been using system XYZ so far and don’t know how best to solve this with OpenHAB.
But as you can see, there is a large, helpful community.
I think it also might help here to understand that OH has very specific definitions for terms like “rules” and the things you describe as rules in your posts on this thread are not what OH would call “rules”.
In an OH context, a “rule” is a unit of automation. When X event happened do Y but only if Z. These are almost always code and these almost always require programming. They are defining automation after all so that’ is to be expected.
But…
These are not usually things that require an openHAB “rule”. These are usually implemented using a binding that supports the technology, a Thing that represents a specific device, sometimes a transformation or two if it’s a low level binding, and Items linked to the Channels of the Thing which exposes those sensor readings and control points to openHAB. OH doesn’t call any of this stuff a “rule” so I think there’s a lot of cross talking going on on this thread.
Specific bindings are almost always going to be way easier to use than low level bindings. For example, the Shelly binding will automatically discover the devices, create Things for you and once you link the Items to the Channels you care about you can command the Items and look at the Item’s state directly. Nothing really specific to configure, no code required. You usually don’t even need transformations.
When you use low level bindings like Exec, HTTP, MQTT, TCP/UDP, KNX, Modbus, etc, you have to understand and do everything yourself. These are orders of magnitude more complicated to get working because you as the end user are required to do everything youself. You need all the details to connect (no auto-discovery), you need to understand the underlying technology, you need to parse and transform the output from the device to something that can be used by an openHAB Item, etc.
One reason you are struggling so much is you have chosen the absolute hardest technologies to work with. Nothing is done for you with these low level bindings. You have to do everything yourself and that adds a huge amount to what you need to know about OH to get them to work.
To answer your specific questions:
When you know how it works, it should only take 2 minutes in OH or any other system too. The struggle is you’ve chosen the technologies that require the most amount of knowledge and the most amount of manual configuration to make work. But once you know how, it’s not hard and it doesn’t take that much.
But there are lots of pointers to the docs here in this thread because for better or worse, you can’t really work with OH, especially the lower level technologies like MQTT, HTTP, and Exec, without them.
The whitelist is a security feature and well documented in the binding add-on. And it’s not complicated. You just need to put the command exactly as it’s written in the command property of the Exec Thing on it’s own line in $OH_CONF/misc/exec.whitelist.
This cannot be done through the UI on purpose.
This stuff is complicated. It’s really hard if you just jump in and expect to figure it out as you go.
It doesn’t. Of course, you are more likely to need some programming skills when using these lower level technbologies becuase the data you get or send to the devices almost always require some sort of transformation to make them work with the appropriate OH Item. Your technologies are basically making you do the most amount of work possible because they are so low level.
But the “rule set” (it’s kind of hard to understand what you are referring to here) is very robust and capable. It’s just that you won’t always apply everything in one place.
Without the Item config and rule It can work but we don’t know what you did to set it up.
Both bindings have a lot in common. Picking one and working through it step by step could lead you to success and success with one should lead to success with the other.
You have three options to replecate this call in OH. But there are three key pieces of information missing.
When is this call made? How often?
What data gets returned?
What UI are you using and how do you want to control this Item from the UI?
I’m assuming the “5” for brightness is going to change from one command to another.
Exec binding
Install the Exec binding from the Add-on Store
Navigate to Settings → Things → + and choose Exec Binding from the list and click “Command”
a. command: curl -s http://192.168.182.135/json-rpc?request={“command”:“adjustment”,“adjustment”:{“classic_config”:false,“brightness”:%2$s}}”
b. transform: ??? we don’t know what this HTTP call returns
c. interval: ??? we don’t know how often this is called or if it’s called on demand. I assume it’s called on demand so leave it as 0 and it will only be called when the Item linked to the Input Channel changes
d. timeout: 15 is reasonable, change if the calls error with timeout errors
e. autorun: toggle to on so the script is called when the input channel changes
Create the file $OH_CONF/misc/exec.whitelist if it doesn’t exist (on a Linux install or openHABian that’s /etc/openhab/misc/exec.whitelist) and add the command exactly as it appears on the thing as a separate line.
Notice it exactly matches, including the command substitution string.
Navigate to the Thing and click on the Channels page. Click on the Input Channel and “Add Link to Item”.
Choose create Item and fill in all the relevant information. Take note, it’s a String Item, not a Dimmer or a Switch, or a Number. The Exec binding only supports String Items by default.
In all likelihood everything here is fine set to the defaults. Except for the Item name you can change any of this later.
At this point anything you send to this new Item will cause the Exec binding to call that curl command using the new state of this Item as the value passed for the “brightness” in the JSON part of the URL. You can put this Item on a sitemap or on a MainUI page. You can tag the Item with semantic tags and it will appear on the Overview tabs on MainUI (where and how it appears depends on the tags). On MainUI if you don’t like how it appears you can change the UI widget by setting the “default list item widget” Item metadata.
HTTP Binding
Notice the similarities:
Install the HTTP binding from the Add-on Store
Navigate to Settings → Things → + and choose HTTP Binding from the list and click “HTTP URL Thing”
a. baseURL: curl -s http://192.168.182.135
Navigate to the Thing and click the Channels page. Click “add Channel”.
a. Choose the type of Item that best represents the way you will interact with this device. Assuming it’s more than two ON/OFF states and to more closely match the Exec binding config I’ll choose String
b. check “show advanced”
c. add the last part of the URL to the “command url extension”: /json-rpc?request={“command”:“adjustment”,“adjustment”:{“classic_config”:false,“brightness”:%2$}}
Again, what ever command is sent to the Item linked to this Channel will be used where the %2$ appears in the command URL extension
I’m assuming no incomming data and no transformations are required.
In all likelihood everything here is fine set to the defaults. Except for the Item name you can change any of this later.
At this point anything you send to this new Item will cause the HTTP binding to call that HTTP URL using the new state of this Item as the value passed for the “brightness” in the JSON part of the URL. You can put this Item on a sitemap or on a MainUI page. You can tag the Item with semantic tags and it will appear on the Overview tabs on MainUI (where and how it appears depends on the tags). On MainUI if you don’t like how it appears you can change the UI widget by setting the “default list item widget” Item metadata.
Discussion
You should notice that the vast majority of the steps above are the same. The properties are a little different given that Exec and HTTP are very different technologies, but in the end you have a single String Item which you send commands to to cause the Thing to make the call. The value posted to the Item is used in the URL that gets called.
There are no rules here. There are no scripts nor any programming involved. We don’t even have a transformation though if this URL returns something that is to be used to update the Item a transformation may be required.
Typically, if you want not just to command a device but to get updates when the device changes state.
And of course there are tons of other ways you can achieve these same results using Blockly, rules external scripts and more. But the “canonical” way to make the curl command in OH would be to use the HTTP binding as shown above.
You can as shown above. But it will be very limiting. For example, if you need to poll a different URL to get updates, you’ll need a sepaate Exec thing. If you use the HTTP Thing you can have both the commanding and the status updates on the same Channel meaning you only need the one Item.
It seems simple because that’s what you know, but in the end it will make things much more complicated.
thank you for this helpful post. I configured the exec thing exactly like you explaned. I put the command in the whitelist but OH tells me, that the command is not in the whitelist. I put different formatted commands in the whitelilst but this doesnt solve the problem.
I think @sihui has why the white list isn’t working. Did you copy these from somewhere?
Text editors that like to make things look nice will often replace the quotes. For example this forum does that: "stuff" vs. “stuff”. Notice how the quotes are different.
The fancy quotes won’t work.
This needs to be fixed in both the Exec Thing and the whitelist. The shell where the command actually runs can’t handle the fancy quotes.
This may have been partially my fauly because I just copied the URL from the forum without paying attention. When you don’t use code fences, the forum will replace the standard quotes with fancy quotes.
maybe you can try to start with a simpler version of your command. Just exec the following command and add the same “short” version to your whitelist
curl -s http://192.168.182.135/json-rpc
I know it will not have the effect you want, but you can check at least if the whitelist is working. If it is not triggering the “whitelist error” add some additional parts from your final url, until you get the whitelist error again. Then you know where or which character exactly was the problem.
I would try the following command version, one after the other
Ok. let me rephrase. I don’t want to test whether the whitelist works in general. I would test up to which character of your command the whitelist works
Please post the actual text from logs and the whitelist and such instead of screen shots. Screen shots are really hard to work with. Use code fences to preserve white space and keep the forum from messing with the text (e.g. fancy quotes).
```
code and logs go here
```
When showing the Thing, click on the code tab and paste the yaml you fing there.
Finally, I’ll note that the Exec binding is really the binding of last resort. It’s super limited, finikey (as is clearly shown in this thread) and hard to get working right because it involves so much extra stuff (we haven’t even had to address permission problems on this thread yet).
One of the reasons I showed the HTTP configuration above was to show that it’s the better tool for the job. Configuration of it is almost the same. And in a lot of ways it’s easier (no whitelist for example).
The added bonus is once you know how the HTTP binding works, you know how the MQTT binding works because they are almost the same.
Because Exec is so limited and challenging to work with, this is why many on this thread are having to debug the config alongside you. We don’t usually use this binding so checking for things like fancy quotes doesn’t occur to us.
The fancy quotes may have messed up the witelist parser somehow. I don’t know that code.
It might be worth an issue if we can show that’s the case, though no shell is going to accept a command with fancy quotes anyway so maybe adding the ability to detect them isn’t needed?
It can work but we don’t know what you did to set it up.
…
