Skip to content
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

Modbus rework #9141

Merged
merged 35 commits into from
May 27, 2021
Merged

Modbus rework #9141

merged 35 commits into from
May 27, 2021

Conversation

srebhan
Copy link
Member

@srebhan srebhan commented Apr 16, 2021

Required for all PRs:

  • Updated associated README.md.
  • Wrote appropriate unit tests.

Restructuring and cleaning the modbus input plugin. This is preparation work to incorporate features from PR #7941 and #8013 as well as various feature-requests around modbus into the current plugin's code-base.
As a side effect the structure of the plugin as well as unit-tests are simplified and IMO easier to follow. The used modbus-library is migrated from the unmaintained goburrow version to the grid-x fork. Additionally, all existing linter-issues are nuked by this PR.

Copy link
Contributor

@telegraf-tiger telegraf-tiger bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤝 ✅ CLA has been signed. Thank you!

Copy link
Contributor

@telegraf-tiger telegraf-tiger bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@ssoroka ssoroka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

left some comments. These are some pretty massive changes. Would be good to get someone with a larger modbus installation to test out this build before we merge it.

plugins/inputs/modbus/modbus_test.go Show resolved Hide resolved
plugins/inputs/modbus/modbus.go Show resolved Hide resolved
plugins/inputs/modbus/modbus.go Show resolved Hide resolved
plugins/inputs/modbus/modbus.go Show resolved Hide resolved
plugins/inputs/modbus/modbus.go Show resolved Hide resolved
@srebhan
Copy link
Member Author

srebhan commented Apr 21, 2021

@ssoroka I fully agree that it should see some testing. I will give it a first test-run next week with about 20 devices, but would be happy if we get some more coverage with different devices...

Copy link
Contributor

@telegraf-tiger telegraf-tiger bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@telegraf-tiger telegraf-tiger bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@srebhan
Copy link
Member Author

srebhan commented May 3, 2021

Added some debugging output to show the raw-values on debug to verify type-conversions. Furthermore, extend the README with a trouble-shooting section. Thanks @binueda for his review of the Trouble-shooting section on slack. :-)

@srebhan srebhan added area/modbus feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin labels May 11, 2021
@srebhan
Copy link
Member Author

srebhan commented May 11, 2021

!retry-failed

@srebhan
Copy link
Member Author

srebhan commented May 11, 2021

Worked out the serial issue (already present in 1.18) in the spin-off PR. Tested by @binueda there (#9256) and working fine with this PR as base.

@ssoroka ssoroka added the waiting for response waiting for response from contributor label May 13, 2021
Sven Rebhan added 12 commits May 18, 2021 12:21
…done to avoid extensive logs during standard debug. Please note, you need to enable both, 'trace_connection=true' as well as debug mode to see the messages.
…d force it to 'true' for serial connections." to not clutter this PR. Will add another PR instead.

This reverts commit 07487f6.
…This is done to avoid extensive logs during standard debug. Please note, you need to enable both, 'trace_connection=true' as well as debug mode to see the messages." to not clutter this PR. Will add another PR instead.

This reverts commit 3d235f1.
@srebhan
Copy link
Member Author

srebhan commented May 18, 2021

!retry-failed

@ssoroka ssoroka mentioned this pull request May 18, 2021
3 tasks
Copy link
Contributor

@ssoroka ssoroka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

approved; waiting for user testing

@wz2b
Copy link

wz2b commented May 19, 2021

If the intent here is to eliminate 8013 and merge in its features there are a few things it needs to be able to do:

  • Specify a unit address per-request, rather than once for the entire driver instance
  • Allow you to 'skip' registers that come back as in a "read multiple" (holding, input, or discrete) request that you don't care about i.e. they shouldn't end up as fields, but you also shouldn't be forced to make them individual requests
  • Per the modbus organization's statement we really should replace the word "slave" with the word "unit" (continuing to silently support "slave_id" is not a problem)

In particularly, the "gateway" functionality provided by #8013 is needed, and I don't think it's addressed here. The issue is allowing you to talk to multiple devices attached to a single gateway without having to have separate TCP connections for each unit. This is a common scenario that occurs even when talking to devices that are not traditionally "gateways." As an example, one of the more popular solar inverters out there is the SMA SB series (e.g. SB3000). It has multiple register sets located inside it, and there are occasions where you want to be able to use both at the same time. To select one vs the other you use a different unit address. Essentially, this inverter acts as two "devices" in one. The other common scenario is strings of power meters e.g. the Square D smart breakers where each breaker is its own device (with its own unit address).

If this PR addresses the above then it's fine; if it's not, then I don't think this replaces or merges 8013. If I'm wrong please let's discuss.

@srebhan
Copy link
Member Author

srebhan commented May 20, 2021

@wz2b as discussed on Slack, this is only a first stage. I hope submitted #9279 clarifies things. Thanks for offering your testing of #9279 on slack. Looking forward to your comments!

@mirkocomparetti-synesis

I run some tests in the following condition:

coils = [
    { name = "D1", measurement="somemeasure", address = [260]},
    { name = "D2", measurement="somemeasure", address = [262]},
  ]
  holding_registers = [
    { name = "A", measurement="somemeasure", byte_order = "ABCD", data_type = "FLOAT32-IEEE", scale=1.0, address = [1, 2]},
    { name = "B", measurement="somemeasure", byte_order = "AB", data_type = "FIXED", scale=1.0, address = [3]},
    { name = "C", measurement="somemeasure", byte_order = "AB", data_type = "FIXED", scale=0.1, address = [4]},
    { name = "D", measurement="somemeasure", byte_order = "AB", data_type = "FIXED", scale=0.001, address = [5]},
  ]

and the results are ok for me.

Data types are good; I would maybe consider to save booleans for the coils and discrete_inputs as those are boolean by definition in the standard, instead of integers.

@srebhan
Copy link
Member Author

srebhan commented May 20, 2021

@mirkocomparetti-synesis thanks for testing!
Looking at the code it might be possible to add this feature (bitwise registers as BOOL) by parsing the datatype field. If this is ok with you, I will postpone adding it to a later point in time. Please add an issue so I won't forget. Thanks in advance!

@srebhan
Copy link
Member Author

srebhan commented May 20, 2021

@ssoroka testing was successful. :-)

@mirkocomparetti-synesis

Agreed @srebhan it can be postponed! Here it is the ticket #9284 for your reference.

@srebhan srebhan removed the waiting for response waiting for response from contributor label May 27, 2021
@ssoroka ssoroka merged commit 2e7b232 into influxdata:master May 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/modbus feat Improvement on an existing feature such as adding a new setting/mode to an existing plugin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants