Daily, Monthly, Yearly and Total generation entities no longer available on update to 2024.8.1 and latest integration

[jouster1974]

did the usual upgrade on the new release, 2024.8.1 and Daily, Monthly, Yearly and Total Generation entities have become unavailable.

Had also upgraded to the latest Solarman instance from HACS

winding integration back to 24.07.14 seems to resolve the issue for daily generation but Monthly, Yearly and Total remain unavailable

Winding back to 2024.8.0 brings back all entities

Updating to Solarman 24.08.04 on HA2024.8.0 has the same issue...so seems to be incompatability in there somewhere

Through some trial and error Ive managed to get 2024.8.1 and 24.07.14 working to give me at least daily generation....so will look to getting the rest at some point to...

If you need me to check anything do let me know

[davidrapan]

Hi @jouster1974, https://github.com/davidrapan/ha-solarman/discussions/45 and then refactor: First batch of name standardization

Solution: Either custom profile or https://github.com/davidrapan/ha-solarman/wiki/Naming-Scheme

[PV-Joe]

@jouster1974

I think you are using a custom configuration file that is not compatible. I was just going through the process to standardize the entityID‘s to David Rapan‘s logic an it works nicely now.

The weekly and monthly sensors from your example are great!

@davidrapan Maybe you could realize those sensors with one of your next releases? I mean for our Deye SG04LP3 only at first step. What do you think?

[davidrapan]

@PV-Joe his inverter has those sensors and provides values for them. SG04LP3 have separate value only for Today(Daily).

Please again let's not confuse data providing with statistics.

[PV-Joe]

I thought it would be nice to implement the same statistic values seen in the Solarman App and the Deye inverter menue to your integration.

They are probably calculated and not integrated in Deye Modbus then. Anyway it would have been nice to see them as sensors for easy handling but nevermind if it is not possible.

[davidrapan]

This is what HA is for, not this integration alone. Not mentioning you already have those data in there. History button in the menu. You are confusing purpose of this integration. HA + this integration is replacement for Solarman App/Deye Cloud, not just integration. Let's keep things clean and simple, please. Statistics are beyond the scope of this integration.

For example: https://www.home-assistant.io/dashboards/statistics-graph/ That card is giving you an option to get those data from total sensor by setting the argument 'period' to 5minute, hour, day, week or month.

And it's just an example how are those things done in a proper way. You can even create sensor which does the same thing if you need that.

Let's stop trying reinventing the wheel. 😋

Edit: Sorry to @jouster1974 for this OT, haha.

[PV-Joe]

Thank you for explaining the goal. I have created lots of sensors in Home Assistant that calculate various values and they work fine.

I thought it would be nice to have those (like the Losses sensor) out of the box with the integration. That would make it easy for people to just install and go.

I do understand that you are just integrating the basic fetching and not much more.

Thx again for all your hard work and the extremely fast respose 😄

By the way: I just updated to Home Assistant 2024.8.1 and Solarman for Stick Logger v24.08.04 works fine without any problems 👍

[davidrapan]

Power losses/Total Losses sensors are something different:

1. It's simple math operation above fetched data
2. It's something what inverters should provide in the first place but they don't cause manufacturers don't want you to see how inefficient those devices are

I thought it would be nice to have those (like the Losses sensor) out of the box with the integration. That would make it easy for people to just install and go.

I still think that that is exactly what this integration provides. Cause you already have those data. No system works in a way that it calculates the same data over and over and stores them separately. In that case it would be data storage hell from many perspectives:

1. If you would store those data separately as you are suggesting here. If you then let's say after a year compared that stored data with data queried again from total sensors it would not give you the same values cause of many reasons of which is for example precision. Cause of that problem alone is always better to re-querry them as needed. That will ensure the best possible precision (data storing especially float and integers is hell of a problem in our IT world in general and it's even worse in python world 😆)
2. The required size of a storage would increase exponencialy with time.
   • It's simply storing the same data over and over and that's really wasteful.

If HA would had feature which would act for example something like Querry sensor, which would only act as that said querry over some data thus only extracting them (and not storing them again) from already stored total sensor data. I would totally satisfy your desire using that cause that would be aligned with what I just said above and also did make you happy. 😆

[jouster1974]

after reading through the many repsonses, thank you all, I tried another inverter parameter (even though Ive been on the same one from the start) and this has less entities but importantly., the ones I was missing are now back...

I will have to look into a custom one at some point

[davidrapan]

@jouster1974 they are not missing. They are simply renamed from Generation to Production.

[jouster1974]

@jouster1974 they are not missing. They are simply renamed from Generation to Production.

apologies...badly worded reply.....there are showing as unavailable on my integration....

[davidrapan]

Yes @jouster1974 but you can see that new sensor for example Total Production appeared instead of previous Total Generation.

It shows the same value under new standardized name.

[davidrapan]

Be aware: refactor: Second batch of name standardization

[davidrapan]

@PV-Joe, you already did go trough that renaming process. Could you maybe writeup some step by step manual in discussions from your perspective as an user?

[davidrapan]

@jouster1974, look when I use your picture and draw over:

[PV-Joe]

Renaming entityID’s to match with Solarman for Stick Logger by David Rapan

(Your history values will be still there after renaming)

1. Check Developer Tools for any as “Problem” marked entities and klick on “Problem” and delete them from here.
2. Choose the right inverter configuration.yaml in the Configuration of the Solarman integration
3. Go to the entity that has to be renamed and klick the cog at the top right corner.
4. The previous entityID name has to be renamed to David Rapan’s logic within this menue. (example attached)

@davidrapan: I think it would be helpful to provide a list of the default entityID names without any custom sensors to look up how they have to be renamed to match your integration. Mybe the Wiki is the right place to store it?

You can’t just use the entity names and add underscores for: Solarman Today's Production

The right entityID has to be written like this: sensor.solarman_today_production

[davidrapan]

@PV-Joe Thanks.

List of new entities is for his case:

["sensor.x_today_production", "sensor.x_monthly_production", "sensor.x_yearly_production", "sensor.x_total_production"]

List of old ones:

["sensor.x_daily_generation", "sensor.x_monthly_generation", "sensor.x_yearly_generation", "sensor.x_total_generation"]

@jouster1974 You should also remove your device and add it again so it removes old sensors.