Von MQTT Mosquitto auf MQTT2_Client Umstellungsprobleme

[Kawaci]

Hallo!
Ich verzweifle noch an mqtt2! Ich wollte eigentlich nur reine Ikea trdfri RGB LEDs in fhem integrieren, ein aus und dimmen ging ja mit dem zigbee2mqtt über einen cc2531 usb Stick! Dann hab ich gelesen das der Farbwechsel nur über mqtt2 einfach funktioniert. Daher habe ich mal etwas gelesen und habe einen MQTT2_client definiert

Code Auswählen Erweitern

defmod MQTT2 MQTT2_CLIENT 127.0.0.1:1883
attr MQTT2 autocreate no
attr MQTT2 devStateIcon .*opened:WLAN_Status.1
attr MQTT2 room Gateways

setstate MQTT2 opened
setstate MQTT2 2019-12-01 22:14:41 state opened

danach habe ich die eine bridge definiert laut Wiki

Code Auswählen Erweitern

defmod zigbee_pi MQTT2_DEVICE zigbee_pi
attr zigbee_pi IODev MQTT2
attr zigbee_pi autocreate 1
attr zigbee_pi bridgeRegexp (tele|cmnd)[/]([^/]+)[/].*:.* "$2"\
  shellies[/]([^/]+)[/].*:.* "$1"\
  (ESPClient_[^/]+)[/].*:.* "$1"\
  valetudo[/]([^/]+)[/].*:.* "$1"\
  [^/]+[/](ems-esp[^/]+)[/].*:.* "$1"
attr zigbee_pi comment Do not use very open bridgeRegexp expressions! This might lead to irritating results...
attr zigbee_pi icon mqtt_bridge_2
attr zigbee_pi model MQTT2_CLIENT_general_bridge
attr zigbee_pi room MQTT2_zigbee_pi
attr zigbee_pi setStateList on off

setstate zigbee_pi 0
setstate zigbee_pi 2019-11-29 21:22:16 associatedWith zigbee_pi



die ikea bulp habe ich mit copy&paste aus den bridge templates per Hand definiert

Code Auswählen Erweitern

defmod Stehlampe_Oben MQTT2_DEVICE
attr Stehlampe_Oben IODev MQTT2
attr Stehlampe_Oben devStateIcon {zigbee2mqtt_devStateIcon255($name)}
attr Stehlampe_Oben model zigbee2mqtt_light_rgbcct_rgb
attr Stehlampe_Oben room XiaomiMQTTDevice
attr Stehlampe_Oben setList on:noAgr zigbee2mqtt/0x000d6ffffe1a1cfe/set {"state":"ON"}\\
    off:noAgr zigbee2mqtt/0x000d6ffffe1a1cfe/set {"state":"OFF"}\\
    brightness:colorpicker,BRI,0,15,255 zigbee2mqtt/0x000d6ffffe1a1cfe/set {"state":"on","$EVTPART0":"$EVTPART1"}\
    color:colorpicker,RGB {" zigbee2mqtt/0x000d6ffffe1a1cfe/set ".zigbee2mqtt_RGB2JSON($EVTPART1)}
attr Stehlampe_Oben setStateList on off
attr Stehlampe_Oben webCmd toggle:ON:OFF:brightness:color

setstate Stehlampe_Oben set_on
setstate Stehlampe_Oben 2019-12-03 09:28:41 brightness set 0
setstate Stehlampe_Oben 2019-12-03 09:26:37 color set ffe591
setstate Stehlampe_Oben 2019-12-03 09:27:46 state set_on


somit funktionierte die Stehlampe über die slider für dimmen und colorpicker für den Farbwechsel das funktioniert jetzt! Nur ausschalten mit on off funktioniert nicht!

Dies e tage sind dann noch 3 Fenstersensoren von Xiaomi gekommen die ich wie gewohnt per bridge gepaart habe, und plötzlich taucht ein MQTT2_DEVICE in meiner liste auf das alle zigbee2mqtt devices und einige tasmota devices in den readings hat und da hänge ich jetzt! was soll ich jetzt weiter machen kann ich das löschen soll ich daraus meine neuen Geräte erzeugen(wie?) usw. Stehe voll auf dem Schlauch!

[Beta-User]

Du hast da irgendwas verbogen mit dem MQTT2_CLIENT_general_bridge, die CID sieht jedenfalls sehr seltsam aus.

Würde vorschlagen, du löschst dieses Device nochmal und wendest dann das attrTemplate MQTT2_CLIENT_general_bridge
nochmal auf das "Sammeldevice" an. Nicht händisch rumeditieren, sondern

Code Auswählen Erweitern

set <sammeldevicename> attrTemplate MQTT2_CLIENT_general_bridge
Danach sollte die readingList des Ausgangsdevices wieder leer sein und die neu eingehenden Nachrichten auch passend sortiert werden (du brauchst dann noch das zentrale Device für den zigbee2mqtt-Dienst, also zwei Devices, die jeweils eine andere bridgeRegexp haben, die eine sortiert allgemein, die andere das zigbee2mqtt-Zeug! Sollte man nicht mischen (kann man zwar, ist aber not recommended)).

Wenn du händinsch an dem Device was machen willst: mach' mal die doppelten "\\" zu einfachen. (Wird vermutlich nicht _den_ Effekt haben, aber das habe ich halt auf die Schnelle gesehen, sonst ist da ein Kommunikationsproblem zu vermuten).

Grundsätzlich sind die templates nicht unbedingt dazu gedacht, die manuell zu übernehmen...

Vermutlich hast du das Problem, dass du ggf. für jedes der attrTemplate eine Neuverbindung zum mosquitto herstellen mußt, damit wieder neue Daten kommen/bzw. erneut gesendet wird, was da ist.

[Kawaci]

Danke, also den MQTT2_Client kann ich lassen dieser stimmt? Das zigbee_pi device wo die bridge drin ist Muss  ich löschen? Die Stehlampe kann vorerst drinnen bleiben oder auch raus?

[Beta-User]

MQTT2_CLIENT: muß auf autocreate (simple), sonst wird kein Device angelegt. Es muß auch ein Gerät des TYPE autocreate aktiv sein.

Um ein Gefühl für die Sache zu bekommen, würde ich raten, alle MQTT2_DEVICEs zu löschen und nochmal neu anzufangen.

Also:
1. autocreate ein neues Device anlegen lassen ("Sammeldevice").
2. MQTT2_CLIENT_general_bridge auf dieses Device anwenden => ergibt 2 Devices, Sammeldevice ohne readingList und eines mit der generellen breidgeRegexp.
3. Nächste Meldung vom/über den Broker sollte wieder ein Device erstellen usw., wobei alle zigbee2mqtt-Infos in einem Device landen.4. a) Auf das mit den zigbee2mqtt-Infos wendest du das attrTemplate zigbee2mqtt_bridge an => alle weiteren eingehenden Messages von zigbee2mqtt ergeben danach wieder eigene Devices.b) Auf die anderen bzw. die weiteren zigbee2mqtt-Devices wendest du das jeweils für das Device passende attrTemplate an...

[Kawaci]

Danke werd ich am abend versuchen!

[rudolfkoenig]

Wenn schon neu, wieso nicht gleich MQTT2_SERVER ?

[Beta-User]

...vermutlich hat der TE Sorge, dass seine "alten" Devices dann auf einen Schlag nicht mehr funktionieren (typisches Umstiegsszenarium...)

@Kawaci:
Es gibt schon einen "Wechsler-Thread", wenn es dich interessiert. Für kleine Installationen ist das kein Act...

@Rudi:
Im Moment plane ich, auch die Tasmotas (teilweise) auf JSONMAP umzustellen, und dann wird es - je nach Ausgangssituation - schwieriger umzustellen, weil dann POWER1 nach state wandert usw., sich also auch Events ändern (setter ist sowieso ein Thema mit Klein-/Großschreibung).

@Kawaci:
Wenn du magst, kannst du den Tester spielen und diese templates austesten (bisher von mir völlig ungetestet)...

Code Auswählen Erweitern


name:tasmota_use_state_jsonmap
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:Applies to all tasmota devices with switchable channel<br>NOTE: This template will change main channel info from POWER1 to state reading.
order:A_01zx
par:READINGLIST;Replace simple json2nameValue code by JSONMAP variant;{ AttrVal("DEVICE","readingList","") =~ m/RESULT:.* { json2nameValue($EVENT) }/RESULT:.* { json2nameValue($EVENT,'',$JSONMAP) }/g }
par:NEWJSONMAP;add JSONMAP entry for POWER1;{ AttrVal("DEVICE","jsonMap","POWER1:state") =~ m/POWER1:[^ ]+/POWER1:state/g }
par:NEWSTATEFORMAT;replace POWER1 by state;{ AttrVal("DEVICE","stateFormat","POWER1") =~ m/POWER1/state/g }
par:LASTSTATE;Value of POWER1 reading;{ ReadingsVal("DEVICE","POWER1","???") }
attr DEVICE jsonMap NEWJSONMAP
attr DEVICE readingList READINGLIST
attr DEVICE stateFormat NEWSTATEFORMAT
deletereading -q DEVICE POWER1
setreading DEVICE state LASTSTATE
prereq:{ AttrVal("DEVICE","stateFormat",undef) eq "state" ? 1 :0 }
deleteattr DEVICE stateFormat

Code Auswählen Erweitern


name:tasmota_use_state_POWER1
filter:TYPE=MQTT2_DEVICE:FILTER=readingList=.*(tele|cmnd|stat).*
desc:Applies to all tasmota devices with switchable channel<br>NOTE: This template will change main channel back to POWER1 from state reading.
order:A_01zy
par:NEWJSONMAP;delete JSONMAP entry for POWER1;{ AttrVal("DEVICE","jsonMap","POWER1:state") =~ m/POWER1:state//g }
par:NEWSTATEFORMAT;replace state by POWER1;{ AttrVal("DEVICE","stateFormat","state") =~ m/state/POWER1/g }
par:LASTSTATE;Value of state reading;{ ReadingsVal("DEVICE","state","???") }
attr DEVICE jsonMap NEWJSONMAP
attr DEVICE readingList READINGLIST
attr DEVICE stateFormat NEWSTATEFORMAT
deletereading -q DEVICE state
setreading DEVICE POWER1 LASTSTATE
prereq:{ AttrVal("DEVICE","jsonMap",undef) =~ m,[:],g ? 1 :0 }
deleteattr DEVICE jsonMap

Hat dann den Vorteil, dass z.B. Sprachsteuerung usw. nicht mehr so einfach verwirrt werden kann und du dann evtl. gleich auf dem nächsten Stand der Dinge bist...

[Kawaci]

@Beta-User:
ok, warum eigentlich nicht! ich häng grad sowieso an nem tasmota sonoff pow fest! warum eigentlich nicht!

Hab versehentlich die dem MQTT2_MQTT2 device das template für tasmota pow eingegeben und jetzt weis ich nicht mehr wie ich zurück komme!

Code Auswählen Erweitern

defmod MQTT2_MQTT2 MQTT2_DEVICE MQTT2
attr MQTT2_MQTT2 IODev MQTT2
attr MQTT2_MQTT2 autocreate 0
attr MQTT2_MQTT2 bridgeRegexp zigbee2mqtt/([A-Za-z0-9._]*)[/]?.*:.* "zigbee_$1"
attr MQTT2_MQTT2 comment NOTE: For on-for-timer SetExtensions are used. You may add on-for-timer option running on the device. The following is limited to 1h max duration, but will not affect future simple "on" commands:<br>on-for-timer {my $duration = $EVTPART1*10;; 'cmnd/Smarthome/Backlog POWER1 1;; delay '.$duration.';; POWER1 0'}<br>See the "Praxisbeispiele" in the wiki for "pulseTime1" alternative option and it's restrictions.
attr MQTT2_MQTT2 devStateIcon {my $onl = ReadingsVal($name,"LWT","false") eq "Online"?"10px-kreis-gruen":"10px-kreis-rot";;;; my $light = ReadingsVal($name,"state","off");;;;"<a href=\"http://".ReadingsVal($name,"IPAddress","none")." \"target=\"_blank\">".FW_makeImage($onl)."</a> <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($light)."</a> uptime: ".ReadingsVal($name,"Uptime",undef).sprintf(" aktuell: %.1f W Tag: %.2f kWh Gestern: %.3f kWh Gesamt: %.4f kWh", ReadingsVal($name,"ENERGY_Power",undef), ReadingsVal($name,"ENERGY_Today",undef), ReadingsVal($name,"ENERGY_Yesterday",undef), ReadingsVal($name,"ENERGY_Total",undef))}
attr MQTT2_MQTT2 getList devicelist:noArg log zigbee2mqtt/bridge/config/devices\
  networkmap_raw:noArg raw zigbee2mqtt/bridge/networkmap raw\
  networkmap_graphviz:noArg graphviz zigbee2mqtt/bridge/networkmap graphviz
attr MQTT2_MQTT2 icon cmnd
attr MQTT2_MQTT2 model tasmota_basic_state_power1
attr MQTT2_MQTT2 readingList Keller/LWT:.* LWT\
  Keller/STATE:.* { json2nameValue($EVENT) }\
  Keller/SENSOR:.* { json2nameValue($EVENT) }\
  Keller/INFO.:.* { json2nameValue($EVENT) }\
  Drucker/RESULT:.* { json2nameValue($EVENT) }
attr MQTT2_MQTT2 room MQTT2_DEVICE
attr MQTT2_MQTT2 setList off:noArg    Smarthome/POWER1 0\
  on:noArg     Smarthome/POWER1 1\
  toggle:noArg Smarthome/POWER1 2\
  setOtaUrl:textField Smarthome/OtaUrl $EVTPART1\
  upgrade:noArg   Smarthome/upgrade 1
attr MQTT2_MQTT2 setStateList on off toggle
attr MQTT2_MQTT2 stateFormat POWER1
attr MQTT2_MQTT2 webCmd :

setstate MQTT2_MQTT2 POWER1


Das ist, bzw. war das Sammeldevice
die zigbee2mqtt geräte kommen nach der reihe herein das funktioniert jetzt ein mal!

Was muss ich mit diesen templates anstellen?

@rudolfkoenig
weis nicht hab mal gehört wegen Entlastung von fhem? Wobei das wenn ich es jetzt so schreibe eigentlich irrsinnig ist wenn mosquitto auf dem gleichen system läuft! Vor nach teile?

[rudolfkoenig]

hab mal gehört wegen Entlastung von fhem?

Das ist eher falsch, egal was man mit Entlastung meint.

Vorteil: Entlastung fuer FHEM- und MQTT-Anfaenger, z.Bsp. braucht man kein mosquitto und fuer autocreate bei tasmota kein MQTT2_CLIENT_general_bridge.
Fuer zigbee2mqtt bleibt es aber gleich.

Aber: lass Dich von Beta-User leiten, er ist der Herr der Templates

[Beta-User]

Kurz&mobil: kannst du löschen...

[Kawaci]

@rudolfkoenig:
Danke werd mich leiten lassen!

@Beta-User:
so gelöscht und gleich wieder da ohne irgend einen Murxs! 

[Beta-User]

@Beta-User:
so gelöscht und gleich wieder da ohne irgend einen Murxs! 

Das ist eigentlich weniger gut, als du zu denken scheinst:
Im "Sammeldevice" landen nämlich nur Messages, die durch die bridgeRegexp-e nicht erfaßt werden. Du solltest also die bridgeRegexp v.a. des allg. Sortier-Devices entsprechend anpassen...
Das Sammeldevice ist also eigentlich ein Fehlerindikator , und aus diesem Grund sollte das das einzige sein, das die CID vom Client hat und das auch nicht für irgendwas anderes verwenden. Dann kann man es nämlich gefahrlos jederzeit löschen und findet eventuelle noch bestehende Lücken in den bridgeRegexp-Ausdrücken genau dort (und nicht irgendwo verstreut).

@rudolfkoenig:
Danke werd mich leiten lassen!

1. Sei nochmal angemerkt, dass Rudi grundsätzlich recht hat mit der Aussage, dass Einsteiger besser MQTT2_SERVER verwenden sollten. Damit entfällt insbesondere diese ganze Vorsortiererei über das General-bridge-template.

2. Etwas mehr Theorie und Praxiserfahrungen zum Thema Umstellung wäre rund um diesen Beitrag zu finden: https://forum.fhem.de/index.php/topic,103762.msg975050.html#msg975050.
Ich hoffe, da einigermaßen nachvollziehbar dargestellt zu haben, wann denn ggf. welcher Weg Sinn macht. (@Rudi: Wenn ich da was sachlich nicht korrekt dargestellt haben sollte, darfst du gerne Kritik üben. Geht ja letztlich darum, dass die User, die umstellen wollen, einen funktionierenden und möglichst wenig aufwändigen Weg haben.)

3. Mittelfristig würde ich dem TE ebenfalls empfehlen, nur noch MQTT2_SERVER zu verwenden.

@Rudi: Neulich hatten wir ein Usertreffen, da hatte jemand eine eigene FHEM-Instanz nur für MQTT2_SERVER aufgezogen, das ganze auf derselben Maschine, auf der das Haupt-FHEM läuft. Das Argument war: Habe 8 Prozessoren, und so kann dieser Serverdienst parallel laufen und die Hardwareresourcen werden besser genutzt.
In eine ähnliche Richtung argumentieren ja auch die mosquitto-Befürworter.
Ob das wirklich einen Performance-Unterschied macht, sei mal dahingestellt, wenn man nur ein FHEM hat und alle MQTT-Daten in FHEM haben will, verwaltet man dieselben Daten ja nach meinem Verständnis doppelt. Hat man mehrere FHEM, oder nutzt das ganze irgendwie anders dezentral, mag das anders sein. Daher die  Frage, ob es eventuell möglich, sinnvoll... wäre, den Serverprozess (optional?) zu forken? (Ich habe keinen Schimmer von derartigem, also bitte nicht verhauen, wenn das völlig daneben ist...).

Gruß, Beta-User

[Kawaci]

also wäre es das geschickteste alles was mit mqtt2 Zutun hat zu löschen und auf MQTT2_Server neu umzustellen! laut übrigen Link?

[Beta-User]

Hmmm, verstehe die Frage nicht ganz:

- Die zu beachtenden Punkt waren in dem anderen Thread genannt; es geht v.a. darum, dass die vorhandenen Devices ja heute auch nicht im luftleeren Raum stehen, sondern irgendwie in FHEM eingebunden sind. Erstetzt man die durch neue, muß man (eventuell) nacharbeiten. Kann man auf einen Rutsch machen, mMn. ist es aber besser, sich erst einzudenken und über die ersten Devices einer "Gattung" (wie z.B. Tasmota-Switches) gründlicher drüberzugehen (z.B. weil die templates von POWER nach POWER1 umstellen (zukünftig vermutlich nach state) und die Werte gleich in Kleinschreibung reinkommen = veränderte Events...).

- Startet man auf der "günen Wiese", ist es ein "piece of cake", auch eine größere Anzahl von Gerätschaft via MQTT2_SERVER einzubinden. Es dauert pro Gerät in der Regel nicht mehr als eine Minute, wenn man keine speziellen Dinge hat (wie IR oder RF-Receiver oder sonst was exotisches/wenig verbreitetes). Ansehen, attrTemplate raussuchen, anwenden, done...
Die eigentliche Arbeit beginnt erst danach (s.o.).

- Beim Wechsel von MQTT2_CLIENT auf MQTT2_SERVER kann man meistens einfach so das IO tauschen; ist also auch kein Ding und man muß (fast) nichts löschen. Ausnahme: Eventuell in den reading-, get- und setList enthaltene CID-Info (das vor dem Topictree, einschließlich dem Doppelpunkt). Es ist also nicht notwendig, diese Arbeit doppelt zu machen, sondern easy, wenn man gleich darauf achtet.

ERGO: Muß jeder für sich selber entscheiden, welcher Weg denn vor dem geschilderten Hintergrund der bessere ist...

[rudolfkoenig]

da hatte jemand eine eigene FHEM-Instanz nur für MQTT2_SERVER aufgezogen, das ganze auf derselben Maschine

Das ist zwar nett, wuerde ich aber nicht machen, weil MQTT2_SERVER kaum Performance kostet.
Es sei denn, darueber laeufen auch andere (nicht-FHEM-bezogene) Kommunikationen, und man will diese durch anderweitige, FHEM-Blockaden nicht ausbremsen.

Den Server per Fork auszulagern hat das gleiche Problem wie mit allen anderen Modulen: man muss eine Kommunikation mit dem Hauptprozess realisieren, was auch nicht wesentlich weniger (CPU) Aufwand ist, als die MQTT-Kommunikation selbst. D.h. bei blockierenden Prozessen (z.Bsp. wg. viel rechnen, oder angewiesen sein auf blockierenden Code) macht das Sinn, bei MQTT2_SERVER sehe ich das nicht.