OH2 IR transmitter binding development. User input requested

Add-ons Bindings
1

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:

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

  2. Have some kind of switch type item where toggling the switch sends either the ON IR code or the OFF IR code and the current state of the switch is determined by some other binding which is able to query if the device is currently online.

  3. Support the sendCommand() method so IR codes can be sent from within rules easily.

How should this configuration (mostly 1 and 2) look in OpenHAB2, so it fits properly into the new OpenHAB2 concepts?

Right now I started to implement the auto-discovery of the thing which let’s me test if the IR transmitter itself is currently online. Once that is finished I have my first “online” channel which is represented by a read-only switch.

Next I will obviously need some kind of channel which accepts a button name, triggering the transmitter to send the appropriate IR code. But which data type should this channel have, to fit into the final configuration and how would the configuration look like, to support the above use cases? How would I connect a switch with different items where one item provides the state of the switch and the other item is used to execute toggle commands (= send IR codes)?

I just started using OpenHAB2 so the configuration concepts are still new to me. Any advice would be very welcome. How would you like to see an IR transmitter being configured in OpenHAB2? What would be your preferred way of configuring it, so it fits into your use cases?

2

Note that there are some constraints with which you need to work with in OH.

Your binding will expose one or more devices (Things) and each Thing will have one or more Channels. Channels get linked to Items and there is a relatively fixed set of Items avaiable to choose from.

So, in referece to 1, You have a Switch Item. There is no “some kind of button type”. For 2 there is the Switch Item. For 3, all bindings are required to support sendCommand. Otherwise it isn’t a binding.

I strongly recommend looking at the Harmony binding to see how a similar technology works with OH.

3

You also could take a look at how I handled IR in the GlobalCache binding using the MAP transform service.
http://docs.openhab.org/addons/bindings/globalcache/readme.html

2 Likes
4

I also find it interesting that the zmote uses the same IR command format as Globalcache.

sendir,1:1,0,<frequency>,1,1,<m1>,<s1>,<m2>,<s2>,...,<mN>,<sN>

http://www.zmote.io/apis

5

Thanks for your input!

I already had a look at the code of a lot of add ons and I’m currently implementing the device discovery which is nearly done. Right now I’m writing the code to update the configuration of already discovered devices so their IP gets updated when they get a new address from the DHCP server.

The first channel I implemented is the “online” channel which represents the current state of the IR transmitter.

Still I’m struggling with how the configuration of a switch should look like which combines sending IR codes and checking the state of a device with the help of another Thing/Item. 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?

That is indeed very interesting. The ZMote devices used to use JSON for their IR request but the latest firmware switched to the above strings to reduce the processing time on the device. The ZMote code is open source (zmote.io · GitHub), maybe they share some common open source libraries which are also used by GlobalCache.

Thanks for all your input, I will have a closer look at the suggested add-ons.

6

I don’t have a clear understanding of what you are trying to accomplish but it seems like you are trying to make the binding do too much. The job of a binding is to communicate with devices and present those devices to OH in a standardized way.

If your device has an online status, you have an online channel that gets linked to a switch or contact item. Fit a remote you have either one channel or button and use a switch for each or you have one channel that represents a push button linked to a string item. When one sends a command string to that item it causes the controller to emit the corresponding it signals.

The key take away is you don’t have just one switch. You have multiple. You would have one representing the online status and another fur sending commands to the device. If you need to combine them somehow you need to use rules and proxy Items, particularly if these are items bound to channels from multiple different bindings.

Doing something in one Channel based on the state of other channels is a job left for rules. That doesn’t mean you can’t store a state internally to your binding, for example some logging to not send commands on to the device if it is offline.

7

That was pretty much the information I was looking for, thank you. So it is indeed the concept of OpenHAB to do even simple checks within rules. It makes sense, but sounds a bit cumbersome for simple use cases like the one described above.

I have implemented that already but now that I have more insights I’m wondering if I should have that online channel at all? After all I can just set the device to offline if it is not available. So should I have an online channel or is it just a waste?

What is the better approach? That is exactly something I was wondering about. Which solution would be more flexible and fit better into the OH architecture?

Proxy items was something I was wondering about. How would a proxy item look, which gets its on/off state from one channel and sends ON/OFF to my transmitter channel so I can send the appropriate button codes? Is this possible without using rules?

Thanks for your input.

8

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

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

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

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.

9

I would keep it. Remember you can’t predict all the different things or ways one may want to do automation. Fit example, maybe a user wants to have the house speakers say "zmote is offline " when they try to use it and it isn’t online. Without this channel you eliminate that as a possibility.

You don’t have to do it this way but anything you do internal to your binding precludes users from using that event it state in their own automation.

But realize that your binding needs to be self contained. If you want to track the online status of a device, you need to do it in your binding. You cant guarantee the user will install other bindings you need or create other channels you need and I’m actually not sure if a binding has access to Things created for another binding.

I’m not an oh cider so am mainly going on observation here. I could be wrong. I often an.

I’ve[quote=“Temar, post:7, topic:22971”]
What is the better approach?
[/quote]

I can’t answer that. I don’t know this device. I don’t know how it interacts with the world nor how it interacts with oh.

If oh primarily sends it button presses the answer may be one thing and if the device and OH button press events the answer could be the opposite. If there are a whole lot of potential buttons to represent you will want to go one way but if just a few you may want to go another. You may want to take a middle path and do both.

Sometimes. It was easier to do in oh 1.x I think but I think you can still do it using channels. You just link the Item to more than one channel. However this mainly works only if you have one channel be incoming and the other outgoing. Otherwise you may end up in a loop.

10

Yes, we have implemented iTach APIs as well, sighting that it is easier for humans to handle IR code in that format than JSON. This format also allows simple compression, which helps for long IR codes, e.g. air conditioner codes.

Additionally, zmote supports multi-line commands for macro operations. For instance, you can build a single command that changes to channel 249 by clubbing IR codes for digits 2, 4 & 9 with some delay inserted between them.

@mhilbush, your binding will probably work as it is with zmote, except for automatic discovery. zmote also emits UDP beacon very similar to iTach, but slightly different content.

  • I was wondering, how do you handle toggle codes?
11

@urmilparikh Thanks for that info. Can you point me to the spec for the udp beacon for zmote? I’ll add to my binding and pick up a zmote to test with.

Do you think the zmote can be controlled by the globalcache binding by adding it manually through the OH Paper UI? From your comment above, it sounds that might be the case.

12

Sorry, missed the question about toggle codes. I assume you are referring to IR codes such as for power? I don’t maintain state in the binding as it would not be reliable. Short answer is that I don’t have any special handling for toggle codes.

13

I think I found it. Is this it?

14

That’s old code, here is the new format:

AMXB<-UUID=CI00a1b2c3><-Type=ZMT2><-Make=zmote.io><-Model=ZV-2><-Revision=2.1.4><-Config-URL=http://192.168.1.12>

By the way, here are two useful links:

  1. Basic IR send / receive APIs: http://www.zmote.io/apis
  2. Advanced APIs: http://www.zmote.io/fedg

zmote also supports remote communication over MQTT, but I wonder if it is helpful in OH2 context.

15

Oh, by the way, zmote supports all commands through HTTP POST as documented in the APIs as well as over TCP port 4998. So, yes, your existing binding should work by adding it manually.

For fast UDP discovery, sending SENDAMXB to UDP multicast 239.255.250.250:9130 will make all zmotes in the network emit UDP discovery beacon immediately.

16

No, there are some IR protocols like RC5, which contain a toggle bit as part of IR signal. This bit should be toggled on every key press. So, every key requires two IR codes and the sender should send them alternately.

In zmote context, the IR signal converter tool shows Code as well as Toggle for such protocols.

17

Thanks for those links, especially the advanced API link, which I didn’t have. This should be pretty easy to add zmote support to the binding, but I won’t be able to get to it for a couple weeks. I’ll report back here with an update.

18

@urmilparikh Just getting back home from vacation – shaking off the jet lag…

My zmote was delivered while I was away. I set it up, then modified the globalcache binding to detect and operate it. As I expected, it was easy to add. I still need to do some documentation updates, then I’ll do a PR with a new binding that includes zmote support.

19

Good to know that @mhilbush!