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.
"Device-to-smartphone" and "smartphone-to-device" technologies
Started by ●December 9, 2018
Reply by ●December 10, 20182018-12-10
On 10.12.2018 г. 00:49, pozz wrote:> 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.CPU power is abundant nowadays, so is connectivity. Just make your device look like say an RFB (aka VNC) server and use the smartphone/ tablet/PC simply as a terminal. We have been doing that for over a decade on our netMCA devices, long before the "IOT" word had been coined I think. ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●December 10, 20182018-12-10
Il 10/12/2018 11:04, Dimiter_Popoff ha scritto:> CPU power is abundant nowadays, so is connectivity. Just make your > device look like say an RFB (aka VNC) server and use the smartphone/ > tablet/PC simply as a terminal.When the device *is* a server, you need at least Dynamic DNS and port forwarding. Too bad for many users.> We have been doing that for over a decade on our netMCA devices, > long before the "IOT" word had been coined I think.
Reply by ●December 10, 20182018-12-10
On 10.12.2018 г. 12:33, pozz wrote:> Il 10/12/2018 11:04, Dimiter_Popoff ha scritto: >> CPU power is abundant nowadays, so is connectivity. Just make your >> device look like say an RFB (aka VNC) server and use the smartphone/ >> tablet/PC simply as a terminal. > > When the device *is* a server, you need at least Dynamic DNS and port > forwarding. Too bad for many users. > >> We have been doing that for over a decade on our netMCA devices, >> long before the "IOT" word had been coined I think. >If being a server is a problem make the device a client. realVNC can be started in "listening" mode, so the device connects to it, it can do that from behind a NAT router without a problem. This is how our netMCA series has been providing online customer support for over a decade now. ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●December 10, 20182018-12-10
Il 10/12/2018 13:09, Dimiter_Popoff ha scritto:> On 10.12.2018 г. 12:33, pozz wrote: >> Il 10/12/2018 11:04, Dimiter_Popoff ha scritto: >>> CPU power is abundant nowadays, so is connectivity. Just make your >>> device look like say an RFB (aka VNC) server and use the smartphone/ >>> tablet/PC simply as a terminal. >> >> When the device *is* a server, you need at least Dynamic DNS and port >> forwarding. Too bad for many users. >> >>> We have been doing that for over a decade on our netMCA devices, >>> long before the "IOT" word had been coined I think. >> > > If being a server is a problem make the device a client. > realVNC can be started in "listening" mode, so the device > connects to it, it can do that from behind a NAT router without > a problem. > This is how our netMCA series has been providing online > customer support for over a decade now.I'm not sure I got your point. Where does realVNC run in "listening mode"? On a smartphone?
Reply by ●December 10, 20182018-12-10
pozz <pozzugno@gmail.com> wrote:> 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.Do you actually want devices to communicate over the internet, or is same-network communication sufficient? For example, if the smartphone is on the same wifi network as the device, you just need discovery protocols so you can find suitable devices. Multicast DNS (aka Bonjour) is one such mechanism, but there are others. There are also things like QR codes, NFC and Bluetooth which can be used as bootstrapping (used to send an ID that's enough to identify the device on the network and go from there). If you do need internet connectivity (such as 'turn on my heating' when you're out of the house) then you need some kind of public endpoint. One thing you could look at is IPv6 tunnels, which allow your device to be accessible if it's behind IPv4 NAT. That solves the NAT issue (although you would need an endpoint to host the tunnel - third party solutions for that exist), and then you're back to discovery (where protocols like SIP allow negotiation of peer to peer connections). But you may decide you'd prefer to go via a central server if you don't want your device listening to the internet. Once you're wedded to the central server model, the thing you should worry about is resilience. It's a single point of failure that can affect all devices if something goes wrong - how will you handle that? Some cloud platforms will take care of hardware failure, but they're no help if your buggy code causes the database to become garbled or the certificate expires (cough, Ericsson), or one of a million different software things that could go wrong. What's the cost of all of your devices going down at the same time? I don't know if any ready made platform handles these things, although in theory they should exist. Next question: how much can you handle being locked in to that platform? Theo
Reply by ●December 10, 20182018-12-10
On 12/10/2018 15:51, pozz wrote:> Il 10/12/2018 13:09, Dimiter_Popoff ha scritto: >> On 10.12.2018 г. 12:33, pozz wrote: >>> Il 10/12/2018 11:04, Dimiter_Popoff ha scritto: >>>> CPU power is abundant nowadays, so is connectivity. Just make your >>>> device look like say an RFB (aka VNC) server and use the smartphone/ >>>> tablet/PC simply as a terminal. >>> >>> When the device *is* a server, you need at least Dynamic DNS and port >>> forwarding. Too bad for many users. >>> >>>> We have been doing that for over a decade on our netMCA devices, >>>> long before the "IOT" word had been coined I think. >>> >> >> If being a server is a problem make the device a client. >> realVNC can be started in "listening" mode, so the device >> connects to it, it can do that from behind a NAT router without >> a problem. >> This is how our netMCA series has been providing online >> customer support for over a decade now. > > I'm not sure I got your point. > > Where does realVNC run in "listening mode"? On a smartphone?The android version cannot do that indeed. So write your own viewer, RFB is simple enough, this is a huge advantage. Anything else you contemplate would take a lot more work for android or whatever. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●December 10, 20182018-12-10
søndag den 9. december 2018 kl. 23.49.12 UTC+1 skrev pozz:> 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.never tried it but, Blynk ?
Reply by ●December 10, 20182018-12-10
Il 10/12/2018 22:17, lasselangwadtchristensen@gmail.com ha scritto:> søndag den 9. december 2018 kl. 23.49.12 UTC+1 skrev pozz: >> 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. > > never tried it but, Blynk ? >It seems Arduino oriented... I will check better.
Reply by ●December 10, 20182018-12-10
Il 10/12/2018 15:34, Theo ha scritto: > pozz <pozzugno@gmail.com> wrote: >> 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. > > Do you actually want devices to communicate over the internet, or is > same-network communication sufficient? Over the Internet, of course. > For example, if the smartphone is on the same wifi network as the device, > you just need discovery protocols so you can find suitable devices. > Multicast DNS (aka Bonjour) is one such mechanism, but there are others. > There are also things like QR codes, NFC and Bluetooth which can be used as > bootstrapping (used to send an ID that's enough to identify the device on > the network and go from there). This is for smartphone-to-device direction. What about device-to-smartphone, for example when the smartphone is off? I think it's impossible without connecting to a Cloud service. > If you do need internet connectivity (such as 'turn on my heating' when > you're out of the house) then you need some kind of public endpoint. > > One thing you could look at is IPv6 tunnels, which allow your device to be > accessible if it's behind IPv4 NAT. That solves the NAT issue (although you > would need an endpoint to host the tunnel - third party solutions for that > exist), and then you're back to discovery (where protocols like SIP allow > negotiation of peer to peer connections). But you may decide you'd prefer > to go via a central server if you don't want your device listening to the > internet. > > Once you're wedded to the central server model, the thing you should worry > about is resilience. It's a single point of failure that can affect all > devices if something goes wrong - how will you handle that? Some cloud > platforms will take care of hardware failure, but they're no help if your > buggy code causes the database to become garbled or the certificate expires > (cough, Ericsson), or one of a million different software things that could > go wrong. What's the cost of all of your devices going down at the same > time? > > I don't know if any ready made platform handles these things, although in > theory they should exist. Next question: how much can you handle being > locked in to that platform? More questions than answers
