Help with Bang Bang Controller/DS18B20 dropouts

Hey guys. Im using a DS18B20 with a bang_bang controller and I keep getting these blocking errors on the dallas_temp.sensor.

The errors dont appear when the bang_bang is removed and the DS18B20 by itself to report the temp.

interval is 120s

[16:49:49][D][dallas.temp.sensor:054]: 'esp32-relay-x2-49c7d0-temperature': Got Temperature=27.9°C
[16:49:49][D][sensor:094]: 'esp32-relay-x2-49c7d0-temperature': Sending state 27.93750 °C with 1 decimals of accuracy
[16:49:49][D][climate:396]: 'esp32-relay-x2-49c7d0-controller' - Sending state:
[16:49:49][D][climate:399]:   Mode: COOL
[16:49:49][D][climate:401]:   Action: COOLING
[16:49:49][D][climate:419]:   Current Temperature: 27.94°C
[16:49:49][D][climate:423]:   Target Temperature: Low: 12.00°C High: 22.00°C
[16:49:49][W][component:237]: Component dallas_temp.sensor took a long time for an operation (60 ms).
[16:49:49][W][component:238]: Components should block for at most 30 ms.
[16:50:03][D][sensor:094]: 'esp32-relay-x2-49c7d0-WiFi Signal': Sending state -45.00000 dBm with 0 decimals of accuracy
[16:50:09][D][esp32.preferences:114]: Saving 1 preferences to flash...
[16:50:09][D][esp32.preferences:143]: Saving 1 preferences to flash: 1 cached, 0 written, 0 failed
[16:51:49][D][dallas.temp.sensor:054]: 'esp32-relay-x2-49c7d0-temperature': Got Temperature=27.9°C
[16:51:49][D][sensor:094]: 'esp32-relay-x2-49c7d0-temperature': Sending state 27.93750 °C with 1 decimals of accuracy
[16:51:49][D][climate:396]: 'esp32-relay-x2-49c7d0-controller' - Sending state:
[16:51:49][D][climate:399]:   Mode: COOL
[16:51:49][D][climate:401]:   Action: COOLING
[16:51:49][D][climate:419]:   Current Temperature: 27.94°C
[16:51:49][D][climate:423]:   Target Temperature: Low: 12.00°C High: 22.00°C
[16:51:49][W][component:237]: Component dallas_temp.sensor took a long time for an operation (71 ms).
[16:51:49][W][component:238]: Components should block for at most 30 ms.

Heres my code:

switch:
  - platform: gpio
    pin: GPIO16
    id: relay_1
    name: ${name}-Relay_1

# Set up the dallas sensors. ESP32 must have a pullup resistor
one_wire:
  - platform: gpio
    pin: GPIO13

sensor:
  - platform: dallas_temp
    name: ${name}-temperature
    update_interval: 120s
    id: temp1

climate:
  - platform: bang_bang
    name: ${name}-controller
    id: controller
    visual:
      min_temperature: 0 °C
      max_temperature: 100 °C
      temperature_step: 0.1 °C
    sensor: temp1
    default_target_temperature_low: 12 °C
    default_target_temperature_high: 22 °C
    idle_action:
      - switch.turn_off: relay_1

    cool_action:
      - switch.turn_on: relay_1

Any input to resolve this issue would be most welcome.

This is a Warning about component running too long.
There is nothing to do on Your side.

Unfortunately it does matter.

In my situation I am running a bang bang controller locally on the ESP

Whenever it happens the sensor goes into “unknown” and cycles the bang bang controller between on and off repeatedly which is connected to a solenoid on a cooler which is REALLY not healthy for the compressor on the cooler.

I wont disable the warning notifications as I use them to determine if the sensor is actually faulty.

Anyone know how to increase the duration?

As said, that’s a common warning and I don’t think it’s the real issue. I agree there is something with unknown status and that is causing your system to drop back to idle state. I had corrupt sensor data because a sub sensor was not always returning real data. I think you should try and use a lambda function to only return valid data. My sensor was in templates.yaml so it was easy to implement.

    - name: "Battery SOC"
      unique_id: bat_soc
      state_class: measurement
      unit_of_measurement: "%"
      # Some devices are controlled by SOC. "unknown" or "unavailabe" causes false
      # triggers so IF statement checks for valid response before returning any result.
      state: >
        {% if has_value('sensor.120ah_soc') and has_value('sensor.202ah_a_soc') and has_value('sensor.202ah_a_soc') %}
          {{ (states('sensor.120ah_soc') | float(0) * (120/524) |round(1) ) + (states('sensor.202ah_a_soc') | float(0) * (202/524)|round(1)) + (states('sensor.202ah_b_soc') | float(0) * (202/524) | round(1)) }}
        {% endif %}

    - name: "Total Solar Power"
      unique_id: total_sol_power
      unit_of_measurement: "W"
      device_class: power
      state_class: measurement
      state: >
        {% if is_state('sun.sun', 'below_horizon') %}
          {{ 0 }}
        {% elif is_state('sensor.pc191ha_lawn_power', 'unavailable') %}
          {{ states('sensor.pv1_power') | float | round(3) + states('sensor.pv2_power') | float + states('sensor.pv3_power') | float }}
        {% else %}
          {{ states('sensor.pv1_power') | float | round(3) + states('sensor.pv2_power') | float + states('sensor.pv3_power') | float + states('sensor.pc191ha_lawn_power') | float }}
        {% endif %}

Sorry - thanks for the effort but I need this to run on the ESP and HA just does the monitoring.

What you have here is a solution that occurs within HA.

What I need is for this to NOT drop out on the ESP as it controls a chiller directly and every time it drop out it cycles the chiller (not healthy for the chiller)

dropouts

As you can all see, the dropouts are frequent. These are caused by the library expecting a response within a time frame but the sensor responds slightly slower.

How to change the libraries expected timeframe???

Thanks

I even tried the idf framework to see

I did state my solution was in an HA yaml and easy for me to do. No skills in c++ but you need something similar in your device yaml as a lambda function. If the result is invalid either ignore it or use the last valid response. I had a smart plug behaving the same way and it took me a while to realise it was the drop outs in data causing it.

I see this warning on many sensors but not sure if it is the real reason for drop outs. Changing library timeframes may not help.

Maybe a filter is good enough to maintain clean data? Clamp or a simple Lambda looks like it would work to only return real data.

I’m also surprised that you see any dropouts. I have a DS18 on an esp32 and use the ambient temp to control things. I have never seen it (nothing in sensor history) give a false reading. I just did a test setup and again, perfect readings. I also tried without sensor address but still ok. Still might be worth adding.

My sensor is connected as left pin to gnd, right pin to 3V3, and middle pin to GPIO32. No external resistor required so maybe try changing from GPIO13 to 32.

one_wire:
  - platform: gpio
    pin: GPIO32

sensor:
  - platform: dallas_temp
    address: 0xe70008010550cd10
    name: "Test Temperature"
    accuracy_decimals: 1
    update_interval: 10s
    state_class: ''