CUL_WS "kaputte" readings

[arnoaugustin]

Hallo Rudi,

Ich hab hier einen ASH 2200 Sensor im Keller. Das CUL_WS Modul liefert mir hier vom Sensor öfter mal "kaputte" Readings. Da ich den ohnehin auf ein Dummydevice umlenke, skippe ich bei mir dort nicht plausible Werte (Find das daher persönlich auch nicht mehr schlimm)

Code Auswählen Erweitern


2016.02.10 19:30:24 1: PERL WARNING: Argument "18.B" isn't numeric in addition (+) at ./FHEM/14_CUL_WS.pm line 274.
2016.02.10 19:30:24 2: KellerReal: Temp difference (-17.2) too large: T: -0.8  H: 18, skipping it
2016.02.10 19:32:56 2: KellerReal: Temp difference (17.2) too large: T: 16.4  H: 47.8, skipping it

Evtl. könnte man im Modul noch prüfen das Ergebnis beim Dekodieren überhaupt Sinn Macht bzw. nur aus [0-9.] besteht und ansonsten kein Reading generieren? Is nur son Gedanke....
Was mich gerade etwas wundert, wenn ich mir das im Code angucke, dann war das nicht nur ein Bitfehler sondern Vollmurks der der angekommen sein muss....

Da ich ich grad ein neues KM200 für die Buderus Gateways geschrieben hab is mir das eben im Log aufgefallen.
(Das Gatewaymodul hat ein paar Features die das offizielle KM200 nicht hat. Kann man das irgendwo abstellen oder soll ich das einfach im KM200 Forum posten? Ist eigentlich soweit fertig und kann sicher manch einer was mit anfangen)


Viele Grüße,
  Arno

[rudolfkoenig]

Evtl. könnte man im Modul noch prüfen das Ergebnis beim Dekodieren überhaupt Sinn Macht bzw. nur aus [0-9.] besteht und ansonsten kein Reading generieren?

Habs implementiert und eingecheckt.

Das eigentliche Problem ist, dass im culfw fuer die S300 Nachrichten nur Parity (fur 4 bits) und die Haelfte des Checksums (d.h. nur ein Nibble) geprueft werden, da ich beim Implementieren nicht wusste, wie die zweite Haelfte zu berechnen ist. Es gab mal vor Jahren Hinweise darauf, ich habe das Thema aber nicht verfolgt, weiss nicht mehr wieso.

[arnoaugustin]

Das ging schnell....Danke 

Das eigentliche Problem ist, dass im culfw fuer die S300 Nachrichten nur Parity (fur 4 bits) und die Haelfte des Checksums (d.h. nur ein Nibble) geprueft werden, da ich beim Implementieren nicht wusste, wie die zweite Haelfte zu berechnen ist. Es gab mal vor Jahren Hinweise darauf, ich habe das Thema aber nicht verfolgt, weiss nicht mehr wieso.

Ja das ist bei der ganzen Sache das eigentliche Problem....
Trivialprotokolle die anscheinend geheim bleiben sollen. Nicht, dass noch ein anderer Hersteller versucht was nach zu bauen.
Ohne FHEM bräuchte man 10 Zentralen, 10 Fernbedienungen usw. und wenn ein Hersteller pleite geht, dann hat man am Ende kein Licht mehr im Haus Etwas übertrieben, aber irgendwo triffts das für mich schon.

FHEM is einfach klasse. Super Struktur, super Interface und in Perl geschrieben  Das isses einfach.
Bin echt froh, dass du das alles mal irgendwann angefangen hast.....

Danke und Grüße,
Arno