Migrating TABS/Browan sensors - remote reboot to trigger OTAA

TTN V2 to V3 Upgrade Migrating Devices to V3
1

As noted in Migrating OTAA Devices from V2 to V3 one of the critical steps in performing the migration of devices is to trigger a new OTAA on the device, so the device receives a new device address / session keys and new network parameters from the TTN “v3” stack. A new OTAA is done for these devices after a reboot or power-cycle.

I have a couple of TBMS100 (motion) and TBHV100 (temperature/humidity) nodes deployed in a location where I cannot easily access them to reboot them by means of a power cycle. So I asked Browan support if there is some other way, like a downlink command to trigger a reboot. I got a friendly reply explaining that this does indeed exist.

You can reboot them remotely by sending the following:
unconfirmed downlink with payload 038000000100 (hex bytes) on port 222
Obviously this will not reboot the node immediately, the download command is scheduled just after the next uplink of the device, which typically happens once an hour as far as I know.

Before you trigger the reboot, you need to make sure that the device has been registered in the v3 stack and OTAA effectively disabled on the v2 stack (e.g. by invalidating the app key), as described in the link above.

I have so far only tested this on a TBMS100:

but I suspect this works accross the entire range of devices.

3 Likes
2

I have 6 new TABS devices (2 Sound, 1 Motion, 1 Light, 2 IAQ) and I registered them for the first time on TTSv3 (they were not previously registered in TTNv2). Out of the 6 devices, 3 of them (Motion, 2xSound) registered immediately and started sending data. The other 3 devices have not sent any messages and haven’t appeared to register at all.
I have deleted these 3 devices from TTSv3 and re-created them, I have removed and reinstalled the battery on these devices, but nothing seems to work.
I tried sending a downlink message, as recommend above, but it doesn’t work as I get a ‘no device session; check device activation’ message. I guess because the device is not registered on TTSv3.

Any ideas?

3

I think the most likely cause is simply entering incorrect join parameters.
Mine came with a piece of paper with two keys, a “network key (in use)” key and another “network key”. I think you need to use the “in use” network key for registration.

Simply removing the battery for a short time does not work to restart the device. It has internal super-caps that maintain the supply voltage. You can discharge them with a resistor, e.g. remove the battery, place a 100 ohms (for example) resistor over the battery connections until the voltage drops below 1V or so. Also check the battery voltage, it should be around 3.6V.

To debug the join process, you need access to a gateway so you can observe the join attempts, and you can double check the device EUI and join EUI. Once you see a join request, look for a join accept in response. The device EUI is also printed on the sticker.

Sending a downlink will not work until the device is OTAA activated on the network.

4

I’ve tried to move one of those over to V3 as well and there seems to be an issue with the firmware. After joining the device seems to freeze. On V2 it works correctly and sends regular updates, so something in V3 triggers an issue with the firmware.
I’ve reset the device twice, both times it joins and then stops all activity.
I want to do some more debugging but this is probably something the manufacturer needs to resolve. Next challenge will be updating the devices because there is no port to program new firmware visible…

5

I had to physically remove the battery, short pins 6+10 on my home Tabs sensors… Then behaving fine on V3

6

Following up on my own message, the issues I had might have been caused by the delayed delivery of packets via the packet broker last week as over the weekend I once again performed a reset and now the device works as expected in V3.

2 Likes
7

hello all,
I managed to get all TABS devices going. Shorting them with a resister for about 30 seconds worked for me. As soon as I did that, I put the battery back in and each one worked straight away and connected to TTSv3.
I had also emailed Browan and they replied, by suggesting to remove the battery for 15 minutes. That didn’t work for me (even 30-40 minutes), but sorting the device with resistor did.
thanks for the suggestion!

2 Likes
8

Just to give a note here too - Our 8 TBMS (motion sensors) hadn’t re-registered after moving them from v2 to v3 devices.

We just removed the battery from each device for about 24h and all 8 devices had re-registered via OTAA afterwards.

[Update]

Taken from a comment of @descartes to emphase this here already:

  1. Before moving v2 devices as v3 devices, we completely had removed the device configuration from the TTN v2 console
  2. We completely re-entered the settings from v2 console as v3 settings including each set of EUI’s and KEY’s
  3. While not every sensor has a button for re-join some need to go through their power cycle (like for TBMS)
  4. This could cause a small downtime of the sensors, e.g. in case for the TBMS around 24h for a full power cycle
9

They wouldn’t re-register automagically. Either you move the exact same set of EUI’s / key over and then change the v2 key so that it can’t decode on v2. Or you update the device with new settings.

10

That’s exactly what we did - removed everything from v2 and added same configuration on v3

11

I was emphasising the point that a v2 OTAA device won’t automagically migrate without either it re-joining on it’s firmware schedule for what ever reason - link check maybe, a downlink to tell it to do so or a power-cycle.

12

I’m happy to report I performed the migration from v2 to v3 for 4 hard-to-reach nodes (2 TBMS and 2 TBHV mounted inside a bridge) successfully last night. As expected, the remote reboot command is exactly the same for the TBHV (temperature/humidity) nodes as for the TBMS (motion sensor) nodes.