An interesting demo I saw while on campus was a “smart” toaster (just bear with me on this one).
The toast was started. A few minutes later, a, erm, popup toast message appeared on the AllJoyn-enabled TV saying your toast was done.
This works because the TV is set, out of the box, to listen to AllJoyn notification messages and display them on-screen.
It’s a really simple demo, but the very simplicity of it is what made it very interesting to me. It certainly seems like something NETMF and Gadgeteer can plug into nicely.
I’ve just started looking at this to see if it could have positive impact in music (depends on how real-time the messages can be) as an ethernet transport for something like MIDI. Having it built into the OS makes it more compelling than many add-on solutions.
So I just started digging into the MS HomeOS/Lab of Things research project. Does this have a future, or should I switch to AllJoyn?
I’ve been waiting for some “standard” to emerge from all these MS based frameworks. It’s still very unclear to me what will win out. “We’re building it into Windows 10” seems to indicate the AllJoyn would be a better investment of my time in the home automation IoT arena.
Pete - Any more prescient guidance you can divulge?
Given the recent thread discussing “security” in Bluetooth Low Energy, I have to wonder how well any of these various connected device protocols will handle security.
Given that Pete said that AllJoyn will be built into Windows 10, that gives me a bit of peace of mind, because it suggests that someone at Microsoft has done the due diligence to at least provide some level of vetting of the protocol and its implications. Then again, I guess BLE would in theory have been subject to the same thing.
But I’m definitely more skeptical of vendor specific solutions like Chord. Not just because they’re limited to the vendor’s devices, but also because I’m much less confident that a vendor specific solution will do a great job with security.
Has anyone seen any info on AllJoyn evaluating it from a security standpoint?
This means, specifically, that we do not have the luxury of bundling in an AllJoyn daemon (which requires multi-threading), having many network connections, and using relatively large amounts of RAM and ROM. We do not have the luxury of running an object-oriented programming environment that includes alternate language bindings.
I think netmf can get rid of at least two of those constraints…
I need to win the lottery and do this stuff full time :think:
Andre, it seems to make perfect sense to me. AllJoyn is about connecting the devices in your home together. It’s a safe assumption that the home already contains a WiFi router. So, no extra cost there. With the recent introduction of $3 WiFi chips (ex. ESP8266) and that price will likely continue to drop, WiFi connectivity makes the most sense. If you’re just wanting an array of sensors that do nothing but measure and report back then maybe something else makes more sense but for the IoT where devices actually talk to each and to you, it seems like a very good solution to me.
I’m really glad Pete mentioned this. I’m excited to give it a try. I just received a 5-pack of ESP8266 chips last week and I’m looking forward to trying to connect some existing devices together.
@ andre.m - In some way I agree with you as wifi is a dead dog for the small device connected world. So the problem goes like this, I buy some Twinkie device say for monitoring my toaster, how do I hook it up to my wifi network? Somehow I have to enter the wifi SSID and password, how do I do that on a device that has no display or keypad (as those cost too much)? Toss in wifi is a power gobbling pig from hell and its not a good match for a lot of devices.
Now I’m the biggest fan on the planet for devices, but there are some realities that need to be handled when building consumer devices and while as a bunch of coders we simply put the SSID and password into our code, its a hugely different game when its a end user.