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

[gandy]

Hi,

keine Eile, der Vorschlag sieht mir ganz solide aus, ich hab den einfach mal unverändert zum Testen übernommen, Danke!    Ich werde dann berichten, ob was geloggt wird oder nochmal schlimmeres passiert.

In Sachen Perl Version hat man ja nicht immer so die Wahl, welche Version läuft denn bei Dir?

Erstmal gute Reise, VG,
Andy.

[Zusch]

Hallo zusammen,
ich habe da noch ein paar Devices, die nicht verarbeitetet werden, obwohl Sie angelegt sind. Ich bekomme auch "listening"-Status aber keine anderen readings. Im Log steht immer noch:

2016-01-25 10:22:56 Global global UNDEFINED WMBUS_TCH_32728854_118_240 WMBUS b294468505488723276F01168A0009F1F34200008342000802C0004051ED9006BA1007CB2008DC3009ED4000FE50096BA80DE
2016-01-25 10:23:03 Global global UNDEFINED WMBUS_TCH_30825882_118_240 WMBUS b294468508258823076F049FBA0009F1F35200008352000802C000305C53F006BA1007CB2008DC3009ED4000FE50096BA80D6
2016-01-25 10:23:24 Global global UNDEFINED WMBUS_TCH_32430683_118_240 WMBUS b294468508306433276F0CBABA0009F1F32200008322000802C0001052173006BA1007CB2008DC3009ED4000FE50096BA82CE
2016-01-25 10:23:41 Global global UNDEFINED WMBUS_TCH_32728846_118_240 WMBUS b294468504688723276F09444A0009F1F35200008352000802C02000513032A1F5A1B1F5A008DC3009ED4000FE500924780EB
2016-01-25 10:24:04 Global global UNDEFINED WMBUS_TCH_32728848_118_240 WMBUS b294468504888723276F0E8A0A0009F1F35200008352000802C000005E532006BA1007CB2008DC3009ED4000FE50096BA86D5
2016-01-25 10:24:19 Global global UNDEFINED WMBUS_TCH_32728850_118_240 WMBUS b294468505088723276F050E7A0009F1F34200008342000802C000505EA01006BA1007CB2008DC3009ED4000FE50096BA86CE
2016-01-25 10:24:25 Global global UNDEFINED WMBUS_TCH_32430700_118_240 WMBUS b294468500007433276F07D7DA0009F1F33200008332003802C00020511A7006BA1007CB2008DC3009ED4000FE50096BA8ACE
2016-01-25 10:24:37 Global global UNDEFINED WMBUS_TCH_30825883_118_240 WMBUS b294468508358823076F08873A0009F1F35200008352000802C05010525475AD440007CB2008DC3009ED4000FE5006E4980D6
2016-01-25 10:24:48 Global global UNDEFINED WMBUS_TCH_32430687_118_240 WMBUS b294468508706433276F08A24A0009F1F35200008352000802C00010511EA006BA1007CB2008DC3009ED4000FE50096BA81D1
2016-01-25 10:25:02 Global global UNDEFINED WMBUS_TCH_32430850_118_240 WMBUS b294468505008433276F02B87A0009F1F33200008332000802C0004052E40006BA1007CB2008DC3009ED4000FE50096BA83CD
2016-01-25 10:25:02 Global global UNDEFINED WMBUS_TCH_33032831_118_240 WMBUS b294468503128033376F01951A0009F1F32200008322000802C000305F5A6006BA1007CB2008DC3009ED4000FE50096BA8CCC
2016-01-25 10:25:21 Global global UNDEFINED WMBUS_TCH_31422257_118_240 WMBUS b294468505722423176F03136A0009F1F33200008332000802C0004052E40006BA1007CB2008DC3009ED4000FE50096BA80DF

Ein neuer Typ? Oder ist da noch was falsch eingestellt bei mir?

Gruß,
Zusch

[herrmannj]

Hi

Das sind Rauchmelder. Da kannst du dich dem Rauchmelder thread anschliessen (sufu pls)

Wenn du noch was anderes erwartest und da nix kommt, poste mal ein list auf dem cul und auf ein device

Vg
Joerg

[Zusch]

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 Erweitern


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)


Hmm. Bei mir reicht das nicht. Da kommt dann "Unknown Message OFF" und der CUL stellt wohl das Senden ein. Fhem versucht immer mit FHZ xmit <Hauscode> den FHT zu kontakten, aber es kommen nur actuator-readings zurück als ob der FHT nichts hört. Ich probiers mal mit Resetten des CUL nach dem Wechsel auf SlowRF.

Gruß,
Zusch

[Zusch]

Hi

Das sind Rauchmelder. Da kannst du dich dem Rauchmelder thread anschliessen (sufu pls)

Wenn du noch was anderes erwartest und da nix kommt, poste mal ein list auf dem cul und auf ein device

Vg
Joerg

Rauchmelder? Das sind nicht meine. Könnten von der Polizeiwache nebenan sein. Wie verhindere ich das die mir das Log vollspammen?

Gruß,
Zusch

[herrmannj]

Hast de denn techem? Welche?

Vg
Joerg

[Zusch]

Hast de denn techem? Welche?

Vg
Joerg

Hier hängen ganz billige Rauchmelder aus dem Baumarkt. Von Techem sind hier nur die HKV. Zumindest in meiner Wohnung.

[herrmannj]

Und kannst du die korrekt empfangen ?

Die rauchmelder sind keine fehlermeldung. Gibt halt noch kein modul was die lesen kann, kommt aber

Vg
Joerg

[gandy]

Hallo Jörg,

hatte wieder eine Serie von Abstürzen, bin aber weitergekommen, was das Eingrenzen des Problems anbelangt. Der Absturz kam nun an der Stelle, wo in Deinem Workaround $index belegt wird:

Code Auswählen Erweitern


$index = int(@{$hash->{CHANGED}}) -1;

Wenn ich $index mit -2 vorbelege und die Zeile jeweils in

Code Auswählen Erweitern


$index = int(@{$hash->{CHANGED}}) -1 if (defined $hash->{CHANGED});

dann sind die Abstürze Geschichte, dafür hagelt es das Log zu mit Meldungen der Art

Code Auswählen Erweitern


2016.01.25 20:33:25.959 0: new_cnt_14113583: index failed (meter) -2
2016.01.25 20:33:25.961 0: new_cnt_14113583: index failed (current_period) -2
2016.01.25 20:33:25.968 0: wz_Heizung: index failed (meter) -2
2016.01.25 20:33:25.969 0: wz_Heizung: index failed (current_period) -2
2016.01.25 20:33:26.396 0: wz_Bad_kalt: index failed (meter) -2
2016.01.25 20:33:26.397 0: wz_Bad_kalt: index failed (current_period) -2
2016.01.25 20:33:26.951 0: new_cnt_14113569: index failed (meter) -2
2016.01.25 20:33:26.952 0: new_cnt_14113569: index failed (current_period) -2
2016.01.25 20:33:30.936 0: new_cnt_20457190: index failed (meter) -2
2016.01.25 20:33:30.937 0: new_cnt_20457190: index failed (current_period) -2

(Um nicht so lange auf Ergebnisse warten zu müssen, habe ich vorübergehend die Abfrage auf "$ats ne $ts" deaktiviert)

Inzwischen habe ich mein Perl auf v5.22.1 aktualisiert, das Fehlerbild hat sich dadurch nicht verändert.

Und während ich das hier schreibe, beobachte ich etwas recht interessantes: Alle Devices habe ich mit Attribut "event-on-change-reading .+" versehen. In dem Moment, wo ich dieses Attribut bei einem Device entferne, ändern sich im Log die Einträge zu

Code Auswählen Erweitern


2016.01.25 20:45:08.499 0: wz_Heizung: index (meter) is 0, cti is -2
2016.01.25 20:45:08.501 0: wz_Heizung: index (priod) is 1, cti is -2

was mir anzeigt, dass $hash->{CHANGED} definiert ist und der Code durchlaufen würde. Sobald ich das Attribut wieder setze, ist der Fehler wieder da.

Nun würde ich sagen man müsste eine Prüfung einbauen, ob $hash->{CHANGED} definiert ist. Einerseits wird so etwas in keinem anderen Modul gemacht, was andererseits verständlich ist, weil am Ende von readingsBeginUpdate()

Code Auswählen Erweitern


$hash->{CHANGED}= () if(!defined($hash->{CHANGED}));

steht. Damit sollte $hash->{CHANGED} an der fraglichen Stelle auf jeden Fall definiert sein. Bin also weiter ratlos...

Grüße,
Andy.

[herrmannj]

Hi Andy,

Nun würde ich sagen man müsste eine Prüfung einbauen, ob $hash->{CHANGED} definiert ist. Einerseits wird so etwas in keinem anderen Modul gemacht, was andererseits verständlich ist, weil am Ende von readingsBeginUpdate()
Code: [Auswählen]

$hash->{CHANGED}= () if(!defined($hash->{CHANGED}));

steht. Damit sollte $hash->{CHANGED} an der fraglichen Stelle auf jeden Fall definiert sein. Bin also weiter ratlos...

Doch, das passt. Ich hatte event-on auch schon in Verdacht, habe mich aber durch eine anderslautende Meinung davon abbringen lassen.

Ich vermute aber das es tatsächlich der Schlüssel ist. Das mit $hash->{CHANGETIME} wird derzeit meines Wissens nach von keinem Modul richtig (sprich funktionierend) eingesetzt, von daher passt das schon.

Hier ist nicht die Frage ob $hash->{CHANGED} existiert - das tut es. Es wird aber nicht mit Inhalt betankt wenn das "richtige" event-on greift und ist dann leer. Daher knallt es. Ist also auch kein Perl Problem. Die Konstuktion des index war vorher auch für perl ok.

So müsste es dann richtig mMn laufen:
(wenn kein event produziert wird dann wird ohnehin nichts geloggt und CHANGETIME gilt nur fürs log)

Code Auswählen Erweitern


  if ($ats ne $ts) {
    my $i;
    readingsBeginUpdate($hash);
    $hash->{".updateTimestamp"} = $ts;

    $i = $#{ $hash->{CHANGED} };
    readingsBulkUpdate($hash, "meter", $msg->{meter});
    $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts if ($#{ $hash->{CHANGED} } != $i ); # only add ts if there is a event to

    $i = $#{ $hash->{CHANGED} };
    readingsBulkUpdate($hash, "current_period", $msg->{actualVal});
    $hash->{CHANGETIME}->[$#{ $hash->{CHANGED} }] = $ts if ($#{ $hash->{CHANGED} } != $i );

    readingsEndUpdate($hash, 1);
  }

So wird für jeden einzelnen Eintrag geprüft ob er an event-on " vorbeikommt. Wenn ja bekommt er den timestamp denn dann ist (theoretisch $hash->{CHANGED}->() je belegt. Wenn CHANGED vor UND nach dem update gleichlang ist passiert nix. Dadurch gibt es auch keine negativen indizies mehr CHANGED leer ist.

Das müsste dann passen.


vg
joerg

[Zusch]

Und kannst du die korrekt empfangen ?

Die rauchmelder sind keine fehlermeldung. Gibt halt noch kein modul was die lesen kann, kommt aber

Vg
Joerg

Die HKV scheinen alle korrekt gelesen zu werden. Insgesamt 34 hab ich entdeckt. Nur das Zurückschalten nach SlowRF macht Probleme (siehe weiter oben). Ich probiere mal Verschiedenes aus und berichte dann. Zu den Rauchmeldern kann ich nur die Readings oben beisteuern, weil die wahrscheinlich nicht hier im Haus sind, zumindest aber nicht in meiner Wohnung. Wenn ich noch was liefern kann... gern.

Gruß,
Zusch

[herrmannj]

Na dann passt das. Für die Rauchmelder auf das Modul warten. Das schluckt die nachbar device dann sind die aus dem log.

Vg
Joerg

[pechnase]

Hallo,

wie weiter oben in einem Beitrag beschrieben, beendet sich bei mir fhem in etwa immer zum gleichen Zeitpunkt Nachts gegen 23:55Uhr, seit einem fhem Update am 23.01.2016. Ich verwende auch die Module TechemHKV (ca. 56 Stück) und TechemWZ (27 Stück). Ich konnte mir zunächst keinen Reim auf die Ursache der 'Abstürze' machen, bin dann über diesen Thread auf die Diskussion in den letzten Beiträgen gestoßen. Bei mir steht im fhem-log zu der 'Problemzeit' ein Eintrag nach folgendem Muster:

Code Auswählen Erweitern


2016.01.25 23:58:07 3: telnetForBlockingFn_1453762687: port 36309 opened
Modification of non-creatable array value attempted, subscript -1 at ./FHEM/32_TechemHKV.pm line 139.

Da ich bis jetzt bei der Ursache für die Abstürze im Dunklen getappt bin, habe ich mir gestern Abend noch ein kleines Script gebastelt, das über einen cronjob alle Minute prüft, ob fhem noch läuft und falls nicht, fhem neu startet. Das hatte auch die Wirkung, dass fhem heute Nacht wieder gestartet wurde und heute Morgen noch lief.

Ich werde die von Jörg vorgeschlagene Änderung im Modul TechemHKV einbauen und prüfen, ob damit die Neustarts von fhem weg sind.

Viele Grüße
Wolfgang

[gandy]

Hallo Jörg,

Danke, dein letzter Ansatz löst das Problem, kein Absturz mehr seit gestern Abend.

Für alle anderen: Bis Jörg wieder von seiner Reise zurück ist, kann ich die gepachte Version hier posten,  falls erwünscht, komme aber erst heute Abend dazu.

Viele Grüße,
Andy.

[pechnase]

Hallo Andy,

ich wäre an der gepachten Version interessiert. Danke.

Viele Grüße
Wolfgang