Subscribe and unsubscribe from HA events dynamically

I have the idea of creating a dashboard with a few screens, each showing states and controls for some HA entities.

The initial plan was to use HA WebSockets API, but it has no filtering by entity, and listening for all change events of ESP32 isn’t the best idea. The second idea was to use ESPHome, as it already supports subscribing to events per entity, but it lacks unsubscribe.

Imagine I have 10 screens. When the screen is switched, the code performs such actions:

  • Unsubscribe from events of a previous page (optional, we may still listen to events of the parent page).
  • Subscribe to change events for the entities on the current page.
  • Get the states of the entities on the current page.
  • Display the UI.

Theoretically, I can subscribe to events of all entities used on the dashboard and track states even for inactive pages (it’ll speed up screen switching, as the data is already here), but it’ll drastically increase network traffic.

Do I miss some better options? Has someone already tried similar approaches?

What about Openhasp?

1 Like

Don’t get me wrong, it’s a great project, but the UI is so… outdated. However, it is worth checking how they implemented those subscriptions.

Do you have any particular limitations in your infrastructure? Typically we have high speed networks at our homes which are mostly north of 100Mbit/s for wired and wireless devices. Some early adopters might having a infrastructure for blasting 2500Mbit/s thru wires and the double (or more) wirelessly (WIFI 5/6/7). :signal_strength::rocket:

Not utilizing the infrastructure installed is a little odd - as you probably also don’t bother dowscaling your 8K/4K/HD video streams to 380p as the higher quality “drastically increase network traffic” :man_shrugging:

Beside when you use the native api it should be more efficient (smaller payloads) than mqtt (which was made/designed for low speed networks anyway). :snail:

Afaik the communication between HA and esphome nodes via native api works via push - so no polling included but states are only send if values are changed :ok_hand:

Yes. :+1: Sounds like the way to go :running_man:

Or in other words: It might use (a fraction :warning:) of your local high speed network you payed for which would just idle otherwise :wink:

orange-assistant, maybe you are right. I have more than enough bandwidth (2.4 GHz WiFi is used almost exclusively for IOT devices, and 5 GHz for laptops, smartphones, etc.). It just sounds a bit non-optimal from the architecture perspective.

I’ll do a POC using the subscribe to all dashboard entities approach and see how it goes.

Does it? For me it sound about the best it can get. Alone having local push thank’s to the native api :trophy:

:+1: Keep us posted. I expect that it will “just work :tm:” and that your network traffic increases less in a whole day than when you would watch only 10 seconds of a 4k stream instead :wink:

MVP works well (ESPHome subscribed to more entities than shown on the screen):

However, changing it into a config-driven dashboard looks quite challenging =D
But this is a separate topic for discussion.

1 Like

nice dashboard.
What hardware are you using?

Thanks. I’m currently working on a fully configurable version.
The device is WT32-SC01 PLUS.

I thought the WT32-SC01-PLUS did not work with ESPhome due to its parallel LCD interface. I am using an older WT32-SC01 to experiment. I have a PLUS that I would also like to use. It should refresh faster.
Is ESPhome running on the display’s ESP32 or you just program it from scratch?

BTW, I came across this topic because I am also looking for a way to dynamically subscribe to MQTT topics.
Take care.

Yes, if you are talking about native display support - it doesn’t work. Despite ESPHome being a great project, display support is not its strong suit (maybe it’s just an initial impression, as I don’t have much experience with ESPHome yet). I’m using the LovyanGFX library in the component.

About subscription and unsubscription: I retired that idea, knowing all states (for selected entities) at any moment have their own benefits.

Thank you for the lead. I will check the library.

I think I am hoping to have a configurable dashboard so I have one firmware and then I can choose what I display. My use is display only.

Let us know how your project continues.
Thank again for mentioning LovyanGFX .

Edit. Sorry I just realized I already posted this recommendation. Still valid though.

You guys may want to look at openhasp. Good integration with HA and LVGL support.

I’ve just released the code: GitHub - strange-v/ha_deck: Config-driven Home Assistant dashboard (built on top of ESPHome)


I’m a big fan of your project. Beautiful UI and very fast. I was wondering, if you plan to integrate an media player or spotify widget?

1 Like

I’m glad that this project is useful for you. No immediate plans about adding either of these. I had thoughts about adding Spotify in some way, maybe using REST API, but it’s not a priority for now.

The main goal now - completing HA Deck v2, which brings styling support and other useful things. And frankly speaking, it moves much slower than I’d like (not due to technical complexity, but lack of enthusiasm, probably).

Thank you for managing my expectations. Haha.
The project has huge potential. I was playing a lot with ili9341 displays, but having a fast display with a nice UI supporting LVGL is a different story.
Anyway, I’m looking forward to your next release and I will wait. :smile:

The demo video has a media card interface shown.

But openhasp may suit you.

1 Like

BTW, yes, the solution from the demo video might be an option, @brix29.

It isn’t a separate widget but a set of buttons, each configured to call some HA service. I use that screen to control a Philips TV (only basic things: volume, play/pause, power).

Thank you, @nickrout, @strange_v. I just like the design of the HA deck very much. :sunglasses:

Based on the value card, I tried to develop a “new” value card with two text sensors. My attempt involved replacing the “text” with another value from a sensor, but I unfortunately it was much too complex for me.

Having a value card that incorporates two sensors would be fantastic, offering a great deal of flexibility. For example, in the case of the MediaPlayer:

Value: song title
Text: artist

Would adding this functionality be challenging?