Starting a new thread as this was getting lost in the Hints, Tips & Troubleshooting thread.
Post details of your integration with Home Assistant etc.
What about getting a harvi and doing away with the zappi CT altogether?
As for slowing the charge,
You could tell it to charge from grid at 0amps.
I wonder can you change the discharge amps of the inverter, but that could be overidden by the bms.. as you can already set nearly every setting.
Zappi is located right next to meter box, so it made wiring considerably easier. I suppose I could extend the inverter CT out to meter box, but it doesn't really cause me a problem. On intermittently cloudy days, I tend to run down battery and let inverter/battery handle any bursty generation.
Interesting, any reason your Zappi ended up like that? That introduces a problem where you can't run your Zappi in Eco mode and leverage the battery as a buffer on days where clouds are on/off. I find that quite useful to avoid thrashing on mixed sunny cloudy days.
Okay, I understand the use case a bit better now. I haven't tinkered with the charge current, but I was investigating the possibility of temporarily disabling the battery (effectively turning the hybrid inverter into a string inverter). My Zappi is connected from the meter box and not the consumer unit, so it only runs on true surplus as inverter CT can't see any Zappi loads. It would be helpful on the odd occasion that I might want to charge car before house battery is full.
You could probably achieve same with your Eddi up until generation exceeds 3kW, then re-enable battery and set a boost.
That only works if your battery has energy in the morning when you want to start the boost. If it's empty come 8am, I can only pull grid energy and can't control the current the Eddi uses during a boost. If you modulate the battery charge current, you can ensure the inverter only diverters power to the battery when the Eddi is maxed out at ~3kW.
What are the advantages over just setting a boost on the Eddi from battery, and then the the inverter top up the battery as the morning goes on?
Has anyone tried modulating the charging current of the battery? I want to use it to prioritize the Eddi first thing.
As a dev myself, I keep an eye on this thread. And I have to applaud your willingness to start poking/peeking about with registers. The last time I did that was on my old VIC-20 circa 1983.
But it does raise with me why they make it so difficult to remote control. Sure, security is important, but if they were serious about supporting the market, they could do it via a server generated API key. Yes, it's "more work" but man .... the stuff you're doing is hard.
Respect.
Yes, the problem lies in the Solarman HA integration. I am hoping to replace the current V5 processing code with pysolarmanv5 and make it more reliable.
For your set up 49 = disabled, 51 = enabled. Look at the binary representation of both and you'll see they differ by one bit, BIT1, which represents grid charging.
I never had this problem with pysolarmanv5 it either provides proper value or spits out some garbage and the exception handles that part and I just retry read again. When doing testing I do get that often but I never got an actual value that would be accepted. I think the problem that @mp3guy got is with home_assistant_solarman rather than with pysolarmanv5.
And that means? enabled? disabled?
49 XOR 2 = 51
51 XOR 2 = 49
Nice work. File a PR with the changes.
That is why integrating pysolarmanv5 is on the to-do list. Current implementation is naive.
Looks like response is not handled properly in the code. It should have some error checking to ignore these and reread the register. I was only getting crazy numbers when was reading modbus directly with 2 modbus masters present hence I had the relay switch to avoid this.
Nice, I trimmed some of the fat (got rid of leading/trailing registers not referenced) and now I'm getting stable 6 second polling;
requests: - start: 33029 end: 33095 mb_functioncode: 0x04 - start: 33116 end: 33179 mb_functioncode: 0x04 - start: 33206 end: 33282 mb_functioncode: 0x04
Read wise most values seem fine bar the odd crazy battery SOC spike:
I get 49 with:
print( modbus.read_holding_register_formatted( register_addr=43110, quantity=1 ) )
Clear the bitmask and bitshift and try again.
Thinking about it further, two distinct functions are probably required. One function to set a bits in a register high or low, using AND and OR as masks. The second then to toggle individual bits in a register using a XOR mask.
Well the read:
modbus.read_holding_register_formatted( register_addr=43110, quantity=1, bitmask=0x2, bitshift=1 )
Returns 0, not 33 so not sure it works then? Maybe FW dependent?
Actually I am getting 0 from all the holding registers with the above code but works if I remove the bitmask and bitshift values.
I get 49 from reading register_addr=43110, quantity=1 now
Yea, that would be great. A "change bit in holding register" utility function would be a really handy addition to the lib
Thanks
No, you need to read it and then XOR it and then write it. For the moment, read the value of 43110. If it is 33, set it to 35, and vice-versa. Look at 33 and 35 in hex and it will make sense to you then.
Although, I was thinking yesterday that it could be helpful to introduce a pseudo modbus function to do this in one step in pysolarmanv5. I'll see what I can do.
What's the write command?
modbus.write_holding_register( register_addr=43110, value=1, bitmask=0x2, bitshift=1 )
When I read I get 0 and then it needs to write 1?
Also do any of these 4xxxx registers allow us to toggle self use on/off? This is handy from charging car from grid without draining battery
You could try setting a 24 hour charge from grid period, and then toggle timed charging using 43110. Haven't tested it though.
Try to break it into 2 or 3 blocks. I was running into issues when trying to do large blocks.
I don't really want the schedule.
Looking for two lines of code I guess (if it works like that)
I have the older FW with the basic and useless schedules not the daily ones.
Can we force charge/discharge on demand?
Could it be tricked by setting overdischarge SOC to 99% for example when wanting to charge from the grid and then set it back to 15% when you want to use the battery?
https://github.com/StephanJoubert/home_assistant_solarman/blob/4d23fe8d25569efa4476b7c3e762f727712f4d9a/custom_components/solarman/inverter_definitions/solis_hybrid.yaml#L6 this set of three reads of 100 each, as Jonathan mentioned
You can run the script on windows or in docker on windows machine also. I actually write and test code on windows.
@mp3guy how many registers are you trying to read? Are you reading them in blocks or looping through each? As @Jonathan mentioned baud rate is only 9600. I am reading total of 129 registers devided in 8 blocks. It takes ~3-4s to do that but there is also overhead of formating, presenting and publishing. I would say the whole read is probably closer to 2s. I've read in some unoficial document that you should not exceed 100 registers in one go on solis modbus. My largest block has 34 registers.
Yes, but the Solis registers are a bit all over the place. The 50 or so sensors that are extracted as based on three reads requests of 100 registers each.
30 seconds polling is more than enough for my needs, so I haven't investigated much further, but I suspect the lag is introduced by the WiFi dongle. It doesn't help however, that the baud rate is only 9,600. @reklamos might be able to confirm the source of the slowness as he was previously reading directly off the RS485 port (bypassing the WiFi dongle).
Running HA OS so not sure if it's possible to add docker to it. Nodered is an addon of HA OS.So maybe this won't work for me, not a linux master or anything, in fact it's my least favorite OS 😁
Yuo need to run python code somewhere. You can run it directly in the OS where you have HA/Nodered or you can run it as container. I have everything conatinerized as it makes it easier but do what works best for you.
