Support Request for Latest Solarman Integration

[Pyinthesky99]

Numerous Entities are inconsistent with the original version of Solarman.

[stevebuk1]

Solarman at https://github.com/StephanJoubert/home_assistant_solarman doesnt look like its being actively supported.

There is a fork at https://github.com/davidrapan/ha-solarman which is active, however when applying a Solis related yaml file the sensor names are different.

The largest change is that there were previously separate entities for hours and minutes for the charge/discharge time registers but these are now combined into a single entity. A new inverter def of SOLIS_SOLARMAN_V2 has therefore been created to allow these entities to be read. This is being developed on branch "Patch2" on my Pv_opt fork.

Re writes, the previous SOLARMAN integration used "call_service/solarman" to write directly to a modbus register, which would mean hours and minutes would still be written separately. This servce (now called action in HA) exists in the new Solarman integration but it is unknown whether it will work in the same way if provided with a modbus register address. If not a different method will need to be found to write to the mode control, the charge/discharge current values and the charge/discharge start and end times - direct writes to the entities may work.

[Pyinthesky99]

Apologies, had to rush out this morning so opened this issue and went. Was going to flesh-out the opening comment on my return but you have a far better understanding of the issues and have done a better job. Have un-hashed the lines in config.yaml but still getting in pv_opt.log 15:54:38 ERROR: id_timed_charge_current : Neither the entities listed in the YAML sensor.solis_timed_charge_current nor the system default of number.solis_timed_charge_current_limit exist in HA. error.log pv_opt.log config.yaml11-10-24.txt

[stevebuk1]

I'd forgotten that whilst I've been keeping a master config yaml up to date, I haven't sent it to you for inclusion.

Just make your entries in Solarman_v2 say this

id_timed_charge_current: number.{device_name}_timed_charge_current

id_timed_discharge_current: number.{device_name}_timed_discharge_current

I.e both say number, not sensor.

[Pyinthesky99]

Set to number and we now have idle with Read Only Mode set to off.

Last line of pv_opt.log... 16:32:47 INFO: No charge/discharge windows planned . Nothing to do.

[stevebuk1]

Hurrah! Ok, so now run for 24 hours. This will log what's going to be written but without actually doing any writes. Hopefully there will be some charge windows scheduled, but that depends on Agile rates and amount of solar expected.

On Fri, 11 Oct 2024, 16:36 Pyinthesky99, @.***> wrote:

Set to number and we now have idle with Read Only Mode set to off.

Last line of pv_opt.log... 16:32:47 INFO: No charge/discharge windows planned . Nothing to do.

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/273#issuecomment-2407665375, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMHBJKPLJ6QILQM55HLZ27V7HAVCNFSM6AAAAABPYP72SSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBXGY3DKMZXGU . You are receiving this because you commented.Message ID: @.***>

[Pyinthesky99]

Hurrah indeed! Thanks for your help so far. Couldn't change 'Loading Configuation' in the 24 hours you have off?!! :-) Sunny day today but not great tomorrow apparently.

[Pyinthesky99]

BTW the problem with my Status of Battery Charge and Discharge is that the entity sensor.solis_battery_power that I used in configuration.yaml to provide Charge and Discharge never goes to a negative! There doesn't seem to be a direct replacement in Solarman for the entity used to generate battery_input_energy/battery_output_energy in the standard dashboard.

[stevebuk1]

Mmmm I was thinking afterwards that the number is always positive so it cant deduce charge or discharge. I guess you could read the text that says charge/discharge, add the appropriate sign and then run the template, but I suspect it's not worth it. Pv opt doesn't use it so it's just dashboard related. One for the future perhaps!

On Fri, 11 Oct 2024, 17:03 Pyinthesky99, @.***> wrote:

BTW the problem with my Status of Battery Charge and Discharge is that the entity sensor.solis_battery_power that I used in configuration.yaml to provide Charge and Discharge never goes to a negative! There doesn't seem to be a direct replacement in Solarman for the entity used to generate battery_input_energy/battery_output_energy in the standard dashboard.

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/273#issuecomment-2407709867, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMBOPJ4JNAG5CKIFC33Z27ZDPAVCNFSM6AAAAABPYP72SSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBXG4YDSOBWG4 . You are receiving this because you commented.Message ID: @.***>

[Pyinthesky99]

Anticipated it would be re-calculating every 10 mins, nothing in pt_opt.log since 16:32 yesterday.

[stevebuk1]

Yes it should be recalculating every 10 mins, please post error.log and pv_opt.log. is the status still Idle?

[Pyinthesky99]

Status is indeed still idle error.log pv_opt.log

[stevebuk1]

Not entirely sure what's wrong. Can you change back to read only using the dashboard toggle and check it runs every 10 mins.

[Pyinthesky99]

Toggled to Read-Only at 14:42 and it cycled around to Idle (Read Only). Waited to 14:55 and no more cycles or update to pv_opt.log config.yaml.txt error.log pv_opt.log solis.py.txt

[stevebuk1]

Nothing to do with Solarman then. Do an edit to config.yaml and see if the restart then sorts it.

[Pyinthesky99]

edit?

[Pyinthesky99]

Guess any edit, have done.

[stevebuk1]

Yes, any edit. Just a carriage return will do.

If you don't get a reoptimise on the 10 minute time turnover (i.e 10, 20, 30, 40, 50, 00) then try an appdeamon reboot.

[Pyinthesky99]

Didn't seem too keen after auto-restart after edit so did a Developer Tools Restart and we have now had at least one 10min recalculate. It had come up with a plan after switching to Read only at 14:00 today which wasn't too realistic but has now come up with a decent plan, presumably as tomorrow's rates are out. Will see what it's like after another day? Will probably do some 'manual' charging overnight. Thanks again

[stevebuk1]

Ok if you are getting 10 min recalculates in read only mode, set it to false and check we are still getting 10 minute recalcs, let me know if not otherwise try the 24 hours again?

Feel free to set the inverter to whatever you want, it won't affect the testing we are doing.

On Sat, 12 Oct 2024, 16:35 Pyinthesky99, @.***> wrote:

Didn't seem too keen after auto-restart after edit so did a Developer Tools Restart and we have now had at least one 10min recalculate. It had come up with a plan after switching to Read only at 14:00 today which wasn't too realistic but has now come up with a decent plan, presumably as tomorrow's rates are out. Will see what it's like after another day? Will probably do some 'manual' charging overnight. Thanks again

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/273#issuecomment-2408603511, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMFWPKSXFS3T5OCSFNTZ3E6TNAVCNFSM6AAAAABPYP72SSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBYGYYDGNJRGE . You are receiving this because you commented.Message ID: @.***>

[Pyinthesky99]

It has actually changed things slightly, I set the Inverter manually and the cycle now stops with Updating Inverter rather than continuing to Idle. I assume the script effectively uses just the first of the three charge and discharge time settings available manually? I had set manually using the first two pairs. Only the first shows on my Dashboard with the start/stop entities... I have just reset the Inverter to charge using the second and third pair and it now cycles around to Idle.

[stevebuk1]

Thanks for the update. Despite me just saying that what the inverter is set to shouldn't matter, it does in some way because if the inverter start and end times are different and there is no charge plan, it will be trying to reset them to be the same.

If they are the same it doesn't need to write and so will go to idle, but if it does need to match them up it will attempt the writes and its either getting stuck (as they are disabled) so the start/end times remain different, or there's another problem. Can you post pv_opt.log and error.log so I can see.

[stevebuk1]

You are quite right that Pv_opt only uses the first set of registers: contiguous slots are joined together and as the inverter recalculates every 10 mins it will just programme later slots slightly in advance of when needed, so theres no need to use the 2nd and 3rd slots

[Pyinthesky99]

error.log pv_opt.log

Still humming away nicely!

[stevebuk1]

Excellent!

This is your latest charge plan:

21:40:15     INFO: Optimal forced charge/discharge slots:
21:40:15     INFO:   12-Oct 23:30 BST - 13-Oct 00:30 BST  Power:  5000W  SOC:   38% ->   86%  
21:40:15     INFO:   13-Oct 03:00 BST - 13-Oct 04:30 BST  Power:  5000W  SOC:   79% ->  100%  
21:40:15     INFO:   13-Oct 05:00 BST - 13-Oct 05:30 BST  Power:   300W  SOC:   99% ->  100%  <=
21:40:15     INFO:   13-Oct 06:00 BST - 13-Oct 06:30 BST  Power:   300W  SOC:   99% ->  100%  <=

Agile has some excellent prices tonight I note, and Pv_opt is doing a good job of saying 'run from battery in the slightly more expensive slots' (04:30 to 5:00 and then 05:30 to 06:00).

I do expect it will run into problems at 23:30 when it tries to load the first charge plan, but this is what I'm after in the logs.

[Pyinthesky99]

Thought I would check at 23:20 on Charge Schedule and Status was on updating inverter again, it had gone from nothing to do to "23:20:15 INFO: Disabling inverter timed discharge" in the log. So just as you said. Log looks like it thinks it has set the charge?

Status at 23:40

These are current logs, will send updated logs in the morning.

error.log pv_opt.log

[Pyinthesky99]

Cycling back to idle this morning. error.log pv_opt.log

I guess all three pairs of timings have to be empty for a 'clean' 24hr cycle of optimization. Are the other two sets of times and Allow Charging from Grid available as entities?

[Pyinthesky99]

Are the other two sets of times and Allow Charging from Grid available as entities?

Guess that's one for David Rapin.

[stevebuk1]

Are the other two sets of times and Allow Charging from Grid available as entities?

They aren't in the default "Solis_hybrid.yaml" provided on the SolarMan repo. I note they aren't also part of the source file used to create the yaml file (https://www.scss.tcd.ie/Brian.Coghlan/Elios4you/RS485_MODBUS-Hybrid-BACoghlan-201811228-1854.pdf). However, they are certainly accessible as the Solax integration provides them. If you fancied having a play, you can get the modbus register numbers from the Solax integration here: https://github.com/wills106/homeassistant-solax-modbus/blob/main/custom_components/solax_modbus/plugin_solis.py, e.g search for "timed_charge_start_hours_2" within this file.

[Pyinthesky99]

Thanks for the info, Steve. Not much of a Charge Plan for tonight!

[stevebuk1]

I guess all three pairs of timings have to be empty for a 'clean' 24hr cycle of optimization.

Pv_opt only uses the first pair of charge start/end times and doesn't try to read the other two pairs. It runs clean if there is no charge windows that require setting, as the code can now load the values from Solarman to see if charge start and charge end are the same. If they are different, it will try and set them, but the setting process is still based on hours and minutes separately so the entities currently aren't found.

Separately to this is functionality of the inverter storage mode. This does have a single entity but it currently expects a number and is getting a string. Again, this is only checked when a charge window approaches.

Pv_opt has been written carefully to minimise the number of actual write operations to the inverter. The inverter itself will use non-volatile memory to store all these settings, and these memory locations have a limited number of reads and writes. Pv_opt therefore always reads the value to ensure it actually needs writing to before commanding the write and this is done at the very lowest level of code, which isnt particularly aware of what is actually being read/written. The reads are done from entities but the writes are done using modbus register numbers. Most of the other Solis integrations generally have a one2-one mapping between entities and Modbus registers which makes this easy, but the new Solarman definitions have changed this, e.g hours and minutes are now in a single entity.

I think the quickest way of getting this up and running will be a different approach for the 3 categories of 1) time registers, 2) inverter mode control and 3) current (charge rate) registers:

1) Change solis_hybrid.yaml such that the new Solarman integration provides separate hours and minutes entities, as per the old. 2) Update Pv_opt to deal with Solarmans storage control register providing strings rather than numbers (this is quite similar to Solax anyway) 3) Current registers I think will work as is.

I guess what I'm really saying is this isn't going to be a quick job and we are probably looking at several weeks. If you are happy to continue then we will start with 1) and I'll create a new solis_hybrid.yaml file for use with Solarman.

[Pyinthesky99]

Thanks for the explanation, I'm happy if you are.

[Pyinthesky99]

now I need to get them into columns!

[stevebuk1]

Great! Saves a walk to the garage....

Note - I may have to go back to hours and minutes to get PvOpt to work, but thats only applies to the first pair. Please post your solis_hybrid.yaml file as I'll need to modify whatever your latest is to do this.

On Mon, 14 Oct 2024, 11:28 Pyinthesky99, @.***> wrote:

image.png (view on web) https://github.com/user-attachments/assets/409bfa27-d687-47a5-a098-7f6409a3b692

now I need to get them into columns!

— Reply to this email directly, view it on GitHub https://github.com/fboundy/pv_opt/issues/273#issuecomment-2410748131, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASVRJMBDFQID6CIKW7NNFA3Z3OMERAVCNFSM6AAAAABPYP72SSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJQG42DQMJTGE . You are receiving this because you were assigned.Message ID: @.***>

[Pyinthesky99]

This is the solis_hybrid.yaml that includes the above solis_hybrid.yaml.txt

[Pyinthesky99]

Great! Saves a walk to the garage....

ATM, when I am not charging every night, I would tend to walk to the Garage and set 'Charging from Grid' to not allow, more steps but less writes to NVRAM? That's another entity that is on the Solax Integration but not the Solis (Register 43110). I think a trifle more complicated than adding the extra switching times from Solax to Solarman!

[stevebuk1]

That's another entity that is on the Solax Integration but not the Solis (Register 43110). I think a trifle more complicated than adding the extra switching times from Solax to Solarman!

Yes, this is the area of complexity!

The Solarman integration provides readonly register 33132 as sensor.solis_storage_control_modewhich is in your entity list. Apparently this is the same as the value of read/write register 43110, according to this sceengrab of the pdf link thats at the top of solis_hybrid.yaml:

Now, this appendix only maps 4 bits, but in reality there are 7 bits in the inverter, as follows:

Bit 0 = Self use Bit 1 = Timed/Charge Discharge Bit 2 = Off Grid Bit 3 = Battery Wake Bit 4 = Backup mode Bit 5 = Allow grid charging Bit 6 = Feed in priority mode

The way these bits map onto what menu item is not particularly intuitive and is subtlety different between inverter models. A key point though is that some Solis inverters don't respect Bit5, i.e. they will charge from grid regardless of whether it is set or not. Partially for this reason but also to protect number of writes, Pv_opt makes as little use of the energy storage control register as possible. There are only two combinations it actually uses, Timed Charge/Discharge(a subfunction of self use) and Backup mode. All control of whether the inverter is going to actually charge/force discharge or not is done by setting the charge/discharge start/end times.

Whilst all of the integrations provide subtledly different ways of reporting the value of this register, Pv_opt just calculates the actual number it wants this register to be. For Solax control, it has to translate it to a dropdown list of inverter modes for both reads and writes. For Solarman, we write the numeric value directly but to read it, we need to read the value of sensor.solis_storage_control_mode which will be one of the following values: Self Use Optimized Revenue Time of Use Off-Grid Storage Battery Wake-Up Feed-In Priority

Basically the list includes "Time of Use" which is the mode we need to be in. It currently doesnt include backup mode. This isnt an issue right now because Francis coded the original Solarman integration not to use it, but I suspect a tweak of Solis_hybrid.yaml with some more hex codes means it will report it. We will deal with backup mode right at the end.

[stevebuk1]

New solis_hybrid.yaml (remove the .txt extension): solis_hybrid.yaml.txt

You'll see I've commented out the Pair1 start/end times with hours/minutes combined, and re-instantiated hours and minutes separately. Pairs 2 and 3 are unaffected so you can still use these for manual programming for the time being.

New Solis.py at https://github.com/stevebuk1/pv_opt/blob/patch2/apps/pv_opt/solis.py

This should read the hours and minutes entities and also now corrrectly read the text strings reported by sensor.solis_storage_control_mode

Writes to the inverter are still disabled.

Please: 1) load the new solis_hybrid.yaml and check the entity "number.solis_timed_charge_start_hours" exists (probably not worth checking them all but there should be 8 registers, charge/discharge/start/end/hours/minutes 2) load solis.py, check you get 10 minute optimiser runs in readonly mode 3) readonly off, checfk you get 10 minute optimiser runs 4) After 1/2 hour of running post a pv_opt.log and error.log

Typos/silly error aside, I'm now hoping that the code for the writes actually runs and we get errors because the registers haven't updated.

[Pyinthesky99]

Copied across solis_hybrid.yaml Only number.solis entities are charge and discharge current

Did you mean sensor.solis?

[Pyinthesky99]

Probably not! Cycled back to Idle in Read only but cycles to Updating Inverter when Read-Only off. Last line of pv_opt.log on that cycle 22:20:14 WARNING: - Retrieved invalid state of None for number.solis_timed_charge_start_hours (Attempt 5 of 5) 22:20:14 ERROR: - FAILED error.log pv_opt.log

[stevebuk1]

Copied across solis_hybrid.yaml Only number.solis entities are charge and discharge current

Did you mean sensor.solis?

I did mean number rather than sensor. Its because I can't spell "platform"!

Try this one: solis_hybrid.yaml.txt

[Pyinthesky99]

Does that matter? :-) We now have clean runs to idle with Read Only Off every 10 mins. Actually I just edited all instances of plaform in V1.1, you may have missed the two charge currents in V1.2. Interestingly, a charge plan is calculated with times on the 16th when the costs aren't out yet! Presumably updated after 4pm ,

All control of whether the inverter is going to actually charge/force discharge or not is done by setting the charge/discharge start/end times.

Presumably, setting charge times by the inverter switches go through some sort of holding register before being loaded proper as they need Grid Charging to be Allowed? pv_opt.log error.log

[stevebuk1]

Interestingly, a charge plan is calculated with times on the 16th when the costs aren't out yet! Presumably updated after 4pm ,

Pv_opt makes use of Agile predictions for the next day which it downloads from the Nordpool website. These are subject to change at 4pm but on the whole are pretty accurate.

Presumably, setting charge times by the inverter switches go through some sort of holding register before being loaded proper as they need Grid Charging to be Allowed?

That doesnt appear to be a restriction when using Modbus. My times are updateable if the grid charging bit is cleared. It probably doesn't matter because I'm pretty sure the grid charging bit is set for both the modes that Pv_opt uses. You can see the status of the 7 bits within Pv_opt.log here:

Current inverter status:
09:56:45     INFO: ------------------------
09:56:45     INFO:   mode              : Self Use
09:56:45     INFO:   code              : 33
09:56:45     INFO:   switches          :
09:56:45     INFO:     SelfUse         : True
09:56:45     INFO:     Timed           : False
09:56:45     INFO:     OffGrid         : False
09:56:45     INFO:     BatteryWake     : False
09:56:45     INFO:     Backup          : False
09:56:45     INFO:     GridCharge      : True
09:56:45     INFO:     FeedInPriority  : False

Thanks for the logs, will look later.

[stevebuk1]

Presumably, setting charge times by the inverter switches go through some sort of holding register before being loaded proper as they need Grid Charging to be Allowed?

Realised I might have misunderstood this question. Almost everything is recalculated every time the optimer runs, nothing is stored away. The inverter is loaded with slot information only if it is within 10 minutes of a slot. Once charging, the inverter is modified if Pv_opt comes up with a different plan on the next run, but given all the inputs shouldnt change this is unlikely (sometimes this can happen when Solcast is updated and the forecast changes).

The logs look like all the reads are now working. What I need to log is when Pv_opt wants to write to the inverter, which as explained above will only happen on slot starts and ends. We;ll need to wait till tomorrow for that to happen? Just leave it running in readonly = false/off and send logs after at least one slot has run through fully, or PV_opt crashes.....

[Pyinthesky99]

All good info, but I did mean the manual switches on the front of the inverter :-) I have already manually set some charge times, 3:30 to 5:00, do you want me to scrub them? PVopt has this currently....

[Pyinthesky99]

Current SOC is 53%, don't anticipate it going below 40% before things kick off

[stevebuk1]

I have already manually set some charge times, 3:30 to 5:00, do you want me to scrub them? PVopt has this currently....

Keep your manual times. I need to test out the routines within Pv_opt that are activated when it wants to update the inverter. The actual update of the inverter is still disabled. I want to be sure as I can be that everything is working before adding actual inverter control.

[Pyinthesky99]

Manual charging went off OK, SOC dropped to 41 before charge started. PV_OPT Status Idle this morning and doing 10min cycles, but you can probably tell all that from the logs. error.log pv_opt.log

Just as a heads up, my hospital visit has been re-scheduled to tomorrow.

[Pyinthesky99]

at 09:40 log started reporting errors.. 09:40:29 WARNING: - Retrieved invalid state of unavailable for sensor.solis_today_load_consumption (Attempt 1 of 5) 09:40:31 WARNING: - Retrieved invalid state of unavailable for sensor.solis_battery (Attempt 1 of 5) 12:02:51 WARNING: - Retrieved invalid state of unavailable for sensor.solis_storage_control_mode (Attempt 1 of 5) 12:04:21 WARNING: - Retrieved invalid state of unavailable for sensor.solis_overdischarge_soc (Attempt 1 of 5) Anything to be concerned about? pv_opt.log

[stevebuk1]

Manual charging went off OK, SOC dropped to 41 before charge started. PV_OPT Status Idle this morning and doing 10min cycles, but you can probably tell all that from the logs.

Looks positive. A couple of logging errors and an inverted logic function corrected here. https://github.com/stevebuk1/pv_opt/blob/patch2/apps/pv_opt/solis.py Just run through a charging window again and post logs.

I might post another code release tonight, which will just do a fixed write to one of your times, perhaps write minutes to 02 or something. If that works then I can do final edits and enable everything, but will save that until your return. Hope it all goes well.

[stevebuk1]

Anything to be concerned about?

Pv_opt is finding some of the entities are unavailable.

It seems to come and go. PV_opt ignores battery soc if it can't find it and reverts to the last reading, as its only 10 minutes later it hasnt usually changed much. Others will error and end that particular optimisation run, but if they are found the next it doesnt matter too much.

In HomeAssistant, click on one of those entities and view the history, are they going unavailable?