-
Notifications
You must be signed in to change notification settings - Fork 35
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
Scan batching and modbus start address #55
Comments
That's a real doozie. Another creative implementation of the modbus protocol. See if you can set the address_offset setting to 1 such that the two-register scan sweeps both registers in one read command. |
Thank you for your answer. |
I rewrote the algorithm a bit to not read out of bounds registers. Also I think the former implementation could have missed the last word of a 32-bit register if it was at the _scan_batching border. EDIT: removed the code, created PR #64 instead |
…ers abort the transfer Should fix tjhowse#55 and tjhowse#28
Hi,
I got the following issue with my solar inverter:
scan batching causes the first modbus read address to start at a boundary that is a multiple of scan batching value.
I have a SMA tripower solar inverter that is somewhat picky on the modbus side: It has 32 bit modbus registers that need to be read within one single modbus command, so I have to set scan_batching=2. However the starting address some registers is an odd value (e.g. 30843 for battery current). So if I set scan_batching = 2 or 4, the script always changes the starting address to an even value (e.g.. 30842). Because this register does not exist, the solar inverter aborts the read command. scan_batching=1 does also not work because the 32 bits must be read within one command.
Workaround is to change line 128 of modbus_read.py in order not to allow to reduce the starting address:
group = int(k) # - int(k) % self._scan_batching
I did not understand the reason why the starting address is reduced to a boundary of scan_batching multiples. Is this somewhere required in the modbus spec or is there another reason to do this?
The text was updated successfully, but these errors were encountered: