Es gibt ja einige Leute hier mit MAX! Thermostaten.
Hat jemand etwas ausgefeiltere Konfigurationen des UI über Node-BLUE vorgenommen?
Wie habt ihr den Heizmodus angekoppelt?
Wie habt ihr CONTROL_MODE, VALVE_STATE oder die LOWBAT eingebunden?
Ein Beispiel hier wäre sehr hilfreich.
Vielleicht hat jemand auch schon das bestehende Heizungs-UI-Modul entsprechend erweitert?
Hallo,
ich habe es inzwischen hinbekommen meine MAX! Wandthermostate über die “Klima” Knoten" in node-BLUE in der UI zu visualisieren.
Nur leider passen die Einträge in der UI nicht zu den Einstellungen am Thermostaten.
So entspricht z.B. die Frostschutzfunktion in der UI standardmäßig dem Automatik Modus im MAX!. Und im Automatikmodus sollte es eigentlich möglich sein, die Temperatur zu verstellen.
Also macht der Knoten nicht das was er soll…
Über händische Einträge wie im Grundlagen Thread beschrieben habe ich bislang noch keinen Thermostaten in die UI bekommen. 
Mit Hilfe von function Nodes kann man die MAX! CONTROL_MODES den Anzeigen in der UI aber auch etwas sinnvoller zuordnen.
So bildet der “Komfort” Modus bei mir jetzt den MAX! “Auto-Modus” ab.
“Spar” entspricht dem MAX! “Manuellen Modus” und
“Fostschutz” ist “Urlaub”
Bei CONTROL_MODE 3, also BOOST sind alle Betriebsarten deaktiviert.
Die Darstellung in der GUI kann man bestimmt irgendwie aufbohren.
Am einfachsten wäre ja bestimmt in der defaultRoles.json die Einträge zu erweitern und dann neu zu laden.
Wenn man aber versucht die einzulesen, sind alle Rollen in der Admin_UI weg.
==> buggy
Hab jetzt auch noch mal einen Schalter für “BOOST” eingebaut.
PeerID 44 im Test-Raum im Geschoss sonstiges …
MAX-WT-UI-Flow.zip (1,8 KB)
Ein auf MAX! Thermostate bezogenes Aufbohren des GUI wäre auch mein Ziel.
Momentan sieht man ja nur ein zentrales WT-44 UI Element und die Variablen eines Geräts im Node-Blu Graphen. Wird das dann noch irgendwie kopiert/vervielfältigt?
Hallo,
das ist im Moment natürlich nur 1 Flow. Den müsste ich jetzt für jeden Wandthermostaten kopieren und die peerID’s anpassen.
Mir wäre es natürlich auch am liebsten, wenn das irgendwie eleganter ginge.
Da sehe ich im Moment aber keine Möglichkeit zumal es ja schon am einlesen der Rollen scheitert…
Ich sehe das Ganze gefrickel nur als Workaround um wenigstens die wichigsten Dinge ans Laufen zu bekommen.
Im Grunde müsste man den ganzen “heating” Node analysieren und für MAX! umprogrammieren.
Ohne diese umfassenden Änderungen wird es nicht möglich sein z.B. die Beschriftung in der UI zu korrigieren.
Alles in Allem wird man nicht umhinkommen sich vollständig mit der einzig korrekten und vollständigen homegear Doku zu beschäftigen. Dem Sourcecode.
Für die Teile, die nicht OpenSource sind dürfte das unmöglich werden.
Vielleicht kann man zunächst einmal den ganzen inneren Teil des Flows auch in einen Subflow packen. Aber mit Subflows habe ich mich noch nicht beschäftigt.
Aber es scheitert ja schon an so einfachen Dingen wie dem “mail” Node.
Ich habe bislang immer noch nicht verstanden wie man aus node-BLUE heraus eine Mail versenden können soll.
Da ich Störungsmeldungen aber ohnehin lieber in Signal haben möchte, kann ich auch ohne Mail leben.
Auch Signal Messages waren eine schwere Geburt.
Aus homegear heraus publishe ich jetzt eine Message in einen mosquitto MQTT Server, den ich auf meinem zentralen OpenWrt Router laufen habe.
War dort am einfachsten, damit Zugriff aus verschiedenen VLAN’s möglich ist.
Als Signalbot Server habe ich zunächst einmal habe ich einen neuen LXC Container mit Debian Bullseye auf ProxMox gepackt. Da hinein habe ich das Signal-CLI und die mosquitto-client-tools installiert.
Das Ganze mit einem bash script garniert, welches die homegear messages per subscribe bekommt, sie analysiert und schließlich dem Signal-CLI übergibt.
Dann nur noch schnell einen systemd service gebaut, damit das auch permanent läuft und beim Restart des Signalbot Servers automatisch funktioniert.
Und Hardware wurde auch gemodded. Dazu habe ich aus einem Fensterkontakt den Reed Kontakt ausgebaut und durch ein Kabel ersetzt, welches ich mit dem Störungsausgang (Relaiskontakt) meiner Therme verbunden habe.
Wenn jetzt die Therme aus Störung geht, meldet das der Fensterkontakt quasi als Fenster zu. Den Event fange ich einfach in node-BLUE ab und baue eine MQTT Nachricht. Der Signalbot schickt mir (und meiner Frau) das dann zu.
Funktioniert. Hat mich aber x Stunden Aufwand gekostet.
Größtes Problem bei der ganzen Aktion war wieder einmal fehlende oder unvollstängie oder unverständliche oder nicht auffindbare Doku von homegear.
Die Idee mit dem Subflow ist natürlich Murks.
Der Aufbau der GUI erfolgt quasi in dem Moment in dem man in node-BLUE auf “Implementieren” klickt.
Dabei werden alle Daten aus allen UI Nodes in die GUI übernommen.
Das funktioniert natürlich nur pro device. Und was da im Hintergrund passiert ist mal wieder ein großes Geheimnis…
Ich hätte gewünscht, das die Einrichtung der UI und die Bestückung mit Daten 2 getrennte Dinge wären. Ist es aber nicht …
Jupp, so sieht es aus. Ich nutze mehrere Subflows, um an zentraler Stelle die eigenen Funktionen vorhalten zu können, die dann an vielen (kopierten) Stellen genutzt werden (alle rötlichen Knoten):
flows.zip (3,5 KB)
Hallo,
ich denke das müsste sich noch weiter generalisieren lassen.
Hab ich nicht getestet, stelle ich mir so in etwa vor.
Statt der ganzen Input Nodes könnte man den “HomeGear Event Node” nutzen, und dort auf Gerätevariablen filtern lassen.
Das funktioniert problemlos. Mache ich bei meinen Wandthermostaten auch so.
Im dahinter liegenden Function Node, schaut man dann, zuerst ob die peerID aus dem aktuellen event gleich der Konstanten ist. Wenn gleich, dann verarbeiten sonst abbrechen.
Dann schaut man welche Variable geliefert wurde. Ist es eine der gewünschten, wird verarbeitet, ansonsten die Verarbeitung abgebrochen.
Deine links von de UI-Nodes liegenden Subflows könnten auch noch gleich in diesen Funtion Node integriert werden.
Das ganze packt man in einen SubFlow.
Wenn man die peerID in einer Flow Variablen speichert kann man den ganzen rechten Teil ebenfalls in einem Function Node abwickeln. Den steckt man dann natürlich auch in einen Subflow…
Für die Nutzung des Flows muss man dann nur noch einen Flow bauen, der die peerID als Konstante zuliefert.
Noch ne Anmerkung.
Warum verwendest du so viele globale Variablen?
Man kann doch fast alle Daten bei Bedarf auslesen da HomeGear sie sowieso speichert.
In PHP geht das so:
`// Werte aus homegear auslesen
$cT = $hg->getValue($peerID, 1, “ACTUAL_TEMPERATURE”);
$sT = $hg->getValue($peerID, 1, “SET_TEMPERATURE”);
$cM = $hg->getValue($peerID, 1, “CONTROL_MODE”);
`
Bzgl. globaler Variablen muss ich mal kurz im Gehirn kramen:
Ein Hauptproblem war, dass ich in Node-Blue Node-Variablen nicht zum laufen bekommen habe, und auch die parent-Methode für Nodes/Subflows hat nicht geklappt. Entweder wurden Fehler geworfen oder es hat einfach nicht gespeichert. Das einzige was an Variablen setzen/lesen funktioniert hat war Global.
Außerdem habe ich so einen schönen Überblick beim Debuggen. Bei den Javascript Funktionen gibt es glaube ich keinen direkten Zugriff auf die Variablen wie bei PHP. (In einem anderen Thread frage ich danach, was eigentlich effizienter in Node-Blue ist: Javascript oder PHP? Leider bisher keine Antwort.
Nun denn, es erfüllt bisher seinen Zweck, auch wenn irgendwo im homegear-Olymp vielleicht bessere Methoden schlummern.
Es ist alles auch eine Frage des Zeitaufwands. Ich bin jetzt denke ich fast fertig mit dem was ich erreichen will - also hänge ich da möglichst keine weitere Zeit mehr rein, denn man bekommt hier offenbar zu wenig (keine) Antwort von den Leuten mehr, die das Ding wirklich gebaut haben. Und die ganze Source zu durchforsten hab ich keine Lust/Zeit. Da hab ich ja schneller normale Zigbee-Thermostate gekauft und komme ohne homegear aus…
Das ist wohl war …
Ich werde mir auf jeden Fall jetzt erst mal HomeAssistant ansehen. Das scheint wesentlich zukunftsträchtiger zu sein. Die HomeGear UI scheint mir ein Fall für die Tonne zu sein.
Dennoch macht es natürlich Sinn alles was der direkten Ansteuerung der MAX! Komponenten dient, in HomeGear abzuwickeln. Als Alternative zu HomeGear bliebe da sonst wohl nur FHEM.
Einen MQTT Server habe ich sowieso am laufen weil Nachrichten von meinen ESP32 Modulen dort zulammenlaufen. Und MQTT läßt sich sowohl von HomeGear als auch von HomeAssistant aus ansprechen.
Immerhin kann man node-BLUE auch nutzen um MQTT als I/O zu nutzen und Flows damit zu realsiseren. Für HomeGear Events die in Richtung MQTT müssen ist node-BLUE ebenfalls prädestiniert.
So könnte ich evtl. auf eine zusätzliche node-RED Instanz verzichten…