[Sensor template + utility meter] Error while setting up utility_meter platform for sensor


I’m using the myenedis integration from HACS in order to replace the Linky integration. With this, I have a sensor with all the different informations like before.

I want to get the daily value using the utility meter in order to have the values for each day (and put everything in a graph) using recorder.

I managed to make the sensor template and for me it works since I have the value in the dev tools:

- platform: template
      friendly_name: "Conso journalière Enedis"
      unit_of_measurement: 'kWh'
      value_template: "{{ (state_attr('sensor.myenedis_14851953566977', 'day_1') /1000) | float | round(2)}}"

Now I’m trying to use this sensor in the utility meter :

  source: sensor.daily_power_enedis
  cycle: daily
    - peak

The value of the sensor that I’m using are:

attribution: ''
lastSynchro: '2020-12-02T13:59:27.405220'
lastUpdate: '2020-12-02T13:59:27.405211'
timeLastCall: '2020-12-02T13:59:27.405077'
yesterday: 17684
last_week: 113305
day_1: 17684

When launching everything, here is the error that I have:

Error adding entities for domain sensor with platform utility_meter
Error while setting up utility_meter platform for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 316, in async_add_entities
    await asyncio.gather(*tasks)
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 507, in _async_add_entity
    await entity.add_to_platform_finish()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 530, in add_to_platform_finish
    await self.async_added_to_hass()
  File "/usr/src/homeassistant/homeassistant/components/utility_meter/sensor.py", line 264, in async_added_to_hass
    self._state = Decimal(state.state)
decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]

I’m not sure how I can check if the value is a decimal, since in the dev tools I can see that the operation works since I have the correct values.

Anyone can help me out? :slight_smile:
Thanks all!

value_template: "{{ (state_attr('sensor.myenedis_14851953566977', 'day_1') | float /1000.0) | round(2)}}"

Without looking at anything else, your template sensor value_template is wrong. You need to convert the state_attr to a float or int before dividing by 1000, not after. It might be related, it might not. You say the template sensor shows the right value…so not sure.

Tried to do the following but same issue.

value_template: "{{ ((state_attr('sensor.myenedis_14851953566977', 'day_1') | float) / 1000) | round(2)}}"
Btw I get the same value so doesn’t seem that it comes from there.

python docs say this is raised when the input doesn’t make sense (i.e. not a number string, not an int, not a float, etc)

But looking at the code, it’s complaining when it’s trying to read its own previous state. not the state of your template sensor.

It’s like the database has some invalid value stored. If there was nothing, this would return ‘None’ and this would just not have a previous state and all would be happy…

Can you try changing the name daily_power_enedis to something else? Rather than clear the whole db that is. Not sure how it would have stored an invalid value…

Damn same thing even when using a new sensor :sob:

Btw I’m using MariaDB as the database, I’m gonna change back to the regular DB and see if it is the same (I don’t mind losing my DB).

Same thing when using standard DB. However, I’m not recording the sensor, I’m only trying to record the utility meter peak sensors, so in theory the sensor should always be None or the value itself.

purge_keep_days: 8
#db_url: !secret mariadb_conn
    - sensor.daily_power_prise_suivi_conso_1_peak
    - sensor.daily_cost_prise_suivi_conso_1_peak
    - sensor.daily_power_enedis_peak
    - sensor.daily_cost_enedis_peak

Yeah, I can’t find any good reason. Though your line error is different than the actual code line. You must be on an older version. There were changes as of 18 days ago, but they seem unrelated to your problem.

Did you figure it out yet?

Does this sensor exist in /.homeassistant/.storage/core.restore_state ? If yes, what is the last stored state in there? Could be a clue.


Well I was gonna look and apparently it fixed it by itself, don’t know why or how. In the .storage, I can indeed find the utility meter (the one that didn’t manage to create) however the last changed is from the 2020/12/02 which is kinda strange. Here are the entries:

            "state": {
                "entity_id": "utility_meter.daily_power_enedis",
                "state": "peak",
                "attributes": {
                    "tariffs": [
                    "friendly_name": "daily_power_enedis",
                    "icon": "mdi:clock-outline"
                "last_changed": "2020-12-02T20:26:56.508373+00:00",
                "last_updated": "2020-12-02T20:26:56.508373+00:00",
                "context": {
                    "id": "9cf6d1eb1e75676841363f7a6580e7b2",
                    "parent_id": null,
                    "user_id": null
                     "state": {
                "entity_id": "sensor.daily_power_enedis_peak",
                "state": "0",
                "attributes": {
                    "source": "sensor.daily_power_enedis_2",
                    "status": "paused",
                    "last_period": "0",
                    "last_reset": "2020-12-04T00:00:00.006597+01:00",
                    "meter_period": "daily",
                    "tariff": "peak",
                    "friendly_name": "daily_power_enedis peak",
                    "icon": "mdi:counter"
                "last_changed": "2020-12-02T23:00:00.006232+00:00",
                "last_updated": "2020-12-03T23:00:00.006691+00:00",
                "context": {
                    "id": "e5df3d913bf7818a8f56d544ad1812c5",
                    "parent_id": null,
                    "user_id": null

Just rebooted the server and still there, however it worked when using the new sensor (enedis_2). Using the enedis alone, it now works too, really strange… Maybe the supervisor update fixed it (not sure but I think I updated it recently).