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

[mircoby]

Hi Bolligru, Jörg,

bin gerade noch am kämpfen mit den Logs. Das klappt noch nicht wirklich.

Im listen-mode werden viele Zähler empfangen, es kommen nahezu sekündlich Pakete. (Verwundert mich etwas, da ich gar nicht so viele Zähler in der näher Erwartet hätte...)

Das Empfangen im list-mode scheint zu klappen, die Zähler zählen hoch. Definiere ich allerdings den Zähler im normalen Modus, zählt dieser nicht hoch (zumindest nicht die Wärmemengenzähler.

Beispiel: "WMZ_oben" hatte gestern abend den Wert 5571, heute abend immer noch. Schaue ich in den ListenerModus, steht dieser aktuell bei 5636. So wie ich es verstehe, wird 1x täglich, sobald der Erste Zählerstand empfangen wird, aktualisiert!? Nachdem sehr oft empfangen wird, würde ich das Update kurz nach mitternacht erwarten!?

Ein WWZ und ein KWZ wurden seit gestern abend um 0.1 hochgezählt.

Das Logfile ist aktuell noch sehr übersichtlich:

2016-01-07_10:19:24 KWZ_WM_OG_li listening
2016-01-07_10:19:24 KWZ_WM_OG_re listening
2016-01-07_10:19:24 KWZ_oben listening
2016-01-07_10:19:24 KWZ_unten listening
2016-01-07_10:19:24 WMZ_debug listening
2016-01-07_10:19:24 WMZ_oben listening
2016-01-07_10:19:24 WMZ_unten listening
2016-01-07_10:19:24 WWZ_oben listening
2016-01-07_10:19:24 WWZ_oben2 listening
2016-01-07_10:19:24 WWZ_unten listening
2016-01-07_10:21:38 KWZ_WM_OG_li listening
2016-01-07_10:21:38 KWZ_WM_OG_re listening
2016-01-07_10:21:38 KWZ_oben listening
2016-01-07_10:21:38 KWZ_unten listening
2016-01-07_10:21:38 WMZ_debug listening
2016-01-07_10:21:38 WMZ_oben listening
2016-01-07_10:21:38 WMZ_unten listening
2016-01-07_10:21:38 WWZ_oben listening
2016-01-07_10:21:38 WWZ_oben2 listening
2016-01-07_10:21:38 WWZ_unten listening
2016-01-08_14:56:57 KWZ_WM_OG_li listening
2016-01-08_14:56:57 KWZ_WM_OG_re listening
2016-01-08_14:56:57 KWZ_oben listening
2016-01-08_14:56:57 KWZ_unten listening
2016-01-08_14:56:57 WMZ_debug listening
2016-01-08_14:56:57 WMZ_oben listening
2016-01-08_14:56:57 WMZ_unten listening
2016-01-08_14:56:57 WWZ_oben listening
2016-01-08_14:56:57 WWZ_oben2 listening
2016-01-08_14:56:57 WWZ_unten listening
2016-01-08_19:12:28 KWZ_WM_OG_li listening
2016-01-08_19:12:28 KWZ_WM_OG_re listening
2016-01-08_19:12:28 KWZ_oben listening
2016-01-08_19:12:28 KWZ_unten listening
2016-01-08_19:12:28 WMZ_debug listening
2016-01-08_19:12:28 WMZ_oben listening
2016-01-08_19:12:28 WMZ_unten listening
2016-01-08_19:12:28 WWZ_oben listening
2016-01-08_19:12:28 WWZ_oben2 listening
2016-01-08_19:12:28 WWZ_unten listening
2016-01-09_20:48:42 KWZ_WM_OG_li listening
2016-01-09_20:48:42 KWZ_WM_OG_re listening
2016-01-09_20:48:42 KWZ_oben listening
2016-01-09_20:48:42 KWZ_unten listening
2016-01-09_20:48:42 WMZ_debug listening
2016-01-09_20:48:42 WMZ_oben listening
2016-01-09_20:48:42 WMZ_unten listening
2016-01-09_20:48:42 WWZ_oben listening
2016-01-09_20:48:42 WWZ_oben2 listening
2016-01-09_20:48:42 WWZ_unten listening
2016-01-09_20:59:56 KWZ_WM_OG_li listening
2016-01-09_20:59:56 KWZ_WM_OG_re listening
2016-01-09_20:59:56 KWZ_oben listening
2016-01-09_20:59:56 KWZ_unten listening
2016-01-09_20:59:56 WMZ_debug listening
2016-01-09_20:59:56 WMZ_oben listening
2016-01-09_20:59:56 WMZ_unten listening
2016-01-09_20:59:56 WWZ_oben listening
2016-01-09_20:59:56 WWZ_oben2 listening
2016-01-09_20:59:56 WWZ_unten listening
2016-01-09_21:04:08 techem_log removeRegexpPart KWZ_unten:state:.*
2016-01-09_22:31:45 KWZ_unten meter: 39.4
2016-01-09_22:31:45 KWZ_unten current_period: 0.6
2016-01-09_22:34:30 KWZ_WM_OG_re meter: 0.1
2016-01-09_22:34:30 KWZ_WM_OG_re current_period: 0
2016-01-09_22:49:19 KWZ_WM_OG_li listening
2016-01-09_22:49:19 KWZ_WM_OG_re listening
2016-01-09_22:49:19 KWZ_oben listening
2016-01-09_22:49:19 KWZ_unten listening
2016-01-09_22:49:19 WMZ_debug listening
2016-01-09_22:49:19 WMZ_oben listening
2016-01-09_22:49:19 WMZ_unten listening
2016-01-09_22:49:19 WWZ_oben listening
2016-01-09_22:49:19 WWZ_oben2 listening
2016-01-09_22:49:19 WWZ_unten listening
2016-01-09_23:07:33 KWZ_oben meter: 29.6
2016-01-09_23:07:33 KWZ_oben current_period: 0.8
2016-01-09_23:38:09 WWZ_oben meter: 4.9
2016-01-09_23:38:09 WWZ_oben current_period: 0.2
2016-01-09_23:45:50 WWZ_unten meter: 23.6
2016-01-09_23:45:50 WWZ_unten current_period: 0.6
2016-01-09_23:56:16 KWZ_WM_OG_li meter: 0.1
2016-01-09_23:56:16 KWZ_WM_OG_li current_period: 0
2016-01-09_23:58:34 WWZ_oben2 meter: 4.9
2016-01-09_23:58:34 WWZ_oben2 current_period: 0.1

Die Definition sieht aktuell so aus:

define techem_log FileLog ./log/techem-%Y-%m.log KWZ_WM_OG_li:.*|KWZ_WM_OG_re:.*|KWZ_oben:.*|KWZ_unten:.*|KWZ_unten:state:.*|WMZ_debug:.*|WMZ_oben:.*|WMZ_unten:.*|WWZ_oben2:.*|WWZ_oben:.*|WWZ_unten:.*

Idee woran das liegen könnte?

Gruß Mirko

[herrmannj]

such Dir mal bitte *EINEN* aus, kopieren *HEUTE* die RAW (detail, inetrnals) und die beiden Werte current_period und previous_period.
Das gleiche dann bitte *MORGEN* nochmal-

Entweder als pm oder (schöner) hier als Post dann alles zu mir

Danke vg
Joerg

[mircoby]

"HEUTE"

Internals
CFGFN   ./config/techem.cfg
CUL_WMBUS_MSGCNT  2261
CUL_WMBUS_RAWMSG  b364468501081015045438837A1009F1FD31400083101000015132AA80B641C64DB1BBA64614101000400000009083C48A04105101C92CA4635CD47E179B47730::-35.5
CUL_WMBUS_RSSI  -35.5
CUL_WMBUS_TIME  2016-01-10 21:41:32
DEF    50018110
ID     50018110
LASTInputDev CUL_WMBUS
METER  heat meter
MSGCNT  2261
NAME WMZ_oben
NR 97
NTFY_ORDER 50-WMZ_oben
STATE 5571
TYPE TechemWZ
VERSION 45

Readings
current_period      240 2016-04-00 00:00:00
meter                5571 2016-04-00 00:00:00
previous_period  5331 2015-12-31 00:00:00
state listening            2016-01-09 22:49:19

Was mir aufgefallen ist, ist das der TimeStamp bei "current_period" und "meter" kaputt ist. (ist bei allen WMZ so, bei WWZ und KZW stehen sinnvolle TimeStamps)

"MORGEN" dann morgen

[herrmannj]

Nun gut.. der WMZ macht das Feld (current date) echt anders.  Dann hat Bolligru doch doch ganz nicht unrecht.

@Bolligru:
der Unterschied ziwschen HKV und Volumen (compact V) ist natürlich klar. Deswegen gibt es das Modul 32_TechemHKV und 32_TechemWZ
WZ sind Volumenzähler (Wasser und Energie -> der Compact V)!

Die msg des Kalt- und Warmwasser und des Compact V haben viele Gemeinsamkeiten, im Modul werden sie aktuell gleich behandelt.

Das current date Feld unterscheidet sich aber. Bolligru hat in seiner Tabelle eine Interpretation aus byte 22/23 vorgeschlagen. Die könnte passen. Bin aber sicher das der Monat noch fehlt (byte 23 7:4 + x?)

Die 14 Tageswerte finden in meinem modul keine Beachtung. Ich vermute das Du (Bolligru) das 27te Feld mit dem Fehler meinst. Lass mal das Feld weg und addiere nur die anderen - dann bist Du genau bei current energie. Das Feld hat keine Bedeutung.

vg
Joerg

Ich beobachte das mal (dazu benötoge ich bitte msg).

[bolligru]

Jörg & Mirko,
danke für die Spätschicht!
Kurz meine Situation: es gibt 20 "private" Zählerobjekte plus einen "offiziellen" Hauptzähler. Die privaten Objekte sind über ein größeres Areal verteilt. Zusätzlich sind die privaten Zähler  "gut abgeschirmt" in Blechgehäusen verbaut. Der  Empfang per CUL endet mehr oder weniger an der Aussenmauer. Das heißt mit ein oder zwei CUL's alle Objekte sicher zu empfangen ist nicht möglich. Eine Infrastruktur z.B. WLAN oder LAN im Areal  gibt es nicht. Damit ist ein Ansatz eines zentralen Erfassungssystems aussen vor. Dazu kommt das die privaten Zähler ad hoc im Wochen bis Monatsabstand ausgelesen werden müssen. Es muß eine tagesgenaue Datenerfassung gewährleistet sein. Die Daten fliessen dann in eine zentrale DB mit entsprechenden Auswerteprozeduren ein. Heute geschieht das Ablesen über eine Android-App auf einem Tablet. Die Zählerstände von Strom und Wasser werden fotografiert. Bei den Wärmezählern funktioniert das wegen dem Hintergrund und der manuellen Bedienung (gelber Knopf) nicht zuverlässig. Auch die  optische Auslesung ist keine Lösung. Diese "Clearing-App" soll nun um eine "walk-by" Lösung per CUL erweitert werden. So dass bei der Erfassung der anderen Verbräuche wie Strom und Wasser im Gebäude auch gleich die von den Wärmezählern gesendeten Verbrauchsdaten erfasst werden. Da die Verrechnung nur innerorganisatorisch erfolgt sind geeichte Zähler usw. kein Thema.
Nun könnte man diese Verrechnungs-Aufgabe ja an einen Dienstleister vergeben. Nur da die infrastrukturelle Betreuung des Projekts "nonprofit" und weitgehend kostenneutral laufen muß ist aus Geld-Gründen gar nicht daran zu denken. Die Anschaffung eines Erfassungsgerätes ist zu teuer und hätte hinten raus wieder das Problem der Datenzusammenführung.
Technisch ist das Ganze kein Problem, wenn man die genaue Datenstruktur der Telegramme kennt. Der Zähler-Hersteller will verständlicher Weise seine Dienstleistung verkaufen und für einen NDA ist der Umfang zu klein. Also = do it yourself!
Nun habe ich eine lebendige Community gesucht die sich mit Engagement diesen Themen annimmt: FHEM. Meine Hoffnung war und ist das ich weitere Informationen über die herstellerspezifische Datenstruktur finde und auch eventuell Datensätze zu Auswertung bekomme.
Das ist ja hier in diesem Forum gegeben. Wie oben geschildert, kann ich FHEM zur Zeit nicht einsetzen, möchte aber gern das Wissen in dem Forum nutzen und teilen.  Mein Beitrag wird kein FHEM-Modul sein können, aber die Ergebnisse zur Datenkodierung und -strukturierung dieses bewussten Herstellers würde ich gern bereitstellen. Bedarf dafür denke ich ist vorhanden. Mein erster Beitrag dazu sollte die Excel-Auswertung sein.

Aus der Situation heraus habe ich keine täglichen Log-Daten, so daß ich auf die Tagesfortschreibung im Zähler nicht verzichten kann.
Dann kommt dazu, dass wegen der Authentizität des Datensatze auf alle Fälle das Datum aus dem Zählersatz verwendet werden muss. Jörg, Du hast genau die richtige Frage gestellt: wo versteckt sich die  Monatsinformation? Sie gibt es bestimmt. Weitere Felder warten auch noch auf Klärung.
Also heißt es einen zusammenhängenden, fortlaufenden Zeitraum an gesammelte Messwerten zu analysieren. Und darum hier meine Frage, besitzt jemand solche Daten und würde er die zur Analyse zur Verfügung stellen? Im Prinzip fallen diese Daten im FHEM als RAW-Daten an. Zur Verifikation besitze ich "offline"-Zähler auf dem Labortisch, bei denen ich alle äusseren Parameter wie Temperatur, Durchfluß, Stichtag usw. manipulieren kann.

So ist es interessant ob es unterschiedliche Firmware-Versionen im Feld gibt. Bisher habe ich bei den Zählern seit Herstellungsjahr 2010 die Version 302.03.01 mit dem CRC C59586 gesehen. Trotzdem gibt es scheinbar funktionelle Unterschiede zwischen den verschiedenen Baujahren, so senden einige Geräte nicht, obwohl UHF = ON angezeigt wird. Hier wäre es interessant per CUL den Ausleseprozess durch einen Dienstleister mitzuschneiden, ob zum Bsp. neuerdings WAKE ON RADIO eingesetzt wird.

Persönlich habe ich Jahrzehnte lange Erfahrung in der Systementwicklung von HW und SW und bin NICHT komerziell tätig.
Ich würde mich freuen wenn es gemeinsam gelingt Licht in die Datenstrukturen und Funktionen dieser Zähler zu bringen.
Es wird und darf auf KEINEN Fall eine kommerzielle Verwendung geben. Allein schon wegen Patentproblemen und ausserdem ist mit dem Hersteller nicht gut Kirschen essen.

Danke für Eure Beiträge!

Bolligru

[herrmannj]

Moin, Moin

Du schaust da etwas anders drauf als ich.

Ich habe die Datensätze der HKV, Wasser (Klat, Warm) der Wärmemengenzähler und der Rauchmelder analysiert.

Bis vor kurzem habe ich die Sätze der Wasseruhren und der Wärmemengenzähler gleich behandelt, scheint nicht exakt richtig zu sein.

Im großen und ganzen sind die raw Daten soweit analysiert das keine großen blinden Flecken sind. Geräte hab ich nicht im Zugriff, bin also auf die Lieferung der Rohdaten angewiesen.

Deine Analyse geht ja in die richtige Richtung. CRC Polynom ist eigentlich immer 0x3D65.
Die ersten 10 byte sind der wmbus Standardheader. Dann kommt die erste CRC, dann jeweils aller 16 byte eine CRC.

Wenn Du Dir dann die Rohdaten von vom Ende aus anschaust sind ja jewels 2 Byte mit dem Verbrauch von 2 Wochen historisch, in Summe ein Jahr. Die addiert geben den Verbrauch im aktuellen Abrechnungszeitraum. Da bleibt genau ein Wert der "über" bleibt (der linke davon). Den ignorieren (ich denke den meinst Du mit Fehler).

Letzter Zeitraum ist auch klar, scheinen dann wirklich 3 Byte zu sein. Tag des Monats (also heute 11) scheint zu passen. Wenn ich über Monat rede suche ich die 1 (für Januar). Der aktuelle Wert ist ja auch klar (ebenfalls vmtl dann 3 Byte).

Die 1 für Januar, die suche ich noch. Ich vermute das die sich in byte 22/23 irgendwo versteckt.

Alles andere sind vmtl Flags (Fehler und Status: Sabotage, Batterie low etc.)

vg
joerg

[bolligru]

Hi Jörg, guten Morgen!

Danke für Deine Antwort, ich hoffe ich halte Dich nicht von einer "geldwerten" Beschäftigung ab!

Im großen und ganzen sind die raw Daten soweit analysiert das keine großen blinden Flecken sind

Ich werde nachher mal meinen Datenbestand analysieren ob ich auch zu konsistenten Ergebnissen komme. Der Normierungsfaktor
bei der Reduktion ist z.B. 4.

bin also auf die Lieferung der Rohdaten angewiesen

30.12:b36446850964408394543F8E6A100811F6C1B00E01C0000000F000700E92450000000000000000000000000000000AE490000000000000000002811D10E7808C95A

31.12:b36446850964408394543F8E6A100811F6C1B00E01C0000800F00070089E050000000000000000000000000000000AE490000000000000000002811D10E7808CB5A

01.01:b36446850964408394543F8E6A100811F6C1B00081C00008000000000A60250000000000000000000000000000000AE490000000000000000002811D10E7808CF5A

02.02:b36446850964408394543F8E6A100811F6C1B00081C00000001000000FDF650000000000000000000000000000000AE490000000000000000002811D10E7808C85A

Das sind die Daten des aktuellen Jahreswechsel 2015 -> 2016 von einem Testzähler.
Was noch sein könnte:  im Byte 19 ein Zähler zum und vom Stichtag aus. Das gäbe ja auch den aktuellen Monat. Weil das Stichtagdatum ist ja ein Fixpunkt im Datensatz. Und sparsam wie der Hersteller ist kann ich mir da eine Lösung vorstellen.
Ich habe einen zweiten Zähler in Beobachtung an dem ich den Stichtag verändert habe und WARTE jetzt auf den kommenden Monatswechsel.
Deswegen wäre eine fortlaufende Messreihe interessant weil man ja schnell rückwärts analysieren kann. Einer meiner Testgeräte läuft ohne Verbrauch damit ich die Datums- und Zeitdatenfelder herausfinde. Zur Analyse lese ich den kompletten Datensatz mit über 400 Byte optisch aus. In diesen Daten findest Du auch die Pufferbereiche für das Funktelegramm usw.

Macht es für Dich Sinn eine aktualisierte Excel-Analyse ins Forum zu stellen?


Gruß Bolligru

edit: sorry der Monat des letzten Datensatzes ist natürlich 01 = Jan!

[herrmannj]

Ich hab ja das HKV und die Wasser formate dekodiert, der Wärmemengenzähler ist da nahezu identisch. Dann sieht man auch wiederkehrende Muster. Sind ja die gleichen devs bei Techem.

Lass mal abgleichen was Du hast.

CRC hast Du ?

In den user daten (a1) stehen das
Datum der letzten Ablesung, (y-m-d)
Der Zählerstand zu dem Zeitpunkt
Das was seid dem verbraucht wurde (alt + Verbrauch = aktuelle Anzeige)

Sowie eine Historie, Verbrauch jeweils 14 Tage, das letzte Jahr.

Das Datum (heute) ist noch gesucht. Normalerweise arbeiten die nicht mit Zählern, die packen die BCD bits mehr oder weniger wild.

Dann gibts noch einige flags (sabotage und co). Mit denen habe ich mich nicht beschäftigt.

Für mich reichen die Daten :
Stichtag
letzter Ablesewert
Heutedatum
Verbrauch seid letzter Ablesung

Hast Du mehr und gehst Du soweit mit ?

vg
joerg

[bolligru]

Jörg, zum Abgleich:

CRC?

ja, nach M-Bus-Formel, tüv't!
Wobei im Gerät die CRC Info scheinbar HW-mäßig gebildet wird. Ich müßte mal die Spec von dem verwendeten Mikroprozessor MPS34F4xx. anschauen. Mir ist was in Errinerung, bin mir aber nicht sicher.

Datum der letzten Ablesung?

ja

Zählerstand zu dem Zeitpunkt

ja

alt + Verbrauch = aktuelle Anzeige

ja

Verbrauch jeweils 14 Tage

ja

Datum (heute)

bin ich dran, wie bekannt

einige flags

nein, sinnvoll aber BAT-LOW m.E. auch für das Log in FHEM

gehst Du soweit mit

ja

Sabotage ist bei den Zählern: Messfühler Vor- Rücklauf vertauscht, verkehrte Fließrichtung
Eine Gehäuseüberwachung habe ich bisher nicht sicher identifizieren können. Kann aber am "gelben Druckknopf" mit hängen.
Auf diese Dinge kann ich auch verzichten. Bei gemieteten Geräten sollte man die Finger von diesen Dingen lassen, generiert nur Ärger!

Allerdings BAT-LOW wäre schon interessant, zumindestens für die Besitzer "privater" Geräte.
Wenn man die Spannungsversorgung stresst schalten die Geräte zeitweise die Schnittstellen ab. Das dürfte auch irgendwo ein Bit setzen.
Hat übrigens schon jemand mal den Akku gewechselt? Was ist nach der Spannungswiederkehr passiert?


Bolligru

[mircoby]

"HEUTE"
Was mir aufgefallen ist, ist das der TimeStamp bei "current_period" und "meter" kaputt ist. (ist bei allen WMZ so, bei WWZ und KZW stehen sinnvolle TimeStamps)

"MORGEN" dann morgen

"MORGEN"...

Internals
CFGFN ./config/techem.cfg
CUL_WMBUS_MSGCNT 4323
CUL_WMBUS_RAWMSG b364468501081015045438837A1009F1FD31400085101008015152AA87AB81C64DB1BBA64614101000400000009083C48A04105101C92CA4635CD47E179B47731::-35.5
CUL_WMBUS_RSSI -35.5
CUL_WMBUS_TIME 2016-01-11 18:20:57
DEF    50018110
ID  50018110
LASTInputDev CUL_WMBUS
METER heat meter
MSGCNT 4323
NAME WMZ_oben
NR 97
NTFY_ORDER 50-WMZ_oben
STATE 5571
TYPE TechemWZ
VERSION 45

Readings
current_period    240 2016-04-00 00:00:00
meter               5571 2016-04-00 00:00:00
previous_period 5331 2015-12-31 00:00:00
state listening           2016-01-09 22:49:19

Der Zählerstand hat sich hier nicht geändert.

Laut Listener sollte der Zählerstand jetzt bei 5668 stehen. Keine weiteren Log Einträge.

[herrmannj]

ist vielleicht so ein doppel ding. Fehler im modul und Datensatz anders.

Stimmte denn der Wert zum Jahreswechsel und was steht heute drauf ?

Code Auswählen Erweitern

b36 44 68501081015045438837 A1 00 9F1F D31400 08 310100 001513 2AA8 0B64 1C64DB1BBA64614101000400000009083C48A04105101C92CA4635CD47E179B47730 10.01
        b36 44 68501081015045438837 A1 00 9F1F D31400 08 510100 801515 2AA8 7AB8 1C64DB1BBA64614101000400000009083C48A04105101C92CA4635CD47E179B47731 11.01
       
vg
joerg

[herrmannj]

Wenn man die user daten ab A1 mit 0 zählt dann kann man

(Monate:)
byte 7 mit den bits 6:3 nehmen.  So wird aus
08 0[000 1]000 -> 01
e0 1[110 0]000 -> 12

(Tagesdatum:)
byte 11 und 12 reverse, bits 11:7
1500 (10.01.)  0001 [0101 0] 000 0000 -> 10
1580 (11.01.)  0001 [0101 1] 000 0000 -> 11
9c00 (24.12.)  1001 [1100 0] 000 0000 -> 24
0c00 (24.12.)  0000 [1100 0] 000 0000 -> 24
0b80 (23.12.)  0000 [1011 1] 000 0000 -> 23

Ist jetzt erstmal für die samples die ich kenne konsistent. Fragt sich warum so kompliziert. Auf der anderen Seite wird ein Techem dev nach vielen Bier sicher eine plausible Erklärung haben.

Mal schauen was das Zählwerk bei Mirco sagt.

bolligru: kannst Du eigentlich Datum Zeit an Deinem sample einstellen ? Sind die ersten vier bit bei byte 12 evtl eine Uhr oder so ?

vg
joerg

[mircoby]

Wenn man die user daten ab A1 mit 0 zählt dann kann man

byte 7 mit den bits 6:3 nehmen.  So wird aus
08 0[000 1]000 -> 01
e0 1[110 0]000 -> 12

byte 11 und 12 reverse, bits 11:7
1500 (10.01.)  0001 [0101 0] 000 0000 -> 10
1580 (11.01.)  0001 [0101 1] 000 0000 -> 11
9c00 (24.12.)  1001 [1100 0] 000 0000 -> 24
0c00 (24.12.)  0000 [1100 0] 000 0000 -> 24
0b80 (23.12.)  0000 [1011 1] 000 0000 -> 23

Ist jetzt erstmal für die samples die ich kenne konsistent. Fragt sich warum so kompliziert. Auf der anderen Seite wird ein Techem dev nach vielen Bier sicher eine plausible Erklärung haben.

Mal schauen was das Zählwerk bei Mirco sagt.

bolligru: kannst Du eigentlich Datum Zeit an Deinem sample einstellen ? Sind die ersten vier bit bei byte 12 evtl eine Uhr oder so ?

vg
joerg

31.12.15:  5331 -> korrekt angezeigt
11.01.16, 20:12 -> 5697 abgelesen

Somit könnte der Stand 5668 (aktuell im Listen mode angezeigt) zum 10.01. 23:59 passen.

[herrmannj]

jo. geh ich mit && mach ich heil !

vg
joerg

[herrmannj]

Na, da bin ich ja mal gespannt. Ab morgen im update. Ich hänge die schon mal an. Denk dran das nur einmal am Tag aktualisiert wird.

Mit Deinem letzten Satz kommt das raus wenn ich es simuliere

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        50018110
   ID         50018110
   METER      heat meter
   NAME       testwmz2
   NR         104
   NTFY_ORDER 50-testwmz2
   STATE      listening
   TYPE       TechemWZ
   VERSION    45
   Readings:
     2016-01-11 00:00:00   current_period  337
     2016-01-11 00:00:00   meter           5668
     2015-12-31 00:00:00   previous_period 5331
     2016-01-11 22:04:00   state           listening
   Helper:
     listmode   0
Attributes:

vg
joerg