war: Techem HKV (ok) -> war Wasserzähler (ok) -> war Wärmemengenzähler (ok)

Zusch · 21 Januar 2016, 02:03:21

Zitat von: herrmannj am 20 Januar 2016, 19:31:28
das gibt es frische http://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUL/

vg
joerg

Super, danke! Hat geklappt:

current_period 346 2016-01-21 00:00:00
previous_period 1804 2015-12-31 00:00:00

Irgendwer hat wohl eine große Ladung HKVs über unserem Haus abgeworfen, das Log schreibt so 50 neue Devices. Es stellt sich raus, dass autocreate "off" und manuelles Anlegen eine gute Idee war

Danke nochmal!

Gruß,
Zusch

P.S. Mal sehen, ob es reicht den CUL nachts eine Stunde auf rfmode WMBus_T zu stellen....

herrmannj · 21 Januar 2016, 10:09:03

Zitat von: Zusch am 21 Januar 2016, 02:03:21
Super, danke! Hat geklappt:

current_period 346 2016-01-21 00:00:00
previous_period 1804 2015-12-31 00:00:00

Irgendwer hat wohl eine große Ladung HKVs über unserem Haus abgeworfen, das Log schreibt so 50 neue Devices. Es stellt sich raus, dass autocreate "off" und manuelles Anlegen eine gute Idee war

Danke nochmal!

Gruß,
Zusch

P.S. Mal sehen, ob es reicht den CUL nachts eine Stunde auf rfmode WMBus_T zu stellen....

Hi,

autocreate: ja so ist es.

CUL Nachts: sollte reichen. Die Uhren der HLV sind nicht so doll, besser also so 3:00 oder 4:00
Einige user haben berichtet das der CUL beim zurückschalten auf andere rf modi evrl zickt, das ist aber unabhängig vom modul. Genaueres kenne ich da jedoch nicht.

vg
joerg

rhya · 22 Januar 2016, 10:00:17

Ich hab meinen CUL per WeekdayTimer von 2:00 bis 2:40 in WMBUS laufen, das klappt ganz gut.
Beim Zurückstellen auf HomeMatic braucht der CUL (von busware, v3) erstmal einen Befehl - dann kommt eine Meldung, dass der CUL verschwunden ist, dann reappeared und dann geht wieder alles

Zusch · 22 Januar 2016, 10:34:16

Zitat von: herrmannj am 21 Januar 2016, 10:09:03

Einige user haben berichtet das der CUL beim zurückschalten auf andere rf modi evrl zickt, das ist aber unabhängig vom modul. Genaueres kenne ich da jedoch nicht.

Hallo,
stimmt. Wär auch zu einfach gewesen. Leider geht beim Umschalten des rfmode wohl das Pairing mit den FHTs verloren. Konnte heute morgen nichts an die FHTs senden und es kamen auch keine measured-temp und desired-temp readings mehr. Die Actuator-readings kamen aber noch durch. Neu gepairt und alles war wieder OK. Kennt jemand das Phänomen und weiss Abhilfe? Resetten des CUL mit B00 brachte nichts.

Gruß,
Zusch

Ergänzung: Nachdem ich 2 FHTs manuell neu gepairt hatte (Einstellen auf Cent n/a und senden einer Wunschtemperatur) waren die anderen plötzlich auch von ganz allein wieder da. Also geht das Pairing wohl doch nicht verloren, aber es kommt nur das Actuator-reading durch. Ich kenn mich aber zu wenig mit den Internas aus um das Problem zu lösen.

Zusch · 22 Januar 2016, 10:53:49

Zitat von: rhya am 22 Januar 2016, 10:00:17
Ich hab meinen CUL per WeekdayTimer von 2:00 bis 2:40 in WMBUS laufen, das klappt ganz gut.
Beim Zurückstellen auf HomeMatic braucht der CUL (von busware, v3) erstmal einen Befehl - dann kommt eine Meldung, dass der CUL verschwunden ist, dann reappeared und dann geht wieder alles

Hallo,
was für einen Befehl braucht der CUL denn? Ich habe da nach dem Rückstellen auf SlowRF ein Problem mit den FHTs (siehe unten). Vielleicht ist das die Lösung...

Gruß,
Zusch

rhya · 22 Januar 2016, 11:12:53

Ich sende bei mir einfach ein set desired-temp an einen HK Regler - das reicht damit FHEM (oder wem auch immer) auffällt, dass der CUL weg ist und er ihn neu einbindet

Kommt dann sowas im log:

Code Auswählen


2016.01.21 02:41:00 3: CUL_HM set Heizung_Flur_Clima desired-temp 17
2016.01.21 02:41:02 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 disconnected, waiting to reappear (CULstick)
2016.01.21 02:41:04 3: Setting CULstick serial parameters to 38400,8,N,1
2016.01.21 02:41:04 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 reappeared (CULstick)

gandy · 23 Januar 2016, 21:47:40

Hi,

seit einem Update heute Vormittag stürzt meine FHEM Installation in schönster Regelmässigkeit ab, bis heue Abend immerhin 14 mal.

Jeder Crash hinterläßt im Logfile die immer identische Meldung

Code Auswählen


Modification of non-creatable array value attempted, subscript -1 at /opt/fhem/FHEM/32_TechemWZ.pm line 153.
        main::TechemWZ_Receive(HASH(0x355f560), HASH(0x3c570e8)) called at /opt/fhem/FHEM/32_TechemWZ.pm line 240
        main::TechemWZ_Parse(HASH(0x34ae0e0), "b2E4468502311752070623D80A0009F1F0B0070030000000000000000A904"...) called at fhem.pl line 3302
        main::Dispatch(HASH(0x34ae0e0), "b2E4468502311752070623D80A0009F1F0B0070030000000000000000A904"..., HASH(0x3b708d8)) called at /opt/fhem/FHEM/00_CUL.pm line 951
        main::CUL_Parse(HASH(0x34ae0e0), HASH(0x34ae0e0), "CULWZ", "b2E4468502311752070623D80A0009F1F0B0070030000000000000000A904"...) called at /opt/fhem/FHEM/00_CUL.pm line 807
        main::CUL_Read(HASH(0x34ae0e0)) called at fhem.pl line 3143
        main::CallFn("CULWZ", "ReadFn", HASH(0x34ae0e0)) called at fhem.pl line 654

Die Zeile 153 (und weiter unten 164, Funktion TechemWZ_Receive) benutzt $hash->{CHANGETIME} als Referenz auf ein Array, obwohl dieses in Zeile 143 gelöscht wurde:

Code Auswählen


143:  delete $hash->{CHANGETIME}; # clean up, workaround for fhem prior http://forum.fhem.de/index.php/topic,47474.msg391964.html#msg391964
153:     $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts;
164:     $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts;

Vorläufig habe ich beide Zeilen 153 und 164 auskommentiert und bis jetzt konnte ich keinen weiteren Absturz verzeichnen. In meinem Produktivsystem wollte ich auch nicht unbedingt an einer funktionierenden Formulierung der beiden Zeilen herumexperimentieren, aber vielleicht würde das ganze Funktionieren, wenn dort

Code Auswählen

$hash->{CHANGETIME}[$#{ $hash->{CHANGED} }] = $ts; oder dergleichen stünde?

Beste Grüße,
Andy.

herrmannj · 23 Januar 2016, 22:28:23

kannst Du bitte ein vollständiges list auf das techem device posten ?

Falls es wirklich durch das update kommt, kannst Du abschätzen wann das vorherige update war ?

Die von Dir vorgeschlagene Änderung sollte mMn syntaktisch gleich sein - ich vermute das Problem entsteht durch einen negativen Index - den es eigentlich nicht geben sollte.

Danke und vg
joerg

gandy · 23 Januar 2016, 23:23:22

Das letzte Update davor war laut restoreDir am 7.Jan. Ich seh auch gerade dass die 32_Techem.pm mit dem vermeintlichen Fehler vom 16.Jan ist, müsste demnacg also schon aufgefallen sein.

Das list schiebe ich gerne nach, wenn du mir nochmal kurz sagen könntest, wie ich die ID des Gerätes aus dem Datagram lesen kann. Hab aktuell noch 60 instanzen von TechemWZ, wovon 5 mir gehören. Der Rest ist gut über das Haus und wohl auch die Nachbarschaft verteilt. Die wollte ich zwar schon gelöscht haben, aber vielleicht kann eins davon ja noch Hinweise liefern...

gandy · 23 Januar 2016, 23:41:15

Habs... Hat aber natürlich schon was empfangen mit meiner abgewandelten TechemWZ:

Code Auswählen


Internals:
   CHANGED
   CULWZ_MSGCNT 3
   CULWZ_RAWMSG b2E4468502311752070623D80A0009F1F0B00800300000000000000006CD0010000000000000000000000000100002AB90000000000FFFF8B::-97
   CULWZ_RSSI -97
   CULWZ_TIME 2016-01-23 23:32:43
   DEF        20751123 warm.water@-92.5
   FRIENDLY   warm.water@-92.5
   ID         20751123
   LASTInputDev CULWZ
   METER      warm water
   MSGCNT     3
   NAME       new_cnt_20751123
   NR         474
   NTFY_ORDER 50-new_cnt_20751123
   STATE      1.1
   TYPE       TechemWZ
   VERSION    70
   Readings:
     2016-01-24 00:00:00   current_period  0
     2016-01-24 00:00:00   meter           1.1
     2015-12-31 00:00:00   previous_period 1.1
     2015-12-28 11:50:38   rssi            -92.5
     2016-01-23 22:02:23   state           listening
   Helper:
     listmode   0
Attributes:
   event-on-change-reading .+
   group      Verbrauchszähler_Nachbarn
   room       Test-Techem
   stateFormat meter

Hoffe das hilft...

Danke,
Andy.

herrmannj · 23 Januar 2016, 23:46:06

Hast Du alle als deivce angelegt ? boah ...

welches os und welches perl ist das denn ?

vg
joerg

gandy · 24 Januar 2016, 00:03:37

Ja, mit TechemSammler device und Shell Einzeiler geht das recht flott

Os ist ein debian wheezy auf einem Cubietruck, Perl Version ist 5.20.2

Vg,
Andy.

herrmannj · 24 Januar 2016, 00:11:32

wertest Du die anderen aus ? Ich frage weil ich durchaus schon darüber nachgedacht habe da was für zu machen. In der Auswertung geht es ja ums Verhältnis aller zu den eigenen.

Wenn es nur um die Meldungen im log geht wenn die device nicht existieren. Die aktuelle Version konsumiert alle, bekannt oder Nachbar.

Über den Absturz grübel ich noch ..

vg
joerg

gandy · 24 Januar 2016, 00:43:05

Über Auswertung habe ich noch gar nicht nachgedacht. Am Anfang ging es mir erstmal darum, meine eigenen Zähler eindeutig zu identifizieren. Nachdem einige der vorhandenen IDs die selben meter readings hatten, dachte ich mir ich definiere mal alles was da ist und vergleiche immer wieder mal mit den tatsächlichen Zählerwerten. Bis ich auf den Trichter kam, die last_period mit der letzten Abrechnung zu vergleichen

Daran, die ganzen Überflüssigen devices wieder zu löschen, dachte ich erst jetzt wieder...

Wenn ich irgendwas tun kann, die Sache einzugrenzen, mach ich das gern. Im FileLog sehe ich gerade, dass es nach dem Update genau einen Eintrag von der neuen Version gab mit 00:00:00 - der meter Eintrag davor trägt aber eineechte Zeit. Etwa 9:30 war das Update, die beiden Zeilen auskommentiert und ein letztes Mal neu gestartet habe ich gegen 22:15.

Code Auswählen


2016-01-23_09:27:13 new_cnt_14113147 meter: 165.9
2016-01-23_09:27:13 new_cnt_14113147 current_period: 2.6
2016-01-23_18:09:00 new_cnt_44593147 meter: 13564
2016-01-23_00:00:00 new_cnt_44593147 current_period: 612
2016-01-23_22:17:48 new_cnt_44594869 meter: 28462
2016-01-23_22:17:48 new_cnt_44594869 current_period: 1102
2016-01-23_22:20:38 wz_Heizung meter: 9087

Vg,
Andy.

herrmannj · 24 Januar 2016, 15:09:50

Hi,

ich vermute mal das es ein Problem / bug mit der 5.20 er perl ist. Dafür spricht mMn das es bei anderen läuft - ich kann es auch nicht provozieren.

Ist aber auch leicht zu lösen, den Index kann man auch anders konstruieren, da sehe ich kein Problem.

Ich bin leider bis Sa unterwegs - komme also erst am WE dazu. Bis dahin hast Du ja einen workaround.

Wenn Du selber Hand anlegen möchtest folgender Vorschlag: line #148

aus

Code Auswählen

  if ($ats ne $ts) {
    readingsBeginUpdate($hash);
    $hash->{".updateTimestamp"} = $ts;
    readingsBulkUpdate($hash, "meter", $msg->{meter});
    readingsBulkUpdate($hash, "current_period", $msg->{actualVal});
    $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts;
    readingsEndUpdate($hash, 1);
  }

wird

Code Auswählen

  if ($ats ne $ts) {
   my $index;
    readingsBeginUpdate($hash);
    $hash->{".updateTimestamp"} = $ts;
    readingsBulkUpdate($hash, "meter", $msg->{meter});
    $index = int(@{$hash->{CHANGED}}) -1;
    if ($index < 0) {
      Log3 $hash->{NAME}, 1, "$hash->{NAME}: index failed (meter) $index";
    } else {
     $hash->{CHANGETIME}[$index] = $ts;
    }
    readingsBulkUpdate($hash, "current_period", $msg->{actualVal});
    $index = int(@{$hash->{CHANGED}}) -1;
    if ($index < 0) {
      Log3 $hash->{NAME}, 1, "$hash->{NAME}: index failed (current_period) $index";
    } else {
     $hash->{CHANGETIME}[$index] = $ts;
    } 
    readingsEndUpdate($hash, 1);
  }

Wenn das so läuft kann man sich den if zweig auch schenken, von daher wäre ein Test gut.
Code ist nicht getestet, aber Du kannst ja sichtlich perl. Sollte ich einen Typo haben siehste das also

vg
jörg