I am using a Balcony Power Plant based on 4 x 500 W Panels, 4 x Growatt NOAH 2000 and Growatt NEO 800M-X. All connected to Growatt Cloud and bound to HA with MQTT and Noah-MQTT.
What i wonder about is how the system is behaving.
For example the SOC1-4 Values are sometimes “switching” like the value for SOC1 is taken over to SOC3 and vice versa. Or there’s a jump from 64% SOC (overall) to 100% in 10 minutes (same for SOC1-4) that is impossible.
The system is loosing 8 % SOC in 14 hours means about 650 W in “standby” / battery first mode over the night with 0W output?
How can you manage the generated power if there’s no stable / accurate info about the remaining energy?
Is this problem limited to Growatt devices or is there similar experiences for other vendors?
Is this a problem in the Growatt Cloud / Devices or with the used Addins in HA?
At the moment i can not really trust the values making it very complicated to manage the produced energy efficient.
Hi!
I have also set up a balcony power plant (2 x 450 W, 1 x Noah 2000) controlled via Home Assistant, starting in June and stumbled across the same issues. The SoC is calculated from the internal BMS (battery management system) and usually the just integrate “incoming” and “outgoing” power values. The measurement is not quite reliable and so errors add up quickly. (E.g. take a look at the reported “charging power” values: They are cut off to zero at around <30 W. However, the SoC still rises a little bit if you have the system on a very cloudy November day. So it may have a more ‘precise’ value internally.) It’s difficult to have a deeper insight because we have to rely on the values that we can get via MQTT.
I programmed a simple correction feature: The average SoC drift is -0.25 %/hr. Thus the corrected SoC in pseudocode is:
I use an automation to save the last SoC synchronisation timestamp everytime the reported SoC crosses a value of 85%. (The sync seems to happen in 2 to 3 steps starting between 55 and 75%, I didn’t quite figure this out yet.)
Unfortunately, this means that after 100 hrs, the SoC is already off by -25%. In my control, the battery has to be charged up to the next sync once the difference between reported and corrected SoC is greater than 30 SoC-%.
Thanks @thomay86, this is a “tricky” solution
Currently i am trying to get some help via support.
I think it is not really good if the NOAH’s are wasting about 10-20%Soc every night. If i could i would switch them off in winter as charging in the morning keeps a long time (today about 3 hours).
Maybe this whole “business” is more or less not really optimized at the moment.
10-20% SoC is definitely not right, there must be something wrong. My Noah ‘loses’ 3-4% over night, which would be about 5 W. (It’s actually less because of the drift as mentioned above.) This is a reasonable value for the internal electronics and especially WiFi I guess.
In my experience, the whole ‘business’ looks fine for users that simply want to plug it in and don’t bother looking after it - although it’s far from optimal and not very energy efficient. As soon as you dive deeper into it (which most of the users in this forum probably will do ) you stumble across a lot of trouble.
Please let me know about your experience with support, I just opened a ticket too yesterday concerning the MPPT capabilities of Noah - I have some odd stuff going on with partial shading of one module.
i even cross checked by using the daily production against the time from starting to load until 100% SoC. Last night it was about 0.6 kWh. In the days before it was up to 0.8 - 1.0 kWh.
Hopefully Solakon will support me. They are not happy as i bought 2 NOAH’s (out of 4) from a different verndor in times they were not able to deliver.
Hopefully they will take care.
of course i could start from scratch but i have no hope that this will change something. For example: today at 14:20 the system (in battery first mode) was at about 100 W solar power. In this situation it is still generating 50 W output power (before the inverter). To achieve this it used battery power until 17:10. This means the batteries were drained (with no need) to have output power that is not configured. If i look on the graphs it looks like in battery first the system is trying to generate output power as long as there’s “some” solar power. As the solar power went to zero at about 17:10 the system also stopped to generate output power. In my opinion this is not a good setup / software / firmware. On the other hand there’s nothing i can configure in the shine app or in the web browser interface. I’d expect that there’s no output if energy loss due to conversion is wasting more energy than what is generated by the sun.
And - the inverter is configured and recognized in shine app but i see nothing there i could configure?
From your graphs it looks like the system is doing mostly what is expected in ‘battery first’: in the morning it uses all solar power to charge up to 100% (orange in 2nd graph) - no output. Once the batteries are full, it bypasses all the solar power to your house (yellow). And yeah, okay,I can’t make sense of what happens with the low discharge in the end - maybe some schedule telling the system to output 50 W. (The numbers still don’t make sense with 50-100 W of solar power, but one thing at a time…)
Did you check in the shinephone app whether there is some schedule configured? Are you able to use the Solakon app? During my install, I had to remove/add the storage two times both in the Solakon and Shinephone app because something apparently wasn’t syncing in the background and there were schedules active that I didn’t want to have. Then I chose the Shinephone app to delete all schedules and activate the ‘consumer first’ option which allows me to set the desired output (via app or ultimately using HA).
Furthermore, try to set the SoC range to 20…80/90% which is actually recommended for this type of battery. Maybe the system is not comfortable sitting at 100% and discharges some of the energy… Just guessing.
Do the other batteries show the same charge/discharge graphs? Maybe there is some kind of energy transfer between the batteries?
i used Solakon at the beginning but there’s no api for automation available there? Of course i can switch to ‘consumer first’ but only with a minimum of 50W output that does not make sense in the current “autumn” situation. What is missing is a 0 W output setting. I can try to change the SoC setting. Maybe this brings more info - good idea. Regarding the other batteries - they are all shown in the below graph before. What i can see there is that at least all batteries are used to discharge but with some kind of delay.
In my Shinephone I can set consumer first and 0 W output - screenshot in German attached. (Are you also located in a German-speaking country or does Solakon deliver abroad?)
In consumer first mode I use Noah-mqtt add-on to communicate with Noah, which works very well. (The Growatt integration didn’t work for me.) When you set 0 W output, you are basically running a battery first mode. Noah will always output the solar power once the batteries are fully charged.
Thank you - i am located in germany.
I am using Noah-mqtt together with mosquitto mqtt.
And i did never see the mentioned optin. It was set to 150W and i changed to 0W.
After changing the “max. Soc” to 90 % today the system was even able to generate 50W output power out of 78W solar power without the need to discharge the batteries.
Guess everything is more or less a question of software and not hardware. Hopefully there will ever be an option to use “community firmware” on such devices instead of the creepy one provided by the manufacturer
one more thing - i have a Smart Meter registered also “Shelly Pro 3EM”. But unfortunately the system does not allow me to select it (i do have two SmartMeter) and the wrong one is taken. Is there any optionthat is making it possible to select the smartmeter if there’s more than one?
Yeah, it’s very often the software or firmware. I tend to ask myself whether the programmers ever used their product themselves - be it a solar system or a TV or a car…
I don’t have a Shelly, so I can’t help on this end, sorry. I have a Tasmota infrared reader on my meter which gives me the current net consumption and I do all the control logics by myself in HA. This way I ‘replace’ the creepy software to a large extent. Smartmeter <> myself <> Noah
yepp - i got a call from a solakon level 2 engineer. He suggested to remove the Pro 3 EM out of the config. Communication with this device might cost energy.
I only have one night to test but it looks like there’s a change. Total SoC only lost 2% and only on battery lost 7%.
Compared to the day before this makes a visual difference and this loss of energy would be much better.
He alos mentioned that the new Solakon One device could be used to manage the existing Growatt devices but with much better firmware (to be prooved) and api functions that can be used in Home Assistant. Guess i might give this a try. But the additional invest has to be thought over before.
Happy to hear that the problems are being addressed. Strange that the Shelly communication seems to draw that much power…
Yeah, I also read about the Solakon One release and the associated functions… Would probably have saved a lot of work at my end . Unfortunately I bought my (Noah) system already in June before the release. And frankly, under my conditions an additional storage would make no sense at all. After all, I have a rather stable and customised system up and running now
i am not yet convinced that removing the Shelly from the shine app really changed the situation. It looked like but there’s also some big “downs” on the SoC after the removal. I also removed the inverter to check if this also makes a difference. still everything is a “miracle” for me
Well - guess this is documenting that there’s an issue in the SoC Management. The SoC was somehow blow 90% and than the batteries started to load. Until at about 12:00 (High Noon ) there’s a “jump” in the graph from 93% SoC to 100%. Also all 4 batteries are on 100% now. As there was no “solar bomb” that could have filled the batteries this can only be a bug or problem somewhere in the communication.
) you stumble across a lot of trouble.
