Control over whether messages are retained?

[NateEaton]

I have started using the gateway running on a pi Zero W to collect BT info from devices on the garage side of my house, one of which is the Inkbird 4X grill thermometer. I had previously used bt-mqtt-gateway for this but Theengs Gateway has been quicker, simpler and more stable.

However, one challenge is that it sets messages for IBT to retain status which means that when I start a grilling session, the graph I have in Home Assistant might have something like a starting temperature for probe 4 (grill surface temp) of 425 assuming that was the temp at end of my last grilling session. Similar issues for the other probes.

With my prior solution, I was using messages not set to retain and so each grilling session the sensors started out from nothing (either undefined or zero - been a while and I don't recall which).

Any chance of adding this type of control?

My alternative idea would be to have the decoder for IBT send a special value when a probe is unplugged instead of only sending data when the probe is reading temperature. I considered posting about that on decoder git discussion but figured I would start here.

[koenvervloesem]

Theengs Gateway doesn't set the retain flag when publishing messages for sensor measurements, it only does this for the messages with device configuration for discovery. I also verified this with mosquitto_sub on my installation with Mosquitto as the MQTT broker.

Which MQTT broker are you using? Is it maybe setting the retain flag for your messages?

[1technophile]

Maybe configuring a kind of expire_after for the sensor value in Home Assistant could help.

[DigiH]

Yes, the expire_after function will be the best solution, as what you are seeing is normal behaviour of Home Assistant, as well as any other controller, to keep the last received value for any sensor, until the next value is being received. Usually this is inconspicuous when the receiving intervals are something like 30 seconds or one minute, but with BBQ thermometers being switched off in between usage this behaviour can cause confusion.

[NateEaton]

Thanks. When I checked the topics for IBT probes in MQTTLens, it shows the retain flag set and I'd assumed that it had been set by the gateway but I guess it's "expected" behavior of HA MQTT integration.

As for using the expire_after feature, one concern is that it appears the gateway sends messages on changes in values, not every time it scans and finds an advertisement package (i e., for other devices like Blue Tempo sensor I see temperature changes come through frequently but battery level may go a long time between messages). That means that if I set the expiration too short it would set a probe to unknown when it's still in use. I could set the expiration for several hours but sometimes I have meat smoking over 12 hours.

I'm sure I could come up with a period that's long enough but not too short but there's another issue: when it goes to unknown, the value shown in dashboard graphs will be the last numerous value published which was the issue that brought me here.

I will try handling this in HA with an automation that zeroes out all the probes after the IBT is turned off. I may do that manually for now with a switch since the gateway doesn't publish an availability topic for the IBT device.

I'll post a separate discussion topic with question(s) about the gathering publishing availability topics for scanned devices.

[DigiH]

When I checked the topics for IBT probes in MQTTLens, it shows the retain flag set

If you see an actual retain flag with the messages from your IBT in MQTTLens or MQTT Explorer you might have an additional separate issue, like your MQTT broker set to retain all received messages or it is the retained device discovery messages you are seeing, not the frequently updating value messages.

As for using the expire_after feature, one concern is that it appears the gateway sends messages on changes in values, not every time it scans and finds an advertisement package

Gateway should send messages every times it scans a device, whether the values have changed or not, so this should not be a concern.

Not knowing too much about the HA expire_after implementation, and my controller allowing it to be set or not for each individual property, you would only apply this to the temperatures of sensors, not the battery status and other possibly less frequent properties, even though most battery properties should also be published with every MQTT message along temperatures and other values of most devices.

If it is for the whole message though it still should be fine, as the expire functionality doesn't look at values changing, but at values not being updated, even if the values stay the same for a longer time.

Personally I set the expire time for my IBT-2X to 5 minutes, zeroing all temperatures after that.

[NateEaton]

If you see an actual retain flag with the messages from your IBT in MQTTLens or MQTT Explorer you might have an additional separate issue, like your MQTT broker set to retain all received messages or it is the retained device discovery messages you are seeing, not the frequently updating value messages.

Apologies... to be clear, the retain is on the actual Config payload of the associated sensor in HA. In looking at the raw payloads under TheengsGateway|BTtoMQTT, those do not show retain flag.

Gateway should send messages every times it scans a device, whether the values have changed or not, so this should not be a concern.

Thanks, with that in mind I suspect what HA is doing is exposing sensor data in MQTT that originates from the gateway and yet internally not "publishing" a new message for that sensor unless the value has changed. In looking back at the raw topics from the gateway showing up in MQTTLens under TheengsGateway|BTtoMQTT, what I see matches what you describe.

Not knowing too much about the HA expire_after implementation, and my controller allowing it to be set or not for each individual property, you would only apply this to the temperatures of sensors, not the battery status and other possibly less frequent properties, even though most battery properties should also be published with every MQTT message along temperatures and other values of most devices.

Personally I set the expire time for my IBT-2X to 5 minutes, zeroing all temperatures after that.

Thanks.