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

Begonnen von herrmannj, 14 Oktober 2015, 02:34:36

Vorheriges Thema - Nächstes Thema

herrmannj

komisch. Scheint bei virscer ähnlich zu sein. Naja, egal aus welchem log wir die rausholen. Hauptsache haben :)

Danke und vg joerg

JanWittke

Nochmal kurz zu den HKV .

Mir ist aufgefallen das meine HKV´s alle schon ein Jahr weiter sind bei den current_period Werten.

Ist das bei anderen auch so?


Gruß Jan

Ps. Habe mir eben nochmal die alte Techemabrechnung vorgenommen. Techem rechnet bei den Wasserzählern bis 1 Stelle nach dem Komma.
Beispiel 76,100 oder der andere Zähler 246,600

Nur so am Rande falls von Interesse  ;)

herrmannj

Nein, ist nur bei Dir so :-)

Allerdings trifft mich da die Fehlinterpretation eines einzelnen bits. Mach ich heil. Und das Datum muss ich zweistellig machen - seh ich.

vg
joerg

herrmannj

Ps. Habe mir eben nochmal die alte Techemabrechnung vorgenommen. Techem rechnet bei den Wasserzählern bis 1 Stelle nach dem Komma.
Beispiel 76,100 oder der andere Zähler 246,600


Oh Danke. Beinahe überlesen. Allerdings liegt es (leider) doch im Rahmen des möglichen das Techem so wie oben beschrieben arbeitet. (Nur Arbeitshypothese!!!):

Nimm den Zähler vom Hauptanschluss, addiere alle Wasseruhren (Integer) und teile das dann den Gesamtverbrauch im Verhältnis. Das ergibt Nachkommastellen auf der Abrechnung.

Leider deutet im Augenblick alles darauf hin. Endgültig kann ich das hoffentlich mit Deinem log klären. Danke dafür

vg
joerg


herrmannj

#64
so, dann mal ein update.

@Jan: danke für das Techem pdf, das war aber Montageanleitung.

Protokoll ist (für die logs: Danke) damit soweit klar.

* Der Sendeintervall ist fix: ca 4min
* Es werden nur volle m3 übertragen (wtf ??)
* Die Wert wird nur mit dem Tageswechsel aktualisiert
* Die Historie (jeweils 14 Tage) ist vollständig und schlüssig mit dem kumulierten Verbrauch
* die ID ist die des Radiomoduls, nicht des Zählers.

Insgesamt schon irgendwie, hmmm, "eigenartig" von Techem gelöst.

Unklar sind noch 2 bytes, die sind fix und ohne was sichtbares. Mag Battery und Sabotage sein.

Das mit der ID ist doof, da wird nur der Weg über autocreate gehen und dann muss man sich von den angelegten halt den richtigen aussuchen. Da der Wert nur einmal am Tag aktualisiert wird muss man da schauen das man den richtigen erwischt (weil auf der EInheit schon mehr stehen wird). Da geht aber nix anderes.

Die Auflösung auf 1000L Genauigkeit finde ich, in Anbetracht von Eichgesetz und co, eigentlich auch eher grenzwertig. Na gut, ist halt so.

Ich stricke das mal in modulform, wird aber vmtl erst nach dem WE

Danke und Grüße
Joerg

edith: irgendwie hab ich mich da auch selber gebremst weil ich die ganze Zeit versucht habe da einen Wert mit Nachkommastellen zu finden. Hätte man das von Anfang an gewusst... Naja ..

stromer-12

Die Stadtwerke wollen bei mir auch nur volle Kubikmeterangaben bei der Zählerablesung haben.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

JanWittke

Freut mich das ich mit meinem Log helfen konnte.
So nun werde ich erstmal wieder alles auf normal stellen. Interessanterweise merkt man jetzt erst wie sehr man sich an Fhem gewöhnt hat.
Es hatte ja bei mir jetzt 2 Tage andere " Aufgaben" zu erfüllen gehabt ;D .

Wenn das Modul fertig ist , werde ich es gerne testen bzw. auch anwenden.  Ich werde versuchen dann zum Tageswechsel den COC für eine halbe oder wenn auch nötig für eine volle Stunde in den anderen Mode versetzen zu lassen.

Ein schönes Wochenende noch

Jan


herrmannj

ZitatFreut mich das ich mit meinem Log helfen konnte.
Danke :)

Zitath werde versuchen dann zum Tageswechsel den COC für eine halbe oder wenn auch nötig für eine volle Stunde in den anderen Mode versetzen zu lassen.
Das sollte reichen. Kommen ja eh nur einmal täglich neue Werte.

ZitatDie Stadtwerke wollen bei mir auch nur volle Kubikmeterangaben bei der Zählerablesung haben.
Trotzdem irgendwie ärgerlich. Da hätte man eigentlich eine Datenquelle die mehr hergeben würde ... Aber hast schon recht. Ist halt für die Abrechnung designed und nicht für und fhemler. ;-)

Schönes WE zurück, vg
Jörg

Yogi221

Hallo,
ich finde Eure Analysen und Scripte super und habe das Modul 32_TechemHKV gleich genutzt, um meine Zähler auszuwerten.

Folgende Zähler habe ich:
1x techem compact V               Gerätekennung im Raw: 4543   CI:A1
2x techem data Kaltwasserzähler   Gerätekennung im Raw: 7072   CI:A0
2x techem data Warmwasserzähler   Gerätekennung im Raw: 7062   CI:A0

Damit musste ich den match-String in 32_TechemHKV.pm anpassen
$hash->{Match}      = "^b..446850[\\d]{8}(6980|4543|7062|7072)....A(0|1).*";

Das Ergebnis passt perfekt mit der Anzeige am Zähler und der Abrechnung zusammen.

Allgemeine Interpretationen:
previous_period ist der Gesamt-Wert vom letzten (als Timestamp angezeigten) Ablesezeitpunkt.
current_period ist der seit dem letzten Ablesezeitpunkt dazugekommene Wert.
Der aktuell am Zähler angezeigte Gesamt-Wert ist zuverlässig die Summe aus beidem.

Zählerbezogene Interpretation:
compact V: Werte sind direkte Kilowattstunden.
Wasserzähler: Werte/10 sind Kubikmeter, d.h. die Werte haben 1 Nachkommastelle.

Die Werte werden einmal pro Tag aktualisiert.
Die temp1- und temp2-Readings kann ich zu nichts zuordnen.
Die Zähler-IDs der Wasserzähler stimmmen auch bei mir nicht mit der aufgedruckten Nummer überein.



herrmannj

He, sehr cool!

TechemWZ ist auch schon einige Tage fertig, ich wollte das nur nochmal simulieren und Doku schreiben. Schön!

Bei den WZ doch eine Nachkommastelle ? Noch besser. Mal schauen, vielleicht bekomme ichs heute Abend noch fertig.

vg
joerg

herrmannj

hier: http://forum.fhem.de/index.php/topic,43820.0.html gehts weiter !.

Freue mich auf feedback, vielen Dank an alle die Rohdaten geliefert haben !!!

vg
joerg

Gator99

Moin,

danke für die Arbeit. Modul läuft soweit und ich kann von 4 Heizkörpern die Daten lesen.
Zwei kleine Problemchen hätte ich noch, vielleicht hat das ja noch jemand:

1) Ich möchte die readings des HKV in ein Log schreiben. leider erscheinen im Log (und auch im Event Monitor) nur die Temeperaturen. Nicht die current_period.
Hab ich da was falsch gemacht?

2) Gehört wahrscheinlich nicht hier hin, tritt aber in Verbindung auf: Wenn ich meinen CUL (USB868) nach der Verwendung im WM-Bus modus mit attr wieder in slowRF bringe funktioniert die schaltung von IT nicht mehr. erst wenn ich den CUL resette (set CUL raw e) gehts wieder....hat das noch jemand?


Schonmal Danke fürs lesen und einen schönen Tag noch!
FHEM auf Raspi mit:
MAX! CUN - Busware CUL - MiLight Wifi LED - Brennenstuhl FunkDosen - Brennenstuhl Remote - Techem HKV und Wasserzähler - IR MCE Remote - Enigma2 VUUno - Kodi FireTV Stick - Sprachausgabe

herrmannj

Hi,

zu 1: die current_period wird nur einmal am Tag aktualisiert. Die macht schon events, eben jeweils eines pro Tag.
zu 2: ich habe einen eigenen CUL dafür genommen, daher nein aber ich habe es schon gehört. "raw e" ist eine gute Lösung.

vg
joerg

Gator99

danke für die schnelle Antwort.
Dazu noch eine Rückfrage:

Ist es so zu verstehen das der Wert für den aktuellen Verbrauch nur ein mal am Tag durch die Luft fliegt?
Das kann ich kaum glauben, denn ich habe jetzt zu Testzwecken entsprechende HKV angelegt und wieder gelöscht...also mit leeren Devices ohne Reading gestartet.
Doch spätestens nach ca 5 Minuten waren alle Werte in den Readings zu finden, auch die Current_period.

Oder habe ich da was falsch verstanden?

Gruss
FHEM auf Raspi mit:
MAX! CUN - Busware CUL - MiLight Wifi LED - Brennenstuhl FunkDosen - Brennenstuhl Remote - Techem HKV und Wasserzähler - IR MCE Remote - Enigma2 VUUno - Kodi FireTV Stick - Sprachausgabe

herrmannj

Richtig. Der Wert fliegt öfter durch die Luft. Im Modul wird er aber einmal pro Tag (das erste mal wenn er empfangen wird) aktualisiert.

Das Modul löst also genau 1 event "current_period" pro Tag aus.

vg
joerg