UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Ben1983]

@mickym ich habe eben gedacht nur ein Broker ist möglich, da er den Port belegt. Deswegen ist der Shelly standardmäßig auf 1882

[mickym]

@ben1983 sagte in Victron MP2 MQTT Anbindung:

Liegt es daran, das ich „#“ subscibt habe?

Ja - jeder Broker sendet an alle Clients die ein topic oder mehrere subscribed haben, die Daten die es interessiert. Und wenn Du an allem interessiert bist machst Du ein #.

Ein Broker verwaltet also nur die Kommunikation an die Clients und an diese sendet er auch aktiv.

[mickym]

@ben1983 sagte in Victron MP2 MQTT Anbindung:

@mickym ich habe eben gedacht nur ein Broker ist möglich, da er den Port belegt. Deswegen ist der Shelly standardmäßig auf 1882

Das hat der Entwickler einfach mal gemacht, da leider !!! viele Adapter keinen externen Broker erlauben (zigbee2mqtt ist da die erste löbliche Ausnahme) und selbst einen Broker simulieren (shelly, sonoff, mqtt, owntracks). In diesem Fall kommt es aber zu einem Port Konflikt, da alle Adapter ja auf der gleichen Maschine laufen. Wenn also ein Gerät einem Broker auf der IP-Adresse x unter dem Port 1883 sendet, wer soll denn bitte darauf antworten? Sonoff, shelly oder wen hätten sie denn gerne?

Also JA - auf EINEM Gerät mit EINER IP-Adresse kann es nur EINEN Broker geben. In einem NETZ kann es aber beliebig VIELE Broker mit jeweils EIGENER IP-Adresse geben. Es ist also ganz generell in einem TCP/IP Netz so, dass auf der Empfängerseite die Eindeutigkeit durch IP-Adresse und Port durch ein bestimmtes Programm oder Prozess gegeben sein muss!

[Ben1983]

@mickym ah ok. Top erklärt. Danke

[Ben1983]

@mickym eine Frage noch.. es braucht immer einen Broker… Client <=> Client geht nicht, oder?

[mickym]

@ben1983 sagte in Victron MP2 MQTT Anbindung:

@mickym eine Frage noch.. es braucht immer einen Broker… Client <=> Client geht nicht, oder?

Richtig. Der Broker koordiniert immer die Kommunikation. Ohne den gehts nicht. Die Kommunikation eines MQTT-Clients ist immer 1:1 zu einem Broker, der Broker hingegen baut eine 1:n Kommunikation zu allen Clients auf, die sich verbunden haben und topics abonniert haben.

Im Prinzip braucht es immer ein Broker als Koordinator, der sich merkt woher eine Information kommt und wer daran interessiert ist und an wen er die noch schicken muss und gerade auch wenn ein MQTT-Client offline ist. Das ist ja der Vorteil gegenüber einer normalen HTTP oder TCP Kommunikation. Der Client muss sich nicht darum kümmern, wann und wie seine Info beim Empfänger ankommt. Sobald ein Client wieder online ist, sendet der MQTT-Broker die aktuellste Information zu einem topic, so dass dieser wieder auf neuestem Stand ist.
Das ist eben der Riesenvorteil gegenüber einer normalen HTTP oder sonstigen Kommunikation. Wenn da der Empfänger offline ist, dann hat er halt Pech gehabt.
Andererseits gibt so ein MQTT-Adapter im iobroker nie den tatsächlichen Status wieder. Das muss man immer im Hinterkopf haben. Wenn Dein mqtt-Adapter (Retain nachrichten ausgeschlossen, die verarbeitet der MQTT Adapter nach meiner Erfahrung aber eh nicht richtig) eine Nachricht empfangen hat, dann ist diese bei ihm gelöscht. Wenn alle Clients die Nachricht empfangen haben, wird sie komplett gelöscht, im Adapter sind sie aber noch vorhanden.

[Ben1983]

@mickym ok.
Und wenn jetzt Client a eine topic von Client b subscribt hat, leitet der Broker das an a weiter, wenn b diese published.
Und kann auch Client a die topic (bspw.)
b/topic schreiben und b übernimmt diese. (Vorausgesetzt es ist so in b implementiert).???

Also subscribt b automatisch seine gepublischten topics?

[mickym]

@ben1983 sagte in Victron MP2 MQTT Anbindung:

@mickym ok.
Und wenn jetzt Client a eine topic von Client b subscribt hat, leitet der Broker das an a weiter, wenn b diese published.

das ist schon wieder die falsche Formulierung. Die Clients kennen sich nicht untereinander. Sprich der Client a subscribed ein TOPIC - egal wer dieses beschreibt. Wenn also b oder c oder d dies published, wird a wenn es diesen topic subscribed hat, informiert.

Und kann auch Client a die topic (bspw.)
b/topic schreiben und b übernimmt diese. (Vorausgesetzt es ist so in b implementiert).???

Genau jeder Client kann jedes topic beschreiben und b übernimmt dies nur, wenn er das topic subscribed hat. Nur würde es in diesem Fall zu einer Endlosschleife kommen und Dein System hängt sich auf. Da wenn ein Client ein topic published und gleichzeitig subscribed gibt es eine Endlosschleife. Deswegen wird client b - nicht dieses topic publishen, wenn es dieses subscribed. Deswegen hast Du auch unterschiedliche topics beim Senden und Empfangen. Deswegen musst Du auch die Datenpunkte selbst anlegen, auf die ein Client hört, da es nicht topics publishen kann, die es selbst subscribed. Das ist für viele eine Hürde am Anfang, wenn sie zum Beispiel statt des Shelly Adapters - MQTT verwenden, da sie die Datenpunkte zum Steuern selbst anlegen müssen. Aber jetzt verstehst Du vielleicht warum und verstehst auch warum Du den keepalive DP selbst anlegen musstest. Wie gesagt die meisten Implementierungen sorgen inzwischen selbst dafür, dass die topics zum Steuern und die für Informationen unterschiedlich sind.
Im mqtt-Adapter gibt es noch eine alte Einstellung, die aber heute eher nicht brauchbar ist.
Es handelt sich um diese Option:

Wenn man das angehakt hat wird die Info nicht unter dem eigentlichen topic gepublished, sondern unter topic/set.
Nur wenn der Empfänger nicht auf topic/set hört, dann hilft das natürlich nicht.

Also subscribt b automatisch seine gepublischten topics?

Nie im Leben, es würde wie gesagt Endlosschleifen geben.

Die würde es auch im iobroker selbst geben, wenn hier nicht mit dem ACK-Flag gearbeitet würde, das gibt es aber unter MQTT nicht.
Im iobroker kannst Du deshalb ohne Endlosschleifen mit einem Datenpunkt arbeiten, da Du zum steuern immer ACK=false nutzt und der Adapter den Vollzug mit ACK=true bestätigt. Unter MQTT muss das in verschiedenen topics erfolgen.

[Ben1983]

@mickym ok.
Also in meinem Fall wäre ja auch der Adapter ein Client, der die Topics vom Broker (GX) subscribt.
Möchte ich also dieNetzleistung schreiben nicht lesen, benötige ich einen anderen Topicnamen, als den der zum Lesen ist. Ok…. Also weis man den nicht, schade.

[mickym]

@ben1983 sagte in Victron MP2 MQTT Anbindung:

Ok…. Also weis man den nicht, schade.

Ja wie die heißen muss der Hersteller in seiner API beschreiben. Das ist nicht selbsterklärend - ausser der Hersteller hat halt ein allgemeines Schema - wo du über einen topic verschiedene Parameter steuern kannst. Meist schickt man dann JSON Objekte an dieses topic. So kannst Du besipielsweise mit Zigbee2mqtt

{"state":"on","brightness":50)

gleichzeitig die Lampe mit 50% Helligkeit einschalten und brauchst dafür nicht 2 Befehle.

[Homoran]

@mickym sagte in Victron MP2 MQTT Anbindung:

ein GX Gerät (was auch immer das ist) i

das ist ein Gerät auf dem das Venus OS läuft und die Zentrale eines Victron Systems ist.

[mickym]

@homoran sagte in Victron MP2 MQTT Anbindung:

@mickym sagte in Victron MP2 MQTT Anbindung:

ein GX Gerät (was auch immer das ist) i

das ist ein Gerät auf dem das Venus OS läuft und die Zentrale eines Victron Systems ist.

Gut und wenn ich mehrere Victron Systeme habe (weiß nicht ob das Sinn macht ) - dann habe ich halt auch mehrere GX Geräte und somit auch mehrere MQTT-Broker.

[Homoran]

@ben1983 sagte in Victron MP2 MQTT Anbindung:

@mickym eine Frage noch.. es braucht immer einen Broker… Client <=> Client geht nicht, oder?

lies dich mal ein, wie schon @mickym geschrieben hat!

Das MQTT-Protokoll erfordert einen Datenbroker. Dies ist die zentrale Idee der Technologie.

https://www.iobroker.net/#de/adapters/adapterref/iobroker.mqtt/README.md

einiges steht auch im GX Handbuch von victronenergy.de

[Fichtendickicht]

@mickym
Lieber mickym.
Ich habe mit großem Interesse all Deine Post gelesen, scheinbar fehlt mir da noch ein wesentlicher Punkt.
Ich habe auch ein Victron System mit einer "Venus GX" (Visualisierungs Zentrale von Victron mit LAN, MODBUS und MQTT) sowie einer Synology mit IO-Broker-Docker.
Die Modbus Verbindung läuft seit Jahren ist aber nicht gut zu warten und Victron ändert da immer wieder Adressen also will ich auf MQTT umsteigen.
@Homoran hat bereits herausgefunden, dass die Venus ein MQTT-Broker ist. Also Habe ich einen MQTT-Adapter als Client angelegt und die Verbindung hergestellt.
Als Subscription ist # voreingestellt und ich bekomme bereits das hier angezeigt:

Wie subscribe ich nun all die anderen Werte?
Angeblich sollen alle verfügbaren Werte mit dem '#' angezeigt werden - tun sie aber nicht.

[Ben1983]

@fichtendickicht Du musst dem Victron das KeepAlive setzen.
ich habe dazu alle 30s einfach "" gesxhrieben.
das funktioniert und er liefert alle anderen daten.

schedule('*/30 * * * * *',()=>{
    setState("mqtt.0.R.c0619ab24727.keepalive","");
});

natürlich musst Du vorher diesen state anlegen.

[Fichtendickicht]

@ben1983 said in Victron MP2 MQTT Anbindung:

schedule('*/30 * * * * *',()=>{

Danke für Deine rasche Antwort. Ich denke da hakt´s bei mir.
Wie lege ich den Datenpunkt an?
Wo gebe ich Deine Befehlszeile ein?
Ich verwende auch den MQTT Explorer:

[mickym]

@fichtendickicht mit dem Mqtt Explorer publishst du einfach ein topic. In dem Fall von Ben wäre das Topic

R/c0619ab24727/keepalive

Sobald einmal gepublished dann taucht der DP im Adapter auf. Du musst ihn nur unbestätigt beschreiben

[Fichtendickicht]

@mickym said in Victron MP2 MQTT Anbindung:

keepalive

das "keepalive" gibt´s wohl schon:

Und wie beschreibe ich den Punkt? Mit Blockly?

[mickym]

@fichtendickicht mit Blockly oder JavaScript. Mit NodeRed kannst auch direkt ohne iobroker beschreiben. Aber der Datenpunkt sollte ja auch im Adapter auftauchen

[Fichtendickicht]

@mickym Ich bekomme es leider nicht hin. Hab einen Befehl abgesetzt wie @Ben1983

aber ich bekomme dadurch nicht mehr Datenpunkte: