You are commenting that co2signal is giving you the wrong data. Why ask here? If a weather forecaster gives the wrong weather, its not down to ha. How us this any different?
1 Like
Do you mean slimlezer? it is an esphome device.
I’m asking here, because I try to discuss an native HA Integration, which I would not even know about, if it was not presented to me by HA.
I do assume, that HA developers do some research, before an integration is made in to the system. So, that makes me think, that there are people around here, who can help with some answers.
If a weather forecaster proves being daily wrong and differ a lot of all other forecasters, will it make it into a core integration on HA?
So, yes, I ask these things here, because i found it here, and if there are some doubts, then they have affect on every HA hobbyist using this integration.
So I still hope for a discussion about this instead of showing me the exit door of the HA building…
No. I am simply pointing out that your assumption may not be valid.
Ok fair enough.
What I find odd is, someone in your position (whose supplier claims 100% renewable) gets exactly the same electricity as your neighbours. You can’t pick and choose your electrons. So this sort of calculation can only be done on a regional average. I am picking that this is what you see.
2 Likes
cant find the answer, and even Thanasis on Discord #energy wasnt sure… so, maybe you can help me out:
checking Sensor Entity | Home Assistant Developer Docs confuses me on the matter of a total_increasing entity for gas consumption, which I now have configured as
- platform: mqtt
state_topic: 'MAC/energy-dsmr4/538d72d9/gas'
unique_id: gas_totaal
name: Gas totaal
unit_of_measurement: m³
icon: mdi:counter
value_template: >
{{value|round(2)}}
state_class: total_increasing
device_class: gas
but do I understand correctly the state_class and device_class are not compatible? as in, total_increasing cant be device_class: gas?
asking because no error is logged anywhere, and the gas usage seems to be recorded just fine
in short:
we can have
state_class: measurement
device_class: gas
on a sensor but not
state_class: total_increasing
device_class: gas
?
Vote here:
2 Likes
there is already a PR in the works to fix the Efergy Integration.
the related issue has a few options listed on how you could work around for now
1 Like
Hi,
after the update 2021.9.1, I have an error on the power supply part.
I have a spike as if the last reading did not take into account the old long term sensors.
see this pictures.
Is it possible to make a procedure to recalculate everything from the standard table or from the table of long term sensors?
[edit]
3 hours after update see this error on graf
and see this data store on my database:
this version is very big bug…
When put option for recalculate the values?
I have a similar issue with my MQTT electricity consumption/return sensors since 2021.9.1.
Unexpected state class
The following entities do not have the expected state class ‘total_increasing’
But adding the state_class: total_increasing is not allowed 
When I retrieve the state in developer tools I get
state_class: measurement
How it got this state_class assigned I don’t know though, as this is not configured anywhere.
The cost also still shows this error in the logs, no idea why this should be wrong. My Hass is configured with EUR as well.
sensor.totaal_verbruik_net_hoog_tarief_cost has unknown unit EUR
Based on this thread 2021.9.0 causes generation of long term statistics to be suppressed I checked my DB. I saw that the state of the cost sensors is recorded in the states table, however there is no entry for them in the statistics_meta table.
How I made sensors that report in W (Watts) work in Energy Dashboard
Now I just need my Aeotec zigbee power monitoring smartplug (that come into HA via MQTT) to be listed as an individual device…
They show like this in Dev:
unit_of_measurement: W
friendly_name: Smart Plug - Back Lounge power
device_class: power
I might try making a template sensor and see if I can get that to work.
OK… I now have this in my configuration.yaml… let’s see if it works (I know a little but not enough so probably wrong somewhere). I can and have added them to individual devices…
UPDATE: Overly complicated. Integration Sensors can be added straight to the dashboard if setup correctly. Instructions updated.
sensor:
#Integration Sensors
- platform: integration
source: sensor.smart_plug_back_lounge_power
name: Smart Plug Back Lounge Energy Spent
unit_prefix: k
round: 2
method: left
- platform: integration
source: sensor.smart_plug_front_lounge_power
name: Smart Plug Front Lounge Energy Spent
unit_prefix: k
round: 2
method: left
- platform: integration
source: sensor.smart_plug_front_door_power
name: Smart Plug Front Door Energy Spent
unit_prefix: k
round: 2
method: left
- platform: integration
source: sensor.smart_plug_pool_filter_power
name: Smart Plug Pool Filter Energy Spent
unit_prefix: k
round: 2
method: left
then add this to customize.yaml :
sensor.smart_plug_back_lounge_energy_monitor:
last_reset: '1970-01-01T00:00:00+00:00'
state_class: 'total_increasing'
device_class: energy
unit_of_measurement: kWh
sensor.smart_plug_front_lounge_energy_monitor:
last_reset: '1970-01-01T00:00:00+00:00'
state_class: 'total_increasing'
device_class: energy
unit_of_measurement: kWh
sensor.smart_plug_front_door_energy_monitor:
last_reset: '1970-01-01T00:00:00+00:00'
state_class: 'total_increasing'
device_class: energy
unit_of_measurement: kWh
sensor.smart_plug_pool_filter_energy_monitor:
last_reset: '1970-01-01T00:00:00+00:00'
state_class: 'total_increasing'
device_class: energy
unit_of_measurement: kWh
1 Like
Why would I rather want to manually install a script, MQTT broker and configure sensors, instead of just using the built-in integration?
If you believe that more and useful information could be retrieved from the Envoy device, why don’t you just contribute to the built-in integration?
The built in integration updates once a minute or longer so it’s not real-time. The mqtt approach updates once per second.
This is a great feature, unfortunately, unless I am missing something it is useful only for those with Net Metering solar production. A few utility companies in the US (such as Austin Energy in my case) take the Value-of-Solar Tariffs approach. Basically, your solar system sells all the production back to the utility company and you continue to “consume” all your energy from the grid. I believe offering that option within the HA energy management implementation should be pretty simple.
Here is some VOS info: Value-of-Solar Tariffs | State, Local, and Tribal Governments | NREL
What sensor? If using HACS Empora VUE you need to reload the MASTER
If you want USD you change that in the general settings for HA
Never expected to like this feature like I do…
The data gives me great in sights about the energy consumption of the home.
If only it would be possible to import historical data from my energy supplier and my solar panel monitoring webpage…
But adding the
state_class: total_increasingis not allowed
For what it’s worth, when energy management first became available in the stable release, setting the state_class to total_increasing didn’t work for any sensor. This has now been fixed with some, but not all, of my sensors. I haven’t tracked down what the difference between them all is, but the hack that got me going in the first place was to add in my configuration.yaml:
customize_glob:
sensor.currents*:
state_class: total_increasing
This sets the total_increasing class to all sensors that start with “currents”. Just change this to flag the sensors you need this attribute set. I’ve put the class statement in as a comment on the sensors that need it so later when this is resolved I can enable it and remove the global filter.
Cheers
If anyone has an Actron Que air conditioner - Mike (the awesome developer of the addon) added the entity for compressor power - and now I have it as an Individual Device on my dashboard!