Jeelik Modul zur Einbindung von La Crosse!

[HCS]

Ich habe seit einiger Zeit einen JeeLink Clone mit La Crosse im Einsatz und dort 10 TX 29 DTH-IT Luftfeuchtigkeit und Thermometer im Einsatz.

Ja, das ist ein noch ungelöstes Probelm, dass irgend ein zufälliger HF-Müll ein "Wetterstation-Datenpaket" mit korrekter Prüfsumme ergibt und das dann an FHEM zugestellt wird.
Das ist bei Dir am 08.02.2016 um 03:53:59 das letzte mal passiert, und seitdem stehen die Readings drin. Kannst sie einfach löschen (deletereading ...)
Ich habe schon überlegt, ob man einem LaCrosse device konfigurieren können sollte, was es ist (Wetterstation, Temp-Humi-Sensor, ...) so dass es solche Daten nicht akzeptiert.
Ich habe das Thema auf alle Fälle auf der ToDo-Liste.

[skuggy]

Vielen Dank für die Info, dann werde ich die Readings einfach löschen...

[Billy]

Ich habe schon überlegt, ob man einem LaCrosse device konfigurieren können sollte, was es ist (Wetterstation, Temp-Humi-Sensor, ...) so dass es solche Daten nicht akzeptiert.
Ich habe das Thema auf alle Fälle auf der ToDo-Liste.

Gute Idee, das hätte was.
Gruß Billy

[rretsiem]

Hi,
hast Du auch das Netzteil hochgerüstet? 2 A sollte es schon sein.

LG
/robin

Ja, Netzteil ist ein 2,5A Netzteil, auch wenn ich den Homematic USB und Fhemduino nicht anstecke, also weniger Strom "ziehe" ist das Verhalten des JeeLink Clone gleich.

[fh168]

Hast du den von mir aus meiner Testumgebung?

LG
/robin

[Fredi69]

Hat es schon jemand geschafft die ID an einem TX37-IT zu ändern?

[chrissi323]

Ja, Netzteil ist ein 2,5A Netzteil, auch wenn ich den Homematic USB und Fhemduino nicht anstecke, also weniger Strom "ziehe" ist das Verhalten des JeeLink Clone gleich.

Ich hab genau das gleiche Problem, an einem "alten" Pi läuft der Clone, an einer BeeBox empfängt er irgendwann nicht mehr. Leider hilft bei mir auch ein Reset nicht immer. Oft muss ich den Clone kurz abziehen.

[Billy]

Hat es schon jemand geschafft die ID an einem TX37-IT zu ändern?

Siehe hier!
https://forum.fhem.de/index.php/topic,14786.msg267652/topicseen.html#msg267652
Die TX37IT haben eine feste ID vom Werk.

[Hollo]

Ich hab genau das gleiche Problem, an einem "alten" Pi läuft der Clone, an einer BeeBox empfängt er irgendwann nicht mehr. Leider hilft bei mir auch ein Reset nicht immer. Oft muss ich den Clone kurz abziehen.

Mach mal ein aktuelles Update und beobachte die Situation.
Ich hatte die letzte Woche ein ähnliches Problem, dass der Jeelink noch aktiv war, der BMP180 auch Daten lieferte, aber die Werte der Sensoren nach einigen Stunden nicht mehr empfangen und/oder ausgewertet wurden.

Das hatte ich so extrem vor nicht und aktuell ist das scheinbar auch nicht mehr.
Manche "Probleme" kommen und gehen bei regelmäßigen Updates.   

[HCS]

Manche "Probleme" kommen und gehen bei regelmäßigen Updates.   

Ich bin mir aber recht sicher, schon seit längerer Zeit nichts gemacht zu haben, das auch nur annähernd dafür in Frage kommt, das zu verbessern.

Ich frage mich, wie man der Sache näher kommen kann.
Ohne es genau analysiert zu haben, kommt doch (fast) immer "Clone" bei diesem Problem vor.

Netzteil: 2,5A sagt erst mal gar nichts. Unten angehängt ein Plot von so einem 2,5A Netzteil, an dem ein Cubietruck hängt.
Man sieht gut, dass die Spannung teils schon bei gut 500mA auf 4,75V einbricht.
Oder in anderen Worten: das Ding taug nichts
Das ist auch nicht so verwunderlich, denn es sind meistens Ladegeräte für Smartphones, was man da kauft und dem Smartphone ist das beim Laden dann doch eher egal.

Was ist der Unterschied zwischen "Clones" und einem original JeeLink?
Die meisten Clones verwenden einen 5V Arduino und da dran einen RFM12B, der ein 3,3V device ist, ohne Pegelanpassung auf den Signalleitungen.
Das ist schon mal nicht in der Spezifikation.

Der JeeLink betreibt den Atmega328 mit den 3,3V, die der FT232R bereitstellt und der hat intern einen LDO, stellt also geregelte 3,3V bereit, wenn auch nur mit 50mA.
Ich vermute eher, dass die Stabilität der Spannung auf dem USB-Port entscheidender ist. Ein Indiz dafür ist, dass hier berichtet wurde, dass der Clone an einem Pi lief, an einer BeeBox aber Probleme macht.

Der RFM12 oder 69 hängt beim Clone also an 3,3V vom Arduino, hat aber auf den Signalleitungen 5V. Wenn die 5V nun rumflattern, dann hat es der RFM mit einer sehr seltsamen Situation zu tun. Möglicherweise lässt ihn das dann irgendwann mal aussteigen.
Wenn die Signalleitungen mit Spannnugsteilern versehen sind, flattert die Spannung trotzdem (dann halt um 3,3V herum oder was immer man sich mit dem Spannungsteiler zurechtgeteilt hat), da die Basis der Spannnungsteilung von keiner geregelten Quelle stammt.

Da auch meisten (sofern vorhanden) berichtet wird, dass ein angeschlossener BMP180 weiter seine Daten bei FHEM abliefert, kann man davon ausgehen, dass der Arduino weiter läuft und nur der RFM aussteigt.

Wenn dann auch noch lange Leitungen auf dem Breadboard mit Übergangswiderständen usw. auf dem SPI-Bus dazu kommen, steigt die Chance, dass der RFM auf dem Bus Müll bekommt und aussteigt.

Was auch noch ein Faktor sein könnte ist der USB-Serial-Umsetzer, den man verwendet. Der liefert ja schließlich die Versorgungsspannung, zumindest die 3,3V.
Und manche der China-Arduinos haben einen CH340 drauf, anstatt einem FTFT232R.

Was könnte man tun?
- nRES vom RFM an einen Port des Arduino hängen und der Sketch macht im Ernstfall einen RFM-Hardware-Reset
Allerdings müsste er sich dazu dann die komplette aktuelle Konfiguration merken, da er sie nach dem Reset ja wieder herstellen muss.
- Die ganze Schaltung (Arduino incl. RFM, usw.) an einem 3,3V LDO (z.B. ein AMS1117 incl. Stützkondensatoren) betreiben
Was nur dann was nützt, wenn die Spannungsversorgungstheorie stimmt.

Alles nur Ideen und Überlegungen. Aber mir ist noch nie ein JeeLink (in der Variante "Echt") ausgestiegen und an meinen LaCrosseGateways laufen zum Teil bis zu 5 RFM69, die auch nie aussteigen.
Wer noch eine Vorschlag oder eine Theorie hat, her damit.

Hier mal noch ein Zitat aus dem RFM12B Datenblatt:

During the reset event (caused by power-on, fast positive spike on the supply line or software reset command), it is very important to
keep the Vdd  line as smooth as possible. Noise or periodic disturbing signal superimposed the supply voltage may prevent the part
getting out from reset state. To avoid this phenomenon use  adequate filtering on the power supply line to keep the level of the
disturbing signal below 100mV p-p  in the DC – 50kHz range for 200ms from Vdd  ramp start.

[Omega-5]

Ich frage mich, wie man der Sache näher kommen kann.
Ohne es genau analysiert zu haben, kommt doch (fast) immer "Clone" bei diesem Problem vor.

Wow, aller Mist auf einem Haufen. 
Da hast du schön was zusammen getragen. Man könnte es fast in jeden thread, der sich in irgend einer Weise mit "Ich habe mal versucht ... nach zu bauen" beschäftigt, kopieren.
Beispiel ESP und USB TTL Konverter. Keine Puffer/Filter-Kondensatoren, max. 100mA aus FT232 oder CP2102, aber 120 -> 180mA im Sendebetrieb. 
Du Solltest deinen Beitrag an der Bastelecke "anpinnen". 

Gruß Friedrich

[Hollo]

Ich bin mir aber recht sicher, schon seit längerer Zeit nichts gemacht zu haben, das auch nur annähernd dafür in Frage kommt, das zu verbessern.

Mein Kommentar war auch eher anders gemeint:
Bei einem "System" wie FHEM darf man nicht vergessen, was da "schlimmstenfalls" alles so zusammentrifft...
da proggen Neerds noch mitten in der Nacht Code zusammen, den interessierte Ahnungslose auf Bastelsystemen mit billigen Zubehörteilen für irgendwelche wahnwitzigen Ideen einsetzen. 

Es kann alles funktionieren, es kann unerwartete Nebenwirkungen geben, usw.
Manchmal treten halt auch Probleme auf, die genauso plötzlich wieder verschwunden sind, bevor man die eigentlichen Gründe gefunden hat.
Je besser die Komponenten sind, umso wahrscheinlicher ist ein reibungsloser Betrieb; eine Garantie gibt es nie.

[HCS]

... da proggen Neerds noch mitten in der Nacht Code zusammen ...

Aha. Dann muss ich wohl schauen, dass ich in Zukunft mit irgend welchen Implementierungen fertig bin, bevor es dunkel wird.
Wobei mir der Zusammenhang zwischen Tageszeit und Ergebnis noch nicht klar ist.
Ist das so Deine generelle Ansicht über FHEM-Developer?
Falls ja, hast Du Dich für das falsche System entschieden.

Und die Definition von "Nerd" ist laut Duden: "sehr intelligenter, aber sozial isolierter Computerfan"

[Hollo]

...Ist das so Deine generelle Ansicht über FHEM-Developer?
Falls ja, hast Du Dich für das falsche System entschieden...

Du hast aber schon die diversen Anführungszeichen und die 3 (in Worten: drei !!!) Smilies dahinter gesehen!? 
Ironie-Tags standen leider nicht zur Verfügung, aber ich lasse sowas lieber zukünftig und bleibe bei meinen sachdienlichen Beiträgen. 

[errazzor]

Hallo zusammen,

ich habe mir einen JeeLink v3c geholt. Flashen und in FHEM einbinden ging problemlos, der JeeLink ist "initialized".

Leider schaffe ich es nicht, diesen Temperatursensor anzubinden: http://www.amazon.de/TFA-Dostmann-Sender-Wetterdirekt-30-3155/dp/B001NY416G/ref=cm_cr_arp_d_product_top?ie=UTF8

Ich setze den JeeLink in den Pairing Modus und lege dann die Batterien in den Sensor. Es passiert einfach gar nichts. Im Logfile findet sich auch gar nichts (keine neuen Einträge).

Autocreate ist aktiviert.

Was kann ich jetzt noch tun / wo nachschauen? Welche Infos werden benötigt zur Fehlersuche?

Hier mal noch ein List vom Jeelink:

Code Auswählen Erweitern


Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        /dev/ttyUSB0@57600
   DeviceName /dev/ttyUSB0@57600
   FD         18
   NAME       myJeeLink
   NR         162
   PARTIAL
   STATE      initialized
   TYPE       JeeLink
   initMessages
   model      [LaCrosseITPlusReader.10.1q (RFM69 f:868280 t:30~3)]
   Matchlist:
     1:PCA301   ^\S+\s+24
     2:EC3000   ^\S+\s+22
     3:RoomNode ^\S+\s+11
     4:LaCrosse ^(\S+\s+9 |OK\sWS\s)
     5:AliRF    ^\S+\s+5
     6:EMT7110  ^OK\sEMT7110\s
     7:KeyValueProtocol ^OK\sVALUES\s
   Readings:
     2016-04-13 16:53:42   state           initialized
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   initCommands 30t 0a 868280f v


NACHTRAG: Habe den verbose-Level des JeeLink auf 5 gesetzt, das hier sehe ich beim Pairing-Versuch:

Code Auswählen Erweitern


2016.04.13 17:18:07 5: JeeLink/RAW: /OK 9
2016.04.13 17:18:07 5: JeeLink/RAW: OK 9/ 37 129
2016.04.13 17:18:07 5: JeeLink/RAW: OK 9 37 129 /4 227 49
2016.04.13 17:18:07 5: JeeLink/RAW: OK 9 37 129 4 227 49/

2016.04.13 17:18:07 5: myJeeLink dispatch OK 9 37 129 4 227 49
2016.04.13 17:18:08 4: LaCrosse: Unknown device 25, please define it
2016.04.13 17:18:12 5: JeeLink/RAW: /OK 9
2016.04.13 17:18:12 5: JeeLink/RAW: OK 9/ 37 129 4 228 49

2016.04.13 17:18:12 5: myJeeLink dispatch OK 9 37 129 4 228 49
2016.04.13 17:18:12 4: LaCrosse: Unknown device 25, please define it
2016.04.13 17:18:17 5: JeeLink/RAW: /OK 9 37
2016.04.13 17:18:17 5: JeeLink/RAW: OK 9 37/ 129 4 227 49

2016.04.13 17:18:17 5: myJeeLink dispatch OK 9 37 129 4 227 49
2016.04.13 17:18:17 4: LaCrosse: Unknown device 25, please define it
2016.04.13 17:18:22 5: JeeLink/RAW: /OK 9 3
2016.04.13 17:18:22 5: JeeLink/RAW: OK 9 3/7 129 4 227 49

2016.04.13 17:18:22 5: myJeeLink dispatch OK 9 37 129 4 227 49
2016.04.13 17:18:22 4: LaCrosse: Unknown device 25, please define it
2016.04.13 17:18:27 5: JeeLink/RAW: /OK 9 37
2016.04.13 17:18:27 5: JeeLink/RAW: OK 9 37/ 129 4 22
2016.04.13 17:18:27 5: JeeLink/RAW: OK 9 37 129 4 22/7 49

2016.04.13 17:18:27 5: myJeeLink dispatch OK 9 37 129 4 227 49
2016.04.13 17:18:27 4: LaCrosse: Unknown device 25, please define it
2016.04.13 17:18:32 5: JeeLink/RAW: /O
2016.04.13 17:18:32 5: JeeLink/RAW: O/K 9 37 1
2016.04.13 17:18:32 5: JeeLink/RAW: OK 9 37 1/29 4 227 49

2016.04.13 17:18:32 5: myJeeLink dispatch OK 9 37 129 4 227 49
2016.04.13 17:18:32 4: LaCrosse: Unknown device 25, please define it


Aber wie gesagt, es wird kein Sensor angelegt und auch der Raum taucht nicht auf.

Wäre für Hilfe sehr dankbar.