Wetterstation-Protokoll

[Joerg (Gast)]

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

[gaast (Gast)]

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.

[Joerg (Gast)]

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.

[Joerg (Gast)]

Push!
@Admin: Danke fürs verschieben.

[Joerg D. (int2k)]

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:

10100011/01111001/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/11111100/00110101/0/00011101/
10100011/01111110/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/00000001/00101101/0/00101111/
10100011/10000011/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/00001110/00111101/0/01000001/
10100011/10000101/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/00011000/00111101/0/01001101/
10100011/10011000/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/00011011/00111101/0/01011011/
10100011/10011101/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/00100000/00110101/0/01101101/
10100011/10011110/00000101/10011000/0/10011000/0/10011000/0/0/0/00100011/0/00100001/00110101/0/01101111/

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 !

[Rainer S. (rsonline)]

Joerg D. schrieb:
> - Das Low ein anderes Timing als High hat, irritiert mich schon
> massivst.

Hat vielleicht mit 1,5 Stopbits oder ähnlich zu tun.

[asdf (Gast)]

Joerg schrieb:
> ich habe hier eine Wetterstation herumliegen,

Welche? Hersteller und genaue Bezeichnung? Foto?

[Joerg D. (int2k)]

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

[Joerg D. (int2k)]

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) ?

1010011/1101111/101/11001000/0/11001000/0/11001000/0/0/0/10011001/1/10111001/100001/0/10010011

Hat denn bisher niemand diese Elsner-Wetterstation im Einsatz ?

[Roland (roliwa)]

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

[.● Des|ntegrator ●. (Firma: FULL PALATINSK) (desinfector)]

in der Zwischenzeit sind 4 weitere Wetterstationen verrostet.

[Joerg D. (int2k)]

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.

vy 73
 Jörg

[Roland (roliwa)]

HAllo Jörg,

 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.

[Roland (roliwa)]

Mit welcher Hardware/Software hast du diese Signale aufgenommen ?

Könnte dann es bei mir auch mal versuchen.

[Fabian (virusbear)]

Hallo zusammen,

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:

meta:
  id: station
  file-extension: station
  endian: le
seq:
  - id: packets
    type: packet
    repeat: eos
types:
  packet:
    seq:
      - id: start
        type: u1
      - id: temp
        type: u2
        
      - id: light_south
        type: u2
      - id: light_west
        type: u2
      - id: light_east
        type: u2
      - id: zero
        type: u2
      - id: flags #bits 1, 2, 3 used only 1, 2 for U packet
        type: u1
      - id: rain #only first bit ever changes (either 0 or 1)
        type: u1
      - id: data_a
        type: u2
      - id: data_b
        type: u2
      - id: long_a
        type: u2
        if: start == 0x55
      - id: long_b
        type: u2
        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.

[Mairian (marianp)]

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

[Fabian (virusbear)]

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.

[Mairian (marianp)]

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

[Rainer W. (rawi)]

Fabian schrieb:
> ich hoffe ich bin nicht all zu spät zu diesem Thema.

Der Thread ist über 13 Jahre alt. Da kommt es auf ein paar Monate 
wirklich nicht drauf an.

Fabian schrieb:
> Die Temperatur hat in der angehangenen Datei zwischen ~1400 bis ~1520
> geschwankt, allerdings waren die Temperaturen in unserer Region zwischen
> 8° und 25°.

Fabian schrieb:
> 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.

Fabian schrieb:
> simples UART mit einer Baudrate von 1130 einschränken

Sehr ungewöhnlich, das sollen möglicherweise 1200 Bd sein.

Fabian schrieb:
> Hier würde ich einfach von einer linearen Skalierung ausgehen.

Gerade bei Licht wäre das relativ ungeschickt, weil die Dynamik recht 
groß ist.

[Fabian (virusbear)]

Rainer W. schrieb:
> 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.

Rainer W. schrieb:
> 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).

Rainer W. schrieb:
> 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).

[Rainer W. (rawi)]

Fabian schrieb:
> Würde eine logarithmische Skala hier eher passen?

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.