Neues Modul HMCCU für Homematic CCU

[rubinho]

Kurze Noobfrage,

ich versuche gerade meine Heizungsgruppe in Fhem anzulegen, Diese besteht aus einem HM_CC_RT_DN und HM-TC-IT-WM-W-EU.
Die Namen sind wie folgt in der CCU angelegt worden ... TC_IT_WM_W_EU_Office, CC_RT_DN_Office. Der Gruppenname (INT0000001) hat in der CCU die Bezeichnung Office und das virtuelle Gerät heißt Group_HLK_Office1.
Wenn ich jetzt versuche die Gruppe mit folgenden Befehl händisch anzulegen.

Code Auswählen Erweitern

define HM_Group_HLK_Office1 HMCCUDEV INT0000001 group=TC_IT_WM_W_EU_Office,CC_RT_DN_Office
Bekomme ich die Meldung

Code Auswählen Erweitern

Invalid device or channel TC_IT_WM_W_EU_Office

Drehe ich die Geräte, steht dann, dass CC_RT_DN_Office in der Fehlermeldung.
Ich hab auch schon statt INT0000001 die Bezeichnung Group_HLK_Office1 genutzt. Das Ergebnis war das gleiche.

Jetzt zur Frage...
Was hab ich falsch gemacht.

[zap]

Versuch erst mal, für eines der Geräte ein normales Device anzulegen, zB

define testtherm HMCCUDEV TC_IT....

Wenn das die gleiche Meldung kommt, mach mit dem IO Dev mal ein "get devicelist" und versuche es nochmal

[zap]

set <name> defaults  würde die attribute aus HMCCUConf.pm in alle devices schreiben, habe ich das richtig verstanden?
ich habe eine HMCCUConf_personal.pm, wie kann ich die anbinden?

set name defaults setzt nur die Attribute für "name". FHEM unterstützt aber Wildcards für set Befehle. Damit kann man dann mehrere Devices in einem Rutsch mit Defaults versorgen.

HMCCU unterstützt benutzerdefinierte Template Files. Du erstellst zunächst mit set exportdefaults eine solche Textdatei, passt sie nach Deinen Vorstellungen an und importierst sie wieder mit set importdefaults.

Damit die Datei beim Start von FHEM geladen wird, setzt Du das Attribut ccudefaults auf den Namen der Datei. Beim Setzen der Attribute mit set defaults schaut HMCCU zunächst Deine selbst definierten Attribute durch. Nur wenn da nichts passt, sucht es in HMCCuConf.pm.

Damit du deine Arbeit nicht nochmal machen musst, kannst Du versuchen, die HMCCUConf.pm durch Deine Datei zu ersetzen und danach mit set exportdefaults eine Textdatei zu erzeugen. Dann kopierst Du die Orginal .pm wieder an ihren Platz und kannst die erstellte Textdatei mit attr ccudefaults einbinden

[rubinho]

Die Einzelgeräte sind ja schon angelegt. (Via Autocreate)
Ich hab sie aber nochmal gelöscht und auch erfolgreich händisch angelegt.
Daran liegts also nicht.

Ach Verdammt, ich hab den Namen von Fhem genommen und Fhem mag doch keine Bindestriche.
Da die CCU-Beschriftung Bindestriche hat und mir es nicht aufgefallen ist, kannte er das Gerät natürlich nicht.
Fhem-Name TC_IT_WM_W_EU_Office
CCU-Name TC-IT-WM-W-EU_Office

Es geht jetzt 

Sry, Jungs

[chris1284]

Damit du deine Arbeit nicht nochmal machen musst, kannst Du versuchen, die HMCCUConf.pm durch Deine Datei zu ersetzen und danach mit set exportdefaults eine Textdatei zu erzeugen.

das geht, man muss nur fhem neustarten damit die manipulierte HMCCUConf.pm eingelesen wird.
man sollte in der datei allerdings keine userreadings mit perlfunktionen haben...

2017.01.14 08:58:45 1: reload: Error:Modul 88_HMCCU deactivated:
syntax error at FHEM/HMCCUConf.pm line 114, near ""color { ReadingsVal(""az_rgbw_01""
Compilation failed in require at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.

2017.01.14 08:58:45 0: syntax error at FHEM/HMCCUConf.pm line 114, near ""color { ReadingsVal(""az_rgbw_01""
Compilation failed in require at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.
BEGIN failed--compilation aborted at ./FHEM/88_HMCCU.pm line 91, <DATA> line 1.

Undefined subroutine &main::HMCCU_FindIODevice called at ./FHEM/88_HMCCUDEV.pm line 134, <$fh> line 67.

das habe ich entfertn, danach lief der export mit meinen werten sauber. das textfile habe ich dann per attr ccudefaults /opt/fhem/HMCCU_templ/myHMCCUdefaults eingebunden.
leider hat er keine attribute hinzugefügt nach dem ich neugestartet hatte.
danach einen importdefaults an einem device, das funktioniert, meine defaults werden geladen

ist es evtl gewollt das die default nicht beim star tgeladen werden und auf alle devices gebügelt?

schade ist auch das bei set defaults nicht andere , in der vorgabe nicht defininierte, hmccu-atrribute gelöscht werden.
zb wenn ein device attr ccureadings 1 hat, dieses in dern defaults nicht gelistet ist, dann sollte es gelöscht werden. hilfreich um in bestehenden systemen die attribute aufzuräumen und zu vereinheitlichen

beim export kann man aktuell keinen pfad angeben?! ich habe es relativ zum fhem-root und absolut probiert (cant open file meldung jeweils)

[zap]

Zum Thema benutzerdefinierte Templates empfehle ich folgende Vorgehensweise (im Beispiel heißt das IO Device "ccu"):

• Export der Default Templates in eine Datei mit dem Befehl "get ccu exportdefaults /opt/fhem/FHEM/hmccutemp.cfg". Verzeichnis und Dateiname können frei gewählt werden. Allerdings muss der Unix-User fhem Schreibrechte haben. Ich empfehle das FHEM Verzeichnis (s.o.), da man dann die erstellte Datei über die FHEM Oberfläche editieren kann.
• Anhand der exportierten Datei sieht man die Syntax, die sich stark an das Format in HMCCUConf.pm anlehnt, allerdings nicht identisch ist (es ist eben eine Textdatei, kein Perl-Modul)
• Anpassen der exportierten Datei an die eigenen Bedürfnisse
• Laden der geänderten Datei in das IO Device mit dem Befehl "attr ccu ccudefaults /opt/fhem/FHEM/hmccutemp.cfg". Für einen einmaligen Import (z.B. für Tests) kann man auch den Befehl "set ccu importdefaults /opt/fhem/FHEM/hmccutemp.cfg" verwenden. Die so importierten Templates "vergisst" HMCCU aber beim nächsten Neustart wieder.
• Prüfen, ob das IO Device die neuen Templates kennt mit dem Befehl "get ccu defaults". Die benutzerdefinierten Attribute werden am Ende aufgelistet.

Für diejenigen, die sich ein eigenes Perl Modul durch Anpassung von HMCCUConf.pm erstellt haben, schlage ich folgende Vorgehensweise vor:

• Export der Templates wie oben beschrieben.
• Einbinden der Exportdatei wie oben beschrieben mit attr ccudefaults
• FHEM Update um die Standard HMCCU-Module wieder zu laden

Templates mit Perl-Code:

In einer benutzerdefinierten Template-Datei sollte Perl-Code keine Probleme machen. Wenn man hingegen HMCCUConf.pm anpasst, muss man Perl-Sonderzeichen wie "$" oder "{" usw. mit einem "\" escapen. Aber davon sollte man absehen und die o.g. Methode der benutzerdefinierten Templates verwenden.

@chris1284: Das Löschen von Attributen, die nicht Bestandteil des Templates sind, dürfte nicht bei jedem Nutzer gut ankommen. Man könnte es aber per Option im Befehl "set defaults" erlauben. Dann kann jeder selbst entscheiden. Ich setze es auf die Liste für die nächste Version.

[chris1284]

irendwas stimmt mit hmmcu nicht. ich lösche bei einer handvoll devices attribute, speichere, starte neu und die attribute sind wieder da!
es betrifft attr DbLogExclude * und nur hmccu geräte die bereits im bestand sind. heute habe ich einen wt angelernt, dieser zeigt das verhalten nicht.

wo cached hmccu die einstellungen? cleardefaults hat nichts gebracht

[Loredo]

Structure? Structexclude ist dein Freund


Gruß

Julian

[chris1284]

Danke, tatsache. die structure gelöscht, alle attribute dazu in devices gelöscht -> reboot alles gut.
wo ist den dieses verhalten näher beschrieben? den sinn / hintergrund verstehe ich noch nicht
cmd-ref

structexclude
Bei gesetztem Attribut wird set, attr/deleteattr ignoriert.

das war aber nicht gesetzt, deswegen irritiert es mich ein wenig

[Loredo]

Kurzum: structure konsolidiert nicht nur buttom-up den Status von Devices, sondern ermöglicht gleichzeitig auch top-down deren gemeinsame Konfiguration. Alle(?) Attribute, die an der Structure definiert sind, werden auch nach unten weitergereicht. Das kann verwirrend sein, wenn man während des Betriebs die Attribute an den untergeordneten Devices selbst anpasst, nicht aber in der Structure. Die Structure vererbt ihre Attribute nur wenn man diese dort neu setzt glaube ich, auf jeden Fall aber immer, wenn die Structure bei einem Neustart initialisiert wird.


Man kann das verschieden beeinflussen:


1. man nutzt Attribute nur an den untergeordneten Devices und hat diese nicht in der Structure definiert -> Attribute bleiben wie sie sind
2. man nutzt Attribute in der Structure -> werden vererbt
3. man nutzt Attribute in der Structure und möchte die gleichen Attribute bei den untergeordneten Devices anders und/oder unterschiedlich belegen -> Attribut in structexclude der jeweiligen untergeordneten Devices aufnehmen. Wenn diese sich nicht unterscheiden sollen, kann man structexclude auch in der Structure selbst setzen und nach unten vererben. Auch structexclude wird dann vererbt. Wenn man das nicht will, muss man auch structexclude selbst mit in das structexclude Value schreiben.


Structures mit HMCCU sind u.U. deutlich komplexer, wenn man dort nicht nur HMCCU Geräte zusammenfassen will, da man die Readingnamen zunächst auf einen einheitlichen (FHEM)Standard bringen muss. Entweder über die Attribute clientstate_priority und <struct_type>_map, die structure verwaltet, oder über die vielen Möglichkeiten von HMCCU selbst.


Das ist einer der Gründe, weshalb ich hier seit langem predige, dass HMCCU eine Möglichkeit braucht es Menschen einfacher zu machen seine komplexen Attribute anständig zu benutzen, ohne zuvor eine Doktorarbeit darüber zu schreiben. Auf mich hört ja keiner 
Ich werde bald nochmal einen letzten Versuch starten aus meiner Sicht vernünftige Default-Settings hier zu posten, die allgemein gültig sein sollten. Ob die dann jeder einfach benutzen können soll oder ob jeder weiterhin dann Stunden und Tage damit verbringen muss FHEM, HMCCU (und eq-3 mit seinen Datapoints) richtig zu verstehen, bleibt dann unserem Modulautor überlassen.

[zap]

Das ist einer der Gründe, weshalb ich hier seit langem predige, dass HMCCU eine Möglichkeit braucht es Menschen einfacher zu machen seine komplexen Attribute anständig zu benutzen, ohne zuvor eine Doktorarbeit darüber zu schreiben. Auf mich hört ja keiner 

Ich finde schon, dass ich bei der aktuellen Version auf dich gehört habe

Ich werde bald nochmal einen letzten Versuch starten aus meiner Sicht vernünftige Default-Settings hier zu posten, die allgemein gültig sein sollten. Ob die dann jeder einfach benutzen können soll oder ob jeder weiterhin dann Stunden und Tage damit verbringen muss FHEM, HMCCU (und eq-3 mit seinen Datapoints) richtig zu verstehen, bleibt dann unserem Modulautor überlassen.

Du kannst Dir das Leben schon mal erleichtern, indem Du im IO Device das Attribut substdefaults nach Deinen Wünschen setzt. Damit hast Du schon mal einheitliche Readingwerte. Das greift bei allen Client Devices.
Einen globalen Default Setter für Readingnames werde ich auch noch bereitstellen (hatte ich nicht mehr in der 3.7 geschafft). Mit diesen beiden Attributen, die du nur einmal setzen musst, kannst Du alle Readings nach deinen Wünschen beeinflussen.

Bzgl. der Datenpunkte wird dir aber auch zukünftig ein Blick in die EQ-3 Doku nicht erspart bleiben, wenn die Verwendung unklar ist, kein Template existiert oder die Templates nicht deinen Wünschen entsprechen.

[Loredo]

Ich finde schon, dass ich bei der aktuellen Version auf dich gehört habe

A bisserl, ja  *thumbsUp*

Du kannst Dir das Leben schon mal erleichtern, indem Du im IO Device das Attribut substdefaults nach Deinen Wünschen setzt.

Danke, das ist ein guter Hinweis. Ich habe eine Zeitlang nicht mitgelesen hier (hier ist einfach zu viel los und die Themen sind leider viel zu divers; solch wichtige Dinge gehen hier schnell unter). Allerdings sehe ich das etwas Zwiegespalten, denn wollte man die Templates in der HMCCUConf.pm verbessern (und das ist ja das, wovon ich die ganze Zeit rede), dann müsste man dort eigentlich pro Device das substitude Attribut mitgeben, weil man sonst voraussetzte, dass substdefaults schon entsprechend richtig gesetzt sein muss. Gleichwohl finde ich es gut die Dopplungen zu vermeiden und diese allgemeinen Mappings zentral zu definieren.

Ich habe substdefaults jetzt mal gesetzt und mixe es für STATE mit einer zusätzlichen substitute Definition in den Devices.

Einen globalen Default Setter für Readingnames werde ich auch noch bereitstellen (hatte ich nicht mehr in der 3.7 geschafft).

Das ist super! Genau das fehlt eben noch, bevor es anfängt nützlich zu werden.

Danach fehlen IMHO noch 2 Dinge:

1. Die Auswertung der Readings, um daraus ein FHEM-kompatibles Status Reading zu generieren. Ich hatte dazu ja bereits per PM Vorschläge für ein Reading "stateHM" gemacht und darum gebeten eine Funktion in HMCCU direkt einzubauen, weil die Informationen da effizienter bereitstehen statt über eine Custom-Funktion in Verbindung mit userReadings.

Code Auswählen Erweitern


sub myHMCCUstate($;$) {

    # based on: HomeMatic-Script Dokumentation, Teil 4: Datenpunkte V1.0

    my ( $name, $reverseOnOff ) = @_;
    my $p = myHMCCUreadingsToHash($name);
    my $stateHM;

    # eval error parameters
    if ( defined( $p->{UNREACH} ) && $p->{UNREACH} =~ /^(1|true|dead)$/i ) {
        $stateHM = "unreachable";
    }
    elsif ( defined( $p->{FAULT_REPORTING} )
        && $p->{FAULT_REPORTING} !~ /^(0|NO_FAULT|4|COMMUNICATION_ERROR|6|LOWBAT)$/i )
    {
        $stateHM = "err_f_" . $p->{FAULT_REPORTING};
    }
    elsif ( defined( $p->{ERROR_OVERHEAT} )
        && $p->{ERROR_OVERHEAT} =~ /^(1|true)$/i )
    {
        $stateHM = "err_overheated";
    }
    elsif ( defined( $p->{ERROR_OVERLOAD} )
        && $p->{ERROR_OVERLOAD} =~ /^(1|true)$/i )
    {
        $stateHM = "err_overloaded";
    }
    elsif ( defined( $p->{ERROR_REDUCED} )
        && $p->{ERROR_REDUCED} =~ /^(1|true)$/i )
    {
        $stateHM = "err_reduced";
    }
    elsif ( defined( $p->{ERROR} ) && $p->{ERROR} !~ /^(0|NO_ERROR)$/i ) {
        $stateHM = "err_" . $p->{ERROR};
    }

    # eval operational parameters
    elsif ( defined( $p->{INHIBIT} )
        && $p->{INHIBIT} =~ /^(1|true|locked)$/i )
    {
        $stateHM = "locked";
    }
    elsif ( defined( $p->{DIRECTION} )
        && $p->{DIRECTION} !~ /^(0|NONE|stop)$/i )
    {
        $stateHM = "undefined";
        if ( $p->{DIRECTION} =~ /^(1|UP)$/i ) {
            $stateHM = "up";
        }
        elsif ( $p->{DIRECTION} =~ /^(2|DOWN)$/i ) {
            $stateHM = "down";
        }
    }
    elsif ( defined( $p->{WORKING} )
        && $p->{WORKING} !~ /^(0|false)$/i )
    {
        $stateHM = "working";
    }

    # eval state parameters
    elsif ( defined( $p->{MOTION} ) ) {
        $stateHM = "noMotion";
        $stateHM = "motion" if ( $p->{MOTION} =~ /^(1|true|motion)$/i );
    }
    elsif ( defined( $p->{LEVEL} ) ) {
        $stateHM = $p->{LEVEL};
        if ($reverseOnOff) {
            $stateHM = "off"
              if ( $stateHM eq "100" );
            $stateHM = "on"
              if ( $stateHM eq "0" );
        }
        else {
            $stateHM = "off"
              if ( $stateHM eq "0" );
            $stateHM = "on"
              if ( $stateHM eq "100" );
        }
        $stateHM = $p->{stateHM}
          if ( defined( $p->{stateHM} ) && $p->{LEVEL} > 100 );
    }
    elsif ( defined( $p->{STATE} ) ) {

        # cannot reliably be translated into text value
        # -> custom rewrite via FHEM device attributes required
        $stateHM = $p->{STATE};
    }
    elsif ( defined( $p->{VALVE_STATE} ) ) {
        $stateHM = $p->{VALVE_STATE};
    }
    elsif ( defined( $p->{ACTUAL_TEMPERATURE} ) ) {
        $stateHM = $p->{ACTUAL_TEMPERATURE};
    }
    elsif ( defined( $p->{CONTROL_MODE} ) ) {
        $stateHM = $p->{CONTROL_MODE};
    }
    elsif ( defined( $p->{TEMPERATURE} ) || defined( $p->{HUMIDITY} ) ) {
        $stateHM .= "T: " . $p->{TEMPERATURE} . " "
          if ( defined( $p->{TEMPERATURE} ) );
        $stateHM .= "H: " . $p->{HUMIDITY} . " "
          if ( defined( $p->{HUMIDITY} ) );
        $stateHM .= "W: " . $p->{WIND_SPEED} . " "
          if ( defined( $p->{WIND_SPEED} ) );
        $stateHM .= "R: " . $p->{RAIN_COUNTER} . " "
          if ( defined( $p->{RAIN_COUNTER} ) );
        $stateHM .= "IR: " . $p->{RAINING} . " "
          if ( defined( $p->{RAINING} ) );
        $stateHM .= "WD: " . $p->{WIND_DIRECTION} . " "
          if ( defined( $p->{WIND_DIRECTION} ) );
        $stateHM .= "WDR: " . $p->{WIND_DIRECTION_RANGE} . " "
          if ( defined( $p->{WIND_DIRECTION_RANGE} ) );
        $stateHM .= "S: " . $p->{SUNSHINEDURATION} . " "
          if ( defined( $p->{SUNSHINEDURATION} ) );
        $stateHM .= "B: " . $p->{BRIGHTNESS} . " "
          if ( defined( $p->{BRIGHTNESS} ) );
    }

    # eval warning parameters
    elsif ( defined( $p->{FAULT_REPORTING} )
        && $p->{FAULT_REPORTING} =~ /^(6|LOW_?BAT)$/i )
    {
        $stateHM = "warn_battery";
    }
   elsif ( defined( $p->{LOW_BAT} )
        && $p->{LOW_BAT} =~ /^(1|true|low)$/i )
    {
        $stateHM = "warn_battery";
    }
   elsif ( defined( $p->{LOWBAT} )
        && $p->{LOWBAT} =~ /^(1|true|low)$/i )
    {
        $stateHM = "warn_battery";
    }

    # default value
    elsif ( defined( $p->{UNREACH} ) && $p->{UNREACH} !~ /^(1|true|dead)$/i ) {
        $stateHM = "ok";
    }
    else {
        $stateHM = "Initialized";
    }

    return $stateHM;
}


sub myHMCCUreadingsToHash ($) {
    my ($name) = @_;
    my $d = $defs{$name};
    my $r;

    my $rmap = {
        Activity        => 'UNREACH',
        controlMode     => 'CONTROL_MODE',
        direction       => 'DIRECTION',
        humidity        => 'HUMIDITY',
        level           => 'LEVEL',
        locked          => 'INHIBIT',
        'measured-temp' => 'ACTUAL_TEMPERATURE',
        motion          => 'MOTION',
        motor           => 'DIRECTION',
        pct             => 'LEVEL',
        temperature     => 'TEMPERATURE',
        valve           => 'VALVE_STATE',
    };

    if ( defined($d) && defined( $d->{READINGS} ) ) {
        foreach ( keys %{ $d->{READINGS} } ) {
            my $n = $_;
            $n = $rmap->{$_} if ( $rmap->{$_} );

            $r->{$n} = $d->{READINGS}{$_}{VAL}
              if ( defined( $d->{READINGS}{$_}{VAL} ) );
        }
    }

    return $r;
}

2. Für Datenpunkte, bei denen der Zweck eindeutig global über die eq-3 Doku zu ermitteln ist, sollte HMCCU die Attribute entsprechend sinnvoll vorbelegen. Derzeit kann man z.B. gefahrlos bei jedem HMCCUDEV/HMCCUCHN Device diese Settings setzen und erhält damit endlich die FHEM Kompatibilität:

Code Auswählen Erweitern


ccureadingformat datapoint
ccureadingname ^.*ACTUAL_TEMPERATURE$:measured-temp,^.*AES_KEY$:sign,^.*BRIGHTNESS$:brightness,^.*CONTROL_MODE$:controlMode,^.*DIRECTION$:direction,^.*ENERGY_COUNTER$:energy,^.*FREQUENCY$:frequency,^.*HUMIDITY$:humidity,^.*INHIBIT$:lock,^.*LEVEL$:pct,^.*LOW[_]?BAT$:battery,^.*MOTION$:motion,^.*POWER$:power,^.*SET_TEMPERATURE$:desired-temp,^.*TEMPERATURE$:temperature,^((.*\.)?\d\.+)?UNREACH$:Activity,^.*VALVE_STATE$:valve,^.*VOLTAGE$:voltage,^.*WORKING$:working,^\d\.+:,
substitude AES_KEY!(1|true):on,(0|false):off;DIRECTION!(none|0):none,(up|1):up,(down|2):down,.*:undefined;INHIBIT!(false|0):unlocked,(true|1):locked;LOWBAT,LOW_BAT!(false|0):ok,(true|1):low;MOTION!(false|0):noMotion,(true|1):motion;UNREACH!(false|0):alive,(true|1):dead;WORKING!(false|0):false,(true|1):true
stateFormat stateHM
userReadings stateHM:^(?!stateHM).* { return myHMCCUstate($name); }


(Ich taste mich da aktuell aber selbst gerade noch - eben mühsam - vor die FHEM Standards teils zu ermitteln und mit der eq-3 Datenpunkt-Doku in Einklang zu bringen)

Aber warum sich jeder HMCCU Nutzer diese Erkenntnisse erst selbst mühsam durch lesen und verstehen(!) der CommandRef sowie der eq-3 Datenpunkt-Doku erarbeiten muss, erschließt sich mir eben gar nicht. Die sollte man nur zur Hilfe nehmen müssen, wenn es wirklich was ganz neues gibt oder man eben weiß was man tut und warum man dann etwas anders konfigurieren will.

Bzgl. der Datenpunkte wird dir aber auch zukünftig ein Blick in die EQ-3 Doku nicht erspart bleiben, wenn die Verwendung unklar ist, kein Template existiert oder die Templates nicht deinen Wünschen entsprechen.

Absolut richtig, das darf ja auch so sein 

[Loredo]

Ich habe gerade HMCCU Version 3.7 eingecheckt.

Grad erst gesehen... mea culpa.

   
• Das Attribut "ccureadingname" in HMCCUDEV und HMCCUCHN wurde erweitert. Wenn der neue Readingname mit einem "+" beginnt, wird dieses Reading zusätzlich erzeugt, d.h. das alte wird beibehalten. Beispiel: Mit "LOWBAT:+battery" erhält man zwei Readings.

Sollte das auf eines meiner Feedbacks zurückzuführen sein wäre mir hier nicht ganz klar, wie ich jetzt das Reading umbenennen kann und gleichzeitig unter zwei anderen Namen erzeugen lasse..
(Beispiel: LEVEL -> pct+level)

   
• Für jedes Device wird ab sofort ein Reading "hmstate" erzeugt. Wenn einer der Datenpunkte UNREACH, ERROR*, FAULT* oder LOWBAT eines Devices einen Wert > 0 hat, wird dieser Wert in "hmstate" übernommen. Die Priorisierung erfolgt nach o.g. Reihenfolge. Das Attribut "hmstatevals" legt fest, wie die Werte > 0 ersetzt werden. Die Syntax entspricht dem Attribut "substitute", jedoch ohne den Wert 0. Beispiel: "LOWBAT!1:battery_low;UNREACH!1:unreachable". Wenn keiner der o.g. Datenpunkte > 0 ist, wird der Wert von "state" in "hmstate" übernommen.

Ähnlich hier: Wenn das auf mein PM Feedback zurückgehen sollte, ist der Sinn verfehlt, da sich die in meinem vorigen Post genannten Custom-Funktionen für stateHM nicht dadurch ersetzen lassen.
Nur die Errors zusammenzuführen (und die Zahlenwerte zu deuten) ist IMHO so gut wie sinnfrei, zumal du Fehler mit Warnungen vermischst (LOWBAT ist kein Fehler).

Ich hätte mich darüber gefreut, wenn du lieber nochmal bei mir nachgefragt hättest, ob du es richtig verstanden hast oder weshalb du meinst etwas weglassen zu müssen. Darüber hätte ich dann gerne diskutiert.
So entsteht jetzt das "friss oder stirb" Gefühl und meine Dankbarkeit hält sich eher in Grenzen.

   
• Die Datenpunkte LOWBAT/LOW_BAT und UNREACH werden immer als Readings gespeichert. Ein Angabe im Attribut "ccureadingfilter" ist nicht mehr erforderlich.

Verstehe ich nicht. Was ist daran neu? Wenn ich ccureadingfilter gar nicht gesetzt habe oder die Datenpunkte dort mit aufgenommen habe, dann wurden sie auch gespeichert. Werden sie jetzt also gespeichert, egal ob sie in ccureadingfilter aufgeführt sind? Da wird's jetzt aber inkonsistent, wenn du jetzt plötzlich von deiner Absicht abweichtest alles vollkommen flexibel und bloß ohne Bevormundung umzusetzen.
Versteh mich richtig, ich finde auch, dass diese Angaben essentiell für jedes Device sind. Aber es entspräche eben nicht mehr deiner eigens definierten Philosophie.

[zap]

Sollte das auf eines meiner Feedbacks zurückzuführen sein wäre mir hier nicht ganz klar, wie ich jetzt das Reading umbenennen kann und gleichzeitig unter zwei anderen Namen erzeugen lasse..
(Beispiel: LEVEL -> pct+level)

ccureadingname LEVEL:+pct,LEVEL:+level => Ergibt 3 Readings LEVEL, pct und level
ccureadingname LEVEL:+pct,LEVEL:level => Ergibt 2 Readings pct und level

Im Fall von LEVEL => level hilft auch "ccureadingformat datapointlc" (lc für lower case)

Ähnlich hier: Wenn das auf mein PM Feedback zurückgehen sollte, ist der Sinn verfehlt, da sich die in meinem vorigen Post genannten Custom-Funktionen für stateHM nicht dadurch ersetzen lassen.
Nur die Errors zusammenzuführen (und die Zahlenwerte zu deuten) ist IMHO so gut wie sinnfrei, zumal du Fehler mit Warnungen vermischst (LOWBAT ist kein Fehler).

Mit dem Reading hmstate in Kombination mit dem Attribut hmstatevals läßt sich m.E. Deine stateHM Funktion 1:1 abbilden. Dabei bleibt alles weitgehend frei konfgiurierbar, ohne eine Funktion mit endlosen if/elsif Konstrukten bauen zu müssen, die vielleicht beim nächsten EQ-3 Gerät oder Firmware Update nicht mehr funktioniert. Es gibt bei der Brechnung von hmstate eine Prioliste. LOWBAT als Warning steht ganz hinten in dieser Liste.

So entsteht jetzt das "friss oder stirb" Gefühl und meine Dankbarkeit hält sich eher in Grenzen.

Vom Anspruch, es jedem recht zu machen und alle Anforderungen umzusetzen, habe ich mit schon vor vielen Berufsjahren verabschiedet

Werden sie jetzt also gespeichert, egal ob sie in ccureadingfilter aufgeführt sind? Da wird's jetzt aber inkonsistent, wenn du jetzt plötzlich von deiner Absicht abweichtest alles vollkommen flexibel und bloß ohne Bevormundung umzusetzen.
Versteh mich richtig, ich finde auch, dass diese Angaben essentiell für jedes Device sind. Aber es entspräche eben nicht mehr deiner eigens definierten Philosophie.

Das Statement im HMCCU Code sieht so aus:

Code Auswählen Erweitern


return 1 if ($cf !~ /nohmstate/ && $dpt =~ /(^UNREACH|^LOWBAT|^LOW_BAT|^ERROR|^FAULT)/);


Soll heißen, all diese Datenpunkte im Statement werden als Reading gespeichert. Sie werden benötigt, um hmstate zu ermitteln. Mit dem Attribut ccuflags = nohmstate kann man dieses Speichern verhindern, dann gibt es aber auch kein hmstate Reading.
Die Flexibilität bleibt also insofern gewahrt, als man über ccuflags das bisherige Verhalten wiederherstellen kann.

[Kai-Alfonso]

Hi,

ich habe irgendwie Ärger mit dem RPC Server - er scheint zwar zu laufen, aber er updatet nicht die Readings automatisch.

Code Auswählen Erweitern

defmod d_ccu HMCCU homematic-ccu2
attr d_ccu alias HomeMatic CCU2
attr d_ccu room Schnittstellen
attr d_ccu rpcport 2001,2010
attr d_ccu rpcserver on
attr d_ccu stateFormat rpcstate/state

setstate d_ccu running/OK
setstate d_ccu 2017-01-17 19:15:07 rpcstate running
setstate d_ccu 2017-01-18 08:24:16 state OK



get rpcstate sagt "RPC Process not running"

RPCPID hat die Werte 4824,4825 und ps -ef sagt

Code Auswählen Erweitern

root@fhem:~# ps -ef |  grep 482
fhem      4824  4813  0 Jan17 ?        00:00:52 /usr/bin/perl fhem.pl fhem.cfg
fhem      4825  4813  0 Jan17 ?        00:00:50 /usr/bin/perl fhem.pl fhem.cfg

Code Auswählen Erweitern

RPCState     running
STATE     running/OK

Ein ps -ef | grep ccurpcd ergibt auch, das kein entsprechender Process läuft

Ein set rpcserver on ergibt

Code Auswählen Erweitern

2017.01.18 10:13:27 0: HMCCU: RPC server(s) already running with PIDs 4825,4824


ein set rpcserver restart ergibt

Code Auswählen Erweitern

2017.01.18 10:14:07 1: HMCCU: Deregistering RPC server http://192.168.1.166:7420/fh2010 at http://homematic-ccu2:2010/
2017.01.18 10:14:07 1: HMCCU: Deregistering RPC server http://192.168.1.166:7411/fh2001 at http://homematic-ccu2:2001/
2017.01.18 10:14:07 0: HMCCU: Stopping RPC server CB2010 with PID 4825
2017.01.18 10:14:07 0: HMCCU: Stopping RPC server CB2001 with PID 4824
2017.01.18 10:14:07 0: CCURPC: CB2010 Server loop terminated
2017.01.18 10:14:07 0: CCURPC: CB2001 Server loop terminated
2017.01.18 10:14:07 2: CCURPC: Eventcount DD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount DD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount EV = 39
2017.01.18 10:14:07 2: CCURPC: Eventcount EV = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount EX = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount EX = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount IN = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount IN = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount ND = 73
2017.01.18 10:14:07 2: CCURPC: Eventcount ND = 9
2017.01.18 10:14:07 2: CCURPC: Eventcount RA = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount RA = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount RD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount RD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount SL = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount SL = 1
2017.01.18 10:14:07 2: CCURPC: Eventcount UD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount UD = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount total = 115
2017.01.18 10:14:07 2: CCURPC: Eventcount total = 12
2017.01.18 10:14:07 2: CCURPC: Eventcount writeerror = 0
2017.01.18 10:14:07 2: CCURPC: Eventcount writeerror = 0
2017.01.18 10:14:11 0: HMCCU: Received EX event. RPC server CB2001 terminated.
2017.01.18 10:14:11 0: HMCCU: Received EX event. RPC server CB2010 terminated.
2017.01.18 10:14:11 0: HMCCU: RPC server(s) with PID(s) 4824,4825 shut down. f=2
2017.01.18 10:14:11 2: HMCCU: Eventcount DD = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount EV = 39
2017.01.18 10:14:11 2: HMCCU: Eventcount EX = 2
2017.01.18 10:14:11 2: HMCCU: Eventcount IN = 2
2017.01.18 10:14:11 2: HMCCU: Eventcount ND = 82
2017.01.18 10:14:11 2: HMCCU: Eventcount RA = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount RD = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount SL = 2
2017.01.18 10:14:11 2: HMCCU: Eventcount ST = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount UD = 0
2017.01.18 10:14:11 2: HMCCU: Eventcount total = 127
2017.01.18 10:14:11 0: HMCCU: RPC server CB2001 started with pid 17404
2017.01.18 10:14:11 0: HMCCU: RPC server CB2010 started with pid 17405
2017.01.18 10:14:18 0: HMCCU: Received SL event. RPC server CB2001 enters server loop
2017.01.18 10:14:25 1: HMCCU: Registering callback http://192.168.1.166:7411/fh2001 with ID CB2001 at http://homematic-ccu2:2001/
2017.01.18 10:14:25 1: HMCCU: RPC callback with URL http://192.168.1.166:7411/fh2001 initialized
2017.01.18 10:14:30 0: HMCCU: Received SL event. RPC server CB2010 enters server loop
2017.01.18 10:14:37 1: HMCCU: Registering callback http://192.168.1.166:7411/fh2010 with ID CB2010 at http://homematic-ccu2:2010/
2017.01.18 10:14:37 1: HMCCU: RPC callback with URL http://192.168.1.166:7411/fh2010 initialized



jetzt sehe ich auch die beiden RPC Prozesse

Code Auswählen Erweitern

fhem     17404  4813  3 10:14 ?        00:00:04 /usr/bin/perl ./FHEM/ccurpcd.pl homematic-ccu2 2001 /tmp/ccuqueue_2001_1 ./log/ccurpcd_2001_1.log 3
fhem     17405  4813  3 10:14 ?        00:00:03 /usr/bin/perl ./FHEM/ccurpcd.pl homematic-ccu2 2010 /tmp/ccuqueue_2010_1 ./log/ccurpcd_2010_1.log 3


Die Readings aktualisieren sich trotzdem nicht


Ich habe auch mal eine Frage zu der IP-Adresse 192.168.1.166 für den RPC-Server. Woher kommt diese IP? Die wurde nicht per DHCP vergeben und die feste IP des Fhem Servers ist eine andere (192.168.1.30)

Auszug aus der ccurpcd Log Datei

Code Auswählen Erweitern

root@fhem:/opt/fhem# cat ./log/ccurpcd_2010_1.log
16.01.2017 17:53:54 Creating file queue
16.01.2017 17:53:54 Initializing RPC server
16.01.2017 17:53:54 Callback server created listening on port 7410
16.01.2017 17:53:54 Adding callback for events
16.01.2017 17:53:54 Adding callback for new devices
16.01.2017 17:53:54 Adding callback for deleted devices
16.01.2017 17:53:54 Adding callback for modified devices
16.01.2017 17:53:54 Adding callback for replaced devices
16.01.2017 17:53:54 Adding callback for readded devices
16.01.2017 17:53:54 Entering server loop. Use kill -SIGINT 24528 to terminate program
16.01.2017 17:55:29 RPC server terminated
18.01.2017 10:14:14 Creating file queue
18.01.2017 10:14:14 Initializing RPC server
18.01.2017 10:14:15 Callback server created listening on port 7410
18.01.2017 10:14:15 Adding callback for events
18.01.2017 10:14:15 Adding callback for new devices
18.01.2017 10:14:15 Adding callback for deleted devices
18.01.2017 10:14:15 Adding callback for modified devices
18.01.2017 10:14:15 Adding callback for replaced devices
18.01.2017 10:14:15 Adding callback for readded devices
18.01.2017 10:14:15 Entering server loop. Use kill -SIGINT 17405 to terminate program
root@fhem:/opt/fhem# cat ./log/ccurpcd_2010_1.log
16.01.2017 17:53:54 Creating file queue
16.01.2017 17:53:54 Initializing RPC server
16.01.2017 17:53:54 Callback server created listening on port 7410
16.01.2017 17:53:54 Adding callback for events
16.01.2017 17:53:54 Adding callback for new devices
16.01.2017 17:53:54 Adding callback for deleted devices
16.01.2017 17:53:54 Adding callback for modified devices
16.01.2017 17:53:54 Adding callback for replaced devices
16.01.2017 17:53:54 Adding callback for readded devices
16.01.2017 17:53:54 Entering server loop. Use kill -SIGINT 24528 to terminate program
16.01.2017 17:55:29 RPC server terminated
18.01.2017 10:14:14 Creating file queue
18.01.2017 10:14:14 Initializing RPC server
18.01.2017 10:14:15 Callback server created listening on port 7410
18.01.2017 10:14:15 Adding callback for events
18.01.2017 10:14:15 Adding callback for new devices
18.01.2017 10:14:15 Adding callback for deleted devices
18.01.2017 10:14:15 Adding callback for modified devices
18.01.2017 10:14:15 Adding callback for replaced devices
18.01.2017 10:14:15 Adding callback for readded devices
18.01.2017 10:14:15 Entering server loop. Use kill -SIGINT 17405 to terminate program


Die beiden Dat Dateien ccuqueue_2010_1.dat und ccuqueue_2001_1.dat in /tmp haben jeweils 0 Byte



Das HMCCU Device steht in Fhem jetzt seit 10 Minuten auf starting/busy

Hmm, was kann ich noch tun um das Problem einzukreisen?