openHAB zmote binding

Tags: #<Tag:0x00007fe7469dd250> #<Tag:0x00007fe7469dd0e8> #<Tag:0x00007fe7469dcf80>

@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.


Code & Documentation:


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 :smiley:

Thank you @ThomDietrich for your order :slight_smile:

@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 :clap: :clap:

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.

The solution with the strings was just the fastest to implement, to get an initial plugin version out of the door. The plugin should now work but it still has some bugs when dealing with invalid configurations and there are quite some things I’d like to improve.

When it comes to the items configuration I’ll see what other ways I can implement, once I have a real device to play around with. Right now I have the feeling I still do not really understand the OpenHAB2 configuration details yet. Sure, basic linking is clear, but when it comes to the more complex things, like defining custom event types to simulate short or long button presses, I have a lot to read.

I’d actually like to suggest to move questions about the best architecture of a binding to as this is really all about the ESH APIs only.

I’ve actually finished an initial version of my plugin by now:

Once my device arrives I will test different ways of integrating it and I will revise the way the plugin has to be configured if other solutions make more sense.

Thanks for all your input, it helped me a lot to get a better understanding of OpenHAB2 configuration concepts.


I had my ZMote for a week now (works very well btw.) and played around with different ways of configuring the device. From what I have seen, only predefined values seem to be possible when defining an Item -> Channel link. So there is no way of passing any parameters which can be picked up by the thing handler.

This is bad, as it makes use cases like e.g. Amazon Echo integration unnecessarily complex. These use cases will always require a rule, even though we only want to pass one single parameter to the channel.

This could be solved be changing the configuration to a bridge type configuration where every button of a remote would be represented by a Thing. That way Switch-Items would be possible again. However, I think the overall configuration would get far too complicated for the normal user.

If no one knows a more elegant solution for configuring this, I will stick with the current one. What I’m looking for is something link this, where I can pass an arbitrary parameter to a channel, without having to define it in the channel definition file first:

Switch zmote_tv_power "TV Power" { channel="zmote:zmt2:tv:sendkey#POWER" }
Switch zmote_tv_power "TV Power" { channel="zmote:zmt2:tv:sendkey" key="POWER" }

Did you start a discussion about that topic in the eclipse smarthome forum?

No, I just read the documentation and browsed the code.

However, the maintainer of the GlobalCache plugin has extended his plugin to support ZMote devices as well. So I’m not sure if I should put any more effort into this plugin, as a pull request will most likely not get accepted if there is support from another plugin already. After all, both plugins would basically do just the same thing.

I see, maybe you can contribute ideas of yours there?

@mhilbush what do you think?

@ThomDietrich My goal was to add to the GlobalCache binding only enough zmote support so that it’s compatible with all the other GlobalCache devices (GC-100, Itach, and Itach Flex). This was easy to add because the zmote shares the same IR api and discovery mechanism as the GlobalCache IR devices. It literally was about an hour of work to add it (and that was when I was still pretty jet-lagged from flying back from Asia to the US, LOL).

I would prefer to not add any zmote-specific functionality to the globalcache binding. So, IMO, integrating with the rest of the zmote ecosystem is probably best left to a binding specific to zmote, which is what @Temar seems to be working on.

Hi guys.

Although zmote has GC API compatibility, it is just one part of zmote functionality. It has a lot of additional features.

For instance, it supports macros. You can send multiple IR signals in a single command, with configurable delays in between. It is useful for scene setting or for changing channels.

zmote also supports remote access over MQTT and through HTTP-to-MQTT bridge, which can be useful e.g. for controlling devices at your home from your office.

There are many more features under development. A dedicated binding will enable OH users to make use of them.



Hi guys, how can i install the first version of the binding? I have copied the JAR file in the addons folder and restarted openhab… but it does not appears in the bundle:list… What have I done wrong?

Copying the JAR into the addons folder should be enough. That worked for me and others. You can try to start it manually by entering:

start org.openhab.binding.zmote

You can also install the binding from the Eclipse Marketplace, as described here: Distributing bindings through the IoT Marketplace

@Temar: Worked! Thanks…

Hey Alex,

I’ve tested your bindings for a few days now. I’m using sendkey as well as sendcode inside my sitemap and inside rules. Everything’s working as expected. I ended up using sendcode more because I found editing the json file cumbersome and converting an IR code is quite easy using the converter - this way I’m not dependent on the zMote webapp.

You should consider supporting a map file for IR codes. It would also be amazing if your binding included the converter (you can probably ask @urmilparikh for the code or specifications) allowing codes in the other more common formats, e.g. NEC1 2 160 8.

By the help of your binding I’ve implemented one of the coolest rules my home might have seen so far, and it’s dead simple:

rule "Sound System: Switch between PC input and Sonos input channel"
    Item KodiPlayerState changed
    if (KodiPlayerState.state == "Play") WZ_zMote_sendcode.sendCommand("38000,2,69,343,171,21,22,21,65BBBBBBBBBBBCBCBBCBBBBBCCBCCCCC21,1672,343,86,21,3730")
    else if (KodiPlayerState.state == "Stop") WZ_zMote_sendcode.sendCommand("38000,2,69,343,171,21,22,21,65BBBBBBBBBBBCBCBCBBBBBCCBCCCCCB21,1672,343,86,21,3730")

What are your plans for further development? You should consider opening a pull request to get the binding into the openHAB distribution before Version 2.1.

Best! Thomas

Isn’t that possible already by just defining a map? I’ll give it a try these days.

I’ll ask him. I could also just send a web service request to his server. That was planned anyway when implementing support for reading IR codes.

Basically I wanted to implement support for reading IR codes and the IR code cleanup. Maybe also support for sending one key multiple times. However I’m quite busy atm, as I’m doing my sailing license. This pretty much takes up all my weekends for the next month.

I can send a pull request these days. I just wanted to wait a little while to see if there are any bugs left. So far I didn’t find any, so maybe it’s indeed a good time to send a PR for this version.

1 Like

I just received my two zmote devices and managed to connect them to my WIFI.
Using the examples I was able to turn on/off a TV and change channels up/down.

My question is: How can openHAB2 determine what the current state of the TV power is? If openHAB is the exclusive control, you can keep track of it, but if somebody is still using the original remote, the state can change without openHAB knowing.

Here is an example I see where this would be a problem:
I have a “vacation” setting, where the TV should be turned ON at a certain time and turned OFF again after some time. That will work fine if the initial state of the TV is OFF. But if for some reason I forgot to turn the TV off before leaving (and after enabling the “vacation” rules), the openHAB rule would invert the desired behavior, that is the TV would turn OFF at my intended ON time and would turn back ON after the rules programmed delay time. In a way, the TV should be able to be queried or alternatively, there should be a dedicated ON IR code and a dedicated OFF IR code. I have not seen that in my short time of investigating IR codes, the only thing I see in most definitions is POWER rather than POWER_ON and POWER_OFF.

Does anybody have some insight on this?

Classic problem with power IR codes that toggle the power on-off-on-off-etc… The only way you can reliably do what you want is if the device being operated has discrete on and off IR codes. Some devices have discrete on and off codes, and some do not.