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?
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:
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
I am aware of the security argument, and that argument is always uncompromising.
I do not consider/expect a LoRaWAN motion sensor to be a high-security device, but losing the keys would bascially mean you can throw the device away and buy a new one.
There is also no way to recover/reset the keys, like in usual practical security.
A typical (bad) scenario I’m thinking is of, is a conversation like this:
-> "hey Bertrik! I bought some of those motion PIR sensors you we’re talking about, can you help me set them up with TTN?
<- “sure, tell me the dev EUI and the secret key that came with it on a piece of paper!”
-> “huh, piece of paper?”
<- "… better buy new ones 
"
So, that’s why I was hoping there is another way.
Security is always a balance between (in)convenience and keeping things secure. Most people these days are aware they need to keep their online credentials secure, that isn’t convenient but shouldn’t be compromised…
You don’t but other people do. Their building automation might result in heating/cooling/lighting rooms that falsely report occupants when there are none, resulting in financial loss.
1 Like
Remember this?
Also, I know someone in this forum sees an awful lot of data on their gateway from occupancy-detection devices from a nearby office building. I trust them not to try to mess with those devices, but: if they would (and could, by determining the AppKey for a range of DevEUIs), then your devices may be affected too.
This is my payload decoder:
function Decoder(bytes, port) {
// Decode an uplink message from a buffer
// (array) of bytes to an object of fields.
var decoded = {};// if (port === 1) decoded.led = bytes[0];
if (port==100) { //window door sensor
decoded.status=bytes[0];
decoded.battery=((bytes[1] & 0x0f)+25)/10;
decoded.temp=(bytes[2] & 0x7f)-32;
decoded.interval=bytes[3]+256bytes[4];
decoded.counter=bytes[5]+256bytes[6]+65536bytes[7];
} else if (port==136) { //object locator TBOL100
decoded.status=bytes[0];
decoded.buttontrigger = bytes[0] & 0x01;
decoded.movingmode = (bytes[0] & 0x02)>>1;
decoded.nognssfix = (bytes[0] & 0x08)>>3;
decoded.gnsserror = (bytes[0] & 0x016)>>4;
decoded.battery=((bytes[1] & 0x0f)+25)/10;
decoded.temp=(bytes[2] & 0x7f)-32;
decoded.lat=(bytes[3]+256bytes[4]+65536bytes[5]+16777216(bytes[6]&0x0F))/1000000;
decoded.long=(bytes[7]+256bytes[8]+65536bytes[9]+16777216*(bytes[10]&0x1F))/1000000;
decoded.precision=Math.pow(2,((bytes[10] & 0xE0)>>5)+2);
}
return decoded;
}
1 Like
It looks like the forum mangled your decoder…
I got a decoder for all the tabs devices (yeah every 7 different devices in one decoder) for the The Things Stack V3 ready. I did take a look at the one provided by Sensational Systems for the v2 stack and changed it for V3, did a bit ob clean up and added all the other tabs devices as well… now the variables have descriptive names and use camelCase, the battery and temperature is only decoded in one place (because every tabs is providing these information), etc.
You can find the decoder for v3 stack here on github: https://github.com/dasdigidings/the_things_stack_v3_tabs_decoder
4 Likes
Thanks for this lib have found a wee issue when using object tracker details in Git issue.
Thank you @iiLaw for finding the error! I fixed it the way you did and there is a new commit now with the working code. I was only able to test the sound level, humidity, presence detection, light and window&door sensor beforehand because these are in my possession. So i couldn*t test the object locator, water level and iaq sensors with real sensors on my desk.
1 Like
Has anyone migrated these from v2 to v3 already?
There are now a couple of TBMS100/TBHV100 monitoring movement/temperature/humidity in bat boxes in the city of Delft, Netherlands and it would be nice to get them migrated to v3 (before the owner of the gateway they’re now connected to decides to upgrade their gateway). Preferably I would like to reset them remotely so triggering another OTAA. They are difficult for me to access physically.
I checked the manual, to see if there is perhaps a downlink command I can send to trigger them to reboot and do another OTAA, but found no such information. Perhaps someone knows more, maybe even an undocumented command?
Replying to myself: I got a friendly answer from Browan support.
There is indeed a downlink command to trigger a remote reboot of the node, which also performs the OTAA join again. I’ve tested this and it works, I see a new join, with an OTAA performed against v3 and the device receives a new device address, data coming in, etc. This mechanism can be used to migrate nodes from v2 to v3, as described in Migrating OTAA Devices from V2 to V3
specifically if physical access to reboot each sensor is difficult.
I’ll post about this in the https://www.thethingsnetwork.org/forum/c/v2-to-v3-upgrade/migrating-devices-to-v3/104 category later today or tomorrow.
1 Like
Excellent news because after 4 days I’m still waiting for a VOC node to decide the session is gone and a new join is required. ADR moved it from SF9 to SF12 in two days (so the firmware has detected it isn’t getting the anticipated responses) but it hasn’t hit the point where it rejoins yet.
1 Like