Jeelik Modul zur Einbindung von La Crosse!

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

Vorheriges Thema - Nächstes Thema

justme1968

die temperatursensoren senden wirklich von sich aus.

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

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

ohweh

Hi JoeALLb,

ich schätze mal Du hast ein schlechtes Exemplar des Sensors erwischt. Schlecht insofern, als dass die Grenzfrequenz von dem RF-Modul etwas abseits des normalen liegt. Hast Du den erst kürzlich erworben und kannst ihn noch zurückgeben? Wenn ja, dann würde ich das machen. Ansonsten kann ich Dir nur anbieten am nächsten Wochenende mal zu schauen, ob man nicht im Sketch ein bisschen an den RF-Parametern tunen kann. Vielleicht klappt es dann doch noch mit Deinem Sensor...

Gruss
Oliver

Zitat von: JoeALLb am 11 November 2013, 12:57:34
Ich habe mit meinem einen Sensor weitergespielt mit folgendem Resultat:
* Wenn ich ihn in den Raum begebe, in der die Wetterstation befindet, wird für innen und Außentemperatur die (fast) selbe Temperatur angezeigt.
* MeinJeelink findet keinen Sensor, der auch nur annähernd 20° anzeigt (dafür aber 20 andere...)
* Wenn ich dem Sensor die Batterien entferne, verschwindet die Anzeige auf der Wetterstation, und es werden nur noch die Daten eines anderen Sensors, den FHEM bereits empfängt, angezeigt.

Ich bin mir daher zwischenzeitlich recht sicher, dass es gewisse Sensoren gibt, die (noch?) nicht empfangen werden können!
Vielleicht sollte ich diesen einen einfach aussortieren, oder sieht jemand eventuell eine Möglichkeit, wie dieser doch empfangen werden kann?

JoeALLb

Hallo ohweh,

Danke für die Antwort. Der Sensor ist schon 4 Jahre alt, also kein Umtausch in sicht.
Gerne kann ich auch den ein oder anderen Test durchführen/übernehmen, aber ich bräuchte eine kleine Anleitung dazu,
denn den jeeLink habe ich noch nie selber programmiert. Vielleicht reicht es auch schon, wenn Du mir sagst, mit welchen Parametern
ich rumspielen soll?!?

Wenns nicht klappt sehe ich das aber auch  nicht sooo tragisch! Mich würde lediglich interessieren, woran es liegen könnte.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Woran liegt es eigentlich, dass manche Sensoren im State nur die Temperatur anzeigen, und ein anderer "T: xx H: xx"?
Den humidity-Eintrag kann ich bei allen erkennen, und die Konfiguation unterscheidet sich nicht!

Der funktionierende zeigt 80% an, der nicht funktionierende 98%.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

justme1968

die bedingung zum erzeugen des humidity readings und H: teils von state ist gleich. state wird aber nur für den channel 1 erzeugt.

zeig mal bitte ein list von deinem device.

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

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

JoeALLb

Voila
list  temp.aussensuedseite.lacross
Internals:
   DEF        20
   IODev      JLLaCR
   JLLaCR_MSGCNT 57920
   JLLaCR_RAWMSG OK 9 32 1 4 11 81
   JLLaCR_TIME 2013-11-13 15:33:27
   LASTInputDev JLLaCR
   LaCrosse_lastRcv 2013-11-13 15:33:27
   MSGCNT     56857
   NAME       temp.aussensuedseite.lacross
   NR         337
   STATE      T: 3.5 H: 81
   TYPE       LaCrosse
   addr       20
   battery_new 0
   previousH  81
   previousH2 99
   previousT  3.5
   previousT2 11.7
   Readings:
     2013-11-01 10:52:02   H               0
     2013-11-04 09:45:41   T               0
     2013-11-13 15:33:27   battery         ok
     2013-11-13 15:33:27   humidity        81
     2013-11-13 15:33:10   state           T: 3.5 H: 81
     2013-11-13 15:33:27   temperature     3.5
     2013-10-27 21:32:55   temperature0    21
Attributes:
   event-min-interval T:300,state:300
   event-on-change-reading T
   event-on-update-reading .*
   filterThreshold 3
   room       Device

fhem> list  temp.bz.AussenthermometerLaCrosse
Internals:
   DEF        30
   IODev      JLLaCR
   JLLaCR_MSGCNT 46759
   JLLaCR_RAWMSG OK 9 48 1 4 5 99
   JLLaCR_TIME 2013-11-13 15:33:43
   LASTInputDev JLLaCR
   LaCrosse_lastRcv 2013-11-13 15:33:43
   MSGCNT     45871
   NAME       temp.bz.AussenthermometerLaCrosse
   NR         316
   STATE      T: 2.9
   TYPE       LaCrosse
   addr       30
   battery_new 0
   previousH  99
   previousH0 99
   previousT  2.9
   previousT0 1.2
   Readings:
     2013-10-31 19:42:34   H               0
     2013-10-31 20:43:10   T               0
     2013-11-13 15:33:43   battery         ok
     2013-11-13 12:48:24   humidity        98
     2013-11-13 15:15:55   state           T: 2.9
     2013-11-13 15:33:43   temperature     2.9
     2013-10-27 19:21:00   temperature0    12.7
Attributes:
   event-min-interval T:600
   event-on-change-reading T
   event-on-update-reading .*
   filterThreshold 3
   room       Device
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

justme1968

das humidity reading des sensors der nicht so funktioniert wie du erwartest ist älter als das temperature reading. wenn du in den infernal values schaust siehst du das der sensor aktuell 99 sendet. das ist laut protokoll der wert der einen ungültigen wert anzeigen soll. deswegen wird das reading und auch der H: Teil im state nicht aktualisiert/erzeugt.

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

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

justme1968

ich sehe gerade das laut der grafik weiter vorne im thread 99 noch erlaubt ist und erst 100 nicht mehr. in der beschreibung die ich hatte war bis 98 erlaubt und 99 nicht mehr.

wenn mir jemand sagt welche der beiden versionen stimmt baue ich es um.

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

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

JoeALLb

#113
> 99 sollte es nicht geben, weil diese Zeile im Sketch enthalten ist..
  if (humidity > 99) {
    humidity = 99;
  }


Schade, die Außentemperatur ist derzeit 81 bei 2 anderen Sensoren.... warum dieser neue Sensor nun solche Werte liefert würde mich schon interessieren.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

justme1968

dann ändere ich dir grenze
fhem modul auch von 98 auf 99.

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

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

JoeALLb

Ich habe gerade nachgesehen... dieser Sensor ist nur ein Temperatursensor.
Woher also die Feuchtigkeitswerte kamen, kann ich nicht sagen.
Lt. Log hat er genau 2 mal in den letzten Tagen einen H-Wert mitgeschickt, ich gehe also davon aus, dass dies ein Fehlerhaftes Funkpacket war.

Habe den Sensor gelöscht und neu eingetragen, jetzt sehen die Readings wieder sauber aus.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Billy

Hallo

ZitatIch habe gerade nachgesehen... dieser Sensor ist nur ein Temperatursensor.
Woher also die Feuchtigkeitswerte kamen, kann ich nicht sagen.

Das könnte schon sein wenn auf dem gleichen Kanal ein TH Sensor z.B. aus der Nachbarschaft sendet!

Deswegen ist es sinnvoll bei möglichem Fehlverhalten eines Sensors auch immer die Type mit anzugeben!
Mein TX25IT sendet zum Beispiel auf dem H-Kanal eine 2. Temperatur. Andre hat das super gelöst.

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*

JoeALLb

Zitat von: Billy am 13 November 2013, 17:16:49
Deswegen ist es sinnvoll bei möglichem Fehlverhalten eines Sensors auch immer die Type mit anzugeben!

??? Wie oder was genau machst Du da? Eine Typen-Einstellung habe ich nicht gefunden...
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Billy

Sorry,
Habe mich wohl missverständlich ausgedrückt. Meine die Typenbezeichnung des Sensors
Bei Fragen ans Forum.

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*

Spiff

Hallo!

Ich bekomme hin und wieder Fehler in meinem fhem-Fenster angezeigt:
C:\FHEM>C:\Perl\bin\perl.exe fhem.pl fhem.cfg
Use of uninitialized value $found[0] in string eq at fhem.pl line 2822.


In meiner fhem.log steht dann immer:
2013.11.16 15:42:22 3: LaCrosse Unknown device 64, please define it

Das können (wenn überhaupt) nur Sensoren der Nachbarn sein, meine eigenen sind definiert und funktionieren.
Trotzdem: wie kann ich den Fehler beseitigen?
Autocreate ist an, liegt es daran?

Ich nutze die aktuellste Version.

Danke & Grüße
Spiff