Änderungen durch zigbee2mqtt Vers.2

[rob]

Hallo.

Vielleicht bei Euch auch der Fall: zigbee2mqtt hat mit v2 Änderungen mitgebracht.
- zwingende Angabe des Adaptertyps (z.B. "adapter: zstack") in der configuration.yaml nötig, sonst startete z2m nicht
- Devices wurden aus den Gruppen in z2m entfernt, sodass sie dort und über Fhem funktionslos sind -> musste die Geräte erst wieder den Gruppen hinzufügen
- in Fhem wurde ein neues MQTT-Device angelegt "MQTT2_mqttjs_a329d2bb", das anscheinend nur mit Homeassistant-topics befüttert wird (ich hab kein HA, weshalb das für mich unnütz erscheint)

Vielleicht gibt es noch mehr, muss noch schauen, was es so tut (oder eben nicht ).

VG
rob

Edit: hier die Release Notes: https://github.com/Koenkk/zigbee2mqtt/releases
Bei mir ist eigentlich alles zu HA im zigbee2mqtt WebIF deaktiviert. Warum dann trotzdem das HA-config-Zeugs kommt, weiß ich nicht. Scheint aber nicht weiter zu stören - das Bridge-Device zu z2m tut jedenfalls.

[eisman]

hi,

ja,

$DEVICETOPIC/availability:.* availability

===>  {"state":"online"}

topic
  zigbee2mqtt/EG/VS_0202/availability
Value
  {"state":"online"}

es wird nicht mehr online oder offline angezeigt sonder {"state":"online"}

Gruß

[TomLee]

Hi,

evtl. ist legacy_availability_payload mit der neuen Version jetzt default false?

https://forum.fhem.de/index.php?msg=1316578

[eisman]

hi,

in der configuration.yaml habe ich es eingeschaltet

Verfügbarkeit Online

wird auch nach der Einstellung angezeigt

$DEVICETOPIC/availability:.* { json2nameValue($EVENT) } ==> wird immer noch {"state":"online"} angezeigt..
availability wird aber aktualliesiert

die Einstellungen sind so gesehen korrekt,

action        on_l1                         2025-01-05 14:58:00
availability {"state":"online"}       2025-01-05 14:37:44
last_seen 2025-01-05T15:55:45+01:00  2025-01-05 15:55:45
linkquality                           208 2025-01-05 15:55:45
power_on_behavior              off 2025-01-05 15:55:45
power_on_behavior_l1          off 2025-01-05 15:55:45
state                                       on 2025-01-05 15:48:56
state_l1                                  on 2025-01-05 15:55:45
state_l2                              OFF  2025-01-05 15:55:45
state_l3                               OFF 2025-01-05 15:55:45
gruss

[TomLee]

$DEVICETOPIC/availability:.* { json2nameValue($EVENT) } ==> wird immer noch {"state":"online"} angezeigt..
availability wird aber aktualliesiert

Komm nicht ganz mit, bzw. kann ich es mir nicht vorstellen. Mit json2nameValue($EVENT) ändert sich der Zeitstempel des "alten" Readings availability?

Rate nur, hab selbst noch nicht aktualisiert. online/offline sollte mit json2nameValue doch jetzt in state landen und der wird sofort wieder vom "Devicestatus" überschrieben, darum sieht man nix im Device? Meine Vorstellung.

[eisman]

hi,

nein er ändert sich nur nach dem neu starten von zigbee2mqtt.

sonst zeig der Status keine Reaktionen.

Zeitstempel des "alten" Readings availability? nein nur nach reboot

Rate nur, hab selbst noch nicht aktualisiert. online/offline sollte mit json2nameValue doch jetzt in state

nein der wert ändert sich auch nicht (mehrere male ausprobiert.

nach löschen aller readings wird availability auch nicht neu geschrieben
er wird nur beim neustart von zigbee2mqtt wieder angelegt

so hab es nochmal getestet, es wird nur das availability genutzt und es wird
in state geschrieben (Schlimmer Fehler). Warum war das nicht zu sehen....
es wird in zigbee2mqtt nicht ausgelöst,
wenn ich es direkt schreibe, wird es in state angezeigt (mist)

ich habe es jetzt erstmal so gelöst das ich das reading fest auf online gestellt habe
ist zwar blöd, falls das device offline ist

gruss

[TomLee]

Bin jetzt auch auf 2.0.0

Kommt wohl nur noch als Json, egal ob true oder false. Hab das zuvor noch getestet mit der Version davor, da hat das noch geklappt umzustellen.

Vorschlag:

Code Auswählen Erweitern

$DEVICETOPIC/availability:.* { $EVENT=~s/state/availability/;json2nameValue($EVENT) }

[eisman]

teste ich gleich mal.....

okay jetzt kommt wieder offline und online, Dankeschön
ich lass es so mal etwas laufen

wenn man unter Einstellung erweitert
MQTT output type = attribute
Examples when 'state' of a device is published json: topic: 'zigbee2mqtt/my_bulb' payload '{"state": "ON"}' attribute: topic 'zigbee2mqtt/my_bulb/state' payload 'ON' attribute_and_json: both json and attribute (see above)

einstellt kommt availability bei mir garnicht

gruss

[eisman]

hi,

lief soweit auf der einen Installation gut,
auf der zweiten hat es mir den kompletten zigbee zweig zerlegt,
hab dort erstmal wieder auf phoscon umgestellt.

gruss

[betateilchen]

- in Fhem wurde ein neues MQTT-Device angelegt "MQTT2_mqttjs_a329d2bb",

In aktuellen FHEM Installationen sollte der Präfix MQTT2_ bei automatisch angelegten devices eigentlich nicht mehr auftauchen.

Scheint aber nicht weiter zu stören - das Bridge-Device zu z2m tut jedenfalls.

Wozu man dieses bridge-device überhaupt braucht, erschließt sich mir bis heute noch nicht.
Meine zigbee devices funktionieren auch ohne diese bridge alle perfekt mit zigbee2mqtt in FHEM.
Und das, was man über die bridge von FHEM aus in zigbee2mqtt machen könnte, ist über die eigene WebGUI von z2m in einem Bruchteil der Zeit erledigt.

[Beta-User]

- in Fhem wurde ein neues MQTT-Device angelegt "MQTT2_mqttjs_a329d2bb", das anscheinend nur mit Homeassistant-topics befüttert wird (ich hab kein HA, weshalb das für mich unnütz erscheint)

Kommt vermutlich darauf an, wie die bridgeRegexp im bridge-Device definiert war. Habe da in meiner Installation ein paar Dinge geändert/ergänzt, das ist aber alles noch nicht konsolidiert...

Wozu man dieses bridge-device überhaupt braucht, erschließt sich mir bis heute noch nicht.

Niemand "braucht" das... V.a. nicht, seit es die WebUI gibt, gehen viele Konfigurationen in der Tat darüber sehr viel einfacher.
Ich "brauche" das, weil ich den Zustand des Interfaces - wie bei vielen anderen externen Diensten auch - sehen will und ggf. darauf reagieren. Als "Nebeneffekt" kann ich autocreate eingeschaltet lassen (das auch "niemand braucht"), um mir die Topics vorsortieren zu lassen.

Wenn man weiß, was man tut, geht das alles selbstredend auch "irgendwie anders" - wie immer bei FHEM. Bisher habe ich allerdings noch keine verallgemeinerungsfähigen Vorschläge dazu gehört .

[betateilchen]

Niemand "braucht" das
...
autocreate eingeschaltet lassen (das auch "niemand braucht")

Einfaches Prinzip:

Je mehr solcher Dinge, die "niemand braucht" man in seiner FHEM Installation hat, umso mehr mögliche Fehler- bzw. Störungsquellen muss man auch im Auge behalten. Damit schafft man lediglich vermeidbaren zusätzlichen Aufwand, der keinen in vernünftiger Relation stehenden Nutzen schafft.

[rudolfkoenig]

Diese "niemand braucht" Sachen wie autocreate ermoeglichen FHEM zu benutzen, ohne vorher fuer jedes einzelne Geraet stundenlang Doku zu studieren und zu experimentieren. Klar hat man nach Studieren alles besser im Griff (bis man es wieder vergessen hat), aber Software ist auch dazu da, um Zeit zu sparen.
 
In manchen Faellen wie ZWave ist die manuelle Inlusion ohne autocreate fast unmoeglich, weil die Kommunikation innerhalb von wenigen Sekunden erledigt werden muss.

Immerhin wird keiner dazu gezwungen, es zu benutzen.

[Beta-User]

Je mehr solcher Dinge, die "niemand braucht" man in seiner FHEM Installation hat, umso mehr mögliche Fehler- bzw. Störungsquellen muss man auch im Auge behalten. Damit schafft man lediglich vermeidbaren zusätzlichen Aufwand, der keinen in vernünftiger Relation stehenden Nutzen schafft.

Ob man "autocreate" immer angeschaltet lassen sollte, sei mal dahingestellt, aber für den jüngst erfolgten Umzug von deconz nach zigbee2mqtt fand (und finde) ich beide Tools (und "Automatismen" wie $DEVICETOPIC) ausgesprochen hilfreich.
Aber da darf ja jeder, wie er will...

Bei anderen Dingen (wie z.B. der "availability"-Behandlung) muss man m.E. eh selbst Hand anlegen, wenn man "Spezialfälle" abfangen will wie Devices, die aus baulichen Gegebenheiten heraus halt auch mal vom Netz gehen und dann über diesen Automatismus zutreffend als "off" behandelt werden.
Und ganz abgesehen von vielen Dingen, die v.a. beim attrTemplate-Satz für zigbee2mqtt verbessert werden könnten, wären wir heute sicher weder bei der Funktionalität, die MQTT2_DEVICE heute bietet, noch - und das finde ich besonders wichtig - hätten wir derart viele User, die halbwegs sicher mit dem Baukasten MQTT2_DEVICE umgehen können.
(Was teils an Konfigurationen für Tasmota-Devices in MQTT_DEVICE zu finden war, war imo einfach grausam und komplett uneinheitlich).

[betateilchen]

Diese "niemand braucht" Sachen wie autocreate ermoeglichen FHEM zu benutzen, ohne ...

... zu verstehen, warum etwas wie funktioniert. Und das geht genau so lange gut, bis die erste Störung auftritt. Und dann wird es langwierig und der ursprüngliche vermeintliche Zeitvorteil ist komplett im Ar...

Immerhin wird keiner dazu gezwungen, es zu benutzen.

immerhin...