Double calculated values for absoulte humidity sensor

[monotonus]

I have an issue with the calculated absolute humidity on my balcony:

As you can see there are many strange spikes in the graph. These are double values in the same minute:

I don't know why this just occurs there that often. For the indoor sensors it does'nt have these spikes. Maybe because there are not that much changes than outdoor?

The sensors are all Xiaomi Temperature and Humidty sensors without pressure (the round ones).

Any idea?

[NovDavid]

I have the same issue. I'm using the same sensor as you, via zigbee2mqtt. My theory is that hass updates the temperature and humidity values with a little time difference, but fires an update of the absolute humidity for both, hence the duplicate data points in absolute humidity, with the first being incorrect.
I didn't debug it though,so it's just a theory, and I haven't yet come up with a solution either.

[rautesamtr]

Maybe an optional poll mode could work around this. Basically sacrificing responsiveness for a smoother graph.

[rautesamtr]

Could you both give 30c5511 a try if using poll mode fixes the issue for you?
You have to enable polling in your yaml config to enable it and use a scan_interval that avoids those duplicate entries.
e.g.

sensor:
  - platform: thermal_comfort
    poll: true
    scan_interval: 300
    sensors:
      livingroom:
        friendly_name: Living Room
        temperature_sensor: sensor.temperature_livingroom
        humidity_sensor: sensor.humidity_livingroom

[rautesamtr]

Closing this for now.

[tetsuo55]

@rautesamtr the way @lymanepp solved it for me was by adding a change threshold, this way the double calculated value would be dropped and not written to the database.

Unfortunately his repo has been force pushed but i have the snippet of code here

new_state = self._calc_simmer_danger()

if new_state == self._state:
    return False

if (
    isinstance(new_state, float)
    and isinstance(self._state, float)
    and abs(new_state - self._state) < self._change_threshold
):
    _LOGGER.debug(
        f"Suppressed {self._name} update less than {self._change_threshold} - new: {new_state} current: {self._state}",
    )
    return False

Mark-up is not working (Fixed for you)

[lymanepp]

@tetsuo55,

Now that this repo has SSI, I don't need to maintain a fork. But I restored my repo to https://github.com/lymanepp/thermal_comfort_archived.

[tetsuo55]

@tetsuo55,

Now that this repo has SSI, I don't need to maintain a fork. But I restored my repo to https://github.com/lymanepp/thermal_comfort_archived.
Thanks
@rautesamtr is there enough information here to fix this issue in this repo?

[lymanepp]

@rautesamtr is there enough information here to fix this issue in this repo?

@tetsuo55, have you tried using polling?

[tetsuo55]

@rautesamtr is there enough information here to fix this issue in this repo?

@tetsuo55, have you tried using polling?

No i don't want to switch until im sure it works because I'll lose history

[rautesamtr]

@tetsuo55 what offset did you actually use? i am looking at home assistant significant_change feature which basically sets tresholds for what is a significant change (e.g. default for °C is 0.5) but i am not sure yet how users can properly user that feature.

[lymanepp]

@tetsuo55 what offset did you actually use? i am looking at home assistant significant_change feature which basically sets tresholds for what is a significant change (e.g. default for °C is 0.5) but i am not sure yet how users can properly user that feature.

I was using 0.1 as the threshold for changes.

[tetsuo55]

@tetsuo55 what offset did you actually use? i am looking at home assistant significant_change feature which basically sets tresholds for what is a significant change (e.g. default for °C is 0.5) but i am not sure yet how users can properly user that feature.

I was using 0.1 but maybe 0.05 would have been better