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 @iiLawlinked to it seems Tabs might always be sending the temperature value as 7 bits and with an offset of 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.)
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 "
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.
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.
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.
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.
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.
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.
Just wondering if someone here uses TBOL100 Browan Object Locator devices.
I try one to track a moving object, and while TBOL100 does what I expect it to do - start sending locations every 2 minutes, when moves - it does always send GNSS fix that has been 2-3-4 minutes ago. So while roundtrip time from the sensor via my own gateway, then through TTN to HTTP hook of my service, then to the app is 1-2 seconds, position reflected in the app is 2-4 minutes from the past.
This kind of defies the purpose of real-time object tracking, and the end device is the culprit.
I wonder whether this is by design, or there is some parameters in TBOL100 I can tune? This doesn’t seem logical, other sensors do send realtime fixes but this is the lightest one and hence preferable. Firmware upgrade?
Well, I did send 00 1E 00 on port 204, as described in manual, but it doesn’t seem to have any effect on the device.
Now it still sends every 2 minutes and 30 seconds.
I believe the commands have to be sent as confirmed downlink messages. I’ve seen a TBMS100 respond with a configuration settings uplink message each time a configuration command was sent. Do you also see that?
If it isn’t working for you, I think you should contact the manufacturer.
I tried with confirmed too, same effect. And yes I’ve written to BroWAN, no response yet…
The problem is not in the frequency of the updates as such, the problem is that each update comes with a fix (real position) that has been 2-4 minutes ago - as seen visually and on another trackers.
I wonder if there are any other similar devices, LoRaWAN GNSS and <50 g weight… that one fits my case quite good, be it not for real-time fixes…
"