Home Assistant temperature recording readings

[Bishbosh02]

I have some odd temperature recordings, they go very low has anyone seen this before I am using the development branch but this also happened on an old version so don't think its a new issue see pic

[visualapproach]

How does the graph on airbubbles/pump look like? Can it be a noisy data transmission that flips the unit bit occasionally? In that case it should also be visible on the other states I guess.

[Bishbosh02]

The spa target also has the issue and this just comes from the control board? but is also affecting air bubbles so looks like a noise issue

[visualapproach]

Yeah probably. I don't remember your setup now but possible mitigations are shorter wires and low pass filters

[Skeletorjus]

#236

I have the same ting. It's honestly not a big deal, and I've made some template sensors in Home Assistant that filters out the rogue values. I did build a board with shorter wires as suggested, but must have messed up in another way since I couldn't get it working at all, so that is still on ny todo-list.

[Bishbosh02]

Can you share your template sensors 👍

[Skeletorjus]

Sure!
For temperature sensors I use two templates. One filters out all values outside scope. I use celsius, so everything between 5 and 41 is discarded. Then I have another trigger based template sensor that filters out all values from the first one that are present for less than 5 seconds and/or unavailable to remove the "blips".
The original temperature as reported by the ESP has been renamed to sensor.layzspa_temperature_raw in Home Assistant.

Temperature sensor

template:
  - sensor:
      - name: Layzspa Temperature filtered
        unique_id: sensor.layzspa_temperature_filtered
        state: "{{ states('sensor.layzspa_temperature_raw') | int }}"
        unit_of_measurement: "°C"
        availability: "{{ ((states('sensor.layzspa_temperature_raw') | int) > 5) and  ((states('sensor.layzspa_temperature_raw') | int) < 41) }}"
        device_class: temperature

  - trigger:
      - platform: state
        entity_id: sensor.layzspa_temperature_filtered
        for: "00:00:05"
    sensor:
      - name: Layzspa Temperature
        unique_id: sensor.layzspa_temperature_sanitized
        state: "{{ states('sensor.layzspa_temperature_filtered') | int }}"
        unit_of_measurement: "°C"
        availability: >-
          {{ not is_state('sensor.layzspa_temperature_filtered','0') and not is_state('sensor.layzspa_temperature_filtered','unavailable') and not is_state('sensor.layzspa_temperature_filtered','unknown') }}
        device_class: temperature

I use template binary sensors to clean up states of switches and binary sensors. These turn on only after the parent switch/sensor has been on for 5 seconds, and will remove all the blips.
Example:

Binary state sensor

template:
  - binary_sensor:
      - name: Layzspa Pump
        unique_id: binary_sensor.layzspa_pump
        state: >-
          {{ states('switch.layzspa_pump') }}
        delay_on:
          seconds: 5

In UI I use button-card and configure it to show the state from the template binary sensor, and to toggle switch.layzspa_pump when clicked.

Card

type: custom:button-card
color: auto
color_type: card
entity: binary_sensor.layzspa_pump
icon: mdi:pump
hold_action:
  action: more-info
tap_action:
  action: call-service
  service: switch.toggle
  service_data:
    entity_id: switch.layzspa_pump
name: Pump
styles:
  card:
    - height: 80px

The only thing in the UI that still is irregular is the history of the climate control. I'm sure this can be worked around by creating a secondary MQTT climate control and move values between that and the original climate control by way of automations, but I don't really think it's needed.

I guess this could be done in the ESP itself with configurable debouncing before reporting to MQTT and/or a min/max for temperature readings, but as @visualapproach stated in #236 (comment), this would only be a workaround for the root hardware issue.

[Bishbosh02]

Thanks this worked.....

[visualapproach]

I guess this could be done in the ESP itself with configurable debouncing before reporting to MQTT and/or a min/max for temperature readings, but as @visualapproach stated in #236 (comment), this would only be a workaround for the root hardware issue.

Yeah but this is the best we have atm. Thanks @Skeletorjus for the work around

[Bishbosh02]

I decided to try and get rid of the issue rather than use the filter, as I have a test system and other type of level converter.

After changing to the transistor level converter on the test system I now have no issue with readings as it is rock steady (note I used 680R resistors )

[Bishbosh02]

After updating the firmware with the latest dev branch I have had no more glitches, so I would say the issue is fixed and I can remove the filters from Home Assistant 👍

[visualapproach]

That's great news! If anyone is interested, I added a check if the clock pulses count is as expected when receiving end of packet. Otherwise it discards the packet. I should ofc had done this from the start but better late than never. Thought it was the data line that was the problem but it seems it's the clk.
Thanks for testing

[Skeletorjus]

Well, this is highly encouraging for my issue as well!
Here's the last 24 hours of temperature readings, try to spot where I updated to 2022-06-29:

I see that I still got a blip on all sensors at 06:53:17, but this is night and day compared to before.

[Skeletorjus]

A quick update:
I'm still getting some blips, but not nearly to the extent I did earlier. Don't know what's causing these, but they happen as the same time as every other signal gets a quick toggle.

@visualapproach Can you think of a way this can be debugged, or is it simply something that's not fixable in software?

[visualapproach]

I can think of a couple of ways to debug or filter out the blips. Think I need to do that to get the next feature to work. But I can't do anything on the project for a couple of days.