Ich bin jetzt schon mal einen Schritt weiter. Ich hatte vergessen, das neue USB Device (Sonoff) in den Container durchzureichen (hier beschrieben und Schritt 2: https://smarthome.buanet.de/2020/02/usb-devices-im-iobroker-docker-container-nutzen/).

Danach sah mein Log wie folgt aus (immer noch nicht gut).

zigbee.0
	2022-01-26 21:10:34.938	error	Error herdsman start
zigbee.0
	2022-01-26 21:10:34.937	error	Failed to start Zigbee
zigbee.0
	2022-01-26 21:10:34.935	error	Starting zigbee-herdsman problem : "Error while opening serialport 'Error: Error Resource temporarily unavailable Cannot lock port'"
zigbee.0
	2022-01-26 21:10:34.697	info	Installed Version: iobroker.zigbee@1.6.14
zigbee.0
	2022-01-26 21:10:34.671	info	Starting Zigbee npm ...
zigbee.0
	2022-01-26 21:10:34.669	info	Try to reconnect. 1 attempts left
zigbee.0
	2022-01-26 21:10:24.663	error	Error herdsman start
zigbee.0
	2022-01-26 21:10:24.662	error	Failed to start Zigbee
zigbee.0
	2022-01-26 21:10:24.659	error	Starting zigbee-herdsman problem : "startup failed - configuration-adapter mismatch - see logs above for more information"
zigbee.0
	2022-01-26 21:10:24.223	error	Re-commissioning your network will require re-pairing of all devices!
zigbee.0
	2022-01-26 21:10:24.222	error	If you wish to re-commission your network, please remove coordinator backup at /opt/iobroker/iobroker-data/zigbee_0/nvbackup.json.
zigbee.0
	2022-01-26 21:10:24.221	error	Please update configuration to prevent further issues.
zigbee.0
	2022-01-26 21:10:24.220	error	- Channel List: configured=11, adapter=11
zigbee.0
	2022-01-26 21:10:24.218	error	- Network Key: configured=01030507090b0d0f00020406080a0c0d, adapter=01030507090b0d0f00020406080a0c0d
zigbee.0
	2022-01-26 21:10:24.217	error	- Extended PAN ID: configured=c1addd4bc9e2addd, adapter=00124b0024c8b9c2
zigbee.0
	2022-01-26 21:10:24.216	error	- PAN ID: configured=5782, adapter=5782
zigbee.0
	2022-01-26 21:10:24.215	error	Configuration is not consistent with adapter state/backup!
zigbee.0
	2022-01-26 21:10:23.952	info	Installed Version: iobroker.zigbee@1.6.14
zigbee.0
	2022-01-26 21:10:22.980	info	Starting Zigbee npm ...
zigbee.0
	2022-01-26 21:10:22.749	info	starting. Version 1.6.14 in /opt/iobroker/node_modules/iobroker.zigbee, node: v14.18.3, js-controller: 3.3.22

Aber dieser Hinweis hat dann weitergeholfen:

zigbee.0
	2022-01-26 21:10:24.217	error	- Extended PAN ID: configured=c1addd4bc9e2addd, adapter=00124b0024c8b9c2

Habe dann in den Adaptersettings die PAN ID geändert und das Ergebnis sieht jetzt gut aus

@marc-berg Danke, dass war der entscheidende Hinweis.

Für alle anderen, hier direkt die Lösung:
Der "Button" im Shelly wird über das Topic relay/0/command mit dem Befehl on aktiviert. Da dieses Topic bei mir bisher nicht exisiterte, habe ich es einfach (mit einem beliebigen MQTT Client) geplublished.

@mcu DONE

@deralff Ja wirklich gut. Und das erste Pairing hat jetzt auf Anhieb funktioniert.

Danke an alle!!

@mcu said in Garagentor mit Shelly öffnet sich nach Neustart:

Wie sind denn die Einstellungen im MQTT?

Das war vermutlich der entscheidende Hinweis.

Ich hatte die Checkbox Publish own states on connect aktiviert. Da das Topic shellies/eg_garage_tor/relay/0/command ja praktisch immer auf "on" steht, wurde dieses Topic beim Connect gepublished, was zum Öffnen des Garagentors führte.

@mcu said in MQTT Befehl publishen per Button in Jarvis:

@kraxelhuber Stellst du bitte alle notwendigen Bilder(jarvis) und auch das Blockly als Export rein, ich nehme es dann mit in die Doku auf. Danke.

User-defined button:

Blockly script, welches eine MQTT message versendet, um das Garagentor zu öffnen/schließen.

<xml xmlns="https://developers.google.com/blockly/xml">
  <block type="on_ext" id="v3k}0IJYeg%f#Q_X{$7j" x="-87" y="-62">
    <mutation xmlns="http://www.w3.org/1999/xhtml" items="1"></mutation>
    <field name="CONDITION">any</field>
    <field name="ACK_CONDITION"></field>
    <value name="OID0">
      <shadow type="field_oid" id="frWa5)|+yq0%F[zz^aSY">
        <field name="oid">0_userdata.0.garage</field>
      </shadow>
    </value>
    <statement name="STATEMENT">
      <block type="sendto_custom" id="Jk@yEg*?oRGz[ovksWQM">
        <mutation xmlns="http://www.w3.org/1999/xhtml" items="topic,message" with_statement="false"></mutation>
        <field name="INSTANCE">mqtt.0</field>
        <field name="COMMAND">sendMessage2Client</field>
        <field name="LOG"></field>
        <field name="WITH_STATEMENT">FALSE</field>
        <value name="ARG0">
          <shadow type="text" id="o2pI)aO9s-J7dm,Vt)$N">
            <field name="TEXT">shellies/eg_garage_tor/relay/0/command</field>
          </shadow>
        </value>
        <value name="ARG1">
          <shadow type="text" id="81sL8f/h7MmvC?9-0p;X">
            <field name="TEXT">on</field>
          </shadow>
        </value>
      </block>
    </statement>
  </block>
</xml>

Gerät in Jarvis:

Die Idee mit der zweiten Instanz hat wunderbar funktioniert. Falls also jemand sonst noch auf dieses Problem stößt, ich habe es wie folgt lösen können.

Ich habe bei mir im lokalen Netzwerk einen MQTT Broker (Mosquitto) als Docker Container laufen. Dieser ist völlig unabhängig vom ioBroker und bekommt die Zustände aller meiner MQTT-fähigen Geräte übermittelt. Im ioBroker habe ich dann den Adapter MQTT Broker/Client in zwei verschiedenen Instanzen installiert und jeweils die IP in den Adaptereinstellungen auf Client/subscriber gestellt. Damit kann ich dann innerhalb des ioBroker die gewünschten Topics abonnieren.

1. Alle Geräte, die kein /set Topic benötigen (z.B. alle Tasmota Geräte), werden unter einem bestimmten Topic veröffentlicht, z.B. tasmota/#. Dieses Topic wird von der MQTT.0 Instanz mit folgenden Einstellungen abonniert.
   
   
   

2. Alle Geräte, die ein /set Topic benötigen (z.B. ZWave Geräte), werden unter einem bestimmten Topic veröffentlicht, z.B. zwave/#. Dieses Topic wird von der MQTT.1 Instanz mit folgenden Einstellungen abonniert.
   
   
   

Damit ist es also auch nicht nötig einen zweiten MQTT Broker (Mosquitto) im Netzwerk zu betreiben.

@arteck @Homoran @MartinP Danke für eure Unterstützung!

@homoran said in MQTT Zielkonflikt ZWave vs. Tasmota:

@martinp oder den mqtt-client verwenden, da muss dann jedem State das entsprechende Topic für publish und abonnieren konfiguriert werden

Das muss ich mir in Ruhe anschauen. Du sprichst also wirklich vom MQTT Client Adapter?

Ich habe bis dato den MQTT Broker/Client Adapter installiert.

@martinp said in MQTT Zielkonflikt ZWave vs. Tasmota:

Wenn der Mosquitto-Broker die Daten unmodifiziert durchreicht, ist mir seine Rolle nicht so ganz klar ... ansonsten wäre er für ein Mapping zuständig.

Und hier hören dann meine MQTT Kenntnisse vermutlich auf bzw. ich verstehe nicht ganz worauf du hinaus willst?
Mosquitto reicht alle Datenpunkte eines Gerätes durch bzw. vom ioBroker aus abboniere ich bestimmte Topics. Die Datenpunkte kann ich dann in ioBroker ganz normal verwenden.

Anscheinend gibt es hier noch ein anderes (besseres?) Vorgehen?

Ich dachte eigentlich die Idee mit zwei Instanzen klingt sinnvoll. In einer Instanz kann ich dann in den Einstellungen auswählen, dass verschiedene Topic Namen für Set und Get verwendet werden (ZWave) während ich es bei der anderen Instanz deaktiviert lasse (Tasmota).

Die eigentliche Frage, die ich mir gestellt hatte war, ob ich tatsächlich einen weiteren MQTT Broker (Mosquitt, extern als Docker Container) benötige, der auf einem anderen Port (z.B. 1884) läuft?

@martinp said in MQTT Zielkonflikt ZWave vs. Tasmota:

@kraxelhuber Was GENAU läuft da in dem Container? Nutzt Du einen vorgeschalteten externen Broker (z. B. Mosquitto) vor dem MQTT Broker/Client von ioBroker? Wenn ja, warum?

Im Container läuft ein Mosquitto Broker. Ich habe den MQTT Broker gerne unabhängig von ioBroker. So kann ich die Daten auch in anderen Systemen verwenden.

@homoran said in MQTT Zielkonflikt ZWave vs. Tasmota:

ist dir die Funktionsweise von MQTT bekannt?

Ich bin sicherlich kein Experte, aber ich betreibe seit langem etliche Tasmota und Shelly Geräte via MQTT innerhalb von ioBroker.

Habe ich vorhin etwas falsch verstanden? Kläre mich gerne auf

@martinp said in MQTT Zielkonflikt ZWave vs. Tasmota:

Du legst zwei Instanzen des MQTT Broker/Client Adapters an (mit unterschiedlichen Portnummern konfiguriert!)

Das war meine Frage. Mit MQTT Server meinte ich folgendes: MQTT läuft bei mir als Docker Container auf Port 1883. Muss ich jetzt einen zweiten MQTT Container (z.B. auf Port 1884) anlegen? Das schließe ich aus deiner Antwort.

Ich hatte alternativ daran gedacht weiterhin nur einen einzigen MQTT Container zu betreiben und die beiden MQTT Adapter Instanzen auf verschiedene Topics anzusetzen, z.B. smarthome/tasmota/# und smarthome/zwave/#. Das kann ich ja in den Adapter Einstellungen unter "Client settings" vergeben.

@martinp @arteck
Daran hatte ich nicht gedacht, klingt aber logisch.

Es ist dann aber doch ausreichend, dass ich die jeweiligen Instanzen auf bestimmte MQTT Topics beschränke? Ich brauche keinen zweiten MQTT Server, oder?

Hallo zusammen,

ich würde gerne so viele meiner Geräte wie möglich per MQTT steuern. Tasmota Geräte laufen bei mir traditionell bereits über MQTT. Nun habe ich auch per ZWave-JS-UI die Steuerung meiner ZWave Geräte auf MQTT umgestellt.

Innerhalb des ioBroker stoße ich dabei allerdings auf folgendes Problem:

Schaltbefehle für ZWave Geräte werden i.d.R. an einen Kanal gesendet, dem noch ein /SET Topic angehängt wird. Im MQTT Adapter kann man daher einstellen, dass der ioBroker diese Unterscheidung zwischen Reading und Publishing (/SET) selbstständig übernimmt.

Tasmota Geräte haben zur Steuerung auf der anderen Seite einen eigenen PUBLISH Kanal. Hier mal am Beispiel einer schaltbaren Steckdose: cmnd/POWER

Wenn ich also die Option im MQTT Adapter aktiviere, laufen meine ZWave Geräte, während Tasmota den Dienst versagt, und umgekehrt.

Hier liegt also ein Zielkonflikt vor.

Was kann man hier tun?

@peppino said in [gelöst] ZWave über MQTT steuern:

Da der Zwave2-Adapter schon länger nicht mehr aktualisiert worden ist, bin ich auch auf die Konstellation "Zwave-JS-UI <--> MQTT <--> IoBroker" umgestiegen.

Ich steige auf ZWave-JS-UI um, damit ich den Controller auch von anderen Systemen (z.B. irgendwann evtl. einmal Home Assistant) aus nutzen kann.