Nowadays the poor embedded developer faces new challenges that go outside the limited world of C/C++ program on a resource constrained hardware. Now the hardware isn't so resource constrained (Raspberry and many other embedded Linux boards or SOM are just examples) on one side. And the device isn't isolated anymore, it is usually connected (directly or indirectly to Internet).
The Thing/device connected to Internet (IoT) is now a reality on all embedded hardware. With ESP chips you can have a WiFi connection for a couple of dollars. With many Cortex M3 you can have a wired 10/100Mbps Ethernet connection. lwip is the piece of software to have a working TCP/IP stack on those hw. Now we are at the application high-level layer.
Yesterday a typical request for an Internet-oriented device was HTTP server (I designed such a system one year ago).
Today the request is different. The end-user, at least in most consumer applications, doesn't want to spend time for DDNS and port forwarding. Moreover he wants to use his smartphone and not a typical desktop PC.
So now we have typical appliances that can be managed by a smartphone. You can configure the washing machine through your mobile phone and you can be notified when the clothes are ready.
This is a typical request for an embedded Internet-connected device. It should communicated with a registered smartphone. The main question of this post is: what are the technologies that allow a device to communicated with a smartphone?
I understood this problem can be divided in two completely different challenges. The first is "device to smartphone" direction, with its solutions. The second is "smartphone to device" direction, with other solutions.
Regarding device-to-smartphone, I think the best solution is "push notifications". The push notification technology allows to reach whatever mobile phone in every situation, even if our app isn't running (I understood Android apps can be started automatically at startup, but iOS apps can't be started automatically at startup... so a push notification is the only solution). This technology allows to reduce traffic so increasing battery duration.
How to create a push notifications from an embedded device? I understood we need to register (and pay for) a notification service, for example Google Firebase Cloud Messaging (FCM). A notification can be sent with an HTTPs request to a server, so we need an HTTP client and the full TCP/IP plus TLS stack. Of course we need a custom app running on the mobile phone: without a custom app, the notification can't reach the smartphone. This is a big issue, because apps and embedded fw are two completely different monsters that need different technical skills.
The smartphone-to-device direction is more critical, at least for me. The app running on the smartphone can't reach directly our device, that is usually behind a router and configured with a private IP address. The key technlogy is the "cloud", a public server that accepts requests from the smartphone and connections from devices on the field. The cloud server is able to link the smartphone request to a connected device. Here the high-level view block diagram is clear, but I can't go down to the next level of details.
Which protocol do use the smartphone during communcation with the server? Maybe HTTP(s). Which protocol do use the device during communication with the server? I think we have many solutions: MQTT, HTTP(s) and so on. What are the software to use in the server? I don't know.
As a developer, I can think to rent a physical server (the infrastructer) from service providers and: install an OS (maybe a Linux variant), install a HTTP server (for smartphone requests), write and run server-side scripts to process smartphone requests, install a custom software that communicated with the embedded devices. Wait wait, but I don't have the skills to create and maintain a serious, reliable and secure server that is reachable in Internet. Does it mean we need another guy in our team?
Another possibility is to rent (and pay for) a cloud service that let the smartphone to "chat" with the device. MQTT broker? PubNub? Amazon Web Services (AWS)? I don't know.
I also read about serverless solutions where you wrote the program and "launch it in Internet", without knowing the server where it really runs (you usually pay for processing time). In this case I needn't to have good skills to create and maintain a real server.
I'd like to know if you received those type of challenges in your daily embedded work and how did you try to solve them.