Hoher Duty Cycle auf CCU3 bei FHEM-Anbindung

[stobor]

Ich habe keine Dummy-Programme angelegt - zumindest nicht bewusst. Wo sollte ich die in der CCU finden?
Ich habe auch noch richtige HomeMatic Fernbedienungen, auch mit denen habe ich keine Probleme, und auch keine Dummy-Programme in der CCU angelegt.

[stobor]

Ist meine Definition so eigentlich korrekt/vollständig - Beispiel eines Gerätes (Fensterkontakt) inkl. der CCU Initialisierung:

Code Auswählen Erweitern

# Homematic via CCU

define d_ccu HMCCU 192.168.179.11
setuuid d_ccu 67658243-f33f-2cfb-13c4-7e39c5fbb59dfb67
attr d_ccu room Homematic
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

define d_rpc179011HmIP_RF HMCCURPCPROC http://192.168.179.11 HmIP-RF
setuuid d_rpc179011HmIP_RF 67658243-f33f-2cfb-cb96-326106ac99baff20
attr d_rpc179011HmIP_RF alias CCU 179011 RPC HmIP-RF
attr d_rpc179011HmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc179011HmIP_RF room Homematic
attr d_rpc179011HmIP_RF stateFormat rpcstate/state
attr d_rpc179011HmIP_RF verbose 2

define d_rpc179011BidCos_RF HMCCURPCPROC http://192.168.179.11 BidCos-RF
setuuid d_rpc179011BidCos_RF 6765824c-f33f-2cfb-70d5-6ba11d197fdacbf6
attr d_rpc179011BidCos_RF alias CCU 179011 RPC BidCos-RF
attr d_rpc179011BidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc179011BidCos_RF room Homematic
attr d_rpc179011BidCos_RF stateFormat rpcstate/state
attr d_rpc179011BidCos_RF verbose 2


#define d_rpc179011CUxD HMCCURPCPROC http://192.168.179.11 CUxD
#setuuid d_rpc179011CUxD 6765824d-f33f-2cfb-6443-d76eb73a86c49063
#attr d_rpc179011CUxD alias CCU 179011 RPC CUxD
#attr d_rpc179011CUxD eventMap /rpcserver on:on/rpcserver off:off/
#attr d_rpc179011CUxD room Homematic
#attr d_rpc179011CUxD stateFormat rpcstate/state
#attr d_rpc179011CUxD verbose 2

define d_rpc179011VirtualDevices HMCCURPCPROC http://192.168.179.11 VirtualDevices
setuuid d_rpc179011VirtualDevices 6765824d-f33f-2cfb-8691-f78bd3bd0e52e514
attr d_rpc179011VirtualDevices alias CCU 179011 RPC VirtualDevices
attr d_rpc179011VirtualDevices eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc179011VirtualDevices room Homematic
attr d_rpc179011VirtualDevices stateFormat rpcstate/state
attr d_rpc179011VirtualDevices verbose 2

#--------------------------------------------------------------------------------------------------------------
# Homematic Devices

# Fensterkontakte ----------------------------------------------------------------------------------
define HM_SC_Schuppen_West HMCCUCHN 00155D89B48433:1
setuuid HM_SC_Schuppen_West 676697f1-f33f-2cfb-52c5-01c6ab47b8557c79
attr HM_SC_Schuppen_West devStateIcon closed:fts_window_1w@green open:fts_window_1w_open@red
attr HM_SC_Schuppen_West group Fensterkontakt
attr HM_SC_Schuppen_West room Aussen,Fensterkontakte,Homematic
Ich wundere mich gerade, dass d_ccu nirgends mehr verwendet wird, stattdessen aber HMCCUCHN verwendet wird, ohne es vorher näher zu definieren.
Wäre die CCU und der Beispiel-Fensterkontakt so vollständig in FHEM konfiguriert?


Ich habe jetzt übrigens einmal alle HM-Geräte aus der fhem.cfg entfernt.
Es gibt lediglich die Initialisierung zzgl. Einer Speicherung der HM-Zustände in einem Array (sofern Geräte Vorhanden sind):

Code Auswählen Erweitern

# Homematic via CCU

define d_ccu HMCCU 192.168.179.11
setuuid d_ccu 67658243-f33f-2cfb-13c4-7e39c5fbb59dfb67
attr d_ccu room Homematic
attr d_ccu rpcinterfaces BidCos-RF,HmIP-RF
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

define d_rpc179011HmIP_RF HMCCURPCPROC http://192.168.179.11 HmIP-RF
setuuid d_rpc179011HmIP_RF 67658243-f33f-2cfb-cb96-326106ac99baff20
attr d_rpc179011HmIP_RF alias CCU 179011 RPC HmIP-RF
attr d_rpc179011HmIP_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc179011HmIP_RF room Homematic
attr d_rpc179011HmIP_RF stateFormat rpcstate/state
attr d_rpc179011HmIP_RF verbose 2

define d_rpc179011BidCos_RF HMCCURPCPROC http://192.168.179.11 BidCos-RF
setuuid d_rpc179011BidCos_RF 6765824c-f33f-2cfb-70d5-6ba11d197fdacbf6
attr d_rpc179011BidCos_RF alias CCU 179011 RPC BidCos-RF
attr d_rpc179011BidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc179011BidCos_RF room Homematic
attr d_rpc179011BidCos_RF stateFormat rpcstate/state
attr d_rpc179011BidCos_RF verbose 2


#define d_rpc179011CUxD HMCCURPCPROC http://192.168.179.11 CUxD
#setuuid d_rpc179011CUxD 6765824d-f33f-2cfb-6443-d76eb73a86c49063
#attr d_rpc179011CUxD alias CCU 179011 RPC CUxD
#attr d_rpc179011CUxD eventMap /rpcserver on:on/rpcserver off:off/
#attr d_rpc179011CUxD room Homematic
#attr d_rpc179011CUxD stateFormat rpcstate/state
#attr d_rpc179011CUxD verbose 2

define d_rpc179011VirtualDevices HMCCURPCPROC http://192.168.179.11 VirtualDevices
setuuid d_rpc179011VirtualDevices 6765824d-f33f-2cfb-8691-f78bd3bd0e52e514
attr d_rpc179011VirtualDevices alias CCU 179011 RPC VirtualDevices
attr d_rpc179011VirtualDevices eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpc179011VirtualDevices room Homematic
attr d_rpc179011VirtualDevices stateFormat rpcstate/state
attr d_rpc179011VirtualDevices verbose 2


define deviceEventOff notify HM_.*:off {\
set_HM_DeviceStatus($NAME, "off");;\
}
setuuid deviceEventOff 67728d2a-f33f-2cfb-1a19-7f6f16822793018c

define deviceEventOnTimer notify HM_.*:on-for-timer.* {\
set_HM_DeviceStatus($NAME, "on-for-timer");;\
}
setuuid deviceEventOnTimer 67728d2a-f33f-2cfb-cdd6-a67ed5b335add28e

define deviceEventOn notify HM_.*:on {\
set_HM_DeviceStatus($NAME, "on");;\
}
setuuid deviceEventOn 67728d2a-f33f-2cfb-78ed-dae3368174f17c68
der zugehörige Teil aus der 99_myUtils.pm:

Code Auswählen Erweitern

our $semaChangeHMon = time();

...

sub set_HM_DeviceStatus{
my $sDevice = $_[0];
my $sStatus = $_[1];

my $semaHmDelta = time() - $semaChangeHMon;
# Log 1, "TimeDelta: $semaHmDelta";
if ($semaHmDelta < 0.3){
# Log 1, "zu schnelles Update";
} else {
$semaChangeHMon = time();
# Log 1, "HM data setzen";
$hHMDeviceStatus{$sDevice} = $sStatus;
# Log 1, " >> set HM $sDevice = $sStatus";
}
}

Der DC lag ohne FHEM Verbindung bei ca 6%. Nach dem Entfernen der HM-Geräte und dem FHEM-Neustart liegt er derzeit bei ca. 8%.

Der Event-Monitor zeigt seit ca. 30min alles Möglich, aber nichts, was zur CCU/Homematic gehören könnte.

[frank]

hallo stobor,

ich habe den eindruck, das du den "duty cycle" nicht wirklich verstanden hast.

bei meldung "100% DC" am 868mhz-funkmodul der ccu, hat dieses modul in der letzten stunde insgesamt 36 sekunden gesendet (das sind 1% von 3600 sek).

wenn du die ccu rebootest, wird auch das funkmodul rebootet, also alle daten gelöscht.
logisch, dass dann der DC erstmal 0% wird.
ein "echter, gültiger" DC ist dann erst wieder nach 1 stunde verfügbar.

um den DC zu analysieren muss du als erstes mal einen plot wie tobi01001 erstellen.
und vor allem reboots vermeiden.

[stobor]

Danke für die Erklärung 
Wie erzeugt ihr denn das Diagramm? Ich habe keine Attribute gefunden, die den DC oder CS abbilden.

Ich habe gerade alle HM-Geräte aus FHEM entfernt und füge diese nun Schritt für Schritt wieder ein - immer mit langen Pausen dazwischen, um ggf so das Problemgerät zu finden.

[tobi01001]

Danke für die Erklärung 
Wie erzeugt ihr denn das Diagramm? Ich habe keine Attribute gefunden, die den DC oder CS abbilden.

Ich habe gerade alle HM-Geräte aus FHEM entfernt und füge diese nun Schritt für Schritt wieder ein - immer mit langen Pausen dazwischen, um ggf so das Problemgerät zu finden.

Das Device HMCCU (d_CCU3) schreibt zumindest bei mir den dutycycle in ein Reading mit dem selbstredenden Namen DutyCycle. Wenn man dieses in in FileLog-Device schreibt (sofern nicht bereits vorhanden), kann man ein SVG-Plot direkt daraus erstellen.

Code Auswählen Erweitern

help FileLog
Ich nutze allerdings DbLog....

[stobor]

Hmmm, bei mir sehe ich das Attribut nicht:
Du darfst diesen Dateianhang nicht ansehen.

Kann ich das irgendwie hinzufügen? Wie?

[passibe]

Ich glaube es sind die Readings mit iface_ducy_xxx gemeint.
Weiß jetzt nicht ob sich das von "CCU2" und das von "HMIP_CCU2" groß unterscheidet, vielleicht ja einfach mal beide loggen (oder auch alle drei?).

[stobor]

Ich nutze eine CCU3 und nutze HM und HmIP Geräte.
Was meinst Du mit CCU2 bzw. HMIP_CCU2?
Kein Wert der in FHEM angezeigten Attribute deckt sich mit dem in der CCU3 angezeigten DC Wert.

[tobi01001]

In deinem Screenshot steht CCU2 und nicht CCU3 in den iface.. Readings. diese hab ich bei mir gar nicht.., Was hast du denn am 15.01. um 22:03 gemacht um diese Readigns zu erzeugen?

Ich habe auch andere Readings zur Verfügung.
Mach mal bitte ein

Code Auswählen Erweitern

get d_ccu vars .* und schau ob der DutyCycle dann bereits als Reading dabei ist...
Falls nein:

Code Auswählen Erweitern

get d_ccu dutycycle (gibt es zumindest bei mir)
Ein

Code Auswählen Erweitern

attr d_ccu ccuGetVars 60:.* holt die Systemvariablem alle 60 Sekunden. Wenn das zu viele sind bzw. zu viele Events ausgelöst werden, kannst du das auf den dutycycle eingrenzen. Das Lesen selbser hat aber keinen Einfluss auf den duty cycle.

Edit:

Es gibt lediglich die Initialisierung zzgl. Einer Speicherung der HM-Zustände in einem Array (sofern Geräte Vorhanden sind):

Was macht das denn außer den Status speichern? Wird der ggf. bei bestimmten Ereignissen (fhem restart?) wiederhergestellt?
Und wo ist

Code Auswählen Erweitern

$hHMDeviceStatus definiert und wo wird es überall verwendet?

[stobor]

Ich bin auch etwas verwundert, dass bei mir nicht explizit CCU3 steht. Vorgegangen bin ich nach dieser Anleitung: https://wiki.fhem.de/wiki/HMCCU

get d_ccu vars .* liefert:

Code Auswählen Erweitern

Alarmmeldungen=1
Anwesenheit=true
DutyCycle=20.000000
DutyCycle-ccu2-LAN-Gateway=-1.000000
Servicemeldungen=0
Wobei der DC in der CCU3 einen anderen Wert anzeigt:
Du darfst diesen Dateianhang nicht ansehen.
Und die anderen Variablen sagen mir tatsächlich nichts.

In derCCU3 sehe ich übrigens unter "Status und Bedienung"/"Systemvariable" dieses:
Du darfst diesen Dateianhang nicht ansehen.
Komisch, dass die letzte Änderung von vor 3 Tagen ist.

In der CCU3 sind keine Programme hinterlegt:
Du darfst diesen Dateianhang nicht ansehen.

Wo kommen Alarmmeldungen, Anwesenheit und Servicemeldungen her?

Vor der CCU3 hatte ich einen Raspberry genutzt und dessen Konfiguration exportiert und auf die CCU importiert. Wäre das ein Problem?
Alle Geräte komplett neu anzulernen ist ja kein Vergnügen.


Bzgl. des HM Status - ich hatte einen Teil des Codes in der 99_myUtils vergessen:

Code Auswählen Erweitern

our $semaChangeHMon = time();
our %hHMDeviceStatus = ('DeviceName' => 'status');

...

sub set_HM_DeviceStatus{
    my $sDevice = $_[0];
    my $sStatus = $_[1];

    my $semaHmDelta = time() - $semaChangeHMon;
    # Log 1, "TimeDelta: $semaHmDelta";
    if ($semaHmDelta < 0.3){
        # Log 1, "zu schnelles Update";
    } else {
        $semaChangeHMon = time();
        # Log 1, "HM data setzen";
        $hHMDeviceStatus{$sDevice} = $sStatus;
        # Log 1, " >> set HM $sDevice = $sStatus";
    }
}

sub get_HM_DeviceStatus{
    #liefert den Status zurück : on / off / on-for-timer / unknown
    my $sDevice = $_[0];
    my $sReturn = $hHMDeviceStatus{$sDevice};
     #Log 1, "  >> get_HM_DeviceStatus: $sDevice - $sReturn";
    if (defined($sReturn)) {
        return ("$sReturn");       
    } else {
        my $sRet = ReadingsVal("$sDevice",'state','unknown');
        return ("$sRet");
    }
}

...

Ich habe das Problem, dass ich von HM Geräten nicht richtig erfassen konnte, ob ein Gerät eingeschaltet (on) oder zeitlich befristet eingeschaltet (on-for-timer) ist. Da das Einschalten von Lampen ggf. abhängig von ihrem aktuellen Einschaltzustand sein soll, kann ich das über get_HM_DeviceStatus genauer erfahren.

[tobi01001]

ich sehe jetzt zu meiner Definition der ccu keine wesentlichen Unterschiede.
Lediglich die Variablen frage ich zyklisch ab - dazu passt auch meine Reading DutyCycle und dessen Wert.
Weiterhin habe ich 3 ccuflags definiert - die wirken sich aber nicht auf den DC aus.

Code Auswählen Erweitern

attr d_CCU3 ccuGetVars 60:.*
attr d_CCU3 ccuflags procrpc,nonBlocking,reconnect

Mit get d_ccu dutycycle wird bei mir das Reading iface_ducy_xxx aktualisert und enthält auch den richtigen DC.
Der Unterschied liegt glaube in der CCU SW saelbst. Ich verwende auf meiner ccu3 Raspberrymatic anstatt der von eq3. Mit Raspberrymatic wird eie Systemvariable DutyCycle erzeugt, die den Wert enthält.
Deine Konfiguration sieht für mich so aus, dass du die originale SW hast. Allerdings hast du auch eine netsprechende Systemvariable, was die Vermutung nahelegt, dass Raspberrymatic mal installiert war?

Unabhängig davon könnte für dich das ccuflag "logCommand - Write all set and get commands of all devices to log file with verbose level 3." in Kombination mit verbose 3 interessant sein. Ich vermute noch immer (wie Otto), dass da unverhältnismäßig oft geschrieben oder aktiv abgefrag wird.

[stobor]

Die CCU3 betreibe ich von Beginn an nur mit der Originalsoftware. Allerdings habe ich ein Backup einer Raspberrymatic eingespielt, um nicht ale Gerät neu anlernen zu müssne. Kann das vielleicht eine Erklärung sein?

Unabhängig davon könnte für dich das ccuflag "logCommand - Write all set and get commands of all devices to log file with verbose level 3." in Kombination mit verbose 3 interessant sein. Ich vermute noch immer (wie Otto), dass da unverhältnismäßig oft geschrieben oder aktiv abgefrag wird.

Wie muss ich vorgehen, um das protokollieren zu lassen?

[tobi01001]

Allerdings habe ich ein Backup einer Raspberrymatic eingespielt, um nicht ale Gerät neu anlernen zu müssne

Ja, sehe aber nicht, dass da ein Problem sein sollte.

Wie muss ich vorgehen, um das protokollieren zu lassen?

Code Auswählen Erweitern

attr d_ccu ccuflags logCommand
attr d_ccu verbose 3
Das Ergebins siehst du dann im Logfile. (habs nicht probiert).

[stobor]

Habe es gerade einmal konfiguriert:

Code Auswählen Erweitern

attr d_ccu ccuflags logCommand
attr d_ccu verbose 3
Da ich gerade schrittweise alle CCU/HM-Komponenten wieder in FHEM einfüge, würde ich jetzt einmal ein paar Steckdosen einfügen, um das Logging zu testen.

Wenn ich nun HM-Steckdosen schalte, taucht im FHEM-Log leider nichts auf. Entsteht ein separates File? Wo?

[stobor]

Ich haqbe inzwischen herausgefunden, dass der DutyCycle in der CCU3 als Systemvariable nicht automatisch aktualisiert wird. Das scheint es nur in der RaspberyyMatic zu geben. Ich habe nun ein kleines Script in die CCU eingefügt, welches dort die Systemvariable aktualisiert. Diese bekomme ich jetzt auch in FHEM aktualisiert. Der Hinweis mit

Code Auswählen Erweitern

get d_ccu vars .*
get d_ccu dutycycle
attr d_ccu ccuGetVars 60:.*
hat geholfen. Danke.

Ich füge ja noch immer nach und nach weitere Homematic-Geräte in die FHEM config. Derzeit liegt mein DC bei ca. 6%.