CULnano kann Unterputzschalter nicht anlernen

[grossmaggul]

Hallo,

ich habe hier einen wiederspenstigen Unterputzschalter eq3 "hm lc sw1pbu fm", er ist das einzige Homematic Gerät, das ich noch habe. Aber ich bekomme das Ding nicht mit meinem CULnano gepairt.
Ich habe den UPSchalter schon resetet, aber wenn ich den Stick in den Pairingmodus setze und den Configbutton kurz drücke, blinkt der Configbutton ca. 20 Sekunden und das war's das Gerät taucht nirgendwo auf.
Ich habe das jetzt mehrer Mal versucht, es geht nicht.
Wie kann ich herausbekommen ob das Problem beim UPSchalter oder beim CULnano liegt?
Oder übersehe ich da was?
Ist das Problem evtl., daß der Schalter schomal mit einer CCU (die ich nicht mehr habe) gekoppelt war?

Gibt es eigentlich nur von Homematic die Unterputzschalter oder gibt's da auch was mit Zigbee?

Hier noch das Listing des CULnano:

Code Auswählen Erweitern

Internals:
   .FhemMetaInternals 1
   CMDS       ABCEeFfGhiKklMmRTtUVWXxYZz
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0@38400
   FD         34
   FHTID      0000
   FUUID      6758578c-f33f-f310-ce60-2ec164f9c172a431
   FVERSION   00_CUL.pm:0.248150/2021-08-01
   NAME       culnano_hm
   NR         779
   PARTIAL   
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.67 nanoCUL868
   devioNoSTATE 1
   eventCount 1
   initString X21
Ar
   .attraggr:
   .attrminint:
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2025-10-14 16:43:39   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2025-10-14 17:55:17   cmds             A B C E e F f G h i K k l M m R T t U V W X x Y Z z
     2025-10-14 15:04:36   credit10ms      900
     2025-10-14 15:04:47   fhtbuf          No answer
     2025-10-14 15:04:55   raw             No answer
     2025-10-14 17:55:17   state           Initialized
     2024-12-10 16:54:59   uptime          0 00:16:17
     2025-10-14 16:43:33   version         V 1.67 nanoCUL868
Attributes:
   DbLogExclude .*
   hmId       C4D5E6
   icon       cul_868
   model      nanoCUL
   rfmode     HomeMatic
   room       System->CUL
gm

[Beta-User]

Moin.

Ist ein wenig tricky rauszufinden, an welcher Seite das Problem liegt, wenn man nur je ein IO und ein Gerät hat. UP-Aktoren gibt es in praktisch allen gängigen Systemen, für ZigBee habe ich diese beiden im Einsatz, und zumindest bei dem 2. läßt sich der Modus auch tatsächlich auf "Stromstoßschalter" (momentary switch) umstellen, was zu dem HM-Aktor passen sollte; beim anderen hab ich's nicht ausprobiert, weil die hinter echten Schaltern stecken:
- https://www.zigbee2mqtt.io/devices/WHD02.html
- https://www.zigbee2mqtt.io/devices/TS0001_switch_module.html#tuya-ts0001_switch_module

Zum eigentichen Problem:
a) stimmt die Adressierung des CUL? Du hast laut Signatur 3 CUL-Geräte, und das, was dein list zeigt, ist ein WCH34x-USB-Seriell-Wandler. Checke also mal die "by-path"-Infos, um Fehladressierungen auszuschließen.
b) "eigentlich" sollte via autocreate auch was angelegt werden, wenn der CUL irgendwelche Messages von irgendeinem HM-Gerät "sieht" (OK, kann sein, dass wir das in den letzten Überarbeitungsrunden ausgebaut haben, irgendwas war da mit autocreate gewesen). Jedenfalls früher musste das nicht zwangsläufig im Zusammenhang mit einem pairing gewesen sein. So oder so: autocreate ist aktiv?
c) Unabhängig von allem anderen ist ein CUL kein optimales IO-Gerät für HM: Ohne spezielle firmware (TSCUL by noansi) muss FHEM schnell reagieren können, um ACK's etc. zeitnah zu quittieren. Wenn also dein Server grade im Hintergrund mit etwas anderem beschäftigt ist, kann es Probleme geben (sollte hier aber nicht durchgeschlagen haben). Und dann gibt es noch "verstellte" CC1101, die zumindest eine Zeitlang im Umlauf waren. Wenn du so einen erwischt hast, lauscht und sendet der ohne Anpassung (=>Forensuche) auf einer leicht versetzten Frequenz.
d) Zu guter Letzt kann natürlich auch einfach der UP-Schalter einen Hau haben. Die HM-UP-Geräte haben praktisch alle gerne mal das "C26"-Problem, worunter zumindest nach meinen Erfahrungen irgendwann vor dem letzten Relay der Transceiver-Teil leidet.
Und/oder du hattest bei der Koppelung mit der CCU AES aktiviert und es nicht sauber abgelernt? Dann ist die Verschlüsselung noch aktiv und du benötigst entweder den Schlüssel oder einen Hack (gibt es irgenwo hier in den Untiefen des Forums).

[grossmaggul]

Morjen,

danke für Deine Antwort.

Meine Signatur müsste ich mal überarbeiten, das stimmt nicht mehr so ganz, inzwischen habe ich nur noch einen CUL für MAX! und eben den HM CUL, den ich aber schonmal mit mehreren HM Geräten gekoppelt hatte. Der funktionierte eigentlich einwandfrei.
Zu a) Was meinst Du mit by-path Infos?
Zu b) autocreate ist aktiv
Zu c) Wie bereits geschrieben, habe ich den CUL schon mit HM Geräten in Betrieb gehabt, mit verschiedenen Firmwares culfw, a-culfw, TSCUL habe ich aber irgendwie nie zum Laufen gebracht.
Zu d) Ich hatte schomal einen defekte HM UPSchalter, der ging dann aber gar nicht mehr, sprich ließ sich auch nicht per Schalter betätigen.
Ob ich den per AES an der CCU angemeldet hatte, weiß ich nicht (mehr), zumindest mit Bewußtsein habe ich das nicht gemacht. Mal sehen ob ich den Hack finde.

Zu den zigbee UP Schaltern, wie funktioniert das genau, wird der Schalter durch diese Teile ersetzt oder kommen die zusätzlich zu dem vorhandenen Schalter in die Dose? Bei ersterem würde das ja bedeuten, daß man das Licht nicht mehr per mechanischem Schalter betätigen kann. Bei zweiterem hätte ich wahrscheinlich das Problem das Ding noch in der Dose unterzubringen.
Dimmer könnte ich sowieso nicht einsetzen, da ich als Lampe eine Halogenlampe mit Ringkerntrafo an der Decke hängen habe.

gm

[Beta-User]

Zu a) Was meinst Du mit by-path Infos?

https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden#Problemf%C3%A4lle:_by-id
In deinem list fand ich die Verbindungsdauer auch eher kurz, die deutete aber nicht auf ein Problem hin und die Kommunikation mit der MCU scheint ja zu klappen. Von daher scheint es tatsächlich eher der Aktor zu sein, der zickt. Wie geschrieben: Das C26-Problem zeigt sich nicht immer gleich auf dieselbe Weise, es _kann_ schon sein, dass der Kondensator noch ausreichend funktioniert, um das eine Relay zu bedienen.
Z.B. bei diversen Rollladenaktoren hatte ich schon den Effekt, dass nur noch eine Fahrtrichtung zuverlässig funktionierte, und es die andere Richtung Glückssache war...
Eine VCCU und/oder irgendwelche auf dummy oder ignore stehenden CUL_HM-Devices gibt es nicht (die sind teilweise schwer zu finden)?

Zu den zigbee UP Schaltern, wie funktioniert das genau, wird der Schalter durch diese Teile ersetzt oder kommen die zusätzlich zu dem vorhandenen Schalter in die Dose? Bei ersterem würde das ja bedeuten, daß man das Licht nicht mehr per mechanischem Schalter betätigen kann. Bei zweiterem hätte ich wahrscheinlich das Problem das Ding noch in der Dose unterzubringen.

Die verlinkten Teile sind Unterputz-Varianten, kommen also hinter den vorhandenen Schalter (brauchen aber - wie der HM-Aktor - einen N-Leiter). Die sind beide eher etwas kleiner als die HM-UP-Dinger, von daher sollten sie (mit der "momentary switch"-Option) als 1:1-Ersatz funktionieren.
Es gibt auch unzählige andere ZigBee-Geräte, die in europäische Dosen passen, die mit externem Bedienfeld kommen mal mit Tasterchen, mal mit Touch-Bedienung. Gemeinsam ist denen dann nur, dass sie wohl eher nicht in das "übliche" 55-er Maß passen. So kann man sowas daher nicht (einfach) in die hierzulande gängigen Schalterserien von Jung oder Gira einbauen, sondern muss die ganze "Reihe" tauschen, wenn man mehrere Elemente (Schalter oder Steckdosen usw.) unter- oder nebeneinander hat...
Von daher bin ich darauf ausgewichen, die UP-Varianten auf Vorrat zu beschaffen . Da gibt es auch welche, die keinen N-Leiter brauchen, man muss also beim Bestellen sehr aufpassen, dass man die Beschreibung richtig liest .

[RalfRog]

Hallo
Ich würde bei mir mal versuchen herauszufinden ob der Schalter noch gepairt ist - wenn noch ordentlich sendet (siehe Post vorher).

So weit ich mich erinnere schreibt der CUL (Verbose 4 oder evtl. 5) den Verkehr mit auch wenn eine fremde Zentrale adressiert ist.

Wenn du den Schalter betätigst sollte im Log zu sehen sein mit welcher bzw. ob er mit einer bestimmten Adresse kommuniziert. Vermutlich lässt sich auch erkennen ob es per AES verschlüsselt ist.

Sollte sich mit ein paar Minuten Aufwand erledigen lassen.

Gruß Ralf

[grossmaggul]

O.K., danke, werde ich mal testen und melde mich, wenn ich was rausbekomme.

Vielleicht stelle ich das aber auch auf so ein Zigbee Teil um.

Achso, by-path sieht für mich unverdächtig aus:

Code Auswählen Erweitern

ls -l /dev/serial/by-path
insgesamt 0
lrwxrwxrwx 1 root root 13 14. Okt 19:38 pci-0000:00:1d.0-usb-0:1:1.0-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 14. Okt 17:51 pci-0000:00:1d.0-usb-0:2:1.0-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 14. Okt 17:49 pci-0000:00:1d.1-usb-0:1:1.0-port0 -> ../../ttyUSB0
Das sind der MAX!- und HM-CUL und der Sonoff Zigbee Stick.

[Beta-User]

Achso, by-path sieht für mich unverdächtig aus:

Sorry, das hatte ich vermutlich nicht ausreichend erklärt: "by-id" sieht man immer alles, bei uneindeutigen Geräten ist die Liste der Ausgabe von "by-id" kürzer als die der tatsächlich vorhandenen Geräte, siehe den Abschnitt im Wiki vorher.
Aber wie gesagt: Die Adressierung scheint ok zu sein, und der CUL war als funktionierend bekannt, der Teil sollte (!) eigentlich ok sein.

[grossmaggul]

Ich habe in meiner Elektroschrottkiste noch eine alte CCU2 gefunden, die habe ich dann mal reaktiviert und damit ging das Anmelden des UPSchalters ohne Probleme, also scheint es doch auf CUL Seite ein Problem zu geben.
Ich hatte mal beim CUL den verbose auf 5 gesetzt, da kam leider gar nichts.

Danke für Euren Input!

[kabanett]

Hat der MAX die gleiche ID?
"1a86" heißen auch meine Beiden. Ist halt die Clone ID. Ich konnte diese nur über byPath vernünftig ansprechen.

Gruß

[grossmaggul]

Hat der MAX die gleiche ID?

Eigentlich nicht:

Code Auswählen Erweitern

# ls /dev/serial/by-id/usb-*
/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL02VDG7-if00-port0
/dev/serial/by-id/usb-Itead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_V2_2ee77d20a51fef11ba204ed0639e525b-if00-port0

[noansi]

Mich wundert, dass der nanoCUL /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0 sein soll.

/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL02VDG7-if00-port0 würde wegen FTDI_FT232R_USB_UART wesentlich sinniger sein, da der nanoCUL via USB zu UART Bridge Chip angebunden ist.

Den CUBE, wenn es nicht welche mit seriell Anbindung via FDTI Chip gibt (?), kenne ich zumindest nur mit nativer USB Schnittstelle und nicht mit USB zu UART Bridge Chip.
Mein auf a-culfw umgeflashter CUBE wird als ...AT91USBSerial.. gelistet. Was mit der original CUBE Firmware gelistet würde, kann ich leider nicht sagen.

Jedoch würde ich vorschlagen, mal CUBE und nanoCUL abzustecken.
Dann neues by-id list. Irgendwas muss verschwinden.
Es sollte nur noch der Zigbee übrig bleiben. Am besten auch den mal abstecken und schauen ob dann nichts mehr gelistet wird.
nanoCUL anstecken und neues by-id list. Der nanoCUL sollte zusätzlich auftauchen, welcher es dann auch wäre.
CUBE anstecken und neues by-id list. Der CUBE sollte zusätzlich auftauchen.
Zigbee einstecken. Der sollte zusätzlich auftauchen.

Wie Du mit Durcheinander den nanoCUL list dann mit der Versionsangabe hinbekommen hast, erschließt sich mir dann jedoch erst mal nicht.

[Beta-User]

@noansi
Für mich klang das nach zei CUL-Devices, je eines für max und moritz😉.
Da ist kein (umgeflashter) Cube im Spiel und das "wie herum" ziemlich egal - aber die DEF tauschen zum Gegenchecken, ob der eine doch einen Hau hat, ist eine gute Idee 😊.

[noansi]

Für mich klang das nach zwei CUL-Devices, je eines für max

Danke, klein geschrieben lässt sich das mit dem MAX viel besser unterscheiden.

Vielleicht noch als Ergänzung. nanoCUL und schlechte Lötverbindung zum cc1101 Tranceiver Modul gab es auch schon als Fehlermöglichkeit.

Und mit welchem get raw ist dieses reading zustande gekommen?

Code Auswählen Erweitern

     2025-10-14 15:04:55   raw             No answer


[grossmaggul]

Ja, es handelt sich um zwei nanoCULs, einer für MAX! der andere für Raabe...äh..Homematic.

Und der usb-186... ist definitiv der für Homematic, der mit usb-FTDI... für MAX!

Der MAX! CUL arbeitet einwandfrei.

Und mit welchem get raw ist dieses reading zustande gekommen?

Na halt mit "get raw"

Ich weiß noch nicht, ob ich mich jetzt weiter mit dem Ding abmühen möchte. So wirklich glücklich war ich damit eh nie.
Ich habe mir jetzt mal einen zigbee Aktor bestellt, mal schauen ob das damit fluffiger geht.
Mit dem Homematic Aktor hatte ich immer das Problem, daß es mehrere Sekunden dauerte bis der schaltete.