Parking Sensor with TTN Gateway

Gateways TTKG - The Things Kickstarter Gateway
1

Hello everyone,

I am very new in this comunity and have no experiences with IoT and Lora. But i want to install parking sensors with the TTN Gateway and the whole TTN Backend stuff for my master thesis.
Till now i activated and installed the gateway successfully. For another project I activated an temperature sensor and receive the temperature via the gateway, so it’s working. I could write the appEui and the appKey to the sensor via USB cable.
My problem is that the parking sensors havent got a USB Interface, so I cant write the keys on the sensors nor configure them. I ordered the parkins sensors from this page http://www.iotsens.com/sensors_en/smart-parking-sensor-road-surface/ and received them without any installation or configuration instruction. After research I found similar sensors (https://market.thingpark.com/iot-devices/parking-light-sensors/geomagnetic-vehicle-detector-surface-mount#) with a short documentation (https://drive.google.com/file/d/0B6TBYAxODZHHa2pFN0dMWWR6alE/view). The documentation says that the sensors are always sending 5 Bytes, but the gateway is receiving 18 Bytes?!

After activating a parking sensor it sends three times data and remains silent after that. It doesnt sent any join request to which I could reply. Following an example of the payload: “80 52 00 03 70 80 02 00 01 78 9D C8 A9 F2 99 BC 7C A8”.

I want to forward the payload to an application which will forward the data again to a HTTP-Server. Is this possible without a successful join?

Has anyone experience in working with parking sensors and lora or any idea I could get further?

Thanks in advance :slight_smile:

2

start by asking the documentation from the seller ( iotsen)
I find this a strange story btw

3

What do you mean with strange story? From the seller?
I allready requested some documentation waiting for response. Maybe someone had similar issues or experiences with parking sensors?

4

snow plugs will remove all those sensors mounted on the streets, probably. normally there is a distance of 5 cm… but: who cares?

5

yes … you should get the documentation from this LoRaWAN (?) product.
hope you find/get it soon, without you’ll never get it to work on the TTN network.

you probably need a kind of ‘bridge’ between these devices and LoRaWAN

6

The seller replied to me with user manual (1.1 MB) and a table with codes for registering the devices. After registering, setting activation mode to ABP and performing the command

./ttnctl devices set device_id --override --dev-addr device_addr --nwk-s-key key1 --app-s-key key2

via cli, I dont receive data by my application. In the gateway traffic console I can see the following uplink:

{“gw_id”: “de_hbrs_prosywis”,
“payload”: “gFEAA3CABAABrBXBDVqhFYB8”,
“f_cnt”: 4,
“lora”: {
“spreading_factor”: 12,
“bandwidth”: 125,
“air_time”: 1318912000
},
“coding_rate”: “4/5”,
“timestamp”: “2018-01-25T16:15:54.413Z”,
“rssi”: -36,
“snr”: 8.5,
“dev_addr”: dev_addr,
“frequency”: 868100000
}

Getting information about the device via cli:

Application ID: app_id
Device ID: device_id
Last Seen: never

LoRaWAN Info:

AppEUI: app_eui
DevEUI: dev_eui
DevAddr: dev_addr
AppKey: <nil>
AppSKey: key1
NwkSKey: key2
FCntUp: 0
FCntDown: 0
Options: FCntCheckEnabled, 16BitFCnt
7

@Dolsch what are the first 2 digits(prefix) of the dev-addr of your sensor? The ttn broker is probably dropping the packets. :confused:

Check your gateway console traffic for the devaddr you should see the data being received and dropped instead of forwarded.

You should read this whole post and it’ll give you a better understanding of what’s happening and the fate of your sensor.:
https://www.thethingsnetwork.org/forum/t/pycom-lopy-gateway-drops-packet-with-no-brokers/10043/6

Here are some highlights from the post:

8

Good call: it’s 0x70030051, which has not been assigned yet:

Also, TTN will indeed not handle it, regardless any --override.

9

Many thanks for your responses.
I tried to setup a private routing environment and change the gateway sending his data to this backend. But I couldn’t find any chance to change the server address except of the router. But I think its not the right way. I used

ttnctl gateways edit <GATEWAY_ID> --router-id 192.168.2.121

But I dont receive any up- or downlink at the bridge. After rebooting the gateway it has problems with the config.

Is there any way to use the official TTN gateway in a private environment? It has to be a private one because the TTN broker (I think) drops the the packets. :frowning:

(I asked the question allready in TTN gateway central)

10

yes and I removed it because it was not ontopic there.

did you really read this ? https://www.thethingsnetwork.org/article/setting-up-a-private-routing-environment
its not that simple.

Did you contact the manufacturer and ask them how to change/program their sensor… that would be easier

11

Hi, yes I contacted the manufacturer and they said that it is NOT possible to change the devAddr of the sensors.

Yes I read the tutorial carefully and get the environment running.

The last problem which was left is changing the gateway sending to my private environment. If this is not possible I have to use another gateway… Therefore I need a confirmation that I this is not possible.

12

Just in case it helps: if they advertise the device being LoRaWAN compliant, then: it’s not.

1 Like
13

On their website they say

Sensor system fully compatible with Lora and Sigfox technologies to enable long range and low power consumption

but in the uploaded user manual

Its fully compatible with LoRaWAN technology.

So is it right that I can not use the parking sensors with a devAddr beginning with 70 and is it too right that I can not change the official TTN Gateway to use a private backend, which will not drop data from the parking sensors?
If both is right I will send the parkings sensors or the gateway back. I just need a confirmation from someone with experiences.

A lot of thanks in advance.

14

Correct. Those have not been assigned by the LoRa Alliance, so you could say they’re “illegal”. Of course, anyone can do whatever they want, but as soon as they are using the LoRaWAN logo they need to adhere to the rules of the LoRa Alliance.

Note that according to some messages at Slack, apparently Actility/ThingPark Wireless does support whatever DevAddr it gets. But: I would not rely on that unless they explicitly tell you they will keep doing that in the future:

@cruzer 2017-12-02 10:27 AM

Hey guys, just want to ask some help if someone can point me to a direction where to find the solution.
My problem is this TBS-220 Parking sensor running AS923.
I have a RAK831 gateway running in Raspberry Pi host, and it can’t seem to get the data coming from the parking sensor.
I know the sensor is working because it is working in our “thingpark wireless” platform, but can’t seem to make it work in TTN.

…

@arjanvanb 2017-12-04 9:57 PM

@cruzer I guess you considered this, but in case you did not: if you continue to use Actility then I’d ask them about support of 0x70 addresses in the long turn, before getting more sensors. Just like TTN, they should only handle their own NetID…

I don’t know:

  • Your attempts to use @brocaar’s lora gateway bridge with the TTN Gateway are wrong, as the TTN Gateway is simply not using the Semtech protocol, which is what that bridge expects.

  • I don’t expect someone to write firmware for the TTN Gateway to support the Semtech protocol. (Also, right now, I would not know how to load such firmware into the gateway.)

  • I’d expect the TTN Gateway to some day support private backends (if those support the protocol that the TTN Gateway uses). But I don’t know if it’s already possible today. Maybe it is already possible.

2 Likes
15

Thank you very much @arjanvanb! Your post helps me a lot that I can discuss with my prof what doing next!

16

https://www.thethingsindustries.com/marketplace/product/smart-parking-sensor

1 Like
17

@Dolsch, just for clarification, I would contact the manufacturer asking what is not possible: a) change the DevAddr by yourself, or b) upgrade the firmware of the sensor by yourself. I am just asking because if option b) is possible, then perhaps you could “create” some DevAddr in the TTN console and ask the manufacturer to compile the firmware with those specific DevAddr-s and send them to you, so you could upgrade the sensors firmware by yourself. Of course there is still an option c): you create DevAddr-s in the TTN console and ask the manufacturer to send you sensors with these DevAddr-s programmed in the new sensors. I am almost sure that the manufacturer will happily do this exchange because negative comments in this forum are not really advantageous for businesses that would like to stay long enough in the LoRaWAN based IoT arena… But this is just my personal opinion.

1 Like
18

And even if the manufacturer does not want to disclose the firmware’s source code, maybe something like the following would still be an option to allow the user to replace the ABP details: