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

Groups > comp.arch.embedded > #28417

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

From Dimiter_Popoff <dp@tgi-sci.com>
Newsgroups comp.arch.embedded
Subject Re: "Device-to-smartphone" and "smartphone-to-device" technologies
Date 2018-12-10 12:04 +0200
Organization TGI
Message-ID <puldo8$i64$1@dont-email.me> (permalink)
References <puk654$21p$1@dont-email.me>

Show all headers | View raw

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/

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