Device detection with MQTT

Let’s say our gateway device can handle multiple protocols and data types. And we want to integrate these streams with HA, say over MQTT, with some sort of self discovery.

Do we extend Netdisco init.py to have a base class MQTT Listener - then subclass to capture individual topics?

Or is there a different approach recommended?

Also, I note that if HA starts when our MQTT gateway is down, our sensors do not appear when the gateway connection is resumed. Is this by design?

thx.

[quote=“agsense”]Let’s say our gateway device can handle multiple protocols and data types. And we want to integrate these streams with HA, say over MQTT, with some sort of self discovery.

Do we extend Netdisco init.py to have a base class MQTT Listener - then subclass to capture individual topics?
[/quote]

I don’t think that netdisco is the right place for the discovery of MQTT. mDNS and uPnP are a bit too different to MQTT. Perhaps it would make more sense to extent the current MQTT implementation or add new component that is handling the discovery.

[quote=“agsense”]
Also, I note that if HA starts when our MQTT gateway is down, our sensors do not appear when the gateway connection is resumed. Is this by design?.[/quote]

If your MQTT gateway is the broker then the entities will not show up. Yes, it’s by design. Setup failures of platforms will lead to an exclusion. Otherwise the MQTT platforms stay on their initial state and wait for changes.

1 Like

In 0.38 MQTT Discovery was introduced.
But is it only working with the internal MQTT?

I tried to add it to my mosquitto broker but then HASS fail to set up MQTT.

mqtt:
  discovery: true
  discovery_prefix: homeassistant
  broker: 192.168.1.222
  client_id: home-assistant-1
  keepalive: 60
  username: USER
  password: PASS

yeah same thing here also.

@fabaff, great! No I can start HASS without problem.

But I can´t get the discovery to find my binary sensor automatically by publishing this to my broker:

mosquitto_pub --cafile /home/pi/ca.crt -h 192.168.1.222 -p 8883 -t "homeassistant/binary_sensor/garage/config" -m "{"name": "garage", "sensor_class": "motion"}"

mosquitto_pub --cafile /home/pi/ca.crt -h 192.168.1.222 -p 8883 -t "homeassistant/binary_sensor/garage/state" -m "1"

Shouldn´t it appear or what am I missing?

Could be an issue with the quotes. This works for me:

$ mosquitto_pub -h localhost -p 1883 -t "homeassistant/binary_sensor/garage/config" -m '{"name": "garden", "sensor_class": "motion"}'
$ mosquitto_pub -h localhost -p 1883 -t "homeassistant/binary_sensor/garage/state" -m ON

There is an open PR to improve the MQTT documentation incl. the discovery part. The configuration is run through voluptuous and the missing parts are filled with defaults.

Great, seems to work better!
Thanks

Is it possible to “stick” the discovered device in HA like you can do with discovered rfxcom devices?

For me the device disappear if I restart HASS and I need to restart my device/script to make it appear.
And if I do the opposite (restart device while HASS is running) it appear twice in HASS.

Hmm, how about to retain the configuration message from the device?

@fabaff that might be a solution for issue 1. But will it prevent HASS to create duplicates?

No, it would create multiple senors if HA receives the config playload again and again. This is on my to-do list. The initial idea was that the sensor is updated if it gets an new configuration.

2 Likes

how does it identify the function?

I have multiple devices in my Smartthings that report via smartthings but I assume it doesnt detect it as the topic is not sensor, binary_sensor etc - is there an option to identify devices as per published message on a wildcard basis?

here is what I am thinking
smartthings//illuminance - add as sensor
smartthings/
/temperature - add as sensor
smartthings//threeAxis - add as sensor
smartthings/
/tamper - I guess this is a binary_sensor
smartthings//switch - add as switch?
smartthings/
/level - add as light
smartthings//saturation - add as light
smartthings/
/color - add as light
smartthings//hue - add as light
smartthings/
/presence - add as sensor
smartthings//power - add as power
smartthings/
/button - add as switch?
smartthings/*/battery - add as ???

I hope you get the idea? not sure if this would be possbile, I think we could just just regex parsing of the name and do that …

Unfortunately your devices wouldn’t be detected by the current MQTT discovery implementation. We require one messages which contains the device details.

If the structure of the topic always looks the same it would be possible to create a separate implementation for Smartthings. Topic ending with X, then a lookup is done, and the sensor/switch created.

thanks - so how could I figure this out whats needed? I have mentioned all topics I have seen so far the wildcard is the devicename …

Hi,
Just discovered HA a few days ago while looking for a replacement to another solution, looks great!
I would like to integrate some devices from a domotics system. The aim would be to use the mqtt discovery but I could not find the different payloads to use for discovering new device.
Did some small tests and hit the same kind of issue than @frelev (items registered twice for example)
Not sure it was the right place to post, but would appreciate any hint or help :wink:
thanks

Thanks for so quick reply!
I saw the doc you are referring, but the payload mentioned there is very limited for creating new device (name and type)
Isn’t it possible to add a friendly name or additional info?

Concerning the fix, I saw it was merged but is it already released? Not sure how to check that.

The “system” I am trying to integrate contains rooms and devices attached to them. I can easily have a JSON with everything. Ideally I would like to create both “rooms” as group if they do not exist and devices. Is this possible through mqtt or other API? My “source” system is in node, and I don’t know python :wink:

thanks

Not at the moment as only values which usually are used as configuration variables are accepted. We are using the platform validation to make sure that the requirements are a match.

Will be shipped with 0.46.

MQTT discovery is a generic approach but we open to integrate third-party tools through separate implementations. The arwn platform is an example.