Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #28432

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

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>

Show all headers | View raw


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


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