IoT-System: Überarbeitung Datentypen

Hallo zusammen,

da ich aktuell ein wenig Zeit für mich zur Verfügung habe, ist es mir möglich mein IoT-System zu überarbeiten und auszubauen. Dafür habe ich mir überlegt, das Gesamtkonzept umzustellen, worauf ich jedoch heute noch nicht eingehen möchte. Bevor ich mit der Umstrukturierung beginnen kann, möchte ich noch ein paar Altlasten loswerden, welche ich bei der ersten Programmierung des Systems erzeugt habe. Auf eine dieser Lasten möchte ich heute eingehen.

Enumerationen

Als eines der grundlegendsten Elemente in der Programmierung des gesamten Systems existiert die Enumeration "IoTValueType". Eine Enumeration ist - einfach gesagt - ein Datentyp, welcher nur definierte Werte annehmen kann. Ein gutes Beispiel dafür ist ein Wochentag. Eine Enumeration vom Typ "Wochentag" kann logisch nur die Werte "Montag", "Dienstag", ... "Sonntag" annehmen. (mehr) Im Hintergrund kümmert sich dann der Compiler darum, dass jedem Enumerationswert ein passender Ganzzahlwert  zugeordnet wird. Diese Zuordnung kann auch per Hand durchgeführt werden.

Enumerationen können auch dafür genutzt werden, um mehrere der definierten Werte auszuwählen. Um beim gleichen Beispiel zu bleiben, könnte mit Hilfe der Enumeration "Wochentag" eine Auswahl erstellt werden, an welchen Tagen beispielsweise ein Wecker klingeln soll. Dafür muss die Enumeration mit dem "Flags-Attribut" markiert werden. Im Normalfall wird jedem Enumerationswert eine Ganzzahl zugeordnet:

(Montag = 0, Dienstag = 1, Mittwoch = 2, Donnerstag = 3, Freitag = 4, ...)

Mit dem Flags-Attribut wird jedem Wert ein Bit zugeordnet, wodurch sie praktisch Werte der Zweierpotenzreihe annehmen:

(Montag = 1, Dienstag = 2, Mittwoch = 4, Donnerstag = 8, Freitag = 16, ...)

Dadurch ist es nun möglich, Kombinationen zu bilden. Beispielsweise entspricht die Auswahl "Dienstag und Mittwoch" gleich der Zahl 6. Ohne das Flags-Attribut ergibt dieselbe Kombination die Zahl 3, welcher bereits "Donnerstag" zugeordnet ist. Es kann daher nicht unterschieden werden, ob bei einer 3 "Donnerstag" oder "Dienstag und Mittwoch" gemeint ist.

Ich habe nun bisher eine solche Enumeration verwendet, um die möglichen Datentypen im System zu definieren. Dadurch ist es nicht nur möglich gewesen, den genauen Datentyp eines Elements festzulegen, sondern mit Hilfe des Flags-Attributes auch eine Auswahl an Typen anzugeben, welche von einem Element unterstüzt werden. Dies habe ich insbesondere bei der Erstellung der Logikstrukturen verwendet, wie ich in einem früheren Post beschrieben habe.

IoTValueType-Enumeration

Die Verwendung einer Enumeration an dieser Stelle hat jedoch den Nachteil, dass die Auswahl an Datentypen auf die angegebenen Typen begrenzt ist. Eine Erweiterung ist daher nur möglich, indem neue Typen der Enumeration hinzugefügt werden. Ich habe zwar auch einen Datentyp "Objekt" hinzugefügt, welcher einen beliebigen Datentyp beschreibt, dies führt jedoch dazu, dass Elemente mit verschiedenen Objekt-Datentypen verknüpft werden können. Ein weiterer negativer Punkt ist, dass keine Arrays o.Ä. existieren. Arrays können zwar auch über den Objekt-Datentyp übergeben werden, aber das führt wieder zu dem eben genannten Verhalten.

DataType - Klasse

Um die aufgezeigten Probleme zu lösen, habe ich beschlossen die Enumeration "IoTValueType" zu ersetzen. Dafür habe ich mir zunächst überlegt, welche Arten von Datentypen es gibt und wie diese zu differenzieren sind. Grundsätzlich resultieren daraus drei Arten: Ein Grunddatentyp, welcher einfache Werte wie Ganzzahlen, Strings, etc. darstellt, ein Arraydatentyp, welcher eine Auflistung von Werten eines Datentyps darstellt und ein komplexer Datentyp, welcher eine Zusammenstellung verschiedener Datentypen darstellt. Die genannten Datentypen habe ich nun durch Klassen beschrieben, welche alle eine gemeinsame "DataType"-Basisklasse verwenden.

Datenstruktur "DataType"

Neben den im Bild dargestellten Feldern besitzt die DataType-Basisklasse noch weitere Felder und Methoden, um beispielsweise einem Datentyp Methoden zum Serialisieren und Deserialisieren zuzuordnen.

MultiDataType

Die Verwendung der genannten DataType-Klasse hat aber nun den Nachteil, dass jeweils nur exakt ein Datentyp verwendet werden kann. Daher habe ich zusätzlich eine Klasse MultiDataType angelegt, welche es ermöglicht mehrere mögliche Datentypen anzugeben.

using System;
using System.Collections.Generic;
using System.Linq;
using HomeAutomationServerExtensionInterface;
 
namespace LogicStructureEditor
{
 public class MultiDataType
 {

using System;
using System.Collections.Generic;
using System.Linq;
using HomeAutomationServerExtensionInterface;
 
namespace LogicStructureEditor
{
 public class MultiDataType
 {
  private enum WorkMode
  {
   All,
   TypesByList,
   AllExceptList,
   None
  }
  private readonly WorkMode workMode = WorkMode.All;
  private readonly List<DataType> types;
 
  private bool AcceptAll { get { return workMode == WorkMode.All; } }
  private bool AcceptNone { get { return workMode == WorkMode.None; } }
 
  public MultiDataType(IEnumerable<DataType> types)
  {
   if (types == null || !types.Any())
   {
    workMode = WorkMode.None;
   } else { 
    this.types = new List<DataType>(types);
    workMode = WorkMode.TypesByList;
   }
  }
  public MultiDataType(DataType type)
  {
   if (type == null)
   {
    workMode = WorkMode.None;
   } else
   {
    types = new List<DataType>() { type };
    workMode = WorkMode.TypesByList;
   }
  }
 
  //Private constructor for operators
  private MultiDataType(WorkMode mode, IEnumerable<DataType> types)
  {
   switch (mode)
   {
    case WorkMode.All:
     break;
    case WorkMode.None:
     break;
    case WorkMode.AllExceptList:
     if (types == null || !types.Any())
     {
      workMode = WorkMode.All;
      return;
     }
     this.types = new List<DataType>(types);
     break;
    case WorkMode.TypesByList:
     if (types == null || !types.Any())
     {
      workMode = WorkMode.None;
      return;
     }
     this.types = new List<DataType>(types);
     break;
   }
   workMode = mode;
  }
  static MultiDataType()
  {
   AllTypes = new MultiDataType(WorkMode.All, null);
   None = new MultiDataType(WorkMode.None, null);
  }
  public static readonly MultiDataType AllTypes = null;
  public static readonly MultiDataType None = null;
 
  public DataType GetSingleDataType()
  {
   if(workMode == WorkMode.All)
   {
    throw new Exception("Unable to get DataType from MultiDataType with all elements.");
   }
   if (workMode == WorkMode.None)
   {
    throw new Exception("Unable to get DataType from MultiDataType with zero elements.");
   }
   if(workMode == WorkMode.AllExceptList)
   {
    throw new Exception("Unable to get DataType from MultiDataType with more than one element.");
   }
   if (types.Count == 0)
   {
    throw new Exception("Unable to get DataType from MultiDataType with zero elements.");
   }
   if (types.Count != 1)
   {
    throw new Exception("Unable to get DataType from MultiDataType with more than one element.");
   }
   return types[0];
  }
 
  public bool Any()
  {
   switch (workMode)
   {
    case WorkMode.None:
     return false;
    case WorkMode.All:
     return true;
    case WorkMode.TypesByList:
     return true;
    case WorkMode.AllExceptList:
     return true;
   }
   throw new Exception("Invalid WorkMode: " + workMode.ToString());
  }
  public bool SingleType()
  {
   switch (workMode)
   {
    case WorkMode.None:
     return false;
    case WorkMode.All:
     return false;
    case WorkMode.TypesByList:
     return types.Count == 1;
    case WorkMode.AllExceptList:
     return false;
   }
   throw new Exception("Invalid WorkMode: " + workMode.ToString());
  }
 
  public override int GetHashCode()
  {
   if(workMode == WorkMode.All)
   {
    return 12345678;
   }
   if(workMode == WorkMode.None)
   {
    return 87654321;
   }
   int hash;
   if (workMode == WorkMode.AllExceptList)
   {
    hash = 19 + types.Count;
   } else
   {
    hash = 29 + types.Count;
   }
   foreach (DataType t in types)
   {
    hash = hash * 31 + t.GetHashCode();
   }
   return hash;
  }
  public override bool Equals(object obj)
  {
   if (obj.GetType() != typeof(MultiDataType)) { return false; }
   return this == (MultiDataType)obj;
  }
 
  public static bool operator ==(MultiDataType obj1, MultiDataType obj2)
  {
   //Check if both use the same workmode. Otherwise they are different.
   if (obj1.workMode != obj2.workMode) { return false; }
   //If one (=both) accepts all or none elements, they are equal.
   if (obj1.AcceptAll || obj1.AcceptNone) { return true; }
   //The are on the same workmode. Their typelist should contain the same values.
   if (obj1.types.Count != obj2.types.Count) { return false; }
   return obj1.types.Except(obj2.types).Any() == false;
  }
  public static bool operator !=(MultiDataType obj1, MultiDataType obj2)
  {
   //Check if both use the same workmode. Otherwise they are different.
   if (obj1.workMode != obj2.workMode) { return true; }
   //If one (=both) accepts all or none elements, they are equal.
   if (obj1.AcceptAll || obj2.AcceptNone) { return false; }
   //The are on the same workmode. Their typelist should contain the same values.
   if (obj1.types.Count != obj2.types.Count) { return true; }
   return obj1.types.Except(obj2.types).Any();
  }
 
  public static bool operator ==(MultiDataType obj1, DataType obj2)
  {
   if(obj1.workMode != WorkMode.TypesByList) { return false; }
   if (obj1.types.Count != 1) { return false; }
   return obj1.types[0] == obj2;
  }
  public static bool operator !=(MultiDataType obj1, DataType obj2)
  {
   if (obj1.workMode != WorkMode.TypesByList) { return true; }
   if (obj1.types.Count != 1) { return true; }
   return obj1.types[0] != obj2;
  }
 
  public static MultiDataType operator &(MultiDataType obj1, MultiDataType obj2)
  {
   //If one of them accepts all, the second one is the restriction
   if (obj1.AcceptAll) { return obj2; }
   if (obj2.AcceptAll) { return obj1; }
   //If one of them accepts none, then it is the restriction
   if (obj1.AcceptNone) { return obj1; }
   if (obj2.AcceptNone) { return obj2; }
   //Check if their modes are equal
   if (obj1.workMode == obj2.workMode)
   {
    if (obj1.workMode == WorkMode.TypesByList)
    {
     //Both are working normal. Return the ones, which are in both lists
     return new MultiDataType(WorkMode.TypesByList, obj1.types.Where(X => obj2.types.Contains(X)));
    } else
    {
     //Both are working in Except-Mode. Return the ones, which are in none of both lists
     return new MultiDataType(WorkMode.AllExceptList, obj1.types.Union(obj2.types));
    }
   } else
   {
    //The elements ere different.
    if (obj1.workMode == WorkMode.TypesByList)
    {
     //Obj1 is working normal and obj2 is working in Except-mode. Return the ones, which are in the first one, but not in the second one.
     return new MultiDataType(WorkMode.TypesByList, obj1.types.Where(X => (obj2.types.Contains(X) == false)));
    } else
    {
     //Obj1 is working in Except-mode and obj2 is working normal. Return the ones, which are not in the first one, but in the second one.
     return new MultiDataType(WorkMode.TypesByList, obj2.types.Where(X => (obj1.types.Contains(X) == false)));
    }
   }
  }
  public static MultiDataType operator |(MultiDataType obj1, MultiDataType obj2)
  {
   //If one of them accepts all, the result will accept all
   if (obj1.AcceptAll) { return obj1; }
   if (obj2.AcceptAll) { return obj2; }
   //if one of them accepts none, then the result will be the other object
   if (obj1.AcceptNone) { return obj2; }
   if (obj2.AcceptNone) { return obj1; }
   //Check if their modes are equal
   if (obj1.workMode == obj2.workMode)
   {
    if (obj1.workMode == WorkMode.TypesByList)
    {
     //Both are working normal. Return the elements from both lists.
     return new MultiDataType(obj1.types.Union(obj2.types));
    } else
    {
     //Both are working in Except-Mode.
     return new MultiDataType(WorkMode.AllExceptList, obj1.types.Where(X => obj2.types.Contains(X)));
    }
   } else
   {
    if (obj1.workMode == WorkMode.TypesByList)
    {
     //Obj1 is working normal and obj2 is working in Except-mode.
     return new MultiDataType(WorkMode.AllExceptList, obj2.types.Where(X => (obj1.types.Contains(X) == false)));
    } else
    {
     return new MultiDataType(WorkMode.AllExceptList, obj1.types.Where(X => (obj2.types.Contains(X) == false)));
    }
   }
   
  }
  public static MultiDataType operator &(MultiDataType obj1, DataType obj2)
  {
   switch (obj1.workMode)
   {
    case WorkMode.All:
     return new MultiDataType(obj2);
    case WorkMode.None:
     return None;
    case WorkMode.TypesByList:
     if (obj1.types.Contains(obj2))
     {
      return new MultiDataType(obj2);
     } else
     {
      return None;
     }
    case WorkMode.AllExceptList:
     if (obj1.types.Contains(obj2))
     {
      return obj1;
     } else
     {
      List<DataType> types = new List<DataType>(obj1.types);
      types.Add(obj2);
      return new MultiDataType(WorkMode.AllExceptList, types);
     }
   }
   throw new Exception("Invalid WorkMode: " + obj1.workMode.ToString());
  }
  public static MultiDataType operator |(MultiDataType obj1, DataType obj2)
  {
   switch (obj1.workMode)
   {
    case WorkMode.All:
     return AllTypes;
    case WorkMode.None:
     return new MultiDataType(obj2);
    case WorkMode.TypesByList:
     List<DataType> types = new List<DataType>(obj1.types);
     types.Add(obj2);
     return new MultiDataType(WorkMode.TypesByList, types);
    case WorkMode.AllExceptList:
     return new MultiDataType(obj1.types.Where(X => X != obj2));
   }
   throw new Exception("Invalid WorkMode: " + obj1.workMode.ToString());
  }
  
  public static MultiDataType operator ~(MultiDataType obj)
  {
   switch (obj.workMode)
   {
    case WorkMode.All:
     return None;
    case WorkMode.None:
     return AllTypes;
    case WorkMode.TypesByList:
     return new MultiDataType(WorkMode.AllExceptList, obj.types);
    case WorkMode.AllExceptList:
     return new MultiDataType(WorkMode.TypesByList, obj.types);
   }
   throw new Exception("Invalid WorkMode: " + obj.workMode.ToString());
  }
 
 }
}

Das Prinzip des MultiDataType besteht darin, dass es zunächst vier Zustände besitzt. Diese sind "Alle", "Keine", "Alle außer" und "Keine außer". Bei der Nutzung einer der letzten beiden Zustände wird außerdem eine Liste verwendet, welche die Datentypen enthält, welche zulässig oder eben nicht zulässig sind.

Zudem definiert die Klasse Operatoren zum Vergleich und die Bitoperatoren OR, AND und die Bitweise-Negation. Diese werden verwendet, um das Verhalten der Enumeration des alten IoTValueType weiterverwenden zu können. Dadurch kann ein Großteil des geschriebenen Quellcodes weiterverwendet werden. Trotzdem war es nötig, große Teile des Quellcodes zu überarbeiten. Die Überarbeitung ist aber nun abgeschlossen und mein System läuft mit der überarbeiteten Variante.

Im nächsten Schritt werde ich die Anfangs erwähnte Umstrukturierung des Systems angehen. Dazu werde ich mich hier äußern, wenn ich dies abgeschlossen habe.

Bis dahin,
Markus

IoT-System: Update Geräteprotokoll

Hallo zusammen,

heute möchte Ich näher auf das Verbindungsprotokoll eingehen, welches von meinem IoT-System zur Kommunikation zwischen dem Server und den Geräten verwendet wird. Der Grund dafür ist, dass ich dieses System in den letzten Wochen überarbeitet habe.

Bisheriger Zustand

Zunächst möchte ich darauf eingehen, wie das Protokoll bisher funktioniert hat.

Sogut wie alle meiner bisher eingebundenen Geräte sind über WLAN mit dem Server verbunden. Dieser ist über LAN mit einem Router gekoppelt, welcher das WLAN zur Verfügung stellt. Da den Geräten anfangs die Zugangsdaten zum WLAN nicht bekannt sind, spannen sie zunächst einen eigenen AccessPoint (AP) auf. Zu diesem muss sich nun mit einem Rechner, Tablet, etc. verbunden werden. Die Geräte stellen anschließend eine HTML-Seite zur Verfügung, über welche die Netzwerk-Verbindungsdaten eingegeben werden können. Dafür nutze ich den ein Modul namens WiFiManager, welches über GitHub zur Verfügung steht.

Ist die WLAN-Verbindung erfolgreich, so wird eine TCP-Verbindung zu einer fest eingetragenen Server-IP + Port aufgebaut. Dies ist auch der erste Hauptgrund, warum ich das System überarbeiten wollte. Ändert sich die IP oder der Port des Servers, so musste auf alle Geräte eine neue Software aufgespielt werden. Auch wenn dies per OTA-Update möglich ist, stellt es doch einen nicht geringen Aufwand dar.

Nachrichtenformat

Nach erfolgreichem Aufbau der TCP-Verbindung beginnt die eigentliche Kommunikation. Da TCP-Verbindungen lediglich aus einem Bytestrom ohne definiertes Datenformat bestehen, werden zunächst vier Bytes geschicht, welche eine 32-Bit Integerzahl darstellen. Diese teilen den Bytestrom in definierte Nachrichten auf.

Die Nachrichten bestehen nun aus 4 Byte SenderID, 4 Byte ZielID, 4 Byte BefehlsID und optionalen, befehlsabhängigen Daten. Deren Länge ergibt sich aus der Nachrichtenlänge minus den 12 Bytes an eben genannten Daten.

Datenformat altes Geräteprotokoll

Bevor ich nun das eigentliche Protokoll beschreiben kann, muss ich kurz auf die Verbindungsstruktur der Geräte eingehen. Auch wenn es sich aktuell um eins-zu-eins-Verbindungen zwischen Server und Geräten handelt, ist es vorgesehen, dass Geräte auch Sub-Geräte anbinden können. Beispielsweise könnte so ein Gerät als Bridge zwischen LAN/WLAN und einem anderen Bus-System, beispielsweise SPI, fungieren.

Parent Discovery

Da der Server später zur Übertragung von Nachrichten wissen muss, an welches Gerät er die Nachricht schicken muss, ist es notwendig, dass die Geräte bei der späteren Anmeldung ihr übergeordnetes Gerät (Parent-Device) mitteilen. Dafür ist es wiederum notwendig, dass sie wissen, welches Gerät ihr Parent-Device ist. Daher senden sie als erstes eine Nachricht mit dem Befehl "GetParent" an ihr ParentDevice. Da sie hier noch nicht wissen, welche ZielID sie dafür verwenden müssen, nutzen sie die dafür reservierte ID -2. Das übergeordnete Gerät antwortet nun mit einer Nachricht "SetParent", wobei im SenderID-Feld nun die ID des Geräts enthalten ist. Ist das Gerät direkt mit dem Server verbunden, so ändert dies nichts an der Vorgehensweise. Das SenderID-Feld der "SetParent"-Nachricht enthält dann die ID 0, welches die eindeutige ID des Servers darstellt.

Nachrichten GetParent/SetParent

Device Registration

Nun kann sich das Gerät am Server anmelden. Dafür gibt es zwei Varianten. Welche Variante genutzt wird, hängt davon ab, ob das Gerät bereits einmal mit dem Server verbunden war oder nicht. Sollte es noch nicht verbunden gewesen sein, so besitzt es noch keine eindeutige DeviceID. In diesem Fall wird zunächst eine DefaultDeviceID verwendet, für welche die ID -1 reserviert ist. Auch für die eben beschriebene Anforderung der ParentID wird dann diese ID verwendet. Das Gerät fragt nun eine Registrierung als neues Gerät an, wobei die ParentID im Feld für optionale Daten angehängt ist. Der Server antwortet darauf mit einer neuen, eindeutigen DeviceID.

Nachrichten RegisterNew / AcceptNew

Erhält das Gerät die Nachricht AcceptNew, so beginnt es, die einzelnen Ein- und Ausgänge (IOs) anzumelden. Darauf möchte ich an dieser Stelle jedoch nicht eingehen, da es sich bei der Überarbeitung nicht geändert hat und da es den Rahmen hier sprengen würde.

Sollte das Gerät zuvor schon einmal verbunden gewesen sein, so besitzt es bereits eine DeviceID. Diese wird in einem lokalen Festspeicher (EEPROM, SPIFFS, etc.) gespeichert. Stellt das Gerät beim Start fest, dass es bereits eine DeviceID besitzt, so lädt es diese. Das Gerät geht nun davon aus, dass es sich bei dem Server schon einmal angemeldet hat und ihm dabei diese ID zugeteilt wurde. Dies ist ein weiterer Grund, warum ich das Protokoll überarbeiten wollte, aber dazu später mehr.

Für die Anmeldung am Server verwendet das Gerät nun seine eigene DeviceID und registriert sich auch nicht als neues, sondern als bekanntest Gerät. Nach der Annahme der Registrierung durch den Server ist es nun nichtmehr notwendig, die IOs anzumelden, da diese dem Server bereits bekannt sein sollten.

Nachrichten RegisterKnown / AcceptKnown

Zusammenfassung altes Protokoll

Ich möchte nun noch einmal die Punkte auflisten, welche mich an dem bisherigen Protokoll gestört haben, bzw. welche zu Problemen führen könnten und zum Teil auch geführt haben.

1. Die IP und der Port des Serves sind fest eingetragen.
2. Bei der Anfrage als neues Gerät wird eine nicht-eindeutige DeviceID verwendet. Dies könnte bei gleichzeitiger Anmeldung von mehreren Geräten dazu führen, dass die AcceptNew-Nachricht dem falschen Gerät zugestellt wird, welchem dadurch Serverseitig die falsche ParentID zugeordnet sein könnte.
3. Eine Anmeldung eines Geräts an verschiedenen Servern ist nicht möglich. Da der Server den Geräten die DeviceID zuteilt, sind diese nur für diesen Server gültig. Versucht sich das Gerät nun an einem alternativen Server anzumelden, so kennt dieser das Gerät entweder nicht, oder kennt unter der DeviceID bereits ein anderes Gerät. Beides führt zu Problemen. Kenn der Server das Gerät nicht, so muss er es ablehnen. Das Gerät muss darauf reagieren. In diesem Fall hat es bisher seine DeviceID gelöscht und sich neu angemeldet. Sollte es sich später erneut beim Original-Server anmelden, so beginnt das Problem von vorn. Kennt der Alternativserver unter der DeviceID bereits ein Gerät, so besitzen zwei Geräte die gleiche ID, was zwangsweise zu Problemen führt.
4. Nur das Gerät ist in der Lage, seine IOs anzumelden. Dies geschieht nur bei einer Registrierung als neues Gerät. Wird das Gerät baulich verändert, so muss es komplett neu registriert werden.

Gesamtübersicht altes Protokoll

Neues Protokoll

Um die genannten Probleme zu lösen, habe ich das System in zwei Schritten verändert.

Server Discovery

Zunächst habe ich die festeingetragenen Serverdaten entfernt. Der Server teilt nun seine möglichen Verbindungen über einen UDP-Multicast mit. Dafür sendet er eine Nachricht mit den möglichen Protokollen an eine UDP-Multicast-Adresse. Die Geräte lauschen auf dieser Adresse und erhalten alle dahin geschickten Nachrichten.

Neben den Protokoll-Informationen enthält die Nachricht natürlich auch die IP des Servers und zusätzlich noch zwei Bytes an Flags. Aktuell werden nur zwei Bits verwendet. Ein Bit gibt an, ob es sich um ein Standard oder ein Backup-Server handelt. Die Geräte bevorzugen dabei Standard-Server. Ist kein Standart-Server vorhanden, so nutzen sie, falls vorhanden, auch Backup-Server. Das zweite Bit gibt an, ob es sich um einen Entwicklungs-Server handelt. Diese Server werden nur verwendet, wenn auch die Geräte im Entwicklungsmodus betrieben werden, anderenfalls werden die ignoriert. Die weiteren 14 Bits werden aktuell nicht verwendet.

Protokoll-Veränderungen

Zunächst hat sich das Datenformat der Nachrichten geändert. Dies ist darin begründet, dass als DeviceID nun keine fortlaufende 32-Bit-Integerzahl mehr verwendet wird, sondern eine GUID. Diese umfasst 16 Bytes, also 128 Bit, und wird zufällig generiert.

Datenformat neues Geräteprotokoll

Diese Änderung liegt darin begründet, dass die Vergabe einer DeviceGUID nun unabhängig von der Registrierung als Gerät stattfindet. Stellt eine Gerät beim Start fest, dass es noch keine GUID besitzt, so fordert es nun nach erfolgreichem Verbindungsaufbau als erstes eine GUID von seinem ParentDevice an. Sollte das ParentDevice nicht der Server sein, so fordert es wiederum eine GUID von seinem ParentDevice an. Die ParentDevices müssen sich nur merken, welches ChildDevice als letztes nach einer GUID gefragt haben und nach Erhalt der GUID diese an das ChildDevice weiterleiten. Dies löst auch das Problem der gleichzeitigen Anmeldung mehrerer Geräte. In diesem Fall erhält das Gerät, welches zuletzt angefragt hat die neue GUID. Das erste Gerät erhält daher keine Antwort auf seine GUID-Anfrage. Mit Hilfe eines TimeOuts stellt das übergangene Gerät später die Anfrage erneut.

Nachrichten RequestGUID / SendGUID

Im Anschluss an die GUID-Anfrage, beziehungsweise wenn das Gerät bereits eine GUID besitzt, folgt die Anfrage des ParentDevice. Im Vergleich zum bisherigen Protokoll hat sich lediglich geändert, dass das Gerät nun bereits eine GUID besitzt.

Nachrichten Get/Set Parent

Der Vorteil der vorgestellten GUID-Anfrage zeigt sich nun in der Anmeldung beim Server. Hier entscheidet nun nicht mehr das Gerät, ob es sich als neues oder bekanntes Gerät anmeldet, sondern der Server. Kennt dieser die DeviceGUID bereits, so akzeptiert er die Registrierung. Kennt er die DeviceGUID noch nicht, so fragt er zunächst die IOs des Gerätes an. Im Anschluss an die IO-Registrierung akzeptiert er dann die Registrierung

Nachrichten RegisterDevice / AcceptDevice

Sollte sich die Gerätekonfiguration später einmal ändern, so ist es jederzeit möglich über das Server-Interface eine neue Abfrage der Geräte-IOs zu starten.

Ich möchte nun noch einmal darauf zurückkommen, warum es nötig war, die DeviceID von Int32 auf GUID umzustellen. Da die Vergabe von IDs durch verschiedene Server durchgeführt werden könnte, müssen die IDs zufällig generiert werden. Bei den bisherigen fortlaufenden Zahlen würde es zwangsweise zu Überschneidungen kommen. Auch wenn die Anzahl an Möglichkeiten bei 32 Bit schon 2^32 ~ 4.3 Milliarden beträgt,  besteht doch die Möglichkeit, dass IDs zufällig mehrfach belegt werden. Bei der Verwendung einer GUID gibt es 2^128 ~ 3.4*10^38 Möglichkeiten. Dies schließt eine Mehrfachbelegung selbst bei hunderten Geräten innerhalb eines Systems nahezu aus.

Ein weiterer Grund der Umstellung liegt darin, dass GUIDs überall im gesamten restlichen System verwendet werden. Da ich für die Erweiterung des Systems plane, dass beliebigen Objekten (Geräte, Logikstrukturen, Logikinstanzen,...) beliebige Daten angehängt werden können, ist es sinnvoll, wenn alle Objekte eine einheitliche Referenzierung ermöglichen. Die Verwendung von GUIDs liegt hier nah.

Gesamtübersicht neues Protokoll

Portierung

Die Portierung des Systems vom alten auf das neue Protokoll musste sowohl Serverseitig, als auch Geräteseitig durchgeführt werden. Da ich nicht verhindern wollte, alle Geräte wieder neu anlernen und verknüpfen zu müssen, habe ich auf beiden Seiten Update-Routinen erstellt. Diese updaten die Daten der Systeme auf die neuen Versionen. Im Zuge dessen habe ich in allen Systemen eine Angabe einer Dateiversion hinzugefügt. Dies wird es erleichtern, bei späteren Updates herauszufinden, ob die Daten bereits geupdated wurden, oder nicht. In den aktuellen Update-Routinen musste ich dies über Umwege feststellen.

Leider ist mir beim Überarbeiten der Quellcodes auf Geräteseite ein Fehler unterlaufen, sodass ich das OTA-Update außer Kraft gesetzt habe. Daher musste ich nach Behebung des Fehlers alle bereits geupdateten Geräte vom Netz trennen, öffnen und per Hand updaten. Da dies ein vergleichsweise hoher Aufwand ist, kann ich daher anderen nur empfehlen und werde mich hoffentlich in Zukunft auch daran halten, bei neuen Updates das OTA-Update zu testen, bevor das Update groß verteils wird.

Damit bin ich für heute am Ende angelangt und bedanke mich für das Lesen!

Sonoff T1 und 4CH-R2

Hallo,

Heute möchte ich zu einem Blogeintrag kommen, welchen ich schon einige Zeit vor mir her schiebe. Bereits Mitte März diesen Jahres erreichte mich ein Päckchen aus China, welches die beiden Geräte enthielt, die ich heute vorstellen möchte.

Sonoff T1 (2CH)

Bei der Sonoff T1 Reihe handelt es sich um WLAN-Lichtschalter, welche in Ausführungen mit 1-3 Kanälen angeboten werden. Leider existiert die 3-Kanal-Ausführung nur in der deutlich größeren US-Version und der etwas größeren UK-Version, sodass in der EU-Version nur die Ausführungen mit ein und zwei Kanälen angeboten werden. Ich habe mir testweise zunächst eine 2-Kanal-Version bestellt. Diese kostet direkt beim Hersteller aktuell 17,12€, die 1-Kanal-Version ist für 15,92€ zu haben.

Das Gerät wird in einer handlichen Verpackung geliefert, welche nicht viel größer ist als das Gerät selbst.

Verpackung Sonoff T1 2CH (EU)

Wie auf der Packung lesbar ist, unterstützt das Gerät nicht nur WLAN ("WiFi"), sondern auch RF ("Radio Frequency"). Dies bedeutet, dass das Gerät auch über Funkschalter angesprochen werden kann. Diese werden einzeln von ITEAD verkauft und orientieren sich im Erscheinungsbild am T1, weichen jedoch leicht von diesem ab.

In der Verpackung befinden sich neben dem gut verpackten Sonoff-T1 eine englisch/chinesische Anleitung und eine Garantiekarte. Zum Einbau muss die Glasfrontplatte des T1 abgenommen werden. Darunter befindet sich eine Platine, welche den ESP8266 sowie die Touch-Sensoren enthält. Zudem befinder sich hier auch die serielle Schnittstelle (auf dem Bild rechts auf der Platine), welche zum flashen des ESP benötigt wird. Auf der Platine ist gut erkennbar, dass diese für einen weiteren Touchsensor vorbereitet ist und somit auch für die Einkanal-Version verwendet wird und theoretisch auch für 3 Kanäle verwendet werden könnte. Die Platine ist zudem mit 4 Löchern versehen, welche auch im hinteren Gehäuse enthalten sind. Durch diese wird der T1 an den Wandlöchern befestigt.

Sonoff T1 mit abgenommener Frontplatte

Da die Platine nur aufgesteckt ist, lässt sie sich einfach entnehmen. Dabei wird eine zweite Platine freigelegt. Diese enthält das Netzteil, zwei Relais und einen Pieper. Beim Blick auf die Rückseite (leider ohne Bild) zeigt sich, warum die EU-Version nur mit maximal zwei Kanälen angeboten wird. Dies ist darin begründet, dass einfach kein Platz für ein drittes Relais vorhanden ist.

Sonoff T1 mit beiden Platinen

Auf der Rückseite des Gehäuses befinden sich Schraubanschlüsse zum Anschluss des Gerätes. Der Neutralleiter ist seitlich etwas abgesetzt zu den anderen Anschlüssen, sodass Kurschlüsse effektiv vermieden werden. Das eigentliche Schraubterminal enthält einen Eingang für den Leiter, welcher sowohl Stromversorgung des T1 dient. Gleichzeitig steht die Leiterspannung an den Ausgängen L1 und L2 geschaltet zur Verfügung.

Rückseite des Sonoff-T1

Um den Sonoff-T1 testen zu können, habe ich ihn in eine Aufputz-Wandbox eingebaut. Bevor ich zu den Details komme, muss ich darauf hinweisen, dass es sich hier um 230V-Netzspannung handelt und bei unfachgemäßer Handhabung Lebensgefahr besteht! Aktuell nutze ich nur einen Ausgang des T1, sodass eine Zuleitung und nur eine Ausgangsleitung nutwendig ist.Während die Leiter-Anschlüsse an L und L1 angeschlossen werden, habe ich die Neutralleiter über eine Wago-Klemme verbunden und eine kurze Abzweigung als Verbindung zum T1 hergestellt.

Anschluss Sonoff-T1 bei Nutzung von einem Kanal

Der T1 lässt sich schließlich über zwei oder vier Schrauben am Gehäuse befestigen. Letztendlich muss die Frontplatte aufgeklickt werden.

Fertig angeschlossener Sonoff-T1 ohne Frontplatte

Fertiger eingebauter Sonoff-T1

Leider hat der T1 für Deutschland ungünstige Abmessungen von 85mm * 85mm, sodass er zu breit für Doppelsteckdosen bzw. -schalter ist. Eine Version mit 71mm Größe wäre hier wünschenswert.

Etwas enttäuscht bin ich auch vom Auslöseverhalten der Touch-Sensoren. Diese sind zwar optisch markiert und leuchten auch im Dunkeln, sie müssen jedoch sehr genau getroffen werden um auszulösen. Ein Wischen über den Sensor löst leider kein Signal aus. Berühert man direkt die Sensorflächen auf der Platine hinter der Frontplatte, so lösen diese deutlich besser aus. Das Problem scheint demzufolge an der Glasplatte zu liegen. Zur Verbesserung des Verhaltens habe ich hinter die obere Platine Unterlegscheiben platziert, sodass diese besser an die Frontplatte gedrückt wird. Dies verbessert das Verhalten zwar, ist jedoch immernoch Verbesserungsfähig.

Die Beleuchtung der Sensoren hängt im übrigen direkt an den Relais des T1. Sind die Relais ausgeschaltet, so sind die Kreise etwas beleuchtet, sind die Relais eingeschaltet, so leuchten die Kreise deutlich. Leider können somit die Sensoren nicht unabhängig von den Relais verwendet werden. Auch eine Einstellung der Helligkeit ist leider nicht möglich.

Immerhin lässt sich das blaue WLAN-Symbol beliebig verwenden. Hinter diesem befindet sich eine blaue LED, welche über den Port 13 des ESP8266 steuerbar ist.

Eine Funktion, welche ich nicht testen konnte ist die RF-Steuerung. Dafür befindet sich ein weiterer Chip auf der Frontplatine. Dieser scheint die Funksignale entgegenzunehmen und die Relais entsprechend zu schalten. Unklar ist mir jedoch, wie der ESP8266 dies mitbekommen soll. Die Funktion des RF-Chips scheint jedoch auch nach Neuprogrammierung des ESP noch zu funktionieren, sodass keine Kommunikation der beiden Chips stattzufinden scheint. Es scheint jedoch die Möglichkeit zu geben, auch den RF-Chip umprogrammieren zu können, da auch für diesen vier Pins zur Verfügung stehen.

Die Neuprogrammierung des ESP8266 funktioniert im übrigen analog zum Standart-Sonoff. Zum Flashen muss der ESP in den Flash-Modus versetzt werden. Dazu muss der linke Touchsensor (Port 0) während des Startens gedrückt gehalten werden. Um einen Neustart auszulösen befindet sich auf der Platine ein Reset-Taster. Der rechte Sensor ist mit Port 9 verbunden. Die Relais sind an Port 12 und Port 5 angeschlossen. Leider scheint der Pieper der zweiten Platine nicht vom ESP8266, sondern nur vom RF-Chip ansteuerbar zu sein. Dies wäre beispielsweise für Alarme nützlich.

Zum erstmaligen Flashen sollte die Frontplatine entnommen werden. Dies stellt sicher, dass keine Netzspannung anliegt. Gleichzeitig wird das System so von den Relais getrennt, sodass selbst der geringe Strom des Programmers zur Versorgung ausreicht. Auf die Dauer sollte die verwendete Software bestenfalls eine OTA-Flash-Möglichkeit vorsehen, um das Gerät nicht ständig öffnen zu müssen.

Mittlerweile hat ITEAD auch eine 3-Kanal-Version angekündigt. Diese wird sich jedoch möglicherweise im Design von den bisherigen Varianten unterscheiden. Bei einem Besuch eines YouTubers bei Sonoff in Shenzen durfte sich dieser die neue Version bereits einmal anschauen. Anscheinend werden auch die 1- und 2-Kanal-Versionen überarbeitet. Über die neue Farbgebung lässt sich natürlich streiten, möglicherweise wird dies jedoch auch noch einmal verändert. Ein wichtiger Punkt dürfte sein, dass die neuen Modelle nun keine Glasplatten mehr enthalten. Es handelt sich nun also vermutlich um Plastik, wodurch sich das Touch-Verhalten verändern dürfte.

Sonoff 4CH R2

Beim Sonoff 4CH R2 handelt es sich die zweite Revision eines 4-Kanal-WLAN-Schalters. Im Vergleich zur ersten Revision hat sich das Gehäuse verändert. Ob es auch technische Änderungen gibt, kann ich nicht feststellen, da ich nur die zweite Revision zur Verfügung habe. Das Gerät sollte zudem vom Sonoff 4CH Pro (R2) unterschieden werden. Auf die Unterschiede werde ich später eingehen.

Das Gerät ist bei mir analog zum T1 in einer passgenauen Verpackung angekommen. Diese enthält neben dem Gerät wieder eine Kurzanleitung und eine Garantiekarte.

Sonoff 4CH R2 mit Verpackung

Auf der Oberseite des Gerätes befinden sich zunächst vier Knöpfe und fünf Anzeigen. Vier der Knöpfe und Anzeigen dienen jeweils zur Statusanzeige und -änderung der vier Kanäle. Die verbleibende LED dient dagegen zur Anzeige des WLAN-Status.

An der unteren langen Seite des Gerätes befindet sich eine Klappe, welche die Anschlussleisten der Gerätes verdeckt. Die erste Revision des Gerätes hatte diese Klappe nicht, entsprechend lagen die Anschlüsse dauerhaft frei. Diese Verbesserung erhöht die Sicherheit des Gerätes, indem sie es erschwert, ungewollt an die Anschlüsse und damit mit Netzspannung in Berührung zu kommen.

Für den Anschluss stehen drei Steckleisten zur Verfügung. Die graue Leiste ist für den Neutralleiter vorgesehen. Die Buchsen sind intern alle zusammengeschaltet, sodass es beim Anschluss irrelevant ist, welche der Buchsen für welchen Neutralleiter verwendet wird. Anders sieht das bei der orangen Leiste aus. Diese enthält die Buchsen für die spannungsführenden Leiter. Hier muss die Buchse ganz links zur Spannungsversorgung für das Gerät und für die Ausgänge genutzt werden. Die vier verbleibenden Buchsen sind über Relais einzeln geschaltet und dienen entsprechend als Ausgang. Die grüne Leiste dient zuletzt für die Erdung. Auch diese Buchsen sind zusammengeschaltet, sodass es keinen Unterschied macht, welches Kabel an welche Buchse angeschlossen wird. Gleichzeitig dient dieses Terminal zur Erdung der Platine. Im letzten Bild unten ist erkennbar, dass vom geerdeten Bereich eine Leitung zum Kleinspannungsbereich der Platine geführt wird.

Die Anschlussleisten sind auch schon der erste Punkt, welcher das Gerät von der Pro-Version unterscheidet. Diese enthält neben einer 2-poligen Stromversorungsleiste vier 3-polige Leisten, welche die Anschlüsse der Wechsler-Relais rausführen. Zudem enthält die Pro-Version zusätzlich eine Hohlstecker-Buchse zur direkten Versorgung mit 24V. Dadurch muss das Gerät nicht zwangsweise an Netzspannung betrieben werden.
 

Anschlussleisten Sonoff 4CH R2

Auf der Rückseite des Gehäuses befindet sich eine Befestigungsmöglichkeit für DIN-Schienen. Das Gerät kann daher einfach in eine Schiene eingehangen und über die blauen Schieber festgestellt werden. Alternativ existieren am Gerät vier Löcher (ganz außen), über welche das Gerät festgeschraubt werden kann. Die vier innenliegenden Löcher enthalten Schrauben, welche die beiden Gehäuseteile zusammenhalten.

DIN-Schienenaufnahme Sonoff 4CH R2

Entfernt man die Schrauben und öffnet das Gehäuse, so kommt die Platine zum Vorschein. Es ist gut erkennbar, dass Netzspannungsbereich (unten/links) und Kleinspannungsbereich (rechts/oben) durch einen Schlitz in der Platine getrennt sind. Zudem sieht man rechts neben den Anschlussleisten, dass eine Hohlstecker-Buchse vorgesehen ist. Warum diese letztendlich weggelassen wurde, lässt sich nur spekulieren. Da für die Pro-Version eine andere (komplexere) Platine verwendet wird, kann es auch kein Überbleibsel aus dieser Variante sein.

Oberhalb der Relais befindet sich der ESP8266 inklusive der Pinleiste der seriellen Schnittstelle. Links befinden sich die mit zum Gehäuse passenden Kappen abgedeckten Taster. Gegenüber sind die fünf Leuchtdioden platziert. Die vier oberen LEDs sind fest mit den Relais verbunden und geben deren Status an. Die letzte LED signalisiert den WLAN-Status. Glücklicherweise sind alle Komponenten mit den Anschlusspins des ESP beschriftet, sodass sich die Programmierung relativ einfach gestaltet.

Die Portnummern die Taster lauten 0, 9, 10 & 14. Die Portnummern der Relais/LEDs lauten 12, 5, 4 & 15. Die Status-LED ist analog zu allen bisher von mir verwendeten Sonoffs an Port 13 angeschlossen.

Platine des Sonoff 4CH R2

Auf der Rückseite der Platine befinden sich hauptsächlich die Verstärkungen der Neutral- und spannungsführenden Leiter. Gleichzeitig sind die großen (geerdeten) Massebereiche im Kleinspannungsbereich sichtbar.

Einzelteile Sonoff 4CH R2

Leider habe ich bei mir noch keinen Einsatzort für das Gerät gefunden, sodass ich noch keine Verkabelung vorgenommen habe. Da jedoch hier ein Erdleiter vorhanden ist, sollten hier zwingend Schuko-Stecker verwendet werden. Sollte ich einen Einsatzort für das Gerät finden, so werde ich es hier mitteilen und darüber berichten.

IoT-Server: Umstellung Softwarestruktur & Plugins

Hallo,

In den letzten Wochen habe ich die Softwarestruktur meines IoT-Servers grundlegend überarbeitet.

Dieser lief und läuft auch weiterhin auf einem RaspberryPi 3B. Als Betriebssystem verwende ich WindowsIoT. Diese Wahl habe ich getroffen, um den Server in C# programmieren zu können. Bisher war dies allerdings nur über sogenannte "Background Tasks" möglich. Diese sind praktisch im Webinterface zu verwalten und können Remote per VisualStudio debuggt werden. Allerdings haben sie den Nachteil, dass sie wie Windows-Store-Apps gewissen Einschränkungen unterliegen.

Dazu gehört, dass sie nicht auf beliebige Dateien im Dateisystem zugreifen können, sondern nur Zugriff auf einen zur App gehörenden Ordner haben. Eine weitere Einschränkung ist, dass Code nicht dynamisch nachgeladen werden kann. Während das am Anfang nicht unbedingt ein Problem darstellte, hat das Projekt mittlerweile eine gewisse Größe erreicht. Dadurch nimmt die Übertragung des Projekts auf den Raspberry beim Debuggen viel Zeit in Anspruch. Daher wollte ich eine Aufspaltung des Projektes in den "Core-Server" und Plugins durchführen. Praktisch kann man diese Unterteilung in verschiedene Assemblys auch mit Background-Tasks durchführen, jedoch müssen alle verwendeten Assemblys in der gleichen Projektmappe liegen.

.NET Core Anwendung

Als ich mit der Programmierung des Servers 2016 begonnen habe, war ich auf die Background-Tasks angewiesen, da es keine relevanten Alternativen gab. Mittlerweile gibt es jedoch .NET Core Anwendungen. Diese ermöglichen die Programmierung von C# Anwendungen, theoretisch Plattform- und Architekturabhängig. Jedoch muss für jede Plattform/Architektur-Kombination eine passende Runtime-Umgebung installiert werden. Die offiziell freigegebenen sind [hier] erhältlich, die noch in der Entwicklung befindlichen (dazu gehört aktuell auch WindowsIoT auf dem Raspberry) dagegen [hier]. Da es aktuell noch keinen Installer für WindowsIoT gibt, habe ich die Dateien aus dem ZIP-Archiv einfach in den Windows/System32 Ordner kopiert.

Nun musste meine Server-Anwendung noch von "IoT-Background-Task" auf ".Net Core Anwendung" umgestellt werden. Da es dafür keine triviale Möglichkeit gibt, habe ich einfach eine neue Projektmappe mit den gleichen Projekten angelegt und die Quelldateien rüberkopiert. Dabei habe ich festgestellt, dass einige verwendete Klassen bzw. Namespaces hier nicht existieren. Die entsprechenden Codeabschnitte mussten also auf alternative Klassen umgestellt werden. Das betrifft konkret die Bereiche TCP/UDP-Kommunikation, sowie Dateisystemzugriff und Datenverschlüsselung. Außerdem muss ein neuer Programmeinstiegspunkt angelegt werden.

Sind alle Umstellungen abgeschlossen und wird die Projektmappe erfolgreich kompiliert, so kann das Startprojekt (in meinem Fall "HomeAutomationServerLauncher") via Rechtsclick und "Veröffentlichen" freigegeben werden. Dabei sollte darauf geachtet werden, dass als "Target-Runtime" "Portable" oder die Runtime des Zielsystems ausgewählt wird. Läuft dieser Prozess ohne Fehler durch, so liegen die erzeugten Dateien im "Target-Location"-Ordner.

Veröffentlichen eines Projektes unter Visual Studio

Das erzeugte Projekt befindet sich anschließend in "Target-Location"

Beim Betrachten der erzeugten Dateien fällt auf, dass keine ausführbare Datei (".exe") dabei ist. Diese wird nicht benötigt, da wir mit der "dotnet.exe" aus der .NET Runtime bereits eine solche haben. Das Programm kann also nun über PowerShell oder einer anderen Console per

dotnet "C:\Program Files\HomeAutomationServer\HomeAutomationServerLauncher.dll"

gestartet werden.

Autostart mit dem TaskScheduler

Um die Anwendung automatisch nach dem Start des Betriebssystems auszuführen, habe ich diesen Befehl in eine Batch-Datei geschrieben und diesen an den Windows-TaskScheduler angehängt. Dazu habe ich folgenden Befehl verwendet:

SCHTASKS /Create /SC ONSTART /TN HomeAutomationServer /TR "'C:\Program Files\HomeAutomationServer\Startup.bat'" /ru SYSTEM

Die Anwendung wird nun also bei jedem Windows-Start ausgeführt. Um die Anwendung sofort zu starten, kann man die Ausführung mit folgendem Befehl auslösen:

SCHTASKS /Run /TN HomeAutomationServer

Um die Anwendung wieder aus dem Scheduler zu entfernen, kann folgener Befehl verwendet werden:

SCHTASKS /Delete /TN HomeAutomationServer /f

Plugins

Da der Server nun nicht mehr in einer Sandbox läuft, kann er auch Assemblys und damit Plugins nachladen. Deswegen habe ich damit begonnen, einige Abschnitte in Plugins auszulagern. Angefangen habe ich mit der Alexa-Implementierung, da sich diese dafür besonders angeboten hat.

Bisherige Alexa-Kommunikations-Struktur

Der Grund dafür ist, dass der HTTP-Server, welcher die Alexa-Requests aus dem Internet bearbeitet, bisher in ein virtuelles Gerät ausgelagert war, welches ebenfalls als Background-Task auf dem Raspberry lief und sich intern mit dem Server verbunden hat. Nun läuft dieser als Plugin direkt auf dem Server. Gleichzeitig habe ich die zu Alexa gehörenden Logikelemente an diese Veränderung angepasst und mit in das Plugin ausgelagert. Beim Start des Servers sucht dieser nun im Plugin-Ordner nach ladbaren Assemblys und versucht in darin Plugins zu finden, welche daraufhin geladen werden.

Neue Alexa-Kommunikations-Struktur

Die Struktur mit Plugins wird es mir in Zukunft ermöglichen, den Server variabler zu gestalten und weiter zu einer einfacheren Handhabung zu verbessern. Zudem wird es, sollte ich mich jemals für eine Veröffentlichung des Projektes entscheiden, Nutzern ermöglichen, selbst den Server zu erweitern.

Projektabschluss: Forschungsseminar Teil 2

Hallo,

wie bereits angekündigt, möchte ich heute die Umsetzung unseres Forschungsseminar-Projektes vorstellen. In [Teil1] ging es um die Projektidee und deren Konzeption.

Für die Umsetzung unserer erarbeiteten Konzepte hatten wir erneut ein Semester Zeit. Da wir unsere Bestelllisten bereits am Ende des ersten Semesters abgegeben hatten, konnten wir zunächst zügig unsere Lieferungen in Empfang nehmen. In Folge dessen konnte ich die geplante Schaltung auf einem Breadboard aufbauen.

Schaltungsaufbau auf Steckbrett

Mikroprozessor-Programmierung

Diesen provisorischen Aufbau habe ich genutzt, um die Programmierung zu beginnen. Es war nötig, dies zügig anzugehen, da davon die Arbeit der anderen Gruppenmitgliedern abhängte. Die Programmierung des Mikroprozessors habe ich in mehrere unabhängige Module (Antrieb, Eingabe, Kommunikation, etc.) unterteilt. Jedes der Module enthält eine "Init" und eine "Handle" Methode. Die Init-Methoden werden ein mal bei Programmstart ausgeführt, die Handle-Methoden anschließend in einer Schleife. Dadurch ist es möglich, Modulen mehr Rechenzeit zuzuordnen, wenn diese zeitkritisch behandelt werden müssen. Dies war insbesondere bei der Motorsteuerung von Vorteil, da die Steuerausgänge des Motors während einer Bewegung oft geändert werden müssen. In diesem Fall wird die Handle-Methode des Motors zehn mal öfter aufgerufen, als die Handle-Methoden der anderen Module.

Programmablaufplan Mikroprozessor

Kommunikation

Die Kommunikation mit der Einrichtungs-App erfolgt über WLAN. Ist dem System noch kein Netz bekannt, so wird ein eigener Hotspot aufgebaut. Zu diesem kann sich verbunden werden, um das System einzurichten und mit einem WLAN zu verbinden. Diese Verbindung ist optional, hat jedoch den Vorteil, dass das System von selbst die Uhrzeit aus dem Internet beziehen kann. Außerdem muss sich für spätere Änderungen nicht erneut zum Hotspot verbunden werden.

Als Transportprotokoll wird sowohl TCP, als auch UDP verwendet. TCP wird zur Übertragung von Daten verwendet, welche nur sporadisch gesendet werden, also beispielsweise die Änderung eines Parameters. UDP wird dagegen für zyklisch übertragene Daten verwendet. Dies sind sich ständig ändernde Werte wie der aktuelle Umgebungslichtwert oder die Rolloposition.

Platinenlayout

Parallel zur Programmierung musste die Schaltung in ein Platinenlayout übertragen und umgesetzt werden. Dazu habe ich die Bauteile auf kariertem Papier gezeichnet und angeordnet. Dabei habe ich insbesondere darauf geachtet, den Leistungsteil und den Logikteil zu trennen, da diese mit unterschiedlichen Spannungen arbeiten (12V und 5V). Als Resultat ergibt sich das folgende Layout.

Platinenlayout

Diese Layout habe ich im folgenden mit der Gruppe besprochen, da die Platine auch in ein Gehäuse integriert werden musste und dafür entsprechende Anschluss- und Befestigungsmöglichkeiten gegeben sein mussten. Da es jedoch keine Einwände gab, habe ich das Layout umgesetzt. Das folgende Bild zeigt eine fertige und eine für die Bestückung vorbereitete Platine.

Fertige und vorbereitete Platine

Tasterleiste

Zur lokalen Bedienung ohne App wurde eine Tasterleiste entwickelt. Diese besteht aus vier Tastern, welche über ein Wiederstandsnetzwerk an den analogen Eingang des ESP8266 angeschlossen sind. Die Tasterleiste ist optional an das Antriebsmodul ansteckbar. Da die Belegung der Tasten variabel und Geräteübergreifend vorgesehen war, hätte so nur eine Leiste für beispielsweise zwei Rollos verwendet werden können. Auf Grund knapper Bearbeitungszeit haben wir uns jedoch dazu entschlossen, die variable Belegung außenvor zu lassen. Stattdessen wurden die vier Tasten mit Standardfunktionen belegt, welche von allen im Netzwerk befindlichen Geräten ausgeführt werden. Diese Funktionen sind: "bis ganz oben fahren", "nach oben fahren, solange gedrückt", "nach unten fahren, solange gedrückt" und "bis ganz unten fahren".

3D-Modell der Tasterleiste

Die Leiste selbst besteht aus einer kleinen Lochrasterplatine, welche die vier Taster mit jeweils einem Widerstand enthält. Die Platine ist in einem Gehäuse eingefasst, welches aus aus Rückseite, Deckel und vier Tasterblenden besteht. Die Gehäuseteile wurden per 3D-Druck gefertigt. Leider war die Qualität des 3D-Drucks nicht besonders überragend, sodass die gedruckten Teile mehrere Stunden Nacharbeit benötigten, um zusammen zu passen, obwohl beim Design bereits Toleranzen vorgesehen wurde. Dieses Problem hat auch die Gehäuse für unsere Antriebsmodule, sowie einige andere Gruppen des Seminars betroffen. Den Grund für die schlechte Qualität vermute ich in den Druckeinstellungen. Da wir die Teile jedoch in der Uni fertigen haben lassen, hatten wir keinen Einfluss darauf.

Ein weiteres Problem war der Zusammenhalt des Gehäuses der Tasterleiste. Die Front und die Rückseite sollten über einen Schnappmechanismus zusammen halten. Leider habe ich diesen zu klein dimensioniert, sodass mittlerweile drei der vier Nasen abgebrochen sind. Normalerweise hätte ich die Teile noch einmal designt und erneut gedruckt, leider mangelte es aber auch dafür an der Zeit. Stattdessen haben wir die Teile mit Metallklammern versehen und mit Klebeband fixiert - schön ist es nicht, aber es hält  ¯\_(ツ)_/¯

Die Tasterleiste von der Planung bis zum fertigen Objekt

Abschluss

Am Ende des Semesters galt es, die Module an unseren Demonstrator anzubauen und für die Abschlusspräsentation vorzubereiten. Die folgenden Bilder zeigen unseren finalen Zustand, welchen wir auch letztendlich präsentiert und verteidigt haben.

Der Demonstrator in der Gesamtansicht

Eines der drei Antriebsmodule im geschlossenen Gehäuse

Ein anderes der Antriebsmodule mit offenem Gehäuse.
Dieses wurde offen gelassen, um bei der Präsentation einen Einblick zu gewähren

Die Tasterleiste an der linken Seite des Demonstrators.

Mit dem Abschluss dieses Projekts sollte es mir nun auch wieder möglich sein, weiter an meinen privaten Projekten zu arbeiten. An einigen Dingen habe ich bereits gearbeitet, aber darüber werde ich in einem zukünftigen Blogeintrag schreiben.

Projektabschluss: Forschungsseminar Teil 1

Hallo,

nach knappen fünf Monaten komme ich endlich wieder mal zu einem Blogeintrag. In dieser Zeit hat sich viel getan bei mir: Mein Studium schreitet Richtung Studien- und Masterarbeit voran, gelegentlich arbeite ich an meinen IoT-System, wozu ich wohl auch mal wieder einen Eintrag verfassen werde, und seit November bin ich zudem stolzer Autobesitzer. :)

Den Blog habe ich in letzter Zeit leider etwas vernachlässigt. Das möchte ich heute ändern, denn im Rahmen meines Studium galt es ein Forschungsseminar über zwei Semester durchzuführen. Dieses hat mich viel Zeit gekostet, was auch einer der Gründe für den kahlen Blog ist. In diesem Eintrag möchte ich erst einmal grundsätzlich beschreiben, was das Forschungsseminar ist und was wir im ersten Semester an Konzeptionsarbeit geleistet haben. In einem späteren Eintrag wird die Umsetzung im zweiten Semester behandelt.

Zum Forschungsseminar

Das Forschungsseminar ist eine Pflichtveranstaltung meines Studiengangs (Mikrotechnik/Mechatronik). Der Sinn ist die Arbeit an einem Projekt von der Idee, über die Planung, bis zur Umsetzung. Dafür sollte zunächst von jedem Studenten eine Projektidee erarbeitet werden, welche in kurzen 3-Minuten Vorträgen vorgestellt werden mussten. Aus diesen wurden dann die besten ausgewählt und jeweils vier Personen zugeteilt, unter welchen sich natürlich jeweils der Ideengeber befand. Mein Vorschlag war ein nachrüstbarer Antriebssatz für "Klemmfix"-Rollläden, welcher glücklichweise auch ausgewählt wurde. Als Budget standen uns, wie jeder anderen der insgesamt 10 Gruppen auch, 400€ bereit.

Unser Projektlogo

Projektidee und Anforderungen

Die Grundidee meines Projektes ist, dass es elektrische Rollläden quasi nur fest eingebaut gibt. Grade unter uns Studenten sind jedoch die günstigen "Klemmfix"- Rollläden verbreitet. Für diese gibt es jedoch keinerlei Möglichkeit eines elektrischen Antriebs.

Im Projekt sollte also ein Prototyp entwickelt werden, welcher diese Funktionalität nachrüstet. Dabei ist zu beachten, dass es für diese Art von Rollläden viele verschiedene Hersteller gibt, deren Systeme untereinander leicht abweichen. Der Prototyp muss von daher an die verschiedenen Systeme anpassbar sein und auch mit verschiedenen Breiten und Längen funktionieren.

Aus elektrischer Sicht sollte ein Antrieb, sowie eine Positions- und Umgebungslichterkennung realisiert werden. Dafür ist natürlich ein Mikroprozessor erforderlich. Dieser sollte neben der Steuerung des elektrischen Systems auch eine "smarte" Funktionalität ermöglichen. Für uns bedeutete dies, dass das System Zeit- und auch Lichtgesteuert verfahren werden kann. Gleichzeitig ist eine manuelle Steuerung vorzusehen.

Um das System einzurichten und manuell zu verfahren, sollte außerdem eine Android-App entwickelt werden. Diese sollte aber nicht für den reinen Betrieb benötigt werden, der Mikroprozessor musste also auch unabhängig von der App arbeiten können.

Konzeption

Auf Basis dieser selbst auferlegten Vorgaben entwickelten wir im ersten Semester Konzepte und Pläne zur Umsetzung. Während der Rest des Teams sich um die mechanische Auslegung und um die App kümmerte, beschränkte sich mein Aufgabenbereich auf die elektrische Entwicklung, sowie die Mikroprozessor-Programmierung.

Da der Mikroprozessor mit einem Smartphone kommunizieren sollte, wählte ich zunächst den mir wohlbekannten ESP8266 als Startpunkt aus. Zum Antrieb wusste ich bereits aus dem Studium wusste, dass ein Schrittmotor wohl die ideale Wahl wäre. Trotzdem musste ich mich tiefer mit Schrittmotoren befassen, da im Studium leider nicht vermittelt wird, wie diese in Systeme zu integrieren sind. Schließlich entschied ich mich für einen Schrittmotor des Typs "28BYJ-48", nicht zuletzt auch auf Grund der Verbreitung und Verfügbarkeit und damit verbundenen Anleitungen und Tipps in diversen Foren. Da der analoge Eingang des ESP schon verwendet war -dazu gleich mehr- musste ich mich für die Lichtmessung nach einem digitalen Sensor umsehen. Letztendlich habe ich mich für den per I²C anschließbaren "TSL2561" auf einem Breakoutboard entschieden.

Um eine manuelle Bedienung auch ohne App zu ermöglichen, habe ich außerdem eine Tasterleiste vorgesehen, welche optional an das Antriebsmodul angesteckt werden kann. Diese enthält vier Taster, welche verschiedene Aktionen auslösen können. Elektrisch gesehen, ist diese Leiste ein Widerstandsnetzwerk, welches über ein Zweidrahtsystem an das Antriebsmodul angesteckt wird. Über die Auslegung dieses Systems hatte ich damals schon einen Eintrag verfasst.

Schaltplan des Systems

Von informatischer Seite waren die in der Konzeption festgelegten Anforderungen umzusetzen. Um meinen Teammitgliedern, welche die App programmieren sollten, die Integration zu vereinfachen habe ich parallel zur Mikroprozessorprogrammierung eine C++-Bibliothek erstellt, welche die gesammte Kommunikation übernimmt und eine JNI-API zur Verfügung stellt. Dadurch konnte ich die hardwarenahe Programmierung klar von der App-Programmierung trennen.

Neben meinen Konzepten entstanden während dieses Semesters durch die anderen Teammitglieder Konzepte für die App, für die Mechanik und den Demonstrator zur abschließenden Vorführung. Dazu möchte ich die beiden unten stehenden Bilder zeigen, welche den Abschluss der Konzeption in diesen Bereichen ganz gut wiedergeben.

Konzept des Demonstators mit drei Rollläden verschiedener Hesteller

Das Use-Case-Diagramm mit umzusetzenden Möglichkeiten

Damit möchte ich diesen Eintrag abschließen. Nach Erscheinen wird Teil 2 zur Umsetzung [hier] zu finden sein.