Solar mode no longer works in ver 1.2.1

[MurrayVK3]

I updated to ver 1.2.1 and now solar mode refuses to charge no matter how much excess solar I have. Was working (sort of) prior to the update.

Excess and Eco modes charge at least with a minimal amount (6 amps) and standard mode will charge at maximum current if Allow Grid Charging is enabled.

I'm also getting:
Failed to get state for sensor: number.dynamic_ocpp_evse_max_current: [FrameInfo(frame=<frame at 0x7f71648040, file '/config/custom_components/dynamic_ocpp_evse/dynamic_ocpp_evse.py', line 47

and similar for min_current as well. I've attached the full log file.

home-assistant_2026-02-15T05-33-04.338Z.log

Thanks again
Murray

[LeoAlioth]

Do you have a setup with a home battery?
For systems with a home battery, i gained access to a site i can test on last month, so i also noticed that solar is not working as intended. Again, it seems like my current dev builds are working properly even for systems with batteries now, so you should try the pre-release in the following days.

[MurrayVK3]

No battery. I selected no in the config and set the two battery values (whatever they are) to 0.

[LeoAlioth]

Hmm, The grid phase entites you selected. Do they read positive or negative values when solar is exporting?

[MurrayVK3]

The current sensor is negative when exporting.

BTW I'm pretty sure I originally had a power (W) sensor there but it says 'phase_a_current_entity' so I'm giving it current (A). Then again I could be mistaken...

[LeoAlioth]

Okay, then i am not sure what could be the reasons, and i have no plans on fixing that with just a minor update to the v. 1.2.1

But you can try the current pre-release:
https://github.com/LeoAlioth/Dynamic_OCPP_EVSE/releases/tag/2.0.0-pre-2026-02-15_23-27

In HACS, if you click Redownload in the overflow menu, you can manually select it. But make sure do delete current setup, as i have decided to not bother with the migration process this time, as there were so many changes in comparison to the 1.2.1

But note that this version has barely been tested, so while i do expect it will fix this weird solar mode behavior and the problem with the profile validity you mentioned in the other issue.

[MurrayVK3]

I'm happy to test it for you.

In the new config:

excess_export_threshold is power (watts)? Thats the amount of excess solar before charging starts? I've set it to 1300

invertor_output_phase_a_entity Is that power or current? and how is it different from solar_production_entity on the next page? I have put my total solar power (W) in both.

I'm getting reasonable looking numbers. Is 'Total EVSE Power' what is offered to the EVSE? It remains zero no matter what mode I set and there is plenty of surplus solar:

[MurrayVK3]

I removed all the ocpp related integrations and started again. Its now working, sort of.
I'm getting reasonable values for Dynamic OCPP EVSE Solar Surplus but the ZJBeny Current Offered doesn't make a lot of sense. I've also got maximum current set to 10A because my battery is nearly full but that is being ignored.

Some of that time when Current Offered is 6A is when I had stopped the car charging but the offered current dosen't really follow the surplus at all.

[LeoAlioth]

excess_export_threshold. This is only used in Excess mode. You should set it a little lower that what your utility allows you to send back towards the grid. For example, I have a 13.6 kW export limit. After that. Inverter starts curtailing to not go over that. So I set the excess_export_threshold to 13000W, with the idea of having a car plugged in at let say 80%, and I only want it to charge if otherwise that energy would be wasted.

invertor_output_phase_a_entity, not necessary for single phase systems and systems without batteries. solar_production_entity is a fallback for the 3 individual phases.

Total ever power is actually charging power. Not what is offered. But what is consumed by all ever in site.

Current offered can be put of whack when a car is not actively charging.

Instead, you would look at the available current and allocated current.

Also, when you have a chance and you have a car plugged in, peferably when there is solar export above the excess_export_threshold, can you pleaseenable debug logging, select each of the charge modes for about a minute, and then send me a log?

[MurrayVK3]

I set the excess export threshold to 1000. Solar export was well above mostly (all?) the time debug was running.
Log attached:

home-assistant_dynamic_ocpp_evse_2026-02-16T23-16-08.424Z.log

[LeoAlioth]

I the debug, i see that the mode was Standard at all times. Soi don't
really see a whole lot that would help me determine why solar mode has problems.

[MurrayVK3]

I went through the 4 modes, about 2 minutes each. I'm using my own dashboard with a switch assigned to 'select.dynamic_ocpp_evse_charging_mode_2'.

Searching the log for 'Charging mode changed' I found:

2026-02-17 10:08:09.761 INFO (MainThread) [custom_components.dynamic_ocpp_evse.select] Charging mode changed to: Eco
2026-02-17 10:10:45.159 INFO (MainThread) [custom_components.dynamic_ocpp_evse.select] Charging mode changed to: Solar
2026-02-17 10:13:15.439 INFO (MainThread) [custom_components.dynamic_ocpp_evse.select] Charging mode changed to: Excess

at roughly 2 minutes intervals.

[LeoAlioth]

I see. I was looking at the logs that come out of the target_calculator which stayed on standart at all times
Calculating targets for 1/1 active chargers - Mode: Standard, Distribution: Priority
so the charge mode was not being properly registered at all, due to an mismatch in entity names, which occurs on clean installs like yours, and i missed it on the instance i test with.
Ill get back to work :)

[LeoAlioth]

New Release for you to try out 😃
https://github.com/LeoAlioth/Dynamic_OCPP_EVSE/releases/tag/2.0.1-rc.20260217.1931

[LeoAlioth]

I've found another bug in the eco/solar priority mode at my friends site yesterday (they have a battery), so i've pushed a 2.0.2 pre-release.

[MurrayVK3]

Overcast and a full battery ATM. I'll try this in a day or two.