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

[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)

[mickym]

@humidor Der Broker published die topics an die Clients, die dieses topic verwendet haben.

Der Broker liefert die Information unter N/... (N bedeutet? notification?) Nein - der Broker sendet/published seine Information an alle Clients, die ein topic subscribed abonniert haben. Dein Vectron OS/ Cerbo (keine Ahnung wer das wirklich macht) ist auch ein mqtt-Client, der alles unter R/ und W/ subscribed hat, also abonniert hat.
Was R/N/W bedeutet weiß ich auch nicht. Aber stell Dir vor Deine Batterie oder das Betriebssystem ist auch ein mqtt-client, wie jeder andere Client auch.

Betrachte den mqtt-Broker einfach als eigene Einheit - die NIEMAND gehört.

Deine Batterie/Vectron/Cerbo subscribed einfach alles was unter R oder W steht. - Die Batterie macht also das Gleiche wie eine mqtt-IN Node, die folgende topics abonniert:
R/#
und eine zweite mqtt-IN Node, die
W/#
abonniert.

Das etwas unter R oder W schreibt sind keine allgemeingültigen topics, sondern jedes Gerät kann selbst festlegen auf welche topics es hört.
R könnte so was wie Read für den Cerbo mqtt Client bedeuten, sprich wenn das jemand beschreibt
W könnte Write bedeuten also etwas an das Cerbo zu schicke
N könnte Notification bedeuten -
Das ist aber alles nicht wichtig - weil das Cerbo das einfach so festlegt.

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

Nein das ist schon wieder verkehrt. Der Broker liefert keine Informationen. Der Cerbo/Batterie ist ebenfalls ein mqtt-client, der published Information unter dem N topic an den Broker. - Der Broker verteilt diese Information an alle, die das topic subscribed haben.
Umgekehrt subscribed Cerbo/Batterie alle topics die unter W und R veröffentlicht werden. Dabei legt der Cerbo selbst fest, dass alles was unter R gepublished wird - Informationen anfordert und alles was unter W gepublished wird, da muss der Cerbo was machen.

Also betrachte den Broker als eigene Einheit, die Informationen entgegennimmt und die Information an alle weiterleitet, die dieses Topic subscriebd haben.

[Humidor]

@mickym ich muss schon verstehen wo der Client liest und wo er schreibt, das hab ich noch nicht restlich verstanden

Der Broker - die Datenkrake - published.

Der Client - der Informationslieferant - published und subcribed.
subscribed vom Broker um Infos aus der Datenbank zu erhalten (N/...)
oder um Befehler zu erhalten (W/...)

• wo published der Client? R/.. ?
  

[mickym]

@humidor R publishst Du in dem Du mit NodeRed als mqtt Client ein topic unter R beschreibst. Zum Beispiel den keepalive Datenpunkt. Der mqtt Client Cerbo subscribed die topics unter R und published die Informationen unter dem N topic.

Das hast Du doch schön in Deinem mqtt-Instanzen gesehen. Am Anfang war nur der N-Ast da, dann hast Du mit NodeRed oder einem andern mqtt-Client den R Ast beschrieben und dann wurden alle geforderten Informationen vom Cerbo Client in den N Ast gepublished

Den mqtt topic unter R zu beschreiben dazu brauchst Du im Übrigen kein NodeRed. Du kannst direkt im mqtt-Adapter in den Objekten den keepalive Datenpunkt beschreiben. Das kannst Du auch mit Blockly machen, falls Dich das ganze NodeRed verwirrt.

Um den R-keepalive zu beschreiben brauchst Du auch KEIN Node-Red - sondern das geht auch mit den mqtt-Instanzen im iobroker und Puzzleteilchen.

oder Du schreibst den Wert direkt in der Objektansicht des Admin Adapters im iobroker.

Du musst also nicht NodeRed lernen, wenn Du nicht willst und lieber über Puzzleteilchen über mqtt mit Deiner Batterie kommunizieren willst.

Lange Rede kurzer Sinn - wenn Du kein NodeRed nutzen willst um via mqtt mit Deiner Batterie zu kommunizieren, dann musst Du nicht.

[Humidor]

@mickym ja, ich sagte ja, nicht restlich verstanden

Node Red ist schon OK, ich kenne Json nicht, aber bin interessiert es zu lernen. Andere Möglichkeiten, wenn mans kapiert ev. einfacher für komplexe Aufgaben als in Blockly.
Blockly war meine bisherige Heimat, hat aber auch seine Grenzen.

Die Topology Mqtt ist mir jetzt szsg bekannt, lese gerade das Doc dazu.

Eigentlich ist Mqtt nicht dazu da, dass der Client Aktionen am Broker startet, so mein Verständis. Man misbraucht es um Werte oder Anweisungen zu übergeben, in meinem Fall.

In meinem System liegt der Broker am Gerät das gesteuert werden soll, somit missbrauche ich den Broker um Anweisungen an das OS bzw. Gerät zu übergeben.

Am Ende mache ich es bewusst den Rest ignoriere ich.

Ich möchte es jetzt schon verstehen und wissen, wie ich aus Node-Red meine Befehle übergebe, das aber so, dass ich das Protokoll nicht verletze oder zerstöre.
Ob ich es dann noch in Blockly realisieren werden, ist dzt. noch offe.

[mickym]

@humidor

Eigentlich ist Mqtt nicht dazu da, dass der Client Aktionen am Broker startet, so mein Verständis. Man misbraucht es um Werte oder Anweisungen zu übergeben, in meinem Fall.

Nein Du missbrauchst da gar nichts - sondern das ist ganz normale Kommunikation.

Dein Cerbo/OS nutzt einen mqtt Broker, um mit der Aussenwelt zu kommunizieren. Du nutzt halt keinen externen Broker - sondern der Broker mit dem Dein Cerbo/OS kommuniziert ist halt festgelegt und fest verdrahtet und befindet sich auf der gleichen Maschine.

Es wird nichts missbraucht.

Tasmota/Shellies alles was mit mqtt funktioniert auch nach diesem Prinzip. Die Shellies hören auf bestimmte topics und führen dann entsprechende Aktionen aus oder publishen Infos. So schaut meine ganze Hausautomation im iobroker aus - da ich alles mit mqtt mache und weder Shelly/Sonoff/Zigbee Adapter nutze.