Additional Status

[smeinecke]

Recently installed your extension - everything works and I am very happy - thank you for your work!

Unfortunately, as mentioned in Issue #3, I had the problem that the battery of my Pulse was empty, because the communication between my Pulse and Bridge is rather "bad" (2 "Feuerschutztüren" in the basement!) and thus the Pulse sends constantly on 100% power.

Do you think it would be possible to output the status information from /metrics.json?node_id=1 in addition to the actual meter data, so that I can monitor the 'node_battery_voltage'?

{
  "$type": "node_status",
  "node_status": {
    "product_id": 49344,
    "bootloader_version": 17563650,
    "meter_mode": 3,
    "node_battery_voltage": 3.127,
    "node_temperature": 22.51,
    "node_avg_rssi": -72.746,
    "node_avg_lqi": 186.438,
    "radio_tx_power": 190,
    "node_uptime_ms": 167656940,
    "meter_msg_count_sent": 75,
    "meter_pkg_count_sent": 237,
    "time_in_em0_ms": 8405,
    "time_in_em1_ms": 30,
    "time_in_em2_ms": 291717,
    "acmp_rx_autolevel_300": 146,
    "acmp_rx_autolevel_9600": 164
  },
  "hub_attachments": {
    "meter_pkg_count_recv": 237,
    "meter_reading_count_recv": 75,
    "node_version": "1007-56bd9fb9"
  }
}

[marq24]

Of course this is possible... and I'll see what I can do in the next couple of days

[marq24]

Actually I have an alternative solution for this request - simply make use of the REST Integration in order to get any additional value you would like to have as entity - like this one here

In order to archive this do the following: (I will add this to the readme shortly)

---

Additional entities to get status information about your Tibber Pulse itself

Beside the data that the Tibber Pulse is reading from your electricity meter, the device is also provide additional information about its own status. Since the assumption is that you want to read this additional status information with a much lower update-interval (less frequent) the usage of a REST-Entity template a (IMHO) simple way to archive your goal.

REST-Template in your HA configuration.yaml

Check if you have already a sensor section in your configuration.yaml file - if there is none - create one on as top level entry like this:

sensor:
  - platform: ...

Add in the sensor section of your configuration.yaml file the following content: sections with [ CHANGE_ME:xxx ] have to be modified to your requirements. E.g. assuming your assuming password is 55AA-CC21, then you have to replace [ CHANGE_ME:YOUR-PWD ] with just 55AA-CC21

  - platform: rest
    name: [ CHANGE_ME:Tibber Prices ]
    unique_id: [ CHANGE_ME:tibber_prices ]
    resource: http://admin:[CHANGE_ME:YOUR-PWD]@[CHANGE_ME:YOUR_IP]/metrics.json?node_id=1
    method: GET
    json_attributes_path: "node_status"
    json_attributes:
      - node_temperature
      - node_avg_rssi
      - radio_tx_power
      - [ CHANGE_ME: add as many of the node_status attributes you want to meassure ]
    value_template: "{{ value_json.node_status.node_battery_voltage | float }}"
    # for update every 5min (60sec * 5min = 300)
    # for update every 15min (60sec * 15min = 900)
    # for update every 24h (60sec * 60min * 24h = 86400)
    scan_interval: 900
    headers:
      Content-Type: application/json
      User-Agent: REST
    unit_of_measurement: [ CHANGE_ME:A_UNIT_HERE ]

Here is a complete example assuming the password is 55AA-CC21 the IP is 192.168.2.213, and you want to capture the node_battery_voltage as main entity information and all other children of the node_status as additional attributes of the entity that will be requested every 5 minutes:

  - platform: rest
    name: Tibber Pulse Metrics
    unique_id: tibber_pulse_metrics
    resource: http://admin:55AA-CC21@192.168.2.213/metrics.json?node_id=1
    method: GET
    json_attributes_path: "node_status"
    json_attributes:
      - node_temperature
      - node_avg_rssi
      - node_avg_lqi
      - radio_tx_power
      - node_uptime_ms
      - meter_msg_count_sent
      - meter_pkg_count_sent
      - time_in_em0_ms
      - time_in_em1_ms
      - time_in_em2_ms
      - acmp_rx_autolevel_300
      - acmp_rx_autolevel_9600
    value_template: "{{ value_json.node_status.node_battery_voltage | float }}"
    scan_interval: 300
    headers:
      Content-Type: application/json
      User-Agent: REST
    unit_of_measurement: V

---

Please let me know, if this is sufficient in your point of view - TIA

[smeinecke]

Wow, I'm a little overwhelmed right now that you've gone to all this trouble just so I can check it out. Thank you very much for your time and help! Yes, I will try this, looks like a very good solution for my problem :)

[marq24]

Wow, I'm a little overwhelmed right now that you've gone to all this trouble just so I can check it out...

you are welcome - HA is a very powerful eco-system - but IMHO the learning curve is extremely steep - I can't expect that every user is on the same level... So I try to document in a way that I have wished for myself when I started with HA at the beginning of this year...

So when the provided docu will be sufficient for you (to pick it up correctly and adjust it to your local requirements) then I am pleased - and the time is well invested... Please let me know, if you have everything up and running to your expectations - and if there had been misinterpretations (something does not work for you) - please provide this feedback, so I can enhance the documentation...

[smeinecke]

Again: thank you very much. It's working fine as expected and I can now monitor the voltage (and other attributes).

Btw. there is a typo in your example:

resource: http://admin:[CHANGE_ME:YOUR-PWD]@http://[CHANGE_ME:YOUR_IP]/metrics.json?node_id=1

Duplicate "http://" which resulted in a: Platform rest not ready yet: [Errno -5] Name has no usable address; Retrying in background in 30 seconds on my first try :D

---

As I did not use the rest sensor before: is possible to reformat the output of the other attributes too? so, the node_temperature is shown as °C and/or node_uptime_ms is shown in hours/days?

[marq24]

Btw. there is a typo in your example:

resource: http://admin:[CHANGE_ME:YOUR-PWD]@http://[CHANGE_ME:YOUR_IP]/metrics.json?node_id=1

Duplicate "http://" which resulted in a: Platform rest not ready yet: [Errno -5] Name has no usable address; Retrying in background in 30 seconds on my first try :D

THANKS! - corrected that

As I did not use the rest sensor before: is possible to reformat the output of the other attributes too? so, the node_temperature is shown as °C and/or node_uptime_ms is shown in hours/days?

I would go the route to generate a template Sensor for that [https://www.home-assistant.io/integrations/template/] - I haven't tried myself - but I assume, that you can create state that reading the attribute value of using your new sensor entity as source...

You can use https://[YOUR-HA-IP]/developer-tools/template to get a working template (for reading the sensor.attribute)... So once you managed that, you create for every attribute a separate template sensor. ["obviously" most of that have to be created in YAML in your configuration.yaml file]

[ProfDrYoMan]

But still you will include this into the integration so there is no need to manually add it now and just wait for you?

PS. You mentioned that there might be a buffer issue in the bridge webserver. Does that possible impact.

[marq24]

But still you will include this into the integration so there is no need to manually add it now and just wait for you?

Actually even if my first reaction was to think about extending the current integration I have dropped that train of thought. The main reason for this (not planing to integrate it and use simply the REST Integration instead) is, that update interval for the status information should be (IMHO ) way less frequent then power data readings... Personally I don't need the battery status ever 2 sec...

Making use of the REST Integration with the provided YAML section is IMHO a good compromise for someone who want's this data...

IF I am going to change my mind, and adding this to the default integration in the future (probably cause I am board and the weather is bad), then you don't loose too much, if you add now the entity manually in your config... Or does I miss something?!

PS. You mentioned that there might be a buffer issue in the bridge webserver. Does that possible impact.

impact on what? [you mean, if the additional request to the bridge (to fetch the status) can cause interference with the integration requests?] - Well "of course" it could - but I expect the root of my "shared buffer"-Theorie more inside the TibberPulse<->TibberBridge communication - I would expect, that the "Default ESP-Webserver Code" is well tested...

[smeinecke]

You can use https://[YOUR-HA-IP]/developer-tools/template to get a working template (for reading the sensor.attribute)... So once you managed that, you create for every attribute a separate template sensor. ["obviously" most of that have to be created in YAML in your configuration.yaml file]

Ah, ok. I will try that.

impact on what? [you mean, if the additional request to the bridge (to fetch the status) can cause interference with the integration requests?] - Well "of course" it could - but I found expect the root of my "shared buffer"-Theorie more inside the TibberPulse<->TibberBridge communication - I would expect, that the "Default ESP-Webserver Code" is well tested...

if I have understood correctly, the metric values are cached anyway and are only output asynchronously - I had also received metric values when the Pulse was not connected / had no batteries. Then there should be no problem with the communication, right?

[ProfDrYoMan]

Ok. Thanks. Heading towards implementing the REST stuff. Your arguments also fit.