Spannungsregler

Hallo zusammen,

in meinem heutigen Beitrag möchte ich über die Energie-/Spannungsversorgung von Smart-Home-Geräten sprechen. Die meisten dieser Geräte benötigen intern eine Spannung von 3.3V oder 5V. Je nach Modell wird diese Spannung über ein integriertes Netzteil erzeugt oder extern als Niederspannung zugeführt. In letzterem Fall beträgt die zugeführte Spannung abhängig vom Einsatzzweck oft 5V oder 12V. Entsprechend muss die zugeführte Spannung auf die benötigte Versorgungsspannung heruntertransformiert werden.

Als Beispiel möchte ich einen meiner RGB-Controller aufführen. Dieser steuert ein 12V RGB-LED-Band, weswegen sich hier ein 12V-Netzteil anbietet. Die dadurch zur Verfügung gestellten 12V sollen gleichzeitig für die Versorgung des Controllers verwendet werden. Intern habe ich deswegen zwei Spannungsregler verbaut. Dabei handelt es sich um einen Linearregler vom Typ LM7805. Dieser erzeugt aus den gegebenen 12V zunächst 5V. Daran schließt sich ein Low-Dropout Linearregler vom Typ LM1117-3.3 an, welcher aus den 5V nun 3.3V erzeugt. Beide Spannungen werden intern für verschiedene Bauteile benötigt.

Aufbau des RGB-Controllers. Rechts oben im Bild befinden sich die beiden Spannungsregler.

Bei beiden Spannungsreglern handelt es sich um lineare Längsregler. Diese haben den Nachteil, dass sie eine hohe Verlustleistung aufweisen. Dies ist darauf zurückzuführen, dass die Ausgangsspannung dadurch erzeugt wird, indem sie die Spannungsdifferenz zwischen Eingangs- und Ausgangsspannung in Wärme umwandeln. Dabei ergibt sich die entstehende Wärmeverlustleistung aus der Multiplikation der Spannungsdifferenz mit dem fließenden Strom. Dieser ist auf Eingangs- und Ausgangsseite nahezu identisch. Praktisch heist das daher, dass die Wärmeverluste sowohl linear mit der Spannungsdifferenz, als auch linear mit dem Strom skalieren.

Soll nun also ein ESP8266 über die genannte Konfiguration aus 12V versorgt werden, so ergibt sich bei einem angenommenen Strombedarf von 100mA eine Wärmeverlustleistung von (12V-3.3V) * 0.1A = 0.87W. Gleichzeitig liegt die tatsächlich benötigte Leistung des ESP bei grade einmal 3.3V * 0.1A = 0.33W. Es wird also mehr als das 2.5-fache an Leistung zur Versorgung als zum Betrieb benötigt. Für den Anwender ergeben sich daraus zwei Schlussfolgerungen: Erstens eine dauerhafte elektrische 0,87W-Heizung und zweitens jährliche (unnötige) Stromkosten von 2.30€ pro Jahr (30ct/kWh).

Glücklicherweise gibt es eine Alternative zu Linearreglern in Form von Schaltreglern (auch "DC/DC-Wandler" oder "Step-Down Converter"). Deren Wirkungsweise unterscheidet sich grundlegend, sodass sie wesentlich effizienter arbeiten. Anstatt die Spannungsdifferenz in Wärme umzuwandeln, schalten sie die Eingangsspannung mit einer hohen Frequenz ein und wieder aus. Abhängig von dem zeitlichen Verhältnis zwischen ein und aus ("Tastverhältnis") ergibt sich im Durchschnitt die benötigte Ausgangsspannung. Dieses Verfahren wird als PWM ("Pulsweitenmodulation") bezeichnet. Dies hat jedoch den Nachteil, das die Ausgangsspannung unsauber ist. Daher wird sie nach dem Schalten noch mit Hilfe von Spulen und Kondensatoren geglättet, um eine annähernd konstante Spannung zu erzeugen. Trotzdem ist dies ein Punkt der beachtet werden muss, da sich Schaltregler dadurch nicht zur Verwendung in frequenzkritischen Anwendungen, wie zum Beispiel in der Audiotechnik, eignen.

Allerdings sind auch Schaltregler nicht Verlustfrei, da Energie zur Versorgung des Reglers benötigt wird. Ich habe mich nun gefragt, wieviel Energie mit dem Ersatz von Linearreglern durch Schaltregler gespart werden kann. Deswegen habe ich mir online DC/DC-Wandler als Modul des Typs HW-613 besorgt. Leider konnte ich keine Angabe finden, welcher Reglerchip auf diesem verbaut ist, auf Grund der Aufschrift vermute ich jedoch das Modell MP2315. Die Module können bis zu 3A Strom zur Verfügung stellen. Dabei unterstützen sie einen Eingangsbereich von 4.5V-24V und können eine beliebige Spannung ab 0.8V bis zur Versorgungsspannung zur Verfügung stellen. Die Ausgangsspannung kann dabei über ein Potentiometer auf der Oberseite oder über Lötbrücken auf der Rückseite eingestellt werden.

DC/DC-Wandlermodul HW-613.

Zum Vergleich der Regler habe ich die drei Regler LM7805, LM1117-3.3 und HW-613 in einem Versuch durchgemessen. Dafür habe ich jeden Regler mit einem einstellbaren Widerstand belastet und somit verschiedene Lastströme erzeugt. Dabei habe ich die Eingangs- und Ausgangsspannung, sowie den Eingangs- und Ausgangsstrom des Reglers gemessen. Die Messungen der beiden Linearregler musste ich bei 200mA abbrechen, da einerseits die Regler bereits beachtlich warm wurden, andererseits mein Messgerät bei der gewünschten Auflösung maximal 200mA messen kann. Dadurch ergeben sich folgende Diagramme für den Wirkungsgrad und die Verlustleistung.

Verlustleistung der verschiedenen Regler in Abhängigkeit vom Ausgangsstrom.

Wirkungsgrad der verschiedenen Regler in Abhängigkeit vom Ausgangsstrom.

Mit den ermittelten Werten wollte ich nun wissen, wieviel Verlustleistung und Geld damit nun theoretisch gespart werden kann. Dafür gehe ich wieder davon aus, dass 100mA bei 3.3V benötigt werden. Bei der Kombination der zwei Linearregler ergibt sich mit den gemessenen Werten eine Verlustleistung von 0.965W (2.53€/Jahr). Wird nun der LM7805 durch ein DC/DC-Wandler ersetzt, veringern sich die Verluste auf 0.287W (0.72€/Jahr). Wird nun auch der LM1117-3.3 ersetzt, so reduzieren sich die Verluste auf 0.096W (0.25€/Jahr). Die Verluste wurden dadurch also auf ein Zehntel des ursprünglichen Wertes verringert. Bei den Kosten von etwa 40ct pro DC/DC-Wandler rentiert sich der Ersatz daher bereits nach knapp zwei Monaten.

Dies sind jedoch nur theoretische Werte. Dabei ist beispielsweise nicht beinhaltet, dass das verwendete Netzteil auch noch Verluste aufweist. Deswegen habe ich den LM7805 meines RGB-Controllers ersetzt und die Stromaufnahme des Netzteils vorher und nachher gemessen. Dadurch ergeben sich die folgenden beiden Abbildungen.

Stromaufnahme vor dem Umbau

Stromaufnahme nach dem Umbau

Dazu muss gesagt werden, dass die Stromaufnahme Schwankungen unterliegt. Im Durchschnitt betrug die Aufnahme vorher 21mA und nachher 17.5mA. Das klingt zunächst nicht viel, macht aber bei 230V Netzspannung einen Leistungsunterschied zwischen 4.83W (12.69€/Jahr) und 4.025W (10.58€/Jahr) und damit einer Differenz von 0.805W (2.11€/Jahr). Der Unterschied ist also größer, als durch die theoretische Betrachtung vorhergesagt. Leider habe ich den LM1117-3.3 nicht auch gleich noch mit ausgetauscht, sodass ich keine Angabe machen kann, wieviel der Austausch des zweiten Reglers noch bringt. Dies möchte ich jedoch demnächst nachholen. Möglicherweise tritt jedoch keine massive Änderung auf, da die Hauptverluste durch das Netzteil verursacht werden.

Zum Abschluss stellt sich nun noch die Frage, für welche Geräte denn ein Umbau möglich ist. Dies hängt hauptsächlich davon ab, wie die Spannungsversorgung aufgebaut ist. Ein gutes Beispiel eine Gerätes (bzw. Modules), welches sich für den Umbau eignet ist der Arduino. Bei der Versorung über die Hohlsteckerbuchse wird die Eingangsspannung (12V-7V) über einen Linearregler (LM1117-5) geregelt. Diesen habe ich durch einen DC/DC-Wandler ersetzt. Der Arduino läuft dabei ohne Probleme, leider habe ich dazu aber keine Leistungsmessungen gemacht. Ich kann jedoch sagen, dass die gefühlte Temperatur in diesem Bereich drastisch abgenommen hat.

Arduino mit ersetztem Spannungsregler

Damit verabschiede ich mich bis zum nächsten Beitrag.

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!