MQTT non-autodiscovery lights/switches as devices?

Is there a way to get my MQTT lights, which are not auto-discovered, to show up as devices so I can use them with NFC tags?

This is one of my example configs:

    - platform: mqtt
      name: "Office Light"
      state_topic: "insteon/24.05.13/state"
      command_topic: "insteon/24.05.13/set"
      unique_id: "24.05.13"

And this is my MQTT config (I know, not really anything there, but for the sake of being thorough):

    mqtt:
      broker: !secret mqtt_broker
      port: !secret mqtt_port
      client_id: "HomeAssistant"
      username: !secret mqtt_user
      password: !secret mqtt_pass

And here you can see I don’t see my office light under devices.

They do show up as entities and I can control them, change the name, entity id, and icon, but without them showing up as a device I can’t assign them to an area or use them in the automations for the NFC tags.

You can’t. The only way to create mqtt devices is through auto discovery.

Thanks, I was afraid that’d be the case. Insteon2MQTT doesn’t support autodiscovery yet, though they are working on it I think. Maybe I can trigger something that NodeRed can use to change the lights states.

It doesn’t matter if it supports auto-discovered or not. Instead of configuring lights in YAML (what you are currently doing) you can configure them via MQTT Discovery with a script. That’s how I have configured several dozen entities consisting of lights, sensors, binary_sensors, climate, lock, etc. I provided an example here:

1 Like

Ah, thanks :smiley: This is great.

So, I would, for example, create an automation like below for my office light, if I got this right. Is there a reason to use an automation to create it versus just doing a one off publish to the topic?

  create_light:
    alias: "Create lights via MQTT Discovery"
    sequence:
      - service: mqtt.publish
        data:
          topic: homeassistant/switch/office_light/config
          retain: true
          payload: >
            {
              "name": "Office Light",
              "device_class": "switch",
              "state_topic": "insteon/24.05.13/state",
              "command_topic": "insteon/24.05.13/set",
              "unique_id": "24.05.13",
            }

Dang, it looks like it’s an all or nothing deal, either it’s all done this way or it’s all in the config.yaml?

If you want a device, you need a device in your discovery message

  create_light:
    alias: "Create lights via MQTT Discovery"
    sequence:
      - service: mqtt.publish
        data:
          topic: homeassistant/switch/office_light/config
          retain: true
          payload: >
            {
              "name": "Office Light",
              "device_class": "switch",
              "state_topic": "insteon/24.05.13/state",
              "command_topic": "insteon/24.05.13/set",
              "unique_id": "24.05.13",
              "device": {"identifiers": ["24.05.13"],"name": "Insteon 24.05.13", "model": "Insteon", "manufacturer": "Insteon"}
            }

1 Like

Gotcha, thank you both. I guess I’m going to be inventorying my MQTT devices and sensors and building out an automation to run when I switch it over.

What you posted isn’t an automation, it’s a script. In contrast to a script, an automation contains a trigger (and an optional condition).

You only need to run the script once to cause MQTT Discovery to create devices and entities. What’s important in this case is to ensure the discovery topic’s payload is published with the retain: true option. That tells the MQTT broker to retain a copy of the payload. When the broker (or Home Assistant) restart, the topic and payload are immediately available for use. If they were to disappear, so would the related device and entity disappear from Home Assistant.

No. You can use both techniques (as long as you’re not using both to define the same entity) but MQTT Discovery includes the ability you were looking for: define devices. The linked example showed how to define a device (also shown in francisp’s example).

1 Like

Ok, I know what I was running into I think. I had the broker defined in yaml and went through the integrations tab thinking I needed to add the broker there for the discovery stuff to work. You can only define the broker in the yaml or the GUI, not both (it says as much when you try to do it). That’s good though, I can start testing a device at a time. A lot less pressure when I don’t have to worry about breaking the whole house at once :slight_smile:

And yeah, I guess I was thinking it was an automation for some reason, I do most of my automations and stuff like that in Node-Red so I don’t mess with the Home Assistant side of that very often.

If you’re more comfortable with Node-Red you can create a flow instead of a script. It doesn’t matter what you use as long as it allows you to publish a payload to a discovery topic. The real work is constructing the payload according to MQTT Discovery’s specifications.

Oh, I’m good with the YAML, I just have found Node-Red to be easier to work out logic for automations and stuff with, probably the visualization helps with working out flow and such. I may even just drop mosquitto_sub commands in notepad++ and then copy paste them in the terminal of the MQTT server.