Did you Google "IoT Web Server"? You should know that it's an oxymoron for the following reasons:
In this tutorial, we will guide you through using a ready-to-run example that includes a web user interface that's both locally accessible through an embedded web server and externally available via a proxy portal. This approach ensures that users can access the interface locally and externally without opening a pinhole in the router/firewall. By leveraging a single user interface for the local web server and the portal, we facilitate the same user experience and significantly reduce development time and costs.
Increase your customer's confidence in your product by providing a dual embedded web server and IoT solution that assures your product never ends up as explained in the EE Journal article RIP, Cloud-Connected Devices.
Embedded Web Servers have been used for device management long before IoT was coined, and it is still very popular due to its simplicity. Take your home router as an example, providing a web interface for all the router settings.
The benefit of using an Embedded Web Server is that it does not rely on any third-party products that may fail, thus making it more reliable and always available on the local network where the device is deployed.
The negative with an Embedded Web Server powered device is that it is not easy to control the device outside of the local network where the device is deployed. Technically challenging solutions such as setting up a pinhole (port forwarding) in the router are possible, but it is not ideal solution.
IoT has many benefits, such as being able to manage and supervise multiple devices in multiple locations. With IoT, the devices typically act as network clients and connect to an online IoT cloud server. A user does not directly control a device, but must first navigate to the cloud solution to get access to the device(s).
What is an IoT device?
An IoT device is simply a network-enabled client that sends and/or receives data from an online cloud server. The data transmitted can be anything, including sensor data and control messages. IoT device protocols include HTTP, MQTT, WebSockets, SMQ, OPC-UA and so on.
The negative with an IoT solution is for devices that are more often controlled from the local network where they are deployed. The IoT round-trip slows down communication, making some real-time applications too slow. Should the IoT cloud server or its network infrastructure go down, the devices become impossible to control.
Reaping the benefits of both solutions and eliminating the negatives is to design a device that can both provide a local web interface via an embedded web server and be controlled via an IoT cloud server. However, doing so has traditionally incurred extra complexity and development time.
Is it possible to provide both solutions and re-use the device management application for both solutions?
Yes it is possible, but doing so requires rethinking the traditional way of designing web-based device management applications. Instead of using the standard HTTP GET/POST for performing the actual commands, a persistent WebSocket connection is used. For this to work, the HTML application must be designed as what is known as a Single Page Application (SPA).
See the end of this article for how to provide a similar solution for standard HTTP servers.
To show that it is indeed possible to re-use a SPA for both local management directly via an embedded web server and remotely via IoT, we created an online testing server you may use. The testing server is available at the following URL:
IoT Testing Server: https://minnow.realtimelogic.com/
The simulated device code can be downloaded to your computer and compiled as follows:
The above commands download the Minnow Server (WebSocket server) from GitHub and compile the Minnow Server reference example in IoT mode by the make command IOT=true.
The above commands require that you have git make gcc zip, and curl installed on your host computer. You may install the required tools as follows:
Windows users: If you are using Windows, use the Windows Linux subsystem.
When the Minnow Server runs, the server connects to the online IoT server after 3 seconds if the Minnow Server is not controlled locally.
When the Minnow Server runs, use your browser and navigate to http://localhost:#, where # is the port number the server is listening on. You may then control the device using a local connection. The default credentials are user "root" and password "password".
You may also control the device using the online server, but make sure to close the local connection first. After closing the connection, the server will connect to the online IoT server after 3 seconds. You may then click the link presented on the online IoT server. Click this link and log in.
See the article Creating Single-Page Apps with the Minnow Server for details on how the reference example works.
This example focuses on devices with extreme memory limitations since only one network connection is used for the cloud server connection and the local WebSocket server connection service. Note that the example can only be used by one human operator at a time. We recommend using the Barracuda App Server for systems with more memory. You may also download the ready-to-use Barracuda App Server's WebSocket C source code example from GitHub.
What if you do not want to limit your design to only WebSockets, but also want to use standard HTTP, including all standard services provided via HTTP? This is possible, but it gets more complicated and is best solved by a product designed specifically for this purpose.
The Barracuda App Server includes a reverse HTTP(S) connection bridge designed for a free product called SharkTrustX. The Barracuda App Server, when embedded in a product, runs on the local (LAN) network, and SharkTrustX runs as an online connection bridge portal.
See the IoT & HTTPS Behind Firewall Product SharkTrustX for details.