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:
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:
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?
Ja gibts. Sogar hier im Forum beschrieben. Kennst Du das Suchfeld oben rechts?
http://forum.fhem.de/index.php/topic,14327.0.html
Ich kenne Die SuFu - habe aber vermutlich die falschen Begriffe verwendet. Der Beitrag sieht interessant aus.
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
site:forum.fhem.de SUCHBEGRIFF
Zitat von: marvin78 am 28 März 2014, 12:20:45denn 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.
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.
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.
Hallo,
Zitatoder 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.
ZitatDieser ist ebenfalls auf 886MHZ umgebaut.
Das alleine sagt noch nichts aus - es muss u.a auch das Protokoll stimmen.
Grüße
Hallo,
der Umbau würde mich interessieren und ich würde mich über eine Beschreibung freuen. Danke Dir.
Jörg
Zitat von: JoWiemann am 29 März 2014, 12:59:57
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:
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_WSEinziges 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:
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_WSDann 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
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 PlotsEdit: Bild von WS7000-20 @ 886Mhz angefügt
Zitat von: Waldmensch am 29 März 2014, 15:14:41
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.
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.
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
ich verstehe nicht, warum Du überhaupt zwei Logfiles brauchst?
Zitat von: betateilchen am 29 März 2014, 15:55:50
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
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
Die Zeilen sind doch eindeutig unterscheidbar, da sollte es keine Probleme geben. Gib mir mal 10 Minuten, ich bau mal was.
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)
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
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.
und mit nrAxis kann man die zusätzlichen achsen sogar rechts und links vom plot anzeigen.
gruss
andre
Zitat von: Waldmensch am 29 März 2014, 15:46:15
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.
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
attr CUL_WS_8 stateFormat T: temperature H: humidity P: pressure D: dewpointgesetzt.
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.
@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
Zitat von: betateilchen am 29 März 2014, 16:52:36
@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
Zitat von: Waldmensch am 29 März 2014, 10:47:01
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.
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.
jaja, schon gut.
(Gilt für beide vorangegangenen Antworten)
muss mich nebenbei noch um was anderes kümmern ;)
(http://up.picr.de/17798291oz.jpg)
Sieht lecker aus.
@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):.*
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
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:
# 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
Zitat von: Waldmensch am 29 März 2014, 17:12:46
@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
2014-03-09_13:46:37 CUL_WS_8 R: 25
Hallo kann man ev auch andere Windsensoren umbauen? Worauf müßte man achten?
Zitat von: Franz Tenbrock am 29 März 2014, 19:12:16
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.
Ich habe hier eine Meldung im Log - kann jemand was damit anfangen?
2014.03.30 01:32:47 1: CUL_WS Cannot decode K8122E
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