Corona-IoT Story

Welche Daten können z.B. verarbeitet werden?

• Daten von jeder Art Sensoren
• Daten an jede Art Aktoren
• Maschinen- und Anlagedaten
• Konfigurationsdaten
• Daten von Eingabegeräten und Bedienterminals
• Daten an Dashboards, Infodisplays und Visualisierungen.
• Daten von und an Internet- oder Intranetdienste
• Daten an und von beliebigen Programmen auf PC, Handy, Steuerungen
• Daten aus und in andere Datenbanken
• Daten aus und in beliebige Kommunikationskanäle
• Daten über beliebige Bussysteme und Kommunikationsprotokolle
• Daten in praktisch beliebigen Datenformaten

Adapter und Datenbroker sind der Schlüssel zu dieser Vielfältigkeit.

Für die gewählte Lösung gibt es bereits eine sehr große Anzahl von Adaptern für viele gängige Anwendungen. Aber auch die Entwicklung von Adaptern für weitere Anforderungen ist mit geringem Aufwand möglich.

Für unsere interne Gebäudesteuerung

… werden z.B. jede Menge Umweltsensoren (Licht, Temperatur, Feuchtigkeit, Luftdruck), Kontaktsensoren (alle Fenster und Türen und mehr), Bewegungssensoren, Vibrations-, Beschleunigungs- und Neigungssensoren, Kamera mit Bewegungs- und Objekterkennung, IR-Fernbedienungen, RF-Fernbedienungen, drahtlose Schalter, Türklingeln, Daten von Wetterdiensten, Ortungsdaten, ein eigener universeller Alexa-Skill ausschließlich zur Spracherkennung, Smartphone Apps, PC Apps, Webbrowser, Info- und Bedienterminals, ESP8266/ESP32-Geräte und vieles andere mehr verwendet

Es werden Beleuchtung, Steckdosen, Klimaanlagen, Mediageräte, Elektrokamin, Abzugshauben, Belüftungen, Garagentore u.a.m. gesteuert, Musik- und Videostreams initiiert, alles bei Bedarf auch per Smartphone oder Sprache geschalten, abgefragt, konfiguriert oder signalisiert. Alles ist möglich.

Bei der Gebäudesteuerung wurde eine Vielzahl neuer Geräte angeschafft. Ziel war jedoch auch, die große Anzahl bereits vorhandener Geräte zu integrieren. Die Geräte stammen von verschiedenen Herstellern, verwenden unterschiedliche Kommunikationswege und -protokolle.

Alle Teilnehmer interagieren übergreifend zusammen: RF-Fernbedienungen steuern auch Bluetooth-, Infrarot-Geräte, Philips-Hue-Lampen, Zigbee- und WLAN-Aktoren, Zigbee-Schalter schalten auch Infrarot und RF-Geräte. Die Bewegungserkennung einer Kamera wird in der gleichen Weise abgebildet, wie Zigbee- oder RF-Motion-Sensoren.

Die Kommunikation zwischen den Teilnehmern erfolgt über LAN/WLAN, MQTT, http, REST, Websockets, SignalR, udp, upnp, FTP, RTSP, RTMP, Zigbee, RF(433 MHz), Infrarot, Bluetooth u.a.m..

Die Daten werden bei uns aktuell über einen iobroker-Master und einen iobroker-Slave, zwei RF-Bridges, zwei ZigBee-Controllern als Koordinatoren, 4 Infrarot-Bridges, ein Philips-Hue-Hub u.a.m. über drei Etagen und den Hof erfasst, verarbeitet und ausgegeben. Die Verwaltung erfolgt zentral über den Master. Die Lösung ist über das hinzufügen weiterer Slaves, Bridges und Controllern über LAN/WLAN/Powerline auch für sehr große Installationen skalierbar.

Es werden Daten in Form von Dashboards und Bedienterminals auf PCs, Smartphones, Fernseher, Echo Show, Webbrowser in Echtzeit angezeigt und erfasst, historisierte Daten in Zeitverläufen oder ggf. untereinander abhängig dargestellt.

Mit noch vorhanden gewesenen Leap-Motion-Controllern ist zudem eine äußerst flexible berührungslose 3D-Hand- und Fingergestensteuerung möglich, die z.B. in Küche, Bad und Toilette verwendet werden kann, also Umgebungen wo ggf. eine zusätzliche berührungslose Interaktion erforderlich oder gewünscht ist.

Es werden Ortungsdaten über externe Locationservices, Smartphones, GPS-tracker und einem eigenen unabhängigen lokalen GPS-Tracking-Service verarbeitet. Personen und Orte können zudem via WLAN-AP’s innerhalb von Gebäuden lokalisiert werden. Rechtlich Rahmenbedingen sind dabei natürlich unbedingt zu berücksichtigen und Persönlichkeitsrechte zu wahren.

Für die Spracherkennung, Kommunikation, sowie ebenfalls Visualisierung, sind bei uns insgesamt 10 Alexa Echo Show, Dot und Spot-Geräte in den verschiedenen Räumen installiert. Eine Sprechererkennung wäre bei Alexa ebenfalls möglich. (Rechtliche Rahmenbedingung und Persönlichkeitsrechte berücksichtigen!) Eine Ablösung durch eine eigene Cloud-unabhängige Spracherkennung wird hier noch untersucht.

Es werden zudem eine Reihe weiterer Informationsservices aus dem Internet eingebunden, wie z.B. für Nachrichten, Wetter, Fernsehprogramm, Auskunftssysteme, sowie verschiedene andere mehr.

Und für die Industrie oder andere Bereiche?

Quelle und Ziel der Daten sind universell: Ob Maschinen- und Anlagedaten, Messwerte, Steuer- und Regelgeräte, Konfigurationsdaten, Rezepte, Finanzdaten oder Wirtschaftskennzahlen, Wetterdaten, Geodaten, Umweltdaten, Kalenderdaten, Nachrichten, Fernsehprogramme etc. - Erfassung und Verarbeitung der Daten erfolgt auf die gleiche Weise.

Alles ist mit allem verbunden.

Es gibt für die bei uns eingesetzte Lösung bereits eine sehr große Anzahl von Adaptern aller mehr oder weniger gängigen Datenprotokolle, Bussysteme, Internetdienste und vieles anderes mehr. Aber auch die Implementierung eigener Adapter ist mit geringem Aufwand möglich. Die vorhandenen Adapter sind praktisch alle Open Source.

Über Skripte und Adapter in beinahe beliebigen Sprachen, z.B. JavaScript, TypeScript, Blockly, Node-Red, werden Regeln erstellt, Daten aggregiert, Datenpunkte verknüpft. Über eigene Programme können auch C/C++, C#, Java, Python, SmallTalk oder beliebige andere Programmiersprachen verwendet werden und interagieren.

Skripte und Anwendungen können auf dem Master oder den Slaves, aber auch auf beliebigen anderen Geräten ausgeführt werden.

Daten können aus verschieden Gebäuden, Produktionsbereichen, Standorten und Filialen integriert werden.

Was passiert mit den erfassten Daten?

Eingehende Daten oder Signale werden in einer Echtzeitdatenbank gespeichert und bei Bedarf historisiert.

Darüber hinaus werden Eingang und Änderung von Daten signalisiert. Diese Signale können von beliebigen andere Datenpunkten, Skripten, Adaptern, internen oder externen Anwendungen, Geräten, Maschinen oder sonstigen denkbaren Prozessen verarbeitet werden.

Jeglicher Datenpunkt sowie die Metadaten können von anderen Teilnehmern aboniert werden. Es können Daten in Datenpunktepunkte geschrieben und damit andere Prozesse, Adapter oder Aktoren getriggert und gesteuert werden.

Wie sieht es mit der Datensicherheit aus?

Für die Verwaltung und Konfiguration sind Authentifikation und Autorisierung, sowie Berechtigungen für jeden einzelnen Datenpunkt, Adapter und Skripte implementiert. Für den Einsatz in sensiblem Umfeld muss das aktuell jedoch noch jeweils geprüft und ggf. an die lokalen Gegebenheiten angepasst werden.

Einige Kommunikationsprotokolle sind oft nicht abzusichern und deshalb zu prüfen, ob für sensible Anwendung ggf. ungeeignet. Dazu zählen z.B. insbesondere RF (433MHz etc.) sowie auch Infrarot. Infrarot kann dabei wegen der begrenzten Ausbreitung noch lokal eingesetzt werden. Bereits vorhandene Geräte können also weiterverwendet werden. Da über die übergreifende Integration eine universelle Interaktion aller Komponenten möglich ist, muss hier aber entsprechend Augenmerk gelegt werden.

Cloud-basierte Funktionen oder Geräte sind für sensible Bereiche generell ein Problem und sollten nach Möglichkeit hier nicht verwendet werden. Dazu zählen auch diverse Spracheerkennungssysteme.

Für unsere interne Sparchererkennung haben wir einen speziellen Alexa-Skill implementiert, der die Interaktion mit den Cloud-Services von Amazon u.a. auf ein Minimum reduziert und die Verarbeitung der Daten soweit möglich auf eigene lokale Systeme verlagert. Dies ist jedoch für sehr sensible Bereiche u.U. nicht ausreichend. Nach einer vollständig unabhängigen Lösung wird hier noch gesucht.

Die bei uns historisch bedingt noch verwendete Philips-Hue-Bridge wird durch unsere eigenen Anwendungen zwar ausschließlich intern angesprochen, ist jedoch über Alexa mit dem Hue-Skill mit der Cloud verbunden. Die Philips-Hue-Bridge wird deshalb sukzessive durch unsere eigenen Zigbee-Koordinatoren ersetzt. Außerdem gibt es bei Geräten für die Philips Hue ein aggressives Vendor-LockIn.

Die meisten kommerziellen WLAN-Geräte mit ESP8266/ESP32 verwenden eine auf Tuya basierende Cloud-Anbindung über ausländische Provider. Bei diesen Geräten kann zumeist die Firmware ersetzt werden, so dass diese dann ausschließlich lokal z.B. via MQTT angesteuert werden können. Da es sich bei den Herstellern der Geräte oft um kleine und ggf. kurzlebige Unternehmen handelt, besteht zu dem das Risiko, dass deren Serverinfrastruktur irgendwann nicht mehr verfügbar ist und die Geräte nicht mehr verwendet werden können. Durch die eigene Firmware wird dieses Risiko ebenfalls eliminiert. Außerdem wird auch die Reaktionsgeschwindigkeit der Geräte erheblich verbessert und die Funktionalität oft erweitert.