-
-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Ethernet Logger LSE-3 #21
Comments
Hi @oetiker! I can try to implement suggested changes but as I don't have the device it will be like shooting in the dark. Are you willing to try it afterwards and help solve potential bugs and so? Have fun! |
Hi David yes sure, I would be totally willing to test and help out :) cheers |
Ok, I'll let you know whenever there is anything to try out. But as the code of those suggested changes is apart from the pysolarmanv5 it won't be as straight forward implementation as I initially thought so I can't make promises it will work as great as when it goes through the mentioned python library. But I'll do what I can to make it work. 😉 Have fun! |
Does the Ethernet Stick Logger also responds to the discovery packet? Probably not, right? |
I have both sticks. The Ethernet Adapter also response to the discovery packet. |
Here is a log: |
Indeed it seems so. I currently use an integration based on pure modbus protocol, but I'm testing your integration and the config flow correctly presents the logger IP address, port and also serial number. |
Okay, thanks guys. I'm currently investigating possible approaches to the implementation. |
Guys, can anyone test feat: Experimental testing of ethernet stick and show me the debug log? Thanks! For enabling this there is a new configuration toggle (Solarman protocol passthrough mode) which must be in on position. |
@davidrapan, It is not lack of interest, I'm currently not at home. I will be able to test it when I will come back! Thank you for spending time on this issue. |
And then for anyone who is going to try it there is this row in the api.py file (on line 34):
Try to tweak number 10. It says how much it should cut from the response from the start and treat the rest as an modbus frame. So try for example maybe also 20 and 2... But it really depends on what the code is gonna do. |
@davidrapan I will be glad to test, but I have not read the code to deeply and I am involved in way to many projects atm ...
|
Hi @oetiker,
You would have to manually download the code in zip and replace it in the HA as this changes are not part of any release.
Yes. |
You can also select master in version combo box in HACS. Download again if already installed. |
I know that you "can" do that but it won't switch to it. It reselects automatically to the release version and thus it never worked for me. And I think it was also stated that they gonna remove that feature all together though. |
It's now part of the 24.08.08 pre-release. |
I was hoping someone would at least give it a try before the planned 08/14/24 release, but I guess I'm out of luck, huh? 😆 |
@davidrapan I'm not at home! Will try as soon as I will be back for sure. |
@lcavalli, I know you said that! 😆 I did not mean to pressure anyone with that post! 😆 |
Hi @proggaras, this is what https://github.com/kellerza/sunsynk or modbus tcp is for, I guess. 😉 This integration specializes on using Solarman protocol only. |
@davidrapan yey, I finally got to test ... unfortunately it does not work yet,. but there is debug data. this is with the released version .17
|
Excellent! |
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. |
That's incredible! I wouldn't guess (even in my wildest dreams) that it will be such a smooth ride! 😆 |
Working well event at 10 seconds query cycle. |
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! |
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. |
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. |
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.
Awesome! I will remove that option from the configuration in the future if there won't be any issues. 😉
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) |
1 minute log: home-assistant_solarman_2024-08-21T19-51-39.277Z.log |
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? |
@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' |
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. |
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. 😉
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) 👋 |
refactor: Ethernet detection against frame length for "better" peace of mind @githubDante 😉 And really thanks for help! 🚀 |
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! |
It does not remove it, just makes it more strict to what is considered as frame from ethernet logger. 😉 |
@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? |
There are registered services which you can use in automations. |
See #90 |
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 |
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? |
Yes but you need to catch that disconnect, is it in there? |
yes |
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. |
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. |
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?
The text was updated successfully, but these errors were encountered: