3.53.34.59 - Update nicht möglich

Debian/Ubuntu basierte CCU

Moderator: Co-Administratoren

Antworten
pmiller
Beiträge: 79
Registriert: 04.01.2020, 08:43
System: Alternative CCU (auf Basis OCCU)
Wohnort: Baden bei Wien
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

3.53.34.59 - Update nicht möglich

Beitrag von pmiller » 23.02.2021, 19:30

Hallo!

Leider können wir bei dieser Firmware Version nicht updaten - und zwar weder Geräte-Firmware noch debmatic selbst. Letzteres hab ich ja schon im Thread viewtopic.php?f=81&t=64757 erwähnt und lass ich jetzt mal hier bei Seite. Ist halt nur zur Erinnerung warum wir hier auf dieser Version ein Geräte-Update starten wollten.

Nun Problem selbst. Mein Mädl wollte ein HMiP-SMI updaten. (Welches Geräte ist nach Tests letztendlich egal - es passiert bei allen.)
Das funktioniert eine Zeitlang recht gut - aber nach ca. 18h scheint der Service HmIP-RF nicht mehr zu funktionieren. Dies bekommen wir sowohl über http://[mydebmatic}/tools/devconfig.cgi?cmd=service_messages&sid=@2Qx3pfIOn9@ zurückgemeldet.

Das grundlegende Problem ist: wir können zwar Daten auf der debmatic empfangen (Beispiel: Direktverknüpfung funktioniert und auf der debmatic GUI sehe ich dass ich geschalten habe - Asksin zeigt auch, dass der Datenverkehr nicht über einen HAP geht) aber wir könne keine Daten von der debmatic versenden.

debmatic-info liefert:

debmatic version: 3.53.34-59
Kernel modules: Available
Raw UART dev: Available
HMRF Hardware: RPI-RF-MOD
Connected via: HB-RF-USB@usb-0000:02:00.0-2.1 (/dev/raw-uart)
Board serial: 5A4993####
Radio MAC: 0xFFF1##
HMIP Hardware: RPI-RF-MOD
SGTIN: 3014F711A0001F5A4993####
Radio MAC: 0xBF####

hm_mode liefert:

HM_HOST='DEBMATIC'
HM_HOST_RAW_UART='raw-uart'
HM_HOST_GPIO_UART='/dev/raw-uart'
HM_HOST_UART_DEVICE_TYPE='HB-RF-USB@usb-0000:02:00.0-2.1'
HM_HOST_GPIO_RESET=''
HM_LED_GREEN=''
HM_LED_RED=''
HM_LED_YELLOW=''
HM_RTC=''
HM_MODE='NORMAL'
HM_HMRF_DEVNODE='/dev/mmd_bidcos'
HM_HMIP_DEVNODE='/dev/mmd_hmip'
HM_HMRF_DEV='RPI-RF-MOD'
HM_HMIP_DEV='RPI-RF-MOD'
HM_HMRF_SERIAL='5A4993F###'
HM_HMRF_VERSION='4.2.6'
HM_HMRF_ADDRESS='0xFFF###'
HM_HMIP_SGTIN='3014F711A0001F5A4993####'
HM_HMIP_SERIAL='5A4993####'
HM_HMIP_VERSION='4.2.6'
HM_HMIP_ADDRESS='0xBF8B4C'

Mittels systemctl kann ich folgendes finden:

UNIT LOAD ACTIVE SUB DESCRIPTION
● debmatic-ssdpd.service loaded failed failed debmatic ssdpd

Der Service lässt sich allerdings manuell starten und läuft dann auch.

Folgende services sind disabled:

console-getty.service disabled
debug-shell.service disabled
ifupdown-wait-online.service disabled
serial-getty@.service disabled
systemd-boot-check-no-failures.service disabled
systemd-networkd-wait-online.service disabled
systemd-networkd.service disabled
systemd-resolved.service disabled
systemd-time-wait-sync.service disabled
ssh.socket disabled
systemd-networkd.socket disabled
ctrl-alt-del.target disabled
exit.target disabled
halt.target disabled
kexec.target disabled
poweroff.target disabled
reboot.target disabled
remote-cryptsetup.target disabled
runlevel0.target disabled
runlevel6.target disabled
fstrim.timer disabled
rpi-rf-mod_systohc.timer disabled

Also probiert man mal debmatic-rfd zu stoppen und sich dann den Status anzusehen:

● debmatic-rfd.service - debmatic rfd
Loaded: loaded (/lib/systemd/system/debmatic-rfd.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Tue 2021-02-23 19:16:35 CET; 35s ago
Process: 768 ExecStart=/usr/share/debmatic/bin/start_rfd.sh (code=exited, status=0/SUCCESS)
Process: 77042 ExecStopPost=/bin/rm -f /var/run/rfd.pid (code=exited, status=0/SUCCESS)
Main PID: 778 (code=killed, signal=TERM)

Feb 22 15:39:45 debmatic rfd[778]: XmlRpcClient error calling event({[methodName:"event",params:{"hmm_BidCos-RF","QEQ0690485","DUTY_CYCLE",98}]}) on http://10.20.30.136:2000/RPC2:
Feb 22 15:39:45 debmatic rfd[778]: XmlRpc transport error
Feb 22 15:40:05 debmatic rfd[778]: XmlRpcClient error calling event({[methodName:"event",params:{"hmm_BidCos-RF","QEQ0690485","DUTY_CYCLE",99}]}) on http://10.20.30.136:2000/RPC2:
Feb 22 15:40:05 debmatic rfd[778]: XmlRpc transport error
Feb 22 15:40:25 debmatic rfd[778]: XmlRpcClient error calling event({[methodName:"event",params:{"hmm_BidCos-RF","CENTRAL","PONG","nr"}]}) on http://10.20.30.136:2000/RPC2:
Feb 22 15:40:25 debmatic rfd[778]: XmlRpc transport error
Feb 23 19:16:35 debmatic systemd[1]: Stopping debmatic rfd...
Feb 23 19:16:35 debmatic systemd[1]: debmatic-rfd.service: Main process exited, code=killed, status=15/TERM
Feb 23 19:16:35 debmatic systemd[1]: debmatic-rfd.service: Succeeded.
Feb 23 19:16:35 debmatic systemd[1]: Stopped debmatic rfd.

Das spannende: selbst wenn der Service gestoppt ist bekommen wir Meldungen an die debmatic rein. Offensichtlich haben wir hiermit nur den BiDCOS Teil gekillt :-) - also wieder gestartet.

------------------------

Wie auch immer: das Problem tritt erst auf, wenn mein Mädl versucht ein Geräte-Update einzuspielen. Reproduzierbar. Immer nach ca. 18h sobald man ein Geräte-Update startet.
Anderenfalls haben wir ein gutes, stabiles System.

Welche Logs können wir noch liefern? Wir lassen das System jetzt mal in diesem Zustand (auch wenn wir somit gerade ein Dumb-Home haben) aber vielleicht schaffen wir es ja, hier der Ursache auf den Grund zu gehen.

Liebe Grüße aus Baden bei Wien,
Peter

Benutzeravatar
eiGelbGeek
Beiträge: 979
Registriert: 24.07.2014, 17:46
Wohnort: Ruhrpottrandgebiet
Hat sich bedankt: 105 Mal
Danksagung erhalten: 19 Mal

Re: 3.53.34.59 - Update nicht möglich

Beitrag von eiGelbGeek » 24.02.2021, 03:14

Klingt irgendwie nach Duty Cycle Problem... wenn es nur beim Geräte Update passiert...

Falls du ne BackUp CCU hast, mach das Geräte Update dort und dann zurück an die Produktiv CCU. Ich mache sofern möglich HmIP Updates immer an einer anderen CCU, dann belaste ich mein Produktiv System nicht so sehr, auch wenn das ohne Probleme funktionieren sollte.
Nur weil es nicht geht, muss es nicht kaputt sein ^^

Apple for Work, Linux for Network, iOS for Mobility and still Windows for Solitaire

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: 3.53.34.59 - Update nicht möglich

Beitrag von deimos » 24.02.2021, 06:38

Hi,

debmatic-rfd ist die SystemD Unit für den rfd, welcher rein den BidCos Funk verarbeitet.

debmatic-ssdpd ist die Unit vom ssdpd, welcher die CCU per MDNS im lokalen Netzwerk bekannt macht, der ist für das Thema ziemlich irrelevant. Das der manchmal nicht sauber startet ist auch bereits gefixt.

Die Anzeige bei devconfig.cgi muss man differenziert betrachten, die sagt nicht aus, was aktuell ist, sondern gibt alles seit dem letzten Start aus. Und da der HMServer lange zum Starten braucht, steht er faktisch immer in der Liste, das war bereits bei der CCU2 so und ist es auch jetzt bei der (original) CCU3.

Wo du nach dem Problem suchen kannst, ist der HMServer, welcher u.A. für HmIP zuständig ist in der Unit debmatic-hmserver. Hier würde ich aber keinen Restart machen, weil du durch die Abhängigkeiten auch gleich die Rega neu startest, sondern lieber mal ins Log /var/log/hmserver.log schauen.

Und auf jeden Fall solltest du mal auf den Dutycycle schauen, wie es eiGelbGeek bereits vorgeschlagen hat. Grade bei dem Hintergrund der Menge an Geräten von euch.

Viele Grüße
Alex

pmiller
Beiträge: 79
Registriert: 04.01.2020, 08:43
System: Alternative CCU (auf Basis OCCU)
Wohnort: Baden bei Wien
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: 3.53.34.59 - Update nicht möglich

Beitrag von pmiller » 24.02.2021, 07:55

eiGelbGeek hat geschrieben:
24.02.2021, 03:14
Klingt irgendwie nach Duty Cycle Problem... wenn es nur beim Geräte Update passiert...

Falls du ne BackUp CCU hast, mach das Geräte Update dort und dann zurück an die Produktiv CCU. Ich mache sofern möglich HmIP Updates immer an einer anderen CCU, dann belaste ich mein Produktiv System nicht so sehr, auch wenn das ohne Probleme funktionieren sollte.
Grundsätzlich ein netter Ansatz - aber bei fast 400 HMiP Geräten ist dies nicht mehr wirklich praktikabel. Auch ist das dann kein Bug-Fix sondern ein Workaround. Natürlich kann ich auch über Forst- und Waldwege quer durch's Land Fahren - aber wenn ich 1000km zurücklegen will, dann ist die dafür eigentlich vorgesehene Autobahn wohl die sinnvollere Lösung.

Der Duty-Cycle ist bei uns natürlich auf Grund der Anzahl der Geräte entsprechend hoch - bei gleicher Anzahl und voriger Firmware (ich bilde mir ein es war 3.37) hat es zwar logischerweise gedauert (ich rede hier von Monaten für eine Handvoll Geräte), aber es hat wenigstens funktioniert und die restliche Systematik nicht lahmgelegt.
3701933b-f407-4c7e-816b-f1bdbc7778a3.jpg
DutyCycle_23022021
Wie man hier sehr gut sehen kann: er hat einen zeitlang gut funktioniert (Updates rausgeschossen und trotzdem lief alles einwandfrei) und gegen 9:00 fiel dann debmatic aus und hat nur mehr empfangen.

Liebe Grüße aus Baden bei Wien,
Peter

pmiller
Beiträge: 79
Registriert: 04.01.2020, 08:43
System: Alternative CCU (auf Basis OCCU)
Wohnort: Baden bei Wien
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: 3.53.34.59 - Update nicht möglich

Beitrag von pmiller » 24.02.2021, 08:04

Servus!

debmatic-rfd ist die SystemD Unit für den rfd, welcher rein den BidCos Funk verarbeitet.

Ja, das haben wir auch gemerkt und gelernt :-)

debmatic-ssdpd ist die Unit vom ssdpd, welcher die CCU per MDNS im lokalen Netzwerk bekannt macht, der ist für das Thema ziemlich irrelevant. Das der manchmal nicht sauber startet ist auch bereits gefixt.

Auch schon auf Github gefunden - wir sind ja brav und gelehrig...

Die Anzeige bei devconfig.cgi muss man differenziert betrachten, die sagt nicht aus, was aktuell ist, sondern gibt alles seit dem letzten Start aus. Und da der HMServer lange zum Starten braucht, steht er faktisch immer in der Liste, das war bereits bei der CCU2 so und ist es auch jetzt bei der (original) CCU3.

OK - noted.

Wo du nach dem Problem suchen kannst, ist der HMServer, welcher u.A. für HmIP zuständig ist in der Unit debmatic-hmserver. Hier würde ich aber keinen Restart machen, weil du durch die Abhängigkeiten auch gleich die Rega neu startest, sondern lieber mal ins Log /var/log/hmserver.log schauen.

Hier mal ein Logauszug:

Feb 24 06:55:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 06:55:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 06:55:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:00:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:00:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:00:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:05:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:05:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:05:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:10:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:10:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:10:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:13:08 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] AP 3014F711A0001F5A4993F135: OTAU RF Handler 8ea55c9b-fb0a-40e0-832a-c654dc5dab23 aborted for device(s) [3014F711A000091709AC0530]
Feb 24 07:13:23 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] AP 3014F711A0001F5A4993F135: OTAU Handler 23e7f003-3468-4011-b940-a56b840c2172 continues for device(s) [3014F711A000091709AC0530]
Feb 24 07:15:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:15:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:15:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:20:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:20:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:20:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:25:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:25:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:25:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:30:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:30:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:30:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:31:53 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] AP 3014F711A0001F5A4993F135: OTAU RF Handler 23e7f003-3468-4011-b940-a56b840c2172 aborted for device(s) [3014F711A000091709AC0530]
Feb 24 07:32:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] AP 3014F711A0001F5A4993F135: OTAU Handler b08c7b37-f358-46cb-afcf-9837630e4848 continues for device(s) [3014F711A000091709AC0530]
Feb 24 07:35:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:35:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:35:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:40:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:40:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:40:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:45:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:45:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:45:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:50:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:50:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:50:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 07:52:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] AP 3014F711A0001F5A4993F135: OTAU RF Handler b08c7b37-f358-46cb-afcf-9837630e4848 aborted for device(s) [3014F711A000091709AC0530]
Feb 24 07:52:53 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] AP 3014F711A0001F5A4993F135: OTAU Handler c2c76d56-065d-47fe-8aeb-56b38b7b755b continues for device(s) [3014F711A000091709AC0530]
Feb 24 07:55:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 07:55:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 07:55:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used
Feb 24 08:00:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: 1 Accesspoints in Queue
Feb 24 08:00:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Permanent-/Burstlistener Handler utilization: 1/50 used
Feb 24 08:00:38 de.eq3.cbcs.server.core.otau.DeviceBackgroundUpdateSubsystem INFO [vert.x-eventloop-thread-0] SYSTEM: Eventlistener Handler utilization: 0/50 used

Und auf jeden Fall solltest du mal auf den Dutycycle schauen, wie es eiGelbGeek bereits vorgeschlagen hat. Grade bei dem Hintergrund der Menge an Geräten von euch.

Das tun wir - und wie du in meiner Antwort an ihn sehen kannst ist er "für uns" normal.

Liebe Grüße aus Baden bei Wien
Peter

Benutzeravatar
deimos
Beiträge: 5383
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 949 Mal
Kontaktdaten:

Re: 3.53.34.59 - Update nicht möglich

Beitrag von deimos » 24.02.2021, 09:16

Hi,

naja, ein DC nahe 100% ist halt nicht wirklich normal und das es da zu Problemen kommt, verwundert mich jetzt nicht so stark. Dann hast du scheinbar 5 HAPs eingebunden, offiziell werden aktuell nur 2 unterstützt. Gut möglich, dass sich da intern dann irgendwas verhakt. Problem ist: Closed Source von eQ-3 und ich habe auch nicht ansatzweise genug Testgeräte hier um den Versuch zu starten, das nachzustellen.

Im Moment würde ich etwas pragmatisch vorschlagen: Warte noch etwas mit den Updates. Die Firmware 3.57.x steht vor der Tür und wenn man den Github Repo trauen kann, dann wird es da auch eine neue Firmware für das RPI-RF-MOD geben. Möglicherweise erledigen sich damit dann beide deine Probleme.

Viele Grüße
Alex

pmiller
Beiträge: 79
Registriert: 04.01.2020, 08:43
System: Alternative CCU (auf Basis OCCU)
Wohnort: Baden bei Wien
Hat sich bedankt: 6 Mal
Danksagung erhalten: 4 Mal

Re: 3.53.34.59 - Update nicht möglich

Beitrag von pmiller » 24.02.2021, 09:32

Naja -schade - rebooting.

Und nein, es sind nur 4 HAPs - übertreiben wollen wir es auch wieder nicht :P

Ja, dass die 3.57 in den Startlöchern scharrt hab ich schon gesehen - wir sind gespannt und werden es natürlich testen und reporten.

Und ja, Firmware-Updates rausschmeißen und rebooten hat es natürlich gebracht (Dumb-Home somit wieder Smart-Home).

Liebe Grüße aus Baden bei Wien
Peter

Benutzeravatar
eiGelbGeek
Beiträge: 979
Registriert: 24.07.2014, 17:46
Wohnort: Ruhrpottrandgebiet
Hat sich bedankt: 105 Mal
Danksagung erhalten: 19 Mal

Re: 3.53.34.59 - Update nicht möglich

Beitrag von eiGelbGeek » 01.03.2021, 02:31

Natürlich Offtopic... wo verbaut man 400 Geräte? :mrgreen:

Es müsste schon ein riesiger Palast sein, das ich auf 400 Geräte kommen würde und hätte ich so einen Palast, wäre KNX oder HmIP Wired mein Freund, weil Geld dann keine Rolle spielen würde :mrgreen:
Nur weil es nicht geht, muss es nicht kaputt sein ^^

Apple for Work, Linux for Network, iOS for Mobility and still Windows for Solitaire

Benutzeravatar
eiGelbGeek
Beiträge: 979
Registriert: 24.07.2014, 17:46
Wohnort: Ruhrpottrandgebiet
Hat sich bedankt: 105 Mal
Danksagung erhalten: 19 Mal

Re: 3.53.34.59 - Update nicht möglich

Beitrag von eiGelbGeek » 01.03.2021, 02:33

pmiller hat geschrieben:
24.02.2021, 07:55
Grundsätzlich ein netter Ansatz - aber bei fast 400 HMiP Geräten ist dies nicht mehr wirklich praktikabel. Auch ist das dann kein Bug-Fix sondern ein Workaround. Natürlich kann ich auch über Forst- und Waldwege quer durch's Land Fahren - aber wenn ich 1000km zurücklegen will, dann ist die dafür eigentlich vorgesehene Autobahn wohl die sinnvollere Lösung.
Naja an den Spezifikationen von EQ3 hälst du dich ja nicht, daher wirst du wahrscheinlich mit Workarounds leben müssen... :mrgreen:
Nur weil es nicht geht, muss es nicht kaputt sein ^^

Apple for Work, Linux for Network, iOS for Mobility and still Windows for Solitaire

Antworten

Zurück zu „debmatic“