While good to see this being released, I would have thought the standard would have been made extensible and future proofed by using a tagged method (eg something like Json or similar).
Also a little surprised by the small number of contributors, would have thought quite a few others would have participated.
Yeah the QR code spec is finally here, and it will drastically improve device onboarding.
Today I’m hosting a webinar for device makers, and I’d love to see community members there too, as they are building community products or contemplating about going commercial with their work. Please sign up here: https://thethingsnetwork.us11.list-manage.com/subscribe?u=20406705fec6d7d4b2ab1d6cc&id=58e3d8ae1b.
The webinar will mostly be around the device repository: https://github.com/TheThingsNetwork/lorawan-devices
As for @Jeff-UK’s question on whether the community can make use of TTN’s vendor ID (428) still needs to be decided. It looks like it doesn’t come with responsibilities, certification requirements, etc, so it doesn’t seem like there are many problems with doing that.
JSON doesn’t fit; QR codes should be as small as possible so the aim was to reduce the number of characters. As for extensions, there’s the Proprietary extensions, see document. Device makers can put anything in there.
This doesn’t say anything really. Contribution, i.e. the listed names on the spec, is different from participation. In the LoRa Alliance, unless you submit a Word diff in a committee call in a specific format, you’re not a listed contributor of the specs.
Thanks, I’ll have a closer look.
Hi Johan thanks for the prompt feedback. Have signed up for this afternoons session but participation is dependent on if I can get frm meeting in time - will session be recorded/released on You Tube?
Generating QR codes for typical TTN experiments and small qty deployments might not be impacted but would be interested on the call to know if it can be made viable for batch builds/deployments say 100 up (50up?), as that would be a game changer and would make wider use of TTN (and potentially then TTI longer tem) much more viable after any cost/benefit eval given the proportion of time taken to manually run through and register apps and each and every node manually, once through any prototyping
and/or development phase, even when taking mainly off the shelf hardware from other vendors - poss as a subsystem to the complete node. 
It may be the route forward is for the LoRaWAN Module/ Subsystem vendors to use these with deployers leveraging their QR code for actual device/system deployment & onboarding… I dont know how might work but just putting the thought out there for comment… 
All of @Jeff-UK and probably more - witness last nights thread with the 200+ LWL01’s that weren’t getting provisioned, not particularly due to finger issues, but if there was something to scan that had enough info in it to just make it happen, all of that angst would have been avoided and the OP wouldn’t be spending the day typing in long complex strings between now & Christmas.
Yes, it will be streamed on YouTube and available after
That is definitely the idea. LoRa Alliance members get a vendor ID and so they can make their devices recognizable for the entire ecosystem. It’s just that we need to decide whether we make TTN’s vendor ID available for the community to use, for end-to-end testing.
Right. This is exactly what we’re addressing today in the webinar.
Hmmm, interesting - I wonder if there will be some general purpose ones made available or allow someone to sell a sub-section of their ID in the same way I get my EAN’s - not strictly the scheme, but allows the smaller businesses to have proper IDs where being a member would be prohibitively expensive.
Hi
Isn’t it possible for every seller to use a QR code to get the necessary info?
Ok it would be a different one and they need a website with the info behind it.
It’s a bit more technical - still need to review the info, but it gives setup information for the individual device and would be something the manufacturers would provide in the first instance. But like everything, it’s a new system and will probably evolve. See the links in @Jeff-UK’s post above - the PDF is only 16 pages so from my perspective, one bath long.
If you want to make suggestions, The LoRa Alliance will be happy to receive your $20,000 membership so you can contribute to the committee meetings
The proposal is more than just QR.
But everybody can make a QR code with the most needed id’s and other info or a link to a webpage with the needed info.
The included QR code should redirect to this forum.
Yes, anyone can make a QR code (not that I said it was just about QR codes or that only special people can make them) - but will it provision your device? That’s the point of this specification. Network & application server interfaces / API’s that can pick up the information can then automagically enter the relevant keys & EUI’s without anyone having to copy them from labels.
And as part of the specification is embedding a LoRa Alliance Id, for now it will only be special people that can do this.
For me there are 2 issues (at least)
a) manual typing (errors) --> every QR implementation can remove that.
b) The complete provisioning of you’re device. It’s not wise to limit those that want to do that.
BTW. While scanning the document I also found that there’s some improvement aka a “quick win” possible.
Well don’t keep it a secret - TTI can pass the information along …
Gas leak detection using LoRaWAN.
AWS IoT Core pricing models here…
Mmm, what about “Network error, message(s) not received”…
Google Android Things inc RPi support sunset phase starts in new year:-
https://developer.android.com/things/faq
At first I was rather angry that this scheme sets a 20.000 euro entry fee for producers that have a speciality device with a low number. They could be using NBiot for the equipment and have a question from one client to make a lorawan version. Adding 20.000 euro at the start for maybe 50 devices is high.
On the other hand everybody that would take a look would find it.
A lot of the encodings are in hex. That’s far from optimal if you use alphanum in QR, which has 44 characters. Using base 32 or base 41 would make for more possible info and shorter QR codes. Given that those would end up on rather small devices, this is a big bonus.