[BUG] Wrong total consumption

[TheCherry]

Environment

• ShellyForHASS release with the issue: 0.3.3
• Last working ShellyForHASS release (if known): 2021.12.4
• Home Assistant Core release with the issue:
• Operating environment (Home Assistant/Supervised/Docker/venv): Supervised VM

I use a Shelly Plus 1PM with FW 0.9.1. The "Total consumption" in HASS is totaly wrong, I have the Shelly running since few days by 1165 W and the total consumption shows only 0.81 kWh.

[danygi79]

I have same problem at Shelly Pro 4PM. all other device show this value correct.

[mdzmdz]

I have the same issue, also Shelly Pro 4PM.

[MaxRink]

I can also see thais behaviour on all my "plus" devices, the consuption is off by a huge factor

doesnt match with

[mdzmdz]

I used MQTT explorer to monitor the traffic between HA and MQTT server The results are strange:
{"id":0, "source":"MQTT", "output":true, "apower":9.1, "voltage":229.9, "current":0.198, "pf":-0.51, "aenergy":{"total":8711.160,"by_minute":[15.500,23.776,23.250],"minute_ts":1647977137},"temperature":{"tC":32.0, "tF":89.6}}

Power 9,1W and voltage 229,9 implies current 0,03958A, not 0.198. Power and voltage are as expected, so the current must be wrong. Also, the total consumption seems to be wrong. I calculated difference in the 20min interval.
{"id":0, "source":"MQTT", "output":true, "apower":8.9, "voltage":230.5, "current":0.198, "pf":0.00, "aenergy":{"total":8711.669,"by_minute":[15.894,25.089,24.170],"minute_ts":1647978340},"temperature":{"tC":31.5, "tF":88.8}}
It should be about 3Wh, but the difference is only 0,509. It is not a minute value, because the aenergy value is increasing.

[mdzmdz]

MQTT sends correct data in terms of total consumption. I approved this with several independent meter. I do not know why integration incorrectly calculates the result, but it seems that some changes to const.py could help. I am working on it.

[mdzmdz]

Fixed using native Shelly integration. configuration.yaml must be edited.

switch:

• platform: mqtt
  name: "Shelly Pro 4PM 1 - mdz"
  unique_id: "shellypro4pm-c8c9a3ef5014-switch-0"
  command_topic: "shellypro4pm-c8c9a3ef5014/rpc"
  payload_on: '{"id": 1, "src":"homeassistant", "method": "Switch.Set", "params": {"id": 0, "on": true}}'
  payload_off: '{"id": 1, "src":"homeassistant", "method": "Switch.Set", "params": {"id": 0, "on": false}}'
  state_topic: "shellypro4pm-c8c9a3ef5014/status/switch:0"
  value_template: "{{ value_json.output }}"
  state_on: true
  state_off: false
  qos: 1

sensor:

• platform: mqtt
  name: "Total Consumption Shelly pro 1"
  unit_of_measurement: "kWh"
  state_topic: "shellypro4pm-c8c9a3ef5014/status/switch:0"
  value_template: "{{ value_json.aenergy.total | multiply(0.001) | round(3) }}"
  state_class: total_increasing
  device_class: energy

• platform: mqtt
  name: "Voltage Shelly pro 1"
  unit_of_measurement: "V"
  state_topic: "shellypro4pm-c8c9a3ef5014/status/switch:0"
  value_template: "{{ value_json.voltage }}"

• platform: mqtt
  name: "Power Shelly pro 1"
  unit_of_measurement: "W"
  state_topic: "shellypro4pm-c8c9a3ef5014/status/switch:0"
  value_template: "{{ value_json.apower }}"

• platform: mqtt
  name: "Current Shelly pro 1"
  unit_of_measurement: "A"
  state_topic: "shellypro4pm-c8c9a3ef5014/status/switch:0"
  value_template: "{{ value_json.current }}"

[mlq]

I think the root cause of this issue is that pyShelly divides the obtained data by 60 and, thus, converting from Wh to Wm. ShellyForHass assumes that the unit is Wh.

I have written a small patch for pyShelly that changes this behavior for Gen 2 devices and the values look more plausible. However, I am not experienced with this code base. While all the reports here suggest that it only affects Gen 2, I would assume that it might apply to the previous generation as well but I don't have any device to test that. Maybe someone can verify this and we can send the patch as a pull request.

[mdzmdz]

I think the root cause of this issue is that pyShelly divides the obtained data by 60 and, thus, converting from Wh to Wm. ShellyForHass assumes that the unit is Wh.

I have written a small patch for pyShelly that changes this behavior for Gen 2 devices and the values look more plausible. However, I am not experienced with this code base. While all the reports here suggest that it only affects Gen 2, I would assume that it might apply to the previous generation as well but I don't have any device to test that. Maybe someone can verify this and we can send the patch as a pull request.

It is not Shelly for HASS, it is e different integration. Is it correct?

[mlq]

ShellyForHASS is using pyShelly as a dependency to communicate with the devices.

In my installation, version 0.3.5 is installed to /usr/local/lib/python3.9/site-packages/pyShelly but a local installation can be set with the debug_local_py_shelly configuration option for ShellyForHASS.

[andrepcg]

I think the root cause of this issue is that pyShelly divides the obtained data by 60 and, thus, converting from Wh to Wm. ShellyForHass assumes that the unit is Wh.

I have written a small patch for pyShelly that changes this behavior for Gen 2 devices and the values look more plausible. However, I am not experienced with this code base. While all the reports here suggest that it only affects Gen 2, I would assume that it might apply to the previous generation as well but I don't have any device to test that. Maybe someone can verify this and we can send the patch as a pull request.

I believe this is exactly what's happening. I divided the reported total consumption in HA by 60 and now it matches the aenergy.total attribute

[pstzh]

Possible and simple solution - Specific device setting in configuration.yaml for the affected devices:
settings:
total_consumption: { decimals: 2, div: 16.66667, unit: 'kWh' }

[mlq]

The pull request has been merged and should be included in tomorrow's release.

[hakana]

Possible and simple solution - Specific device setting in configuration.yaml for the affected devices: settings: total_consumption: { decimals: 2, div: 16.66667, unit: 'kWh' }

Better to install new release now ;)