Windsensor

[Waldmensch]

Ich habe noch Sensoren aus der WS-7000 Serie. Diese habe ich auf 886MHZ umgebaut und sie funktionieren Super in FHEM. Dabei ist auch ein Windsensor mit Fahne, der folgenden Output liefert:

Code Auswählen Erweitern

2014-03-28 08:34:45 CUL_WS CUL_WS_8 W: 0 D: 345 A: 0
2014-03-28 08:34:45 CUL_WS CUL_WS_8 wind: 0
2014-03-28 08:34:45 CUL_WS CUL_WS_8 wind_direction: 345
2014-03-28 08:34:45 CUL_WS CUL_WS_8 wind_swing: 0
2014-03-28 08:34:45 CUL_WS CUL_WS_8 RSSI: -89
2014-03-28 08:34:45 CUL_WS CUL_WS_8 RAWMSG: K73005034

Log:

Code Auswählen Erweitern

2014-03-28_09:21:39 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:24:24 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:27:10 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:29:55 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:32:41 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:35:26 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:38:12 CUL_WS_8 W: 0 D: 270 A: 0
2014-03-28_09:43:43 CUL_WS_8 W: 2.4 D: 275 A: 0
2014-03-28_09:46:29 CUL_WS_8 W: 0 D: 275 A: 0
2014-03-28_09:49:14 CUL_WS_8 W: 0 D: 275 A: 0
2014-03-28_09:52:00 CUL_WS_8 W: 0.4 D: 280 A: 0

Die Windstärke kann ich mir in einem Diagramm auch anzeigen lassen. Allerdings hätte ich für die Windrichtung gern sowas wie eine Windrose. Der Winkel "D" wird von 0-360 übermittelt wobei Wind aus Süd 180 entspricht also aus Nord dann vermutlich 0

Hat jemand sowas schon mal umgesetzt oder gibt es sogar eine fertige Lösung?

[betateilchen]

Ja gibts. Sogar hier im Forum beschrieben. Kennst Du das Suchfeld oben rechts?

http://forum.fhem.de/index.php/topic,14327.0.html

[Waldmensch]

Ich kenne Die SuFu - habe aber vermutlich die falschen Begriffe verwendet. Der Beitrag sieht interessant aus.

[marvin78]

Vielleicht hast du auch nicht die falschen Begriffe verwendet, denn die Suchfunktion funktioniert nicht immer korrekt. Wenn du hier wirklich etwas finden möchtest, verwende google folgendermaßen

Code Auswählen Erweitern

site:forum.fhem.de SUCHBEGRIFF

[betateilchen]

denn die Suchfunktion funktioniert nicht immer korrekt.

Doch, tut sie. Man muss aber folgendes berücksichtigen (was von vielen Leuten missachtet wird!):

Sie sucht immer in dem Bereich, in dem Du gerade stehst. Also wenn Du jetzt diesen Beitrag liest und dann oben rechts einen Suchbegriff eingibst, wird der nur im Unterforum "SlowRF" (und eventuell darunter befindlichen Unterforen) gesucht.

Deshalb empfiehlt es sich, vor einer Suche immer in den Bereich zu wechseln, in dem man suchen will. Wenn man vor der Suche die "Übersicht" auswählt, wird das gesamte Forum durchsucht.

[marvin78]

Mal ab gesehen davon, dass diese Funktionweise für eine globale Suche (und das wird bei einem Suchfeld über einem Forum impliziert) quatsch ist, stimmt das auch nicht immer. Hin und wieder wird die Suche auch über den Bereich hinaus ausgeführt und beim nächsten mal wieder eingeschränkt. Ich denke, dass das an einem nicht korrekt funktionierenden Suchindex liegt. Leider ist der Fehler aber offenbar nicht reproduzierbar. Ich suche häufig aus den ungelesenen Beiträgen oder aus der Übersicht heraus und finde oft erst beim zweiten Suchlauf was ich suche.

Und sorry aber diese Funktionsweise eines Suchfeldes, welches über einen Forum angeordnet ist, ist quatsch und alles andere als intuitiv. Ich betreibe mehrere Foren (unter anderem ein selbst programmiertes) und soetwas würde mir nie einfallen. Für eine Suche in einem bestimmten Bereich gibt es die erweiterte Suche.

Nichts desto trotz führt die Google-Suche in jedem Fall schneller und sicherer ans Ziel da sie, unter anderem, in der Lage ist, auch Typos zu korrigieren.

[Waldmensch]

Um nochmal zum Thema zu kommen - ich habe aus der gleichen WS7000 Serie noch einen Regenmengensensor WS 7000-16 (son runder Kübel mit Wippe drin http://www.schelli.at/wetterst.htm) Dieser ist ebenfalls auf 886MHZ umgebaut. Leider ist der auf dem Dach wo ich so schnell nicht rankomme. Es könnte sein, das er nicht mehr sendet.

Falls er doch noch senden sollte, wie bekomme ich das mit? FHEM hat bisher noch nichts über autocreate angelegt. Das kann aber auch die Ursache haben, das der Sensor nicht unterstützt wird, außerhalb des Empfang ist oder die Adresse eine Andere überlagert. Da der Windsensor erfolgreich erkannt wird, gehe ich davon aus das das Protokoll kein problem sein sollte.

Gibt es in FHEM einen Modus bei dem man nur unbekannte Messages darstellen kann? Falls der Sensor sendet und halt nur nicht unterstützt ist würde man ihn da ja entdecken.

[Puschel74]

Hallo,

oder die Adresse eine Andere überlagert.

Dann solltest du im Plot "Sprünge" erkennen können.
Einmal der Wert des einen Sensors und einmal der Wert des anderen.
Das würde mich aber wundern.

Dieser ist ebenfalls auf 886MHZ umgebaut.

Das alleine sagt noch nichts aus - es muss u.a auch das Protokoll stimmen.

Grüße

[JoWiemann]

Hallo,

der Umbau würde mich interessieren und ich würde mich über eine Beschreibung freuen. Danke Dir.

Jörg

[Waldmensch]

Hallo,

der Umbau würde mich interessieren und ich würde mich über eine Beschreibung freuen. Danke Dir.

Jörg

Also der Umbau ist völlig unspektakulär. Du besorgst dir den Billigsten 886Mhz Sender den du kriegen kannst (defekter FHT88 oder so) und lötest ihn statt dem 443Mhz Sender ein. FHEM erkennt den Sensor von allein und ordnet ihn unter WS7000 ein

Windsensor:

Code Auswählen Erweitern

Internals:
   CODE       8
   DEF        8
   IODev      CUL_0
   NAME       CUL_WS_8
   NR         151
   STATE      W: 0 D: 165 A: 0
   TYPE       CUL_WS
   corr1      0
   corr2      0
   corr3      0
   corr4      0
   Readings:
     2014-03-29 11:28:29   DEVFAMILY       WS7000
     2014-03-29 11:28:29   DEVTYPE         Wind
     2014-03-29 11:28:29   state           W: 0 D: 165 A: 0
     2014-03-29 11:28:29   wind            0
     2014-03-29 11:28:29   wind_direction  165
     2014-03-29 11:28:29   wind_swing      0
Attributes:
   alias      Sensor Wind
   room       CUL_WS

Einziges Problem ist, das der WS7000-20 (innensensor T/H/P) unter der selben ID 8 sendet. Wenn ich die Jumper intern umsetze wird er aber nicht mehr als T/H/P erkannt sondern so:

Code Auswählen Erweitern

Internals:
   CODE       6
   CUL_0_MSGCNT 3
   CUL_0_RAWMSG K543142351398
   CUL_0_RSSI -61
   CUL_0_TIME 2014-03-29 14:37:41
   DEF        6
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     3
   NAME       CUL_WS_6
   NR         154
   STATE      T: 23.1  H: 35.4
   TYPE       CUL_WS
   corr1      0
   corr2      0
   corr3      0
   corr4      0
   Readings:
     2014-03-29 14:37:41   DEVFAMILY       WS7000
     2014-03-29 14:37:41   DEVTYPE         TH5
     2014-03-29 14:37:41   humidity        35.4
     2014-03-29 14:37:41   state           T: 23.1  H: 35.4
     2014-03-29 14:37:41   temperature     23.1
Attributes:
   alias      Sensor Flur
   room       CUL_WS

Dann habe ich den Windsensor und den Innensensor zwar getrennt, aber ohne Luftdruck. Lasse ich den WS7000-20 "ungejumpert" laufen die Werte unter einem Sensor auf. Ich habe mir beholfen indem ich 2 Logfiles erstelle und damit die Sensordaten auseinanderklamüsere. Einmal mit T:.* den Temperatursensor und mit W:.* den Windsensor

Code Auswählen Erweitern

define CUL_WS_8 CUL_WS 8
attr CUL_WS_8 alias Sensor WS7000
attr CUL_WS_8 room CUL_WS

define FileLog_CUL_WS_8a FileLog ./log/CUL_WS_8a-%Y.log CUL_WS_8:T:.*
attr FileLog_CUL_WS_8a alias Log Sensor Flur
attr FileLog_CUL_WS_8a logtype temp4hum6:Temp/Hum,text
attr FileLog_CUL_WS_8a room CUL_WS

define FileLog_CUL_WS_8b FileLog ./log/CUL_WS_8b-%Y.log CUL_WS_8:W:.*
attr FileLog_CUL_WS_8b alias Log Sensor Wind
attr FileLog_CUL_WS_8b logtype temp4hum6:Temp/Hum,text
attr FileLog_CUL_WS_8b room CUL_WS

define SVG_CUL_WS_8a SVG FileLog_CUL_WS_8a:SVG_CUL_WS_8a:CURRENT
attr SVG_CUL_WS_8a label "CUL_WS_8 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_CUL_WS_8a room Plots

define SVG_CUL_WS_8b SVG FileLog_CUL_WS_8b:SVG_CUL_WS_8b:CURRENT
attr SVG_CUL_WS_8b label "CUL_WS_8 Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_CUL_WS_8b room Plots


Edit: Bild von WS7000-20 @ 886Mhz angefügt

[betateilchen]

Einziges Problem ist, das der WS7000-20 (innensensor T/H/P) unter der selben ID 8 sendet. Wenn ich die Jumper intern umsetze wird er aber nicht mehr als T/H/P erkannt

Logisch.

Die Typerkennung (beispielsweise T/H oder T/H/P)erfolgt anhand von zwei Bytes aus der empfangenen Nachricht. Die leiten sich u.a. aus der Hardwareadresse ab. Wenn Du also die Hardwareadresse änderst, kommen bei der Typerkennung andere Bytes raus und die führen zu einer falschen Einordnung Deines Sensors.

[Waldmensch]

Danke für die Erklärung. Also ist meine Herangehensweise mit dem Log aufsplitten schon die Richtige? (wenn ich den Luftdruck haben möchte) Oder kann ich den die 14_CUL_WS.pm irgendwie überlisten? Das mit dem Aufsplitten sorgt ja für vernünftige Charts und die Readings enthalten die Werte von beiden Sensoren, wenn man mal vom "state" absieht, der immer wechselt. Aber wenn man das berücksichtigt und im weiteren Verlauf nur auf die Einzelwerte zugreift ist das ja kein Problem.

Code Auswählen Erweitern

   Readings:
     2014-03-29 15:43:17   DEVFAMILY       WS7000
     2014-03-29 15:43:17   DEVTYPE         Indoor
     2014-03-29 15:43:17   humidity        36.5
     2014-03-29 15:43:17   pressure        1012
     2014-03-29 15:43:17   state           T: 22.8  H: 36.5  P: 1012
     2014-03-29 15:43:17   temperature     22.8
     2014-03-29 15:39:31   wind            0
     2014-03-29 15:39:31   wind_direction  165
     2014-03-29 15:39:31   wind_swing      0

[betateilchen]

ich verstehe nicht, warum Du überhaupt zwei Logfiles brauchst?

[Waldmensch]

ich verstehe nicht, warum Du überhaupt zwei Logfiles brauchst?

Ich bin nicht so der Profi im SVG Chart erstellen aber dachte mir, das es Probleme bei den Spalten gibt wenn das Log so aussieht

Code Auswählen Erweitern

2014-03-29_14:54:51 CUL_WS_8 T: 23.6  H: 36.4  P: 1013
2014-03-29_14:55:23 CUL_WS_8 W: 0 D: 165 A: 0
2014-03-29_14:57:33 CUL_WS_8 T: 23.5  H: 36.3  P: 1013
2014-03-29_14:58:08 CUL_WS_8 W: 0 D: 165 A: 0
2014-03-29_15:00:14 CUL_WS_8 T: 23.4  H: 36.3  P: 1013
2014-03-29_15:00:54 CUL_WS_8 W: 0 D: 165 A: 0
2014-03-29_15:02:55 CUL_WS_8 T: 23.4  H: 36.3  P: 1013

[betateilchen]

Die Zeilen sind doch eindeutig unterscheidbar, da sollte es keine Probleme geben. Gib mir mal 10 Minuten, ich bau mal was.

[betateilchen]

Kannst Du mal bitte ein Log von 30 Minuten posten, in dem beide Zeilen drin sind?

Grundsätzlich sieht das im PlotEditor so aus:

(http://up.picr.de/17797734zt.jpg)

Ok, Achsenbeschriftung ist jetzt noch nicht definiert, aber es lassen sich alle 6 Werte eindeutig identifizieren und plotten:

(http://up.picr.de/17797746mn.jpg)

[Waldmensch]

Ich habe mal so ein Kombi Log mit ./log/CUL_WS_8all-%Y.log CUL_WS_8:(T|W):.* erstellt - es muß aber erst noch ne Weile laufen. Mehr als den Schnipsel von vorhin habe ich derzeit nicht.

Edit: Alles in ein Chart ist aber sowieso doof weil sich Druck (1000++), Winkel (0-360), Feuchte(0-100%), Temperatur (-20- +40) kaum sauber und lesbar darstellen lassen

[betateilchen]

Doch, das kann man durchaus sinnvoll darstellen. Man kann nämlich bei Bedarf auch mehr als zwei y-Achsen definieren.

(http://up.picr.de/17798049fh.jpg)

Wart mal ab, bis ich ein paar Werte mehr von Dir habe.

Bei mir wird z.B. der Luftdruck auf der Feuchtigkeitsachse abgebildet, dazu ziehe ich beim Plotten einfach 950 vom aktuellen Luftdruck ab, dann kommen Werte von 0-100 raus, weil der Luftdruck sich immer im Bereich 950-1050 bewegt. Und die Werte von 0-100 passen genau zur y-Achse für die Humidity, die auch 0-100 verwendet.

[justme1968]

und mit nrAxis kann man die zusätzlichen achsen sogar rechts und links vom plot anzeigen.

gruss
  andre

[rabbe]

Danke für die Erklärung. Also ist meine Herangehensweise mit dem Log aufsplitten schon die Richtige? (wenn ich den Luftdruck haben möchte) Oder kann ich den die 14_CUL_WS.pm irgendwie überlisten? Das mit dem Aufsplitten sorgt ja für vernünftige Charts und die Readings enthalten die Werte von beiden Sensoren, wenn man mal vom "state" absieht, der immer wechselt. Aber wenn man das berücksichtigt und im weiteren Verlauf nur auf die Einzelwerte zugreift ist das ja kein Problem.

Code Auswählen Erweitern

   Readings:
     2014-03-29 15:43:17   DEVFAMILY       WS7000
     2014-03-29 15:43:17   DEVTYPE         Indoor
     2014-03-29 15:43:17   humidity        36.5
     2014-03-29 15:43:17   pressure        1012
     2014-03-29 15:43:17   state           T: 22.8  H: 36.5  P: 1012
     2014-03-29 15:43:17   temperature     22.8
     2014-03-29 15:39:31   wind            0
     2014-03-29 15:39:31   wind_direction  165
     2014-03-29 15:39:31   wind_swing      0

Bei mir ist es ähnlich. Ich habe

Code Auswählen Erweitern

attr CUL_WS_8 stateFormat T: temperature H: humidity P: pressure D: dewpoint
gesetzt.
Ich habe zusätzlich noch einen Regensensor auf der ID8. Das CUL_WS-Modul unterstützt nur das 1.2-Sendeprotokoll http://www.dc3yc.privat.t-online.de/protocol.htm. Es könnte durchaus sein, dass dein Regensensor noch das (alte) 1.1er http://www.dc3yc.privat.t-online.de/protocol_alt.htm benutzt.

[betateilchen]

@rabbe und was hat das mit der aktuellen Plot-Frage zu tun?


@andre ja, kann man schon. Aber irgendwann wird mir dann der Plotbereich zu klein Deshalb versuche ich immer, die Werte zu "normalisieren

[rabbe]

@rabbe und was hat das mit der aktuellen Plot-Frage zu tun?

Er hatte vorher (auf Seite 1 des Themas) die Frage mit dem Regensensor gestellt

Um nochmal zum Thema zu kommen - ich habe aus der gleichen WS7000 Serie noch einen Regenmengensensor WS 7000-16 (son runder Kübel mit Wippe drin http://www.schelli.at/wetterst.htm) Dieser ist ebenfalls auf 886MHZ umgebaut. Leider ist der auf dem Dach wo ich so schnell nicht rankomme. Es könnte sein, das er nicht mehr sendet.

Falls er doch noch senden sollte, wie bekomme ich das mit? FHEM hat bisher noch nichts über autocreate angelegt. Das kann aber auch die Ursache haben, das der Sensor nicht unterstützt wird, außerhalb des Empfang ist oder die Adresse eine Andere überlagert. Da der Windsensor erfolgreich erkannt wird, gehe ich davon aus das das Protokoll kein problem sein sollte.

Gibt es in FHEM einen Modus bei dem man nur unbekannte Messages darstellen kann? Falls der Sensor sendet und halt nur nicht unterstützt ist würde man ihn da ja entdecken.

und anschließend noch die Sache mit dem wechselnden Status angemerkt. Die Frage war meines Wissens noch nicht beantwortet.
Achso. Äußerlich erkennt man die (alten) 1.1er Sensoren an der aufgedruckten BAKOM-Nummer. Bei den (neuen) 1.2ern fehlt diese.

[justme1968]

ich weiss schon das du die zusätzlichen achsen nichts magst

klar ist manchmal nicht genug platz. zumindest wenn man die plots ins dashboard oder ähnliches packt. auf den normalen seiten ist aber immer sehr viel platz neben den plots so das man sie mit plotsize auch breiter machen kann.

[betateilchen]

jaja, schon gut.

(Gilt für beide vorangegangenen Antworten)

muss mich nebenbei noch um was anderes kümmern

(http://up.picr.de/17798291oz.jpg)

[rabbe]

Sieht lecker aus.

[Waldmensch]

@rabbe: vielen Dank für die Infos - ich glaub ich muß dann doch mal aufs Dach

Kannst Du mir eine Zeile vom Regensensor Log besorgen? Nicht das er nur vom Regex verworfen wird, weil er nicht mit W:.* oder T:.* anfängt.

hier ist mal das was jetzt schon aufgelaufen ist mit regex (W|T):.*

Code Auswählen Erweitern

2014-03-29_16:18:16 CUL_WS_8 T: 22.4  H: 36.9  P: 1012
2014-03-29_16:20:54 CUL_WS_8 W: 0.3 D: 165 A: 0
2014-03-29_16:20:58 CUL_WS_8 T: 22.5  H: 36.9  P: 1012
2014-03-29_16:23:39 CUL_WS_8 W: 0.4 D: 160 A: 0
2014-03-29_16:23:39 CUL_WS_8 T: 22.4  H: 37  P: 1012
2014-03-29_16:26:21 CUL_WS_8 T: 22.4  H: 37  P: 1012
2014-03-29_16:26:25 CUL_WS_8 W: 0.4 D: 160 A: 0
2014-03-29_16:29:04 CUL_WS_8 T: 22.4  H: 37  P: 1012
2014-03-29_16:31:44 CUL_WS_8 T: 22.4  H: 37  P: 1012
2014-03-29_16:37:07 CUL_WS_8 T: 22.4  H: 37.1  P: 1012
2014-03-29_16:37:27 CUL_WS_8 W: 0 D: 160 A: 0
2014-03-29_16:39:49 CUL_WS_8 T: 22.3  H: 37.2  P: 1012
2014-03-29_16:40:12 CUL_WS_8 W: 0 D: 160 A: 0
2014-03-29_16:42:30 CUL_WS_8 T: 22.3  H: 37.2  P: 1012
2014-03-29_16:42:58 CUL_WS_8 W: 0.4 D: 160 A: 0
2014-03-29_16:45:12 CUL_WS_8 T: 22.4  H: 37.2  P: 1012
2014-03-29_16:45:43 CUL_WS_8 W: 0 D: 160 A: 0
2014-03-29_16:47:53 CUL_WS_8 T: 22.4  H: 37.1  P: 1012
2014-03-29_16:48:29 CUL_WS_8 W: 0 D: 160 A: 0
2014-03-29_16:53:16 CUL_WS_8 T: 22.3  H: 37  P: 1012
2014-03-29_16:54:00 CUL_WS_8 W: 0.1 D: 160 A: 0
2014-03-29_16:55:58 CUL_WS_8 T: 22.3  H: 37  P: 1012
2014-03-29_16:58:39 CUL_WS_8 T: 22.3  H: 37.1  P: 1012
2014-03-29_16:59:31 CUL_WS_8 W: 0.1 D: 165 A: 0
2014-03-29_17:01:21 CUL_WS_8 T: 22.3  H: 37.1  P: 1012
2014-03-29_17:02:16 CUL_WS_8 W: 0 D: 165 A: 0
2014-03-29_17:04:02 CUL_WS_8 T: 22.3  H: 37.1  P: 1012
2014-03-29_17:05:02 CUL_WS_8 W: 0 D: 165 A: 0
2014-03-29_17:06:44 CUL_WS_8 T: 22.3  H: 37.1  P: 1012
2014-03-29_17:07:47 CUL_WS_8 W: 1 D: 165 A: 0
2014-03-29_17:09:25 CUL_WS_8 T: 22.3  H: 37.1  P: 1012

[betateilchen]

ergibt folgenden Plot:

(http://up.picr.de/17798441qe.jpg)

W und A sind immer 0, weil Du da noch keine Werte hast - bzw: weil die Werte immer 0 sind, werden sie am unteren Rand geplottet.

Hier das zugehörige gplot-File:

Code Auswählen Erweitern


# Created by FHEM/98_SVG.pm, 2014-03-29 16:10:26
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics
set y2tics
set grid
set ylabel "Temperatur"
set y2label "Feuchtigkeit"
set y2range [0:100]
set y3label "Druck hPa"
set y3range [950:1050]
set y4label "Richtung"
set y4range [0:360]

#FileLog 4:CUL_WS_8.T\x3a::
#FileLog 6:CUL_WS_8.T\x3a::
#FileLog 8:CUL_WS_8.T\x3a::
#FileLog 4:CUL_WS_8.W\x3a::
#FileLog 6:CUL_WS_8.W\x3a::
#FileLog 8:CUL_WS_8.W\x3a::

plot "<IN>" using 1:2 axes x1y1 title 'T' ls l0 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'H' ls l1 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y3 title 'P' ls l2 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'W' ls l3 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y4 title 'D' ls l4 lw 1 with lines,\
     "<IN>" using 1:2 axes x1y2 title 'A' ls l5 lw 1 with lines



[rabbe]

@rabbe: vielen Dank für die Infos - ich glaub ich muß dann doch mal aufs Dach

In einem anderen Thread vor ein paar Tagen hatte ich schon einmal ein Bild angehängt. http://forum.fhem.de/index.php/topic,21807.0.html

Code Auswählen Erweitern

2014-03-09_13:46:37 CUL_WS_8 R: 25

[Franz Tenbrock]

Hallo kann man ev auch andere Windsensoren umbauen? Worauf müßte man achten?

[Waldmensch]

Hallo kann man ev auch andere Windsensoren umbauen? Worauf müßte man achten?

Na das Protokoll muß halt unterstützt sein vom FHEM. Das ist ja beim WS7000 gegeben, nur halt auf 443Mhz. Wenn das Datenpaket über eine andere Frequenz reinkommt ist es ja wurscht, solange das Paket an sich aufgeschlüsselt werden kann. Ich habe die WS7000 Sensoren noch aus einem Komplettpaket mit der ELV Wetterstation mit Touchscreen. Das Teil ist irgendwann mal verstorben. Ich habe dann alle Sensoren umgebaut um sie mit einer ebenfalls umgebauten PC-WS2500 und weiteren 886Mhz Sensoren zu loggen. Das Projekt ist aber mit dem Tod meines Servers eingeschlafen. Nun hat sich durch Zufall der WS7000-20 aus der Abstellkammer bei FHEM angemeldet (dank 8dbi Antenne am COC zufällig ein Paket eingefangen und autocreate hat ihn zugefügt) Da habe ich halt den Windsensor mal in die Sonne gelegt (Solarzelle) und schwups war er auch da. Wie gesagt, das WS7000 System wird eh unterstützt, auf 443. Aber halt auch auf 886 nach Umbau. Allerdings wird es sicher billiger einen 443 CUL zu nehmen als 886er Sender für alle Sensoren zu beschaffen.

[Waldmensch]

Ich habe hier eine Meldung im Log - kann jemand was damit anfangen?

Code Auswählen Erweitern

2014.03.30 01:32:47 1: CUL_WS Cannot decode K8122E

[JoWiemann]

Hallo,

vielen Dank für die Umbauinfo. Ich habe selber einfach zu aufwändig gedacht. Einfacher Austausch fühlte sich zu einfach an. 

Grüße Jörg