AllJoyn is an open protocol and device architecture for IoT. We’re building it into Windows 10. The list of companies supporting this shows that it’ll be a big deal in homes especially.
Would be nice to see some NETMF->AllJoyn stuff going on. It’s all open source.
When I looked at the APIs, it felt to me a lot like the spirit of Gadgeteer and NETMF: strongly typed classes with meaningful method names that are easily discoverable.
Pete
I was reading about this and was thinking how great would this be for netmf actually.
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.
Pete
Where can we get info about AllJoyn? That marketing doc was extremely content-free. Plenty of hype, though. Lots of buzzwords, too.
I’ve been listening to this for the last half hour and it seems to be a fairly decent overview.
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?
why not try … https://www.alljoyn.org/ … you can even find a reference to the source code or SDKs, including examples …
well … see it as a challenge … :whistle:
for developer resources you have to go here https://allseenalliance.org/source-code to find sources for Android, iOS, Windows, etc.
@ ransomhall - Wouldn’t they complement each other in one form or another? Just thinking out loud - have to read more about both.
That is actually a very cool demo. I would never thought why would I need a “smart” toaster. No I see the benefit. I like my toasts warm!
Regarding the TV, what kind of TV was it?
Found my answer. Looks like it is LG
Hopefully Samsung will jump on that train as well. Love my Samsung TV.
I havent been through the material but where is Apple and Homekit in this?
@ njbuch - Probably doing its own thing.
As I have just found same is for Samsung and their Chord:
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?
Looks like we need a netmf port of the AllJoyn Thin Client
https://allseenalliance.org/sites/default/files/resources/intro_alljoyn_thin_client.pdf
from the doc intro:
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:
I just wanted to 1+ this statement since I agree
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.