Jeelik Modul zur Einbindung von La Crosse!

[Alex8508]

Hallo zusammen,

ich habe noch etwa mehrere TFA Außensensoren, Modell TX7 mit 433MHz (Kat. Nr. 30.3125), wie unter http://tfa-dostmann.de/index.php?id=116 aufgeführt.

Würden diese Sensoren mit einem 433MHz Jeelink und dem LaCrosse-Sketch funktionieren? Oder sind die Protokolle zwischen dieser "älteren" und der IT-Version verschieden?

Ich habe leider nur einen 868MHz Jeelink da, sonst würde ich es kurz testen. Es wäre auf jeden Fall super, wenn ich meine vorhandenen Sensoren in FHEM integrieren könnte.

[JoeALLb]

filterThreshold funktioniert für mich sehr gut, jedoch ist der eingestellte Standard für meine Begriffe recht hoch.
Da diese Sensoren so häufig senden, reicht meiner Meinung nach ein filterThreshold von 1 leicht aus.
Dies hat auch den Vorteil, dass Graphen viel glatter dargestellt werden können, weilviel  weniger und wenn dann nur sehr kleine Ausreißer
aufgezeichnet werden. Dies läuft bei mir auch seit einigen Tagen problemlos. Der größte gemessene Unterschied von 2 Temperaturmessungen betrug bisher 0.2°.

Meine Sorge ist jedoch, dass dies irgendwann mal doch zu einem zu großen Unterschied führt, beispielsweise wenn die Sonne plötzlich direkt auf den Sensor scheint.
Gibt es dafür schon Überlegungen? Beispielsweise könnte ein veränderter Wert nach 5(?) aufeinanderfolgenden gültigen Messungen dennoch angenommen werden,
auch wenn er ausserhalb dieses filterThreshold liegt?!?

[justme1968]

ich hatte den wert deshalb so hoch gewählt um genau den sonne auf sensor fall abzufangen und die größten ausreißer durch falsche funknachrichten trozdem nicht durch zu lassen.

im systat modul habe ich einen optionalen gleitenden mittelwert über dir letzen 4 werte um große ausreißer abzufangen.

ich baue mal ein das der threshold auf einen solchen mittwert angewendet wird.

da ich keinen sensor habe brauche ich aber einen freiwilligen zum testen.

gruss
  andre

[JoeALLb]

Hi,

ich kann das gerne testen!

Noch eine kurze Frage: Kann man auch solche kleinen Temperaturunterschiede "glätten", damit diese nicht so häufig ind en Logs erscheinen?
Wenn sich der Sensor nicht sicher ist, ob es 9 oder 8.1° sind, ist mir eigentlich egal, welcher der beiden Werte angezeigt wird.
Ich versuche, meine Logdateien etwas zu verkleinern, da im Moment fast 5MB pro Tag geschrieben werden...

Code Auswählen Erweitern


2013-11-18_12:01:26 temp.bz.AussenthermometerLaCrosse T: 8 H: 99 D: 7.9
2013-11-18_12:01:39 temp.bz.AussenthermometerLaCrosse T: 8.1 H: 99 D: 8.0
2013-11-18_12:02:58 temp.bz.AussenthermometerLaCrosse T: 8 H: 99 D: 7.9
2013-11-18_12:03:02 temp.bz.AussenthermometerLaCrosse T: 8.1 H: 99 D: 8.0
2013-11-18_12:03:11 temp.bz.AussenthermometerLaCrosse T: 8 H: 99 D: 7.9
2013-11-18_12:03:20 temp.bz.AussenthermometerLaCrosse T: 8.1 H: 99 D: 8.0
2013-11-18_12:03:29 temp.bz.AussenthermometerLaCrosse T: 8 H: 99 D: 7.9
2013-11-18_12:03:37 temp.bz.AussenthermometerLaCrosse T: 8.1 H: 99 D: 8.0
2013-11-18_12:03:42 temp.bz.AussenthermometerLaCrosse T: 8 H: 99 D: 7.9

[DOCa Cola]

ja, dieses "zappeln" kann ich bei meinen beiden sensoren auch immer wieder mal beobachten.
das gilt nicht nur für die temperatur, sondern auch für die feuchtigkeit

Code Auswählen Erweitern

2013-11-17_22:30:25 LaCrosse_74 T: 20.1 H: 60
2013-11-17_22:32:46 LaCrosse_74 T: 20.1 H: 61
2013-11-17_22:32:55 LaCrosse_74 T: 20.1 H: 60
2013-11-17_22:33:03 LaCrosse_74 T: 20.1 H: 61
2013-11-17_22:33:08 LaCrosse_74 T: 20.1 H: 60
2013-11-17_22:33:17 LaCrosse_74 T: 20.1 H: 61
2013-11-17_22:33:26 LaCrosse_74 T: 20.1 H: 60
2013-11-17_22:33:39 LaCrosse_74 T: 20.1 H: 61
2013-11-17_22:33:43 LaCrosse_74 T: 20.1 H: 60
2013-11-17_22:33:56 LaCrosse_74 T: 20.1 H: 61
2013-11-17_22:34:01 LaCrosse_74 T: 20.1 H: 60
2013-11-17_22:34:05 LaCrosse_74 T: 20.1 H: 61
das ist natürlich sehr log intensiv
Also das vorgeschlagene "glätten" könnte z.B so funktionieren, dass die letzten 20 Werte (oder z.B die der letzten 2 minuten) genommen werden und davon nur der häufigst vorkommende an FHEM durchgereicht wird. Damit könnte man wohl auch den Toleranzwert wieder entfernen, denn die Messausreisser fliegen dadurch automatisch raus.

[justme1968]

ich glaube es gibt mehrere strategien und randbedingungen:

- die werte in fhem sollten so schnell wie möglich aktuell sein um z.b. mit einem trigger reagieren zu können
- es sollen grobe ausreisser ausgefiltert werden. das geht mit einem mittelwert (auch gleitend) und es geht über die häufigkeit/median.
- die plausiblen werte sollen gemittelt werden
- es soll so wenig wie möglich geloggt werden

je mehr gemittelt wird um so träger wird das ganze.

die anzahl der einträge beim loggen kann man mit event-min-intervall jetzt schon in den griff bekommen. dazu braucht es nicht unbedingt eine mitteilung/filterung.

gruss
  andre

[JoeALLb]

Hallo Andre,

mit

Code Auswählen Erweitern

event-min-interval .*:300
event-on-change-reading state
event-on-update-reading .*

ist das System nicht träge, loggt aber gleichzeitig auch nicht alle x sekunden den selben Temperaturwert.
Ich bekomme dadurch alle 5 Minuten einen Temperatureintrag(bei keiner Änderung), jedoch wird eine Änderung des state-wertes sofort geloggt.
Da diese Sensoren so häufig senden, würde ich es nicht als Problem sehen, wenn ich 2 oder 5 mal den selben Wert vom Sensor erwarte, bevor
ich dies dem System mitteile...

[justme1968]

ja ich weiss. genau darauf wollte ich ja hinaus. mit den event- attributen kann man jetzt schon das logging anpassen so wie es gebraucht wird.

das filtern/mittelwert bilden/was auch immer kann also darauf beschränkt bleiben aussreisser auszufiltern und muss nicht auch noch das loggen einschränken. das

gruss
  andre

[justme1968]

die angehängte version rechnet eine art gleitenden mittelwert über 4 werte. das ergebniss wird für den threshold vergleich verwendet. die readings selber sind dabei immer noch die jeweiligen original werte.

gruss
  andre

[JoeALLb]

Anbei ein Screenshot für eine kurze Rückmeldung:
Gefühlt ist die aktualisierte Version des Moduls besser, die Linie sieht im rechten Bereich, der mit dem aktualisierten Modul geschrieben wurde, "glatter" aus.



Edit: Nach genauerer Betrachtung konnte keine Besserung festgestellt werden. Wie man in dem Screenshot sieht, "tanzt" die Außentemeratur(pink) noch stark hin und her! Im Gegensatz dazu oben Rot ein HM-Sensor.

[justme1968]

wenn du magst kannst du die beiden zeilen zur mittwert berechnung vom ende ans anfang des if schieben. dann wird die berechnung aufs reading gemacht.

ich poste morgen eine angepasste version.

gruss
  andre

[JoeALLb]

Hallo Andre,

danke. Damit sieht es nochmals flacher aus, jedoch sind diese Zacken ähnlich wie beim menschlichen Puls immer noch da (heute waren es bisher 4).
Vielleicht sollte man lediglich Tendenzänderungen beobachten, wenn also der Wert sinkt und plötzlich steigt, dass wir für diesen Moment eine zweite oder sogar eine dritte Bestätigung benötigen?!

[JoeALLb]

Wie kommt es eigentlich, dass bei neu erkannten Devices das IoDev falsch ist und das von den PCA eingetragen wird?
Hab dies nun korrigiert, nachdem ich es übersehen hatte.

Seit der letzten Änderung(?) bekomme ich folgende Temperaturwerte angezeigt. Hängt dies mit dem Mitteln der Werte zusammen?

Code Auswählen Erweitern

T: 3.64093961715698

[justme1968]

es wird in fhem immer das letzte 'passende' IODev verwendet. da fehm nicht weiß das der zweite jeelink nur mit pca301 etwas anfangen kann wird der falsche genommen.

bei einem device das nur empfängt ist es aber egal. das IODev ist nur beim senden wichtig.

die werte sehen so aus weil ich noch keine runden eingebaut hatte weil das nur nötig ist wenn sie als reading verwendet werden.

gruss
  andre

[JoeALLb]

Danke für die Zusatzinfo.
Wenn aber bei "LASTInputDev" immer der falsche eingetragen ist, vermute ich, dass eventuell beim letzten Boot mein Linux die beiden Sticks vertauscht hat?!?
/dev/ttyUSB0 + 1?
Wenn dies dann nur für das Senden benötigt wird, und ich per "attr <> IODev XX" dies fest definiert habe, habe ich sorge, dass der Ausschaltbefehl zu
meinen Steckdosen immer über den LaCross-JeeLink gesendet wird, kann das sein?

Leider fällt mir kein Weg ein, wie ich den PCA301-Stick immer auf ttyUSB1 mounten kann,
außer vielleicht über die ID.
Aber diese ID ist nur minimal anders: Wäre dies ein zuverlässiger Anhaltspunkt?
Oder mache ich mir hier überhaupt über was unwichtiges gedanken?

Code Auswählen Erweitern

define <Device> JeeLink /dev/ttyUSB1@57600

Code Auswählen Erweitern

ls -l /dev/serial/by-id/
lrwxrwxrwx 1 root root 13 Jan  1  1970 usb-FTDI_FT232R_USB_UART_A901RPMR-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan  1  1970 usb-FTDI_FT232R_USB_UART_A901RQMP-if00-port0 -> ../../ttyUSB0