API-Rohdaten für das Cisco Meraki CMX Dashboard

Hat jemand mit Merakis CMX-Rohdaten-Feed gearbeitet und kann bei der Beantwortung einiger Fragen helfen?

Ich bin hierher gekommen, um zu fragen, weil ich anderswo keine Gespräche über die CMX-API von Meraki gefunden habe und mir vorgestellt habe, dass Netzwerktechniker immer noch eher über diesen Service Bescheid wissen als BI-Teams oder Entwickler.

Wir haben kürzlich in einigen unserer Einzelhandelsgeschäfte Meraki-Zugangspunkte eingerichtet, um über den Fußgängerverkehr zu berichten. Wir haben den Datenfeed so eingerichtet, dass er auf eine SQL Server-Datenbank mit fast Live-Ergebnissen verweist. Unser Plan ist eine nächtliche Routine, um die Daten zusammenzufassen und über ähnliche Metriken wie das Meraki-Dashboard zu berichten. Ich habe die Daten, die wir derzeit haben, durchkämmt und die Dokumentationen gelesen, aber festgestellt, dass nicht alles erklärt wird. Hier sind einige Punkte, mit denen ich zu kämpfen habe.

1. RSSI nicht vollständig erklärt

• Ein RSSI-Wert von 0 und 102 ist unverhältnismäßig höher als jeder andere RSSI-Wert. Ich gehe davon aus, dass ein 0- Wert verbunden anzeigt, bin mir aber nicht sicher, wofür 102 ist? Maximale Stärke oder ein Fehler?

2. Die Dokumentation unterstützt nicht mehrere Fälle, in denen eine ungerade Anzahl von Pings oder eine kleine Anzahl von Pings vorhanden ist

• Ich habe Fälle bemerkt, in denen es zwei oder drei Pings in einem bestimmten 20-Minuten-Slot geben kann, die ungefähr 3 Minuten voneinander entfernt sind. Dies würde darauf hindeuten, dass dieses Gerät ein Besucher war, basierend auf Merakis Dokumentation, aber auch als langsamer Passant, Fensterwächter oder als jemand, der sein Auto vor dem Haus parkt, gelesen werden könnte. Hat jemand eine Idee, wie Meraki damit umgeht?

• Ein anderer Fall wäre, wenn nur zwei Pings vorhanden sind und beide über den RSSI-Schwellenwerten liegen und mehr als 5 Minuten voneinander entfernt sind, jedoch weniger als 20 Minuten. Auch dies würde einen anderen Besucher vorschlagen, aber ich würde argumentieren, ein anderer Passant zu sein.

• Mein anderer Punkt der Verwirrung ist mit starken einzelnen Pings. Ich stelle mir vor, wenn ein Telefon einen starken Ping hat und nur dann, wenn es ein Passant ist, aber es überrascht mich, nicht mehrere Pings zu sehen.

3. Die Dokumentation erklärt nicht die Methode zur Verfolgung von Besuchern, die länger als 20 Minuten bleiben

• Werden alle Segmente in 20-Minuten-Intervallen aufgeteilt und dann summiert, um Zeit im Speicher zu schaffen?

Lassen Sie mich wissen, ob ich die Links zu der von mir gelesenen Dokumentation hinzufügen soll. Jede Hilfe wäre super hilfreich.

Ich habe die CMX-APIs also nicht verwendet, aber ich kann Ihre erste Frage zu RSSI beantworten. RSSI ist also ein Maß für die Signalstärke. Grundsätzlich ist die Funksignalstärke umso stärker, je höher die Zahl ist. Ich habe viel Erfahrung mit dem Einrichten der drahtlosen APs von Meraki sowie mit der Fehlerbehebung bei drahtlosen Problemen. Ein RSSI-Wert von weniger als 40 bedeutet normalerweise ein schlechtes Signal und bedeutet normalerweise, dass der Client entweder keine Verbindung zum Netzwerk herstellen kann oder zeitweise Daten verliert.

In Ihrem Kontext trianguliert CMX im Allgemeinen, wo sich ein Client in einem drahtlosen Bereich befindet, indem die gemeldeten RSSI-Werte verwendet werden, die von den verschiedenen APs stammen. Solange sich die APs im Meraki-Portal an der richtigen Stelle auf der Bodenkarte befinden, kann das Dashboard eine geschätzte Position triangulieren. Ich würde mir vorstellen, dass die Rohdaten, die Sie erhalten, das sind, was das Dashboard vor der Triangulation berechnet.

Hoffentlich habe ich Ihnen geholfen, die RSSI-Werte zu verstehen.