decrease mqqt update frequency

[sla-te]

For me the temperature on a connected hub2 will not refresh if the value has not changed. Changing this was somehow possible through redefining the sensor in configuration.yaml and settings the force_update: true paramater but this workaround seems to have stopped working. Can you add a switch so we can enable it?

ref.: force_update: https://www.home-assistant.io/integrations/sensor.mqtt/#force_update

[hsakoh]

Thank you for the feedback.

Firstly, let me explain some aspects of the current specification of this add-on...

• It does not support overriding detection properties. Specifically, the add-on does not subscribe to detection topics, so even if you override force_update, it cannot read it. (You mentioned, "this workaround seems to have stopped working," but this aspect has not changed consistently since the past.)

• Here's a screenshot of the debug information for an MQTT device. The subscribed status update topic sends messages regardless of value changes. Since the add-on does not internally maintain state, it sends all values received from polling or webhook. This means it behaves as if force_update=true at all times.

---

Could you please provide more details about what you want to achieve? Is it among the following?

• "I want to receive values at a frequency higher than the automatic polling frequency." (Currently, since it doesn't internally maintain state, it's difficult to determine if the value has changed...)

• "I want to avoid sending messages to the status update topic if the value hasn't changed." (In this case, I interpreted it as wanting force_update:false...)

• Other (there might be a misunderstanding in my understanding of how it behaves when force_update:true is set)

[sla-te]

Thanks for the comprehensive reply.

If you are unsure about what adding force_update:true to the payload will do and if it is not too much of a hustle, add it and take a look at the sensors history graph. If the last update value aligns with the polling frequency it works, if not it doesnt.

I want to achieve having a history graph, that reflects the polling interval, 10s in my case.

By the change I noticed I mean, that you cannot define the sensor manually anymore using the syntax suggested in the forum post I linked (yields a configuration error). Hence I assumed something changed and broke that workaround, which potentially worked in the past.

To my understanding the force_update:true setting, in case of autodiscovery, must come from the provider/implementation and cannot be overriden by redefining the already autodiscovered sensor (anymore?). I also couldnt find a global switch to enable this flag for all mqtt sensors.

[hsakoh]

I'm sorry, but since I only have MQTT devices created by myself, even when setting force_update:true, there are no devices with changing expressions...

Considering the 10-second interval, it seems to be "I want to receive values at a frequency higher than the automatic polling frequency." In other words, I understand that you want to render more data points (with the same value repeatedly) at a frequency finer than the automatic polling frequency (the frequency of calling the GetStatus API).

To accommodate this in the add-on, it would require significant modifications to maintain internal state and send at a frequency other than the automatic polling frequency. Let me think about whether i can support this.

Regarding "yields a configuration error" I recommend raising them as issues on the MQTT Integration side.

On a slightly different note, apart from MQTT devices, couldn't you define a filter sensor to achieve sensors with the desired frequency of data points? (I haven't used it myself) https://www.home-assistant.io/integrations/filter/

[sla-te]

While https://www.home-assistant.io/integrations/filter/ seems interesting my goal would rather be to have very precise temperature updates on the sensor itself for e.g. a growing room, where a couple minutes of temperature changes can actually matter.

[hsakoh]

For that purpose, you would need to actually capture temperature changes, so you can only increase the automatic polling frequency. In the device configuration on the Ingress page, specify intervals such as every 1 minute (PT1M) or every 15 seconds (PT15S).

However, please note that the SwitchBot API has a limit of a maximum of 10,000 requests per day, so extremely high-frequency polling is not feasible.

Additionally, based on my logs, the actual measurement frequency of Hub2 has never been shorter than 5 minutes. (When exporting to CSV in the smartphone app, you can select every minute, so it’s possible that measurements are taken every minute.)

[hsakoh]

https://github.com/hsakoh/switchbot-mqtt/blob/main/INSTALLATION.md#physical-devices

[sla-te]

Thank you very much for your investigation.

Good find on, that the actual reading only takes place every 5 minutes on the device itself - in this case I will probably switch to using a BMU280.

About the API limits and ISO notation - yes I had that calculated to be just below the API limit, so in my case PT10s which results in 8640/10000 API calls.