Welchen MQTT Broker nehmen?

[ewfwd]

Beide nutzen Docker

Und? Ich kann Home Assistant OS trotzdem als virtuelle Maschine auf Proxmox laufen lassen, genauso kann ich Home Assistant Bare Metal laufen lassen.

Wenn ich MQTT also in HA dann installiere ist es folglich auch down wenn mein Home Assistant OS down ist weil neustart oder weil es nicht mehr hoch fährt...
Wenn man also HomeAssistant als VM laufen lässt in Proxmox dann wäre es schonmal sinnvoller den MQTT Broker unter Proxmox laufen zu lassen und nicht unterhalb von Home Assistant.

Noch besser wäre es man kommt auch von Proxmox weg weils einfach nur ein Hutschienen Gerät ist was ich an mein Netzwerk stecke und dann fertig bin und das Teil Jahrelang durchlaufen kann und ich mich auch um Updates net kümmern muss...Sprich das Teil ist nur offline wenn ich die Hauptsicherung an meiner UV umlege weil Wartung, Umbau whatever...

[henfri]

Stating the obvious.

Wenn du dem Microcontroller den Strom nimmst geht er auch nicht mehr.

Lies dir nochmal durch, was ich schrieb: wenn HA aktualisiere hat das keinen Effekt auf den Broker.

[CaptainFuture]

.. Ein MQTT Broker ist ein Gerät was in aller Regel Jahre durchlaufen kann ohne dass du da regelmäßig updates einspielen musst. Das hat in meinen Augen außer zum Testen eigentlich nicht viel irgendwo virtualisiert verloren. Autonom finde ich in diesem Fall tatsächlich besser.
Ich will ja dass Wärmepumpe, Wallbox usw. möglichst direkt kommunizieren und nicht wenn mein Proxmox dann mal ausfällt, ersetzt wird was auch immer da nichts läuft mehr für die Zeit.

Nicht für alles ist virtualisieren das Nonplusultra.Die Routersoftware würdest du auch nicht umbedingt irgendwo virtualisieren sondern bevorzugst da eigenständige Geräte..

Ich würde alles virtualisieren. Du hast nur noch einen Server. Ein Backup. Einen Single-Point-of-Failure. Den Router würde ich ggf. ausnehmen, da er eine Security-Funktion hat, aber wieso sollte man den sonst nicht virtualisieren wollen?

Etwas anderes ist, wenn einem das Know-How für so einen Server fehlt und man das Kleingeld für viele Hutschienen-Gadgets hat. Oder man als alter Bastel-Huber seine Finger nicht von der Konfiguration lassen kann (und sich kennt). Dann ist etwas mit einer Read-Only-Firmware ggf. besser, um es vor mir selbst zu schützen.

Wenn die Angst der Ausfall an sich ist, dann baust Du Dir einen Proxmox-Cluster mit Fail-over: Beisst der eine Server ins Gras, migrieren Deine VMs auf einen anderen Server und Du verlierst grade mal ein paar Minuten Deiner Daten und es läuft ansonst nahtlos weiter.

Muss ja deswegen keiner so machen, wäre imho halt die flexibelste, zukunftsträchtigste, zuverlässigste und preiswerteste Lösung.

[CaptainFuture]

ewfwd
Bei mir werkelt ein RasPi4 mit Docker (NodeRed, ioBroker, Mosquitto, Influxx, Grafana).

Bei mit läuft das seit Jahren so. Allerdings mit einer SSD statt einer SD. Was hattest du für Probleme?

Den Klassiker mit der defekten Micro-SD-Karte. Und Abstürze vermutlich wg. unzureichender Netzteile. Aber mittlerweile sind die persönlichen Ansprüche bzgl. Speicher auch weit jenseits dessen, was der Raspberry hergibt, sodass ich zu Gen3 und Gen4 keine anekdotische Evidenz beisteuern kann.

[ewfwd]

Muss ja deswegen keiner so machen, wäre imho halt die flexibelste

In meinen Augen halt nicht. Muss aber jeder selber wissen...

Den Klassiker mit der defekten Micro-SD-Karte

Die meisten Fälle dürfen entweder auf schrottige SD Karten zurückzuführen sein (hauptsache billig), oder weil abnormal viel drauf geschrieben wurde.
Ich hab mir für Kodi vor einigen Jahren und nem RPi3 ne "Industrial" SD Karte geholt und nie Probleme mit gehabt... SSD in so einem Gerät ist überflüssig zumal das ganze Zubehör was man benötigt den Preis jenseits von Gut und Böse steigen lässt. Ein MQTT Server hat auch nicht groß Daten die er wegschreiben muss..

[jreeg]

Und wenn es wirklich ein dediziertes Gerät genau für die Aufgabe sein soll, gibt es noch das hier:
https://www.wut.de/e-55990-ww-dade-000.php
Ist halt kein Schnäppchen und passt nicht unter handelsübliche Verteilerabdeckungen.

Gruß

Jochen

[CaptainFuture]

Also läuft grad bei mir auf Proxmox. Benötigt aktuell knapp 20MB Ram..

In meinen Augen [ist es] halt nicht [die flexibelste, zukunftsträchtigste, zuverlässigste und preiswerteste Lösung]. Muss aber jeder selber wissen...

Äh, nur das ich das richtig verstehe: Du hast bereits einen Proxmox-Server laufen. Mit einem MQTT-Broker drin. Aber Du willst stattdessen lieber ein zusätzliches Gerät haben?

Der separate MQTT-Broker wird genausoviele Software-Updates brauchen, wie der im Proxmox. Und wenn Dir der nächste SSL-Bug egal ist, kannst Du ihn auch mit Proxmox ignorieren. Schmeiss lieber Deinen Kodi-Raspberry-Pie raus und migrier den auch auf Proxmox (oder ESXi, Hyper-V, ..). Oder installier PXVIRT auf dem Raspberry-Pie. Oder halt einfach nur einen mosquitto auf der Kodi-Box. Mehr Geräte heisst immer erhöhte Ausfallwahrscheinlichkeit des Gesamtsystems. Und mehr Hardware kostet immer auch mehr Geld und hat einen höheren Pflegeaufwand. Und wenn Du Dich ja bereits mit dem ganzen Gedöns auskennst, dann bewirfst Du ein nicht vorhandenes Problem mit Geld. Gib die Kohle lieber für was Schönes aus.

[Gunner67]

Schmeiss lieber Deinen Kodi-Raspberry-Pie raus und migrier den auch auf Proxmox (oder ESXi, Hyper-V, ..).

Und nen 20m HDMI Kabel zieht er dann nochmal durch die Wohnung? Sorry aber bei Kodi sehe ich nun wirklich keine sinnvolle Anwendung in der Virtualisierung. Kodi sitzt bei mir hinter dem Fernseher, gibt die Daten per HDMI aus. Da muss ich nix virtualisieren wieso soll ich es mir alles kompliziert machen. Würde schon damit anfangen dass du ne GPU dann durchreichen muss um an deinen HDMI zu kommen. Ja kann man alles machen, viel Spaß damit...

Oder halt einfach nur einen mosquitto auf der Kodi-Box.

Total wild...

Mehr Geräte heisst immer erhöhte Ausfallwahrscheinlichkeit des Gesamtsystems.

Nope. Mehr Geräte verringern die Ausfallwarscheinlichkeit des Gesamtsystems weil der restliche Teil dann weiterlaufen kann...
Es ist also von der Betrachtung her wichtig zu schauen welche Geräte machen überhaupt noch Sinn wenn sie weiterlaufen weil sie ohne ein anderes System nutzlos sind. Wenn zB alle meine Daten über MQTT in InfluxDB kommen, dann ist es egal ob InfluxDB weiterläuft oder nicht wenn MQTT ausgefallen ist...

Wenn du gleichzeitig noch Daten über andere Wege reinpackst ist es wieder etwas anderes..Indem du alles virtualisierst erschaffst du dir einen weiteren SPOF...

Anderes Beispiel: Wenn ich ein NAS habe und ich habe Dienste die darauf angewiesen sind zB ne Datenbanksoftware oder Eigene Cloud oder was auch immer, ja DA macht es Sinn zu virtualisieren weil dieser Dienst ohne das NAS eh nutzlos wäre. DA würden eigenständige System weniger Sinn ergeben mitunter...
Man sollte sich gut überlegen was packt man alles auf ein Gerät und wo trennt man dann doch lieber...

Szenario: Ich habe mit Home Assistant nur paar optionale Logiken laufen, ne Visu und Datenaufzeichnung... Sprich wenn das ausfällt ist doof aber nicht schlimm, ggf kann ich auch einfach mal den Netzwerkstecker ziehen im Switch und was umkonfigurieren usw.

WENN ich dann aber nicht dran gedacht habe dass meine Türklingel auch darüber läuft zB in Form irgendeiner Logik und ich bekomme das dann nicht mit, is doof..
Von daher sollte man sich nicht zuviele Abhängigkeiten schaffen...

MQTT kann toll sein um paar Werte hin und her zuschieben wie Zählerdaten vielleicht auch ne Funksteckdose damit schalten usw. Ob ich aber Infrastrukturkritische Dinge darüber laufen lassen will und mir eine zusätzliche Komponente nämlich den MQTT Broker da mit reinhole in die Kette sollte man sich GUT überlegen...

Bei nem Wechselrichter wird aus gutem Grund der Zähler ja auch direkt mit Modbus RTU angebunden und nicht "irgendwie über Netzwerk" und noch MQTT dazwischen usw...

Und wenn auch im "normalen" EFH immer mehr über Netzwerk läuft ist auch da die Frage auf was für eine Infrastruktur setzt man da, ist man dann gut beraten einfach das billigste TP-Link Gerät herzunehmen oder schaut man sich nicht vielleicht doch eher so im "Prosumer" oder "Business" Bereich um um die Ausfallwarscheinlichkeit zu verringern...

Die Statistische Ausfallwarscheinlichkeit würde ich bei KNX auch als geringer einstufen als irgendwas mit IP. Wenns ganz kritisch ist bildet man vielleicht doch nochmal ne eigene Unterlinie innerhalb einer UV um alle Abhängigkeiten von außerhalb loszuwerden wie "Kurzschluss irgendwo in der Anlage" (oder geht andere Wege)

[CaptainFuture]

Wenn Du einen MQTT-Broker auf Server1 (mit Verfügbarkeit V1) und eine Datenbank auf Server2 (mit Verfügbarkeit V2) hast, in die Du via MQTT schreibst, dann ist die Verfügbarkeit V des Gesamtsystems nur V1 * V2.
Virtualisierst Du den Broker und die Datenbank zusammen auf Server1, dann ist Deine Verfügbarkeit V1 -- also höher. Und selbst wenn wenn Dir nur der Broker alleine was bringt, ist seine Verfügbarkeit exakt genauso hoch wie die virtualisierte Lösung.
Bei Deiner Türklingel machst Du genau das gleiche: Die Türklingel alleine hat Verfügbarkeit T. Jetzt packst Du Dein zweites System mit Verfügbarkeit A dazu, dass die Klingel auswertet. Und schon geht Deine Verfügbarkeit runter auf T * A. Genau das gleiche mit dem Wechselrichter und dem Zähler. Die Anzahl der physikalischen Geräte zieht Deine Verfügbarkeit nach unten. Der "Sunny Home Manager" kommuniziert bspw. via Ethernet mit seinem Wechselrichter. Wenn Du da noch einen Switch dazwischen hast, sinkt Deine Verfügbarkeit noch um den Faktor des Switches.

Die virtualisierte Lösung wäre dann schlechter, wenn die Verfügbarkeit des Hypervisors geringer ist, als die Verfügbarkeit der dedizierten MQTT-Box und das Gesamtsystem vollständig unabhängig vom Server ist.

Wenn die Verfügbarkeit nicht nur technisch betrachtet wird, dann ist natürlich Polen offen: Wenn jemand aufhört seinen Hypervisor als kritische Infrastruktur zu betrachten, sobald er auch Kodi drauf laufen hat, dann macht die dedizierte MQTT-Box sehr viel Sinn. Schaltet die Frau den Hypervisor immer aus, aber würde sich nie an den Schaltschrank wagen, her mit der MQTT-Box! Und auch die Hemmschwelle ein physikalische Geräte zu "löschen" ist sehr viel höher als bei einer Virtuellen Maschine. Don't drink and root. Oder kauf die MQTT-Box.

[Gunner67]

Der "Sunny Home Manager" kommuniziert bspw. via Ethernet mit seinem Wechselrichter. Wenn Du da noch einen Switch dazwischen hast, sinkt Deine Verfügbarkeit noch um den Faktor des Switches.

Woran du aber nicht viel ändern kannst weil das schon der direkte Weg ist. Was anderes wäre wenn beiden noch MQTT zwischengeschaltet ist und sie nur über einen Broker miteinander reden können...

Ich schrieb ja für gewisse Dinge macht MQTT Sinn, für andere in meinen Augen weniger wegen der zusätzliche Abhängigkeit.

Ich betrachte es auch aus einer anderen Sicht: Wenn ich an meinem Home Assistant usw. gern mal dran bastel, dann ist es eher von Nachteil wenn dort simple Dinge drauf laufen die aber besser 24/7 durchlaufen sollen und das theoretisch auch könnten.. Dann hat so ein System was "fire und forget" ist einfach sinniger. Weil im privaten kannst du einen Broker stumpf durchlaufen lassen auch ohne Updates über Jahre...

Weiterer Punkt dein Server/NAS hat ggf auch mechanische Bauteile wie Lüfter. Ein Gerät was wirklich nur die Aufgabe MQTT hat würde aber ohne auskommen. Das ist im Grunde einfach nur ne Software die im Ram durchläuft...

Die Anzahl der physikalischen Geräte zieht Deine Verfügbarkeit nach unten

Ist zu einfach betrachtet... Ich hatte letztens nen Stromausfall. Proxmox ist abgestürzt und ist dann nicht wieder hochgefahren. Musste er Bildschirm dran anschließen, hat gemeckert weil irgendwie paar Bits wären verlogen gegangen jedenfalls musste man einmal Enter drücken damit es wieder hochfährt.
Wenn ich nun 10 Dienste drauf habe, sind 10 Dienste vorrübergehend nicht verfügbar. Äußerst unwarscheinlich dass wenn die Dienste auf 10 unterschiedliche Geräte aufgeteilt werden alle den exakt gleichen Fehler gehabt hätten. Da wären dann vielleicht 2 nicht wieder hochgefahren, die anderen 8 aber schon...

Und mal ehrlich sowas wie Hochverfügbarkeit mit Proxmox und so ist für daheim einfach nix weil viel zu kompliziert. Entweder kommste beruflich aus der Ecke und bringst das ganze Wissen ohnehin mit alternativ sind das unmengen an Freizeit die du da opfern musst um dich einzuarbeiten...Wenn keiner mehr durchblickt am Ende ist dabei auch nix gewonnen...
Kurzum alles auf einer Kiste ist eben nicht das Nonplusultra für jeden...

[CaptainFuture]

Und mal ehrlich sowas wie Hochverfügbarkeit mit Proxmox und so ist für daheim einfach nix weil viel zu kompliziert. Entweder kommste beruflich aus der Ecke und bringst das ganze Wissen ohnehin mit alternativ sind das unmengen an Freizeit die du da opfern musst um dich einzuarbeiten...Wenn keiner mehr durchblickt am Ende ist dabei auch nix gewonnen...

Da geh ich d'accord. Ich hatte halt den Eindruck, was ewfwd hier für einen Flex hinlegt, dass das nicht das Problem ist.