[BUG] [Solis] Sensors producing garbage - integration has to be restarted #340
Comments
|
Another issue from this morning is the same scenario. I got it back to normal after reloading the integration. Logs attached |
|
If you reduce block_size to say 40, does that improve the situation? |
I made a change, so it will take some time to confirm its working correctly - I also attached the logs in relation to the following warning towards the end of the log file |
|
@wills106 is there any limitation in reducing the block size to 40? I cross-checked with other plugins and Solax has 100. Also, I looked into the documentation and the max recommended seems to be the same (100 bytes).
https://www.photovoltaikforum.com/core/attachment/202315-modbus-solis-rhi-5k-pdf/ So far, limiting to 40 is working ok with no issues, but I will need another week to feel more comfortable with it. |
|
Each normal register is two bytes (Normal registers are 16bit) SolaX for example could be set higher than 100 registers as Modbus TCP can support 123 Registers and Modbus RTU 125 The only limitation by reducing the block size is the speed you can poll at. I don't know exactly when you would reach the limitation, but I don't recommend going below 5s on any Inverter. |
|
So, it has been a while since reducing the block_size to 40, and it is working stable. I am still on So now, it's either a combination of both or the pyModbus |
It won't be that pyModbus is unable to handle blocks larger than 40 registers (80 bytes) It will be either the Inverter is struggling to provide so many registers or on occasion is returning garbage and pyModbus doesn't know what to do with it / #346 is another way to deal with it if 40 blocks doesn't help.
I can do that yes. |
|
@wills106 Thanks for the clarity - I appreciate your time on this project, especially when you have no access to equipment. |
|
Yes:
|
|
@wills106 I just had the below this morning Unable to download a full log at the moment |
|
This time it produced some weird things - 8% battery. On previous occasions, it was 0%.
Still, Producing garbage for other sensors.
|
|
So far it worked best with |
|
@wills106 I am currently on |
|
2023.02.7b4 didn't upload correctly. There were meant to be more changes. |
|
With block_size = 40 could you confirm you have the same block configuration as #341 (comment) |
|
Those weird errors received regularly. I got the It looks similar when restarted this afternoon, but no further errors as of yet : Please see a full log here |
|
Is
Your new timed registers? Which you added here alienatedsec/homeassistant-solax-modbus@main...solis_timeslots |
yes |
|
I'll work on adding them in and making sure |
|
I have just released 2023.03.2b5 with the new time blocks and the missing |
|
@wills106 I am currently on 2023.03.2b7 since its was released. I can see no 'garbage', but the following in the logs. Those are since I restarted yesterday. Even the |
|
Seems to be stable since 2023.03.2b7 Thanks for now. I hope you can progress with those two discussions at some point and I can contribute to #365 if needed: |
|
Do you want to see if you can clone the Wiki and update it? |
|
@wills106 I can have a go |
|
@wills106 I hope that works for you |
|
That seems good. |
|
Unfortunately not - edit your page and paste the below |
|
Just updated thanks. Seems odd how you can clone a Wiki but not push back. |
|
You can clone, but not |
|
@wills106 Unfortunately, this issue came back with the latest
|
|
I don't think b16 would have reintroduced this error. I think the register is unreliable. I have released 2023.03.2b17 I have added |
|
Is your "Battery SOC" behaving now? |
|
@wills106 it looks normal since the b17 release, but the SOC is not my concern, but all other sensors producing extreme numbers and messing with the graphs at the same time until the integration is restarted. I only inserted SOC to present timelines and when it started. If this will happen again, we could reopen the issue with further information. |
|
It didn't take long before the next problem occurred. This time, I had an automation to restart SolaX integration automatically when the battery SOC is at 8% or 0% - in theory, that should never happen. See the logs, but those are not showing anything useful to me on this occasion.
So when the battery SOC drops to this weird (garbage) value, it also gives other (garbage) values, and I would not point at the unreliable register, which I believe is the same issue since my very first post in this thread.
That gives some false figures used for the energy dashboard - look at the slot 15:00 - 16:00 when the issue happened.
If you look at the previous logs I uploaded in the past, there is more indication of which sensors produce garbage until the integration is restarted. |
|
@wills106 previous examples below |
|
It has been several days since it occurred last - I guess, I will close this issue and it will happen again :) Some latest logs below |
|
I have now two waveshares at different baud rates TCP Server at 19200 and the inverter the same Works fine (so far). The cloud is reporting as normal and the integration is polling data. The inverter is not supporting anything higher than 38400. Originally posted by @alienatedsec in #401 (comment) |
alienatedsec
changed the title
|
Another option could be to adapt Infradom's https://github.com/infradom/ha-addon-modbusspy instead of having so many Waveshares. I don't have anything to attach a Waveshare to so I can't test to see if having multiple connected in your setup are causing any issues or not. It's also potentially a lot cheaper to have a couple of USB-RS485 adaptors connected running ModbusSpy compared to the multiple Waveshare setup. |
|
@wills106 this sounds great and thanks for some alternatives; however, there are several obstacles I could think about:
I still think that those false readings are due to Waveshare losing the connection with the inverter.
Two ways to address it:
I am not a programmer and many things are still on my ToDo list :), but having some exposure in the industry and ChatGPT, gives an idea of how to handle such reading issues. The below was created based on my assumptions and some can be amended accordingly. I could have attempted to include it in the code, but I have no time to digest all things that I am missing at the moment (knowledge). Even as an example, it refers to many things that would not be relevant (setting the Modbus TCP IP) or even incorrect (32000 is not a holding register), but I am sure it could give a clue about how to handle unexpected readings. There is another problem which could prevent the below effort from being successful. There is no easy way from HA to register that unexpected reading unless it is verified as unexpected - again something that I would need to expand my knowledge on this. |
|
I had another problem overnight.
The pattern is that it drops the battery to While I agree with @wills106 that Solis is not the most reliable regarding comms on RS485, I think we should mitigate it somehow with the integration. Now, I see that the integration is registering data despite it having reading errors. @infradom do you have any ideas on how to prevent the integration from registering any data when read errors occur? If I don't reload the integration it keeps registering data for sensors despite not getting it from the inverter, and the below errors are generated. In my earlier posts and logs, you can find some randomly generated data for many sensors if the integration is not reloaded. After the above last log, the battery registers Everything is back to normal until the next issue occurs. I can do testing with some experimental code if that is required. |
|
It turns out the problem can be resolved another way. Thanks for the support @wills106 @infradom |
|
Thanks @alienatedsec , I have added a link to your page in our wiki |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The integration seems to crash occasionally and produces some garbage for the sensors until reloaded.
Mandatory details
2023.02.7b3and it happened with earlier versions too2023.2.5RHI-6K-48ES-5G
solis603105Waveshare RS485 to ETH (B) PoEversion. I described it here in more detailDetailed Error Log
From around 08:35 this morning until I restarted the integration at around 09:10, the sensor reported incredible battery usage (around 500kWh) and it affects the energy dashboard. It also reports 0 for other sensors - seems like the integration is not reading data from the gateway.
That wasn't the first time, and it happens occasionally with no real trigger. Firstly, I thought it was the problem with my unusual setup or even the gateway crashing and producing those results. However, noticed that when the integration is restarted, it gets back to normal. Also, my datalogger relies on the gateway, and it produced correct figures for other integration and the cloud between 08:35 - 09:10. It is worth noting that if the integration is to poll data
lessoften (every 15 instead of 5 seconds) it crashesmoreoften. It hasn't crashed on me for the last 4 days since I changed it to poll data every 5 seconds.I attach the log files for the period it occurred.
Problem.txt
The text was updated successfully, but these errors were encountered: