Ich bin mit meinem Fhem auf ein neues Gerät ebenfalls auf einen Intel-NUC umgezogen.
Vorher hatte ich ebenfalls einen Intel-NUC.
Den Sduino habe ich komplett neu angelegt, die neue USB Schnittstelle abgefragt so wie es im WIKI steht in dev eingetragen danach ein Update gemacht aber er geht nicht in Opened.
Was muss ich noch beachten oder habe ich vergessen.?
hier mal das list:
Internals:
Clients :IT:CUL_TCM97001:SD_RSL:OREGON:CUL_TX:SD_AS:Hideki:SD_WS07:SD_WS09: :SD_WS:RFXX10REC:Dooya:SOMFY:SD_BELL:SD_UT:SD_WS_Maverick:FLAMINGO:CUL_WS:Revolt: :FS10:CUL_FHTTK:Siro:FHT:FS20:CUL_EM:Fernotron:SD_Keeloq:SIGNALduino_un:
DEF /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
DMSG nothing
DevState disconnected
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
FUUID 5d9a0461-f33f-a6c6-8338-fa1cadf0df6eb535
IDsNoDispatch 2,72.1,82
LASTDMSG nothing
LASTDMSGID nothing
NAME sduino
NR 6029
PARTIAL
STATE disconnected
TIME 1570377337.05767
TYPE SIGNALduino
unknownmessages
versionProtocols 1.06
versionmodul v3.4.0
MatchList:
10:SD_WS07 ^P7#[A-Fa-f0-9]{6}[AFaf][A-Fa-f0-9]{2,3}
11:SD_WS09 ^P9#F[A-Fa-f0-9]+
12:SD_WS ^W\d+x{0,1}#.*
13:RFXX10REC ^(20|29)[A-Fa-f0-9]+
14:Dooya ^P16#[A-Fa-f0-9]+
15:SOMFY ^Ys[0-9A-F]+
16:SD_WS_Maverick ^P47#[A-Fa-f0-9]+
17:SD_UT ^P(?:14|29|30|34|46|69|76|81|83|86|90|91|91.1|92|93|95)#.*
18:FLAMINGO ^P13\.?1?#[A-Fa-f0-9]+
19:CUL_WS ^K[A-Fa-f0-9]{5,}
1:IT ^i......
20:Revolt ^r[A-Fa-f0-9]{22}
21:FS10 ^P61#[A-F0-9]+
22:Siro ^P72#[A-Fa-f0-9]+
23:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
24:FS20 ^81..(04|0c)..0101a001
25:CUL_EM ^E0.................
26:Fernotron ^P82#.*
27:SD_BELL ^P(?:15|32|41|42|57|79)#.*
28:SD_Keeloq ^P(?:87|88)#.*
2:CUL_TCM97001 ^s[A-Fa-f0-9]+
3:SD_RSL ^P1#[A-Fa-f0-9]{8}
4:OREGON ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
5:CUL_TX ^TX..........
6:SD_AS ^P2#[A-Fa-f0-9]{7,8}
7:Hideki ^P12#75[A-F0-9]+
9:CUL_FHTTK ^T[A-F0-9]{8}
X:SIGNALduino_un ^[u]\d+#.*
READINGS:
2019-10-06 17:56:19 state disconnected
2019-10-06 17:12:35 version 0
mcIdList:
10
11
12
18
47
52
57
58
96
msIdList:
0
0.1
0.2
0.3
0.4
1
3
3.1
4
6
7
13
13.2
14
15
17
23
25
33
33.1
33.2
35
41
51
55
65
74.1
87
88
90
91.1
93
muIdList:
8
9
13.1
16
17.1
19
21
22
24
26
27
28
29
30
31
32
34
36
37
38
39
40
42
44
44.1
45
46
48
49
50
56
59
60
61
62
64
66
67
69
70
71
72
73
74
76
79
80
81
83
84
85
86
89
91
92
94
95
Attributes:
blacklist_IDs 43
cc1101_frequency 433,920
group Hardware
hardware nanoCC1101
icon cul@blue
room HWR,System
sortby 08
verbose 3
Was sagen die Fhem Log und die system Log (dmesg)?
Evtl. ein Berechtigungsproblem auf der USB Schnittstelle?
habe ich gerade mal eben geschaut, dass ist das einzige was ich habe
2019.10.06 18:19:26 3: sduino: IDlist development protocol is active (to activate dispatch to not finshed logical module, enable desired protocol via whitelistIDs) = 2 72.1 82
2019.10.06 18:19:26 3: sduino: IDlist MC 10 11 12 18 47 52 57 58 96
2019.10.06 18:19:26 3: sduino: IDlist MU 8 9 13.1 16 17.1 19 21 22 24 26 27 28 29 30 31 32 34 36 37 38 39 40 42 44 44.1 45 46 48 49 50 56 59 60 61 62 64 66 67 69 70 71 72 73 74 76 79 80 81 83 84 85 86 89 91 92 94 95
2019.10.06 18:19:26 3: sduino: IDlist MS 0 0.1 0.2 0.3 0.4 1 3 3.1 4 6 7 13 13.2 14 15 17 23 25 33 33.1 33.2 35 41 51 55 65 74.1 87 88 90 91.1 93
2019.10.06 18:19:26 3: sduino: IDlist attr blacklistIds=43
2019.10.06 18:19:26 3: sduino: IDlist attr whitelist disabled or not defined (all IDs are enabled, except blacklisted and instable IDs):
2019.10.06 18:19:26 3: sduino IdList: ### Attribute development is in this version ignored ###
dmesg muss ich wo eingeben:?
die Abgfrage des USB Ports sieht so aus:
lrwxrwxrwx 1 root root 13 Okt 6 17:14 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Okt 6 15:32 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001949EB8D-if00 -> ../../ttyACM0
dmesg ist ein Systembefehl. Dann in der Console. Angenommen, Du bist auf Linux.
ich dachte es muss noch etwas dazu kommen, weil der ja sonst ellenlang ist.
ich suche mal darin nach sduino oder usb
das hier habe ich gefunden:
[ 2.435311] usb 1-3: New USB device found, idVendor=0403, idProduct=6001
[ 2.435317] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.435319] usb 1-3: Product: 433
[ 2.435321] usb 1-3: Manufacturer: SIGNALduino
[ 2.435323] usb 1-3: SerialNumber: MHz
[ 2.596121] usb 1-4: new full-speed USB device number 4 using xhci_hcd
[ 2.748269] usb 1-4: New USB device found, idVendor=0451, idProduct=16a8
[ 2.748275] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.748278] usb 1-4: Product: TI CC2531 USB CDC
[ 2.748280] usb 1-4: Manufacturer: Texas Instruments
[ 2.748282] usb 1-4: SerialNumber: __0X00124B001949EB8D
[ 2.876129] usb 1-7: new full-speed USB device number 5 using xhci_hcd
[ 3.025586] usb 1-7: New USB device found, idVendor=8087, idProduct=0a2b
[ 3.025591] usb 1-7: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 3.030068] hidraw: raw HID events driver (C) Jiri Kosina
[ 3.032402] usbcore: registered new interface driver usbhid
[ 3.032405] usbhid: USB HID core driver
[ 3.034058] hid-generic 0003:1B1F:C00F.0001: hiddev0,hidraw0: USB HID v1.10 Device [eQ-3 HM-CFG-USB] on usb-0000:00:14.0-2/input0
Dann grep nutzen:
dmesg | grep sduinooder was auch immer
Das ist aber eine Systemlog, und nicht nur die gesuchte Zeilen wären relevant, sondern auch einige davor und danach
da kommt gar nichts :-\
das habe ich noch ganz am Ende gefunden: was mich wundert das dort nichts von dem Port steht welchen ich in die dev eingeben muss
code im nächsten Beitrag
[ 6099.942734] usb 1-3: USB disconnect, device number 3
[ 6099.943196] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 6099.943239] ftdi_sio 1-3:1.0: device disconnected
[ 6107.314412] usb 1-3: new full-speed USB device number 6 using xhci_hcd
[ 6107.770159] usb 1-3: New USB device found, idVendor=0403, idProduct=6001
[ 6107.770166] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 6107.770172] usb 1-3: Product: 433
[ 6107.770177] usb 1-3: Manufacturer: SIGNALduino
[ 6107.770180] usb 1-3: SerialNumber: MHz
[ 6107.803964] ftdi_sio 1-3:1.0: FTDI USB Serial Device converter detected
[ 6107.804055] usb 1-3: Detected FT232RL
[ 6107.804940] usb 1-3: FTDI USB Serial Device converter now attached to ttyUSB0
Ich denke das hängt mit deiner Definition zusammen.
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
Wenn du ein ftdi Chip mit drauf hast, dann fehlt da die eindeutige Nummer des Chips.
Lass dir mal in der Konsole, auf den pi zugegriffen, die angeschlossenen usb devices anzeigen.
ls -l /dev/serial/by-id
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Zitat von: sash.sc am 06 Oktober 2019, 20:53:25
Ich denke das hängt mit deiner Definition zusammen.
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
Wenn du ein ftdi Chip mit drauf hast, dann fehlt da die eindeutige Nummer des Chips.
Lass dir mal in der Konsole, auf den pi zugegriffen, die angeschlossenen usb devices anzeigen.
ls -l /dev/serial/by-id
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
Ich liefere das nach bin grad nicht am PC, was ich nicht verstehe, am anderen Intel-NUC hat das funktioniert mit dieser Definition
Zitat von: sash.sc am 06 Oktober 2019, 20:53:25
Ich denke das hängt mit deiner Definition zusammen.
DeviceName /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
Wenn du ein ftdi Chip mit drauf hast, dann fehlt da die eindeutige Nummer des Chips.
Lass dir mal in der Konsole, auf den pi zugegriffen, die angeschlossenen usb devices anzeigen.
ls -l /dev/serial/by-id
Gruß Sascha
Gesendet von meinem MI 9 mit Tapatalk
das hatte ich oben schon geschrieben, da kommt folgendes bei raus
root@fhem-server:~# ls -l /dev/serial/by-id
insgesamt 0
lrwxrwxrwx 1 root root 13 Okt 6 17:14 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Okt 6 15:32 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001949EB8D-if00 -> ../../ttyACM0
folgndes steht jetzt noch im log, da stimmt irgend etwas mit dem Zugriff nicht, aber ich kann es grad nicht deuten..
2019.10.06 19:33:26 1: sduino: Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
2019.10.06 19:33:26 3: Opening sduino device /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0
2019.10.06 19:33:26 3: sduino reset
Normalerweise hat die Systemgruppe dialout Rechte einen USBPort zu verwenden.
Der Systemaccount der den FHEM Prozess ausführt, sollte mitglied dieser Systemgruppe sein.
Grüße Sidey
das habe ich aber gemacht, immer wenn Dateien erstellt werden werden passe ich die Rechte an mit
chown -R fhem:dialout /opt/fhem
noch jemand einen Tipp.? Evtl. nochmal neu installieren bzw. den sduino neu anlegen.?
Hast du auf deinem nano einen ftdi Chip?
Gesendet von meinem MI 9 mit Tapatalk
Nicht das ich es wüsste
Dann solltest du einen ch340 Chip drauf haben oder?
Weil die Kennung by/id sich zum Teil aus der serial Nummer des ftdi oder aus der Kennung ch340 zusammen setzt.
Hier mal eine Definition von meinem cul mit ftdi
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A10489VD-if00-port0@38400 0000
Gesendet von meinem MI 9 mit Tapatalk
Nein, er hat definitiv keinen CH340, und da hat jemand eine ID vergeben (und wohl die serial gelöscht, wußte nicht, dass das geht...). Eine ID zu vergeben, geht jedenfalls mit CH340 nicht ;) . (Oder hattest du auf dem alten eine UDEV-rule definiert?!?)
Wie dem auch sei, das Problem könnte auf der Motherboard-Seite liegen. Das ist eine USB3-Schnittstelle, nehme ich an? Dann uU. mal im BIOS nachschauen, ob man die Geschwindigkeit drosseln kann (bzw. auf OS-Ebene). (Klemm mal testweise einen USB2-Hub dazwischen).
Zitat von: Beta-User am 07 Oktober 2019, 07:30:39
Nein, er hat definitiv keinen CH340, und da hat jemand eine ID vergeben (und wohl die serial gelöscht, wußte nicht, dass das geht...). Eine ID zu vergeben, geht jedenfalls mit CH340 nicht ;) . (Oder hattest du auf dem alten eine UDEV-rule definiert?!?)
Wie dem auch sei, das Problem könnte auf der Motherboard-Seite liegen. Das ist eine USB3-Schnittstelle, nehme ich an? Dann uU. mal im BIOS nachschauen, ob man die Geschwindigkeit drosseln kann (bzw. auf OS-Ebene). (Klemm mal testweise einen USB2-Hub dazwischen).
Zitat von: moonsorrox am 07 Oktober 2019, 00:19:40
das habe ich aber gemacht, immer wenn Dateien erstellt werden werden passe ich die Rechte an mit
chown -R fhem:dialout /opt/fhem
noch jemand einen Tipp.? Evtl. nochmal neu installieren bzw. den sduino neu anlegen.?
Laut einem Listing weiter oben gehört die usb Weiterleitung dem User Root und auch der Gruppe Root.
Vom usbport selbst hast Du kein listing angegeben glaube ich.
Schau da noch mal nach.
Gesendet von meinem Moto Z (2) mit Tapatalk
...dass die "by-id" / "by-path" - Schnittstellen root:root "gehören", ist normal. Im Ergebnis scheint entscheidend zu sein, dass dann die verlinkte Schnittstelle (/dev/ttyUSBx) für dialout freigegeben ist (was in der Regel der Fall ist), und fhem zur Gruppe dialout gehört (was in der Regel ebenfalls kein Problem darstellt).
Hi Beta-User,
Richtig. Danke für die gute Erklärung. Wissen wir, welchen Gruppen der User Fhem angehört und ob dialout auf die Schnittstelle berechtigt ist?
Grüße Sidey
Gesendet von meinem Moto Z (2) mit Tapatalk
Zitat von: Sidey am 07 Oktober 2019, 08:56:26
Wissen wir, welchen Gruppen der User Fhem angehört und ob dialout auf die Schnittstelle berechtigt ist?
::) Du hast natürlich recht, wenn du den Finger nochmals in diese Wunde legts; eines der beiden Dinge, die "üblicherweise" so sind, ist hier verbogen...
Vielen Dank für die zahlreichen Antworten, ich bin gerade etwas erschlagen davon :-\
Was ich jetzt noch liefern kann ist folgendes, der Intel-NUC den ich vorher dran hatte ist ist nur in der Prozesseor Variante etwas neuer.
DIe USB Schnittstelle ist ebenfalls eine USB 3.0 Schnittstelle, es ist eben sogar der gleiche Port an dem der sduino steckt, da sollte sich nichts dran geändert haben. Aber was kann ich euch jetzt noch liefern damit wir weiter kommen.?
Diesen Befehl hatte ich schon abgesetzt
chown -R fhem:dialout /opt/fhem
Das ist die eingelesene USB Schnittstelle
lrwxrwxrwx 1 root root 13 Okt 6 17:14 usb-SIGNALduino_433_MHz-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Okt 6 15:32 usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B001949EB8D-if00 -> ../../ttyACM0
wenn ich ein reset am sduino mache erscheint im log folgendes
2019.10.07 12:16:07 1: sduino: Can't open /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0: Permission denied
2019.10.07 12:16:07 3: Opening sduino device /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0
2019.10.07 12:16:07 3: sduino reset
also irgendetwas ist da mit dem Zugriff nicht OK..!
was wird jetzt noch benötigt, oder soll ich den nochmals anlegen.?
EDIT:
die RAW Dev
defmod sduino SIGNALduino /dev/serial/by-id/usb-SIGNALduino_433_MHz-if00-port0@57600
attr sduino blacklist_IDs 43
attr sduino cc1101_frequency 433,920
attr sduino group Hardware
attr sduino hardware nanoCC1101
attr sduino icon cul@blue
attr sduino room HWR,System
attr sduino sortby 08
attr sduino verbose 3
Wie kommst du auf den Gedanken, dass der Befehl
chown -R fhem:dialout /opt/fhem
irgendeine Auswirkungen auf die Rechte der USB-Schnittstelle haben könnte?!?
(Wir brauchen ein "ls -l" von /dev/ttyUSB* und die Gruppen, in denen fhem ist: http://man7.org/linux/man-pages/man1/groups.1.html (http://man7.org/linux/man-pages/man1/groups.1.html)).
damit wollte ich nur sagen das fhem dieser Gruppe zugeordnet ist..!
hier die Ausgabe von
fhem@fhem-server:~$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Okt 7 12:18 /dev/ttyUSB0
fhem@fhem-server:~$ ls -l
insgesamt 18336
-rw-rw-r-- 1 fhem fhem 18774592 Okt 7 2018 fhem-5.9.deb
EDIT: evtl. sollte das die falsche Gruppe sein..?
Der Befehl hat auch keinerlei Auswirkungen auf die Gruppenzugehörigkeit des users fhem, und das was du zuletzt an ls -l-Infos geliefert hast,zeigt zwar, dass die USB-Schnittstelle korrekterweise durch dialout-Gruppenmitglieder genutzt werden darf, sagt aber nichts zu der zweiten Frage aus.
(Wenn du nicht mit einer so kurzen manpage wie der verlinkten klarkommst, solltest du ernsthaft darüber nachdenken, ob FHEM@Linux das passende setup für dich ist...)
Just my2ct.
Zitat von: Beta-User am 07 Oktober 2019, 13:05:22
(Wenn du nicht mit einer so kurzen manpage wie der verlinkten klarkommst, solltest du ernsthaft darüber nachdenken, ob FHEM@Linux das passende setup für dich ist...)
ich habe auch nicht behauptet das ich der Mega Linux Freak bin...! :-\
Das Problem ist eben das man nicht ewig damit beschäftigt ist wie was wo eingestellt werden muss und somit ist auch mal etwas aus dem Kopf verschwunden, was ist daran so schlimm, dazu ist das Forum da um Fragen zustellen.
ich richte nicht jeden Tag einen sduino ein und ich hatte damit als ich es seinerzeit eingerichtet hatte nicht diese Probleme.
das habe ich hier noch wenn es die Frage war:
fhem : fhem adm tty cdrom sudo dip plugdev lxd lpadmin sambashare
hier ist wohl etwas krumm... ;)
Ich weiß jetzt nicht was ich machen soll...!
OK, also fhem ist nicht Mitglied in dialout...
Da findest du die Lösung:
https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/
;) siehe eben geschrieben
EDIT: das war mein alter Intel-NUC
fhem : fhem adm dialout cdrom sudo dip plugdev lpadmin sambashare
Schhh. edits.
Siehe geänderter Beitrag...
Zitat von: Beta-User am 07 Oktober 2019, 13:12:34
OK, also fhem ist nicht Mitglied in dialout...
Da findest du die Lösung:
https://wiki.ubuntuusers.de/Benutzer_und_Gruppen/
jou jetzt habe ich es ;) das mit den Gruppen (blöd von mir) :-X
ich denke das ist seinerzeit mit dem Ubuntu 14.04 eben anders gewesen als jetzt beim 18.04
An einen Unterschied zwischen den Ubuntu-Versionen mag ich nicht glauben. Du hast beim Installieren von FHEM vermutlich irgendwas gemacht, was nicht default ist (z.B. nur den opt/fhem-Zweig kopiert und das Startscript für systemd manuell angelegt?).
Wenn du sowas verschweigst, bekommst du zurecht Haue :P .
Zitat von: Beta-User am 07 Oktober 2019, 13:19:48
An einen Unterschied zwischen den Ubuntu-Versionen mag ich nicht glauben. Du hast beim Installieren von FHEM vermutlich irgendwas gemacht, was nicht default ist (z.B. nur den opt/fhem-Zweig kopiert und das Startscript für systemd manuell angelegt?).
Wenn du sowas verschweigst, bekommst du zurecht Haue :P .
warst du dabei..? ;)
ich habe ein backup eingespielt und ja das Startscript für systemd manuell angelegt :-\ :-\
OK ich sage einmal ein großes Danke :) der sduino ist Opened :)
Übrigens warst
DU derjenige der es letztens gesagt hatte ich sollte mein Ubuntu aktuell halten, du erinnerst dich.? Ich wollte das zigbee2mqttl einfügen und irgend etwas was nicht aktuell glaube es war node...
Ich wollte auch nur einen weiteren Intel-NUC anschaffen und loslegen... das habe ich jetzt getan... egal jetzt mache ich weiter mit zigbee ;) ;)
EDIT:
Übrigens jetzt wo ich es schreibe wundert es mich das beim backup kein hmcfgusb und auch kein zigbee2mqtt mir gemacht wird, demnach wird wohl beim backup nur der fhem Zweig genommen.
Es ist schon ok, wenn du ein aktuelles OS nutzt (das sollte man in der Tat tun), es ging auch eher darum, ob sich die Installationsmechanismen für FHEM (debian-Paket) geändert haben (ja, aber nur dahingehend, dass jetzt systemd statt init.d genutzt wird) wie implizit behauptet. Aber der user fhem wurde "schon immer" zu dialout hinzugefügt, das konnte schlicht nicht die Ursache sein, dass fhem nicht in dialout war... Von da ab war es "einfach" mit der Diagnose, dass du da was "ungewöhnliches" gemacht haben mußtest.
(Und zur Klarstellung: die Empfehlung, FHEM "anders" zu installieren, stammt jedenfalls nicht von mir ;D .)
Der CC1101 auf einem Arduino bleibt bei einem "set Signalduino reset" hängen und muss dann physisch getrennt werden. Hab ich mal irgendwo gelesen. Im Übrigen habe ich gute Erfahrungen mit einem aktiven USB-2.0-Hub.
Gruß Jens
Zitat von: dirigent am 07 Oktober 2019, 18:03:43
Der CC1101 auf einem Arduino bleibt bei einem "set Signalduino reset" hängen und muss dann physisch getrennt werden. Hab ich mal irgendwo gelesen. Im Übrigen habe ich gute Erfahrungen mit einem aktiven USB-2.0-Hub.
Gruß Jens
der sduino läuft jetzt schon ein paar stunden und es lag an einer Rechtevergabe
mit einer aktuellen Firmware sollten normalerweise keine resets notwendig sein.
Ich habe bei mir inzwischen eine uptime von 112 Tagen.
Gruß Ralf
@dirigent: das Test-PIN-Problem hast du mal geprüft?
Sorry, wenn ich mich falsch ausgedrückt habe. Meine Signalduino (1x Nano ohne CC1101, 1x Nano mit mi CC1101) laufen zuverlässig. Das Reboot-Problem bezog sich irrtümlich auf einen NanoCUL https://wiki.fhem.de/wiki/Selbstbau_CUL#Hinweise_zum_Betrieb_mit_FHEM (https://wiki.fhem.de/wiki/Selbstbau_CUL#Hinweise_zum_Betrieb_mit_FHEM).
@Beta-User: Test-Pin-Problem - im Web gesucht und wieder was dazugelernt. Danke.
Gruß Jens