When there is no sunlight my inverter goes to status No irradiation.
And i dont get these logs that say can’t read data.
Does yours go to the same status when there is no sunlight?
But he always reads E-total and E-day also when there is no sunlight.
Welkom to the community.
I think you better start with installing openhabian on a sd card.
And go from there. If you read the doc’s you will come al long way.
If it doesn’t work you can always ask here on the forum according to your problem if you have problems with the configuration of the inverter let me know.
I don’t have this kind of inverter but hopefully will have a SUN2000-8KTL-M0 in a few months. So I haven’t got a chance to see an inverter in real life.
I would like to connect to the inverter via wifi dongle and modbus tcp. Is it working or just with cable?
How will I get the numbers for the poller bridges (start, lenght)? How will I know which data can I get from the inverter?
I want to keep the data in local network and not use huawei api.
It does, there is no need for extra hardware connected to your inverter. Some models will only accept TCP connections when connected to the wifi AP, but others will accept connections from your router. The models that only accept TCP modbus connections through the AP are the SUN2000L and the ones that accept connections through the client are SUN2000L I think.
First of all, many thanks for sharing the know how here in the community.
I connected my SUN2000-(3KTL-10KTL)-M1 via a serial modbus USB-RS485-WE-1800-BT
I had issue to get serial modbus working stable but i got a fix from the modbus binding team resolving the OH3 issues with serial.
I am still struggling with stability as i by far get to much CRC error and re-try.
My cable is 1.8m long, so i would guess it should not be a big issue.
Here a few question i am still working on:
I saw that some inverter also support modbus tcp connections through the WLAN / ethernet dongle. Emilv2 has mentioned it. Is there any official statement from Huawei which model are supported or do you know which inverter model would support it? Or maybe a step by step tutorial?
I am trying to indicate the startup and shutdown time. The time is coming as a integer. Do you have a working transformation to transform the integer to a Datetime format on the item?
i do also get error messages from the binding when the inverter is shutting down. What would be the best way to gt ride of these? Is it possible to offline the things based on some information from the inverter in a rule?
I also have a SUN2000-(3KTL-10KTL)-M1 and i never managed to connect them by TCP.
You can use %s as transformation for date time.
Number Start_up_time "Start up time [%s] " { channel="modbus:data:slave100:slave105holding:Start_up_time:number" }
Number Shutdown_time "Shutdown time [%s] " { channel="modbus:data:slave100:slave105holding:Shutdown_time:number" }
You have to remove the wifi or ethernet module of de inverter and reboot openhab and the crc error’s would be gone.i have not been able to solve this yet i have already pulled a shielded cable and bought an ethernet module but if i plug in all 2 i get errors.
So i am not working with de huawei dongle.
I do have a battery now (luna 2000 huawei) i will update de modbus config with battery storage soon.
many thanks for the responds.
i unplugged the Dongle and see how stable the stuff is.
maybe it makes sense to get support from Huawei. I will try to make a feedback on the support line and share info
I implemented the transformation and get 2021-04-08T08:11+02:00
When i lookup the startup time in the fusion app from huawei i do get 7:11 .
so i guess the string represents UTC plus the daylight saving time.
any good way to make the transformation presenting the time in my actual time?
if i use [%1$tR] i do get 8:11, which does not include the day light saving.
I am not sure if this applies with the dongle discussed here but it certainly applies to generic serial-ethernet converters.
These converters introduce tcp fragmentation (modbus message is not aligned to tcp packets, meaning that one message might spread to two tcp packets)
Turned out fairly recently that tcp fragmentation is not handled properly in the modbus library used by the binding. Fix is still pending merge, but you can access it already here.
Good catch Rossko, Indeed this is the case with regular modbus tcp
Original reports were in fact modbus rtu over tcp where you would have crc also.
With regular modbus tcp, if we would have the tcp fragmentation, we can probably expect wrong data coming in, possibly other validation errors and such.