KS300/KS555 unbekannte Werte - unknown1 und unknown2 entschlüsselt

Begonnen von tupol, 30 Dezember 2013, 21:04:23

Vorheriges Thema - Nächstes Thema

tupol

Hallo Rudi,

ich bin inzwischen auch ein glücklicher Besitzer eines Conrad-KS555-Kombisensors. Dabei sind mir in FHEM die Readings unknown1, unknown2 und unknown3 aufgefallen und Dein Kommentar, dass Dir der Inhalt nicht bekannt ist.
Ich habe mal auf gut Glück im Netz gesucht und die folgenden interessanten Infos gefunden. Wurden die von Dir schon mal in Betracht gezogen?


Im Netz gibt eine Beschreibung des KS300 Protokolls http://www.dc3yc.privat.t-online.de/kombi.htm und auf http://www.dc3yc.privat.t-online.de/protocol.htm die Beschreibung der CheckSummen-Bildung.
ZitatCheck: alle Nibbles beginnend mit dem Typ bis Check werden XOR-verknüpft, Ergebnis ist 0
    Summe: alle Nibbles beginnend mit dem Typ bis Check werden aufsummiert, dazu 5 addiert und die oberen 4 Bit verworfen
Die Seite http://www.wetterstationen.info/forum/entwicklerforum/wetterwilli-byte-entschlusselt/ hat mich noch auf die Idee gebracht, dass ein Byte etwas mit dem "Wetter-Willi" zu tun haben könnte.
ZitatBit 1 bis 0 also diese 0000 00XX
00 Sonnig
01 teilweise Bewölkt
10 Bewölkt
11 Regnerisch

rudolfkoenig

Die ersten zwei Links haben mir nicht geholfen. Die Dritte koennte recht haben (unknown1 -> Wetterwilli), aber das muss ich laenger beobachten. Bleiben weiterhin noch unknown2/unknown3.

rudolfkoenig

Nach etwas nachdenken: Wie soll ein KS300/KS555 zwischen sonnig, teilweise bewoelkt und bewoelkt unterscheiden?
Ich wuesste nichtmal welche Sensoren dazu noetig waeren. Wir bleiben bei 3 * unknown.

tupol

Danke für die prompte Antwort. Sind die ersten beiden Links (Check+Summe) falsch oder nicht verständlich genug?

Wie kann ich die Rohdaten des KS300 loggen?

Für den Wetter-Willy hier zwei Auszüge aus der Beschreibung für die WS300, die genauen Werte für Wind und Temperatur müßten eine Validierung ermöglichen.
Seite 5:
ZitatWetteranzeige ,,Wetter-Willi"
In Anlehnung an das fast vergessene Wetterhäuschen, wo bei schlechtem Wetter
eine Person mit Regenschirm vor die Tür tritt und bei gutem Wetter eher leichte
Bekleidung angesagt ist, verfügt die WS 300 über ,,Wetter-Willi".
Das Verhalten dieser Figur richtet sich nach mehreren Wetterfaktoren, so dass man
auf einen Blick erkennt, wie eine mögliche Bekleidung für den Aufenthalt im Freien
aussehen könnte. Hierbei werden nicht nur die aktuellen Messwerte für Außentemperatur,
Luftfeuchtigkeit, Wind und Regen
ausgewertet. Die Wettervorhersage spielt
hier nämlich auch eine wesentliche Rolle. So gibt es je nach Wetterlage viele unterschiedliche
Darstellungen und Bekleidungszustände des ,,Wetter-Willi".

Seite 17
ZitatWetter-Willi
Der Wetter-Willi zeigt als animierte Figur gleichzeitig mehrere Wetterfaktoren an:
Außentemperatur (nur Kombi-Sensor)
- Der Bekleidungszustand richtet sich nach der Höhe der Außentemperatur am
Kombi-Sensor.
Regen
- Hat die Vorhersagefunktion Regenwetter ermittelt, trägt die Figur einen geschlossenen
Regenschirm.
- Bei beginnendem Regen trägt die Figur den Regenschirm aufgespannt.
Windgeschwindigkeit
- Bei Windgeschwindigkeiten über 20 km/h (mäßiger Wind) wehen die Haare des
Wetter-Willi. Ist die Temperatur gleichzeitig unter 14˚C, weht auch der nun getragene
Schal im Wind.
Wettervorhersage
- Die Wettervorhersagesymbole ganz oben im Display geben folgende Prognosen
ab:
· Wolken mit Regen → Regnerisch
· Wolken → Bewölkt
· Wolken mit Sonne → Heiter
· Sonne → Sonnig

rudolfkoenig

ZitatWie kann ich die Rohdaten des KS300 loggen?
Nicht auf dem ueblichen Weg. Wenn man "attr KS300 verbose 4" setzt, dann landen die Rohdaten (in den relativ doofen FHT1000 Format) im globalen fhem-log.

Michael

Moin

@tupol
Ich kann zwar nichts zu den Werte beitragen.
Aber bei ELV ist eine Simulation zum WetterWilli.

http://www.elv-downloads.de/ws300/flash.html
Gruß, Michael

FHEM 6.0 auf RPi 3
CUL V3 868 Mhz | JeeLink LaCrosse & PCA301 | CCU3
BMP085(180) | 14x TX29DTH-IT | 5x PCA 301 | SMA Peripheries | MobileAlerts MA-10(100,120PRO,200,251,410,650,660,800) | HM IP

tupol

#6
Frohes neues Jahr Rudi,

also der Wert unknown1 ist tatsächlich die zweite (letzte?) hexadezimale Quersumme aller 13 vorherigen Werte
Also für folgende Rohdaten im FHT1000-Format

810d04xx4027a0017130058110210e
-->  7+1+3+0+0+5+8+1+1+0+2+1+0 = 1d -->  1 + d = e
oder 810d04xx4027a00179600887202105
-->  7+9+6+0+0+8+8+7+2+0+2+1+0 = 32  --> 3 + 2 = 5


Könntest Du mir bitte kurz erklären, was der Unterschied zwischen dem FHT1000-Format und der Darstellung von  http://www.dc3yc.privat.t-online.de/kombi.htm ist? Irgendwie fehlen die letzten drei 4bit-Nibble (?? + Check + Summe) im FHT1000-Format
Laut der angegebenen Seite sind die ersten Ziffern 0(4bit) 0(4bit) 1(1bit) 7(4bit) zudem immer gleich.

rudolfkoenig

Sorry, hab mich verschrieben, es heisst FHZ1000 Format, und das ist das, wie ein FHZ1000 die Daten einer KS300 liefert. Da das KS300 Modul vor dem CUL-Zeit erstand, habe ich in CUL die Daten konvertiert, damit ich das KS300 nicht umbauen muss.
Im wesentlichen wird 810d04xx4027a001 davorgehaengt, und danach alle "nibbles" umgedreht. Kaputt halt. Siehe auch 00_CUL.pm

tupol

#8
OK. Dann versuche ich mich mal weiter im Rätselraten.  ;)

Bei mir ist der unknown2 Wert immer 7. Wenn das die 7 vom Anfang der FHZ1000 Formats ist, dann ist es laut erwähnter Seite nur die Typenkennung für den KS300.

Allerdings weiß ich nicht, wo unknown3 (bei mir immer 1) herkommt. Wenn es das erste 4bit-Nippel ist, müsste es eine 0 sein, da die 1(binär) ja immer als Trennzeichen zwischen den 4bit-Nippeln genutzt wird. Da wäre dann die Frage, wie die CUL das ganze auswertet. Wird evt. die 1 zwischen den 4bit-Nippeln nicht mit ausgegeben - beim ersten Signal aber schon? Und wo bleibt die Check+Summe aus erwähnter Seite? Wird die nur von der CUL verarbeitet - aber nicht weitergegeben?

Gelöst???

rudolfkoenig

Sowohl die 1-en (parity) als auch checksum sind schon vom jeweiligen firmware (culfw bzw. FHZ1000) weggefiltert worden.

tupol

Hallo Rudi,

ich wollte mal vorsichtig anfragen, ob Du nach der obigen Auflösung vor hast, die unknown-readings in dem KS300 Modul zu entfernen. Oder ist die Lösung die falsche?

rudolfkoenig

Ich weiss immer noch nicht, was ich fuer diese 3 unknown Eintraege (jeweils 4 bit) programmieren soll.
- ich finde es unwahrscheinlich, dass  hier ein zweites Checksum eingebaut ist: den ersten hat FHZ/culfw schon geprueft und weggefiltert.
- parity wird von FHZ/culfw weggefiltert.
- die Wetterewilli Erklaerung kommt mir unwahrscheinlich vor, da die KS300 keine Vorhersagedaten empfaengt.
- Mit unknown2/typ/7 hast Du aber recht, ich habe unknown2 in type_raw geaendert und eingecheckt. Mit etwas knobeln und vergleichen haette man das auch aus CUL_WS.pm ableiten koennen, da ist eine einfachere Implementierung der KS300 drin, 00_CUL.pm waehlt aber absichtlich das KS300 Modul.

tupol

Bei meiner Angabe unknown1 = zweite HEX-Quersumme aller 13 vorherigen HEX-Werte  handelt es sich nicht um eine Vermutung, sondern um eine Tatsache. :)
Ich habe sie bei über 20 KS300-Readings (per verbose 4) korrekt nachvollziehen können. Du kannst das anhand der angegebenen Formel gerne auch selber nachprüfen. Oder Du schickst mir den entsprechenden Teil eines Deiner raw-Werte und ich liefere die letzte Ziffer.  8)

Bzgl. der Checksumme-Prüfung in der CUL stolpere ich immer wieder über scheinbare Fehlinterpretationen von unsauberen KS300 und WS300 Telegrammen. Bevor ich meine CUL-Einstellung verbessert habe, sind so ca. 1-2 Mal im Monat Pseudo-Sensoren (per autocreate) aufgetaucht. Seit der Verbesserung der Einstellung aber nicht mehr, weil nun alle Telegramme ordentlich empfangen werden. Irgendwie müssen die Telegramme aber durch die CUL-Checksummenbildung geschlüpft sein. Das ist irgendwie seltsam weil eigentlich recht unwahrscheinlich. Mit der zweiten Checksumme sollte das dann aber verschwunden sein.

chris1284

Nabend,

ich habenur ein ekurze zwischenfrage: funktionieren aktuell KS300/KS555  mit fhem "out of the box" und ohne WS xxxx? Also definieren und Werte betrachten?

Danke schonmal!

tupol