Shelly 2.5

Heute möchte ich den Shelly 2.5 vorstellen. Es handelt sich dabei um den Nachfolger des Shelly 2, welchen ich vor knapp vier Monaten vorgestellt habe. Grundsätzlich ist der Shelly 2.5 genau wie sein Vorgänger ein 2-Kanal WLAN-Funkschalter, welcher für den Einbau hinter einem Lichtschalter konzipiert ist. Er ist ein direkter Ersatz für den Shelly 2, daher wird der Shelly 2 auch nicht weiter hergestellt und vertrieben. Der Preis ist mit 20€ pro Stück gleich geblieben. Als Nachfolger weist das Gerät eine Reihe von Verbesserungen und Unterschiede auf.

Die Anschlüsse des Shelly 2.5 befinden sich nun alle auf einer Seite.

Auf der Rückseite finden sich der Pinheader zum Flashen, sowie ein Resetbutton.

Äußerlich fällt zunächst direkt auf, dass das Gerät nun deutlich kantiger ist als sein Vorgänger. Vermutlich konnte der zusätzliche Platz auf der Platine des Shelly 2 durch die runde Form nicht genutzt werden und konnte daher eingespart werden. Die Anschlüsse des Shelly 2.5 liegen nun alle auf einer Seite. Die Anzahl derer ist zudem um eins gewachsen, da es nun zwei Schraubanschlüsse für den stromführenden Leiter gibt. Diese sind intern zwar verbunden, ermöglichen dadurch jedoch theoretisch einen höheren Strom. Dieser wurde vom Shelly 2 von 8A auf 10A pro Kanal erhöht. Bei kleineren Lasten sollte es aber kein Problem darstellen, nur einen Anschluss anzuschließen.

Auf der Rückseite des Gerätes befinden sich nun eine Pinleiste, ein Reset-Button, sowie eine Status-LED. Die Pinleiste dient zum Flashen einer eigenen Firmware. Dies gestaltet sich jedoch ein wenig schwieriger als erwartet, da diese nicht das typisch 2.54mm Raster aufweist, sondern nur 1.27mm verwendet werden. Normale Kabel von Breadboards funktionieren daher hier nicht, oder nur mit erhöhtem Aufwand. Die Pins sind von außen nicht beschriftet, dafür befindet sich die Beschriftung direkt auf der Platine. Da sich auf der Pinleiste aber sowieso werksseitig eine kleine Klebefolie befindet, muss das Gehäuse eh einmal geöffnet werden. Das Öffnen des Gerätes gestaltet sich deutlich einfacher als beim Shelly 2, bei welchem die Gehäusehälften noch verklebt wurden. Beim Shelly 2.5 wird dagegen ein Schnappmechanismus verwendet. Dieser ist von außen am Gehäuse markiert.

Ein Shelly 2.5 mit geöffnetem Gehäuse.

Nach dem Öffnen des Gerätes zeigen sich zunächst die beiden Relais, sowie verschiedene Bauteile des internen Netzteiles. Die Relais befinden sich auf einer zweiten, senkrechtstehenden Platine, welche in die Hauptplatine gesteckt und gelötet ist. Dadurch wird sich der Platz für die Relaispins auf der Hauptplatine gespart.

Die Rückseite der Hauptplatine des Shelly 2.5.

Auf der Rückseite der Hauptplatine befindet sich die Logik des Gerätes. Neben dem ESP8266 als Mikroprozessor finden sich zudem ein Chip mit der Bezeichnung ADE7953. Dabei handelt es sich um einen Chip zur Energiemessung. Dieser unterscheidet sich deutlich vom MCP39F501, welcher im Shelly 2 verbaut wurde. Für den Anwender am relevantesten ist hier, dass der Chip des Shelly 2.5 nun eine Zweikanalmessung für Strom und Leistung beherrscht. Die beiden Schaltausgänge des Gerätes können nun also getrennt gemessen werden. Der Chip beherrscht zudem eine Spannungsmessung. Da beide Kanäle an die gleiche Versorgungsspannung angeklemmt ist, ist diese auch nur einkanalig. Im Gegensatz zum Chip des Shelly 2 beherrscht der Chip nun jedoch keine Messung der Phasenverschiebungen, sowie keine Unterscheidung der Leistung nach Schein-, Wirk- und Blindleistung. Dies dürfte jedoch für das Anwendungsfeld kaum relevant sein.

Ein weiterer Vorteil des neuen Chips ist die Kommunikation mit dem ESP8266. Diese wird nun über I²C durchgeführt, anstatt über eine serielle Verbindung. Dadurch bleibt die serielle Schnittstelle des ESP8266 frei und kann für Debugging-Nachrichten genutzt werden.

Bevor ich nun zu einem abschließenden Vergleich des Shelly 2 mit dem Shelly 2.5 komme, möchte ich noch eine Warnung zum Shelly 2.5 verbreiten, welche vom Hersteller veröffentlicht wurde. Die Geräte der ersten Charge des Shelly 2.5 weisen möglicherweise einen Fehler auf, was die Platzierung der Antenne betrifft. Diese ist an den unteren Gehäusedeckel geklebt und mittels einer Folie isoliert. Die Platzierung der Antenne der ersten Charge ist jedoch teils fehlerhaft. Im Fehlerfall kann die Folie durch herausstehende, Netzspannung führende Pins zerstört werden. Dies kann zu einem Kurzschluss und damit zu einer Zerstörung des Gerätes führen. Es soll wohl jedoch keine Gefahr nach außen bestehen. Dafür übernehme ich jedoch keine Garantie. Näheres dazu im Forum des deutschen Vertreibers CreationX.

Hier ist die Antenne zu weit unten rechts platziert, wodurch sie perforiert werden kann. Im Bild erkennt man auch bereits rechts einen Abdruck eines Pins.

So sollte die Antenne in etwa platziert sein.

Zum Abschluss des Blogeintrags hier nun noch einmal die wichtigsten Daten des Shelly 2.5 im direkten Vergleich zu seinem Vorgänger.

	Shelly 2	Shelly 2.5
Abmessungen: (L*B*H)	44mm * 43mm * 20mm	39mm * 36mm * 17mm
Maximale Größe: (diagonal)	44mm	47mm
Energiemessung:	1 Kanal: Spannung Strom Wirkleistung Blindleitsung Scheinleistung Phasenverschiebung	2 Kanal: Spannung Strom Scheinleistung
Maximale Schaltleistung pro Kanal:	8A (1840W @ 230V)	10A (2300W @ 230V)
Weitere Vorteile	-	Pinheader zum Flashen Reset-Button + LED

Shelly 2 und Shelly 2.5 im Größenvergleich.
Der Shelly 2 hier nur als Gehäuse ohne Innenleben.

Projektzwischenstand und GitHub

Der heutige Post wird leider ein ziemlich kurzer. Da ich ja aktuell meine Masterarbeit schreibe, fehlt mir momentan die Lust dazu, auch noch privat technische Beschreibungen und Darstellung zu erarbeiten. Ich arbeite allerdings trotzdem weiterhin an meinen Projekten. Insbesondere bei meinem Smart-Home Projekt gibt es einige Fortschritte.
So habe ich beispielsweise inzwischen gerätespezifische Funktionen implementiert. Dies sind Funktionen welche vom Userclient aus gestartet und unter Verwendung von Parametern auf den Geräten ausgeführt werden können. Praktisch habe ich dies benötigt und verwendet, um die Energiemessung des Shelly 2 und des Shelly 2.5 kalibrieren zu können. Die Shelly 2.5 sind inzwischen bestellbar und ich habe sie auch bereits erhalten und in mein System eingebunden.

Aktuell arbeite ich zudem an Gerätevorlagen. Im momentanen Zustand ist es noch notwendig, dass jeder Eingang, jeder Ausgang und jede Funktion eines Gerätes einzeln benannt werden müssen. Wird ein weiteres Gerätes des selben Typs hinzugefügt, so muss die Prozedur wiederholt werden. Die Gerätevorlagen sollen dazu dienen, dass dies nur noch einmal geschehen muss. Alle weiteren Geräte des gleichen Typs können die Daten anschließend übernehmen, beziehungsweise erhalten die Daten aus der gleichen Vorlage. Auch ein Import der Daten aus verschiedenen Quellen, möglicherweise auch direkt von den Geräten wäre denkbar.

All die genannten Dinge werde ich hier näher darlegen, wenn ich wieder Lust dazu habe Texte zu verfassen. Währenddessen habe ich mich zunächst dazu entschieden, den Quellcode zu meinem 4x4-LEDCube auf GitHub zu veröffentlichen. Ich möchte nach Möglichkeit auch meine anderen Projekte dort mit hochladen. Auch dies werde ich jedoch nach Zeit und Lust durchführen.

Alte Projekte: 4x4 LED-Cube

Hallo zusammen,

während ich natürlich weiterhin an superinnovativen Projekten arbeite, habe ich es heute wieder einmal geschafft, die Projektseite für ein abgeschlossenes Projekt fertigzustellen. Es handelt sich dabei um meine 4x4 LED-Cubes, welche ich 2015 als Weihnachtsgeschenke gebaut habe.

Die gesamte Beschreibung des Würfel kann jetzt auf der dazugehörigen Projektseite gelesen werden.

Shelly 1 & 2

Hallo zusammen,

heute möchte ich euch zwei neue Geräte vorstellen, welche ich bereits im Dezember erhalten habe. Es handelt sich dabei um die Modelle Shelly 1 "open source", sowie Shelly 2. Beide Geräte gehören zur Marke Shelly, welche die IoT-Sparte der bulgarischen Firma "Allterco Robotics" darstellt. Die Geräte sind kompakte WLAN-Schalter auf Basis des ESP8266, welche in vorhandene Wandschalter integriert werden können. Dadurch können vorhandene (Beleuchtungs-) Systeme in das eigene WLAN-IoT-Netz integriert werden. Im Gegensatz zu Geräten wie dem Sonoff T1 , welche als Ersatz für den kompletten Schalter konzipiert sind, können die Shellys hinter bestehende Schalter eingebaut werden.

Die Preise der Geräte betragen 10€ für den Shelly 1 und 20€ für den Shelly 2. Dies ist zwar nicht so günstig wie die Sonoff-Geräte, es muss jedoch bedacht werden, dass die Geräte nicht aus China kommen. Betrachtet man zudem die Preise für ähnliche Produkte für fertige Systeme, so sind die Preise plötzlich nicht mehr so teuer.

Betrachtung der Geräte

Die Geräte werden in kompakten Pappschachteln geliefert, welche nicht viel größer sind, als die Shellys selbst.

Neben den Geräten enthalten die Schachteln noch jeweils einen Warnhinweis zum Anschluss, einen Hinweis auf den Support, bzw. die Facebook-Supportgruppe, sowie eine ausführliche Anleitung zum Anschluss des Gerätes.

Der Shelly 1 wird mit dem Slogan "open source" beworben. Dies ist darauf zurückzuführen, dass die Pins zum Flashen des integrierten ESP8266 als Pinheader nach außen geführt sind. Dadurch ist es möglich, eine eigene Firmware aufzuspielen.

Neben dem Pinheader enthält der Shelly 1 einen Jumper, mit welchem die Betriebsspannung ausgewählt werden kann. Dabei kann man sich zwischen 230V AC oder 12V DC entscheiden. Die ausgewählte Spannung muss dann auf die Eingänge N/L angeklemmt werden, um das Gerät in Betrieb zu nehmen.

Bei Verwendung eines externen Handschalters muss dieser zwischen die Anschlüsse SW und L geklemmt werden. Der ESP8266 kann dann die Schalterstellung erfassen und auf Eingaben reagieren. Abhängig von der Firmware können dabei Schalter oder Taster verwendet werden.

Der Ausgang des Shelly 1 besteht aus den Klemmen 0 und 1. Beim Schalten des internen Relays werden diese Klemmen verbunden oder getrennt. Da sie ansonsten vom Rest des Gerätes getrennt sind, ist es auch möglich hier andere Spannungen zu schalten, als die ausgewählte Betriebsspannung. Dabei ist jedoch zu beachten, dass sich die Ausgänge trotzdem auf der gleichen Platine befinden wie die anderen Klemmen und nicht besonders von diesen abgeschirmt sind. Sollte also mit dem Gerät Netzspannung geschalten werden, während die Betriebsspannung durch ein 12V-Netzteil zur Verfügung gestellt wird, so sollten auch die 12V nicht als berührungssicher betrachtet werden.

Oberseite der Geräte, Links: Shelly 1, Rechts: Shelly2

Der Shelly 2 ähnelt dem Shelly 1 äußerlich sehr, hauptsächlich die andere Anschlussverteilung fällt auf. Diese ist darin begründet, dass der Shelly 2 gleich zwei Kanäle enthält. Das heist, dass sowohl zwei geschaltete Ausgänge, als auch zwei Handschalter-Eingänge zur Verfügung stehen. Im Unterschied zum Shelly 1 sind die Ausgänge nicht potentialgetrennt. Das heist, dass das Schalten der internen Relais den jeweiligen Ausgang mit dem L-Eingang verbindet. Die Betriebsspannung von 230V entspricht daher immer der zu schaltenden Spannung. Ein Betrieb an 12V etc. ist nicht vorgesehen.

Zusätzlich enthält der Shelly 2 einen Chip zur Energiemessung, welcher Energiedaten (Spannung, Strom, Leistung, Frequenz, Leistungsfaktor, etc.) der angeschlossenen Geräte erfassen kann. Allerdings ist die Leistungsmessung nur für einen Kanal ausgeführt, das heist die Daten können nur für beide Ausgänge zusammen ermittelt werden.

Diesem erweiterten Leistungsumfang im Vergleich zum Shelly 1 ist leider der Pinheader und der Jumper zur Spannungsauswahl zum Opfer gefallen. Es ist also nicht vorgesehen, das der Shelly 2 mit einer neuen Firmware versehen wird. Das Gerät wird daher auch nicht mit dem "open source"-slogan des Shelly 1 beworben.

Oberseite der Geräteplatinen, Links: Shelly 2, Rechts: Shelly 1
Achtung, Anordnung zu vorherigen Bildern vertauscht!

Die Platinen beider Geräte scheinen gut verarbeitet. Insbesondere die Platine des Shelly 2 ist dabei jedoch sehr eng bestückt. Daher war es vermutlich auch nicht möglich, einen Pinheader herauszuführen.

Bei den Relais fällt auf, dass das Relais des Shelly 1 den gleichen Platz einnimmt, wie beide Relais des Shelly 2.  Ich führe dies darauf zurück, dass die Schaltleistung des Shelly 1 16A beträgt, die Schaltleistung des Shelly 2 jedoch pro Kanal 8A. Beides macht durchaus Sinn, da Stromkreise im Haus hier typischerweise mit 16A-Sicherungen abgesichert sind. Alle Geräte eine Stromkreises sollten daher nicht mehr als 16A ziehen. Bei zwei angeschlossenen Geräten am Shelly 2 sollten auch diese also zusammen nicht mehr als 16A ziehen.

Die Aufteilung auf zweimal 8A führt allerdings dazu, dass die Anschlussleistung nicht asymmetrisch verteilt werden kann, also beispielsweise ein Gerät mit 12A und ein Gerät mit 4A versorgt werden kann. Auch der Fall, dass an beiden Anschlüssen jeweils ein 16A Gerät angeschlossen wird und dass die beiden Anschlüsse nur exklusiv eingeschalten werden können, wird durch die 8A/8A-Verteilung ausgeschlossen. Dies ist schade, sollte aber nur in wenigen Fällen zu Problemen führen.

Unterseite der Geräteplatinen, Links: Shelly 2, Rechts: Shelly 1

Integration der Geräte

Die Integration des Shelly 1 in mein Home-Automation-System ist mir nicht sonderlich schwer gefallen. Die Firmware konnte ich fast 1:1 vom Standard-Sonoff übernehmen. Lediglich die fehlende LED habe ich aus der Software entfernt. Zudem mussten die Erfassung des Handschaltereingang angepasst werden, da der Anschluss elektrisch etwas anders ausgeführt ist.

Zum Testen des Gerätes habe ich dieses vorübergehend in ein Aufputz-Gehäuse eingebaut und angeschlossen. Leider ist dieses nicht so tief wie typische Unterputzdosen, sodass ich Abstandhalter für den aufgesetzten Handschalter verwenden musste, damit der Shelly 1 in das Gehäuse passt.

Integration des Shelly 1 in ein Aufputzgehäuse

Deutlich schwieriger gestaltete sich die Integration des Shelly 2. Die einfache Implementierung der Ein- und Ausgänge war dabei das geringste Problem, da ich dafür die Firmware des Sonoff T1 übernehmen und anpassen konnte.

Die Herausforderung ist nun gewesen, die Firmware auf den Shelly 2 zu flashen, da ja kein Pinheader vorhanden ist. Stattdessen sind jedoch kleine Lötlöcher vorhanden, an welche Anschlusspins angelötet werden können. Dafür können jedoch keine Stiftleisten mit 2.54mm-Raster verwendet werden, da der Abstand der Löcher nicht passt. Das Anlöten von Pins gestaltet sich daher auf Grund des geringen Abstandes vergleichsweise schwierig.

Später habe ich durch ein wenig Reverse-Engineering herausgefunden, dass alternativ zu den 3.3V auch oben 12V an die Pins eines Kondensators angelegt werden können. Die 12V sind intern vorhanden, um die Relais zu schalten, es wird daraus aber auch die 3.3V Spannung für den ESP8266 erzeugt. Auch hier müssen natürlich Pins angelötet werden. Dies ist am Kondensator jedoch einfacher, da sich keine anderen Kontakte in diesem Bereich befinden.

Anschlussmöglichkeiten des Shelly 2
Nicht gleichzeitig 3.3V und 12V anschließen!

Als deutlich größere Schwierigkeit stellte sich der integrierte Chip zur Energiemessung heraus. Es handelt sich dabei um einen "MCP39F501" von Microchip. Für diesen gibt es keine fertige Arduino/C++-Bibliothek. Ich konnte jedoch die Funktionsweise anhand des Datenblattes, sowie der Integration in Sonoff-Tasmota nachvollziehen. Aus dem dort verwendeten Code habe ich mir eine Bibliothek für den Chip zusammengebaut, welche nach einem nicht unerheblichen Zeitaufwand letztendlich auch die verschiedenen Funktionen des Chips unterstützt.

Dazu gehören neben der Initialisierung und der Abfrage der Energiewerte auch die Kalibrierung. Um diese auch von meiner Clientanwendung durchführen zu können, habe ich das Device-Modul meines Home-Automation-Systems um "Device-Functions" erweitert. Auf diese möchte ich ausführlich in einem späteren Blogeintrag eingehen. Als Kurzbeschreibung soll an dieser Stelle ausreichen, dass es sich dabei um parameterbehaftete Funktionen handelt, welche per Hand auf dem Gerät ausgeführt werden können und welche auch Daten zurückliefern können. Eine solche Device-Function habe ich hier verwendet, um die Daten einer bekannten angeschlossenen Last (1.1 kW Heizlüfter) an das Gerät zu übertragen und mit Hilfe dieser die Kalibrierung durchzuführen.

Genau wie den Shelly 1 habe ich auch den Shelly 2 in ein Aufputzgehäuse eingebaut und angeschlossen. Leider habe ich davon keine Fotos gemacht und kann diese auch aktuell nicht nachmachen. Der Grund dafür ist, dass ich leider ein Montagsmodell der Shelly 2 erwischt habe. Dieses gab während des Betriebs einen deutlich wahrnehmbaren Fiepton von sich. Dieses Geräusch konnte ich auf ein spezielles SMD-Bauteil zurückführen. Leider konnte ich den Chip anhand des Aufdruckes nicht identifizieren, ich vermute jedoch, dass es sich um einen DC/DC-Wandler ähnlich dem "MCP16301" von Mircochip handelt. Beim Versuch das Fiepen abzuschalten, ist mir jedoch versehentlich der ESP8266 durch Überspannung kaputt gegangen, sodass ich nun kein Gerät dieses Typs mehr zur Verfügung habe.

Ausblick

Nachdem ich mir also den Shelly 2 zerschossen habe, wollte ich mir auf der Herstellerwebseite einen neuen bestellen. Dabei musste ich aber feststellen, dass der Shelly 2 dort nicht mehr auftaucht. Sowohl die Produktseite als auch die Shopseite ist verschwunden. Stattdessen wird mit der Möglichkeit zur Vorbestellung des Shelly 2.5 ab dem 15. Februar geworben.

Zu diesem sind leider noch keine genauen technischen Details bekannt, es wird jedoch mit deutlichen Verbesserungen im Vergleich zum Shelly 2 geworben:

• 30% kleiner
• 2 * 10A Relais
• Energiemessung für beide Kanäle getrennt
• Herausgeführter Pinheader
• Außenliegende Status-LED + Resetknopf
• Interner Temperatursensor zur automatischen Sicherheitsabschaltung
• Gleich bleibender Preis (~20€)

Damit sind sämtliche Kritikpunkte, welche ich an dem Gerät habe abgedeckt. Da es mir nun nicht möglich ist, einen weiteren Shelly 2 zu bestellen und da es auf Grund des Nachfolgemodells auch keinen Sinn macht, werde ich das Projekt wohl bis zum Eintreffen des neuen Modells auf Eis legen und mich anderen Dingen widmen.

Bis dahin verabschiede ich mich und bedanke mich fürs Lesen!

Zeitpläne und Generics

Hallo zusammen,

Wie jeden Winter wurde bei uns wieder Anfang Dezember die Weihnachtsdekoration ausgepackt, dazu gehört auch mein Lichterbogen. Diesen hatte ich auch schon die beiden letzten Jahre über mein HomeAutomation-System zeitgesteuert integriert. Durch die Veränderungen der letzten Monate hat sich aber nun die Möglichkeit gegeben, die Integration zu verbessern.

Zunächst möchte ich einmal zeigen, wie die Zeitsteuerung bisher gelöst war. Dies ist im ersten untenstehenden Bild dargestellt. Die Steuerung funktioniert nach dem im Folgenden beschriebenen Prinzip.

Es existieren zunächst zwei globale Ganzzahl-Variablen. Dieses Ganzzahlen (14 und 1) stellen die Stunden von Uhrzeiten dar, genauer von einer Start-Uhrzeit und einer End-Uhrzeit. Beide zusammen ergeben einen Zeitbereich von 14Uhr-1Uhr. Diese globalen Variablen werden über zwei "Globale-Variable"-Blöcke ausgelesen und jeweils in einen "Time Generator"-Block übergeben.

Diese wandeln Werte für Stunde, Minute und Sekunde in eine Uhrzeit in Millisekunden um, wobei alle drei Eingangswerte optional sind. Die beiden Uhrzeiten in Millisekunden werden nun an einen "InDailyTime"-Block übergeben.

Dieser gibt einen Boole'schen Wert aus (also ja/nein), welcher angibt, ob sich die aktuelle Zeit innerhalb oder außerhalb der beiden Uhrzeiten befindet. Mit fortlaufender aktueller Zeit ändert sich natürlich der Ausgabewert des letzten Blocks.

Alte Zeitsteuerung

Diese Variante lief so (naja fast, die globalen Variablen waren ursprünglich mal lokale Konstanten) schon die beiden letzten Jahre. Dies hat einwandfrei funktioniert, hat aber diverse Nachteile. Erstens werden mehrere Variablen für die Zeitangabe benötigt, zweitens ist das Blockschema so schon unübersichtlich und drittens wird bei die Programmierung für weitere Zeitbereiche sehr schnell deutlich unübersichtlicher, da diese jeweils das gezeigte Schema benötigen.

Durch meine letzten Anpassungen, welche ich in den letzten Blogeinträgen beschrieben habe, hat sich nun die Möglichkeit ergeben, diesen Bereich zu optimieren. Bisher war das System auf die Grunddatentypen (Integer, Bool, Float, String, etc.) beschränkt. Jetzt gibt es aber die Möglichkeit  weitere Datentypen anzulegen und zu verwenden. Dadurch hat sich das Blockschema auf folgendes Bild vereinfacht.

Neue Zeitsteuerung

Das Schema hat nicht nur den Vorteil übersichtlicher zu sein, sondern ist dabei auch gleichzeitig deutlich funktionaler. Es verwendet den neuen Datentyp "TimeSchedule" (Zeitplan). Diesem Datentyp ist ein neuer Editor zugeordnet. Dieser ist genau auf den Datentyp zugeschnitten. Ein Zeitplan besteht zunächst aus einer beliebigen Anzahl von Gruppen. Jede Gruppe (im Bild "Woche" und "Wochenende") besitzt eine Zuordnung, an welchen Tagen die Gruppe gültig ist, sowie eine beliebige Anzahl an Zeitbereichen. Solange mindestens ein Zeitbereich einer beliebigen Gruppe aktiv ist, ist der Ausgabewert des Zeitplans "wahr", ansonsten "falsch".

Zeitplan-Editor

Die Angabe von Zeitplänen ist dadurch nun deutlich einfacher. Die neuen Zeitpläne nutze ich nun beispielsweise auch, um dem System mitzuteilen, wann es Tag ist und wann Nacht. Daran ist wiederum eine Vielzahl an Dingen gekoppelt.

Bei der Programmierung der Logik-Elemente (Die Blöcke in den ersten beiden Bildern) habe ich nun allerdings ein Problem festgestellt. Für jeden Datentyp, den ich anlege, muss ich einen "Konstante"-Block erstellen. Dies ist zwar prinzipiell möglich, zieht aber nach sich, dass mit jedem Datentyp die Anzahl der Blöcke steigt. Sollte ich mich dazu entscheiden, dass Projekt für weitere Entwickler freizugeben, müssten auch diese für jeden neuen Datentyp dieser Regelung folgen.

Konstanten für jeden Datentyp

Das ist zwar so schon nicht schön, es hätte aber vorübergehend funktioniert und ich hätte mich auch später noch darum kümmern können. Allerdings hat sich in Verbindung mit dem "Globale Variablen"-System gezeigt, dass ich es mir nicht so einfach machen kann. Denn ich hätte für jeden Datentypen auch noch einen Block für die globale Variable erstellen müssen.

Das ist nun gleich noch unschöner, hätte aber auch noch funktioniert. Nun ist aber seit kurzem jedes System als Plug-In realsiert. Das heist, das System "Globale Variablen" steht für sich, das System "Zeitplan" steht für sich, etc. Um nun also einen Block "Globale Variable (Typ Zeitplan)" zu erstellen, hätte ich die Spaltung in eigene Systeme auftrennen müssen. Das wollte ich dann doch vermeiden. Daher habe ich mir was intelligenteres einfallen lassen.

Den Programmierern unter den Lesern wird der Begriff "generic" bekannt sein. Für alle anderen möchte ich kurz erklären, worum es sich dabei handelt. Als generisch wird ein Objekt bezeichnet, welches mit verschiedenen Typen umgehen kann. Als Beispiel möchte ich eine Liste (C#) nennen. Eine Liste ist ein Objekt, welches mehrere Objekte eines Types enthält. Die Liste kann dabei mit allen möglichen Datentypen umgehen und besitzt verschiedene Funktionen, welche unabhängig vom Datentyp der enthaltenen Objekte sind. In C# erkennt man solche generischen Elemente an den Pfeilen, welchen den generischen Typ angeben. Im Beispiel der Liste mit dem enthaltenen Typ einer Ganzzahl würde dies so aussehen: List<int>

Um jetzt mal zum Thema zurückzukehren, möchte ich zeigen, was ich eingentlich getan habe. Es gibt nun einen neuen generischen Konstanten-Block, welcher alle bisherigen Konstanten-Blöcke ersetzt. Je nachdem, mit welchem Datentyp dieser Block verbunden wird, ändert sich der enthaltene Datentyp. Nach dem Verbinden kann anschließend der Wert der Konstante festgelegt werden.

Der Datentyp des neuen "Konstante"-Blocks ändert sich je nach angeschlossenen Typ.

Nach dem Verbinden kann der Wert festgelegt werden.

Der Typ des Blocks lässt sich jedoch nicht nur durch den angeschlossenen Datentyp bestimmen. Ist noch kein Datentyp angeschlossen, so bietet das Element eine Auswahl der Datentypen, welche alle nötigen Kriterien für Konstanten erfüllen. Diese Kriterien sind: Der Typ muss ich serialisieren (~speichern) und deserialisieren (~laden) lassen, und ihm muss ein Editor zugeordnet sein.

Das generische Element bietet eine Auswahl, welcher Datentyp verwendet werden soll.

Es kann natürlich auch eine Mischung aus beiden Fällen auftreten. Beispielsweise beim Verbinden mit dem Additions-Element. Dieses unterstützt Eingänge vom Typ "Ganzzahl" und "Gleitkommazahl". Da dem Element nach dem Verbinden noch nicht bekannt ist, welchen Datentyp es enthalten soll, fragt es auch hier nach.

Das Element fragt bei einer Auswahl an Datentypen nach, welcher verwendet werden soll.

Hinter dem Konstanten-Element steht ein System, welches es ermöglicht den Ausgabetyp eines Logikelements genau zu spezifizieren. Dieses System kann natürlich auch von allen anderen Logikelementen verwendet werden. Dadurch habe ich nun auch das"Globale Variablen"-Plug-In überarbeitet, sodass auch hier ein neues generisches Element existiert. Jeder Datentyp, der nun also die oben genannten Kriterien erfüllt, kann nun automatisch für globale und lokale Konstanten verwendet werden, ohne dass ein eigenes Logikelement erstellt werden muss.

Damit bin ich für heute auch schon wieder am Ende. Ich bedanke mich bei allen Lesern und wünsche schöne Weihnachten, sowie einen guten Start ins neue Jahr.

Markus

Umstrukturierung SmartHome-System

Hallo zusammen,

heute möchte ich über die Umgestaltung meines IoT-Systems sprechen. Dazu möchte ich zunächst auf die bisherige Struktur eingehen.

Alte Struktur

Bei der Entwicklung der Struktur 2015 bin ich von einer einfachen EVA-Struktur ausgegangen. Das heißt es gibt die Schritte Eingabe, Verarbeitung und Ausgabe. Für die Ein- und Ausgabe hatte ich physische Geräte vorgesehen, welche sich mit einem Server verbinden und sich dort registrieren. Dabei teilen sie diesem ihre Ein- und Ausgänge (IOs) mit, welche vom Server gespeichert werden. Zur Verbindung dieser virtuellen IOs waren Logikstrukturen gedacht. Diese enthalten auch wieder Ein- und Ausgänge, sowie Logikelemente, welche vom Benutzer über einen Editor zusammengestellt werden können. Sämtliche Elemente, also Eingänge, Ausgänge und Logikelemente können schließlich über den Editor logisch verbunden werden. Die dadurch entstandenen Strukturen stellen Vorlagen dar, von welchen nun Instanzen erzeugt werden können. Diese enthalten nun die definierten IOs, welche mit den IOs der Geräte verbunden werden können.

Das ganze System wurde mit der Zeit Schritt für Schritt erweitert. Eine Erweiterung stellt die Möglichkeit dar, instanzabhängige Variablen einzufügen. Während es schon von Beginn an möglich war Konstanten in die Struktur zu integrieren, welche für alle Instanzen einer Struktur gleich sind, so ist es damit möglich Konstanten zu definieren, welche für jede Instanz einzeln einen Wert erhalten.

Eine andere Erweiterung ist die Möglichkeit, eigene Logikelemente programmieren und als Plug-In integrieren zu können. Beispiele dafür sind Plug-Ins für Alexa, sowie ein Plug-In für globale Variablen. Damit ist es möglich Konstanten zu definieren, welche Struktur- und Instanzübergreifend verwendet werden können.

Mit der stetigen Erweiterung des Systems wurde für jede Möglichkeit die verschiedenen IOs zu verbinden jeweils eigener Code und passende Nutzerinterfaces erstellt. Daher existieren mehrere Quellcodebereiche, die praktisch die gleichen Aufgaben erfüllen, jedoch alle leicht unterschiedlich sind. Dabei ist jedoch immernoch die starre Struktur Eingang-Logik-Ausgang vorhanden.

Alte Systemstruktur: Alle Module sind direkt verbunden

Das Ziel der Überarbeitung ist es daher, den gesamten Prozess des Verbindens zu vereinheitlichen. Dadurch soll die Menge des Quellcodes reduziert und der Prozess flexibler gestaltet werden.

Neue Struktur

Als Lösung verwende ich einheitliche Datenpunkte „DataNodes“. Jeder Ein- und Ausgang im System erstellt nun für sich ein DataNode. Die DataNodes werden global verwaltet und können über ein einheitliches Interface verbunden werden. Daher bezeichne ich diese Systemstruktur als „Unified Node Architecture“ („UNA“).

Der Vorteil von UNA besteht darin, dass die verschiedenen Module (Logikmodul, Gerätemodul), welche bisher hart über den Quellcode verbunden wurden, nun als Plug-Ins ausgelegt werden können, welche ihre IOs flexibel registrieren. Weiterhin können einfach zusätzliche Plugins hinzugefügt werden, welche mit den bestehenden Plug-Ins verbunden werden können. Zudem entfällt die starre Eingang-Logik-Augang-Struktur, da nun auch beispielsweise Geräte direkt ohne Logik verknüpft werden können, oder auch Ausgänge von Logikstrukturen als Eingang von weiteren Strukturen genutzt werden können.

Neue Systemstruktur: Die Module sind als Plug-Ins (blau) ausgelegt, die Verbindung erfolgt universell.

Nutzerinterface

Damit die neuen UNA-Nodes auch verbunden werden können, wurde ein neues Form erstellt. Das Verbinden von IOs war bisher ein vergleichsweise unübersichtlicher Prozess. Das verwendete Form war für die vier Kombinationen von Ein- und Ausgängen aus Logik- und Gerätesicht ausgelegt.

-    Eingang aus Logiksicht
-    Eingang aus Gerätesicht
-    Ausgang aus Logiksicht
-    Ausgang aus Gerätesicht

Für jede Variante war eigener Code vorhanden, welcher je Anwendung ausgewählt wurde. Das führte leider zu viel und zu unübersichtlichen Code, sowie zu einem unübersichtlichen Form.

Altes Verbindungsform:
Anzeige vorhandener Verbindungen

Altes Verbindungsform:
Auswahl möglicher Geräte

Altes Verbindungsform:
Erstellen einer Verbindung

Aus diesem Grund bin ich froh, dieses Verbindungsform durch ein neues ersetzen zu können. Da es nun nur noch DataNodes gibt, gestaltet sich das neue Form übersichtlicher. Es besteht aus zwei (TreeView-)Listen, welche alle existierenden Nodes anzeigen. Dabei wird unterschieden, ob ein Node zum Lesen oder zum Schreiben gedacht ist. Generell können alle Schreib-Nodes auch gelesen werden, jedoch nicht anders herum. Entsprechend dieser Information erscheint das Node auf der linken und/oder der rechten Seite.

Auf beiden Seiten können Nodes ausgewählt werden (türkis im Bild). Entsprechend wird die jeweils andere Liste nach Kompatibilität mit dem gewählten Node gefiltert. Gleichzeitig werden bereits verbundene Nodes farblich (grün im Bild) hervorgehoben. Ist auf beiden Seiten ein Node ausgewählt, so können diese über Buttons verbunden oder getrennt werden.

Neues Verbindungsform für UNA-Nodes

Möglicherweise ist dem ein oder anderen beim Betrachten des Bildes aufgefallen, dass sich dieses im Design von allen anderen Forms unterscheidet, die ich bisher in diesem und in anderen Einträgen gepostet habe. Dies ist darin begründet, dass ich dieses Form erstmals mit WPF („Windows-Presentation-Foundation“) erstellt und programmiert habe, während es sich bei allen anderen Forms um Windows-Forms handelt. Darauf möchte ich an dieser Stelle jedoch nicht näher eingehen.

Nutzerinterface-PlugIns

Neben der Neuerstellung des Verbindungs-Forms ist es durch die Umarbeitung des Geräte-Handlers und des Logik-Handlers zu serverseitigen Plug-Ins parallel nötig, die jeweiligen Bereiche in der Bedienoberfläche zu überarbeiten. Diese Module waren bisher fest in die Software integriert und konnten über einen Kommunikations-Kern (UI-Core) entsprechende Funktionen auf dem Server auslösen und Daten abrufen.

Alte Kommunikationsstruktur mit direkten Verbindungen

Da die Module serverseitig nun Plug-Ins sind, kann der Connection-Handler auf Serverseite eintreffende Requests nicht mehr einfach an die Module weitergeben. Daher habe ich die Module auf Client-Seite ebenfalls in Plug-Ins ausgelagert. Zur Kommunikation können diese nun Requests an einen Plugin-Handler weiterreichen. Dieser verpackt die Anfrage und schickt sie an den Server. Der Connection-Handler kann die Anfrage nun an den Plugin-Handler übergeben. Dieser entpackt die Anfrage wieder und sucht anhand einer angehängten Plug-In-ID  ein passendes Plug-In. Diesem übergibt er die Anfrage, welche dort verarbeitet wird.

Neue Kommunikationsstruktur mit Plug-Ins (blau)

Da die Umstrukturierung nun abgeschlossen ist, überlege ich aktuell, an welchen Stellen das System weiter ausgebaut und verbessert werden kann. Gleichzeitig sind bei mir weitere Geräte eingetroffen, die ich gern in das System einbinden möchte. Weiterhin prüfe ich derzeit, ob das System bereits weit genug entwickelt ist, um es als Anwendung oder als Quellcode auf GitHub zu veröffentlichen.

Über all diese Themen werde ich jedoch hier berichten, wenn die Zeit gekommen ist. Bis dahin bleibt mir nur, mich fürs Lesen zu bedanken und mich für heute zu verabschieden.

Vielen Dank!

Sonoff S26

Hallo zusammen,

heute erreichte mich ein weiteres Päckchen aus China, welches zwei Sonoff S26 (F) enthielt. Dabei handelt es sich um schaltbare Zwischenstecker, welche per WLAN kommunizieren. Die Geräte kommen in einer einfach gehaltenen Pappbox, welche - wie bei allen anderen Sonoff-Geräten auch - nicht viel größer ist als die Geräte selbst.

Sonoff S26 in Originalverpackung

Sonoff S26 Vorder- und Rückansicht

Da ich nicht die Original-Firmware verwenden möchte, habe ich zunächst ein Gerät geöffnet. Dazu müssen einfach drei Schrauben auf der Rückseite entfernt werden. Dadurch lässt sich die Front abnehmen. Anschließend kann der TypF-Aufsatz abgenommen werden, sodass die blanken Kontakte sichtbar sind.

Sonoff S26 offen

Sonoff S26 mit Typ-F Einsatz

Sonoff S26 ohne Typ-F Einsatz

Als nächstes lässt sich die Rückseite abnehmen. Übrig bleibt dann nur noch die Platine und der Typ-F Stecker. Beim Betrachten der Platine fällt auf, dass der verbaute ESP8266 auf einer eigenen Platine untergebracht wurde. Leider fallen deswegen die Kontakte zum Flashen des ESP sehr klein aus und es lassen sich auch keine Stiftleisten anlöten.

Unterseite Platine Sonoff S26

Seitenansicht Platine Sonoff S26 mit Platine für ESP8266

Oberseite Platine Sonoff S26

Da der S26 die gleichen Pins wie der Standard-Sonoff zu verwenden scheint, konnte ich das dafür geschriebene Programm übernehmen, lediglich der Name des Gerätetyps musste angepasst werden. Auch die Parameter des verwendeten ESP8266 sind die gleichen wie beim Standard-Sonoff (1MB Flash). Als problematisch gestaltet sich das Flashen des Programms auf den S26. Nach verschiedenen Versuchen mit gebogenen Stiften als Federelemente habe ich letztendlich doch zum Lötkolben gegriffen und kurze Drähte angelötet.

Drähte zum Flashen des Sonoff S26

Das Flashen ist nun unproblematisch. Allerdings müssen diese Drähte nun bei jedem neuen Gerät erneut angebracht werden. Schöner wäre ein Adapter mit Federkontakten gewesen.

Letztendlich habe ich den S26 natürlich auch noch ausprobiert. Die Funktionen sind dieselben wie beim Standard-Sonoff. Als einziger Unterschied gibt es beim S26 zwei LEDs statt einer (blauen), welche einen Ring um den Taster an der Frontseite beleuchten. Die zusätzliche (rote) LED zeigt den Status des Relays an und ist daher fest mit diesem verbunden.

Die schaltbare Leistung des Gerätes ist mit 2200W (entspricht etwa 230V/10A) angegeben, die verwendeten Leitungen scheinen dafür auch gut dimensioniert zu sein. Beim Standard-Sonoff wäre ich dagegen mit einer solchen Leistung vorsichtig. Ein weiterer Vorteil gegenüber dem Standard-Sonoff ist das Vorhandensein eine Schutzkontaktes. Diese kann zwar beim Standard-Sonoff über eine dritte Ader, welche am Gerät vorbei geführt wird, realisiert werden, die hier verwendete Lösung ist aber natürlich besser.

Damit möchte ich mich auch für heute schon wieder verabschieden. Im nächsten Post werde ich voraussichlicht über die Umstrukturierung meines IoT-Systems berichten, da diese gut voranschreitet.

Markus