Jeelik Modul zur Einbindung von La Crosse!

Begonnen von Billy, 16 September 2013, 15:12:15

Vorheriges Thema - Nächstes Thema

HCS

Zitat von: Kalli01 am 20 Oktober 2015, 17:30:04
Im Log steht: Undefined subroutine &main::timelocal called at ./FHEM/36_JeeLink.pm line 872.

Spielt die Firmware eine Rolle? Da bin ich bei 10.1n
Die Firmware spielt keine Rolle.

@justme1968: das feature ist eine echt schwere Geburt  :(
Da muss wohl oben noch ein use Time::Local; rein?

justme1968

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

marco-f

Zitat von: HCS am 18 September 2015, 21:58:02
Jetzt habe ich mich mal intensiver mit beschäftigt.

Nebeneinander stehen: Ein Uno mit Breadboard auf dem der BMP180 steckt, ein 30.3155WD und drei TX25IT

Alles in °C

30.3155WD: 21,8

TX25IT #1: 22,0
TX25IT #2: 21,3
TX25IT #3: 21,5

Nacheinander sechs BMP180 auf das Breadboard gesteckt
#1: 22,2 / 1020 hPa
#2: 22,2 / 1022 hPa
#3: 22,5 / 1019 hPa
#4: 22,2 / 1021 hPa
#5: 22,7 / 1022 hPa
#6: 24,2 / 1022 hPa

Man beachte #6, der mit 24,2 °C deutlich abseits vom Rest liegt.
Aber 7 °C oder mehr daneben kann ich nicht reproduzieren.

Auf dem Uno mit drei verschiedenen BMP180 Libs (Adafruit, "Name vergessen" und meiner aus dem LaCrosse Sketch) mit dem selben BMP180 das gleiche Ergebnis. Anzeige in FHEM deckt sich mit dem Wert der Test-Sketche.

Hat jemand noch eine Idee zu dem Thema?

Hi,

ich ziehe das Thema nochmal kurz hoch. Woher hast Du Deine Sensoren? Ich hab meine über Aliexpress besorgt. Laufen nun schon einige Zeit, Abweichung immer noch 8-9°K. Im meinem Wohnzimmer sind es laut BMP180 hochsommerliche 28°C.

MfG
Marco

Feuerdrache

Meine Sensoren kamen über eBay im 5er pack.


Gesendet von meinem iPhone mit Tapatalk
FHEM auf Raspberry PI B2
- CUL V3.4 mit culfw 1.65 für HM
- nanoCUL mit culfw 1.66 für KOPP FreeControl

Feuerdrache

Meine Sensoren kamen über eBay im 5er pack.


Gesendet von meinem iPhone mit Tapatalk
FHEM auf Raspberry PI B2
- CUL V3.4 mit culfw 1.65 für HM
- nanoCUL mit culfw 1.66 für KOPP FreeControl

HCS

Die hier: http://www.ebay.de/itm/400902076881
Aber die kommen garantiert auch ursprünglich aus China.

gero

Ich habe zur Zeit 15 TX 29-DTH-IT am laufen. Soweit ist alles okay und ich empfange Daten von allen Sensoren ohne Aussetzer.
Was mich allerdings stört sind die sporadischen battery low Warnungen.
Pro Tag melden sich meist 1-2 der Sensoren (per Mail) und glauben, dass die Batterie leer ist selbst wenn neue Batterien eingelegt wurden (neuwertige Duracell).
Danach wechselt der Batterie Status auf ok und sie laufen ohne Probleme weiter.

Kennt jemand dieses Verhalten?

Ich verwende die aktuelle Version des Sketches:

[LaCrosseITPlusReader.10.1p (RFM12B f:868300 r:17241)]



Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

Kalli01

Hallo
Das Problem habe ich auch. Es Meldet sich immer mal ein Sensor aber dann ist die Batterie auch ohne Auswechseln wieder ok.
Die Sensoren sind aber erst ein paar Monate im Einsatz.

HCS

Zitat von: gero am 23 Oktober 2015, 14:02:35
Ich habe zur Zeit 15 TX 29-DTH-IT am laufen. Soweit ist alles okay und ich empfange Daten von allen Sensoren ohne Aussetzer.
Was mich allerdings stört sind die sporadischen battery low Warnungen.
Pro Tag melden sich meist 1-2 der Sensoren (per Mail) und glauben, dass die Batterie leer ist selbst wenn neue Batterien eingelegt wurden (neuwertige Duracell).
Danach wechselt der Batterie Status auf ok und sie laufen ohne Probleme weiter.

Zitat von: Kalli01 am 23 Oktober 2015, 14:38:21
Das Problem habe ich auch. Es Meldet sich immer mal ein Sensor aber dann ist die Batterie auch ohne Auswechseln wieder ok.
Die Sensoren sind aber erst ein paar Monate im Einsatz.

Na dann gehen wir das Problem mal an. Ich vermag aktuell nicht zu sagen, ob das bei mir auch so ist. Habe zwar den Batterie-Status im Frontend aber wenn da mal einer kurz auf low geht, würde ich es nur sehen, wenn ich gerade drauf schaue.

Generell könnte das zwei mögliche Ursachen haben: ein sensor sendet, warum auch immer, sporadisch mal "low bat" oder es sind schlicht Übertragungsfehler auf der HF-Strecke, bei der Bits kippen und unglücklicherweise die Prüfsumme trotzdem aufgeht.
Ich tippe eher auf das zweite. Besonders, wenn viele 868 MHz Sender laufen, kann es da schon mal kollidieren.

Ich könnte das LaCrosse Modul so erweitern, dass es "low bat" erst dann durch gibt, wenn es mindestens drei mal empfangen wurde. Wenn die Batterie wirklich leer ist, ist sie es ja 12 Sekunden später immer noch.

Hat mal jemand einen code Schnipsel, wie ihr das loggt? Dann muss ich mir es nicht selbst ausdenken.

Wzut

@HCS , bei mir haben alle Sensoren das attr event-on-change-reading battery,
gelogt wird alles in eine mySQL DB.
Wenn ich mir die aktuellen battery Werte (current) aller LaCrosse Sensoren aufrufe so hat keiner einen Zeitstempel der darauf schliessen läst das die Battery mal eben kurz low war :)
D.h. bei keinem meiner sechs TX-29 IT oder der WS 1600 oder dem LevelSender tritt das Problem auf.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

gero

Neben den DbLog Einträgen lasse ich mir eine Mail über ein notify zuschicken:

.*:[Bb]attery.* {sendmail("Batterie Warnung","%NAME %EVENT") if("%EVTPART1" eq "low")}

An die Bitkipper glaube ich nicht so recht. Die Wahrscheinlichkeit dürfte doch recht gering sein. Außerdem beobachte ich keine Ausreißer bei der Temperatur oder Luftfeuchtigkeit, die auch durch solche Bitkipper entstehen sollten.
Meine Theorie ist eher ein Softwarefehler der Sensoren: Evtl. werden die Werte alle x Sekunden vom Sensor gelesen. Das Senden über Funk findet ebenfalls in einem festen Intervall statt. Beides kostet Strom. Wenn das Auslesen der Batteriespannung, welches ebenfalls in einem festen Zeitraster stattfindet, mit einem oder beiden anderen Events zusammentrifft, bricht die Spannung aufgrund des erhöhten Strombedarfs ein und es wird eine battery low Nachricht generiert.
(einen ähnlichen Fehler habe ich schonmal bei einem BLE Sender selbst verbockt)

Die Frage ist, wie sich die Nachrichten verhalten, wenn tatsächlich die Batterie leer geht. Ich habe zu Hause leider kein Labornetzteil zur Verfügung, um die Situation zu simulieren. Vielleicht kann ich das nächste Woche mal machen.
Ich vermute, dass eine n-malige Wiederholung vor dem Auslösen der battery low Warnung der richtige Weg ist.
Gruß,
Gero
Odroid C1 - CULV3-868, JeeLink
16 x TX 29 DTH
MAX!: 15x Heizkörperthermostat+, 2x Wandthermostat, 14x Fenserkontakt, 1x Ecotaster
FS20 S4A, FS20IRF, BSB-Heizungssteuerung über Atmega2560
Z-Wave: ZME_UZB1, Fibaro Wall Plug + Motion Sensor

HCS

Zitat von: gero am 23 Oktober 2015, 21:20:59
An die Bitkipper glaube ich nicht so recht. Die Wahrscheinlichkeit dürfte doch recht gering sein. Außerdem beobachte ich keine Ausreißer bei der Temperatur oder Luftfeuchtigkeit, die auch durch solche Bitkipper entstehen sollten.
Das LaCrosse Modul hat einen treshold (filterTreshold Attribut) für Temperatur und Feuchte. Default ist 10. Wenn also ein gekipptes Paket reinkommt, bei dem Temperatur oder Feuchte mehr als 10 vom vorhergehenden Paket abweicht, wird es ignoriert, und erst wenn dieser Wert das zweite mal kommt, wird er genommen. Battery wird aber immer übernommen. Somit kann es schon sein, dass Schrott-Pakete kommen, Temp und Hum unterdrückt werden und Low bat durchgeht.

Vielleicht sollte ich das zuerst mal ändern, dass Battery nur gesetzt wird, wenn auch die Temperatur akzeptiert wurde.
Ich muss mal am Labornetzteil das Verhalten eines Sensors bei sinkender Spannung anschauen, ob der bei low bat noch korrekte Temp und Hum sendet.

fossy

Hallo zusammen,

Zitat von: HCS am 16 November 2014, 20:52:22
Nein, beide nicht.

ich habe zu Hause auch eine WS1080. Daher habe ich ein bisschen gesucht und habe folgende sourcen gefunden:
https://github.com/kylegordon/mqtt-weatherstation

Mit dieser Firmware werden die Daten des WS1080 Außensensors empfangen und auf der seriellen Schnittstelle ausgegeben!


[weatherstationFSK]
nok  64 19 80 5E 5F BF 23 21 01 C0
ok  A8 C0 00 63 00 00 00 86 0C 2E
ok  A8 C0 00 63 00 00 00 86 0C 2E
ok  A8 C0 00 63 00 00 00 86 0C 2E
ok  A8 C0 00 63 00 00 00 86 0C 2E
ok  A8 C0 00 63 00 00 00 86 0C 2E
ok  A8 C0 00 63 00 00 00 86 0C 2E
1970-01-01 00:00:23  pkt_cnt: 7 ok_cnt: 6 pkt: A8C00063000000860C2E
1970-01-01 00:00:23 ID: 8C, T=  0.0`C, relH= 99%, Wvel=  0.0m/s, Wmax=  0.0m/s, Wdir=W  , Rain=  40.2mm


Jetzt meine Frage:
Ist es denkbar, diesen Sensor in die zu diesem Modul gehörende Firmware zu integrieren oder sind da irgendwelche "Inkompatibilitäten" im Weg? Wenn eine Integration nicht möglich ist, müsste man also ein neues fhem-Modul zur Einbindung der Daten programmieren.

Leider hab ich mit "Funkprotokollen" gar keine Erfahrungen und hoffe, Ihr könnt mich zu den Möglichkeiten aufklären. Danke!

cu
Andreas

HCS

Zitat von: fossy am 24 Oktober 2015, 08:23:05

1970-01-01 00:00:23 ID: 8C, T=  0.0`C, relH= 99%, Wvel=  0.0m/s, Wmax=  0.0m/s, Wdir=W  , Rain=  40.2mm

Das sieht aber nicht so sehr nach empfangenen Werten aus.
Kannst Du mal etwas mehr loggen, ob da tatsächlich brauchbare Werte kommen?

Da die WS1080 FSK auf 838300 kHz mit 17241 kbps sendet, könnte es mit dem LaCrosse Sketch vielleicht machbar sein.
Man müsste halt das Protokoll der WS1080 implementieren.

Billy

Zitat von: HCS am 23 Oktober 2015, 20:50:39
Na dann gehen wir das Problem mal an.
Ich könnte das LaCrosse Modul so erweitern, dass es "low bat" erst dann durch gibt, wenn es mindestens drei mal empfangen wurde. Wenn die Batterie wirklich leer ist, ist sie es ja 12 Sekunden später immer noch.
Hat mal jemand einen code Schnipsel, wie ihr das loggt? Dann muss ich mir es nicht selbst ausdenken.

Also ich habe das Problem mit dem ab und zu Battery low auch.

Bei mir sieht das im Log dann so aus!
2015-06-12_02:15:34 TX_25_HL temperature: 22
2015-06-12_02:22:34 TX_25_HL battery: low
2015-06-12_02:23:21 TX_25_HL battery: ok

Da ich mit dem attr "event-on-change-reading battery" logge, ist logisch, dass im falle der Falschmeldung immer battery: low und battery: ok
hintereinander auftauchen.

Wenn nur  battery: low kommt ist die Batterie zu tauschen. (Da ja kein change event)

deshalb meine ich dass dein o.a. Lösungsvorschlag passt!

Gruß Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*