Home Assistant integration

[gensyn]

Hi, I'm working on connecting Stream Deck UI to Home Assistant and it's looking pretty good so far. Is anyone else interested in this integration? If I create a pull request, would it be merged (provided all formal criteria are met)?

In my first draft I'm supporting the domains light, switch, input_boolean and media_player. For each button you can select an entity from those domains and a service from the entity's domain to be called when the button is pressed.
Do you have other ideas/wishes what should be possible regarding Home Assistant?

Thanks.

[gensyn]

I'm specifically asking about a pull request possibly being merged because there are several open PRs containing nice features, some open for over two years. So any feedback by the owners would be welcome

[julian-hoch]

I am not the owner, just a user. I managed to control my Philips Hue lights via the 'hueadm' command, which works well enough, but of course you have to figure out the exact group and scene ids and put it manually on the button. What exactly was your plan, would this include a change to the UI and/or some automation?

[gensyn]

I establish a websocket connection to Home Assistant and load available domains, entities and services. For each button you can then pick a domain, and an entity as well as a service from that domain to be called when the button is pressed. This obviously only works with services that do not require further data, but it's a start. The button automatically gets the icon of the entity from HA and changes the color based on the entity's state (gray for "off", yellow for "on" if applicable). The websocket connection registers itself to be notified when the entity state changes in Home Assistant so the icon can be updated. I'm doing all this from inside Stream Deck UI; no changes to Home Assistant are necessary apart from enabling websocket_api in the configuration.yaml. This means there are several UI changes to Stream Deck UI: There will be a new Settings Dialog to enter URL/Token/Port/SSL for Home Assistant and the options for buttons are expanded to include HA domain/entity/service.

I'm rewriting a lot of the code in my fork because I didn't like the generated code for the UI classes. I'll post here when I have pushed a working version.

[dodgyrabbit]

@Gensyn The main concern here is that there is already a very large fork of this code base that needs to be integrated. Complex PRs built on top of current master is basically not going to be merged.

If you can keep it seperate (i.e. completely different form with minimal changes on existing code), then it may be possible down the road.

Generally speaking, the simpler the PR the more likely I can take a look. This is a side project that I don't have a lot of time to spend on unfortunately. The bit of time I have, I often spend on trying to help people, answering questions and just keeping things afloat.

With regards to the UI classes - while it's perfectly acceptable to generate the code by hand, this project was originally created (not by me) with a specific workflow in mind:

• Design your form using Qt Designer
• Use the /scripts/build_ui.sh to "compile" the UI
• Use the /scripts/lint.sh to ensure all standards are adhered to.
• Fix up issues
• All of this is also managed using Poetry

I'm explaining this - because if you manually start making UI changes the the produced Python classes, they will simply be incompatible with the workflow above and will be overwritten next time the UI is built.

FYI In the branch that I've slowly been working on - there is a whole extensibility mechanism where you can build your own UI for settings and other interactions.

Again, due to time constraints, I've put those efforts on ice for now and focussed on just keeping this project alive as libraries and operating systems that it depends on get updated.

The other consideration is that in order to be more flexible down the road, the format of the settings file had to change. I'm still not 100% sure I'm even happy with the way I've done it.

So what does this mean for you? Merging complex changes now will make life very difficult down the road to merge my own, already created branch, back in. What would really help is for you to figure out how to keep things out of the core code with the goal to later integrate it better. Makes sense? Separate settings, separate UI etc. We may throw a button in there somewhere to hook things up for now.

[gensyn]

Yeah, time is always an issue. But what I gather from this is that creating a PR now or adapting my code to the current master is pointless because my PR won't be merged until your major changes are pushed. So for now I'll stay in my fork and go hog wild; when you eventually push your changes I can still try to create a PR. Though I have to reiterate that I don't like generating code and I don't think any UI is ever complex enough to warrant it. Out of 397 lines of code in ui_main.py I deleted 160 lines without losing any functionality; that's 40% bloat. Using the generator also limits your design choices because you can't put code in classes where you logically should.

Example: The function _deck_id(ui) in gui.py uses the UI to get the deck ID. Logically this function would (in my opinion) better fit in ui_main.py but you can't generate that function.

In my fork I'm redesigning these parts to make more sense to me. I can still later create a PR just for the Home Assistant stuff but maybe you would like to take a look at my fork when I'm finished - maybe you find some changes you like...

That being said, thank you for your work!

[gensyn]

If anyone's interested, I pushed my changes to my fork and I'm pretty happy about how I can now control Home Assistant.

[StayPirate]

Hi @Gensyn, can you provide a guide about how to use your fork? I'll be happy to test it. I'm currently using hass_cli in streamdeck-ui to control HA. But of course, it can't handle icon states.

Here a small example about how I'm currently use it.

"12": {
    "command": "hass-cli service call scene.turn_on --arguments entity_id=scene.test_synthwave_scene_studio",
    "text": "",
    "icon": "/home/crazybyte/.config/streamdeck-ui/icons/synthwave.jpg"
},

[gensyn]

Hi @StayPirate, I added a small guide at the top of my README. Let me know if you run into any trouble.

[bcdonadio]

I would go for MQTT personally. In fact, that's what I will be implementing in the next weeks. It's agnostic of home control system or even anything related to home control (except for the auto-discovery bits, which is basically solved with a few templated JSONs) and feedback comes basically for free, you just need to subscribe to a return topic. This could possibly be done all in BASH if feeling particularly distasteful today.

It's so generic that it has the potential of being mainlined, and even if it's not you can probably get most of the desired functionality just by interacting via the mosquitto CLI if you don't want to commit to a fork.

[coolapso]

hi, this project seems to be stale and a new fork as been made with the intention of replacing this one.

if this still an issue please reopen it at: https://github.com/streamdeck-linux-gui/streamdeck-linux-gui