Aufbau digital production Platform

Die lokale (client) Plattform "digitalproduction" basiert auf dem openHabian Projekt und wurde für den Einsatz in der Bewirtschaftung von Gewächsräumen optimiert. Es ist möglich diesen Controller zentral in einem Betriebsnetzwerk zu betreiben oder auch dezentral im Gewächsraum zu platzieren und als Acces Point für alle Sensoren/ Aktoren zu konfigurieren.

Dezentraler Einsatz

Für den dezentralen Einsatz empfiehlt sich folgende Konfiguration der Netzwerkeinstellungen: Die Kommunikation im dezentralen Modus (Platform <-> Senoren /aktoren) folgt über wifi ausser für die Liftsteuerung welche direkt mit dem Raspberry verbunden sind (Modbus) . Hierfür wird auf dem Raspberry ein Wifi 2.4 Ghz Netzwerk für die oben beschriebenen Broadcast adressen eingerichtet. Wenn mehrere Roboter eingesetzt werden, wird ein mesh wifi eingerichtet.

https://gist.github.com/christofluethi/1be3b5e6b9010a4d4bdcf2a892fedb47

Zentraler Einsatz

Sofern die Plattform Zentral eingesetzt wird muss die Netzwerkinfrastruktur entsprechend in den Räumen ausgebaut werden und die Einbindung in das Netzwerkes gemäss der nachfolgender Beschreibung erfolgen:

Logischer Layer

Alle an die digitalproduction Plattform angeschlossenen Geräte sollten mittles mDNS Service angebunden werden. Hierzu sollte die Gerätenamen alle auf XXX.local enden. Zusätzliche Infos für die Anbindung von Geräten über mDNS: siehe mDNS-Einbindung

Physikalischer Layer

Verfügbare IP-Range pro IPV4 Netzwerk: 254 IPv4-Adresse

• Adresse 1 (1): Router (Client)
• Adressen 2-9 (8): Reserve (Wifi Acces Points)
• Adressen 10-99 (90): Aktoren (Beleuchtungs-Relais, Klima-Steuerung)
• Adressen 100-150 (50): Sensoren (Temperaturfühler, Schalter, Feuchtigkeitssensor, Kameras)
• Adressen 250-254 (5): digitalproduction Platform (Raspberry Pi)

Kommuniktaion der Teilnehmer (Client-Server)

Die Verfügbaren Kommunikations Schnitstellen für die digitalproduction Plattform sind:

1. CoIoT (Coap Tool von Shelly)
2. MQTT (Mosquitto Broker)

Für die Kommunikation unter den Teilnehmer soll primär die als RESTfull verfügbare CoIoT Schnitstelle von Shelly verwendet werden. Diese ist mächtiger, da neben Publish und Subscribe auch request, response und get hat. Diese Möglichkeiten führen zu grösserer Flexibilität und auch einem tieferen Batterieverbrauch bei den Batterie betriebenen Geräte. Als Beschrieb zur CoAP Schnitstelle ist folgender Artikel interessant Heisse RESTful mit CoAP Shelly vewendet eine eigete Version des CoAP Protokoll sogenannt CoIoT Shelly CoIoT V1 Für den Einsatz von CoIoT muss unbedingt IPV4 eingestellt sein weshalb undedingt darauf zu achten ist, dass bei Openhab unter System Configuration IPv6 deaktiviert wird.

In Fällen wo CoIoT nicht verfügbar ist wird der Mosquitto MQTT Broker verwendet und die Geräte können als MQTT-Think (MQTT Binding) hinzugefügt werden.

mDNS-Einbindung (Entwurf)

Mittels mDns werden die Teilnehmer im lokalen Netzwerk sichtbar gemacht und können so entdeckt werden. Dies ist seit der Einführung von Apples Bonjour Druckertreiber eine stark verbreiteter Standart für die Einrichtung verschiedener Netzwerkdienste. (Sonos, Drucker Shelly etc..) Dies funktioniert nur im Netzwerk mit selber Broadcast Adresse. Ein Routing in eine andere Broadcast Adresse ist nur bedingt möglich. Die mDNS-Einbindung ist im Rahmen als MDNSDiscoveryService implementiert. Um die Entwicklung zu erleichtern, müssen Binding-Entwickler lediglich einen MDNSDiscoveryParticipant implementieren. Hier muss der Entwickler nur vier einfache Methoden implementieren:

getServiceType - Definiert den mDNS-Diensttyp : _http._tcp.local

. getSupportedThingTypeUIDs - Gibt die Liste der Ding-Typ-UIDs zurück, die dieser Teilnehmer unterstützt. Der Suchdienst verwendet diese Methode aller registrierten Suchteilnehmer, um die Liste der derzeit unterstützten Ding-Typ-UIDs zurückzugeben. getThingUID - Erstellt eine Thing-UID aus den mDNS-Dienstinformationen oder gibt null zurück, wenn dies nicht möglich ist. Diese Methode wird während der Ergebniserstellung vom Discovery-Dienst aufgerufen, um eine eindeutige Ding-UID für das Ergebnis bereitzustellen. createResult - Erstellt das DiscoveryResult aus dem mDNS-Ergebnis. Diese Methode wird vom Suchdienst aufgerufen, um das eigentliche Suchergebnis zu erstellen. Sie verwendet die getThingUID-Methode, um die Ding-UID des Ergebnisses zu erstellen.