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

[mickym]

@humidor Du hast doch weitere NOdeRed Systeme auf den anderen Systemen ? Da kannst Du das doch machen - da sind doch auch mqtt Nodes?
Und da schreibst Du halt in das test/topic woher er es kommt-

[Humidor]

@mickym auf jedem läuft ein Node-Red
du meinst ich soll vom Cerbo Node-Red auf das test/hallo auch was schreiben? ich bin vom Cerbo...

[mickym]

@humidor Genau vom Cerbo Node-Red publishst Du auf den Raspi und schaust ob Du es in der mqtt1 Instanz siehst.
Vom Raspi schickst du an den Cerbo und schaust ob Du es in der mqtt2 Instanz siehst.

[Humidor]

@mickym Ok, das funktioniert nicht

[mickym]

@humidor DOCH nicht server iobroker! - Die Broker sind doch jeweils auf dem anderen System. Du schickst nichts an den IOBROKER sondern an den jeweils anderen Broker

1. Vom NodeRed CERBO an den mqtt- Broker Raspberry!!!!!
2. Vom Node-Red Raspberry an den mqtt-Broker CERBO!!!

Die beiden Broker senden dann automatisch an den iobroker!! Das machst NICHT DU!!!
In Fall 1 siehst Du was Du vom Cerbo schickst im iob in mqtt Instanz 1
Im Fall 2 siehst Du was Du von Raspberry schickst im iob in mqtt Instanz 2

Ich schrieb doch DU sollst vom CERBO an den Raspberry schicken und nichts von iobroker!!

Ich hab doch in dem oder anderen Thread ein Schaubild geschickt wie ein mqtt Broker funktioniert. Warum schaust Du dir das nicht an!

[Humidor]

@mickym verstanden

ich habe jetzt das System bereinigen müssen, hat etwas gedauert

nun fkt. es, ioBroker überschreibt die Texte
senden vom Cerbo kommt im mqtt2 an
senden vom VenusOS kommt im mqtt1 an

weiß nicht welches Schaubild du meinst.

[mickym]

@humidor

senden vom Cerbo kommt im mqtt2 an
senden vom VenusOS kommt im mqtt1 an

Das passt doch nicht:

Wenn Du von Cerbo zu Venus OS schickst dann musst Du dass doch am mqtt 1 sehen und umgekehrt.

191 = Cerbo GC = dort hängt die Batterie
132 = Venus OS = Raspi = Empfänger der Batteriedaten

Also entweder Du machst nicht was ich sage oder die Kreuzkommunikation funktioniert nicht.

[Humidor]

@mickym vermutlich mach ich es noch falsch

am Cerbo Node Red, das ist ein Broker, soll ich an den Raspi Venus OS senden, so verstehe ich deine Worte - oder ist das falsch?

iobroker.mqtt 1 = Client auf Cerbo .191
iobroker.mqtt 2 = Client auf Raspi Venus OS .132

Abbildung meines aktuellen Systems:

ich sende vom Cerbo an den Venus OS

[mickym]

@humidor sagte in Mqtt zum Victron Cerbo GX ?:

am Cerbo Node Red, das ist ein Broker, soll ich an den Raspi Venus OS senden, so verstehe ich deine Worte - oder ist das falsch?

Das sind doch beides Broker. Die 195 lass mal aussen vor. Wenn Du von der 191 was auf die 132 schickst musst Du dass in der mqtt.2 Instanz sehen, wenn Du 132 was an die 191 siehst musst Du das in der mqtt.1 Instanz sehen.

Das sollst Du prüfen.

Die mqtt Instanzen auf dem iob bekommen das alles automatisch mit, da Du # subscribed hast.

[Humidor]

@mickym genau so ist es doch

[mickym]

@humidor Na gut - wenn dem so ist und Du nun weißt wie die Kommunikation funktioniert - dann müsstest Du ja auch das Objekt sehen, dass Du vor mehreren Tagen via mqtt gesendet hast - dann brauchst Du auch nichts monitoren, da automatisch das ganze Objekt in der entsprechenden mqtt Instanz auftaucht.

[mickym]

Sprich dass was hier https://forum.iobroker.net/post/1123751 gesendet hast, musst Du auch in der entsprechenden mqtt Instanz sehen, was Du aber am 3.2. verneint hast und damit muss auch nichts an den iobroker gesendet werden, da es automatisch auftaucht.

[Humidor]

@mickym schaue ich mir morgen an, bin kaputt

[mickym]

@humidor Ja gut - dann schlaf gut.

[Humidor]

@mickym vom Cerbo werden die Batteriedaten zusammengestellt und an das VenusOS gesendet

das "enphase/battery" müsste ich dann im ioBroker.mqtt.2 sehen, dass es dorthin gesendet wurde.

im ioBroker Objektbaum sehe ich davon noch nichts, das liegt aber nicht daran, dass die Daten nicht ankommen, denke die Anzeige im Objektbaum ist hier nicht vollständig
das wird auch sicher damit zusammenhängen, da ich schon Falscheinträge gelöscht haben, ev. war da auch das enphase am mqq2 dabei, die Frage jetzt, wie bekomme ich diese wieder zurück, normalerweise würde ich meinen, legt er es selbstständig wieder an, das scheint aber nicht so zu sein. Ich könnte den ganzen mqqt.2 Baum löschen, dann muss er alles wieder aufbauen

gemacht und siehe da, es ist gekommen

und es war falsch, der Node-Red vom Cerbo, ist ein Broker, dh die Node-Red Mqtt Out Node muss auf sich schauen
dann kommen die Daten im ioBroker.mqtt.1 an
der Client der virtuellen Batterie am VenusOS schaut auf den Cerbo Broker und holt sich die Daten
diese werden dann sofort angezeigt

aktualsierte Beschreibung:

was ich hier noch nicht verstehe, generiert die virtuelle Batterie hier einen Client oder geht sie über den Mqtt Master und holt die Daten vom Cerbo?

[Humidor]

@humidor denke ich habe es noch immer nicht verstanden, aber bin schon einen Schritt weiter, ich habe nochmal alles breinigt und mein Verständnis ist wie folgt:

vom ioBroker.mqqt(Client) schreiben wir direkt mit dem Node-Red Mqtt Out in den Cerbo ESS bzw. Cerbo BAT.
Was wir geschrieben haben zeigt der Objektbaum an, der vom ioBroker Client wieder eingelesen wurde.

Auf den Cerbos schreiben wir direkt in deren Broker rein, der published alles und die Clients (ioBroker, Cerbo GX BAT) können sich die Daten abholen.
.

.


.
.
.
.
ACHTUNG - das Venus OS ist nun aus dem System raus, da der 2. Cerbo bereit ist und die Umstellung habe ich soeben vollzogen! dh Venus OS am Raspi gibt es nicht mehr. Nun sind es Cerbo GX ESS und Cerbo GX BAT, am ESS hängt die echte Batterie, am BAT sind die Ladegeräte der Batterie mit den virtuellen Batterie-Infos.

[Humidor]

@humidor ich habe einen Weg gefunden, denke nicht, dass es der offizielle bzw. übliche Weg ist, mir scheint, dass meiner um die Ecke läuft

Ich habe eine VIS erstellt

aus den Variablen im ioBroker Blockly angelegt

im Node Red am ioBroker sende ich den Wert

am Node Red vom Cerbo ESS lese ich diesen Wert aus

es funktioniert, aber ist das der Weg ??

[mickym]

Nun - es gibt wahrscheinlich 1000 Wege - aber wenn Du die Basics nicht verstehst oder verstehen willst - dann hat das alles keinen Zweck. Du sollst auch nicht mit einer VIS nun irgendwas steuern - auch wenn Du das später kannst.

Diese blauen Nodes - damit kommunizierst Du direkt mit der Batterie oder Deinem Cerbo - die würde ich aber im 1. Schritt mal aussen vor lassen. Also bitte LASS diese blauen Nodes erst mal weg.

Lerne doch erst mal wie MQTT funktioniert und versuche jetzt nicht eine Batterie zu steuern. Ich hab Dir schon gesagt ich will und werde mich mit Deiner Batterie nicht beschäftigen, aber ich kann versuchen, dass Du ein Verständnis entwickelst.

Also Dein Schaubild - bitte präge Dir folgende Sachen einfach EIN für ALLEMAL ein, wenn Du die Kommunikation verstehen willst.

1. In einer MQTT-Kommunikation gibt es erst mal EINEN Mqtt-Broker und viele Clients. (Das ist die Mindesvorraussetzung).
2. Du hast in Deinem Netz ZWEI Mqtt Broker und viele Clients.
3. Es empfiehlt sich erst mal alle Kommunikationswege auszuprobieren und auch noch zu verstehen, was für Programme auf Deinen physischen Geräten laufen.
4. In einer MQTT Umgebung HOLT NIE ein mqtt-Client irgendwelche Informationen!!!!!!!!!
5. Ein MQTT Client published (veröffentlicht) Information an einen BROKER (nirgendwo anders hin) also nie an einen anderen Client.
6. Ein MQTT Client schickt an einen MQTT Broker an welchen topics er interessiert ist (grüne Pfeile im unteren Bild). Der MQTT-Client subscribed oder abonniert bestimmte Themen/topics.
7. Ein MQTT-Broker subscribed NIEMALS topics.
8. Ein MQTT-Broker published grundsätzlich an alle mqtt-Clients, die Themen, die diese Clients subscribed haben.

Ich bin mir auch sicher, dass ich in dem anderen Thread Dir dieses Bild schon mal gepostet habe:

Punkt 1: Iobroker auf dem physischen Gerät mit IP 192.168.0.20 hast Du derzeit folgende Clients am Laufen:

• 2 mqtt-clients in Form Deiner iobroker mqtt-Adapter Instanzen
• 1 mqtt Client als eine NodeRed Instanz.

Punkt 2: Auf deinem Cerbo ESS Gerät mit IP 192.168.0.191 hast Du:

• 1 mqtt Broker laufen (wird zukünftig einfach mqtt-Broker ESS genannt)
• 1 mqtt Client als eine NodeRed Instanz
• 1 mqtt Client Cerbo GSX ESS

Punkt 2: Auf deinem Cerbo BAT Gerät mit IP 192.168.0.195 hast Du:

• 1 mqtt Broker laufen (wird zukünftig einfach mqtt-Broker BAT genannt)
• 1 mqtt Client als eine NodeRed Instanz
• 1 mqtt Client Cerbo GSX ESS

Nun gilt folgendes:

• Dein mqtt Client- Instanz 1 hat alle Themen/topic Deines ESS mqtt Brokers abonniert/subsribed und kann auch Infos an den ESS-Broker veröffentlichen/publishen. - Ausprobieren !!!
  Du siehst also in der mqtt.1 immer alle Inhalt deines ESS-Brokers (191)- EGAL von welchem mqtt-client sie gepublished wurden.

• Dein mqtt Client- Instanz 2 hat alle Themen/topic Deines BAT mqtt Brokers abonniert/subsribed und kann auch Infos an den BAT-Broker veröffentlichen/publishen. - Ausprobieren !!!
  Du siehst also in der mqtt.2 immer alle Inhalt deines ESS-Brokers (195)- EGAL von welchem mqtt-client sie gepublished wurden.

• Jede Node-Red Instanz kann beliebige Information an beliebige topics an jeden mqtt Broker publishen (mqtt-Out Nodes mit entsprechendem mqtt Broker als Ziel).

• Jede von NodeRed mittels mqtt gepublished Information wird von dem entsprechenden Broker an alle Clients, die dieses topic abonniert haben gepublished. Deshalb erhalten die mqtt Instanz die sich als Client mit dem entsprechenden Broker verbunden haben - die entsprechende Information.

• Die Geräte (Batterie Cerbo OS oder keine Ahnung wie das heißt) sind in diesem System auch mqtt-Clients die mit dem mqtt-Broker auf dem jeweiligen Gerät verbunden sind. Also Deine Cerbo ESS mit dem mqtt Broker ESS. Auch wenn sich das auf der gleichen Maschine befindet sind das verschiedene Programme/Funktionen, sowie auf dem Gerät sich auch eine NodeRed Instanz befindet. Also auf der Maschine 191 - hast Du ein Cerbo/Victron OS, ein mqtt- Broker und eine Node-Red Instanz. Die NodeRed Instanz kann sich via mqtt-Out mit jedem mqtt-Broker der Welt verbinden.

• Das gleiche gilt für Dein Cerbo BAT Gerät. Dort gibt es auch einen mqtt-Broker ein mqtt-Client in Form Deinen Victron/Cerbo OS und eine NodeRed Instanz.

• Die blauen Nodes in den jeweiligen Node-Red Instanzen können wahrscheinlich direkt mit dem Cerbo OS reden und brauchen dazu kein mqtt.

• Die Cerbo mqtt clients kommunizieren mit dem mqtt-Broker auf dem physikalisch gleichen Gerät wie folgt:
  Sie publishen (veröffentlichen) alles unter den topic N/xxxxxxx/xxxx.

• Sie hören auf/subscriben von diesem mqtt-Broker alle Themen mit R/xxxx/xxx zum Lesen und zur Anforderung von Informationen die sie unter N/xxxx/xxxx veröffentlichen.

• Sie hören auf/subscriben von diesem mqtt-Broker alle Themen mit W/xxxx/xxx um bestimmte Aktionen auszuführen. Dabei müssen diese Informationen als Objekte mit der Eigenschaft value veröffentlicht werden (s. anderer Thread {"value": Wert}. Aktionen werden ggf. unter unter N/xxxx/xxxx quittiert.

Mehr kann ich Dir nun wirklich nicht sagen. Und nur wenn du das alles verstanden hast, dann kannst Du ggf. noch Fragen stellen - aber auf willkürliches ich mach mal - finde ich eher unproduktiv.

Insbesondere wenn du das alles verstanden hast - dann kannst Du nämlich auch wieder puzzeln und brauchst KEIN Node-Red auf Deinem iobroker um mit VIS was zu steuern.

[mickym]

@humidor Somit ist dieser Weg zwar prinzipiell ein gangbarer aber in diesem Fall völlig falsch.

In dem Mode gibst du die Zahl 1-4 ein. Das topic ist aber Schwachsinn - weil das nur Objekt versteht. Wenn Du schon mit den blauen Nodes arbeiten willst und mqtt austauschen willst, dann brauchst Dich an keine Konvention zu halten.

Dann kannst auch 1-4 an das topic test/hallo schicken - das mit einer mqtt-In Node abonnieren und dann an die blaue Node schicken. Das ist durchaus ein Weg - aber dann mach nicht den Schwachsinn, dass Du das mit der offiziellen mqtt Schnittstelle vermischst.

Du kannst die blauen Node nutzen und eine eigene mqtt Kommunikation aufmachen, aber Du sollst es tunlichst vermeiden beides zu machen.

Wie gesagt den Wert 1-4 an das topic test/hallo zu schicken und das mit einer mqtt-In node zu subscriben und an die blaue Node weiterzuleiten - kann man machen - aber dazu brauchst Du dann keine Konvention beachten.

Also im Grunde: VERWENDE die blauen Nodes NICHT zusammen mit der offiziellen mqtt-Schnittstelle

[Humidor]

@mickym da hast du mir wieder einige Fragen beantwortet, vielen Dank!
am Willen scheitert es ja nicht, sonst würde ich nicht hier sein und fragen, der Unterschied ist du bist auf der Theorieseite zu Hause - wie genau muss es funktionieren, ich bin auf der Praxisseite, gleich was realisieren, was ich suche bzw. brauche. Ich verstehe das. Für einen Tag Mqtt, hab ich doch schon was geschafft, der Rest wird auch noch, wie gesagt, am Willen scheitert es nicht und nein, das Bild kannte ich noch nicht, hast du vermutlich jemand anderen gezeigt und verwechselst das.

Werde mir deinen Beitrag noch öfter durchlesen, noch lange nicht habe ich alles verstanden oder verinnerlicht. Fragen kommen auf und müssen gestellt werden, damit die auch wieder aus dem Kopf raus sind, blockieren mich sonst. Deine Beiträge werfen so manche Frage schon aus. Auch deine Schreibweise, wenn von du "Sie" schreibts, ja wer ist das jetzt der Client oder Broker.
Vor allem sind es die korrekten Bezeichnungen. Wenn von Client subscribed gesprochen wird, heißt das eigentlich, dass er dem Broker was sendet (Anforderung für Daten oder Information die er weiter verteilen kann). Im Prinzip ist der Broker die Datenbank.

zum Verständnis:
Broker senden nur Informationen nach Aufforderung, dh der Client sendet die Aufforderung was er will, einen Wert, Topic oder alles.

Der Broker liefert die Information unter N/... (N bedeutet? notification?)

Der Client fragt beim Broker Informationen unter R/... ab (R bedeutet? request?)

Der Client liefert dem Broker Informationen unter W/.. ? (w bedeutet? write? to broker)