You did right, but: Dragino did wrong. From the LoRaWAN specifications:
6.1.2 Application identifier (AppEUI)
The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the entity able to process the JoinReq frame.
By definition, an EUI-64 address should be unique. In this case: unique per application, but Dragino should not expect customers to share an application, so each off-the-shelf device should have its own unique AppEUI (and DevEUI). As apparently Dragino uses
A000000000000100 for all their LHT65 devices (which was not even assigned to them, unlike their DevEUI which is okay), in theory TTN would not be able to tell the applications of different LHT65 users apart.
I’m a bit surprised that multiple users can apparently add the same non-unique AppEUI to TTN Console, but it seems TTN only uses the combination of AppEUI and DevEUI:
Just to be sure: is the DevEUI indeed unique for each device?
But as it’s still not working for you, and as I assume you don’t want to be surprised in the future: apparently making it unique and using the AT-commands to set that unique value helps. One could simply use the value that TTN generates when one does not explicitly set a value in TTN Console.
No. Devices do not really “connect”. The gateway(s) will forward any valid LoRa packet to TTN, and one can see those in the gateway’s Traffic page in TTN Console. But TTN would not be able to find the AppEUI and DevEUI, so would not know the secret AppKey it needs for a Join Accept, and will ignore the Join Request. Also, even if somehow magically joined (or when using ABP rather than OTAA): where would you expect the data to go when the device has not been registered in TTN?