I'm a fulltime IoT software consultant, and I wish we'd see more of these initiatives. A few thoughts:
1. The problem isn't the transport layer, it's the application layer. The transport layer is mostly solved via MQTT, COAP, Thread, etc. Sure, we can improve there, but the real problem is the application layer. So I applaud Mozilla's attempt to bring something into this space.
2. Bootstrapping this will require a substantial number of hardware vendors to sign on, both at the edge and at the hub layers. IMHO this is why Google Weave [1] never took off in it's original incarnation. Bootstrapping this like they did with web stuff isn't enough, because this isn't the web.
3. Devices are only part of the problem: We need a software services layer, too. Think time services, IFTTT-like orchestrators, media services, etc.
4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse.
5. Request-Response isn't the right pattern for most use cases.
6. The Property/Action/Event concept is a solid start.
7. For the love of everything holy, add versioning!
You (and a lot of others) forgot the most important need -- security. It seems almost every iot device out there is easily hacked.
Maybe a web implementation with all it's built in protections really is the most pragmatic solution even if it isn't light weight.
I think a safe language like SML/ocaml, erlang, or rust (each with various performance/productivity tradeoffs) is a better solution if we can get a secure framework on top.
MQTT and CoAP both support TLS. With TLS 1.2 you've got elliptic ciphers which puts it in reach of small embedded devices. So TLS with server certificates are enough to ensure confidentiality and server authenticity.
Client certificates can cover the client auth side although there are gotchas:
(1) dealing with revocation is more difficult as devices can more easily become compromised (physical access = extracting keys from flash/RAM.)
(2) assume a vendor issues a unique client cert on every device, and the chain reaches a CA. For multi-tenant cloud vendors, you still need to figure out which e.g. Philips Hue bulb is Bob's when Bob logs into his cloud portal. So there's a pairing issue that usually requires a one-time-pad or similar. Right now everyone does that differently.
Agreed, that goes to my comment about transportation vs. application layer. Transport security is just one small part of IoT security, of course. It is not a solved problem, but there are a lot of best practices that just aren't addressed most of the time.
To put it another way: Mozilla proposal needs to work with _multiple_ security models. They won't get there overnight.
Just a note on IoT: Yes, it's messy, yes it's early, but I really love working in the space full time. It spans every part of computer science and it's never dull. I get to work with Fortune 100s and startups, and it's really a fun place to play.
Here's a quick bread-first overview some of our recent projects:
* Industrial IoT - If I had to guess, most of the projects are 95% analytics, 5% command and control (i.e., configure machines and/or centrally control them) - PLCs make this suck, but as that moves to SBCs we're seeing that improve. Energy management, too. Get a lot of questions about Industry 4.0, too.
* Transportation - Mostly telematics (GPS, listening off the CAN Bus for events, etc.)
* Healthcare - RTLS, some basic analytics. C&C is unlikely due to security and use cases.
* Retail - Restock tracking, footfall traffic, etc. Ordering by voice. ("Alexa, I'd like to order 5 cases of carrots")
* Consumer IoT - Voice, energy management (Europe has some great use cases here), some analytics. C&C is big in this this space. "Alexa, set my Jenn-Air oven to 350 degrees for 25 minutes" was a recent project.
* Insurance - The 5 five all have innovation groups very intent on IoT, but I haven't see a really great use case yet.
One last thought: I've noticed is that IoT really screws with the traditional "Enterprise Architecture" patterns. Startups are going to kill it once they figure that out, because traditional enterprise architects are lost in that space.
Hi! I'm intrigued by your statement about SBCs. Do you have a link to learn more about them?
I've seen someone have intimate contact with Beckhoff PLCs and the upgrade story isn't great, plus using git with it tends to be painful, and writing modular code seems so too. It would be great to learn about an alternative that's more hackable.
The biggest issues IoT companies have is what to do with all the data. Without someone finding value in the data you'll be unable to justify the costs.
Data Science & Data Engineering don't require an EE background
The company I currently contract for (not my own) has some of these right. The hard part, of course, is getting everyone to sign to a standard. Sometimes they're good, sometimes they're bad, i.e., IoTivity, which is a steaming pile of shit. It will be interesting to see if this takes off, because it could knock a few companies on their asses.
> ASN.1 is similar in purpose and use to protocol buffers and Apache Thrift, which are also interface description languages for cross-platform data serialization. Like those languages, it has a schema (in ASN.1, called a "module"), and a set of encodings, typically type-length-value encodings. However, ASN.1, defined in 1984, predates them by many years. It also includes a wider variety of basic data types, some of which are obsolete, and has more options for extensibility. A single ASN.1 message can include data from multiple modules defined in multiple standards, even standards defined years apart.
ASN.1 has one of the same problems of XML - the data format is far too strict. Many libraries work by generating new structs/classes from the specification, which is a real problem for an agile workflow. The "struct" type also allows keys of the same name, which means you can't properly represent it in a Json/hashmap/dictionary type. (Not to mention that ASN.1 is just the specification language, there are more then ten ways to actually encode it on the wire. And from personal experience it can also be a pain to work with.)
There are plenty of more modern binary formats that would be a good alternative. CBOR, MessagePack, Protobufs, etc.
In theory it’s nice, but the core cap’n’proto library is too large for many embedded devices. It seems to be full of dynamic features making it difficult to pair down.
Have you tried using link-time garbage collection? The library is designed in a layered way, such that the core serialization does not depend on the "dynamic" features, so if you don't ever call "dynamic" features then link-time GC should be able to drop a huge chunk of the lib.
There's also "lite mode", which #ifdef's out all the dynamic stuff:
./configure --disable-reflection
Although it isn't as aggressive as it could be. We should fix that. I filed an issue:
No I didn’t but that’s good to know. I tried a few attempts but wasn’t sure about how integral the reflection portions were (or if exceptions were crucial). I’d likely just compiled the library on my dev machine and looked at the library size and tried a few flags to get a quick idea if it’d work.
It’d be useful to be able to just use the serialization protocol. Currently I’m using MsgPack which works decently well to get data from embedded cores but I’d prefer typed structures. Thanks for the feedback!
Although KJ style prefers exceptions, the library is carefully written (and tested) to work with -fno-exceptions. KJ_ASSERT/KJ_REQUIRE invocations (which normally throw exceptions) can define a fallback path to use in the case that exceptions are disabled, usually involving returning some sort of dummy value. You can also register a per-thread exception callback which will be called on all exceptions before the fallback starts (or before aborting, if there is no fallback).
Asn.1 is great, and I see a lot of folks relearning the hard-earned lessons of it. The only problem is that there are no good open source implementations.
> ASN1SCC is an ASN.1 compiler that was developed for ESA to cover all data modelling needs of space applications.
> The compiler is targeting safe systems and generate either Spark/Ada or C code. Runtime library is minimalistic and open-source. The tool handles custom binary encoding layouts, is fully customizable through a code templating engine, generates ICDs and automatic test cases.
> This repository contains the complete source code and tests of the ASN1SCC compiler ; an ASN.1 compiler that targets C and Ada, while placing specific emphasis on embedded systems: no black-box run-time library, portable code able to run under any OS (embedded or otherwise), no dynamic memory used anywhere, etc.
People who dismiss this effort so quickly should actually spend a little time to discover what is actually happening here. It is really disheartening to see so many negative comments about Mozilla without any substantial deeper comments about this specific project.
To me the big news here is not the gateway, it is the "Web Thing API" that you can read at https://iot.mozilla.org/wot/
This is a W3C draft about something that is badly missing currently: a common language that devices can speak.
"This document describes a common data model and API for the Web of Things. The Web Thing Description provides a vocabulary for describing physical devices connected to the World Wide Web in a machine readable format with a default JSON encoding. The Web Thing REST API and Web Thing WebSocket API allow a web client to access the properties of devices, request the execution of actions and subscribe to events representing a change in state. "
This is meaningful work that can impact you in a big way. Don't dismiss it too quickly.
Trying not to dismiss it, but IoT is, frankly, a total mess. Consider that:
- It's mostly done by companies that use hardware as a delivery platform for their cloud services, trying to vendor-lock you, in delusion that they'll be The Next Platform. This results in an extremely user-hostile ecosystems.
- Said companies develop IoT devices with little or no regard to security and protection of user data.
- The business strategy of tying everything into my butt means things are not interoperable by design. I don't see much incentive for IoT vendors to accept standard protocols that go against the core of their business.
- Now W3C wants to tie IoT into the web. The web is a total clusterfuck. JavaScript is not a language suited for this task, and its ecosystem is doubly not suited to working on this.
Maybe I'm just grumpy, old (by web standards; I'll be 30 this year) programmer who desperately tries to turn an unstoppable tide. One who believes IoT should stand for Intranet of Things. I can believe this is "work that can impact me in a big way". I'm not convinced this impact will be in any way positive.
> JavaScript is not a language suited for this task
I think the name of this technology may be leading to some confusion here. From a quick read-through of the API description (https://iot.mozilla.org/wot/), it doesn't seem to have anything to do with JavaScript except that there is a small amount of example code showing how to open a WebSocket. (But you can open a WebSocket from other languages, of course.)
This whole technology seems to center around using RESTful HTTP and WebSocket to discover and manipulate IoT devices. It doesn't seem to have anything to do with using a browser as the client. A more-accurate name might be "HTTP/WebSocket of Things", but that's a mouthful.
At any rate, the API document just describes using GET/PUT/POST and so on to do things like discover actions, read sensors, and actuate things.
If it doesn't have anything to do with browser as client then why would they choose a hobbled protocol like http or websockets? MQTT, AMQP are already standards for this and much better suited for nearly any task. They are more powerful, more efficient and simpler to use than http or websockets. And if you can't get past the firewall or proxy both of them will run over websockets anyway.
Isn't that the point of this? We've got AWS IoT, Artik, Xively, Google Cloud IoT.. I've looked at a few and they basically all do the same thing in a slightly different, incompatible way. If we get something that enough people agree is "the standard" then maybe you can define a single device schema and connect to any of those services interchangeably.
> I don't see much incentive for IoT vendors to accept standard protocols
But we see already this is not the case. Cloud providers give MySQL/ Postgres compatible storage, Docker deployments... Consider that customers are already faced with "do I want to tie my product to this cloud backend" when it could be "oh good Artik supports the ""IoT standard"" let's go." There's still tons of incentive to stick with one platform.
> Now W3C wants to tie IoT into the web. ... JavaScript is not a language suited for this task
Not sure what you mean about JavaScript, they use JSON to represent the schema, and WebSockets as the transport but presumably you could use a websocket library written in any language.
Personally I did hope to see MQTT bindings and/or weight thrown behind CoAP but maybe those will come along later.
I agree the Web is messed up today thanks to big tech doing whatever they feel to defend their empires. But they will overstep (enough examples from the past) and when they do it creates the right kind of pressure for alternatives. Don't have any delusions that the web standards you know today, just fell into place cause some old altruistic wise men sat together out of joblessness and came up with things that were good for the world. Things don't work like that. Good people don't come together to do jack until they are highly frustrated and under pressure.
I really agree that Mozilla/W3C can attempt to make a standard, but I highly doubt we'll see Google/Apple/MS devices support it.
It'd be nice if there was one standard, and you could buy devices that use your local server or phone home (but not both), but for all the reasons you stated, I don't see that happening. The average consumer just don't care enough.
When I first read the grandparent post, I thought it was a deliberate choice of words to denigrate "the cloud" but the fact that it's the accidental result of an overzealous browser extension in a thread talking about dysfunctional technologies makes this incredibly funny.
IoT is a total overkill, whether it's inter- or intranet of things. There are devices that are useful to connect to a local network, e.g. a printer/scanner, a security cam, but almost all other home devices are fine (actually better off) when they are dumb tools that work when you press the correct button.
The web is better of if we can somehow shake it off a bit, removing all the cruft we've accumulated and stopping making shit websites---and stop wars and cure hunger worldwide while at it, I know what I'm saying is pipe dreams. I'd be glad if Mozilla wouldn't implement this, and was a bit more opinionated in general. It sometimes stinks of yet another SV startup but in disguise of freedom fighters. I'm looking forward to nEXT browser, where at least I can presumably stop WebKit from doing silly things via some lisp here and there (I'll reach the good times where I run Emacs and nEXT on GuixSD, turtles all the way down!).
There is a big need for open API for internet of things. Currently, each company has proprietary protocol for talking to their gateways or service. Which means need to have separate app. Can integrate with IFTTT, Google Home, or Alexa, but those need integrations for each service.
Open API would allow the open source home automation systems like Home Assistant to have integrate with the services. Or make easier for Google Home and Alexa to control the open source systems. Or apps that control devices and gateways from different companies.
It takes more than two decades for browser implementers to recognize the need to follow specs as much as possible. The only way to replicate that without the two-decade mistake again would be a compelling toolsets available. Docker got people interested in containers, so Docker has the influence in driving the standard, although I am not really sure how many implementers will participate and willing to bend.
In general, the dominant one has to be willing to let go of its "pride" so others will "follow" to beat the dominant one. Otherwise everyone will be busy beating everyone and forget about consumers (which includes developers).
Make the standard open, make it work, build a high quality reference implementation and market the hell out of it.
As far as I can tell Mozilla is one of the only institutions with the resources and incentive to do all of this. I'm not altogether convinced they won't fuck it up though - the way they handled firefox OS was not encouraging. They might spend all of their time stroking their beards and deliberating over where to put the comma in their specs rather than getting their hands dirty with no-brand Chinese hardware manufacturers and figuring out all of the subtle problems that can arise building a network of devices and the not so obvious use cases.
If I were running mozilla I'd put the office for this venture in Shenzhen and make sure that the employees visit often and work closely with OEMs because if you keep these people away from actual manufacturers then the result is going to be pretty poor.
So, I just searched for "security" in that page you linked to and... not a single mention.
As I see it the problem with IoT isn't features, it's the absolutely abysmal security record. I mean, it's abysmal in home ADSL routers, what are expecting of companies just churning out one-off IoT things?
Maybe they should start out by mandating an update policy[1]? ... but then of course nobody would join, so what to do...?
[1] I'm not talking about a concrete schedule, just a documented human-readable policy of what their usual schedule would be (if any), and how severity levels work (for them), etc.
-------------------------------------
EDIT: HN won't let me post again "too soon", so here's my reply to "st3fan":
> Ok, what does this actually mandate and how many actual devices adhere to this standard? What is the motivation for any particular device manufacturer to adhere to this "standard"? (etc. I'm sure you can come up with your own questions.) Also, shouldn't this other standard at least be mentioned in the IoT standard and match the key word "security"? This whole IoT thing is an omnishambles.
You may be right, but you’ve said nothing to support your position.
Most of HN mistakenly assumes IoT == putting cameras and microphones on televisions with no security (eg, super stoopidity), when in fact IoT is a powerful way for businesses to monitor/diagnose/control remote devices (like jet engines, vending machines, stop lights,...)
But I don’t see what Mozilla has to do with that, nor why we need some kind of “gateway” or json spec when it’s just yet another internet device.
Yeah, that's when things work well. But soon someone finds a use-after-free in that code et voilà now he has full control[1] over the engine.
[1] OK, maybe not full control over the engine because that's not how it works, but it has full control over the embedded monitoring system, which is still pretty bad.
IoT means different devices connecting to internet and/or each other. A jet engine is part of a closed system, there is no need to use a standard protocol to communicate to it. You don't just pick one and plug into a multi-million-dollar plane. Vending machines need no special protocols to connect to other things, because why would they? And stop lights. These things may connect to some server or maybe each other, but no standard protocol is needed, if a traffic light isn't supposed to talk to a random device passing by (and it isn't supposed to).
Stop lights might want to have some 1-n beacon protocol available for automated cars, and vending machines likewise might want a way to expose what's currently in stock and allow sufficient verbs to pay by a phone app.
These don't necessarily need to be the same system, only one might need interactivity, but there's certainly a case to be made that both devices could reasonably want to communicate with passers-by.
The traffic lights communicating with vehicles automated or not is sinister. That would get attacked ASAP, DoS or otherwise, and crashes would happen. A vending machine provides a keyboard interface for making selections. You can integrate NFC to it and require the payment in between the selection and dispensing. Allowing automated connections to public devices is not a useful idea.
Right so, we agree, special protocols and json specs for "IoT" don't make any sense, since the last thing we need in our home is every product we buy transmitting on the internet.
A gateway to block all those devices, that could be useful.
> It is really disheartening to see so many negative comments about Mozilla without any substantial deeper comments about this specific project.
Mozilla has a) no track record of doing small embedded systems b) a very negative track record of failed projects, so it very much makes sense to be very skeptical.
A lot of engineers from FxOS ended up in a group called "Connected Devices" with a new VP, but the goal was never to adapt the phone OS to IoT (the goal was to kill the phone OS).
A couple of members of the small team (5 people) who built this gateway were indeed former FxOS/CD staff.
Persona was the best side project they could have ever picked, sth. that the internet community needed as an alternative to Google etc. logins or maybe proprietary username/password/2fa for each and every side, but they dropped it and later bought Pocket and made funny privacy scandals. Sad.
Well not actual privacy scandals, but shocking practices that some of the community took so. The most recent was an easter-egg extension covertly installed in about everybody's browsers, and there was a partnering I read of with a German web company. Then also there's the case with Pocket where it was (and if I'm not mmistaken still is) installed by default, even before Mozilla acquired the company.
That surely was a fuckup. Lessons learned can be read here[0].
> ...and there was a partnering I read of with a German web company.
Think of it as a default search engine that's applied to 1% of new German installs. Other 99% remained on the Google(Yahoo) deal(s) (which apply to Germany). My opinion is that it was blown way out of proportions. That company also purchased Ghostery, Mozilla invested some money in it[1] before they did this, and is also making its own private browser (Cliqz).
> Then also there's the case with Pocket where it was (and if I'm not mmistaken still is) installed by default.
Pocket started as a Firefox extension in 2007, raised 7.5 million of investments in 2011 and 2012, got bundled with Firefox by default in 2015, and then the whole startup became a subsidiary of the Mozilla Corporation in 2017.
The Pocket button itself never did anything unless you click it. Extensions are now open sourced[2], apps are on their way (I think, I thought their code was online already), and I don't know about the server code. I am not familiar with what happened with the data between 2015 and 2017, but I presume that the data didn't get shared outside modern-day Mozilla Corporation (to confirm that, one would need to chase down Pocket's previous Terms of Service).
DISCLAIMER: Affiliated with the Mozilla Foundation, not the Corporation (therefore, not affiliated with Pocket nor Firefox, other than being a happy user of both).
For reference, that company "CliqZ" is majority owned by a German ad, tracking, and publishing company, Burda.
Burda is mostly known for its tabloids (e.g. the clickbait magazine Focus that loves spreading conspiracy theories) and for its malware-serving ad and tracking networks.
That’s the company that Mozilla, by default, sent the autocomplete data of 1% of German users to.
I take it you mean that as a rebuttal, because Thunderbird is still being released? At first I thought you were just offering another example of something cancelled, and I was pretty sure (but not positive) Thunderbird was still around. It is.
Can't this already be accomplished via XMPP? The protocol already exists, you just need to register devices to services. I know people don't love xmpp, but it seems like this is already an open source gateway that can manage IOT. Why do we need to create a "new open standard"?
Do you mean you were using MQTT over websockets before, and you've since moved to pure MQTT (still over TCP), without websockets in between? Are you sure websockets were the cause of your network bandwidth issues?
I'm on a different team, AFAIK we where using simple JSON payloads on websocket connections. Dropping websockets and switching to MQTT saved a lot of bandwidth. I can ask for precise numbers or details if you wish.
Running XMPP on an ESP8266 or similar is probably not a great experience. MQTT is a more adequate protocol if you want to save processing time and memory (and hence energy).
It’s a really complicated standard with all kinds of components, optional components, prorietary extensions, etc. Plus it has a lot of overhead in every packet.
I don’t know how many vendors use this IoT flavor of XMPP but my guess would be not many. Implementing it on a micro controller would not be fun.
Is there XMPP XEP for controlling devices? The "things" section of that site is empty. Need standardized messages for controlling devices. That is what HTTP Web Things API provides. The Web Things API could probably be adapted to XMPP. But HTTP has taken over the world.
IOT is pointless for a lot things. For some even a hazard.
I laugh to myself when some business people think their IOT widget is the best thing ever. Then I tell them why it's freaking insane or stupid. They look at me like I am a luddite. Thankfully, that is minority of my interactions. Still there are enough of them that it's far from a non-existent issue.
Just connecting something to the internet does not make it better or you just want to monetize with software activated features. A lot IOT devices provides no additional value. A lot of times it decreases the objects value. It makes vulnerable to hacking, and has more possible points of failure, and potential more overhead for the end user to maintain it.
I am not saying all internet connected devices are a bad idea. I just see a lot business people basically taking the latest hype Koolaid and mixing it with existing things. Then they think it's the greatest idea since sliced bread, and that everything will be connected to the the internet. It's one thing to throw many things at the wall to see what sticks for some people that is one way of discovering what works. However, I hate how pervasive some of the IOT hype is getting. I was talking with someone the other day that literally thought that any device that could not connect to the internet was useless for today's society...
Any ways I am sick of hearing about IOT. The fact Mozzila is even trying to get in on this madness is disheartening.
> The fact Mozilla is even trying to get in on this madness is disheartening.
I share a lot of your reservations about IoT. But at the same time, for those things that are going to become successful, I'd really like there to be a unified and open integration for them, rather than each one being their own little walled island.
So from that point of view, I'm actually glad about Mozilla (or any other party) building an open infrastructure for IoT, rather than leaving it to others to build proprietary solutions.
The problem is it does not stop someone from building proprietary systems. Do you really think the Apples of the world are going to want to use an open protocol when then use vendor lock in to basically rent seek?
No, it doesn’t prevent a proprietary system from being built, but it does provide the end users/customers a choice to support products that uses an open system.
I just worked on a pool-pump-controller IoT device. Its connected value was, you could manage it without visiting the pool pit. Your service guy could check on it without driving out to your house. And you could get push notifications when something goes wrong.
Some things, especially automation-control things, benefit greatly from being IoT.
In theory I agree, but in my experience the 'IoT' bits are less reliable than the underlying physical component that's being monitored.
What's more likely? A brushless motor fails, or my wifi password changes when I replace my router, I move my router and its out of range for the pool pump, the pool pump pushes out a bad update, the pool pump company goes out of business, some IoT specific electrical component fails before the actual pump fails, or something of that nature.
Did you hear me say that not all internet connected devices are garbage/pointless.
There are things that can benefit from remote monitoring and control.
However, what's the point of an internet connected blender? There is so much hype that I would almost avoid using the term unless you want to taint your product with such associations.
I thought long and hard about IoT devices and their value. For the most part, I agree that most IoT devices could exist and provide the same value as a non-IoT counterpart. Do you really need a connection to the weather service to know the canopy in your backyard needs to be rolled because of a potential storm?
A simple anemometer with a micro controller can tell it to shut off above a certain wind speed. Most IoT devices "excel" in allowing you to connect to the device via your smart phone. Which is convenient, but not groundbreaking. Where the value of IoT devices lies is in very few use-cases where the IoT device relies on data not found in its proximity. Something like Nest speaking to my electric company to find the lowest rate and optimizing A/C usage around it is quite compelling IMHO. I look forward to seeing more of that rather than the remote use case....
I agree with you that it's fun to tease IoT projects, and that implementations generally are shitty and unsecure.
But do you really, truly believe that the world 100 years from now will not consist of massively connected devices? Can you admit, honestly, to yourself that the preferred method to turning on lights in 2118 won't be a voice command?
2024: IoT voting machines are deployed to a majority of US polling places. Peter Thiel is elected President in a stunning upset.
2025: Tavis Ormandy dies in a tragic IoT jetski accident.
2030: All new cars are required to have fully autonomous and connected control.
2040: Cars produced before 2030 are taxed at 50% of their initial purchase value per year.
2045: North Korea deploys its long-held stockpile of cyber-weapons against the perceived EuroAmeriUnion threat, causing mass fatalities in IoT cars. Since North Korea's vehicles were all produced before 2030, the EAU is forced to fall back to a nuclear response. In its last, desperate act of retaliation, NK's leadership releases its cyber arsenal on the public internet.
2046: In the ensuing nuclear winter, hacker gangs desperately rampage through the Internet of Things in search of food and fuel. Only those with non-connected possessions are unaffected.
I'll be dead either way, but it's not hard to imagine the IoT turning ugly.
HTTP2 server push isn't really designed for the kind of two way communication needed in IoT use cases, it's mainly designed for web servers pushing CSS files down to a web browser before they're requested.
MQTT isn't a web protocol and the goal here is to give things URLs on the web. But I'm aware of some Web of Things implementations using MQTT over WebSockets to benefit from the QoS features.
Restful? I thought it was dead and graphql was the new silver bullet for everything? On a serious note though this is seriously needed and I actually like the start of this API I would mind curling a device and seeing how easy it is to write 2 lines of code to email me if it dies without really having to read documentation and this is the real intent of the idea behind rest, discoverable network apis self documenting because they use links and http standards so I don't have to go look up some companies specific error codes.
> It’s important to note that all of this runs on your own gateway in your house. Google or Amazon can’t see when you turn on the light using your voice.
Is the RPi gateway capable of local speech recognition that can compete with Siri, Alexa, Google? That seems unlikely, unless it has a dedicated processor for that purpose.
I would guess not, but Mozilla will probably wrap this in with https://voice.mozilla.org/ <- that project at some point.
Personally, I'm not one for using Pis as computers, because I have always running computers at home anyways. I'm quite confident my computer can handle adequate voice recognition, though most companies today have avoided developing solutions that run locally.
> Is the RPi gateway capable of local speech recognition that can compete with Siri, Alexa, Google? That seems unlikely, unless it has a dedicated processor for that purpose.
We were doing local speech recognition and full voice dictation back in the 90's through products like this (https://en.wikipedia.org/wiki/Dragon_NaturallySpeaking). Back then your typical computer had a 100Mhz processor and would be lucky to have 32MB of RAM. So yes, with 20 years of progress the much more powerful rasberry pi should be able to handle it just fine.
Make no mistake, siri, alexa and google are spyware, they send your information to themselves because they want to, not because they have to.
There is a pretty big difference between the level of speech recognition that is offered by these smart devices, and what was being done 10-20 years ago. We're talking 80% accuracy (missing every fifth word), to now 95% accuracy (the entire sentence will likely be perfect).
I have worked with several speech recognition softwares, and the ones which can run on a low-powered device in real-time today are not the ones reaching 95% accuracy.
My experience has been different, I found dragon back in the day to be about 90-95% accurate, but today I find google to be about 50% accurate. An that's 50% accurate for some limited voice commands, which is a much lower standard than full voice dictation that dragon offered.
Dragon was trained for me, google is trained for some mythical "everyone".
Who am I to argue with your experience? I can only offer the current literature on the topic [0]. (They report a 5.1% error)
> These systems typically use deep convolutional neural network (CNN) architectures ... driving the word error rate on the benchmark Switchboard corpus down from its mid-2000s plateau of around 15% to well below 10%.
Unless the OS image they want to use is some sort of custom distro that limits what you can run on the raspberry pi, it probably isn't all that hard.
If nothing else, you could probably just hook up the AIY voice kit to it. If the software for the AIY voice kit runs on that OS image, it's pretty trivial to do it. There're multiple tutorials about how to make that happen.
Google leads me to https://webofthings.org/ , "web of things", seems related to Mozilla's Gateway mentioned here, i.e. use http/www/internet to connect all IoT devices.
The web of things started in 2007, somehow it does not gain any traction, is this gateway using the same conception: https://iot.mozilla.org/wot/
Both are referring web-of-things and nodejs/json etc
Have any of Mozilla's projects outside of Firefox actually survived for any length of time? Thunderbird? Is Bugzilla still around? I can't think of anything else.
The first stable 1.0 release of Rust was in 2015, less than three years ago. I believe GP's point is that Mozillas projects come and Mozillas projects go, that FF may be the only one that is still around after some time. Rust doesn't yet meet those criteria.
What I keep failing to see is how does IOT improves anyone's life. It can simplify peoples lives but does it improve? Mozilla could have an important role, which I think is more important than standards. Right now I only see this fad as let's sell some gadgets that will get us free data about millions of people so they can get inside the house at the sound of their favorite tune.
I think "improve" is a very subjective and lofty standard to hold these things to. I think "simplify" is correct, and most people would see simplification as an improvement.
There is definitely something magical about leaving your house and having your lights shut off and your door lock automatically, then coming home after a long day and having your door unlock and lights come back on.
It's not such a drastic improvement or change, but it feels like attention to detail. IMO, reducing the number of things I have to think about on a daily basis to live my life is an improvement.
>There is definitely something magical about leaving your house and having your lights shut off and your door lock automatically, then coming home after a long day and having your door unlock and lights come back on.
I can see how it would feel that way if one didn't know too much. Google home devices were caught with their microphones stuck open constantly uploading within weeks of release.
What makes you think you won't get a doorlock that gets stuck in an open/close loop and just oscillates, allowing a burglar to just stick their shoulder against the door and wait for the bolt to retract? Are you going to remember to check after every firmware update? Are you even going to know if a firmware update is issued?
Will it still be magical if you get declared a legacy customer[1] and your door is programmed to unlock and stay unlocked? Will you even follow IoT news close enough to be confident that this hasn't happened to you?
Myself, I'd prefer a door lock that locks only when locked, and unlocks only when the correct key is inserted into it. I've /certainly/ seen one too many crazy software errors to believe in a stove that has the ability to turn itself on and off.
> What makes you think you won't get a doorlock that gets stuck in an open/close loop and just oscillates, allowing a burglar to just stick their shoulder against the door and wait for the bolt to retract?
Door locks are security theater anyways. If someone really wants to rob you, it's not difficult to get into a house.
> Are you going to remember to check after every firmware update? Are you even going to know if a firmware update is issued?
No, for the same reason I don't check if my computer requires my specific password every time I log in. I'm not that paranoid.'
> Will it still be magical if you get declared a legacy customer and your door is programmed to unlock and stay unlocked?
That has never happened. Even in the example you cite, they caved and offered users a full refund.
> Myself, I'd prefer a door lock that locks only when locked, and unlocks only when the correct key is inserted into it. I've /certainly/ seen one too many crazy software errors to believe in a stove that has the ability to turn itself on and off.
Go for it. While you're at it, make sure you don't get a car that has a remote start or an unlocking keyfob, or a safe that unlocks with a code. Wouldn't want that scary technology near your locks.
>Door locks are security theater anyways. If someone really wants to rob you, it's not difficult to get into a house.
That doesn't compute. If that's the case, then why pay for a smart doorlock? Just stop locking your door.
>That has never happened. Even in the example you cite, they caved and offered users a full refund.
They caved in and offered a full refund /for the hub/, which is the minority cost. No refunds on the compatible bulbs, thermostats, etc that it was made to work with.
>While you're at it, make sure you don't get a car that has a remote start or an unlocking keyfob, or a safe that unlocks with a code.
You're trying to be sarcastic and paint me as a luddite, but you don't know the domain you're opining about. You really /don't/ want a car with a remote start mate, they're already well broken and have been for years: https://www.nytimes.com/2015/04/16/style/keeping-your-car-sa...
> That doesn't compute. If that's the case, then why pay for a smart doorlock? Just stop locking your door.
Your insurance company might feel otherwise. Security theatre serves a purpose, but acting like a deadbolt is some amazing security measure is ridiculous.
> They caved in and offered a full refund /for the hub/, which is the minority cost. No refunds on the compatible bulbs, thermostats, etc that it was made to work with.
Which is why standards are good. Buy ZigBee bulbs and compatible items. Lack of standardization is common in all new industries. Taking one token example and using it to paint the entire concept as bad is also ridiculous.
> You're trying to be sarcastic and paint me as a luddite, but you don't know the domain you're opining about. You really /don't/ want a car with a remote start mate, they're already well broken and have been for years.
I'm well familiar with the issues with remote start. I'm also familiar with the ability that spark plug has to thwart a traditional key.
Once again, if you want to steal a car it's not hard. This is what I'm talking about. For some reason people insist on holding digital locks to this ridiculous standard, when we all know that 99% of consumer locks are intended to "keep honest people honest" and not to actually thwart a real criminal.
Digital/IoT locks meet and exceed that standard IMO. You're letting perfect be the enemy of good, and it does come off as luddite FUD. "I'm scared of this change and what it could do, so better to just stick with the devil I know."
Denial of service attack potential is nice as well: pay $x or we won't unlock your door. As long $x is somewhat lower than what it would cost to replace the lock or fix the damage to the door you might have a buyer.
Back in the kitchen he fished in his various pockets for a dime, and, with it, started up the coffeepot. Sniffing the-to him-very unusual smell, he again consulted his watch, saw that fifteen minutes had passed; he therefore vigorously strode to the apt door, turned the knob and pulled on the release bolt.
The door refused to open. It said, “Five cents, please.”
He searched his pockets. No more coins; nothing. “I'll pay you tomorrow,” he told the door. Again he tried the knob. Again it remained locked tight. “What I pay you,” he informed it, “is in the nature of a gratuity; I don't have to pay you.”
“I think otherwise,” the door said. “Look in the purchase contract you signed when you bought this conapt.”
In his desk drawer he found the contract; since signing it he had found it necessary to refer to the document many times. Sure enough; payment to his door for opening and shutting constituted a mandatory fee. Not a tip.
“You discover I'm right,” the door said. It sounded smug.
From the drawer beside the sink Joe Chip got a stainless steel knife; with it he began systematically to unscrew the bolt assembly of his apt's money-gulping door.
“I'll sue you,” the door said as the first screw fell out.
— from Ubik, Philip K Dick, 1969
(Dick failed to foresee the convenient ability to have everything automatically debited from your Alexoori account. That, and the annual applobe variation so you can't unscrew your door with a knife.)
Alternatively, when I contemplate a world where I need to apply firmware upgrades to my light switches, worry about having to set firewall rules for my front door lock, and ponder what will happen if my letterbox vendor goes out of business and turns of their server - the sheer unadulterated, mechanical simplicity of taking a piece of shaped metal out of my pocket, flicking a light switch and then closing my front door by inserting said pice of metal into a small hole is just so very, very attractive. The lack of cognitive load is just magical
I'd say that's a very accurate description of an inevitable future, assuming we don't extinct ourselves or wipe our our technology progress by nearly extincting ourselves.
One way or the other, for example, automated cars are coming. We can say "but trolleycar problem!" Sure, we need to worry about that! But, no matter how hard we gripe about all the problems and scary things about the new tech, it is coming. It will happen, because there is profit to be had there and it is more efficient than having humans drive and a million other reasons that more than overcome the obstacles.
So, an IoT lightswitch may not be as inevitable as self-driving cars, but IoT valve meters sure as heck are, or IoT lightswitches for an oil rig, or IoT smoke detectors... in fact, some of these might become legally required, once they get robust enough! (similar arguments have been made that it may become illegal to drive a non-autonomous car without lots of training/licensing)
So, people like you and me, that prefer zippos and straight razors and automatic watches over quartz watches and fountain pens and manual-transmission cars, we'll still be able to have our mechanical switches, we just won't live in a world where everyone wants those things.
If you find manually managing those things easier than the occasional firmware update and making sure you buy things from companies that are reasonably reputable and have decent security practice, then by all means stick with regular options.
What if there were a world where your light switches are smart and don’t need firmware updates? The state of mass-market IoT right now is a bit of a shitshow, I’ll grant you, but that doesn’t mean it will always be the case.
People once groused about the complexity of fuel injection, too.
Yes, you don't have to think about your energy bill or your home security as much. So you stop looking at your bills and don't lock your house. Only to find out later that both services stopped working, so you got charged money you didn't know you were being charged, and your house was open to being looted.
People have an annoyance. They think, "I know, I'll add more technology to my life." Now they have two annoyances.
> Only to find out later that both services stopped working, so you got charged money you didn't know you were being charged, and your house was open to being looted.
Wait, in this scenario am I blind & deaf or something? Because I can see my lights turn off when I leave and turn on when I arrive. I can hear and see the lock close when I leave and hear and see it open when I return.
I'm definitely not saying IoT is perfect, but this argument is idiotic. I can also leave my lights on and forget to lock my house with a manual setup, both things I have done before as I'm sure we all have.
Honestly, for a community of users that is entirely focused on tech startups, this is a ludicrous amount of FUD.
Yes, and I've left my keys in the outside of the front door all night, with the keys for both cars attached, probably. Fortunately it's a good neighbourhood...
I'd like houses to have something like central locking, like cars have had for ages. I just don't want it to depend on the Internet, except if I deliberately choose to connect it somehow.
I'd also like to be able to read my gas meter without having to change my clothes afterwards having fought my way through dense vegetation and spiders' webs and knelt down in the mud. But I don't want a "smart" meter connected to the Internet. I just want a local radio link to my own hardware.
Any chance I could have these things without having to build them myself?
Yes, this has been around for years. It's just basic "smart home" stuff. Zwave/Zigbee devices are plentiful. If you don't want to do it yourself then you pay a company to come in and make your home "smart", they'll sell you everything from the controller to the remote to control everything.
80% of the comments in this entire thread are about the woes of connecting everything to the internet which is a fair concern but it's not like non internet connected equivalents haven't been available for decades.
Do you seriously imagine that a complex piece of software, combined with a complex piece of hardware, both of which requiring power to work, and probably a network, would be more reliable than physical, offline, dumb keys and switches?
Of course you don't. You'd have to be an idiot to believe that. So my main point, that technology makes shit more complicated with more failure potential, stands.
I don't have an answer for you, but many things didn't improve peoples' lives when they were created. Powered flight didn't become something meaningful when it was first achieved.
The Internet wasn't built to improve peoples' lives either, but once in the hands of people, can be used to do that.
Certainly some IoT device will improve peoples' lives, and some IoT device (or many) may make them worse.
If you figure out how to make IoT improve peoples' lives, you may be able to make some money though :)
Thing about IOT is it does two main things, informs, and/or controls.
For different people the advantages are going to be different, but for some people there's a lot of anxiety involved in whether they did or didn't do something at home before they left. You could argue IOT can reduce their anxiety and therefore it gives them a higher quality of life. But possibly they just find other things to be anxious about :)
We do IOT for farmers, it allows them to manage their crops far more effectively, saves them money.
...Which should be enough of an answer if you have ever lived in Chicago, but suffice to say, temperature here ranges between -10 and 110, and has the incredible ability to swing 50 or 60 degrees in one day. And my favorite situation can happen where my house is too warm but it's too cold outside to safely operate the air conditioner...
Anyways, fire and forget doesn't really work for my thermostat, I need one I can monitor and control, especially if the weather changes unpredictably here. One of my pets in particular is extremely sensitive to temperature, and I actually have a secondary thermostat monitoring the temperature by my pets, which can swing a good 6-8 degrees from the temperature at my master control.
Today I had a power outage at home. I got notifications, the computer controlling my home (and my router and modem) are on UPS, and remained online. I was able to remote in and verify that after the outage my thermostat was where it was supposed to be and doing what it was supposed to.
I also have had a computer light on fire before, so I'm pretty wary of fire concerns. My computer monitors my home's smoke and carbon monoxide alarms and notifies me as well. While there's no chance my pets might still be alive by the time an outside party notices something wrong in my home, there's a reasonable chance I could call the fire department and they could intervene before all of my pets perished.
A close relation is a firefighter, the one thing that sets him apart from everybody else that I know is that he religiously powers down (as in: unplugged) all consumer electronics before leaving the house. Now, obviously, that is a job related thing, he's seen more than anybody else that isn't in the firefighting business what causes home fires. But if I had had a computer light on fire in my house I probably would switch it off when I'm leaving, and you are making me wonder if that wouldn't be worth it for my home system (which is normally on for years on end).
I do spend a lot of time keeping the power supply and the airways dust free, that's one reason computers overheat.
Keeping your PC dust-free, and your surge protectors and electrical wiring well-organized is a must. I personally prefer surge protectors with outlet covers to ensure nothing gets in them. I have additional removable dust filters on my computers' fan intakes that can easily be removed and cleaned.
My PC fire specifically happened due to a melting Molex to SATA adapter, I learned the "Molex to SATA, lose your data" adage after this incident, and I've actually purged any such adapters from any of my builds. (They're cheaply made, as the case is.)
I was super lucky, it happened while I was nearby, and I was able to shut off the PC before it became more than a purely electrical fire. (And the computer it happened in still works!)
Sometimes electronics can be surprisingly sturdy. The only case when I've had my computer emit the magic blue smoke was when I first connected my homemade fan rpm regulator. After I replaced one of the wires where the shielding had partially melted away, and fixed my circuit, everything worked as if nothing had happened.
Ouch. You should consider yourself very lucky that that is how it ended. That looks like you were at best seconds away from something a lot more exciting.
> What I keep failing to see is how does IOT improves anyone's life
I fail to see this as I get older as well. And my parents failed to see it with smart phones as they got older. And their parents with early-day PCs and so on.
I've gotten a lot of utility out of adding voice controls and some simple automation to my apartment. Things like turning out the lights from bed with a voice command have been quite nice. I also play music and check the weather before leaving home. None of it is revolutionary, but it's all quite nice.
It improves the lives of the people that peddle the solutions.
I personally would not install any IoT devices that require access to anything outside of my home network and even then only if I see no other solution.
Seems like OGC SensorThings API, but there are sections that are related to events and actions. As far as I know, the creator of OGC SensorThings API going to publish a second standard about the events also.
Check it out :https://github.com/opengeospatial/sensorthings
I have no idea if this is what the OP is referring to, but it's pretty much impossible to use HTTPS on your home network without managing your own Root CA and somehow managing to get certificates signed by that Root CA into your devices.
You've got a fighting chance in a corporate network where you can deploy and manage the Root CA via Active Directory/Group Policy, but managing it at home with consumer-grade devices... not gonna be a good day.
I'm not sure what the original commenter meant; however TLS is useful only when talking with your own server. What about other connections? NTP, DNS etc are all unencrypted (read: unsigned). Google "DNS client CVE" for instance. Or what about SSH? It may not be accessible from the Internet, but still exploitable from an infected host in the LAN. Someone has to keep all that software updated.
In those conditions, I would never connect a RaspberryPI or similar to my door / gate / car / ...
If you connected an IoT device in the same network of an infected PC, the infected PC can talk to the IoT device directly if you do not block traffic somehow (eg. a firewall). Are there open ports with buggy services? Probably not today, what about in ten years?
I assume they mean you can only ssh from your local network, the IoT device gets pwnd, it's on the same network as the rest of your computers, someone can use the IoT device as an entry point into your network.
Easily solved with separate networks or vlans etc...
No no no. I am stating that, while TLS is good, your device will use other unprotected connections too (both on LAN and WAN) unless something else is done.
until bugs or weaknesses are found, see SSL v1/2/3 deprecation, heartbleed, etc
rather unrelated I have just seen this article on Smart-Home Privacy, by Gizmodo¹ which at the bottom reads:
"This story was produced with support from the Mozilla Foundation as part of its mission to educate individuals about their security and privacy on the internet."
Considering the timing of both the announcement & Gizmodo piece, suddenly the line "story was produced with support from the mozilla foundation" sounds just like another ad. I wish Gizmodo / Mozilla would be clear of what Mozilla contributed. Especially because Mozilla positions itself by accepting donations.
The gateway is a proof of concept for the "Web Thing API" https://iot.mozilla.org/wot/ that will let you chat with all the things in your home. It is an open alternative to the closed HomeKit and Android Home ecosystems.
Ok so for a typical IoT device I have the software on the device that talks to some server/service on the Internet, and an app on my phone to control the device. This replaces the server/service? What about the app? Does that mean I can create my own devices and an Amazon Echo or Siri will eventually be able to talk to it?
But IoT IS based on industry standards. Rest/Json are NOT the preferred way, it's MQTT/AMQP. Interfacing with a company owned API like Siri/Google is always going to be dictated by the said company. I don't see anything here that Mozilla CAN influence
MQTT is messaging protocol. Is there standardized messages for controlling devices?
Also, there can be different protocols for talking to devices and for talking between computers, gateways, and services. Most home automation devices don't speak Internet protocols and need a gateway as bridge and implement more complicated controls. Devices need to worry about low power, bandwidth, and limited processing power. Might be good idea for security if devices aren't available on Internet routed protocols.
Most current IoT applications are HTTP(S) and JSON. I'm not sure why in the future there would be big change due to increasing resource scarcity, as hardware is getting cheaper and more powerful all the time.
1. The problem isn't the transport layer, it's the application layer. The transport layer is mostly solved via MQTT, COAP, Thread, etc. Sure, we can improve there, but the real problem is the application layer. So I applaud Mozilla's attempt to bring something into this space.
2. Bootstrapping this will require a substantial number of hardware vendors to sign on, both at the edge and at the hub layers. IMHO this is why Google Weave [1] never took off in it's original incarnation. Bootstrapping this like they did with web stuff isn't enough, because this isn't the web.
3. Devices are only part of the problem: We need a software services layer, too. Think time services, IFTTT-like orchestrators, media services, etc.
4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse.
5. Request-Response isn't the right pattern for most use cases.
6. The Property/Action/Event concept is a solid start.
7. For the love of everything holy, add versioning!
[1] http://internetofthingsagenda.techtarget.com/feature/Google-...
Edit: Grammar.