piVCCU Update 3.47.10 und 2.47.10
Moderator: Co-Administratoren
-
- Beiträge: 3974
- Registriert: 24.03.2011, 04:32
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 110 Mal
- Danksagung erhalten: 71 Mal
Re: piVCCU Update 3.47.10 und 2.47.10
Das Announcement für piVCCU enthielt diesen Hinweis bereits, s. viewtopic.php?f=69&t=51399&p=515066#p515066
Die Einblendung in der Homematic WebUI bezieht sich auf die Original CCU-SW und ist so erst mal nur für die Anwender der Original CCU, also nicht für piVCCU, relevant.
piVCCU verhält sich ja identisch zur Original CUU SW und macht damit genau das was die CCU-SW auch machen würde. So sind z.B. auch die Backups kompatibel. Deshalb mag ich dieses Konzept auch so. In den vorliegenden Falle frägt die SW - genau wie die Originale CCU - bei ELV/eQ3 nach, ob es was Neues gibt und zeigt das dann an.
Allerding ist piVCCU an der Schnittstelle zum Computer (Host) so modifiziert, daß sie in einem Container auch auf einem anderen Rechner als der eigentlichen CCU-HW laufen kann. Diese "glue logic" baut Alex @deimos dann an die originale CCU-SW an und das ist dann piVCCU.
Wenn jetzt die Abfrage nach einer neuen Version verändert würde, dann wäre das ja ein anderes Verhalten als bei der originalen CCU. Und das ist in dem Konzept piVCCU explizit nicht gewünscht.
Also müssen wir damit leben. Und können es auch. Wenn der Hinweis kommt, dann ins Forum schauen. Dort gibt es dann recht rasch einen Thread zur Original-CCU-SW und dann sieht man schnell, ob sich ein Update lohnt.
Falls ja, dann nach einem Thread von @deimos suchen, der die zugehörige piVCCU zum Gegenstand hat. Wer mutig ist, kann gleich aus dem Entwicklungs Repository updaten, ansonsten 2 Wochen warten, bis zum stable.
Die Einblendung in der Homematic WebUI bezieht sich auf die Original CCU-SW und ist so erst mal nur für die Anwender der Original CCU, also nicht für piVCCU, relevant.
piVCCU verhält sich ja identisch zur Original CUU SW und macht damit genau das was die CCU-SW auch machen würde. So sind z.B. auch die Backups kompatibel. Deshalb mag ich dieses Konzept auch so. In den vorliegenden Falle frägt die SW - genau wie die Originale CCU - bei ELV/eQ3 nach, ob es was Neues gibt und zeigt das dann an.
Allerding ist piVCCU an der Schnittstelle zum Computer (Host) so modifiziert, daß sie in einem Container auch auf einem anderen Rechner als der eigentlichen CCU-HW laufen kann. Diese "glue logic" baut Alex @deimos dann an die originale CCU-SW an und das ist dann piVCCU.
Wenn jetzt die Abfrage nach einer neuen Version verändert würde, dann wäre das ja ein anderes Verhalten als bei der originalen CCU. Und das ist in dem Konzept piVCCU explizit nicht gewünscht.
Also müssen wir damit leben. Und können es auch. Wenn der Hinweis kommt, dann ins Forum schauen. Dort gibt es dann recht rasch einen Thread zur Original-CCU-SW und dann sieht man schnell, ob sich ein Update lohnt.
Falls ja, dann nach einem Thread von @deimos suchen, der die zugehörige piVCCU zum Gegenstand hat. Wer mutig ist, kann gleich aus dem Entwicklungs Repository updaten, ansonsten 2 Wochen warten, bis zum stable.
- deimos
- Beiträge: 5396
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 957 Mal
- Kontaktdaten:
Re: piVCCU Update 3.47.10 und 2.47.10
Hi,
jetzt wollte ich grade noch was dazu schreiben, aber klassisch hat das schon vollumfänglich beschrieben.
Viele Grüße
Alex
jetzt wollte ich grade noch was dazu schreiben, aber klassisch hat das schon vollumfänglich beschrieben.
Viele Grüße
Alex
-
- Beiträge: 250
- Registriert: 08.08.2018, 20:13
- Hat sich bedankt: 7 Mal
- Danksagung erhalten: 21 Mal
Re: piVCCU Update 3.47.10 und 2.47.10
OK, danke Euch beiden für die Erklärung! Den Thread habe ich ja gefunden, aber die Ankündigung ließe sich ja auch so interpretieren, dass die Testphase vorzeitig vorbei wäre
Wie auch immer, war etwas irritiert, aber mit der Erklärung ist alles wieder gut!
Wie auch immer, war etwas irritiert, aber mit der Erklärung ist alles wieder gut!
-
- Beiträge: 235
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: piVCCU Update 3.47.10 und 2.47.10
btw... Besten Dank @Alex, die 3.47.10 läuft seit gestern bei mir .... alles im grünen Bereich
und bez. Updates vom piVCCU hier meine 2ct:
und bez. Updates vom piVCCU hier meine 2ct:
- ich nutze eigentlich immer 3 Befehle:
- "apt update" ... wenn da was von "Aktualisierung für 3 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen." steht ...
- dann eben "apt list --upgradable" ausführen, um zu sehen, was denn so "upgradable" ist. Da sieht man u.a. auch, ob im eigestellten "Branch" auch ein piVCCU-Update drin ist
- erst dann mache ich nach persönlicher Entscheidung ein "apt upgrade" ...
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1
-
- Beiträge: 235
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: piVCCU Update 3.47.10 ... DutyCycle über 70 % ???
Hi mal wieder,
gestern und heute hatte ich komischerweise nen DutyCycle von über 70% mit der v3.47.10 ...
ok, ich bin gerade intensiv am Testen mit scripts, Heizungssteuerung, CUxD, Alarmen, Emails etc.
aber auch wenn ich nach einem Reboot die Finger vom System lasse (und natürlich vorher meine Test-Programme deaktiviert) isses wieder passiert heute morgen.
btw, ich hab die scripts von alchy bez. Dutycycle aktiv... mit Debug. Könnten die evtl. mit der Standard-Anzeige/Bar in 3.37.10 Konflikte auslösen ?
schau ich mir die logs an, sehe ich da für mich komisches , "Copro timeout", danach war der DC für ca 1 Std. sehr hoch:
dann noch mal am gleichen Tag mit der gleichen Meldung bez. "Copro":
und heute morgen dann noch mal mit "Copro", hat sich jedoch nicht mehr beruhigt, sodass ich mittags den Raspi rebootet habe :
kann sich wer das erklären, bzw. kann ich noch irgendwas an Infos liefern ?
besten Dank.
PS: seit dem Reboot heute mittag hab ich nen für mich normalen DC von 8-12 % ... ich hab auch noch nicht weiter "getestet", d.h. die Finger vom Raspi gelassen ... bis jetzt
gestern und heute hatte ich komischerweise nen DutyCycle von über 70% mit der v3.47.10 ...
ok, ich bin gerade intensiv am Testen mit scripts, Heizungssteuerung, CUxD, Alarmen, Emails etc.
aber auch wenn ich nach einem Reboot die Finger vom System lasse (und natürlich vorher meine Test-Programme deaktiviert) isses wieder passiert heute morgen.
btw, ich hab die scripts von alchy bez. Dutycycle aktiv... mit Debug. Könnten die evtl. mit der Standard-Anzeige/Bar in 3.37.10 Konflikte auslösen ?
schau ich mir die logs an, sehe ich da für mich komisches , "Copro timeout", danach war der DC für ca 1 Std. sehr hoch:
Code: Alles auswählen
Jul 8 14:02:51 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Jul 8 14:11:52 HasiMatic user.debug script: [DutyCycle 9] by_Alchy
Jul 8 14:13:51 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Jul 8 14:21:52 HasiMatic user.debug script: [DutyCycle 9] by_Alchy
Jul 8 14:24:51 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Jul 8 14:27:57 HasiMatic user.err ^E: Copro timeout on ACK_AESChallenge send
Jul 8 14:31:52 HasiMatic user.debug script: [DutyCycle 66] by_Alchy
Jul 8 14:35:52 HasiMatic user.debug script: [DutyCycleIP 68] by_Alchy
Jul 8 14:41:52 HasiMatic user.debug script: [DutyCycle 91] by_Alchy
Jul 8 14:46:52 HasiMatic user.debug script: [DutyCycleIP 98] by_Alchy
Jul 8 14:51:52 HasiMatic user.debug script: [DutyCycle 97] by_Alchy
Jul 8 14:57:52 HasiMatic user.debug script: [DutyCycleIP 97] by_Alchy
Jul 8 15:01:52 HasiMatic user.debug script: [DutyCycle 97] by_Alchy
Jul 8 15:08:52 HasiMatic user.debug script: [DutyCycleIP 96] by_Alchy
Jul 8 15:11:52 HasiMatic user.debug script: [DutyCycle 96] by_Alchy
Jul 8 15:19:52 HasiMatic user.debug script: [DutyCycleIP 96] by_Alchy
Jul 8 15:21:52 HasiMatic user.debug script: [DutyCycle 97] by_Alchy
Jul 8 15:30:52 HasiMatic user.debug script: [DutyCycleIP 37] by_Alchy
Jul 8 15:31:52 HasiMatic user.debug script: [DutyCycle 37] by_Alchy
Jul 8 15:41:52 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Jul 8 15:41:52 HasiMatic user.debug script: [DutyCycle 8] by_Alchy
Jul 8 15:51:52 HasiMatic user.debug script: [DutyCycle 10] by_Alchy
Code: Alles auswählen
Jul 8 18:37:54 HasiMatic user.debug script: [DutyCycleIP 11] by_Alchy
Jul 8 18:41:54 HasiMatic user.debug script: [DutyCycle 11] by_Alchy
Jul 8 18:48:54 HasiMatic user.debug script: [DutyCycleIP 11] by_Alchy
Jul 8 18:51:54 HasiMatic user.debug script: [DutyCycle 11] by_Alchy
Jul 8 18:59:54 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Jul 8 19:01:54 HasiMatic user.debug script: [DutyCycle 17] by_Alchy
Jul 8 19:03:51 HasiMatic user.err ^E: Copro timeout on ACK_AESChallenge send
Jul 8 19:10:54 HasiMatic user.debug script: [DutyCycleIP 72] by_Alchy
Jul 8 19:11:54 HasiMatic user.debug script: [DutyCycle 70] by_Alchy
Jul 8 19:20:56 HasiMatic daemon.info cuxd[379]: save paramsets(/usr/local/addons/cuxd/cuxd.ps) size:651
Jul 8 19:21:54 HasiMatic user.debug script: [DutyCycleIP 71] by_Alchy
Jul 8 19:21:54 HasiMatic user.debug script: [DutyCycle 70] by_Alchy
Jul 8 19:31:54 HasiMatic user.debug script: [DutyCycle 70] by_Alchy
Jul 8 19:32:54 HasiMatic user.debug script: [DutyCycleIP 71] by_Alchy
Jul 8 19:41:54 HasiMatic user.debug script: [DutyCycle 70] by_Alchy
Jul 8 19:43:54 HasiMatic user.debug script: [DutyCycleIP 70] by_Alchy
Jul 8 19:45:00 HasiMatic user.info kernel: [175307.892013] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null)
Jul 8 19:51:54 HasiMatic user.debug script: [DutyCycle 70] by_Alchy
Jul 8 19:54:54 HasiMatic user.debug script: [DutyCycleIP 70] by_Alchy
Jul 8 20:01:55 HasiMatic user.debug script: [DutyCycle 21] by_Alchy
Jul 8 20:05:54 HasiMatic user.debug script: [DutyCycleIP 22] by_Alchy
Jul 8 20:11:55 HasiMatic user.debug script: [DutyCycle 8] by_Alchy
Jul 8 20:16:55 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Code: Alles auswählen
Jul 9 07:42:01 HasiMatic user.debug script: [DutyCycle 11] by_Alchy
Jul 9 07:50:01 HasiMatic user.debug script: [DutyCycleIP 11] by_Alchy
Jul 9 07:52:01 HasiMatic user.debug script: [DutyCycle 11] by_Alchy
Jul 9 08:01:01 HasiMatic user.debug script: [DutyCycleIP 10] by_Alchy
Jul 9 08:02:01 HasiMatic user.debug script: [DutyCycle 10] by_Alchy
Jul 9 08:07:41 HasiMatic user.err ^E: Copro timeout on ACK_AESChallenge send
Jul 9 08:12:01 HasiMatic user.debug script: [DutyCycleIP 65] by_Alchy
Jul 9 08:12:01 HasiMatic user.debug script: [DutyCycle 68] by_Alchy
Jul 9 08:22:01 HasiMatic user.debug script: [DutyCycle 73] by_Alchy
Jul 9 08:23:01 HasiMatic user.debug script: [DutyCycleIP 74] by_Alchy
Jul 9 08:32:02 HasiMatic user.debug script: [DutyCycle 73] by_Alchy
Jul 9 08:34:01 HasiMatic user.debug script: [DutyCycleIP 73] by_Alchy
Jul 9 08:42:02 HasiMatic user.debug script: [DutyCycle 74] by_Alchy
Jul 9 08:45:01 HasiMatic user.debug script: [DutyCycleIP 74] by_Alchy
Jul 9 08:52:02 HasiMatic user.debug script: [DutyCycle 73] by_Alchy
Jul 9 08:56:01 HasiMatic user.debug script: [DutyCycleIP 74] by_Alchy
Jul 9 09:02:02 HasiMatic user.debug script: [DutyCycle 58] by_Alchy
Jul 9 09:07:02 HasiMatic user.debug script: [DutyCycleIP 16] by_Alchy
Jul 9 09:12:02 HasiMatic user.debug script: [DutyCycle 13] by_Alchy
Jul 9 09:18:02 HasiMatic user.debug script: [DutyCycleIP 14] by_Alchy
Jul 9 09:22:02 HasiMatic user.debug script: [DutyCycle 13] by_Alchy
Jul 9 09:29:02 HasiMatic user.debug script: [DutyCycleIP 15] by_Alchy
Jul 9 09:32:02 HasiMatic user.debug script: [DutyCycle 13] by_Alchy
Jul 9 09:40:02 HasiMatic user.debug script: [DutyCycleIP 40] by_Alchy
Jul 9 09:42:02 HasiMatic user.debug script: [DutyCycle 61] by_Alchy
Jul 9 09:51:02 HasiMatic user.debug script: [DutyCycleIP 76] by_Alchy
Jul 9 09:52:02 HasiMatic user.debug script: [DutyCycle 74] by_Alchy
Jul 9 10:02:02 HasiMatic user.debug script: [DutyCycleIP 77] by_Alchy
Jul 9 10:02:02 HasiMatic user.debug script: [DutyCycle 75] by_Alchy
Jul 9 10:12:02 HasiMatic user.debug script: [DutyCycle 76] by_Alchy
Jul 9 10:13:02 HasiMatic user.debug script: [DutyCycleIP 77] by_Alchy
Jul 9 10:22:02 HasiMatic user.debug script: [DutyCycle 77] by_Alchy
Jul 9 10:24:02 HasiMatic user.debug script: [DutyCycleIP 77] by_Alchy
Jul 9 10:32:02 HasiMatic user.debug script: [DutyCycle 75] by_Alchy
Jul 9 10:35:02 HasiMatic user.debug script: [DutyCycleIP 75] by_Alchy
Jul 9 10:42:03 HasiMatic user.debug script: [DutyCycle 16] by_Alchy
Jul 9 10:46:02 HasiMatic user.debug script: [DutyCycleIP 16] by_Alchy
Jul 9 10:52:03 HasiMatic user.debug script: [DutyCycle 14] by_Alchy
Jul 9 10:57:03 HasiMatic user.debug script: [DutyCycleIP 15] by_Alchy
Jul 9 11:02:03 HasiMatic user.debug script: [DutyCycle 38] by_Alchy
Jul 9 11:08:03 HasiMatic user.debug script: [DutyCycleIP 75] by_Alchy
Jul 9 11:12:03 HasiMatic user.debug script: [DutyCycle 75] by_Alchy
Jul 9 11:16:08 HasiMatic auth.info sshd[25327]: Accepted password for root from 192.168.176.12 port 50741 ssh2
Jul 9 11:19:03 HasiMatic user.debug script: [DutyCycleIP 76] by_Alchy
Jul 9 11:22:03 HasiMatic user.debug script: [DutyCycle 74] by_Alchy
Jul 9 11:30:03 HasiMatic user.debug script: [DutyCycleIP 76] by_Alchy
Jul 9 11:32:03 HasiMatic user.debug script: [DutyCycle 75] by_Alchy
Jul 9 11:41:03 HasiMatic user.debug script: [DutyCycleIP 76] by_Alchy
Jul 9 11:42:03 HasiMatic user.debug script: [DutyCycle 75] by_Alchy
besten Dank.
PS: seit dem Reboot heute mittag hab ich nen für mich normalen DC von 8-12 % ... ich hab auch noch nicht weiter "getestet", d.h. die Finger vom Raspi gelassen ... bis jetzt
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1
- deimos
- Beiträge: 5396
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 957 Mal
- Kontaktdaten:
Re: piVCCU Update 3.47.10 und 2.47.10
Hi,
versuchst du zu dem Zeitpunkt ein (Batterie-)Gerät anzusprechen? So wie ich die Meldung verstanden habe, kommt die, wenn versucht wird ein Gerät mit Schlüssel anzusprechen und keine Antwort kommt. Wenn das dann noch ein Batteriegerät mit Burst ist, dann schnellt dir der DC natürlich gleich durch die Decke.
Interessant wäre noch, welches Funkmodul du hast, es gab im CCU Thread ja auch eine Meldung mit Kommunikationsstörungen, bei der unklar ist, ob es möglicherweise mit der neuen Firmware des RPI-RF-MOD zusammenhängt.
Viele Grüße
Alex
versuchst du zu dem Zeitpunkt ein (Batterie-)Gerät anzusprechen? So wie ich die Meldung verstanden habe, kommt die, wenn versucht wird ein Gerät mit Schlüssel anzusprechen und keine Antwort kommt. Wenn das dann noch ein Batteriegerät mit Burst ist, dann schnellt dir der DC natürlich gleich durch die Decke.
Interessant wäre noch, welches Funkmodul du hast, es gab im CCU Thread ja auch eine Meldung mit Kommunikationsstörungen, bei der unklar ist, ob es möglicherweise mit der neuen Firmware des RPI-RF-MOD zusammenhängt.
Viele Grüße
Alex
-
- Beiträge: 235
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: piVCCU Update 3.47.10 und 2.47.10
@Alex, vielen Dank für diene prompte Ruckmeldung
ich hab das klassiche Funkmodul, HM-MOD-RPI-PCB, nix RPI-RF-MOD.
und nö, ich versuche nicht bewußt, ein batterie-betriebenes Gerät anzusprechen ... z.B. war ich heute morgen gegen 08:07 Überhaupt nicht angemeldet am piVCCU
sorry für die Frage : aber was ist ein "Batteriegerät mit Burst" ?
"Burst" kenne ich eigentlich nur von den Heizkörperventilen HMIP-eTRV, von denen ich etliche habe ... den Burst nutze ich da eigentlich nicht, ist nicht aktiv...
btw. "Firmware" ... war im 3.47.10 evtl ein Firmware-Update für das HM-MOD-RPI-PCB mit dabei ? wenn ja, wie kann ich checken, ob das gelaufen ist ? ...in "messages" sehe ich da nix
hier noch zur Info :
ich hab das klassiche Funkmodul, HM-MOD-RPI-PCB, nix RPI-RF-MOD.
und nö, ich versuche nicht bewußt, ein batterie-betriebenes Gerät anzusprechen ... z.B. war ich heute morgen gegen 08:07 Überhaupt nicht angemeldet am piVCCU
sorry für die Frage : aber was ist ein "Batteriegerät mit Burst" ?
"Burst" kenne ich eigentlich nur von den Heizkörperventilen HMIP-eTRV, von denen ich etliche habe ... den Burst nutze ich da eigentlich nicht, ist nicht aktiv...
btw. "Firmware" ... war im 3.47.10 evtl ein Firmware-Update für das HM-MOD-RPI-PCB mit dabei ? wenn ja, wie kann ich checken, ob das gelaufen ist ? ...in "messages" sehe ich da nix
hier noch zur Info :
Code: Alles auswählen
~# pivccu-info
piVCCU version: 3.47.10-27
Kernel modules: Available
Raw UART dev: Available
Rasp.Pi3 UART: Assigned to GPIO pins
HMRF Hardware: HM-MOD-RPI-PCB
HMIP Hardware: HM-MOD-RPI-PCB
Board serial: OEQ2298319
Radio MAC: 0x6510f2
SGTIN: 3014F711A061A7D709AC79CF
State: RUNNING
PID: 866
IP: 192.168.176.21
CPU use: 1083.71 seconds
Memory use: 218.00 MiB
KMem use: 6.41 MiB
Link: vethpivccu
TX bytes: 34.60 MiB
RX bytes: 17.49 MiB
Total bytes: 52.09 MiB
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1
- deimos
- Beiträge: 5396
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 957 Mal
- Kontaktdaten:
Re: piVCCU Update 3.47.10 und 2.47.10
Hi,
Batteriebetriebene Aktoren lauschen nicht dauerhaft auf Signale, sondern nur ca. alle 300ms. Das dient dazu, dass der Stromverbeauch gering gehalten wird um die Batterien zu schonen. Damit die dennoch erreicht werden können, wird ein Burst vor dem eigentlichen Telegramm gesendet, was vereinfacht ausgedrückt ein Dauerton über 300ms ist. Sobald ein Batterieaktor den hört, wacht er auf und horcht dann eine gewisse Zeit auf das folgende Telegramm. Und eben dieser Burst kostet extrem viel Sendezeit.
Ob du an der CCU angeneldet bist, ist dafür absolut irrelevant, dass kann auch einfach irgendein Progeamm sein, welches ein solches Gerät triggert oder den Status abfragt.
Firmware Updates für das alte Funkmodul gab es schon länger nicht mehr, in piVCCU3 ist seit Anfang an die immer nocht aktuelle 2.8.6 drin.
Viele Grüße
Alex
Batteriebetriebene Aktoren lauschen nicht dauerhaft auf Signale, sondern nur ca. alle 300ms. Das dient dazu, dass der Stromverbeauch gering gehalten wird um die Batterien zu schonen. Damit die dennoch erreicht werden können, wird ein Burst vor dem eigentlichen Telegramm gesendet, was vereinfacht ausgedrückt ein Dauerton über 300ms ist. Sobald ein Batterieaktor den hört, wacht er auf und horcht dann eine gewisse Zeit auf das folgende Telegramm. Und eben dieser Burst kostet extrem viel Sendezeit.
Ob du an der CCU angeneldet bist, ist dafür absolut irrelevant, dass kann auch einfach irgendein Progeamm sein, welches ein solches Gerät triggert oder den Status abfragt.
Firmware Updates für das alte Funkmodul gab es schon länger nicht mehr, in piVCCU3 ist seit Anfang an die immer nocht aktuelle 2.8.6 drin.
Viele Grüße
Alex
-
- Beiträge: 235
- Registriert: 02.10.2018, 19:24
- System: Alternative CCU (auf Basis OCCU)
- Hat sich bedankt: 59 Mal
- Danksagung erhalten: 11 Mal
Re: piVCCU Update 3.47.10 und 2.47.10
besten Dank für deine Erklärung bez. "Burst"
verstehe ich zwar noch nicht ganz ... lese ich mir morgen noch bestimmt mindestens 2x durch
danke auch für den Hinweis auf "Programme" ... hatte ich schon die meisten deaktiviert. Werd ich mir morgen auch noch mal genauer ansehen, sind grad nicht mehr so viele
ok, dann kann es an der Firmware fürs alte Funkmodul wohl nicht liegen, wenn das keine Updates erfolgt sind.
btw. im syslog grad gesehen , ist heute Nachmittag grad wieder aufgetreten ohne irgendwelche Fehler:
hat sich wohl auch nach ner Stunde beruhigt ... versteht ich zwar net, aber egal, der Rest funktioniert ja.
irgendwie sagt mir mein Bauchgefühl schon, dass mit der 3.47.10 und der eingebauten DC-Anzeige was nicht stimmt ... ich lese auch ähnliches in anderen Themen, auch von Jens ... is mir zwar suspekt, kann ich jedoch mit meinem HM-basic-how2 nicht nachvollziehen
verstehe ich zwar noch nicht ganz ... lese ich mir morgen noch bestimmt mindestens 2x durch
danke auch für den Hinweis auf "Programme" ... hatte ich schon die meisten deaktiviert. Werd ich mir morgen auch noch mal genauer ansehen, sind grad nicht mehr so viele
ok, dann kann es an der Firmware fürs alte Funkmodul wohl nicht liegen, wenn das keine Updates erfolgt sind.
btw. im syslog grad gesehen , ist heute Nachmittag grad wieder aufgetreten ohne irgendwelche Fehler:
Code: Alles auswählen
Jul 9 15:13:26 HasiMatic user.debug script: [DutyCycle 8] by_Alchy
Jul 9 15:20:26 HasiMatic user.debug script: [DutyCycleIP 10] by_Alchy
Jul 9 15:23:26 HasiMatic user.debug script: [DutyCycle 23] by_Alchy
Jul 9 15:31:26 HasiMatic user.debug script: [DutyCycleIP 73] by_Alchy
Jul 9 15:33:26 HasiMatic user.debug script: [DutyCycle 72] by_Alchy
Jul 9 15:42:26 HasiMatic user.debug script: [DutyCycleIP 73] by_Alchy
Jul 9 15:43:26 HasiMatic user.debug script: [DutyCycle 72] by_Alchy
Jul 9 15:53:26 HasiMatic user.debug script: [DutyCycleIP 73] by_Alchy
Jul 9 15:53:26 HasiMatic user.debug script: [DutyCycle 72] by_Alchy
Jul 9 16:03:26 HasiMatic user.debug script: [DutyCycle 72] by_Alchy
Jul 9 16:04:26 HasiMatic user.debug script: [DutyCycleIP 72] by_Alchy
Jul 9 16:13:26 HasiMatic user.debug script: [DutyCycle 69] by_Alchy
Jul 9 16:15:26 HasiMatic user.debug script: [DutyCycleIP 70] by_Alchy
Jul 9 16:23:26 HasiMatic user.debug script: [DutyCycle 30] by_Alchy
Jul 9 16:26:26 HasiMatic user.debug script: [DutyCycleIP 31] by_Alchy
Jul 9 16:33:26 HasiMatic user.debug script: [DutyCycle 7] by_Alchy
Jul 9 16:37:26 HasiMatic user.debug script: [DutyCycleIP 8] by_Alchy
Jul 9 16:43:26 HasiMatic user.debug script: [DutyCycle 8] by_Alchy
Jul 9 16:48:26 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
Jul 9 16:53:27 HasiMatic user.debug script: [DutyCycle 9] by_Alchy
Jul 9 16:59:27 HasiMatic user.debug script: [DutyCycleIP 9] by_Alchy
irgendwie sagt mir mein Bauchgefühl schon, dass mit der 3.47.10 und der eingebauten DC-Anzeige was nicht stimmt ... ich lese auch ähnliches in anderen Themen, auch von Jens ... is mir zwar suspekt, kann ich jedoch mit meinem HM-basic-how2 nicht nachvollziehen
Proxmox-MiniServer (J4125, 12GB RAM, nur SSDs, Proxmox 7.4-3), RM v3.69.7.20230506, abgesetztes, altes Funkmodul HM-MOD-RPI-PCB am RB-RF-ETH, ca. 5 HM- und 107 HMIP-Geräte, Addons : CUxD v2.10.1, eMail v1.7.6, XML-API v1.22, JB-HB v6.0, ProgrammeDrucken v2.6, CCU-Historian v3.3.1
- deimos
- Beiträge: 5396
- Registriert: 20.06.2017, 10:38
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Leimersheim
- Hat sich bedankt: 121 Mal
- Danksagung erhalten: 957 Mal
- Kontaktdaten:
Re: piVCCU Update 3.47.10 und 2.47.10
Hi,
soweit ich weiß, ist das Script von alchy korrekt und wenn das so einen hoher DC meldet, dann darf man davon ausgehen, dass das Funkmodul der Meinung ist, dass der DC so hoch ist. Mir wäre aktuell auch kein Fall bekannt, dass der DC vom Funkmodul massiv falsch berechnet wird. Aufgrund deiner Logs würde ich extrem stark vermuten, dass du da einfach ein Script hast, welches den DC massiv hochtreibt.
Viele Grüße
Alex
soweit ich weiß, ist das Script von alchy korrekt und wenn das so einen hoher DC meldet, dann darf man davon ausgehen, dass das Funkmodul der Meinung ist, dass der DC so hoch ist. Mir wäre aktuell auch kein Fall bekannt, dass der DC vom Funkmodul massiv falsch berechnet wird. Aufgrund deiner Logs würde ich extrem stark vermuten, dass du da einfach ein Script hast, welches den DC massiv hochtreibt.
Viele Grüße
Alex