![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
silveradeptThere hasn't been much done since the last set of automation work. Which means that I haven't discovered anything that would be improved through scripting or automation yet, or tried to do something that would require a significant amount of research to implement, like some form of free-floating "play this song" skill that would run a search and start playing the result through a selected speaker.
Instead, what's happened is a whole lot of people decamping from Twitter and moving to other spaces. Including a fair few people in the household, some of whom are maintaining a foot in a couple of different sites for when Twitter fully becomes more hassle than it is worth, a calculation that each person gets to make themselves.
So! With the establishment of some other accounts, an earlier project involving using a mantel light got replicated using the API of a completely different project. The general form was the same (retrieve the latest from the timelines of notifications and of posts, extract salient data, make a comparison). This API did not have a targetable meta component to find the id of the latest item, but it did have a limit where I could only ask for the very latest, and then extract the "created_at" attribute value from the JSON and make correct comparisons there as well, since the formatting of those elements allowed for apples to apples comparisons. Once both indicator lights components were confirmed working, I then set them to run on opposite time schedules, so that one of them would fire at every minute ending in 5, and the other at every minute ending in 0. The two have compatible color schemes to know which indicator is firing at the moment, and their mostly white indicators (i.e. the state when there are no notifications newer than the latest post) have the chosen notification color tinged into them to identify which site does not currently need attention. Since the indicators are now on a schedule of operations, rather than firing when the states themselves changed, we adjusted how often the APIs get polled and I set conditions so that when the lights turn out as a suggestion that we go to bed, the indicator lights do not light up again until the morning. It took a little work to set everything up, but once the data was rolling in and the color schemes chosen, there weren't really any issues other than the fine tuning parts and getting the scheduling properly set up.
Which brings us to the other indicator light, which I finally decided to set up for myself based on my own hedging on Twitter. But rather than provide the same dual-instance setup, I'm only looking for indicators on one of the microblogging spaces, which brings with it five different possible things a notification could be. Four of them are things I'm interested in knowing about, and so setting up the indicator lights meant choosing distinct hues of a single color (at least for me, it did) so that I could know what kind of interaction just happened by the tint of the color. (The other indicator light also got hues chosen for itself by the person who was going to be looking at it, since they were also working from the same API choices.) That part was pretty simple, since it was building on the previous work I had done with indicator lights. The new wrinkle was the possibility that I might receive multiples of the same type of interaction, and the way that I had the automation set up, if something new arrived that was the same kind as the last thing, there would be no change, because the automation was set only to fire when the type of notification changed. And unlike the dual-indicator setup that I had completed earlier, I'm not the kind of person who is very prolific on social media, such that it would be reasonable to assume that after receiving a notification, I would make some sort of post, and I could use the post as the comparison point for whether something was "new" or not.
The solution I came up with required paying attention to one more attribute of the API's JSON payload, the datetime string when the notification arrived, and comparing that to an internal method from Home Assistant, because all of the "sensors" have an "updated at" attribute that stores a datetime string when the value the sensor is monitoring changes. I changed the automation to fire when the datetime of the most recent notification changed, and finally wrote valid templating code on the first try to make a comparison between the newest notification's datetime and the updated at attribute's datetime. I assumed the sensor would update at the same time the value in the datetime changed, so I set the comparison for equality. If they were the same time (meaning the type of notification had changed, triggering an update to the sensor state), the light would change to the new notification type. If they weren't equal (meaning the type of notification hadn't changed, but the latest notification's datetime had), then the light would blink on and off three times, as a " same type, new item" notifier.
It turned out that the sensor updated itself first with the new information, and there was lag between what the sensor said was the latest notification's datetime and when the "updated at" attribute changed, so I had to change the comparison to an inequality, where if the notification's datetime is smaller (earlier) than the "updated at" attribute, that's the sign of a state change, and change the light to the new notification type's color. If the notification's datetime is greater (later) than the "updated at" attribute, that means it was the same type of notification, and the light should blink instead. And thankfully, since I could get both of those datetime strings to format to the same type of string, I can make useful comparisons between them!
I feel like this is a slightly more clever/programmer type of solution to the problem, since it didn't require asking for any additional data from the API call (the attribute I needed came in the JSON, I just needed to have something explicitly paying attention to it) and it used something built-in as a good-enough proxy, rather than trying to do something more complex. I'm pretty proud of having been able to think it through, test it, see the results, and, perhaps most importantly, not have to have bashed my head against the templating language to figure out what I was doing wrong. Sure, it's 95% recycled working code from other things, but why reinvent the wheel, right?
At some point, I'll come across something else that needs automating, or decide I want to try and do something clever again, and you'll get to hear about it. This one didn't use the voice assistant, but those are skills that I would love to be able to do more of, to voice-control complex reactions or pass in arbitrary things and have it understand. But that requires a lot more work than the simple thing that I'm using and enjoying as a local control device.
More adventures in home automation (or clever light projects) shortly!
Instead, what's happened is a whole lot of people decamping from Twitter and moving to other spaces. Including a fair few people in the household, some of whom are maintaining a foot in a couple of different sites for when Twitter fully becomes more hassle than it is worth, a calculation that each person gets to make themselves.
So! With the establishment of some other accounts, an earlier project involving using a mantel light got replicated using the API of a completely different project. The general form was the same (retrieve the latest from the timelines of notifications and of posts, extract salient data, make a comparison). This API did not have a targetable meta component to find the id of the latest item, but it did have a limit where I could only ask for the very latest, and then extract the "created_at" attribute value from the JSON and make correct comparisons there as well, since the formatting of those elements allowed for apples to apples comparisons. Once both indicator lights components were confirmed working, I then set them to run on opposite time schedules, so that one of them would fire at every minute ending in 5, and the other at every minute ending in 0. The two have compatible color schemes to know which indicator is firing at the moment, and their mostly white indicators (i.e. the state when there are no notifications newer than the latest post) have the chosen notification color tinged into them to identify which site does not currently need attention. Since the indicators are now on a schedule of operations, rather than firing when the states themselves changed, we adjusted how often the APIs get polled and I set conditions so that when the lights turn out as a suggestion that we go to bed, the indicator lights do not light up again until the morning. It took a little work to set everything up, but once the data was rolling in and the color schemes chosen, there weren't really any issues other than the fine tuning parts and getting the scheduling properly set up.
Which brings us to the other indicator light, which I finally decided to set up for myself based on my own hedging on Twitter. But rather than provide the same dual-instance setup, I'm only looking for indicators on one of the microblogging spaces, which brings with it five different possible things a notification could be. Four of them are things I'm interested in knowing about, and so setting up the indicator lights meant choosing distinct hues of a single color (at least for me, it did) so that I could know what kind of interaction just happened by the tint of the color. (The other indicator light also got hues chosen for itself by the person who was going to be looking at it, since they were also working from the same API choices.) That part was pretty simple, since it was building on the previous work I had done with indicator lights. The new wrinkle was the possibility that I might receive multiples of the same type of interaction, and the way that I had the automation set up, if something new arrived that was the same kind as the last thing, there would be no change, because the automation was set only to fire when the type of notification changed. And unlike the dual-indicator setup that I had completed earlier, I'm not the kind of person who is very prolific on social media, such that it would be reasonable to assume that after receiving a notification, I would make some sort of post, and I could use the post as the comparison point for whether something was "new" or not.
The solution I came up with required paying attention to one more attribute of the API's JSON payload, the datetime string when the notification arrived, and comparing that to an internal method from Home Assistant, because all of the "sensors" have an "updated at" attribute that stores a datetime string when the value the sensor is monitoring changes. I changed the automation to fire when the datetime of the most recent notification changed, and finally wrote valid templating code on the first try to make a comparison between the newest notification's datetime and the updated at attribute's datetime. I assumed the sensor would update at the same time the value in the datetime changed, so I set the comparison for equality. If they were the same time (meaning the type of notification had changed, triggering an update to the sensor state), the light would change to the new notification type. If they weren't equal (meaning the type of notification hadn't changed, but the latest notification's datetime had), then the light would blink on and off three times, as a " same type, new item" notifier.
It turned out that the sensor updated itself first with the new information, and there was lag between what the sensor said was the latest notification's datetime and when the "updated at" attribute changed, so I had to change the comparison to an inequality, where if the notification's datetime is smaller (earlier) than the "updated at" attribute, that's the sign of a state change, and change the light to the new notification type's color. If the notification's datetime is greater (later) than the "updated at" attribute, that means it was the same type of notification, and the light should blink instead. And thankfully, since I could get both of those datetime strings to format to the same type of string, I can make useful comparisons between them!
I feel like this is a slightly more clever/programmer type of solution to the problem, since it didn't require asking for any additional data from the API call (the attribute I needed came in the JSON, I just needed to have something explicitly paying attention to it) and it used something built-in as a good-enough proxy, rather than trying to do something more complex. I'm pretty proud of having been able to think it through, test it, see the results, and, perhaps most importantly, not have to have bashed my head against the templating language to figure out what I was doing wrong. Sure, it's 95% recycled working code from other things, but why reinvent the wheel, right?
At some point, I'll come across something else that needs automating, or decide I want to try and do something clever again, and you'll get to hear about it. This one didn't use the voice assistant, but those are skills that I would love to be able to do more of, to voice-control complex reactions or pass in arbitrary things and have it understand. But that requires a lot more work than the simple thing that I'm using and enjoying as a local control device.
More adventures in home automation (or clever light projects) shortly!
