azure / iot-edge-modbus Goto Github PK

View Code? Open in Web Editor NEW

90.0 27.0 69.0 783 KB

Modbus protocol module for use with the Azure IoT Edge

License: Other

CMake 1.93% C 25.96% C++ 41.54% C# 30.57%

iot-edge-modbus's People

Contributors

Stargazers

Watchers

Forkers

alex1818 aidajulia linearregression lc2a senthamizhgp iotblackbelt rhenangarcia berique truenorthit hvusyslogic idavis rachot skyformat99 sympthom sroddy76 agostinia wjffsx m-chau waltercoan gabrielpereirapinheiro terrymandin mysmart-dev jorgemaia gaecom 4nandp sasauz josephk9 zhaodong2013062 rjoshi torototonator chencao187 phaest benjguin suneetnangia noreway dolphinsimon spsims calledanell mikhail2k15 fredrikfrostad karahakan oliverchristen baekdavid iot-edge-foundation craigdv jonmikeli boopathiperumal isabella232 ilseokoh rboddipalli giofranco aaronxieyl thbetolar philipf krenal-yash hguomin lukemccarthy-versor jamesyun7 meetrilok eugen-meissner karthik904 whey-ten sourcecodecheck raphi007fly arkintea bigjiongeagle

iot-edge-modbus's Issues

Why isn't Modbus RTU available on Windows?

RTU is currently not available in Windows environment

Why is this? Are there blockers on the Windows side or is it a case of not implemented?

Runtime error

Hi,
I'm trying to run the module, but I get an error in my IoT Edge Dashboard.

The status of my modbus module is:

Runtime status: backoff
Exit code: 128

I am trying to use modbus RTU and I do not know if I configured "Container Create Option section" correctly:

{
  "HostConfig": {
    "Devices": [
      {
        "PathOnHost": "user",
        "PathInContainer": "user",
        "CgroupPermissions": "rwm"
      }
    ]
  }
}

Where can I look to try to solve this?

Error: Invalid TcpPort: , set to DefaultTcpPort: 502

Error: Invalid TcpPort: , set to DefaultTcpPort: 502. Even-though I am trying for RTU device.

I am trying to add my modbus RTU device and following the steps mentioned in README.md provided here.

So what is happening here, it shows a error and is stuck there no telemetry is coming and published to cloud.
Logs:

pi@raspberrypi:~ $ sudo iotedge logs -f modbus --tail=20
IoT Hub module client initialized.
Desired property change:
{"PublishInterval":"2000","Version":"2","SlaveConfigs":{"Slave01":{"SlaveConnection":"/dev/ttyACM0","HwId":"LGP5310","RetryCount":"10","RetryInterval":"50","BaudRate":"9600","DataBits":"8","StopBits":"1","Parity":"NONE","FlowControl":"NONE","Operations":{"Op01":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000156","Count":"2","DisplayName":"frequency_hz","CorrelationId":"MessageType1"},"Op02":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000126","Count":"2","DisplayName":"va_r_phase_v","CorrelationId":"MessageType1"},"Op03":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000128","Count":"2","DisplayName":"va_y_phase_v","CorrelationId":"MessageType1"},"Op04":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000130","Count":"2","DisplayName":"va_b_phase_v","CorrelationId":"MessageType1"},"Op05":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000150","Count":"2","DisplayName":"current_r_phase_amp","CorrelationId":"MessageType1"},"Op06":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000152","Count":"2","DisplayName":"current_y_phase_amp","CorrelationId":"MessageType1"},"Op07":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000154","Count":"2","DisplayName":"current_b_phase_amp","CorrelationId":"MessageType1"}}}},"$version":4}
Attempt to load configuration: {"PublishInterval":"2000","Version":"2","SlaveConfigs":{"Slave01":{"SlaveConnection":"/dev/ttyACM0","HwId":"LGP5310","RetryCount":"10","RetryInterval":"50","BaudRate":"9600","DataBits":"8","StopBits":"1","Parity":"NONE","FlowControl":"NONE","Operations":{"Op01":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000156","Count":"2","DisplayName":"frequency_hz","CorrelationId":"MessageType1"},"Op02":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000126","Count":"2","DisplayName":"va_r_phase_v","CorrelationId":"MessageType1"},"Op03":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000128","Count":"2","DisplayName":"va_y_phase_v","CorrelationId":"MessageType1"},"Op04":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000130","Count":"2","DisplayName":"va_b_phase_v","CorrelationId":"MessageType1"},"Op05":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000150","Count":"2","DisplayName":"current_r_phase_amp","CorrelationId":"MessageType1"},"Op06":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000152","Count":"2","DisplayName":"current_y_phase_amp","CorrelationId":"MessageType1"},"Op07":{"PollingInterval":"1000","UnitId":"1","StartAddress":"000154","Count":"2","DisplayName":"current_b_phase_amp","CorrelationId":"MessageType1"}}}},"$version":4}
Invalid TcpPort: , set to DefaultTcpPort: 502
Opening.../dev/ttyACM0
Saving reported properties: {"PublishInterval":2000,"SlaveConfigs":{"Slave01":{"Operations":{"Op01":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000156","Count":2,"DisplayName":"frequency_hz","CorrelationId":"MessageType1"},"Op02":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000126","Count":2,"DisplayName":"va_r_phase_v","CorrelationId":"MessageType1"},"Op03":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000128","Count":2,"DisplayName":"va_y_phase_v","CorrelationId":"MessageType1"},"Op04":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000130","Count":2,"DisplayName":"va_b_phase_v","CorrelationId":"MessageType1"},"Op05":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000150","Count":2,"DisplayName":"current_r_phase_amp","CorrelationId":"MessageType1"},"Op06":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000152","Count":2,"DisplayName":"current_y_phase_amp","CorrelationId":"MessageType1"},"Op07":{"PollingInterval":1000,"UnitId":1,"StartAddress":"000154","Count":2,"DisplayName":"current_b_phase_amp","CorrelationId":"MessageType1"}},"SlaveConnection":"/dev/ttyACM0","RetryCount":10,"RetryInterval":50,"TcpPort":502,"HwId":"LGP5310","BaudRate":9600,"StopBits":1,"DataBits":8,"Parity":0}}}

And no logs after that. Why it is showing "Invalid TcpPort: , set to DefaultTcpPort: 502". How to differentiate between RTU and TCP device? What am I doing wrong here?

[v2] failure in standalone mode

Is it possible to run this v2 module without iot-edge v2 runtime for debug purpose? I tried running as a normal dotnet application and it failed with below error message. I haven't installed any iot-edge v2 related applications (edgeHub, edgeAgent etc). For dotnet application, is standalone mode not supported?

Unhandled Exception: System.AggregateException: One or more errors occurred. (Environment variable IOTEDGE_WORKLOADURI is required.) ---> System.InvalidOperationException: Environment variable IOTEDGE_WORKLOADURI is required.
at Microsoft.Azure.Devices.Client.Edge.EdgeModuleClientFactory.CreateInternalClientFromEnvironmentAsync()
at Modbus.Containers.Program.InitEdgeModule() in /Users/xxxxxx/Desktop/sdaf/iot-edge-modbus-master/iotedgeModbus/modules/iotedgeModbus/Program.cs:line 69
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait()
at Modbus.Containers.Program.Main(String[] args) in /Users/xxxxxxx/Desktop/sdaf/iot-edge-modbus-master/iotedgeModbus/modules/iotedgeModbus/Program.cs:line 32
Abort trap: 6

[v1] failure on any single modbus operation, discards results of all successful operations

We can specify multiple operations as in modbus config[1]. Now if we have 3 operations specifying 3 different register reads, failure in a single read will result in no JSON output from other two successful read operations as well.

This was tested with ModbusPal[2].

Combine multiple operation results into one object holding an array of values

When multiple operations are executed, the results are sent as an array. But when consumed by Azure Stream Analytics, these seem to be split into separate actions.

Then, the relationship between the values is lost.

Please put the operations in an array, within a result class.

Unable to deploy on Windows 10 1803 with Windows containers

I have Docker running on Win 10 desktop 1803, configured with windows containers. Docker pull fails with the following:

docker pull mcr.microsoft.com/azureiotedge/modbus:1.0
1.0: Pulling from azureiotedge/modbus
no matching manifest for unknown in the manifest list entries

Iot edge is running successfully, and auto-deployed tempSensor without any issues.

NAME STATUS DESCRIPTION CONFIG
tempSensor running Up 9 minutes mcr.microsoft.com/azureiotedge-simulated-temperature-sensor:1.0
edgeHub running Up an hour mcr.microsoft.com/azureiotedge-hub:1.0
edgeAgent running Up an hour mcr.microsoft.com/azureiotedge-agent:1.0

Modbus server not receiving messages sent

Hi - I am currently using the Edge module preview to connect to a modbus server. It is reading the variables correctly. However, when I send a command from Azure to the module, it is not showing receipt of the message as a "received command".

If I build the code in debug mode (as per your instructions) in Visual Studio, that code shows receipt of the message and I can see the change on the modbus server.

There is obviously something wrong about the edge module? Perhaps you have updated the code recently but not the module?

Cheers,
Dave

After restart Docker (rebooted laptop) not all data is read anymore

I rebooted my laptop and had to restart Docker (does not start automatically).

This is what I see when I run the logging of the module:

40001: 4759
00002: 1
00001: 1
40002: 4757
40001: 4754
00001: 1
00002: 1
40002: 4743
Something wrong with the socket, disposing...
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
Something wrong with the socket, disposing...
Object reference not set to an instance of an object.
Something wrong with the socket, disposing...
Object reference not set to an instance of an object.
Something wrong with the socket, disposing...
Object reference not set to an instance of an object.
Connection lost, reconnecting...
00001: 1
00001: 1
00001: 1
00001: 1
00001: 1
00001: 1
00001: 1
etc.

Before the reboot, I received 4 values (as configured).
After the reboot, I only received 1 value.

Configuration is:

"desired": {
  "PublishInterval": "10000",
  "SlaveConfigs": {
    "Slave01": {
      "SlaveConnection": "192.168.1.142",
      "HwId": "Wise4012E-142",
      "Operations": {
        "Op01": {
          "PollingInterval": "10000",
          "UnitId": "1",
          "StartAddress": "40001",
          "Count": "1",
          "DisplayName": "KnobOne"
        },
        "Op02": {
          "PollingInterval": "10000",
          "UnitId": "1",
          "StartAddress": "40002",
          "Count": "1",
          "DisplayName": "KnobTwo"
        },
        "Op03": {
          "PollingInterval": "10000",
          "UnitId": "1",
          "StartAddress": "00001",
          "Count": "1",
          "DisplayName": "SwitchOne"
        },
        "Op04": {
          "PollingInterval": "10000",
          "UnitId": "1",
          "StartAddress": "00002",
          "Count": "1",
          "DisplayName": "SwitchTwo"
        }
      }
    }
  },

I expected that the module is tollerant against restarting the Docker environment.

Add synchronous message handling for RTU

When using the RTU variant, the async nature of the read operations make it difficult to manage when there are several read operations defined. The behavior I'm seeing is that the register values for one read operation are in the register locations for another read operation.

For example, if I have two read ops defined, one that reads 1-50 and one that read 51-100, I have observed that the VALUE for register 1 actually gets returned in register 51. I have anywhere from 8 - 12 read operations, each reading 50 registers, each with a pooling interval of 1500ms.

I believe that implementing synchronous communication should give more consistent results.

Socket issues for larger count values

In the modbus config, if you specify a "count" value larger than 251, socket issues start to show in the logs:

Here is a sample of what I see:
Something wrong with the socket, disposing...
Specified argument was out of the range of valid values.
Parameter name: size
Connection lost, reconnecting...

Values up to 251 are okay.

Request for varying read intervals across registers

There could be need to read different registers at different frequencies. With the current setup( of single "Interval" spanning all registers/slaves), lib user is forced set up configuration with least common denominator of all read frequencies( and then ignore data as appropriate ).

Module do not resume communication if fail

When standard modbus module fails sending in the send_request_tcp method it does not resume communication until i restart the Gateway. The error is "Send failed".

Docker module updates not getting deployed

Hi all,

currently i have deployed the modbus docker image on a linux(ubuntu) edge device. The docker image gets successfully deployed from the container registry created in azure portal. But if any changes are made to the docker image and pushed to the container registry it does'nt gets updated in the edge device. The device keeps running the old docker image. As per my understanding when a updated image is pushed it should get reflected in the edge device immediately.
Is there any configuration that need to be performed while building the modbus docker image for this?

Changing RTU StartAddress can result in ArgumentNullException

I have the following module configured for Modbus RTU and it is running as expected (receiving values):

uno2271gsv@uno2271gsv-UNO-2271G-E2xAE:~$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
aee3e18ee461 microsoft/azureiotedge-modbus-tcp:0.0.1-amd64 "dotnet iotedgeModbu…" 9 minutes ago Up 3 minutes

I have the following ModuleTwin:

"desired": {
 "PublishInterval": "10000",
 "SlaveConfigs": {
   "Slave01": {
     "SlaveConnection": "/dev/ttyS0",
     "BaudRate": "9600",
     "DataBits": "8",
     "StopBits": "1",
     "Parity": "NONE",
     "FlowControl": "NONE",
     "HwId": "Adam4168U1",
     "Operations": {
       "Op01": {
         "PollingInterval": "10000",
         "UnitId": "1",
         "StartAddress": "00017",
         "Count": "8",
         "DisplayName": "Relays"
       }
     }
   }
 },
 "$metadata": {

This is a part of the output:

00020: 0
00021: 0
00022: 0
00023: 0
00024: 0

I change "00017" into 17.

The module picks up the change and start reading...

Desired property change:
{"PublishInterval":"5000","SlaveConfigs":{"Slave01":{"SlaveConnection":"/dev/ttyS0","BaudRate":"9600","DataBits":"8","StopBits":"1","Parity":"NONE","FlowControl":"NONE","HwId":"Adam4168U1AA","Operations":{"Op01":{"PollingInterval":"5000","UnitId":"1","StartAddress":"17","Count":"8","DisplayName":"RelaysAA"}}}},"$version":21}
Attempt to load configuration: {"PublishInterval":"5000","SlaveConfigs":{"Slave01":{"SlaveConnection":"/dev/ttyS0","BaudRate":"9600","DataBits":"8","StopBits":"1","Parity":"NONE","FlowControl":"NONE","HwId":"Adam4168U1AA","Operations":{"Op01":{"PollingInterval":"5000","UnitId":"1","StartAddress":"17","Count":"8","DisplayName":"RelaysAA"}}}},"$version":21}
Invalid TcpPort: , set to DefaultTcpPort: 502
Invalid RetryCount: , set to DefaultRetryCount: 10
Invalid RetryInterval: , set to DefaultRetryInterval: 50
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
Opening.../dev/ttyS0

No data is received as expected. Let's change it back to "00017":

Error when receiving desired property: System.ArgumentNullException: Value cannot be null.
Parameter name: format
at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at Modbus.Slaves.ModbusSlaveSession.ProcessResponse(ModbusSlaveConfig config, ReadOperation x) in /app/ModbusSlave.cs:line 238
at Modbus.Slaves.ModbusSlaveSession.d__27.MoveNext() in /app/ModbusSlave.cs:line 197
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Modbus.Slaves.ModbusSlaveSession.<>c__DisplayClass20_0.<b__0>d.MoveNext() in /app/ModbusSlave.cs:line 163

Every time I change a value in the Module twin (even with a valid twin), the exception occurs.

Zo the module 'freezes' I can not change anymore (maybe by rejecting and deploying the complete module again?). Only a "docker kill rtu" restarts the module. And because the module twin is correct, it starts reading directly.

I also tried changing a sound "00017" into a sound "00018" and this works ok.

The issue seems to be that once this format exception occurs, the module can not recover on its own.

Bonus: I also have a TCP version running with succesful hardware calls. in TCP, I also changed "00017" into "17" (I did not touch 00001, 00002, 00018, 40001, 40002). Service keeps running with this continuous message:

00018: 0
40001: 0
40002: 0
00001: 1
00002: 1
Modbus exception code: 2

After setting the TCP coil address back to "00017":

00002: 1
Modbus exception code: 2
Desired property change:
{"PublishInterval":"5000","SlaveConfigs":{"Slave01":{"SlaveConnection":"192.168.1.142","HwId":"Wise4012E-142","Operations":{"Op01":{"PollingInterval":"5000","UnitId":"1","StartAddress":"40001","Count":"1","DisplayName":"KnobOne"},"Op02":{"PollingInterval":"5000","UnitId":"1","StartAddress":"40002","Count":"1","DisplayName":"KnobTwo"},"Op03":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00001","Count":"1","DisplayName":"SwitchOne"},"Op04":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00002","Count":"1","DisplayName":"SwitchTwo"},"Op05":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00017","Count":"1","DisplayName":"RelayOne"},"Op06":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00018","Count":"1","DisplayName":"RelayTwo"}}}},"$version":6}
Attempt to load configuration: {"PublishInterval":"5000","SlaveConfigs":{"Slave01":{"SlaveConnection":"192.168.1.142","HwId":"Wise4012E-142","Operations":{"Op01":{"PollingInterval":"5000","UnitId":"1","StartAddress":"40001","Count":"1","DisplayName":"KnobOne"},"Op02":{"PollingInterval":"5000","UnitId":"1","StartAddress":"40002","Count":"1","DisplayName":"KnobTwo"},"Op03":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00001","Count":"1","DisplayName":"SwitchOne"},"Op04":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00002","Count":"1","DisplayName":"SwitchTwo"},"Op05":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00017","Count":"1","DisplayName":"RelayOne"},"Op06":{"PollingInterval":"5000","UnitId":"1","StartAddress":"00018","Count":"1","DisplayName":"RelayTwo"}}}},"$version":6}
Invalid TcpPort: , set to DefaultTcpPort: 502
Invalid RetryCount: , set to DefaultRetryCount: 10
Invalid RetryInterval: , set to DefaultRetryInterval: 50
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
Empty CorrelationId: , set to DefaultCorrelationId: DefaultCorrelationId
40001: 0
40002: 0
00001: 1
00018: 0
00002: 1
00017: 0

docker version:

Client:
Version: 18.06.0-dev
API version: 1.37
Go version: go1.10.2
Git commit: daf021fe
Built: Mon Jun 25 21:07:53 2018
OS/Arch: linux/amd64
Experimental: false
Orchestrator: swarm

Server:
Engine:
Version: dev
API version: 1.37 (minimum version 1.12)
Go version: go1.10.2
Git commit: 9aac187
Built: Mon Jun 25 20:43:05 2018
OS/Arch: linux/amd64
Experimental: false
uno2271gsv@uno2271gsv-UNO-2271G-E2xAE:~$

Conclusion: Modbus TCP does not return an exception and ignores an invalid address. Modbus RTU gives an exception and seems to be locked.

Unable to locate identity_map library...Can i get the source code to understand it better please

I have assignment to map the modbus slave devices with IoT Hub devices (Not Edge devices). The identity map source code would help me understand it better. Please help me.

Thank you.
Venu

Question: Would you consider supporting multiple register write?

I understand that

Currently it supports writing back to a single register/cell in a Modbus slave.

However I've encountered a scenario where a device exposes two addresses for a single value representation. Address 13056 & 13057 correspond to a Counter 1 with a range of 0 - 999,999,999.

As a test I used QModMaster to write the value 4400 (to address 13056) and 1 (to address 13057).
Perfect, the Modbus Module also reads this value fine!

However, since the modbus module only supports single register writes at a time
Write to 13056 value 4400
Write to 13057 value 1

I actually end up with (0, 1) instead of the expected (4400, 1).
I am not familiar with MODBUS and how the devices are designed but assuming that is NORMAL behavior for a device, I can't use this modbus module to write any values as single write operation overwrites the other register. I always end up with just the one value.

Write to 13056 value 4400 results in (4400, 0)
Write to 13057 value 1 results in (0, 1)

Update No 1

The earlier "issue/question" may very well be device specific, however after talking to the manufacturer even they will have to do some investigation on their end to make sure they can re-produce my findings and provide feedback.

However: The actual device supports 32-bit reading/writing and a lot of addresses are treated by the device in 32-bit words.
This would raise a further question: Will iot-edge-modbus support the reading and writing of 32 bit addresses?

This would simplify a lot of the comms to/and from the device as the value that we intend to read/write is in 32 bit so any conversions would take place on the device itself rather than a custom hand-cranked iot-edge module.
For example: If your Modbus driver does not support a 32-bit long integer format, you can read the two 16-bit registers separately, and then convert them into a 32-bit value as follows (using C notation): 32-bit value = (unsigned short) low order register + (signed short) high order register * 65536L

eg: Value[0] + ( Value[1] * 65536)

Error when registering EventHandlers

I was able to run the module in a stand alone module, but starting yesterday i'm receiving the following error message "SetInputMessageHandlerAsync for a named output is available for Modules only" when i hit the below code.

await UpdateStartFromTwin(moduleTwin.Properties.Desired, ioTHubModuleClient);

Whats the reason behind this behavior?

Modbus module fails with IoT Edge GA

With the IoT Edge GA release the module fails to run.

From iotedge logs modbus:
Missing path to certificate collection file.

Unhandled Exception: System.InvalidOperationException: Missing path to certificate file.
at Modbus.Containers.Program.InstallCert() in /app/Program.cs:line 79
at Modbus.Containers.Program.Main(String[] args) in /app/Program.cs:line 35
Missing path to certificate collection file.

Socket handling

Hi, in your code you are checking for return of recv == SOCKET_ERROR that is -1 but you also have to check for == 0

See manpages: "These calls return the number of bytes received, or -1 if an error occurred. The return value will be 0 when the peer has performed an orderly shutdown." from https://linux.die.net/man/2/recv

Also the socket is stream oriented and may transfer fewer bytes than requested for read or write operations. This is referred to as socket short read for the recv function. recv_size needs to be checked, also check if the number of bytes to send are less compared with the return value of send (short write).

See: http://stackoverflow.com/questions/666601/what-is-the-correct-way-of-reading-from-a-tcp-socket-in-c-c

Error: Modbus Serial

Hello ! I'm using iot edge modbus serial in raspberry pi to read data from a sensor and always the program stop reading in different times after start. Someone knows about it ?

Executing Modbus Module Example Throws OpenSSL Error

OS: Linux raspberrypi 4.4.26-v7+
GCC: (Raspbian 4.9.2-10) 4.9.2

When the current version of the module is built and run against the 2016-11-18 branch of the azure-iot-gateway-sdk the following error is thrown indicating a failure to establish a connection to the IoT Hub:

Error: Time:Wed Dec 21 12:58:55 2016 File:/home/pi/code/azure-iot-gateway-sdk/deps/c-utility/src/tlsio_openssl.c Func:log_ERR_get_error Line:296 Failed allocating OpenSSL context.
Error: Time:Wed Dec 21 12:58:55 2016 File:/home/pi/code/azure-iot-gateway-sdk/deps/c-utility/src/tlsio_openssl.c Func:log_ERR_get_error Line:303   [0] error:140A90A1:lib(20):func(169):reason(161)
Error: Time:Wed Dec 21 12:58:55 2016 File:/home/pi/code/azure-iot-gateway-sdk/deps/iot-sdk/c/iothub_client/src/iothubtransport_amqp_common.c Func:establishConnection Line:627 Failed to open the connection with CBS.
Error: Time:Wed Dec 21 12:58:55 2016 File:/home/pi/code/azure-iot-gateway-sdk/deps/iot-sdk/c/iothub_client/src/iothubtransport_amqp_common.c Func:IoTHubTransport_AMQP_Common_DoWork Line:1349 AMQP transport failed to establish connection with service.
Error: Time:Wed Dec 21 12:58:55 2016 File:/home/pi/code/azure-iot-gateway-sdk/deps/iot-sdk/c/iothub_client/src/iothubtransportamqp_auth.c Func:authentication_reset Line:637 Failed to reset the authentication state (authentication status is invalid: 0)
Error: Time:Wed Dec 21 12:58:55 2016 File:/home/pi/code/azure-iot-gateway-sdk/deps/iot-sdk/c/iothub_client/src/iothubtransport_amqp_common.c Func:prepareDeviceForConnectionRetry Line:1071 Failed resetting the authenticatication state of device �	�r

The IoTHub module's transport was set to AMQP as follows:

{
      "name": "IotHub",
      "loader": {
        "name": "native",
        "entrypoint": {
          "module.path": "../../modules/iothub/libiothub.so"
        }
      },
      "args": {
        "IoTHubName": "********",
        "IoTHubSuffix": "*********",
        "Transport": "AMQP"
      }
    },

And the modbus_read module is configured for TCP:

      "name": "modbus_read",
      "loader": {
        "name": "native",
        "entrypoint": {
          "module.path": "../../modules/modbus_read/libmodbus_read.so"
        }
      },
      "args": [
        {
          "serverConnectionString": "10.121.208.5",
          "interval": "2000",
          "macAddress": "01:01:01:01:01:01",
          "deviceType": "powerMeter",
          "operations": [
            {
              "unitId": "0",
              "functionCode": "4",
              "startingAddress": "1",
              "length": "10"
            }
          ]
        }
      ]

The error is not thrown with a similar IoT Hub and Device configuration in the simulated_device_cloud_upload sample project in the base SDK repository.

The error seems to pivot around registering a macAddress with the mapping module that is the same as what is in the modbus_read module.

Recommendation - Data types

This is not a problem but a recommendation, the data could be converted to the correct data type in the same module. It would be useful to have different data types e.g. unit16, int32, float32, etc.
This information could be incorporated into the device twin for the module when you build each modbus mapping.

Thanks
Brendan

[v1] modbus module is not reading data from when a slave is disabled and enabled

I used ModbusPal[1] for testing the module. It has options to disable and enabling a slave. Try disabling and enabling a slave. Modbus module fails to read from it ever again until the modbus slave is restarted. Mbpoll[2] continues to work.

Machine restart - no data from modbus to edge

HI - I have noticed that sometimes after a reboot of the machine, although the modbus module comes up fine and is reporting data, no data is received at the IoT Hub. It would appear that either data is not arriving at the edgeHub from the module. If I try and send a device twin update to the module I get this error in the module logs:

Error when receiving desired property: Operation timeout expired.

Restarting the module does not fix it. I have also removed the module and redeployed it. Although this fixes the device twin issue, I still get not data into the hub.

Can you advise how to debug this or advise as to what the issue is?

ArgumentNullException: Value cannot be null after Module twin update

Hello, I try to update a Module twin. I got this exception which does not give a good description.

But more serious is that the update is not ignored (or rolled back). The module stops functioning and ignores newer Module Twin changes.

40115: 0
40116: 0
40117: 0
40118: 0
40119: 0

Desired property change:
{"PublishInterval":"2000","SlaveConfigs":{"Slave01":{"SlaveConnection":"10.1.35.104","HwId":"eWONAtcData","Operations":{"Op01":{"PollingInterval":"2000","UnitId":"1","StartAddress":"110","Count":"2","DisplayName":"Dancer22Position"}}}},"$version":4}
Attempt to load configuration: {"PublishInterval":"2000","SlaveConfigs":{"Slave01":{"SlaveConnection":"10.1.35.104","HwId":"eWONAtcData","Operations":{"Op01":{"PollingInterval":"2000","UnitId":"1","StartAddress":"110","Count":"2","DisplayName":"Dancer22Position"}}}},"$version":4}

Error when receiving desired property: System.ArgumentNullException: Value cannot be null.
Parameter name: format

at System.String.FormatHelper(IFormatProvider provider, String format, ParamsArray args)
at Modbus.Slaves.ModbusSlaveSession.ProcessResponse(ModbusSlaveConfig config, ReadOperation x) in /app/ModbusSlave.cs:line 235
at Modbus.Slaves.ModbusSlaveSession.<SingleOperation>d__26.MoveNext() in /app/ModbusSlave.cs:line 194
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Modbus.Slaves.ModbusSlaveSession.<>c__DisplayClass21_0.<<ProcessOperations>b__0>d.MoveNext() in /app/ModbusSlave.cs:line 172

I seems the event of a new Module Twin is arriving but still the old (corrupt) one is evaluated.
I have to roll out another version of this module to try to fix this

Modbus settings?

Hi all,

how do I set the parrity, stopbit, etc? I cannot connect to my modbus device.
Also I'm using linux which means there is no COM1 or COM2 but the module doesn't allow /dev/ttyS1 or /dev/ttyS2...
Ideas?
Thanks =)

Best regards
Zuendelmeister

Polling interval

This seems to have no effect on the module. Jus reads as fast as possible.

Would be good to timestamp the output.

Thanks

Unable to run as stand-alone mode, because its dependant on ConnectionString to the EdgeHub and EdgeHub Certificate

I pretty much followed the documentation and tried executing the module as a standalone app and received the following error message. Basically it looks for Environment variables for IoTEdge Connection string and Certificate File path. Are there any work around for this, if so where do i get these information from.

Error Message

Unhandled Exception: System.AggregateException: One or more errors occurred. (Value cannot be null.
Parameter name: connectionString) ---> System.ArgumentNullException: Value cannot be null.
Parameter name: connectionString
at Microsoft.Azure.Devices.Client.DeviceClient.CreateFromConnectionString(String connectionString, ITransportSettings[] transportSettings, IDeviceClientPipelineBuilder pipelineBuilder)
at Modbus.Containers.Program.d__11.MoveNext() in C:\Ilyas\AzureFunction\iot-edge-modbus\src\Program.cs:line 108
--- End of inner exception stack trace ---
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions)
at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
at System.Threading.Tasks.Task.Wait()
at Modbus.Containers.Program.Main(String[] args) in C:\Ilyas\AzureFunction\iot-edge-modbus\src\Program.cs:line 39

Connecting to multiple modbus devices

I need the same gateway to read from multiple ModBus enabled devices.

How can this be achieved with you module, i can't seam to get it working?

Construct Json message with parson APIs

Rewrite the code where generates Json format messages with parson APIs instead of manipulating the strings directly.

Suggestion - Sub-Operations to help with data usage management

I have hundreds of registers to read and would like to control PollingInterval in 10-12 separate groups. For example:

{
"PublishInterval": "5000",
"SlaveConfigs": {
"Slave01": {
"SlaveConnection": "127.0.0.1",
"TcpPort": "502",
"RetryCount": "10",
"RetryInterval": "100",
"HwId": "PowerMeter-0a:01:01:01:01:01",
"Operations": {
"Op01": { //Group "Non-Critical"
"PollingInterval": "60000",
"UnitId": "1",
"Addressses": {
["StartAddress": "400001", "Count": "2", "CorrelationId": "MessageType1", "DisplayName": "Voltage"],
["StartAddress": "400002", "Count": "2", "CorrelationId": "MessageType1", "DisplayName": "Current"],
}
},
"Op02": { //Group "Critical"
"PollingInterval": "2000",
"UnitId": "1",
"Addressses": {
["StartAddress": "300001", "Count": "1", "CorrelationId": "MessageType1", "DisplayName": "TemperatureAlarm"],
["StartAddress": "300002", "Count": "1", "CorrelationId": "MessageType1", "DisplayName": "SafetyInterlock1"],
}
}

Module Build Warnings

OS: Linux raspberrypi 4.4.26-v7+
GCC: (Raspbian 4.9.2-10) 4.9.2

When the current module is built against the 2016-11-18 branch of the azure-iot-gateway-sdk on Raspbian the following build warnings are encountered:

Building C object modules/modbus_read/CMakeFiles/modbus_read.dir/src/modbus_read.c.o
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: In function ‘addOneServer’:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:171:46: warning: passing argument 1 of ‘isValidServer’ discards ‘const’ qualifier from pointer target type
     if (server_str == NULL || !isValidServer(server_str))
                                              ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:90:13: note: expected ‘char *’ but argument is of type ‘const char *’
 static bool isValidServer(char* server)
             ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:177:49: warning: passing argument 1 of ‘isValidMac’ discards ‘const’ qualifier from pointer target type
     else if (mac_address == NULL || !isValidMac(mac_address))
                                                 ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:54:13: note: expected ‘char *’ but argument is of type ‘const char *’
 static bool isValidMac(char* mac)
             ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: In function ‘modbusReadThread’:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:681:43: warning: assignment from incompatible pointer type
             server_config->encode_read_cb = (int*)encode_read_request_com;
                                           ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:682:44: warning: assignment from incompatible pointer type
             server_config->encode_write_cb = (int*)encode_write_request_com;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:683:47: warning: assignment from incompatible pointer type
             server_config->decode_response_cb = (int*)decode_response_com;
                                               ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:684:44: warning: assignment from incompatible pointer type
             server_config->send_request_cb = (int*)send_request_com;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:697:43: warning: assignment from incompatible pointer type
             server_config->encode_read_cb = (int*)encode_read_request_tcp;
                                           ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:698:44: warning: assignment from incompatible pointer type
             server_config->encode_write_cb = (int*)encode_write_request_tcp;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:699:47: warning: assignment from incompatible pointer type
             server_config->decode_response_cb = (int*)decode_response_tcp;
                                               ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:700:44: warning: assignment from incompatible pointer type
             server_config->send_request_cb = (int*)send_request_tcp;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: At top level:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:1095:2: warning: initialization from incompatible pointer type
  ModbusRead_ParseConfigurationFromJson,
  ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:1095:2: warning: (near initialization for ‘moduleInterface.Module_ParseConfigurationFromJson’)
Linking C shared module libmodbus_read.so
[ 81%] Built target modbus_read
Scanning dependencies of target modbus_read_static
[ 82%] Building C object modules/modbus_read/CMakeFiles/modbus_read_static.dir/src/modbus_read.c.o
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: In function ‘addOneServer’:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:171:46: warning: passing argument 1 of ‘isValidServer’ discards ‘const’ qualifier from pointer target type
     if (server_str == NULL || !isValidServer(server_str))
                                              ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:90:13: note: expected ‘char *’ but argument is of type ‘const char *’
 static bool isValidServer(char* server)
             ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:177:49: warning: passing argument 1 of ‘isValidMac’ discards ‘const’ qualifier from pointer target type
     else if (mac_address == NULL || !isValidMac(mac_address))
                                                 ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:54:13: note: expected ‘char *’ but argument is of type ‘const char *’
 static bool isValidMac(char* mac)
             ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: In function ‘modbusReadThread’:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:681:43: warning: assignment from incompatible pointer type
             server_config->encode_read_cb = (int*)encode_read_request_com;
                                           ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:682:44: warning: assignment from incompatible pointer type
             server_config->encode_write_cb = (int*)encode_write_request_com;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:683:47: warning: assignment from incompatible pointer type
             server_config->decode_response_cb = (int*)decode_response_com;
                                               ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:684:44: warning: assignment from incompatible pointer type
             server_config->send_request_cb = (int*)send_request_com;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:697:43: warning: assignment from incompatible pointer type
             server_config->encode_read_cb = (int*)encode_read_request_tcp;
                                           ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:698:44: warning: assignment from incompatible pointer type
             server_config->encode_write_cb = (int*)encode_write_request_tcp;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:699:47: warning: assignment from incompatible pointer type
             server_config->decode_response_cb = (int*)decode_response_tcp;
                                               ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:700:44: warning: assignment from incompatible pointer type
             server_config->send_request_cb = (int*)send_request_tcp;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: At top level:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:1095:2: warning: initialization from incompatible pointer type
  ModbusRead_ParseConfigurationFromJson,
  ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:1095:2: warning: (near initialization for ‘moduleInterface.Module_ParseConfigurationFromJson’)
Linking C static library libmodbus_read_static.a
[ 82%] Built target modbus_read_static
Scanning dependencies of target modbus_read_unittests_exe
[ 83%] Building CXX object modules/modbus_read/tests/modbus_read_unittests/CMakeFiles/modbus_read_unittests_exe.dir/modbus_read_unittests.cpp.o
[ 85%] Building C object modules/modbus_read/tests/modbus_read_unittests/CMakeFiles/modbus_read_unittests_exe.dir/__/__/src/modbus_read.c.o
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: In function ‘addOneServer’:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:171:46: warning: passing argument 1 of ‘isValidServer’ discards ‘const’ qualifier from pointer target type
     if (server_str == NULL || !isValidServer(server_str))
                                              ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:90:13: note: expected ‘char *’ but argument is of type ‘const char *’
 static bool isValidServer(char* server)
             ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:177:49: warning: passing argument 1 of ‘isValidMac’ discards ‘const’ qualifier from pointer target type
     else if (mac_address == NULL || !isValidMac(mac_address))
                                                 ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:54:13: note: expected ‘char *’ but argument is of type ‘const char *’
 static bool isValidMac(char* mac)
             ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: In function ‘modbusReadThread’:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:681:43: warning: assignment from incompatible pointer type
             server_config->encode_read_cb = (int*)encode_read_request_com;
                                           ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:682:44: warning: assignment from incompatible pointer type
             server_config->encode_write_cb = (int*)encode_write_request_com;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:683:47: warning: assignment from incompatible pointer type
             server_config->decode_response_cb = (int*)decode_response_com;
                                               ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:684:44: warning: assignment from incompatible pointer type
             server_config->send_request_cb = (int*)send_request_com;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:697:43: warning: assignment from incompatible pointer type
             server_config->encode_read_cb = (int*)encode_read_request_tcp;
                                           ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:698:44: warning: assignment from incompatible pointer type
             server_config->encode_write_cb = (int*)encode_write_request_tcp;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:699:47: warning: assignment from incompatible pointer type
             server_config->decode_response_cb = (int*)decode_response_tcp;
                                               ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:700:44: warning: assignment from incompatible pointer type
             server_config->send_request_cb = (int*)send_request_tcp;
                                            ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c: At top level:
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:1095:2: warning: initialization from incompatible pointer type
  ModbusRead_ParseConfigurationFromJson,
  ^
/home/pi/code/test/azure-iot-gateway-sdk/modules/modbus_read/src/modbus_read.c:1095:2: warning: (near initialization for ‘moduleInterface.Module_ParseConfigurationFromJson’)```

Modbus module delay in reconnecting after network drop

We have an interesting and rather unusual network configuration that we established to make a portable demonstration of Azure IoT reading data from a Modbus device. This portable solution requires that we bridge a local network out to the internet via a Windows 10 laptop with Internet Connection Sharing (ICS) enabled.

The ICS service has proven somewhat unreliable under certain conditions and the bridge in the laptop can fail to function and need to be restarted.

When this occurs there is a significant delay (greater than 5 minutes) between the time network connectivity is re-established and the time that data starts to be received again by the Azure IoT Hub. And during this period data is still being produced out of the Modbus module.

Is there a configuration that will prevent this delay in sending data to the IoT Hub from occurring? Some time out setting?

Thanks in advance for any help.

--UPDATE: We had this issue with both version 1.0.3 and 1.0.4 of the edge runtime.

Please name the root array

It is difficult to work with both versions of the output JSON in Azure Stream Analytics as the root array is not named. For example, see this documentation that assumes "the input events have a property named "arrayField" that is an array datatype": Parse JSON and Avro data in Azure Stream Analytics

Modbus TCP does not support hostname resolution

It would be convenient if we could use syntax such as tcp:mycontainer instead of 10.0.71.1 for the SlaveConnection setting and have the iot-edge-modbus resolve the container to IP.

PR to follow.

MessageResponse could not be found in 'Microsoft.Azure.Devices.Client'

MessageResponse enum does not exist any of the stable build 'Microsoft.Azure.Devices.Client' NuGate package when trying to build in visual studio 2017.

Error message when trying to build-

Severity Code Description Project File Line Suppression State
Error CS0246 The type or namespace name 'MessageResponse' could not be found (are you missing a using directive or an assembly reference?) iot-edge-modbus D:\Code\VisualStudio\iot-edge-modbus-master\src\Program.cs 136 Active

Severity Code Description Project File Line Suppression State
Error CS0103 The name 'MessageResponse' does not exist in the current context iot-edge-modbus D:\Code\VisualStudio\iot-edge-modbus-master\src\Program.cs 176 Active

Configuration - documentation is unclear

You say "you need proper configuration" - where does that JSON go? I can't find it in the azure ui, and I don't know where to put it on the device (a linux vm at the moment)

Update Reported Properties on Config Change

Update the reported properties on successful config change so that it can be verified via module twin that the config has been received.

Would be especially helpful in UI apps and administration verification.

ModuleClient.UpdateReportedProperties

Would probably be best to put it in the if block confirming the configuration is valid here. But also might be better in other places.

How to write to Modbus from IoT Hub

Hi @606simps,

Is there a way to write to Modbus using direct methods or cloud-to-device messages from the IoT Edge panel on the IoT Hub?

I could not make it work. Is it necessary to add some route from the IoT Hub to the Modbus input1?

Thank you.

[v1] retries on connect failure

If the Modbus slave is not started when the v1 module is started, no connect retries are ever attempted. The polling/publish interval is not honoured if the Modbus slave gets started after v1 iot-edge-modbus module.

Once the v1 module connects to a Modbus slave for at-least one time, there after connect retries works perfectly. After a single successful connect, we can restart the Modbus slave as many times and v1 module will successfully connect.

Can tcp port be made configurable?

Currently iot-edge-modbus.json doesn't accept TCP port as a parameter. Can this be added?

A non related query: You have mapped modbus RTU devices to inside containers with "Container Create Option Section"(1). I tried reading iot-edge docs, but this area is not documented. Could you please point to the docs or sample source from which you go this? Please feel free to not respond to this documentation request if this is not in your scope.

How to you build a multi-architecture docker image?

Is documented how you built microsoft/azureiotedge-modbus-tcp:1.0-preview to be multi-architecture?

Apparent hang if modbus server restarted

Hi - at the moment I noticed that if the modbus server stops/crashes and is restarted, you have to restart the modbus edge module to re-establish connectivity.

Is there a way for the modbus module to do this automatically?
Or perhaps get the module to report to eventHub that it cannot connect and send a command back to edge to restart the module??

Single stage build for arm32v7 not working

I am following the single stage build process for arm32v7:

$cd iot-edge-modbus/src/
$dotnet restore
$dotnet build
$dotnet publish -f netcoreapp2.0 -c Release
$cd ../
$docker build --build-arg EXE_DIR=./src/bin/Release/netcoreapp2.0/publish -t "modbus:latest" -f Docker/linux-arm32/Dockerfile .

But when I deploy this module I get the following error when trying to use MODBUS RTU operations:

"Unable to load DLL 'libcomWrapper.so': The specified module or one of its dependencies could not be found"

The libcomWrapper.so file looks like it has correctly generated and is located in the /usr/lib/ folder on the container.

Any ideas what I am doing wrong?

Desired Properties not getting triggrered

Hi all,
With polling interval set to 1 second for 8 sensors with 1 slave. After some time the desired properties does not get triggered(the data does not get received in OnDesiredPropertiesUpdate callback) after changing from the cloud portal. I had to restart the edge using the command sudo iotedgectl stop followed by sudo iotedgectl start in order to receive the desired properties. Any pointers to this issue ?

Extend module

Hi
I'm very new to c++ and i want to extend your module but i can't get the code to build.
How should i extend you module and test if it can build without having to copy the folders to gateway folder?

Token and TLS handshake

Hi @606simps,

I openned an issue with the IoT Edge team and solved it, but I have 2 doubts that they said to ask here, please, see if you can help.

All the data that is being sent by the IoT Edge is received by IoT Hub (I used Stream Analytics to measure that).

Here is my edgeHub log:

2018-03-27 13:51:03.528 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 13:51:03.529 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 13:51:03.627 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 45 with batch size 10.
2018-03-27 13:51:03.628 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 46.
2018-03-27 13:51:03.629 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 46 with batch size 10.
2018-03-27 13:51:03.629 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 46.
2018-03-27 13:51:03.858 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 13:51:04.998 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Getting new token for TC-IoT-Edge/modbus.
2018-03-27 13:51:04.999 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Existing token not found for TC-IoT-Edge/modbus. Getting new token from the client...
2018-03-27 13:51:05.000 +00:00 [WRN] [ProtocolGateway] - Closing connection for device: TC-IoT-Edge/modbus, Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnectionException: Connection closed for device TC-IoT-Edge/modbus., 
2018-03-27 13:51:05.001 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Disposing MessagingServiceClient for device Id TC-IoT-Edge/modbus because of exception - Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnectionException: Connection closed for device TC-IoT-Edge/modbus.
2018-03-27 13:51:05.002 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.DeviceProxy] - Closing device proxy for device Id TC-IoT-Edge/modbus
2018-03-27 13:51:05.002 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - Device connection removed for device TC-IoT-Edge/modbus
2018-03-27 13:51:05.003 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnection] - Updating device TC-IoT-Edge/modbus connection status to Disconnected
2018-03-27 13:51:05.213 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Obtained new token for client TC-IoT-Edge/modbus that expires in 00:59:59.7868522
2018-03-27 13:51:05.213 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Updated cloud connection for client TC-IoT-Edge/modbus
2018-03-27 13:51:05.213 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - New cloud connection created for device TC-IoT-Edge/modbus
2018-03-27 13:51:05.213 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Authenticator] - Successfully authenticated device TC-IoT-Edge/modbus
2018-03-27 13:51:05.214 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SasTokenDeviceIdentityProvider] - Successfully generated identity for clientId TC-IoT-Edge/modbus and username HIDDEN
2018-03-27 13:51:05.214 +00:00 [INF] [ProtocolGateway] - ClientAuthenticated, TC-IoT-Edge/modbus, 5c147a81
2018-03-27 13:51:05.214 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - Obtained cloud connection for device TC-IoT-Edge/modbus
2018-03-27 13:51:05.216 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Binding cloud listener for device TC-IoT-Edge/modbus
2018-03-27 13:51:05.216 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - New device connection for device TC-IoT-Edge/modbus
2018-03-27 13:51:05.216 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnection] - Updating device TC-IoT-Edge/modbus connection status to Connected
2018-03-27 13:51:05.225 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Device.DeviceMessageHandler] - Bind device proxy for device TC-IoT-Edge/modbus
2018-03-27 13:51:05.225 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Binding message channel for device Id TC-IoT-Edge/modbus
2018-03-27 13:51:05.226 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStatePersistenceProvider] - Adding subscription $iothub/twin/res/# for client TC-IoT-Edge/modbus.
2018-03-27 13:51:05.226 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStatePersistenceProvider] - Adding subscription devices/TC-IoT-Edge/modules/modbus/# for client TC-IoT-Edge/modbus.
2018-03-27 13:51:05.227 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStatePersistenceProvider] - Adding subscription $iothub/twin/PATCH/properties/desired/# for client TC-IoT-Edge/modbus.
2018-03-27 13:51:05.228 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStateStoragePersistenceProvider] - Set subscriptions from session state for TC-IoT-Edge/modbus
2018-03-27 13:51:05.244 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Updating reported properties for device TC-IoT-Edge/$edgeHub
2018-03-27 13:51:05.244 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Successfully sent reported properties to cloud for TC-IoT-Edge/$edgeHub and reported properties version 0
2018-03-27 13:51:05.246 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Updated cached reported property for TC-IoT-Edge/$edgeHub at reported property version 841 cloudVerified True
2018-03-27 13:51:07.360 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Updating reported properties for device TC-IoT-Edge/$edgeHub
2018-03-27 13:51:07.361 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Successfully sent reported properties to cloud for TC-IoT-Edge/$edgeHub and reported properties version 0
2018-03-27 13:51:07.365 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Updated cached reported property for TC-IoT-Edge/$edgeHub at reported property version 841 cloudVerified True
2018-03-27 13:53:34.732 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 13:53:34.732 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 13:53:34.734 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 46 with batch size 10.
2018-03-27 13:53:34.735 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 47.
2018-03-27 13:53:34.735 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 47 with batch size 10.
2018-03-27 13:53:34.736 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 47.
2018-03-27 13:53:34.941 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 13:54:46.035 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of stores
2018-03-27 13:54:46.038 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of store checkpoints
2018-03-27 13:54:46.070 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of store sessions
2018-03-27 13:54:46.089 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of store twins
2018-03-27 13:54:46.105 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of store iothub
2018-03-27 13:54:46.120 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of store messages
2018-03-27 13:54:46.139 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Storage.RocksDb.DbStoreProvider] - Starting compaction of store default
2018-03-27 13:56:05.749 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 13:56:05.749 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 13:56:05.752 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 47 with batch size 10.
2018-03-27 13:56:05.847 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 48.
2018-03-27 13:56:05.848 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 48 with batch size 10.
2018-03-27 13:56:05.848 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 48.
2018-03-27 13:56:06.292 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 13:56:23.803 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Started task to cleanup processed and stale messages for endpoint iothub
2018-03-27 13:56:23.803 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Checkpoint for endpoint iothub is 47
2018-03-27 13:56:23.917 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Cleaned up 12 messages from queue for endpoint iothub and 12 messages from message store.
2018-03-27 13:56:23.918 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Total messages cleaned up from queue for endpoint iothub = 48, and total messages cleaned up for message store = 48.
2018-03-27 13:58:36.761 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 13:58:36.762 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 13:58:36.764 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 48 with batch size 10.
2018-03-27 13:58:36.766 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 49.
2018-03-27 13:58:36.767 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 49 with batch size 10.
2018-03-27 13:58:36.866 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 49.
2018-03-27 13:58:37.107 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:01:07.779 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:01:07.779 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:01:07.781 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 49 with batch size 10.
2018-03-27 14:01:07.881 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 50.
2018-03-27 14:01:07.882 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 50 with batch size 10.
2018-03-27 14:01:07.883 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 50.
2018-03-27 14:01:08.164 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:03:38.789 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:03:38.790 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:03:38.792 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 50 with batch size 10.
2018-03-27 14:03:38.794 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 51.
2018-03-27 14:03:38.795 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 51 with batch size 10.
2018-03-27 14:03:38.796 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 51.
2018-03-27 14:03:39.069 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:06:09.808 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:06:09.808 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:06:09.811 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 51 with batch size 10.
2018-03-27 14:06:09.813 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 52.
2018-03-27 14:06:09.813 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 52 with batch size 10.
2018-03-27 14:06:09.814 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 52.
2018-03-27 14:06:10.053 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:08:40.809 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:08:40.809 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:08:40.811 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 52 with batch size 10.
2018-03-27 14:08:40.904 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 53.
2018-03-27 14:08:40.904 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 53 with batch size 10.
2018-03-27 14:08:40.904 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 53.
2018-03-27 14:08:41.135 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:11:11.818 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:11:11.818 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:11:11.909 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 53 with batch size 10.
2018-03-27 14:11:11.911 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 54.
2018-03-27 14:11:11.911 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 54 with batch size 10.
2018-03-27 14:11:11.912 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 54.
2018-03-27 14:11:12.392 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:13:42.913 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:13:42.914 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:13:42.916 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 54 with batch size 10.
2018-03-27 14:13:42.918 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 55.
2018-03-27 14:13:42.919 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 55 with batch size 10.
2018-03-27 14:13:42.920 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 55.
2018-03-27 14:13:43.167 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:16:13.928 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:16:13.929 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:16:13.931 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 55 with batch size 10.
2018-03-27 14:16:13.933 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 56.
2018-03-27 14:16:13.935 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 56 with batch size 10.
2018-03-27 14:16:14.033 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 56.
2018-03-27 14:16:14.229 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:18:44.948 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:18:44.949 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:18:44.951 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 56 with batch size 10.
2018-03-27 14:18:45.049 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 57.
2018-03-27 14:18:45.049 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 57 with batch size 10.
2018-03-27 14:18:45.050 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 57.
2018-03-27 14:18:45.312 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:21:15.948 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:21:15.948 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:21:15.951 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 57 with batch size 10.
2018-03-27 14:21:15.953 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 58.
2018-03-27 14:21:15.954 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 58 with batch size 10.
2018-03-27 14:21:15.955 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 58.
2018-03-27 14:21:16.199 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:23:46.968 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:23:46.968 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:23:46.971 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 58 with batch size 10.
2018-03-27 14:23:47.078 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 59.
2018-03-27 14:23:47.085 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 59 with batch size 10.
2018-03-27 14:23:47.086 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 59.
2018-03-27 14:23:47.335 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:26:17.989 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:26:18.083 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:26:18.087 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 59 with batch size 10.
2018-03-27 14:26:18.089 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 60.
2018-03-27 14:26:18.090 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 60 with batch size 10.
2018-03-27 14:26:18.095 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 60.
2018-03-27 14:26:18.273 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:26:53.925 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Started task to cleanup processed and stale messages for endpoint iothub
2018-03-27 14:26:53.925 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Checkpoint for endpoint iothub is 59
2018-03-27 14:26:54.079 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Cleaned up 12 messages from queue for endpoint iothub and 12 messages from message store.
2018-03-27 14:26:54.079 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Total messages cleaned up from queue for endpoint iothub = 60, and total messages cleaned up for message store = 60.
2018-03-27 14:28:49.098 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:28:49.099 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:28:49.101 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 60 with batch size 10.
2018-03-27 14:28:49.103 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 61.
2018-03-27 14:28:49.103 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 61 with batch size 10.
2018-03-27 14:28:49.104 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 61.
2018-03-27 14:28:49.323 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:31:20.122 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:31:20.123 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:31:20.126 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 61 with batch size 10.
2018-03-27 14:31:20.204 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 62.
2018-03-27 14:31:20.204 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 62 with batch size 10.
2018-03-27 14:31:20.204 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 62.
2018-03-27 14:31:20.471 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:33:51.154 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:33:51.155 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:33:51.160 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 62 with batch size 10.
2018-03-27 14:33:51.261 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 63.
2018-03-27 14:33:51.263 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 63 with batch size 10.
2018-03-27 14:33:51.264 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 63.
2018-03-27 14:33:51.497 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:36:22.169 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:36:22.169 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:36:22.174 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 63 with batch size 10.
2018-03-27 14:36:22.176 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 64.
2018-03-27 14:36:22.176 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 64 with batch size 10.
2018-03-27 14:36:22.177 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 64.
2018-03-27 14:36:22.360 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:38:53.189 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:38:53.189 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:38:53.194 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 64 with batch size 10.
2018-03-27 14:38:53.287 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 65.
2018-03-27 14:38:53.295 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 65 with batch size 10.
2018-03-27 14:38:53.296 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 65.
2018-03-27 14:38:53.524 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:41:24.209 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:41:24.209 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:41:24.312 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 65 with batch size 10.
2018-03-27 14:41:24.316 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 66.
2018-03-27 14:41:24.318 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 66 with batch size 10.
2018-03-27 14:41:24.319 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 66.
2018-03-27 14:41:24.504 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:43:55.320 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:43:55.320 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:43:55.323 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 66 with batch size 10.
2018-03-27 14:43:55.327 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 67.
2018-03-27 14:43:55.328 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 67 with batch size 10.
2018-03-27 14:43:55.328 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 67.
2018-03-27 14:43:55.681 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:46:26.332 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:46:26.333 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:46:26.335 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 67 with batch size 10.
2018-03-27 14:46:26.433 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 68.
2018-03-27 14:46:26.440 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 68 with batch size 10.
2018-03-27 14:46:26.441 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 68.
2018-03-27 14:46:26.663 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:48:57.343 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:48:57.343 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:48:57.346 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 68 with batch size 10.
2018-03-27 14:48:57.348 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 69.
2018-03-27 14:48:57.348 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 69 with batch size 10.
2018-03-27 14:48:57.349 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 69.
2018-03-27 14:48:57.638 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus
2018-03-27 14:49:05.007 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Getting new token for TC-IoT-Edge/modbus.
2018-03-27 14:49:05.017 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Existing token not found for TC-IoT-Edge/modbus. Getting new token from the client...
2018-03-27 14:49:05.018 +00:00 [WRN] [ProtocolGateway] - Closing connection for device: TC-IoT-Edge/modbus, Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnectionException: Connection closed for device TC-IoT-Edge/modbus., 
2018-03-27 14:49:05.019 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Disposing MessagingServiceClient for device Id TC-IoT-Edge/modbus because of exception - Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnectionException: Connection closed for device TC-IoT-Edge/modbus.
2018-03-27 14:49:05.019 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.DeviceProxy] - Closing device proxy for device Id TC-IoT-Edge/modbus
2018-03-27 14:49:05.019 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - Device connection removed for device TC-IoT-Edge/modbus
2018-03-27 14:49:05.020 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnection] - Updating device TC-IoT-Edge/modbus connection status to Disconnected
2018-03-27 14:49:05.288 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Updating reported properties for device TC-IoT-Edge/$edgeHub
2018-03-27 14:49:05.288 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Successfully sent reported properties to cloud for TC-IoT-Edge/$edgeHub and reported properties version 0
2018-03-27 14:49:05.291 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Updated cached reported property for TC-IoT-Edge/$edgeHub at reported property version 841 cloudVerified True
2018-03-27 14:49:05.297 +00:00 [WRN] [ProtocolGateway] - TLS handshake failed., System.IO.IOException: Channel is closed, 09c67dc6
2018-03-27 14:49:05.312 +00:00 [ERR] [DotNetty.Common.ResourceLeakDetector] - LEAK: IByteBuffer.Release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, set environment variable io.netty.leakDetection.level to advanced or set ResourceLeakDetector.Level in code. See http://netty.io/wiki/reference-counted-objects.html for more information.
2018-03-27 14:49:05.611 +00:00 [WRN] [ProtocolGateway] - TLS handshake failed., System.IO.IOException: Channel is closed, 352bfabd
2018-03-27 14:49:06.223 +00:00 [WRN] [ProtocolGateway] - TLS handshake failed., System.IO.IOException: Channel is closed, 50ded65c
2018-03-27 14:49:07.291 +00:00 [WRN] [ProtocolGateway] - TLS handshake failed., System.IO.IOException: Channel is closed, 6f15790f
2018-03-27 14:49:08.976 +00:00 [WRN] [ProtocolGateway] - TLS handshake failed., System.IO.IOException: Channel is closed, 0a1cd124
2018-03-27 14:49:12.794 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Obtained new token for client TC-IoT-Edge/modbus that expires in 01:00:00.2050982
2018-03-27 14:49:12.795 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudConnection] - Updated cloud connection for client TC-IoT-Edge/modbus
2018-03-27 14:49:12.795 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - New cloud connection created for device TC-IoT-Edge/modbus
2018-03-27 14:49:12.796 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Authenticator] - Successfully authenticated device TC-IoT-Edge/modbus
2018-03-27 14:49:12.796 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SasTokenDeviceIdentityProvider] - Successfully generated identity for clientId TC-IoT-Edge/modbus and username HIDDEN
2018-03-27 14:49:12.797 +00:00 [INF] [ProtocolGateway] - ClientAuthenticated, TC-IoT-Edge/modbus, 0f6f8e19
2018-03-27 14:49:12.797 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - Obtained cloud connection for device TC-IoT-Edge/modbus
2018-03-27 14:49:12.799 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Binding cloud listener for device TC-IoT-Edge/modbus
2018-03-27 14:49:12.799 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.ConnectionManager] - New device connection for device TC-IoT-Edge/modbus
2018-03-27 14:49:12.800 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.EdgeHubConnection] - Updating device TC-IoT-Edge/modbus connection status to Connected
2018-03-27 14:49:12.802 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Core.Device.DeviceMessageHandler] - Bind device proxy for device TC-IoT-Edge/modbus
2018-03-27 14:49:12.802 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Binding message channel for device Id TC-IoT-Edge/modbus
2018-03-27 14:49:12.803 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStatePersistenceProvider] - Adding subscription $iothub/twin/res/# for client TC-IoT-Edge/modbus.
2018-03-27 14:49:12.803 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStatePersistenceProvider] - Adding subscription devices/TC-IoT-Edge/modules/modbus/# for client TC-IoT-Edge/modbus.
2018-03-27 14:49:12.804 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStatePersistenceProvider] - Adding subscription $iothub/twin/PATCH/properties/desired/# for client TC-IoT-Edge/modbus.
2018-03-27 14:49:12.806 +00:00 [INF] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.SessionStateStoragePersistenceProvider] - Set subscriptions from session state for TC-IoT-Edge/modbus
2018-03-27 14:49:12.942 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Updating reported properties for device TC-IoT-Edge/$edgeHub
2018-03-27 14:49:12.942 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Successfully sent reported properties to cloud for TC-IoT-Edge/$edgeHub and reported properties version 0
2018-03-27 14:49:12.944 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.TwinManager] - Updated cached reported property for TC-IoT-Edge/$edgeHub at reported property version 841 cloudVerified True
2018-03-27 14:51:28.349 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Mqtt.MessagingServiceClient] - Sending message for device Id TC-IoT-Edge/modbus
2018-03-27 14:51:28.350 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Routing.RoutingEdgeHub] - Received message from TC-IoT-Edge/modbus
2018-03-27 14:51:28.352 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 69 with batch size 10.
2018-03-27 14:51:28.455 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 1. Next start offset = 70.
2018-03-27 14:51:28.456 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Getting next batch for endpoint iothub starting from 70 with batch size 10.
2018-03-27 14:51:28.456 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.Core.Storage.MessageStore] - Obtained next batch for endpoint iothub with batch size 0. Next start offset = 70.
2018-03-27 14:51:28.642 +00:00 [DBG] [Microsoft.Azure.Devices.Edge.Hub.CloudProxy.CloudProxy] - Sending message for device TC-IoT-Edge/modbus

If you look at my edgeHub logs, you are going to see that the modbus token is renewed every one hour, because the token is set to expire every one hour, is this default? Can I change the validity of this token somewhere?

Another question is that sometimes appers TLS handshake failed but does't seem to cause trouble to the data. Do you have any thoughts about this?

Thank you.

Modbus TCP Exception

Hello,

I am trying to read holding registers from Beckhoff plc the register address start from 32768 and when I use ModbusPoll I can access the values. But unfortunately when I use these desired properties, I get an Exception Code 2 and I cannot find a documentation of the exceptions
{
"properties.desired":{
"PublishInterval":"2000",
"SlaveConfigs":{
"Slave01": {
"SlaveConnection": "10.26.1.158",
"HwId": "PowerMeter-0a:01:01:01:01:01",
"Operations": {
"Op01": {
"PollingInterval": "2000",
"UnitId": "1",
"StartAddress": "432768",
"Count": "1",
"DisplayName": "Werte"
}
}
}
}
}
}
According to the Wiki page to access the holding register I have to use the prefix 4. I also tried it with the StartAddress :"32768".

I hope you can help me with my issue.
KR
Shehata

Error when building project

-- Configuring done
-- Generating done
-- Build files have been written to: E:/.../IoT/Azure/azure-iot-gateway-sdk/deps/nanomsg/build
-- Installing nanomsg. Please wait...
CMake Error at samples/modbus_sample/CMakeLists.txt:38 (copy_gateway_dll):
Unknown CMake command "copy_gateway_dll".

-- Configuring incomplete, errors occurred!
See also "E:/.../IoT/Azure/azure-iot-gateway-sdk/build/CMakeFiles/CMakeOutput.log".
See also "E:/.../IoT/Azure/azure-iot-gateway-sdk/build/CMakeFiles/CMakeError.log".