edgexfoundry / edgexfoundry/device-modbus-go
(Modbus TCP)device-modbus-go using multi connections, but real devices support one connection only.
- Dominant language
- Go
- Stars
- 120
- Forks
- 105
- PR merge metrics
- No merged PRs in 30d
Description
# 🐞 Bug Report
### Affected Services [**REQUIRED**]
The issue is located in:
[device-modbus-go](Modbus TCP)
### Is this a regression?
No, all versions have the same issue.
### Description and Minimal Reproduction [**REQUIRED**]
Device-modbus-go connects modbus during HandleReadCommands、HandleWriteCommands in driver.go, This will client muti DeviceClient instances.
So that the "connect()" function in tcpclient.go(github.com/goburrow/modbus) be invoked multi times before the previours connection closed.
It is ok for some of the devices which have ability of muti tcp connections, but lot of others only support one tcp connection. that will get error showing in Exception section.
Hope this can be solved. At least to give one setting to config to use one tcp connection or muti tcp connections. May be it has the functionality already, but I don't know?
## 🔥 Exception or Error
code: 500 , message: request failed, status code: 500, err: {"apiVersion":"v2","message":"error reading DeviceResourece TemperatureTop for TCP-Temperature-Humidity -\u003e dial tcp 192.168.1.17:502: connect: connection refused","statusCode":500}
## 🌍 Your Environment
**Deployment Environment:**
raspiberry pi 4
**EdgeX Version [**REQUIRED**]:**
all versions
**Anything else relevant?**
Contributor guide
Research direction
Start in driver.go at HandleReadCommands and HandleWriteCommands, then inspect how tcpclient.go invokes connect() through the Modbus client. Determine how connection reuse versus multiple connections should be configured and verify the chosen behavior against a device that permits only one TCP connection. Done means the reported connection-refused failure is avoided without breaking supported multi-connection devices.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100