Datos de API sin procesar para Cisco Meraki CMX Dashboard

¿Alguien ha trabajado con la fuente de datos en bruto CMX de Meraki y puede ayudar a responder algunas preguntas?

Vine a preguntar porque no he encontrado conversaciones sobre la API CMX de Meraki en ningún otro lado e imaginé que los ingenieros de redes aún tienen más probabilidades de conocer este servicio que los equipos de BI o los desarrolladores.

Recientemente hemos establecido puntos de acceso Meraki en algunas de nuestras tiendas minoristas para informar sobre el tráfico peatonal. Configuramos la fuente de datos para que apunte a una base de datos del servidor SQL con resultados casi en vivo. Nuestro plan es tener una rutina nocturna para resumir los datos para informar sobre métricas similares al panel de Meraki. Revisé los datos que tenemos actualmente y leí las documentaciones, pero noté que no todo se explica. Aquí hay algunos puntos con los que estoy luchando.

1. RSSI no explicado completamente

• un valor RSSI de 0 y 102 es desproporcionadamente más alto que cualquier otro valor RSSI. Supongo que un valor 0 indica conectado, pero no estoy seguro de para qué sirve 102 . Fuerza máxima o un error?

2. La documentación no admite múltiples casos cuando hay una cantidad impar de pings o una pequeña cantidad de ellos

• He notado casos en los que puede haber dos o tres pings en una ranura de 20 minutos que están separados por unos 3 minutos. Esto sugeriría que este dispositivo era un visitante basado en la documentación de Meraki, pero también podría leerse como un transeúnte lento, un observador de ventanas o alguien sentado estacionando su automóvil en el frente. ¿Alguien tiene una idea de cómo Meraki maneja esto?

• Otro caso sería cuando solo hay dos pings y ambos están por encima de los umbrales de RSSI y tienen más de 5 minutos de diferencia pero menos de 20 minutos. Nuevamente, esto sugeriría otro visitante, pero yo diría que es otro transeúnte.

• Mi otro punto de confusión es con fuertes pings individuales. Me imagino que si un teléfono tiene un ping fuerte y solo cuando son transeúntes, me sorprende no ver múltiples pings.

3. La documentación no explica la metodología de seguimiento de visitantes que permanecen más de 20 minutos

• ¿Se dividen todos los segmentos en intervalos de 20 minutos y luego se suman para crear tiempo en la tienda?

Avíseme si desea que agregue los enlaces a la documentación que he leído. Cualquier ayuda sería de gran ayuda.

Por lo tanto, no he usado las API de CMX, pero puedo responder a su primera pregunta sobre RSSI. Entonces RSSI es una medida de la intensidad de la señal. Básicamente, cuanto mayor es el número, más fuerte es la intensidad de la señal de radio. Tengo mucha experiencia configurando los puntos de acceso inalámbricos de Meraki y solucionando problemas de conexión inalámbrica. Un valor RSSI menor que 40 generalmente significa una señal deficiente y generalmente significa que el cliente no puede conectarse a la red o tiene una pérdida de datos intermitente.

Para su contexto, en general, CMX triangula dónde se encuentra un cliente en un espacio inalámbrico utilizando los valores RSSI informados que provienen de los diversos AP. Mientras los AP se coloquen en el portal Meraki en la ubicación correcta en el mapa del piso, el tablero podrá triangular una posición estimada. Me imagino que los datos sin procesar que está recibiendo es lo que el tablero obtiene los cálculos previos a la triangulación.

Espero haberle ayudado a comprender los valores de RSSI.