I would like to monitor the free hard disk space on my Pi-Hole with HA. To do this I created one line script on the Pi that sends messages of the available free space on the SD card in the following format:
No, I have tried it with several values (sending different values manually using mosquitto_pub -h ip.address -t viktak/spiti/devices/pihole -m "{\"DiskFreeSpace\":15000}")
The problem is with the argument of below.
As it is in this example, I would expect to trigger when the number received becomes less than 1000000 (one million). However, in reality, it does not trigger then (I tried it with a few 6 digit numbers), and that is what threw me off at the beginning.
When I tried it with increasingly smaller numbers, I found out that it does trigger, but not when it goes below 1000000, but when it goes below 1000. Strange.
Could someone confirm this is expected behavior because some obscure reason? If not, Iāll open an issue in github.
First I set the below attribute to 1 million as mentioned earlier, thatās when the real limit was at 1000.
Now I started experimenting putting lower values to below, and I found that putting 100000, 10000 or 1000 made absolutely no difference, the real turning point stayed at 1000.
Once I started lowering that, it started to behave correctly at 100 and 10.
Now I am guessing it has to do with some variable sizesā¦
I think it is still a bug though as it shouldnāt matter how I format a number for displaying, the value of it should be the same. I will report it on Github.
Iām not sure if this should be reported on Github. The value template of your PiHole sensor applies the format you want and at this point itās not a number anymore but a string. However Iām not really sure about this.
I didnāt read through the whole topic (I had bookmarked it and planned to provide input sooner but got busy ), but just an FYIā¦ For the value_template of the numeric_state trigger, the new state (i.e., the State Object) that caused the trigger to re-evaluate is provided as a variable named state. So the following will work, too, and is probably better (in that it is using the exact state that caused the automation to re-evaluate the trigger.) Also, the trigger will convert the value to a float, so no real need for the int filter in your template (unless you really want the comparison to be done as an int instead of a float.) So, Iād suggest: