hoher Duty Cycle durch Fehler Hue Bridge ?

Einrichtung, Nutzung und Hilfe zu RaspberryMatic (OCCU auf Raspberry Pi)

Moderatoren: jmaus, Co-Administratoren

romeoalfa1975
Beiträge: 133
Registriert: 04.04.2019, 18:26
Hat sich bedankt: 14 Mal
Danksagung erhalten: 9 Mal

hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von romeoalfa1975 » 13.11.2019, 06:53

Moin!

Ich habe in den letzten Tagen auch dieses Phänomen und konnte den Fehler bisher auch nicht finden.
Daraufhin habe ich nun extra mal die RaspberryMatic auf meine CCU3 gespielt und die Geräte dort wieder neu angelernt. Quasi richtig frisch noch mal angefangen. Jetzt, nach zwei Tagen, hatte ich über Nacht (ausgerechnet, wo nichts geschaltet oder genutzt wurde) wieder für ca. eine Stunde Dutycycle von 98-100%. Interessanterweise ohne Webui-Programme (die muss ich erst noch wieder anlegen). Die Geräte sind alle auf wenig senden eingestellt (meine Messsteckdosen habe ich erst gar nicht angelernt).

Jetzt habe ich auch mal Funk loggen auf "alles" gestellt und bin gespannt, wann es das nächste Mal passiert.
Bisher kann ich schon mal sagen, dass dieser ominöse Anstieg des DC sowohl mit der original eq-3 Firmware, als auch mit der RaspberryMatic passiert.
Noch seltsamer ist es, dass seit Monaten nun keine neuen HmIP-Geräte dazugekommen sind und vorher der DC im Ruhezustand immer so bei 15-18% lag. Jetzt liegt er, wenn sich alles beruhigt hat, dennoch bei ca. 30%.

Ich poste mal einen Ausschnitt des Protokolls, dort sind irgendwelche RGB-Einträge zu sehen - könnte es mit einer angelernten he-Bridge zu tun haben? Diese ist allerdings schon immer angelernt gewesen und hatte bisher keine Probleme gemacht.

Code: Alles auswählen

Nov 12 22:12:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 84%
Nov 12 22:13:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 84%
Nov 12 22:14:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 85%
Nov 12 22:15:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 12 22:16:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 86%
Nov 12 22:20:41 ccu3-webui local0.err ReGaHss: ERROR: ScriptRuntimeError:  {    object oRGB = cObj.DPByControl("RGBW_COLOR.RGBW");    integer rgbID = -1;   string rgbValue = "unknown";   string rgbDefaultValue = "rgb(255,255,255,255)";    if (oRGB) {     rgbID = oRGB.ID();     rgbValue = oRGB.Value();     rgbDefaultValue = oRGB.MetaData("DEFAULT").ToString();   }    WriteLine("<tr>");      WriteLine("<td>");       WriteLine("<table width='100%' _height='100%' cellspacing='4'>");         WriteLine("<tr>");           WriteLine("<td>");             WriteLine("<table class='ControlBtnInfo' style='width: 250px;'>");               WriteLine("<tr>");                 WriteLine("<td style='text-align:left'>");                   WriteLine("<span>${lblColorValue}</span>");                 WriteLine("</td>");                 WriteLine("<td style='text-align:right'>");                   WriteLine("<input type='text' id='colorPicker"#chnId#"'></input>");                 WriteLine("</td>");               WriteLine("</tr>");             Wri
Nov 12 22:20:41 ccu3-webui local0.err ReGaHss: ERROR: ScriptRuntimeError:  {    object oWhiteLevel = cObj.DPByControl("COLORTEMP.WHITE");    integer whiteLevelID = -1;   string whiteLevelValue = "-1";   real whiteLevelMin = 2700;   real whiteLevelMax = 6500;   real whiteLevelStep = 50;     if (oWhiteLevel) {     whiteLevelID = oWhiteLevel.ID();     whiteLevelValue = oWhiteLevel.Value();     whiteLevelMin   = oWhiteLevel.MetaData("MIN");     whiteLevelMax   = oWhiteLevel.MetaData("MAX");     ! Check if the parameter STEP exists whiteLevelStep   = oWhiteLevel.MetaData("STEP");    }    WriteLine("<tr>");    WriteLine("<td>");      WriteLine("<table class='ControlBtnInfo' style='width: 250px; margin-left: 5px;'>");         WriteLine("<tr>");           WriteLine("<td style='text-align:left'><span>${lblColorTemperatureBR}</span></td>");           WriteLine("<td class='CLASS02546' style='text-align:right'>");             WriteLine("<div class='PercBtn' style='height:35px; line-height:35px; width:100px; background-color:#89989b; dis
Nov 12 23:06:38 ccu3-webui daemon.info chronyd[669]: Can't synchronise: no majority
Nov 12 23:07:23 ccu3-webui daemon.info chronyd[669]: Selected source 90.187.99.165
Nov 12 23:10:52 ccu3-webui daemon.info chronyd[669]: Selected source 131.234.137.64
Nov 12 23:31:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 81%
Nov 12 23:32:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 84%
Nov 12 23:33:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 89%
Nov 12 23:34:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 95%
Nov 12 23:35:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:36:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:37:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 98%
Nov 12 23:38:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:39:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:40:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:41:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:42:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 98%
Nov 12 23:43:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 99%
Nov 12 23:44:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 100%
Nov 12 23:45:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 100%
Nov 12 23:46:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 100%
Nov 12 23:47:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 97%
Nov 12 23:48:00 ccu3-webui user.info dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 97%
Nov 12 23:49:00 ccu3-webui user.err dutycycle: DutyCycle-QEQ0145281 / CCU2 / FW: 4.0.20 / DC: 98%
Zuletzt geändert von alchy am 13.11.2019, 08:14, insgesamt 2-mal geändert.
Grund: Code in Codetags posten & abgetrennt von CCU3 Thread

Xel66
Beiträge: 9578
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 128 Mal
Danksagung erhalten: 623 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von Xel66 » 13.11.2019, 09:05

romeoalfa1975 hat geschrieben:
13.11.2019, 06:53
Daraufhin habe ich nun extra mal die RaspberryMatic auf meine CCU3 gespielt und die Geräte dort wieder neu angelernt.
Warum gibt Dein Log dann eine CCU2 aus. Irgendwie verwirrend.
romeoalfa1975 hat geschrieben:
13.11.2019, 06:53
Ich poste mal einen Ausschnitt des Protokolls, dort sind irgendwelche RGB-Einträge zu sehen - könnte es mit einer angelernten he-Bridge zu tun haben?
Das Log ist "unvollständig". Meine, es fehlen Zeitbereiche. Du loggst den DutyCycle im Minutentakt aber zwischen 22:20 Uhr und 23:06 Uhr gibt es eine riesige Lücke. Vor dem RGB-Eintrag fehlen auch ein paar Minuten. Was ist dort passiert? An einer Hue-Bridge kann es eher nicht liegen. Die wird per Netzwerk angesprochen und die Geräte sind über einen ganz anderen Frequenzbereich miteinander vernetzt. Wenn Du die CCU und Bridge nicht gerade in unmittelbarer Nähe (wenige Zentimeter) betreibst, dann sollte es dort keine Beeinflussungen geben. Viel mehr ist ein anderer Eintrag interessant.

Code: Alles auswählen

Nov 12 23:06:38 ccu3-webui daemon.info chronyd[669]: Can't synchronise: no majority]
Warum hat die CCU keinen Netzwerkzugriff? Es scheint, als könnte sie keine NTP-Server erreichen.

Gruß Xel66
-------------------------------------------------------------------------------------------
343 Kanäle in 118 Geräten und 264 CUxD-Kanäle in 33 CUxD-Geräten:
282 Programme, 246 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.55.10.20210213 + Testsystem: CCU2 2.53.27
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

romeoalfa1975
Beiträge: 133
Registriert: 04.04.2019, 18:26
Hat sich bedankt: 14 Mal
Danksagung erhalten: 9 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von romeoalfa1975 » 13.11.2019, 09:18

Hallo Xel66,

danke für die schnelle Reaktion.
ja, da steht CCU2 - das hat mich auch gewundert. Es ist eine originale CCU3 mit der aktuellen RaspberryMatic-Version. Habe diesen CCU2-Eintrag auch schon beim Googlen in anderen Logs gesehen. Eventuell ein Überbleibsel aushalten Zeiten?

Zumindest der Ausschnitt, den ich gepostet habe, ist ein zusammenhängender, da habe ich nichts weggelassen.
Die hue Bridge steht ca. 50cm neben der CCU3. Hat aber bisher (seit Januar) nie Probleme gemacht.

Wegen des Netzwerkzugriffs: Die CCU3 hängt direkt an einer FritzBox. Eventuell sollte ich diese mal neu starten?

Bin irgendwie ratlos momentan. Habe die RaspberryMatic vor einer Stunde mal neu gestartet, seitdem ist der DC wieder so bei ca. 30% im Ruhezustand. Werde das jetzt bis heute Mittag mal laufen lassen - dann ist niemand zu Hause und es müsste funktechnisch Ruhe einkehren.

Falls das nichts bringt, würde ich
- die hue Bridge ausschalten und beobachten
- die hue Bridge ablernen und beobachten

Ich wollte nicht das komplette Log hier posten, kann man das denn machen? Nicht, dass das den Rahmen sprengt...

Xel66
Beiträge: 9578
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 128 Mal
Danksagung erhalten: 623 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von Xel66 » 13.11.2019, 09:32

romeoalfa1975 hat geschrieben:
13.11.2019, 09:18
...seitdem ist der DC wieder so bei ca. 30% im Ruhezustand.
Die 30% ohne angelegte Programme nur durch angelernte Geräte kann nicht sein. Da stimmt was gewaltig nicht. Die CCU hat massive Kommunikationsprobleme. Ich würde vermuten, wegen eines externen Störers, der auf der gleichen Frequenz ein dauerhaftes Störsignal sendet. Übrigens, LTE-Stationen kommen dort auch infrage. Und das Log kann bei den Lücken in der Aufzeichnung des DutyCycle nicht vollständig sein. Als Ursache käme hier nur eine massive Auslastung der CCU infrage. Hier würde mir ein amoklaufendes Script einfallen, denn ein solches blockiert die ReGa. Da es aber keine Programme gibt, kann das auch nicht sein.

Gruß Xel66
-------------------------------------------------------------------------------------------
343 Kanäle in 118 Geräten und 264 CUxD-Kanäle in 33 CUxD-Geräten:
282 Programme, 246 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.55.10.20210213 + Testsystem: CCU2 2.53.27
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

romeoalfa1975
Beiträge: 133
Registriert: 04.04.2019, 18:26
Hat sich bedankt: 14 Mal
Danksagung erhalten: 9 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von romeoalfa1975 » 13.11.2019, 09:37

Kann man denn irgendwo ablesen, ob die CCU solche Probleme hat?
Wenn ich testweise per Webui etwas schalte, klappt das einwandfrei.
Auch Konfigurationsänderungen an Aktoren usw. werden anstandslos übermittelt und die RSSI-Werte in der Geräteübersicht sind auch grün.
Mal sehen, was ich noch alles abschalten kann, um eine Veränderung zu sehen.

Da würde ja fast nur noch die LTE-Station bleiben, da sich ansonsten seit Monaten an den Standorten meiner Geräte nichts geändert hat...

Ach ja, Skripte hatte ich vorher nur welche für die Sonnenstandsberechnung und das Kalender-Skript. Aber die sind beide aktuell noch nicht wieder drauf.

Xel66
Beiträge: 9578
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 128 Mal
Danksagung erhalten: 623 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von Xel66 » 13.11.2019, 09:45

romeoalfa1975 hat geschrieben:
13.11.2019, 09:37
Da würde ja fast nur noch die LTE-Station bleiben...
Nein, nicht unbedingt. Kann auch ein babbling idiot sein. Irgendein Sensor/Aktor mit fast leeren Batterien, der sich wegen der Unterspannung nicht mehr "erwartungsgemäß" verhält. Das können diverse Sensoren auch anderer Hersteller sein, die den gleichen Frequenzbereich nutzen (z.B. Wetterstationen, Fernbedienungen von Garagentoren uswusf.). So einfach ist es nicht. RX und TX-Vorgäge der CCU könnte man mit dem Homematic-Manager von hobbyquaker auf der Registerkarte "Ereignisse" beobachten. Fremdgeräte siehst Du aber nicht. Das sind dann nur decodierte Meldungen der CCU und der angelernten Geräte. Störungen sieht man nicht. Zumindest gäbe das einen Hinweis darauf, was die CCU selbst auf der Funkstrecke so veranstaltet.

Gruß Xel66
-------------------------------------------------------------------------------------------
343 Kanäle in 118 Geräten und 264 CUxD-Kanäle in 33 CUxD-Geräten:
282 Programme, 246 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.55.10.20210213 + Testsystem: CCU2 2.53.27
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Daimler
Beiträge: 8030
Registriert: 17.11.2012, 10:47
Wohnort: Köln
Hat sich bedankt: 14 Mal
Danksagung erhalten: 179 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von Daimler » 13.11.2019, 11:14

Hi,
Xel66 hat geschrieben:
13.11.2019, 09:32
Die 30% ohne angelegte Programme nur durch angelernte Geräte kann nicht sein.
Nun, eine gewisse Anzahl an falsch konfigurierten Messaktoren, BMs und Konsorten schaffen die 30% aber leicht.
Gruß Günter

3 * pivccx mit 3.57.4 in Produktiv, pivccx mit 3.57.4 Testsystem mit HM-, HMIP- und HMIP-Wired Testgeräten, 3 * HPCx Studio 4.1,
6 * L-Gateway, 3 * RS-L-Gateway, 4 * HAP, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .

Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

Xel66
Beiträge: 9578
Registriert: 08.05.2013, 23:33
System: Alternative CCU (auf Basis OCCU)
Wohnort: Nordwürttemberg
Hat sich bedankt: 128 Mal
Danksagung erhalten: 623 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von Xel66 » 13.11.2019, 23:08

Daimler hat geschrieben:
13.11.2019, 11:14
Nun, eine gewisse Anzahl an falsch konfigurierten Messaktoren, BMs ...
Die Aktoren mit Messfunktion hat er haut ersten Post nicht angelernt. Und für BMW muss schon einiger Trubel im Haus sein.

Gruß Xel66
-------------------------------------------------------------------------------------------
343 Kanäle in 118 Geräten und 264 CUxD-Kanäle in 33 CUxD-Geräten:
282 Programme, 246 Systemvariablen und 144 Direktverknüpfungen,
RaspberryMatic Version 3.55.10.20210213 + Testsystem: CCU2 2.53.27
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

romeoalfa1975
Beiträge: 133
Registriert: 04.04.2019, 18:26
Hat sich bedankt: 14 Mal
Danksagung erhalten: 9 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von romeoalfa1975 » 14.11.2019, 05:41

Genau, diese sendeintensiven Steckdosen (HmIP-PSM - haben laut eq-3 tatsächlich einen Firmwarefehler!) habe ich erst mal nicht angelernt.

Dafür hat jedoch jeder Lichtschalter (HmIP-BSM) auch eine Messfunktion (14 Stück). Diese habe ich jedoch durch:

- Zyklische Statusmeldung = AUS
- Mindestsendeabstand = 24 Std
- Leistungsmessung = UNBENUTZT

auf ein Minimum an zusätzlichem Senden eingestellt.

Generell ist bei jedem Gerät die zyklische Statusmeldung schon mal präventiv beim Anlernen abgeschaltet worden (außer bei einem Temperatur- und drei Lichtsensoren, diese senden ca. alle 4-6 Minuten, aber das muss ja sein, um gut auf die Dämmerung und die Sonneneinstrahlung zu reagieren). Die Bewegungsmelder (5 Stück HmIP-SMI) haben 1 Minute als Sendeabstand und werden aber nur relativ selten angesprochen, da im Treppenhaus und Keller)

Aktuell liegt der Ruhezustand nach einer weiteren Nacht immer noch bei ca. 27-30%, laut Systemprotokoll.

Einen Ausreißer in der Nacht gab es jedoch wieder: Zwischen ziemlich genau 2:50 und 3:50 Uhr ging der DC rapide bis ca. 65% hoch und danach genau so schnell wieder runter. Also wieder genau dann, wo alles schlief (nur die CCU3 hat Party gemacht :shock: ).

Was empfehlt Ihr für eine Einstellung für die Logdateien? Ich habe sie aktuell auf: Homematic-Funk: ALLES, Logikschicht: NUR FEHLER eingestellt. Gestern habe ich die CCU gegen 14:00 Uhr neu gestartet: Die Logdatei unterteilt sich in drei Abschnitte: *** messages.0 *** hört komischerweise gestern Abend bei ca. 21:10 Uhr auf und beginnt dann neu mit *** Messages *** bei exakt 4:00 Uhr heute morgen. Der dritte Teil *** hmserver.log *** dokumentiert durchgehend.

Also alles zwischen 21:10 Uhr und 4:00 Uhr fehlt.
Vielleicht habe ich die Log-Einstellungen ja falsch gewählt und die Kapazität des Logfiles gesprengt!?

Vielleicht hat jemand noch einen Tipp, was man noch mal probieren könnte, ich wäre Euch sehr dankbar. :|

Daimler
Beiträge: 8030
Registriert: 17.11.2012, 10:47
Wohnort: Köln
Hat sich bedankt: 14 Mal
Danksagung erhalten: 179 Mal

Re: hoher Duty Cycle durch Fehler Hue Bridge ?

Beitrag von Daimler » 14.11.2019, 08:16

Hi,
Xel66 hat geschrieben:
13.11.2019, 23:08
Die Aktoren mit Messfunktion hat er haut ersten Post nicht angelernt.
romeoalfa1975 hat geschrieben:
14.11.2019, 05:41
Dafür hat jedoch jeder Lichtschalter (HmIP-BSM) auch eine Messfunktion (14 Stück).
:wink:
Aber egal - es kann sich halt summieren.

Nur mal so am Rande:
Ich hatte bis vor 2 Wochen eine CCU mit FW 3.45.7 - DC durchgehend < 20 %.
Nun habe ich aus speziellen Gründen das System auf 3 CCUs mit FW 3.42.22 erweitert und seitdem in der Summe einen DC zwischen 40 und 50 % - bei ansonsten gleichem Fuhrpark.
Habe i. M. aber keine Zeit, der Sache auf den Grund zu gehen.

romeoalfa1975 hat geschrieben:
14.11.2019, 05:41
Was empfehlt Ihr für eine Einstellung für die Logdateien?
Wenn du einen externen Log-Server hast / in Betrieb nehmen kannst, würde ich zur Fehlersuche Alles auf Alles setzen.
Denn das
romeoalfa1975 hat geschrieben:
14.11.2019, 05:41
hört komischerweise gestern Abend bei ca. 21:10 Uhr auf und beginnt dann neu mit *** Messages *** bei exakt 4:00 Uhr heute morgen.
und das
Xel66 hat geschrieben:
13.11.2019, 09:05
Du loggst den DutyCycle im Minutentakt aber zwischen 22:20 Uhr und 23:06 Uhr gibt es eine riesige Lücke.
Ist ja auch nicht normal.
Gruß Günter

3 * pivccx mit 3.57.4 in Produktiv, pivccx mit 3.57.4 Testsystem mit HM-, HMIP- und HMIP-Wired Testgeräten, 3 * HPCx Studio 4.1,
6 * L-Gateway, 3 * RS-L-Gateway, 4 * HAP, FHZ200x, vereinzelt noch FS2x-Komponenten.
HM: Zur Zeit knapp 300 Komponenten mit ??? Kanälen .

Ich übernehme für alle von mir gegebenen Hinweise, Tipps und Links keine Haftung! Das Befolgen meiner Tipps ist nur für Fachkundige gedacht und erfolgt auf eigene Gefahr!

Antworten

Zurück zu „RaspberryMatic“