Jeelik Modul zur Einbindung von La Crosse!

[Prof. Dr. Peter Henning]

Nun ja, bei der WS2800 sind sowohl Anemometer TX56 als auch Pluviometer TX57 über Funk angeschlossen - laut Doku aber eben nicht an die Zentrale. Sie müssen wirklich erst mit dem Außenthermometer TX59 gepaart werden, dieses wird dann von der Zentrale gelesen. Und die Zentrale wird von einem PC ebenfalls per Funk abgefragt.

@HCS: Mit "dokumentiert" meine ich: "Code verfügbar, kommentiert und erläutert" ? So dass jemand anders etwas damit anfangen kann ?

LG

pah

[HCS]

@HCS: Mit "dokumentiert" meine ich: "Code verfügbar, kommentiert und erläutert" ? So dass jemand anders etwas damit anfangen kann ?

Code verfügbar:
hier -> http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip

Kommentiert und erläutert:
Die Protokolle sind teilweise im Quellcode dokumentiert:
Beispiel:

Code Auswählen Erweitern

/*
* Message Format:
*
* .- [0] -. .- [1] -. .- [2] -. .- [3] -. .- [4] -.
* |       | |       | |       | |       | |       |
* SSSS.DDDD DDN_.TTTT TTTT.TTTT WHHH.HHHH CCCC.CCCC
* |  | |     ||  |  | |  | |  | ||      | |       |
* |  | |     ||  |  | |  | |  | ||      | `--------- CRC
* |  | |     ||  |  | |  | |  | |`-------- Humidity
* |  | |     ||  |  | |  | |  | |
* |  | |     ||  |  | |  | |  | `---- weak battery
* |  | |     ||  |  | |  | |  |
* |  | |     ||  |  | |  | `----- Temperature T * 0.1
* |  | |     ||  |  | |  |
* |  | |     ||  |  | `---------- Temperature T * 1
* |  | |     ||  |  |
* |  | |     ||  `--------------- Temperature T * 10
* |  | |     | `--- new battery
* |  | `---------- ID
* `---- START = 9
*
*/

So dass jemand anders etwas damit anfangen kann:
Wenn man C++, Arduino, RFM12/RFM69 usw. kann, dann sollte man etwas damit anfangen können


Generell: Ich implementiere aktuell in den Sketch exakt die WS 1600 (TX22). Das wird aber etwas dauern, da der TX22 in den oben angehängten Files recht "wüst" in die Hauptroutine reingepackt wurde (was die Leistung, das Protokoll zu anlaysieren, nicht schmälern soll, vielen Dank, das war tolle Arbeit) und ich das, wie alle bisher implementierten Sensoren, in eine modularisierte Form bringen werde.
In dem Sketch funktionieren z.B. die 9.579 kbps Sensoren (z.B. TX35) nicht mehr. Das bedeutet einiges an Arbeit und wird wohl 1-2 Wochen dauern.

Und dann muss auch noch an dem JeeLink und dem LaCrosse Modul etwas getan werden, oder gar ein weiteres Modul her, da ich erst mal klar sehen muss, ob es sinnvoll ist, die WS 1600 Daten im LaCrosse Modul zu handhaben oder besser sonstwo. Liest eigentlich justme1968 hier noch mit? Würde gerne mit Dir den Plan für die FHEM-Module abstimmen.

[justme1968]

ich bin da

mehrere module wären zwar sauberer aber der modul spezifische teil ist im vergleich zum overhead meist winzig. ich weiss nicht ob es sich lohnt.

was ich aber auf jeden fall machen würde ist den protokoll spezifische teil für jeden sensor in eine eigene routine auslagern und nicht alles direkt in der parse routine zusammen mischen.

man könnte parse routine dann einen allgemeinen hash aus reading und werte paaren zurück liefern lassen und so alles recht generisch halten.

gruss
  andre

[Prof. Dr. Peter Henning]

Wenn man C++, Arduino, RFM12/RFM69 usw. kann, dann sollte man etwas damit anfangen können

Sehn wir mal, was ich so drauf habe...

Ich würde tatsächlich gerne den TX56 und TX57 einbinden (und die doofe Zentrale sowie ggf. das Außenthermometer) auf den Müll werfen.


LG

pah

[aroesler]

Moin,

eventuell lande ich jetzt etwas off-topic - muss gestehen, nicht den gesamten Thread studiert zu haben. Weil aber eingangs nach Regensensoren gefragt wurde: Ich habe mal ein WS-9004-IT (http://www.amazon.de/Technoline-WS-9004-IT-Regenmesser-gr%C3%BCn-Mehrfarbig/dp/B001ALPF1M/ref=cm_cr_pr_product_top) gewonnen. Der beiliegende Regensensor heißt TX24-IT, auf der Packung steht iT+. Mein JeeLink findet zwar meine Temperatur und Luftfeuchtesensoren, den Regensensor ignoriert er aber.

Hat einer von Euch damit schon Erfahrungen gesammelt? Hier im Forum konnte ich nichts helfendes identifizieren.

Viele Grüße



Andreas

[HCS]

@justme1968: habe mich nun doch entschlossen, ein eigenes modul (36_ITPlusWS.pm) zu bauen.
Das Protokoll zwischen sketch und 36_ITPlusWS.pm implementiere ich so, dass es auch für andere IT+ Stationen als die WS 1600, die der Sketch evtl. noch "lernt", funktioniert, und der 36_ITPlusWS.pm das Modul für alle LaCrosse-Wetterstationen wird.

Würdest Du schon mal vorbereitend den angehängten Patch in das 36_JeeLink übernehmen?

Das 36_ITPlusWS.pm habe ich initial (noch nicht fertig) selbst als maintainer committed.
Wenn es gut läuft, dann kann ich am nächsten WE den Sektch mit der WS 1600-Erweiterung und das fertiggestellte Modul als Beta veröffentlichen.

[HCS]

Der beiliegende Regensensor heißt TX24-IT, auf der Packung steht iT+. Mein JeeLink findet zwar meine Temperatur und Luftfeuchtesensoren, den Regensensor ignoriert er aber.

Der TX24 überträgt mit größter Wahrscheinlichkeit ein anderes Protokoll und evtl. auch mit einer anderen data rate.
Somit kann der Sketch nichts mit anfangen.
Wenn das Protokoll bekannt ist, wäre evtl. was machbar.

[justme1968]

@HCS: wäre es nicht besser und für die endanwender einfacher wenn das modul mit namen LaCrosse auch für die LaCrosse wetterstationen zuständig ist? wie wäre es wenn du den namen bzw das modul übernimmst? ich denke es wäre besser hier nicht zu forken.

für den jeelink patch habe ich einen wunsch/vorschlag: wir haben jetzt schon das problem das im jeelink modul die clients und match list nicht wirklich sketch spezifisch ist. das hat dann zur folge das das iodev oft nicht richtig automatisch gewählt wird wenn man mehrere jeelinks mit unterschiedlichen sketches betreibt.

kannst du bitte deinen patch so umbauen das in JeeLink_Parse clients und match list passend gesetzt wird wenn dein sketch erkannt wird. es ist schon ein bisschen vorbereitet aber noch nicht durchgezogen. ich würde das dann noch nachziehen.

gruss
  andre

[HCS]

wie wäre es wenn du den namen bzw das modul übernimmst?

modul übernehmen = maintainer ?
name übernehmen = ??

wir haben jetzt schon das problem das im jeelink modul die clients und match list nicht wirklich sketch spezifisch ist. das hat dann zur folge das das iodev oft nicht richtig automatisch gewählt wird wenn man mehrere jeelinks mit unterschiedlichen sketches betreibt.

kannst du bitte deinen patch so umbauen das in JeeLink_Parse clients und match list passend gesetzt wird wenn dein sketch erkannt wird. es ist schon ein bisschen vorbereitet aber noch nicht durchgezogen. ich würde das dann noch nachziehen.

Du meinst für $dmsg =~m /LaCrosseITPlusReader/ eine eigene matchlist und nicht die matchListPCA301 gemeinsam verwenden und dann noch clients getrennt für die verschiedenen Sketches?

Könntet Du das übernehmen, wobei, wenn die WS 1600 in den LaCrosse mit rein kommt, sich an clients ja nichts ändert.

Wenn ich den LaCrosse übernehmen soll, dann baue ich es dort ein und ziehe den 36_ITPlusWS.pm zurück.
Eigentlich habe ich den gebaut, um ohne Nebeneffekte und Risiken in "deinem LaCrosse" ungestört die WS 1600 erledigen zu können.

Müssen wir aber schnell entscheiden, dass ich ihn zurückziehen kann, bevor er morgen mit dem Update mitkommt.

[justme1968]

ich habe keinen einzigen lacrosse sensor und das modul sowieso nur weil es kein anderer gemacht hat wenn du es übernimmst hat das also nur vorteile für alle.

wenn es eh der gleiche sketch ist ist das mit dem auftrennen der clients und match list nicht ganz so dringend. am status quo ändert sich ja erst mal nichts. ich schaue aber das ich es einbaue sobald es geht. ich muss erst mal versuchen rauszufinden wie viele unterschiedlich sketches es inzwischen gibt.

gruss
  andre

[HCS]

ich habe keinen einzigen lacrosse sensor und das modul sowieso nur weil es kein anderer gemacht hat wenn du es übernimmst hat das also nur vorteile für alle.

OK, gekauft 
Ich schreibe die maintainer.txt um und nehme den 36_ITPlusWS.pm wieder raus.

wenn es eh der gleiche sketch ist ist das mit dem auftrennen der clients und match list nicht ganz so dringend. am status quo ändert sich ja erst mal nichts. ich schaue aber das ich es einbaue sobald es geht. ich muss erst mal versuchen rauszufinden wie viele unterschiedlich sketches es inzwischen gibt.

Die matchListPCA301 müsste aber trotzdem erweitert werden, dass das LaCrosse Modul die "OK WS" Pakete bekommt.

[justme1968]

ich hab die match list ergänzt.

kannst du es bitte noch kurz testen (und kurz selber reparieren ) das morgen im update nicht etwas falsches raus geht?

gruss
  andre

[HCS]

Testen geht gerade nicht, sieht aber gut aus.

[Prof. Dr. Peter Henning]

OK, was kann ich beitragen ?

Ich würde gerne beim Sketch anfangen und den so aufbohren, dass man ggf. auch "unbekannte" IT-Pakete empfangen und an FHEM weiterreichen kann (und damit langfristig dem Ziel der Einbindung neuer Sensoren näher kommen).

LG

pah

[HCS]

OK, was kann ich beitragen ?

Aktuell wäre es nicht sinnvoll, an dem Sketch zu ändern, da ich gerade den TX22 implementiere.
Es sein denn, es ist etwas, das ich recht einfach übernehmen kann.

Ich würde gerne beim Sketch anfangen und den so aufbohren, dass man ggf. auch "unbekannte" IT-Pakete empfangen und an FHEM weiterreichen kann (und damit langfristig dem Ziel der Einbindung neuer Sensoren näher kommen).

Das ist nicht ganz so einfach.
Zuerst muss die Frequenz (wobei man da recht sicher 868.300 kHz annehmen kann) und die data rate bekannt sein.
Wenn man die data rate nicht kennt, empfängt man nur Müll, der aber auch wie etwas gesendetes aussieht.

Die LaCrosse Sensoren senden mit 17.241 kbps (z.B. TX29DTH), 9.579 kbps (z.B. TX35) und der TX22 der WS 1600 sendet mit 8.842 kbps.
Im Erfinden von Protokollen und data rates sind die LaCrosse Menschen ganz groß.

Auch das sync pattern (bisher bei allen LaCrosse Sensoren, die ich habe, 0x2dd4) muss passen, könnte man also auch erst mal so annehem.

Wenn es keine Quelle gibt, die die data rate usw. benennt, dann hat man fast nur eine Chance: am Sensor oder der Station am RFM mit einem Protokoll-Analyzer den SPI Bus abhören, wie der RFM initialisiert wird. So wurden die meisten IT+ Sensoren "geknackt"

Erst wenn man so weit gekommen ist, kann man beginnen, in den empfangenen Daten nach Mustern zu suchen und das Protokoll zu entschlüsseln, also die Semantik lernen.

Wenn man den Sketch in den Debug-Mode versetzt, liefert er heute schon die empfangenen Rohdaten, nur nützt es nichts, wenn man mit der falschen data rate und evtl. falschen HF-Parametern unterwegs ist. Da wird allerdings noch einiges mehr an debug-log mitgesendet. Ich könnte aber auch recht einfach noch einen Mode implementieren, der nur die Rohdaten rausgibt.

Wenn Du bis zum Wochenende wartest, habe ich eine Sketch Version, die auch die 8.842 kbps für den TX22 unterstützt, dann kannst Du mal mit den drei möglichen data rates schauen, ob etwas empfangen wird, das ein sich wiederholendes Muster aufweist.

Je mehr 868 MHz Sender man im Umkreis hat, ums schwieriger wird das, weil man ständig etwas empfängt. Ich war schon mit dem Laptop und einem Sensor im Wald, um frei von HF-Müll einen Sensor zu analysieren. 

Es ist sehr frustrierend, wenn man nach Stunden der Analyse feststellt, dass das, was man beobachtet, auch dann noch empfangen wird, wenn man die Batterie aus dem Sensor nimmt