core: Memory usage increase and Updating ping binary_sensoe error

More testing, more thoughts.

First, I set up a new sensor to ping my Mac and ran a tcpdump to detect incoming pings, then manually updated the sensor in Home Assistant. Pings came through instantaneously - so there is no problem with delays affecting initiation of commands or scripts in sensors.

Next - I have separated the ping command from the sensor by putting it into a bash file.

configuration.yaml:

sensor:
  - platform: command_line
    name: AV Receiver
    command: sh /config/av_receiver.sh
    command_timeout: 15
    scan_interval: 60

av_receiver.sh:

#!/bin/bash
ping -w 5 -c 1 192.168.1.147 > /dev/null 2>&1 && echo 'on' || echo 'off'

Interestingly, when the AV receiver was on, this all worked fine. As soon as I turned it off, the status wouldn’t update to reflect it and I once again got:

Updating command_line sensor took longer than the scheduled update interval 0:01:00
8:45 PM helpers/entity_platform.py (WARNING) - message first occured at 8:35 PM and shows up 10 times

Whilst still borked out in this state, I can still execute the shell script without any problems using the Configurator add-on - it works exactly as expected:

Command executed: sh /config/av_receiver.sh: 0
off

So here is my new theory: ping works fine in itself, but the way its responses are processed by the sensor or binary_sensor elements of HA are problematic, particularly if no packets are received. Due to the -w 5 header, the script shouldn’t (and doesn’t, as proven by testing in Configurator) take more than 5 seconds to execute a response, and the sensor should timeout anyway after 15 seconds - but it doesn’t. It lingers, stuck, apparently waiting for a response, indefinitely, until HA is restarted.

Could someone pick this up and take a look as to why it doesn’t work in docker installation as intended?

Brand new install, this time on an SSD using HassOS 3.5 and USB booting. So, so much faster and has fixed almost all the usual errors that would occur except this one.

Error first gets logged at 10:20pm. You can see the CPU and RAM spikes that coincide with it, but no apparent changes to network connectivity. The sensor that broke in this case was the CPU temperature sensor, which doesn’t require any network connectivity anyway.

Here are all my command_line sensors, in case anyone can see what is causing the issue:

  - platform: command_line
    name: CPU Temperature
    command: "cat /sys/class/thermal/thermal_zone0/temp"
    unit_of_measurement: "°C"
    value_template: '{{ value | multiply(0.001) | round(1) }}'
  - platform: command_line
    name: electricity
    value_template: '{{ value_json.count }}'
    scan_interval: 600
    json_attributes: 
      - results
    command: 'sh /config/bash_scripts/electricity.sh'
  - platform: command_line
    name: gas
    value_template: '{{ value_json.count }}'
    scan_interval: 600
    json_attributes: 
      - results
    command: 'sh /config/bash_scripts/gas.sh'
  - platform: command_line
    name: Household Waste
    value_template: '{{ value.split("</td><td>")[2]|replace("</td>","") }}'
    scan_interval: 600
    command: 'sh /config/bash_scripts/household_waste.sh'
  - platform: command_line
    name: Recycling
    value_template: '{{ value.split("</td><td>")[2]|replace("</td>","") }}'
    scan_interval: 600
    command: 'sh /config/bash_scripts/recycling.sh'

I am having the same issue. HassOS, rPI 3B+, 0.95.4

Not seeing quite the same problems with CPU usage as above but after a few hours my ping binary sensors stop working with the same error - took longer that scheduled update interval.

I have tried converting to command line binary sensors instead but this yields the same issue after working initially:

binary_sensor:
  - platform: command_line
    name: AV Receiver
    command: ping -W 1 -c 1 192.168.1.147 > /dev/null 2>&1 && echo success || echo fail
    scan_interval: 10
    command_timeout: 10
    payload_on: "success"
    payload_off: "fail"

Therefore I believe the issue is with the way Hassio handles any ping request, and not necessarily the specific ping components.