Ersatz für FS20 Bewegungsmelder

[Beta-User]

die waren anfangs sehr günstig...

Na ja, günstig ist halt relativ: Die kosten gefühlt "schon immer" irgendwas zwischen 15 und 25 Euro. Früher war das "vergleichsweise günstig", heute ist es "vergleichsweise teuer" - in meiner Grabbelkiste habe ich noch ein paar Melder rumliegen, die irgendwas um die 7 Euro gekostet haben.

PS: Habe den Thread hier zum Anlass genommen, den Umzug von HUE.* nach zigbee2mqtt anzugehen und bin echt angetan von der Entwicklung, die der Dienst seit den Anfangstagen genommen hat. Fast alles funktioniert ootb, firmware-updates werden herstellerunabhängig gecheckt und das (gesondert zu aktivierende) web-Interface ist sehr viel übersichtlicher als deCONZ-GUI.
Ein paar Würgarounds wird es wohl noch brauchen, die attrTemplate sind imo an der einen oder anderen Stelle etwas "outdated".

Und der Umzug geht auch einigermaßen, weil die meisten (netzgebundenen) Geräte direkt in den pair-Modus gehen, wenn man sie per phoscon-App "löschen" läßt!

[Sany]

Hallo Elektrolurch,

ich möchte Dir auch empfehlen, für den Ersatz von FS20 auf zigbee umzusteigen. Ich habe zwar noch FS20 im Einsatz, aber nur noch ein paar 6-fach-taster, für die ich noch nix passendes in der Zigbee-Welt gefunden habe.

Angefangen habe ich auch, wie vermutlich viele hier, mit deconz/Phoscon. Bin damit aber nicht so recht zufrieden gewesen (neue Geräte wurden oft erst spät oder auch gar nicht unterstützt, Konfiguration manchmal etwas eigen, ab und zu wurden Geräte vergessen ...) Dann der Umstieg auf zigbee2mqtt. Hierfür habe ich mir den Sonoff ZBDongel-E 3.0 mit EFR32MG21 besorgt. Der war "früher" noch als experimentell angegeben, mittlerweile als recommended.
Aktuell ist die Firmware 7.4, es wird aber an einer 8.0x gewerkelt. Das flashen dieses Adapters ist wirklich einfach: das geht per Browser (chrome oder edge) mit ein paar Klicks und das ist auch das einzige, was Du evtl. mal flashen "müsstest". Die einzelnen Komponenten werden aus zigbee2mqtt per OTA versorgt. Ich habe auf einem Testsystem einen "alten" Stick stufenweise bis auf 8... hochgeflashed, das hat einfach funktioniert und auch die Devices im Netz liefen einfach weiter. Also recht simpel mittlerweile und die Gefahr, das System zu "zerschiessen" ist auch nicht mehr wirklich hoch.
Apropo System: Du wirst es hier öfter lesen: Proxmox als Basis und fhem, zigbee und was sonst noch so ist, in getrennten LXC (Container) oder VM(virtual machines). Vorteil: sollte z.B. für zigbee2mqtt ein Update anstehen, einfach den Contaier/VM sichern, Update machen und wenn da was schief geht und Du keine Zeit/Lust zur "Reparatur" hast das Backup zurückspielen und gut ist. Fehlersuche kann man dann später machen etc.
Was ich noch berichten kann: Ich habe 2 zigbee-Netzwerke, eines ist zum Test für neue Devices oder auch der Updates. Die laufen auf unterschiedlichen "Channels" und stören sich nicht. Die Adapter sind per ser2net übers LAN angebunden. Auch das läuft völlig problemlos und performant. Ein Druck auf einen Taster schaltet ein Licht wirklich so, als wäre es "fest verdrahtet", obwohl der Signalweg schon recht lang ist. Die Frage des Channels stellt sich auch noch, je nach dem auf welchem Channel Dein WLAN arbeitet. Da gibts reichlich Info auf der zigbee2mqtt-Seite. Bei mir ist WLAN auf kanal1, zigbee auf 20. Mein zigbee-mesh mit ca 60 Komponenten und das WLAN mit betimmt auch so um die 30 läuft störungsfrei zusammen. Ist allerdings in und um ein freistehendes Haus, könnte mit vielen Nachbarnetzen unter Umständen schon etwas schwieriger werden, die passenden Kanale zu finden.
Anlernen: In fhem habe ich beim MQTT2Server das autocreate immer auf aus. Ein neues Device lerne ich in zigbee2mqtt an, konfiguriere dort die Dinge, die später übertragen werden sollen (nicht alles, was da kommt, ist nötig/sinnvoll auch in fhem) und vergebe einen Namen. Auch kann man in zigbee2mqtt das Log auf das neue Device filtern und bekommt dann fast einen "Event-Monitor" und kann schon mal sehen, wie gesprächig das Teil ist. Wenn das so läuft, wie ich es möchte, wird im MQTT2Server das autocreate eingeschaltet, einmal etwas von der neuen Komponente ausglöst (Taster drücken, Licht einschalten, bewegungsmelder triggern etc) und schon ist das Teil in fhem angelegt zusammen mit einem Log. Autocreate kann wieder aus. Warum diesen Weg: Ein neu angelegtes Device bekommt erst mal ein lange Hex-Zahl als Name, und mit Autocreate eingeschaltet hättest Du sofort das Device eben mit der Hexzahl als Namen in fhem. Änderst Du dann den Namen in zigbee2mqtt würde fhem ein neues Device anlegen, oder Du müsstest es vorher schon in fhem umbenennen auf den gleichen Namen. Das war mir zu doof, deshalb der Weg wie vorher beschrieben. Kann aber jeder machen wie er will.
Nach dem Anlegen in fhem dann ein passendes Template raussuchen und das war es im Prinzip. Die grundsätzlichen Funktionen waren bisher immer gegeben, auch wenn, wie Beta-User sagt, die Templates schon etwas in die Tage gekommen sind.
In zigbee2mqtt habe ich noch "availabiliy" eingerichtet, damit "melden" sich batteriebetriebene Geräte alle 25h, netzversorgte alle 10 min. Das Reading muss dann in fhem bei jedem Device noch in die Readinglist eingetragen werden, sollte es nicht schon automatisch per json ausgewertet werden.

Das war jetzt viel Text, sollte Dir aber ein wenig die Möglichkeiten mit zigbee2mqtt und fhem aufzeigen und das es alles gar nicht sooo kompliziert ist mittlerweile, und dafür dann aber auch gut funktioniert.

Solltest Du den zigbee-Weg gehen gibts hier immer Unterstützung, wenns irgendwo klemmt.


Viel Erfolg!


Sany

[Beta-User]

nur noch ein paar 6-fach-taster, für die ich noch nix passendes in der Zigbee-Welt gefunden habe.

Falls (!) es nicht um die Integration in bestehende Schaltersysteme geht (über die Optik der eQ-3-Dinger kann man streiten...), würde ich das Stichwort "opple" in die Runde werfen. Mit denen bin ich seit langem sehr zufrieden (mehrere 6-fach), die können ua. auch triple-clicks, was ggf. "Optionen für den Admin" eröffnet. An die Batterien kommt man da allerdings eher schlecht, aber die haben eine "ewige" Batterielebensdauer (meine laufen noch mit der originalen...).

@Elektrolurch
Habe eben (wg. backup-Funktionalität) noch zwei von den CC2652p-Sticks bestellt und gesehen, dass es die ggf. auch mit CP2102-USB-Chip gibt. Falls diese Art Coordinator-Chip deine Wahl ist, würde ich diese Variante empfehlen, weil man die USB-seitig eindeutig benennen kann (der vorhandene ist CH341-based und kollidiert uU. mit vorhandenen Nanos usw.).

[Elektrolurch]

Hallo zusammen,

danke für die Tipps. Nachdem mir nun auch noch ein FS20 Unterputz Schalter defekt gegangen ist, habe ich das Projekt der Umstellung mal angegangben.
1. Für den mqtt - Broker habe ich das in fhem eingebaute Modul verwendet.
2. Für den  zigbee2mqtt habe ich auf einem anderen Rechner  ein docker image mit einem Sonoff USB Stick installiert.
Zum Testen habe ich eine Aqara Steckdose verwendet.
Diese konnte ich mit dem zigbee2mqtt Dienst auch pairen und die Steckdose erscheint mit allen  readings, wie state, poer, energie usw. auch in fhem.
Jetzt stehe ich aber auf dem Schlauch: Wie schalte ich nun die Steckdose aus fhem heraus? Die Beispiele im Forum für die IKEA - Lampen erschließen mir leider nicht, wie man da prtinzipiell vorgeht. Die readings aus den mqtt - Messages per regex  zu befüllen, verstehe ich ja noch, aber der umgekehrte Weg?

Hier mal der Auszug von der Steckdose:

Code Auswählen Erweitern

   STATE      OFF
   TYPE       MQTT2_DEVICE
   eventCount 632
   myBroker_CONN mqtt_Testsystem
   myBroker_MSGCNT 640
   myBroker_TIME 2024-11-13 12:55:36
   READINGS:
     2024-11-13 12:04:49   IODev           myBroker
     2024-11-13 12:04:49   associatedWith  MQTT2_zigbee_pi
     2024-11-13 12:55:36   device_temperature 25
     2024-11-13 12:55:36   energy          0
     2024-11-13 12:55:36   linkquality     108
     2024-11-13 12:55:36   power           0
     2024-11-13 12:55:36   state           OFF
     2024-11-13 12:55:36   update_installed_version 45
     2024-11-13 12:55:36   update_latest_version 45
     2024-11-13 12:42:28   update_progress 100
     2024-11-13 12:42:28   update_remaining 25
     2024-11-13 12:55:36   update_state    idle
Attributes:
   event-on-change-reading .*
   readingList zigbee2mqtt/Az_Media1:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE

Noch der vollständigkeitshalber die configuration.yaml:

Code Auswählen Erweitern

homeassistant: false
permit_join: false
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://Speicherknecht
  client_id: zigbee_pi
frontend: true
serial:
  port: /dev/ttyUSB0
advanced:
  homeassistant_legacy_entity_attributes: false
  legacy_api: false
  legacy_availability_payload: false
device_options:
  legacy: false
devices:
  '0x54ef441000c2b71f':
    friendly_name: Az_Media1


Gruß Elektrolurch

[betateilchen]

Die readings aus den mqtt - Messages per regex  zu befüllen, verstehe ich ja noch, aber der umgekehrte Weg?

Vereinfacht gesagt: Du benutzt im MQTT2_DEVICE das Attribut setList, um für jeden möglichen set-Befehls des Aktors eine mqtt-Nachricht zu erzeugen und zu verschicken:

Code Auswählen Erweitern

attr <NameDerStreckdose> setList on:noArg                  zigbee2mqtt/Az_Media1/set {"state":"ON"}\
off:noArg                 zigbee2mqtt/Az_Media1/set {"state":"OFF"}\
toggle:noArg              zigbee2mqtt/Az_Media1/set {"state":"TOGGLE"}

Die möglichen Befehle und wie die mqtt-Nachricht aussehen muss, findest Du in zigbee2mqtt in der Detailansicht eines Gerätes, wenn Du dort auf die Modellbezeichnung klickst.

Beispiel:

Du darfst diesen Dateianhang nicht ansehen.

Nach dem Klick auf die Modellnummer landest Du hier:

https://www.zigbee2mqtt.io/devices/3RSPE01044BZ.html

und findest die mqtt Informationen unter "Exposes"

[Beta-User]

Für "Standardfälle" gibt es auch attrTemplate, in denen häufig passende Einstellungen vercodet sind (u.a. setList), die allerdings nicht jedem gefallen. Dafür sollte man aber tendenziell keine "friendly names" vergeben, weil man sonst uU. Rückfragen der attrTemplate beantworten muss, die den einen oder anderen überfordern...

[betateilchen]

attrTemplate sollte man erst verwenden, wenn man grundsätzlich verstanden hat, wie etwas funktioniert.

Im Endeffekt ist es bei den templates ja so, dass nicht der eigene "Wille" des Anwenders umgesetzt wird, sondern das, was sich irgendjemand als für sich selbst sinnvoll überlegt hat. Das muss nicht zwangsläufig für jeden Anwendungsfall passen.

[Beta-User]

Kann man so oder so sehen.
Dem einen helfen (halbwegs) funktionierende Beispiele, der andere erarbeitet sich die Dinge besser selbst. Muss jeder für sich entscheiden.

Die zigbee2mqtt-attrTemplates finde ich selbst im Moment "na ja". Funktional schon, aber mit "room for improvement" (u.A. beim Thema "availability"). Da hatte ich halt (nach der Startphase) eingecheckt, was "irgend jemand" als funktionierend gemeldet hatte... Ein Anfang.