Sonoff 4CH 4-Kanal Schaltmodul per MQTT

[Beta-User]

Am einfachsten sorgst du erst dafür, dass eine LWT-Message eingeht; die wird bei attrTemplate@Tasmota nämlich dafür genutzt, diese drei Parameter aufzulösen, nach denen du hier gefragt wirst.

Kurz: Erst den ESP nochmal booten...
Es kann auch sein, dass du über eine "Spezialität" von MQTT2_CLIENT stolperst, weil der nicht wissen kann, von welchem Device die Message ursprünglich kam. Dazu gibt es ein "Hilfstemplate", siehe die Hinweisbox hier: https://wiki.fhem.de/wiki/MQTT2_CLIENT#Anwendung

[Otto123]

Du musst auch darauf achten, dass der topic in tasmota unikat ist! Leider ist da die Voreinstellung bescheuert: Da steht einfach tasmota drin, damit laufen dann alle Dosen synchron
Siehe Anhang so mach ich das.

[Beta-User]

@Otto:
Das scheint hier nicht das Problem zu sein, zumindest sieht das hier so aus, als wäre was individuelles (VDR_1) vergeben:

Code Auswählen Erweitern

stat/fhem01/VDR_1/POWER/on
Die attrTemplates sollten auch mit dieser Struktur klarkommen, allerdings vermute ich, dass es noch kein "general_bridge"-Device gibt und daher alles ungeordnet auf das eine "Sammeldevice" läuft.

Hier wären lists (RAW ist hier besser) der Devices hilfreich, so ist es noch etwas "Glaskugel" (ist kein Vorwurf).

[TomLee]

@Otto
Ich mein das ist seit kurzem die default-Einstellung das die CID an tasmota angehängt ist.

[Otto123]

Aha ok interessant ich nehme das bescheuert zurück 

@Beta-User Du bist auf der richtigen Richtung FHEM-User22 hat ja einen MQTT2_CLIENT an einem externen mqtt Server da sind die Dinge ein klein wenig anders. Aber autocreate hatte er ja gemacht.
Wahrscheinlich wirklich einfach nochmal die Dose "booten"?
Ich hatte das irgendwie auch schon mal ganz hartnäckig. Da ging dann auch simpel: Device löschen und nochmal anlegen lassen (Dose booten)

Gruß Otto

[Beta-User]

Aha ok interessant ich nehme das bescheuert zurück 

Nun ja, es war nicht grade glücklich, dass es solange gedauert hat, bis es (scheinbar) geändert wurde...

@Beta-User Du bist auf der richtigen Richtung FHEM-User22 hat ja einen MQTT2_CLIENT an einem externen mqtt Server da sind die Dinge ein klein wenig anders. Aber autocreate hatte er ja gemacht.
Wahrscheinlich wirklich einfach nochmal die Dose "booten"?

Jein. Man sollte bei einer "CLIENT"-Konstruktion mMn. immer ein "Sortierdevice" dazwischenschalten (s.u. a)) und sich neuerdings am besten auch noch etwas um "ignoreRegexp" am IO kümmern, (s.u. b)) .

Ich hatte das irgendwie auch schon mal ganz hartnäckig. Da ging dann auch simpel: Device löschen und nochmal anlegen lassen (Dose booten)

Nochmal: Das Problem ist, dass die CID@m2-CLIENT "irreführend" ist, da "getauscht".

a) "Mein" Sortier-Template (MQTT2_CLIENT_general_bridge) wird hier auch nicht direkt weiterhelfen, weil das für "unveränderte" Topic-Trees gemacht ist. Hier müßte man also statt des 2. Teils des Trees den 3. "abgreifen", was aber als "Trockenübung" ohne Bezugspunkt für den TE wenig erhellend ist.
Wir brauchen also eine RAW-Definition von so einem Gerät, dann können wir das ggf. zur allg. Weiterbildung zusammen ändern .

b) Will man in diesen verteilten Konstruktionen (für autocreate) "unsinnige" Messages aussortieren, kann man neuerdings eine ignoreRegexp an MQTT2_(SERVER|CLIENT) setzen. Diese Idee hatte zwei Anwendungsfälle (="unsinnige Messages") im Auge:
1. die für uns nutzlosen "autodiscovery"-Messages für homeassistant und
2. "Befehle von dritter Seite" = z.B. cmnd-Anweisungen aus FHEM-Instanz 1 an Gerät xyz, die man typischerweise nicht in FHEM-Instanz 2 irgendwie auswerten will (es reicht, wenn das Zielgerät die Bestätigung sendet, dass sie das erhalten und verarbeitet hat).

Würde mich freuen, wenn wir das hier einmal exemplarisch darstellen könnten, wie diese Dinge zusammenspielen sollten . Vielleicht kann ich dann auch b) 2. "vertemplaten"...

Einverstanden?

[Otto123]

Ja gern. Ich muss das erst mal sacken lassen und mir in Ruhe anschauen. Ich melde mich zurück

[TomLee]

(scheinbar)

sicher

[Beta-User]

Ja gern. Ich muss das erst mal sacken lassen und mir in Ruhe anschauen. Ich melde mich zurück

Klar. Scheint auf den ersten Blick recht abstrakt zu sein, aber wenn du "live" austesten kannst, wird sich vermutlich der Nebel schnell lichten.

Falls du verwertbare Erkenntnisse hast/generieren magst: Von mir aus kann das bridgeRegexp-Ding gleich in die "Praxisbeispiele" (ganz oben) mir rein und ein ignoreRegexp-template-Vorschlag für "m2-IO" wäre die Krönung!
(Was mir eigentlich vorschweben würde, wäre die Möglichkeit, das nach und nach _individuell_ ergänzen zu können - "cmnd" muß ja z.B. nicht bei jedem user an derselben Stelle stehen, und über die Shellys haben wir noch gar nicht gesprochen... Man müßte also die einzelnen Zeilen (z.B. aus einem Tasmota-Gerät raus) ermitteln, schauen, ob die spezielle-Topic-Tree-Struktur schon erfaßt ist, und ggf. ergänzen. (Code, um bestehende Attributwerte zu übernehmen und ggf. zu ergänzen gab's mind. übergangsweise mal in den Sprachsteuerungstemplates...).

Have fun .

sicher

Ist ja gut... Wollte es nicht verifizieren, war nicht irgendwie wertend gemeint .

[Otto123]

ganz sicher

[FHEM-User22]

Du musst auch darauf achten, dass der topic in tasmota unikat ist! Leider ist da die Voreinstellung bescheuert: Da steht einfach tasmota drin, damit laufen dann alle Dosen synchron
Siehe Anhang so mach ich das.

Hallo,
es ist also nicht gut, in alle Geräte bei topic fhem01 einzutragen und dann beim full_topic  den Gerätenamen?

Grüße

[Beta-User]

Nun ja, eigentlich ist es wohl anders rum gedacht... Aber im Ergebnis sollte auch diese Variante ja eindeutige Pfade je Gerät geben - unterstellt, das VDR1 ist "unique". Dann wäre es zwar "falsch", aber ok für FHEM.
Aus dem Ergebnis hätte ich eher abgeleitet, dass du %prefix% um "/fhem01" erweitert hattest...

[FHEM-User22]

Moin,
wenn ich zu sehr auf den Senkel gehe, bitte sagen.....

Wie wären den dann meine Einstellungen richtiger?

Ich habe das hier mit probiert und mich daran gehalten:

https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben

Code Auswählen Erweitern


Internals:
   FUUID      5e8195ab-f33f-6033-16ce-e1d84837193f5c37
   IODev      Mosquitto.MQTT
   NAME       mqttGeneric
   NR         328
   NTFY_ORDER 50-mqttGeneric
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    .*
   prefix     mqtt
   READINGS:
     2020-04-20 17:08:44   device-count    0
     2020-04-20 17:08:42   incoming-count  0
     2020-04-22 09:01:12   outgoing-count  807112
     2020-04-22 09:01:12   transmission-state outgoing publish sent
     2020-04-20 17:08:42   updated-reading-count 0
     2020-04-20 17:08:42   updated-set-count 0
   devices:
     :global:
       :defaults:
         pub:qos    0
         pub:retain 1
         sub:qos    2
         sub:retain 1
       :publish:
         *:
           mode       R
           topic      {"fhem01/$device/$reading"}
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
     pub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
     sub:
       FHEMWEB    *
       Global     *
       MQTT       transmission-state
       MQTT_BRIDGE transmission-state
       MQTT_DEVICE transmission-state
       MQTT_GENERIC_BRIDGE *
       telnet     *
   message_ids:
   subscribe:
   subscribeExpr:
   subscribeQos:
Attributes:
   IODev      Mosquitto.MQTT
   comment    https://www.loxwiki.eu/display/LOXBERRY/MQTT+Gateway+-+Alle+FHEM-Readings+weitergeben

FHEM-Dienststatus per MQTT publishen
Der Status von FHEM selbst kann auf diese Weise an den Broker übergeben werden:
attr Mosquitto.MQTT on-connect retain:1 {Log3("mqtt",3,"connected to MQTT server");;1} fhem01/connection/status connected
attr Mosquitto.MQTT on-disconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;1} fhem01/connection/status disconnected
attr Mosquitto.MQTT room MQTT2_DEVICE,y-Devices,y-MQTT


   globalDefaults sub:qos=2 pub:qos=0 retain=1
   globalPublish *:topic={"fhem01/$device/$reading"}
   room       MQTT2_DEVICE,y-MQTT


um alles von meinem FHEM im MQTT zu haben.

Dort kommt es so an:

Code Auswählen Erweitern

fhem01/handy_XY01/presence

Vom anderen FHEM:

Code Auswählen Erweitern

fhem03/sysmon/cpu_temp

Daher habe ich es auch so in meine Tasmota-Dosen eingetragen, das dieses Prinzip auch so ankommt.

Also: Hauptstandort/Gerät/Aktion

Wie mache ich es besser?

Dankeschön

[Beta-User]

Moin,

vorab: ich kann das auch nur vom theoretischen Standpunkt aus beurteilen...

Grundsätzlich: Die Topic-Struktur an sich kommt mir sinnvoll vor, ich hätte den "fhem0x"-Anteil nur eben eher in "Full topic" untergebracht und nicht in %topic%. Aber wenn es so funktioniert, sollte es auch ok sein (es muß nur eindeutig sein, was ja der Fall zu sein scheint, und die cmnd's müssen eben auch (eindeutig) ankommen, wovon ich aber im Moment auch ausgehe).

Es sollte auch "ok" sein, gleich die Geräte, die direkt MQTT sprechen, so zu konfigurieren, dass "der richtige Standort" dort vercoded ist; das mit der MQTT_GENERIC_BRIDGE (MGB) betrifft ja eher nur Geräte, die nicht von sich aus "MQTT können". Dass es durch die Einstellungen an der MGB aber ggf. "gedoppelt" wird, ist m.E. nicht ganz optimal (vermutlich verhindert die MGB das selbst). (An sich hätte ich vermutet, dass das globalPublish nicht mehr funktioniert, ich meine mich zu erinnern, dass Hexenmeister da irgendwas ändern wollte; kann aber auch den "subscribe"-Teil betreffen).

Vielleicht eine doofe Frage: der Tasmota spricht mit demselben Broker wie die MGB's, es läuft also zentral alles über diesen einen Server? Oder gibt es je lokal einen und das wird dann über die MGB's an den zentralen "externen" weitergeleitet? Und wie hast du dann die Tasmota-Geräte in den anderen FHEM's eingerichtet?

[FHEM-User22]

Hallo,
kann erst heute gegen Abend antworten. Vorab, was meinst Du mit MGB (bin bisschen im Streß)?

Beste Grüße