[gelöst] FGR-223 - Inclusion will nicht

Begonnen von Beta-User, 04 Mai 2019, 12:26:47

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

versuche grade bzw. schon eine ganze Zeit, einen FGR-223 einzubinden. Das Teil war originalverpackt, außerdem habe ich zwischenzeitlich wegen Erfolglosigkeit auch mehrfach die "B"-Taste so lange gedrückt, bis die LED blau leuchtete, danach auch 3x kurz den Button (sollte reset sein).

Umfeld:
- einen FGS222 hatte ich neulich erfolgreich eingebunden, ansonsten ist das Thema relativ neu für mich (erfolglose Test mit einem Maple als zwcul und dem FGS ausgenommen);
- autocreate ist an
- IO: ZWDongle ist ein ZME_UZB1, version sagt Z-Wave 4.05 STATIC_CONTROLLER (scheint SDK 6.51 zu sein, nach dem was ich irgendwo in den Untiefen des Inet gefunden hatte)
- set ... addNode on und onNw habe ich versucht, die LED am ZWDongle blinkt dann auch artig,
- danach dann 3x kurz Spannung auf den S1 versucht; alternativ auch 3x kurz "B"-Taste. Nix passiert...

FHEM ist auf Updatestand von heute morgen.

list vom IO:
Internals:
   CallbackNr 8
   Clients    :ZWave:
   DEF        /dev/serial/by-id/usb-0658_0200-if00@115200
   DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
   FD         37
   FUUID      5cb4bb5f-f33f-d171-4b79-8944edf3fea6cc11
   MaxSendRetries 3
   NAME       zwaveme
   NR         410
   PARTIAL   
   RAWMSG     004a08060000
   ReadTime   1556964744.00912
   STATE      Initialized
   SendRetries 0
   SendTime   1556964743.85814
   TYPE       ZWDongle
   WaitForAck 0
   homeId     12345678   nodeIdHex  01   nrNAck     0
   zwaveme_MSGCNT 12
   zwaveme_TIME 2019-05-04 12:12:24
   MatchList:
     1:ZWave    .*
   READINGS:
     2019-05-04 11:52:42   caps            Vers:5 Rev:5 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET ZW_NVR_GET_VALUE NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 ZW_FIRMWARE_UPDATE_NVM GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP ZW_SET_ROUTING_MAX UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH ZME_CAPABILITIES
     2019-05-04 11:52:43   ctrlCaps        PRIMARY
     2019-05-04 11:52:43   homeId          HomeId:12345678 CtrlNodeIdHex:01
     2019-04-29 21:31:55   nodeList        zwaveme UNKNOWN_2 UNKNOWN_3 ZWave_SWITCH_BINARY_4
     2019-05-04 11:52:43   random          1568344e9b93d7ffc389c4d00f4d1e086432fa864e79c3b7b3908572d2486cc2
     2019-05-04 11:52:43   state           Initialized
     2019-05-04 11:52:43   sucNodeId       no
     2019-04-15 22:20:56   version         Z-Wave 4.05 STATIC_CONTROLLER
   SendStack:
Attributes:
   group      Interfaces
   homeId     12345678


Hat jemand einen Tipp für mich, was ich falsch mache?

Danke vorab,

Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Allgemeine Bemerkungen, da ich dieses  beruehmt-beruechtigtes Geraet nicht direkt kenne:
- 3x kurz ist bei ZWave Geraeten eine Herausforderung, da muss man schon flink sein.
- "attr ZWDongle verbose 5" und das Log beobachten.
- Originalverpackt heisst nicht viel, es gab schon oefters den Fall, dass die Geraete zurueckgesetzt werden mussten.
- sehe ich richtig, dass du bereits ein Geraet inkludiert hast, d.h. das waere nicht das Erste?
- Was genau heisst: "Inklusion will nicht"?

Beta-User

Mist, ich lese hier das erste Mal von berühmt-berüchtigt, da habe ich wohl nicht aufgepaßt... Suche nach dem 223-er hier liefert auch nicht viel, im Wiki ist mir auch nichts aufgefallen.

Es ist nicht das erste, mit dem anderen hatte das funktioniert, also am Ende ein rotes Fragzeichen und drei FHEM-Geräte, mit denen ich was anfangen konnte (auf Schalter- statt Tasterbetrieb umstellen, z.B.).
Das erste Gerät brauchte aber nur mit Strom versorgt zu werden, während der ZWDongle im inclusion-Mode war.
Das meine ich mit "Inklusion will nicht": Ich bekomme es nicht in FHEM angelegt wie bei dem anderen beschrieben.

Etwas konkreter noch: Im normalen Mode sehe ich hier nichts, werde also dann bei Gelegenheit das Ding wieder auspacken und weiterspielen (mit verbose 5 am Dongle). Am Dongle selbst habe ich nur das schnelle Blinken gehabt, Entfernung erst eine Decke und schräg durch die Wand (neben dem anderen), dann im selben Raum wie das Dongle, gut 2 m Luftlinie. Parallel hatte ich getestet, ob ich zwischen den Versuchen das andere Gerät erreichen konnte - ging... Das Dongle hatte ich auch mal abgestöpselt, nur den Rechner nicht wieder stromlos gemacht und neu gestartet (wie gesagt, das andere Gerät läßt sich ansprechen).
Wollte mit OVP nur sagen: War komplett neu, sollte daher nicht irgend einen anderen "Master" haben, der es kontrolliert (HomeMatic-Sprech: nicht gepairt). Das mit dem reset hatte ich auch bereits versucht (jedenfalls war das mit dem "B" lange drücken, warten bis die LED blau wird und 3xkurz "B" die Anleitung, die ich "irgendwo" gefunden hatte).

"Kurz" zu noch kürzer machen, versuche ich mal, dachte, ich hätte schon einige Variationen durch, aber dann eben nochmal mit fullspeed ;D ...

Melde mich wieder, wenn ich den schnellen Taster versucht hatte ::) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tux75at

Hallo Beta-User

Einen Versuch wäre eine Exklusion wert. Ich habe es selber noch nicht gemacht, aber öfter hier gelesen, dass Geräte schon gepaired waren (evtl. vom Werk/Test?).
Dabei ist es egal, ob das Gerät mit dem selben Controller gepaired is oder mit einem anderen. Die Exklusion kann trotzdem durchgeführt werden.

Reset mit lange drücken, benötigt (soviel ich mich erinnern kann) auch eine Stromabschaltung nach dem Reset (Sicherung kurz rausnehmen).
Beim Reset auch schauen ob die kleine LED richtig leuchtet. Beim Dimmer gibt es unterschiedliche Möglichkeiten, je nachdem, wann man den Taster auslässt.
FGR-223 ist der Roller Shutter 3, den hab ich zwar hier liegen, aber noch nicht verbaut.

Taste dreimal schnell drücken ... ich hab hier einen Dimmer, bei dem konnte ich die Taste nicht mehr drücken. Ich hab das Kunststoffteil weggebrochen, dadurch kommt man dann zum Taster auf der Platine. Um keinen Unfug zu machen, habe ich von einem Kugelschreiber ein Kunststoffteil genommen (das Teil, welches auf der Mine steckt und für die Drückermechnanik zuständig ist), das hat perfekt reingepasst und der Taster war wieder sehr gut zu drücken. Wichtig!! Kein Leitendes Material verwenden!!!
Hier auch wieder auf die LED Schauen, ich glaube diese sollte relativ schnell blinken (blau?). Wenn die LED nicht zu blinken beginnt, auf die Haptik des Tasters achten, nicht dass du das gleiche Problem hast, glaubst zu drücken, aber du drückst ins leere.
Mit Schaltern statt Tastern bekomme ich das nicht hin, schnell genug zu drücken, um in den Inklusionsmodus zu kommen.

Gruß
   Tux

Beta-User

Zitat von: Beta-User am 04 Mai 2019, 17:55:14
"Kurz" zu noch kürzer machen, versuche ich mal, dachte, ich hätte schon einige Variationen durch, aber dann eben nochmal mit fullspeed ;D ...

Melde mich wieder, wenn ich den schnellen Taster versucht hatte ::) .
Ergebnis: [gelöst]

Langfassung:
Ich habe jetzt nichts anderes gemacht, als eben den addNode-Modus auf on zu stellen (kein Reboot, kein Abstöpseln, kein update seit gestern..., einfach alles genau so wie gehabt), dann das Teil mit Spannung zu versorgen und recht kurz danach SEHR SCHNELL 3x S1 kurzfristig mit Spannung zu versorgen. Die 3 Pulse kamen ca. innerhalb einer halben Sekunde.

Man sieht den Moduswechsel am 223 auch daran, dass er zügig (grün?) blinkt, solange die Inclusion läuft.

Danke an alle!

Anmerkungen noch: Auch nach dem bereits beschriebenen Reset hatte ich das Teil zwischendurch auch mal spannungslos gehabt (ist ja bei allem möglichem anderen Gerät auch so, dass spannungslos machen eine gute Idee ist, wenn was nicht funktioniert). Jetzt lag es eben seit dem Abklemmen (vor dem Schreiben des Beitrags gestern) einfach nur einige Zeit in Ruhe im Eck...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Nachtrag noch:

Auch die Konfiguration ist nicht ganz so selbsterklärend, jedenfalls, wenn man den Aktor im VenetianBlind-Modus (für Jalousien) betreiben will (dafür habe ich den gekauft...). Dazu geht es hier weiter.

Und da Rudi hier mitliest:
Ich war etwas überrascht, dass bei einem "list -R <zwavedevice>" die zusammengehörigen Kanäle der endpointchildren nicht mit ausgegeben werden... ;)
Magst du das ggf. mal anpacken, oder "gehört das so"?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Nein, es gehoert nicht so.
associatedWith kam nach meiner ZWave-Aktivitaet, und ich habe es vergessen, da nachzupflegen.
Habe es jetzt nachgeholt.

Beta-User

Hat etwas gedauert, bis ich wieder Lust hatte, mit dem Teil rumzuspielen...

Vorab mal Danke für das Einbauen von associatedWith. Allerdings erschließt sich die ganze Logik mit den Sub-Devices für mich noch nicht so recht:
An sich hätte ich vermutet, dass es associatedWith gar nicht braucht (vielleicht der Einfachheit halber für list), und das ansonsten über das Internal "endpointChildren" laufen würde. Nun habe ich zu meiner Überraschung festgestellt, das dieses Internal sehr statisch ist, und insbesondere Umbenennungen (rename) nicht mag (ich habe das bisher nicht gespeichert, könnte also sein, dass nach Speichern+restart  wieder alles paßt; den Code dahinter habe ich nicht angesehen, versuche erst mal, den "dummen user" zu mimen; von CUL_HM her hatte ich die Erwartung mitgebracht, dass die Bezüge zu Kanal-Devices vom Modul her verwaltet werden).

Zum Hintergrund: Was ich eigentlich am Ende haben will, ist ein Device-Overview (o. notfalls eine ReadingsGroup), mit dem man beide Elemente in der Raumansicht "beeinander" steuern kann, wofür es tendenziell hilfreich wäre, die Querbezüge automatisch und generisch auflösen zu können...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

associatedWith und endpointChildren/endpointParent werden nach dem Start und nach jedem ZWave define/modify im ZWave Modul fuer alle ZWave Instanzen neu gesetzt.
associatedWith wird in rename explizit gepflegt, ich habe jetzt ZWave ein RenameFn spendiert, damit endpointChldren/endpointParent auch gepflegt wird.
Ich habe zwar immer noch nicht kapiert, warum du auf diese Werte angewiesen bist, aber ich will auch nicht, dass sie was Falsches enthalten.

Beta-User

Zitat von: rudolfkoenig am 01 Juni 2019, 14:42:22
Ich habe zwar immer noch nicht kapiert, warum du auf diese Werte angewiesen bist, aber ich will auch nicht, dass sie was Falsches enthalten.
Na ja, ich hatte mich erst mal nur etwas gewundert, dass (erst mal) was "falsches" (besser wohl: vorläufiges) drin stand.

Wie gesagt, worum es in dem speziellen Fall geht, ist den Status im DeviceOverview richtig darzustellen. Da ich den Aktor für eine Jalousie einsetze (Venetian mode), reicht mir der simple dim-Wert aus dem Hauptdevice nicht (den ich zu allem Überfluß auch noch wegkonfiguriert zu haben scheine und daher aus endpointChildren 1 holen muss), ich brauche auch den Dreh-Wert für die Lamellen aus dem 2. endpointChildren (sonst wäre in der Tat die ganze Aktion völlig unnötig), und ich möchte eigentlich auch beide Werte (Öffnung und Drehwinkel) aus einem DeviceOverview/einer Zeile in der Raumansicht heraus einstellen können.
Es ist daher irgendwie schade, dass diese "manufacturer specific"-Dinge durch den Generationswechsel vom 222-er auf den 223-er rausgeflogen sind und jetzt halt Drei Kanal-Devices angelegt werden.
Wenn wir grade dabei sind: auch ein 100%="on" auf den ersten Kanal ist bei dieser Art Aktor auch m.E. nicht optimal - die Jalousie bewegt sich dadurch keinen Millimeter (daher habe ich "dim 100" via eventMap auf "dim 99"  umgebogen, wie das auch einige andere beim Vorgänger wohl gemacht haben). Bin aber immer noch beim Lernen und Rumexperimentieren, vielleicht übersehe ich auch einfach was essentielles...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

krikan

Zitat von: Beta-User am 01 Juni 2019, 15:55:04
Wenn wir grade dabei sind: auch ein 100%="on" auf den ersten Kanal ist bei dieser Art Aktor auch m.E. nicht optimal - die Jalousie bewegt sich dadurch keinen Millimeter (daher habe ich "dim 100" via eventMap auf "dim 99"  umgebogen, wie das auch einige andere beim Vorgänger wohl gemacht haben). Bin aber immer noch beim Lernen und Rumexperimentieren, vielleicht übersehe ich auch einfach was essentielles...
In der Class SWITCH_MULTILEVEL ist on (0x255) = "Restore most recent (non-zero) level."
dim 100 (0x64) ist nicht definiert ("reserved").
dim 99 (0x63) ist 100%.
Im dim-Befehl ist die Zahl kein Prozentwert, sondern muss gemaeß Specs umgerechnet werden.

Gruß, Christian