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

[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.

Check: 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.

Bit 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:

Wetteranzeige ,,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

Wetter-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]

Wie 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

[tupol]

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]

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. 

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]

Ja.

[tupol]

Hallo Rudi,

ich verstehe nicht so richtig, was Dich davon abhält, meine Aussage zu unknown1 zu überprüfen. Ich habe mich sogar bereit erklärt, Dich bei der Überprüfung zu unterstützen.

Es wäre zumindest schön, wenn Du das Reading unknown1 entfernen könntest, um zu verhindern, dass jemand anderes damit seine Zeit vertrödelt.

Gruß
tupol

[betateilchen]

Es wäre zumindest schön, wenn Du das Reading unknown1 entfernen könntest,

In der aktuellen Modulversion 13_KS300.pm sollte das Reading gar nicht mehr vorhanden sein.

Hat Dich eigentlich jemand aufgefordert, Deine Zeit mit der Erforschung zu "vertrödeln"?

[rudolfkoenig]

ich verstehe nicht so richtig, was Dich davon abhält, meine Aussage zu unknown1 zu überprüfen.

Zeit bzw. Prioritaet. Das "Problem" stoert mich nicht, und es gibt andere Bereiche, die sowohl interessanter, als auch fuer andere dringender sind.

Es wäre zumindest schön, wenn Du das Reading unknown1 entfernen könntest, um zu verhindern, dass jemand anderes damit seine Zeit vertrödelt

Ich habe "unknown1" in "checksum" umbenannt und eingecheckt.

[tupol]

Danke für die Rückmeldung und die Änderung. 

[Michael]

Moin tupol

Sehe dir das mal an.

Zufallsfund aus dem Netz in schlechter Qualität. 

Aber Achtung Copyright!

[chris1284]

hi,

ich wollte erstmal keinen neuen fred eröffnen daher hier die frage.
ich reagiere per notify auf events meines ks300. mit win, rain, israining, humidity, temperature und state geht das super. aber mit diesen
avg_day
avg_month
cum_day
cum_month

geht leider nicht. sie tauchen auch in meinem selbst definierten log und im standard,auto-erstellten nicht auf. ich denke weil sie irgendwie berechnet werden und keine richtigen readings sind (?).

wie kann ich nun darauf reagieren wenn sich die avg* oder cum* ändern?

[rudolfkoenig]

> ich wollte erstmal keinen neuen fred eröffnen daher hier die frage.

Ganz schlechte Idee. Sonst: cum_* sollte man nicht loggen (sind interne Werte zum Rechnen) und avg* funktioniert bei mir prima, bis auf, dass es nur einmel am Tag/Monat aktualisiert werden, aber das ist eine andere Baustelle.

[horchundkuck]

wie kann ich nun darauf reagieren wenn sich die avg* oder cum* ändern?

weil es eben doch "richtige" Readings sind, z. Bsp. mit ReadingVal(...

[Puschel74]

Hallo,

weil es eben doch "richtige" Readings sind, z. Bsp. mit ReadingVal(...

Es geht hier darum das der Fragesteller ein notify auslösen möchte wenn einer der Werte ein Event generiert.
Mit ReadingsVal kannst du den Wert des Readings auslesen - aber kein Event erzeugen.

Aber Rudi hat ja schon geschrieben wie man auf diese Werte per notify reagieren kann resp. das es auch funktioniert.

Grüße

[chris1284]

es hat nun funktioniert. muss wohl am notify gelegen haben. eine löschung und neu anlegen und heute nacht wurde der wert auch in meine hauptinstanz gespiegelt.
ich ging halt davon aus (da es nicht geloggt wird) dass das notify irgendwie nichts vom event mitbekommen kann da wie gesagt zich andere identische triggerten.

[kpwg]

Ich hänge mich hier auch mal ran, weil ich sonst nichts zum Problem finde.

Habe soeben den KS300 von WS300PC (die wirklich übel ist) auf CUL umgestellt. Endlich saubere Kommunikation und ein fehlerfreies Log. Die WS300 ist in ihrer Kommunikation extrem anfällig. Mit dem CUL funktioniert's nun. Einfach so.

Was ich vermisse: vom KS200/300 wird kein Batteriestatus ausgelesen! Muss man da noch was aktivieren? Hab' ich was verpasst? Bei der WS300 klappte das...

Viele Grüße, Ricardo

[chris1284]

könnte das evtl einer unknown werte des ks300 sein die in den readings stehen?

[kpwg]

könnte das evtl einer unknown werte des ks300 sein die in den readings stehen?

Davon gehe ich aus. Das sollte sich doch aus der 50_WS300 ableiten lassen? Ich schau dann mal...

[kpwg]

Habe nachgesehen, wobei sich die Frage stellt: Kommen überhaupt Rohdaten aus der WS300PC oder ist das bereits aufbereitet?
In der 50_WS300.pm steht:

Code Auswählen Erweitern

my @txt = ( "temperature", "humidity", "wind", "rain_raw", "israining", "battery", "lost_receives", "pressure", "rain_cum", "rain_hour", "rain_day", "rain_month");
  #           1         2         3         4         5         6         7         8
  # 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
  # 3180800001005d4e00000000000000000000000000000000000000000000594a0634001e00f62403f1fc stored
  #       aaaatttthhtttthhtttthhtttthhtttthhtttthhtttthhtttthhtttthhrrrrwwwwtttthhpppp
  # 3300544a0000000000000000000000000000000000000000000057470634002c00f32303ee32fc current
  #   tttthhtttthhtttthhtttthhtttthhtttthhtttthhtttthhtttthhrrrrwwwwtttthhppppss
  # 3210000000000000001005003a0127fc config
  #   001122334455667788iihhhhmmmm
  $offs = 2 if(hex($a[0].$a[1]) == 0x33);
  $offs = 10 if(hex($a[0].$a[1]) == 0x31);


[chris1284]

Was ich vermisse: vom KS200/300 wird kein Batteriestatus ausgelesen! Muss man da noch was aktivieren? Hab' ich was verpasst? Bei der WS300 klappte das...

Viele Grüße, Ricardo

ist hier eigentlich schon was in der mache / bei rumgekommen? wäre echt super den batterie-status des ks300 als reading zu haben.

[kpwg]

Nein, scheint kein Interesse zu bestehen. Es ist auch müßig, am meist außen schwer zugänglichen KS300 einen niedrigen Batteriestatus zu emulieren 

Ich habe aber noch einen defekten KS200 (Temp zeigt immer 79.9°C; Leiterbahnen völlig vergammelt) und kann das dieser Tage mit leer genuckelten Batterien (oder Labornetzteil)  testen. Nur schade, das am KS200/300 keine Adresse änderbar ist. Es lassen sich denk ich trotzdem vom KS300 die readings beobachten, wenn man zwei Sensoren hat: der erste liefert korrekte Werte mit vollen Batterien, der zweite 79.9°C mit leeren Batterien. Bleibt noch die Frage, welches Reading den Anlernmodus für wie lange darstellt. Gib mir mal paar Tage; dann kann ich was dazu sagen. Wenn es eine Möglichkeit gibt, explizit Rohdaten zu loggen wäre ich auch für einen abkürzenden Tip dankbar.

Viele Grüße, Ricardo

[kpwg]

Habe den völlig verregneten Nachmittag genutzt, um mich mal wieder dem Batterie-Problem des KS200/300 anzunehmen. Dabei ist folgende Erkenntnis herausgekommen:

type_raw und unknown3 sind bei mir stets "7" und "1". Bei beiden Sensoren.

Interessant dagegen ist checksum: hier meldet meine Sensoren oft 6 oder 7, gelegentlich aber auch alles andere von 1 bis f. Kann man das weiter aufsplitten bzw. gibt es da bereits Erkenntnisse?

Viele Grüße, Ricardo

EDIT: nach nochmaligem Lesen eurer Beiträge gibt's also keine neuen Erkenntnisse. checksum ist klar, wie der Name sagt. Es muss weiter vorn im Stream ein Bit für den Batteriestatus geben.

[tupol]

unknown3 ändert sich.

[kpwg]

unknown3 ändert sich.

Nur unter welchen Bedingungen? Der KS300 sendet bei Inbetriebnahme häufiger; später dann in den üblichen Intervallen. Wie lang ist diese Zeit? 10min? Die WS300PC zB wartet 10min auf Sensoren.

[Matscher]

Nur unter welchen Bedingungen? Der KS300 sendet bei Inbetriebnahme häufiger; später dann in den üblichen Intervallen. Wie lang ist diese Zeit? 10min? Die WS300PC zB wartet 10min auf Sensoren.

Laut Anleitung 5 min im Synchronisationsmodus mit einem Sendeintervall von 3 Sekunden.

Gestern war bei uns Starkregen und der unknown3 hatte den Wert 3. Danach wieder den Wert 1.

[tupol]

ist hier eigentlich schon was in der mache / bei rumgekommen? wäre echt super den batterie-status des ks300 als reading zu haben.

Auszug aus der Bedienungsanleitung des Sensors:
Die Batterien des Sensors haben eine Lebensdauer von bis zu 2 Jahren (Alkaline-Batterien). Sie sind zu wechseln, wenn am Empfangsgerät ein Datenempfang für mehr als 24 Stunden ausbleibt und keine allgemeine und länger andauernde Störung der Funkstrecke in Betracht kommt.

Das heißt: Es gibt anscheinend kein Batteriestatus im Sende-Protokoll.

[kpwg]

Das heißt: Es gibt anscheinend kein Batteriestatus im Sende-Protokoll.

Diese Vermutung ist leider falsch. Ich betreibe parallel noch die WS300PC sowie eine Conrad WS555: da wird bei leerer Batterie ein Symbol angezeigt.

[tupol]

Das überrascht mich. Auch die Bedienungsanleitung des KS555 sagt:
Wenn am Empfangsgerät (z.B. an der Basisstation ,,WS555") ein Datenempfang für mehr als 24 Stunden ausbleibt, sind die Batterien gegen neue auszutauschen.

Ist das tatsächlich die Batterieanzeige des Sensors und nicht die des Empfängers. Es sollte dann zwei Anzeigen für leere Batterien geben.

Falls es zwei Anzeigen gibt. Kannst Du die mit einer fast leeren Batterie triggern? Evt. wartet auch der Empfänger nur 24 h, bis er etwas anzeigt.

[tupol]

Gleiches gilt für die WS300 (Ich glaube, die ist baugleich mit der WS555.)
Basisstation
Erscheint im Display das Batterie-Leer-Symbol (Lo Bat, ), so sind alle Batterien nach Abschnitt 2.2 (,,Basisgerät", S. 8) gegen solche gleichen Typs auszutauschen. Wechseln Sie stets alle 4 Batterien aus und setzen Sie nur hochwertige Alkaline-Batterien ein.
...
Funk-Sensoren
Die Batterien in diesen Sensoren haben eine Lebensdauer von bis zu 2 Jahren
(Alkaline-Batterien). Sie sind zu wechseln, wenn die Anzeige des entsprechenden
Sensors im Display des Basisgerätes für mehr als 24 Stunden ausbleibt und keine
allgemeine und länger andauernde Störung der Funkstrecke in Betracht kommt,
die im Allgemeinen daran zu erkennen ist, dass die Datenübertragung weiterer, in
der Nähe liegender Sensoren ebenfalls ausgefallen ist (s. Abschnitt 5).

Fazit: Kein Batteriestatus vom Sensor

[kpwg]

Fazit: Kein Batteriestatus vom Sensor

Ok, wie Du meinst. Leider ist die WS300PC anderer Meinung und meldet über die 50_WS300.pm brav einen Batteriestatus des Außensensors (nicht der WS300PC!). Ich hatte die WS300PC eine Weilchen, bin aber dann auf CUL umgestiegen. Suche mal nach "WS300PC"- da hatte ich die recht lästigen Probleme umfassend beschrieben.

[tupol]

Leider habe ich hier ausser deinen Beiträgen in diesem Thema nichts gefunden. Was genau meinst Du?

Aus Deiner Beschreibung innerhalb dieses Themas geht nicht hervor, ob die Meldung eine von der WS300PC erzeugte Meldung ist (24 h kein Signal) oder ob es der Sensor selbst ist.

Du hattest aber auch geschrieben, das es ein Symbol/Meldung in der WS555 gibt. Ist die Bedienungsanleitung also falsch?

[tupol]

Jetzt habe ich auch noch in der Bedienungsanleitung der KS300PCII nachgesehen. Auch dort kein Hinweis auf eine Sensor-Batterieanzeige sondern nur auf den 24h-Signalausfall.

Es würde mich überraschen, wenn der Sensor das Signal übermittelt, aber alle drei Geräte es in Ihrer Bedienungsanleitung nicht erwähnen.