6 ms·

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 appli

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! [1] http://internetofthingsagenda.techtarget.com/feature/Google-takes-on-IoT-with-Brillo-and-Weave http://internetofthingsagenda.techtarget.com/feature/Google-... Edit: Grammar.

wiremine 9y ago
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.
- statictype 9y ago
  Curious, How are Fortune 100s using iot? Our company does Device integration stuff but most of the big guys are using older automation systems (typically a bms) We have not seen any significant adoption of iot so far. Maybe our market is just different.
  - wiremine 9y ago
    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. * Smart City - Energy management, parking. We weren't involved too much, but our city's snowmelt system is another example: https://runengine.com/vroom/58-smart-city-snowmelt-monitor https://runengine.com/vroom/58-smart-city-snowmelt-monitor (The guy with the beard is one of my SAs) https://www.hackster.io/kayakpete/snowmelt-system-monitor-be4a01 https://www.hackster.io/kayakpete/snowmelt-system-monitor-be... 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.
    - pm 9y ago
      The last thought intrigues me, but I'm not sure what you mean by "Enterprise Architecture" specifically.
    - rob-olmos 9y ago
      Thanks for the insights. What kind of traditional "Enterprise Architecture" patterns do you mean? I imagine the "Enterprise service bus" architecture is probably a good fit, but maybe I'm missing something.
    - savolai 9y ago
      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. Thanks!
- fyfy18 9y ago
  Is it possible to get involved without any kind of EE background?
  - ramzyo 9y ago
    Err, yes, totally. EE definitely not required.
  - cobookman 9y ago
    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
pm 9y ago
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.
carapace 9y ago
In re #4: > 4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse. ASN.1? https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One > 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.
- mkj 9y ago
  cbor looks better for small devices?
  - wiremine 9y ago
    This would be the first place I'd look if I were the Mozilla guys.
    - bugmen0t 9y ago
      why not cap'n'proto?
      - _pmf_ 9y ago
        Cap'n Proto's Time Traveling RPC[0] would indeed be a perfect match for the IoT. [0] https://capnproto.org/news/2013-12-12-capnproto-0.4-time-travel.html https://capnproto.org/news/2013-12-12-capnproto-0.4-time-tra...
      - elcritch 9y ago
        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.
tomkinson 9y ago
Nailed it.
mrtree 9y ago
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. +1 to CoAP, cause MQTT is an insecure hack. 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. +1 Check out Oauth. 3. Devices are only part of the problem: We need a software services layer, too. Think time services, IFTTT-like orchestrators, media services, etc. Sounds to me like a good start up proposition! 4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse. RFC7049 5. Request-Response isn't the right pattern for most use cases. -1 Wrong. 6. The Property/Action/Event concept is a solid start. W3C WoT Thing Description. 7. For the love of everything holy, add versioning! +1
- shandor 9y ago
  > MQTT is an insecure hack. How so? Usually when I hear someone talking about MQTT, it sounds like it has to be the best thing since sliced bread.
bhudman 9y ago
Hi - I'm working on some projects with IoT now and would like to see if we can use your services. Any chance you can contact me? Info in my about.
hajile 9y ago
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.
- thom_nic 9y ago
  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.
  - wiremine 9y ago
    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.

wiremine 9y ago

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.

statictype 9y ago
Curious, How are Fortune 100s using iot? Our company does Device integration stuff but most of the big guys are using older automation systems (typically a bms) We have not seen any significant adoption of iot so far. Maybe our market is just different.
- wiremine 9y ago
  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. * Smart City - Energy management, parking. We weren't involved too much, but our city's snowmelt system is another example: https://runengine.com/vroom/58-smart-city-snowmelt-monitor https://runengine.com/vroom/58-smart-city-snowmelt-monitor (The guy with the beard is one of my SAs) https://www.hackster.io/kayakpete/snowmelt-system-monitor-be4a01 https://www.hackster.io/kayakpete/snowmelt-system-monitor-be... 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.
  - pm 9y ago
    The last thought intrigues me, but I'm not sure what you mean by "Enterprise Architecture" specifically.
  - rob-olmos 9y ago
    Thanks for the insights. What kind of traditional "Enterprise Architecture" patterns do you mean? I imagine the "Enterprise service bus" architecture is probably a good fit, but maybe I'm missing something.
  - savolai 9y ago
    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. Thanks!
fyfy18 9y ago
Is it possible to get involved without any kind of EE background?
- ramzyo 9y ago
  Err, yes, totally. EE definitely not required.
- cobookman 9y ago
  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

pm 9y ago

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.

carapace 9y ago

In re #4: > 4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse. ASN.1? https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One https://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One > 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.

mkj 9y ago
cbor looks better for small devices?
- wiremine 9y ago
  This would be the first place I'd look if I were the Mozilla guys.
  - bugmen0t 9y ago
    why not cap'n'proto?
    - _pmf_ 9y ago
      Cap'n Proto's Time Traveling RPC[0] would indeed be a perfect match for the IoT. [0] https://capnproto.org/news/2013-12-12-capnproto-0.4-time-travel.html https://capnproto.org/news/2013-12-12-capnproto-0.4-time-tra...
    - elcritch 9y ago
      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.

tomkinson 9y ago

Nailed it.

mrtree 9y ago

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. +1 to CoAP, cause MQTT is an insecure hack. 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. +1 Check out Oauth. 3. Devices are only part of the problem: We need a software services layer, too. Think time services, IFTTT-like orchestrators, media services, etc. Sounds to me like a good start up proposition! 4. JSON is a non-starter long-term: it sucks for small devices. They need a binary format that is easy to parse. RFC7049 5. Request-Response isn't the right pattern for most use cases. -1 Wrong. 6. The Property/Action/Event concept is a solid start. W3C WoT Thing Description. 7. For the love of everything holy, add versioning! +1

shandor 9y ago
> MQTT is an insecure hack. How so? Usually when I hear someone talking about MQTT, it sounds like it has to be the best thing since sliced bread.

bhudman 9y ago

Hi - I'm working on some projects with IoT now and would like to see if we can use your services. Any chance you can contact me? Info in my about.

hajile 9y ago

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.

thom_nic 9y ago
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.
- wiremine 9y ago
  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.