Seite 16 von 16
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 05.10.2021, 20:20
von jp112sdl
joerg_rw hat geschrieben: ↑05.10.2021, 17:03
Was mag wohl degegen gesprochen haben dass das sendende device seinen RX nach dem Senden irgendwas 2 oder 5s statt 0.25s anlaesst um die quittung zu empfangen?
Das Peering mit mehreren Geräten.
Wenn eine einzelne Direktverknüpfung 10 Aktoren ansteuert, wird die Wartereit u.U. nervig und die Haptik unschön.
Aber gut, ich denke, eine Grundsatzdiskussion über "warum hat man nicht... das hätte man auch... usw" bringt ohnehin nichts, da das Protokoll ist wie es ist. Und daran wird sich auch nichts mehr ändern.
joerg_rw hat geschrieben: ↑05.10.2021, 17:03
haben ihren Empfaenger doch "staendig" (evtl mit 20:1 dutycycle) in Betrieb. Wandthermostat z.B explizit sobald man Fensterkontakte anlernt
Nein, Fensterkontakte senden mit Burst, um das Thermostat beliebig zu wecken.
Ein Heizkörperthermostat, das ein Wandthermostat verknüpft hat, wacht in einem unregelmäßigen, aber definierten Zeitintervall kurz auf, um die Werte zu empfangen.
joerg_rw hat geschrieben: ↑05.10.2021, 17:03
Ich wuenschte eQ-3 wuerde sich so spezifisch aeussern
Die Infos sind von eQ-3. Zugegeben, man muss "proaktiv" danach suchen.
Aber spätestens wenn man sich mit der Geräteentwicklung beschäftigt, kommt man da nicht drumherum.
https://www.homematic-inside.de/media/d ... everhalten
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 05.10.2021, 21:41
von joerg_rw
jp112sdl hat geschrieben: ↑05.10.2021, 20:20
joerg_rw hat geschrieben: ↑05.10.2021, 17:03
haben ihren Empfaenger doch "staendig" (
evtl mit 20:1 dutycycle) in Betrieb. Wandthermostat z.B explizit sobald man Fensterkontakte anlernt
Nein, Fensterkontakte senden mit Burst, um das Thermostat beliebig zu wecken.
Ich glaube wir meinen das gleiche
: Empfaenger arbeitet alle X (sagen wir: max 2) Sekunden fuer ein paar Sekundenbruchteile um zu bemerken wenn z.B. ein Fensterkontakt - oder KeyMatic Handsender - sich schon sekundenlang nen Wolf sendet. Auch hier nennt man das Verhaeltnis von Off- zu On-zeit "duty cycle"
Wandthermostat -> Ventilsteuerung macht glaub ich so alle 3 Minuten oder so, ist
fast das selbe Prinzip in Ultra-Zeitlupe,
nur sendet hier der Wandthermostat nicht 3 Minuten lang dauernd im "Burst" sondern die beiden Geraete synchronisieren sich
@Moderator: Vermutlich waere es sinnvoll den ganzen FLGW Subthread aus diesem hier rauszuschneiden und in einen neuen eigenen Thread zu werfen?
[edit]
DER WAHNSINN, wie hast du das gefunden? Ich hab vor gefuehlt nem Jahrzehnt frustriert aufgehoert zu suchen. TAUSEND DANK!
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 05.10.2021, 21:45
von jp112sdl
joerg_rw hat geschrieben: ↑05.10.2021, 21:41
Wandthermostat -> Ventilsteuerung macht glaub ich so alle 3 Minuten oder so, ist das selbe Prinzip in Ultra-Zeitlupe
Das Zeitraster ist abhängig vom Message-Counter. Der Zeitslot variiert. Aber das wird jetzt arg OT
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 07.10.2021, 16:38
von joerg_rw
jp112sdl hat geschrieben: ↑05.10.2021, 14:04
joerg_rw hat geschrieben: ↑05.10.2021, 13:34
packetloss zwischen CCU und FLGW in Groessenordnung von mindestens 1%, besser mehr, sicherstellen. Dann warten.
Ok, danke. Klingt überschaubar.
Mal schauen ob meine alte WANem Appliance noch läuft, um das zu simulieren.
Ich glaube das zeigt ganz gut wie das ganze anfaengt, nach
Code: Alles auswählen
Oct 7 11:21:22 ccu3-webui user.err rfd: LGWPortWrapper::keepAliveThreadFunction(): Did not receive reply on keepalive.
QEQ4711815 [zensiert]
ccu3-webui user.info rfd: LanConnection::receive(): sock 9: Remote host closed connection.
Oct 7 11:21:49 ccu3-webui user.err rfd: UnifiedLanCommController::connect(): Didn't receive switch protocol command. ... disconnecting [**latchup?**]
Oct 7 11:22:00 ccu3-webui user.err rfd: LGWPortWrapper::SendData(): Send error
schauen in abgehaengter Datei (redigiert also schaut teilweise verhackstueckt aus deswegen, nicht wundern!)
Ich frag mich jetzt ob ich packets mitschneiden kann auf der FLGW Seite um zu schauen ob evtl tatsaechlich das FLGW selber abschmiert - was immer noch nicht dazu fuehren duerfte dass sich der rfd aufhaengt, aber...
Gruss
jOERG
ps:
NORMAL, also wenn alles glatt laeuft da wo manchmal denn was schiefgehtl:
Code: Alles auswählen
root@ccu3-webui:~# while sleep 1; do echo $(date "+%S %H:%M" && netstat 2>/dev/null -ntpla | grep "192.168.111.21" | paste - - - - - -); done |sed 's/ *tcp *. *. */ >> /g'|uniq -c -s 3
56 00 16:47 >> 192.168.178.40:55844 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:45482 192.168.111.21:2001 ESTABLISHED 9169/rfd
42 00 16:48 >> 192.168.178.40:55844 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:45482 192.168.111.21:2001 ESTABLISHED 9169/rfd
1 46 16:48 >> 192.168.178.40:55844 192.168.111.21:2000 TIME_WAIT - >> 192.168.178.40:45482 192.168.111.21:2001 FIN_WAIT1 -
2 47 16:48 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:55844 192.168.111.21:2000 TIME_WAIT - >> 192.168.178.40:45482 192.168.111.21:2001 FIN_WAIT1 - >> 192.168.178.40:60600 192.168.111.21:2001 SYN_SENT 9169/rfd
1 49 16:48 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:55844 192.168.111.21:2000 TIME_WAIT - >> 192.168.178.40:45482 192.168.111.21:2001 TIME_WAIT - >> 192.168.178.40:60600 192.168.111.21:2001 SYN_SENT 9169/rfd
9 50 16:48 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:55844 192.168.111.21:2000 TIME_WAIT - >> 192.168.178.40:45482 192.168.111.21:2001 TIME_WAIT - >> 192.168.178.40:60600 192.168.111.21:2001 ESTABLISHED 9169/rfd
44 00 16:49 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:55844 192.168.111.21:2000 TIME_WAIT - >> 192.168.178.40:45482 192.168.111.21:2001 TIME_WAIT - >> 192.168.178.40:60600 192.168.111.21:2001 ESTABLISHED 9169/rfd
2 47 16:49 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:45482 192.168.111.21:2001 TIME_WAIT - >> 192.168.178.40:60600 192.168.111.21:2001 ESTABLISHED 9169/rfd
10 49 16:49 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:60600 192.168.111.21:2001 ESTABLISHED 9169/rfd
56 00 16:50 >> 192.168.178.40:42726 192.168.111.21:2000 ESTABLISHED 9169/rfd >> 192.168.178.40:60600 192.168.111.21:2001 ESTABLISHED 9169/rfd
- wireshark screenshot des selben Vorgangs
Code: Alles auswählen
Oct 8 16:48:43 ccu3-webui user.debug multimac: SubsystemBidcos::CheckDutyCycleEventThreshold( 2.0, 2.0 ) = 0
Oct 8 16:48:45 ccu3-webui user.err rfd: LGWPortWrapper::keepAliveThreadFunction(): Did not receive reply on keepalive.
Oct 8 16:48:45 ccu3-webui user.debug rfd: asyncReconnect
Oct 8 16:48:45 ccu3-webui user.debug rfd: asyncReconnect -> reconnect
Oct 8 16:48:45 ccu3-webui user.err rfd: LGWPortWrapper::ReadData(): Receive error
Oct 8 16:48:45 ccu3-webui user.debug rfd: asyncReconnect
Oct 8 16:48:45 ccu3-webui user.debug rfd: LGWPortWrapper::asyncReconnect(): Reconnect already in progress.
Oct 8 16:48:46 ccu3-webui user.debug rfd: LGWPortWrapper::reconnect(): Trying to reconnect.
Oct 8 16:48:46 ccu3-webui user.debug rfd: LGWPortWrapper::reconnect(): Perform connect.
Oct 8 16:48:46 ccu3-webui user.info rfd: Lan Device Information: Protocol-Version: 1 Product-ID: eQ3-HM-LGW Firmware-Version: 1.1.5 Serial Number: QEQ4711
Oct 8 16:48:46 ccu3-webui user.debug rfd: LGWPortWrapper::reconnect(): Initialize coprocessor.
Oct 8 16:48:46 ccu3-webui user.debug rfd: CCU2CommController::improvedInit() - Coprocessor is in application.
Oct 8 16:48:46 ccu3-webui user.info rfd: (QEQ4711) CCU2CommController::setCSMACAEnabled(): CSMA/CA disabled.
Oct 8 16:48:46 ccu3-webui user.debug rfd: (QEQ4711) Response status: Input wrong.
Oct 8 16:48:46 ccu3-webui user.debug rfd: (QEQ4711) Response status: OK, Data.
Oct 8 16:48:46 ccu3-webui user.debug rfd: CCU2BidcosRemoteInterface::republishAllDevices(): Re-added device with address 60(dec)
Oct 8 16:48:46 ccu3-webui user.debug rfd: (QEQ4711) Response status: OK, Data.
Oct 8 16:48:46 ccu3-webui user.debug rfd: CCU2BidcosRemoteInterface::republishAllDevices(): Re-added device with address 70(dec)
Oct 8 16:48:46 ccu3-webui user.debug rfd: (QEQ4711) Response status: OK, Data.
Oct 8 16:48:46 ccu3-webui user.debug rfd: CCU2BidcosRemoteInterface::republishAllDevices(): Re-added device with address 70.....(dec)
Oct 8 16:48:46 ccu3-webui user.debug rfd: LGWPortWrapper::reconnect(): Initializing keepalives.
Oct 8 16:48:46 ccu3-webui user.debug rfd: LGWPortWrapper::connect(): Reconnected.
Oct 8 16:48:46 ccu3-webui user.debug rfd: LGWPortWrapper::reconnect(): Reconnect finished.
Oct 8 16:48:50 ccu3-webui user.info rfd: Lan Device Information: Protocol-Version: 1 Product-ID: eQ3-HM-LGW Firmware-Version: 1.1.5 Serial Number: QEQ0977246
Oct 8 16:48:50 ccu3-webui user.debug rfd: Switching RF-LGW LED OFF
Oct 8 16:48:53 ccu3-webui user.debug multimac: C<: #193 TRX GetDutyCycle
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 07.10.2021, 17:11
von jp112sdl
joerg_rw hat geschrieben: ↑07.10.2021, 16:38
schauen ob evtl tatsaechlich das FLGW selber abschmiert
Glaub ich nicht, da ja ein RFD-Restart der Zentrale ausreicht.
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 07.10.2021, 17:47
von joerg_rw
jp112sdl hat geschrieben: ↑07.10.2021, 17:11
joerg_rw hat geschrieben: ↑07.10.2021, 16:38
schauen ob evtl tatsaechlich das FLGW selber abschmiert
Glaub ich nicht, da ja ein RFD-Restart der Zentrale ausreicht.
Ich meinte, ob evtl das FLGW tatsaechlich selber den "sock 9: Remote host closed connection" verursacht, durch internen reboot oder 5s Schlaf oder was auch immer, oder ob das ein Artefakt des Uebertragungswegs ist, z.B. von irgendwas in den FritzBoxen verursacht (die moegen z.B. angeblich nicht mehr als 2 packets/s oder sowas - flood protection).
Ein anderes Thema ist, dass sich anschliessend der rfd verhakt - vermutlich im "
err rfd: UnifiedLanCommController::connect(): Didn't receive switch protocol command. ... disconnecting" - und anschliessend alle volle Minute "
err rfd: LGWPortWrapper::SendData(): Send error wirft selbst wenn der ausloesende Fehler wieder verschwunden ist. Ich vermute dass genau zu dem Zeitpunkt die orphaned/stale connection (ohne process)
Code: Alles auswählen
root@ccu3-webui:~# netstat -ntupla | grep 111.
tcp 0 0 192.168.178.40:53172 192.168.111.21:2000 ESTABLISHED -
auftaucht und deshalb der rfd keine neue connection aufmachen kann
Re: RaspberryMatic 3.59.6.20210911 – Neue Version
Verfasst: 09.10.2021, 15:38
von jmaus
Da ich soeben eine neue RaspberryMatic Version (3.59.6.20211009) freigegeben habe geht es hier weiter:
viewtopic.php?f=65&t=69941