Dyson - es muss nicht immer der Akku sein

 

Immer wieder werde ich angesprochen, mir fehlerbehaftete, kabellose Staubsauggeräte anzusehen. Dabei sind die modernen Geräte nach dem Zyklon Prinzip am häufigsten vertreten. Meist sind es die Akkus, deren BMS (Batterie-Management-System) dem Akku den "Garaus" macht, indem der im BMS verbaute Microcontroller ein "disabled" Flag setzt und den Akku unbrauchbar macht. Der Grund dafür ist meist ein defekt einer oder mehrerer Zellen. Genauer gesagt ist es die Balance der Zellen, die nicht mehr gegeben ist oder erreicht wird. Bei vielen Akkusystemen moderner kabelloser Geräte kommen Lithium-Ionen Zellen der Baugröße 18650 zum Einsatz. (zylindrische Zellen mit 18mm Durchmesser und 65mm Länge, einer Nominalspannung von 3.7V und einer Kapazität von durchschnittlich zwei Ah) Ein defekter oder ein, durch das BMS abgeschalteter Akku, lässt sich dann nicht mehr Laden, der Handstaubsauger schaltet nicht mehr ein, wenn der der Trigger gedrückt wird und es gibt je nach Bauart und Modell Blinksignale der im Akku verbauten Leuchtdioden. Zu diesen Fehlerbildern gibt es einige Ansätze, erfolgreiche Reparaturen durchzuführen. Zum einen können aufgrund des Alters des Gerätes Zellen defekt sein, die dann eine viel zu geringe oder gar keine Zellspannung mehr abgeben. Hier ist ein Tausch der einzelnen, betroffenen Zellen dann möglich - wenn auch nicht sinnvoll. Man kann natürlich auch alle Zellen erneuern - so man sich die Arbeit und den Umgang mit dem Punktschweißgerät und dem Nickelband zutraut. Ich hatte aber auch schon einige Geräte am Tisch, dessen Akkus auch keine Ausgangsspannung mehr freischalteten, obwohl die einzelnen Zellen und deren Leerlaufspannung absolut in Ordnung und die Balance untereinander gegeben war.  Der einfachste Lösungsansatz war dabei eine genauere Untersuchung der BMS Platine. Ein einfacher Reset des verbauten Microcontrollers erweckte den Akku schon häufig wieder zum Leben. (Hier ist natürlich vorausgesetzt, dass man am Board ein wenig Reverse Engineering betreibt und sich zumindest die Type des Microcontrollers und dessen Beschaltung herauszeichnet) Bei Recherchen im Netz bin ich sogar auf ein GitHub Projekt gestoßen, bei dem jemand eine eigene Firmware für das BMS Board einiger Dyson Akkus entwickelt hat.

 

Wie im Titel des Beitrags beschrieben, muss es aber nicht immer an einem defekten Akku liegen, dass der kleine Zyklon nicht mehr tobt. In diesem Fall hat sich folgendes Verhalten gezeigt:

Beim Betätigen des Triggers blinkt die LED am Dyson DC34 und der Motor dreht nicht.  Steckt man das Ladegerät an den Akku des Saugers an, so leuchtet die LED am Netzteil und es sieht alles nach einem, wie in der Bedienungsleitung beschriebenen Ladevorgang aus.

Dyson DC34 am Ladegerät - noch ist die LED an

 

Soweit so gut. Doch schon nach einigen Minuten erlischt die LED am Ladegerät und man bekommt signalisiert, dass der Akku vollgeladen ist. Dem ist aber nicht so. Wenn der Trigger betätigt wird, so passiert nichts außer, dass die LED am Dyson zu blinken beginnt. Der Motor bleibt still. Also war mein erster Verdacht - wie so oft - der Akku ist defekt. Also habe ich zuerst einmal den Akku demontiert und die Spannungen der 18650er Zellen gemessen. Die waren jedoch alle ok – also einem Bereich um die 3.5V und vor allem gab es auch unter den Zellen keine großen Abweichungen. Sie waren somit auch gut balanciert, aber eben leer. Im nächsten Schritt habe ich dann das BMS Board genauer betrachtet und den darauf befindlichen Mikrocontroller resettet. Ein erneuter Ladeversuch brachte aber keine Änderungen und LED am Ladegerät erlosch wieder nach einigen Minuten.

So war der nächste Schritt, den Akku mit einem Labornetzteil zu laden und dann messen wie sich das BMS und die Zellen verhalten. Das Modell DC34 ist eines der „älteren“ Geräte. Hier wurden auf der DC Seite noch zwei Spannungen benötigt. 16.75V DC und 24.35V DC werden über den dreipoligen Ladestecker geliefert. Da der Akku ja schon geöffnet war, war es ein Leichtes, die beiden Spannungen anzulegen. Und siehe da, das Laden der Zellen klappte. Nach einigen Minuten am Labornetzteil hatte der Dyson Akku wieder genug Energie um den Sauger zu betreiben. Somit konnte ich den Akku als Defekt ausschließen.

Der nächste Ansatz war nun, das Ladegerät zu untersuchen. Und um das Ergebnis vorweg zu nehmen – genau das war das Problem. Um hier die Ursache zu finden, entschloss ich mich, das Ladegerät zu öffnen. Aufgrund der Nachhaltigkeit der heutigen Konsumentenprodukte ist das Teil ganz einfach zu öffnen – lediglich zwei Kreuzschlitzschrauben halten die Gehäuseschalen zusammen und nach dem Lösen dieser, fallen die Teile einfach auseinander und die Platine liegt auf dem Tisch… - schön wär´s. Leider ist kein Hersteller daran interessiert, dass seine defekten Teile einfach zu reparieren sind. So ist das Gehäuse auch nicht verschraubt. Denn Schrauben sind ja auch teuer. Die Kunststoffteile sind natürlich verschweißt bzw. verklebt und nur mit einer Trennscheibe am Dremel zu lösen. Gesagt – getan. 

 

Nach dem Öffnen und Freilegen der Netzteilplatine habe ich die DC-Ausgänge mit Lasten, die der aufgedruckten Nominalleistung entsprechen, belastet und gleichzeitig die Spannungen gemessen. Diese fallen unter Last um ein paar Millivolt ab, aber sind zu Anfang auch vorhanden. Dann passierte aber folgendes: Nach ein paar Minuten Betrieb fielen die Spannungen auf 0V ab und die LED leuchtete nicht mehr. Aha! Also kurz von der Netzspannung getrennt und wieder eingesteckt. Doch die LED blieb dunkel und es gab keine Ausgangsspannung. Erst nach einigen Minuten ohne AC-Versorgung fuhr das „Schaltnetzteil“ wieder hoch. Unter Last ließ sich das Verhalten immer nachvollziehen. Zwei bis fünf Minuten unter Last und das Netzteil schaltet ab. Bei einem Versuch ohne Ausgangsbelastung passierte lange nichts und die Spannungen standen stabil. Erst geschätzte dreißig Minuten später war wieder Ende. Nach einer genaueren Untersuchung ist mir dann aufgefallen, dass die primäre Ansteuerung des Wandlers auf einmal nicht mehr vorhanden war. Der Enable/Undervoltage Pin des Controller IC wurde aber im Ausschaltmoment über den Optokoppler Transistor nicht aktiviert und trotzdem war Schluss. 

DC34 Ladegerät mit Lastwiderständen

 

Ein kurzes Berühren des Controller ICs mit dem Finger und das darauffolgende Wahrnehmen von unangenehmer Hitze und Schmerz eröffnete mir eine neue Fehlerursache. Das Teil wird thermisch zu heiß und es könnte ja eine „thermal-Protection“ geben. Bingo. Bei dem Controller IC handelt es sich um einen TNY278PN der TinySwitch Family von „power integrations“, einem IC der den Leistungs Mosfet und die Ansteuerelektronik (den PWM Generator) in einem Chip vereint hat. Und sieht man sich das Datenblatt an, dann ist folgendes zu lesen:

Auszug aus dem Datenblatt des TNY

 

Somit hat es etwas mit der Erwärmung des IC´s, bzw. dessen thermischer Belastung zu tun, die sich anscheinend nicht mehr im Sollbereich bewegt. Glücklicherweise schaltet der Chip durch seine eingebaute Sicherheitstechnik ab und nicht die Sicherung, die auslöst, wenn der Mosfet stirbt und dauerhaft niederohmig wird. Das Abschalten des Controller ICs auch bei Nichtbelastung war ein weiteres Indiz, dass der Chip nicht mehr in Ordnung ist. Also habe ich den IC erneuert und das Board wieder in Betrieb genommen. Die LED und die Ausgangsspannungen waren sofort wieder da. Nach 20 Minuten Dauerbetrieb mit angeschlossenen Lastwiderständen war immer noch alles OK. Auch die Temperatur des Controller IC war durchaus im erträglichen Bereich.

 

alt vs. neu

Also konnte ich davon ausgehen, dass das Ladegerät wieder ok war. Vor dem Verkleben der Gehäuseschalen bekam ein Gehäuseteil noch ein Tuning in Form von vier Lüftungslöchern. So gibt es zumindest die Möglichkeit, die thermische Abwärme im Netzteil abzuführen.

Netzteil mit Tuning :D

Keysight DSO-X 2012A Oszilloskop stirbt im Standby – Netzteiltausch

In einem alten Beitrag aus dem Jahr 2019 habe ich über Oszilloskope des Herstellers Keysight und deren Problem mit einem plötzlichen Ausfall berichtet. (siehe Link). Es ging damals darum, dass die Oszilloskope plötzlich ihren Dienst verweigerten - manchmal auch mit einem Knall und anschließendem Geruch nach "Strom". Oder es passierte einfach gar nichts nach dem Einschalten. Der Grund dafür war und ist immer wieder der Ausfall des verbauten 12VDC Netzteils CCH0123F1-Z03A. Das Oszilloskop ist so konstruiert, dass das Netzteil bei ausgeschaltetem "Hauptschalter" des Oszilloskops trotzdem am Netz hängt und im Standby-Modus betrieben wird. Der an der Frontseite des Gerätes befindliche Druckschalter schaltet das Netzteil dann in den PowerON Modus und die 12V Leistung ein. Wenn die Geräte in den Labors permanent an bestromten Steckdosen hängen, verwundert es auch nicht, dass die Geräte schneller altern, als die guten alten Kisten mit den Kathodenstrahlröhren. Die Teile, die der permanenten Stromversorgung durch thermische Dauerlast zu Opfer fallen, habe ich, sowie auch den Reparaturaufwand im damaligen Beitrag dargestellt. Von Seiten der Vertriebsfirmen ist auch ein Nachbestellen oder eine Ersatzlieferung von neuen Netzteilen nicht vorgesehen oder gewünscht. Wenn die Geräte innerhalb der Garantie- Gewährleistungszeit ausfallen sollten, ist der Austausch durch den Hersteller kein Problem. Fallen die Geräte aber erst aus, wenn sie schon ein paar Jahre im Labor oder der Werkstatt verweilen (dabei spielt es aber keine Rolle ob sie jeden Tag in Betrieb sind, oder eben nur angeschlossen und ausgeschaltet herumstehen), so läuft ein üblicher Reparatur- Serviceprozess beim Hersteller. Da sind dann auch die ordentlichen Tarife für den Service von Messtechnik zu bezahlen.

Im Bild oben: "neues Meanwell Powersupply" unten: "origales Lineage Power"

Die Netzteile sind, wie im alten Bericht beschrieben, recht gut zu reparieren. Allerdings ist die Reparatur auch ziemlich zeitaufwendig. Schneller geht es natürlich, wenn ein neues Netzteil eingebaut wird. Die Vertriebsfirmen der Keysight Oszilloskope bieten leider keinen Ersatzteilsupport an und einen direkten Lieferanten des original verbauten Lineage Power Netzteils habe nicht finden können. Es gibt aber auch eine andere Alternative: Im Forum des EEV-Blogs haben einige User alternative Netzteile gefunden, die in die DSO-X Oszilloskope passen. Ein passendes Modell ist das RPSG-160-12 von Meanwell. Es handelt sich dabei um ein 12V 160W Powersupply. Die Bezeichnung "G" in RPSG deutet darauf hin, dass auch ein 5V Standby-Supply vorhanden ist. Und genau diese Funktion benötigt auch das DSO-X. Denn wie schon zuvor beschrieben, ist der Frontschalter am Oszi nicht dazu gedacht, die Primärseite der Netzversorgung zu trennen, sondern lediglich eine Leitung am DC-Niedervoltstecker gegen Masse zu schalten. Diese Leitung steuert im Netzteil den "PowerON-Pin".

Mechanisch passt das Meanwell beinahe auf die Montagehalterungen des DSO-X. "Beinahe" bedeutet, dass der Abstand der Befestigungslöcher der Längsseite am Powersupply um etwa einen Millimeter weiter auseinander liegt, als die Befestigungsbolzen am Chassis des Oszilloskops. Das lässt sich aber mit einer kleinen Rundfeile oder einem 4mm Bohrer schnell anpassen. Jetzt kann das Meanwell Powersupply mit den originalen Torx Schrauben am Oszi Chassis befestigt werden. Die Steckverbindung für die AC-Versorgung von der OSZI-Platine zum Netzteil kann direkt vom alten Netzteil übernommen werden.

Pinout der Meanwell Steckerleisten

Die 12V Spannungsversogung am CN2 des Netzteils liegt an den Pins 1,2,3,4 (+12V) und 5,6,7,8 (GND) an. Die Verbindungsleitung zum Oszi ins entsprechend anzupassen.

DC12V Ausgänge an CN2

 

Im Bild unten sind die Pins der Steckerleiste am Oszi beschriftet dargestellt.

DC12V Eingang ins Oszilloskop

Ich habe die Drähte passend umgepinnt und den Stecker wie unten dargestellt mit dem Powersupply verbunden.

 

Die Hauptenergieversorgung zum Oszilloskop ist jetzt hergestellt. Es fehlt nur noch die "Einschaltleitung" (PowerOn). Hierzu habe ich den 7. Pin (GND) und den 9.Pin(Switch) aus dem alten Stecker gelöst und direkt auf dem Standby Board des Netzteils angelötet. Der Draht am untersten Pin des Standby Boards ist das Signal "PowerOn" und der darüber ist GND. Somit kann das Netzteil mit dem frontseitigen Einschalter am Oszilloskop hochgefahren werden.

"Steuerleitungen" für das PowerOn des Netzteils

Gesamtansicht der Verkabelung

 

 

Nach einem kurzen Funktionstest und Überprüfen der Spannung (kann ggf. auch an dem Trimmpoti am Netzteil korrigiert werden) ist der Umbau abgeschlossen und der Zusammenbau kann wieder erfolgen.

 

 

EVU Smartmeter mit ESP32 auslesen und Daten per MQTT senden

So nach und nach bringe ich viele meiner Smarthome Komponenten auf einen gemeinsamen Standard. Dabei habe ich mich entschieden, sämtliche Geräte über einen NodeRed Server zusammen zu führen. Auch das HomeMatic System kommuniziert mit NodeRed. Hier übergebe ich unter anderen auch die Messwerte des EVU-Zählers (bei mir ist ein Siemens IM350 Smartmeter verbaut) an die HomeMatic CCU. Dies geschieht wie schon einem früheren Beitrag erwähnt, über die LED-Impulsschnittstelle (1000 Impulse/kWh). Hierzu wird einfach ein Fototransistor über der LED am Zähler angebracht, der die Blinkimpulse der LED erkennt und in der Zählersensor-Sendeeinheit HM-ES-TX-WM in die Momentanleistung umrechnet und über die Zeit integriert und die Daten dann an die CCU weitersendet. Das funktioniert an sich ganz gut. Nur die Aktualisierungsrate (im Minutenbereich) ist mir zu lange. Auch scheint der Fototransistor immer wieder auf das Streulicht der benachbarten LED (diese zeigt die Blindleistung in 1000 Impulse/kvarh an) zu reagieren. So entstehen Abweichungen zwischen der Zählung über den HomeMatic Sensor und den direkt am Zähler abgelesenen Werten.

Das geht auf jeden Fall genauer. Wenn man sich den IM350 Smartmeter Zähler im Detail ansieht, bzw. das Manual durchliest, so stellt man schnell fest, dass er eine sog. "Kundenschnittstelle" besitzt. Diese Kundenschnittstelle stellt einige Messdaten über eine galvanisch getrennte Datenleitung im Sekundentakt zur Verfügung. Dazu gehören unter anderen die momentane Wirkleistung in beiden Richtungen, sowie die Zählerstände von Wirk- und Blindleistung in Bezugs- und Einspeiserichtung. Also perfekte Ausgangbedingungen, um den HomeMatic Zählersensor durch eine eigene Konstruktion zu ersetzen. Nach ein wenig Internetrecherche habe ich schnell erkannt, dass ich nicht der Einzige bin, der sich mit genau dieser Thematik beschäftigt. Die Daten der Kundenschnittstelle purzeln nach Anforderung über eine Daten-Request Leitung mit einer Geschwindigkeit von 115kbaud heraus. Sie sind allerdings verschlüsselt, und nicht direkt lesbar. Um den 16 Byte langen Entschlüsselung Key zu erhalten, muss der Energieversorger konsultiert werden. Der Schlüssel ist an die Seriennummer des Smartmeters gebunden und für jedes Smartmeter individuell. Nach einigem Telefonieren mit meinen Kärntner Energieversorger wurde mir der Key-Code per Mail zugesandt. Im nächsten Schritt testete ich mit einem USB-UART Adapter an einem PC, ob bei korrekter Beschaltung der Schnittstelle auch wirklich Daten aus dem Zähler herauskommen. Dazu habe ich einen RJ11 Stecker auf ein geeignetes 6pol. Kabel gekrimpt und das offene Ende des Kabels entsprechend des Datenblattes des Zählers beschaltet. Dazu ist nicht besonders viel notwendig. Eine 5V Versorgung muss die Schnittstelle aktivieren, ebenso muss auch die Data Request Leitung an 5V geschaltet werden und schon stehen an der Data Out Leitung die Datenpakete an. Es funktioniert übrigens auch mit einer 3V3 Versorgung. Mit einem Terminalprogramm am PC (ich verwende meist putty oder hterm) kann man die verschlüsselten Daten visualisieren.

Jetzt ging es daran, sich zu überlegen, wie die Daten entschlüsselt und aufbereitet werden. Hierzu findet man mit Netz zwei Ansätze:

* über einen RaspberryPi, mit einer Python-Umgebung und einem Python Skript. Die Skripten übernehmen hier den Empfang und die Entschlüsselung der Daten und stellen sie dann auf unterschiedliche Weise zur weiteren Verarbeitung zur Verfügung

* über einen ESP32. Der ESP ist ebenfalls in der Lage eine 128Bit AES Verschlüsselung zu dekodieren und hat noch reichlich Ressourcen um die Daten aufzubereiten und über WiFi zu versenden. Außerdem ist ein ESP für wenig Geld in ausreichender Stückzahl verfügbar. Also habe ich mich für diese Lösung entschieden. Dazu gibt es auf GitHub ein open source Projekt vom User https://github.com/Andre-Schuiki/esphome_im350  in dem er einen ESP32 IM350 Decoder als Basis für eigene Projekte zur Verfügung stellt. Mit seinen Sourcen erhält man einen Decoder der die Zählerdaten im Sekundentakt ausliest und über die USB UART Programmierschnittstelle und auch via Telnet über WiFi ausgibt. Dieses Sourcen habe ich als Basis verwendet. 

Mein Ziel ist es, die aus dem Smartmeter gewonnenen Daten in MQTT Messages zu verpacken und an meinen MQTT Broker zu senden. Ab da ist es dann ein Einfaches, sie in NodeRed und die HomeMatic CCU zu bekommen und dort zu speichern. Also habe ich den Code angepasst.  Dazu wurde die Wifi Verbindung zum Router auf eine statische IP gesetzt. (sind in settings.h zu definieren). Die ausgelesenen Messwerte, sowie die RSSI der WiFi Verbindung, werden jetzt über MQTT Topics zur Verfügung gestellt. (die IP-Adresse zum Broker ist auch in settings.h zu definieren). Wenn man den Code jetzt kompiliert und auf den ESP jagt, dann sollte er sich in das jeweilige Netzwerk einbuchen. Solange der ESP noch auf einem PC-hängt, kann man über die Programmierschnittstelle und ein Terminal auch gleich überprüfen was er tut. Verbindet man jetzt den RJ11 Stecker mit der Kundenschnittstelle des Zählers, dann solle im Display des Zählers im Sekundentakt das Dreieck über der Beschriftung "KU" blinken. Passiert das, dann sollten auch schon im Terminal die Messwerte stehen (vorausgesetzt man hat den KEY vom EVU nicht vergessen in secrets.h einzugeben). Klappt auch das, dann stellt ein Blick auf den MQTT-Broker (mit z. Bsp.: MQTT-Explorer) sicher, dass die Messages auch ankommen. Jetzt kann der ESP vom PC entfernt werden.

Anschlussbelegung

 

ESP32 im "freifliegenden" Testaufbau

 

Ich habe eine sehr einfache Lösung gewählt und des ESP auf einer Lochrasterplatine befestigt. Das 6polige Kabel zum Smartmeter dort angelötet. Auf der Lochrasterplatte finden dann noch die Pull-Up Widerstände und ein NPN Transistor (BC547 etc.) zum Invertieren der Datenpulse Platz. Die Platine habe ich in einem kleinen Kunststoffkästchen untergebracht, dass jetzt lediglich mit einem Kabel an der Kundenschnittstelle und mit einem USB Kabel an einem USB Steckernetzteil angeschlossen ist.

 

 

Der fertige Aufbau sieht dann (bzw. zurzeit) so aus. Die Daten landen im MQTT Broker und NodeRed visualisiert sie und schickt sie auch zur HomeMatic CCU.

so kommen die Daten im MQTT Broker an

 

und können zum Beispiel so in NodeRed verarbeitet werden

wenn jemand an den angepassten Skripten interessiert ist, kann ich die gerne zusenden. Betreffend einer Veröffentlichung auf  GitHub muss ich mich erst informieren welche Lizenzbedingungen betreffend des ursprünglichen Repositorys zu erfüllen sind. Es wird dann hier (public) verfügbar sein:

https://github.com/ingmarsretro/esphome_im350/tree/main/standalone_version_mqtt

 

 

 

Die Wärmepumpe (NEURA) in das Smarthome einbinden

 

Ein Smarthome ist heute keine Seltenheit mehr und sehr weit verbreitet. Es gibt unzählige Systeme am Markt, die das eigene Zuhause "Smart" machen. Die digitalen Sprachassistenten von Google, Amazon und co. in Verbindung mit Smarten Glühlampen zählen zu den einfach und schnell zu installierenden Systemen. Aber es gibt auch komplexe Smart Home Systeme, bei denen in den Hausverteilern Aktoren für jede Lampe und Steckdosen verbaut sind. Die Fenster und Türen sind mit Meldekontakten ausgestattet und sichern das Eigenheim oder melden, wenn einmal auf das Schließen der Fenster nach dem Stoßlüften vergessen wird. Das diese Systeme bei vernünftiger Programmierung auch zur Energieoptimierung beitragen ist selbstverständlich. Auch ich betreibe Smarthome Komponenten unterschiedlichster Hersteller.

 

 

Dazu gehört seit Jahren das HomeMatic System, das sowohl kabelgebunden als auch über das Bidcos-Protokoll mit seinen Aktoren und Sensoren kommuniziert. Das HUE - System von Phillips spricht dabei über ZigBee mit seinen smarten Lampen und Steckdosen. Die Gateways dieser Systeme sind an ein LAN Netzwerk angeschlossen und jedes System bringt seinen eigenen Webserver mit, über den es dann zu steuern und einzustellen ist. Ein Wechselrichter von Photovoltaikanlagen kann seine Daten über unterschiedlichste Schnittstellen (RS485, CAN, RS232) zur Verfügung stellen. Um alle auf eine zentrale Darstellungsebene zu bringen, habe ich mich für das NodeRed System entschieden. Der Dazu notwendige NodeRed Server läuft auf einem Raspberry PI. (Auf der CCU3 mit dem Raspbian Image ist noch genug Platz um den NodeRed Server laufen zu lassen - der ist sogar als eigenes Plugin für die CCU verfügbar und wird "RedMatic" genannt).  Mit dieser Konfiguration lässt sich fast alles im Bereich Homeautomation "erschlagen". Mit ESP32 und Raspberry lassen sich über MQTT (Message Queueing Telemetry Transport) bequem Statusinformationen übertragen. Dies wende ich beispielsweise bei den kleinen Einspeise Wechselrichtern einer Balkon PV-Anlage an, als auch bei den PV-Wechselrichtern einer Offgrid-Anlage. Hier werden die Daten über unterschiedliche Bussysteme im Raspberry oder ESP32 empfangen und in das MQTT-Protokoll umgesetzt. Der MQTT Broker sammelt die Daten der einzelnen Geräte und über NodeRed lassen sie sich dann in eine Datenbank schreiben, im Browser oder am Smartphone visualisieren und auch einfach, je nach Bedarf, im HomeMatic System verarbeiten.

Beispiel eines Smarthomenetzwerks

Somit ist es möglich, nahezu alle Systeme miteinander Smart zu vernetzen und, für mich wichtig auf EINER Plattform zu visualisieren. Ein einziges System fehlte bisher noch. Das ist meine alte Neura Heizungswärmpepumpe. Die Firma Neura ist schon seit einigen Jahren nicht mehr existent und der von "b.i.t." entwickelte auf Webserver "webidalog" wurde nie mehr aktualisiert. Die Wärmepumpe hat also einen Webserver auf einem kleinen mit Linux-Rechner onboard und baut die Webapplikation mit einer uralten Java Version. Für die Bedienung muss am PC eine Java Runtime installiert sein, die nur mit einigen Tricks auf einem aktuellen Windows Rechner läuft (Stichwort: Virtualisierung). Für die Bedienung über ein Smartphone ist eine html - Version mit eingeschränkter Funktionalität verfügbar. Mein Plan war es nun, eine Schnittstelle zu finden, mit der ich die Daten der Wärmepumpe zumindest einmal auslesen kann, um Vorlauf- Rücklauftemperaturen der Fußbodenheizung, Kesseltemperatur, etc. auch in meinem NodeRed System zur Verfügung habe. Da zu dem System aber so gut wie keine Dokumentation zu finden ist und ein Reverse-Engineering ein wenig kritisch ist, wenn das System weiter laufen soll, kam mir folgende Idee:

Mit einem "headles browser" sollte es ja möglich sein, die html-Version der Neura WebDialog Website zu parsen und die relevanten Daten zu finden und über Variablen in MQTT-Topics zu verwandeln. Und hier muss ich einen besonderen Dank an meinen Kollegen Mario Wehr aussprechen, der mir die Softwarestrukur zum parsen der Website gebaut hat. Die Software ist in PHP geschrieben und läuft schlussendlich auf einem Raspberry PI. Hier sind lediglich eine php8-cli runtime und ein paar Module notwendig. Die Software funktioniert so, dass bei jedem Aufruf ein Login auf der Wärmepumpenwebsite ausgeführt wird, danach werden die Daten geparsed und zu MQTT-Broker gesendet. Das kontinuierliche Aufrufen des php-Skriptes habe ich dann einfach mit einem cronjob gelöst, der jede Minute ausgeführt wird.

>sudo crontab -e

und der job sieht dann so aus:

* * * * * sudo php /home/neura2mqtt/neura2mqtt.php -c

(wenn man sich die files  ins  /home/ verzeichnis legt...). Das Projekt habe ich auf github unter:  https://github.com/ingmarsretro/neura2mqtt veröffentlicht.