Speedtest Ping replacement sensor

tom_l · May 14, 2019, 7:06am

Not quite. I want to calculate a percentage used (of the total) so it lines up with the days used, but that can wait until I get it working.

DavidFW1960 · May 14, 2019, 7:07am

It can be slow updating… can be up to 40 minutes behind. Tapping on the bar should refresh as well… My rainmeter meter is similarly slow. ABB only update every 15 mins and then it isn’t available immediately

tom_l · May 14, 2019, 7:08am

Ah ok. I’ll keep an eye on it.

DavidFW1960 · May 14, 2019, 7:10am

I think it’s because I’m comparing a number with a string… probably need to convert the var to a string… and I need to add used to remaining to get the limit. I’ll look at how to best fix this and let you know.

tom_l · May 14, 2019, 7:20am

It is updating. Like you said, just not every 15 minutes.

tom_l · May 14, 2019, 7:37am

Or maybe not:

2019-05-14 17:30:05 ERROR (MainThread) [homeassistant.components.shell_command] Error running command: `/bin/bash /config/abbusage/abbusage_ha.sh`, return code: 6
NoneType: None

If I were to remove this how do I remove the generated sensor?

DavidFW1960 · May 14, 2019, 7:43am

did you use backticks? it’s a standard single quote. The sensor will disappear if you restart HA…
I just have
abbusage: /bin/bash /config/abbusage/abbusage_ha.sh no quotes for the shell_command. Have not seen that error… maybe if it does that it can’t connect. Are you on Hassbian or hass.io?

tom_l · May 14, 2019, 7:50am

The error disappears if I use single quotes (not backticks). It appears when I remove the quotes and restart.

Hassio NUC image.

I just put the quotes back. All appears to be well (other than the plan limit).

DavidFW1960 · May 14, 2019, 8:01am

Yeah… well I’m comparing a number to a srting and can’t quite get that right yet but I’ll solve that and let you know. I might even see if I can get the usage bar graph as well if you don’t beat me to it.

clyra · May 14, 2019, 11:54am

hey guys,

I’m used to do network monitoring for a living, and I may have a tip or two. I usually like to ping a few upstream routers to detect network problems. You can use traceroute (tracert on windows) to discover those routers. Like was said before 8.8.8.8 is what we call a “anycast” address and may be used by different servers on the internet and the routing protocol (BGP) chooses the one “near” to you. You may (or not) see this using traceroute. It may completely change the path to reach it during the day.
One popular tool to graph ping latency/jitter is smoking.. Shouldn’t be too difficult to put it on docker and import the graphs.
Here in Brazil, the NIC.BR (our regional internet register) has a cool project called SIMET which is like a speedtest on steroids :). They have servers on various IX (Internet eXchange points) across the country. And they also have something called the “simet box” which is a modified firmware for APs with the simet software built in. The box keeps measuring the quality of your internet. I ran one on a old TP-link and is very helpful to discover if your ISP is delivering what you contracted. I wonder if there are similar projects on US or Eu.

tom_l · May 14, 2019, 1:11pm

I beat you to it. Sort of. I created individual template sensors from your abb sensor attributes and a few extras. This is so I can see a history graph of some of the sensor attributes.

It’s easy to see if I’m going to go over my plan - I dont actually expect this to happen it should settle down in a couple of days - it was GoT day yeasterday

I still have a bit of prettying up to do (icons and maybe hide a few less used stats with a fold.

The main problem I have is that your sensor attributes aren’t persistent through a restart. Leading to some divide by zero errors on restart and this sort of graph trouble:

This sensor is just:

- platform: template
  sensors:
    used_gb:
      friendly_name: Used
      entity_id: sensor.abb_usage
      value_template: "{{ ( state_attr('sensor.abb_usage', 'usedMb') | float / 1000 ) | round(2) }}"
      unit_of_measurement: "GB"

Is it possible to manually include your sensor so that it persists through restarts?

DavidFW1960 · May 14, 2019, 10:47pm

Divide by zero errors? I have not seen any errors at all. That is weird. Is it your template sensors causing that?

I’ve never thought the history was that important - the sensor I create doesn’t even have a state (because that screws up the template card I’m using (displays extraneous data)

It’s possible to do it such that the script creates everything as an individual sensor but I was trying to avoid that as well as I didn’t want the history filling up with useless shit lol… Also, check your card title for a typo.

I was originally using MQTT to get the data in… it created the same sensor and attributes… it’s potentially persistent across reboots - it’s in the zip file in the repo but I have changed the script a lot since then and stripped out the config stuff as well. I can probably pretty easily do a script that uses a setup script as well if you think that would be useful? (Note: that won’t work on HassOS as there is no access to mosquitto_pub in the HA container)

I am going to add a plan limit attribute today as that will solve the issue I found yesterday and it’s probably the best way to fix that - i’ll Let you know when I have a new script.

tom_l · May 14, 2019, 11:11pm

Yes my sensors are causing it. You won’t see the errors. You are only using templates in the Lovelace card. By the time the system starts up and you can navigate to the card the abb sensor is initialised.

My template sensors on the other hand are relying on the abb sensor (and it’s attributes) being available right from start up. It is not available until a short time after start up.

Attributes all in the one sensor are fine. I just need the sensor to be permanent and not recreated every restart.

I looked at your MQTT option but noted you said it was not compatible with Hassio.

Yeah it was a rush job before bed time. I’ll fix it up today if I get a chance.

DavidFW1960 · May 14, 2019, 11:26pm

I know it’s being pedantic but it’s HassOS - it works fine with Hass.io just not if the base OS is HassOS because they don’t provide mosquitto-tools.

Is it possible to have a delay or a test in your sensor for a zero value and then try again? Something like. That? Did you try adding the entity_id in the sensor so it knows it needs the ABB sensor? (Like we do for other template sensors)?

tom_l · May 14, 2019, 11:44pm

I was going on memory of what I read. Apologies. The mix-up is one of my pet-peeves too.

Yes, I always add the entity_id to my template sensors. How would I add a delay in a template?

- platform: template
  sensors:
    used_gb:
      friendly_name: Used
      entity_id: sensor.abb_usage
      value_template: "{{ ( state_attr('sensor.abb_usage', 'usedMb') | float / 1000 ) | round(2) }}"
      unit_of_measurement: "GB"

DavidFW1960 · May 15, 2019, 12:25am

No idea lol… What about testing if it’s zero?

tom_l · May 15, 2019, 1:16am

I can prevent the error by applying a | max filter for the template denominators so that the minimum is never 0. However this still puts spikes in the history data on restart.

I’ve got my card looking how I want:

DavidFW1960 · May 15, 2019, 2:20am

Nice Tom… My lovelace card was only an example anyway although I do want to fix it so it puts the correct limit and will do that by adding an attribute for that today.

tom_l · May 15, 2019, 2:29am

Thanks heaps for making the sensor David.

DavidFW1960 · May 15, 2019, 3:45am

Tom: if you wouldn’t mind, can you download the abbusage_ha.sh script again and run it and check that you now have an extra attribute allowanceMb in the sensor? And obviously that it correctly shows your Data Allowance in Mb please?