Mqtt2 Fragen über Fragen und Tasmota mit 8ch-Relaise

Begonnen von dihe85, 25 August 2020, 23:22:27

Vorheriges Thema - Nächstes Thema

dihe85

Hallo zusammen
Vor kurzen hatte mir tomlee bei der korrekten einrichtung eines mqtt2_devices geholten.[Garagentor]
Jetzt wollte ich meine falsch konfigurierten devices korrigieren.[2 d1 minis mit 8kanal relais]
Durch autocreate hatt mir der allerdings die ganzen neuen readings in das fertige device [Garagentor] mit eingetragen.
Als ich das früher eingerichtet hatte, hatte ich mosquitto installiert und in fhem ein mqtt2_client angelegt.
Ich frage mich jetzt halt wieso die beiden Tasmotageräte zusammen in das reading vom garagentor geschrieben wurden.
Wie korrigiere ich das am besten, dass das nicht mehr passiert?

Gruß
Dirk

Beta-User

Zeigst du bitte mal ein list von den beteiligten Devices?

Nutzt du jetzt immer noch M2_CLIENT oder M2_SERVER? Hast du ein Bridge-Gerät (mit passender bridgeRegexp) vom TYPE=MQTT2_DEVICE im Einsatz, wenn du noch M2_CLIENT verwendest? (Wenn nein: Wiki zu M2_CLIENT lesen).
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

dihe85

Die Obersten zeilen sind von meinem Garagentor. Der Rest wurde durch den MQTT2-Client angelegt.

tele/DVES_F4660B/LWT:.* LWT
  tele/DVES_F4660B/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/DVES_F4660B/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/DVES_F4660B/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }
  tele/DVES_F4660B/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }
  stat/DVES_F4660B/POWER1:.* state
  stat/DVES_F4660B/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }

mymqtt2:tele/DVES_B672D4/LWT:.* LWT
mymqtt2:cmnd/DVES_B672D4/POWER:.* POWER
mymqtt2:tele/DVES_B672D4/INFO1:.* { json2nameValue($EVENT) }
mymqtt2:tele/DVES_B672D4/INFO2:.* { json2nameValue($EVENT) }
mymqtt2:tele/DVES_B672D4/INFO3:.* { json2nameValue($EVENT) }
mymqtt2:stat/DVES_B672D4/RESULT:.* { json2nameValue($EVENT) }
mymqtt2:stat/DVES_B672D4/POWER1:.* POWER1
mymqtt2:stat/DVES_B672D4/POWER2:.* POWER2
mymqtt2:stat/DVES_B672D4/POWER3:.* POWER3
mymqtt2:stat/DVES_B672D4/POWER4:.* POWER4
mymqtt2:stat/DVES_B672D4/POWER5:.* POWER5
mymqtt2:stat/DVES_B672D4/POWER6:.* POWER6
mymqtt2:stat/DVES_B672D4/POWER7:.* POWER7
mymqtt2:stat/DVES_B672D4/POWER8:.* POWER8
mymqtt2:tele/DVES_B672D4/STATE:.* { json2nameValue($EVENT) }

mymqtt2:tele/DVES_594830/LWT:.* LWT
mymqtt2:cmnd/DVES_594830/POWER:.* POWER
mymqtt2:tele/DVES_594830/INFO1:.* { json2nameValue($EVENT) }
mymqtt2:tele/DVES_594830/INFO2:.* { json2nameValue($EVENT) }
mymqtt2:tele/DVES_594830/INFO3:.* { json2nameValue($EVENT) }
mymqtt2:stat/DVES_594830/RESULT:.* { json2nameValue($EVENT) }
mymqtt2:stat/DVES_594830/POWER1:.* POWER1
mymqtt2:stat/DVES_594830/POWER2:.* POWER2
mymqtt2:stat/DVES_594830/POWER3:.* POWER3
mymqtt2:stat/DVES_594830/POWER4:.* POWER4
mymqtt2:stat/DVES_594830/POWER5:.* POWER5
mymqtt2:stat/DVES_594830/POWER6:.* POWER6
mymqtt2:stat/DVES_594830/POWER7:.* POWER7
mymqtt2:stat/DVES_594830/POWER8:.* POWER8
mymqtt2:tele/DVES_594830/STATE:.* { json2nameValue($EVENT) }
mymqtt2:stat/DVES_594830/UPGRADE:.* { json2nameValue($EVENT, 'UPGRADE_', $JSONMAP) }


ZitatNutzt du jetzt immer noch M2_CLIENT oder M2_SERVER?
Ich hab die Installation bis jetzt nicht geändert. Versteh ich die Commendref da richtig mit dem MQTT2_Server benötige ich Mosquitto nicht mehr?
Würde es stören wenn Mosquitto noch mit läuft?

ZitatHast du ein Bridge-Gerät (mit passender bridgeRegexp) vom TYPE=MQTT2_DEVICE im Einsatz, wenn du noch M2_CLIENT verwendest? (Wenn nein: Wiki zu M2_CLIENT lesen).
Die Commandref hatte ich mir dazu angeschaut die Wiki nicht. und um erlich zu sein versteh ich den Wiki-eintrag an der stelle auch nur so halb.
weil was macht er dann?

Es sich bis jetzt nicht viele Devices angelegt (zumindest bleiben nur 2 so wie sie angelegt sind). Macht es sinn mit Mosquitto an der stehhe weiter zu machen oder auf M2_server zu gehen?

Gruß
Dirk

Beta-User

Ja, MQTT2_SERVER = mosquitto+MQTT2_CLIENT (und das MQTT2_DEVICE mit MQTT2_CLIENT_general_bridge).

Bei MQTT2_DEVICE-autocreate wird immer geschaut, ob es ein Device mit der betreffenden CID (ClientID im Artikel MQTT) schon gibt, das bekommt dann die entsprechenden neuen Einträge in die readingList. Das ist genau das, was du hier zu sehen bekommst, alles geht an "das erste Gerät" mit der CID "mymqtt2"=die CID des MQTT2_CLIENT, und das ist es, was MQTT2_CLIENT_general_bridge ändert/durchbricht... (Im Zweifel hilft ausprobieren, wenn du Verbesserungsvorschläge zur Verständlichkeit hast: her damit).

Es kann auf jeder Maschine nur einen Dienst geben, der auf einem bestimmten Port lauscht, man kann also nicht MQTT2_SERVER und mosquitto auf Port 1883 derselben Maschine laufen lassen, eines muß deaktiviert werden. (Es gibt diverse Umstellungs-Threads, in denen das in sämtlichen Facetten beleuchtet wird, für Leute mit sehr wenigen Geräten ist es zu empfehlen, mosquitto zu deinstallieren und direkt im Anschluss M2_Server in FHEM zu definieren (und ggf. dieselbe Zugangsdaten zu vergeben, die für mosquitto galten).
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

dihe85

ZitatBei MQTT2_DEVICE-autocreate wird immer geschaut, ob es ein Device mit der betreffenden CID (ClientID im Artikel MQTT) schon gibt, das bekommt dann die entsprechenden neuen Einträge in die readingList. Das ist genau das, was du hier zu sehen bekommst, alles geht an "das erste Gerät" mit der CID "mymqtt2"=die CID des MQTT2_CLIENT, und das ist es, was MQTT2_CLIENT_general_bridge ändert/durchbricht

das ist mal verständlich.

Zitatfür Leute mit sehr wenigen Geräten ist es zu empfehlen.....
auf dauer werden es mehr werden. Mom sind es nur 3-4 geräte mit Tasmota mit insgesammt 20 Devices (Aktoren)


MQTT2_CLIENT_general_bridge wird aber auf das Device angewendet wenn ich das richtig verstehe.
Aber auch nur auf das als aller erste erstellte?

Gruß
Drik

Beta-User

Das mit den "wenigen Geräten" bezog sich auf den Zeitpunkt der Umstellung... => go for M2_SERVER!

Das General-bridge-template kann auf jedes beliebige Device angewendet werden; es empfiehlt sich, das zu nehmen mit der CID des M2_CLIENT.
Du kannst eine Kopie deines "Sammeldevices" nehmen, und bei dem einen (das den 1. Tasmota repräsentieren soll) die DEF ändern, dass das eine "richtige" (oder einfach nur andere) CID hat.

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

dihe85

Danke schonmal dafür.

Hab jetzt Mosquitto runter geworfen, den MQTT2 Client rausgeworfen und nen Mqtt2_server mit den gleichen Autentifications angelegt wie die Devices in Mosquitto hatten.
Läuft

Ich steh da leider an einer Stelle weiterhin auf dem Schlauch.
per Autocreate hat er mir jetzt ein device angelegt für das erste 8 Kanal-Relais mit tasmota.
Template tasmota_basic mit drauf.
jetzt muss ich die ja splitten. aber wie?
es gibt ja nur nen tasmota_4chanel_split.

muss ich den doch von Hand splitten?



Beta-User

Na ja, wenn du ein 8Channel-attrTemplate erstellst, checke ich das gerne ein. Ansonsten eben das 4-Ch als Basis nehmen und den Rest manuell entsprechend ergänzen...?
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

dihe85

Ich glaub von hand macht das nicht sooviel arbeit.
interessant wäre hier aber wie ich die anderer Power status ausgeblendet bekomme.

das macht er ja über das atr rein
attr ESP_24_1 jsonMap POWER1:0 POWER2:0 POWER3:0 POWER4:0 Dimmer:0 Channel_0:0 Channel_1:0 Channel_2:0 Channel_3:0 Channel_4:0 HSBColor:0 Color:0

ich hab das so verstanden, das eigentlich das hier so funktionieren müsste
attr ESP_24_1 jsonMap POWER2:0 POWER3:0 POWER4:0 POWER5:0 POWER6:0 POWER7:0 POWER8:0

hier mal das device
defmod Rasen_vorne_links MQTT2_DEVICE ESP_24_1
attr Rasen_vorne_links IODev mqtt2_serv
attr Rasen_vorne_links alias 1_Rasen_vorne_links
attr Rasen_vorne_links autocreate 0
attr Rasen_vorne_links genericDeviceType switch
attr Rasen_vorne_links jsonMap POWER2:0 POWER3:0 POWER4:0 POWER5:0 POWER6:0 POWER7:0 POWER8:0
attr Rasen_vorne_links model tasmota_basic_state_power1
attr Rasen_vorne_links readingList tele/DVES_B672D4/LWT:.* LWT\
  tele/DVES_B672D4/STATE:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_B672D4/SENSOR:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_B672D4/INFO.:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  tele/DVES_B672D4/UPTIME:.* { json2nameValue($EVENT,'',$JSONMAP) }\
  stat/DVES_B672D4/POWER1:.* state\
  stat/DVES_B672D4/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }
attr Rasen_vorne_links room 80-Garten-Devices
attr Rasen_vorne_links setList off:noArg    cmnd/DVES_B672D4/POWER1 0\
  on:noArg     cmnd/DVES_B672D4/POWER1 1\
  toggle:noArg cmnd/DVES_B672D4/POWER1 2\
  setOtaUrl:textField cmnd/DVES_B672D4/OtaUrl $EVTPART1\
  upgrade:noArg   cmnd/DVES_B672D4/upgrade 1
attr Rasen_vorne_links setStateList on off toggle

setstate Rasen_vorne_links off
setstate Rasen_vorne_links 2020-08-26 11:47:41 Heap 26
setstate Rasen_vorne_links 2020-08-26 11:29:19 LWT Online
setstate Rasen_vorne_links 2020-08-26 11:47:41 LoadAvg 19
setstate Rasen_vorne_links 2020-08-26 11:47:41 MqttCount 2
setstate Rasen_vorne_links 2020-08-26 11:47:41 POWER1 off
setstate Rasen_vorne_links 2020-08-26 11:32:41 POWER5 off
setstate Rasen_vorne_links 2020-08-26 11:32:41 POWER6 off
setstate Rasen_vorne_links 2020-08-26 11:32:41 POWER7 off
setstate Rasen_vorne_links 2020-08-26 11:32:41 POWER8 off
setstate Rasen_vorne_links 2020-08-26 10:00:08 SaveData on
setstate Rasen_vorne_links 2020-08-26 10:00:08 SetOption26 on
setstate Rasen_vorne_links 2020-08-26 11:47:41 Sleep 50
setstate Rasen_vorne_links 2020-08-26 11:47:41 SleepMode Dynamic
setstate Rasen_vorne_links 2020-08-26 10:00:07 StateText1 off
setstate Rasen_vorne_links 2020-08-26 10:00:07 StateText2 on
setstate Rasen_vorne_links 2020-08-26 10:00:07 StateText3 toggle
setstate Rasen_vorne_links 2020-08-26 10:00:07 StateText4 hold
setstate Rasen_vorne_links 2020-08-26 11:47:41 Time 2020-08-26T10:47:41
setstate Rasen_vorne_links 2020-08-26 11:47:41 Uptime 0T01:50:09
setstate Rasen_vorne_links 2020-08-26 11:47:41 UptimeSec 6609
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_AP 1
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_BSSId 2C:91:AB:39:73:4B
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_Channel 11
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_Downtime 0T00:00:03
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_LinkCount 1
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_RSSI 60
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_SSId Unser
setstate Rasen_vorne_links 2020-08-26 11:47:41 Wifi_Signal -70
setstate Rasen_vorne_links 2020-08-26 10:00:06 attrTemplateVersion 20200522 or prior
setstate Rasen_vorne_links 2020-08-26 11:36:52 state off
setstate Rasen_vorne_links 2020-08-26 11:41:41 subscriptions cmnd/DVES_B672D4/# cmnd/ESP_24_1_fb/# cmnd/tasmotas/#


Gruß
Dirk

TomLee

Zitatich hab das so verstanden, das eigentlich das hier so funktionieren müsste

Machts doch auch die Readings werden nicht mehr aktualisiert, laut deinem List.

Die Readings kannst du mit deleteReading löschen, mit dem jsonMap werden sie nicht mehr angelegt.

dihe85

Danke an euch sieht gut aus
Gruß
Dirk

Beta-User

Danke für's wieder aufmachen des Thread.

Es gibt seit heute auch ein 8-Channel-split-tasmota-attrTemplate, das sollte seit 8:00 Uhr nach einem update auswählbar sein (es setzt aber voraus, dass keine gleichnamigen Devices für die _CHxy vorhanden sind, sonst wird es vermutlich Fehler geben; ggf. einfach zum Testen eine Kopie des ersten Kanals nehmen und hinterher alles umbenennen, wenn es paßt?).

Um den Thread auf "gelöst" zu setzen, einfach den ersten Beitrag editieren und dann den Thread-Titel entsprechend ergänzen (bzw. gerne auch darauf hinweisen, dass es (auch) um 8ch-Tamota ging)...
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

dihe85

Hallo Beta-User,
ich hab den split grade mit nem 2 board getestet.
Sieht soweit gut aus.
1-2 kleinigkeiten musste ich korrigieren
Der chanel1 wird nicht benannt alle anderen erhalten den zusatz chX
Und es wurde überall ein Alias gesetzt. Und zwar alle mit dem gleichen Namen.

Also alias überall raus und chanel1 umbenannt fertig.

Top

Beta-User

Hmm, kann es sein, dass der alias vorher schon vergeben war (also dem entspricht, was im Ausgangsdevice drin stand)? Dann hast du grade einen generellen "bug" bei (fast) allen mehrkanaligen Tasmota-templates gefunden, danke! update ist seit eben eingeckeckt :) .

Dass ch1 nicht umbenannt wird, ist normal (und bei allen mehrkanaligen so, auch Shelly usw.). Oder verstehe ich die Rückmeldung falsch?
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

dihe85

#14
Das mit chanal 1 ist mir bis jetzt dann wahrscheinlich nicht aufgefalle. Die letzten habe ich von Hand gespitet.

Nen Alias war vorher nicht drauf. Das device war frisch angelegt und jungfreulich