Need assistance with MQTT_Eventstream

Configuration
1

Hello all,

I’m sort of new at this Home-Assistant thing, but I have dug deep into this and my HASS is expanding very rapidly. I’m looking for some help if someone can give me some advice. Here’s my issue.

I have two Rasp Pi’s running and one is set up as MQTT_eventstream master and other is slave. I have the communication working successfully, but I have run into an issue. Each time I trigger my cover (garage door), it triggers it on the master and then about 2 secs later, the slave also triggers it, so the cover opens/closes and then stops after 2 secs. I know it is the eventstream because I unplug the slave and the garage door works correctly.

Any suggestions/thoughts as to why the slave is mimicking the command? I can post code, but I’m not sure how everyone posts their code and it shows up in the nice Courier stand-out format.

Thanks.

2

Can’t help with the MQTT problem, but I can with the posting of code!

Select your code block so the whole thing is highlighted, then press the preformatted text button in the editor. I included an image to show you which button it is.

3

Thanks. Here’s the code thus far.

This is what’s in the MASTER PI.
script.yaml

open_garage: sequence: - service: cover.open_cover entity_id: cover.garage

mqtt.yaml
broker: 127.0.0.1 port: 1883 client_id: home-assistant-1 keepalive: 50 username: user password: pass birth_message: topic: 'hass/status' payload: 'online' qos: 1 retain: true will_message: topic: 'hass/status' payload: 'offline' qos: 1 retain: true

This is the mqtt_eventstream:
mqtt_eventstream: publish_topic: MainHASS subscribe_topic: SecondHASS

cover.yaml
- platform: mqtt state_topic: "home-assistant/garage/1/state" command_topic: "home-assistant/garage/1" name: "Garage" qos: 0 retain: false payload_open: "OPEN" payload_close: "CLOSE" payload_stop: "STOP" state_open: "OPENED" state_closed: "CLOSED" optimistic: false

4

This is what’s in the SLAVE PI:
configuration.yaml

mqtt:
broker: 192.168.1.68
port: 1883
client_id: hass2
keepalive: 50
username: user
password: pass

mqtt_eventstream:
subscribe_topic: MainHASS

5

I can’t help with eventStream, I’ve never used it. But I am curious about why you need two brokers on your local network?

6

I have turned both PI’s into IR blasters to turn on appliances (tv’s, receivers, etc.) and I have them in separate rooms to reach different equipment. I have managed thus far to establish ‘nested’ scripts over the eventstream (for example the script on the master is called Play_PS4 which executes the ps4-waker bash command) so that when the Play_PS4 script state turns to ‘on’ the the slave identifies and reacts by in-turn running it’s own internal script (called Play_Video_Games) that then execute a series of shell commands. The shell commands are LIRC irsend bashes to turn on all of my PS4 stuff. I have an Optoma projector and Pioneer AV receiver fully functional through LIRC on the slave PI at the moment and can run the entire system via a voice command on my Google Home. The ‘nested scripts’ (I’ll call it) over the eventstream has only been operational but a day or two when I noticed this above issue with my garage controller that I built.

Sorry to be so long winded and maybe there’s a less convoluted way to make this happen, but it was the most direct route I could ponder when I began down this path.

7

I think I understand the overall principle and goal of the MQTT_eventstream, but maybe we need to have a way to exclude: certain entities or domains.

8

I used eventstream but set slave as publish only
Master was set to receive and automate actions.

Sensor.entity was created on only 1of2 pi.
Group was used to display on other pi

I did have issue with GPIO temp sensors not showing up when page load(delayed until sensor reported) but never issue with circular automation firing

9

Eventstream is not widely used nor supported, unfortunately.

May I suggest an alternative: Install https://www.npmjs.com/package/lirc2mqtt on your PIs, and let home assistant publish to the configured topics, or subscribe, as the case may be.

I just set that up myself and it works great, without having to deal with additional HA instances.

10

I’m not sure I understand, or I’m not sure if this is the correct action for me. I’d like the slave to subscribe to the messages from the master so that I can have the master tell the slave to fire my shell_command scripts for LIRC.

I think your case is sending data back to the broker, opposite of my case which is pulling data from the broker.

I’m thinking maybe I should just go a different route. Do you think it is possible to use an MQTT switch component to send a command from the master to slave?

11

Hmm… Thank’s happyleaves. That’s interesting. So I wouldn’t need HA running on the second PI at all then?

12

Yes. Assuming all you want to do on the PI is send and receive IR. Your automations would live in your main HA instance.

13

Ok, so main PI just sends a mosquitto broker message to the mosquitto listener on the second PI. How does the second PI interpret and fire the lirc command? Is there a mqtt2lirc that has to be installed on the second PI then?

14

Is github having issues, or is it just on my end?

15

Not sure how your setup is exactly, but assuming PI1 is running HASS and PI2 is your remote …

PI1: HASS, MQTT
PI2: lircd, lirc2mqtt

Two flows:

PI1 -> mqtt.publish to lirc/set/<remote>/<button> -> PI2’s lirc2mqtt picks that up and transmits appropriate IR command per your lirc config

IR -> Received by PI2 -> lirc2mqtt publishes to lirc/status/<remote>/<button> -> PI1 has automation with mqtt trigger on that topic that does whatever.