HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Kabellose und kabelgebundene Sender und Empfänger der klassischen Homematic-Serie

Moderator: Co-Administratoren

Benutzeravatar
jmaus
Beiträge: 9929
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 468 Mal
Danksagung erhalten: 1921 Mal
Kontaktdaten:

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von jmaus » 16.02.2022, 17:43

Es bleibt dabei: sobald der Erste mir ein verwertbares multimacd debug log samt Zusatzinfos (wann ausgestiegen, mögliches analyzer log, etc.) liefert, reiche ich das an die eQ3 Entwickler direkt weiter und dann sehen wir wohin die Reise geht.

Und es bringt wirklich nichts (!) sich hier ellenlang darüber erneut und erneut darüber aufzuregen das man im 1st level support von eQ3 hängen bleibt und vermeintlich nicht ernst genommen wird und das vllt sogar am Ego kratzt. Da sollte man mal wirklich seine Erwartungshaltung etwas runterschrauben und zielorientiert bleiben. Nutzt daher die direkten Kanäle die wir Gottseidank haben und gut ist. Diese haben in der Vergangenheit bei vielen anderen Bugs auch hundertmal schneller geholfen einen Fix an closed source teilen der CCU Firmware zu erhalten als irgendwelche indirekte Kommunikationswege über Support-Webformulare oder Email Austausch mit den eQ3 Support-Mitarbeitern.
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Thomas.Weinreich
Beiträge: 67
Registriert: 06.10.2014, 07:18
System: CCU
Wohnort: Seevetal
Hat sich bedankt: 10 Mal
Danksagung erhalten: 4 Mal

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von Thomas.Weinreich » 16.02.2022, 21:53

jmaus hat geschrieben:
16.02.2022, 17:43
Und es bringt wirklich nichts (!) sich hier ellenlang darüber erneut und erneut darüber aufzuregen das man im 1st level support von eQ3 hängen bleibt und vermeintlich nicht ernst genommen wird und das vllt sogar am Ego kratzt. D
Hallo Jens,
da Du mich hier scheinbar indirekt ansprichst, mein Ego hat damit nun wirklich nichts zu tun. Ich habe nur versucht mit meiner Zeit zu helfen weil mich dieser sch.. Bug extrem nervt und ich definitiv an einer Lösung interessiert bin.

Nicht mehr und nicht weniger.

Ich habe für den 1.st Level sogar viel Verständnis, wenn alles an ihm vorbei geht und aus zig verschieden Richtungen alles direkt beim 2.nd Level landet ist das dann irgendwie auch nicht im Sinne des Erfinders. Daher wollte ich das in seine Richtung bringen.

Aber da ich hier im Forum noch nicht so lange bin wenn ihr bessere Wege habt das das OK. Diese Erfahrung habe ich nicht.

Es bleibt dabei ich wollte nur helfen und wenn ich was tun kann um das Ganze schneller voranzubringen bin ich dabei.

PS: Wenn Du was zu kritisieren hast kann Du mich auch persönlich anschreiben, mein Ego hät das aus.

Gruß
Thomas

Thomas.Weinreich
Beiträge: 67
Registriert: 06.10.2014, 07:18
System: CCU
Wohnort: Seevetal
Hat sich bedankt: 10 Mal
Danksagung erhalten: 4 Mal

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von Thomas.Weinreich » 16.02.2022, 21:58

Tarjan hat geschrieben:
16.02.2022, 16:37
Hi Thomas,

ich habe einen Syslog seit Reboot (5 Tage, 2:50 ) mitlaufen (alles loggen) und seit gestern auch den AskSin Analyzer XS - bisher ist das Problem immer so nach 7-9 Tagen aufgetreten. Ich hoffe, dass ich zeitnah noch Logs liefern kann.

VG Jens
Hallo Jens,
wenn Du die Zeit dafür noch investieren möchtest werde ich Deine Infos entsprechend an EQ-3 über mein Ticket weiterleitem oder ich gebe Dir die Ticketnummer dann kannst Du die Infos ohne mein Einblick direkt an weiterleiten.

Gruß
Thomas

Benutzeravatar
Tarjan
Beiträge: 41
Registriert: 14.09.2016, 16:46
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dortmund
Hat sich bedankt: 5 Mal
Danksagung erhalten: 3 Mal

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von Tarjan » 17.02.2022, 10:19

Ich hoffe, dass der Fehler nun alsbald auftritt und die Logs dann auch Aussagekraft haben...
Ich stelle sie gern zur Verfügung, Jens M. hat sich ja bereits angeboten.

VG Jens

Benutzeravatar
stan23
Beiträge: 2060
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 601 Mal
Danksagung erhalten: 342 Mal
Kontaktdaten:

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von stan23 » 20.02.2022, 16:54

stan23 hat geschrieben:
07.02.2022, 17:43
Da ich keine richtige Testumgebung habe, läuft jetzt mein produktives System mit Syslog-Server und HomeMatic Funk auf "alles loggen".
Die Logs vom multimac kommen an.

Von meinen 19 HM-Sec-SCo hängen 6 Stück am CCU2-LAN-Gateway, von den restlichen sind die Hälfte jetzt auf gesicherte Kommunikation umgestellt.
Heizungsgruppen kann ich trotzdem keine zum Test erstellen weil mein einziges HM-CC-RT-DN einen anderen Zweck hat.
Bei mir sind in der Produktiv-Umgebung seit ein paar Stunden 6 Stück meiner 19 SCo auf "Gerätekommunikation gestört".
Interessanterweise nur solche mit gesicherter Übertragung, aber nicht alle gesicherten.

Sowohl die gestörten als auch die nicht gestörten machen bei jeder Fensteränderung 3 Sendeversuche, von denen verzögert der zweite und dritte von der CCU beantwortet wird.

So ganz sicher bin ich mir nicht, ob das wirklich das gewünschte Problem ist, denn etwas ähnliches habe ich schon mal berichtet und das war laut Analyse ein andersartiges Problem.
Außerdem habe ich immer noch keine Heizungsgruppen.
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

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

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von Xel66 » 20.02.2022, 17:23

stan23 hat geschrieben:
20.02.2022, 16:54
Interessanterweise nur solche mit gesicherter Übertragung, aber nicht alle gesicherten.
Die noch nicht gestörten haben vermutlich noch nicht ihre zyklische Meldung abgesetzt. Ab da werden sie auch betroffen sein. Forcieren kannst Du das, indem Du mal kurz das Fenster öffnest. Am Ende bekommst Du dann die rote LED am SCo.
stan23 hat geschrieben:
20.02.2022, 16:54
So ganz sicher bin ich mir nicht, ob das wirklich das gewünschte Problem ist...
"Gewünscht" ist gut. Eher das Gegenteil. Ich denke aber mal, das ist es. Hast Du verwertbare Meldungen im multimacd-Log?

Gruß Xel66
-------------------------------------------------------------------------------------------
524 Kanäle in 146 Geräten und 267 CUxD-Kanäle in 34 CUxD-Geräten:
343 Programme, 334 Systemvariablen und 183 Direktverknüpfungen,
RaspberryMatic Version: 3.65.11.20221005 + Testsystem: CCU2 2.61.7
-------------------------------------------------------------------------------------------
Einsteigerthread, Programmlogik-Thread, WebUI-Handbuch

Benutzeravatar
stan23
Beiträge: 2060
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 601 Mal
Danksagung erhalten: 342 Mal
Kontaktdaten:

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von stan23 » 20.02.2022, 18:07

Xel66 hat geschrieben:
20.02.2022, 17:23
Ab da werden sie auch betroffen sein. Forcieren kannst Du das, indem Du mal kurz das Fenster öffnest. Am Ende bekommst Du dann die rote LED am SCo.
Das ist tatsächlich nicht so. Die gesicherten ohne Störung leuchten beim Öffnen des Fensters brav nach dem ersten Versuch grün.
Der Analyzer verrät dass er trotzdem 3 Sendeversuche unternommen hat, von dem der erste und dritte korrekt mit RESPONSE, AES-RESPONSE und RESPONSE beantwortet wurde.

Einen gestörten konnte ich durch Drücken der Config-Taste dazu bewegen, ein Telegramm ohne AES zu schicken, damit ging die Störungsmeldung erstmal weg. Weitere Öffnungen führen aber wieder zu einer roten LED. Wenn das Zeitfenster vorbei ist wird die CCU da sicherlich auch wieder "Gerätekommunikation gestört" melden.


Der gestörte aber betätigte Sensor ist 0x5BE6E0 = OEQ0706584. Die Seriennummer taucht im Log aber nicht auf, ich vermute der multimac gibt das Event gar nicht an den rfd weiter.
0x2D7DD5 ist die Zentrale.
0xC0, 0xC1, 0xC2 sind die Messagecounter 192, 193, 194.
Feb 20 17:51:05 homematic-raspi user.debug multimac: C> @1201555646: #174 LLMAC RX @25744ms -64dBm C0 A6 41 5B E6 E0 2D 7D D5 01 56 00
Feb 20 17:51:05 homematic-raspi user.debug multimac: Bidcos RX: #C0[BiDi|BC|Ren|WMup] 5BE6E0->2D7DD5 SwitchConditional: 01 56 00
Feb 20 17:51:05 homematic-raspi user.debug multimac: GetAckActionForIncomingTelegram() channel=1
Feb 20 17:51:05 homematic-raspi user.debug multimac: GetAckActionForIncomingTelegram() ackAction=AckAction_AesChallenge, wakeup=None
Feb 20 17:51:05 homematic-raspi user.debug multimac: BidcosMacController::SendAESChallenge()
Feb 20 17:51:05 homematic-raspi user.debug multimac: MacController::OnDownstreamFrame(#255 LLMAC TX @25851ms [10k,NoCCA] C0 A0 02 2D 7D D5 5B E6 E0 04 29 F8 0F BB 52 66 00)
Feb 20 17:51:05 homematic-raspi user.debug multimac: BidcosMacController::SendAESChallenge() - autoTxState=AutoTxState_AesChallenge, txState=TxState_WaitCoproResponseAesSolution
Feb 20 17:51:05 homematic-raspi user.debug multimac: C<: #63 LLMAC TX @25851ms [10k,NoCCA] C0 A0 02 2D 7D D5 5B E6 E0 04 29 F8 0F BB 52 66 00
Feb 20 17:51:05 homematic-raspi user.debug multimac: C< @1201555647: bin:FD 00 17 03 3F 06 64 FB 80 C0 A0 02 2D 7D D5 5B E6 E0 04 29 F8 0F BB 52 66 00 D8 0F
Feb 20 17:51:05 homematic-raspi user.debug multimac: AutoTx: #C0[BiDi|Ren] 2D7DD5->5BE6E0 Ack: 04 29 F8 0F BB 52 66 00
Feb 20 17:51:05 homematic-raspi user.debug multimac: C> @1201555776: #63 LLMAC Response ACK @25851: 64 FB
Feb 20 17:51:05 homematic-raspi user.debug multimac: _txState = TxState_WaitAesSolution
Feb 20 17:51:05 homematic-raspi user.debug multimac: No aes solution received. Repetition not possible because communication has been initiated by device.
Feb 20 17:51:05 homematic-raspi user.debug multimac: _txState = TxState_Idle
Feb 20 17:51:05 homematic-raspi user.debug multimac: _autoTxState = AutoTxState_Idle

Feb 20 17:51:06 homematic-raspi user.debug multimac: C> @1201556421: #175 LLMAC RX @26518ms -62dBm C1 A6 41 5B E6 E0 2D 7D D5 01 56 00
Feb 20 17:51:06 homematic-raspi user.debug multimac: Bidcos RX: #C1[BiDi|BC|Ren|WMup] 5BE6E0->2D7DD5 SwitchConditional: 01 56 00
Feb 20 17:51:06 homematic-raspi user.debug multimac: GetAckActionForIncomingTelegram() channel=1
Feb 20 17:51:06 homematic-raspi user.debug multimac: GetAckActionForIncomingTelegram() ackAction=AckAction_AesChallenge, wakeup=None
Feb 20 17:51:06 homematic-raspi user.debug multimac: BidcosMacController::SendAESChallenge()
Feb 20 17:51:06 homematic-raspi user.debug multimac: MacController::OnDownstreamFrame(#255 LLMAC TX @26625ms [10k,NoCCA] C1 A0 02 2D 7D D5 5B E6 E0 04 BF 20 F4 3C 9C BB 00)
Feb 20 17:51:06 homematic-raspi user.debug multimac: BidcosMacController::SendAESChallenge() - autoTxState=AutoTxState_AesChallenge, txState=TxState_WaitCoproResponseAesSolution
Feb 20 17:51:06 homematic-raspi user.debug multimac: AutoTx: #C1 [BiDi|Ren] 2D7DD5->5BE6E0 Ack: 04 BF 20 F4 3C 9C BB 00
Feb 20 17:51:06 homematic-raspi user.debug multimac: C<: #64 LLMAC TX @26625ms [10k,NoCCA] C1 A0 02 2D 7D D5 5B E6 E0 04 BF 20 F4 3C 9C BB 00
Feb 20 17:51:06 homematic-raspi user.debug multimac: C< @1201556422: bin:FD 00 17 03 40 06 68 01 80 C1 A0 02 2D 7D D5 5B E6 E0 04 BF 20 F4 3C 9C BB 00 CF D8
Feb 20 17:51:06 homematic-raspi user.debug multimac: C> @1201556549: #64 LLMAC Response ACK @26625: 68 01
Feb 20 17:51:06 homematic-raspi user.debug multimac: _txState = TxState_WaitAesSolution
Feb 20 17:51:06 homematic-raspi user.debug multimac: No aes solution received. Repetition not possible because communication has been initiated by device.
Feb 20 17:51:06 homematic-raspi user.debug multimac: _txState = TxState_Idle
Feb 20 17:51:06 homematic-raspi user.debug multimac: _autoTxState = AutoTxState_Idle

Feb 20 17:51:08 homematic-raspi user.debug multimac: C<: #65 TRX GetDutyCycle
Feb 20 17:51:08 homematic-raspi user.debug multimac: C< @1201558798: bin:FD 00 03 01 41 03 9E 18
Feb 20 17:51:08 homematic-raspi user.debug multimac: C> @1201558905: #65 TRX Response Ack 42
Feb 20 17:51:08 homematic-raspi user.debug multimac: SubsystemBidcos::CheckDutyCycleEventThreshold( 32.5, 33.0 ) = 0
Feb 20 17:51:15 homematic-raspi user.debug rfd: RX for MEQ0478118: @403400683 RSSI=-46dB 0x3A7C99 -> 0x000000 Generic [CCU2GW0001]: CNT=19,RPTEN=1,RPTED=0,BIDI=0,BURST=0,WAKEUP=0,WAKEMEUP=1,BCAST=1,TYPE=0x5A DATA = A0 CC 36
Feb 20 17:51:15 homematic-raspi user.debug rfd: Event: MEQ0478118:2.ACTUAL_TEMPERATURE=20.400000


Feb 20 17:51:15 homematic-raspi user.debug multimac: C> @1201565200: #176 LLMAC RX @ 2531ms -63dBm C2 A6 41 5B E6 E0 2D 7D D5 01 56 00
Feb 20 17:51:15 homematic-raspi user.debug rfd: Event: MEQ0478118:2.ACTUAL_HUMIDITY=54.000000
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 2 events
Feb 20 17:51:15 homematic-raspi user.debug multimac: Bidcos RX: #C2[BiDi|BC|Ren|WMup] 5BE6E0->2D7DD5 SwitchConditional: 01 56 00
Feb 20 17:51:15 homematic-raspi user.debug multimac: GetAckActionForIncomingTelegram() channel=1
Feb 20 17:51:15 homematic-raspi user.debug multimac: GetAckActionForIncomingTelegram() ackAction=AckAction_AesChallenge, wakeup=None
Feb 20 17:51:15 homematic-raspi user.debug multimac: BidcosMacController::SendAESChallenge()
Feb 20 17:51:15 homematic-raspi user.debug multimac: MacController::OnDownstreamFrame(#255 LLMAC TX @ 2638ms [10k,NoCCA] C2 A0 02 2D 7D D5 5B E6 E0 04 46 D2 B4 D0 F7 C0 00)
Feb 20 17:51:15 homematic-raspi user.debug multimac: BidcosMacController::SendAESChallenge() - autoTxState=AutoTxState_AesChallenge, txState=TxState_WaitCoproResponseAesSolution
Feb 20 17:51:15 homematic-raspi user.debug multimac: C<: #66 LLMAC TX @ 2638ms [10k,NoCCA] C2 A0 02 2D 7D D5 5B E6 E0 04 46 D2 B4 D0 F7 C0 00
Feb 20 17:51:15 homematic-raspi user.debug multimac: AutoTx: #C2[BiDi|Ren] 2D7DD5->5BE6E0 Ack: 04 46 D2 B4 D0 F7 C0 00
Feb 20 17:51:15 homematic-raspi user.debug multimac: C< @1201565201: bin:FD 00 17 03 42 06 0A 4E 80 C2 A0 02 2D 7D D5 5B E6 E0 04 46 D2 B4 D0 F7 C0 00 A3 B3
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 2 events
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Feb 20 17:51:15 homematic-raspi user.debug rfd: Event: MEQ0478118:2.SET_TEMPERATURE=20.000000
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 2 events
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send 1 events
Feb 20 17:51:15 homematic-raspi user.debug rfd: HSSXmlRpcEventDispatcher::Handle send completed
Feb 20 17:51:15 homematic-raspi user.debug multimac: C> @1201565331: #66 LLMAC Response ACK @2638: 0A 4E
Feb 20 17:51:15 homematic-raspi user.debug multimac: _txState = TxState_WaitAesSolution
Feb 20 17:51:15 homematic-raspi user.debug multimac: No aes solution received. Repetition not possible because communication has been initiated by device.
Feb 20 17:51:15 homematic-raspi user.debug multimac: _txState = TxState_Idle
Feb 20 17:51:15 homematic-raspi user.debug multimac: _autoTxState = AutoTxState_Idle
Feb 20 17:51:18 homematic-raspi user.debug multimac: C<: #67 TRX GetDutyCycle
Feb 20 17:51:18 homematic-raspi user.debug multimac: C< @1201568798: bin:FD 00 03 01 43 03 12 1B
Feb 20 17:51:18 homematic-raspi user.debug multimac: C> @1201568904: #67 TRX Response Ack 3D
Feb 20 17:51:18 homematic-raspi user.debug multimac: SubsystemBidcos::CheckDutyCycleEventThreshold( 33.0, 30.5 ) = 0
Auffällig ist "No aes solution received. Repetition not possible because communication has been initiated by device."
Analyzer 0xEBE6E0.png
Analyzer 0xEBE6E0.png (21.57 KiB) 672 mal betrachtet
Zuletzt geändert von stan23 am 20.02.2022, 21:02, insgesamt 1-mal geändert.
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

Benutzeravatar
stan23
Beiträge: 2060
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 601 Mal
Danksagung erhalten: 342 Mal
Kontaktdaten:

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von stan23 » 20.02.2022, 20:10

stan23 hat geschrieben:
20.02.2022, 18:07
Wenn das Zeitfenster vorbei ist wird die CCU da sicherlich auch wieder "Gerätekommunikation gestört" melden.
Und das ist auch so.

Ich lasse das mal über Nacht so weiter laufen, stört ja nicht weiter. Also mich zumindest nicht.

Das Log habe ich auf der Suche nach Auffälligkeiten oder Gemeinsamkeiten durchsucht, aber außer der genannten Fehlermeldung nichts spannendes gefunden.
Möglicherweise hilft es wenn man genau weiß, welche Werte da im Log ausgegeben werden.
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

Benutzeravatar
jmaus
Beiträge: 9929
Registriert: 17.02.2015, 14:45
System: Alternative CCU (auf Basis OCCU)
Wohnort: Dresden
Hat sich bedankt: 468 Mal
Danksagung erhalten: 1921 Mal
Kontaktdaten:

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von jmaus » 20.02.2022, 20:51

Dann sicher mal schön die ganzes debug logs inkl multimacd debug infos und schreib die zeiten mal auf die du da hattest als ein SCo ausgestiegen ist bzw angefangen hat rot zu zeigen. Und wenn du dann auch noch ein analyzer log mit entsprechend gekennzeichneten details dieses sco mitlieferst wo man dann sehen kann das dee counter durcheinander kommt wäre das ein traum und ich würde das morgen dann gleich mal weiterschicken richtung eq3
RaspberryMatic 3.75.7.20240601 @ ProxmoxVE – ~200 Hm-RF/HmIP-RF/HmIPW Geräte + ioBroker + HomeAssistant – GitHub / Sponsors / PayPal / ☕️

Benutzeravatar
stan23
Beiträge: 2060
Registriert: 13.12.2016, 21:14
System: Alternative CCU (auf Basis OCCU)
Wohnort: Altmühltal
Hat sich bedankt: 601 Mal
Danksagung erhalten: 342 Mal
Kontaktdaten:

Re: HM-Sensorsterben (SC und SCO) nach update auf FW 3.61.5

Beitrag von stan23 » 21.02.2022, 08:45

jmaus hat geschrieben:
20.02.2022, 20:51
sicher mal schön die ganzes debug logs inkl multimacd debug infos
Habe ich, zusammen mit etwas Erklärung.
Sind gepackt rund 35 MB.

Ich schicke dir eine PN um auszuhandeln wie ich das mit dir teile.
Viele Grüße
Marco

RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)

Antworten

Zurück zu „HomeMatic Aktoren und Sensoren (klassisch)“