Open freman opened 2 years ago
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?
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
Oh, I see. I like the idea of being able to pass a transport when creating a client, i'll whip something up ASAP.
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
Would mean I could then come along and add what I need without committing fringe code to your repository (or forking it entirely)
I would of course have it load all your existing transports to maintain backwards compatibility