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

[kaihs]

@hermanj; ja, ich denke auch das da schon beim CUL was schief läuft. Empfangsfehler kann eigentlich nicht sein, da die culfw schon den crc des gesamten Pakets prüft. Vielleicht wird das Paket beim Weg vom CUL zu unseren Modulen verstümmelt.

[BennySt]

Ich mische mich mal ein. Solche Fehler bekomme ich auch

Code Auswählen Erweitern

2017.01.26 18:49:48 2: WMBUS Error during LinkLayer parse:CRC check failed on link layer
2017.01.26 18:49:48 2: WMBUS Error during LinkLayer parse:CRC check failed on link layer
und immer wieder folgendes und ähnliches

Code Auswählen Erweitern

2017.01.26 18:49:30 2: CUL_WLAN2: unknown message 468501227751094802321A20F9F210F00A023340011FA09EC0E140FC111000807000000000000000000000000F49B00000000000000000000FFFF8019
2017.01.26 18:49:48 2: CUL_WLAN2: unknown message 0111202008410C000000000000000000B0D000000000000FFF80DF

Ich würde sagen das der Buffer im CUL Überläuft oder der CUL selbst irgendwo klemmt... genaues habe ich noch nicht verfolgt...
Es tritt aber mit 2 verschiedenen CULs  fast nie Zeitgleich auf.
Ich würde TTY_BUFFERSIZE in der boards.h mal erhöhen auf 256 und schauen ob es Besserung bringt, habe aber momentan keine Zeit. Evtl. nächste Woche.

[tca]

@BennySt
verwendest du aculfw bzw. culfw-a (Max! Cube)? Falls ja, welche Version?

[herrmannj]

18:19:30 im log ist klar ein Fragment einer techem Nachricht. Weshalb ist die zerstückelt? Komisch...

[BennySt]

@tca
a-culfw auf einem nanoCUL und einem Selbstbau mit geänderter Firmware
@hermannj
Diese Zerstückelungen tretten meistens bei meinem Selbstbau mit der geänderten Firmware auf. Ich gehe davon aus das der TTY_Buffer zuklein wird. Beim nanoCUL tauchen Sie aber auch auf, nur seltener. Manchmal auch nur der Anfang b33. Das Verhalten muss ich noch Untersuchen.

[tca]

@BennySt
... macht Sinn;
ich sehe gerade, dass bei meinem CUL/COC der TTY_BUFSIZE=1024 gesetzt ist, hingegen bei dem CUL/CUBe [a-cufw] TTY_BUFSIZE=128 - wobei, da stehen ein zweites "TTY_BUFSIZE=512" weniger Zeilen drunter, das scheint für den Bootloader zu sein; ich vermute, das erste ist zu ändern...

[BennySt]

@tca
Eigentlich dürfte es nur ein #define TTY_BUFFSIZE geben.
Bei der nanoCUL board.h ist es diese hier.

Code Auswählen Erweitern

#define HAS_UART
#define UART_BAUD_RATE          38400

/* ATMega328P has only one UART, no need to define the UART to use */
//#define USART_RX_vect           USART0_RX_vect
//#define USART_UDRE_vect         USART0_UDRE_vect

#define TTY_BUFSIZE             128


#define RCV_BUCKETS            2      //                 RAM: 25b * bucket

Sei aber vorsichtig mit der Erhöhung ich weiß nicht wieviel RAM noch zur Verfügung steht

[tca]

@herrmannj, @kaihs
ich habe hier einen Log-Auszug, aus dem man evtl. etwas mehr lesen kann (Position 2017.01.26 22:39:27 2 bzw. 3):

Code Auswählen Erweitern


2017.01.26 22:39:27 5: CUL/RAW: b3244685/b324468507432809269803FCCA0119F211D04A0233001AB08AC0A5BD5D19B005BA87B4B09130000000000000000004CF50E0000451E4587A05B79D9

2017.01.26 22:39:27 4: CUL_Parse: cube b3244685b324468507432809269803FCCA0119F211D04A0233001AB08AC0A5BD5D19B005BA87B4B09130000000000000000004CF50E0000451E4587A05B79D9
2017.01.26 22:39:27 5: cube: dispatch b3244685b324468507432809269803FCCA0119F211D04A0233001AB08AC0A5BD5D19B005BA87B4B09130000000000000000004CF50E0000451E4587A05B79D9
2017.01.26 22:39:27 5: WMBUS raw msg b3244685b324468507432809269803FCCA0119F211D04A0233001AB08AC0A5BD5D19B005BA87B4B09130000000000000000004CF50E0000451E4587A05B79D9
2017.01.26 22:39:27 2: WMBUS Error during LinkLayer parse:CRC check failed on link layer
2017.01.26 22:39:27 3: cube: Unknown code b3244685b324468507432809269803FCCA0119F211D04A0233001AB08AC0A5BD5D19B005BA87B4B09130000000000000000004CF50E0000451E4587A05B79D9, help me!
2017.01.26 22:39:28 5: CUL/RAW: /b324468507931809269804F5FA0119F21CD05A0235401F209040C8CC824D8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A14

2017.01.26 22:39:28 4: CUL_Parse: cube b324468507931809269804F5FA0119F21CD05A0235401F209040C8CC824D8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A14 -64
2017.01.26 22:39:28 5: cube: dispatch b324468507931809269804F5FA0119F21CD05A0235401F209040C8CC824D8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A::-64

Was mich wundert ist, dass die WMBus-Device-Readings generell nach dem ersten Auftreten der Fehlermeldung, nicht mehr aktualisiert werden. Sollte nicht mit der nächsten richtigen/vollständigen WMBus-Message alles wieder 'normal' laufen?

[herrmannj]

konnte prüfen, das ist der Stand:

Wenn ich in den Techem Modulen eine defekte (CRC Error) Nachricht erhalte wird das im log vermerkt ("crc error <msg>") und die Nachricht dann verworfen. Die hier angesprochenen Nachrichten kommen aber wegen der regex im dispatch gar nicht erst in den Techem Modulen an. Die regex mit denen techem wmbus erkannt wird matched schon vorab nicht.

Von daher: innerhalb der techem module: nothing to do.

Empfehlung: CUL fw anschauen, reparieren.

Bzgl der Frage mit den WMBUS (modul von kaihs) readings: da ist in der Fragestellung etwas vermischt :

Wenn es eine techem Funknachricht ist wird die vom entsprechenden techem modul bearbeitet sofern in fhem als device definiert.
Ansonsten werden (generische) wmbus Nachrichten vom WMBUS modul bearbeitet.

Sollte also eine verstümmelte techem msg reinkommen dann wird die formatprüfung auf techem fehlschlagen. Damit ist es keine techem Nachricht, kein techem modul übernimmt. Stattdessen wird sie vom WMBUS modul übernommen und dort als kaputt (CRC link error) gemeldet. Alles richtig. Kommt jetzt die nächste korrekte techem Nachricht geht sie an das entsprechende Techem modul. Da kann im *WMBUS modul* per default auch nichts aktualisiert werden. Die techem module werden die Nachrichten aber weiterhin verarbeiten.

Aktuell sieht das alles aus wie "arbeitet wie geplant".

vg
joerg

[tca]

Danke für das Prüfen und die ausführliche Erklärung!

In der Tat habe ich in meiner Frage etwas vermischt: es sollte heissen "Techem-Device-Readings werden nicht mehr aktualisiert" (und nicht "WMBus-Device-Readings ...")
Aber: im Ergebnis spricht das für die selbe Ursache, die culfw ... ich probier einfach mal ein größeres TTY_BUFSIZE;

Danke nochmal @herrmannj, @kaihs, @BennySt

[kampfkartoffel]

hallo erst mal 
ich glaub hier bin ich bei den richtigen technick nerds angekommen 

JUHHUU

so mein problem ist ich will nicht das meine daten ausgelesen werden  warm kalt wasser strom und heizung
1-2 mal im jahr habe ich kein problem aber wie ich sehe passiert das wohl sehr oft 

meine frage:
gibt es legale mittel um dieses zu verhindern ( funk kopfhöerer ?)
grund: ich habe einfach große bauchschmerzen das ich immer mehr zum gläsernen menschen werde und will etwas dagegen tun ...
die unternehmen techem und ista wollen jetzt ein lukratives unternehmen ( gewinne um 37 %) verkaufen das sagt ALLES !!!
ich sage mal nur whatsapp und facebook
ich hatte in einem anderen forum schon ne menge geschrieben  wer will kanns hier lesen
http://www.funkbasis.de/viewtopic.php?f=39&t=44050&p=481657#p481657

dickes danke schon mal im voraus

[herrmannj]

Moin und herzlich willkommen !

sei mir nicht böse aber Deine Frage zielt auf eine recht dunkle Ecke.

Wenn Du Bedenken bzgl gläsernem Mensch hast solltest Du Dich politisch oder gesellschaftlich engagieren. Es gibt, auch aus meiner Sicht, viele Punkte die man in dem Themenkomplex sehr kritisch hinterfragen darf.

- aber -

Die Übertragung der Daten ist relevant für die Abrechnung der Versorger.

Ich möchte keine Diskussion sehen die sich in irgendeiner Art und Weise mit der Manipulation der Übertragung dieser Daten beschäftigt ! (sehr nachdrücklich)

Hier geht es ausschließlich um die technische Ebene. Darum die anfallenden, eigene Messwerte zu erfassen und zu nutzen um dann durch Verbesserung des eigenen Verhaltens oder Umfeldes zB sparsamer mit Energie umgehen zu können. 

vg
joerg

[ConiKost]

Hallo,
ich habe hier auch einen CUL 868 und wollte damit meine Techem HKV auslesen. Ich habe hier 4 Stück.

Code Auswählen Erweitern

define Techem_Wohnzimmer TechemHKV 0007
define Techem_Schlafzimmer TechemHKV 0008
define Techem_Kueche TechemHKV 0009
define Techem_Badezimmer TechemHKV 5019

Der HKV aus dem Badezimmer wird sauber erkannt und ich kann die Werte lesen. Die anderen drei werden aber nicht erkannt. Es werden keine Werte geliefert, ich habe daher mal die im Thread neuere 32_TechemHKV.pm ausprobiert, ohne Erfolg. Es fällt aber dabei auf, dass das funktionierende Modell anders aussieht. Sind die anderen Varianten evtl. nicht kompatibel?

Funktioniert: http://imgur.com/0CXP8Ds
Funktioniert nicht: http://imgur.com/VngdxQO

[Brice]

Habe lange nicht mehr in diesen Thread geschaut....

Code Auswählen Erweitern

WMBUS Error during LinkLayer parse:CRC check failed on link layer
Als CUN verwende ich einen Max!Cube (culfw-a)...

Hier passiert dasgleiche und zwar auf beiden Systemen, die auf den CUN im Netzwerk zugreifen. Nach Durchsicht der Logfiles war der Eintrag erstmalig beim Jahreswechsel

Code Auswählen Erweitern

2016.12.31 23:58:53 2: WMBUS Error during LinkLayer parse:CRC check failed on link layer

Vor dem Jahreswechsel hatte ich die Meldungen nicht. Die Meldungen ignoriere ich. Der CUN wird per at täglich auf "set <Device> reopen" gesetzt, von daher habe ich in der Aufzeichnung keine Ausfälle.

Interessant wäre natürlich zu erfahren, wie ich die Meldungen unterdrücken kann.

Stefan

[herrmannj]

Das ist eine Fehlermeldung weil die Daten die vom CUL kommen defekt sind. Liegt wohl an der a-culfw. Wenn man den verbose vom WBMUS modul kleiner stellt dann sollte die Meldung im log nicht mehr erscheinen. Die Daten kommen natürlich trotzdem nicht.

vg
joerg