Accessing IoT device from remote server using IP address

Question

Is it possible to access an IoT device (which may be a HTTP REST Client or MQTT client) from remote web server over Internet and send text to that particular device (instead of broadcasting message over topic as in the case of MQTT) using the IP address of device? This article describe that IoT devices have IP address (private IPs assigned by router to IoT devices). In such case how the devices can be seen from a web server?

Note: 1-3 devices will be on a home network behind a router and consumers will not be technically capable of setting things like port forwarding up.

Answer 1

So the short answer to your question is No, you can not make a HTTP request to the device you have described.

The reason is that in order to reach the device directly the client (Your central cloud app would be a HTTP client at this point) needs to know the following things:

1. A publicly routed IP address for the device
2. A fixed port for the device

In the case you have described you have neither. You don't have a publicly routable IP address because the device has private (RFC 1918) IP address that can not be routed to. If you set up port forwarding on the router for this device you could then use the external IP address of the router, but since most home broadband providers do not supply fixed IPv4 addresses this address will not be static, and is subject to change when ever the router restarts. You could have the devices report in every time they regain network access after a router reboot to let the central service know the IP address, but that means keeping a real time list of device locations.

You can't use normal port forwarding for 2 reasons:

1. You state that you can not depend on your users being tech savy enough actually enable it
2. How do you deal with multiple devices? You would need a separate port for each device and you need to let each device know what port they were bound to so when they report in to the central service they could include the port. But this means not only would the user have to set up the port forwarding, they would have to configure each device with port information.

There is a solution that allows the devices to set up their own port forwarding called UPnP (Universal Plug and Play) but this requires that the router supports this functionality and it is largely considered to be a security vulnerability and most people are recommended to disable it.

All of the above is why protocols like MQTT are the defacto standard for IoT devices. Because the device connects out to the MQTT broker and then keeps that connection open indefinitely it avoids all the problems I have outlined.

The outbound connection means that there is no need to keep a list of device connection details, no need to set up any port forwarding, no limit on the number of devices behind each NAT router, no need to worry if the public IP address of the router changes.

Each device subscribes to a topic specific to its self (e.g. based on the device serial number) and as such can receive messages directed specifically for that device, it can also subscribe to more general topics allowing for broadcast type messaging.

Answer 2

If your device runs a Linux distro (like a Raspberry Pi), you can set up a reverse SSH tunnel, so you can access your device even if it's behind a router.

The thing here is that your device has to start the connection, opening a tunnel to a server. Then you can connect to the device through the server. So you could send a message to the device (thorough MQTT or HTTP) indicating that it should open the reverse tunnel.

If you're using a microcontroller (Arduino, ESP8266, etc), you have to manually broadcast the messages you want, no other option.

Answer 3

I'm curious why you want to use HTTP instead of MQTT? One of the design goals of MQTT is bi-directional communication.

By using MQTT, you could have a unique topic per device, that only the device itself is authorized to subscribe to. Then the cloud service can publish a message to the device-specific topic to send a message to that device.