Buderus KM200 Kommunikationsmodul

[Sailor]

Und schon hab ich auch Readings bis der Arzt kommt!

Un schon haben wir ganz nebenbei eine neue Krankheit geschaffen: Akute Readingseritis! 

Gruss
   Sailor

[Sailor]

Hallo Olaf

Bin gerade dran, das Interval in die Attribute zu übernehmen, und auch die per Interval zu holenden Werte per Attribut modifizierbar zu machen.

OK, dann lege ich mich diesbezueglich erstmal zurueck. Man muss ja auch mal Anderen den Vortritt lassen... 
In den Zeilen 263 bis 271 hatte ich ja schon einen zarten Versuch gemacht, aber irgendwie kommt das Attribut nicht rein

Denn: den ganzen Quatsch brauchen wir nicht regelmäßig abfragen. Das meiste ist statisch und nur einmal interessante.
Es gibt ne handvoll Werte, die regelmäßig spannend sind.
Damit das aber jeder selbst entscheiden kann, baue ich die in die Attribute.

FULL ACK"
Genau das war auch der Grund fuer die unterschiedlichen Subroutinen "km200_CompleteData" und "km200_CompleteDataInit"

km200_CompleteDataInit soll am Anfang alle bekannten Services versuchen und dann zwei Tabellen (HASH oder ARRAY) anlegen:
a) Alle Services die lesbar sind.
b) Alle Services die darueberhinaus auch schreibar sind.

Eine Tabelle ist bekannt:
c) Alle Services die statische Werte liefern und nicht in der Intervallschleife erneut geprueft werden muessen.

Ich habe also die Idee aus den Tabellen a) und c) zwei neue Tabellen zu generieren:
d) Vorhandene statische Werte: a){n} && c){n}.
e) Vorhandene dynamische Werte a) - (a){n} && c){n}). Soll heissen: Alle vorhandenen Werte minus vorhandene statische Werte = vorhandene dynamische Werte.

Und dann werden nur Tabelle
d) im Rahmen des Intervalls fuer statische Werte abgefragt

Code: [Auswählen]

attr myKM200 statValInterval 600
e) im Rahmen des Intervalls fuer dynamische Werte abgefragt

Code: [Auswählen]

attr myKM200 dynValInterval 60
So weit meine Idee. An der Umsetzung hapert es wie du an den Kommentarzeilen in der "km200_CompleteDataInit" sehen kannst.

Der Hintergrund ist, dass ich in PERL nicht ganz so bewandert bin und ich an dieser Stelle wirklich die Hilfe eines PERL-Experten brauche, der sich mit HASHs auskennt.

In den Zeilen 823 bis 831 hate ich die Idee dem globalen HASH alle vorhandenen Werte mit allen individuellen keys anzuhaengen.
Sozusagen ein HASH im HASH...

Es eruebrigt sich wohl zu sagen, dass ich nicht einmal eine Ahnung habe, ob die Werte ueberhaupt reingekommen sind, da ich sie nicht auslesen kann.

Wenn du diesbezuglich eine Idee hast... Dann bitte her damit! Ich bin diesbezueglich scheinbar in eine Sackgasse geraten.

Mein Vorschlag:
Lass uns erstmal das Problem mit dem Einlesen der Attribute loesen. Das wuerde mich schon ein Stueck weiterbringen.
Dann koennte ich mich schon mal an die von fhem geforderte Subroutine "km200_Attr" machen.

Gib mir die entsprechenden CodeZeilen und ich werde sie in meine Version einfuegen. Wohlkommentiert und formatiert versteht sich! 

Gruss
   Sailor

[Sailor]

Moinsen!

Warum zum Henker funktioniert AttrVal nicht 

fhem.cfg

Code: [Auswählen]

define myKm200 km200 192.168.178.200 120 aaaa-bbbb-cccc-dddd KM200PW
attr myKm200 room Central Heating
attr myKm200 IntervalDynVal 90
attr myKm200 IntervalStatVal 900


Code: [Auswählen]

sub km200_Initialize($)
{
    my ($hash)  = @_;

    $hash->{Version}  = "V 1.0.8";
    $hash->{STATE}    = "Init";
    $hash->{DefFn}    = "km200_Define";
    $hash->{UndefFn}  = "km200_Undefine";
    #$hash->{SetFn}    = "km200_Set";
    $hash->{GetFn}    = "km200_Get";
    #$hash->{AttrFn}   = "km200_Attr";
    $hash->{AttrList} = "do_not_notify:1,0 " .
"passwords_encoded:1,0 " .
"loglevel:0,1,2,3,4,5,6 " .
"IntervalDynVal " .
"IntervalStatVal " .
$readingFnAttributes;
}

km200_Define:

Code: [Auswählen]

my $tempval = AttrVal($name, "IntervalDynVal", 5);
print ("IntervalDynVal: $tempval \n");

Und die Ausgabe ist 5 statt 90 obwohl der Wert in der fhem.cfg mit 90 definiert ist.

Gruss
    Sailor

[nobody0472]

Hi Sailor,

anbei ein Aufschlag. Mit den Attributen muß man "gequoted" umgehen, nicht wie im HASH direkt.
Habe Interval nun im Attribut, kann dies auch ändern, es wird aber dem HASH weiterhin übergeben.
Finde die Idee, es doppelt zu halten nicht verkehrt, weil:
a) der User kann Attribute löschen
b) dann würden die Routinen fehlschlagen, die sich drauf verlassen.

Daher würde ich die Attribute nutzen wollen, um die Werte zu ändern, aber die eigentlichen Werte (falls Attribute gelöscht werden) trotzdem am Hash hängen lassen. Und die Routinen selbst, ob nun Timer, GetData, etc. auf den Hash-Values operieren lassen.

Schau mal, ob Du damit was anfangen kannst.
Habe AttrFN in Betrieb genommen, und Interval im Define direkt mit in die Attribute gehängt.

LG,
Olaf

[Sailor]

Hallo Olaf,


Die angehängte hat gar kein AttrFN im gesamten Text.
Darüber hinaus kann ich auch keine Änderungen gegenüber meiner letzten Version feststellen.

Ich fürchte du fast hast aus Versehen die falsche Datei angehängt. 
23:06:55 - War wohl en bisschen spät gestern...

M

[nobody0472]

Hi Sailor,

schau mal in Zeilen 459-479 zzgl. Zeile 264 & 270;

Ist nicht viel, aber wirkungsvoll.

LG,
Olaf

[Sailor]

Oh Mann, ich habe deine Datei runtergeladen und dann eine von meinen geöffnet.

War wohl eher spät bei mir... 

Ich versuchs heute Abend mal...

Gruß
    Sailor

[Rockojfonzo]

Auch Version 1.08 funktioniert soweit ohne Fehlermeldungen.
Mir ist aber aufgefallen, dass es manche Werte bei meinem KM200 nicht gibt, wie z.B.

Code: [Auswählen]

2014.10.27 22:39:43 3: Buderus : km200 - Service: /heatingCircuits/hc1/controlType NOT available
2014.10.27 22:39:43 3: Buderus : km200 - Service: /heatingCircuits/hc1/currentOpModeInfo NOT available
2014.10.27 22:39:44 3: Buderus : km200 - Service: /heatingCircuits/hc1/designTemp NOT available
2014.10.27 22:39:44 3: Buderus : km200 - Service: /heatingCircuits/hc1/heatCurveMax NOT available
2014.10.27 22:39:44 3: Buderus : km200 - Service: /heatingCircuits/hc1/heatCurveMin NOT available
2014.10.27 22:39:45 3: Buderus : km200 - Service: /heatingCircuits/hc1/roomInfluence NOT available
2014.10.27 22:39:46 3: Buderus : km200 - Service: /heatingCircuits/hc1/roomTempOffset NOT available
2014.10.27 22:39:46 3: Buderus : km200 - Service: /heatingCircuits/hc1/setpointOptimization NOT available
2014.10.27 22:39:46 3: Buderus : km200 - Service: /heatingCircuits/hc1/solarInfluence NOT available
2014.10.27 22:39:46 3: Buderus : km200 - Service: /heatingCircuits/hc1/suWiSwitchMode NOT available
2014.10.27 22:39:46 3: Buderus : km200 - Service: /heatingCircuits/hc1/suWiThreshold NOT availablewohl aber

Code: [Auswählen]

/heatingCircuits/hc1/activeSwitchProgram  A
/heatingCircuits/hc1/actualSupplyTemperature  42.4
/heatingCircuits/hc1/currentRoomSetpoint   0
/heatingCircuits/hc1/fastHeatupFactor   0
/heatingCircuits/hc1/manualRoomSetpoint   21
/heatingCircuits/hc1/operationMode   auto
/heatingCircuits/hc1/pumpModulation   0
/heatingCircuits/hc1/roomtemperature  -3276.8
/heatingCircuits/hc1/status  ACTIVE 
/heatingCircuits/hc1/temperatureRoomSetpoint   21
/heatingCircuits/hc1/temporaryRoomSetpoint   -1
Liegt wahrscheinlich am Unterschied KM50 vs. KM200?
Ich habe laut Readings versionFirmware 01.05.04 und versionHardware iCom_Low_NSC_v1

@Sailor, Du hattest aber doch auch eine KM200, oder?

Und ich habe z.B. einen zweiten Heizkreis (Fußbodenheizung); die Werte kann ich natürlich problemlos mit "hc2" abfragen.
Da müsste das Modul ja auch irgendwie "user customizable" sein.

Schon wieder neue Krankheit: Akute Attributis! 

[nobody0472]

Hi all,

das ist super, so wollten wir das sehen.
Meine KM50 hat eine neuere Firmware (zumindest die Version) aber inhaltlich ist es wohl gleich. Auch meine Hardware-Version ist eine andere.
Die Werte, die abfragbar sind, sind aber alle gleich, eben nur anders/nicht belegt. Das liegt aber nicht am Gateway sondern an der Frage, was die Komponenten am EMS-Bus hergeben. Also die eigentliche Heizung und ihre Elemente.

Und ja, das ist eine Frage der Attribute. Habe gerade in einer Debug-Version mal eingebaut, dass die Values, die ein RETURN liefern, in eine zweite Liste als Attribute geschrieben werden. Diese kann ich dann modifizieren und per Interval abholen lassen.
Somit hat ein User, der Atributitis hat, die Möglichkeit zu bestimmen, welche Werte abgeholt werden.

Sobald da keine 3000 Debug-Meldungen mehr drin sind, stelle ich sie online.
Gruß,
Olaf

[Rockojfonzo]

Die Werte, die abfragbar sind, sind aber alle gleich, eben nur anders/nicht belegt. Das liegt aber nicht am Gateway sondern an der Frage, was die Komponenten am EMS-Bus hergeben. Also die eigentliche Heizung und ihre Elemente.

Bei dem Solarkram ist mir das auch grundsätzlich klar (hab ich nicht).
Aber warum es einen
/heatingCircuits/hc1/operationMode gibt, aber einen
/heatingCircuits/hc1/controlType nicht, erschließt sich mir natürlich nicht.

Die spannende Frage ist ja: Wie finde ich heraus, welche spannenden Werte ich verpasse? Gibt es eine Idee herauszufinden, welche noch abfragbar sind, die Du z.B. nicht hast?
Mittelfristig würde ich natürlich gerne mal das Heißwasserprogramm feiertags wie sonntags laufen lassen. Das kann meine sündhaft teure, aber leider blöde Kiste nämlich nicht.

[nobody0472]

Hi,
soweit ich weiß, fragen wir mit den REST Strings alles ab, was das Gateway über den EMS-Bus überhaupt hinkriegt. Daher kommen bei manchen Anfragen die Antworten, dass der Dienst nicht verfügbar ist.
Erst daraus wollen Sailor und ich eine Liste der Abfragen bauen, die die jeweilige Heizung tatsächlich unterstützt.
Die Liste der MÖGLICHEN Abfragen haben wir aus dem IPS-Forum übernommen, da es ja keine interne Doku von dem Gateway gibt. Ich habe aber bis dato auch keine weiteren Abfragemöglichkeiten gefunden. bzw. beim Sniffen an der APP gesehen.

Wenn aber einer unserer User mehr Infos hat, immer gern, dann bauen wir mehr mit ein.
Gruß,
Olaf

[Sailor]

Moinsen zusammen

soweit ich weiß, fragen wir mit den REST Strings alles ab, was das Gateway über den EMS-Bus überhaupt hinkriegt.

Korrekt - Die Quelle des Strings hat ein Kollege aus dem ip-symcon Bereich ermittelt: http://www.ip-symcon.de/wiki/Buderus_KM200
Woher er diese hat, erschließt sich mir zwar nicht, aber er hält mich bisher auf dem Laufenden!
Wenn Ihr noch was habt, dann her damit!

bzw. beim Sniffen an der APP gesehen.

Korrekt - Aber da wir immer nur die User-APP sniffen können und nicht die viel interessantere Wartungs-Variante der Heizungs-Installationsbetriebe wo auch interne/versteckte Werte abgefragt werden.

Gruss
    Sailor

[Sailor]

So,

und wieder eine neue Version...

In der derzeitigen Version 1.09 habe ich das Interval aus der Definitionszeile rausgeschmissen.

Daher: Vorsicht, neuer Aufruf:

Code: [Auswählen]

define <name> km200 <IPv4-address> <GatewayPassword> <PrivatePassword>
Zwei neue Atrtribute für ein unterschiedliches Interval der statischen Werte und der dynamischen sollen eingelesen werden:

Code: [Auswählen]

attr <name> IntervalDynVal
attr <name> IntervalStatVal
Sind diese nicht übergeben worden, werden default-Werte gesetzt. (Zeile 305 & 316)
Ist IntervalStatVal auf 0, werden die statischen Werte nur nach fhem-Neustart oder neuem Laden der fhem.cfg eingelesen.


Am Anfang werden alle bekannten Services "abgeklopft" (Zeile 482) und alle antwortenden Services in ein hash geschrieben.
Von dieser Liste werden dann die bekannten statischen Werte abgezogen und übrig bleiben die antwortenden dynamischen Werte.

Statische und dynamische Werte können dann mit einem unterschiedlichen Intervall abgefragt werden.

Das spart extrem CPU-Ressourcen, da für den Zeitraum der Abfrage das fhem System leider komplett blockiert ist.

Probleme:

Die Aktivierung der Zeile 112

Code: [Auswählen]

$hash->{AttrFn}   = "km200_Attr"; sorgt für eine Endlosschleife, aus welcher man nur noch mit "shutdown -h now" entkommen kann.

Kurz bevor fhem krepiert gibt es noch den Log-Eintrag

Code: [Auswählen]

2014.10.27 22:32:04 5: Cmd: >attr myKm200 room Central Heating<
2014.10.27 22:32:04 5: Cmd: >attr myKm200 IntervalDynVal 60<

Die entsprechende Funktion lautet:

Code: [Auswählen]

###START###### Handle attributes after changes via fhem GUI ###################################################START####
sub km200_Attr(@)
{
my @a = @_;
my $name = $a[1];
my $hash = $defs{$name};

if($a[2] eq "IntervalDynVal")
{
my $IntervalDynVal = $a[3];
RemoveInternalTimer($hash);
$hash->{INTERVALDYNVAL} = $IntervalDynVal;

###START###### Re-Start the timer #####################################START####
InternalTimer(gettimeofday()+$hash->{INTERVALDYNVAL}, "km200_CompleteDynData", $hash, 1);
####END####### Re-Start the timer ######################################END##### 
}
elsif($a[2] eq "IntervalStatVal")
{
my $IntervalStatVal = $a[3];
RemoveInternalTimer($hash);
$hash->{INTERVALSTATVAL} = $IntervalStatVal;
   
###START###### Re-Start the timer #####################################START####
# InternalTimer(gettimeofday()+$hash->{INTERVALSTATVAL}, "km200_CompleteStatData", $hash, 1);
####END####### Re-Start the timer ######################################END##### 
}

return undef;
}
####END####### Handle attributes after changes via fhem GUI ####################################################END#####

Daher könen auch die entsprechenden Attribute nicht eingelesen werden und es werden die o.g. Default-Werte verwendet.

Wenn Jemand weisss warum, dann immer her damit! 

Wie immer lautet die Devise: Mit der Bitte um Testeritis

Gruß
    Sailor

[furban]

erstaunlich was sich da alles in meinem Urlaub getan hat....
IN dem Code ist ja kein Stein auf dem anderen geblieben.

Für die neuste Version musste ich erst mal wieder ein Perl Modul auf dem Raspberrypi installieren

cpanm List::MoreUtils

Dann sieht das aber nicht schlecht aus

[Sailor]

Hallo Furban

Willkommen zurück... Hoffe Du hattest einen schönen Urlaub!

Dann sieht das aber nicht schlecht aus

Aber nur solange du den #-Kommentator vor Zeile 112 lässt wo er ist. 

Gruß
    Sailor