Zha + mqtt eventstream/statestream


I’m trying to move my config from rpi3 to a nuc. All but my zha, because I’m using an elelabs shield. So, the idea is keep on the rpi3 only zha and controled devices, mostly lights. But here is the problem, as far I understand I can use eventstream to show zha devices on the main ha, the nuc one. But what about controlling zha devices from the main ha? I can’t turn on/off lights from the main one. How this can be achieved?


Ok, I get something working…

My main config is like:

  broker: !secret mqtt_broker
  username: !secret mqtt_username
  password: !secret mqtt_password
  client_id: primary
  discovery: true

  publish_topic: primary/eventstream
  subscribe_topic: secondary/eventstream/#

And the secondary:

  broker: !secret mqtt_broker
  username: !secret mqtt_username
  password: !secret mqtt_password
  client_id: zha_hub
  keepalive: 60

  publish_topic: secondary/eventstream/zha_hub

this makes entities on the secondary visible on the primary, its clunky, some entities appears and disappears without a reason… but there is another issue, the entity on primary is dummy, it display the state but does nothing if you interact with it, I mean, if a turn off a light on the primary nothing happen, not even a mqtt message is send… or at least I’m not seeing it…

So I ended up creating mqtt lights on the primary and handling the messages on the secondary with this automation:

- alias: Control lights brightness via MQTT
    platform: mqtt
    topic: +/+/light/+/brightness/set
    - service_template: >
        entity_id: >-
          {{ trigger.topic.split('/')[-4] }}.{{ trigger.topic.split('/')[-3] }}
        brightness: >-

there is some easier way to achieve this?

The secondary has to subscribe to the event stream of the primary in order to interact with the entities. However, there are more problems that arise when this is done. For instance, all sun events will happen twice unless you disable the sun component on the secondary.

All in all, it’s not a very elegant solution.

I once saw a custom_componet that would connect to another Home Assistant instance and relay specific aspects of it back to the primary. It worked well and was specifically designed with zwave and zigbee in mind, but I can’t seem to find it again today. A deep google search could probably make it turn up.

I tried with remote_assistant.py, but wasn’t working, probably is old and unmaintained…
I’ll try with secondary subscribed to the primary… thanks!

If that’s the component I was using, it only works with the primary subscribed to the secondary. The other way around, you’d have to manipulate all devices on the secondary, which isn’t what you want from what I understand.

I got this almost working… but still with a blocker issue… If I turn on/off a light on the secondary the primary properly reflect the change, I’m seeing the light change on the primary UI. But the other way around didn’t work, debugging mqtt on both instances I found that the primary is sending this call_service event:

2019-05-28 23:23:05 DEBUG (MainThread) [homeassistant.components.mqtt] Transmitting message on primary/eventstream: {"event_type": "call_service", "event_data": {"domain": "light", "service": "turn_on", "service_data": {"entity_id": "light.sengled_e11_g13_031346cf_1"}}}

and the secondary receives the event:

2019-05-28 23:23:05 DEBUG (MainThread) [homeassistant.components.mqtt] Received message on primary/eventstream: b'{"event_type": "call_service", "event_data": {"domain": "light", "service": "turn_on", "service_data": {"entity_id": "light.sengled_e11_g13_031346cf_1"}}}'

but nothing happen, if I’m not wrong this should be handled by this line https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/mqtt_eventstream/init.py#L92
so, should I consider this a bug on mqtt_eventstream? in the core? or maybe I’m still doing something wrong?

I think that I tracked the issue down to zha.light… maybe the implementation of light_on is wrong there, and that could be the cause for remote_assistant.py didn’t working neigther…