-
Notifications
You must be signed in to change notification settings - Fork 10
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
More than 8 consecutive coil addresses results in the coils with index above 8 to not be detected/polled #37
Comments
Hi @Ruaktom! Thx for reaching out. I haven't been looking into this repo for quite some time, so apologies for the late reply. I was just reading into my own source again. Normally, the length of the Upon closer inspection however I did notice that the modbus client I am using is returning the data as https://github.com/goburrow/modbus/blob/606c02f4eef527a1d4cf7d8733d5fd7ba34f91d8/client.go#L41 Hence, the mapping back I did in the This should probably fix it:
I'll see if I can create test to reproduce the issue plus look into a patch release. |
When trying to do updates for coils in using the `CoilGroup.Update`, it was assumed that the results from the modbus client were returned as an array of `uint16`. However, they are in fact arrays of `byte`, so the conversion scheme that was part of `CoilGroup.Update` was NOK and thus was wrong in case of setups with more of 8 consecutive coils (including my own).
When trying to do updates for coils in using the `CoilGroup.Update`, it was assumed that the results from the modbus client were returned as an array of `uint16`. However, they are in fact arrays of `byte`, so the conversion scheme that was part of `CoilGroup.Update` was NOK and thus was wrong in case of setups with more of 8 consecutive coils (including my own).
When trying to do updates for coils in using the `CoilGroup.Update`, it was assumed that the results from the modbus client were returned as an array of `uint16`. However, they are in fact arrays of `byte`, so the conversion scheme that was part of `CoilGroup.Update` was NOK and thus was wrong in case of setups with more of 8 consecutive coils (including my own).
When trying to do updates for coils in using the `CoilGroup.Update`, it was assumed that the results from the modbus client were returned as an array of `uint16`. However, they are in fact arrays of `byte`, so the conversion scheme that was part of `CoilGroup.Update` was NOK and thus was wrong in case of setups with more of 8 consecutive coils (including my own). Spoof a new commit
When trying to do updates for coils in using the `CoilGroup.Update`, it was assumed that the results from the modbus client were returned as an array of `uint16`. However, they are in fact arrays of `byte`, so the conversion scheme that was part of `CoilGroup.Update` was NOK and thus was wrong in case of setups with more of 8 consecutive coils (including my own).
When I have more than 8 consecutive coil addresses in the confi.yml file, this results in groups being created with more than 8 coils.
The coils with index number above 8 are no longer triggered.
Issue can be solved by introducing an additional condition in the GroupCoils function (coilgroup.go) that creates a new group if size of group would exceed 8.
Maybe something to be implemented?
The text was updated successfully, but these errors were encountered: