I recently read about Thread as a wireless communication standard and are super exited to know more about it.
Thread is featured by all Samsung Artik Modules as well as the Artik 030 which is a low-cost, low-power Thread Module for use as a battery driven sensor controller.
This makes Samsung Artik Series perfectly suitable for a smart home gateway driven by Resin.io. The Smart Home Gateway could easily bring up a python or node based Server with HTTP API and Communication to wireless sensors using Thread.
Using Public-URL remote controlling or monitoring would also be very straightforward.
So I am asking for some examples, projects and information about Thread and Resin.io on Samsung Artik Modules. I really think that those modules and resin.io do make a wonderful combination! Even more that the Raspberry or any of those other modules.
I don’t think we have any examples internally. @curcuz is working with ARTIK a lot and knows them pretty much inside out, but was working with other libraries and hardware.
Generally we recommend people to give it a try to prototype the things they are interested in, and see whether there are any stumbling blocks down the road. We’d love to see (and facilitate) more variety of examples and use cases, as resources permit. It does look interesting, I’ll definitely note this down for a Hack Friday.
@imrehg The reason why I am so after Thread is just because I have been working with ZigBee for some time now and you really can feel the age of it.
Thread has Meshing, Self-Healing and shares many other things with ZigBee (most important: it is low-power ready) so that both are very similar to each other. The only thing that is totally different is that on top of all those things, Thread is using IP-technology for communication and addressing.
This means that instead of talking over serial port or SPI to ZigBee devices - as far as I understand Thread can be added as a networking device at the bottom of the OS.
This also means that you wont have to convert data, HTTP Request, etc. to serial data and back just to communicate with low-power devices.
I think that this is a very huge improvement - if not a new category of low-powered wireless communications. This is why I think that protocols / techniques like that have huge importance in the very near future!
And having a smart home device with a gateway using Resin.io on (for example) Artik 520 - and Artik 030 as low-power, battery powered, long-lasting sensor device which communicates with the gateway using Thread … Well that would be a killer example for Resin.io
I will be doing such a thing for one of my customers so I will come up with this …
Yeah it all looks definitely on the same path we were working on on. I’ve been browsing the Thread website again, though not much actual development info that I can find, looks like most of the know-how is in the hardware, if I understand it correctly?
In these kinds of situations I think we usually concentrate on the base platform (ie. the resin.io services), so others who have specific use cases like this have the required tools to build what they need. I say, usually, because I can see some demos or uses developed by us, while it is more likely that we’ll mostly facilitate instead, when there’s something that you are already developing.
The gateway example is definitely very life-like, and what you mentioned about the ARTIK is very similar to a demo that we are just building up (@curcuz and @mccollam mostly) around the ARTIK5 gateway + the BBC micro:bit dependent devices like this. Just the connection is BlueTooth there, no new stuff is needed. But the foundations should be there for building something like that with Thread, if someone has the right hardware.
Do you think you’ll build something with Thread in the near future? If you’ll do that, what would a development process look like for this tech?
Well I have been trying to get more information about Thread and was looking for development guides, etc. but currently the information is very limited.
After reading through different sources I know that the Thread Group is very similar to Z-Wave Alliance. Developing a Thread device means that you have to be a part of the Group. So you have to apply first. I guess that’s the main benefit of ZigBee where information and hardware is more open.
On the other hand, Thread is based on 6lowpan and that is what makes it so interesting. However 6lowpan has to be integrated into the base operating system and I guess that this means modifying the Yocto Linux of Resin.io - well I am however not pretty sure.
I have been working with ZigBee so far using DIGI XBee Modules and they are - even if they are that old - a charm to work with.
I really think that Thread will have quite some impact on the market but when you first have to apply to the group which includes paying a fee, well I begin to step back from Thread. Also when you want to market a Thread enabled product you will have to test it by the Thread group.
Sure I understand where this comes from. There are a lot of developers who build ZigBee enabled devices without properly implementing ZigBee (strong) security functions. ZigBee has security - but it is up to the developer to implement these features.
To prevent Thread or Z-Wave from being called low on security - best way is to have each device tested before it is put on the market
