question

RajPandey-0212 avatar image
1 Vote"
RajPandey-0212 asked SandervandeVelde42 edited

How to configure TCP/IP communication working device with Azure IoT Hub

Hi,

We are using an OBD-II device that works on TCP/IP communication protocol. We can't add anything to the device besides the IP and the port of the server on which it has to send the data.

This device doesn't work on the MODBUS TCP communication protocol.

We want to connect these devices to the Azure IoT Hub. But there is no example working example for these. And there is no proper documentation. Everything is just theory and High leveled and confusing and fully complicated.

We are thinking of using Azure IoT Edge as a gateway(this will be on the server) and this gateway will work as a communication broker between devices and the Azure IoT Hub.

As we can't add anything in the device like for authentication (SAS token and the certificates) we can rule out the transparent gateway method. Now we are looking at the Azure IoT Edge gateway as a translation gateway which will include Identity translation and protocol translation.

But there is no working example for these two. How will we configure these two to get it to work as we want?

There is a little bit of theory on protocol translation but no working example and complicated documentation.

There is only a little theory about what is identity translation but nothing on how to implement it or any working example. And does this gateway communicate two ways (Device to cloud and cloud to device)?

If anybody has implemented this and has simple documentation or a way to do so Please tell us.

We have also looked into the Azure IoT protocol gateway. But there was only a developer guide on GitHub which has a theory on how to do it. There was no mention of how to implement it, making TCP socket custom module in it, How will the device connect to this? Is there a need for some certificate or authentication from the device side so it can communicate to the Azure IoT Protocol gateway? And can it communicate two ways (Device to cloud and cloud to device)?

Please, anybody, provide a solution on how to implement this and tell us which way would be best and their working example and simple documentation.

azure-iot-hubazure-iot-edge
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

SandervandeVelde42 avatar image
1 Vote"
SandervandeVelde42 answered SandervandeVelde42 edited

Hello anonymous user-0212,

Does your (internet-connected?) device only take an Ip address and port? OR does it take a URL as well (which is more common).

In that case, think about setting up an HTTPS triggered Azure function as bridge (here is one for Azure IoT Central).

Setting up a local Edge device is possible once you solve that IP/Port/URL connectivity question.

I suggest getting in contact with the supplier or manufacturer and figure out, together with them, how the device this device.


· 6
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

The OBD-II device is from a Chinese manufacturer. This device takes APN, IP, and PORT only. Also, we want sometimes the cloud to send the data back to the device. As mentioned in the documentation HTTPS is not a good choice if we want bidirectional communication.

And the OBD-II strictly works on the TCP/IP communication protocol and sends hexadecimal (binary level) data to the server and it receives it in that format too. So this is not an option.

This is their protocol documentation: https://drive.google.com/file/d/1q235dNfz4Fy-XtwxfJW5BQww3BzrO8xC/view?usp=sharing

0 Votes 0 ·

Hello anonymous user-0212,

According to 3.4 in the documentation, several protocols are supported, including UDP.

If Azure IoT Edge is a possible solution, please check this Azure IoT Edge UDP Module example.


0 Votes 0 ·

Yes, it supports UDP communication protocol but as mentioned in the UDP module example you provided it has these issues

There are some disadvantages (it has no handshaking dialogues, and thus exposes the user’s program to any unreliability of the underlying network; there is no guarantee of delivery, ordering, or duplicate protection) but if you can cope with that at a higher level, UDP is a handy tool in your protocol toolbox.

As device data is our first priority we cannot lose it.



0 Votes 0 ·
Show more comments