MQTT Verbindung zwischen 2 IP-Symcon Systemen

Hallo,

nachdem Paresy ja gestern beim Event meinte: „…damit lassen sich auch super 2 IPS verbinden…“ habe ich mal ein wenig rumgespielt :rolleyes: und scheinbar steht bei mir noch jemand auf dem Schlauch.

Auf dem Hauptsystem einen MQTT-Server (bzw. Konfigurator) einzurichten ist kein Problem - die möglichen Variablen erscheinen auch im Konfigurator (alles gut :rolleyes: auf den Button zum Löschen aus dem anderen Thread kann ich warten :))

Ich habe Probleme/Fragen zum Client-IPS:

  1. Ich kann dort zwar ein MQTT-Client-Device anlegen (auch verschiedene Typen (Float, Bool…)) und diese mit dem Befehl aus der Doku(RequestAction(12345, „EinTollerWertZumPublishen“):wink: auch senden. Aber wenn ich den Wert per Script ändern möchte z.B. mit
SetValueFloat($id,$value);

erhalte ich als Ausgabe:

Warning:  Variable is marked as read-only and cannot be changed in /var/lib/symcon/scripts/56051.ips.php on line 5

Wenn ich den Wert mittels Doppelklick in der Konsole ändere, erhalte ich auch diese Warnung, er wird aber wenigstens geändert (und übertragen) :eek: Dies ist m.E. ein Bug :rolleyes:

  1. Ist es wirklich so gedacht, dass man für z.B. das Übertragen von 10Variablen jeweils 1MQTT-Client-Device anlegen muss (also auch 10) und darunter dann jeweils eine „wirkliche Variable“ - von der Übersichtlichkeit finde ich dies eher unglücklich (derzeit habe ich unter jeder Variablen eine Script in dem die per JSON-RPC die Date übertragen wird)

  2. Kann man den Erfolg der Übertragung auswerten? Optimal wäre m.E. auch ein erneutes Senden (nach parametrierbarer Zeit) falls die Übertragung fehlerhaft war…

Schönen Sonntag noch
HerbertF

Hallo HerbertF,

Kai hat dafür ein Modul gebaut: MQTTSync. Im Store zu finden, und die Beta benutzen.
Das nutze ich, um von meinem HeizungsPi die Daten auf mein Hauptsystem zu bekommen.

Oh:eek:

Ich rufe bisher meine HeizungsPI mit zweitem IPS, immer noch oldschool über diese Webhook Schnittstelle ab…
(D.h. Variablen holen, Variablen schreiben - völlig oldscool…)
Läuft…

Wie würde das nun mit MQTTSync laufen.
Auf dem HeizungsPI hab ich MQTT eingerichtet, da ich damit eine Heizungssteuerung (Heishamon) abfrage.
Wenn das Haupt-IPS System nun Daten von dem HeizungsPI möchte, dann ist der HeizungsPI der MQTT Server, oder?
Und auf das Haupt-IPS kommt dieses neue Modul MQTTSync von Kai?

Auf beiden Systemen installierst du das Modul.
Dann gibt es einen Konfigurator für den Server und einen für den Client.

Auf dem Heizungs Pi installierst du den Server Konfigurator, auf dem Hauptsystem dann den Cloent Konfigurator.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Moin,

ja die Frage was ist sinnvoll Client und Server ging mir auch schon durch den Kopf :eek:

Aus dem Bauch heraus würde ich jeweils den Sender als Client sehen :wink:

Optisch wäre mir aber eher sehr wichtig :slight_smile: dass man den MQTT-Client eher unter jede Variable positioniert und faktisch die Parent-ID (Value) überträgt :wink: Optimal wäre dann, wenn man noch den jeweiligen Empfänger (MQTT auf IPS-Server) auswählen kann :wink:

Zum besseren Verständnis habe ich mal ein Screenshot angehangen (optimal wäre, wenn die Scripts „ZurHaussteuerungSenden“ bzw. „ZurHeizungSenden“ durch MQTT-Client-Objekt ersetzt werden könnte :slight_smile:

Ciao
HerbertF

Hast du dir das Modul schon angeschaut?
Denn alls im Konfigurator zu haben, sehe ich als einzig richtigen Weg.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Hi Kai,

bin gerade am Testen - auf den zweiten Blick gefällt es mir viel besser :wink:

Habe jetzt 3 IPS-Clients erfolgreich dazu gebracht Daten zur Zentrale zu senden. Kleine Anmerkung anbei, die Text-Länge im MQTT-Server-Konfigurator ist für den MQTT-Topic scheinbar begrenzt (bei zu langen Texten kommt kein Fehler, aber es werden keine Variablen/Werte übertragen).

Ebenso ist es mir gelungen die andere Richtung einzurichten :slight_smile: Habe im Kopf etwas länger gebraucht um zu erkennen, dass es für jede Verbindung nur einen MQTT-Client und einen MQTT-Server aber jeweils zwei MQTT-Sync-Konfiguratoren braucht :rolleyes: Ist aber eigentlich logisch :banghead:

Mit der Profilübertragung (per se tolles Feature) habe ich noch irgendwelche Probleme, vermutlich wenn es den Profilnamen schon gibt, wird er nicht zugewiesen - habe ich aber nicht weiter analysiert :frowning:

Interessieren würde mich noch der Fehlerfall. Wird bei keiner erfolgreichen Verbindung (bei fehlender Quittung) nach Wiederherstellung alles erneut gesandt?? Muss bzw. kann man die Eventcontrol hierfür nutzen?

Nicht zuletzt :wink: ich überlege ernsthaft meine ganzen RPC-Scripte zu ersetzen - tolle Arbeit - vielen Dank.

Ciao
HerbertF

Wir müssten da mal gemeinsam schauen, was geht und was nicht.
Für meine Zwecke lief es bis jetzt perfekt.

Kannst du mir ein Beispiel geben, wann nichts übertragen wird?
Bei den Profilen sollte eigentlich kein Problem auftauchen, auch wenn es die Profile schon gibt, dürfte es keine Fehler geben.

Grüße,
Kai

Da warte mal lieber noch ein bischen.:smiley:
Ich habe auch noch einige wenige RPC-Scripte neben MQTT am laufen.
Da ich dann auch immer Kai’s neue Dinge probiere, hängt auch mal ab und an was. Aber das in normal, jeder macht Fehler.

Das mit dem Profilnamen, wo siehst du das ? Habe da so eine Vermutung.:smiley:
Glaube das Profil ist schon richtig…

Hi Kai,

habe jetzt noch einen Client angebunden und etwas künstlichen Traffic erzeugt :smiley:

Nach dem Shutdown vom IPS-Dienst (auf dem Client) geht auf dem Server die Instanz ordentlich auf Störung und kommt nach Restart auch wieder - sollte mir eigentlich reichen.

Was ich jetzt in meinem Test nicht ausprobieren konnte und auch aus Deiner Doku nicht lesen :wink: - werden denn in dem Fall ALLE Variablen neu übertragen oder nur die, welche sich nach Wiederverfügbarkeit ändern (letzteres wäre eher schlecht:eek:)

Ciao
HerbertF

PS: Die Anmerkung vom tomgr hinsichtlich Stabilität ist schon richtig und wäre bei dem Modul essentiell - dies müsste m.E. über Beta und Stable sichergestellt werden - oder ???

Nur wenn die Variablen sich ändern, aber das kann man ja noch anpassen.

Die Stabilität sollte man auf Dauer mal testen.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Meine erste Idee wäre - man kann auf die Splitter-Instanz oder auf den Konfigurator einen Befehl zum Senden aller Variablen auslösen - dann könnte man dies bestimmt über die EventControl oder auch direkt per Ereignis aufrufen.

Ciao
HerbertF

Ich habe da schon eine Idee, ich schaue mir das mal an.
Sobald sich ein neuer Client verbindet sollte man die Variablen senden. Ich muss mal schauen, ob das geht.

Grüße,
Kai

Gesendet von iPhone mit Tapatalk

Moin,

das wäre top.

Nochmal eine Frage "retain"im MQTT-SyncServer bedeutet genau was? Schließt er dann die Verbindung nicht ?

Ciao und besten Dank
HerbertF

Dann werden die Nachrichten mit dem retain Flag versendet, dies bedeutet, dass sobald sich ein neuer Teilnehmer anmeldet, bekommet er die letzte gespeicherte MQTT Nachricht zu dem Topic.

Grüße,
Kai

Hallo zusammen,

ich habe vor eine Variable zwischen zwei Servers zu syncronisieren. Dazu habe ich jeweils MQTT Server und Client Konfigurator installiert und eingerichtet - sieht für mich soweit fehlerfrei aus. Allerdings sind nun die „Fenster“ mit den Themen sowohl bei Client als auch Server leer? (auch wenn ich auf aktualisieren klicke) Was muss ich als nächstes tun?

Viele Grüße und besten Dank
Peter

Du musst die Variable zuerst dem Client zuordnen, dann taucht sie auch beim Server auf und kannst sie dort auch einer Variablen zuordnen.

Vielen Dank - hat geklappt

Hallo Kai,

stehe hier noch etwas auf dem Schlauch was die Einrichtung angeht…

Wenn ich etwas von einem „Subsystem“ auf ein „Hauptsystem“ senden möchte, dann muss auf dem Subsystem der Client installiert werden und auf dem Hauptsystem der Server??

Sollte das auch mit der magicip-Adresse über den Connect-Dienst funktionieren oder nur im gleichen Netzwerk?

Joachim

Im gleichen Netzwerk funktioniert das mit Server und Client, mit VPN habe ich noch nicht probiert. Sollte theoretisch aber gehen. Über den Connect Dienst werden das sicherlich zu viele Aufrufe.