Omasn-Cloud 'Monitoring & Notify'


Die Omasn-Cloud enthält jetzt Monitoring- und Benachrichtigungsfunktionen.
Signal

Beispiel: Überwachung der Raumtemperatur für 'Brandvorwarnung'

Signal Messenger E-Mail
Signal Image Mail Image

Es können Bedingungen definiert werden, welche beim Empfang jeder Omasn-Sensormeldungen geprüft werden. Weiters werden Nachrichtenkanäle - etwa Signal-Messenger-Empfänger oder E-Mail-Adressen - konfiguriert.

Ein Omasn-Monitor fasst eine Gruppe von Bedingungen und ein Liste von Nachrichtenkanäle zusammen. Omasn-Monitore können dann Omasn Sensoren zugeordnet werden.


Grafana-Schnittstelle für Omasn-Cloud

Für die Darstellung von Sensorwerten mittels Grafana stellt die Omasn-Cloud eine json-Schnittstelle zur Verfügung.

Grafana Image

Omasn BLE Wetterstation - nRF52

Eine erste Wetterstation mit BLE (Bluetooth Low Energy) Datenübertragung ist im Testbetrieb.

Omasn BLE-Wettersensor

Die Wetterstation besteht aus einem BME280 Sensor (Temperatur, Druck und relative Luftfeuchtigkeit) und einem Regenmesser. Die Station wird mit 3 AAA Batterien versorgt.

Für die Verarbeitung der Messwerte und die Übertragung der Daten werkelt ein nRF52 SoC von Nordic Semiconductor (nRF52840 Dongle). Die nRF52840-Firmware wurde auf Basis des Omasn-Frameworks erstellt und ist für den Batteriebetrieb optimiert. Im Mittel verbraucht die Wetterstation 60 µA.

Die BLE-Gegenstelle ist ein ESP32-Modul. Die ESP32-Firmware wurde mit dem ESP32-IDF erstellt und basiert auch auf dem Omasn-Framework. Die ESP32-Firmware leitet die Omasn-Sensordaten (BLE) mittels Omasn-Routing an die Omasn-Cloud (über WiFi) weiter. Die Daten der Wetterstation können am Omasn-Testserver beobachtet werden: (-> OmasnCloud - Testserver).


Die Loseneggerklamm

In der Nähe der Loseneggerklamm leben einige Ameisen.

Ameisen

Da entstand auch die Idee zu 'Omasn'. (Loseneggerklamm Bilder)

OMASN-Logikeditor

Die SPS-Funktionalität der Omasn-FW wurde um einen webbasierten OMASN-Logikeditor erweitert

OMPLC-Editor


Der aktuelle Zustand der SPS-Logik kann über das WEB jederzeit beobachtet werden.
Die Logik kann online geändert/erweitert und am Omasn-Node aktualisiert werden.
Weiters können die Logikdaten am PC für eine spätere Verwendung gespeichert werden.

omasn - object oriented micro application service network

OMASN ist ein Baukasten zur Realisierung von Internet of Things (IoT) Anwendungen. Der Baukasten umfasst fertige Komponenten zur Realisierung von Omasn-Nodes.
Omasn-Nodes verwalten abstrakte Omasn-Objekte, welche allgemeine Services (get, set, ind) zur Verfügung stellen. Omasn-Objekte können dabei als Client oder Server vorkommen. Die Verknüpfung von Client und Server Objekten führt dann zu verteilten Omasn-Anwendungen.
Neben Omasn-Nodes können Omasn-Objekte auch in mobile Apps oder in Cloud-Anwendungen integriert werden. Die Service-Kommunikation zwischen den Omasn-Objekten erfolgt 'connectionless' mittels Omasn-Telegrammen. Auch eine unidirektionale Interaktion ist möglich.

OMASN

Omasn-Objekten können über 'lokale Protokolle' (RS232, USB, Ethernet, BLE, IEEE802.15.4, WLAN) Omasn-Telegramme austauschen. Auch über 'Internet-Protokolle' (UDP, TCP, HTTP, WebSockets) ist die Service-Interaktion zwischen Omasn-Objekte möglich. Da keine Verbindung aufgebaut werden muss, kann die Omasn-Kommunikation sehr einfach mittels NB-IoT (UDP) realisiert werden.

Omasn-Wettersensor

Ein erster Omasn-Wettersensor ist im Testbetrieb.

Omasn Wettersensor

Der Wettersensor erfasst Werte für Temperatur, Druck und relativer Luftfeuchtigkeit. Weiters ist ein Regensensor an den Wettersensor angebunden. Die Sensorwerte werden in die OmasnCloud übertragen und stehen in Echtzeit im Internet zur Verfügung.

Die Daten des Wettersensors können am Omasn-Testserver beobachtet werden:
(-> OmasnCloud - Testserver).

Der Wettersensor ist mittels Omasn-Baukasten realisiert und läuft auf einem EFM32-Prozessor. Die Übertragung der Daten erfolgt über LORA (RFM95W) zu einem ESP8266-LORA/WiFi Gateway.



Omasn am Sonoff 4CH Pro

Die Omasn FW läuft erfolgreich am Sonoff 4CH Pro.

Sonoff 4CH Pro

Diese erweiterte Omasn-FW ermöglicht das Schalten der 4 Relais über ein WEB-Interface. Weiters enthält die Omasn-FW eine SPS-Funktionalität. Über das WEB-Interface kann eine individuelle Logic (Verknüpfungen und Zeitglieder) festgelegt werden.



Omasn-Sensor FW verfügbar

Eine erste Version der Omasn-Sensor FW für ESP8266 ist verfügbar (-> FW Download).
Pdf

Omasn-Sensor-Nodes beinhalten neben den allgemeinen Omasn-Funktionen spezielle Funktionen zum Erfassen und Melden von Sensorwerten.


Sensor-OmasnCloud online

Eine erste Version der Sensor-OmasnClound ist online (-> OmasnCloud).

Omasn Cloud

Omasn-Sensoren senden Sensorwerte an die OmasnCloud. Die OmasnCloud speichert die Werte und stellt via WEB-Interface Informationen über Omasn-Sensoren und Omasn-Nodes zur Verfügung.


Omasn via LORA

Erste Interaktionen zwischen Omasn-Nodes mittels LORA konnten erfolgreicht getestet werden.

Lora Modules

Der Test erfolgte mit zwei Ra-01 LORA-Modulen. Ein Modul war an einen EFM32 angebunden, das zweite Modul wurde über einen Raspberry Pi angesteuert. Unter realen Bedingungen konnten Reichweiten von > 1km erreicht werden. Ziel ist es, energieautarke Sensoren an das Omasn-Netz anzubinden.



OMASN jetzt auch für ESP8266

Der Omasn-Baukasten ist jetzt auch auf der ESP8266-Plattform lauffähig. Omasn-Nodes können somit sehr einfach mittels WLAN in bestehende Netzwerke eingebunden werden.

ESP8266mod

Eine große Auswahl an ESP8266-Modulen und ESP8266-Applikationsboards steht für den Omasn-Baukasten zur Verfügung. Auch fertige ESP8266-Produkte (etwa Sonoff) können mit Omasn betrieben werden.

OMASN IoT Gateway - Single Chip Lösung

IoT Gateways (GW) zur Anbindung von IoT-Endgeräten an Cloud Server werden heute üblicherweise mit zwei Komponenten realisiert - einem embedded Linux System für die Ethernet/IP/HTTP Funktionen, und Wireless Module für die Abarbeitung der Funkprotokolle. Für Omasn wurde jetzt ein IoT GW realisiert, welcher die vollständige Gateway-Funktionen auf einem Wireless Modul zum Ablauf bringt. Die Lösung basiert auf den CC26xx/CC13xx SoCs von TI. Die Ethernet-Anbindung erfolgt über einen ENC26J60 Chip. Der GW unterstützt den Transport der Omasn-Kommunikation über UDP und über HTTP (wahlweise auch verschlüsselt). Auf der Funkseite steht neben 802.15.4 und BLE auch eine 'LongRange-Variante' für Verbindungen über 1000 m zur Verfügung. Die Ip-Konfiguration des GW kann statisch oder mit DHCP erfolgen. Für die Adressfindung von CloudServer-Namen ist im GW DNS implementiert.

Eigenschaften

  • OMASN dient zur Realisierung von IoT-Anwendungen. Solche Anwendung sind etwa 'Personal Area Network (PAN) Apps', wie Temperatur-Regelung (Heizkörper-Stellantrieb), mobilder Blutdruckmesser oder AV-Fernsteuerungen. Weiters kann OMASN zur Realisierung von 'Datensammlern' für BigData-Anwendungen dienen. Beispiele dazu sind etwa Wettersensoren für die Berechnung von Wettervorhersagen oder Omasn-Smart-Meter für Smart-Grid Anwendungen.
  • Jeder OMASN-Node im Netzwerk hat mindestens eine Kommunikationsschnittstelle. (z.B RS232, USB, WLAN, IEEE802.15.4, Bluetooth, Bluetooth LE; aber auch SMS, TCP, HTTP, TWITTER, …)
  • Jedes OMASN Netzwerk kann in mehrere virtuelle Netzwerke unterteilt werden (ähnlich VLANs). So kann z.B. das Zählernetzwerk vom Haustechniknetzwerk logisch getrennt werden.
  • Ein OMASN-Node enthält logische OMASN-EndPoints. OMASN-EndPoints haben im Netzwerk eine eindeutige Adresse.
  • Jeder OMASN-Node im Netzwerk (auch der kleinste) enthält eine Routing-Funktion. Das Routing wird dabei separat für jedes virtuelle Netzwerk durchgeführt. Die Routing-Funktion ist medienunabhängig. D.h ein Gateway-Node - mit einer IEEE802.15.4-Funkschnittstelle zu Sensor-Nodes und einer HTTP-Schnittstelle zu einer Web-Anwendung - transportiert und konvertiert OMASN-Meldungen automatisch zwischen den verschiedenen Schnittstellentypen.
  • Ein OMASN-Endpoint enthält OMASN-Service-Objekte. Ein OMASN-Service-Objekt implementiert eine sog. OMASN-Klasse. OMASN-Klassen werden mittels einer speziellen OMASN-Sprache beschrieben. Mit Code-Generatoren können Code-Teile für Sprachen, wie C, Java oder C# generiert werden. U.a erzeugt ein Code-Generator C-Stubs und Java-Proxy-Klassen aus den OMASN-Klassen.
  • Für jedes OMASN-Objekt ist eine spezifische End-to-End Authentifizierung und Verschlüsselung möglich.
  • Die OMSAN-Anforderungen sind so gewählt, dass Mikroprozessoren mit 64kByte-Flash und 12kByte Ram verwendet werden können.
  • Ein OMASN-EndPoint kann aber auch ein Servlet in einem Web-Server sein. Weiters sind PC-Anwendungen oder Android-Apps mögliche OMASN-EndPoints.

Die OMASN-Sprache OMDL

Ein Vorgabe für den IoT-Baukasten war, dass die Schnittstellen zu den Remote-Objekten (OmObjekte) formal beschrieben werden. Dieses Konzept ermöglicht die Anwendung von Code-Generatoren. Eine sehr gebräuchliche Unart ist es dafür XML-Files zu verwenden. Meine persönliche Ansicht ist aber, dass XML ungeeignet ist um für Menschen lesbare Dokumente zu schreiben (Die spitzen Klammern verstellen die Sicht auf die tatsächlichen Inhalte). Daher wurde eine eigene Sprache entwickelt. Da Embedded-Entwickler in der täglichen Arbeit mit Sprachen wie C oder Java arbeiten, war es naheliegend eine Sprache sehr ähnlich zu C bzw. Java zu definieren. Zur Vollständigkeit: die Sprache hab ich OMDL – für OMASN Description Language – genannt.

Zentrales Element in OMDL ist die OmKlasse. OmKlassen beschreiben den Bauplan eines OmObjektes. Eine OmKlasse enthält dabei Basis-Attribute und (optional) komplexe Attribute.

Folgender Code zeigt die Definition einer OMASN-Klasse für Sensoren:

OMASN