HMCCU 5.0 im SVN verfügbar

[Otto123]

Mein Problem ist, dass ich im DOIF den set Befehl nicht benutzen kann, wie in der Kommandozeile:

Das liegt am Syntax im DOIF
Lösung steht hier in der commandref https://fhem.de/commandref_DE.html#DOIF_Angaben_im_Ausfuehrungsteil

[pc1246]

Moin Otto
Und Danke! Bin derzeit beruflich stark eingebunden, da bleibt nur das Wochenende.
Zweimal runde Klammern, das war mir nicht mehr gegenwaertig!
Gruss Christoph

P.S.: Zu dem anderen Problem gibt es keinen Kommentar?

Edith: Zumindest habe ich jetzt mal eine Erklaerung der Parameter gefunden:

Code Auswählen Erweitern

Der String zum Setzen der LED-Settings (HmIP-BSL) besteht immer aus nachfolgenden (DPs) des Aktorkanals (durch "," getrennt)
L=(LEVEL),DV=(DURATION_VALUE),DU=(DURATION_UNIT),RTV=(RAMP_TIME_VALUE),RTU=(RAMP_TIME_UNIT),C=(COLOR)
Und zwar hier: https://homematic-forum.de/forum/viewtopic.php?t=57290#p568111

[loescher]

Hallo zap,

Ich habe eine CCU in einem entfernten Netzwerk (VPN), was normalerweise sehr gut funktioniert.
Wenn allerdings die Bandbreite extrem schlecht ist, und ich dann zufällig FHEM neu starte, dann bleibt mir der FHEM Start hier stundenlang komplett hängen:

Code Auswählen Erweitern

HMCCU [d_ccu_Z] Reading device config from CCU. This may take a couple of seconds ...
Kann ich irgendwie einen Timeout dafür aktivieren bzw. könnte das auch im Hintergrund laufen, damit zumindest das restliche FHEM weiter startet?

LG,
Stephan.

Hier noch die DEF, aber nicht wundern, dass es "inactive" ist. Das war meine einzige Möglichkeit FHEM trotzdem zu starten.

Code Auswählen Erweitern

define d_ccu_Z HMCCU 192.x.x.x
attr d_ccu_Z ccudef-substitute LOWBAT,LOW_BAT!(0|false):ok,(1|true):low;;UNREACH!(0|false):alive,(1|true):dead
attr d_ccu_Z ccuflags procrpc,reconnect
attr d_ccu_Z rpcinterfaces HmIP-RF
attr d_ccu_Z rpcserver on
attr d_ccu_Z stateFormat rpcstate/state
#   CCUNum     2
#   Clients    :HMCCUDEV:HMCCUCHN:HMCCURPCPROC:
#   DEF        192.x.x.x
#   FUUID      60197ddf-f33f-a2be-630c-3fcad4b33840e321
#   NAME       d_ccu_Z
#   NOTIFYDEV  global
#   NR         368
#   NTFY_ORDER 50-d_ccu_Z
#   RPCState   inactive
#   STATE      inactive/OK
#   TYPE       HMCCU
#   ccuip      192.x.x.x
#   ccustate   active
#   ccutype    CCU2/3
#   config     5.0
#   eventCount 2
#   host       192.x.x.x
#   prot       http
#   version    5.0 222930908
#   READINGS:
#     2024-09-13 18:09:57   VERSION         2.53.34
#     2024-09-13 18:09:57   count_channels  168
#     2024-09-13 18:09:57   count_devices   10
#     2024-09-13 18:09:57   count_groups    0
#     2024-09-13 18:09:57   count_interfaces 4
#     2024-09-13 18:09:57   count_programs  0
#     2024-09-30 16:45:53   rpcstate        inactive
#     2024-09-30 16:46:48   state           OK
#   hmccu:
#     defaults   0
#     evtime     0
#     evtimeout  0
#     postInit   0
#     rpccount   0
#     rpcports  
#     updatetime 0
#     adr:
#     ccu:
#       delay      180
#       delayed    1
#       sync       1
#       timeout    1
#     dev:
#     ifports:
#     interfaces:
#
setstate d_ccu_Z inactive/OK
setstate d_ccu_Z 2024-09-13 18:09:57 VERSION 2.53.34
setstate d_ccu_Z 2024-09-13 18:09:57 count_channels 168
setstate d_ccu_Z 2024-09-13 18:09:57 count_devices 10
setstate d_ccu_Z 2024-09-13 18:09:57 count_groups 0
setstate d_ccu_Z 2024-09-13 18:09:57 count_interfaces 4
setstate d_ccu_Z 2024-09-13 18:09:57 count_programs 0
setstate d_ccu_Z 2024-09-30 16:45:53 rpcstate inactive
setstate d_ccu_Z 2024-09-30 16:46:48 state OK



[Rewe2000]

Hallo Stefan,

es hört sich für mich fast so an, wie ein ähnliches Problem welches ich vor einiger Zeit hatte.
Gibt es bei dir nur die einzige Meldung im LOG oder noch weitere zu RPC-Servern und HMCCU?

https://forum.fhem.de/index.php?topic=98287.msg916435#msg916435
https://forum.fhem.de/index.php?topic=127098.msg1217131#msg1217131

Versuch doch mal bei den RPC-Servern und bei der HMCCU das Attribut "ccuflags" zusätzlich noch auf "noInitialUpdate" zu setzen.
Startet dann Fhem ohne Probleme, musst du entscheiden, ob du mit den verzögerten Infos nach einem Neustart leben kannst.

Bin mir aber nicht sicher, ob der Fehler bei dir nicht doch woanders liegt, aber einen Versuch wäre es Wert.
Eventuell hat ja ZAP auch noch eine andere Lösung für dein Problem.


Gruß Reinhard

[loescher]

Hallo Reinhard,

Danke für den Tipp!
Aber mit noInitialUpdate bleibt FHEM ebenfalls hängen, allerdings an anderer Stelle:

Code Auswählen Erweitern

HMCCURPCPROC [d_rpc010024HmIP_RF] Initialized version 5.0 222930908 for interface HmIP-RF with I/O device d_ccu_ZDas Problem ist halt, dass meine VPN Verbindung über Mobilfunk geht und wenn das Datenvolumen erschöpft ist, läuft es mit 64 kB/s weiter.
Das reicht für den Normalbetrieb, aber wenn ich dann FHEM zufällig neu starten muss, dann überträgt das HMCCU so viele Daten, dass es "ewig" dauert.
Wäre an sich egal, wenn das restliche FHEM normal weiterarbeiten/starten würde.
Jetzt geht die Verbindung wieder mit 150,0 Mbit/s. Aber beim nächsten Mal kann ich ggf. das noInitialUpdate nochmal versuchen.

LG,
Stephan.