[Development] Qt and IoT infographic

[Jason H]

> Sent: Tuesday, August 29, 2017 at 12:00 PM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: development at qt-project.org
> Subject: Re: [Development] Qt and IoT infographic
>
> On Tuesday, 29 August 2017 02:43:44 PDT Shawn Rutledge wrote:
> > And yet it has a web server for serving up either a human-readable page or
> > JSON on demand, and it also pushes data to a central server periodically.
> 
> Is that a static JSON? Because if you need to compose the data on the fly, you 
> may also want to replace JSON with something simpler. See 
> 	https://github.com/01org/tinycbor/
> 
> You'll find that the maintainer is familiar :-)
> 
> As for the part about "pushes data to a central server", I hope it's a server 
> on the local network, not on the Cloud.
> 
> > After
> > reading about CoAP I think it would be a much better fit than HTTP for such
> > a device, so I hope I find the time to try.  But then again, browsers don’t
> > have CoAP yet, so I wonder if there could be a web client that uses JS to
> > talk to it.  Having to build a dedicated Qt client for it would be a step
> > backwards in a way, but also nice for a desktop widget or some such.
> 
> Firefox has a CoAP addon.
> https://addons.mozilla.org/en-US/firefox/addon/copper-270430/
> 
> As for Chrome, I'll cat with Alexis and see what he thinks about the chances 
> of adding it by default to the browser.


I think the ideal tech solution here is not to do one or the other, rather both, in a layered approach. Use the HTTP/REST and provide a translation layer to CoAP. They make a statement about it being really close, so it shouldn't be that hard to proxy down/up to a full-on REST server?


> > Qt for IoT is maybe primarily for devices that have graphically-rich
> > screens.  But they can be clients reading data from truly-embedded sensors,
> > and they might also have data of their own to serve to other clients
> > (consolidated results, or just extra sensors that happen to be attached).
> 
> Good point on the data of their own.
> 
> I really do think we need to reevaluate our position that Qt is for clients 
> only. I'm not against the HTTP server stack. I'm just saying it's a much more 
> complex beast. And unlike the server that serves a single page, any Qt 
> solution that makes to API would need to be a lot more capable.
> 
> Otherwise, just lift the MiniHttpServer from the many unit tests.

I'm not saying re-write apache or node anything like that. (Although node libraries in QML would be great!) I'm only suggesting that we make Qt able to trivially provide data to the web in both a conceptually easy and easy to implement way.

No where could this be easier than with QML 
HttpServer {
port: 80

    // C++ QObject with Q_PROPERTIES: ["temperature", "cores", ...etc] automatically mapping Q_PROPERTY READ/WRITE methods as GET/POST respectively
    CpuSensor {
        id: cpu 
        onTemperatureChanged: { /*alarm if over 100, etc */ }
    }

    ObjectRequestMapper {
       url: '/cpu'
       object: cpu
    }

}
GET /cpu/temperature
GET /cpu/cores

As well as with a simple QObject tree

> > There are some PLCs powerful enough to run Linux, though, like these:
> > https://www.bachmann.info/en/products/controller-system/  Some industrial
> > applications can afford to use them, and so can the shipping industry, as I
> > learned a couple of years ago on a certain consulting gig… and so they can
> > afford to use Qt too, just for network comms, even though there is no GUI.
> 
> Intel has shown that Linux is a viable target at 2 MB of RAM. We can boot a 
> kernel at 1 MB, but then there's nothing left for your application. Shrinking 
> the kernel further is possible, but it depends on whether the upstream would 
> accept such changes -- for example, disabling TCP and leaving only UDP 
> enabled. The kernel network maintainers currently have the position that they 
> don't want this and you should just switch to a microcontroller RTOS at that 
> point.
> 
> For Qt, we have to make sure it runs comfortably at 128 MB and we should 
> strive to make it possible for 32 MB of RAM.
> 
> But the question is whether this is worth the effort. Are there devices that 
> have memory in this range? One anecdote I've heard is that you can't buy DRAM 
> at less than 512 MB -- since there's just not enough volume for them, their 
> prices went up, causing people to stop buying them, further causing the prices 
> to go up...

There is a pretty big gulf between MCUs and the IoT. 
Yeah, I've got Aurduino (even a uCSimm), various Pis and BeagleBoards, but with the Pi Zero at $5, it's the same price as an Arduino, and it runs Qt no problem. The calculus that has to be made is if IoT will be in quantities where costing < $5 but more than pennies will inhibit a market. I think IoT is not currently suffering from that as most IoT things I think of are luxury projects where a $5 CPU isn't cost prohibitive. Meanwhile, you've got the whole Moore's law thing going on. If it takes Qt 3 years to whittle down to fit on a board, or just quadruple the resources, then it's a wash. I don't see Qt reaching down much lower than a Raspberry Pi Zero. The future of IoT development isn't reaching down, its gluing things together with a minimal level of effort while prices on the more advanced stuff plummet and capabilities increase. There maybe a market for a lower-end CPUs reaching into the MCU space, but I just don't see Qt going there.