Added mqtt_statestream component#9286
Conversation
|
|
||
| hass.bus.async_listen(EVENT_STATE_CHANGED, _event_publisher) | ||
|
|
||
| hass.states.async_set('{domain}.initialized'.format(domain=DOMAIN), True) |
There was a problem hiding this comment.
Hi, @pvizeli - I've removed the 'initialized' state.
|
Is there any reason why you can't use https://home-assistant.io/components/mqtt_eventstream/? |
Hi, @lwis - the mqtt_eventstream component works really well for linking together Home Assistant instances, or in cases where I want to look at a lot of different entities or events. However, for cases where I'm just interested in getting updates for one or two entities, it's a bit of a firehose. I have to process each message to see if it's one I'm interested in, and on low-power devices like Arduinos or ESP8266-based boards, it's not efficient. The mqtt_statestream component lets me just subscribe to the particular entities that I am interested in for that particular device. A real-world example from my setup - I have a small panel in my kitchen with 6 addressable LEDs and an ESP8266 controller. The controller subscribes to the entities for my locks and garage doors, and shows the current locked/unlocked status for everything. I know I could rework it to be 'push' based - have Home Assistant control the LEDs and use automations to flip them, but I prefer the other way. I hope that answers your question... |
|
I like the idea of creating the topics from the entity ids. |
|
I'm wondering if this should be a different option for eventstream to avoid overlap, but if it's purpose is to link HA instances then it conflates the component. I've always preferred discrete topics, because you can always wildcard to get the 'firehose'. |
|
I thought about adding it to eventstream, but I can see wanting to use both modes (in fact, I am using both right now...) |
|
This PR pushes in the same direction as #1518 was. I see that splitting state updates to different topics could be useful for a specific use-case. |
|
Hmm, I don't like the overlap as this can also be fulfilled by an automation that is triggered on all state changes. Maybe this should use case should remain as an automation/custom component as I feel a breaking change (as much as I agree with it) of the eventstream component could be disruptive. |
|
Not sure what you mean about breaking change to eventstream - this is a completely separate item. And I suspect that a large percentage of current components could be handled by an automation, but I think having an actual component makes it a bit more user-friendly. Not a big deal - I am fine keeping this in my tree. |
| return | ||
|
|
||
| topic = base_topic + new_state.entity_id.replace('.', '/') | ||
| mqtt.async_publish(hass, topic, payload, 1, True) |
There was a problem hiding this comment.
Use hass.components.mqtt.async_publish(topic, payload, 1, True)
| topic = base_topic + new_state.entity_id.replace('.', '/') | ||
| mqtt.async_publish(hass, topic, payload, 1, True) | ||
|
|
||
| hass.bus.async_listen(EVENT_STATE_CHANGED, _event_publisher) |
|
I think this is a great idea 👍 |
|
This is huge, because the way that mqtt_eventstream works is an anti-pattern for MQTT. Having everything broken out into individual topics allows the broker to (optionally) retain messages for each state, allows clients to selectively subscribe to individual states (and hopefully attributes at some point), and doesn't create enormous 1k+ JSON objects which can be difficult for embedded systems with limited memory to handle (the entire purpose of MQTT, and something which the commonly-used library PubSubClient struggles with). |
9 participants
Description:
This PR adds an
mqtt_statestreamcomponent that publishes state changes to discrete MQTT topics. My use case for this is that I have a number of external systems (including small ESP8266-driven displays) that need to monitor only certain entities. With this component, I can subscribe those displays only to the topics that they need instead of the whole event stream.For example, with a
base_topicconfigured ashass/states, turning onlight.master_bedroomwill publishontohass/states/light/master_bedroom.Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.io#3302
Example entry for
configuration.yaml(if applicable):Checklist:
If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
toxrun successfully. Your PR cannot be merged unless tests passREQUIREMENTSvariable ([example][ex-requir]).requirements_all.txtby runningscript/gen_requirements_all.py..coveragerc.If the code does not interact with devices:
toxrun successfully. Your PR cannot be merged unless tests pass