Silver Adept (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
silveradept) wrote2024-06-16 10:44 pm
silveradept) wrote2024-06-16 10:44 pm
Entry tags:
Adventures in Home Automation #13: Welcome Back (Again), Bedroom Television
Bit of a redux situation here, brought on by having done what is apparently the most dangerous thing to do for any Linux machine: run updates. The machine that did have the MQTT-CEC bridge from the earlier situation got itself caught in a bind when things wanted to update, but one of the crucial libraries involved would not update itself to a new version that needed it. The attempt to do the update broke everything, and it was easier to wipe the machine and re-image it than to try and fix the snarl. Which put us back on a different path, with an operating system that once again is more intended for the machine, rather than one that hasn't fully managed to hack its way into full compatibility yet. In the interim, though, there were enough upgrades and new systems and things that it was worth going back to what had been. (Most importantly, getting Widevine on the thing was no longer difficult. Since it's a bedroom TV thing, it kind of needs to decode DRM-laden streams to be entertaining.) However, in my distaste for how the upgrade process had bombed spectacularly, I wiped the item without copying off the old executable that I had, which managed the bridge. I figured I could reconstruct it when the new system was in place.
Not so much. Turns out that Go has changed sufficiently in the interim that the old code I had put to use, which had a last update of several years ago, no longer worked out of the box to retrieve the necessary dependencies and compile. I spent an awful lot of time trying to figure out how to put the right things in the right places to get the module to go, but it didn't, and eventually, frustration won out, because I didn't know enough about what I was looking at to have an idea of what needed fixing, and the manuals and documentation weren't clear enough to me to be helpful.
So I went back to the basics of the HDMI-CEC integration in Home Assistant and a pyCEC server on the Pi connected to the TV. That did not work out at all. Home Assistant could see the server, but from what I could see of the logs of said server, Home Assistant was basically perpetually pinging it and not sending commands or receiving messages in return. So that idea got scrapped in a hurry, and so, instead, we turned to what everyone else seemed to be using as their basis for bridging, a bit of fairly old Python code configured to run in a Docker container. I don't like the idea of doing it that way, but that was the way that everyone else on the Internet seemed to be going at it.
The problem with that particular piece of code, and basically all of its forks, is that the docker image they rely on ot pull things and put them together seems to be hard-pinned to a specific version of Debian to find libraries from, and naturally, since it's older code, that version of Debian is now several versions out of date, and the servers that supposedly would serve those old libraries and let them get bundled in don't exist. So once again, things were going to result in frustration, because the stupid thing wouldn't compile when you ran the install instructions for it. Even the fork of the original that I ended up using for my base still has the old Dockerfile integrated into it. Big grumbles all around for this. Admittedly, this is all based on fairly old code, even if the forks are newer and have been trying to do other things with that code and to make it work better. So I suppose that's a testament to the longevity of Python code?
After being stymied by the hard-pinned out-of-date material in the Docker image, it seemed like things were not going to go for me at all. However, because I am experienced in the ways of F Around and Find Out, and this was specifically a machine meant for that purpose, I gave it persistence and examined the code itself to see what kind of requirements and dependencies the script itself had. All of the named Python libraries listed as requirements, I could (and did) install as system packages to make them available to the script, with the idea that I could skip the Docker bit and run the script directly. And it almost worked just by doing that. When I invoked the script, though, one of the try-except situations caught me. The code was trying to set up an interface to the CEC bus, and if successful, would proceed, but if it didn't, it would fail and throw an exception. Since the exception seemed to be happening on a specific kind of parameter, I wondered if removing the parameter and the reference to the parameter would make the script work. It did, in the sense that removing the parameter and its reference meant the script continued on, and supposedly connected itself to a bus and was listening and publishing to the MQTT broker. Except when I tried to listen for the traffic, and to send command to the topics that the bridge was supposedly listening to, I didn't get anything. No reaction. So I assumed that what I was getting was a false positive, and stuck the parameters back in that I'd taken out, so as to get back to the actual error messages I had been getting before.
The debugger/interpreter had isolated a specific line as the issue and the problem that was raising exceptions. The code itself seemed fine and normal, nothing obviously wrong that an inexperienced person like me could spot. So I let my information professional self out and started querying the line, and then parts of that line, to see if there were other projects out there that were using the same code method of creating a connection to the CEC adapter. There was one that came up in the search results, and it was a code snippet that, as best as I can tell, is intended to interpret CEC signals and transform them into keystrokes. It looks like the idea in that script is to have a remote control be able to navigate through things like RetroArch, EmulationStation, and other such classic gaming tools. What's important is that from this code snippets, there was the "create" code from before, but it stored that command into a variable, and in the next line underneath it, there was a method call to detect any adapters that were in that variable, with a condition to exit if none were found. Being the kind of person who happily will borrow someone else's methods if it looks like they might work (and also basically not understanding what was going wrong on any kind of conceptual level so as to be able to insert any code of my own), I dropped in the additional code to detect a CEC adapter, saved, re-ran the script, and my MQTT listener lit up like a holiday display, along with encouraging signs from the script itself. I sent test messages and examined output and apparently, rally-ho, the script was working by itself and did not need any of the Dockerfile anything.
Do I really know what I did? Well, in the sense that I can read the additional line or two that I added to the script and have a reasonable idea of what it does, sure. Would I have thought to add that myself, because I had studied the libraries and knew that was one of the available methods? No. Is this coding? Well, maybe. But it also turns out that this method of doing things is pretty robust. The old executable occasionally would either stop or wander off or otherwise need to be stopped and started again. The Python script seems to be going gangbusters and working great for a significant amount of time after the initial run of the script on logon. So it's possible that this version of the solution is a superior one for reliability and for using what was already available.
[Victory Fanfare Plays, Somewhat Confused?]
As with so many of these things that involve automation, functionality, and other such kinds of things, where I didn't actually write anything, but instead poked, prodded, borrowed, and banged together something that appears to have worked correctly, I don't know that the thing that I did was "coding" in any meaningful sense. Engineering, absolutely. Debugging, maybe? Systems thinking and information professional work, definitely. And a healthy amount of Effing Around and Finding Out to see what happened when I changed things or inserted stuff. I'm glad it works, but I'm definitely having a moment of "can I be justifiably proud of having managed to put this together and found a working solution?" A+ for effort and persistence, certainly, and hooray that it works! Which are the things that I really do want to encourage for myself and others.
It might be something to do with feeling like my nerd credentials are somehow in jeopardy, or something, since I'm still somewhat resolutely an end-user type who appreciates good GUIs and tutorials, and borrows where possible, rather than trying to build everything myself. And that I often do things in the service of getting games to play, or to tinker and play, or (most often) because someone else has an idea of something they want to do and have asked me how they might go about doing it. Pay no attention to the "has successfully installed many different forms of Linux on different machines," "has installed aftermarket OS on phones and tablets," "rescued a flash gone wrong by literally shorting a circuit to hard boot a device into recovery mode," and other such things, they don't count because I followed tutorials, rather than editing the inodes manually with magnets or tracing and then soldering together all the components of a machine and then wrote the operating system and software for it. Yes, it's a silly worry. But there's always the urge to compare what I'm doing to the people who actually built the libraries and code that I'm using and say that I'm not really doing anything at all.
To some degree, that's why I'm documenting these things: So there's a record, yes, and also so that I can look at what I did and hopefully then recognize that what I did was still impressive if I think about it from the perspective of someone who doesn't have all of the background knowledge and experience that I have that absolutely makes difficult things seem easier to me because I'm starting on step five of the true process, rather than step one.
Not so much. Turns out that Go has changed sufficiently in the interim that the old code I had put to use, which had a last update of several years ago, no longer worked out of the box to retrieve the necessary dependencies and compile. I spent an awful lot of time trying to figure out how to put the right things in the right places to get the module to go, but it didn't, and eventually, frustration won out, because I didn't know enough about what I was looking at to have an idea of what needed fixing, and the manuals and documentation weren't clear enough to me to be helpful.
So I went back to the basics of the HDMI-CEC integration in Home Assistant and a pyCEC server on the Pi connected to the TV. That did not work out at all. Home Assistant could see the server, but from what I could see of the logs of said server, Home Assistant was basically perpetually pinging it and not sending commands or receiving messages in return. So that idea got scrapped in a hurry, and so, instead, we turned to what everyone else seemed to be using as their basis for bridging, a bit of fairly old Python code configured to run in a Docker container. I don't like the idea of doing it that way, but that was the way that everyone else on the Internet seemed to be going at it.
The problem with that particular piece of code, and basically all of its forks, is that the docker image they rely on ot pull things and put them together seems to be hard-pinned to a specific version of Debian to find libraries from, and naturally, since it's older code, that version of Debian is now several versions out of date, and the servers that supposedly would serve those old libraries and let them get bundled in don't exist. So once again, things were going to result in frustration, because the stupid thing wouldn't compile when you ran the install instructions for it. Even the fork of the original that I ended up using for my base still has the old Dockerfile integrated into it. Big grumbles all around for this. Admittedly, this is all based on fairly old code, even if the forks are newer and have been trying to do other things with that code and to make it work better. So I suppose that's a testament to the longevity of Python code?
After being stymied by the hard-pinned out-of-date material in the Docker image, it seemed like things were not going to go for me at all. However, because I am experienced in the ways of F Around and Find Out, and this was specifically a machine meant for that purpose, I gave it persistence and examined the code itself to see what kind of requirements and dependencies the script itself had. All of the named Python libraries listed as requirements, I could (and did) install as system packages to make them available to the script, with the idea that I could skip the Docker bit and run the script directly. And it almost worked just by doing that. When I invoked the script, though, one of the try-except situations caught me. The code was trying to set up an interface to the CEC bus, and if successful, would proceed, but if it didn't, it would fail and throw an exception. Since the exception seemed to be happening on a specific kind of parameter, I wondered if removing the parameter and the reference to the parameter would make the script work. It did, in the sense that removing the parameter and its reference meant the script continued on, and supposedly connected itself to a bus and was listening and publishing to the MQTT broker. Except when I tried to listen for the traffic, and to send command to the topics that the bridge was supposedly listening to, I didn't get anything. No reaction. So I assumed that what I was getting was a false positive, and stuck the parameters back in that I'd taken out, so as to get back to the actual error messages I had been getting before.
The debugger/interpreter had isolated a specific line as the issue and the problem that was raising exceptions. The code itself seemed fine and normal, nothing obviously wrong that an inexperienced person like me could spot. So I let my information professional self out and started querying the line, and then parts of that line, to see if there were other projects out there that were using the same code method of creating a connection to the CEC adapter. There was one that came up in the search results, and it was a code snippet that, as best as I can tell, is intended to interpret CEC signals and transform them into keystrokes. It looks like the idea in that script is to have a remote control be able to navigate through things like RetroArch, EmulationStation, and other such classic gaming tools. What's important is that from this code snippets, there was the "create" code from before, but it stored that command into a variable, and in the next line underneath it, there was a method call to detect any adapters that were in that variable, with a condition to exit if none were found. Being the kind of person who happily will borrow someone else's methods if it looks like they might work (and also basically not understanding what was going wrong on any kind of conceptual level so as to be able to insert any code of my own), I dropped in the additional code to detect a CEC adapter, saved, re-ran the script, and my MQTT listener lit up like a holiday display, along with encouraging signs from the script itself. I sent test messages and examined output and apparently, rally-ho, the script was working by itself and did not need any of the Dockerfile anything.
Do I really know what I did? Well, in the sense that I can read the additional line or two that I added to the script and have a reasonable idea of what it does, sure. Would I have thought to add that myself, because I had studied the libraries and knew that was one of the available methods? No. Is this coding? Well, maybe. But it also turns out that this method of doing things is pretty robust. The old executable occasionally would either stop or wander off or otherwise need to be stopped and started again. The Python script seems to be going gangbusters and working great for a significant amount of time after the initial run of the script on logon. So it's possible that this version of the solution is a superior one for reliability and for using what was already available.
[Victory Fanfare Plays, Somewhat Confused?]
As with so many of these things that involve automation, functionality, and other such kinds of things, where I didn't actually write anything, but instead poked, prodded, borrowed, and banged together something that appears to have worked correctly, I don't know that the thing that I did was "coding" in any meaningful sense. Engineering, absolutely. Debugging, maybe? Systems thinking and information professional work, definitely. And a healthy amount of Effing Around and Finding Out to see what happened when I changed things or inserted stuff. I'm glad it works, but I'm definitely having a moment of "can I be justifiably proud of having managed to put this together and found a working solution?" A+ for effort and persistence, certainly, and hooray that it works! Which are the things that I really do want to encourage for myself and others.
It might be something to do with feeling like my nerd credentials are somehow in jeopardy, or something, since I'm still somewhat resolutely an end-user type who appreciates good GUIs and tutorials, and borrows where possible, rather than trying to build everything myself. And that I often do things in the service of getting games to play, or to tinker and play, or (most often) because someone else has an idea of something they want to do and have asked me how they might go about doing it. Pay no attention to the "has successfully installed many different forms of Linux on different machines," "has installed aftermarket OS on phones and tablets," "rescued a flash gone wrong by literally shorting a circuit to hard boot a device into recovery mode," and other such things, they don't count because I followed tutorials, rather than editing the inodes manually with magnets or tracing and then soldering together all the components of a machine and then wrote the operating system and software for it. Yes, it's a silly worry. But there's always the urge to compare what I'm doing to the people who actually built the libraries and code that I'm using and say that I'm not really doing anything at all.
To some degree, that's why I'm documenting these things: So there's a record, yes, and also so that I can look at what I did and hopefully then recognize that what I did was still impressive if I think about it from the perspective of someone who doesn't have all of the background knowledge and experience that I have that absolutely makes difficult things seem easier to me because I'm starting on step five of the true process, rather than step one.