Double calculated values for absoulte humidity sensor about thermal_comfort HOT 12 CLOSED

@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.

from thermal_comfort.

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.

from thermal_comfort.

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

from thermal_comfort.

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

from thermal_comfort.

Closing this for now.

from thermal_comfort.

@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)

from thermal_comfort.

@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?

from thermal_comfort.

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

@tetsuo55, have you tried using polling?

from thermal_comfort.

@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

from thermal_comfort.

@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.

from thermal_comfort.

@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.

from thermal_comfort.

@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

from thermal_comfort.