Parking space occupancy for car parks and streets

At a glance

Item	Typical answer
Problem	Nobody knows at any moment how many spaces are free in a car park or on a street, restricted bays are blocked for hours, and planning decisions rest on manual counts.
What is connected	A battery LoRaWAN occupancy sensor in each bay, LoRaWAN gateways on roofs, lamp posts and car park levels, and optionally entrance counters and variable message signs.
Who uses it	The parking operations team, enforcement officers, transport planners and, through feeds, drivers in a city or campus app.
Typical first scope	One street segment of 50 to 150 kerbside bays and one level of a car park, about 200 to 400 sensors.
Time to first screen	Typically a day after the first gateway is up and sensors are added, because the codec library decodes common parking sensors. Budget four to six weeks for a pilot including a radio survey and sensor calibration.

The situation

Municipalities, hospitals, campuses, airports and shopping centres run kerbside bays and car parks without a live count. Drivers circle looking for a space, entrances queue while a far level stands half empty, and disabled, loading and short-stay bays are occupied for hours by vehicles that should not be there. Enforcement officers patrol fixed routes and find most bays compliant.

Planning is no better informed. Whether a district needs another car park, whether a tariff change moved demand, or how long people really stay is decided on manual counts done once or twice a year. Existing guidance systems, where they exist, count barriers in and out and drift by tens of spaces within a week.

This blueprint puts a sensor in each bay, keeps the state of every bay and the free count of every area live, stores the history for planning and passes the counts to signs and apps. Hermetry City, the planned smart city product, is scheduled for 2027; everything described here uses parts that run on Hermetry today: the LoRaWAN network server, codecs, assets, rules, flows and maps.

Goals and measures

• Free spaces per level, car park and street segment, live = capacity minus occupied bays reporting, with bays whose sensor is silent counted separately rather than guessed.
• Occupancy rate = occupied bay-hours ÷ available bay-hours over a period. Because sensors report on change, compute it from a counter that reports at a fixed interval (see Automation), not from an average of raw sensor messages.
• Peak occupancy per day and the hour it occurred, per car park.
• Arrivals per bay per day = number of free-to-occupied changes. Average stay = occupied bay-hours ÷ arrivals.
• Overstay events per restricted bay type per week, and the share handled within an agreed time.
• Sensor availability = share of sensors that reported within their heartbeat period, a measure of the network itself.

Planners usually want occupancy by hour and weekday, before and after a change. Hermetry keeps minute, hourly and daily aggregates of every stored key; history tables download to Excel for the deeper analysis.

Architecture

Bay sensors are battery LoRaWAN devices, usually magnetometer, radar or combined sensors glued to or set into the surface. They join Hermetry's own LoRaWAN network server with OTAA in EU868 as class A devices: they send an uplink when the bay changes state and a periodic heartbeat, and listen only briefly after each uplink. See LoRaWAN.

Gateways that speak LoRa Basics Station connect to your organisation's own network server address over a secure WebSocket; licensed routers with LoRaWAN use their own link. On streets, place gateways on roofs or lamp posts so that each bay is heard by at least two; the network server removes the duplicates and answers through the best gateway. In multi-storey and underground car parks, radio rarely passes through more than one slab, so plan a gateway per level or per pair of levels, with Ethernet or a licensed 4G router as backhaul. The gateway map shows every gateway by state, and gateway health is stored as telemetry.

Component	Role	Notes
Bay occupancy sensor (LoRaWAN)	Occupied or free, battery, radio quality	Class A, OTAA. Decoded by a library codec when the model is listed, or by your own codec.
LoRaWAN gateway	Hears the sensors	Basics Station; one Hermetry device each; token shown once.
Licensed 4G router	Backhaul where there is no fixed line	Your own SIM and operator today; eSIM management is in development (Hermetry Connect).
Entrance counters (optional)	In and out counts at barriers	Barrier controller over Modbus via a licensed gateway, or loop detector contacts if the gateway model counts pulses.
Car park counter device	Holds the computed counts as telemetry	An HTTP device in Hermetry, fed by a flow; one per car park or street segment.
Variable message signs (optional)	Show free spaces at entrances	Driven by a flow over HTTP, or as devices with a command catalog.

Library codecs decode many common parking sensors. Their output keys follow the vendor's naming, often a text state, so decide early how to normalise them (see Device setup).

Point list

Per bay sensor, after normalisation. Intervals depend on the sensor model and its settings; heartbeat periods of one to six hours are common.

Point	Telemetry key	Unit	Source	Interval	Notes
Bay occupied	occupied	0/1	Sensor state, normalised in the root flow	on change + heartbeat	Numeric so it can be summed and averaged.
Arrival marker	arrival	1	Written by the root flow on a free-to-occupied change	on change	Daily sum = arrivals.
Raw sensor state	parking_status	text	Codec output (example name)	with each uplink	Kept for diagnosis.
Battery	battery	% or V	Codec	with each uplink	Unit depends on the model.
Sensor temperature	temperature	°C	Codec, where the model reports it	with each uplink	Helps explain drift in winter.
Bay type	bay_type	text	Server attribute	set once	standard, disabled, loading, ev, short_stay.
Maximum stay	max_stay_min	min	Server attribute	set once	For restricted bays.
Bay code	bay_code	text	Server attribute	set once	Matches paint marking and enforcement records.

Per car park or street segment, on the counter device:

Point	Telemetry key	Unit	Source	Interval	Notes
Occupied bays	occupied_count	count	Flow	every 5 min + on change
Free bays	free_count	count	Flow	every 5 min + on change	What signs show.
Bays with silent sensor	unknown_count	count	Flow	every 5 min	Not counted as free.
Occupancy	occupancy_pct	%	Flow	every 5 min + on change	occupied ÷ (capacity − unknown).
Restricted bays free	free_disabled, free_loading, free_ev	count	Flow	every 5 min + on change	Per bay type.
Entrance in and out	entries, exits	count	Barrier controller via gateway	5 min	Optional cross-check.
Capacity	capacity	count	Server attribute	set once	Bays in the area.

Asset model

In Sites & Assets, the tree mirrors how the operator manages parking, and its codes match signage:

• City or campus (Site) with the time zone and the location used for sunrise and sunset.
• District or zone (Area) with enforcement_team and tariff_zone as attributes for people and integrations.
• Car park (Site or free kind) with location, capacity, opening_hours and public_feed_id; Level (Floor) with capacity; or Street segment (Area) with capacity and the street name.
• Bay sensors placed under their level or segment, each with bay_type, max_stay_min and bay_code.
• Counter device of the car park or segment placed on the same asset, plus LoRaWAN gateways placed where they hang.

Placement drives everything else: the counter flow groups bays by an attribute that names their area, a Rules card homed on a car park can only name devices beneath it, and a person narrowed to one district sees only its bays. Use separate profiles per bay type (for example Bay sensor, standard and Bay sensor, loading, made with Duplicate), because rules address devices one by one or by profile.

Device setup

Adding sensors

Add each sensor with its DevEUI, JoinEUI and AppKey, or import a delivery in a batch; a profile can hold the shared AppKey of a batch. Choose the codec on the profile: a library codec when the model is listed, otherwise Save a copy of a similar one, edit it and check it on the test bench with frames from the supplier's manual before publishing. Record each sensor's bay code as a server attribute at installation; a spreadsheet of DevEUI against bay code, imported with the devices, avoids typing errors.

Normalising the state

Library codecs return vendor keys and values, for example a text state such as car or none. In the profile's root flow, after the default save, add a small script or switch block that writes occupied as 0 or 1, and an Only changes block that passes a message when occupied changes so a second save stores arrival = 1 on each free-to-occupied change. Heartbeats then repeat the state without creating false arrivals.

Online rule and silence

LoRaWAN devices hold no connection, so use the Recent message online rule with the expected interval set to the sensor's heartbeat and a factor of two or three. A sensor that misses its heartbeats turns offline, raises an inactivity alarm and drops out of the counts as unknown.

Changing sensor settings

Third-party LoRaWAN sensors do not take Hermetry's remote device settings; their heartbeat period or sensitivity is changed with the downlink commands documented by the vendor. Hermetry sends application downlinks as raw frames (port and hex or base64 data) through the command catalog. A class A sensor receives a downlink only after its next uplink, so a change can take up to one heartbeat to arrive. Test any downlink on one sensor first; a wrong frame can stop a sensor reporting.

Calibration and time

Many magnetometer sensors calibrate against an empty bay after installation; follow the vendor's procedure and confirm each bay reads free before it goes live. The network server stamps each uplink at reception, so sensors do not need their own clock.

Dashboards

One board with an entity parameter for the car park serves every car park; the city view is a separate board.

Board	Audience	Widgets and what they show
City or campus overview	Operations, management	Map of car parks and street segments, coloured by occupancy ranges (for example green below 70 %, amber to 90 %, red above), with free spaces in the tooltip and markers grouped when zoomed out (each counter device carries its area's coordinates); table of areas with free, occupied and unknown counts; stat cards for total free spaces and sensors silent; alarm table.
Car park	Operations, car park staff	Stat for free spaces and progress card for occupancy; free bays per type; line chart of occupancy over 24 hours; device table of bays with state, bay type, time since last change and battery, filtered by level; alarm table of overstays.
Level plan	Car park staff, enforcement	A floor plan of the level with each bay as a marker coloured by state, built like the floor-plan map of the Sensor regions ready solution. That map places markers by plan coordinates stored as telemetry of each sensor, so bays need a one-time write of their coordinates; plan the effort.
Planning	Transport planners	Bar chart of hourly average occupancy per weekday from the counter's aggregates; daily arrivals and peak occupancy per car park; stat with trend against the previous period; table export to Excel.
Network health	Network technician	LoRaWAN gateway map by state; device table of sensors sorted by battery and last seen. Signal per frame and the gateways that heard it are on each sensor's LoRaWAN tab.

For a screen at the car park office, use a display link: read-only, no menus, valid for 1 to 365 days and revocable per screen. Do not publish display links on a public website; give public channels the counts through a feed instead.

SCADA screens

A car park rarely needs a process drawing, but an operations room screen benefits from one schematic per car park: entrances and exits with Barrier gate symbols, Car park sign symbols showing the free count, and Parking meter symbols where pay stations exist. These come from the city family of the Water pack, which covers city networks; see the symbol library.

• States. The sign symbol prints free_count; a colour rule turns it red when free_count drops below an agreed reserve; a barrier symbol shows open or closed from the barrier controller where it is read.
• Reuse. Attach the drawing as a view of the car park asset; car parks with the same layout share the drawing with their own bindings.
• Commands. Leave barrier commands out. Barriers involve vehicle and pedestrian safety and stay with their own controllers.

Rules and alarms

Two details shape the rules. First, bay sensors report on change, and profile alarm rules that debounce by duration count device time stamps that advance only when a message arrives; a bay that stays occupied sends nothing for an hour. Overstay detection therefore uses the Rules card, whose "stays so for N minutes" is a real timer that survives restarts and is cancelled when the bay frees. Second, rules address single devices or all devices of a profile in a place, which is why restricted bays get their own profiles.

Alarm	Condition	Delay and hysteresis	Severity	Notified	Escalation
Loading bay overstay	Rules card on the district: loading bay occupied = 1, only if between 07:00 and 19:00 Monday to Saturday	Stays so for 30 min	Minor (raised by the rule)	Enforcement team for the district, push	Reminder every 30 min until acknowledged
Disabled bay overstay	As above for disabled bays, with the limit that applies	Stays so for the limit, e.g. 180 min	Minor	Enforcement team, push	Reminder every 60 min
Bay occupied a full day	Rules card: any bay occupied = 1	Stays so for 24 h	Warning	Operations, in-app	None; checked on the next patrol
Car park nearly full	Rules card: occupancy_pct rises above 95	Stays so for 10 min	Info (notify only)	Car park staff, push	None
Sensor silent	Inactivity rule on the bay profiles	2 to 3 heartbeats	Warning	Network technician, e-mail	None
Sensor battery low	Profile rule: battery below the model's low level	Debounce 2 samples	Info	Network technician, e-mail	None
LoRaWAN gateway offline	Rules card: gateway device goes offline	Stays so for 15 min	Major	Network technician, push and SMS	Reminder every 60 min
Counter stopped	Inactivity rule on the counter profile, no message for 15 min		Major	Integrator on duty, push	Reminder every 30 min

Lifecycle. Alarms open after their delay, are acknowledged by the officer who takes them, with an optional note such as the notice number, and resolve by themselves when the bay frees. One alarm per bay and type stays open; repeats count as occurrences. Acknowledging needs the User role. Because resolution is automatic, review resolved overstays with no acknowledgement each week to see which went unattended.

Quiet periods. Overstay rules carry their own time windows and can use the holiday calendar condition, so they stop on public holidays. During a street market or roadworks, switch the street segment to Manual until the end of the event; its rules stop and resume on their own, and every switch is audited.

Floods. A gateway outage makes dozens of sensors miss heartbeats together. Keep the gateway alarm at Major and sensor silence at Warning with e-mail only, so one push explains the cause. Above 20 alarm notifications a minute Hermetry collects the rest into a five-minute digest.

Automation and integrations

The counter flow

A flow on the bay profiles keeps the counts. On each bay message it reads the bay's area and type attributes with a device details block, updates a persistent flow variable that holds the latest state of every bay, and computes occupied, free and unknown counts per area. A schedule trigger every five minutes recomputes the counts so that silent sensors move to unknown and the counter reports at a regular interval. An Only changes block avoids repeating identical counts, and an HTTP request block posts the counts as telemetry of the area's counter device through the device HTTP API, with an HTTP endpoint holding that device's access token as a bearer secret.

This is an integrator's pattern, not a ready module: test it with the flow test runner, and expect the counts to rebuild themselves within one heartbeat period after the flow is changed and its variables reset. Persistent variables survive restarts within the store's size limits; a few thousand bays fit comfortably.

Signs, apps and other systems

• Variable message signs. The same flow can post the free count to the sign controller's HTTP interface. A sign connected to Hermetry as a device can instead receive a command from its catalog. Either way, show a fallback text when the counter is stale.
• City or campus app. The app's backend reads the counter devices' values through the REST API with a read-only API key restricted to the backend's addresses, or receives them from a flow over HTTP.
• Enforcement systems. alarm.created, alarm.acknowledged and alarm.cleared webhooks, HMAC-signed, pass overstays with the bay code to the enforcement back office.
• Reports. Monthly occupancy and arrival figures come from history tables exported to Excel; scheduled reports are not built in today.

Roles and access

Who	Role or group	Can
Parking operations	User + IoT operator group	See every area, acknowledge alarms, switch areas to Manual.
Enforcement officer	User, narrowed to their district	See bays and overstays of the district, acknowledge with a note.
Transport planner	User + IoT viewer group	Read boards and history, export to Excel.
Network technician	User + IoT operator group	See gateways, sensors, battery and reception, acknowledge network alarms.
Integrator	Admin	Profiles, codecs, flows, rules, API keys for the app backend.
Partner operator (for example a hospital)	Own organisation or narrowed users	Only the car parks it runs.

Narrowing officers to a district uses attribute-based policies; test each policy with the policy simulator. Revealing a LoRaWAN AppKey needs its own permission. Enforcement officers in the street receive push in the browser or SMS today; the Hermetry mobile app is in development. The audit log records rule and profile changes, mode switches, commands and sign-ins in a verifiable hash chain.

Sizing and data

As an order of magnitude for 2,000 bays (1,200 kerbside, two car parks of 400) and 12 counter devices:

• Bay sensors: about 20 state changes a day on busy kerbside bays, fewer in car parks, plus 4 heartbeats; assume 25 uplinks per sensor per day, so 2,000 × 25 = 50,000 messages a day.
• Counters: one post every five minutes plus changes, capped by the Only changes block; assume at most one a minute, so 12 × 1,440 = 17,280 a day.
• Total: roughly 67,000 messages a day, about 2 million a month. Values stay small: five or six keys per bay message, around 300,000 values a day.

Only telemetry and attribute messages count toward the monthly allowance; alarms and commands do not. Occupancy history is valuable for years; raw bay data is kept for at most 90 days (30 days in the 90-day class, 90 days in the 365- and 1,095-day classes), so rely on hourly and daily aggregates of the counters, kept for the full class, for multi-year planning. LoRaWAN airtime, not the platform, is the usual limit: a dense street with a short heartbeat needs more gateways, not a bigger plan.

Rollout plan

Phase	Weeks	Work	Exit criteria
0. Survey	1-2	Bay inventory with codes and types; radio survey on streets and each car park level; choose sensor model and gateway positions.	Every bay heard by at least one planned gateway position, two on streets.
1. Pilot	3-6	Gateways, one street segment and one level; codec, normalisation and counter flow; overview and car park boards.	Bay states match a manual walk-round on three different days; counts within one bay of reality.
2. Restricted bays	7-8	Bay type profiles, overstay rules notifying only, enforcement team access.	Overstays confirmed by officers; no false overstays from sensor flapping.
3. Scale	9-20	Remaining streets and car parks area by area; signs and app feed; webhooks to the back office.	Sensor availability above an agreed level, for example 98 %; feeds stable for two weeks.
4. Planning use	After 3	Planning board, monthly export routine, before-and-after studies.	First planning question answered from the data.

Commissioning checklist

1. Gateway added, Basics Station files installed, gateway online on the map at its real position.
2. Each sensor joined; latest reception shows at least the planned number of gateways and a usable signal.
3. Calibration done on an empty bay; bay reads free.
4. A vehicle parked and removed on each bay of a sample; state changes within the expected time; arrival written once per arrival, not on heartbeats.
5. Bay code, bay type and maximum stay attributes checked against the bay inventory.
6. Counter device shows the right capacity, free and unknown counts; a sensor switched off moves to unknown after its heartbeat period.
7. Overstay rule tested with a parked vehicle in a loading bay; officer receives it, acknowledges with a note.
8. One gateway switched off: sensors still heard through the second gateway; gateway alarm raised.
9. Sign or app feed shows the same count as the board; stale counter shows the fallback text.

Pitfalls

• Duration alarms on event-driven sensors. Profile alarm debounce by time waits for the next message. Use Rules card time holds for overstays.
• Treating silence as free. A dead sensor in a full street makes the sign lie. Count silent bays as unknown and show that count.
• Vendor key names in rules. A sensor swap to another model changes key names and values. Normalise to occupied once, in the root flow.
• Underground coverage from outside. One rooftop gateway will not reach the lower levels. Survey each level.
• Barrier counts as the truth. In and out counts drift. Use them to cross-check, or reset them nightly against the bay sensors.
• One profile for all bay types. Rules cannot pick bays by attribute, so restricted bays need their own profiles.
• Public display links. A display link acts with its creator's rights. Feed public channels from the API or a flow.

What Hermetry does not replace

Hermetry supplies live and historical occupancy, alarms and feeds. Payment, permits and season tickets, penalty notices and enforcement records, number-plate recognition and the barrier and guidance controllers stay in the parking operator's systems, and barrier safety stays with the barrier hardware. A free count on a sign is guidance, not a guarantee of a space. Hermetry City, the planned smart city product, is not available yet; this blueprint uses only parts available today.