Trigger automation when sensor is updated, even to the same value

Configuration
1

I have a sensor for the weight reported by my bathroom scale (via MQTT at the moment, but might change to BLE in the future).

I want to trigger an automation (speak the weight) whenever the scale sends a value, even if the value is the same as last time.

But this seems to be suppressed by HA, not even states.sensor.mi_scale_weight.last_updated is actually updated?

2

Could you use the MQTT message as the trigger?

3

As a general rule, when a received entity value is identical to an existing entity value, nothing happens to the entity’s existing value. There’s no state-change and the entity’s last_updated value remains the same (basically, the duplicate value is ignored).

Try r-j-taylor’s suggestion. MQTT Trigger

1 Like
4

Currently I’m converting the BLE message on the Raspberry Pi to MQTT but to extend the range I consider moving it to an ESP8266 device running ESPhome. Would the MQTT trigger also work with an ESPhome sensor? As far as I know ESPhome does not use MQTT?

5

Sounds like you have full control over what gets sent to HA from the scale. If that’s the case the simplest solution seems to me to change it so the scale sends a timestamp of “last used” or “last weigh in”. You can set that timestamp as either an attribute on the existing sensor or (ideally) a new sensor in the device for the scale with device_class: timestamp.

Then you can trigger your automation when the timestamp updates and use the last weigh in value as you see fit, without worrying about whether it was different from the last weigh in or not. And without depending on the technical details like what the mechanism of transport happens to be currently (Mqtt, ble, etc)

1 Like
6

I could probably rig something together based on this example?

But as you say, a solution that doesn’t depend on the technical details of how the sensor value arrives would be even better. Why is there even a last_changed and a last_updated attribute if they seemingly do the exact same thing? Seems like a bug to me.

7

Why is there even a last_changed and a last_updated attribute if they seemingly do the exact same thing?

I found the answer to this myself, here: last_changed doesn’t change when only the attributes of the state object change.

Still seems like a bug to me that there is no mechanism to react to incoming updates.

8

It’s known behavior; not a bug.

Feel free to vote for the following WTH:

1 Like
9

I call it a “known bug” :slight_smile:
But that’s too harsh on some devs to call it that.

10

It’s not a bug because it works exactly the way it’s documented:

image
image693×211 12.4 KB

1 Like
11

I agree it’s a missing feature, it just feels like a bug. :slight_smile:

12

It’s definitely not a bug since as 123 shows, it works exactly as documented. Also to each their own but to me I would be extremely confused if a field called last_updated changed when literally nothing was updated. If the entity wasn’t updated why would the field that records the last time it was updated change?

If an integration wants to keep track of the last time it received information from the external service even if nothing changed then its the responsibility of the integration to record that information. HA can’t really handle that for the integration because it has no idea how any individual integration works. The only thing it knows is when the state of the entities it is being asked to keep track of has changed.

In general there’s two ways integrations do this signalling that they received data even if nothing changed:

  1. Fire an event which can be listened for in an automation
  2. Record timestamp of last data received somewhere, either in an attribute or an entity

#1 is sort of an option for you, that’s basically the equivalent of listening for the MQTT message. Or if you really want to you can modify the code on the pi to make an authenticated call to POST /api/events and actually fire an event. Or make a custom integration instead of using an OOTB one for your scale that fires events when it receives data before updating its entities.

#2 seems like the ideal option for you in this case since I think it involves the least customization of existing code. And doesn’t depend on technical details like MQTT.

13

Good point, it might not make sense for all integrations to provide the “sensor updated” information. So if I would go about implementing something (hypothetically, I’m not planning that right now) then it should probably go in the direction of allowing for example the BLE or ESPhome integration to send events when a weight is acquired. Actually I think ESPhome can already do that.

1 Like