I have switched 5 identical (apart from keys) LMIC based ABP devices from V2 to V3 and 4 of them work fine but one does not. I don’t have physical access to the devices - they are mounted on lamposts around my city. But I have no reason to suspect the device because it transmitted just minutes before the switch.
I have double/triple checked the deveui, devaddr, newskey and appskey of the non-working device. They were copied from the V2 console and pasted in V3. The device was then deleted from V2 as with the other three working devices.
I have tried setting/unsetting “Resets frame counters” but it appears to make no difference. The devices which work have this option set.
It would appear that the last time the device was seen on V2 it was seen by a council run gateway which might still be on V2. I have no access to view the gateway traffic.
No data is appearing in either V2 or V3. I have MQTT programs running which subscribe to both and I am not seeing any traffic from the device only from the working units on V3.
I am at a loss as to what to try next so I’m open to any suggestions - even dark satanic incantations.
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?
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.
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.
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.
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.
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…
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.
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!
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…