Sensor einfügen und konfigurieren |
  
|
Sensor einfügen und konfigurieren |
|
Jeder Sensor / Zähler muss eingefügt werden. Alle Pflichtfelder sind mit (*) markiert und müssen definiert werden, bevor der Sensor hinzugefügt werden kann.
Klasse *
Jeder Sensor/Zähler wird einer Klasse zugeordnet.
Folgende Klassen stehen zur Verfügung:
•Sensor
Ein Sensorwert ist ein Wert, der kontinuierlich sich verändern kann (z.B. eine Temperatur oder ein Druck). Ein Sensorwert kann auch abnehmen und es gibt keine Überläufe.
•SensorSet (bedingt entsprechende Lizenz)
Ist ein Sensor, der sich aus anderen Sensoren berechnen lässt. Damit lassen sich Summen und Durchschnittswerte von über Filter zusammengestellten Sensoren (z.B. alle Hauptstromzähler aller Schulhäuser mit Baujahr > 1990).
•Zähler (aufwärts zählend) - CounterUp
Ein CounterUp-Wert ist ein typischer Zähler (Elektrozähler, Ölzähler, Wärme-/Kältemengenzähler usw.), welcher sein aktueller Zählerstand übermittelt. Ein Zähler kann einen Überlauf haben. Der Messwert kann im Gegensatz zum Sensor nicht abnehmen (ausser bei einem Zählerwechsel/-Reset/-Überlauf - wobei auch dort ein Sensor-Validierungs-Alarm erzeugt wird).
•Zähler (aufwärts/abwärts zählend) - CounterUpDown
Ein CounterUpDown-Wert ist ein bidirektionaler Zähler (z.B. Anlage mit Photovoltaik), welcher sein aktueller Zählerstand übermittelt. Der Messwert kann bei diesem Zähler auch abnehmen.
•Manueller Sensor
Ein manueller Sensor ist ein Wert, der sich gleich einem Sensorwert kontinuierlich verändern kann. Der Wert wird aber nicht automatisch erfasst, sondern durch Handeingaben definiert. Beispiele sind Anzahl Mitarbeiter, Abfallmengen usw.
•Manueller Zähler
Ein manueller Zähler ist ein Zähler, der von Hand abgelesen wird und in das System eingetragen werden muss. Dies können z.B. monatliche Messungen sein.
•Binär
Ein Binärsensor ist ein Sensor, der einen Zustand abbildet. Beispiele sind: Kompressor eingeschaltet, Tag/Nacht usw.
•Interval-Sensor
Ein spezieller Sensor vom Typ Kalender. Damit lassen sich datumsabhängige Vorgaben definieren. Es kann ein Zeitmuster erstellt werden, wann der Sensor welchen Wert besitzt. Somit lassen sich beispielsweise Öffnungszeiten oder Tag-/Nachttarife abbilden, welche später für Berechnungen genutzt werden können.
Objekt *
Jeder hinzugefügte Sensor wird einem Objekt zugewiesen. Damit wird er später auch einfacher gefunden. Sensoren, wie die Aussentemperatur, sind auch fast auf jeder Anlage zu finden. Die Zuweisung zu einem Objekt ist zudem für das Arbeiten mit relativen Sensoren wichtig.
Maschinen-ID (*)
Mit der Maschinen-ID wird die eindeutige Datenpunkt-Bezeichnung auf der Datenquelle definiert. Als Datenquelle wird die ausgewählte Komponente (Leitsystem, Mail, MQTT-Client usw.) verwendet.
Wird als Datenquelle ein ProMoS / Visi.Plus-Leitsystem verwendet, muss als Maschinen-ID der Datenpunkt (AKS) ausgewählt werden (z.B. "BN028MBus:MBus:012:Vis:E:VEnergy1" ). Die Ebenen werden jeweils mit Doppelpunkt ( ":") getrennt.
Ist ein ProMoS / Visi.Plus-Leitsystem die Datenquelle, wird ein Ordner-Symbol angezeigt, mit welchem die verfügbaren Datenpunkte in einer Baumansicht (DMS-Baum) mit Klicken ausgewählt werden können. Der DMS-Baum im Leitsystem wird intern gecached, da der Aufbau des Baumes mehrere Minuten dauern kann. Der Cash wird einmal täglich upgedatet.
Wird als Datenquelle ein MQTT-Client verwendet, muss der Topic-Pfad angegeben werden. (z.B."integration1/devices/multi-room-sensor/up/analog1/temperature/value" ). Die entsprechende MQTT-Client-Komponente abonniert/subscribed auf dem konfigurierten MQTT-Broker automatisch sämtliche Topics (also alle Maschinen-IDs der dieser Komponente angehörenden Sensoren).
Wichtig: Wird lediglich ein MQTT-Topic angegeben, muss auf diesem Topic ein numerischer Wert published werden, da diese Werte 1zu1 als Sensorwerte im EDL-Portal abgelegt werden. Wird auf ein Topic ein JSON-String published, kann das Topic als Pfad angegeben werden und hinter dem Topic-Pfad mit "json=" auf das gewünschte Element in der JSON-Struktur zugegriffen werden.
Beispiel JSON-String mit verschachtelten Objekten:
Auf dem Topic device1/topic/2/ wird folgender Payload published: { "payload": { "temperature": { "input": 10} } }
Soll auf den Wert "input" (im Beispiel mit dem Wert 10) zugegriffen werden, ist die Maschinen-ID des Sensors wie folgt: device1/topic/2/json=payload:temperature:input
Beispiel JSON-String mit verschachtelten Objekten und einem Array:
Auf dem Topic device2/topic/2/ wird folgender Payload published: { "payload": { "temperature": [ { "input": 50} ,{ "input": 42 } ] } }
Soll auf den Wert "sensor" des ersten Elements (im Beispiel mit dem Wert 50) zugegriffen werden, ist die Maschinen-ID des Sensors wie folgt: device2/topic/2/json=payload:temperature:0:input
Soll auf den Wert "sensor" des zweiten Elements (im Beispiel mit dem Wert 42) zugegriffen werden, ist die Maschinen-ID des Sensors wie folgt: device2/topic/2/json=payload:temperature:1:input
Werden auf diese Art mehrere Werte in einem Array übermittelt, muss sichergestellt werden, dass die Reihenfolge immer konstant ist, da beim Maschinen-ID immer auf das gleiche ( n-te ,wobei n für eine beliebige natürliche Zahl steht) Element zugegriffen wird.
AKS *
Jeder Sensor kriegt einen eindeutigen Namen (AKS - Anlagekennzeichnungssystem). Dieser Name ist meist kundenspezifisch.
Name *
Dieses Feld beinhaltet einen beliebigen Namen für den Sensor/Zähler. Es sollten aussagekräftige Namen verwendet werden. So ist z.B. "Temperatur" nicht sehr aussagekräftig, da man nicht sieht, um welche Temperatur es sich handelt.
Art *
Über dieses Feld wird die Art des Sensors definiert. Beispiele sind: Temperatur, Wärme, Elektrizität usw. Die Auswahl kann nicht selber erweitert werden, damit die Filtermöglichkeiten nach einem Sensortyp gewährleistet werden kann. Erweiterungswünsche bitte an den Portalbetreiber melden, damit diese eingepflegt werden können.
Einheit *
Jedem Sensor muss eine Einheit zugeordnet werden. Diese wird später auch verwendet, um einfache Plausibilitätstests durchzuführen. So macht es kaum Sinn Energie und Leistung miteinander zu verrechnen. Es ist aber nicht sinnvoll, diese softwaretechnisch zu verunmöglichen (z.B. werden bei der Berechnung absoluter Feuchte Temperaturen mit Feuchte multipliziert, um anhand einer vereinfachten Formel ).
Beispiele: °C, bar, kWh, kg, m2 usw.
Spezialfälle Temperaturdifferenz und Druckdifferenz:
Bei Temperatur- und Druckdifferenzen ist besondere Vorsicht geboten, da die im Portal zur Verfügung stehenden Umrechnungen nur für absolute Temperaturen und Drücke gelten. Somit darf eine Temperaturdifferenz (beispielsweise 10 °C) nicht in Kelvin umgerechnet werden, da in diesem Fall 10 °C als absolute Temperatur betrachtet wird und das Ergebnis somit 283.15 K wäre. Gleiches gilt bei der Druckdifferenz.
Kommastellen
Die Anzahl angezeigter Kommastellen in Tabellen, falls nicht die Einheiten und Standard-Nachkommastellen übernommen werden sollen.
Kumulativ-Methode
Summe = Die Werte werden bei Veränderung des Zeitbereichs summiert (Beispiele: Verbrauchswerte von Energien, Wasser, Volumen usw.)
Durchschnitt = Die Werte werden bei Veränderung des Zeitbereichs gemittelt (Beispiele: Temperaturen, Drücke, Luftfeuchtigkeit usw.)
Letzter Wert = Als kumulierter Wert wird immer der letzte Wert der ausgewählten Zeitspanne verwendet. (Beispiel: Wochenwert = Wert vom Sonntag um 23:45 Uhr)
(Hinweis: Zeichnet ein Sensor Zahlwerte von einem Betriebsstatus auf (z.B. 0 = aus; 1 = Automatik; 2 = Sommerbetrieb usw.), kann ebenfalls die Kumulativ-Methode "Letzter Wert" genutzt werden. In Kombination mit "Werte werden als Verbrauch versendet" auf "JA" wird dann (bei entsprechender Trenderfassung im Gebäudeleitsystem) jede Veränderung des Betriebsstatus mit korrektem Zeitstempel übernommen. Dadurch werden auch Veränderungen kleiner als 15 Minuten aufgezeichnet.)
Werte werden als Verbrauch versendet
Liefert ein Zähler Verbrauchswerte (keine Zählerstände), muss dieser als "Sensor" (nicht als "Zähler aufwärts zählend") und mit aktivierter Option "Werte werden als Verbrauch gesendet" erstellt werden. Zudem ist der Kumulativ Typ auf "Summe" zu stellen (gemäss Beschreibung oben).
Wird diese Option aktiviert,werden keine interpolierten 15-Minuten-Werte aus dem Leitsystem ProMoS abgerufen, sondern alle verfügbaren Werte.
Das Portal wertet den Zeitstempel als Ende der Messperiode aus.
Achtung: Ist diese Option aktiviert, werden alle Werte vom Leitsystem ProMoS (Datenquelle) übernommen, auch kleiner als 15 Minuten Werte. (Dies ist nötig da bei Verbrauchswerten eine Summe von allen Werten berechnet werden muss.). Entsprechend können bei einer Falschkonfiguration eines Sensors mit dieser Option unnötig grosse Datenmengen resultieren.
In- Ausserbetriebnahmedatum Doku In- Ausserbetriebnahmedatum
Daten werden erst ab dem Inbetriebnahmedatum ins Portal geladen. Ab diesem Zeitpunkt sind sämtliche Überwachungen aktiv.
Bis 3 Monate nach dem Ausserbetriebnahmedatum werden noch Daten abgerufen.
Danach wird der Sensor nicht mehr automatisch berechnet, ausser wenn das Ausserbetriebnahmedatum geändert wird.
Sensor-Ausfallerkennung Doku Sensorausfallerkennung
Es kann eine Zeitangabe angegeben werden, in welcher sich der Wert verändern muss (z.B. eine Boilertemperatur muss sich innerhalb von 2 Stunden verändern, oder ein Wasserzähler muss innerhalb einer Woche ändern, andernfalls wird ein Alarm generiert).
Vorsicht bei Energiezählern und Werten aus Heizungsanlagen. Diese Werte ändern sich im Sommer u.U. nicht.
Sensor für die Ersatzwertbildung
Jedem Sensor kann ein (virtueller oder gemessener) Sensor zugewiesen werden, der im Falle eines Sensorausfalls einen Ersatzwert liefert.
Beispiele:
•Wetterprognosedaten als Ersatzwertgrundlage für den Aussentemperaturfühler.
•Energiezähler Gaskessel für Berechnung des Gasverbrauchs, falls der Gaszähler geeicht werden muss (nur Verbrauch - kein Zählerstand).
Falls angegeben, steht der Ersatzwert bei Ausfall des Sensors dann beim Quittieren eines Alarms zur Verfügung.
Korrekturfaktor
Die Erfahrungen zeigen, dass die Mess- und Zählwerte teilweise grössere Abweichungen zur effektiven Messgrösse haben. So kann es vorkommen, dass ein Ölzähler zu wenig Oel misst und daher der Wirkungsgrad eines Kessels weit über 100% steigt. Mit dem Korrekturfaktor können leichte Abweichungen korrigiert werden.
Der Korrekturfaktor sollte nicht eingesetzt werden, um Einheiten umzurechnen. Dies wird einerseits mittels virtuellen Sensoren realisiert oder durch Auswahl einer andern Einheit (z.B. können Liter Oel direkt in kWh umgeschaltet werden, ohne dass etwas berechnet werden muss).
Grenzwert-Regeln
Jedem Sensor können Grenzwerte zugewiesen werden (siehe Kapitel Grenzwertüberwachungen).
Es sind nur die Grenzwerte mit exakt gleicher Einheit (also bei Sensor-Einheit kWh werden keine MWh-Grenzwerte angezeigt) ersichtlich.
Weitere Datenfelder
Bei den Sensoren können beliebige weitere Datenfelder definiert werden (siehe Kapitel "Feld Konfig."). Daher kann es durchaus vorkommen, dass die Eingabemaske weit mehr Eingaben erfordert, als hier aufgeführt sind. Diese wurden kundenspezifisch definiert und können auch als Pflichtfeld definiert sein.
Je nach Sensor-Klasse können auch ergänzende Datenfelder, wie z.B. "Überlauf des Zählers", definiert sein:
Datenpunkte protokollieren nur Änderungen
Wenn diese Option nicht aktiviert ist, so wird davon ausgegangen, dass 15-Minuten-Werte vorliegen. Fehlende Werte werden nicht interpoliert und generieren eine Fehlermeldung, die quittiert werden muss.
Wenn von einem Zähler z.B. nur Tageswerte vorliegen, dann sollte die Option aktiviert werden, damit die dazwischenliegenden Werte automatisch interpoliert werden, ohne dass Fehlermeldungen wegen fehlender Daten generiert werden.
Wird die Option später angepasst, so werden die Roh-Daten erneut aus dem Leitsystem ausgelesen und entsprechend in das Energiemonitoring eingefügt. Daten, die über die API eingelesen werden, werden nicht neu eingelesen, jedoch werden alle Berechnungen neu gemacht (inkl. Interpolation von fehlenden Werten).
(Zusatzoption: Alle Daten erneut einlesen?)
Wenn die Konfiguration "Datenpunkte protokollieren nur Änderungen" geändert wird, wird die zusätzliche Option "Alle Daten erneut einlesen?" angezeigt. Falls diese Option aktiviert wird, werden sämtliche Daten des betreffenden Sensors verworfen und vom datenführenden (Leit-)System neu eingelesen.
Achtung! Dies wird zum Verlust der Sensordaten und dessen Korrekturwerten führen.
Zeitangabe
Dieses Feld ist nur bei manuellen Sensoren und manuellen Zählern vorhanden und definiert das Datumsformat, wie die Werte eingegeben werden. Wird beispielsweise "15 Minuten" definiert, werden die manuell eingetragenen Werte mit einem Zeitstempel im Format "TT.MM.JJJJ HH:MM" eingegeben (also z.B. 01.01.2010 08:15). Wird hingegen "Monat" definiert, kann bei der Eingabe der manuellen Daten nur Monat und Jahr ausgewählt werden (z.B. 01.2020).
Berechne Zwischenwerte
Dieses Feld ist nur bei manuellen Sensoren vorhanden und definiert, ob die eingegebenen Werte auf 15-Minuten-Werte heruntergerechnet/verteilt werden sollen oder nicht. Falls diese Option auf "Nein" gesetzt ist, werden die Werte nur am angegebenen Zeitpunkt eingetragen und nicht auf 15-Minuten-Werte verteilt. Detaillierte Informationen sind im Kapitel Berechne Zwischenwerte beschrieben.
Maximalverbrauch innerhalb 15 Minuten
Es kann definiert werden, wie viel der Wert innerhalb von 15 Minuten ändern darf. Wenn z.B. ein Wasserzähler mit 1 Zoll-Anschlüssen in 15 Minuten 30 m3 Wasser zählt, dann kann man davon ausgehen, dass hier etwas nicht stimmt (meist liegen Kommunikationsprobleme vor).
Dies dient dazu, um fehlerhafte Spitzen zu ignorieren, damit diese nicht Auswertungen verfälschen.
Max. Rückwärtszählung (2h) Doku Sensorvalidierung
Ein Zähler kann grundsätzlich nur Aufwärtszählen (Ausnahmen sind bidirektionale Zähler, für welche die Klasse "Zähler (aufwärts/abwärts zählend)" zu wählen ist). Ein kleinerer Wert deutet auf einen Zählerwechsel oder einen Zählwertüberlauf hin. Es kann aber vorkommen, dass im Sommer ein Wärmezähler um 0.1 kWh rückwärts zählt, weil im fast stehenden Wasser eine Temperaturdifferenz bei Vorlauf- und Rücklauftemperatur entsteht. Um solche Fehler zu unterdrücken, kann in dieser Option ein Wert definiert werden, der verhindert, dass Fehlalarme generiert werden.
Der definierte Wert gibt den maximalen Wert an, um welchen sich der Zählerstand innerhalb von 15 Minuten oder insgesamt über 2 Stunden verringern darf. Sinkt der Wert tiefer als die genannte Toleranz, wird ein Alarm erstellt. Steigt der Wert nach 2 Stunden nicht über den letzten gültigen Zählerstand, wird ebenfalls ein Alarm erstellt (sofern der Anstieg nicht innerhalb der Toleranz der weiteren Konfigurationsmöglichkeit "Max Rückwärtszählung" liegt.
Max. Rückwärtszählung
Ergänzend zur oben erklärten "Max Rückwärtszählung 2h" kann mit der weiteren Konfigurationsmöglichkeit eine weitere Toleranz für eine Rückwärtszählung definiert werden.
Der eingegebene Wert wird generell pro 15-Minuten-Wert rückwärts zählend toleriert.
ACHTUNG: Durch diese weitere konfigurierbare Toleranz kann ein Zähler ohne Alarm über eine längere Zeitperiode langsam zurück zählen.
Maximale Wertänderung
Bei Zählern (aufwärts/abwärts zählend) kann definiert werden, um welchen maximalen Wert sich der Zählerstand innerhalb von 15 Minuten verändern darf. Wird der Wert überschritten, wird ein Sensor-Validierungs-Alarm erzeugt.
Durch die Eingabe von Wert 0 wird diese Prüfung deaktiviert.