Un vistazo
| Elemento | Respuesta habitual |
|---|---|
| Problema | Nadie sabe en cada momento cuántas plazas libres hay en un aparcamiento o en una calle, las plazas restringidas permanecen bloqueadas durante horas y las decisiones de planificación se basan en recuentos manuales. |
| Qué se conecta | Un sensor de ocupación LoRaWAN con batería en cada plaza, gateways LoRaWAN en tejados, farolas y plantas de aparcamiento y, opcionalmente, contadores de entrada y paneles de mensajes variables. |
| Quién lo usa | El equipo de operaciones de aparcamiento, los agentes de control, los planificadores de transporte y, a través de feeds, los conductores en una app de ciudad o campus. |
| Alcance inicial típico | Un tramo de calle de 50 a 150 plazas en bordillo y una planta de un aparcamiento, unos 200 a 400 sensores. |
| Tiempo hasta la primera pantalla | Normalmente un día después de que el primer gateway esté operativo y se hayan añadido los sensores, porque la librería de codecs decodifica los sensores de aparcamiento más comunes. Prevea de cuatro a seis semanas para un piloto, incluido un estudio de radio y la calibración de los sensores. |
La situación
Ayuntamientos, hospitales, campus, aeropuertos y centros comerciales gestionan plazas en bordillo y aparcamientos sin un recuento en tiempo real. Los conductores dan vueltas buscando una plaza, las entradas hacen cola mientras una planta lejana está medio vacía, y las plazas para discapacitados, de carga y de corta estancia están ocupadas durante horas por vehículos que no deberían estar allí. Los agentes de control patrullan rutas fijas y encuentran que la mayoría de las plazas cumplen la normativa.
La planificación no está mejor informada. Si un distrito necesita otro aparcamiento, si un cambio de tarifas ha modificado la demanda o cuánto tiempo se queda realmente la gente, se decide con recuentos manuales realizados una o dos veces al año. Los sistemas de guiado existentes, donde los hay, cuentan las barreras de entrada y salida y se desvían decenas de plazas en una semana.
Este blueprint coloca un sensor en cada plaza, mantiene en tiempo real el estado de cada plaza y el recuento de libres de cada área, almacena el histórico para la planificación y envía los recuentos a paneles y apps. Hermetry City, el producto de ciudad inteligente previsto, está programado para 2027; todo lo descrito aquí usa componentes que funcionan hoy en Hermetry: el servidor de red LoRaWAN, codecs, activos, reglas, flujos y mapas.
Objetivos e indicadores
- Plazas libres por planta, aparcamiento y tramo de calle, en tiempo real = capacidad menos plazas ocupadas que reportan, contando por separado las plazas cuyo sensor no responde, sin estimarlas.
- Tasa de ocupación = horas-plaza ocupadas ÷ horas-plaza disponibles en un periodo. Como los sensores informan al cambiar, calcúlela a partir de un contador que informe a intervalo fijo (véase Automation), no a partir de una media de los mensajes brutos de los sensores.
- Ocupación máxima por día y la hora en que se produjo, por aparcamiento.
- Llegadas por plaza y día = número de cambios de libre a ocupada. Estancia media = horas-plaza ocupadas ÷ llegadas.
- Eventos de exceso de estancia por tipo de plaza restringida y semana, y la proporción gestionada dentro de un tiempo acordado.
- Disponibilidad de sensores = proporción de sensores que informaron dentro de su periodo de heartbeat, una medida de la propia red.
Los planificadores suelen querer la ocupación por hora y día de la semana, antes y después de un cambio. Hermetry guarda agregados por minuto, por hora y por día de cada clave almacenada; las tablas históricas se descargan a Excel para el análisis más profundo.
Arquitectura
Los sensores de plaza son dispositivos LoRaWAN con batería, normalmente sensores magnetométricos, de radar o combinados, pegados o embebidos en el pavimento. Se unen al servidor de red LoRaWAN propio de Hermetry mediante OTAA en EU868 como dispositivos de clase A: envían un uplink cuando la plaza cambia de estado y un heartbeat periódico, y escuchan solo brevemente tras cada uplink. Véase LoRaWAN.
Los gateways que hablan LoRa Basics Station se conectan a la dirección del servidor de red de su organización mediante un WebSocket seguro; los routers con licencia con LoRaWAN usan su propio enlace. En las calles, coloque los gateways en tejados o farolas para que cada plaza sea oída por al menos dos; el servidor de red elimina los duplicados y responde a través del mejor gateway. En aparcamientos de varias plantas y subterráneos, la radio rara vez atraviesa más de una losa, así que planifique un gateway por planta o por cada dos plantas, con Ethernet o un router 4G con licencia como backhaul. El mapa de gateways muestra cada gateway por estado, y el estado del gateway se almacena como telemetría.
| Componente | Función | Notas |
|---|---|---|
| Sensor de ocupación de plaza (LoRaWAN) | Ocupada o libre, batería, calidad de radio | Clase A, OTAA. Decodificado por un codec de la librería si el modelo está incluido, o por un codec propio. |
| Gateway LoRaWAN | Escucha los sensores | Basics Station; un dispositivo Hermetry por cada uno; el token se muestra una sola vez. |
| Router 4G con licencia | Backhaul donde no hay línea fija | Su propia SIM y operador por ahora; la gestión de eSIM está en desarrollo (Hermetry Connect). |
| Contadores de entrada (opcional) | Recuentos de entrada y salida en barreras | Controlador de barrera por Modbus mediante un gateway con licencia, o contactos de detector de bucle si el modelo de gateway cuenta pulsos. |
| Dispositivo contador de aparcamiento | Guarda los recuentos calculados como telemetría | Un dispositivo HTTP en Hermetry, alimentado por un flujo; uno por aparcamiento o tramo de calle. |
| Paneles de mensajes variables (opcional) | Muestran las plazas libres en las entradas | Controlados por un flujo sobre HTTP, o como dispositivos con un catálogo de comandos. |
Las librerías de codecs decodifican muchos sensores de aparcamiento comunes. Sus claves de salida siguen la nomenclatura del fabricante, a menudo un estado de texto, así que decida pronto cómo normalizarlas (véase Device setup).
Lista de puntos
Por sensor de plaza, tras la normalización. Los intervalos dependen del modelo del sensor y de su configuración; son habituales periodos de heartbeat de una a seis horas.
| Punto | Clave de telemetría | Unidad | Origen | Intervalo | Notas |
|---|---|---|---|---|---|
| Plaza ocupada | occupied | 0/1 | Estado del sensor, normalizado en el flujo raíz | al cambiar + heartbeat | Numérico para poder sumarlo y promediarlo. |
| Marcador de llegada | arrival | 1 | Escrito por el flujo raíz en un cambio de libre a ocupada | al cambiar | Suma diaria = llegadas. |
| Estado bruto del sensor | parking_status | texto | Salida del codec (nombre de ejemplo) | con cada uplink | Se conserva para diagnóstico. |
| Batería | battery | % o V | Codec | con cada uplink | La unidad depende del modelo. |
| Temperatura del sensor | temperature | °C | Codec, si el modelo la informa | con cada uplink | Ayuda a explicar la deriva en invierno. |
| Tipo de plaza | bay_type | texto | Atributo de servidor | una sola vez | standard, disabled, loading, ev, short_stay. |
| Estancia máxima | max_stay_min | min | Atributo de servidor | una sola vez | Para plazas restringidas. |
| Código de plaza | bay_code | texto | Atributo de servidor | una sola vez | Coincide con la señalización en el pavimento y con los registros de control. |
Por aparcamiento o tramo de calle, en el dispositivo contador:
| Punto | Clave de telemetría | Unidad | Origen | Intervalo | Notas |
|---|---|---|---|---|---|
| Plazas ocupadas | occupied_count | recuento | Flujo | cada 5 min + al cambiar | |
| Plazas libres | free_count | recuento | Flujo | cada 5 min + al cambiar | Lo que muestran los paneles. |
| Plazas con sensor sin respuesta | unknown_count | recuento | Flujo | cada 5 min | No se cuentan como libres. |
| Ocupación | occupancy_pct | % | Flujo | cada 5 min + al cambiar | ocupadas ÷ (capacidad − sin respuesta). |
| Plazas restringidas libres | free_disabled, free_loading, free_ev | recuento | Flujo | cada 5 min + al cambiar | Por tipo de plaza. |
| Entradas y salidas | entries, exits | recuento | Controlador de barrera vía gateway | 5 min | Contraste opcional. |
| Capacidad | capacity | recuento | Atributo de servidor | una sola vez | Plazas del área. |
Modelo de activos
En Sites & Assets, el árbol refleja cómo el operador gestiona el aparcamiento, y sus códigos coinciden con la señalización:
- Ciudad o campus (Site) con la zona horaria y la ubicación usada para el orto y el ocaso.
- Distrito o zona (Area) con
enforcement_teamytariff_zonecomo atributos para personas e integraciones. - Aparcamiento (Site o tipo free) con ubicación,
capacity,opening_hoursypublic_feed_id; Planta (Floor) concapacity; o Tramo de calle (Area) concapacityy el nombre de la calle. - Sensores de plaza colocados bajo su planta o tramo, cada uno con
bay_type,max_stay_minybay_code. - Dispositivo contador del aparcamiento o segmento colocado en el mismo activo, además de las pasarelas LoRaWAN colocadas donde llegue la señal.
La ubicación condiciona todo lo demás: el flujo de contadores agrupa las plazas por un atributo que indica su zona, una tarjeta de Reglas anclada a un aparcamiento solo puede nombrar dispositivos que estén debajo, y una persona limitada a un distrito solo ve sus plazas. Use perfiles separados por tipo de plaza (por ejemplo Sensor de plaza, estándar y Sensor de plaza, carga, creados con Duplicar), porque las reglas se aplican dispositivo por dispositivo o por perfil.
Configuración de dispositivos
Añadir sensores
Añada cada sensor con su DevEUI, JoinEUI y AppKey, o importe una entrega en lote; un perfil puede contener la AppKey compartida de un lote. Elija el códec en el perfil: un códec de la biblioteca cuando el modelo figure en ella; en caso contrario, use Guardar una copia de uno similar, edítelo y compruébelo en el banco de pruebas con tramas del manual del proveedor antes de publicarlo. Registre el código de plaza de cada sensor como atributo de servidor en la instalación; una hoja de cálculo con DevEUI frente a código de plaza, importada con los dispositivos, evita errores de escritura.
Normalización del estado
Los códecs de la biblioteca devuelven claves y valores del fabricante, por ejemplo un estado de texto como car o none. En el flujo raíz del perfil, después del guardado por defecto, añada un pequeño script o un bloque de conmutación que escriba occupied como 0 o 1, y un bloque Solo cambios que pase un mensaje cuando occupied cambie, de modo que un segundo guardado almacene arrival = 1 en cada cambio de libre a ocupada. Los latidos repiten entonces el estado sin generar llegadas falsas.
Regla de conexión y silencio
Los dispositivos LoRaWAN no mantienen una conexión, así que use la regla de conexión Mensaje reciente con el intervalo esperado fijado en el latido del sensor y un factor de dos o tres. Un sensor que pierde sus latidos pasa a desconectado, genera una alarma por inactividad y sale de los recuentos como desconocido.
Cambio de ajustes del sensor
Los sensores LoRaWAN de terceros no admiten los ajustes remotos de dispositivo de Hermetry; su periodo de latido o su sensibilidad se cambian con los comandos downlink documentados por el proveedor. Hermetry envía downlinks de aplicación como tramas en bruto (puerto y datos en hex o base64) mediante el catálogo de comandos. Un sensor de clase A solo recibe un downlink después de su siguiente uplink, por lo que un cambio puede tardar hasta un latido en llegar. Pruebe primero cualquier downlink en un solo sensor; una trama incorrecta puede hacer que un sensor deje de informar.
Calibración y hora
Muchos sensores magnetómetro se calibran frente a una plaza vacía tras la instalación; siga el procedimiento del proveedor y confirme que cada plaza marca libre antes de ponerla en servicio. El servidor de red marca cada uplink en el momento de su recepción, así que los sensores no necesitan reloj propio.
Cuadros de mando
Un único cuadro con un parámetro de entidad para el aparcamiento sirve a todos los aparcamientos; la vista de ciudad es un cuadro aparte.
| Cuadro | Público | Widgets y lo que muestran |
|---|---|---|
| Vista general de ciudad o campus | Operaciones, dirección | Mapa de aparcamientos y tramos de calle, coloreado por rangos de ocupación (por ejemplo, verde por debajo del 70 %, ámbar hasta el 90 %, rojo por encima), con plazas libres en la información emergente y marcadores agrupados al alejar el zoom (cada dispositivo contador lleva las coordenadas de su zona); tabla de zonas con recuentos de libres, ocupadas y desconocidas; tarjetas de estadística con el total de plazas libres y sensores silenciosos; tabla de alarmas. |
| Aparcamiento | Operaciones, personal del aparcamiento | Estadística de plazas libres y tarjeta de progreso de ocupación; plazas libres por tipo; gráfico de líneas de ocupación en 24 horas; tabla de dispositivos con las plazas, su estado, tipo, tiempo desde el último cambio y batería, filtrada por planta; tabla de alarmas de estancias excedidas. |
| Plano de planta | Personal del aparcamiento, control | Un plano de la planta con cada plaza como marcador coloreado por estado, construido como el mapa de planos del solution Sensor regions ready. Ese mapa sitúa los marcadores según coordenadas de plano almacenadas como telemetría de cada sensor, por lo que las plazas necesitan una escritura única de sus coordenadas; planifique el esfuerzo. |
| Planificación | Planificadores de transporte | Gráfico de barras de la ocupación media horaria por día laborable a partir de los agregados del contador; llegadas diarias y ocupación máxima por aparcamiento; estadística con tendencia frente al periodo anterior; exportación de tablas a Excel. |
| Salud de la red | Técnico de red | Mapa de pasarelas LoRaWAN por estado; tabla de dispositivos sensores ordenada por batería y última vez visto. La señal por trama y las pasarelas que la recibieron están en la pestaña LoRaWAN de cada sensor. |
Para una pantalla en la oficina del aparcamiento, use un enlace de visualización: solo lectura, sin menús, válido de 1 a 365 días y revocable por pantalla. No publique enlaces de visualización en un sitio web público; en su lugar, ofrezca a los canales públicos los recuentos mediante un feed.
Pantallas SCADA
Un aparcamiento rara vez necesita un diagrama de proceso, pero una pantalla de sala de operaciones se beneficia de un esquema por aparcamiento: entradas y salidas con símbolos de Barrera de acceso, símbolos de Señal de aparcamiento que muestran el recuento de libres y símbolos de Parquímetro donde existan puntos de pago. Proceden de la familia urbana del paquete Water, que cubre redes urbanas; consulte la biblioteca de símbolos.
- Estados. El símbolo de señal muestra
free_count; una regla de color lo pone en rojo cuandofree_countcae por debajo de una reserva acordada; un símbolo de barrera muestra abierta o cerrada según el controlador de barrera donde se lea. - Reutilización. Adjunte el dibujo como vista del activo de aparcamiento; los aparcamientos con la misma distribución comparten el dibujo con sus propios enlaces.
- Comandos. No incluya comandos de barreras. Las barreras afectan a la seguridad de vehículos y peatones y permanecen en sus propios controladores.
Reglas y alarmas
Dos detalles condicionan las reglas. Primero, los sensores de plaza informan al cambiar, y las reglas de alarma del perfil que aplican antirrebote por duración cuentan marcas de tiempo del dispositivo que solo avanzan cuando llega un mensaje; una plaza que sigue ocupada no envía nada durante una hora. Por ello, la detección de estancias excedidas usa la tarjeta de Reglas, cuyo "permanece así durante N minutos" es un temporizador real que sobrevive a los reinicios y se cancela cuando la plaza queda libre. Segundo, las reglas se aplican a dispositivos individuales o a todos los dispositivos de un perfil en un lugar, por eso las plazas restringidas tienen sus propios perfiles.
| Alarma | Condición | Retardo e histéresis | Gravedad | Notificado | Escalado |
|---|---|---|---|---|---|
| Estancia excedida en plaza de carga | Tarjeta de Reglas en el distrito: plaza de carga occupied = 1, solo entre las 07:00 y las 19:00 de lunes a sábado | Permanece así durante 30 min | Menor (generada por la regla) | Equipo de control del distrito, push | Recordatorio cada 30 min hasta que se confirme |
| Estancia excedida en plaza de discapacitados | Igual que la anterior para plazas de discapacitados, con el límite que corresponda | Permanece así durante el límite, p. ej. 180 min | Menor | Equipo de control, push | Recordatorio cada 60 min |
| Plaza ocupada un día completo | Tarjeta de Reglas: cualquier plaza con occupied = 1 | Permanece así durante 24 h | Aviso | Operaciones, en la aplicación | Ninguna; se revisa en la siguiente ronda |
| Aparcamiento casi lleno | Tarjeta de Reglas: occupancy_pct supera 95 | Permanece así durante 10 min | Información (solo notificar) | Personal del aparcamiento, push | Ninguna |
| Sensor silencioso | Regla de inactividad en los perfiles de plaza | De 2 a 3 latidos | Aviso | Técnico de red, correo electrónico | Ninguna |
| Batería del sensor baja | Regla de perfil: battery por debajo del nivel bajo del modelo | Antirrebote de 2 muestras | Información | Técnico de red, correo electrónico | Ninguna |
| Pasarela LoRaWAN fuera de línea | Tarjeta de Reglas: el dispositivo pasarela pasa a estar fuera de línea | Permanece así durante 15 min | Grave | Técnico de red, push y SMS | Recordatorio cada 60 min |
| Contador detenido | Regla de inactividad en el perfil del contador, sin mensajes durante 15 min | Grave | Integrador de guardia, push | Recordatorio cada 30 min |
Ciclo de vida. Las alarmas se abren tras su retardo, las confirma el agente que las atiende, con una nota opcional como el número de aviso, y se resuelven por sí solas cuando la plaza queda libre. Una alarma por plaza y tipo permanece abierta; las repeticiones cuentan como ocurrencias. Confirmar requiere el rol de Usuario. Como la resolución es automática, revise cada semana las estancias excedidas resueltas sin confirmar para ver cuáles quedaron sin atender.
Períodos de calma. Las reglas de estancia excedida tienen sus propias ventanas horarias y pueden usar la condición de calendario de festivos, así que se detienen en los días festivos. Durante un mercadillo o unas obras en la calle, cambie el segmento de la calle a Manual hasta el final del evento; sus reglas se detienen y se reanudan por sí solas, y cada cambio queda registrado en auditoría.
Avalanchas. Una caída de una pasarela hace que decenas de sensores dejen de enviar latidos a la vez. Mantenga la alarma de la pasarela en Major y el silencio de los sensores en Warning solo con correo electrónico, para que una sola notificación explique la causa. Por encima de 20 notificaciones de alarma por minuto, Hermetry agrupa el resto en un resumen de cinco minutos.
Automatización e integraciones
El flujo del contador
Un flujo sobre los perfiles de plaza mantiene los recuentos. En cada mensaje de plaza lee los atributos de área y tipo de la plaza mediante un bloque de detalles del dispositivo, actualiza una variable persistente de flujo que contiene el último estado de cada plaza, y calcula los recuentos de ocupadas, libres y desconocidas por área. Un disparador programado cada cinco minutos recalcula los recuentos para que los sensores silenciosos pasen a desconocido y el contador informe a intervalos regulares. Un bloque Solo cambios evita repetir recuentos idénticos, y un bloque de solicitud HTTP envía los recuentos como telemetría del dispositivo contador del área mediante la API HTTP del dispositivo, con un endpoint HTTP que guarda el token de acceso de ese dispositivo como secreto de tipo bearer.
Es un patrón para integradores, no un módulo listo para usar: pruébelo con el ejecutor de pruebas de flujos y espere que los recuentos se reconstruyan por sí solos en un periodo de latido tras modificar el flujo y restablecer sus variables. Las variables persistentes sobreviven a los reinicios dentro de los límites de tamaño del almacén; unos pocos miles de plazas caben sin problemas.
Señales, aplicaciones y otros sistemas
- Señales de mensaje variable. El mismo flujo puede enviar el número de plazas libres a la interfaz HTTP del controlador de la señal. Una señal conectada a Hermetry como dispositivo puede, en cambio, recibir un comando de su catálogo. En cualquier caso, muestre un texto alternativo cuando el contador esté desactualizado.
- Aplicación de ciudad o campus. El backend de la aplicación lee los valores de los dispositivos contadores mediante la API REST con una clave de API de solo lectura restringida a las direcciones del backend, o los recibe de un flujo por HTTP.
- Sistemas de control de infracciones. Los webhooks
alarm.created,alarm.acknowledgedyalarm.cleared, firmados con HMAC, envían las estancias excedidas con el código de la plaza a la back office de control de infracciones. - Informes. Las cifras mensuales de ocupación y llegadas proceden de tablas de historial exportadas a Excel; los informes programados no vienen incluidos actualmente.
Roles y accesos
| Quién | Rol o grupo | Puede |
|---|---|---|
| Operaciones de aparcamiento | Usuario + grupo de operadores IoT | Ver todas las áreas, reconocer alarmas, cambiar áreas a Manual. |
| Agente de control | Usuario, limitado a su distrito | Ver plazas y estancias excedidas del distrito, reconocer con una nota. |
| Planificador de transporte | Usuario + grupo de visualizadores IoT | Consultar paneles e historial, exportar a Excel. |
| Técnico de red | Usuario + grupo de operadores IoT | Ver pasarelas, sensores, batería y recepción, reconocer alarmas de red. |
| Integrador | Administrador | Perfiles, codificadores, flujos, reglas, claves de API para el backend de la aplicación. |
| Operador asociado (por ejemplo, un hospital) | Su propia organización o usuarios limitados | Solo los aparcamientos que gestiona. |
Limitar los agentes a un distrito usa políticas basadas en atributos; pruebe cada política con el simulador de políticas. Revelar una AppKey de LoRaWAN requiere un permiso propio. Los agentes de control en la calle reciben hoy notificaciones push en el navegador o por SMS; la aplicación móvil de Hermetry está en desarrollo. El registro de auditoría recoge los cambios de reglas y perfiles, los cambios de modo, los comandos y los inicios de sesión en una cadena hash verificable.
Dimensionamiento y datos
Como orden de magnitud para 2.000 plazas (1.200 en la calle, dos aparcamientos de 400) y 12 dispositivos contadores:
- Sensores de plaza: unos 20 cambios de estado al día en las plazas de calle más concurridas, menos en los aparcamientos, más 4 latidos; suponga 25 uplinks por sensor al día, así que 2.000 × 25 = 50.000 mensajes al día.
- Contadores: un envío cada cinco minutos más los cambios, limitados por el bloque Solo cambios; suponga como máximo uno por minuto, así que 12 × 1.440 = 17.280 al día.
- Total: aproximadamente 67.000 mensajes al día, unos 2 millones al mes. Los valores son pequeños: cinco o seis claves por mensaje de plaza, unos 300.000 valores al día.
Solo los mensajes de telemetría y de atributos cuentan para la cuota mensual; las alarmas y los comandos no. El historial de ocupación tiene valor durante años; los datos brutos de plazas se conservan como máximo 90 días (30 días en la clase de 90 días, 90 días en las clases de 365 y 1.095 días), así que para la planificación plurianual use los agregados horarios y diarios de los contadores, conservados durante toda la clase. El límite habitual es el tiempo en el aire de LoRaWAN, no la plataforma: una calle densa con latidos cortos necesita más pasarelas, no un plan mayor.
Plan de despliegue
| Fase | Semanas | Trabajo | Criterios de salida |
|---|---|---|---|
| 0. Estudio | 1-2 | Inventario de plazas con códigos y tipos; estudio de radio en las calles y en cada planta de aparcamiento; elegir modelo de sensor y posiciones de las pasarelas. | Cada plaza recibida por al menos una posición de pasarela planificada, dos en las calles. |
| 1. Piloto | 3-6 | Pasarelas, un tramo de calle y una planta; codificador, normalización y flujo del contador; paneles de visión general y de aparcamientos. | Los estados de las plazas coinciden con un recorrido manual en tres días distintos; recuentos a una plaza de la realidad. |
| 2. Plazas restringidas | 7-8 | Perfiles por tipo de plaza, reglas de estancia excedida solo con notificación, acceso para el equipo de control de infracciones. | Estancias excedidas confirmadas por los agentes; ningún falso exceso causado por el parpadeo de los sensores. |
| 3. Escalado | 9-20 | Resto de calles y aparcamientos, área por área; señales y envío a la aplicación; webhooks a la back office. | Disponibilidad de sensores por encima de un nivel acordado, por ejemplo 98 %; flujos estables durante dos semanas. |
| 4. Uso para planificación | Tras 3 | Panel de planificación, rutina de exportación mensual, estudios de antes y después. | La primera pregunta de planificación respondida con los datos. |
Lista de verificación de puesta en marcha
- Pasarela añadida, archivos Basics Station instalados, pasarela en línea en el mapa en su posición real.
- Cada sensor unido; la última recepción muestra al menos el número previsto de pasarelas y una señal utilizable.
- Calibración hecha en una plaza vacía; la plaza indica libre.
- Un vehículo aparcado y retirado en cada plaza de una muestra; los cambios de estado se producen en el tiempo esperado;
arrivalse escribe una vez por llegada, no en los latidos. - Código de plaza, tipo de plaza y atributos de estancia máxima comprobados frente al inventario de plazas.
- El dispositivo contador muestra la capacidad correcta y los recuentos de libres y desconocidas; un sensor apagado pasa a desconocido tras su periodo de latido.
- Regla de estancia excedida probada con un vehículo aparcado en una plaza de carga; el agente la recibe y la reconoce con una nota.
- Una pasarela apagada: los sensores siguen siendo recibidos a través de la segunda pasarela; se genera la alarma de pasarela.
- La señal o el envío a la aplicación muestra el mismo recuento que el panel; un contador desactualizado muestra el texto alternativo.
Errores habituales
- Alarmas de duración en sensores basados en eventos. El antirrebote de alarma por tiempo del perfil espera al siguiente mensaje. Use las retenciones de tiempo de la tarjeta de Reglas para las estancias excedidas.
- Tratar el silencio como libre. Un sensor muerto en una calle llena hace que la señal mienta. Cuente las plazas silenciosas como desconocidas y muestre ese recuento.
- Nombres de claves del fabricante en las reglas. Cambiar de sensor a otro modelo cambia los nombres y valores de las claves. Normalice a
occupieduna sola vez, en el flujo raíz. - Cobertura subterránea desde el exterior. Una pasarela en el tejado no llegará a las plantas inferiores. Estudie cada planta.
- Tomar la barrera como verdad. Los recuentos de entrada y salida se desvían. Úselos para contrastar, o reinícielos cada noche frente a los sensores de plaza.
- Un solo perfil para todos los tipos de plaza. Las reglas no pueden elegir plazas por atributo, así que las plazas restringidas necesitan sus propios perfiles.
- Enlaces de paneles públicos. Un enlace de panel actúa con los derechos de su creador. Alimente los canales públicos desde la API o un flujo.
Lo que Hermetry no sustituye
Hermetry proporciona ocupación en tiempo real e histórica, alarmas y fuentes de datos. El pago, los permisos y abonos, las notificaciones de sanción y los registros de control, el reconocimiento de matrículas y los controladores de barrera y de guiado permanecen en los sistemas del operador del aparcamiento, y la seguridad de la barrera corresponde a la propia barrera. Un recuento libre en una señal es una orientación, no una garantía de plaza. Hermetry City, el producto de ciudad inteligente previsto, todavía no está disponible; este blueprint utiliza solo componentes disponibles hoy.

