Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28432
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: "Device-to-smartphone" and "smartphone-to-device" technologies |
| Date | 2018-12-10 23:05 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <c210775a-55e6-835d-a475-a48d9d3536ed@gmail.com> (permalink) |
| References | <puk654$21p$1@dont-email.me> <507da611-51e8-472e-b561-ac50e732b19b@googlegroups.com> |
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.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
"Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-09 23:49 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 12:04 +0200
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 11:33 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 14:09 +0200
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 14:51 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-10 22:50 +0200
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 14:27 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-11 16:50 +0200
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 23:34 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Dimiter_Popoff <dp@tgi-sci.com> - 2018-12-12 02:26 +0200
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Theo <theom+news@chiark.greenend.org.uk> - 2018-12-10 14:34 +0000
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 23:05 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Theo <theom+news@chiark.greenend.org.uk> - 2018-12-11 11:58 +0000
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-11 14:36 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies lasselangwadtchristensen@gmail.com - 2018-12-10 13:17 -0800
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-10 23:05 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Robert Wessel <robertwessel2@yahoo.com> - 2018-12-10 20:18 -0600
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-12-12 08:34 +0200
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-13 13:51 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-13 10:09 -0800
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 18:59 +0000
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2018-12-13 11:17 -0800
[OT] Gopher Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2018-12-13 21:00 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 20:37 +0000
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Clifford Heath <no.spam@please.net> - 2018-12-14 08:12 +1100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-13 21:46 +0000
Re: "Device-to-smartphone" and "smartphone-to-device" technologies pozz <pozzugno@gmail.com> - 2018-12-14 09:17 +0100
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Grant Edwards <invalid@invalid.invalid> - 2018-12-14 15:18 +0000
Re: "Device-to-smartphone" and "smartphone-to-device" technologies Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2018-12-15 18:20 +0200
csiph-web