Yes, exec binding may be used.
However, using sendHttpPostRequest in rules may be a better option. It supports POST message body with specified content-type.
Thanks,
now I have integrated ZMote to my openhab. So now I can power on / off my tv from my sitemap and rules.
Of course own binding would be even better. 
–Ari
I hope it was smooth.
A binding will come soon… stay tuned 
Wow this looks like a nice process. I’ll need to order one Ari, can you post your working configuration?
Hello,
my solution is bit ugly. But here it is anyway.
I have 2 items:
/* Switch for network binding to check that TV's IP response to a ping. Ping is done every second */
Switch NetworkTV "TV"(Devices,Persistance,MyOpenHAB) { channel="network:device:192_168_1_212:online"}
/* Virtual switch that is used from sitemap */
Switch ZMoteTV "TV"
In rules file I have these. I want keep NetworkTV and ZMoteTV in same states. Probably there is more elegant solution available…
rule "Turn TV On"
when
Item ZMoteTV changed to ON
then
if(NetworkTV.state == OFF)
executeCommandLine("/opt/zmote/power.sh")
end
rule "Turn TV Off"
when
Item ZMoteTV changed to OFF
then
if(NetworkTV.state == ON)
executeCommandLine("/opt/zmote/power.sh")
end
rule "TV On"
when
Item NetworkTV changed to ON
then
if(ZMoteTV.state == OFF)
sendCommand(ZMoteTV,ON)
end
rule "TV Off"
when
Item NetworkTV changed to OFF
then
if(ZMoteTV.state == ON)
sendCommand(ZMoteTV,OFF)
end
I allready had this power.sh so I used that instead of php sendHttpPostRequest
curl -X POST -H ‘Content-Type: application/json’ -d ‘{“period”: 862316,“n”: 68,“seq”: [ 171, 172, 21, 65, 21, 65, 21, 65, 21, 22, 21, 22, 21, 22, 21, 22, 21, 22, 21, 65, 21, 65, 21, 65, 21, 22, 21, 22, 21, 22, 21, 22, 21, 22, 21, 22, 21, 65, 21, 22, 21, 22, 21, 22, 21, 22, 21, 22, 21, 22, 21, 65, 21, 22, 21, 65, 21, 65, 21, 65, 21, 65, 21, 65, 21, 65, 21, 1672],“repeat”: [ 0, 0, 68] }’ http://192.168.1.223/xx-xx-xx-84-8f-f4/api/ir/write
And finally the sitemap:
Switch item=ZMoteTV label="TV"
Text item=NetworkTV label="TV" icon="network"
1 Like
Hello guys,
OH2 binding for zmote is under progress. We are also making some changes to zmote firmware to make it simpler to use.
In the mean time, here is a simple example that you can use as reference, if you want to start exploring today:
zmote-demo.items:
String TV_POWER { autoupdate="false" }
zmote-demo.sitemap Snippet:
Switch item=TV_POWER label="TV" mappings=[POWER="POWER"]
zmote-demo.rules:
rule "TV Power"
when
Item TV_POWER received command
then
sendHttpPostRequest("http://192.168.1.4/5c-cf-7f-84-8d-ed/api/ir/write", "application/json", '{"frequency":37900,"n":36,"repeat":[1,2,36],"seq":[320,159,20,60,20,60,20,20,20,20,20,20,20,20,20,20,20,20,20,60,20,60,20,60,20,20,20,60,20,20,20,20,20,20,20,899]}')
end
Note that I used single-quote ' around JSON string to avoid escaping double-quotes " inside the JSON string.
We will have support for non-JSON commands in the new firmware, which we are planning to roll out next month.
Stay tuned.
3 Likes
Hello,
I’ve bought one and configured with no problems. Great product and easy to understand manual. Great job!
One note to your example:
Don’t we need to use something like this???
Anyways - when I was trying to add rules to OH 1.x, I’ve encountered small problem which I’d like to share…
Part of my JSON file with problematic button / command:
{
"key": "KEY_POWER",
"name": "POWER",
"icon": "settings_power",
"_id": "5602db2f8b871efc4c088181",
"tcode": {
"seq": [],
"repeat": []
},
"code": {
"period": 885622,
"n": 100,
"seq": [
128,
64,
...
16,
2765
],
"repeat": [
1,
0,
100
]
},
"spec": {
"protocol": "Panasonic",
"device": 160,
"subdevice": 0,
"obc": 61,
"misc": "no repeat"
},
"confidence": 32
},
My rule:
sendHttpPostRequest("http://192.168.0.204/MAC-goes-here/api/ir/write", "application/json", '{"period":885622,"n":100,"repeat":[1,0,100],"seq":[128, (...),2765]}')
It was giving me 404 error in the log when switching.
Solution was to change repeat part from [1,0,100] to [0,0,100].
What is more interesting - when using zmote.io app, browser console shows:
repeat: Array[3]
0: 1
1: 0
2: 100
Keep up good work and thank you again!
Hello @Wqty,
Either frequency or period will work, as far as the value is correct. For period = 885622, frequency should be 37000. We started with using period, but soon moved to using frequency, mostly for readability. zmote supports both of them .
The 404 issue you have seen is not expected. I checked the the same code on my zmote with curl command and I got valid response for repeat = 0 as well as 1. If possible, please try with curl command once:
curl http://IP/MAC/api/ir/write -X POST -H "content-type: application/json" -d '{"period":88
5622,"n":100,"repeat":[1,0,100],"seq":[128,64,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,1
6,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,
16,48,16,16,16,48,16,48,16,48,16,48,16,16,16,16,16,48,16,16,16,48,16,48,16,48,16,16,16,16,16,48,16,2765]}'
I have seen sendHttpPostRequest has a small timeout. But I wonder if it will give 404 error.
Generally, it is a good idea to repeat IR signal a few times. When we press button on a physical remote control, we usually end up repeating 2-4 times. I have also seen some devices (my own TV) which recognise IR command only if it is repeated at least once. That’s the reason our web app adds a repeat of at least once even if the code from DB doesn’t say so.
Lastly, thank you for encouraging words!
Hello,
I have just started in home automation, and am currently shopping around for an IR blaster. I was looking at the Zmote greatly encouraged to see you are starting a binding for it! I Just wanted to see how it was coming along? Support for openHAB has become one of the major considerations when buying new smart home devices, so thank you for contributing so eagerly!
Keep up the good work!
Hi there! Any updates on a zmote binding? I bought 4 of them for my home automation tinkering; have managed to get some manual commands working using curl and HTTP but it isn’t super reliable. Love the zmotes though - great product, great price, works with my IR devices for which I have long since lost the original remotes! Thanks for all your hard work.
cheers!
David G
I just ordered one of these and was thinking about writing an OpenHAB2 binding. I’m an experienced Java developer but I know not much about OpenHAB, I just started using it.
How should that binding look like configuration wise, so it fits into the new OpenHAB2 concepts?
To configure your remotes, I was thinking about one or multiple configuration files in JSON format where you can just copy and paste the buttons you have downloaded. Maybe there is even a way to download all buttons from the ZMOTE web page in one go so we could just use that file as input.
But how should the configuration look like within OpenHAB? Maybe like this?
Thing:
// read buttons from file ‘remote-tv.json’ and send them to the given ZMOTE server URL
Thing zmote:remote:tv “TV Remote” [ url="http://server:port/mac/’, remote=“remote-tv” ]
Item:
// sends the IR code for a button named “Power” from the “remote-tv.json” file
Switch zmote-remote-tv-power “TV Power” { channel=“zmote:remote:tv:button” button=“Power” }
Would that be a reasonable way to configure the remote in OpenHAB2 or should it be done differently?
1 Like
Hey Alex,
first of all, that would be amazing! I am also one of probably many users waiting for a binding before ordering. So I’d really appreciate your effort.
Regarding your approach: The thing should take the IP rather than the URL. Relying on an external file is a bit uncommon and I’d see that as a bit unflexible. Why not add the key code to the Item directly? Another aspect you would need to take care of is receiving IR codes (needed before we even can define sending items…).
However this is the end of my knowledge regarding the zmote capabilities and interfaces. @urmilparikh will hopefully be able to answer all your questions.
Thanks again for considering the binding!
Thanks for your input!
I decided to go for the URL in case someone wants to hide the transmitter behind a reverse proxy. Also the URL is provided by the device itself, so in case they change the base URL with a firmware update, the plugin would continue to work.
Well, the file can be downloaded somewhere from the ZMote web app. The idea was to make it as easy as possible for the user. The user can configure his buttons with the web app and then just use the downloaded file as input for the binding. But I guess I could add a configuration parameter for direct IR codes as well.
That will not be included in the initial version of the plugin, as it is handled by the ZMote web app (see above). However if it turns out that there really is a need for it, I can implement it.
For now I just try to get an initial version ready so I can actually test it when my device arrives.
Thank you!
On a side not, I just saw the other thread now.
URL vs. IP: That are some good arguments. How about supporting both. This way the user can use whichever information he/she has 
Ah I see. Now I get the idea.
I’ve looked at the sources of zmote a bit and it seems, these are from the lirc database - probably also why they are equal to the ones @mhilbush is using. I wonder if it would be a good idea to include all of these with the binding to begin with. I’d encourage you to follow his advice and check out, how his binding is doing this kind of thing
That’s totally reasonable! On the long run, I’d however try to not be dependent on other components. Especially as receiving codes is probably not more than one Switch to activate receive mode and one String to write the received code to. Easy-peasy 
Yes this one should be there because bound items are what you will interact with in your openHAB sitemap and rules. If I want to know, that the device is available, I’D need an item for that. “Online”, “Reachable” or “Unreachable” are common channels I’ve seen for that.
As above, I would say: Why compromise? The users will benefit from different options. One Switch item to send the file-known power on / power off commands, a String item with a fixed IR code to send (maybe not known by lirc) and yet another String item the user can write a IR code to in a rule via sendCommand().
Switch ZMote_TV_Power "TV Power" { channel="zmote:remote:tv:sendkey#POWER" }
String ZMote_TV_Special "TV Special Key" { channel="zmote:remote:tv:sendir#1:1,0,<frequency>,1,1,<m1>,<s1>,<m2>,<s2>,...,<mN>,<sN>" }
String ZMote_TV_SendIR "TV Send IR" { channel="zmote:remote:tv:sendir" }
in a rule:
... ZMote_TV_SendIR.sendCommand("1:1,0,<frequency>,1,1,<m1>,<s1>,<m2>,<s2>,...,<mN>,<sN>")
I am not sure about the constraints in regards to the channel part! Please check the Channel definition at Archived Projects | The Eclipse Foundation
The first part needs to be taken care of by the binding.
Linking different binding is indeed task of the user (in rules or during item definition). If the Z-Wave power socket says the TV is off, the ZMote binding can’t and shouldn’t react on that and e.g. not send Volume commands. That’s higher level logic and user decision and can be take care of in rules or via sitemap visibility.
Thank you very much, your examples above helped me a lot to understand OH configuration.
I was more thinking in the line of: If the TV is OFF ZMote should send the ON button code, if it is ON the ZMote sends the OFF button code. Probably the most common use case a user will have. It would be nice if that use case could be made available without the need for rules. For example with a Switch item that has two channels bound, one for the online-check and one to send the correct button code, depending on the state of the switch.
I have another question about that. If you say the online-channel is a good idea, should I set the Thing to offline if it is no longer available? Would the online-channel work at all if the Thing was set to offline? What is the offline-mode good for, if the real state of the device should be provided by a channel?
@Temar I have to take one step back. I’m not a bindings developer myself. Passing additional data to the item binding definition was possible with openHAB 1.x but the longer I look at the Channels description the more uncertain I am, this is still possible.
Maybe @Kai could help out here. (Check the example in my previous message) Thanks!
Hello I had some time this weekend and finished an initial version of my ZMote plugin. As I do not have a ZMote device yet, I tested this version using a device mock. The plugin should work but as I wrote the device emulator myself I’m not sure if it behaves like a real ZMote device.
Can anyone with a real ZMote device please test this. Feedback would greatly be appreciated.
Just download the JAR file and copy it into your addons/ folder.
Download:
Code & Documentation:
3 Likes
Hey @Temar first of all: Well written README! I do not own a ZMote to test but all functionality looks great. The solution you chose, going with a String for both, is also nice. I would still favor to have items for specific commands (in addition to the generic sendkey String). Any idea how to accomplish that?
@urmilparikh I’ve just now (finally, as promised) ordered two ZMotes 
Thank you @ThomDietrich for your order
@Temar has done amazing work! Even without a zmote in his hand, the first version itself auto-detected multiple zmotes at my place and the binding has started communicating with them
The idea of using IR code configuration file directly downloaded from our web app is great - makes it easy for anyone to use it without worrying about specifics.