fboundy
Support Request for Latest Solarman Integration
Numerous Entities are inconsistent with the original version of Solarman.
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.
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
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.
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.
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: @.***>
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.
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.
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: @.***>
Anticipated it would be re-calculating every 10 mins, nothing in pt_opt.log since 16:32 yesterday.
Yes it should be recalculating every 10 mins, please post error.log and pv_opt.log. is the status still Idle?
Not entirely sure what's wrong. Can you change back to read only using the dashboard toggle and check it runs every 10 mins.
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
Nothing to do with Solarman then. Do an edit to config.yaml and see if the restart then sorts it.
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.
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
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: @.***>
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.
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.
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
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.
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.
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?
Are the other two sets of times and Allow Charging from Grid available as entities?
Guess that's one for David Rapin.
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.
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:
- Change solis_hybrid.yaml such that the new Solarman integration provides separate hours and minutes entities, as per the old.
- Update Pv_opt to deal with Solarmans storage control register providing strings rather than numbers (this is quite similar to Solax anyway)
- 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.