Solax X1 Inverter support

[fboundy]

Continuation of #149 @punkymuzzle

[fboundy]

The critical thing will be to see whether the inverter kicks in at 22:30

[punkymuzzle]

Well I've left it for two charge cycles, and nothing has happened.
I've checked the error log and pv_opt log and it has the same timestamp as earlier, so not worth uploading.....

[fboundy]

Sorry I think I missed the logs. Did you upload them?

…

On 28 Mar 2024 at 23:39 +0000, punkymuzzle ***@***.***>, wrote: Well I've left it for two charge cycles, and nothing has happened. I've checked the error log and pv_opt log and it has the same timestamp as earlier, so not worth uploading..... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[punkymuzzle]

I didn't upload them as they had the same date / time stamp s the previous upload, so there was no additional information in them.
I'll upload them again anyway:

I've also noticed that the charging times aren't recalculating and are still showing yesterdays times to charge:

.
.
To me it sort of looks like it's just stopped and needs something to kickoff the process again, so I'll reboot HA and then upload the logs again.

[punkymuzzle]

Rebooted and uploaded the logs:

.
.
Also noted that the dashboard is showing errors again, so assume it's working stuff out before it displays it:

[fboundy]

Yes dashboard will always show errors on calculated entities if the script crashes.

4.0.0-solax-x1-beta-11 should fix the last error. Quite likely there will be more while we get controlling the inverter going.

[punkymuzzle]

OK, installed Beta 11 and logs attached:

[fboundy]

Has your config.yaml been over-written? It shouldn't be but that looks like its trying to load solis settings

[punkymuzzle]

No, it's still intact

[fboundy]

Can you upload the latest pv_opt.log then as the entries for 11:18 don't make sense to me

[fboundy]

Maybe re-start AppDaemon as it looks like it might not be loading config.yaml at all

[punkymuzzle]

Restarted AppDaemon and then re-saved config.yaml so it re-ran.
Logs as follows:

[punkymuzzle]

Dashboard has come back to life

[punkymuzzle]

Latest logs if you need them:

[fboundy]

Looks OK in read-only. What if you turn read-only off? You could also set debug: false in the config.yaml for now which makes the log a lot more readable.

[punkymuzzle]

OK will do it and see what happens. Next scheduled charge isn't until 1:00 tomorrow morning. So will give you an update when it's done

…

On Fri, 29 Mar 2024, 12:40 fboundy, ***@***.***> wrote: Looks OK in read-only. What if you turn read-only off? You could also set debug: false in the config.yaml for now which makes the log a lot more readable. — Reply to this email directly, view it on GitHub <#188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNR352GA7C7XAGMYZJUJZTY2VHKDAVCNFSM6AAAAABFNL5W2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGE4DQOBTGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fboundy]

Would be good to see what it’s doing as soon as it’s off read only. Should be reporting inverter status even though there’s nothing to do till then

…

On 29 Mar 2024 at 13:02 +0000, punkymuzzle ***@***.***>, wrote: OK will do it and see what happens. Next scheduled charge isn't until 1:00 tomorrow morning. So will give you an update when it's done On Fri, 29 Mar 2024, 12:40 fboundy, ***@***.***> wrote: > Looks OK in read-only. What if you turn read-only off? You could also set debug: > false in the config.yaml for now which makes the log a lot more readable. > > — > Reply to this email directly, view it on GitHub > <#188 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACNR352GA7C7XAGMYZJUJZTY2VHKDAVCNFSM6AAAAABFNL5W2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRXGE4DQOBTGE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[punkymuzzle]

Understood - here's the logs

[fboundy]

As I suspected a couple of bugs once we start to use the inverter controller module. 4.0.0-solax-x1-beta-12 fixes these. If you could do the same again please. We should get to the point where it checks the inverter status and says that there is nothing to do.

[punkymuzzle]

Beta 12 installed, logs:

[fboundy]

If you have this in your config.yaml can you comment it out (though it's not fatal) then switch Read-Only off

  id_daily_solar: sensor.{device_name}_power_generation_today
  alt_tariffs:
    - name: Agile_Fix
      octopus_import_tariff_code: E-1R-AGILE-23-12-06-G
      octopus_export_tariff_code: E-1R-OUTGOING-FIX-12M-19-05-13-G

    - name: Eco7_Fix
      octopus_import_tariff_code: E-2R-VAR-22-11-01-G
      octopus_export_tariff_code: E-1R-OUTGOING-FIX-12M-19-05-13-G
    - name: Flux
      octopus_import_tariff_code: E-1R-FLUX-IMPORT-23-02-14-G
      octopus_export_tariff_code: E-1R-FLUX-EXPORT-23-02-14-G

[punkymuzzle]

I don't have those in my config.yaml.
The only things I have enabled regarding tariffs are:

`octopus_account: x-xxxxxxx
octopus_api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

octopus_import_tariff_code: x-xx-xxxxx-xxxx-xx-xx-xx-x
octopus_export_tariff_code: x-xx-xxxxxxxx-xxx-xxx-xx-xx-xx-x`
(Removed the detail from this)

The dashboard is using the above to lookup my tariffs?

Do you want me to disable these as well?

[fboundy]

No. They can stay

…

On 29 Mar 2024 at 17:34 +0000, punkymuzzle ***@***.***>, wrote: I don't have those in my config.yaml. The only things I have enabled regarding tariffs are: `octopus_account: x-xxxxxxx octopus_api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx octopus_import_tariff_code: x-xx-xxxxx-xxxx-xx-xx-xx-x octopus_export_tariff_code: x-xx-xxxxxxxx-xxx-xxx-xx-xx-xx-x` (Removed the detail from this) The dashboard is using the above to lookup my tariffs? Do you want me to disable these as well? Logs: , pv_opt.log error.log — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[punkymuzzle]

OK ta

[fboundy]

Though you only need the 1st pair or the 2nd pair or octopus_auto: true

…

On 29 Mar 2024 at 17:34 +0000, punkymuzzle ***@***.***>, wrote: I don't have those in my config.yaml. The only things I have enabled regarding tariffs are: `octopus_account: x-xxxxxxx octopus_api_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx octopus_import_tariff_code: x-xx-xxxxx-xxxx-xx-xx-xx-x octopus_export_tariff_code: x-xx-xxxxxxxx-xxx-xxx-xx-xx-xx-x` (Removed the detail from this) The dashboard is using the above to lookup my tariffs? Do you want me to disable these as well? Logs: , pv_opt.log error.log — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[fboundy]

Looking at the log:

Octopus autodetection is working OK. This is the default so you can actually comment out all the octopus account into in config.yaml but not critical.

We are nearly there! I think we can get around the latest error by adding this to the config.yaml (2 leading spaces):

 id_backup_grid_charge: select.solax_allow_grid_charge              

[punkymuzzle]

Great news.
OK, added the line above, saved and copied logs:

[punkymuzzle]

One thing I have noticed is this:

Before pv_opt, both periods were allowed, and Grid charging was enabled (otherwise I can't charge from the grid).

I tried resetting these but they just revert back to the above.
When I put pv_opt into read only mode I can set them? So assuming pv_opt is controlling this and will change if necessary?

[punkymuzzle]

Still not working.
The charging plan bit is working, but it won't set a charge. Tried the test dashboard with the same results.
Had to use the app in the end, but even that took a few attempts.
Noticed this in the log:

22:36:42 INFO: Current charge/discharge window ends in 23.3 minutes.
22:36:42 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_1 (Attempt 1 of 5)
22:36:43 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_1 (Attempt 2 of 5)
22:36:43 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_1 (Attempt 3 of 5)
22:36:44 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_1 (Attempt 4 of 5)
22:36:44 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_1 (Attempt 5 of 5)
22:36:45 ERROR: - FAILED
22:36:45 INFO: Setting select.solax_charger_start_time_1 to 22:30
22:36:45 INFO: Setting select.solax_charger_end_time_1 to 23:00
22:36:45 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_2 (Attempt 1 of 5)
22:36:45 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_2 (Attempt 2 of 5)
22:36:46 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_2 (Attempt 3 of 5)
22:36:46 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_2 (Attempt 4 of 5)
22:36:47 WARNING: - Retrieved invalid state of unknown for select.solax_charger_start_time_2 (Attempt 5 of 5)
22:36:47 ERROR: - FAILED
22:36:47 INFO: Setting select.solax_charger_start_time_2 to 22:30
22:36:47 INFO: Setting select.solax_charger_end_time_2 to 23:00
22:36:47 INFO: Power 3500 = infA at 0.0V
22:36:50 INFO: Entity: number.solax_battery_charge_max_current Value: inf Old State: 20.0 New state: 20.0 Diff: inf Tol: 1.0
22:36:50 INFO: Failed to write current of infA to inverter
22:36:51 INFO: Entity: number.solax_forcetime_period_1_max_capacity Value: 45.0 Old State: 80.0 New state: 45.0 Diff: 35.0 Tol: 1.0
22:36:51 INFO: Target SOC 45% written to inverter
22:36:51 INFO: Waiting for inverter Read cycle: 360 seconds

Also, the "Backup Grid Charge" was set to disabled and wouldn't be set to enabled (I watched it revert every time I set it). This also happened to the charging mode (set to Self use mode). Once I opened the app and tried to change the mode did it then change in HA.

.
.
So my previous question still stands - does pv_opt set this setting, or is this being kept by the Solax integration?

pv_opt.log
error.log

[punkymuzzle]

Plus, not sure what time this happened but these appeared in the AppDaemon Log:

/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2002: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))

[punkymuzzle]

Sorry for all the updates....
As thigs were still not working I decided to rollback the SolaX Modbus Integration to its previous version. Rebooted HA and now everything seems to have sprung back to life.

HA started OK

• AppDaemon started with no errors

pv_opt started OK

• Tariffs were accessed and read
• The charging plan was configured and written
• When the inverter read time was reached, the charging times were set, as well as "Backup Mode"
• when the time came (23:30), the battery started charging

So it looks like we're back on track with pv_opt working OK.
The charging time is set for quite a few hours (06:30 tomorrow) so I won't know for sure if it's fixed for a while yet. But I'll keep an eye on it and report back tomorrow.

If this does work, I'll more than likely need some help from you to quantify what was causing the issue, so I can report back to the Solax Modbus Integration Dev
Thanks

[punkymuzzle]

Update....
pv_opt ran overnight and into this morning without any issues, which is really promising.
So it definitely looks like the Solax Modbus integration broke it.
Out of interest, have you had any feedback / issues from others who are using it, but with different inverters? Just curious as to whether the update has affected everyone, or if I'm just "special".

I'll leave it to run today and overnight (when I've had previous issues with the inverter going into standby) and update you tomorrow. In the meantime, here's the latest logs fyi:
pv_opt.log
error.log

Thanks

[fboundy]

There is an error related to your power data because it appears to being sampled at very high frequency. It's periodic but I will try to add a fix to catch it when I get a chance

[punkymuzzle]

That would be great, thanks very much.

[punkymuzzle]

I think the inverter is going idle again.
The charging schedule set to 23:30 and the times were set in the Dashboard:

However, it wouldn't come out of "Self Use" mode. I tried changing it several times but nothing.
Tried force charging it vis the "Test" - nothing.

I had to go to the SolaX app and change the mode to "Forced time use" and then save, before coming back to HA and forcing a charge.
I'll do some more digging on how to keep the inverter from going into idle mode.
Unless there's something that can be scripted in pv_opt?

[punkymuzzle]

Looks like this is a known issue.
There is a discussion on the HA community ref the Solax Modbus Integration and lots of people have this issue.
https://community.home-assistant.io/t/universal-solar-inverter-over-modbus-rs485-tcp-custom-component-growatt-sofar-solax-solis/140143/145?page=7
one approach is to set an automation to preserve charge above 10% to stop it going idle (as you then can't write to the inverter until power gets to it - via PV).
My automation changes the mode to "Backup mode" once the SOC gets below 13%, so in theory this will keep it alive. However, others also set it to charge for a short while when it gets to 11% SOC.
I'll keep an eye on my automation and if it's not working correctly I might change it.

Alternatively, someone has said that you can wake the inverter from the Solax Modbus. I've just taken a look and there is a "Battery Waken" button which can be pressed, which should wake the inverter:

The entity behind it is:
button.solax_battery_awaken

I'll take another look tomorrow and if the inverter is idle I'll press it and then see if it comes back to life. If this is successful, can pv_opt be configured to use this entity just before it writes the charging times to the inverter? This will ensure the inverter is "awake" and gets the settings.

[punkymuzzle]

So I think I've found a way to fix my inverter from going into idle mode (which seems to be preventing pv_opt from setting charging schedules once my battery SOC is at 10%.

Asked good old Co-Pilot about the above entity and it came back with this:

Copilot
The entity “button.solax_battery_awaken” in the context of Solax Modbus integration refers to a control mechanism related to waking up or activating the battery functionality in a Solax hybrid inverter. Let’s break down its significance:

Battery Awaken:
This entity corresponds to the Bat_Awaken register in the Solax inverter.
When you send a value of 1 to this register (either via Modbus communication or other means), it activates the battery system.
Essentially, it “wakes up” the battery, allowing it to participate in charging and discharging operations.
Note that this activation might not be accurate if the batteries are cold or haven’t undergone a full charge-discharge cycle for an extended period12.
Use Cases:
If your Solax inverter goes into idle mode, you can use this mechanism to bring the battery back online.
It’s particularly relevant when you want to utilize the battery for energy storage during specific time periods.
Keep in mind that the behavior of this feature may vary based on the specific Solax model and firmware version3.
Considerations:
The “button.solax_battery_awaken” entity is essential for managing battery-related operations.
If you encounter issues with battery responsiveness, explore other settings such as power control or timed charge/discharge to ensure proper battery utilization4.

So it looks like if we send a 1 to this entity prior to setting the charging times on the inverter, it will wake the inverter from idle before.

Is this something that pv_opt can do as part of its process of setting the charging times?
Hopefully it is but if not then I will look to set an automation that runs every so often to do it.

Thanks

[punkymuzzle]

Oh and one other question.
Whenever I restart HA the following is always on.

.
Is there any way (in the config.yaml maybe) to set it to be off by default?
I don't have the ability to force discharge so I never use this option.

Thank you

[punkymuzzle]

It's been hit and miss today with it. sometime it worked, sometimes not. Had to power cycle everything earlier (Panels, Inverter, Modbus, battery etc) as it just became unresponsive and wouldn't respond to any commands to charge.
The latest time (just now)- it was working but the max charging current was set to 1A. I increased it to 20A and it's charging at maximum capacity now.

.
Looking at the history, it's doing it regularly:

Also, logs:
pv_opt.log
error.log

[punkymuzzle]

Upgraded to 3.14.2 - logs as follows:
pv_opt.log
error.log

[fboundy]

Can you tell from the logbook what is setting the charging current? Also if 20A is your max charge current it suggests that your charger_power needs to be set to ~2100W not 3500W

[fboundy]

Oh and one other question. Whenever I restart HA the following is always on. . Is there any way (in the config.yaml maybe) to set it to be off by default? I don't have the ability to force discharge so I never use this option.

Thank you

You should be able to force this to off by having the following in config,yaml:

overwrite_ha_on_restart: true
forced_discharge: false

[punkymuzzle]

Found this in a technical manual online (Mine is 3.6) :

.
From here:
https://midsummerwholesale.co.uk/pdfs/solax-x1-ac-user-manual.pdf

Does this help?

[punkymuzzle]

Logs:
error.log
pv_opt.log

[punkymuzzle]

Something's still not quite right.

Grid charge seems to be disabled again:

Max charging current very low again:

Battery didn't charge overnight:

Logs:
pv_opt.log
error.log

Lots of entries in the AppDaemon log:

/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/solax.py:112: RuntimeWarning: divide by zero encountered in divide
current = abs(round(power / self.host.get_config("battery_voltage"), 1))
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)
/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)

[punkymuzzle]

Here's a new one:

So it's not proposing any charging slots at all. I would have thought it would interrogate the Octopus slots and at least charged in the cheapest ones?

But it hasn't suggested anything....

Restarted AppDaemon and it says the same thing.

The log extract shows:

17:00:08 INFO: Current inverter status:
17:00:08 INFO: ------------------------
17:00:08 INFO: use_mode : Self Use Mode
17:00:08 INFO: allow_grid_charge : Period 1 Allowed
17:00:08 INFO: lock_state : Unlocked - Advanced
17:00:09 INFO: backup_grid_charge: Disabled
17:00:09 INFO: charge :
17:00:09 INFO: start : 17-Apr 06:00 BST
17:00:09 INFO: end : 17-Apr 06:00 BST
17:00:09 INFO: current : 20.0
17:00:09 INFO: active : False
17:00:09 INFO: discharge :
17:00:09 INFO: start : 17-Apr 00:00 BST
17:00:09 INFO: end : 17-Apr 00:00 BST
17:00:09 INFO: current : 0.0
17:00:09 INFO: active : False
17:00:09 INFO: hold_soc :
17:00:09 INFO: active : False
17:00:09 INFO: soc : 0.0
17:00:09 INFO:
17:00:09 INFO: No charge/discharge windows planned . Nothing to do.
17:00:09 INFO: Optimiser will run every 10 minutes from 17:10 or on PV_OPT Event

[punkymuzzle]

Battery didn't charge again last night and I get these in the AppDaemon log:
I still reckon it's to do with the inverter / battery going idle at 10% SOC...

/homeassistant/appdaemon/apps/pv_opt/pv_opt.py:2019: RuntimeWarning: divide by zero encountered in divide
self.charge_current = self.charge_power / self.get_config("battery_voltage", default=50)

[fboundy]

I think that may be correct. It's getting a voltage of zero back which I can workaround but does it need to send the inverter a "wakeup"?

[punkymuzzle]

Yeah that's what I was referring to a few posts ago:

.
I did press it last night before I went to bed but the next charge wasn't scheduled until about 0330, so I think it went idle again.

That's why we need either an automation in HA to do it, or preferably a command sent from pv_opt to wake it before it sets charging schedules etc.
Is this approach something that can be included?

[punkymuzzle]

Still having problems when the inverter reaches 10% and goes idle. I had to use the Solax app to wake the inverter earlier, so not sure if the "Battery Wake" button approach is feasible.

However, I've seen this in a separate thread:

So if the inverter is idle you can't write to it.

I've noticed that pv_opt doesn't write to the inverter until a few minutes before it wants the inverter to do anything. So when the inverter is idle this approach won't work.

We might have two possible ways to approach this:

1. Would it be possible to change the timing to write to the inverter as soon as the next charging cycle is calculated? For example, if the next two cycles were 2100 - 2130 followed by 2300 - 0000, can we set the second charge time as soon as the first one is complete?

Then, if the inverter goes idle the charging time is already set so it should wake up and charge?

or:

2. Is there any way to configure pv_opt to use a higher SOC as it's minimum? My current charging plan shows the battery going down to 10% charge, but if we can get pv_opt to have its minimum to say 12%, the inverter would in theory still be running and would not enter an idle state.

If either of the above is doable, I reckon that this will get round the issue of inverters becoming unresponsive when they go idle (this seems to affect lots of inverters, not just mine)

Would this be possible?

[punkymuzzle]

This is still having problems with the inverter going idle.
None of the Modbus settings seem to wake it once it's gone idle and the only way I can wake it is to use the Solax App to set a charging time which brings the SOC above 10% - then the inverter becomes responsive again.

So if either of the above approaches are feasible then please let me know.
Thanks

[punkymuzzle]

Still problems
I can use an automation to change the mode to "Backup Mode" which stops the inverter from discharging, but pv_opt then overwrites it at the next write cycle.

Also I have noticed this:
I have a charge set 0300 - 0500. However pv_opt is setting the charge times to 0000 - 0000 and will in theory set it nearer the time - however as the inverter is idle (SOC 10%) it doesn't work. This is what the above posts are about.

The additional info is that when I put pv_opt in read only mode, it still clears the charging times.
From my Solax app:
UPDATE - it eventually went into read only mode so hopefully this won't overwrite the settings again....

settings after pv_opt set in read only mode and has done a full cycle:

I might have to stop using pv_opt as it's not doing what we want it to. It's such a shame as we're so close, we just need to prevent the inverter from going idle (as per the above posts).

I'll probably disable it until you have the time to update it.
Thanks

[punkymuzzle]

Latest update - It doesn't want to set a charging plan:

From the log:

22:21:14 INFO: Optimisation Summary
22:21:14 INFO: --------------------
22:21:14 INFO:
22:21:14 INFO: Base cost: -124.5p
22:21:15 INFO: Optimised cost (Optimised Charging): -124.5p
22:21:15 INFO: Optimised cost (Optimised PV Export): -124.5p <=== Current Setup
22:21:15 INFO: Optimised cost (Forced Discharge): -124.5p
22:21:15 INFO:
22:21:15 INFO: No charging slots
22:21:15 INFO:
22:21:15 INFO: Plan time: 25-Apr 21:00 - 26-Apr 23:30 Initial SOC: 30.5 Base Cost: -124.5 Opt Cost: -124.5
22:21:15 INFO:
22:21:15 INFO: Optimiser elapsed time 58.7 seconds

However, here's the prices for tomorrow:

So I would have expected it to charge up during the slightly cheaper time early in the morning to cover the more expensive 0600 - 0930 slot, until my solar PV kicked in?

[fboundy]

Sorry - can't really tell you much without a log file

[fboundy]

I'm going to close this very long issue to help with my house-keeping! There's already a separate one for the Wake-Up issue which I think I can address. Please raise specific queries with log files attached.