Support for Ethernet Logger LSE-3

[oetiker]

I am using a Sofar Hybrid Box (SOFAR HYD 20KTL-3PH) with a LSE-3 logger and get no responses when trying to use the thing with the ha-solarman code. Neither with the code here nor with the original from StephanJoubert.

Reading through @StephanJouberts repo I found this issue which seems to indicate that the LSE-3 device needs different encapsulation ...

Anyone working on this ? Or is there some secret to get my setup to communicate with ha-solarman which I just neglected until now?

[lcavalli]

Not working... Integration cannot even start.

2024-08-21 18:01:06.719 DEBUG (MainThread) [custom_components.solarman.api] [xxx] Querying (1028 - 1067 | 0x0404 - 0x042B # 040) failed. [TimeoutError]
2024-08-21 18:01:06.920 DEBUG (MainThread) [custom_components.solarman.api] [xxx] Querying (1028 - 1067 | 0x0404 - 0x042B # 040) attempts left: 4
2024-08-21 18:01:06.923 DEBUG (MainThread) [custom_components.solarman.api] [xxx] Successful reconnect
2024-08-21 18:01:06.924 DEBUG (MainThread) [custom_components.solarman.api] [xxx] SENT: e7 5a 00 00 00 06 01 03 04 04 00 28
2024-08-21 18:01:08.982 DEBUG (MainThread) [custom_components.solarman.api] [xxx] V5_MISMATCH: e7 5a 00 00 00 53 01 03 50 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 37 00 00 00 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 6f 00 04 bc 27 00 08 78 b8 01 d1
2024-08-21 18:01:17.714 DEBUG (MainThread) [custom_components.solarman.api] [xxx] Request failed. [Previous State: Disconnected (-1)]
2024-08-21 18:01:17.715 INFO (MainThread) [custom_components.solarman.api] [xxx] Disconnecting from 192.168.1.178:8899
2024-08-21 18:01:17.717 DEBUG (MainThread) [custom_components.solarman.coordinator] async_shutdown
2024-08-21 18:01:17.717 INFO (MainThread) [custom_components.solarman.api] [xxx] Disconnecting from 192.168.1.178:8899
2024-08-21 18:01:23.015 DEBUG (MainThread) [custom_components.solarman] async_setup_entry({'created_at': '2024-08-21T13:27:04.824613+00:00', 'data': {'name': 'ZCS', 'inverter_discovery': True, 'inverter_host': '192.168.xxx.xxx', 'inverter_serial': xxxxxxxxxx, 'inverter_port': 8899, 'inverter_mb_slave_id': 1, 'inverter_passthrough': True, 'lookup_file': 'zcs_azzurro-hyd-zss-hp.yaml', 'battery_nominal_voltage': 48, 'battery_life_cycle_rating': 6000}, 'disabled_by': None, 'domain': 'solarman', 'entry_id': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 'minor_version': 1, 'modified_at': '2024-08-21T13:27:04.824617+00:00', 'options': {'name': 'ZCS', 'inverter_discovery': True, 'inverter_host': '192.168.xxx.xxx', 'inverter_serial': xxxxxxxxxxx, 'inverter_port': 8899, 'inverter_mb_slave_id': 1, 'inverter_passthrough': True, 'lookup_file': 'zcs_azzurro-hyd-zss-hp.yaml', 'battery_nominal_voltage': 48, 'battery_life_cycle_rating': 6000}, 'pref_disable_new_entities': False, 'pref_disable_polling': False, 'source': 'user', 'title': 'ZCS', 'unique_id': None, 'version': 1})
2024-08-21 18:01:23.016 DEBUG (MainThread) [custom_components.solarman.discovery] discover
2024-08-21 18:01:23.017 DEBUG (MainThread) [custom_components.solarman.discovery] _discover: [192.168.xxx.xxx, xxxxxxxxxxxxxxxxxx, xxxxxxxxxxxxx]
2024-08-21 18:01:24.090 DEBUG (MainThread) [custom_components.solarman.parser] Defaults for update_interval: 20, code: 3, min_span: 25, digits: 6
2024-08-21 18:01:24.090 DEBUG (MainThread) [custom_components.solarman.api] {'connections': {('mac', '34:ea:e7:f6:55:6b')}, 'identifiers': {('solarman', xxxxx)}, 'name': 'ZCS', 'manufacturer': 'Zcs', 'model': 'AZZURRO-HYD-ZSS-HP', 'serial_number': xxxxxxxxxxx}
2024-08-21 18:01:24.090 DEBUG (MainThread) [custom_components.solarman] async_setup: coordinator.async_config_entry_first_refresh
2024-08-21 18:01:24.090 DEBUG (MainThread) [custom_components.solarman.api] [xxx] Scheduling 7 query requests. #0
2024-08-21 18:01:24.091 DEBUG (MainThread) [custom_components.solarman.api] [xxx] Querying (1028 - 1067 | 0x0404 - 0x042B # 040) ...
2024-08-21 18:01:24.091 INFO (MainThread) [custom_components.solarman.api] [xxx] Connecting to 192.168.1.178:8899
2024-08-21 18:01:24.092 DEBUG (MainThread) [custom_components.solarman.api] [xxx] SENT: ee 51 00 00 00 06 01 03 04 04 00 28
2024-08-21 18:01:24.418 DEBUG (MainThread) [custom_components.solarman.api] [xxx] V5_MISMATCH: ee 51 00 00 00 53 01 03 50 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 37 00 00 00 36 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 6f 00 04 bc 27 00 08 78 b8 01 d1

[davidrapan]

Of course I forgot something:

    def _received_frame_is_valid(self, frame):
        if not self._passthrough:
            return super()._received_frame_is_valid(frame)
        return True

Can you add this method to the PySolarmanV5AsyncWrapper class?

Or do you want me to give you whole file again? (In case you are not familiar with the python that much)

[lcavalli]

No worries, can do by myself...

[lcavalli]

It is working now. Lets see the disconnection issue..

[davidrapan]

Great. A also try to look trough profile you are using to setup appropriate update_intervals so it does not requests everything every scheduled time. 😉

[lcavalli]

Running for more than 15 minutes without disconnections!

[davidrapan]

Excellent!

[lcavalli]

Logs dumped, everything is working without communication errors anymore. Seems stable so far. I will try to revert back to original 10 seconds query cycle.

[davidrapan]

That's incredible! I wouldn't guess (even in my wildest dreams) that it will be such a smooth ride! 😆

[lcavalli]

Working well event at 10 seconds query cycle.

[davidrapan]

I also added: feat: Ethernet Stick Logger autodetection

It's in main now: https://github.com/davidrapan/ha-solarman/blob/main/custom_components/solarman/api.py

So can you try if it actually works by toggling off that checkbox for "passthrough" in configuration?

Edit: There was a typo but I fixed it!

[davidrapan]

And I also set correctly update_intervals for your profile: refactor: HYD 3000~6000 profile update_intervals

So not all registers are requested every single time.

[davidrapan]

v24.08.21

[lcavalli]

v24.08.21 seems to work well (without flagging the pass through option). The only issue now is that the sensor.zcs_update_interval is now around 6, not 10 as before.

[davidrapan]

Can you enable debug and then reload integration and let it run for around 1 minute? I would just like to check the flow and update_intervals.

without flagging the pass through option

Awesome! I will remove that option from the configuration in the future if there won't be any issues. 😉

The only issue now is that the sensor.zcs_update_interval is now around 6, not 10 as before.

Yes that's the standard. Sensors like power, voltage and current are requested with interval of 5 s. The Total sensors are requested with interval of 30 s. Static values like Serial Numbers with interval of 5m. (But your profile has no static value sensors)

[lcavalli]

1 minute log: home-assistant_solarman_2024-08-21T19-51-39.277Z.log

[davidrapan]

V5_ETHERNET_DETECTED and switching the mode! That's what I wanted to see! Awesome! 🎉

This is going to be OT but what are Load Power, Output Active Power, Load Active Power and Temperature sensors showing you? 🤔 In respect to "for you known" values?

[githubDante]

@davidrapan Is it possible the logger type WiFi/Ethernet to be configured through the HA interface by the user ? I'm asking because this type of detection doesn't seem quite right. Yes, the logger understands the V5 request somehow, but then it sends the response in TCP MODBUS mode by reusing the V5 Protocol header as Transaction Identifier with all other V5 attributes stripped.

Looking at logs the response is quite verbose actually and if you decide to use auto-detection you can also use this:

>>> frame = bytes.fromhex('a5 17 00 10 45 53 01 03 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 1a 00 04 bc d2 00 08 79 9d 01 fa')
# This frame is from the last log provided by @lcavalli - frame timestamp: 2024-08-21 21:50:13.156
>>> int.from_bytes(frame[5:6], byteorder='little') == len(frame[6:])
True
>>> int.from_bytes(frame[8:9], byteorder='little') == len(frame[9:])
True
>>> 

Edit: the byteorder doesn't matter, the result will be the same with 'big'

[lcavalli]

V5_ETHERNET_DETECTED and switching the mode! That's what I wanted to see! Awesome! 🎉

This is going to be OT but what are Load Power, Output Active Power, Load Active Power and Temperature sensors showing you? 🤔 In respect to "for you known" values?

Right now load power 390 W, output active power 0 W, load active power 0 W and temperature 47° C. All values seem correct wrt official app.

[davidrapan]

Hey @githubDante! Yeah I noticed that it is just reflecting back the header that's why I decided to try it (check against the reflected control code) when I had to also override the method for checking the validity of the V5 frame anyway (cause otherwise it would end up with the SEQ MISMATCH).

Checking the length also came across my mind cause I remembered we did something similar with the double crc.

I just wanted to test the idea and gather some feedback cause I really was not sure if it will work across more devices.

For now it is toggleable in the configuration. 😉

Right now load power 390 W, output active power 0 W, load active power 0 W and temperature 47° C. All values seem correct wrt official app.

I was hoping that some of them are maybe redundant. 😆 Cause it has ridiculously scattered registers all over the place and it's impossible to get it under 6 requests. 😆 Let me know if you find there any redundancy in the sensors available cause it just seems strange to me, but nvm.

Yeah and what about the "names", it is correct? (for example load active power vs load power, lol)

👋

[davidrapan]

refactor: Ethernet detection against frame length for "better" peace of mind @githubDante 😉 And really thanks for help! 🚀

[lcavalli]

It is working stable since a couple of days now. I still have to import your last commit that removes the auto detection of ethernet data loggers, will do when the official release will be published. IMHO this issue can be closed 🙂. Thank you @davidrapan and all!

[davidrapan]

It does not remove it, just makes it more strict to what is considered as frame from ethernet logger. 😉

[Bolo92]

@davidrapan LSE-3 allows configuration changes using Modbus. I see write_holding_registers in the code, but I don't know enough Python to understand how to use it. Is there an example of how the code should look to write a value?

[davidrapan]

There are registered services which you can use in automations.

[gedger]

See https://github.com/davidrapan/ha-solarman/discussions/90

[MarkoSchweizer]

I use the Logger LSE 3 for this integration. It worked good for a few days. Two days ago the solarman smart app lost connection to my inverter, but the logger was still online, so I asked the sofar support for help. They updated the firmware of the Logger, but now the integration loses the connection after a few minutes.

Does the firmware updated cause the connection problems?

Edit: I changed the update-interval from 5 to 10s. It works stable without connection loose. Can the updated interval cause the connection problems?

Best regards Marko

[davidrapan]

They are doing some nasty stuff in new firmwares so I honestly have no idea, maybe the logs could reveal something?

[MarkoSchweizer]

They are doing some nasty stuff in new firmwares so I honestly have no idea, maybe the logs could reveal something?

home-assistant_solarman_2024-11-13T12-16-43.792Z.log

Is this the log you need?

[davidrapan]

Yes but you need to catch that disconnect, is it in there?

[MarkoSchweizer]

Yes but you need to catch that disconnect, is it in there?

yes

[davidrapan]

It sends a request and then it hangs for 20 seconds. After 20 seconds it timeouts in pysolarmanv5. it repeats the request hangs again and ends on 30 second (configured hard limit).

So yeah the stick just does not talk.,, Could be maybe interesting to see the traffic from the stick. But you need some setup for that so not that easy to do though. Maybe it just do interfere with communication with the servers... But this is so hostile protocol! And it's getting worse. 😆

Edit: BTW, my lsw stick also has this 20 seconds hangs! Quite often I'd say... but every other request try is always successful.

[MarkoSchweizer]

It sends a request and then it hangs for 20 seconds. After 20 seconds it timeouts in pysolarmanv5. it repeats the request hangs again and ends on 30 second (configured hard limit).

So yeah the stick just does not talk.,, Could be maybe interesting to see the traffic from the stick. But you need some setup for that so not that easy to do though. Maybe it just do interfere with communication with the servers... But this is so hostile protocol! And it's getting worse. 😆

Edit: BTW, my lsw stick also has this 20 seconds hangs! Quite often I'd say... but every other request try is always successful.

Okay, so I better ask the support to change the previous firmware version? Thanks for your help so far.

[davidrapan]

I don't think local communication it's that important for them but I guess they should do downgrade if customer asks.

And is really up to you which communication is more valuable and important to you and you want to work the best.