Jeelik Modul zur Einbindung von La Crosse!

[Wzut]

Wie steht's mit dem Wind?

schei.... ich habe dein Update total übersehen ....
Die Beta Version ist nun auf dem JeeLink und ich habe meine 25.4 Unterdrückung im LaCrosse Modul wieder entfernt, schaun mer mal
 

[HCS]

Das Regen-Thema bei der WS 1600 habe ich jetzt im Griff. Morgen gibt es eine neue Beta, die liefert dann genau die rain Werte, die auch von der Station angezeigt werden.

[Wzut]

und wo lag nun der Fehler das der Wert plötzlich wieder kleiner wurde ?
Btw: gestern wieder Regen, aber diesmal gings von 5 nach 8mm ohne Rücksprung durch.
Was die Basis Station direkt anzeigt kann ich leider aus z.Z. ca. 800km Entfernnung nicht erkennen ....

[HCS]

Was die Basis Station direkt anzeigt kann ich leider aus z.Z. ca. 800km Entfernnung nicht erkennen ....

Dann hat Deine webCam aber eine schlechte Reichweite 

und wo lag nun der Fehler das der Wert plötzlich wieder kleiner wurde ?

Programmfehler im Sketch. Ich dachte, der Regen wäre wie die Temperatur BCD kodiert. Ist aber basis 16 kodiert.
Das gibt dann diese lustigen Sprünge im Ergebnis.

Und ich war mir so sicher, dass der TX22 das tatsächlich sendet, bis mir mal die Rohdaten im Augenwinkel aufgetaucht sind und ich mich gewundert habe, warum die größer werden und der an FHEM gesendete Wert kleiner.

Der plot sieht schon mal gut aus. Muss nur noch beim loggen etwas gegensteuern. 64000 Datensätze im Dblog in zwei Tagen ist etwas heftig 

Ach ja, der Wind sieht nun auch gut aus, siehe Anhang

[HCS]

Version 10.1j (Sketch, Quellcode und LaCrosse Modul) ist eingecheckt

Änderungen
WS 1600: Hotfix zur Unterdrückung der "25.4 m/s Pakete"
Ich forsche noch, was es mit den seltsamen Paketen mit dem Error flag auf sich hat.

WS 1600: Regen: Der Fehler bei der Berechnung im Sketch ist behoben (siehe oben) und es wird nun genau der Wert geliefert, den die WS 1600 Station auch anzeigt.

WS 1600: Plausibilität der Daten wird nun im Sketch geprüft.
Temperatur -40.0 ... 59.9 und Lufteuchtigkeit 1 ... 99
Wenn das nicht zutrifft, wird das Paket nicht an FHEM ausgeliefert.

LaCrosse-Sketch: Erweiterung des "raw payload" mode. 2p setzt einen Modus, in dem raw data nur für empfangenen Pakete ausgegeben wird, die nicht von einer der Sensor-Logiken decodiert werden konnte. Für korrekt dekodierte Pakete wird der "OK ..." String ausgegeben.
Dient als Datenquelle für den "LaCrosse Scanner" an dem ich (z.Zt. leider selten) dran bin.

LaCrosse-Sketch: <n>r: es kann nun anstatt 0, 1 oder 2 auch direkt eine data rate angegeben werden.
Es muss aber eine data rate sein, die der RFMxx auch beherscht. Beispiel: 19157r

LaCrosse-Sketch: Neues Kommando 1z um auf "analyze frames" zu schalten (oder 0z um es wieder abzuschalten).
War bisher nur durch ändern und compilieren im Sketch möglich

WS 1600: Das an FHEM übermittelte Error-Flag und LowBattery wird nun im LaCrosse-Modul korrekt ausgewertet und angezeigt (neues Reading "error")
Allerdings forsche ich noch, ob und wie der TX22 den Batteriestatus übermittelt. Solange liefert der Sketch immer "Batterie gut"

Das Ganze kommt dann morgen mit dem normalen Update.

[kpwg]

Hat jemand ein Jeelink bzw. Clone mit RFM69 im Einsatz? Ich habe bei mir umgestellt, bin aber nicht ganz glücklich mit den zusätzlich empfangenen Sensoren. Ich bin sogar überzeugt, das hier viel Müll empfangen wird, da ich den Jeelink nun an einer anderen Stelle betreibe, wo es im Umkreis von mehreren hundert Metern nur vier (Einfamilien-)Häuser gibt. Alles ausblenden, was mir nicht gehört ist hier nur schwer möglich.

[HCS]

Habe beides. Auf dem Testsystem laufen RFM69 und auf dem Produktivsystem RFM12. Da habe ich keinen großen Unterschied. Allerding habe ich auch bei beiden vereinzelt Phantom-Sensoren. Das ist, wenn die Prüfsumme stimmt und Temperatur und Feuchte im gültigen Bereich liegen, obwohl es ein falsch empfangenes Paket war.

Der Sensor mit der ID 8 in Deiner Liste sieht aber sehr realistisch aus, den könntest Du mal einrichten und schauen, ob da tatsächlich reale Daten kommen.

Es wäre eine Überlegung wert, ob man eine Plausibilitäts-Prüfung für neue Sensoren implementieren könnte, z.B. nach dieser Methode:
Wenn ein Sensor noch nicht in FHEM definiert ist, muss er innerhalb einer Minute mindestens zwei mal empfangen worden sein, um ihn zu akzeptieren und zu loggen bzw. anzulegen. Zeit und Anzahl sind nur beispielhaft, muss das mal noch genauer überlegen. Evtl. mit einem Attribut in der Art: NewSensorTreshold, dass man die Empfindlichkeit selbst festlegen kann.

Bin für jeden Hinweis (pro/contra) zu dieser Thematik offen.

[kpwg]

Der Sensor mit der ID 8 in Deiner Liste sieht aber sehr realistisch aus, den könntest Du mal einrichten und schauen, ob da tatsächlich reale Daten kommen.

Den habe ich nun definiert und schaue einfach mal. In meinem eigenen FHEM hatte ich das RFM69 Modul vorher auch laufen, jedoch waren da die eher nicht plausiblen Werte recht nervig in den Plots. Das average rechnet es dann noch "breit", so das man dann täglich in den Logs korrigiert oder eben mit solchen Peaks leben muss.

Es wäre eine Überlegung wert, ob man eine Plausibilitäts-Prüfung für neue Sensoren implementieren könnte, z.B. nach dieser Methode:
Wenn ein Sensor noch nicht in FHEM definiert ist, muss er innerhalb einer Minute mindestens zwei mal empfangen worden sein, um ihn zu akzeptieren und zu loggen bzw. anzulegen. Zeit und Anzahl sind nur beispielhaft, muss das mal noch genauer überlegen. Evtl. mit einem Attribut in der Art: NewSensorTreshold, dass man die Empfindlichkeit selbst festlegen kann.

Dann müsste jedoch das Auto-Toggle vom JeeLink berücksichtigt werden?

[justme1968]

 ich könnte mir vorstellen das man so etwas direkt im autocreate einbaut. vielleicht mit einem attribut <code>autocreateThreshold <TYPEx>:<count>:<min>,...</code>devices von TYPE würden dann nur angelegt wenn sie count male innerhalb von min minuten vorgekommen sind. und man könnte  über das device modul jeweils einem spezifischen default wert vorgeben.

oder man verwendet direkt das attribut das devices von autocreate ausschließt. dann wäre kein neues attribut nötig. 

gruss
  andre

[HCS]

... jedoch waren da die eher nicht plausiblen Werte recht nervig in den Plots. Das average rechnet es dann noch "breit", so das man dann täglich in den Logs korrigiert oder eben mit solchen Peaks leben muss.

Kannst Du das noch etwas erläutern oder Beispieldaten liefern?
Meine Polts von meinen 12 Sensoren sind über Monate hinweg absolut sauber. Das LaCrosse Modul macht doch auch per default einen filterThreshold von 10, bedeutet, dass sich Temperatur und Feuchte nicht mehr als 10 gegenüber dem vorhergehenden Wert ändern dürfen, sonst wird der Wert ignoriert.
Bist Du mit dem LaCrosse Modul auf dem aktuellen Stand?

ich könnte mir vorstellen das man so etwas direkt im autocreate einbaut. vielleicht mit einem attribut <code>autocreateThreshold <TYPEx>:<count>:<min>,...</code>devices von TYPE würden dann nur angelegt wenn sie count male innerhalb von min minuten vorgekommen sind. und man könnte  über das device modul jeweils einem spezifischen default wert vorgeben.

Das kling gut. Dann müsste man es nicht in allen Modulen der verschiedenen devices (LaCrosse, EMT7110, ...) implementieren.

Damit sollte man in der Lage sein, den größten Teil der Phantom-Sensoren zu unterdrücken.
Der 08er von kpwg wäre durchgegangen, da er innerhalb von einer Minute sech mal gekommen ist, aber das könnte ja duchaus ein realer sein. Aber beim überfliegen seiner Liste wären mit so einer regel fast alle raus.

Kannst Du dieses Thema vorantreiben?

[kpwg]

Kannst Du das noch etwas erläutern oder Beispieldaten liefern?

Ja, anbei zwei Bilder. Einmal der Tagesplot, das Andere maximal gespreizt. Es war definiv ein anderer Sensor, denn zu der Zeit war niemand da.

Meine Plots von meinen 12 Sensoren sind über Monate hinweg absolut sauber. Das LaCrosse Modul macht doch auch per default einen filterThreshold von 10, bedeutet, dass sich Temperatur und Feuchte nicht mehr als 10 gegenüber dem vorhergehenden Wert ändern dürfen, sonst wird der Wert ignoriert.
Bist Du mit dem LaCrosse Modul auf dem aktuellen Stand?

Hier laufen seit 12/2013 fünf Sensoren mit Jeelink-Clone+RFM12(B) absolut sauber. Anfangs hatte ich einen originalen Jeelink. Keine Ausreißer, zwei stets präsente Sensoren aus der Nachbarschaft. Erst mit dem RFM69 hatte ich das Phänomen.
Mit dem Sketch und dem Modul bin ich auf dem letzten Stand.

[Kalli01]

Hallo

ich habe aus einem Arduino Nano und einem RFM12B einen JeeLink Ersatz gebaut und mit der Software LaCrosseITPlusReader.10.1j programmiert.
Ein TX29DTH-IT wird auch erkannt.

Nach kurzer Zeit bricht aber die Verbindung ab. Die LED auf dem Modul blinkt noch aber in FHEM kommt nichts an. Über ein reset Befehl kann ich das ganze aber sofort wieder starten.

Hatte jemand schon mal so ein Problem?

Gruß Kalli

[justme1968]

anbei eine erste version einen patches für autocreate.

das attribut ist eine liste aus <type>:<count>:<timeout> tripeln:

Code Auswählen Erweitern

attr autocreate autocreateThreshold LaCrosse:2:30,EMT7110:2:60

bitte mal testen ob das so funktioniert.

gruss
  andre

[HCS]

bitte mal testen ob das so funktioniert.

Getestet. Funktioniert mit folgenden Änderungen (gekennzeichnet mit ###HCS)

Code Auswählen Erweitern

          my $count = keys %{$hash->{helper}{received}{$type}{$arg}};
          ###HCS: added Minimum info
          Log3 $me, 3, "autocreate: received $count event(s) for '$type $arg' during the last $interval seconds. Minimum is $min_count.";

          ###HCS: my $min_count = 3;
          if( $count < $min_count ) {
            Log3 $me, 3, "autocreate: ignoring '$type $arg'";
            next;
          }

          #delete entries for this event
          delete( $hash->{helper}{received}{$type}{$arg} );
          delete( $hash->{helper}{received}{$type} ) if( !%{$hash->{helper}{received}{$type}} );
        }
      }
      ###HCS: next;

Allerdings verbessert das die Situation im Log nicht unbedingt, eher im Gegenteil.

Code Auswählen Erweitern

2015.06.07 19:38:47 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:38:57 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:39:07 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:39:18 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:39:27 3: LaCrosse: Unknown device 00, please define it

ab hier "set myJeeLink LaCrossePairForSec 60 ignore_battery"

2015.06.07 19:39:27 3: autocreate: received 1 event(s) for 'LaCrosse 00' during the last 60 seconds. Minimum is 4.
2015.06.07 19:39:27 3: autocreate: ignoring 'LaCrosse 00'
2015.06.07 19:39:37 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:39:37 3: autocreate: received 2 event(s) for 'LaCrosse 00' during the last 60 seconds. Minimum is 4.
2015.06.07 19:39:37 3: autocreate: ignoring 'LaCrosse 00'
2015.06.07 19:39:47 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:39:47 3: autocreate: received 3 event(s) for 'LaCrosse 00' during the last 60 seconds. Minimum is 4.
2015.06.07 19:39:47 3: autocreate: ignoring 'LaCrosse 00'
2015.06.07 19:39:57 3: LaCrosse: Unknown device 00, please define it
2015.06.07 19:39:57 3: autocreate: received 4 event(s) for 'LaCrosse 00' during the last 60 seconds. Minimum is 4.
2015.06.07 19:39:57 2: autocreate: define LaCrosse_00 LaCrosse 00
2015.06.07 19:39:57 3: LaCrosse_00: I/O device is myJeeLink
2015.06.07 19:39:57 2: autocreate: define FileLog_LaCrosse_00 FileLog ./log/LaCrosse_00-%Y.log LaCrosse_00

Ich würde nun gerne nach diesen Regeln im LaCrosse, EMT7110, ... die "Unknown device xx, please define it" loggerei unterdrücken, so dass erst geloggt wird, wenn die in autocreate definierte Regel erfüllt ist. Dazu müsste Deine neue Funktionalität irgendwie zentral verwendbar werden und als Ergebnis zurückgeben, ob die Regel erfüllt ist.

Der Pan wäre dann, das alles mit Loglevel 4 oder 5 zu loggen und erst wenn die Regel erfüllt ist, die "Unknown device xx, please define it" mit Loglevel 3 zu loggen.

Dann wäre für die Ausreißer auch Ruhe im Log.

Oder hast Du eine Idee für eine Alternative, um das Log zu beruhigen?

[HCS]

Es war definiv ein anderer Sensor, denn zu der Zeit war niemand da.

Der RFM69 ist empfindlicher als der RFM12. Damit kann es schon sein, dass man Sensoren empfängt, die man bisher nicht in der Reichweite hatte. Das würde bedeuten, dass ein Nachbar einen Sensor mit der gleichen Adresse wie Du hat. Das könnte man ja durch Batterie raus und wieder rein lösen, um auf eine andere (freie) Adresse zu kommen.