vcontrold hängt sporadisch - usb-Problem?

Hallo zusammen, habe vcontrold nach der Anleitung https://openv.wikispaces.com/vcontrold+mit+Raspberry+Pi installiert und komme auch damit nun recht gut klar. Mittels viessmann-Adapter konnte ich die Heizung auch in ioBroker einbinden. Leider "hängt sich" vcontrold sporadisch auf (mal nach 4-5 Std - mal nach 3-4 Tagen). Anschließend hilft nur ein Neustart des vcontrold-raspi.

Hier meine Konfiguration: 1 raspi 3B+ mit ioBroker 1 raspi 3B+ mit vcontrold und Original Optolink Kabel aus original Vitoconnect 100 Typ OPTO1 und Software "2018-06-27-raspbian-stretch-lite.zip"

Auf dem raspi mit vcontrold: vctrld>version Version: 0.98.2_IPv6 mittlerweile geupdatet auf version 0.98.6-1-g96c2a55

Meine Vito habe ich mit dem Windows-Programm v-control1_2_5.exe zuvor ausgelesen: Anlage mit V200 KW6B wird als "VScotH01" in log-Datei angegeben, hieraus ID "20CB" ermittelt per Geräteliste unter openv

Folgendes habe ich versucht - leider ohne Besserung:

vom Pi1 auf Pi3B+ gewechselt
SD Karte erneuert
Netzgerät auf 2 A getauscht
Software mehrmals neu installiert gemäß Anleitung und aktualisiert
Autostart von vcontrold entfernt - starte jetzt nur noch nach Neustart des raspi mit Befehl "vcontrold"
Raspi und Software erneut nstalliert - diesmal ohne die Schritte von https://openv.wikispaces.com/vcontrold+mit+Raspberry+Pi
ioBroker mit viessmann-Adapter entfernt
vcontrold auf version 0.98.6-1-g96c2a55 geupdatet

Beim "Aufhängen" der vcontrold scheint es wohl am USB-Port zu liegen - hier habe ich immer den Optolink-Adapter auf mehrere USB connected:

Fehlerfall 27.09.18: (ohne Autostart, Vito zuvor mit vcontrold gestartet!): root@raspberrypi: dmesg | grep "now attached" [ 3.997639] usb 1-1.1.2: cp210x converter now attached to ttyUSB0 [ 515.526622] usb 1-1.1.2: cp210x converter now attached to ttyUSB1 [ 3626.433020] usb 1-1.1.2: cp210x converter now attached to ttyUSB1 [ 3627.710916] usb 1-1.1.2: cp210x converter now attached to ttyUSB1 root@raspberrypi:~#

Beim Neustart sieht es folgendermaßen aus: root@raspberrypi: dmesg | grep "now attached" [ 3.367114] usb 1-1.1.2: cp210x converter now attached to ttyUSB0

Danach funktioniert vcontrold problemlos bis zum nächsten "aufhängen".

Hier noch meine udevadm info direkt nach reboot:

root@raspberrypi:~# sudo udevadm info --name=/dev/ttyUSB0 --attribute-walk

Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.

looking at device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/ttyUSB0/tty/ttyUSB0': KERNEL=="ttyUSB0" SUBSYSTEM=="tty" DRIVER==""

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/ttyUSB0': KERNELS=="ttyUSB0" SUBSYSTEMS=="usb-serial" DRIVERS=="cp210x" ATTRS{port_number}=="0"

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0': KERNELS=="1-1.1.2:1.0" SUBSYSTEMS=="usb" DRIVERS=="cp210x" ATTRS{authorized}=="1" ATTRS{bAlternateSetting}==" 0" ATTRS{bInterfaceClass}=="ff" ATTRS{bInterfaceNumber}=="00" ATTRS{bInterfaceProtocol}=="00" ATTRS{bInterfaceSubClass}=="00" ATTRS{bNumEndpoints}=="02" ATTRS{interface}=="CP2102 USB to UART Bridge Controller" ATTRS{supports_autosuspend}=="1"

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2': KERNELS=="1-1.1.2" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{authorized}=="1" ATTRS{avoid_reset_quirk}=="0" ATTRS{bConfigurationValue}=="1" ATTRS{bDeviceClass}=="00" ATTRS{bDeviceProtocol}=="00" ATTRS{bDeviceSubClass}=="00" ATTRS{bMaxPacketSize0}=="64" ATTRS{bMaxPower}=="100mA" ATTRS{bNumConfigurations}=="1" ATTRS{bNumInterfaces}==" 1" ATTRS{bcdDevice}=="0100" ATTRS{bmAttributes}=="80" ATTRS{busnum}=="1" ATTRS{configuration}=="" ATTRS{devnum}=="4" ATTRS{devpath}=="1.1.2" ATTRS{devspec}==" (null)" ATTRS{idProduct}=="ea60" ATTRS{idVendor}=="10c4" ATTRS{ltm_capable}=="no" ATTRS{manufacturer}=="Silicon Labs" ATTRS{maxchild}=="0" ATTRS{product}=="CP2102 USB to UART Bridge Controller" ATTRS{quirks}=="0x0" ATTRS{removable}=="removable" ATTRS{serial}=="0001" ATTRS{speed}=="12" ATTRS{urbnum}=="16" ATTRS{version}==" 1.10"

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1': KERNELS=="1-1.1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{authorized}=="1" ATTRS{avoid_reset_quirk}=="0" ATTRS{bConfigurationValue}=="1" ATTRS{bDeviceClass}=="09" ATTRS{bDeviceProtocol}=="02" ATTRS{bDeviceSubClass}=="00" ATTRS{bMaxPacketSize0}=="64" ATTRS{bMaxPower}=="2mA" ATTRS{bNumConfigurations}=="1" ATTRS{bNumInterfaces}==" 1" ATTRS{bcdDevice}=="0bb3" ATTRS{bmAttributes}=="e0" ATTRS{busnum}=="1" ATTRS{configuration}=="" ATTRS{devnum}=="3" ATTRS{devpath}=="1.1" ATTRS{idProduct}=="2514" ATTRS{idVendor}=="0424" ATTRS{ltm_capable}=="no" ATTRS{maxchild}=="3" ATTRS{quirks}=="0x0" ATTRS{removable}=="fixed" ATTRS{speed}=="480" ATTRS{urbnum}=="41" ATTRS{version}==" 2.00"

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1': KERNELS=="1-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{authorized}=="1" ATTRS{avoid_reset_quirk}=="0" ATTRS{bConfigurationValue}=="1" ATTRS{bDeviceClass}=="09" ATTRS{bDeviceProtocol}=="02" ATTRS{bDeviceSubClass}=="00" ATTRS{bMaxPacketSize0}=="64" ATTRS{bMaxPower}=="2mA" ATTRS{bNumConfigurations}=="1" ATTRS{bNumInterfaces}==" 1" ATTRS{bcdDevice}=="0bb3" ATTRS{bmAttributes}=="e0" ATTRS{busnum}=="1" ATTRS{configuration}=="" ATTRS{devnum}=="2" ATTRS{devpath}=="1" ATTRS{idProduct}=="2514" ATTRS{idVendor}=="0424" ATTRS{ltm_capable}=="no" ATTRS{maxchild}=="4" ATTRS{quirks}=="0x0" ATTRS{removable}=="unknown" ATTRS{speed}=="480" ATTRS{urbnum}=="27" ATTRS{version}==" 2.00"

looking at parent device '/devices/platform/soc/3f980000.usb/usb1': KERNELS=="usb1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{authorized}=="1" ATTRS{authorized_default}=="1" ATTRS{avoid_reset_quirk}=="0" ATTRS{bConfigurationValue}=="1" ATTRS{bDeviceClass}=="09" ATTRS{bDeviceProtocol}=="01" ATTRS{bDeviceSubClass}=="00" ATTRS{bMaxPacketSize0}=="64" ATTRS{bMaxPower}=="0mA" ATTRS{bNumConfigurations}=="1" ATTRS{bNumInterfaces}==" 1" ATTRS{bcdDevice}=="0414" ATTRS{bmAttributes}=="e0" ATTRS{busnum}=="1" ATTRS{configuration}=="" ATTRS{devnum}=="1" ATTRS{devpath}=="0" ATTRS{idProduct}=="0002" ATTRS{idVendor}=="1d6b" ATTRS{interface_authorized_default}=="1" ATTRS{ltm_capable}=="no" ATTRS{manufacturer}=="Linux 4.14.69-v7+ dwc_otg_hcd" ATTRS{maxchild}=="1" ATTRS{product}=="DWC OTG Controller" ATTRS{quirks}=="0x0" ATTRS{removable}=="unknown" ATTRS{serial}=="3f980000.usb" ATTRS{speed}=="480" ATTRS{urbnum}=="26" ATTRS{version}==" 2.00"

looking at parent device '/devices/platform/soc/3f980000.usb': KERNELS=="3f980000.usb" SUBSYSTEMS=="platform" DRIVERS=="dwc_otg" ATTRS{busconnected}=="Bus Connected = 0x1" ATTRS{buspower}=="Bus Power = 0x1" ATTRS{bussuspend}=="Bus Suspend = 0x0" ATTRS{devspeed}=="Device Speed = 0x0" ATTRS{driver_override}=="(null)" ATTRS{enumspeed}=="Device Enumeration Speed = 0x1" ATTRS{fr_interval}=="Frame Interval = 0x1d4b" ATTRS{ggpio}=="GGPIO = 0x00000000" ATTRS{gnptxfsiz}=="GNPTXFSIZ = 0x01000306" ATTRS{gotgctl}=="GOTGCTL = 0x001c0001" ATTRS{gpvndctl}=="GPVNDCTL = 0x00000000" ATTRS{grxfsiz}=="GRXFSIZ = 0x00000306" ATTRS{gsnpsid}=="GSNPSID = 0x4f54280a" ATTRS{guid}=="GUID = 0x2708a000" ATTRS{gusbcfg}=="GUSBCFG = 0x20001700" ATTRS{hcd_frrem}=="HCD Dump Frame Remaining" ATTRS{hcddump}=="HCD Dump" ATTRS{hnp}=="HstNegScs = 0x0" ATTRS{hnpcapable}=="HNPCapable = 0x1" ATTRS{hprt0}=="HPRT0 = 0x00001005" ATTRS{hptxfsiz}=="HPTXFSIZ = 0x02000406" ATTRS{hsic_connect}=="HSIC Connect = 0x1" ATTRS{inv_sel_hsic}=="Invert Select HSIC = 0x0" ATTRS{mode}=="Mode = 0x1" ATTRS{mode_ch_tim_en}=="Mode Change Ready Timer Enable = 0x0" ATTRS{rd_reg_test}=="Time to read GNPTXFSIZ reg 10000000 times: 1660 msecs (166 jiffies)" ATTRS{regdump}=="Register Dump" ATTRS{regoffset}=="0xffffffff" ATTRS{regvalue}=="invalid offset" ATTRS{rem_wakeup_pwrdn}=="" ATTRS{remote_wakeup}=="Remote Wakeup Sig = 0 Enabled = 0 LPM Remote Wakeup = 0" ATTRS{spramdump}=="SPRAM Dump" ATTRS{srp}=="SesReqScs = 0x1" ATTRS{srpcapable}=="SRPCapable = 0x1" ATTRS{wr_reg_test}=="Time to write GNPTXFSIZ reg 10000000 times: 300 msecs (30 jiffies)"

looking at parent device '/devices/platform/soc': KERNELS=="soc" SUBSYSTEMS=="platform" DRIVERS=="" ATTRS{driver_override}=="(null)"

looking at parent device '/devices/platform': KERNELS=="platform" SUBSYSTEMS=="" DRIVERS==""

Im Fehlerfall erhalte ich bei root@raspberrypi:~# sudo udevadm info --name=/dev/ttyUSB0 --attribute-walk device node not found

USB1 liefert dann ein Ergebnis:

root@raspberrypi:~# sudo udevadm info --name=/dev/ttyUSB1 --attribute-walk

looking at device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/ttyUSB1/tty/ttyUSB1': KERNEL=="ttyUSB1" SUBSYSTEM=="tty" DRIVER==""

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0/ttyUSB1': KERNELS=="ttyUSB1" SUBSYSTEMS=="usb-serial" DRIVERS=="cp210x" ATTRS{port_number}=="0"

looking at parent device '/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1/1-1.1.2/1-1.1.2:1.0': KERNELS=="1-1.1.2:1.0" .... nd noch einiges mehr .... ....

Wäre schön, wenn mir jemand helfen könnt. Viele Grüße Micky14

Versuche als mal, die Schnittstelle des Optolink-Adapters mit einem gleichbleibenden Namen zu versehen. Das machst Du mit einem Eintrag für udev, z.B. in /etc/udev/rules.d/99-optlink.rules:

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="0001", SYMLINK+="optolink"

Der Eintrag entspricht deinen obigen Angaben (beachte ATTRS{serial} - ich hätte hier etwas anderes erwartet, habe aber keinen originalen Optolink).

Dann ein sudo service udev reload und nach dem Neueinstöpseln des Optolink-Adapters in die USB-Schnittstelle erscheint dieser als /dev/optolink, so dass vcontrold das Gerät immer unter gleichem Namen finden kann (Konfig unix>config>serial>tty in der vcontrold.xml entsprechend anpassen).

Hallo Sönke, vilen Dank für den Vorschlag. Ich hatte bereits ähnliches versucht: Erstellung einer 70-lesekopf.rules: SUBSYSTEMS=="usb", ATTRS(serial)=="0001", SYMLINK+="vitoir0" Beim Neustart konnte ich dann die Schnittstelle mit vitoir0 (in der XML) ansprechen - ein ls -l /dev/vitoir0 lieferte folgendes Ergebnis: root@raspberrypi: ls -l /dev/vitoir0 lrwxrwxrwx 1 root root 7 Sep 27 13:05 /dev/vitoir0 -> ttyUSB0

Dennoch hängte sich die vcontrold auf und es waren dabei wieder mehre USB-Einträge mit dmesg | grep "now attached" vorhanden.

Habe jetzt noch Deinen Vorschlag versucht und eine Datei 99-optlink.rules mit folgendem Inhalt erstellt: SUBSYSTEM=="tty", ATTRS{idVendor)=="10c4", ATTRS{idProduct)=="ea60", ATTRS{serial]=="0001", SYMLINK+="optolink" und den rapi neu gestartet. Nun liefert root@raspberrypi:~# ls -l /dev/optolink ls: Zugriff auf '/dev/optolink' nicht möglich: Datei oder Verzeichnis nicht gefunden und auch vcontrold funktioniert nicht.

Im Gegensatz zu meinem früheren Versuch hast Du auch SUBSYSTEM=="tty" statt wie ich SUBSYSTEMS==usb" (mit S und usb) vorgeschlagen. Ich hatte die Info damals aus einen anderen Forum und kann leider nicht beurteilen, was hier richtig ist. Kenne mich mit Linux nicht aus.

1. Serielle Schnittstelle festsetzen

In deinen Rules sieht die Klammersetzung nicht in Ordnung aus. Deine Regel wäre auch sehr weit gefasst, sie träfe auf alle USB-Geräte mit der Serial "0001" zu. Das würde ich wie oben beschrieben lieber etwas spezifizieren.

Der User bzw. die Gruppe, unter der vcontrold läuft, muss natürlich Zugriff auf die serielle Schnittstelle haben. Die Gruppe legst du in GROUP fest (ich habe hier mal exemplarisch dialout genommen), 0660 steht für Schreib- und Leseberechtigung für den Owner und die Gruppe, kein Zugriff für andere.

SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="0001"   GROUP="dialout", MODE="0660", SYMLINK+="vitoir"

Wenn du es dann nach Korrigieren der Regel, Neu-Einlesen via service udev reload und Neu-Einstöpseln des USB-Steckers des Optolink in den Raspi eine nun festen Devicenamen /dev/vitoir oder was auch immer hast, muss vcontrold diesen auch noch in seiner Konfiguration haben.

Jetzt findet vcontrold zumindest schonmal immer die richtige serielle Schnittstelle und eine mögliche Fehlerquelle ist raus.

2. Kernelmeldungen genauer anschauen

Schau mal genauer in die Kernelmeldungen, ob da was bestimmtes passiert, bevor der USB-Seriell-Adapter neu eingehangen wird: dmesg | grep -B 10 attached | less Ist zu erkennen, ob da was dazwischenfunkt? Bei Google finden sich z.B. Hinweise auf brltty.

3. `vcontrold` als Übeltäter ausschliessen

Beende vcontrold und halte die Schnittstelle mit einem Terminalprogramm, socat, vitalk o.ä. auf und beobachte, ob sich der Adapter auch hier sporadisch verabschiedet.

Wenn ja, dann versuche mal, einen externen USB-Hub mit Spannungsversorgung zwischen Raspi und USB-Optolink zu setzen.

Ist es nun stabil, so wie vorher oder wird zusätzlich auch der Hub neu verbunden?

Wie verhält es sich, wenn der Raspi ohne Ethernet betrieben wird (serielle Konsole nutzen)?

4. Anderes Kabel versuchen

Hast du noch eine andere Möglichkeit, die Optolink-Schnittstelle anzubinden. Also z.B. per FTDI232 oder direkt an eine "echte" serielle Schnittstelle (ttyS?) des Raspi?

Das war's erstmal mit spontanen Ideen, viel Erfolg!

Hallo Sönke, vielen Dank für die Tipps. ''Du hast natürlich Recht mit der falschen Klammer in meiner rules gehabt - nachdem ich diese korrigiert habe auf SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="0001", SYMLINK+="optolink" funktioniert vcontrol mit dem Devicenamen "optolink" (vorerst) problemlos. Von gestern 22:21 Uhr bis heute 18:45. Danach war der optolink wieder von USB0 auf USB1 gewechselt und vconstrol stürzte ab.

Hier ein Auszug aus der dmesg (dort war nach Hochfahren des raspi bis zum heutigen, erneuten Problem nichts besonders passiert - aber dann kam Fehlermeldung usb_serial_generic_read_bulk_callback - urb stopped: -32 : root@raspberrypi: dmesg -T .... .... [Fr Sep 28 22:21:05 2018] Bluetooth: BNEP filters: protocol multicast [Fr Sep 28 22:21:05 2018] Bluetooth: BNEP socket layer initialized [Sa Sep 29 18:48:14 2018] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [Sa Sep 29 18:48:14 2018] cp210x ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32 [Sa Sep 29 18:48:14 2018] cp210x ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32 [Sa Sep 29 18:48:14 2018] usb 1-1.1.2: USB disconnect, device number 4 [Sa Sep 29 18:48:14 2018] cp210x ttyUSB0: failed set request 0x12 status: -19 [Sa Sep 29 18:48:14 2018] cp210x ttyUSB0: failed set request 0x0 status: -19 [Sa Sep 29 18:48:14 2018] cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 [Sa Sep 29 18:48:14 2018] cp210x 1-1.1.2:1.0: device disconnected [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: new full-speed USB device number 6 using dwc_otg [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: New USB device found, idVendor=10c4, idProduct=ea60 [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: Product: CP2102 USB to UART Bridge Controller [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: Manufacturer: Silicon Labs [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: SerialNumber: 0001 [Sa Sep 29 18:48:15 2018] cp210x 1-1.1.2:1.0: cp210x converter detected [Sa Sep 29 18:48:15 2018] usb 1-1.1.2: cp210x converter now attached to ttyUSB1 root@raspberrypi:~#

Googlen nach "usb_serial_generic_read_bulk_callback" brachte mir den Vorschlag, den USB auf 1.1 zu verlangsamen:

You could try the nuclear option - add dwc_otg.speed=1 to /boot/cmdline.txt - this forces the entire bus to USB1.1 speeds

Habe ich nun mal so eingestellt und den raspi neu gestartet. Vcontrold arbeitet zur Zeit wieder (noch) wie gewünscht.

Könntest Du mir für deinen 4. Vorschlag (neues Kabel) ein (fertiges) Optokabel für Viessmann empfehlen? Ich versuche nun schon 3 Monate die Viessmann in mein Smarthome zu integrieren - und langsam wird es kalt und die Frau ungeduldig :-)

Hi :-)

Könntest Du mir für deinen 4. Vorschlag (neues Kabel) ein (fertiges) Optokabel für Viessmann empfehlen? Ich versuche nun schon 3 Monate die Viessmann in mein Smarthome zu integrieren - und langsam wird es kalt und die Frau ungeduldig :-)

Wenn ein Raspberry Pi benutzt, wie wäre es dann mit einem Connector, der die GPIO-Pins nutzt? Unter https://github.com/openv/openv/wiki/Bauanleitung-RaspberryPi gibt's eine Bauanleitung. Der "normale" Schaltplan ist von mir. Ich betreibe den Connector auf den Fotos jetzt seit 2016 im Dauerbetrieb ohne irgendwelche Probleme. War einfach zu löten (ich bin kein Profi und hab das problemlos geschafft!) und kostet fast nix.

Dann muss man sich nicht mit USB-Kram rumschlagen.

Nur, um das mal in die Runde zu werfen ...

Viele Grüße :-)

Hallo Tobias, ist auch ein guter Ansatz und ziehe ich mal für die langen Winterabende in Betracht (wenn ich nicht mehr dauernd in den Keller laufen möchte, um die Heizung anders einzustellen :-).

Hallo zusammen, konnte die Ursache des Fehlers finden - kaum zu glauben - aber wahr. Der USB verabschiedete sich immer dann, wenn das Licht im Heizraum eingeschaltet wurde. Dort ist eine Leuchtstoffröhre verbaut (36W mit eingebautem Starter, Drossel und Entstörkondensator).

Eine gute Hilfe war hier der Befehl " dmesg -T", der mir den Zeitpunkt des Ausfalls mit Datum/Uhrzeit genau zeigte. Danach konnte ich den Fehler immer mit dem Lichtschalter provozieren.

Erster Versuch der Abhilfe war der Einbau eines Ferritringes in der Netzteizuleitung (mit 4 Windungen) des Raspi - brachte aber keinen Erfolg.

Zeiter Versuch: zusätlicher Ferrit-Ring in der USB-Leitung des Optolink. Brachte etwas Besserung - Feher trat aber immer noch auf.

Dritter Versuch - mit bisher dauerhaftem Erfolg: Masse des USB-Steckers mit Kabel verlötet und dieses dann mit Potentialausgleichsschine verbunden. Seit dem keine Probleme mehr. (So oft wie hier beim Testen habe ich die Lampe das letzte 1/4 Jahr nicht ein/ausgeschaltet.)

Super, dass Du das Problem in den Griff bekommen hast und vielen Dank für die Darstellung der Lösung - da können vielleicht andere noch von profitieren.

openv / vcontrold