"Glances" sensor module - what's the formula?

Configuration
1

Hey all,

Since I can’t (yet) get my Harmony to work, I’m playing with other stuff. Like sensors on my basement servers.

I chose “Glances”, because it was free, runs on Linux, and seemed like it would give me a decent amount of data. But for the life of me, I can’t figure out the “formula” used to create the sensor/entity names for display in Lovelace.

In configuration.yaml, I have this:

sensor:
  - platform: glances
    name: victor
    host: 192.168.1.32
    resources:
      - 'mem_used'

“victor” is the machine’s name and that’s the correct IP address. Under resources, that’s one of the JSON values you get if you query

192.168.1.32:61208/api/2/mem

(the docs are a little inaccurate here; I’ll fix them up once I can make this work)

In Lovelace, I have a simple card with this code:

- type: gauge
    entity: sensor.victor_mem_used
    unit_of_measurement: "%"
    title: Mem Usage

I’m almost certain there’s some sort of secret formula that builds the entity name from the sensor entry. But I can’t figure out what it is. What’s shown in the above example is clearly wrong, because it shows up as a yellow error.

So… anybody know the secret?

2

These are the sensors I use for my glances setup:

- platform: glances
  host: 192.168.7.15
  name: IntelNUC
  resources:
    - 'disk_use_percent'
    - 'disk_free'
    - 'memory_free'
    - 'processor_load'

As you can see, I’m only using four of the ones being shown in the documentation here: https://www.home-assistant.io/components/sensor.glances/

And that’s how I show them in Lovelace:

      - type: entities
        title: IntelNUC
        entities:
          - entity: sensor.intelnuc_cpu_load
          - entity: sensor.intelnuc_disk_free
          - entity: sensor.intelnuc_disk_used
          - entity: sensor.intelnuc_ram_free

If you go to the /dev-state tab you can find the sensors by filtering by the name of your device as defined in the configuration.yaml.

Not the most straightforward process, but that’s how I got it to work

1 Like
3

It seems like it would be simpler (from a backend coding perspective) to just allow access to the JSON data, rather than re-mapping it to another value.

Let me try one or two of your sensors and I’ll be right back.

Thanks so far!

4

Check for the entity name in the dev tools (states) <> and see what the magic name is…

I use the systemmonitor platform for this… is there any reason glances is better?

5

I use glances for accessing info from other machines, not the one HA is running on.

1 Like
6

Right. I’m trying to monitor my two Frankenservers in my basement. They’ve got (I think) 12TB of storage between them. They hold all my media and similar goodies.

chairstacker: I tried your entries letter-for-letter (except for the machine name, naturally) and still got errors.

I’m going to try breaking this out into the separate “sensors.yaml” file and see if it behaves better. If not, there are other FOSS monitoring tools I can try.

Thanks for your help.

7

What do you see in the /dev-tab once you filter for sensor.victor?

8

Hm, I get nothing. That would explain a lot.

Let me keep poking around. I have that old-time programmer’s feeling that I’ve missed something stupidly obvious.

9

Do you get the glances interface when you go to http://192.168.1.32:61208/

10

Yep. Not sure I know what’s up, but I’ve got to move on to something else for a few hours…

I’ll work on this again in the morning.

11

Good luck - and let us know how it’s going!

12

I think I’ve narrowed it down to the version of the Glances API being used. I’m running HA on a Raspberry Pi. Anything sent to a Glances service as a version 3 request will succeed (according to curl), but a V2 request will always fail. Other platforms might not be so touchy.

Test with curl -X <server:port>/api<version>/(mem|disk|}whatever)

According to the HA docs, it defaults to V2 requests, so you need to put version: 3 in your sensor configuration.

But that’s only half the story. HA’s Glances “client” has a mind of its own. I’ve looked at the source and it’s weird. It’s taking some of the returned JSON values and spitting them back out for us. Others are just dropped, even though they contain perfectly valid data. The Glances doc page is horribly unclear on this matter. Even worse, they’re renaming the return value (“use” instead of “used”, for example).

This sensor client badly needs to be rewritten, and in a more sensible way. my guess is that they picked some of the JSON to parse so they could assign an MDI icon to it, so hooray for good intentions. But otherwise, it’s kind of a mess.

1 Like
13

Thanks, @bundito to look into this.
The versions I have running are mostly V2, except one Pi3 that’s running on V3. I haven’t been able to connect to that one, but wasn’t too bothered about it, so I guess your explanation makes sense. I’ll give that another try or upgrade all my installs to V3 so it’s consistent.

And yes: the fact that the name for the sensor definition in the configuration file is different from what the sensor is actually called then is a pain - once I’d figured it out several months ago, though, it was not an issue any more :wink:

14

It seems like a new server install of Glances is only going to give out v3 answers. Anything formatted as /api/2/xxx is going to fail. Mix that with the weird remapping of returned results and the Glances module is pretty useless. And that’s a shame, because even though I’d never heard of Glances before, it seems like it’s got a ton of potential and power.

If I ever get time, I’ll rewrite this client module, but it won’t be quite as friendly. It’ll return the value you ask it for, period. Users will be encouraged to test extensively to get the numbers they want. Sensor names will be the exact name of the api query; no fooling around with renaming them.

It may not end up the friendliest of modules, but at least the bloody thing will work.

15

I like Glances, looking forward to the re-write :+1:

I’ll try to get my V3 machine into HA with the version: 3 parameter, and if that works, I will move my other machines onto V3 as well.

I could keep one machine on V2 for test purposes, though, if you have a timeline in mind for the re-write.

16

Unfortunately, I can’t give you a timeline. In reality, I’m a developer for KDE and my programming/tech tasks over there should take priority. But instead, I’ve taken too much time off playing with Home Assistant. Gotta get back to “work”. :slight_smile:

17

Unterstood - I will see how long I can resist upgrading even the last machine to V3 :grin:

18

You can simply use a REST sensor instead and modify it to your needs. Here’s a few of the ones i’m using

- platform: rest
  name: HDD Temp
  resource: http://insert_your_ip:61208/api/3/hddtemp
  value_template: '{{ value_json[0]["value"] }}'
  unit_of_measurement: "°C"
- platform: rest
  name: Nasbox system disk free
  resource: http://insert_your_ip:61208/api/3/fs
  value_template: '{{ value_json[0]["free"] | filesizeformat }}'

if you have more than one HDD you need to check json output with curl and see in what order are they displayed. the [0] is for the first value, [1] would be for the second one, etc…

19

Hey, cool. This means I can code my display quickly and safely, without fooling around with the HA internals.

I started tinkering with the Glances sensor code yesterday and I think there’s maybe one value that works and gives a result. And that’s not even considering the documentation page, which makes the situation even worse.

20

Sorry, man. I have to retract my “solve” for your answer. Mainly because your API calls don’t work. “hddtemp” isn’t a valid request. Maybe you were just typing something from memory, but your example still doesn’t work.

I’ve been trying to do this with the stupid-simple test of ‘uptime’ and still can’t get the sensor to show up.

Man oh man is this sensor pissing me off. It’s got so much potential but the HA community aren’t showing it any love. I don’t get that.