Messstellen · Ist-Zustände
Standortkarte · Gemeindeübersicht
Diagnoseinformationen
Nur freigegebene Straßensensoren. Nach Zustand priorisiert; weitere Messwerte bei Bedarf öffnen.
Die technische Anzahl der Kartenmarker wird bei geöffneter Diagnose unterhalb der Karte angezeigt.
Detailanalyse · tatsächliche MesswerteKeine simulierten Daten
Echte Messreihen werden nach Auswahl geladen. Zeitachse anhand der Messzeitpunkte.
Fahrbahnzustand · aktives M1-Originalverfahren
RRoad-Detailkurve anzeigen (Rohwerte nicht als Zahlen in der Kundenansicht)
Kontrollfahrten und Maßnahmen
V4.7-Bedienablauf · Fotovorbereitung im Browser (Speicherung noch nicht angebunden)
Der aktuelle DEV-Webspace enthält nur das Frontend: Aktionen und Fotos können noch nicht dauerhaft gespeichert werden. Die Fotos werden im Browser für den späteren Upload vorbereitet. Eine Anbindung an die bestehenden MZ-Endpunkte Action/ConditionAssessment muss separat verifiziert werden. Keine automatischen Warnungen.
Technik & Service
Serviceberichte, technische Sensorverwaltung und Sendeintervalle
Neue Sensoren werden nicht durch eine lokale Simulation registriert: Die Registrierung mit DevEUI im tatsächlichen Sensornetz/Bestandsbackend muss vor Freigabe der Schreibfunktion verifiziert werden.
Servicehistorie (lokales DEV-Protokoll)
Organisatorische Alarmierungen
Erinnerungen und Eskalationsketten nur bei fehlender Benutzerrückmeldung – keine Eiswarnungen
Regeln werden ausschließlich als inaktive DEV-Konfiguration gespeichert. Es findet KEIN E-Mail-, Push- oder WhatsApp-Versand und keine automatisierte Eskalation statt.
Hinweisfunktionen je Gemeinde
V4.7-Einstellungen für organisatorische Kommunikationskanäle
Die Aktivierung eines Kanals löst keinerlei Nachricht aus. Für spätere Zustellung sind validierte Empfänger, Einwilligung, Provider und Rückmelde-Workflow erforderlich.
Aktionsberichte – CSV
V4.7-CSV-Ausgabe aus dokumentierten DEV-Aktionen und Serviceeinträgen
Nur lokale DEV-Dokumentationen. Für Gesamtberichte aus der bestehenden MZ-API ist eine separate, geprüfte ActionResponse-Anbindung erforderlich.
Messstellenvergleich · Gemeinde
Ausgewählte Fahrbahntemperaturen direkt übereinandergelegt – ausschließlich aus berechtigten, echten Messreihen der bestehenden API.
Messstellen zunächst über die API laden. Gemeindezuordnung wird geprüft.
Noch kein Vergleich geladen.
Fahrbahntemperaturen im zeitgleichen Diagramm
Jede Messstelle hat eine eigene Linienfarbe. Die horizontale Position richtet sich nach dem tatsächlichen Messzeitpunkt; fehlende Werte werden nicht ergänzt. Messlücken werden nach dem tatsächlich beobachteten Sendeintervall der jeweiligen Station getrennt. Vertikale Skala wie in der Detailanalyse: −20 bis +80 °C, in drei gleich hohen Bereichen.
Bitte eine Gemeinde und mindestens zwei Messstellen auswählen.
Messstellen im direkten Vergleich
| Messstelle | Letzte Fahrbahntemperatur | Messzeitpunkt | Tiefster Wert im Zeitraum | Backend-Ist-Zustand | Datenpunkte |
|---|---|---|---|---|---|
| Keine Vergleichsdaten | |||||
Historische Tiefstwerte werden für den gewählten Zeitraum ermittelt. Eine Messstelle gilt nur von Oktober bis April bei einem höchstens 60 Minuten alten Wert als aktuell; für Mai bis September ist noch keine pauschale Aktualitätsgrenze freigegeben. Eis wird ausschließlich gezeigt, wenn das bestehende Backend einen überprüften Ist-Zustand „Eis“ geliefert hat. Eine Prognose, welche Messstelle zuerst vereist, erfolgt hier nicht.
Messstellen im Überblick
Nur Geräte des MZ-Produkts Straßenüberwachung aus der bestehenden MZ-API. Ein Klick öffnet die Analyse.
| Messstelle | Kunde | Koordinaten | Aktion |
|---|---|---|---|
| Noch keine echten Gerätedaten geladen. | |||
Messwertanalyse
Echte Sensormesswerte und Originalkanäle direkt aus der vorhandenen MZ-API
Ohne Datumsbereich werden die letzten Messwerte abgerufen. Automatische Aktualisierung alle 60 Sekunden bei sichtbarer Seite. Kein manueller Reload notwendig.
Fahrbahntemperatur (bei eindeutiger Kanalzuordnung)
Keine DatenDie Bezeichnung des Kanals muss zur Fahrbahntemperatur passen. Ohne eindeutige Zuordnung keine Ersatzwerte.
Widerstandsverlauf
Logarithmische DarstellungOriginal-Messkanäle der MZ-API
Messwerte im Detail
| Zeitpunkt | ||||
|---|---|---|---|---|
| Keine Messdaten. | ||||
Parallelvergleich M1 / M2 / M3
Gleiche Sensormessungen, getrennte Zustandsverfahren; M3 nutzt ausschließlich GeoSphere-Wetterprognosen als zusätzlichen Plausibilitätskontext.
M3 wird nach dem schnellen Laden von M1/M2 separat angefordert.
M1 zeigt die Originalzustände aus MeasurementChecks. Eine ältere Regelrekonstruktion wird nicht als Originalwert ausgegeben. M3 übernimmt den lokalen M2-Zustand. Der Forecast wird separat als stützend, abweichend oder nicht verfügbar ausgewiesen. Nur zeitgenössisch archivierte Forecasts gelten als Beleg; ein Forecast ist kein Eisnachweis.
| Zeitpunkt | Temperatur | Widerstand | M1 | V1 Original | M2 | M3 | Forecast-Einordnung | Forecast 2-m-Temperatur | Firmware / Node-Verfahren |
|---|---|---|---|---|---|---|---|---|---|
| Noch keine Messwerte geladen. | |||||||||
Firmware und Messverfahren je Messstelle
Versionierte Stammdaten mit historischem Gültigkeitsbeginn. Für Admin und Techniker sichtbar.
Messstelle wird auf der Seite „Messwertanalyse“ ausgewählt. Die bestehende API dokumentiert derzeit kein Firmwareversionsfeld; vorhandene Einträge werden deshalb im DEV-Test separat historisiert.
Noch nicht geladen.
Historie
| Gültig ab | Firmware | Node-Messverfahren | Notiz |
|---|---|---|---|
| Noch keine Daten. | |||
Protokoll der Änderungen und Korrekturen
Neue Firmwareversion erfassen / korrigieren
Änderungen werden protokolliert. Das technische Messverfahren des Nodes ist nicht mit M1/M2/M3 zu verwechseln.
Dokumentation – M1, M2, M3 und Firmware
Nachvollziehbare Versionen, Regeln und technische Messverfahren. Nur für Admin-Diagnose.
Die Regeln werden als unveränderliche Dokumentationsstände in der DEV-Datenbank archiviert. Für frühere Auswertungen die zugehörige Software-/Regelversion berücksichtigen.
Karte / Sensorstandort
Koordinaten stammen aus der echten Geräteliste.
Keine Koordinaten verfügbar.
Die Karte wird über OpenStreetMap geladen und benötigt eine Internetverbindung. Das Kartenbild ist keine Messwertquelle.
Straßenabschnitte auf der Karte priorisieren
Straßenverlauf direkt auf OpenStreetMap markieren. Prioritäten 1–3 zuweisen, speichern und jederzeit ändern.
Kompakte Kartenansicht. Scrollen über der Karte bewegt die Seite; mit Strg + Mausrad die Karte zoomen. Auf dem Smartphone zum Verschieben zuerst „Karte bewegen“ aktivieren.
Karte: mit der Maus verschieben und per Mausrad oder ± zoomen. Im Zeichenmodus entlang des sichtbaren Straßenverlaufs mindestens zwei Punkte anklicken. Die Linien werden manuell eingezeichnet; eine automatische Übernahme oder verifizierte Zuordnung zur OSM-Straßengeometrie findet noch nicht statt.
Straßenabschnitt bearbeiten
Admin und User-Admin dürfen Abschnitte ihrer berechtigten Kunden anlegen, ändern oder löschen.
Straßenabschnitt auf der Karte wählen oder neu zeichnen.
Bereits markierte Straßen
Straßenplan · Veröffentlichung und jährliche Bestätigung
VersioniertEs gelten ausschließlich Prioritäten 1–3 gemäß V4.7. Alte A–D-Abschnitte bleiben zur Prüfung erhalten und sperren eine erneute Veröffentlichung, bis sie manuell neu eingestuft wurden.
Einen Kunden auswählen, um den Planstatus abzurufen.
Benutzerverwaltung für meine Kunden
User-Admins können nur neue Standardbenutzer für ihre zugewiesenen Kunden anlegen. Systemrollen und fremde Konten bleiben geschützt.
User-Admin-Ansicht
Vorschau der mandantenbezogenen Administrationsansicht.
Die lokale Benutzerverwaltung kann Standardbenutzer für die zugewiesenen Kunden anlegen. Rollen und Gerätefreigaben werden vom neuen Backend durchgesetzt; das bestehende Messdaten-Backend bleibt reine Datenquelle.
Für den echten Mandantentest mit einem eigenen User-Admin-Konto anmelden. Die Rollen-Vorschau des Systemadmins ändert nur die Darstellung und ersetzt keinen Rechte-Test.
GeoSphere Austria
Nur tatsächlich abrufbare Wetterdaten. Beobachtung und Prognose werden getrennt gekennzeichnet.
Die Beobachtungsdaten von GeoSphere sind externe Wetterwerte, nicht die lokale Fahrbahnzustandsmessung. Keine automatische Umdeutung eines Forecasts zum Istzustand.
Noch keine Wetterdaten geladen.
Serviceverträge je Kunde
PDF hinterlegen, Vertragsstatus gesondert kennzeichnen und Änderungen dokumentieren.
PDFs liegen privat im Backend, nicht im öffentlichen Assets-Verzeichnis. Der Haken dokumentiert den im System erfassten Servicevertragsstatus; er ersetzt keine vertragliche Prüfung.
PDF-Dokument hinzufügen
Versionen / hochgeladene PDF-Dokumente
Änderungsprotokoll
Aktions- und Zustandsberichte
Zeitraum und Benutzer wählen; der PDF-Bericht listet jede protokollierte Aktion mit Zeitstempel und den zugehörigen Stationsmesswerten.
Benutzer auswählen
Nachrichtencenter – Support und Kundeninformation
Individuelle Empfänger, Gemeinden oder alle registrierten Kunden; Entwürfe, Vorlagen und geplante E-Mails.
Absender: support@mz-consulting.co.at · E-Mail-Provider serverseitig konfigurierbar: SMTP/IMAP (z. B. World4You) oder Microsoft Graph. Zugangsdaten bleiben ausschließlich in der Serverkonfiguration. Nachrichten sind organisatorische Mitteilungen, keine Wetter-/Eiswarnungen.
Supportanfragen aus dem Dashboard
Posteingang support@mz-consulting.co.at
Empfänger-Stammdaten
Nur ausdrücklich gepflegte E-Mail-Kontakte; keine unkontrollierte Extraktion von E-Mail-Adressen aus der Messgeräte-API.
Nachricht verfassen
Vor dem Versand die Empfängerliste prüfen.
Noch kein Versand erfolgt.
Entwürfe, geplante und gesendete Nachrichten
Dragino LSN50V2 – Sendeintervall
Manuelle Vorgabe oder wiederkehrende Jahresregeln. Konfigurationen werden je Messstelle gespeichert; Downlinks laufen serverseitig über Actility ThingPark MQTT oder den optionalen HTTPS-Adapter.
Firmware laut Projekt: modifizierte Version 1.8.2. Die Payloads verwenden Draginos Common Command 0x01 mit Sekundenwert in 3 Bytes und werden auf FPort 2 adressiert. Das konkrete Firmwareverhalten muss zuerst an einem Test-Node bestätigt werden.
Messstellen auswählen
Intervall konfigurieren
Die folgende Konfiguration wird auf alle ausgewählten Messstellen angewendet.
Automatische Jahresregeln
Monatsbereiche sind inklusive Start- und Endmonat. Bei Startmonat größer als Endmonat läuft die Regel über den Jahreswechsel. Alle 12 Monate müssen genau einer Regel zugeordnet sein.
Noch keine Änderung vorgenommen.
Hinterlegte Downlinks (FPort 2)
Gerätepayload: 01 + 3-Byte Intervall in Sekunden, Big-Endian. Bei ThingPark wird diese Payload als payload_hex im JSON-Umschlag über MQTT veröffentlicht. Broker-/Adapterannahme bedeutet nicht, dass die Node den Downlink schon empfangen hat.
Letzte Downlink-Versuche
Benutzer, Kunden und Vertriebspartner
Zentrale Rollen- und Mandantenverwaltung mit expliziter Gerätezuordnung. Ohne Freigabe werden keine Kundendaten ausgegeben.
Vertriebspartner / Corporate Identity
Kunden / Gemeinden
Benutzerkonto
Kundenzuordnung für Benutzer
Messstellen eindeutig Kunden zuordnen
Die Geräte-ID muss der Bestands-API entsprechen. Die 16-stellige DevEUI erlaubt später die Standortübernahme aus ThingPark.
Messsystem · Y-Achsen und Skalierungszonen
Vier feste Grenzwerte pro Messgröße. Die drei Zonen behalten jeweils ein Drittel der Diagrammhöhe.
Unveränderliche lokale Versionshistorie
Ältere Messzeitpunkte werden immer mit ihrer damaligen Skala dargestellt. Liegen mehrere Versionen in einem Analysezeitraum, erscheinen getrennte Diagrammabschnitte mit jeweils eigener Y-Achse.
| Version | Gültig ab (Europe/Vienna) | Temperatur-Grenzen | Widerstands-Grenzen |
|---|
Integrationen und Zugangsdaten
Serverseitige Verbindungen zum bestehenden MZ-Backend und zum Actility ThingPark TPX Flow Connector.
Zugangsdaten werden auf dem Server verschlüsselt gespeichert. Passwörter und Tokens werden niemals zurück an den Browser gesendet. Im neuen Anmeldemodus schützt die serverseitig geprüfte Admin-Sitzung das Menü. Der bisherige ADMIN_API_KEY bleibt nur für Kompatibilität im abgeschalteten Legacy-Modus. Für Kunden gilt die lokale Gerätezuordnung zusätzlich zum Datenquellenzugriff.
Noch keine Änderung vorgenommen.
ThingPark Koordinaten (schreibgeschützte Geräte-API)
Für die API ist ein ThingPark-Servicekonto mit Leserecht erforderlich. Das Backend synchronisiert nur ausdrücklich hinterlegte DevEUIs. Fehlende oder unklare Positionen überschreiben keine bestehenden Koordinaten.
Noch kein Verbindungstest.
1. Bestehendes MZ-Backend (REST API)
Im lokalen Anmeldemodus nutzt das Backend den Service-Token auch zum Lesen der Messdaten, filtert die Antworten aber anhand der serverseitigen Kunden-/Gerätezuordnungen. Im Legacy-Modus gelten weiterhin persönliche API-Bearer-Tokens.
Noch nicht getestet.
Noch kein Datenvertrag geprüft.
2. MQTT-Uplink-Zugriff (nur lesen)
Standard-Topic: mqtt/things/+/uplink. Der Test baut eine TLS-Verbindung auf und prüft das Abonnementrecht per SUBACK. Er liest dabei keinen Messpayload aus und ändert keine Node-Konfiguration.
Noch nicht getestet.
Letzte empfangene Uplink-Rohmeldungen
3. MQTT-Downlink-Zugriff (Actility ThingPark TPX)
Topic wird je Node gebildet: mqtt/things/{DevEUI}/downlink. Der Verbindungstest authentifiziert sich nur am Broker und veröffentlicht keinen Downlink. Zum echten ACL-Test später einen einzelnen Test-Node manuell ansteuern.
Noch nicht getestet.
Freigaben für den Betrieb
Erst einschalten, nachdem Broker-Zugriff und Payload an einem einzelnen Test-Node geprüft wurden.
Der Scheduler prüft jede Minute, ob eine automatische Intervallregel fällig ist. Standard bleibt deaktiviert.
Historische Freigabekonfiguration
M1/M2/M3 sind ausschließlich in der Admin-Diagnose sichtbar. Alte Freigaben werden nur archiviert.
Rekonstruktion bzw. Originalkanal, sofern konfiguriert
Neue Zustandserkennung in der Kundenansicht
Aktives Kundensystem: M1. Umschaltung gesperrt, bis zentral gespeicherte, unveränderliche Kundenhistorien verfügbar sind. Testdaten werden nicht ausgeliefert.