openhabforum.de

Hi zusammen,
hat schon mal jemand das Autodiscovery von TASMOTA in OH benutzt ?
Beschrieben u.a. hier: "https://community.openhab.org/t/oh3-tas ... ery/111630"

Ich habe hier einen TASMOTA Rolladenschalter, der für sich auch problemlos läuft.
Aber bei dem Zusammenspiel mit OH3 über das "Autodiscovery" funktioniert da gar nichts.

Ablauf: Ich sehe den Rolladenschalter als Thing in der INBOX der UI. Sobald ich es als Thing übernehme,
kommt im OH Log

Code: Alles auswählen

 "Label for a ChanneGroupType must not be empty.

Da ist aber weder eine Group noch ein Label, das ich editieren kann.

Weiter geht's:
Das 'Thing' ist irgendwie trotzdem da, nur von 3 Channels die TASMOTA erzeugt (cover, switch, sensor), erscheinen nur 2 (sensor, cover) im Thing.

Weiter geht's: Wenn TASMOTA seine Status Meldung schickt, kann OH nichts damit anfangen.

TASMOTA:

Code: Alles auswählen

 " … MQT: tele/RolladenWohnzimmer/HASS_STATE = {"Version":"9.5.0(tasmota)","…"

Kommt in OH:

Code: Alles auswählen

[WARN ] [ab.binding.mqtt.generic.ChannelState] - Command  " … … }}' 
	     not supported by type 'RollershutterValue': Cannot call update()  …

Ich hatte die Erwartung das TASMOTA und OH durch das Autodiscovery zusammenarbeiten und dadurch das ganze JSON- Parsing-Zeugs schon erledigt ist.

Aber m.E. läuft da gar nichts zusammen. Es sieht wohl so aus, das man das ganze doch selbst machen muss.
Ich hatte gehofft, das das Autodiscovery einem genau diese Arbeit abnimmt.

Gruß und Dank für jede Hilfe
Gerd

Nun ja, Autodiscovery mit mqtt ist so eine Sache...
Ich nehme an, Du hast setoption19 1 in Tasmota ausgeführt? Meine Erfahrung damit ist, sagen wir mal, gemischt... Das Device wird von openHAB als homie Gerät erkannt. Mit einem Switch Device hat das bei mir auch funktioniert, allerdings war das Ganze dann nicht zuverlässig. Ich bin mir nicht sicher, wo das Problem damals lag (ich habe das ca. 2018 ausprobiert).
Weil die Konfiguration in openHAB anschließend nicht gescheit zu bearbeiten war (weil es sich ja nun um ein homie Device handelte), habe ich das aufgegeben. Konventionell lassen sich die Geräte (insbesondere für Rollershutter) sehr einfach zu Fuß einrichten, zumindest, wenn das Tasmota Device mindestens mit V8.0.irgendwas geflasht ist (ich bin bei mit immer noch auf 8.5.2, 9.5.0 ist aktuell) Bei mir sieht ein Rollershutter Thing so aus:

Code: Alles auswählen

     Thing topic sonoffT1_1 "sonoff T1 1" @ "mqtt" [
         availabilityTopic="tele/sonoff_t1/LWT",
         payloadNotAvailable="Offline",
         payloadAvailable= "Online"
          ]{
        Channels:
            Type rollershutter : ch1 "Shutter" [commandTopic="cmnd/sonoff_t1/shutterposition1", stateTopic= "stat/sonoff_t1/SHUTTER1" ]
      }

Und das reicht, um alle Befehle (UP/DOWN/STOP/0-100) und die Rückmeldung(0-100) zu erhalten. Es braucht noch nicht mal jsonpath.

Die Definition oben ist in der alten OH2-Textform angegeben. nativ unter OH3 sähe das Ganze so aus:

Code: Alles auswählen

UID: mqtt:topic:mymqtt:sonoffT1_1
label: sonoff T1 1
thingTypeUID: mqtt:topic
configuration:
  payloadNotAvailable: Offline
  availabilityTopic: tele/sonoff_t1/LWT
  payloadAvailable: Online
bridgeUID: mqtt:broker:mymqtt
location: mqtt
channels:
  - id: ch1
    channelTypeUID: mqtt:rollershutter
    label: Shutter
    description: null
    configuration:
      commandTopic: cmnd/sonoff_t1/shutterposition1
      retained: false
      postCommand: false
      formatBeforePublish: "%s"
      stop: STOP
      stateTopic: stat/sonoff_t1/SHUTTER1

Also auch hier keine Überraschungen.
Nutzt man Homie, so läuft alles über json-Objekte und die Konfiguration wird sofort um einiges komplexer. Solange es anschließend komplett wie gewünscht funktioniert, ist das natürlich egal

aber offensichtlich funktioniert es zumindest nicht immer so wie gewünscht.

Danke für schnelle Antwort.
Ich hatte so was schon befürchtet. Deine Konfiguration werde ich mal als Vorlage nehmen.

Vielen Dank dafür !

Nebenbei, wie hast du denn diese Konfiguration erstellt ? Und wo hast du die ganzen Einträge her ? In der OH Doku finde ich nix.

Gibt es eine einfache Methode deine Konfigs per Text zu editieren und dann ins OH zu importieren ?

Ich immer noch altmodisch seit OH1 mit den Textdateien unterwegs, aber da verliert man schnell den Überblick.

Gruß und nochmals Dank
Gerd

Also, Textdateien funktionieren mit OH3 noch genauso wie zu Zeiten von OH1. In OH2 sind die Things mit dazu gekommen, aber die kennst Du ja sicher auch.

Was die Textkonfiguration für mqtt betrifft, so hat damals(tm) der Autor des mqtt2 Bindings argumentiert, dass diese Art der Konfiguration nicht im Wiki stehen sollte, auch, weil es zwei gültige Formen der Konfiguration gibt. Weil es nur jeweils eine Datei gibt, die aus github automatisch in die Doku geladen wird, hat er die Konfigurationsbeispiele stattdessen in zwei weitere Dokumente ausgelagert, die aber nur in github verfügbar sind.
Schau mal hier: https://github.com/openhab/openhab-addo ... xamples.md

Ansonsten ist es so, dass die Thing-Struktur ganz klaren Vorgaben folgt, das ist bei allen textlich definierten Things gleich.
Gibt es eine Bridge, dann kann die als Parent angelegt werden (geschweifte Klammern um alle Child Things) oder alternativ unabhängig (dann muss die UID zusätzlich je Thing in Klammern mit angegeben werden).
Bridge oder standalone Thing hat Doppelpunkte im Namen (das ist die UID...), Child Things haben keinen Doppelpunkt, da nur Teil der UID (es fehlt der Bridge-Teil)
Thingspezifische Konfigurationen werden in [eckigen] Klammen angegeben, die einzelnen Parameter sind mit Komma getrennt, Strings stehen in Anführungszeichen, Parameternamen sollten grundsätzlich in camelCase geschrieben sein. "Grundsätzlich" ist hier aber im juristischen Sinne gemeint, es gibt also Ausnahmen. Auf lange Sicht sollen aber alle Bindings so umgebaut werden, dass sie dieser Regel folgen.

Welche Parameter überhaupt zur Verfügung stehen und wie sie genau heißen, kann man am einfachsten über die API herausfinden, indem man zum Test ein Thing über die UI erstellt und dieses dann über die API recherchiert.

Die Topics ergeben sich aus der Tasmota Dokumentation, es gibt drei verschiedene Prefixes, cmnd, stat und tele. cmnd ist zum Senden von Befehlen an das Device. Über stat antwortet das Device bzw. sendet die verschiedenen Status. tele sendet zyklisch (Zykluszeit lässt sich einstellen) ausgewählte Informationen, kommt etwas drauf an, was es für ein Device ist.
Das fullTopic ergibt sich aus %prefix%, %topic% und dem letzten Teil, wobei %topic% quasi der Name des Device ist. Der letzte Teil des Topics ist dann abhängig das konkrete Kommando oder eben der konkrete Status. Was da alles zur Verfügung steht, geht aus der exzellenten Doku von Tasmota hervor. Tasmota ist vollständig über mqtt steuerbar, man kann sogar mqtt ausschalten (das ist dann natürlich das letzte Kommando per mqtt...) Dank Backlog kann man auch in einem Rutsch den Broker wechseln, User und Passwort tauschen und nebenher noch das WLAN tauschen (SSID und Key).

Auch Backe,
jetzt muss ich erst mal schlucken ...
Danke für die sehr ausführliche Erklärung.

Hoffentlich ist am Wochenende schlechtes Wetter, dann kann ich mich mal damit beschäftigen.

Gruß und Dank
Gerd

Dies scheint die finale Erklärung für das o.a. Verhalten zu sein:

... and Tuya shutters are not supported.

https://tasmota.github.io/docs/Home-Assistant/

Kannst Du denn über die Tasmota Webschnittstelle die Shutter auch nicht steuern?

Doch, die Rolladen lassen sich problemlos mit der TASMOTA direkt steuern.
Das o.a. Zitat bezog sich auf das 'Autodiscovery'- Feature.

Ah. Na ja, das mit dem Autodiscovery wäre ja auch nur das i-Tüpfelchen. Manuell kann man es ja auch einfach einrichten...

Kleine Bitte,
könntest du mir mal das Item und den Eintrag in deiner Sitemap posten für deine Rollershutter ?
Ich kriegs nicht richtig hin.

Vielen Dank !
Gerd

openhabforum.de

Autodiscovery von TASMOTA Geräten nach OH

Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH

Re: Autodiscovery von TASMOTA Geräten nach OH