Bosch Parking Lot Sensor with The Things Stack

hi everyone

i’m going crazy!!!
i can’t configure/install the Bosch Parking Lot Sensor right.

Gateway Hardware:
The Things Network Gateway Kickstarter

Status:
Installed and seems like it runs right.
All 30 sec. new message with status and so on.

Device:
Bosch Parking Lot Sensor Firmware Version 0.39.2
AppEUI, DevEUI and AppKey are given by the manufacturer.

So i can’t change them (don’t have acces to the device).

Issue:
i get live data only sporadic from the bosch device.
the device is installed.
live data shows me that it has joined the network

and the first few messages shows up.

but after that, it stops and sometimes there happens for hours nothing on the live data overview, seems like no messages.

then the next day, when i take a look again on the live data view, overnight or in the morning happens something and messages shows up.

but the device should send after all 30 seconds a message.
and also when e car drives over the sensor a message with “occupied: right” and when the car leaves/the sensor dont detect something over itself it sends a message with “occupied: false”.

i deleted a few times (as already mentioned in a earlier post) the devices, applications and the gateway…maybe this can be now the issue?

it’s really strange and i lost so many hours and days with the issue…and i don’t know what to do anymore.
maybe the devices are somewhere in the backend or whereever stucked, because i deleted the devices, apps and gateways a few time?

what about the settings?
if the settings wouldn’t be right, i wouldn’t get even any message…

so if anyone can help me with that, just to get the sensor run and doin it right, would be great.

and sorry for the huge text, but maybe this reflects my despair :slight_smile: :neutral_face:

kind regards
albert

Which, depending on message size and spreading factor would almost certainly mean you are exceeding TTN FUP, and possibly, depending where you are in the world, the local legal D.C. limits! Is this a period you have set? Can you change settings on the device? Occupied/un-occupied changes seem legit. Does the device put itself to sleep to save power between vehicles/updates, or after a quiet period (explaining why device ‘appears’ to have disappeared)? Device then waking up and continuing to send messages when a vehicle in proximity or parking state change…

1 Like

Firmware version v0.39.2 for a commercial Bosch device?
I have no experience with this device but the firmware version looks like a pre-release.

Hopefully the uplink period can be configured (possibly via downlinks, see docs).
Why frequently sending periodic status messages while only state changes (occupied/available) need to be communicated?

The problem with applications like parking lot sensors using LoRaWAN is that you quickly want to be informed if a parking lot gets occupied or becomes available. In this case you want to be sure that the application receives the message.
Delivery of LoRaWAN messages is not guaranteed and can only be verified with confirmed uplinks however.

There is a FUP limit of 10 downlinks per day which means max 10 confirmed uplinks per day which in many parking situations will not be sufficient.
When delivery of uplinks is not confirmed, how to be sure that the message gets delivered?
You can’t but you can increase the likelyhood that a message gets received by sending it multiple times (with intervals between).

Maybe (very) frequently sending status update messages even while the status has not changed is Bosch’ ‘solution’ to the above?

Others with experience with this device can probably give more information.
Possibly many options are configurable (via downlink messages).

1 Like

because…

It is not untypical in such applications to send regular status messages… the change of state message as a vehicle arrives to park in the space might get missed - a status update 10 mns later might catch the new cars presence - so the parking operator only risks loosing 10 mins of parking revenue, similarly the car exiting may get missed, but then the next status message allows signage to be updated with free space count with no more than a 10 min lag. also where parking is associated with automated billing this allows a reasonable resolution for correct billing periods etc. Also in UK, and many other juridictions, it is usual (in many cases enforced by law) for parkers to be allowed a 10 min grace period for any time over runs before incuring penalties so a status update say 10 or 15 mins after a parking ‘event’ is normal…status message may also update on e.g battery levels etc.or do things like provide information on ice formation or if there is a covering of snow or ice allows the controlling application to temporarily allow a command down to increase SF or TX power under ADR (like mechanism) to ensure correct operation continues during the temporary coverage period…as snow accumuates the stats for the status metadata wrt RSSI & SNR and be monitored and adjustments made accordingly (had many a good discussion with traffic managemnt/parking lot management companies and their engineers over the years! - wont even start on the stats purturbations that can be seen with large/dense (from RF perspective) vehicles park for long periods in adjacent slots etc.). Have also seen comands sent to change update rate during daytime and night time to reflect likely parking lot useage (Actually many lots can even change update rate during typical busy arrival/departure times to reflect e.g. likely hood of say an office worker coming in and parking 7:30-9:30 and then not moving again until 4-7pm - no point updating every 5 or 10 mins through the day for that target audience and likely 1/hr over night!)

1 Like

thank you @Jeff-UK and @bluejedi

with your informations and questions you helped me out.
great!
now i see my big problem and have to change the solution.
because with this Bosch Device it won’t work like i need it.

thank you so much and kind regards

1 Like