My understanding is that it is not possible to migrate devices with active sessions from The Things Network V2 to The Things Stack Community Edition relying on Packet Broker, because of DevAddr ranges. @snejra @htdvisser can you elaborate here? If the migrated device uplinks to a gateway connected to The Things Stack, would that solve the problem?
Interesting that the other devices are working ok then.
Are they all co located and running through V2 GW’s (and hence PacketBroker) or might the others be in range of V3 GW’s?
That will be an issue. Only packets from devices with V2 addresses received by TTS CE (==V3) connected gateways wil get to V3 applications as mentioned by @benolayinka. Packets from devices with V2 addresses received by V2 gateways will not be forwarded to V3.
No they are not co-located.
I know where the non-working device is located and was thinking of making a known good LMIC based V3 device, driving to that location and trying to see which gateways pick it up.
1 Like
That, to me, doesn’t explain why 4 out of 5 devices manually configured as ABP using the console are working ok when I copy the keys from V2 to V3. Unless they are in range of V3 gateways?
I cannot physically access the device to reprogram it as OTAA (preferred) or change the session keys/devaddr at this point in time. I will ask if it can be taken down and re-programmed after I find out if there’s a V3 gateway in reach.
Thanks for all the comments @kersing @Jeff-UK @benolayinka
That is (almost) certain. You can easily verify this by looking at the gateway information in the data stream for the V3 application. Data forwarded by V2 gateways will have packetbroker in the gateway information. Data forwarded by V3 gateways will have a gateway name.
Ah, thanks for that. Yes, all the others are being picked up by V3 gateways, but there are three V3 gateways (on ttnmapper) surrounding that device (maybe a mile or so distant from the device)
The council man has agreed to take the device down for re-programming, when time permits.
I will still try to fire up another device near it later today - I will be passing there.
Thanks.
Is he aware that there are only 30 days left before the gateway goes offline permanently?
yes.
I have another issue that has just popped up whilst making the aforementioned test device. I know it’s ‘fix one at a time’ but this issue is now stopping my investigation.
I have programmed a Heltec Wifi Lora 32 using LMIC-node as an OTAA device (NOT using V2 keys). The LMIC-node code is unchanged apart from the join keys etc.
The V3 console is seeing the JOIN_REQUEST then telling me the gateway is not connected and the JOIN_ACCEPT is, therefore, not being sent to the test device. So it tries over and over to join.
You can see, on the right, the gateway name bnn-ttn-1 but the console has added @ttn.
The gateway page shows messages are received by the gateway and the regular status messages being sent to tnn.
I guess I can still take the test device to the site of the non-working sensor (hccsensor01) and leave the console open , then come back home to see if the test device has been seen.
I have to go look after my old mum for an hour or so now…
There have been a number of other discussions in the last month on getting the Heltec devices to work with TTS.
Not a hugely reliable strategy as the console will “know” and lose the messages about 30 seconds before you get to your computer.
The console is very mobile friendly - still a bit small - but at least you can see in ‘real time’.
Ok, i’ll try using my phone tomorrow. Meanwhile the test device wasn’t joining anyway - could be because I wasn’t at the top of a lamp post or because I was sitting in my car with a tiny antenna (left the magnetic roof antenna at home).
I don’t think the Heltec has anything to do with the console saying my gateway is not connected. I’m using the LMIC-node code not the Heltec Lora code. I got the same thing with my fake hccsensor01 which is RPi+Dragino HAT based. The message received by TTN had the correct gateway id but the downlink error message on the console had the @ttn tennant added. This is a new phenomenon it has never happened before today. I know we are just out of halloween but … LOL
I will make a new device using keys generated in the V3 console and see if that makes any difference.
@bnnorman A bit off topic but… Just dont rely on an IPad (Air or earlier) running Safari (IOS 12.5.5 or earlier)! - my (and some collaborators & clents) mobile/field workflow has been broken for near a couple of months now - since around the time of main website refresh/update and 3.14.3, 4 or 5? roll out - Can no longer log in to EU1 console, nor go direct to previous console pages in history 
Main thingsnetwork.org web page/menu hamburger doesnt even give a log in option so oauth issues and state cookies seem to be causing a problem with either username or email based log-in. Yet a ancient Samsung phone browser on old Android 6.01 lets me in just fine (Though Main site front page doesnt render log-in option in 6.0.1 or 7 either - you need to head straight to the cluster picker at console.thethings… etc.)…just small and fiddley on phone screen as Nick says… Now having to lug a damned laptop to remote sites, up ladders and masts or for monitoring console live when doing coverage mapping/tests!
Thanks, I’m Android (Samsung A10). I have logged into the console as a quick check.
I suppose I could put my phone into hotspot mode and take my laptop there with me coz I have fat fingers when it comes to phone screens/keyboards.
Which most likely uses Chrome.
Shock news - Chrome & FireFox for iPad is available 
Use a Mac and Continuity to load the page in Safari automagically on to iPhone.
Or bookmark in your browser that uses some sort of sync, do the login whilst in the warm on the sofa with one of those capacitive touch screen dibbers (I call mine “my little finger”), et voila!
Indeed that is a path we are thinking of heading down - closer match to pc/laptop workflow then… but main website still broken for FFox sake! (E.g rendering/scaling/closing pop out objects on community maps etc. ) So still not yet full solution.
You know my aversion to the Chrome monoculture and data slurp!
Perhaps you could relax your Foxing ESR policy for your iPad - it’s not like it’s going to explode …
… oh wait, already done that today. RIP iPad. Thankfully the client is on a different continent.
Guess we are off topic and will need to clean up thread now but funny you should say that… we’ve had 3 (ok a bit older!) iPads die since summer hols… and as of last week 3 Rpi’s ( as used for Gw builds) in Oct alone 
Guess it’s just the age of the kit…
To get back on track. I visited the location of the absent sensor again, setup my laptop watching the console and switched on a test device. Nothing.
It is in a location where there are a lot of avenues of trees…hasn’t been a problem before but may be blocking gw signals nearer to the device.
I’ll leave this here for now.
Meanwhile the other problem of the server not scheduling JOIN_ACCEPT because it added @ttn to the gateway id I have moved to a new topic so it can be more focussed,
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.