9 ms·

The Internet of Incompatible Things

156 points by simoncion 11y ago

voltagex_ 11y ago
I have the same issue with chat protocols. Some of my friends are on iMessage, some on Hangouts, some on Whatsapp. None of these talk to each other and I'd really just rather use TextSecure. We had a standard for chat, it's called XMPP, and before that we had IRC. I know they're all non-optimal for mobile use but some goddamn standards (tm) would make my life easier. I can't believe we were better off in the heydays of Trillian - at least all my contact lists were in one program! Maybe I should go back to SMS. Now, on home automation. I came to some of the same conclusions as the author - we're screwed when it comes to being at the behest of big companies and proprietary protocols to control devices we should own. I just dread having to write yet another home automation framework when I do finally automate my doors, windows and lights. Now where did I put my keys again?
- buffoon 11y ago
  Ugh this is the bane of my life. We use basecamp, hipchat, Skype, Skype for business, email and google hangouts all at once. My kids use hangouts, WhatsApp, Facebook messenger. None of them work properly. None of them has everyone on it. None of them add any value to communication. All of them throw ten minutes to the wind finding everyone to start with. I've missed 20 minutes of many meetings dealing with audio problems, network problems and firewall problems when we could have used a simple dial in conference system that has been around for over 10 years. And I'm treated like a Luddite because you have to call me, SMS me or email me?!? I don't want this any more. After a rant yesterday about WiFi and how it sucks and I've switched back to wired ethernet. I have to suggest that there was a technological singularity around 2005 which was 'peak utility' before the proliferation of sharecropped communications, technology with false utility, high cost and pay-per-everything. To add other things to this problem set is going to cost me more money and time of which both are finite and at least one runs out uncontrollably.
  - voltagex_ 11y ago
    One of the things I was hoping would take off was SIP: URIs - in theory you could "dial" my email address and the call would be routed to wherever I was at that moment. Texting is built in too. Goddamn standards strike again.
    - buffoon 11y ago
      Yeah that was a great idea. Until NAT, firewalls, your average contracted out MSP at an SME sysadmin who's idea of admin is lock everything down and pay £300 to open a port (I have to deal with this at least one a week).
      - voltagex_ 11y ago
        If normal Skype supported SIP it could just be bounced to Skype in that case. Also, IPv6 FTW!
        buffoon 11y ago
        Yes that's true although I've lost count of the hours I've thrown out on Skype. Yes IPv6 definitely FTW. We just migrated our office and two data centres to it. Life is good now. V6 firewalls are just packet filters; all our nets are in the public address space.
        simoncion 11y ago
        Stupid question: Just in case you want some nets to not be globally routeable, you guys are aware of the Unique Local Addressing block?
        buffoon 11y ago
        Yes aware of that. There are some gotchas with that, particularly address space collision between two sites with a tunnel between them. I've never seen one in v6 but one of our clients had a 10.0.0.0/8 and so did we and I don't want to get into that state of affairs again. I'd only use that for totally airgapped networks.
- simoncion 11y ago
  > Maybe I should go back to SMS. In my experience, SMS and Hangouts are equally unreliable messaging protocols. Messages sent through either transport can be delayed for arbitrary lengths of time or lost entirely. Everything that's happened with Hangouts that's unrelated to video calling just makes me so sad.
  - josteink 11y ago
    I tried Hangouts v1 and more or less instantly backed out. I was having none of that. Not for IM nor for SMS. After that Google Talk (and thus XMPP) was dead to me. For SMS I could at least revert to the stock AOSP messaging app.
    - simoncion 11y ago
      Google Talk is still alive, well, and performing bi-directional message delivery between XMPP clients with a Google Talk account and Hangouts clients. (Or maybe alive but for the fact that a Google VP hasn't noticed that it's still up and running. shrug) Any client that speaks XMPP should work just fine to reach into Google's IM silo for direct messaging. I make frequent, daily use of Pidgin for this purpose. Sadly, the only way to access group chats is through the official client. Also: If you haven't already, check out TextSecure by Open Whisper Systems. It has the best group-SMS handling of any MMS client I've tried. It's also made and maintained by a group of folks who are really concerned with making secure software that also happens to be as easy to use as is possible.
- kefka 11y ago
  I'm rolling out a test network at the university of IoT. Instead of going with XYZ expensive setup, I'm rolling my own using an Arduino (clone) nano, sensors, and nRF24L01+ using mysensors library. On the acquisition end, I'm using node-red with the mysensors en/decoder. I have node-red generating dynamic HTML, and dumping it in var/www/html and apache serving it up. All I'm waiting for now is 30 more setups for testing purposes. (nRF24L01+ can generate a self-healing mesh network. Given the weird shape of our building, makes this ideal. And a small change turns a sensor node into a sensor/gateway.)
- mahouse 11y ago
  XMPP was fucking crap, whether you like it or not.
- leni536 11y ago
  Why your fallback is SMS and not e-mail?
  - voltagex_ 11y ago
    Most of my non-programmer friends don't check their email addresses, if they maintain one at all. They use Facebook instead.
  - wernercd 11y ago
    Email is the same as Voicemail: ignored, neglected, filled with spam more often than real messages and on the way out.
    - oneweekwonder 11y ago
      SMS is also filled with spam these days. To be honest what medium is not filled with spam/ads?
      - eropple 11y ago
        SMS is filled with spam? That's honestly news to me - I think I've gotten one spam SMS in the last two years? I get a lot more spam calls, though Google Voice filters them for me now.
      - Spivak 11y ago
        If your SMS is filled with spam then you need to talk to your carrier and get a new number
- roflmyeggo 11y ago
  This is the reason I am pushing myself towards simpler solutions, even if I end up losing some functionality/connections out of it. The added cognitive load of dealing with managing all of these services is becoming really painful. Yes, I may not have push via the cloud to my latest iGizmo, but at least I don't have to worry that I forgot an important calendar, todo, file, or chat message on one of 5 services that mix and match between what they offer. Org-mode can run calendar, todo, notes, habits, journal, etc. Chat is where I still haven't found a solution. Switching to XMPP/SMS semi-exclusively is probably the next step.
  - stinkytaco 11y ago
    I would like that, but the thing with calendar, todos, etc, is that syncing with my iGizmo is what makes them most useful for me. That iGizmo is on my person at all times. At the doctor's office and need to make an appointment or talking to a contractor about getting away during the day to meet them at home? Calendar is right there so I won't schedule over a meeting or other engagement. Grocery shopping? My shopping list is there, no way I'd forget it at home. The syncing is precisely what I need it to do to be useful. Before my iGizmo I carried around a notebook, but that was larger, more cumbersome and had less flexibility (I can add a grocery list item from my PC in the kitchen or even input it by voice if I realize I need something). That means that for some of us, a better solution rather than a simpler one is what we desperately hope for.
- profinger 11y ago
  Hey, at least we've finally gotten to the point where I can reliably guess that probably 80+% of the android phones I encounter will have a microUSB plug!!
  - g8oz 11y ago
    You can thank EU regulations for that.
- swsieber 11y ago
  It's really too bad that the mythical man-month is really mythical, otherwise everybody here on HN could pitch in 5 minutes and make a successor to XMPP that is optimal for mobile...
plaguuuuuu 11y ago
This is what happens when everyone focuses on services, rather than protocols.
- drdaeman 11y ago
  Not quite. This is what happens when everyone doesn't give a damn about interoperability. Whenever they build new protocols (that no one else uses because not caring about interop) or unique services doesn't really matter. There are many examples of non-interoperable protocols that do the same thing in a mutually incompatible manner. The most famous one, I suppose is GNU/Linux-surrounding ecosystem with its GUI toolkit mess and audio subsystem jungle.
  - simoncion 11y ago
    There are three major ways to do audio on Linux: * ALSA: Focusses on providing a unified API for audio driver and audio application authors to code to. * JACK: Focusses on very low-latency audio. * PulseAudio: Sits on top of ALSA and makes it trivial to move audio streams on-the-fly between audio output devices. There are three major GUI toolkits: * QT: Used if you don't hate C++. * GTK: Used if you do hate C++. * WxWidgets: Used if you want to always use whatever the "native" widget style is on your target platform. If you want your audio and widgets to work on Linux, Windows and Mac, and you only want to use one toolkit, use SDL. If you want a higher-level widget toolkit than what SDL provides, use QT or GTK, or -I guess- WxWidgets. There's neither a mess, nor a jungle here. I suspect that you've been paying way too much attention to what Poettering has to say about the state of Linux. :)
    - drdaeman 11y ago
      You're right - as a programmer, it's simple - there are plenty of choice. But I'm looking at this from desktop machine user perspective. And I really do have a desktop with eight different somewhat differently looking and behaving (although they try to co-operate and it's possible to bring some consistency to be not too bothered) widget toolkits. I'm not exaggerating - it's really 8 different toolkits here. Ok, I got lazy and run KDE those days so it's primarily KDElibs+Plasma and plain Qt (which has its own differences, like file dialogs being notorious one), which are mostly consistent between each other. Then I have a few apps that use GTK2 and GTK3, a few Wine apps, too. There are also KDE3libs for kTechLab, WxWidgets used by pgAdmin3 and Swing for IntelliJ-based IDEs. There are also some old Tk apps but I run those once in a blue moon, so they doesn't count. But on the other hand, LibreOffice and Firefox have their own widget sets... I've long given up on OSS4 (which, in my personal opinion, is^W was the only Linux sound system with a KISS API) and surrendered to ALSA+PA stack many years ago. And don't have apps that need JACK anymore (used to run some streaming-related software). And ESD & aRts are dead. So, no objections here, although I had quite unpleasant experiences making ESD+JACK+ALSA combo working (that was at least a decade ago). That was before Poettering's rants - honest - although I won't deny that the "jungle" part is obvious reference.
InclinedPlane 11y ago
IoT is one of the least well thought out ideas in quite some time, right up there with the "semantic web". Hopefully it dies a quick death and is resurrected in a more sensible and mature form years down the road. There are worthwhile ideas there, but running headlong into a world where everything has the same quality and security as a typical software project doesn't seem like a notch in the "advance of civilization" column to me.
- simoncion 11y ago
  What, specifically is poorly thought out about IoT? Is your beef with the typically abysmal quality of software written by hardware companies, or is it something larger than that?
  - InclinedPlane 11y ago
    Is there any part of the "Internet of Things" that is well thought out? The idea of our lives becoming surrounded by hojillions of things that are constantly connected to the internet running software written by whomever with no standards, no testing, no regulation or certification, that doesn't seem so great to me. Even the best software written by the most capable engineers who continue to be dedicated to the projects they support is still a horribly bug-ridden mess with occasional enormous security holes. Even if all IoT software was written by, say, a division of Google, it would still be a nightmare. But it will be far, far worse because IoT software will be, and is being, written by anyone and everyone. When you buy a networked device today, how can you tell what level of security it has? What level of testing it's been subjected to? Who has signed off on the design and the code? No such thing of course, it's all at the same level as the kids down the street building stuff out of their garage for kicks. And while there's some merit to that when it comes to innovation, for production, in the modern era, it's not just naive, it's either insane or idiotic. We need more rigor, more standards, and less vulnerability surface-area when it comes to internet-connected devices. IoT is precisely the opposite of that. It's already bad enough that there are millions of zombie PCs in botnets around the globe, we don't need zombie to add toasters, garage doors, light bulbs, and what-have-you to that mess. Anyone who thinks that we can get security and quality in the IoT for free without making a concerted effort is, again, either monstrously naive, insane, or idiotic. It's 2015, that naivete is no longer defensible.
kaolinite 11y ago
This is what Homekit[1] (and Brillo[2] from Google) is trying to fix. We're early on in IoT - things are very immature right now but that doesn't mean the entire concept is flawed. [1] https://developer.apple.com/homekit/ https://developer.apple.com/homekit/ [2] https://developers.google.com/brillo/ https://developers.google.com/brillo/
- buffoon 11y ago
  The very nature of there being two things is a problem already.
  - roel_v 11y ago
    No, it's not, it's actually great that there are literally hundreds of them. They are just the 'hubs'. Whatever 'hub' implements most 'protocol bindings' and provides the best added value on top of it, 'wins'. And if one gets behind, you can 'easily' (depending on circumstances...) switch to another without having to replace the devices.
- kale 11y ago
  Also, it's third-party over the internet, but IFTTT would connect all of the items mentioned in the post. LIFX, Alexa, Hue, and WeMo. It's not ideal to be dependent on a third party web application that's still in its early stages, but it is a partial solution.
  - ocdtrekkie 11y ago
    IFTTT is a third-party cloud service where you give a random startup access to all of the devices in your house. Far from a good idea, and more likely an eventual security nightmare.
- ocdtrekkie 11y ago
  Sorry, "Brillo" was Google's "wait a minute, we have to own the home automation standard, we can't be compatible with others!" Neither Google nor Apple behave themselves well enough to provide the standard in home automation.
jhaand 11y ago
The real money for IoT is not in domestic appliances. But in companies that already had networked devices. For example: Logistic, City automation, large medical devices, factories, Transportation and more of these capital goods. Which can afford to have these different vertical silo's for the coming time. The domestic sector will remain screwed and you're better of to roll your own open source solution. Another solution would be to use a blockchain or one single database were the other appliances can see what is happening and roll their own interpretation of it. Or we remain screwed and only put in an automatic light in toilet and done with IoT.
rdeboo 11y ago
There's an interesting open source project OpenHAB (http://www.openhab.org/ http://www.openhab.org/) that aims to connect all these devices. There are quite a few plugings available (e.g. Philips Hue, Tesla, Sonos etc).
- simoncion 11y ago
  This was mentioned by a commenter on the OP. The author had this to say in reply: "[OpenHAB] provides a consistent interface, but unfortunately it doesn't provide the right consistent interface - the Echo only speaks Wemo or Hue, so I'd still need something to bridge from there to OpenHAB"
  - kefka 11y ago
    OpenHAB is great, if it's a house. When you start to move in the area of building automation tech, we have to deal with Luteon. And that means MSSQL database, and "pain and suffering". And there's no way to dynamically extract that data, so it's a little island of all its own. We've been working with Citrix for quite some time. And they purchased IoT automation company Skynet, and rebranded it OctBlu. Seems good, really good. Well, until I decided to build my own sensor net using cheap tech. All I should really need for a sensor is a 8 bit micro, a sensor, and a nRF24L01+ board. Turns out, from China, those little boards are a whopping $.67/each. Add that to the $1.87 arduino clone, and a sensor (starting with PIR, $.82) along with a dinky project box comes to $5-$6 per node. MySensors library for arduino/nRF24L01+ works superb. Simple API, mesh healing just works. Well, after building a few nodes, I wanted to connect them together in a sort of a dashboard that makes programming them easy. We're already working with Citrix/Octoblu so what about that? Well, there is a MQTT-gateway for MySensors, using an arduino-ethernet module. No. I didn't want these sensors directly hanging off the internet, as our IP's are fully routable. Same with ESP8266-gateway. I wanted something more secure than "put it on the internet". So, I made a mySensors-serial gateway. Plugs in via USB, and provides a serial port of all the data on the network. Simple and effective. From there, I have it going in to a linux machine running Node-Red. Turns out, this is what Octoblu uses. They just provided some pretty dockerizable instances and whatnot. But I have data coming in via serial port, through a mySensors decoder block, and then rest of the logic laid out nicely. It's easy to see how the data flows through the system. I can control how it's logged, as well as where data is terminated. With potential fears of data leakage, I can provably show that the flowchart doesn't leak data. (well, aside mathematically proving said code: we're not doing that).
anythings 11y ago
At https://anythings https://anythings we try to somve this problem by listing the best new smart devices and their compatibilities. It's still WIP. We want to help people build their ecosystem of smart devices. I would love to know what are your thoughts on this. Quentin
- DiabloD3 11y ago
  If you're going to spam on HN, at least use a real URL.
  - nitrogen 11y ago
    There was a time when HN was all about self-promotion. I'm surprised the comment was flagged to death, even with the broken URL.
dade_ 11y ago
For now, it either uses CoAP or REST web service, otherwise I won't consider it. Easy to understand, human readable messaging keeps the integration open and is the second most important concern for IOT (security being #1), but most everyone wants to create a platform and lock in a user/customer base. No thanks.
aqwwe 11y ago
Maybe the European government will do something similar to what they did for cellphone's charging ports (require all manufacturers to use micro USB). And as for the cellphone change, it would hopefully be applied mostly across the board by manufacturers (in USA too).
- ocdtrekkie 11y ago
  That bears the question of whether or not the law will select the right standard, or be able to change it when practical. For instance, with USB Type-C coming out, with EU law be permissive of this transition? Or will the EU requirement adapt to allowing Micro-USB and Type-C for a while, and then eventually mandate Type-C?
  - Someone1234 11y ago
    This is a common misconception. The way the EU's "common external power supply" standard was implemented allowed the manufacturers to pick the standard themselves. Essentially the EU put a gun to manufacturer's heads, and said "pick a common standard together, or we will!" And they did. So the EU never picked micro-USB, the manufacturers did. Additionally the original memorandum of understanding has since expired (2012) but it has been deemed a "success" as all major mobile phone manufacturers continue to utilise micro-USB. So there's no specific reason why USB-C cannot become the new normal. And it seems manufacturers have actually become used to the status quo of having a common standard (except Apple of course). I don't think you'd see the EU get involved if all of them together moved to USB-C (from micro-USB), they would only get involved if they started to developer proprietary ports again, or all had different incompatible ports/chargers. Now they just need to do laptops...
    - ocdtrekkie 11y ago
      That's a very helpful explanation, thank you.
kaendfinger 11y ago
Our company has been working on an Open Source IoT Integration Platform to connect services together into one single protocol that can be used to integrate devices and services together. Notice that it's an integration platform, not a platform for purely building devices on. It can be used for that, but it's primary purpose is integration. http://iot-dsa.org/ http://iot-dsa.org/
- Someone1234 11y ago
  So you've created this: https://xkcd.com/927/ https://xkcd.com/927/
  - kefka 11y ago
    Yep. Node-red remixed with some MQTT in a non-supported way. yay. As for me, I'll roll my own and stick with Node-red, mySensors arduino/nRF24L01+ stack. It just works, and it works Now. And compatibility is easy to do. Connecting to Octoblu (or any MQTT broker) is 1 node away, and just works.
DarkLinkXXXX 11y ago
From the Conditions of Use for the Hue Developer Program[1]: "We want all your apps to work with our API to form a rich ecosystem of interoperable applications, so it is a condition of access to our API documentation that you do not use it to develop or distribute any bridges or devices which interpret the hue API in order to control physical devices. Emulators are allowed provided they only control virtual bulbs" Umm… what are they trying to say? They want interoperability, but only if it's done their way? Seems kinda elitist. [1]: http://www.developers.meethue.com/documentation/conditions-use http://www.developers.meethue.com/documentation/conditions-u...
- warfangle 11y ago
  I think they're trying to say, "you can create an app that uses the hue api to control virtual lightbulbs, but you can't build software/devices that accept hue api messages that will also control your window blinds." It makes sense: the hue api is for lightbulbs, not for window blinds or door locks. You're free to create a layer on top of it that accepts hue api messages for lightbulbs, and other messages for other things. I think they don't want people to get your hypothetical hue-api enabled deadbolt and mistakenly unlock their deadbolt by turning using the hue app to turn their lights off. On the other end of things, you could make an app that will unlock your doors and turn the lights on, as long as the message that unlocks the doors does not conform to the hue api.
  - mjg59 11y ago
    It's more that they're saying "You can't make a bridge that would allow a Hue app to control a non-Hue lighting system"
    - warfangle 11y ago
      Succinct, but I think it's more restrictive than what they're saying - more like, "You can't make a bridge/device that would allow a Hue app to control something that isn't a lightbulb."
      - 11y ago

156 points by simoncion 11y ago

I have the same issue with chat protocols. Some of my friends are on iMessage, some on Hangouts, some on Whatsapp. None of these talk to each other and I'd really just rather use TextSecure. We had a standard for chat, it's called XMPP, and before that we had IRC. I know they're all non-optimal for mobile use but some goddamn standards (tm) would make my life easier. I can't believe we were better off in the heydays of Trillian - at least all my contact lists were in one program! Maybe I should go back to SMS. Now, on home automation. I came to some of the same conclusions as the author - we're screwed when it comes to being at the behest of big companies and proprietary protocols to control devices we should own. I just dread having to write yet another home automation framework when I do finally automate my doors, windows and lights. Now where did I put my keys again?

buffoon 11y ago
Ugh this is the bane of my life. We use basecamp, hipchat, Skype, Skype for business, email and google hangouts all at once. My kids use hangouts, WhatsApp, Facebook messenger. None of them work properly. None of them has everyone on it. None of them add any value to communication. All of them throw ten minutes to the wind finding everyone to start with. I've missed 20 minutes of many meetings dealing with audio problems, network problems and firewall problems when we could have used a simple dial in conference system that has been around for over 10 years. And I'm treated like a Luddite because you have to call me, SMS me or email me?!? I don't want this any more. After a rant yesterday about WiFi and how it sucks and I've switched back to wired ethernet. I have to suggest that there was a technological singularity around 2005 which was 'peak utility' before the proliferation of sharecropped communications, technology with false utility, high cost and pay-per-everything. To add other things to this problem set is going to cost me more money and time of which both are finite and at least one runs out uncontrollably.
- voltagex_ 11y ago
  One of the things I was hoping would take off was SIP: URIs - in theory you could "dial" my email address and the call would be routed to wherever I was at that moment. Texting is built in too. Goddamn standards strike again.
  - buffoon 11y ago
    Yeah that was a great idea. Until NAT, firewalls, your average contracted out MSP at an SME sysadmin who's idea of admin is lock everything down and pay £300 to open a port (I have to deal with this at least one a week).
    - voltagex_ 11y ago
      If normal Skype supported SIP it could just be bounced to Skype in that case. Also, IPv6 FTW!
      - buffoon 11y ago
        Yes that's true although I've lost count of the hours I've thrown out on Skype. Yes IPv6 definitely FTW. We just migrated our office and two data centres to it. Life is good now. V6 firewalls are just packet filters; all our nets are in the public address space.
        simoncion 11y ago
        Stupid question: Just in case you want some nets to not be globally routeable, you guys are aware of the Unique Local Addressing block?
        buffoon 11y ago
        Yes aware of that. There are some gotchas with that, particularly address space collision between two sites with a tunnel between them. I've never seen one in v6 but one of our clients had a 10.0.0.0/8 and so did we and I don't want to get into that state of affairs again. I'd only use that for totally airgapped networks.
simoncion 11y ago
> Maybe I should go back to SMS. In my experience, SMS and Hangouts are equally unreliable messaging protocols. Messages sent through either transport can be delayed for arbitrary lengths of time or lost entirely. Everything that's happened with Hangouts that's unrelated to video calling just makes me so sad.
- josteink 11y ago
  I tried Hangouts v1 and more or less instantly backed out. I was having none of that. Not for IM nor for SMS. After that Google Talk (and thus XMPP) was dead to me. For SMS I could at least revert to the stock AOSP messaging app.
  - simoncion 11y ago
    Google Talk is still alive, well, and performing bi-directional message delivery between XMPP clients with a Google Talk account and Hangouts clients. (Or maybe alive but for the fact that a Google VP hasn't noticed that it's still up and running. shrug) Any client that speaks XMPP should work just fine to reach into Google's IM silo for direct messaging. I make frequent, daily use of Pidgin for this purpose. Sadly, the only way to access group chats is through the official client. Also: If you haven't already, check out TextSecure by Open Whisper Systems. It has the best group-SMS handling of any MMS client I've tried. It's also made and maintained by a group of folks who are really concerned with making secure software that also happens to be as easy to use as is possible.
kefka 11y ago
I'm rolling out a test network at the university of IoT. Instead of going with XYZ expensive setup, I'm rolling my own using an Arduino (clone) nano, sensors, and nRF24L01+ using mysensors library. On the acquisition end, I'm using node-red with the mysensors en/decoder. I have node-red generating dynamic HTML, and dumping it in var/www/html and apache serving it up. All I'm waiting for now is 30 more setups for testing purposes. (nRF24L01+ can generate a self-healing mesh network. Given the weird shape of our building, makes this ideal. And a small change turns a sensor node into a sensor/gateway.)
mahouse 11y ago
XMPP was fucking crap, whether you like it or not.
leni536 11y ago
Why your fallback is SMS and not e-mail?
- voltagex_ 11y ago
  Most of my non-programmer friends don't check their email addresses, if they maintain one at all. They use Facebook instead.
- wernercd 11y ago
  Email is the same as Voicemail: ignored, neglected, filled with spam more often than real messages and on the way out.
  - oneweekwonder 11y ago
    SMS is also filled with spam these days. To be honest what medium is not filled with spam/ads?
    - eropple 11y ago
      SMS is filled with spam? That's honestly news to me - I think I've gotten one spam SMS in the last two years? I get a lot more spam calls, though Google Voice filters them for me now.
    - Spivak 11y ago
      If your SMS is filled with spam then you need to talk to your carrier and get a new number
roflmyeggo 11y ago
This is the reason I am pushing myself towards simpler solutions, even if I end up losing some functionality/connections out of it. The added cognitive load of dealing with managing all of these services is becoming really painful. Yes, I may not have push via the cloud to my latest iGizmo, but at least I don't have to worry that I forgot an important calendar, todo, file, or chat message on one of 5 services that mix and match between what they offer. Org-mode can run calendar, todo, notes, habits, journal, etc. Chat is where I still haven't found a solution. Switching to XMPP/SMS semi-exclusively is probably the next step.
- stinkytaco 11y ago
  I would like that, but the thing with calendar, todos, etc, is that syncing with my iGizmo is what makes them most useful for me. That iGizmo is on my person at all times. At the doctor's office and need to make an appointment or talking to a contractor about getting away during the day to meet them at home? Calendar is right there so I won't schedule over a meeting or other engagement. Grocery shopping? My shopping list is there, no way I'd forget it at home. The syncing is precisely what I need it to do to be useful. Before my iGizmo I carried around a notebook, but that was larger, more cumbersome and had less flexibility (I can add a grocery list item from my PC in the kitchen or even input it by voice if I realize I need something). That means that for some of us, a better solution rather than a simpler one is what we desperately hope for.
profinger 11y ago
Hey, at least we've finally gotten to the point where I can reliably guess that probably 80+% of the android phones I encounter will have a microUSB plug!!
- g8oz 11y ago
  You can thank EU regulations for that.
swsieber 11y ago
It's really too bad that the mythical man-month is really mythical, otherwise everybody here on HN could pitch in 5 minutes and make a successor to XMPP that is optimal for mobile...

plaguuuuuu 11y ago

This is what happens when everyone focuses on services, rather than protocols.

drdaeman 11y ago
Not quite. This is what happens when everyone doesn't give a damn about interoperability. Whenever they build new protocols (that no one else uses because not caring about interop) or unique services doesn't really matter. There are many examples of non-interoperable protocols that do the same thing in a mutually incompatible manner. The most famous one, I suppose is GNU/Linux-surrounding ecosystem with its GUI toolkit mess and audio subsystem jungle.
- simoncion 11y ago
  There are three major ways to do audio on Linux: * ALSA: Focusses on providing a unified API for audio driver and audio application authors to code to. * JACK: Focusses on very low-latency audio. * PulseAudio: Sits on top of ALSA and makes it trivial to move audio streams on-the-fly between audio output devices. There are three major GUI toolkits: * QT: Used if you don't hate C++. * GTK: Used if you do hate C++. * WxWidgets: Used if you want to always use whatever the "native" widget style is on your target platform. If you want your audio and widgets to work on Linux, Windows and Mac, and you only want to use one toolkit, use SDL. If you want a higher-level widget toolkit than what SDL provides, use QT or GTK, or -I guess- WxWidgets. There's neither a mess, nor a jungle here. I suspect that you've been paying way too much attention to what Poettering has to say about the state of Linux. :)
  - drdaeman 11y ago
    You're right - as a programmer, it's simple - there are plenty of choice. But I'm looking at this from desktop machine user perspective. And I really do have a desktop with eight different somewhat differently looking and behaving (although they try to co-operate and it's possible to bring some consistency to be not too bothered) widget toolkits. I'm not exaggerating - it's really 8 different toolkits here. Ok, I got lazy and run KDE those days so it's primarily KDElibs+Plasma and plain Qt (which has its own differences, like file dialogs being notorious one), which are mostly consistent between each other. Then I have a few apps that use GTK2 and GTK3, a few Wine apps, too. There are also KDE3libs for kTechLab, WxWidgets used by pgAdmin3 and Swing for IntelliJ-based IDEs. There are also some old Tk apps but I run those once in a blue moon, so they doesn't count. But on the other hand, LibreOffice and Firefox have their own widget sets... I've long given up on OSS4 (which, in my personal opinion, is^W was the only Linux sound system with a KISS API) and surrendered to ALSA+PA stack many years ago. And don't have apps that need JACK anymore (used to run some streaming-related software). And ESD & aRts are dead. So, no objections here, although I had quite unpleasant experiences making ESD+JACK+ALSA combo working (that was at least a decade ago). That was before Poettering's rants - honest - although I won't deny that the "jungle" part is obvious reference.

InclinedPlane 11y ago

IoT is one of the least well thought out ideas in quite some time, right up there with the "semantic web". Hopefully it dies a quick death and is resurrected in a more sensible and mature form years down the road. There are worthwhile ideas there, but running headlong into a world where everything has the same quality and security as a typical software project doesn't seem like a notch in the "advance of civilization" column to me.

simoncion 11y ago
What, specifically is poorly thought out about IoT? Is your beef with the typically abysmal quality of software written by hardware companies, or is it something larger than that?
- InclinedPlane 11y ago
  Is there any part of the "Internet of Things" that is well thought out? The idea of our lives becoming surrounded by hojillions of things that are constantly connected to the internet running software written by whomever with no standards, no testing, no regulation or certification, that doesn't seem so great to me. Even the best software written by the most capable engineers who continue to be dedicated to the projects they support is still a horribly bug-ridden mess with occasional enormous security holes. Even if all IoT software was written by, say, a division of Google, it would still be a nightmare. But it will be far, far worse because IoT software will be, and is being, written by anyone and everyone. When you buy a networked device today, how can you tell what level of security it has? What level of testing it's been subjected to? Who has signed off on the design and the code? No such thing of course, it's all at the same level as the kids down the street building stuff out of their garage for kicks. And while there's some merit to that when it comes to innovation, for production, in the modern era, it's not just naive, it's either insane or idiotic. We need more rigor, more standards, and less vulnerability surface-area when it comes to internet-connected devices. IoT is precisely the opposite of that. It's already bad enough that there are millions of zombie PCs in botnets around the globe, we don't need zombie to add toasters, garage doors, light bulbs, and what-have-you to that mess. Anyone who thinks that we can get security and quality in the IoT for free without making a concerted effort is, again, either monstrously naive, insane, or idiotic. It's 2015, that naivete is no longer defensible.

kaolinite 11y ago

This is what Homekit[1] (and Brillo[2] from Google) is trying to fix. We're early on in IoT - things are very immature right now but that doesn't mean the entire concept is flawed. [1] https://developer.apple.com/homekit/ https://developer.apple.com/homekit/ [2] https://developers.google.com/brillo/ https://developers.google.com/brillo/

buffoon 11y ago
The very nature of there being two things is a problem already.
- roel_v 11y ago
  No, it's not, it's actually great that there are literally hundreds of them. They are just the 'hubs'. Whatever 'hub' implements most 'protocol bindings' and provides the best added value on top of it, 'wins'. And if one gets behind, you can 'easily' (depending on circumstances...) switch to another without having to replace the devices.
kale 11y ago
Also, it's third-party over the internet, but IFTTT would connect all of the items mentioned in the post. LIFX, Alexa, Hue, and WeMo. It's not ideal to be dependent on a third party web application that's still in its early stages, but it is a partial solution.
- ocdtrekkie 11y ago
  IFTTT is a third-party cloud service where you give a random startup access to all of the devices in your house. Far from a good idea, and more likely an eventual security nightmare.
ocdtrekkie 11y ago
Sorry, "Brillo" was Google's "wait a minute, we have to own the home automation standard, we can't be compatible with others!" Neither Google nor Apple behave themselves well enough to provide the standard in home automation.

jhaand 11y ago

The real money for IoT is not in domestic appliances. But in companies that already had networked devices. For example: Logistic, City automation, large medical devices, factories, Transportation and more of these capital goods. Which can afford to have these different vertical silo's for the coming time. The domestic sector will remain screwed and you're better of to roll your own open source solution. Another solution would be to use a blockchain or one single database were the other appliances can see what is happening and roll their own interpretation of it. Or we remain screwed and only put in an automatic light in toilet and done with IoT.

rdeboo 11y ago

There's an interesting open source project OpenHAB (http://www.openhab.org/ http://www.openhab.org/) that aims to connect all these devices. There are quite a few plugings available (e.g. Philips Hue, Tesla, Sonos etc).

simoncion 11y ago
This was mentioned by a commenter on the OP. The author had this to say in reply: "[OpenHAB] provides a consistent interface, but unfortunately it doesn't provide the right consistent interface - the Echo only speaks Wemo or Hue, so I'd still need something to bridge from there to OpenHAB"
- kefka 11y ago
  OpenHAB is great, if it's a house. When you start to move in the area of building automation tech, we have to deal with Luteon. And that means MSSQL database, and "pain and suffering". And there's no way to dynamically extract that data, so it's a little island of all its own. We've been working with Citrix for quite some time. And they purchased IoT automation company Skynet, and rebranded it OctBlu. Seems good, really good. Well, until I decided to build my own sensor net using cheap tech. All I should really need for a sensor is a 8 bit micro, a sensor, and a nRF24L01+ board. Turns out, from China, those little boards are a whopping $.67/each. Add that to the $1.87 arduino clone, and a sensor (starting with PIR, $.82) along with a dinky project box comes to $5-$6 per node. MySensors library for arduino/nRF24L01+ works superb. Simple API, mesh healing just works. Well, after building a few nodes, I wanted to connect them together in a sort of a dashboard that makes programming them easy. We're already working with Citrix/Octoblu so what about that? Well, there is a MQTT-gateway for MySensors, using an arduino-ethernet module. No. I didn't want these sensors directly hanging off the internet, as our IP's are fully routable. Same with ESP8266-gateway. I wanted something more secure than "put it on the internet". So, I made a mySensors-serial gateway. Plugs in via USB, and provides a serial port of all the data on the network. Simple and effective. From there, I have it going in to a linux machine running Node-Red. Turns out, this is what Octoblu uses. They just provided some pretty dockerizable instances and whatnot. But I have data coming in via serial port, through a mySensors decoder block, and then rest of the logic laid out nicely. It's easy to see how the data flows through the system. I can control how it's logged, as well as where data is terminated. With potential fears of data leakage, I can provably show that the flowchart doesn't leak data. (well, aside mathematically proving said code: we're not doing that).

anythings 11y ago

At https://anythings https://anythings we try to somve this problem by listing the best new smart devices and their compatibilities. It's still WIP. We want to help people build their ecosystem of smart devices. I would love to know what are your thoughts on this. Quentin

DiabloD3 11y ago
If you're going to spam on HN, at least use a real URL.
- nitrogen 11y ago
  There was a time when HN was all about self-promotion. I'm surprised the comment was flagged to death, even with the broken URL.

dade_ 11y ago

For now, it either uses CoAP or REST web service, otherwise I won't consider it. Easy to understand, human readable messaging keeps the integration open and is the second most important concern for IOT (security being #1), but most everyone wants to create a platform and lock in a user/customer base. No thanks.

aqwwe 11y ago

Maybe the European government will do something similar to what they did for cellphone's charging ports (require all manufacturers to use micro USB). And as for the cellphone change, it would hopefully be applied mostly across the board by manufacturers (in USA too).

ocdtrekkie 11y ago
That bears the question of whether or not the law will select the right standard, or be able to change it when practical. For instance, with USB Type-C coming out, with EU law be permissive of this transition? Or will the EU requirement adapt to allowing Micro-USB and Type-C for a while, and then eventually mandate Type-C?
- Someone1234 11y ago
  This is a common misconception. The way the EU's "common external power supply" standard was implemented allowed the manufacturers to pick the standard themselves. Essentially the EU put a gun to manufacturer's heads, and said "pick a common standard together, or we will!" And they did. So the EU never picked micro-USB, the manufacturers did. Additionally the original memorandum of understanding has since expired (2012) but it has been deemed a "success" as all major mobile phone manufacturers continue to utilise micro-USB. So there's no specific reason why USB-C cannot become the new normal. And it seems manufacturers have actually become used to the status quo of having a common standard (except Apple of course). I don't think you'd see the EU get involved if all of them together moved to USB-C (from micro-USB), they would only get involved if they started to developer proprietary ports again, or all had different incompatible ports/chargers. Now they just need to do laptops...
  - ocdtrekkie 11y ago
    That's a very helpful explanation, thank you.

kaendfinger 11y ago

Our company has been working on an Open Source IoT Integration Platform to connect services together into one single protocol that can be used to integrate devices and services together. Notice that it's an integration platform, not a platform for purely building devices on. It can be used for that, but it's primary purpose is integration. http://iot-dsa.org/ http://iot-dsa.org/

Someone1234 11y ago
So you've created this: https://xkcd.com/927/ https://xkcd.com/927/
- kefka 11y ago
  Yep. Node-red remixed with some MQTT in a non-supported way. yay. As for me, I'll roll my own and stick with Node-red, mySensors arduino/nRF24L01+ stack. It just works, and it works Now. And compatibility is easy to do. Connecting to Octoblu (or any MQTT broker) is 1 node away, and just works.

DarkLinkXXXX 11y ago

From the Conditions of Use for the Hue Developer Program[1]: "We want all your apps to work with our API to form a rich ecosystem of interoperable applications, so it is a condition of access to our API documentation that you do not use it to develop or distribute any bridges or devices which interpret the hue API in order to control physical devices. Emulators are allowed provided they only control virtual bulbs" Umm… what are they trying to say? They want interoperability, but only if it's done their way? Seems kinda elitist. [1]: http://www.developers.meethue.com/documentation/conditions-use http://www.developers.meethue.com/documentation/conditions-u...

warfangle 11y ago
I think they're trying to say, "you can create an app that uses the hue api to control virtual lightbulbs, but you can't build software/devices that accept hue api messages that will also control your window blinds." It makes sense: the hue api is for lightbulbs, not for window blinds or door locks. You're free to create a layer on top of it that accepts hue api messages for lightbulbs, and other messages for other things. I think they don't want people to get your hypothetical hue-api enabled deadbolt and mistakenly unlock their deadbolt by turning using the hue app to turn their lights off. On the other end of things, you could make an app that will unlock your doors and turn the lights on, as long as the message that unlocks the doors does not conform to the hue api.
- mjg59 11y ago
  It's more that they're saying "You can't make a bridge that would allow a Hue app to control a non-Hue lighting system"
  - warfangle 11y ago
    Succinct, but I think it's more restrictive than what they're saying - more like, "You can't make a bridge/device that would allow a Hue app to control something that isn't a lightbulb."
    - 11y ago