Hallo zusammen,
ich habe hier eine Wetterstation herumliegen, die mit der Basisstation
ueber GND/DATA mit 5V-Pegeln "spricht". Leider macht die Basisstation
die Grätsche, sodass ich mich an das "Reverse-Engineeren" des Protokolls
gemacht habe, um die Daten anschliessend mit einem mC (Arduino)
auszulesen und auszuwerten.
So wie es aussieht ist hier eine umgekehrte Logik mit einer 833us
Pulsweite Trumpf.
Komme allerdings trotzdem keinen Schritt weiter - vielleicht hat jemand
hier aus dem Forum eine Idee.
Ein paar Randinfos noch:
- Das "Telegramm" wird jede Sekunde übertragen.
- An Sensorik ist folgendes vorhanden, was (vermutlich) hier auch in dem
Screenshot enthalten ist. Ob darüber hinaus noch etwas übermittelt wird
-> keine Ahnung:
1. bis 3.) 3 x Sonneneinstrahlung in KiloLux (Hier: 10,21 und 19
KiloLux)
4.) Temperatur (Hier: 13 Grad bei Oszillografie)
5.) Luftfeuchtigkeit (Hier im Diagramm muesste eine 44% herauskommen)
6.) Regen (Ja/Nein) (Hier: Nein)
7.) Windgeschwindigkeit (Leider nicht notiert)
Mir würde es schon helfen, wenn mir jemand auf die Sprünge helfen könnte
wie ein Byte/Nibble hier zu lesen ist. Zur Grafik:
- Das "rote" ist nur ein invertiertes "grünes" :-)
- Start ist bei 40.000ms im Diagramm (gtkwave auf dem Mac ist irgendwie
creepy)
Ich sag schonmal danke im vornherein.
Viele Grüsse aus dem Rheinland
Jörg
So wird das nichts. Für ganz viele verschiedene Eingangswerte
(Temperatur/Wind usw) das Telegramm aufnehmen, in logisch 1/0 umwandeln
(einfach ablesen) und dann reverse engineeren und/oder hier posten.
Besonders "wertvoll" sind Telegramme zwischen denen sich nur ein Wert
(z.B. Wind) ändert.
Garnicht so trivial. Bei der Masse an Sensoren die an dem Teil hängt.
Wenn ich wenigstens wüsste woran ich eine 0/1 oder ein Startbit
identifizieren könnte - dann liesse sich etwas gezielter auf die Suche
gehen.
Nun gut. Habe es mal versucht.
Von oben nach unten:
1. bis 3.) Vermutlich nur Temperaturwechsel (nach oben) - weil
Wetterstation mit Karton zugedeckt. Ob sich die Luftfeuchte verändert
hat kann ich nicht sagen. Müsste aber alles marginal sein.
Bild 4.1) Karton noch drauf
Bild 4.2) Karton runter - und somit Lichteinstrahlung (auf allen 3
Helligkeitssensoren - lässt sich leider nicht vermeiden) - Hier ist auch
bereits beides invertiert.
Die Helligkeitsdinger müssten demach ziemlich am Ende des Telegramms
sein.
Hab derweil alles durch und hänge trotzdem noch.
Auffälligkeiten:
- LowPulse: 750uS
- HighPulse: 1000uS
- Das Low ein anderes Timing als High hat, irritiert mich schon
massivst.
- Nach genau 8750uS kommt grundsätzlich ein LowPulse (HL-Flanke bis
HL-Flanke vom 750er) -> Bytelänge ????
Scheint in jedem Falle irgendwas RS232 mässiges zu sein (Nein, Clock
bekomme ich nirgends). Zur angehängten Grafik:
- Vor diesem "Telegramm" hängt der Pegel auf +5V, danach ebenso. Das
erste "Bit" sind diese 750uS Low.
- Da ich in den vorherigen Grafiken das Ding teilweise invertiert habe,
ist also von dieser Logik (Ruhe=High) auszugehen.
Zur Analyse"
Am sinnigsten scheint mir folgendes:
FullDelay=750
HalfDelay=375
Warten auf das erste "Low", dann 1,5 Bit warten und 8 x lesen (Mit je
einem FullDelay dazwischen). Am Ende noch 2 FullDelays dazu und dann
wieder von vorn.
Heraus kommt (bei steigender Tempeatur) folgendes:
Byte 2, oder aber 14/15 geben irgendwie die Temperatur wieder. Wobei ich
da auch noch keinerlei Offset entdecken konnte. Bei dem Test habe ich
einfach mal den Finger an den Temperatursensor gehalten - sonst sollte
sich nichts verändert haben.
Bin ich auf dem Holzweg, oder hat irgendjemand eine Idee ? Verzweifele
langsam !
Elsner P01 (die, die original zur Wintergartensteuerung WS10 WS20
WS1000 gehört - also NICHT die RS485-Variante).
Der Hersteller gibt sich leider extremst zugeknöpft. Im Manual steht
auch nur was von "Eigenes Protokoll".
Foto: Siehe Anhang.
3 Anschlüsse:
+24V/DC (für Spannungsversorgung + Regensensorheizung)
GND
DATA
@rsonline: Wenn das Stopbit ein 1,5x so langes wäre, dann müssten ja
irgendwo 1500er oder 1125er auftauchen - ist leider nicht der Fall :-(
So,
hier ein kleiner Zwischenstand:
Beim den bisherigen Versuchen schien das Timing nicht ordentlich zu
passen. Mit dem Resultat, dass entweder ein Bit verschluckt wurde, oder
aber eines zuviel kam. Mit einer Clock von 860uS kommt nun folgendes
heraus:
Byte 1) Statisch ""S"
Byte 2) Temp LSB
Byte 3) Temp MSB
Byte 4) Licht vorn LSB
Byte 5) Licht vorn MSB
Byte 6) Licht links LSB
Byte 7) Licht links MSB
Byte 8) Licht rechts LSB
Byte 9) Licht rechts MSB
Byte 10)Dämmerung ?
Byte 11)Regen J/N
Byte 12)irgendwas mit Licht
Byte 13-17) ?
Hast du mit der Elser Weterstation weitergemacht ?
Ich habe ebenfalls 2 Steuerungen WS10 und eine Wetterstation mit RS484 daran. Denke eher P00 . Jetzt würde ich gerne die DAten mit einem Arduino lesen also die Station weiterbetreiben.
Wie hattest du damals die Daten gelesen -- womit und wie hattest du alles angeschlossen - Wäre um jede Hilfe sehr dankbar
Hallo Roland,
nein - habe an der Front aufgegeben, da das ding viel zu teuer ist.
Meine Wintergartenanlage läuft inzwischen zwar noch mit der überteuerten Closed-Source-Elsner Lösung, jedoch übersteuere ich nahezu alles über die Relaiseingänge.
Mit anderen Worten: Ziehe Steuerungsdaten (Wetter & Co.) aus anderen Sensoren und triggere dann einfach nur über eine Relaiskarte mit ESP32 die entsprechenden Aktoren.
ich besitze 2 WS10 und eine davon hatte Probleme. Ersatz ist viel zu teuer !!
Die meiste Elektronik in der WS10 ist ja noch brauchbar.
Ich habe die Prozessor-Einheit und LCD display im Deckel entfernt und durch
ein ESP32 mit Wifi und dual-Prozessor ersetzt. Ebenfalls ein neues LCD und temp Sensor.
Hardware Kosten ca. 20 Euro !!
Die STecker-Anschlüsse habe ich analysiert und soweit ich es brauche erkannt !
Jetzt habe ich eine Lösung, welche 2 Arbeitsgruppen schalten kann. Bis jetzt nur
Temp gesteuert.
Habe es noch nicht geschafft die Wetterstation Daten zu lesen -- brauche ich aber eigentlich nicht da ich über WIFI Daten bekommen kann.
Software kann ich auch OverTheAir updaten und die TAstenbedienung läuft für mich einfacher.
Kann ebenfalls alles über Web/Tablett bedienen .
Gut, die Software war etwas zeitaufwendig, da ich keine Erfahrung mit Arduino hatte -
ist aber denke ich ganz gut gelungen.
Also nicht alles gleich wegwerfen -- bin gerne bereit die Erfahrung zu teilen.
ich hoffe ich bin nicht all zu spät zu diesem Thema.
Ich bin vor ein paar Wochen auf diesen Thread gestoßen, als ich meine alte Wetterstation (Hager TG051) wieder ans laufen bringen wollte. Der Hager Support hat mich darauf hingewiesen, dass es sich wohl um ein altes Exemplar einer Elsner Wetterstation handelt (P01 soweit ich das sehen kann).
Nach einiger Zeit mit einem Logic Analyzer und Pulseview, konnte ich das verwendete Protokoll auf simples UART mit einer Baudrate von 1130 einschränken.
Ich habe einfach mal einen mehrstündigen Dump der Pakete angehangen. Der Dump müsste so gegen 09:30 Uhr anfangen und gegen 15:00 aufhören.
Ein großteil der Daten stümmen mit dem Format von Jörg überein. Allerdings scheint bei mir alle 60s ein 'U' anstatt eines 'S' als Start-Byte gesendet zu werden. In diesen Fällen ist die Länge eines Paketes dann 21 Bytes anstatt der üblichen 16.
Byte 10 ist bei mir über mehrere Messungen an unterschiedlichen Tagen und Uhrzeiten immer 0. Dies scheint ein reservierter Byte zu sein.
Byte 12 (in output.png as "flags") zeigt ohne wirkliches Muster die Werte 0-5. Hier scheinen keine weiteren Werte aufzutauchen.
Interessant sind auch Bytes 13-16. Hier unterscheiden sich die Daten basierend auf dem Start-Byte:
Start-Byte 'S': zufällige Daten. Hier konnte ich keine Korrelation zu irgendeinem Messwert feststellen. (siehe byte13-17.png)
Start-Byte 'U': Hier werden Bytes 13&14 jede Minute um ungefähr 200 erhöht. alle 16 samples (also einmal die Stunde) wird der Wert hier wieder auf 0 zurückgesetzt und Bytes 15&16 werden um genau 1 inkrementiert.
Bei Paketen mit 21 Bytes, bilden Bytes 17&18 die Konstante 2310, während 19&20 einen zufälligen Wert zwischen 0 und 65535 abbilden.
Den Dump konnte ich relativ leicht mit der kaitai Web IDE in brauchbare Pakete parsen. Hier einmal die dazugehörige .ksy Datei:
1
meta:
2
id: station
3
file-extension: station
4
endian: le
5
seq:
6
- id: packets
7
type: packet
8
repeat: eos
9
types:
10
packet:
11
seq:
12
- id: start
13
type: u1
14
- id: temp
15
type: u2
16
17
- id: light_south
18
type: u2
19
- id: light_west
20
type: u2
21
- id: light_east
22
type: u2
23
- id: zero
24
type: u2
25
- id: flags #bits 1, 2, 3 used only 1, 2 for U packet
26
type: u1
27
- id: rain #only first bit ever changes (either 0 or 1)
28
type: u1
29
- id: data_a
30
type: u2
31
- id: data_b
32
type: u2
33
- id: long_a
34
type: u2
35
if: start == 0x55
36
- id: long_b
37
type: u2
38
if: start == 0x55
Bisher bin ich mir noch unschlüssig mit der skalierung der gemessenen Daten. Ich bin mir ziemlich sicher, dass die ByteOrder mit little-endian korrekt ist und die Daten als uint16 übertragen werden (bei der Temperatur denke ich wird es signed sein, kann dies aber aktuell noch nicht bestätigen).
Die Temperatur hat in der angehangenen Datei zwischen ~1400 bis ~1520 geschwankt, allerdings waren die Temperaturen in unserer Region zwischen 8° und 25°.
Bei dem Licht sieht das ganze ein wenig einfacher aus in meinen Augen. Der Minimalwert lag bei 200 und der Maximalwert bei 3886 (clipping). Hier würde ich einfach von einer linearen Skalierung ausgehen.
Leider konnte ich bisher noch nicht herausfinden, wie genau die Windgeschwindigkeit übertragen wird.
Ich hoffe irgendwer kann vielleicht noch ein wenig mehr informationen aus den Daten herausziehen.
Mit hilfe von Ki kostenlosen tools hast du das doch noch heute fix gelöst.
Ob ChatGPT das auch kann weiß ich nicht, aber es gibt genug darauf spezialisierte tools im Netzt
ChatGPT habe ich schon häufiger versucht. Der steigt leider bei der Datenmenge relativ schnell aus.
Welche anderen Tools könntest du in diese Richtung empfehlen?
Wenn das relativ schnell geht würde ich diese gerne mal auf meine Daten loslassen.
empfehlen kann ich da leider nichts, hab sowas selber nie genutzt, stelle mir nur vor, das es damit recht einfach sein müsste, da es genau ins Muster für eine Ki Analyse passt
Die Temperatur hat in der angehangenen Datei zwischen ~1400 bis ~1520
geschwankt, allerdings waren die Temperaturen in unserer Region zwischen
8° und 25°.
Der steigt leider bei der Datenmenge relativ schnell aus.
Dann konzentriere dich erstmal auf einen Parameter, statt "endlose" Logfiles zu erzeugen. Betreibe die Wetterstation bei kontrollierten Bedingungen, wo du bspw. nur die Temperatur oder nur die Beleuchtungsstärke änderst.
Dann konzentriere dich erstmal auf einen Parameter, statt "endlose"
Logfiles zu erzeugen. Betreibe die Wetterstation bei kontrollierten
Bedingungen, wo du bspw. nur die Temperatur oder nur die
Beleuchtungsstärke änderst.
Das hatte ich auch schon überlegt. Die Kontrolle über Messwerte wäre hier deutlich höher. Leider habe ich ein wenig Sorge, die Station nicht wieder an ihren aktuellen Ort zu bekommen. Sie ist bereits seit 20 Jahren auf dünnem Putz befestigt. Möchte ungern das Gerät bei der Montage beschädigen.
Ich werde ggf. einmal versuchen einzelne Messwerte (flags oder die unbekannten bytes) ChatGPT zur verfügung zu stellen. Vielleicht funktioniert das besser als alle Daten zu exportieren.
Sehr ungewöhnlich, das sollen möglicherweise 1200 Bd sein.
Damit hatte ich auch als erstes getestet. Bei 1200 Bd ist der Decoder nach wenigen Bytes nicht mehr komplett synchron. Zudem scheint der µC der Auswerteeinheit diese Geschwindigkeit recht gut abbilden zu können (Atmega 128-16AU bei UBRR ~884).
Gerade bei Licht wäre das relativ ungeschickt, weil die Dynamik recht
groß ist.
Würde eine logarithmische Skala hier eher passen? Sowohl logarithmisch als auch linear sehen auf den Plots recht sinnvoll aus, wobei logarithmisch ein wenig besser auf die Sonnenposition und Intensität passen würde.
Der Wertebereich könnte auch recht gut mit einem 12bit analogen Messwert übereinstimmen (0-4096, bzw. Sensoroutput zwischen 200-3886).
Eine logarithmische Skala ist bei großer Dynamik grundsätzlich das Mittel der Wahl.
Du könntest dir die Kennlinie von deiner Lichtmessung angucken, d.h. bei Dunkelheit mit künstlicher Lichtquelle beleuchten und messen, wie sich der Messwert mit dem Abstand zwischen Lichtquelle und Sensor ändert.
// Deklarationen für WS10 ( P00/P01 ) Wetterstation Daten lesen
3
4
#include<SoftwareSerial.h>
5
#define rxPin 05 // dieser ist wichtig zum lesen
6
#define txPin 18 // wird nicht verwendet
7
8
SoftwareSerialmySerial(rxPin,txPin);
9
10
boolnewData=false;
11
intnumReceived=0;
12
constintmaxDataBytes=13;// max 13 Bytes Daten zwichen den Markers
13
14
/* Umrechnung des erhaltenen numerischen ADC Aussentemp Wertes in
15
/ wirkliche Temperatur nach Formel
16
17
temp = m * ADC +d
18
*/
19
floatnewATemp;
20
21
structData_record_t{
22
int8_tAtemp_ADC;// -128 ... 127
23
int8_ttype;// ?
24
uint16_tSun1;
25
uint16_tSun2;
26
uint16_tSun3;
27
byteunc1;
28
byteunc2;
29
uint8_tWind;
30
uint8_train;// byte 11 0/1
31
uint8_tcrc;// unklar wie berechnet
32
};// sollte 13 Bytes lang sein -- ohne Startmarker "S"
33
34
35
// Create a union to easily access read data in bytes, by other format
36
typedefunion{
37
Data_record_tData_S;
38
byteData_B[maxDataBytes];
39
}Data_union_t;
40
41
Data_union_tData;
Ich habe es aber mittlerweile aufgegeben alle empfangenen Daten zu benutzen,
da ich es nicht geschafft habe sinnvolle Werte zu bekommen. Angefangen bei der Aussentemperatur. Mich hat eh als erste Prio nur der RAIN Sensor
interessiert.
Ich habe mit meinem ESP32 und einen neuen LCD jetzt eine WIFI fähige
Steuerung der WS10 welche an der PIN Leiste der WS10 angesteckt ist. Nur der Prozessor ist quasi ersetzt.
ich hatte vor über einem Jahr das Protokoll relativ weit ausgewertet. Folgenden Stand hab ich noch gefunden:
Byte
1 Start = 0x53 (ASCII 'S')
2 Temperatur LSB [(Wert - 1300) / 7 = °C]
3 Temperatur MSB
4 Helligkeit Süd LSB [(Wert - 200) / 37 = klx]
5 Helligkeit Süd MSB
6 Helligkeit West LSB
7 Helligkeit West MSB
8 Helligkeit Ost LSB
9 Helligkeit Ost MSB
10 Dezimal 100 in der Nacht, sonst 0
11
12 Wind [Wert / 3,6 = m/s]
13 Dezimal 1-7 bei Regen, sonst 0
14 Summe der Daten (8bit, Überlauf 256 = 0)
Die Tabelle mit meinen Aufzeichnungen und der Näherung der Werte hab ich einfach mal angehängt, ist etwas chaotisch. Es gibt für Sonne, Temperatur und Wind jeweils ein Tabellenblatt: "Wert" ist der empfangene Wert aus den Daten (MSB und LSB zusammengesetzt und als Dezimalwert), "Anzeige" ist der abgelesene Wert vom Display der Wintergartensteuerung, "Berechnet" war mein erster Versuch die Werte nachzurechnen, "Neu" ist mein aktueller Ansatz.
Irgendwo müsste ich auch noch eine funktionierende Tasmota SML Konfiguration haben...
Edit: und hier ist es:
D
B
=>sensor53 r
M 1
+1,4,r,0,1200,Außen
1,53uuUU@7-1300,Temperatur,°C,temp,1
1,53x2uuUU@37-208,Sonne Süd,klx,ssued,0
1,53x4uuUU@37-208,Sonne West,klx,swest,0
1,53x6uuUU@37-208,Sonne Ost,klx,sost,0
1,53x8uu@100,Nacht,,night,0
1,53x10uu@3.657,Wind,m/s,wind,1
1,53x11uu@1,Regen,,rain,0
So kann man es auch rechnen. /Wert/ ist dann vermutlich direkt die
Geschwindigkeit in km/h ;-)
Jein, ich hab dann in den späteren Versuchen gesehen, dass ein Faktor von 3,657 besser mit der tatsächlichen Anzeige übereinstimmt. Es kann natürlich auch ein gleitender Mittelwert o.ä. mitspielen.
Möchte nochmals der alten Thread hochholen, da ich eine Jalousiesteuerung mit Elsner WS1 und P00(P01?) reparieren müsste. Die Steuerung WS1 werde ich wohl nicht mehr aktivieren könne, aber die Wetterstation PS00 (oder PS01) scheint noch zu leben. Ich möchte wenn noch möglich einen eigeen einfache Steuerung mit der Wetterstation idealisieren.
Entgegen der Dokumentation die ich gefunden habe, sendet die Wetterstion via RS232 und nicht via RS485. Ich konnte sie an den PC anschließen und sehe Daten alle Sekunde. Elsner hat ein Wetterstation Tool (WetterstationCOM_13), aber ich kann da sehe ich keine Auswertung der Daten. Vermutlich passt es nicht mehr zu meine Wetterstion oder ich mache ein Fehler bei der Baudrate oder Auswahl.
Weiß jemand genau welche Einstellungen man mache muss für RS232 Verbindung? Ich habe 1200 Bd, 8N1 ausgewählt.
Nochmals , weiß jemand welche Einstellungen zum Elsner Tool passen
würden, wenn RS232 (0/5V) verwendet wird? Da nutzt mir mein Oszillokop
wenig.
Warum nützt dir dein Oszi da nichts? Da kannst du den Ruhepegel sehen, siehst, ob es RS232 oder TTL ist und die Baudrate kannst du auch berechnen. Also, frisch an's Werk und den Oszi angeschlossen! Und wenn man ein bisschen logisch denken kann, kann man vielleicht sogar das Protokoll entschlüsseln! Ich weiss, wovon ich rede. Habe vor Jahrzehnten das ELV-WS2000-Protokoll nur mit einem Speicheroszi entschlüsselt.
Ich sehe gutgemeinte Ratschläge, aber ich habe doch geschrieben, dass ich bereits Daten am PC sehen kann. Ich kenne die Baudrate (1200 Bd) und vermutlich 8N1.
Ich möchte wissen , ob man mit dem Elsner Tool und den dortigen Einstellungsmöglichkeiten die alte Wetterstation dekondieren kann,
bevor ich selber anfangen muss.
Ich weiß auch wovon ich red und bitte hier nochmals, nur Antworten auf gestellte Fragen zu posten. Aus alles andere verzichte ich gerne.
Das dass wieder kommt habe ich erwartet. Zur Klarstellung: Die Daten werden 1:1 aus dem Mikrocontroller über den UART ohne +-12V Wandler über das Kabel
übertragen.
@Peter
Danke für den Hinweis.
Deiner Beschreibung nach müssten 14 Byte gesendet werden, wenn ich es richtig gesehen habe. Bei mir sind es aber 17 Byte, das aber stabil.
Jein, ich hab dann in den späteren Versuchen gesehen, dass ein Faktor
von 3,657 besser mit der tatsächlichen Anzeige übereinstimmt.
Wie sicher bist du mit dem Faktor, d.h. welche Genauigkeit besitzt dieser Wert? Könnte es nicht 3,6 sein?
Eine Angabe zur Windgeschwindigkeit mit vier gültigen Stellen ist mehr als mutig.
Wie sicher bist du mit dem Faktor, d.h. welche Genauigkeit besitzt
dieser Wert? Könnte es nicht 3,6 sein?
Dazu müßte man wissen wie die Station den Wert ausgibt. Wenn es wie von Dir vermutet km/h sind, dann sind es genau 3,6. Kann man sich an Hand der Einheiten schnell selbst ausrechnen. Einen Wert von 3,657 gibt es bei keiner gängiger Umrechnung von Geschwindigkeiten.
Abweichend von km/h könnte die Ausgabe auch in m/h erfolgen, aber da wäre der Faktor kleiner als 3,6 da eine Meile deutlich mehr als ein Kilometer ist.
Eine Tabelle mit Umrechnungsfaktoren für Geschwindigkeiten gibt es hier https://www.unitjuggler.com/speed-umwandeln-von-kms-nach-ms.html.
Elsner ist ein deutscher Hersteller und der dürfte wohl eher metrisch verwenden. Der Umkehrschluß ist dann, das das Protokoll falsch entschlüsselt wurde und der vermeintliche Wert für Windgeschwindigkeit, selbige gar nicht repräsentiert.
Einen Wert von 3,657 gibt es bei keiner gängiger Umrechnung
von Geschwindigkeiten.
Aach - deswegen meine Frage an Peter, was das für eine komische Zahl ist und wie genau die wirklich ist. Eine Zahlenangabe ohne zusätzliche Angabe eines Fehlers impliziert in diesem Fall eine Genauigkeit von besser als 0,03% und das ist im Zusammenhang mit einer Windgeschwindigkeitsmessung nun einmal grober Unfug.
Eine Tabelle mit Umrechnungsfaktoren für Geschwindigkeiten gibt es hier
Zeit- und Längeneinheiten ineinander umzurechnen, ist nun wirklich nicht sooh kompliziert.
Der Umkehrschluß ist dann, das das Protokoll falsch entschlüsselt
wurde und der vermeintliche Wert für Windgeschwindigkeit, selbige gar
nicht repräsentiert.
Jein, ich hab dann in den späteren Versuchen gesehen, dass ein Faktor
von 3,657 besser mit der tatsächlichen Anzeige übereinstimmt.
Wie sicher bist du mit dem Faktor, d.h. welche Genauigkeit besitzt
dieser Wert? Könnte es nicht 3,6 sein?
Eine Angabe zur Windgeschwindigkeit mit vier gültigen Stellen ist mehr
als mutig.
Zur Entstehung der Umrechnungswerte: ich habe über mehrere Tage hinweg immer wieder die Kommunikation aufgezeichnet und die dazugehörigen Werte auf dem Display notiert. Dann das Ganze in Excel (bzw. Calc) gepackt und mir im Diagramm über eine Trendlinie die Funktion ausgeben lassen.
Was dabei nicht berücksichtigt ist, ist ein zeitlicher Versatz bzw. eine Mittelwertbildung zwischen Kommunikation und Anzeige.
Dann das Ganze in Excel (bzw. Calc) gepackt und
mir im Diagramm über eine Trendlinie die Funktion ausgeben lassen.
Deshalb meine Frage nach der statistischen Signifikanz. Was sagt das Bestimmtheitsmaß (R²) oder anders ausgedrückt: Wie groß ist die Genauigkeit der ausgewiesenen Geradenparameter, d.h. wie empfindlich reagiert die Abweichung zu den Messdaten (Gesamtfehler) auf den Steigungsparameter, über welchen Geschwindigkeitsbereich wurde die Trendlinie berechnet und welche Genauigkeit der Messwerte wurde zu Grunde gelegt (absolut/relativ)?
da ich jetzt eine Elsner WS1 mit Wetterstation für den Schreibtisch habe (Danke an botnec!) konnte ich die Erweiterung von 14 byte auf 17 byte Protokoll dekodieren:
Byte
1 Start = 0x53 (ASCII 'S')
2 Temperatur LSB
3 Temperatur MSB
4 Helligkeit Süd LSB
5 Helligkeit Süd MSB
6 Helligkeit West LSB
7 Helligkeit West MSB
8 Helligkeit Ost LSB
9 Helligkeit Ost MSB
10 Dezimal 0x64 (P01) bzw. 0x1F (P02) in der Nacht, sonst 0
11 ? bisher immer 0
12 Wind
13 Dezimal 1-7 bei Regen, sonst 0
14 Summe Byte 1 bis Byte 13 % 256
zusätzlich ab P02
15 Helligkeit LSB (direkt in Lux, max. 999 lx)
16 Helligkeit MSB
17 Summe Byte 1 bis Byte 16 % 256
weiter habe ich das ROM (UV EPROM 27C512) meiner WS20 ausgelesen, mit KI Hilfe disassembliert und die Berechnungen von Temperatur, Helligkeit und Wind nachvollzogen. Hier die Zusammenfassung als Pseudocode:
Temperatur:
raw = LSB + 256 * MSB
U = raw * 1.2207000256 / 1000.0
R = 3570.0 * U / (5.0 - U)
T0 = ((R - 2000.0) / 15.8) + 25.0 + TempOffset
T = T0 - (30.0 - T0) * 0.13, falls T0 < 30.0, sonst T0
Anzeige_C = round(T)
(TempOffset ist der im Menü einstellbare "Kalibrierwert")
Ich konnte hier eine WS20 mit "Sensorfehler" durch Austausch der 4 Kondensatoren nahe dem Trafo wiederbeleben. Dazu musst zwischenzeitlich die Displayanschlussleiste ausgeloetet werden.
