IPS als MQTT Broker oder doch lieber Mosquitto?

Hallo Freunde
Corona sei Dank hab ich mal ein altes Projekt rausgekramt und mit MQTT rumgespielt.
Soweit ganz nett, wäre fast zu überlegen meine ganzen DiY Aktoren/Sensoren von den diversen selbst gestrickten Protokollen auf MGTT umzustellen.
Das würde etwas mehr Ordnung bringen und wenn die Konsole zu sehr nerft auch die evtl. loslösung von IPS erleichtern.

Nun frage ich mich was besser wäre:
Den in IPS eingebauten Broker verwenden ?
oder
auf dem NAS einen Mosquitto laufen lassen und IPS als Client.

Gibt es für und wieder ?
Datenaufkommen ist eher gering, im Schnitt so alle paar Sekunden gäb es was zu tun. Sowohl Publish() als auch Subscribe().

Meine Nodes sind alle möglichst einfach, OTA und so Sachen hab ich nicht. Daher ist auch die Frage an welche Server IP ich die Teile binde von belang. QoS ist auch nicht sooo wichtig. Dort wo es kritisch ist laufen sowiso Watchdogs.

bin auf eure Meinung gespannt
Bernhard

Hallo Bernhard,

ehrlich gesagt verstehe ich Deinen Frust (auch aus dem anderen Thread) nicht. Ich habe Mosquitto genutzt, bevor es den IPS-MQTT-Server gab und habe den zügig in die Ecke geschmissen, nachdem die native Lösung da war. Mit der nativen Lösung habe ich noch nie Probleme gehabt. Ich habe aber auch nicht den Anspruch, dass eine EierlegendeWollmilchSau die für mich perfekte Lösung bietet.

Für meine DiYs habe ich auf der ESP-Seite ein Standard-Basisprogramm geschrieben, dass für die Kommunikation mit Symcon-MQTT zuständig ist. Das ergänze ich dann mit den spezifischen Dingen des DiY wie Garagentor öffnen, Gaszähler auslesen oder Temperatur messen.

Auf der Symcon-Seite habe ich das genauso gemacht. Ich habe mir ein Basis-Modul geschrieben, das sich an den Broker hängt und die Topics empfängt. Wenn ich ein neues DiY-Projekt habe, dann ergänze ich dieses Basismodul mit den spezifischen Dingen des Projekts. Das dauert meistens keine 10 Minuten, bis es funktioniert.

Mosquitto würde ich auch aus Keep-it-simple-Gründen niemals dazwischenschalten.

Viele Grüße
Jürgen

Ich bin auch sehr zufrieden mit dem internen.
Ist auch viel einfacher als andere Dienste da bei zu fummeln.

Ich nutze auch nur noch den internen MQTT Server und solltest du sehr viele Geräte haben, kannst du mehrere MQTT Server Instanzen anlegen, dann ist die Performance besser.

Grüße,
Kai

Das sehe ich wie meine Vorredner, lieber den eingebauten Dienst nutzen, als etwas dazu basteln, dass dann auch gepflegt werden muss.

Aber ich kann auch Bernhard verstehen, die Umsetzung könnte vielleicht optimaler sein. Ich fühle mich bei MQTT, wie mit den ZWave-Problemen: es ist Gott sei Dank eingebaut, aber 100% glücklich ist man damit auch nicht. Aber das wird im anderen Thread eh schon thematisiert.

Meine nicht maßgebliche Meinung.

Viele Grüße aus dem schneeverwehten Unterallgäu
Harry

Was genau fehlt dir bei MQTT @harry28, wir können gerne mal quatschen. Vielleicht kann ich dir ja auch etwas dabei helfen. :slight_smile:

Grüße,
Kai

Danke euch für die Meinungen.
Um vielleicht ein Missverständnis aufzuklären: Am Dienst an und für sich hab ich noch nichts negatives bemerkt, darum auch die Frage an die in dem Thema Erfahreneren.
Wollte vermeiden das wenn ich meine ganzen nicht MQTT Nodes auf diesen Dienst umstelle und ggfls. auch noch andere Lösungen in Rente schicke, dann später draufkomme aufs falsche Pferd gesetzt zu haben.

Ich lese aus euren Antworten das es wohl keinen Vorteil bringt auf eine externe Broker Lösung zu setzen.
Muß halt irgendwie rausfummeln wie ich meine Nodes bei Bedarf auf einen anderen Host/IP umhängen kann.

schöne Grüße aus dem endlich mal wieder sonnigen Süden
Bernhard

Dafür sehe ich zwei Möglichkeiten: Der externe MQTT Broker liegt auf der selben Maschine wie Symcon. IP bleibt gleich. Ports kann man zwischen den Diensten dann einmalig tauschen.

Du gibst IP-Symcon aktuell 2 IP-Adressen und die 2. Adresse nur für mqtt dann bei Bedarf später dem MQTT Broker.

Um was für Geräte handelt es sich?
Kannst du dort Einstellungen per http vornehmen?

Grüße,
Kai

Zweite Netzwerkkarte, hmm.
Am liebsten würde ich meinen Arduinos einen alternativen Host vorgeben. Muß noch ein wenig Googlen ob es da nette Lösungen gibt.
Irgendeine komplexe Netzwerkkonfiguration lohnt aber nicht, da es ja nur für den Fall der Fälle ist.

@Kai: habe alles Eigenbauten mit absichtlich ganz minimalistischer Software.
Tasmotas/Shellys oder irgendein OTA Mechnismus will ich wahrscheinlich nicht.

schönen Abend
Bernhard

Ein bischen kann ich das schon verstehen.

Ich hatte in anderen Threads ja auch schon angemerkt, das ich eigentlich lieber meinen vorhandenen MQTT Broker auf der Synology benutzen würde als den lokalen IPS MQTT Broker auf den Raspberry. Schon weil ich historisch alles dorthin connected habe und dort auch mein zentrales Logging, Grafana etc angedockt ist. Bei meinen ersten Gehversuchen mit dem den Tasmota Modulen und dem reinen Client hatte ich eine Reihe von Fehlermeldungen auch hier gemeldet (primär End of File nach einer Minute, aber hier nie eine Antwort dazu bekommen. Mit dem internen Broker gab es diese Probleme nicht
Nun muss ich sehen, wie ich den internen Broker mit dem externen verheiraten kann, sprich der externe Broker auch die beim internen Broker ankommenden Topics zu sehen bekommt. Ist eigentlich auch auch total unnötige Mehrarbeit, wenn der interne MQTT Client ausreichend funktionieren würde.

Tommi

Hast du da mal ein Beispiel, was du da Einsetzt ?
Hatt mir auch schon mal ein eigenes Gerät per Arduino erzeugt, aber heute nutze ich fast nur noch Tasmota. Aber auch da fehlt mir Hardware, einen Treiber habe ich mir schon selber gebastelt.

Dann habe ich noch ein Shelly Em an meiner Test Solarzelle hängen, dass Ding flutet den Brocker (bei mir läuft alles auf einem Pi (Tinkerborad) mit Meldungen, wodurch es langsam wurde. Daher laufen in IPS mehrere interne MQTT-Server auf verschienden Port’s und das ganze sieht ziemlich gut aus.

Ich möchte MQTT nicht mehr missen, und ich ich vermute, dass IPS Team wird es immer weiter verschlimm… Äh … Verbessern.:smiley:

Ich sprach von zwei Netzwerk-ADRESSEN nicht von zwei Karten.

wenn Du auf Deinen ESP8266 die EspMQTTClient-Bibliothek einsetzt, dann hast Du da auch einen kleinen Web-Server drauf, der bereits ein Firmware-Update implementiert hat. Damit würde es auch ohne OTA gehen. Für mich spricht aber auch nichts gegen OTA. Man muss halt aufpassen, dass man beim Update keinen Blödsinn macht, wenn die Dinger irgendwo vergraben sind. Das gilt aber immer.

Jürgen

Meinst du Hardware, Software oder Applikation ?
Hardware ist das übliche: Verschiedene Arduinos, ESP01, NodeMCU, die Peripherie dann was halt grad in der Bastelkiste lag

Software: die uC ist bis auf einfache Grundfunktionen ziemlich dumm und arbeiten im wesentlichen nur als I/O. Alle Logik steckt in IPS

Applikation:

  • Logging der Stringströme der PV (DC-Strommessung)
  • Aquarium Wasserwechsel (Pumpen und Ventile)
  • Heizungkessel & therm. Solar (Pumpen,Ventile, Temperatur) im mix mit 1Wire
  • Aquarium Temperatur (Stellventil, Temperatur)
  • Interface zur Modelleisenbahn (GPIO)
  • Bad Lüftersteuerung (Luftfeuchte, Temperatur, Motor, Schrittmotor)
  • Lüftung Heizungsraum (Schrittmotor)
  • Gartenbewässerung (Gardena Ventile)
  • Küche Dunstabzug (Relais)
  • und diverses Kleinzeugs(Temperatur) und Bastelversuche
    Obsolet: Balancing für PV Akku, Aquarium PH Wert, RFID für Schlüsselboard

Geplant:

  • Panasonic WP (kommt fix im Frühjahr)
  • wenn mir mal langweilig ist den PV Wechselrichter und den Akku (beides läuft zzt. über USB)
  • GPIO im Zählerkasten (Ersatz für 1 Wire)

Die Verbindung zu IPS mache ich immer per ClientSocket und einfachem Klartextprotokol. Es ist für jeden Anwendungsfall immer individuell angepasst. Der üblichen teilw. nur mehr schwer durchschaubare Wildwuchs eben…

Von da her wäre es echt hübsch mal aufzuräumen und einen Standard dazwischenzuschalten. Auch vor dem Hintergrund zumindest die theoretische Möglichkeit eines Exit Szenarios zu haben.

@tobias: Klingt interessant, muß mal lesen

Betrachte es wie ein großes Haus. Da kannst du auch Hausnummer 22+24 haben und musst trotzdem nicht zwei Eingangtüren haben. So kannst du dir halt „unendlich“ viele Adressen an deine Netzwerkkarte schreiben. Was meinst du wohl, warum man für etliche Dinge in Symcon auch den lokalen Socket oder den Sende-Host einrichten kann.