Hi all,
The new TTN release asks for a JoinEUI during an ABP device registration. It seems a mistake that hopefully will be corrected soon. If it’s not, can someone explain me why we shall need this?
(ttnv3 22.1 , manual registration of 1.0.1 ABP device).
Thanks,
Join eui is a naming convention change….it is what used to be the AppEUi
OK, so same question with AppEUI. Neither of them (AppEUI or JoinEUI) is used in ABP.
On what basis would this be a mistake - someone at TTI accidentally put the field on to the web page in a moment of madness??
Consider it a hint that OTAA is by far and away preferable. But if you must, you could just use zero’s.
Not if you don’t file an GitHub issue. TTI does not use the forum for bug reports.
Will be corrected in the next release, so topic closed.
Impressive how responsive the developer team is. Congrats guys. Thanks for the hint @kersing.
Hey everyone, thanks for reporting. This was indeed a quirk that adventurously made it into the release. I worked on a fix today and yesterday that will resolve this. Obviously, for ABP devices, a JoinEUI and AppKey are not required and the whole JoinEUI check can be skipped.
Indeed, OTAA should be preferred whenever possible but it’s not illegal to use ABP and the device onboarding is also meant to allow doing this in a logical way.
It appears that the field to include the DevEUI has also been removed.
This is highly important information for our application.
DevEUI was not required for ABP end Device prior to version 1.0.4. Indeed, it’s written in the specs :
When registering an ABP end-device, you’re able to enter this field only if you choose 1.0.4 LoRaWAN version.
But I agree that if you’re using DevEUI in your application that could be annoying…
Hmm, I see. I’ll look into adding the field back then (as non-required field). Also it should be added to the general settings panel then.
V. Important (and urgent) as e.g. cayenne/mydevices use the DEV EUI to register and I guess then filter receipt of any messages forwarded through the associated integration/webhook! 
Please please test changes before implementation!
Obviously, we do test before implementation (and the generally smooth roll-out of the new onboarding proves that) but it is nearly impossible to foresee every possible consequence of onboarding changes
and any of their exponential number of combinations. We’re sometimes forced to iterate based on progressive insight. I get the frustration, but I also hope you can understand that something like setting DevEUI on <1.0.4 ABP devices for use in cayenne/mydevices just happened to be edge-casy enough to slip through and be fixed iteratively.
Hi Kevin, do appreciate that, and am not being sniffy about it! You guys have a tough job maintaining and keeping on top of all this stuff! 
As you say regression gets harder with every passing day and each new feature and spec change… just suprised to see something as fundamental to device identity as the DEV EUI being called out as a corner case issue. 
Ensuring correct entry of Dev Eui, along with other identifiers and keys, has been a key item called out on the Forum posts since long before I even started using. Given there are featured/high profile integrations for the platform - of which cayenne is just one, and TBH one of the easiest for many and one that has been around a long time, I would have expected/hoped a check to see if a change breaks one of these key integration capabilities would be part of the regression suite?! Not sure if other integrations use the DEV EUI of the top of my head, (believe e.g. TTNMapper is device id, rather than dev eui, focussed) no doubt others will chime in if the Dev Eui needed for other than custom apps…
This isn’t a testing issue, it’s an engineering / design issue - somehow this change got put in to the plan and escaped the eagle eyes of those that have read the LoRaWAN spec.
Any change other than typos etc, could reasonably be assumed to be reviewed by someone else that is either actively using the console or has that detailed knowledge of the MUSTs / SHOULDs / WILL.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
This issue has been resolved on TTN and TTS Cloud.