Dears
I plan to add several devices to my app, mostly of them with an own AppEUI. I wondering if there is a limit to generate AppEUI’s per application. Or does it make sense, to balance the devices to several applications with less AppEUI per application.
What is your advise ?
Thanks a lot
How many is several, 10, 100, 1,000, 10,000??
in the future potential >10’000. I’d like to avoid to reach a limit, because the device registration is implemented via API and driven from an external app
10,000 devices on the community edition of The Things Network - ambitious, brave, maybe foolhardy - depending on what the devices are measuring.
I can’t imagine that there would be a particularly artificial limit but various elements of the fair use policy and how many calls to API’s may impact on all of this.
Why so? Come on Nick dont knock it - where is your ambition? 
Easily done with say just 100GW’s each servicing 100 nodes… easily reached with say 100 schools, 100 business parks, 100 student accomodation blocks, 100 rivers being monitored, 10-100 car parks, 100 fields with 100 cows or whatever.
Routing performance for TTN back-end is pretty good, even if the Console resiliance sometimes lets the side down 
and of course there are multiple Integrations in place to faciliate a wide range of use cases and expansions…
Key point is to choose use cases and applications where rapid updates/large data payloads are not needed, dropped/missed packets can be tolerated mitigated against or are none critical and where lots of command and control/downloads are not needed and 100% uptime & 100% routing isnt essential…if it is then basically dont use wireless tech!
Mitigating the end node link resiliance problem, or GW to NS backhaul connectivity & resiliance can be helped by deploying multiple GW’s in range of the node - i.e. coverage density or ‘densification’. And that can be readily achieved by all collaborating and sharing in a community to deploy many 10’s even 100’s of GWs in a region (e.g. TTN Zurich), whereas any private company or individual may only be able to afford deploying 1 or 2 in a given area, unless setting up as a full private or public service provider. Strength and resiliance through mass collaboration and herd behaviour… ?
Biggest issue tends to be folk taking their GW down when ‘they’ dont need it (holidays if going away /weekends or evenings say if only testing in office during working hours/weekdays or daytime if a hobbyist out doing a day job and only working on TTN when back from work etc. and the more users and GW’s in an area the lower the impact of any one GW being taken down…
If community network becomes a problem or limitation (e.g if Fair Use Policy starts to be enforced) to your ambitions then migration to TTI or Private V3 Stack instance should be an ‘easy’ option, with the TTN Community Network effectively serving as a massive and scaled test bed… what’s not to like?!
…might say it would be foolhardy to ignore the potential and opportunity…
That sounds like a commercial application so I would encourage the use of your own EUIs. Don’t abuse the community resources (the limited block TTN makes available) for this purpose.
To be fair, 10,000 of anything other than production isn’t my thing other than making sure it’s scalable to the level anticipated x 10. As soon as someone needs to schedule time for administering stuff on a regular basis, that’s support desk / dev-ops and that is SO not me, you won’t be able to see me as I light-speed out the room due to the quantum nature of the wave-lets of photons. Next phase PoC, experimentation, new gadgets, new storage 'scope, perhaps new mouse mats, I’m all in!
I think the context for me is that if you can afford 10,000 devices, you can afford TTI or your own backend servers - that way we don’t end up with a forum post titled “Please help, major disaster, 12,847 devices offline” that is entirely in the hands of the TT crew or has just reached a tipping point on TTN.
Stuff 100 devices in to an app and see how it feels, maybe go to 1,000, but with your own EUI’s and then see if 10,000 on TTN makes sense.
As for a 100 cows, just the small herd then? 
Thanks for all the feedback. The devices shall be a part of a NPO initative to collect environmental data to be shared with all members. A member can buy a device in the NPO store or bring his own device and can register the device in a web portal or mobile app. The backend registers the device in the ttn via API.
My initial questions points to the second option when members bring the own device: to register, the user has to provide a Device ID (easy) , a Device EUI (easy) and a App EUI. Last is not clear, because the App EUI is related to the application but provided by the device (i.e. a draguino LT3322). I assume I have to assign a new AppEUI ID for each device I register.
What stops you assigning an AppEUI from the TTN console? The Draguino LT3322 allows you to set the AppEUI, as do a whole range of other devices.
Perhaps you need to plan around the logistics and consider listing appropriate devices that you can reasonably commission. If you anticipate 10,000+ devices and only 5% are the oddball ones, that’s 500 you have to find a way to make them work.
Why do these devices have different AppEUI’s?
Do you mean each and every device actually has their own unique AppEUI?
This is not what AppEUI was meant for and will require each AppEUI to be separately added to the application. Even when automated this means double registration actions for each and every device, both at application level scope and at device level scope (in the application).
I can now understand your question of how many AppEUI’s can be added to an application.
Adding large numbers of AppEUI to an application has possibly not yet been tested before.
In that case I would suggest to contact the manufacturer to prevent them from putting unique AppEUI’s in every device.
ok, understood.
Either I’m able to change the AppEUI on the devices to a default one or I have to add a new AppEUI, (which is already configured on the device) to the application.
As I understood from kersing, I should use my own AppEUI. That will be the case.
Second, in case we provide the devices, we can change the AppEUI or aks the provder to do it. For the the BYOD, that will not work.
Oh yes it will if the device allows it to be changed. As I said, if you leave too much scope for people to do what they want, you will end up with a huge pile of admin work. If they want to join in your scheme, surely it’s not unreasonable for them to change the AppEUI.
Or are you thinking they get you to do all the setup on a new TTN account - how will you then collect the data?
This sort of situation is where User Stories come in to play - where you think through what different participants in a project may want to or try to do.