Homeassistant MQTT Discovery

[yozik04]

Would be great to have.

[BenjiU]

Whoa, this sounds crazy :-D Is there anyone, who has knowledge about this topic/system?
https://www.home-assistant.io/docs/mqtt/discovery/

[yozik04]

Nothing crazy there. Just one additional retained mqtt post with config. If I will make this project work on my Orange Pi I can get my hands on this.

[flyte]

Very interesting! It'd be great to implement this. I haven't come across it before, but I did design the topics for this project to be in line with ones used with Home Assistant.

If I will make this project work on my Orange Pi I can get my hands on this.

Looking forward to seeing what you come up with @yozik04! Shout if you need any help or want to discuss the best way to handle the configuration or something.

[kollokollo]

Good Idea. This way all the devices could be listed with a simple "mqtt-list-topics".

[dpritt]

This will be a great additional feature, and bring this great bit of software in line with my ESP8266 devices, they auto-create in Hass.io
Has this been implemented in the 0.5.0 release, or is it still work in progress, I notice some extra code relating to home assistant, but I am not seeing any discovery messages being sent, do I need to put something in the config file as I do with Tasmota devices to trigger off the discovery method?

Thanks to yozik04, as I have been trying to work out how to do this and failed!

[flyte]

Yep, this has been merged and released in 0.5.0, but I haven't actually configured my own one yet to test it out (a bit backwards, I know). Once I've done that I'll update the readme, but it looks like you just set the following in your config:

mqtt:
  discovery: yes
  # The following is optional (homeassistant is the default)
  discovery_prefix: homeassistant
  ...etc

Please try it out and update this issue with feedback if you can.

[dpritt]

That was the magic bit I was missing. Just tried it and Hass.IO discovered the device, it named it MQTT GPIO, as I have several devices is there a way to set this to a more meaningful name, like 'Heating Controller' or Irrigation' etc.? David

>> On 26/02/2020 at 15:33, in message ***@***.***>, Ellis Percival ***@***.***> wrote:

Yep, this has been merged and released in 0.5.0, but I haven't actually configured my own one yet to test it out (a bit backwards, I know). Once I've done that I'll update the readme, but it looks like you just set the following in your config: mqtt: discovery: yes # The following is optional (homeassistant is the default) discovery_prefix: homeassistant ...etc Please try it out and update this issue with feedback if you can. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. -- This email was Anti Virus checked by Astaro Security Gateway. http://www.sophos.com

[flyte]

Ah, good feedback. I've just pushed a new version 0.5.1 which includes a new config line:

mqtt:
  discovery: yes
  # The following is optional (homeassistant is the default)
  discovery_prefix: homeassistant
  # Optional too, but change to whatever you like
  discovery_name: MQTT GPIO
  ...etc

Please give that a spin.

[dpritt]

That did the trick, makes this a superb bit of code to use with my Pi Zeros and Hass. Many thanks. David

[dpritt]

I have been doing some more testing and have found a strange situation on one of my devices. This Pi has a GPIO input set as follows, as the input goes low when on I have inverted the call. - name: hot_water module: raspberrypi pin: 26 on_payload: "OFF" off_payload: "ON" pullup: yes pulldown: no retain: no This is sent correctly as part of the MQTT message when I check in MQTT Explorer, and shows OFF when the program is run and pin is high. But Home Assistant shows the entity it creates as ON. everything is reversed, I have cleared and reset the system several times and it is always reversed. I think the issue is the discovery message sends the payload settings (which I have reversed), so reversing them again, {"name": "hot_water", "unique_id": "pi-mqtt-gpio-b4baea8f_raspberrypi_input_hot_water", "state_topic": "heating-mgr/input/hot_water", "availability_topic": "heating-mgr/status", "payload_available": "running", "payload_not_available": "dead", "payload_on": "OFF", "payload_off": "ON", "device": {"manufacturer": "MQTT GPIO", "identifiers": ["mqtt-gpio", "pi-mqtt-gpio-b4baea8f"], "name": "heating-mgr"}} I rem'd out the two lines in the code, cleared the integration in Hass, and then restarted Hass.io and then the Pi, this is now reporting correctly. David

[yozik04]

It actually should send payload_on and payload_off so hass would know how to determine them.

[dpritt]

I agree it should be set, but if you read my earlier posting you will notice that I have reversed the sense of the settings on the PI as my GPIO pin goes low when 'ON'.

This sends the correct msg via MQTT, a Low Pin sends 'ON' as it should do.

But Hass reads the configuration sent and sees the reversed settings and flips it back again, a double-negative, so in the States panel (and Lovelace) a 'ON' MQTT message is reversed to show as 'OFF'.

Try this out for yourself.

David

[yozik04]

I got your point. If I won’t send it then there will be an other problem. Maybe some new parameter for fliping?

[dpritt]

I think it would work if you don't read the .yaml file but always set them as default values expected by Hass, the flipping is then done by the config file.
"payload_on" : "ON",
"payload_off" : "OFF",

[yozik04]

@flyte @dpritt has a valid point. It is very easy to change it for you. I do not think a pull request is required.

[flyte]

I wasn't sure if hardcoding the payloads would work if someone wanted to change the payloads away from the default values, so I've added an inverted config line to the digital_inputs section as such:

digital_inputs:
   - name: hot_water
     module: raspberrypi
     pin: 26
     on_payload: "ON"
     off_payload: "OFF"
     inverted: yes
     pullup: yes
     pulldown: no
     retain: no

@dpritt would you be able to test this out by pulling the develop branch please?

[dpritt]

Ellis,

The changes you made work a treat, the test switches I created are correctly created in HA, and the logic works.

However do you need to now include the default settings for on_payload and off_payload in the configuration file, it could get confusing. These should be sent as defaults and you only need the' inverted:' line now in the configuration yaml.

As well as the toggle switches I have also tested a button using the interrupt_payload: "trigger" option.

A normal Binary_Sensor entity is created in HA, but it does not respond to the MQTT message as this expects ON or OFF'.

For a button to work we need to use a 'MQTT Device Trigger' as outlined here https://www.home-assistant.io/integrations/device_trigger.mqtt/

This needs a 'type' setting up in the discovery module, there are a number of options available, but the default has to be 'button_short_press'.

This 'type' could be added to the configuration yaml to allow the user to select one of the HA defined types.

The 'hass_announce_digital_input' code would need to detect this and sending the relevant discovery message as shown in the HA documentation.

Currently I cannot find a way to use buttons with hass and pi-mqtt-gpio.

David

[flyte]

However do you need to now include the default settings for on_payload and off_payload in the configuration file, it could get confusing. These should be sent as defaults and you only need the' inverted:' line now in the configuration yaml.

Indeed, I just included them in my comment for completeness.

This 'type' could be added to the configuration yaml to allow the user to select one of the HA defined types.

Yeah, I suppose that could be added to the digital_inputs config section. Something along the lines of:

digital_inputs:
  - name: button
    module: raspberrypi
    pin: 26
    interrupt_payload: trigger
    ha_type: button_short_press
    pullup: yes
    interrupt: falling
    bouncetime: 200
    retain: no

I probably won't get round to this this week, as I'm a little busy, but PRs are of course very welcome.

[a-x-]

hey, can we already use ha_type for triggers?

also, ha mqtt receive ON as a trigger payload by default.
And ha expect OFF trigger too. Say, I have an pir motion sensor, and config with interrupt: raising.
When trigger detects motion, HA will set state as detected and will keep it forever because no clear input (OFF payload) will receive.

Maybe you can create special trigger with regular on/off_payload options w/o separate interrupt_payload that will be interrupting on rising as on and falling as off.

It’s must have because I cannot create two triggers: falling with OFF payload and raising with ON payload with the same name.
So I cannot use triggers with HA

[Kosh42]

hey, can we already use ha_type for triggers?

also, ha mqtt receive ON as a trigger payload by default.
And ha expect OFF trigger too. Say, I have an pir motion sensor, and config with interrupt: raising.
When trigger detects motion, HA will set state as detected and will keep it forever because no clear input (OFF payload) will receive.

Maybe you can create special trigger with regular on/off_payload options w/o separate interrupt_payload that will be interrupting on rising as on and falling as off.

It’s must have because I cannot create two triggers: falling with OFF payload and raising with ON payload with the same name.
So I cannot use triggers with HA

Fix this in home assistant. Under -platform: mqtt in configuration.yaml:
- platform: mqtt
state_topic: "tele/RFBridge/RESULT"
name: "Double Switch Left"
value_template: "{{value_json.RfReceived.Data}}"
payload_on: "A23092"
payload_off: "A23092off"
qos: 1
off_delay: 2

[flyte]

@a-x-

When trigger detects motion, HA will set state as detected and will keep it forever because no clear input (OFF payload) will receive.

Unfortunately we don't get information from the interrupt to say what the value of the pin (or even which pin it is sometimes) is that's triggered the interrupt, so we can't publish different payloads when it's turned ON or OFF.

To be honest, I wouldn't (and in fact don't, for my motion detectors) use interrupts for motion detection, since most PIR sensors hold the trigger on for at least a few seconds when motion is detected, and this is plenty of time for this software to poll the input and send an MQTT message. This way you don't have to worry about turning off the HA device after motion has been detected, because you'll receive the OFF message as normal.

[vincentkoevoets]

I'm going back a bit to the beginning of this thread. I'm trying to make my digital_outputs show up in Home Assistant. But when I add discovery: yes to my config file, all I get is
Config did not validate:
mqtt: discovery: unknown field
when trying to start mqtt-io. Am I doing something wrong? Or maybe I'm just putting it in the wrong place?
My config.yml

mqtt:
  discovery: yes
  host: localhost
  port: 1883  
  user: ***
  password: ***
  topic_prefix: home

gpio_modules: 
  - name: rpi
    module: raspberrypi

digital_outputs: 
  - name: deurbel
    module: rpi
    pin: 13
    on_payload: "ON"
    off_payload: "OFF"

[ondras12345]

Follow the documentation: https://mqtt-io.app/2.2.6/#/config/ha_discovery

[vincentkoevoets]

Aha, I only read (most of) the readme here on Github. Thanks for the pointer!