OH2 IR transmitter binding development. User input requested

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.