Forums

"Device-to-smartphone" and "smartphone-to-device" technologies

Started by pozz December 9, 2018
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.
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/
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.
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/
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?
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
On 12/10/2018 15:51, pozz wrote:
> Il 10/12/2018 13:09, Dimiter_Popoff ha scritto: >> On 10.12.2018 &#1075;. 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/
s&oslash;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 ?
Il 10/12/2018 22:17, lasselangwadtchristensen@gmail.com ha scritto:
> s&oslash;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.
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