Ping sensor showing wrong status

Configuration
1

Hi.

I’m running Home Assistant 0.79.3 on a raspberry Pi with Hassio (134). All the ltest versions, of time of writing.

I have a problem with the Ping sensors, I’ve set up, to detect if 2 TVs are turned on.

I have given them static IP’s in my router, and they both respond to ping commands, from the command line. If turned my PI and both devices off and on again.

This is the configuration in my configuration.yaml:

device_tracker:
  - platform: ping
    hosts:
      bedroom_tv: 192.168.1.237
    interval_seconds: 30
    consider_home: 180
    
device_tracker:
  - platform: ping
    hosts:
      stue_tv: 192.168.1.18
    interval_seconds: 30
    consider_home: 180

In known_devices.yaml I get this:

stue_tv:
  hide_if_away: false
  icon: mdi:television
  mac:
  name: Stue TV
  picture:
  track: true

bedroom_tv:
  hide_if_away: false
  icon: mdi:television
  mac:
  name: Bedroom TV
  picture:
  track: true

They also show up in the interface, with the correct icons, and I don’t get any errors when checking my yaml code.

They just do not show the correct status of home/away.

It seems completely random what state they’re in, but it doesn’t change often.

Any ideas?

2

Not sure why you’re using a presence detection sensor for this. I’d suggest using the Ping Binary Sensor instead. That’s what I use to test if devices are responding to network communications.

3

I use ping to determine if the TVs are on, and then have the lights in the room turn on;

- id: every_evening_lights
  alias: Turn on Living Room Lights Every Evening
  trigger:
  - event: sunset
    offset: -01:00:00
    platform: sun
  condition:
  - condition: state
    entity_id: device_tracker.stue_tv
    state: home
  action:
  - data:
      group_name: Livingroom
      scene_name: Sundown
    service: hue.hue_activate_scene
4

Yes, I understand. But the Ping Binary Sensor is better suited to that. E.g.:

binary_sensor:
  - platform: ping
    host: 192.168.1.237
    name: bedroom_tv
    device_class: connectivity
    scan_interval: 30
  - platform: ping
    host: 192.168.1.18
    name: stue_tv
    device_class: connectivity
    scan_interval: 30

And for the automation:

- id: every_evening_lights
  alias: Turn on Living Room Lights Every Evening
  trigger:
  - event: sunset
    offset: -01:00:00
    platform: sun
  condition:
  - condition: state
    entity_id: binary_sensor.stue_tv
    state: 'on'
  action:
  - data:
      group_name: Livingroom
      scene_name: Sundown
    service: hue.hue_activate_scene
1 Like
5

Thanks for replying. And for the suggestion.

I put it into my configuration and automation file, and so far it picks up the devices correctly, as in which one is turned on or off.

I’m looking forward to seeing, if it works with my lights tomorrow!

Thanks again

6

It worked, just as hoped. So your suggestion was spot on!
Happy with my installation now.

7

hey Phil,

why would that be? I use both ping techniques, and also the device_tracker to see if my phones are online, as is suggested to be the correct use for this in the documentation: Ping (ICMP) - Home Assistant

Would you please care to indicate the main difference in suitability between the device_tracker Ping and binary_sensor Ping ?

please see Adding binary_sensor to group changes status from 'home' to 'on'? for some anomalies i’ve ran into using the binary_sensor ping in a group

8

Where do you see it suggesting to use the Ping Device Tracker to monitor if a device is online or not? I only see it saying, “The ping device tracker platform offers presence detection by using ping to send ICMP echo requests.”

The documentation for the Ping Binary Sensor says, “The ping binary sensor platform allows you to using ping to send ICMP echo requests. This way you can check if a given host is online…”

Even just comparing what the documentation says about both, the binary sensor is more suited to testing if a device is online. Besides, a device tracker is intended to “track a device” to determine if it (but really you) are home or not. Most people don’t use a TV for this purpose. (They don’t fit in your pocket very well! And that 10 mile long power cord tends to get in the way, too. :wink: )

But seriously, I think it really comes down to what the component level code does with the ping response. The binary sensor just tells you whether or not the device responded to the ping(s) in the last update period, whereas the device tracker implements the consider_home timeout period, and updates group.all_devices. I don’t think either of those device tracker features match the use case very well.

I’ll take a look.

9

HI,

well, tbh the highlighted Note would suggest this ping component is explicitly suitable for tracking a phone…? Albeit not 100% reliable on their own. Or is it more of a warning not to do so :wink:

Since I was jumping on a thread, I must apologize for practically hijacking, not my intention, hence the separate thread. My question was for the use case of tracking phones on the network, not your Pocket SmartTv … sorry ;-#

10

I think it has more to do with the use case than the device.

A device tracker is intended for tracking a device, which for devices that can report GPS location is tracking it anywhere, whereas for a device that can’t it’s “tracking” if it’s in the home location or not.

On the other hand, the Ping Binary Sensor is intended to indicate whether or not a device is “online” (as well as a few other related features.)

Given what the two are intending to do, they work differently. So it’s just better to use the one whose design is closer to the intended use case.

Not at all. I think your questions have everything to do with the main point of this topic (although that’s just my opinion – I didn’t create it :slight_smile:), which I believe is what component to use to test if a device is online when there are more than one component that might apply.

11

@Mariusthvdb have you considered setting up a Bayesian sensor for presence detection? It’s a little complicated and the documentation/examples could be better, but it’s been brilliant for me since I set it up. If you’re unfamiliar, it allows you to use multiple factors to determine whether or not something is true e.g. if you’re sleeping or at home.

For my home presence detection I currently use ping, bluetooth occupancy, Google Maps location tracking and the motion sensor in my study since that’s where I spend most of my time at home.

12

HI!
yes, as a matter of fact, I have 2 Bayseians. They seem to work alright, though I am always a bit confused about the settings.

this is mine, please check and see if you can spot anomalies or suggest improvement:

  - platform: bayesian
    name: M home
    prior: 0.4
    probability_threshold: 0.75
    observations:
      - entity_id: 'device_tracker.life360_m'
        prob_given_true: 0.9
        prob_given_false: 0.1
        platform: 'state'
        to_state: 'home'
      - entity_id: 'device_tracker.m_phone' #regular wifi 
        prob_given_true: 0.9
        prob_given_false: 0.3
        platform: 'state'
        to_state: 'home'
      - entity_id: 'device_tracker.telefoon_m_bt' #bluetooth
        prob_given_true: 0.9
        prob_given_false: 0.1
        platform: 'state'
        to_state: 'home'
      - entity_id: 'device_tracker.m_ha'  #homeassistant app
        prob_given_true: 0.9
        prob_given_false: 0.3
        platform: 'state'
        to_state: 'home'
#      - entity_id: 'device_tracker.telefoon'  #disengaged iCloud
#        prob_given_true: 0.8
#        prob_given_false: 0.2
#        platform: 'state'
#        to_state: 'home'
      - entity_id: 'device_tracker.owntracks' #owntracks ;-)
        prob_given_true: 0.7
        prob_given_false: 0.4
        platform: 'state'
        to_state: 'home'

As I read it, the prob_given_true, is the reliability of the on/home/true state of the device, and prob_given_false the off/not_home/false state. Is that correct? Seems to work rather fine like this. Bit of a guess about the values here, but almost 1 means 100% correct, and lower means more chance of incorrect.

What prior: 0.4 means is yet beyond me, I’ve copied this from another configuration. Documentation says The prior probability of the event but which of the events is it referring to… and, prioritized to what?

probability_threshold: 0.75 should be the probability at which the sensor should trigger to on .
I take it that means calculating all devices to a final probability and when that is over .75, it turns On?

All in all, rather a lot of variables to turn the knobs…
thanks for any suggestions you might have!

13

It’s hard to say much about your values without knowing which of the sensors you consider most accurate, but they look pretty good to me. If it’s working for you that’s all that really matters, and you should tweak them if they’re returning false positives/negatives. I just give

I periodically experiment by manually turning some states off in the dev tools and seeing how it affects the probability attribute of the sensor.

‘Prior’ refers to the baseline probability of the state being true i.e. if you’re at home 50% of the time it should be 0.5

probability_threshold: 0.75 should be “The probability at which the sensor should trigger to on”. I take it that means calculating all devices to a final probability and who that is over .75, it turns On.

That’s right.

Here’s mine:

  - platform: 'bayesian'
    prior: 0.50
    name: 'me Bayesian'
    device_class: 'presence'
    probability_threshold: 0.85
    observations:
      - entity_id: 'input_boolean.pixel_bluetooth_occupancy'
        prob_given_true: 0.99
        prob_given_false: 0.10
        platform: 'state'
        to_state: 'on'
      - entity_id: 'device_tracker.google_maps'
        prob_given_true: 0.40
        prob_given_false: 0.15
        platform: 'state'
        to_state: 'home'
      - entity_id: 'binary_sensor.motion_study_occupancy'
        prob_given_true: 0.30
        prob_given_false: 0.20
        platform: 'state'
        to_state: 'on'
      - entity_id: 'binary_sensor.me_phone_ping'
        prob_given_true: 0.60
        prob_given_false: 0.10
        platform: 'state'
        to_state: 'on'

I haven’t tweaked it much myself, but it seems to work ok. It detects when I’m home/away very reliably but I could probably work on the response time for arriving/leaving because some of the sensors are a bit slow to update.

14

aha, that’s interesting, didn’t think of that. Will test with that, though, as with all of these variables, oe couldn’t pin a fixed number being home… still an interesting variable. the others are what Id consider most logic. Bluetooth: when connected is 100% correct, not connected is rather unreliable :wink: etc etc Should probably set that to 1 now that I consider it.

15

Having major problems with the unreliability of Ping and was hoping someone could advise on a possible workaround (other than using multiple device trackers, which is not easy with teenagers who don’t like to be tracked so just switch off things like Life360). I am potentially using it to notify me when a family member arrives home. Is there a “simple” piece of code which would ignore a state change from home to away, or vice versa, if the state had previously changed within, say the last hour? Sorry but am still very new to all this, and really have not got my head around conditions yet, so apologies or what is probably a very basic question.

16

yes there is, you set that in the condition block of an automation:

for the timing part, I use this

      - condition: template
        value_template: >
          {{(now() - trigger.from_state.last_changed).total_seconds() >
             states('input_number.presence_timer')|int}}

which means it check if the time passed since the last trigger is longer than the time set in my input_number. using the input so I can play with perfecting the timing from the frontend and not have to rewrite the automation on each fine-tuning.

preventing the state changes can also be done:

but first, add the most important one:

    condition:
      - condition: template
        value_template: >
          {{trigger.to_state is not none and
            trigger.from_state is not none and
            trigger.to_state.state != trigger.from_state.state}}

which prevents ‘false’ triggers all round. Depending on the entity_id’s (device_trackers) and their behavior, you best be safe and prevent these false triggerings. This says not to trigger when the entity_id’s exist, and also not to trigger when an attribute has changed (think battery) but the state itself remained the same. Happens all the time :wink:

then add something like

      - condition: template
        value_template: >
          {{trigger.to_state.state == 'home'}}

meaning what you write here:

of course, the device_trackers should be reliable them selves. cant trick an unwilling person to be tracked. Shouldn’t really either :wink:

if you use a composite tracker and throw in the most reliable ones, your ‘home’ trigger’ should be rather reliable. As long as you dont only rely on the wifi, which keeps losing connection to safe battery, causing false home comings all the time.

cheers

17

Hi Marius
Thank you so much for trying to help out a HA dumb ass. To prove the description of myself is accurate, I am afraid I still need some help.
My automation is now:

- id: 'XXXXXXXXXXXXX'
  alias: Abc Comes Home
  description: ''
  trigger:
  - entity_id: device_tracker.abc
    platform: state
    to: home
    condition:
       - condition: template
         value_template: >
          {{trigger.to_state is not none and
            trigger.from_state is not none and
            trigger.to_state.state != trigger.from_state.state}}
       - condition: template
         value_template: >
          {{(now() - trigger.from_state.last_changed).total_seconds() >
             states('input_number.presence_timer')|int}}  
                   - condition: template
       - condition: template     
         value_template: >
           {{trigger.to_state.state == 'home'}}
  action:
  - data:
      message: Arrived Home
      title: Abc
    service: persistent_notification.create

In configuration.yaml I added:

input_number:
  presence_timer:
    name: Family Coming Home Presence Timer
    initial: 300
    min: 300
    max: 3600
    step: 120

I then get a config error:

Invalid config for [automation]: [condition] is an invalid option for [automation]. Check: automation->trigger->0->condition. (See /config/configuration.yaml, line 13). Invalid config for [input_number]: invalid slug input_number.presence_timer (try input_number_presence_timer) for dictionary value @ data['input_number']. Got OrderedDict([('input_number.presence_timer', OrderedDict([('name', 'Slider'), ('initial', 300), ('min', 300), ('max', 3600), ('step', 120)]))]). (See /config/configuration.yaml, line 42).
Invalid config for [automation]: [condition] is an invalid option for [automation]. Check: automation->trigger->0->condition. (See /config/configuration.yaml, line 13).
Component error: input_number.presence_timer - Integration 'input_number.presence_timer' not found. Invalid config for [automation]: [condition] is an invalid option for [automation]. Check: automation->trigger->0->condition. (See /config/configuration.yaml, line 13).
Component error: input_number_presence_timer - Integration 'input_number_presence_timer' not found. Invalid config for [automation]: [condition] is an invalid option for [automation]. Check: automation->trigger->0->condition. (See /config/configuration.yaml, line 13).

Quite honestly the error message has no meaning for me, although the new config part does start at line 42. The configuration.yaml file at line 13 does not seem to be anything to do with this - it is simply:

group: !include groups.yaml

Can you please help a little more with the (presumably) multiple mistakes.

And by the way, I fully intend to try to track my 17 year old daughter against her wishes - at least until she has reached her mid 40s.

Thank you
Mike

18

you need to check this carefully, there’s a incorrect -condition: template there, simply delete that line.

will be back for the other issues, must be off a bit for now… sorry

back :slight_smile:

please reload your automations with this edit, and see what error comes back. Line 13 probably isn’t from your configuration.yaml …

fyi, this is my presence_timer:

input_number:
  presence_timer:
    name: Presence timer
    icon: mdi:timer-outline
    min: 0
    max: 1200
    step: 60

so seems alright what you have.

19

Hi Marius
Still a problem. Log now simply says:

Source: config.py:404 
First occurred: 12:15:12 (1 occurrences) 
Last logged: 12:15:12

Invalid config for [automation]: [condition] is an invalid option for [automation]. Check: automation->trigger->0->condition. (See /config/configuration.yaml, line 13).

The notification, after reloading th automations, says:

The following integrations and platforms could not be set up:

automation
Please check your config.

Just to reconfirm, the automation in full is:

- id: '1598685272140'
  alias: Abc Comes Home
  description: ''
  trigger:
  - entity_id: device_tracker.abc
    platform: state
    to: home
    condition:
       - condition: template
         value_template: >
          {{trigger.to_state is not none and
            trigger.from_state is not none and
            trigger.to_state.state != trigger.from_state.state}}
       - condition: template
         value_template: >
          {{(now() - trigger.from_state.last_changed).total_seconds() >
             states('input_number.presence_timer')|int}}  
       - condition: template     
         value_template: >
           {{trigger.to_state.state == 'home'}}
  action:
  - data:
      message: Arrived Home
      title: Abc
    service: persistent_notification.create

Thank you again for trying to help

20

Sorry one more thing. When I run the Check Configuration, I get:

Configuration invalid 
 Invalid config for [automation]: [condition] is an invalid option for [automation]. Check: automation->trigger->0->condition. (See /config/configuration.yaml, line 13).