Best architecture reading same Mqtt source on several Hassio's?

Third party integrations
1

HI,

Before I had 1 Hassio instance on a Pi, subscribing to the MQTT channel of my Z-Wave hub. Internal Mosquito on the Hassio. Setup the ip address of the Hassio Pi in the Z-wave hub.

I now have a second Pi with the new HassOS and like to subscribe to the same Z-Wave Hub.

Which would be the best way to do so? I can only se one MQTT broker in the Z-Wave hub, so guess need either of the Pi’s to be the one? Or should I try another configuration? Would like to prevent using an eternal client or even cloud, for obvious reasons of security and complexity.

Would it be possible to have 1 Pi subscribe to the other, which in itself is subscribed to the ZWave hub…?

Thanks for having a look,
Marius

2

Just pick a broker on either Pi and use that for all your connections. Disable/remove the broker from the other pi as it is not needed.

3

I havent yet installed mqtt on the new Pi, not knowing what to subscribe to…

My Pi 1 subscribes to the Zwave hub, but it doesnt publish those to be able to subscribe to from the new Pi 2?

4

I am sorry, I misunderstood. If you have a broker already running in a z-wave hub, then you do not need another broker in either Pi. Both can subscribe to the z-wave hub without any problems. Just make sure that they have a different client_id, as that is how the broker identfies the connection.

Just to be clear, you only need one broker in your network.

5

No, sorry, I think i caused some confusion…

Zwave hub publishes its event stream to the broker which is the native mosquito Add-on on Pi1.

I now want P2 to read those same events.

6

Not sure that you’re trying to achieve using two Hassio instances but would it be easier to use a couple of RESTful sensors on the second installation making work like a master slave configuration.

7

Then you need to get the P2 to subscribe to the broker on P1. Just use whatever address the z-wave hub connects to in the mqtt section

mqtt:
    broker: <ip address z-wave hub connects to>

But I agree with sjee, having two copies of HA running seems unnecessary.

8

you’re both right about the 2 HA copies. Thing is, I want an operational HA and an experimental one, on which I can test out new things, without breaking the operational instance, and having to explain that in the evening…

What would those rest sensors look like. i think the Master slave construction is what i was looking for indeed

9
10

Ah, now if I had known this, I’m not at all sure I would have given the same answers.:grinning:

I have a similar test set up, but I use a virtual machine as a test bed rather than second raspberry pi. On that I have a completely independent mqtt broker that doesn’t connect to any physical lights. I test things out by making sure that the correct MQTT messages are sent, and I simulate the devices by sending MQTT messages in. To my mind, that is actually one of the benefits of using MQTT as an interface.

This way nobody gets disturbed by things turning on when I am testing.

11

ok ill test this. Will the Mosquito P1 publish automatically, or do i need to enable a setting for that? And to port 1883? not sure if authentication is needed too? so many options…MQTT - Home Assistant

12

I think you need to put P2 in bridge mode. Take a look at this;

13

P1 will publish to the broker exactly as before. You should make no changes to P1.

Yes, unless you were very unusual and configured it differently in the mosquitto settings.

Again that depends on how you set up mosquitto, but it will be the same as your P1 settings

All the other options should just use the default, so you can omit them.

Having two brokers and bridging them is appropriate if you want to separate traffic, for instance if you want some traffic encrypted and sent to a location on the network - such as cloudmqtt. Doing that on a single network when you want all clients to communicate is unnecessarily complex.

14

im a bit confused I must confess.

On P1 i have mosquito installed.
use many sensors platform: mqtt of this type:

- platform: mqtt
  state_topic: 'mac_address/powerswitch-zwave/d1978523/usage'
  name: "Tester actueel"
  unit_of_measurement: "Watt"

- platform: mqtt
  state_topic: 'mac_address/powerswitch-zwave/d1978523/power'
  name: "Tester totaal"
  unit_of_measurement: "kWh"
  value_template: "{{ value | round(2) }}"

- platform: mqtt
  state_topic: 'mac_address/powerswitch-zwave/d1978523/state'
  name: "Tester state"
#  unit_of_measurement: "State"
  force_update: true

and control switches via the Api:

sw_tester_cl:
  friendly_name: Tester (cl)
  command_on: >
    curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"d1978523", "prop":"command", "value":"on"}}' http://ip_address/iungo/api_request
  command_off: >
    curl -X POST -d '{"seq":1, "method":"object_prop_set", "arguments":{"oid":"d1978523", "prop":"command", "value":"off"}}' http:///ip_address/iungo/api_request
#      command_state: >
#        curl -X POST -d '{"seq":1, "method":"object_prop_get", "arguments":{"oid":"d1978523", "prop":"state"}}' http:///ip_address/iungo/api_request
  value_template: >
    {% if value_json.rv.value == 'on' %}
    {{ true }}
    {% else %}
    {{ false }}
    {% endif %}

I create several other sensors, binary_sensors, threshold etc etc based on the data gathered with these. No further publishing at all.

On the Pi2 now, i have set the same broker, the one in the P1, and have now added the same switches and sensors in the configuration. They work flawlessly…

I seem not to understand how that can be … the P1 doesn’t publish anything, it merely receives the data from the Z-wave hub. the sensors have the mac address of the zwave hub and the command_line switches use the ip_address. So why would i need the broker in the first place…?
Ive tried to take out the mqtt settings on the P2, but that doesn’t work, so the configuration seems to be in order, its just that I don’t understand the architecture to its fullest.

15

I don’t understand this. A n MQTT switch in HA will send MQTT commands to turn on and off the switch, which is what P2 is now doing. Why are you controlling the switches with http commands?

16

Because my zwave hub won’t subscribe, and only publishes its events. Only way to control out of its own interface is through api calls.

P2 now does exactly the same as p1

17

Ah, I understand now. That’s an unusual arrangement, but it should all work fine.

If you want to disable turning things on and off in your test machine you can just change the scripts to add something to the log file instead of call curl.

18

thanks.

I want to change architecture though…

  • p1 to be the mosquito broker, and instance reading all hardware sensors (hue motion/light sensors, synology nas etc etc), and creating switches and sensors based on that hardware, as in my examples.

  • p2 using those and flipping the switches, reading the states etc etc.

Why would be needed extra on the p1 in the mqtt settings for that (thinking if the now not enabled discovery setting) and on the p2 to read the p1.

Would you be able/willing to show me an example of a p2 mqtt switch switching the tester switch i showed above?

19

I am afraid I don’t understand your question.

I am quite willing to help (I am intrigued by your setup) but I’m not really sure from your description exactly what you have and what you want to do differently.