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

Groups > comp.arch.embedded > #28439

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

Show all headers | View raw

Il 11/12/2018 12:58, Theo ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> Over the Internet, of course.
> 
> OK - that wasn't immediately clear from your question.
> 
>> 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.
> 
> The device could store messages ready for the next time the phone is
> connected.  There's not much you can do until the phone is turned on.

Sorry, I mean when the smartphone is in standby (display is off while 
your are watching TV). Even if the device and the smartphone share the 
same home network, how to reach the smartphone to alert for some event?


>> More questions than answers
> 
> I think this is actually a lot harder than people think.

I know, this is the reason of my post.


> Big question: what's the expected longevity of your system?
> 
> A lot of the IoT stuff is aimed at essentially disposable consumer devices -
> after somewhere between 1 and 5 years they stop working.  If you want to
> make your system still work after 5/10/20/30 years there are some big
> challenges:
> 
> - will your node software be upgradeable, and how will you manage that?
> 
> - if your nodes aren't upgradeable, can you backend cope with all the
> different versions of shipped firmware?  If they are, this issue won't
> entirely go away (at some point, you reach the limits of a particular
> hardware platform and further upgrades are infeasible)
> 
> - how will you test over all the models that might have been shipped?
> 
> - over time, communication protocols will change (eg SSL 2, SSL 3, TLS 1.0 /
> 1.1 / 1.2 / 1.3).  How will you handle that?  What should we do about a
> product that's speaking what's now regarded as insecure SSL 2?
> 
> - a lot of IoT players are quite small.  There's a substantial chance that
> any platform you pick goes out of business, gets bought out by someone who
> isn't interested, 'pivots' to something else, or jacks up the price to
> infeasible levels.
> 
> - running things yourself will insulate from changes at a third-party
> platform.  But can you commit yourself to running the system in 5/10/20
> years?
> 
> - what is the revenue stream that will keep the lights on?
> Funding everything from an upfront purchase price tends not to work.
> 
> 
> On smartphone it's even harder.  iOS is dropping support for 32 bit apps.
> So any app that hasn't been updateed in the last 5 years isn't going to work
> any more.  Can you commit to keeping your software up to date (even if it's
> no longer a shipping product)?

All those are good questions... from a technical point of view. However 
we are on the market and we need to sell products. Do you think the end 
customer asks so many questions when he is purchasing IoT gadgets on 
Amazon? I don't think. So here the main question is how to satisfy the 
stupid requirements of modern customers: playing with his smartphone 
*today* in couple of minutes. He isn't interested (and he will not be 
able to understand) if the gadget will work for 1 or 5 years.


> One option is to rely on simple technologies that are sufficiently baked in
> to society that they aren't going away any time soon - for example voice
> calls and SMS.  That fixes the smartphone end, but not the platform end
> (still a need to provide an SMS gateway)

You will not sell any product with those technologies, even if they are 
more robust and should have a longer life.


> If this is not a product, but merely a means to an end (eg you have a
> project for 6 months and don't care what happens after that) then a lot of
> these headaches go away.
> 
> IFTTT is a possible option, although I have no experience of it.

If I'm not wrong, IFTTT needs an already working cloud server. It talks 
to servers, not real devices behind a NAT.

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