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

More extensibility #14

Open
freman opened this issue Jul 12, 2022 · 3 comments
Open

More extensibility #14

freman opened this issue Jul 12, 2022 · 3 comments

Comments

@freman
Copy link

freman commented Jul 12, 2022

Hi.

I have the pleasure of hacking away at some hardware that... doesn't quite get modbus right and I love the way your package works but It's not exactly extensible (ie: I need a slight variation of the tcp transport)

Before I put the effort into doing it, would you be opposed to receiving a patch that re-arranges the transports as packages?

eg: To get the tcp transport you would have the following imports

import (
    "github.com/simonvetter/modbus"
    _ "github.com/simonvetter/modbus/transport/tcp"
)

Would mean I could then come along and add what I need without committing fringe code to your repository (or forking it entirely)

import (
    "github.com/simonvetter/modbus"
    _ "github.com/freman/device/transport/brokentcp"
)

I would of course have it load all your existing transports to maintain backwards compatibility

@simonvetter
Copy link
Owner

Hi freman,

first off, thanks for chiming in!
While moving transports into subpackages would be great, there's a lot of inter-dependency right now in the code (e.g. the RTU transport needs the function code list as modbus RTU doesn't have proper framing, encoder.go is used everywhere, etc.), and I'm wary of the added complexity to support the odd broken/noncompliant implementation out there.

Out of curiosity, what device are you trying to use? What changes to the TCP transport would you need to make it work?

@freman
Copy link
Author

freman commented Jul 12, 2022

I'd be happy to sort out any of the dependencies, perhaps I was thinking too big, just a way to pass a transport might be enough?

I'm working with sungrow inverters which depending on which combination of adapter, adapter firmware, inverter and inverter firmware you have is broken in a different way

Current revision 12 of the winet-s firmware returns exceptions with the length set to 2 instead of 3
The previous dongle uses an aes encrypted modbus
There's a websocket version of modbus
There's a http get/post version of modbus

@simonvetter
Copy link
Owner

Oh, I see. I like the idea of being able to pass a transport when creating a client, i'll whip something up ASAP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants