TABS nodes from Tracknet (now Semtech)

Sensational Systems have kindley created a set of TTN decoders for some of the old Tabs they are distributing on https://connectedthings.store/gb/
https://github.com/SensationalSystems/smart_building_sensors_decoder

In terms of experience have deployed many 1000s of Tab motion some in use for near two years with 50000+ up links. Like other we’ve seen the odd dead battery also if you have early device they have old firmware and don’t join friendly so end up SF12 sensing a join request every x seconds so battery dead after a week or so. Any device manufactured after Dec 2018 has the later firmware on it and has a join back off strategy so doesn’t kill the battery

.

2 Likes

I had both of these problems setting up Tabs sensors (PIR, door sensors, etc). Firstly the batteries weakened because the gateway wasn’t correctly configured (my gateway, my fault!!!). Then when fixed, the weak batteries prevented join requests, despite measuring 3.6v when removed and inactive.
Finally, I found the same problem as chrisjduncan above: despite the supplied documentation telling you to allow the TTN server to generate the appkey, you MUST use the three LoRa keys supplied with your sensors.
Otherwise all works, and the devices are all now connected and working.

Hello, anyone tested how long the Object locator TBOL lasts or would like to check on this?
I am looking for an estimation on how many messages was able to send out over how long till the battery’s dead?
of course the performance depends on a number of parameters including usage and the environment during transmitions but i’d like to get an average figure from a real test that anybody did?

Thanks
H

Anybody who used the “tabs Object locator TBOL” can comment on performance is it any good?

I just purchased some basic equipment in order to start exploring the lorawan funcionality.
Ordered The Things Indoor Gateway TTIG868, a tabs motion sensor model TBMS100 and a temp/humidity sensor TBHH100. It seems I was able to get the gateway up and running, but getting the sensors connected to The Things Network seems to be much more complicated. I hope you guys can assist me.

After placing my order I received 4 codes: Serial Number, DEVEUI, APPEUI, APPKEY.
On the gateway traffic I see a Join Request coming in every 10seconds where I see following info: DEV EUI, App EUI, physical payload, Event data.

I made an application, I push the Register Device button.
I enter following info:
Device ID: motionsensor
Dev EUI: 58A0CB00001130B7 (which I received by mail, and see as well trying to connect to the gateway)
App key: Will be generated automaticly
App EUI: is already filled in with a code…?

Device status: never seen

I tried alreayd different things, searching for 3 hours, and I see I´m not getting further.
I hope someone can give me advice. Thank you

That’s not okay. See Registration of node with pre-configured LoRaWAN keys - #2 by arjanvanb.

Thank you very much Arjan, that solved my problem.

Does anyone have any details on how to reset the tbhh100 device? I’ve opened it up but electronics is not my forte lol.
The specifics of the problem I’m dealing with is outlined here: Tabs device never seen after re-registration
thank you!

What do you see when you take out the battery? Any numbers visible for the connections that seem to be visible in its FCC report?

Externals

Internals

Just shorting two random pins seems exciting, even if the battery is removed :fearful: @mid-walesha and @Plumbum do you remember where to find those details? (I guess one could also simply ask the manufacturer.)

1 Like

It’s pretty much identical to the photo you uploaded. No obvious numbers that stand out to me. I’ve since tried contacting https://www.browan.com but not received a response as yet.
Capture

thanks!

Short the Battery terminal for at least 10 sec.
Measure with voltmeter from memory you need to less that 2v as board has a Cap/Supper cap and can run upto 16hrs without battery when it’s charged.

It takes at leat 40 sec to boot you will hopefully see short blue flash.
Then after another period 3 ish short flashes together which should be the join request.

3 Likes

Finally got round to looking at this again. Thanks to @iiLaw in particular I have a better understanding of how the device operates. It had been sat on my desk without the battery installed for the last 3+ days as I’ve been busy with other tasks. It seems that alone was enough to reset the device once I replaced the battery. Anyway - the device now works and is sending data once again.
Thank you all for your help with this.

That’s good to hear BTW the motion sensor supports a downlink configuration of the PIR/Motion give me a shout if you want the details.

One strange thing I’ve noticed with the Tabs Healthy Home sensor TBHV100 is that it sends data every 5mins exactly and doesn’t seem to follow the triggers as specified in the manual

Packet Triggers: 60 minute inactivity, 2C delta, 5% RH Delta, 50ppm eCO2, 20ppb VOC

It’s been consistently sending data every 5mins even with no change in the readings at all. Has anyone else experienced this? Obviously this is not ideal as it’s overkill and is going to drain the battery much more rapidly. Is there any way to change this?
thanks

I´m having the TABS Temperature and humidity sensor linked to Cayenne/Mydevices. The sensor is located in my car for some testing, but every time the temperature rises up to more than 30ºC, it seems I´m getting a temperature 120ºC less than the actual temperature.
What can be the reason for this strange behavior? Anything I should check?
image

What binary data do you receive? Using that, you can decipher what Cayenne data type is used, and what value is sent.

(Also, I assume there’s no Decoder in TTN Console?)

I think this is the payload I´m receiving from the sensor:
image
image
The first two readings are giving me a wrong reading, the one in the last screenshot looks good.
I´m not sure how to proceed with this info.

Ah, my bad, I figured that meant the device was using Cayenne LPP, hence I linked to that protocol. But the payloads you’re showing are not LPP.

Given the port number 103 and the the other decoders that @iiLaw linked to it seems Tabs might always be sending the temperature value as 7 bits and with an offset of 32:

// Board temp measurement
temp_board = bytes[2] & 0x7f;
temp_board = temp_board - 32;

For your payloads, hexadecimal 0x42 would then decode to decimal 34, 0x41 to 33 and 0x3D to 29. So, that would work. But as your payload is only 8 bytes long, maybe that decoder simply does not apply here. Still, based on only this, it seems the sensor’s payload is okay so something is wrong in your myDevices setup.

Without knowing what values were displayed (and expected) for these specific payloads, it’s hard to help. I don’t know how things are decoded in myDevices, but to allow others to help you, I’m quite sure they’ll need many more details about your setup in TTN Console and myDevices. Also, the exact device type, any maybe even a link to its documentation might help.

I got a TBMS motion sensor node and plan to put it in a bat box to see if the bat box is actually occupied with bats. I got it working with the EUIs from a piece of paper that came with the node. There is a QR code on a sticker on the node, with the app EUI and device EUI, but the app key is not on there.

Does anyone know if the app key can be derived somehow from the dev eui or app eui (for example) for these nodes? This would save me from having to keep a separate list of devices and their app keys, with error-prone manual copying from the piece of paper.

I guess you’re aware of the security implications if that would be the case. But just to be sure:

The AppEUI and DevEUI are not secret. That’s why they’re often printed on the device. Even more: they are transmitted without encryption during the OTAA Join Request, along with a MIC that is calculated using the secret AppKey. Anyone who knows the secret AppKey (and can guess an unused DevNonce) can trigger a valid OTAA Join, after which TTN will invalidate the existing secret session keys that it exchanged with the device during the previous join, effectively taking it offline. And after that, the attacker could send fake data as well. Or if an attacker would capture the device’s Join Request and TTN’s Join Accept, then when knowing the AppKey it could derive the secret session keys and decrypt the data the device sends.

Even worse: EUIs are not random. If all is well, then a manufacturer purchases a block of EUIs, so most often batches of devices simply use subsequent values from such block. That would make it even easier to just randomly try combinations of AppEUI and DevEUI, allowing an attacker to take a lot of devices offline.

If the secret AppKey could be derived from the AppEUI and DevEUI then I’d look for another device.

(Aside: I tend to type such values into a text editor twice, on two consecutive lines. That makes it easy to spot typing errors. But indeed, it’s very nice if manufacturers include the AppKey in a QR code as well, as long as that QR code is not printed on the device.)

2 Likes