#There's a PR adding the [Victron GX](<

1 messages · Page 1 of 1 (latest)

plain shoal
#

do we have other integrations calculating energy somehow?

toxic warren
#

dunno. the question was more about if it's OK to use restore state like this

oblique pebble
#

I thought we had tesla

#

but apparently not

toxic warren
deep oriole
#

Why does it calculate accumulation from the beginning if that's not exposed by the API? Just skip that and we don't have a need for the restore state either.

peak valve
#

For Tuya I asked the author to drop restore, and always start at zero when the entity is created

sick yoke
#

(I'm the owner of the victron inetgration we discuss here). I got recurring request from my customers (for the custom integration this core one is based on) to fix the issue that each restart take the energy meters back to zero.

toxic warren
#

The root problem is in a sense that the statistics stuff is not easy to use

sick yoke
#

I agree with @toxic warren . Customers could solve it on their own but dont see why this is not behaving correctly by default. The excuse they could implement it using integral helper is not interesting for the novice user.

oblique pebble
sick yoke
#

I agree. I think HA should allow integration to use helpers directly in their code. Today this is not possible so we (integration owners) revert to custom solutions. Saying that, restore state is not that custom. It is being used to exactly what is suppose to do.

oblique pebble
#

No that is not what I was aiming at.

#

I mean that we need to identify when people need this data, and how we can propose the user better when to use it for example

#

like in the energy dashboard

sick yoke
#

They always want the energy data not to get lost when they do HA upgrade.

oblique pebble
#

I am not sure what that has to do with what I just said

sick yoke
#

ok, so maybe I didnt get your point. can you explain it?

oblique pebble
#

Currently when adding for example your solar panels to the energy dashboard, you need to have an energy sensor. if you only have power entities, you can't do this without integral entry. We could make it easier or explain better what is required in this case to still achieve what the user wants, without being thrown in the deep. But this is a product and frontend question, not a core one. But that is how I think this would be solvable

toxic warren
#

What I meant was actually that we automatically do accumulation and store as long term statistics

#

It's just that we don't make that very easy to access

#

For example, it can't be accessed in templates

#

And you need special frontend cards to access it etc.

sick yoke
#

Customers are probably using it for many other things than just energy dashboard. I am not trying to guess what they do. I fully agree that it would be amazing if I could somehow specify as integration owner that a specific entity should be ever accumulating and things will just work. Sadly, I dont have this capability today. If it will be added, I will be glad to revert to use it. Till it exists, I kept getting issues every other week about entity data lost after HA restart.

oblique pebble
#

I think we shouldn't accumulate the data at all as it's not provided by the device. It's not weird or uncommon for integrations to only have power sensors.

#

I think it'd be weirder if my stats stopped counting for a day if my HA was offline for whatever reason, while with the integral helper you know that its a helper doing the calculation, so Home Assistant offline -> no stats

sick yoke
#

There were specific requests to supply energy sensors as well. This is why we have software. To solve problems which is hard to solve via hardware alone. What is valid use case to use restore entity? Where is it valid use case and why here it is not the case?

oblique pebble
#

This is why we have software. To solve problems
Agreed. But our response to this would be that you can already do this out of the box with the integral integration.

What is valid use case to use restore entity?
A valid use case would be restoring state of an entity you don't know the state of at start up, for example in a bus based system like DSMR or with passive bluetooth packets

why here it is not the case?
That is what this thread is made for to find out 🙂

plain shoal
#

Would a TOTAL_INCREASING sensor work here? It can reset to zero. both the energy dashboard, graphs etc will work

sick yoke
#

Yes, the problem is users are expecting to get ever increasing reads even outside the world if energy dashboard. They are using sensors directly in different ways for different reason. They don't expect their data to reset every time they restart HA.

#

@oblique pebble , out of the box means it just work. Without you figuring out how to use helpers. Why do we consider complex solution for the customer with the cost of 25 lines if code?

oblique pebble
sick yoke
#
  1. This is debatable:)
  2. True and we could do better so why not?
oblique pebble
#

Better is debatable as well, because now we're presenting something as a device value which is only updated when home assistant is turned on. Yes it'll help people, but it'll be a value with a weird behaviour compared to the others

#

Have you considered reaching out to Victron to ask if they can add such value to MQTT?

sick yoke
#

I have no problem documenting the behavior in the integration page. I agree you will lose data while HA is off. Still, way better from not having it at all. If some future version of Victron will provide something better, I will be glad to expose their value in those versions. Should be super easy to do with the framework we have.

toxic warren
#

Hey, @deep oriole @oblique pebble @plain shoal I think we should give a clear answer to if t's OK or not to use the restore state functionality as @sick yoke wants to do. As I linked to earlier, starlink does exactly the same, but I can't find any other examples among the core integrations.

deep oriole
#

I'd say no, since it's a workaround for something that the integration shouldn't do in the first place.