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