I’ll try and create some later today. The channels are “power” (a switch), “activeSource” (a switch), “event” (a string for receiving events that will be like ‘hdmicec:equipment:local:TV:event’ for example) and “send” (a string for sending HDMI-CEC commands and be like ‘hdmicec:equipment:local:TV:send’.)
I’ve not tested the ‘send’ as much as the others. For the ‘event’ part, if you monitor the HDMI-CEC bus you will see that it’s a flood of info. It was a judgement call on which info to raise as events and what to ignore. The idea behind my approach is that the switch items would be “smart” and make it easy to do things without the end user having to know much about HDMI-CEC, whereas the event/send channels could be used by someone knowledgeable enough to play with raw HDMI-CEC commands to do something fancy.
I should put all this in a doc somewhere! Anyway, another thing to look at if you are a java head is the HdmiCecBridgeHandler.java class. It has the patterns that trigger the interaction between this openhab addon and the cec-utils io. Those patterns can actually be changed via configuration, but only for the very brave.
Since we have a conversation going, I have a design question.
For the “send” channel, there are two different ways to do it. One way is to have this channel be a part of the HDMI-CEC equipment thing. So, each piece of equipment in your system (the TV, DVD Player, etc.) would have it’s own “send” channel.
The other way would be to associate the channel with the Bridge, so you would only have only one send channel for the system. Currently this is set up the first way (associated with the equipment), but it would make more sense as coded to have it the second way (associated with the Bridge), because there is no equipment context information added when you use the send channel to post a message onto the HDMI-CEC bus.
If we are going to use this channel to transmit raw HDMI-CEC frames to the HDMI-CEC bus, then the second way is the way to go. If we instead want to create some controlled vocabulary of commands to send, that the code then uses to create equipment-specific HDMI-CEC frames, then the first way makes more sense. If anyone has a strong opinion on this, let me know. Otherwise, I’ll likely alter the code to move this channel to the Bridge. Works fine without doing that btw, but just cleaner to have it with the Bridge if we are ignoring the equipment when this channel is used.
Understood a lot and make some check via command line to send command directly from the raspberry hosting my CEC-Client (the rasp connected directly to the TV)
BTW documentation make reference to the same scenario with OSMC too
I have a problem, how to configure the bridge in Thing file stated that OpenHab is running on another Raspberry so I have to refer to the remote Raspberry attached via HDMI to TV
Don’t know if Bridge configuration accept a) ip so the information required would be xxx.xxx.xxx.xxx:0.0.0.0 b) a password eventually needed to access the remote Raspberry
I hope I made a sufficient descritpion
This is my thing file I tried to configure actually:
Bridge hdmicec:bridge:local [ cecClientPath=“xxx.xxx.xxx.xxx./usr/bin/cec-client”, comPort="/dev/ttyACM0"]
{
Thing equipment TV [ device=“0”, address=“same ip as above:0.0.0.0”]
Thing equipment CEC_Tester [ device=“1”, address=“same ip as above:1.0.0.0”]
}
Obviosly this is the result in Paper UI for the Bridge object
Status: OFFLINE - CONFIGURATION_ERROR cec-client executable not found
cec-client needs to be installed on the machine that is also running OpenHab, and the cecClientPath needs to point to that local executable. And for cec-client to be of any value, the machine running OpenHab needs to be connected to your HDMI bus with one of those PlusEight devices. It sounds like you have OpenHab running on one Raspberry, but the Raspberry that is actually connected to your HDMI set up is a different one, is that correct?
Also, the addresses in the Thing file are not IP addresses at all, they are just of the form #.#.#.#, and the TV is always 0.0.0.0. (I think…). In order to figure out the addresses, you need to run cec-client (when OpenHab is NOT running) and pipe the “scan” command into it. The blog at gordontruner.com that I mentioned before shows you how.
Yes, that’s correct, this is my scenario now
So I’m inhibited to make use of this solution for now
Hopefully someone in the future will instruct us how to interface it externally
Thank
Logically, the source of control is the HDMI-CEC adapter, so to me it would make most sense that a single “send” channel is available via a bridge thing and no other device’s thing.
I do wonder if the channel part of Item configs might be more uniform if it was implemented the other way round though. Do you have a notion of what Item configs might look like for both approaches for an example system comprising a TV, an AVR and a Kodi box?
what am I doing? I’m running openhab on one pi 3b+ and have connected another pi 3 to a HDMI Bus of my home cinema. I’m fetching the Power Status via HDMI form the remote pi.
I’ve installed cec tools on the home cinema pi and created a key based authentification from the openhab pi to the remote pi for the root account:
I’ve created some scripts on my openhab pi, e.g:
yamaha_status.sh
#!/bin/bash
ssh pi@remotehost 'echo “tx 15:8F” | cec-client RPI -s | grep "Audio (5): power status
With a simple rule I’ m fetching the status:
rule "Get CEC Yamaha Status"
when
Time cron "0 * * * * ?"
then
if(PI_Power.state==ON){ //only running when remote device is online
createTimer(now, [ |
val result = executeCommandLine("sudo@@/home/openhabian/script/yamaha_status.sh", 5000)
val trans = transform("REGEX",".*? to '(.*?)'.*",result.toString)
if(trans=="on"){
Yamaha_Power.postUpdate(ON)
}
if(trans=="standby"){
Yamaha_Power.postUpdate(OFF)
}
])
}
end
You should be able to send commands this way, too. Just define some Items calling scripts controling your remote pi via ssh.
Configuration in terms of *.things file would be the same, and the rules would just swap one or more thing-based-channels to a single bridge-based channel.
But agreed, I’ll make the change to move the “send” channel to the bridge, it just makes more sense. What I really need to know is where to put documentation…
Sorry, I’m a little bit confused
I understood this
From the RP3 running openahab, I proceed with the first two steps in quote (don’t see any cd command after that),
On the same machine, I proceed with the third step
Only doubt about the user I have to specify for the fourth step
Is it my currently openhabian user which regulary used to login to openhab machine via ssh?
Or my OSMC user on the remote device?
Obviously target machine is the RP3 currently connected to my TV device, the OSMC RP3 machine
i’ve integrated the 2.4 snapshot build.
Is the paper ui configuration possible? In my configuration there is nothing happens and the cec “bridge” is only in the uninitialized status. The trace log is turned on but there is nothing in the openhab2 log File.
What can I provide or where can I search to find the problem?
But I can’t get any messages through “openhab.log”.
I set the trace debug level for through OSGI-console and checked this through:
–> /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg
