Hello, I am having trouble registering a parking sensor in my application.
The sensor is the newest (I think) version, v0.39.2 and not in the device repository so I have entered all the info manually using this document as reference.
I have found everything I need and how to devive the DevEUI from the info on the sensor but nothing about the AppKey. The document explicitely stated that it is pre-provisioned and this (admittedly old) video states the same here. Also the few posts on this forum all talk about their provided AppKey in regards to this device.
My main question is, If I attempt to register the end device with a generated key and fail would it present trouble later on if I get the correct information?
From what I understand I should at least be able to see the join requests of the sensor in my console (provided it connects to a gateway and I have the entered EUIs correctly)
I have contacted the shop I bought from and am waiting on clarification but I wanted to see if anyone here has had experience with these devices and can provide any insight.
Registering a device with a AppKey that is not the same as the programmed one does not make sense. All message integrity checks will fail and the network will drop all uplinks.
Youâll need to wait for the key to be delivered by your vendor.
You are right, I think I just got impatient/too earger to start working on this and I was just looking for something to see life on the console. I will just wait and (hopefully) register properly.
I understand I would not get uplinks without the AppKey to encode the accept-join but, just out of curiosity, am I correct in understanding that (assuming correct app and devEUIs and a connection to a getaway) I would be able to see the join requests of the sensor?
The sensor has no connectivity of any kind that is accesible to me. It does not even have a user accesible power switch, the switch is magnetic and it turns on when its is mounted on a provided plate at which point it supposedly starts transmitting join requests.
That is the behaviour I expected, thanks for confirming.
Again sorry for the beginner question, I have not onboarded any gateways of my own yet, I am relying on the Community Edition infrastructure to do some initial tests and confirm some assumptions. Would the live data on my application console also show these requests?
Thanks for confirming and also for the heads-up, that was one of my concerns, mainly because it would be a waste to leave it hanging over the weekend while I was waiting on the appkey.
If anyone stumbles on the thread here is the expected behaviour: PLS| Communication Interface - Technical Description rev.2 pdf
Always good when trying to set up and debug new devices to have your own gateway close by so you can monitor traffic and any error issues etc -speeds up onboarding and device debug - a cheap indoor GW would be fine and ofcourse you are then also helping build out the community network so its a way of giving something back
The first standard assumption being that you are definitely in range of a gateway. Which is discussed to death on the forum, TL:DR is likely not unless itâs within 500m and the property in question has an antenna array that rivals NASA that you can see out of your window - itâs Line of Sight radio waves, not bendy HF ones.
Thereâs no real need to confirm too many assumptions - LoRaWAN has evolved to most reasonable boundaries being known - this is like buying a TV to check you do actually get pictures but without the antenna / fibre - it may be simpler to ask your questions so you can get straight to a use case.
Mainly what I am trying to test has to do with the integration and the viability of the sensor for my use case. However,
understood, point taken. I did place a fair amount of hope that I could make use of a few far (1.5-2 km) and not quite line of sight gateways (there are is a hill that I have identified as possibly blocking one, the other is possibly on ground level) to do some initial tests. Even if by moving my testing to the roof of my building,
As I understand it you would classify the possibility of a successful connection with those parameters as more than wishful thinking?
In any case I will re-evaluate and get a gateway as soon as possible. Is there any benefit, outside the learning experience, in choosing a Raspberry based + concentrator solution rather than the indoor gateway? Range, versatility? I will look into these, I suppose it has been covered in the past.
Iâd personally classify it as almost entirely wishful thinking - but you are not alone, this is a regular wish as evidenced on the forum.
One of the RF onion layers (see below) for Line of Sight adds the Fresnel Zone complexity in to the mix - so LoS is not always LoS. And not all community gateways are well fed & watered.
Nooooooooooooooooo!
Not the second standard assumption in the same topic - itâs a sign I say, a sign of impending doom!
Gateway range TL;DR: Only one source for chips, itâs hard to make concentrator card so none of them are hacked together = same range for all gateways - itâs all about the antenna & placement. Again, all over the forum.
Anyone âdoingâ LoRaWAN should own a TTIG - itâs a small low power consumption box that has so few buttons you canât fail to have it just work (although people do manage this). So you know you have a gateway that is just there and can help diagnose stuff.
I thinl a gateway is a waste of a Pi - lots of grunt thatâs never used. But good to try it out - so you can do the Raspberry Pi mambo, play with the reset pin settings for a week, use the Packet Forwarder, worry about being hacked on outgoing only connections, dig in to getting Basic Station running on it for âsecurityâ, hold a wake for the SD Card that didnât get backed up, etc etc. If you really need a Pi based gateway, a RAK7246 is good.
Youâll find that LoRaWAN is like Shrek & onions - many layers.
Side observation on the Bosch PLS - itâs on the ground - second worst place to put a device for radio waves (worst being a locked lead box at the bottom of a mine). So your gateway needs to be above it.
I possibly misscalculated (or just did not fully understand) when I was trying to get a max radius but I using wikipedia and (i think) the lorawan academy videos I got an approximate F_1 = 13.7m for the gateway I know is on the roof of a ~3 story building. So I hoped that at ~7m when it is ~10-12m above ground LoS would be a resonable approximation. Still only in theory but as you say not a very original wish. Edit: Just reread what I wrote. My hopes turned radius to diameter and halved the distance furtherâŚ
Hahaha sorry for reenforcing your worries. I commented a bit too fast on that one.
Understood, about what I expected. I will possibly try to get this running as a seperate project for fun/ curiosity call it what you will.
Imagine if I told you the next iteration of the sensor (or a variant not sure) I saw in a presentation on youtube will be below ground level in a drilled hole, to hide it further and protect it from snow plows etc. Anyway at this point I will probably be holding the sensor above my head, on a ladder, on my rooftop I am still a ways away from practical deployment.
The sensor sends an uplink (apart from the occasional heartbeat) on state change (change being defined as a cetrain amount of time with and without obstruction) so basically half the usefull messages will be impeded by the lump of metal. The most brazen numbers I have seen about similar parking sensors in advertized solutions talk about 0.5 mile, so about 800m, from sensor to gateway. And I am sure redundancy in covarege is glossed over in the presentation.
At this point I am quite far from that. Testing with the sensor over my head etc
There are calculations that can be performed. But they require interpretation based on head-bangingly painful experience. Plus luck, sometimes good, sometimes bad. And sometimes chicken innards.
For example, for countryside thatâs not on the east coast of the UK (where there are some interesting radar installations we arenât going to mention again), there is some topographical calculation software that will tell you what coverage youâre likely to get.
Anywhere else has to be based on observation - the gas cylinder that reflects the signals in a random pattern when itâs full, so subject to change. The new hi-rise thatâs got a steel frame that is just right to block signals. As I say, so much discussion on the forum.
If you are deploying sensors to an industrial park, things are a bit more uniform. But urban / city-centre environments are a bit of a lottery.
The best calculation is to figure out how many beers you deserve after youâve got on your bicycle and gone out mapping reality. For which TTN Mapper will help.
How do you know a marketing person is lying? His lips are moving âŚ
