Blockly: mehrere Werte automatisiert per MQTT weiterleiten?

  • Hallo zusammen,


    ich nutze den ioBroker für die Steuerung meines MaxCubes bzw. den zugehörigen Heizkörperthermostaten. Unter maxcube.0 => devices habe ich ja alle Thermostate und Fensterkontakte aufgelistet.


    Kann ich diese Werte automatisiert per MQTT weiterleiten, ohne dass ich für jeden Wert bsp. ein Blockly Script anlegen muss?


    Nehmen wir mal das Thermostat im Wohnzimmer, dieses hat folgende Unterpunkte:

    battery_low, error, initialized, invalid, link_error, mode, panel_locked, setpoint, temp, valve, working


    Kann ich irgendwie eine Wildcard setzen, sodass alle diese Werte automatisch bei Veränderung per MQTT veröffentlicht werden können? Quasi "wenn Wert von maxcube.0.devices.thermostat_aaaa11.$wert geändert wird, dann veröffentliche ihn per mqtt unter /home/unten/wohnzimmer/heizung/$wert", wobei $wert jeweils z.B. battery_low, error, setpoint, etc. ist.


    Ich bin es von node-red gewohnt, schön per copy and paste arbeiten zu können, was bei den Blockly Scripten leider nicht so komfortabel ist. Wenn ich da für jeden Heizkörper manuell jeden Wert für die Veröffentlichung via mqtt anlegen muss, bin ich ja mit gut 2 - 3 Stunden dabei...


    Ich nutze aktuell zu Testzwecken den ioBroker eigenen MQTT Broker, würde aber gerne auf einen separaten MQTT Server wechseln, den ioBroker nur als Client (lesend sowie schreibend) abonniert.


    Danke im Voraus für Eure HIlfe :)

  • Ähm, aber anscheinend mache ich das falsch, oder es funktioniert doch nicht wie gewollt...


    Schraubenschlüssel angeklickt, "Einstellungen für mqtt-client.0": aktiviert, "qos": 2, topic "zigbee/0/00158d000133e5f7/voltage". Wenn ich versuche, das Topic zu abonnieren, passiert gar nichts. Die Werte aktualisieren sich ja regelmäßig, werden mir aber in MQTTFX nicht angezeigt.


    In den Einstellungen habe ich bei "Prefix for publish" testweise mal "home/" gesetzt, aber auch unter "home/zigbee/0/00158d000133e5f7/voltage" stehen keine Werte.


    Den regulären mqtt Broker habe ich für diesen Test deaktiviert, sodass er nicht dazwischen funken sollte.


    Woran kann es noch liegen? ioBroker läuft bei mir derzeit auf einem Raspberry Pi, und das merkt man auch. Log lässt sich noch anzeigen, versuche ich aber, die Ereignisse aufzurufen, kommt nur die Warteschleife of Death. Daher kann ich darüber leider nichts nachvollziehen.


    Im MQTT Client unter Objekte werden mir die erstellten Topics leider auch gar nicht angezeigt. Dort habe ich nur die, die sowieso durch "home/#" sowieso abonniert werden. Die hier gezeigten Beispiele mit "zigbee" im Topic existieren dort überhaupt nicht...?

  • In den Objekten wäre es mir noch relativ egal, aber sie müssten ja eigentlich zumindest in einem anderen MQTT Client dargestellt werden.


    Ich habe alle Haken jetzt mal entfernt und neu gesetzt, retain an/aus, qos 0/1/2. Geht leider nicht. Der Mqtt Broker läuft jetzt auch. Der lief vorher nicht, sollte also damit eigentlich nichts zu tun habe. Ich starte den ioBroker jetzt einmal komplett neu. Wenn das hilft, schreibe ich hier ein Update, wenn nicht warte ich mal bis heute Abend ^^

  • Bingo! Wenn ich # nutze, funktioniert es. Muss das "home/" halt dann bei der Veröffentlichung selbst hinzufügen.


    Nehme ich aber "home/" als Prefix, und lasse esb ei der Veröffentlichung entsprechend weg, funktioniert es nicht. Ist aber okay, so kann ich damit arbeiten.


    Ich möchte sowieso (wenn die Hardware denn mal geliefert wird) node-red und ioBroker auf demselben Gerät laufen lassen. Dann richte eh einen Großteil sowieso neu ein und kann direkt mit dem MQTT Client auf ioBroker arbeiten (aktuell brauche ich den Broker, um die Heizungen zu steuern... das hatte mit dem Client auch nicht funktioniert, und vermutlich aus demselben Grund wie hier, weil ich den Prefix manuell gesetzt hatte).


    Riesigen Dank :) ! Dann kann ich heute doch noch mehr machen, als mich mit diesem Problem rumzuärgern ;)

  • Ich finde das Thema gerade spannend, darf ich den Hintergrund erfragen warum du alles an einen MQTT schickst? Welche Relevanz haben die Daten an einem anderen MQTT? Prinzipiell finde ich die Idee auf einen Schlag mehrere Werte (ggf. auch von unterschiedlichen Geräten) zu übertragen für eine Visualisierung gar nicht so übel.

  • Ich mache das hier aus dem Grund, dass ioBroker zwar ein mächtiges Tool ist, ich aber mit node-red einfach besser arbeiten kann.


    Ich schicke alle Werte per mqtt an home/zimmer/raum/messwerte/hum//temp//pre und abonniere in node-red home/+/+/messwerte/#.


    Die so empfangenen Werte werden dann einmal als Payload für influxdb geparsed und in die Datenbank geschrieben. Zudem kann ich sie auf dem Smartphone mit einem MQTT Client einsehen. HIerüber kann ich beispielsweise auch meine Heizungen steuern (zusätzlich zu ioBroker via Alexa), Geräte ein/aus schalten etc.


    Klar, Influx kann ioBroker auch. Ich finde aber Blockly einfach gruselig (obwohl node-red ja auch relativ ähnlich mit solchen Blöcken arbeitet). Alleine schon mangelndes Copy & Paste nervt mich tierisch, zudem arbeite ich seit mindestens anderthalb Jahren mit node-red, sodass mit Dinge dort einfach leichter von der Hand gehen.


    Seit ich jetzt in den letzten Tagen vermehrt mit ioBroker arbeite, sehe ich, dass es doch nicht so schwierig ist (den ersten Versuch vor 'nem Jahr oder so habe ich aufgrund der Komplexität direkt nach einigen Minuten sein gelassen ;)). Ich denke, es wird auch auf eine 50/50 Zusammenarbeit von ioBroker und node-red hinauslaufen. Aktuell ist es für mich aber einfach simpler, die Werte zur Weiterverarbeitung an node-red weiter zu leiten.


    Der Grund, warum ich ioBroker überhaupt noch eine Chance gegeben habe waren einerseits die Youtube Tutorials, über die ich auch auf dieses Forum gestoßen bin - andererseits einfach die Tatsache, dass sich meine Heizkörperthermostate über den MaxCube mit node-red einfach nie zuverlässig steuern ließen. Das klappt mit ioBroker jetzt endlich, und da das vorher auch schon über MQTT lief (naja, eher laufen sollte :D), kann ich den vorhandenen Workflow behalten, indem ich entsprechend die Topics so anpasse, dass sie für ioBroker passen. Alexa steuert direkt maxcube.0.gerät_zimmer.setpoint via Cloud, der Wert wird dann via MQTT an node-red weitergegeben; andererseits kann ich aber die Zeitsteuerung, die in node-red ja schon existiert, direkt weiter nutzen, indem ich dem MQTT Topic im ioBroker Lese- und Schreibrechte gebe und die Werte so direkt steuere (ist aktuell noch nicht umgesetzt, da ich erst auf die neue Hardware warte, auf der dann beide Systeme parallel laufen - dürfte aber problemlos funktionieren).



    X-R4Y da Du von Visualisierung sprichst: es gibt für Telegraf wohl auch ein MQTT Plugin, sodass man nicht einmal mehr (wie in meinem Fall) den Weg über node-red gehen müsste. Habe ich bislang nicht ausprobiert, weil einfach noch zu viel auf der To Do Liste steht. Ich gehe davon aus, dass man das so einstellen kann, dass aus dem Topic -wenn entsprechend angelegt- direkt Zimmer und Wert geparst werden können, sodass die Werte direkt mit den gewünschten Werten gespeichert werden können.

  • Interessante herangehensweise. Warum verwendest Du node-red nicht innerhalb des ioBrokers als Adapter? Bzw. wie/wo setzt du node-red als eigenständigen Server ein in Verbindung mit dem MQTT? Finde die Konstellation ganz nett, so könnte man (mit entsprechender Hardware) das ganze schön über getrennte virtualisierte Systeme laufen lassen. Bei mir läuft z.B. in einer separaten VM ein SQL Server (anstelle der influxDB) der mir so ziemlich alles protokolliert und ich mit entsprechenden Web-Tools die Daten bequem aufbereiten kann.

  • Warum verwendest Du node-red nicht innerhalb des ioBrokers als Adapter? Bzw. wie/wo setzt du node-red als eigenständigen Server ein in Verbindung mit dem MQTT?

    VirginiaExpress Wenn du MQTT (für die Heizung) nicht unbedingt brauchst, wäre das wirklich einfacher, gerade wenn du dein System neu aufsetzt. Vielen kannst du auch etwas Leistung sparen, auf jeden Fall aber etwas Konfigurationszeit ?.

  • Ich hatte node-red auf einem Raspberry Pi 2 laufen, und wollte da nicht auch noch den ioBroker drauf installieren. Deshab kam der ioBroker auf einen weiteren Pi. Das ist der einzige Grund, weshalb die getrennt sind, ich werde die Systeme dann auf derselben Hardware laufen lassen, wenn Gearbest denn mal liefert (habe mir im Sale am 11.11. einen Beelink gegönnt, der aber leider auf sich warten lässt).


    Es gibt einen MQTT-server node für node-red, den ich aber vor Kurzem erst entdeckt habe. Bei mir läuft einfach mosquitto auf dem node-red Pi, mit dem sich der ioBroker verbindet. Wenn eh beides auf demselben Gerät läuft, könnte ich theoretisch wohl auch den ioBroker MQTT Client nehmen - wobei ich ja anscheinend sowieso auf den MQTT Client angewiesen bin, um den Schraubenschlüssel zu haben, mit dem ich jedem Objekt automatisch ein MQTT Topic zuweisen kann.


    Welches Webtool benutzt Du? Ich bin seit einiger Zeit mit dem TICK Stack unterwegs, bzw. zumindest influxdb, grafana, und minimal telegraf (grafite nur zum Testen, bevor ich die Visualisierung in grafana mache). Meinen Stromverbrauch hatte ich kurzzeitig mal parallel zu influxdb auch in eine MariaDB geschrieben, aber das lässt sich mit Grafana nicht so schön darstellen.


    Vor Kurzem ist mir der ELK Stack plus Logstach aufgefallen, der wohl dank Elasticsearch auch gut für rsyslog sein soll. So kann man dann von allen Geräten die Logs vereint unter einer Weboberfläche darstellen. Habe ich einmal mit docker ausprobiert und frustriert wieder aufgehört - wenn ich nun aber node-red und ioBroker sowieso noch einmal komplett neu aufsetze, werde ich auch das noch einmal ausprobieren.


    Ist einerseits Nerdheaven, andererseits Zeitverschwendung. Ich habe jetzt ein Grafana Dashboard für alle Daten, die mein pfSense per Telegraf hergibt und eins für Plex (Anzahl Shows/Staffeln/Episoden, Filme, Hörbücher, aktueller Stream, zuletzt hinzugefügt). Beides eigentlich nur bedingt sinnvoll (ich weiß, was ich in der Bibliothek habe und was wir sehen, und auch die pfsense Daten zeigt pfSense selbst auch gut an ;)). Aber ich möchte das Logging mal auf ein Maximum bringen und nach einem Jahr oder so schauen, wie ich die Daten auswerten kann.


    Zumindest die Datenbank mit dem Stromverbrauch pro Gerät pro Tag inkl. ungefährer Verbrauch ist echt sinnvoll. Wo jetzt ein paar Infrarotheizungen dazugekommen sind sieht man immer, was die pro Tag kosten und wo man ggf. die Zeitsteuerung noch tweaken kann, damit man vielleicht was einsparen kann.

  • VirginiaExpress Wenn du MQTT (für die Heizung) nicht unbedingt brauchst, wäre das wirklich einfacher, gerade wenn du dein System neu aufsetzt. Vielen kannst du auch etwas Leistung sparen, auf jeden Fall aber etwas Konfigurationszeit ?.

    Wie würde ich das denn dann am Besten umsetzen?


    Ich brauche im ioBroker dann ja sowohl einmal den Broker (damit die ganze Sache überhaupt funktioniert), als auch den Client (damit ich alle Werte wie von Dir beschrieben per MQTT "weiterleiten" kann), richtig?


    Die parallel laufen zu lassen fand ich etwas irritierend, und aus irgend einem Grund "stört" der MQTT Broker (selbst als Client eingesetzt) irgendwie die Werte, die eigentlich nur node-red intern eingesetzt werden - aber natürlich von ihm trotzdem eingelesen werden, wenn ich "#" abonniere. Jedenfalls hatte ich ein paar JSON Parse Fehler in node-red, die immer nur dann auftraten, wenn der ioBroker mqtt Broker (als Client eingesetzt) aktiv war. Sobald ich den ausgeschaltet habe, wurden die Werte wie erwartet geparsed.


    Ich habe aktuell sogar zwei MQTT Server laufen. Einer ist "öffentlich" (Kennen der IP Adresse mal vorausgesetzt ;)) erreichbar, damit auch das Handy meiner Frau (was im Gegensazu zu meinem nicht immer von unterwegs per VPN verbunden ist) die Geodaten senden kann. Da ich aber ungern irgend etwas von außerhalb steuern lassen möchte (Stichwort Shodan.io), ist dieser MQTT Server ausschließlich für die Geodaten da. Alle anderen reinkommenden Topics werden rausgeparst und von node-red ignoriert.


    Grundsätzlich bin ich aber natürlich auch gerne am Start, das Ganze zu vereinfachen.

  • Bei mir machte der MQTT-Server-Adapter auch Probleme.

    Ich habe Mosquitto seperat laufen. Persönlich finde ich es auch am besten, den Broker seperat zu haben, falls man z. B. ioBroker nicht mehr nutzen möchte, ist der Broker immernoch da.


    Wenn du NodeRed als Adapter installierst, brauchst du kein MQTT mehr. Dann gibt es eine Node mit der du direkt auf die Objekte zugreifen kannst.

    Macht natürlich nur Sinn, wenn du auf die Client App verzichten könntest und die Werte auch sonst nicht in MQTT brauchst.


    Auch hier wieder die Frage, ob NodeRed nicht unabhängig von ioBroker laufen sollte...


    Bei mir läuft alles in seperaten Docker Containern, sodass ich jederzeit ein System deaktivieren kann, ohne das ein anderer Dienst fehlt.

  • Ach so, dass die dann ohne MQTT kommunizieren können, hatte ich nicht auf dem Schirm. Auch sehr cool!


    Für mich persönlich wäre das trotzdem nichts. Die Geodaten kommen per MQTT rein, und ich wüsste nicht, wie ich das anders lösen könnte. Das heißt, doch, per HTTP würde gehen, müsste ich dann aber auch nach Außen freischalten. Um owntracks, traccar usw. zu umgehen, kommen die Geodaten direkt per MQTT über Tasker auf den jeweiligen Android Geräten.


    Und ich brauche auch die Client App! Die zeigt mir u.A. auch den offen/geschlossen Status sämtlicher Fenster an, was ich sonst auch wieder neu realisieren müsste, die Messwerte der Sensoren (will ja nicht für alles Grafana öffnen müssen ^^), und und und. Mag für viele bestimmt auch ohne gehen, ich bin aber mittlerweile so auf MQTT eingeschossen, dass es nicht ohne geht.


    Hast Du einen extra VServer nur für die Haussteuerung? Ich bin schon lange auf der Suche, nach einem NAS und Vserver in einem (werde hier bei Gelegenheit auch mal in der Build Ecke nach Vorschlägen fragen), um meine Synology NAS zu ersetzen und nicht immer das Speicherplatzproblem zu haben (mit RAID5 werden aus 32TB halt auch nur 16, damals dachte ich, das reicht schon...), habe mich aber extra dagegen entschieden. Zumindest das Synology, auf dem die Docker Container laufen, muss auch mal neu gestartet werden.


    Klar, die Reboots sind überschaubar, aber jetzt auf den Pis (oder bald dann auf dem Beelink) kann ich mich darauf verlassen, dass alles immer steuerbar bleibt, außer ich muss wirklich die nur für die Haussteuerung eingesetzte Hardware mal manuell rebooten.

  • Ohne MQTT war ja nur ein Vorschlag.


    Auch wenn's nicht unbedingt hier zum Thema passt:

    Ich hatte zwei Pis, aber die kamen an ihre Leistungsgrenze. Habe jetzt einen Intel NUC mit Pentium Prozessor und 8GB RAM. Darauf laufen ca. 10 Docker Container.

    Von außen ist nichts erreichbar, außer über Alexa und Telegram.

    Ein NAS habe ich (leider!) nicht.

  • Ich schweife auch mal ein bisschen ab: auf dem NUC dann ein normales Debian (o.Ä.) und darauf Docker, oder direkt Proxmox als VM- und Dockerserver?


    Ursprünglich wollte ich ja extra nicht Docker verwenden, wenn ich die neue Hardware einsetze... andererseits wäre es schon hilfreich, alles separat aufsetzen (und vor Allem bei eventuellen Fehlern einfach einen neuen Container starten) zu können.

  • Ich habe mich jetzt eine Weile nicht mit Proxmox befasst, aber soweit ich informiert bin, soll das auch nativ Docker "können". Also Proxmox als System und dort über die Oberfläche direkt Container anlegen.


    Habe eben nochmal recherchiert und muss mich wohl getäuscht haben. Es gibt aber irgend eine Virtualisierungoberfläche, die sowohl VM, als auch Docker direkt out of the box kann. Ich komme allerdings gerade nicht auf den Namen.