TASMOTA_DEVICE readings ja, aber set geht nicht

Begonnen von Tueftler1983, 22 März 2019, 22:17:26

Vorheriges Thema - Nächstes Thema

Tueftler1983

Naja ich schließe das Thema glaube ich ab und hoffe das Matthias Kleine mir weiter hilft das Tasmota_Device wieder anständig läuft.
Das mit dem MTTQ2 bekomme ich gar nicht ans laufen und eine für "leihen" verständliche Anleitung findet sich dazu auch nicht

Beta-User

Mach es wie es für dich paßt, ich habe jedenfalls nicht vor, dazu eine Video-Anleitung zu bauen. Es gibt hinreichend Leute, die mit dem Text in den Praxisbeispielen im Wiki klarkommen, und mit den Änderungen von Samstag, welche seit Sonntag, 8:00 Uhr auch mit dem update verteilt wurden, sollte sich das ganze auch nach Anwendung des template (die du ja erstmalig auch hinbekommen hattest...) völlig stressfrei einrichten lassen.

Aber vielleicht verrätst du mir noch, wann du jetzt _genau_ das letzte update gemacht hast und hälst das nicht so "laut schweigend" im Vagen? Es war 2x ausdrücklich danach gefragt >:( .

Ansonsten ist die kurze Variante - die ziemlich sicher funktioniert - immer noch das:
Zitat von: Beta-User am 25 März 2019, 09:20:30
Mach' nochmal ein update, wende auf das Device MQTT2_MQTT2Client das genannte 00...-template nochmal an und lösche dann hinterher entweder das Device MQTT2_MQTT2Client ganz oder zumindest das bridgeRegexp-Attribut da (die readingList sollte das template löschen, wenn nicht, auch diese, das verhindert nämlich das Anlegen der weiteren Devices...).
Nach >700 Beitägen hier (leihe hin, Laie her) sollte das umsetzbar sein (das bereits gefundene template (nur jetzt in der neuen Fassung) anwenden, ein bestimmtes Device löschen), und ich gehe auch davon aus, dass mit der Erfahrung auch selbstverständlich ist, dass nach einem update auch ein shutdown restart gemacht werden muß, damit die neuen Modulversionen auch aktiv sind.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Tueftler1983

Das update habe ich Samstag mittag gemacht und nach dem Hinweis habe ich gestern abend auch nochmal eins gemacht.
Habe dann heute morgen nochmal alle MQTT2_DEVICE gelöscht und habe nach Anleitung wieder eins "MQTT2_MQTT2Client"mit dem tenplet 00 General bridge angelegt, dieses dann nachdem ein device "MQTT2_GeneralBridge" angelegt wurde wieder gelöscht.

Dann wurde ein device "MQTT2_DEVNAME" angelegt in dem aber keine Readings angelegt wurden und das ich auch keinem gerät wirklich zuordnen konnte.
Habe dann mal das templet tasmota basic darauf angewandt aber auch so bekam ich keine Readings.

Beta-User

Ah ok, jetzt wird wieder mehr klar.

Jetzt also nochmal die Anleitung auf Basis der aktuellen Stände:

Optimalerweise sollte das Gerät, auf das du das template angewendet hast, das "MQTT2_MQTT2Client"-Gerät gewesen sein.
Nachdem du das 00-er template darauf (es geht theoretisch auch irgendein anderes MQTT2_DEVICE-Gerät) angewendet hattest, sollte ein 2. Device "MQTT2_GeneralBridge" existieren.
Diese beiden Geräte sollten so aussehen:
- Die "MQTT2_GeneralBridge", die nur eine bridgeRegexp enthält, keine readingList oä.. Dieses Gerät dient dazu, anhand der eingehenden Messages bei eingeschaltetem autocreate neue Geräte zu erstellen, und diese anhand ihrer Topicstruktur zu unterscheiden und wird dauerhaft in dieser Form gebraucht.
- Das weiter bestehende Gerät "MQTT2_MQTT2Client" darf auch bleiben, aber es sollte da keine bridgeRegexp eingetragen sein, und es sollten zunächst auch keine readingList-Einträge mehr vorhanden sein; das readingList-Attribut wird von dem 00-er-template einmalig gelöscht (?).

Kommen jetzt neue messages über das IO, sollte folgendes passieren:
- messages, die der üblichen tasmota-Struktur entsprechen => jeweils ein eigenes Device für alles, was sich im zweiten Teil der topic-Struktur unterscheidet (sollte mit tele oder cmnd beginnen)
- ähnliches gilt für typische shelly und ESPEasy-Geräte.

Alles andere füllt wieder die readingList des Devices "MQTT2_MQTT2Client". Dieses Device kann man dazu nutzen, die readingList-Einträge manuell auf andere Devices zu übertragen usw.. Da kann ich mir bei Gelegenheit noch ein paar Dinge dazu überlegen, wie man das ggf. für weitere bekannte Device-Typen ähnlich wie bei der GeneralBridge vereinfachen kann, aber für's erste sollte das aber für deine Tasmota-Geräte egal sein, die sollten jeweils säuberlich getrennt von autocreate erstellt werden.

Wenn diese Anleitung soweit verständlich ist, gibt das das Grundgerüst für die neue Version bei MQTT2_CLIENT im Wiki. Dass der dortige Inhalt (nach wie vor) nicht mehr zu dem jüngsten update gepaßt hatte, hatte ich erwähnt, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Gerold

Wenn ich das richtig sehe ist das full-topic in den MQTT-Einstellungen nicht ganz korrekt. Das erste Slash "/" kann (muss?) weg, nach dem %prefix% fehlt dafür eins.

Das full-topic sollte also so aussehen:  "SmartHome/Interface/%topic%/%prefix%/".

Beta-User

Zitat von: Gerold am 25 März 2019, 17:26:25
Wenn ich das richtig sehe ist das full-topic in den MQTT-Einstellungen nicht ganz korrekt. Das erste Slash "/" kann (muss?) weg, nach dem %prefix% fehlt dafür eins.

Das full-topic sollte also so aussehen:  "SmartHome/Interface/%topic%/%prefix%/".

Na ja, wenn man die GeneralBridge sinnvoll nutzen will, sollte man das auf den defaults lassen.

Also
%prefix%/%topic%
Ich würde sogar darüber hinaus empfehlen, die Voreinstellung für "Client" auch für den Topic zu nutzen, also "DVES_%06X"

Das hat den Vorteil, dass die CID dann dem entspricht, was auch MQTT2_SERVER machen würde.

Sprechende Namen kann man dann in FHEM daraus machen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Tueftler1983

Ahh okay das bedeutet ja das man bei den Tasmota Geräten die MQTT Einstellungen bis auf IP und port auf den default Einstellungen lassen muss/soll und deshalb meine Frage nach den MQTT Einstellungen in den Gosund berechtigt war.

Da ich da jetzt nicht auch noch alles wieder ändern will warte ich jetzt mal was Matthias Kleine sagt.

Ich danke euch erstmal für eure Hilfe.

Aber ich möchte die MQTT Einstellungen in den Gosund und der RFbridge jetzt nicht ändern um zu testen.
/SmartHome/Interface/%topic%/%prefix%

Beta-User

#22
Sorry für die Verwirrung - screenshots auf Textinhalt zu filtern ist nicht meins...

Du kannst das auch händisch machen, das sollte keine größere Sache sein, es müssen dann halt die ganzen Pfadangaben alle entsprechend gepflegt werden.

Dazu würde ich aber empfehlen, EINEN der tasmotas mal umzustellen (bzw. einen nackigen ESP8266 mit der firmware zu flashen) und das Standard-template mal darauf anzuwenden (oder in den templates nachzusehen, wie die setList aufgebaut ist und das als Basis nehmen). Für die readingList kannst du auch das Sammeldevice kopieren und rauslöschen, was jeweils zu viel ist.

EDIT: Was für einen Grund gibt es, bei einem Neueinstieg erst mal die Defaults zu ändern? Erschließt sich mir nicht so recht, und von daher hatte ich eigentlich auch keine große Veranlassung gesehen, auch dazu noch die ganzen Details anzusehen.
Und das zu Testzwecken bei einem der tasmotas auf default zurückzustellen wäre doch auch kein Ding, oder?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

TomLee

Zitat von: Beta-User am 25 März 2019, 18:04:35

EDIT: Was für einen Grund gibt es, bei einem Neueinstieg erst mal die Defaults zu ändern? Erschließt sich mir nicht so recht, und von daher hatte ich eigentlich auch keine große Veranlassung gesehen, auch dazu noch die ganzen Details anzusehen.
Und das zu Testzwecken bei einem der tasmotas auf default zurückzustellen wäre doch auch kein Ding, oder?

Die Antwort gibts hier ab etwa der 3. Minute  :P

Beta-User

Zitat von: TomLee am 25 März 2019, 19:35:47
Die Antwort gibts hier ab etwa der 3. Minute  :P
...hätte ich mir ja eigentlich denken können...

Besonders gut gefällt mir die Stelle bei 4:25 (viel weiter habe ich nicht geschaut). Die Selbsteinschätzung sagt eigentlich schon alles ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Tueftler1983

Also,
mit den original Einstellungen im Gosund in den MQTT funktioniert es. Vielen dank
Jetzt muss ich mal gucken wie ich den regex part anpassen muss um meine Geräte ohne Änderungen verwenden zu können und ggf beide module parralel nutzen zu können.
Danke nochmal für die Hilfe.

Beta-User

Danke für die Rückmeldung!

Dann baue ich bei Gelegenheit die Anleitung im Wiki um und stelle da auch nochmal deutlicher klar, dass die ganzen attrTemplates so gebaut sind, dass sie (zumindest) mit den default-Einstellungen gut laufen und man daher das erst mal so lassen sollte - nachträglich ändern kann man das ja trotzdem, wenn es mal konfiguriert ist.

Wenn du nicht viel MQTT-Gerät hast, würde ich empfehlen, alles auf MQTT2_DEVICE "umzurüsten", dann mußt du nicht doppelte Syntax lernen.
Wenn alles (auch) über MQTT2 läuft, kannst du auch den mosquitto abschalten und auf MQTT2_SERVER umstellen, das sollte ohne größere Schmerzen vonstatten gehen. Eventuelle "Schmerzen" bei der zukünftigen Umstellung kannst du minimieren, wenn du topic im Tasmota gleich wie empfohlen mit DEVS... dynamisch festlegst (dann müßte eigentlich die CID der MQTT2_DEVICE-Geräte bereits so sein, dass das für den MQTT2_SERVER auch passt. Das ist wichtig für den Fall, dass irgendwann mal die Gosund irgendwas "neues" publisht, sonst landet das ggf. in einem anderen/neuen Device).

Einen dauerhaften Parallelbetrieb von MQTT_DEVICE bzw. TASMOTA_DEVICE und MQTT2_DEVICE _für dieselbe Hardare_ sollte man m.E. nicht anstreben. Und da Rudi der Maintainer von MQTT2.* ist, darfst du auch davon ausgehen, dass das zukünftig auch reibungslos laufen wird und du nicht irgendwo auf unlösbare Probleme stößt.

Just my2ct.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Tueftler1983

Eine Frage habe ich noch, für die RFbridge von Sonoff welches Templer nehme ich dafür? Für die Gosund SP1 habe ich das Sonoff POW genommen das scheint ganz zur zu funktionieren auch mit dem schalten.

Beta-User

Hmmm, für die RF-Bridge ist es m.E. (noch) nicht einfach:

Die ist m.E. nahe verwandt mit der IR-Lösung (A_01d_tasmota_ir). Es hat sich aber noch kein Freiwilliger gefunden, um daraus ein template zu machen. Wir können das gerne gemeinsam machen, dann bitte aber nicht unter einem Thread-Titel "TASMOTA_DEVICE".
Mach' am besten einen Thread dazu im MQTT-Bereich auf ("mqtt2.template für RFbridge von Sonoff entwickeln") und verlinke das im "Wünsche etc.)-Thread. Die firmware ist jetzt aber tasmota, oder?

Was ich benötigen würde, wäre eine RAW-Definition von dem Teil nach Eingang der ersten RF-messages, am besten solltest du den RESULT-Pfad in der readingList "doppeln" und einmal dann "jsonstring" ans Ende dieser Zeile schreiben. So sollten wir die "aufgebrochenen" Werte aus json2namevalue() und den Ausgangs-JSON als Text im Readinginghalt von "jsonstring" erhalten. (Klingt abstrakt, das mit dem "doppelten" Eintrag in der readingList ist aber nicht sehr schwer, wenn du das template A_02b_tasmota_2ch_shutter_invert_1 parallel ansiehst oder auf eine Kopie eines tasmota-MQTT2_DEVICE anwendest und das dann ansiehst).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Tueftler1983

Die RAW Definition der RF bridge als Tasmota device hilft dir nicht weiter oder?
Denn um sie in MQTT2 als device anzulegen muss ich die MQTT Einstellungen in der bridge zurück setzen aber dann ist die Funktion in FHEM nicht mehr gegeben. Und da wird sie für viele funktionen gebraucht.