Handling -ve export values in home assistant (hassio)
Using the template from here - https://gist.github.com/ndfred/5bb51b567f8cfaf2bb06da6393169321
Which is working except when I am exporting the grid I get these sort of values when for example IHD is showing -1.000
Does anyone know how to adjust the template so its reads correctly on hassio?
Thanks!
Comments
That crazy big number is -768.
What do you get if you run Fetch data from a Hildebrand Glow device over MQTT (github.com)
Hi Dougie,
Shows below**. The IHD and App resolve the negative number correctly as -849
**
Reading at 09:27:41
* electricity consumption: 4294966447W
* daily electricity consumption: 7.407kWh
* weekly electricity consumption: 100.534kWh
* monthly electricity consumption: 52.239kWh
* electricity meter: 3912.271kWh
Full payload: {
"elecMtr": {
"0702": {
"03": {
"01": "00000001",
"04": "00",
"02": "000003E8",
"07": "1013008838187",
"03": "FB",
"08": "",
"00": "00",
"06": "00"
},
"00": {
"07": "00000000",
"01": "000000015196",
"00": "0000003BB24F",
"14": "02",
"02": "000000000000"
},
"04": {
"01": "001CEF",
"40": "00CC0F",
"30": "0188B6",
"00": "FFFFFCAF"
},
"02": {
"00": "10"
}
},
"0705": {
"00": {
"01": "FFDA410A",
"00": "0084"
}
},
"0708": {
"01": {
"01": "Bulb"
}
}
},
"gasMtr": {
"0702": {
"00": {}
}
},
"ts": "2021-04-04 08:27:41",
"hversion": "GLOW-IHD-01-1v4-SMETS2",
"time": "6069787D",
"zbSoftVer": "1.2.5",
"gmtime": 1617524861,
"pan": {
"rssi": "D0",
"status": "joined",
"nPAN": "00",
"join": "0",
"lqi": "D0"
},
"smetsVer": "SMETS2",
"ets": "2000-01-01 00:00:00",
"gid": "70B3D521E000CAD1"
}
You need to get the nice folks at Glowmarkt to look at this, send an email to support@glowmarkt.com
"04": { "01": "001CEF", "40": "00CC0F", "30": "0188B6", "00": "FFFFFCAF" },That 0702.04.00 "InstantaneousDemand (signed): current consumption" value 0xFFFFCAF is out of range and there's nothing you can do as a data consumer to fix it.
Will do, shall post back with outcome.
The instant reading in the packet is a signed hex value (2s complement). This means that when you convert it to decimal, a simple hex to decimal will not do the trick.
If you go here: (https://www.rapidtables.com/convert/number/hex-to-decimal.html)
and enter the number FFFFF8A5, you will see -1883 as the correct result which is in the second row (Decimal from signed 2's complement).
To do this in javascript you can refer to this:
https://stackoverflow.com/questions/13468474/javascript-convert-a-hex-signed-integer-to-a-javascript-value
That doesn't address the problem. The problem is that consumption is ALWAYS a positive value.
Appreciate the explanation Alex but was expecting the API to handle the transformation and provide a -ve as I see on the Glow IHD. I guess will have to handle it myself.
You shouldn't need to handle negative numbers, the consumption numbers can *never* be negative (unless you've got solar being exported). There's an error in your data (from the Glowmarkt/Hildebrand API), that's what needs to be fixed.
"That doesn't address the problem. The problem is that consumption is ALWAYS a positive value."
As Alex says that number (0702 04 00) is the instant consumption which is negative if you are exporting.
This is direct from the meter (other behave different and trap the number at zero) and there is nothing wrong with either the mqtt feed or the api.
It is a signed hex number and should be interpreted as such.
Hi @jklondon,
As Clive mentions above the MQTT feed is directly the data we receive from the CAD with minimum intervention, if you use the API we do handle the transformation of the values to decimal.
The trouble is that what being delivered conflicts with the SEP (Page 248).
https://zigbeealliance.org/wp-content/uploads/2019/12/docs-07-5356-19-0zse-zigbee-smart-energy-profile-specification.pdf
0x0402 CurrentDayConsumption Received Unsigned 24-bit Integer 0x000000 to 0xFFFFFF Read Only - O
Unsigned can't go negative. So someone is destroying the data in transit.
it's 04 00 not 04 02
that we were talking about.
OK so that is a signed value and the data consumer needs to handle the two's complement value correctly in their code.
Working on trying to transform this so it renders correctly in Home Assistant using their templating engine (jinja2) - struggling to see how to support two's complement correctly. The below only works for +ve values. Any pointers appreciated.
value_template: "{{ value_json['elecMtr']['0702']['04']['00']|int(base=16) }}"Hi @jklondon - I had the same issue and I ended up creating 2 sensors with the config below. No doubt it could be converted into one but this works for me. Hope its helps if you still haven't sorted it.
- platform: mqtt
name: " Raw Instant Elec"
state_topic: "SMART/HILD/xxxxxxxxxx"
unit_of_measurement: 'watts'
# This is a signed Hex number and when it is negative it currently gives an incorrect high reading.
value_template: "{{ value_json['elecMtr']['0702']['04']['00']|int(base=16) }}"
#icon: 'mdi:flash'
icon: 'mdi:transmission-tower'
# # this sensor converts the raw value to a signed value (so negative when exporting)
- platform: template
sensors:
current_grid_import_smart_meter:
friendly_name: "Current Grid Import (Smart Meter)"
unit_of_measurement: 'watts'
value_template: >-
{% if states('sensor.raw_instant_elec') | int > 30000 %} {{ states("sensor.raw_instant_elec")|int - (2**24) }}
{% else %} {{ states("sensor.raw_instant_elec") }} {% endif %}
Hi @jklondon - in case you’re still working on this, I updated the gist you originally referenced to handle negative import values (i.e. exports) in Home Assistant.
The TL;DR is:
value_template: "{% if value_json['elecMtr']['0702']['04']['00']|int(base=16) > (2**31) -1 %} {{ value_json['elecMtr']['0702']['04']['00']|int(base=16) - 2**32 }} {% else %} {{ value_json['elecMtr']['0702']['04']['00']|int(base=16) }} {% endif %}"Hope that helps!
Thanks for this. This value template works pretty well for me. I've had to make a small adjustment to the template, putting in absolute values rather than power values.
I'm working on a SMETS1 Secure 100 meter, which may be the difference.
For me, in Home Assistant 2**31 doesn't work. My values are 2^23 and 2^24. If I put in the absolute values of these:
value_template: > {% if value_json['elecMtr']['0702']['04']['00']|int(base=16) > 8388607 %} {{ value_json['elecMtr']['0702']['04']['00']|int(base=16) - 16777216 }} {% else %} {{value_json['elecMtr']['0702']['04']['00']|int(base=16)}} {% endif %}This all works a treat.
@meroberts Thank you so much!
I have been trying to get this working for ages and stumbled across this and voila, I now get actual negative readings (-16w) versus 16,000,000w!
The SMETS1 Meter is what I have and @smudger4 version didn't work but this iteration did so definitely specific to the meter.
Just need to get the export aspect working now (I get a 0 reading when when exporting!)