Aqara FP300

[krobipd]

describe the problem in Detail. What do you expect to happen ? What does happen ?

Hallo, ich hab bereits mehrere FP300 in Betrieb und hatte nie Probleme sie einzubinden.

Hab heute versucht einen weiteren einzubinden aber bekomme dabei immer diese Meldung
DeviceConfigure:0x54ef4410015f9393 lumi.sensor_occupy.agl8 Failed to configure. --> Status 'UNSUPPORTED_CLUSTER' manuSpecificLumi

habs auch schon mit auslöschen und nochmal anlernen probiert. und auch 5 Sekunden die Taste am FP300 drücken aber immer diese Fehlermeldung.

Aus dem Debug
{"type":"attributeReport", "data":{"247":{"type":"Buffer", "data":[5, 33, 4, 0, 10, 33, 240, 51, 12, 32, 10, 13, 35, 42, 65, 0, 0, 19, 32, 0, 23, 33, 84, 12, 24, 32, 100, 28, 16, 0, 100, 32, 1, 101, 32, 2, 103, 32, 1]}}, "linkquality":132, "groupID":0, "cluster":"64704", "meta":{"rawData":{"type":"Buffer", "data":[28, 95, 17, 32, 10, 247, 0, 65, 39, 5, 33, 4, 0, 10, 33, 240, 51, 12, 32, 10, 13, 35, 42, 65, 0, 0, 19, 32, 0, 23, 33, 84, 12, 24, 32, 100, 28, 16, 0, 100, 32, 1, 101, 32, 2, 103, 32, 1]}, "zclTransactionSequenceNumber":32, "manufacturerCode":4447, "frameControl":{"frameType":0, "manufacturerSpecific":true, "direction":1, "disableDefaultResponse":true, "reservedBits":0}}, "endpoint_id":1}

Adapter version

3.4.5

Coordinator firmware version

revision:8.0.2 [GA]

Coordinator

SLZB-MR3

Setup

VM

Protocol of the error (as text, encapsulated in multiline code tags <>). Separate different occurrances into clearly split log sections

No response

[krobipd]

Update: mit Version 3.4.3 lassen sie sich anmelden und konfigurieren.

[asgothian]

Bei einzelnen Geräten kommt es vor das sie nach dem Einbinden ihre Cluster nicht ins system laden. Mögliche Gegenmassnahmen sind:

• adapter neu starten -> dann geht das Konfigurieren
• Gerät erneut anmelden ohne den Adapter neu zu starten -> dann geht das Konfigurieren.
  Auch in der 3.4.5 geht das Gerät.

A.

[krobipd]

danke wollte nur bescheid geben, anlernen hat mit 3.4.3 einwandfrei funktioniert und dann wieder update auf 3.4.5. funktionieren dort ja auch einwandfrei nur hatte Probleme mit dem anlernen und da ich direkt 3 neue Geräte angelernt habe war das reproduzierbar für mich zumindest. danke für die schnelle antwort.

[asgothian]

danke wollte nur bescheid geben, anlernen hat mit 3.4.3 einwandfrei funktioniert und dann wieder update auf 3.4.5. funktionieren dort ja auch einwandfrei nur hatte Probleme mit dem anlernen und da ich direkt 3 neue Geräte angelernt habe war das reproduzierbar für mich zumindest. danke für die schnelle antwort.

Genau diese Information ist leider nicht korrekt. Hättest du nicht versucht das Gerät unter 3.4.5 anzulernen wäre der gleiche Fehler auch unter der 3.4.3 aufgetaucht. Nur durch das vergebliche Anlernen ist das nicht passiert.

Ich habe leider noch nicht heraus gefunden an welcher Stelle das schief geht - auch weill ich es halt nicht 'reproduzieren' kann - es scheint eine race-condition zu sein.

A.

[krobipd]

ok :-/

Jedenfalls habs mit zwei nagelneuen Geräten probiert mit 3.4.5 kein Erfolg. Mit 3.4.3 auf Anhieb. Das kann ich dir sagen und als Feedback da lesen. Danke für deine Mühen.

[asgothian]

Das ist ein guter Hinweis. Ich war bisher immer davon ausgegangen, dass es am Modell hängt das der Cluster nicht angelegt wird, aber es scheint eine Funktion des Gerätes selber zu sein.

Dann habe ich noch mehr Informationen darüberwo ich schauen kann, wieso das passiert.

[montro]

hat dein Sensor dann auch funktioniert ? Sprich auch bewegung und presänz erkannt ?
Meine 2 neuen FP300 funktionieren ebfalls nicht und ich habe mittlerweile 4 Stück davon.
Mit 3.4.3 ist das verbinden wieder problemlos möglich gewesen, aber Battiewert und auch Präsenz werden nicht erkannt.

[asgothian]

Ich habe keinen FP300. Das Thema mit der Meldung hängt an diesem Eintrag:

DeviceConfigure:0x54ef4410015f9393 lumi.sensor_occupy.agl8 Failed to configure. --> Status 'UNSUPPORTED_CLUSTER' manuSpecificLumi

Dabei wird beim Anlernen ein zusätzlicher 'device spezifischer' Cluster geladen, der nicht im Standard vorhanden ist. Dieses scheint beim anlernen des ersten Gerätes nicht sauber zu passieren - nachdem die database geschrieben und durch einen Neustart wieder gelesen wurde ist der Cluster vorhanden und damit können zukünftige Geräte angelernt werden.

Auch: Die Geräte die beim Anlernen diesen Fehler bringen müssen in der Folge rekonfiguriert werden damit alle Verbindungen stehen.

Ich habe das ganze an 2 anderen Geräten mit herstellerspezifischen Clustern verifiziert.

A.

Nachtrag: im Adapter gibt es seit 3.3.5 keinerlei Änderung bei der Konfiguration / beim Anlernen der Geräte gegeben. Jegliche Anpassungen kommen aus dem ZH/ZHC Paar.

[montro]

sorry wenn ich nochmal nerve, aber ich habe weiterhin das problem das der wichtigste werte bei mir nicht aktualisieren.
pir_detection und presence ändern sich nicht, voltage hat ebenso keine wert und bekommt auch nie einen.
Die ersten und einzigen Statusänderungen habe ich vom reconfig der Geräte.
Gibt es eine möglichkeit den Cluster der neuen FP300 Sensoren zurückzusetzen und neu schreiben zulassen ?
Helligkeit, Temperatur und Luftfeuchtigkeit funktonieren problemlos.

Ich habe bereits mehrfach die adapter version gewechselt, die geräte mehrfach gelöscht, neugekoppelt und rekonfiguriert
aktuell bin ich wieder auf der aktuellen Github version

[asgothian]

Bitte lies mal dieses Dokument - https://github.com/ioBroker/ioBroker.zigbee/wiki/Device-messaging-debug
Mit dem Gerät im device debug mode kannst du alle Nachrichten sehen die das Gerät an den Adapter sendet, insbesondere auch die die nicht vom Konverter auf States umgesetzt werden können.

Den Cluster umschreiben ist letztendlich nicht entscheidend. Sobald die Cluster Definition erfolgreich aktiviert wurde sollte eine Konfiguration des Gerätes möglich sein. Ich schlage daher den folgenden Ablauf zum Testen vor:

• Ein Gerät als Testgerät heraussuchen
• Dieses Gerät neu anlernen.
• Adapter neu starten (um die UNKNOWN_CLUSTER Problematik zu umschiffen)
• Das Gerät über die Kachel neu konfigurieren - im Log schauen was an Meldungen kommt. Solange die Konfiguration nicht erfolgreich war passt da etwas nicht.
• Für das Gerät Device Debug aktivieren.
• Beobachten welche Meldungen entstehen und diese hier posten. wichtig - als Text Posten wie im Dokument beschrieben - jeweils mit Kontext - sprich was getan wurde / was erwartet wurde.

A.

[montro]

Danke, das mit dem Debug hatte ich nie ganz verstanden :) das war sehr hilfreich.
Allerdings zeigt sich das Bild bei beiden neuen FP300, die ich gekauft habe. Beide reagieren einfach nicht bei Bewegung.
Helligkeit und Temperatur werden ordentlich übermittelt, aber der rest wird gar nicht gesendet, oder kommt nicht an.

Das Log beim reconfig habe ich hier mal angehangen, leider hab ich nichts finden können außer das die Werte einmal sauber übermitelt werden.
Die meisten Cluster werden gemeldet mit result:undefined, aber ich denke mal das wird nichts damit zu tun haben das die Geräte nicht senden.
fp300.txt

Langsam vermute ich ein defekt der Teile

[asgothian]

Das log ist so unbrauchbar:

• Es scheint nur eine Antwort auf ein Device-Query oder ein read zu beinhalten (es sind alles ReadResponse Meldungen, keine AttributeReport Meldungen)
• Es ist ohne Kontext
• Es geht nur über ca. 40 s
• Es gibt keine Beschreibung was da wo wie vor dem Sensor passiert ist.

ich habe in dem Dokument absichtlich auf die einzelnen Meldungen aus dem Debug Tab verwiesen - insbesondere interessant sind da die bei denen keine Werte erzeugt werden.

Zum Thema undefined.

Die ZHC definieren sogenannte Konverter, die auf bestimmte Kombinationen von Cluster, Type und Attribute antworten können. Leider ist der Converter für den Aqara so gebaut das es 26 Konverter gibt die auf so ziemlich alles reagieren. Deswegen folgt auf jede Meldung

2026-06-01 09:52:50.978 - warn: zigbee.0 (637) ELEVATED:I01 (d422) Zigbee Event of Type readResponse from device 0x54ef441001674d13, incoming event: {"type":"readResponse","data":{"351":0},"linkquality":63,"groupID":0,"cluster":"manuSpecificLumi","meta":{"rawData":{"type":"Buffer","data":[28,95,17,10,1,95,1,0,35,0,0,0,0]},"zclTransactionSequenceNumber":10,"manufacturerCode":4447,"frameControl":{"frameType":0,"manufacturerSpecific":true,"direction":1,"disableDefaultResponse":true,"reservedBits":0}},"endpoint_id":1}

eine Liste von 26 Convertern, die jeweils versuchen aus den Daten einen oder mehrere Werte zu extrahieren. Alle bei denen am Ende result:undefined steht haben keine relevanten Daten gefunden.

Interessant für Deine Analyse sind diese Zeilen:

2026-06-01 09:52:50.982 - warn: zigbee.0 (637) ELEVATED:I02.26c (d422) candidates: [{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{},{"target_distance":0},{},{},{}] => payload {"target_distance":0}
2026-06-01 09:52:50.982 - warn: zigbee.0 (637) ELEVATED:I03 (d422) message received '{"target_distance":0}' from device 54ef441001674d13 type 'PS-S04D'

Da kannst du sehen ob aus der initialen Meldung ein Datenwert geworden ist. (in diesem Fall: Ja)

Was du jetzt tun solltest:

• verifizieren das die 'Grundeinstellungen' der FP300 korrekt sind.
• Länger beobachten. batterie wird z.Bsp. oft nur alle 24 h reported
• Gezielte Test-Szenarien schaffen, sprich zu einer bestimmten Zeit dafür sorgen das der Sensor eine Bewegung erkennen soll.

Ich gehe bisher nicht davon aus das

• das Gerät defekt ist
• es ein Problem im Konverter gibt.

A.

[krobipd]

scheinbar sind die Teile noch etwas zickig, gerade etwas herum gesucht und folgende thread inkl pull request gefunden. Koenkk/zigbee2mqtt#32153