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?
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.
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.
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.
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!!
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...
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.)
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.
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.
There's an interesting open source project OpenHAB (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).
"[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"
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.
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.
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.
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.
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.
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).
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?
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.
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.
[+] [-] voltagex_|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] simoncion|10 years ago|reply
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.
[+] [-] roflmyeggo|10 years ago|reply
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.
[+] [-] profinger|10 years ago|reply
[+] [-] leni536|10 years ago|reply
[+] [-] swsieber|10 years ago|reply
[+] [-] kefka|10 years ago|reply
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|10 years ago|reply
[deleted]
[+] [-] plaguuuuuu|10 years ago|reply
[+] [-] pjc50|10 years ago|reply
(Unless it's a patented protocol, but then people avoid it like the plague)
[+] [-] drdaeman|10 years ago|reply
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.
[+] [-] InclinedPlane|10 years ago|reply
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|10 years ago|reply
Is your beef with the typically abysmal quality of software written by hardware companies, or is it something larger than that?
[+] [-] rdeboo|10 years ago|reply
[+] [-] simoncion|10 years ago|reply
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"
[+] [-] DarkLinkXXXX|10 years ago|reply
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-u...
[+] [-] warfangle|10 years ago|reply
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.
[+] [-] jhaand|10 years ago|reply
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.
[+] [-] kaolinite|10 years ago|reply
[1] https://developer.apple.com/homekit/
[2] https://developers.google.com/brillo/
[+] [-] buffoon|10 years ago|reply
[+] [-] kale|10 years ago|reply
[+] [-] ocdtrekkie|10 years ago|reply
Neither Google nor Apple behave themselves well enough to provide the standard in home automation.
[+] [-] aqwwe|10 years ago|reply
[+] [-] ocdtrekkie|10 years ago|reply
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?
[+] [-] kaendfinger|10 years ago|reply
http://iot-dsa.org/
[+] [-] Someone1234|10 years ago|reply
[+] [-] dade_|10 years ago|reply
[+] [-] anythings|10 years ago|reply
[deleted]
[+] [-] DiabloD3|10 years ago|reply