openHAB zmote binding

[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?

[ThomDietrich]

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

[Temar (Alex)]

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:

alexmaret/openhab-binding-zmote

Code & Documentation:

alexmaret/openhab-binding-zmote

[ThomDietrich]

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

[urmilparikh]

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.

[Temar (Alex)]

@ThomDietrich

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?

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.

[Kai (Kai Kreuzer)]

Maybe @Kai could help out here. (Check the example in my previous message) Thanks!

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

[Temar (Alex)]

I’ve actually finished an initial version of my plugin by now: https://github.com/alexmaret/openhab-binding-zmote

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.

[Temar (Alex)]

@ThomDietrich

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

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" }
or
Switch zmote_tv_power "TV Power" { channel="zmote:zmt2:tv:sendkey" key="POWER" }

[ThomDietrich]

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

[Temar (Alex)]

@ThomDietrich

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.

[ThomDietrich]

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

@mhilbush what do you think?