openHAB zmote binding

[urmilparikh]

Super! All the more reason to get a binding quickly

[Ari_Hagman]

Hello @urmilparikh,

I received my zmote and I was able register on of my remotes to that. I was able use web ui to send the commands to my tv. So exellent start!

I checked the API from here GitHub - zmoteio/zmote-server: Server behind zmote.io using Expressjs.

There is a command:

PUT /<sta_mac>/api/ir/write

but the function is bit too low level for me.

Is there an api that understands the remote that I have registerd? So basically if I have a remote like bellow:

I could send something like:

{“remote”: “SAMSUNG_BN59-00940A”, “command”:“Power”}

–Ari

[urmilparikh]

Hi @Ari_Hagman,

That’s a good start, indeed!

Unfortunately, zmote only understands IR signal format. All association of remotes, buttons, etc is handled in the front-end. We designed it that way mainly since it will be difficult to store many remotes inside its little internal memory. Also, having done it that way makes zmote flexible to support variety of IR protocols.

Anyways, I’d recommend this page for simpler explanation of APIs:

REST control over zmote | Details | Hackaday.io

Also, since you have got your TV remote setup on the web app, I can show you a quick way to get the JSON required for each button:

1. Navigate to your TV remote page in web app.
2. Append ?download=true to the URL and refresh the page. Refreshing is necessary. Refer below image.
3. You should see a download button on the left of menu button.
4. Click on that button to download whole JSON file associated with your TV remote.

With a little parsing of that JSON file, you will be able to find out codes that need to be sent to zmote for each button on your remote.

Here is a sample key:

...
 "keys": [
  {
   "key": "KEY_POWER",
   "name": "POWER",
   "code": {
    "period": 864591,
    "n": 36,
    "seq": [
     320,
     159,
     20,
...
     20,
     859
    ],
    "repeat": [
     0,
     2,
     36
    ]
   },
   "spec": {
...

The code part is what you will need.

You can use this method to download codes for any remote you like.

Ping me if you face any difficulties.

[Ari_Hagman]

Thanks @urmilparikh,

this helpped!

If I understand correctly I need use exec binding (curl) so send these commands now, because openhab2 does not have support to post command with body content?

–Ari

[urmilparikh]

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.

[Ari_Hagman]

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

[urmilparikh]

I hope it was smooth.

A binding will come soon… stay tuned

[ThomDietrich]

Wow this looks like a nice process. I’ll need to order one Ari, can you post your working configuration?

[Ari_Hagman]

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"

[urmilparikh]

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.

[Wqty]

Hello,

I’ve bought one and configured with no problems. Great product and easy to understand manual. Great job!

One note to your example:

@urmilparikh

(…) '{“frequency”:37900,“n”: (…)

Don’t we need to use something like this???

(…) '{“period”:37900,“n”: (…)

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!

[urmilparikh]

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!

[Deviance (James Ross)]

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!

[davidg]

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

[Temar (Alex)]

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?

[ThomDietrich]

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!

[Temar (Alex)]

Thanks for your input!

@ThomDietrich

The thing should take the IP rather than the URL.

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.

@ThomDietrich

Relying on an external file is a bit uncommon and I’d see that as a bit unflexible.

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.

@ThomDietrich

Another aspect you would need to take care of is receiving IR codes (needed before we even can define sending items…).

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!

[ThomDietrich]

On a side not, I just saw the other thread now.

OH2 IR transmitter binding development. User input requested

I’m currently developing a binding for the ZMote IR transmitter and need some input from experienced OpenHAB2 users regarding the way such a device should be configured. Basically I see three main uses cases: Have some kind of button type item where you can press the button and it simply transmits an IR code once. Maybe support some way to distinguish between short and long button presses, which would affect how often the IR code is repeated. Have some kind of switch type item where toggl…

URL vs. IP: That are some good arguments. How about supporting both. This way the user can use whichever information he/she has

@Temar

file can be downloaded somewhere from the ZMote web app

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

@Temar

That will not be included in the initial version of the plugin, as it is handled by the ZMote web app

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

@Temar

I’m wondering if I should have that online channel

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.

@Temar

What is the better approach?

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

@Temar

Whenever the switch is toggled it should send the correct IR code for ON/OFF, but the state of the switch should actually be determined by another Item (e.g. a network thing) which can check if the toggled device is online or not. How would such a configuration look like?

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.

[Temar (Alex)]

Thank you very much, your examples above helped me a lot to understand OH configuration.

@ThomDietrich

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.

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.

[Temar (Alex)]

@ThomDietrich

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.

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?