
Build a Thread network with Nordic nRF52840 - kfihihc
https://blog.makerdiary.com/build-a-thread-network-with-nrf52840-mdk/
======
SlowRobotAhead
Article should be titled “how to use a preexisiting CLI”. I’ve been way (WAY)
in the weeds with BLE over GATT and it’s limitations. Using a CLI they give
you isn’t really even close to the same thing - works great until it doesn’t.

Starting the project right now, I would consider Thread to just use data over
IP but for a single device and a phone interface there just doesn’t seem to be
a ease of use like traditional connect-and-go.

For example, waiting “about a minute” for the device to show up with an IPv6
address - fine if it’s a lightbulb, deal breaker if it’s a user device they
just turned on and want to access.

------
oflannabhra
I’ve worked with ZigBee, Bluetooth and Thread. Using IP traffic over Thread
was great.

ZigBee is moving in the same direction with DotDot, but I found Thread’s
agnosticism (in regards to application layer traffic) to be refreshing.
Bluetooth’s mesh is very, very immature, at least what they have released so
far.

~~~
pooya13
Is DotDot intended to replace the ZigBee application layer? (commands and
attributes) If so is it also lightweight? By the way I don't get why they call
it "open" when you have to be part of the alliance before you can access the
specifications.

~~~
oflannabhra
Yes, DotDot is a mapping of the ZCL onto CoAP, and is carried over IPv6. It is
essentially the separation of ZigBee’s networking later from their application
layer.

ZCL is not exactly RESTful, so running it with URIs over CoAP is still a
little weird. It’s main advantage is being able to run all the same
application code on your devices, regardless of networking (WiFi, Thread, BT,
or ZigBee).

I don’t know how that will turn out in practice, but ZCL has wide adoption,
and Thread required you to develop your own application layer. So, it has
great potential, I guess.

