![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradeptThis is more of an assorted miscellaneous, et cetera kind of post, but it does have a few important elements to it involved in home automation and working with technology in general
The first is to keep a backup of all of your crucial files, preferably off the machine that holds the main operating systems. I got a reminder of that recently when I upgraded my tablet and my phone to Android 13, now that there was an official release of Lineage for the tablet and the phone release was basically "there's something we'd have to fix to make it official, we don't have a clue how to fix it, so all the 13 builds will have to be unofficial until we get to 14 or we have a miracle and the problem fixes itself." The problem with version upgrades for Android is almost always that the launcher gets upgraded and that often means all of the icons, groups, widgets, and other such gets wiped in one way or another. So all of that work I'd done in post #8 about getting the daily wisdom formatted correctly and displaying in the Android widget? Gone. I was able to recreate some of it from memory, but I didn't have everything in place, and I hadn't copied the code snippet anywhere else I could find that I could use to cut and paste back in to the widget. After reconstructing the whole thing, and possibly refining it again, so that the regular expression replacements works with one statement that puts both the opening and closing emphasis tags around what's been captured and remembered, I have rebuilt the widget. And then promptly saved the code in a different place so that if the widget gets nuked by accident or some later upgrade, I'll be able to cut and paste back in to the next widget. I also learned about capture groups and how to reference them (because backslash is a metacharacter, to reference capture group 1 by using \1 in the regular expression, I had to do \\1 instead, to make sure that the backslash was escaped properly. It took me a fair amount of time to realize this, because sometimes the obvious eludes me. More on that later.) Ideally, I'd like to get that wisdom formatting down to one or two lines by combining the filter operations all together into one, but I'm not sure that I can do that. It uses the pipe character, but that doesn't necessarily mean it pipes in the same way, such that I could put all the regular replacement filters on one line and the regular expression filter on the next line.
That's reminding me that I should probably off-site the next Home Assistant backup I make in anticipation of an upgrade to the systems, or something. I don't know how much of it would still be necessary for the current paradigms in place, but better safe and having all of the elements in place I'd need to reconstruct it all than sorry and trying to reconstruct everything by hand.
Speaking of failing to notice the obvious, I used a little bit of birthday savings to purchase myself a pair of PineBuds, to see how they did, to hope that a really good open firmware gets developed for them to use, and to complement my PineTime. (Pebbles are still the champion of good smartwatches, but they got eaten by Fitbit, who in turn got eaten by Google. The PineTime does reasonably well for all the things I want a smartwatch to do, and they keep developing new and better things for it with each firmware release.) The current set of wireless Bluetooth headphones I had have a wire running between the two headphones, and I found it very aggravating the way the wire would not move with my head, such that when I turned my head, one of the earphones would pull against me, and I'd have to reset the position of the earphones and the wire. Plus, having something on the back of my neck like that was giving me some sensory No. The PineBuds were cheap enough to want to experiment with and see whether or not that kind of style was something I wanted. They arrived, and I was ready to get them to go to work, but they wouldn't turn on. They wouldn't light up, even though I made sure their charging cradle was properly charged. I was getting disappointed with them, worried that they might have been dead on arrival, and I was showing them to my partner and lamenting the possibility of getting a dud, when they said "Well, I'll remove the tape around the charging contacts," and proceeded to strip off the two strips of blue tape that were protecting the charging contacts during their shipment. Once the earbuds could actually make uninterfered-with contact with the cradle's charging spots, the earbuds lit up with charging immediately. So I let them, and once they had enough charge to turn on, they connected properly and I tested their ability to play music, and it seemed acceptable enough all the way around. We'll have to see how they do handling telephone calls and their single-earbud versions so I can have one earbud in and one listening to the world around me, but I stared at those earbuds for a very long time without noticing the tape. I might have discovered it, but it would have been entirely by accident. So, my partner gets to say to me that I owe them the proverbial $5,000—$1 for taking of the tape, and $4,999 for knowing it was there in the first place to take off. Always get a second opinion before you declare something's gone, right? Sometimes the way that another person sees the world will be exactly what you need.
And sometimes you just have to be clever yourself and deal with inadequate documentation and a lot of jank and bugginess in your situation. Which, in my case, involves the fact that another part of my birthday savings went toward buying a new universal remote. We'd been doing great with a Logitech Harmony device for a while, but the device we had has one button that's basically dead and another that's dying on the context menus where most of the remote functions exist. This wouldn't normally be such a problem, except Logitech is no longer making new remotes in the Harmony series, so it's not like I can buy a replacement remote from them. So, instead I got the Skip1s universal remote from the people who made the FLIRC USB infrared receiver, which I had bought almost immediately to use to drive my media center PC when in Kodi or other media-rich applications. The Skip1s is not the same as the Harmony, with only three profiles to work with, but it does allow for mapping in such a way that a single profile might control two or three devices at a time, such that I can have the power button control the screen, the volume buttons control the soundbar, and the remainder of the buttons control the FLIRC so that I can fast forward and skip around in media playback situations.
The first problem I ran into was that while the Skip1s's database of codes could work on my TVs and soundbar, and had profiles for making the FLIRC work, it didn't have anything for controlling the HDMI input switcher that I have as part of the setup. That's kind of an important thing in the whole scheme of it all, so things weren't looking great, but I discovered in a forum post that there is a way of activating an administrative console mode where new devices can be taught to the remote, so long as something has properly captured the codes. (Which, incidentally, made the Windows app much less stable, as in going from "crashes once every six openings" to "crashes five times out of every six openings." I wouldn't have used the Windows app at all, but the Linux AppImage provided kept throwing warnings about missing libraries that i suspect would have been found and covered on an Ubuntu system. That defeats the idea of an AppImage, though, they're supposed to be completely self-contained and distribution-agnostic. Furthermore, just to get the admin console part to work correctly, I had to run the "put this in your MacOS X console" command on one of my Linux machines so I could replicate the output on the Windows machine. Beta software, man.)
In the same forum post, there was a suggestion to use a software piece that would analyze IR signals and convert them to the correct codes to use for the remote. Sounds simple enough, right? Well, except the part where the software program itself doesn't know how to talk to the FLIRC and accept signals directly from it. Continuing to browse the forums, however, turned up that with a newer release of the FLIRC software and firmware, there was a command-line tool that would capture any signals sent to the FLIRC and output them in a specific kind of format to the console. So I ended up upgrading the firmware and software on the FLIRC machine, starting the capture program, going through all of the buttons on the switcher remote, annotating the file so that i knew which signals were attached to which buttons, and then realizing that I had no idea what parts of that were supposed to be input into a file so that the remote would recognize the switcher and it would work. I was pretty suspicious about the outputs of some of the signals, because they looked functionally identical in some spaces, even though they were supposed to be different buttons being pressed.
It took me quite a while to remember that the IR analyzer program would also accept a file as an input and could analyze the signals that way and convert the raw signal elements into the proper codes the remote would need to command the switcher. So i formatted the raw signal numbers into a file type the analyst program would accept, them had it convert the raw signal to acceptable codes, packages those codes into a file format the remote app would accept, and then taught the remote the switcher and assigned the various functions to appropriate buttons on the remote. Three profiles, one for each screen and one for the switcher, and the new remote was in business, but for one new problem that had cropped up - the FLIRC had stopped responding to command that should have worked on it before. What had happened?
Turns out the firmware upgrade had caused some problems, such that the FLIRC wasn't being properly recognized or controlled, which I only picked up on when I read some console logs and saw the error message. The actual program itself gave very little indication that it was having any trouble, other than the problem that pushing the buttons on the virtual controllers didn't do anything, either, even though it should have. Thankfully, once I had a useful error message to search against, the forums had a suggested solution to the problem of the device not being recognized, involving clearing out all the software, then installing fresh and seeing if things resettled themselves. Which they did! Although I then had to re-teach the other remote what the new correct commands were to restore the functionally I'd had before, so that I could use the voice assistant to pause playback after a certain delay. But that means i had a working remote that i could skip around with, pause, play, and otherwise manipulate to my heart's content.
Except. There's one very annoying exception to the way this remote works flawlessly, and it's through my Internet TV provider. On any other site that offers media controls, including their wildly popular video hosting site, or even when I use the Picture-in-Picture controls that Firefox provides (it's beautiful and we love it and that by itself is a reason to use a Firefox-based browser), I can use the Skip1s to skip forward or backward, pause, play, and manipulate the position of the time of the broadcast. On the baseball site, I can control things so long as they're not in commercial, which disables skipping. (Unless it's in PiP, and then I can use the media controls present there to skip the commercials. Suckers.) But on the TV site, I can only use the remote to control the skipping when the controls are visible in the screen and the most has clicked on the screen recently. Once the controls go away, the remote can't do anything until there's another click to refocus and bring the controls back to the foreground. As a kludge, I'll bet the remote works perfectly when the TV program is PiP, but this particular provider has a habit of obscuring the PiP button with an overlay of whatever the next program it wants me to watch will be. We can get around the overlay using the keyboard shortcut for PiP, but I'd really just rather be able to control the broadcast without having to jailbreak it into a PiP window. If any of you have any insight into why the remote doesn't work as soon as the controls are out of focus, it would be appreciated. (It may or may not be related to the phenomenon where a large amount of skipping ahead by the increments provided in the controls well sometimes cause the broadcast to forget that it had just been happy with the keyboard presses or mouse clicks and demand the mouse click back into the broadcast window again if they want to continue fast-forwarding.)
In any case, you can see that sometimes getting things to work the way you want them to involves diving down a few Vittra warrens (or following a dog into Nisse space) and having to do a little work to get things to go for yourself. Which is, to some degree, expected when working with community programs and services. You always want not to have to do it, because it's much more likely for something to get widely adopted if it Just Works for everyone or nearly everyone, but if there are going to be edge cases or situations where someone has to roll up their sleeves and dive in to things, making it as easy as possible to achieve their goals is definitely recommended. (So don't skimp on your tutorials and documentation! It's not just people who want to examine your code who might have to install programs and use them as steps in a complicated dance to get your device to work with their specific setup.)
The first is to keep a backup of all of your crucial files, preferably off the machine that holds the main operating systems. I got a reminder of that recently when I upgraded my tablet and my phone to Android 13, now that there was an official release of Lineage for the tablet and the phone release was basically "there's something we'd have to fix to make it official, we don't have a clue how to fix it, so all the 13 builds will have to be unofficial until we get to 14 or we have a miracle and the problem fixes itself." The problem with version upgrades for Android is almost always that the launcher gets upgraded and that often means all of the icons, groups, widgets, and other such gets wiped in one way or another. So all of that work I'd done in post #8 about getting the daily wisdom formatted correctly and displaying in the Android widget? Gone. I was able to recreate some of it from memory, but I didn't have everything in place, and I hadn't copied the code snippet anywhere else I could find that I could use to cut and paste back in to the widget. After reconstructing the whole thing, and possibly refining it again, so that the regular expression replacements works with one statement that puts both the opening and closing emphasis tags around what's been captured and remembered, I have rebuilt the widget. And then promptly saved the code in a different place so that if the widget gets nuked by accident or some later upgrade, I'll be able to cut and paste back in to the next widget. I also learned about capture groups and how to reference them (because backslash is a metacharacter, to reference capture group 1 by using \1 in the regular expression, I had to do \\1 instead, to make sure that the backslash was escaped properly. It took me a fair amount of time to realize this, because sometimes the obvious eludes me. More on that later.) Ideally, I'd like to get that wisdom formatting down to one or two lines by combining the filter operations all together into one, but I'm not sure that I can do that. It uses the pipe character, but that doesn't necessarily mean it pipes in the same way, such that I could put all the regular replacement filters on one line and the regular expression filter on the next line.
That's reminding me that I should probably off-site the next Home Assistant backup I make in anticipation of an upgrade to the systems, or something. I don't know how much of it would still be necessary for the current paradigms in place, but better safe and having all of the elements in place I'd need to reconstruct it all than sorry and trying to reconstruct everything by hand.
Speaking of failing to notice the obvious, I used a little bit of birthday savings to purchase myself a pair of PineBuds, to see how they did, to hope that a really good open firmware gets developed for them to use, and to complement my PineTime. (Pebbles are still the champion of good smartwatches, but they got eaten by Fitbit, who in turn got eaten by Google. The PineTime does reasonably well for all the things I want a smartwatch to do, and they keep developing new and better things for it with each firmware release.) The current set of wireless Bluetooth headphones I had have a wire running between the two headphones, and I found it very aggravating the way the wire would not move with my head, such that when I turned my head, one of the earphones would pull against me, and I'd have to reset the position of the earphones and the wire. Plus, having something on the back of my neck like that was giving me some sensory No. The PineBuds were cheap enough to want to experiment with and see whether or not that kind of style was something I wanted. They arrived, and I was ready to get them to go to work, but they wouldn't turn on. They wouldn't light up, even though I made sure their charging cradle was properly charged. I was getting disappointed with them, worried that they might have been dead on arrival, and I was showing them to my partner and lamenting the possibility of getting a dud, when they said "Well, I'll remove the tape around the charging contacts," and proceeded to strip off the two strips of blue tape that were protecting the charging contacts during their shipment. Once the earbuds could actually make uninterfered-with contact with the cradle's charging spots, the earbuds lit up with charging immediately. So I let them, and once they had enough charge to turn on, they connected properly and I tested their ability to play music, and it seemed acceptable enough all the way around. We'll have to see how they do handling telephone calls and their single-earbud versions so I can have one earbud in and one listening to the world around me, but I stared at those earbuds for a very long time without noticing the tape. I might have discovered it, but it would have been entirely by accident. So, my partner gets to say to me that I owe them the proverbial $5,000—$1 for taking of the tape, and $4,999 for knowing it was there in the first place to take off. Always get a second opinion before you declare something's gone, right? Sometimes the way that another person sees the world will be exactly what you need.
And sometimes you just have to be clever yourself and deal with inadequate documentation and a lot of jank and bugginess in your situation. Which, in my case, involves the fact that another part of my birthday savings went toward buying a new universal remote. We'd been doing great with a Logitech Harmony device for a while, but the device we had has one button that's basically dead and another that's dying on the context menus where most of the remote functions exist. This wouldn't normally be such a problem, except Logitech is no longer making new remotes in the Harmony series, so it's not like I can buy a replacement remote from them. So, instead I got the Skip1s universal remote from the people who made the FLIRC USB infrared receiver, which I had bought almost immediately to use to drive my media center PC when in Kodi or other media-rich applications. The Skip1s is not the same as the Harmony, with only three profiles to work with, but it does allow for mapping in such a way that a single profile might control two or three devices at a time, such that I can have the power button control the screen, the volume buttons control the soundbar, and the remainder of the buttons control the FLIRC so that I can fast forward and skip around in media playback situations.
The first problem I ran into was that while the Skip1s's database of codes could work on my TVs and soundbar, and had profiles for making the FLIRC work, it didn't have anything for controlling the HDMI input switcher that I have as part of the setup. That's kind of an important thing in the whole scheme of it all, so things weren't looking great, but I discovered in a forum post that there is a way of activating an administrative console mode where new devices can be taught to the remote, so long as something has properly captured the codes. (Which, incidentally, made the Windows app much less stable, as in going from "crashes once every six openings" to "crashes five times out of every six openings." I wouldn't have used the Windows app at all, but the Linux AppImage provided kept throwing warnings about missing libraries that i suspect would have been found and covered on an Ubuntu system. That defeats the idea of an AppImage, though, they're supposed to be completely self-contained and distribution-agnostic. Furthermore, just to get the admin console part to work correctly, I had to run the "put this in your MacOS X console" command on one of my Linux machines so I could replicate the output on the Windows machine. Beta software, man.)
In the same forum post, there was a suggestion to use a software piece that would analyze IR signals and convert them to the correct codes to use for the remote. Sounds simple enough, right? Well, except the part where the software program itself doesn't know how to talk to the FLIRC and accept signals directly from it. Continuing to browse the forums, however, turned up that with a newer release of the FLIRC software and firmware, there was a command-line tool that would capture any signals sent to the FLIRC and output them in a specific kind of format to the console. So I ended up upgrading the firmware and software on the FLIRC machine, starting the capture program, going through all of the buttons on the switcher remote, annotating the file so that i knew which signals were attached to which buttons, and then realizing that I had no idea what parts of that were supposed to be input into a file so that the remote would recognize the switcher and it would work. I was pretty suspicious about the outputs of some of the signals, because they looked functionally identical in some spaces, even though they were supposed to be different buttons being pressed.
It took me quite a while to remember that the IR analyzer program would also accept a file as an input and could analyze the signals that way and convert the raw signal elements into the proper codes the remote would need to command the switcher. So i formatted the raw signal numbers into a file type the analyst program would accept, them had it convert the raw signal to acceptable codes, packages those codes into a file format the remote app would accept, and then taught the remote the switcher and assigned the various functions to appropriate buttons on the remote. Three profiles, one for each screen and one for the switcher, and the new remote was in business, but for one new problem that had cropped up - the FLIRC had stopped responding to command that should have worked on it before. What had happened?
Turns out the firmware upgrade had caused some problems, such that the FLIRC wasn't being properly recognized or controlled, which I only picked up on when I read some console logs and saw the error message. The actual program itself gave very little indication that it was having any trouble, other than the problem that pushing the buttons on the virtual controllers didn't do anything, either, even though it should have. Thankfully, once I had a useful error message to search against, the forums had a suggested solution to the problem of the device not being recognized, involving clearing out all the software, then installing fresh and seeing if things resettled themselves. Which they did! Although I then had to re-teach the other remote what the new correct commands were to restore the functionally I'd had before, so that I could use the voice assistant to pause playback after a certain delay. But that means i had a working remote that i could skip around with, pause, play, and otherwise manipulate to my heart's content.
Except. There's one very annoying exception to the way this remote works flawlessly, and it's through my Internet TV provider. On any other site that offers media controls, including their wildly popular video hosting site, or even when I use the Picture-in-Picture controls that Firefox provides (it's beautiful and we love it and that by itself is a reason to use a Firefox-based browser), I can use the Skip1s to skip forward or backward, pause, play, and manipulate the position of the time of the broadcast. On the baseball site, I can control things so long as they're not in commercial, which disables skipping. (Unless it's in PiP, and then I can use the media controls present there to skip the commercials. Suckers.) But on the TV site, I can only use the remote to control the skipping when the controls are visible in the screen and the most has clicked on the screen recently. Once the controls go away, the remote can't do anything until there's another click to refocus and bring the controls back to the foreground. As a kludge, I'll bet the remote works perfectly when the TV program is PiP, but this particular provider has a habit of obscuring the PiP button with an overlay of whatever the next program it wants me to watch will be. We can get around the overlay using the keyboard shortcut for PiP, but I'd really just rather be able to control the broadcast without having to jailbreak it into a PiP window. If any of you have any insight into why the remote doesn't work as soon as the controls are out of focus, it would be appreciated. (It may or may not be related to the phenomenon where a large amount of skipping ahead by the increments provided in the controls well sometimes cause the broadcast to forget that it had just been happy with the keyboard presses or mouse clicks and demand the mouse click back into the broadcast window again if they want to continue fast-forwarding.)
In any case, you can see that sometimes getting things to work the way you want them to involves diving down a few Vittra warrens (or following a dog into Nisse space) and having to do a little work to get things to go for yourself. Which is, to some degree, expected when working with community programs and services. You always want not to have to do it, because it's much more likely for something to get widely adopted if it Just Works for everyone or nearly everyone, but if there are going to be edge cases or situations where someone has to roll up their sleeves and dive in to things, making it as easy as possible to achieve their goals is definitely recommended. (So don't skimp on your tutorials and documentation! It's not just people who want to examine your code who might have to install programs and use them as steps in a complicated dance to get your device to work with their specific setup.)
no subject
Date: 2025-01-14 07:06 am (UTC)