Silent option for MQTT (for use alongside Native API)

[mklettke]

Describe the problem you have/What new integration you would like

Add a silent option to MQTT Client which suppresses automatic reporting of ESPHome component (sensor, etc...) values but still allows one to use MQTT features in ESPHome such as triggers, actions (publish), and sensors (subscribe).

Please describe your use case for this integration and alternatives you've tried:

When using the Native API alongside the MQTT Client (with discovery set to false) the values of all ESPHome components are also reported over MQTT automatically creating a lot of unnecessary traffic which can add up over a lot of ESPs.

For example, one may wish to use MQTT alongside the Native API, for:

• Home Assistant sensors that expect MQTT such as MQTT Room Presence
• Simple communication between ESPs (with minimal setup/overhead and not reliant on Home Assistant)
• Commerical devices that have MQTT interfaces
• etc...

My primary use case (Room Presence) could also be done on the Home Assistant side with an automation (for each ESP32) and disabling MQTT on the ESP32 but I think that wouldn't be as clean a solution as directly on the ESPs (i.e. edge computing).

Additional context

I ran across this issue since I have just started using ESPHome (migrated from a custom solution and have been loving it so far - great job btw!) and wanted to setup Room Presence. This is fairly simply using the existing tools (BLE rssi sensor, lambda filter to convert to distance, on_value action with mqtt_publish_json) - I would like to write this up in the cookbook section when I get the chance. The only issue is the extra, unnecessary (IMO) traffic this creates when also using the Native API.

[danps1]

+1 on this request.
In my case I am using zwave2mqtt with some Zwave Door Sensors, and want to use mqtt automation on the ESP which controls my lights. For example...

mqtt:
  broker: 192.168.X.X
  username: xxxxxx
  password: xxxxxx
  discovery: false
  on_json_message:
    topic: zwave/pantry_door/48/1/0
    qos: 0
    then:
      - light.control:
          id: light_2
          state: !lambda |-
            return x["value"];

This works nicely and is much faster the the HA automation I was previously using for the same task, however, a consequence of adding the mqtt config is that ESPHome is now publishing state using both NativeAPI (wanted) and MQTT (unwanted)
I've turned off discovery so at least I haven't ended up with double entities in HA, but the ability to "silence" mqtt publishing would be really good.

[SeByDocKy]

Definitively a very important option to be added

[nagyrobi]

+1 for this.

[AlexDanault]

I'd love to have this option too.

[LewisSpring]

Adding my +1. I'd only like to use the publish action, on it's own.
One use case is the use of Public MQTT brokers on remote ESPs, where you could report a error/status without letting the rest of the internet see your log/etc output.

I've been instructed before to try setting topics to " ", but this does not properly solve the problem and will instead output everything on the top level of the topic.

[mvgijssel]

+1 on this request for the MQTT Room Presence use case!

[grillp]

I've got a pull request open for this: esphome/esphome#4078

🤞

[grillp]

Hey Peeps here... @mvgijssel, @nagyrobi @LewisSpring @AlexDanault @SeByDocKy @danps1 @mklettke
Could you please test the PR that I have made and test it and comment back in the PR if it works ok for you? That way it could get moved up the PR approval priority. Cheers!

[LewisSpring]

Hey Peeps here... @mvgijssel, @nagyrobi @LewisSpring @AlexDanault @SeByDocKy @danps1 @mklettke Could you please test the PR that I have made and test it and comment back in the PR if it works ok for you? That way it could get moved up the PR approval priority. Cheers!

Hi @grillp,

Just tried to test this out but getting an error:
https://gist.github.com/LewisSpring/8bb125ec9f1a17f2bdbe46703ceaa4ec

I added

  - source: github://pr#4078
    components: [ mqtt ]

as per https://esphome.io/components/external_components.html?highlight=dev+branch#:~:text=%23%20equivalent%20shorthand%20for%20GitHub%20pull%20request

[LewisSpring]

As an aside, would it be possible to add an option for entities to allow them to expose over mqtt? (eg, as an override to the expose_entities: false option)
No worries if not or not now :)

[grillp]

Just tried to test this out but getting an error: https://gist.github.com/LewisSpring/8bb125ec9f1a17f2bdbe46703ceaa4ec

as per https://esphome.io/components/external_components.html?highlight=dev+branch#:~:text=%23%20equivalent%20shorthand%20for%20GitHub%20pull%20request

Hmmm... it seems that the 'PR' mechanism in esphome dos not pull in changes in the core components, which these are, so you may not be able to test these changes by using the pr mechanism.. bugger.

The only way would be to build from my fork/branch grillp_mqtt_publish_state_option or from th esphome dev branch
. Which is painful if you have never setup for development before.

Sorry about that folks.

[grillp]

As an aside, would it be possible to add an option for entities to allow them to expose over mqtt? (eg, as an override to the expose_entities: false option) No worries if not or not now :)

That would be fairly trivial, but not something I will do in this first cut.

[LewisSpring]

Just tried to test this out but getting an error: https://gist.github.com/LewisSpring/8bb125ec9f1a17f2bdbe46703ceaa4ec

as per https://esphome.io/components/external_components.html?highlight=dev+branch#:~:text=%23%20equivalent%20shorthand%20for%20GitHub%20pull%20request

Hmmm... it seems that the 'PR' mechanism in esphome dos not pull in changes in the core components, which these are, so you may not be able to test these changes by using the pr mechanism.. bugger.

The only way would be to build from my fork/branch grillp_mqtt_publish_state_option or from th esphome dev branch . Which is painful if you have never setup for development before.

Sorry about that folks.

I'm using Docker, this will be hard to test at present (dev docker image outdated)
If I get a spare few minutes soon, I'll set up an environment for this 👌

[JanPono]

+2 ... we need silent mqtt version so much ;)

[tokke100]

as I'm adding more esp32's with battery (and using deep sleep and control over mqtt) I could use this.

[kev300]

+10 😅 I have over 110 entities on my esp32, which i don't want to publish over mqtt, but one sensor I want to read..