Shouldn't an MQTT subscribe sensor obey expire_after?

ESPHome
1

I have this code to get info about the trim level of my motor from NMEA2000 into the ESP that controls trim and jackplate, by sending it on MQTT from Node-RED:

  - platform: mqtt_subscribe
    name: "Trimsensor"
    id: trimsensor
    topic: madmax/trim
    expire_after: 10s

I need it to be current or not there at all. If the ignition is turned off, the engine interface does not receive changes in the trim, and then I can’t use that as the basis for an automation. The problem is that it doesn’t obey the “expire_after”. if I send a value over MQTT it will stay there until the ESP reboots. Does anybody know why it isn’t obeying the expire?

2

mqtt_suscribe ? That’s to read messages.
The expiry is set when publishing (write) messages, at least from a MQTT pov, not clue about node red.

3

Thank you for answering, but if you look at the subject of the post you will see that this is the mqtt_subscribe sensor.

4

Ah ok.
Well that expire_after is specifically for HA itself. The “trimsensor” value, if exported to HA, should expire in HA after 10s (marked unknown)
I understand your’re doing node-red->ESP, so it’s irrelevant for your use case.

You actually want the pure MQTT publish expiry I mention above, I think.

5

Really? I thought this would work internally in the ESP, so I could use it in an automation there. Hass does not come into this equation for me in this case. Here’s what’s written under that sensor:

The mqtt_subscribe sensor platform allows you to get external data into ESPHome. The sensor will subscribe to messages on the given MQTT topic and parse each message into a floating point number.

And this is about expiring in the general sensor setup:

MQTT Options:

  • expire_after (Optional, Time): Manually set the time in which the sensor values should be marked as “expired”/“unknown”. Not providing any value means no expiry.
  • All other options from MQTT Component.

There’s nothing about Hass in this description. Can you please tell me where it says that this is valid for Hass, and not internally in the ESP?

6

Code tells:

That value is used nowhere in esphome proper

7

Wrong sensor. That’s the regular MQTT Sensor, not the MQTT_subscribe sensor. That is here:

And the expire is not a part of that sensor, it is a part of the base sensor configuration and should be valid for everything that are defined as a sensor.

8

Whatever pal.
The fact that the attribute doesn’t do what you think it does should be a hint I might be right :wink:

9

Or a bug. :grin: So I’m taking the chance of being ridiculed and reporting it as an issue on GitHub.

10

Damn, those guys from ESPhome on Github are fast! And you are right, it’s the outgoing message that expires in 10 seconds in my code. But they also had the solution for me:

  - platform: mqtt_subscribe
    name: "Trimsensor"
    id: trimsensor
    topic: madmax/trim
    filters:
      - timeout:
          timeout: 10s

And that works just as I wanted it to. :grin: