I recently set about seeing what solutions I might have for surfacing information about my Windows desktop PC to HA so that I can track things like “idle state” as a proxy for me occupying my desk etc. I’ve used tools like Eventghost in the past for this sort of use case but I got to thinking that there has to be some modern HA native solutions out there, and I was right!
What I wasn’t expecting is that there’s like 5 solutions out there, most of them no longer being developed. Here’s a short list I came up with for Windows desktop integration:
Home Assistant - Desktop - Dev last active about a year ago, Electron based and pretty heavy for a background service
System Bridge - Kicked tires on this only to find that the current release doesn’t seem to surface idle state. A version 4 is in the works, no word on release date. Also sends cursor into a spinning animation every 15 seconds or so and dev response is to just change your mouse animations so you don’t see that.
And of course there’s the good old EventGhost which is now so far out of development that it appears that literally nobody knows how to wrangle a working build together today (not kidding). Source is out there but there’s little chance of any further development as several hopeful maintainers have jumped in and eventually given up.
Great datapoint and good to know, however I’m concerned that the project is on life support. This is important because the core HA project loves to release breaking changes, so picking up an integration that isn’t able to react to the next round of breaking changes means any work invested here might have to be tossed to the side for yet another solution.
That’s why I’m keeping an eye on developer activity with this research, it’s here as a proxy for “can I expect this setup to work for a year or three”. I know for experience that integration with Home Assistant isn’t a one-time thing, you need to keep the solution updated in order to track with the changing whims of the core project.
… it uses MQTT discovery, which historically hasn’t had any breaking changes and I highly doubt there will be any breaking changes for in the distant future.
I haven’t updated hass agent in ~3 years, I just use it for hotkeys which uses websockets. Still chugging along.
There’s no reason to be afraid of abandonment. This is open source, par for the course. Especially when hass agent takes less than 5 minutes to set up.
You posted this thread just 5 months ago, and I’m currently wrapping up an update to my own project in order to align with the breaking changes in MQTT discovery announced then. As always, you were there to help me understand these changes, but my project would be dead in the water in a couple months here if I don’t re-write the firmware and push it out to my users in response to this change.
It for sure happens, and not infrequently. It’s fine if the developer is engaged and responding, but as we can see from the list above, that’s not the situation for a lot of these projects.
Yes, but that doesn’t break anything . Even if left un touched, it will still work. It’s listed as a breaking change because when you first set up the program it will create entity_id’s w/ double device names in the enitity_id and the name itself. Which (pretty sure I already described this to you) will not impact existing entity_id’s that were already discovered or overridden names. That breaking change is one of the most over conflagrated changes HA has ever had, and it’s largely due to users not understanding how it’s breaking. It literally just doubles the visible name in the UI and the initial auto-generated entity_id when first set up, nothing else.
… and the rest of my project relies on being able to predict those names, which it no longer could do. Again, this is all fine and I was able to get it fixed with your help.
However, it needed to be fixed because the project would no longer work without the fix. Breaking changes have happened a lot less frequently (thank goodness) but they still happen and we don’t have to go too far back in history to find plenty of examples.
As a developer of things that integrate with HA, I’ve come to accept the fact that the core team will break things at will and then expect everyone around the ecosystem to react. This is OK if the rest of the ecosystem is online and pushing updates in response.
So that’s the point of this thread - I will be investing a lot of work into this setup, I’d like to do it once if possible, and am looking for a solution where a developer is actively engaged so that I’m not in the position of having to spend a lot of maintenance cycles on the project. I’m sure many of the solutions listed above are fine today and work like they say they should, but I’m less sure that this will be true in 6 months. If possible, it’d be nice if I could avoid stepping on that future landmine by making The Right Choice here today.
That’s not true at all. The names remain the same. This just shows me that you still don’t understand the change.
Yes because you’re providing the discovery information. Regardless that does not impact anything for hass agent. You can still use it even if they didn’t adapt to this change. You’ll just have double names and entity_ids, which you can change yourself manually if you don’t like it.
It wasn’t the core team. You need ot understand that HA is mostly comprised of volunteers. You and a few select other people still do not understand this and you need to get over it. Open source is open source, it’s managed by the core team but mostly developed by random people.
Then you should come up with a solution yourself that doesn’t rely on another project. Things are abandoned all the time, it’s par for the course with open source and even python. At my work, I used a openopc library circa 2004ish python library all the way to 2020 that was abandoned in 2008. Windows continuously made it fail to work between 2008 and 2020 with it’s admin/permission changes to dcom. I had to learn how to make it work over that time, to no fault of anyone. It’s just how programming works. If you can’t deal with that, open source may not be for you. Even with paid solutions, you have to deal with changes like these. You may not be used to this, but this is very prevalent in software regardless what other people say on this forum. I ended up switching to a new lib that was created in 2016 in 2020 for opc. That was deprecated in 2022 for the async version of that lib. I’m still using the 2016 one… Again, all examples of real world applications where this happens.
All understood. I feel like we’re going way off course for the request in the OP so let me just respectfully suggest that I disagree, and I instead think that developer involvement is important for HA integrations over the long term for my own use case.
The good news is that everyone has a lot of options in front of them, I’m simply here to lay out the rationale behind my own decision process, and looking for solutions which align.
If you don’t agree with my decision process, that’s fine, but it’s not helpful.
I’m just telling you that you’re wasting your own time by having these self imposed rules. Use what’s available, adapt when it breaks. The best option at this moment for anything windows is HASS agent.
Anyways as a side note to your other issue, you can use templates to get to any entity_id from the device_id or integration. If you add manufacture info to your MQTT discovery that points to your ‘stuff’ in some way. You can easily use templates to get to the entity_ids without even needing to know what the entity_id’s are.
e.g. I have a few blueprints that I use for myself that abuse MQTT discovery. I populate the device information (author, manufaturer, etc) in a way that I can use templates to get back to the entity_id if I decide to change it.
You can use device_attr function/filter w/ 'manufacturer' to get to that info. Also selectors for blueprints can look at that information too.
Lastly, you can suggest a entity_id without the name or device name impacting your entity_id if you really want to be lazy and avoid everything I just said. Just add 'object_id': "abc_xyz", to your discovery info and it will create your entity with the entity_id of your choice. I do this as well in places and purposely don’t attach a unique_id to the entity so that users can’t change the entity_id. The only downside is if the entity shares the same name as another entity, it’ll get an _2 appended to it. So choose the object_id wisely.
Thanks again, your insight on how all this works has informed my upcoming release and that project will be better as a result. I do really appreciate it.
Monkeying with the older HASS.Agent release and I note that it’s throwing errors for MQTT discovery for the issue outlined above. As the developer is offline it won’t technically break things but it’ll instead be logging errors until forever because it won’t be fixed. Also, no virtual desktop sensor (which the new v2 project has but also is broken to the point of crashing every time you switch desktops).
Search is over! A new team has picked up development on HASS.Agent and the latest release was created in response to my virtual desktop issue. Everything is fast, works like it should, no more crashing, and scratches all the itches. Bonus points for an active and engaged development team moving forward.
. Even if left un touched, it will still work. It’s listed as a breaking change because when you first set up the program it will create entity_id’s w/ double device names in the enitity_id and the name itself. Which (pretty sure I already described this to you) will not impact existing entity_id’s that were already discovered or overridden names. That breaking change is one of the most over conflagrated changes HA has ever had, and it’s largely due to users not understanding how it’s breaking. It literally just doubles the visible name in the UI and the initial auto-generated entity_id when first set up, nothing else.