Describe Your Problem: Tv does not respond to HomeKit commands, HomeKit running on raspberry pi 3, however cec-util echo commands from command line worked before installing homebridge-cec-tv-control. After plugin install, if I uses cec-util echo command from the command line after a reboot (before home bridge starts?), the tv responds to command line tools for a short while. After sometime (when home bridge starts?) the command line tools also stop responding. Homebridge logs show "unable to open device on port /dev/cec0" After a fresh install of bullseye with nothing but home bridge and this plugin the problem persists.

Logs:

[07/02/2024, 6:55:29 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:55:29 pm] [Panasonic TV] waiting for input TRAFFIC: [ 6971445] << 10:8f

[07/02/2024, 6:55:29 pm] [Panasonic TV] waiting for input

[07/02/2024, 6:55:59 pm] [Panasonic TV] Initializing TVCECControl platform... [07/02/2024, 6:55:59 pm] [Panasonic TV] Initializing TV service [07/02/2024, 6:55:59 pm] [Panasonic TV] Hooking into cec-client process [07/02/2024, 6:55:59 pm] [Panasonic TV] Adding input source with inputID of 1 and displayName of HDMI 1. [07/02/2024, 6:55:59 pm] [Panasonic TV] Adding input source with inputID of 2 and displayName of HDMI 2. [07/02/2024, 6:55:59 pm] [Panasonic TV] Adding input source with inputID of 3 and displayName of HDMI 3. [07/02/2024, 6:55:59 pm] [Panasonic TV] Finished initializing platform: Panasonic TV [07/02/2024, 6:55:59 pm] Publishing external accessory (name: Panasonic TV, publishInfo: { username: 'EC:A2:D9:D7:BE:81', pincode: '*-*-', category: 31, port: undefined, bind: undefined, mdns: undefined, addIdentifyingMaterial: true, advertiser: 'avahi' }). [07/02/2024, 6:55:59 pm] Publishing bridge accessory (name: Homebridge C382, publishInfo: { username: '0E:5A:C4:46:C3:82', port: 51675, pincode: '*-*-', category: 2, bind: undefined, mdns: undefined, addIdentifyingMaterial: true, advertiser: 'avahi' }). Setup Payload: X-HM://00240EEZBBB6R Enter this code with your HomeKit app on your iOS device to pair with Homebridge:

┌────────────┐     
│ 326-99-223 │     
└────────────┘

[07/02/2024, 6:55:59 pm] [Panasonic TV] log level set to 8 No device type given. Using 'recording device' CEC Parser created - libCEC version 6.0.2 no serial port given. trying autodetect: path: /sys/devices/platform/soc/3f902000.hdmi/cec0 com port: /dev/cec0

opening a connection to the CEC adapter... unable to open the device on port /dev/cec0

[07/02/2024, 6:55:59 pm] Panasonic TV E7E5 is running on port 42839. [07/02/2024, 6:55:59 pm] Please add [Panasonic TV E7E5] manually in Home app. Setup Code: 326-99-223 [07/02/2024, 6:55:59 pm] Homebridge v1.7.0 (HAP v0.11.1) (Homebridge C382) is running on port 51675. [07/02/2024, 6:56:01 pm] [Panasonic TV] Checking TV power status [07/02/2024, 6:56:01 pm] [Panasonic TV] Checking TV active source status [07/02/2024, 6:56:09 pm] [Panasonic TV] Checking TV power status [07/02/2024, 6:56:09 pm] [Panasonic TV] Checking TV active source status [07/02/2024, 6:56:09 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:56:19 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:56:28 pm] [Panasonic TV] Checking TV power status [07/02/2024, 6:56:28 pm] [Panasonic TV] Checking TV active source status [07/02/2024, 6:56:29 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:56:39 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:56:40 pm] [Panasonic TV] Turning TV on [07/02/2024, 6:56:49 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:56:56 pm] [Panasonic TV] Turning TV off [07/02/2024, 6:56:59 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:57:09 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:57:19 pm] [Panasonic TV] Requesting CEC Device status [07/02/2024, 6:57:29 pm] [Panasonic TV] Requesting CEC Device status

Plugin Config:

   {
        "name": "Panasonic TV",
        "manufacturer": "Panasonic",
        "model": "TH-P42X10A",
        "pollingInterval": 10000,
        "minimizeLogging": false,
        "inputs": [
            {
                "inputNumber": 1,
                "displayName": "HDMI 1"
            },
            {
                "inputNumber": 2,
                "displayName": "HDMI 2"
            },
            {
                "inputNumber": 3,
                "displayName": "HDMI 3"
            }
        ],
        "useActiveSource": true,
        "useInactiveSource": true,
        "useSourceRouting": true,
        "useSetStreamPath": true,
        "platform": "TVCECControl"
    }
]

}

Screenshots:

Environment:

Plugin Version:0.1.20
Homebridge Version: 1.70
Node.js Version: v18.19.0
NPM Version:
Operating System: Raspbian Bullseye (Pi3)

I suspect that libCEC is somehow crashing, or hanging, and that's why cec-util doesn't work once the plugin is initialized.

The plugin isn't doing anything except hooking into what amounts to the output of the CEC client, so I don't think this is a bug (at least, not an obvious one). This might be a configuration issue (although, for reference, I'm also using a RPi 3b).

Can you actually control the TV with cec-util if you don't use the plugin? It might be that the TV has a malformed CEC spec and it's crashing the buffer when the plugin goes to retrieve its status. I see that it's a Panasonic in your logs -- is this a newer Panasonic, or an older one?

It is a very old tv (2009?) and reports cec version 1.3a.

I would also say libCEC is crashing, but the strange thing is I can indeed control the TV from the command line... at least until home bridge starts (then it requires a reboot, even if I stop home bridge). If I disable home bridge (and restart) I can control the tv with no problems; today as a test I disabled home bridge and ran a script that turned on ("on" command), retrieved power status ("pow" command) and turned off ("standby" command) every minute for an hour without a problem.

I previously controlled this TV via similar scripts for months; with a plan to eventually install home bridge and use a fake switch type plugin to call those scripts. Before I ended up too far down that path I realised I was reinventing the wheel and someone else surely had made such a plugin, which is how I ended up here.

Given my testing today I wonder if its not a specific command in conjunction with this very old TV that's causing a crash. Something your plugin runs every time at startup? Something beyond the "on", "standby" and "pow" I tested with?

Hm, I'm not sure, as your log suggests it's crashing or not finding the HDMI port before my plugin even issues any commands.

Specifically:

opening a connection to the CEC adapter...
unable to open the device on port /dev/cec0

The only thing I can think of is that HDMI support has somehow changed in a more-recent version of the Raspberry Pi OS (I'm still using Buster for this). Bullseye introduced support for the dual HDMI on the Pi 4, I think, so it's likely a firmware change occurred.

Alternatively, I'm using a much older version of libCEC (once I got this working I haven't touched it since). Looking at it, it's 4.0.7, so that might be worth investigating. Downgrading might help?

Unfortunately, there's nothing obvious that's sticking out to me, and CEC is pretty complicated once you get into vendor-specific frames. It's difficult to debug remotely, as anything in the CEC chain (TV, AVR, Game consoles, Android/Apple TV) can all influence the buffer in unexpected ways.

Ok, so I did some more testing and a bit of searching and I think you're spot on. This does seems to be a libcec version or Bullseye problem (maybe in connection with a limited set of older type devices, to explain why it's not more prevalent).

Skip to the hyperlink further down if your not interested in how I got here :-)

This morning I noticed that after yesterday's testing, my command line cec control had quietly failed. I could issue the commands I was using yesterday, but the TV would not respond (no error, just no response). More testing seemed to show that after using cec-client, after some period of time it would quietly fail, but only if I stopped sending commands and it sat idle. After this occurs I discovered a "scan" command would trigger write errors (and not detect the tv), these write errors would then persist if I issued any subsequent commands. Something crashed. It's repeatable, the time seems to vary somewhat but it's as little as 5 minutes of idle time after which it can become non-responsive and it breaks every time. My testing yesterday involved sending a command every minute which I guess explains why it didn't catch this.

This certainly seems to push the problem back into libcec / Bullseye ..maybe in conjunction with my particular tv etc.

I never had this problem months ago when I was controlling the tv with scripts, which got me thinking about what you said about bullseye / libcec firmware etc. When I first tested this machine it was certainly on a legacy system (it was a long time ago, I don't know what I was using ... just whatever was on there). It was only after I got it working with scripts, as much to prove tv support as anything else that I decided to do a fresh build and look for a plugin to do it all a bit more neatly.

So I did a bit of digging and along the bullseye / libcec vein and I found this thread, which sounded all a bit similar: https://forums.raspberrypi.com/viewtopic.php?t=348779

I tried the suggestion regarding changes to config.txt... (and I confess, I'm probably at the limit of my understanding here)

As suggested I changed:

dtoverlay=vc4-kms-v3d

dtoverlay=vc4-fkms-v3d

After a reboot, the quiet failing went away, after enabling HomeKit and rebooting your plugin was working! (mostly)

It might be a legit workaround or a starting point for someone who knows more than me, but there are a couple of issues / observations...

1) As implied in the thread above, there is no video output on the HDMI ..... which may not be a show stopper for some, but is certainly not ideal. 2) The plugin works great except the status seems to revert to "off" after leaving the home app (only tested on a phone atm) ... so I suspect something's not happening with the status; I imagine this is not the standard behaviour under say Buster? 3) If you use command line tools (cec_client) after home bridge has started they work fine, but then the plugin stops working until a reboot. .. maybe this is expected / normal behaviour? maybe not?

So the short version is this looks like a Bullseye or libcec version issue, I am going try to test with a more modern tv to see if that plays a part as well (otherwise i'd expect this to be more widely known?) For me, as this pi doesn't really do anything else at the moment, I'll probably just rebuild with Buster. If I do get around to testing it with another tv first, I'll let you know if that is also a factor.

Even though this doesn't look like a plugin problem, If you do have any insight re: the three observations above or about what the workaround really means, I wouldn't mind hearing them ... I hate half fixes and things I don't understand!

Also, thanks for your help, I don't think I would have got there without the engagement.

Wow, great debugging! I'll be honest, I wasn't super impressed with libCEC's... robustness for lack of a better word. I frequently had the cec-client freeze while I was working on this, although it could just be that HDMI-CEC is extremely brittle and kind of awful to work with. 😆

So, basically, I'm not surprised it might be the culprit.

What you found does seem to point to what I would guess is an OS firmware/kernel issue first (maybe libCEC second). Since disabling the video output seems to temporarily "fix" it, I'd guess Bullseye forward is to blame. (Although that's a largely uneducated guess on my part)

I wasn't aware that libCEC is basically abandonware now. I see that there's some better supported alternatives, but I'll be honest here and say the chances of rewriting this to make use of them are low (as debugging HDMI-CEC is a huge headache). EDIT: And taking a cursory look it doesn't look like any Javascript or Typescript libraries are available, either.

If you do rebuild with Buster and everything works, do let me know! I'll update the Readme to make a note of the OS (in)compatibility. For something like this I'm not too worried about it as long as Homebridge supports Buster. Since this project requires a physical connection to a single TV it's pretty much set up for a "sacrificial" Raspberry Pi that only does one thing, so running an older OS on something like a Pi Zero or Pi 3b shouldn't be too much of a problem (in my opinion).

electroflame / homebridge-cec-tv-control

Tv respond to cec-util echo commands, but doesn't respond in HomeKit #6

dtoverlay=vc4-kms-v3d