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

[herrmannj]

Hallo zusammen,

passend zum Beginn der Heizperiode ein modul um Techem HKV mit FHEM auszuwerten.
http://www.techem.de/fileadmin/de/pdf/techem.de/Landingpages/Mieter/Mieterinfo_Heizkostenverteiler.pdf

Benötigt wird ein CUL im WMBUS_T mode (Dank an tostmann). Der CUL kann auch zeitweise im WMBUS_T mode laufen und sonst andere device bedienen. Der Zeitraum (vmtl. Nachts nach Mitternacht) sollte dann ausreichend lang sein um alle HKV einmal zu empfangen.

Auf dem Display des HKV finden sich 3 Zahlen:
- Gerätenummer (kleines "n")
- Ablesewert Vorjahr ("Stift" Symbol)
- aktueller Verbrauch

Für jeweils einen Zähler muss ein device manuell angelegt werden.
- Gerätenummer notieren (4 Ziffern am HKV ablesen oder 8 stelliger Code aus der letzten Abrechnung):
- definieren:

Code Auswählen Erweitern

define <name> TechemHKV <Gerätenummer> [sprechender Name]}
[sprechender Name] ist optional und wird in den internals geführt.

Übertragen und von FHEM empfangen werden
- Ablesewert Vorjahr (inkl Ablesedatum)
- aktueller Verbrauch (Vortag, kumuliert)
- beide Temperatursensoren (laufend)

Das Sende Intervall der HKV variiert zwischen 2..20 Minuten.

Im Tagesverlauf integriert der HKV den Verbrauch intern (Anzeige läuft mit). Im Funktelegramm nur auf Tagesbasis übermittelt.

Der interessante Teil des Funktelegramms ist damit zugänglich.

Es gibt noch zwei Blöcke sowie ein bit mit unbekannten Funktionen. Die beiden Blöcke sind jedoch uninteressant da statisch. Ich vermute eine Seriennummer (die Gerätenummer ist programmierbar).

Das einzelne bit kommt direkt nach dem CI Feld (A0). In den meisten Fällen ist es gesetzt, in seltenen Fällen ist es jedoch auch clear, sonst keine Auswirkung. Evtl geht der HKV dann vom Zweifühlerbetrieb in den EInfühlerbetrieb.

Die beiden Temperaturen gehören zur Differenzmessung, also einmal am HK und einmal Umgebung. Der HKV "schätzt" den Verbrauch anhand der Differenz. Aus akademischem Interesse könnte man evtl noch  versuchen das Rechenmodell nachzubilden, vielleicht hat da auch jemand Infos.

Zum loggen empfiehlt sich "current_period" der einmal täglich aktualisiert wird.

feedback welcome

vg
joerg

[kaihs]

Ich vermute das WMBUS Modul konnte das nicht verarbeiten, weil das CI-Field A0 nicht unterstützt wird, oder?

Es ist sehr interessant, dass du das Format jetzt decodieren konntest. Ich würde das gerne als ins WMBUS Modul einbauen, wäre das okay?
Hast du ein paar Rohnachrichten wie sie vom CUL kommen die du mir zur Verfügung stellen könntest?

[herrmannj]

Hi,

genau (A0). Wobei meine Interpretation ohnehin die wäre das jeder Hersteller den Application Layer sowieso individuell bedient.

Manchmal ist ja auch das "behind the scenes" ganz unterhaltsam:

Ich habe am Sonntag Abend meinen CUL, der eigentlich keine device mehr bedient, spaßeshalber mit der aktuellen FW betankt. Da war eine 1.4er drauf. Danach hab ich WMBUS getestet und war erstaunt was zu bekommen, die Techem. Obwohl wir nur echt wenige Parteien sind kommt da schon ganz gut was zusammen. Nach kurzer Recherche hab ich dann harryzz von 2014 gefunden (http://forum.fhem.de/index.php?topic=27018.0). An ihn gehen credits, seine ersten Schritte waren richtig und ein guter Startpunkt. Darauf aufbauend konnte ich den Rest des Protokolls dann Stück für Stück dekodieren.

Ich wollte Dir das dann auch schon geben, hab aber dann Mo/Di das modul als POC geschrieben. Mittlerweile denke ich aber fast das es die Aufgabe halt sehr schlank, speziell und so gut löst und der code kaum für andere WMBUS Geräte wiederverwendbar ist das ich es so lassen wollte.  Läuft auch super rund.

Das modul habe ich gestern auf Co-Existenz angelegt, das soll sich nur die Techem HKV Pakete rausfischen und den Rest an Dich durchwinken. Kannst Dich aber natürlich gern bedienen, jederzeit.  Die relevanten Felder siehst Du ja im code.

vg
joerg

[kaihs]

Nach einem ersten Blick auf die Codierung hast du wohl recht. Das hat nichts mit der normalen WMBUS Codierung zu tun.

Allerdings greift sich dein Modul jetzt alle Techem Geräte ab, auch solche die mglw. ein WMBUS Standard konformes Format haben.
Besser wäre wahrscheinlich

Code Auswählen Erweitern


$hash->{Match} = "^b....6850.*";

in

Code Auswählen Erweitern


$hash->{Match} = "^b..446850..80....A0.*";
 
zu ändern.

Dadurch wird dann auch der Gerätetype und das CI-Feld erfasst.

Das WMBUS Modul würde noch eine zusätzliche Längen und CRC-Prüfung bieten, aber das passiert in Prinzip auch schon in der culfw.

[herrmannj]

Ah, gute Idee. Den Match bau ich um.

CRC könnte man noch, zumindest für den Header und das erste Application field. Die culfw prüft die gesamte msg ? Würde reichen.

vg
joerg

[herrmannj]

wofür steht die 80 denn ? btw, davor steht immer eine 69.

Könnte man so oder ?

Code Auswählen Erweitern

"^b..446850[.]{8}6980....A0.*"

vg
edith: (besser)

Code Auswählen Erweitern

"^b..446850[\d]{8}6980....A0.*"

[kaihs]

Der 16-Bit CRC ist pro Block, d.h. das erste Mal nach 10 Bytes und dann alle 16 Bytes.
Das wird auch so von der culfw geprüft und nicht passende Pakete verworfen.
Die Länge des gesamten Pakets steht im ersten Byte, das Längenbyte selbst und die CRCs werden nicht mitgezählt.

Allerdings kann es sein, dass ein Paket zu lang für den Standardausgabepuffer der culfw ist, das wird dann einfach stillschweigend abgeschnitten.
Das bekommt man dann nur durch die Längen- und/oder CRC Prüfung mit.

80 ist der Gerätetype, laut Standard steht das für 'Sonstiges'.
Die 69 davor ist die Version des Geräts, kann der Hersteller selber festlegen.

[herrmannj]

ahh, gut zu wissen. Das passt.

Dann baue ich noch einen Längencheck ein und bin sicher.

Ich würde die 69 mit in die regex nehmen. Sollten irgendwo auf dem Markt Pakete mit abweichender Versionsnummer auftauchen würden die erst mal an WMBUS durch-gereicht. Dann können wir ja schauen ob und wozu die msg dann passt. OK ?

Danke und Grüße
Jörg

[kaihs]

Ja, das hört sich gut an.

[Invers]

Wäre echt begeistert, wenn das bei mire ginge. Leider kann ich nicht definieren, weil die Def.:

Code Auswählen Erweitern

define WohnzimmerRohr TechemHKV 60964814
mit dem Hinweis abgelehnt wird, dass 4 oder 8 Stellen erwartet werden.
Es sind ja aber doch 8. Was kann ich tun?

Danke im Voraus.

[herrmannj]

Hi,

"4814" ist die ID die am HKV angezeigt wird ?

Wenn ja, nimm mal

Code Auswählen Erweitern

define WohnzimmerRohr TechemHKV 4814

Ich muss gestehen das ich nur die 4 stellige def getestet habe, kann sein das die regex buggy ist. Vierstellig geht genauso, der holt die komplette ID selbst aus dem HKV

vg
joerg

[Invers]

Ok, danke. Jetzt steht "listening" da. Scheint also zu gehen (theoretisch) Nun muss ich nur mal sehen, ob ich mit dem umgeschalteten CUL 868 etwas empfange. Kann sein, dass meine Geräte von einer anderen Firma sind. Muss ich mir bei Tageslicht ansehen.
Erst einmal vielen Dank.

[herrmannj]

Hi,

das mit den 8 Digits mach ich heil.

Techem müssen es schon sein. Wenn innerhalb einer Stunde nix kommt ist es ein anderer Hersteller.

vg
joerg

[Invers]

Ja, schade! Mein Hersteller ist ARES. Heul.
Danke.

[herrmannj]

match auf Techem HKV begrenzt und eingecheckt.

vg
joerg