Hier wird das Thema behandelt, wie man mit Hilfe eines JeeLink von JeeLabs (https://www.digitalsmarties.net/products/jeelink) Sensoren empfängt, die das LaCrosse IT+ Protokoll (z.B. von Technoline) senden.
Die initiale Firmware für den JeeLink wurde von ohweh(Oliver) und das zugehörige FHEM-Modul 36_LaCrosse.pm wurde initial von justme1968(andre) geschrieben.
Vielen Dank an die beiden dafür. Inzwischen hat beides HCS als maintainer übernommen.
Wichtig: wer einen JeeLink selbst bauen will (einen sogenannten JeeLink-Clone), sollte unbedingt die Hinweise unten beachten.
Wer LaCrosse-Sensoren empfangen will, sollte zuerst die Überlgung anstellen, was für ihn der bessere Weg ist, da es mindestens zwei Möglichkeiten gibt:
- Den hier beschriebenen LaCrosse-Sketch für den JeeLink
- Das LaCrosseGateway
Unterschied:
Die JeeLink-Firmware basiert auf dem oben genannten JeeLink, ein Stick, der per USB angeschlossen wird, das LaCrosseGateway basiert auf einem ESP8266 der u.A. WiFi unterstützt.
Für den JeeLink gibt es auch Firmware für PCA301 und Energy Count 3000, aber man benötigt für jedes Protokoll einen eigenen Stick.
Das LaCrosseGateway kann diese Protokolle parallel (wenn man mehrere RFM69 angeschlossen hat)
Die JeeLink-Firmware hat die machbaren Features erreicht, hier sind keine Erweiterungen mehr zu erwarten.
Funktionalitäten vom LaCrosseGateway, die der JeeLink-Sketch nicht hat:
- Anbindung per WiFi oder per USB (JeeLink nur USB)
- Abfrage und Steuerung von PCA301 Funk Mess-/Schalt-Steckdosen
- Empfang von Energy Count 3000 Funk Mess-Steckdosen
- Optionales OLED Display
- Transparente Bereitstellung von bis zu zwei MiniCUL über zwei serielle Brücken
- Anbindung eines Nextion-Displays
- "OnBoard" Sensoren BMP180, BME280, LM75, DHT22
- Erweiterungsmöglichkeit für 8 Digital Aus-/Eingänge
- Ein Analogport für einen eigenen externen Analogsensor
- WebFrontend für die Konfiguration, Überwachung, ...
- usw.
Wiki JeeLink: https://wiki.fhem.de/wiki/JeeLink
Wiki LaCrosseGateway: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x
JeeLink Thread: hier :-)
LaCrosseGateway Thread: https://forum.fhem.de/index.php/topic,43672.0.html
Im jeweiligen Wiki ist die Inbetriebnahme beschrieben.
Für ein "Grundmodell" ist der Materialaufwand (Euro) ungefähr gleich.
Man sollte also zuerst ermitteln, welche Variante die eigenen Anforderungen besser erfüllt.
JeeLink-Clone: Es werden immer wieder JeeLink-Clone gebaut, die nicht oder nicht richtig oder nur eine Zeit lang funktionieren.
Das am meisten verbreitete Problem ist, dass es im Internet in Blogs usw. gibt, die die üblicherweise erforderliche Pegelanpassung für den RFM12/RFM69 nicht haben.
Die meisten Clone basieren auf einem Aruino Nano, der mit 5V Betriebsspannung läuft. Der angeschlossene RFMxx wird dann mit dem meist vorhandenen 3.3V-Ausgang des Nano mit Betriebsspannung versorgt.
So weit ist das OK. RFM12/RFM69 sind 3.3V Bausteine. Das bedeutet, dass nicht nur die Spannungsversorgung sondern auch die Signaleingänge (SEL, SCK und SDI) mit 3.3V betrieben werden müssen.
Der Arduino liefert aber auf seinen Ausgängen (üblicherweise D10, D11 und D13) einen V5-Pegel, da er ja ein 5V-Device ist.
Eigentlich ist der Fall klar, man würde ja auch keine 12V-Glühbirne an eine 230V-Steckdose anschließen :-)
Für diese Signalleitungen ist also eine Pegelanpassung (meist als LevelShifter oder LevelConverter bezeichnet) erforderlich.
Dazu kann man entweder Widerstandsspannungsteiler nehmen (die den Nachteil haben, dass sie die Flanken der Signale abrunden) oder man verendet LevelShifter mit Feldeffekttransistoren, die diesen Effekt nicht haben.
Diese Clone sind übrigens keine echten Clone. Im Original JeeLink wird ein ATMEGA328 mit 3,3V Versorgungsspannung betrieben, was dann zur Folge hat, dass er auf den Ports auch nur 3.3V liefert und keine Pegelanpassung erforderlich ist.
Dass der ATMEGA328 im Original JeeLink mit 3.3V bei 16MHz Taktfrequenz außerhalb seine Spezifikation betrieben wird (also übertaktet ist) nimmt man da in Kauf und es scheint üblicherweise auch kein Problem zu sein.
Und man solle inzwischen eher einen RFM69CW anstatt einen RFM12 verwenden, da der RFM69CW eine höhere Eingangsempfindlichkeit hat und somit einen etwas besseren Empfang.
Gruss Billy / HCS
========================================================================================
noch ein paar kleine anmerkungen:
- 36_JeeLink.pm ist seit eben in der passenden version eingecheckt. d.h. ab dem update morgen ist es nicht mehr nötig die verison aus dem zip file zu verwenden.
- zu 6. von oben: ich habe inzwischen das attribut ignore für 36_LaCrosse.pm aktiviert damit kann man dann fehlerhaft devices ignorieren bzw. 'verstecken'.
- falls jemand einen passenden wind oder regenmengensensor in betrieb hat bitte melden. die würde ich gerne auch interstützen. vor allem den regen mengen sensor.
- wenn es mehr als zwei anwender gibt checke ich auch 36_LaCrosse.pm ganz normal ein.
gruss
andre
Hallo andre
Zitat- falls jemand einen passenden wind oder regenmengensensor in betrieb hat bitte melden. die würde ich gerne auch interstützen. vor allem den regen mengen sensor.
Hast du da einen bestimmten im Auge?
Wenn der Jeelink bei mir sowieso dranhängt schaffe ich mir vielleicht einen an?
Gruss
Billy
ich hab nur auf verschiedenen seiten z.b. hier http://en.lacrossetechnology.fr/R-20-A1-0-rain-sensor.html (//en.lacrossetechnology.fr/R-20-A1-0-rain-sensor.html) gesehen das es scheinbar recht viele gibt die zum teil sehr günstig sind. ich weiss aber nicht ob und wo die in deutschland zu bekommen sind.
gruss
andre
Der hier scheint auch nach Deutschland zu liefern!
La Crosse TX34-ITregensensor 868MHz zum Sonderpreis von Euro 28.95 und lieferbar.
http://weerhuisje.nl/index.php?item=la-crosse-tx34-itregensensor-868mhz---draadloos&action=article&group_id=10000018&aid=9345&lang=NL (//weerhuisje.nl/index.php?item=la-crosse-tx34-itregensensor-868mhz---draadloos&action=article&group_id=10000018&aid=9345&lang=NL)
Wenn dein erster Link stimmt müsste er gehen da IT+
Siehe auch
http://www.weerstation-emmen.nl/hardware.php (//www.weerstation-emmen.nl/hardware.php)
Gruss
Billy
ich würde sagen ja. einen versuch wäre es wert.
gruss
andre
Hi
Bin mir inzwischen ziemlich sicher,
dass die TFA Dostmann IT Serie auch laufen müsste!
http://tfa-dostmann.de/index.php?id=117 (//tfa-dostmann.de/index.php?id=117)
Zitat- falls jemand einen passenden wind oder regenmengensensor in betrieb hat bitte melden. die würde ich gerne auch interstützen. vor allem den regen mengen sensor.
Vielleicht gibts da einen mit passendem Regensensor!
Gruss Billy
Hi,
verstehe ich das richtig, dass dieses Modul dann eine günstige Alternative zu den recht teuren ASH550 / S555TH Sensoren ist, um Luftfeuchte und Raumtemperatur mit FHEM zu messen?
Das wäre ja super! Man bräuchte dann nur den JeeLink und passende Sensoren, oder? Einen schon vorhandenen CUL für FS20 auf 868 MHz kann man wahrscheinlich nicht verwenden, um damit FS20 und JeeLink zusammen abzudecken?
Im Beispiel aus der PDF Datei im ersten Post eignet sich der TX27 TH und TX29 DTH um Feuchte und Temperatur zu messen, oder?
Können diese Sensoren genutzt werden? In der Beschreibung steht nur etwas von Temperatur aber nicht für feuchte. Oder gibt es andere gute Bezugsquellen für Feuchte- und Temperatursender?
http://www.technikdirekt.de/main/de/haushalt/raumklima/wetterstationen/516747/-/article-technoline-tx-29-it.html (//www.technikdirekt.de/main/de/haushalt/raumklima/wetterstationen/516747/-/article-technoline-tx-29-it.html)
http://www.technikdirekt.de/main/de/haushalt/raumklima/wetterstationen/391076/-/article-technoline-tx-29-dth-it-aussensender.html (//www.technikdirekt.de/main/de/haushalt/raumklima/wetterstationen/391076/-/article-technoline-tx-29-dth-it-aussensender.html)
Danke!
Schöne Grüße
Daniel
Hi Daniel
Zitatverstehe ich das richtig, dass dieses Modul dann eine günstige Alternative zu den recht teuren ASH550 / S555TH Sensoren ist, um Luftfeuchte und Raumtemperatur mit FHEM zu messen?
Richtig!
ZitatMan bräuchte dann nur den JeeLink und passende Sensoren, oder? Einen schon vorhandenen CUL für FS20 auf 868 MHz kann man wahrscheinlich nicht verwenden, um damit FS20 und JeeLink zusammen abzudecken?
Jawohl du brauchst zusätzlich einen Jeelink und die Sensoren!
ZitatIm Beispiel aus der PDF Datei im ersten Post eignet sich der TX27 TH und TX29 DTH um Feuchte und Temperatur zu messen, oder?
Jawohl !!!
Siehe Da http://www.heavyweather.de/TX27-IT-Aussensensor-868MHz-TX-27-IT-fuer-WS-9620-und-WS-9720_p884_x2.htm (//www.heavyweather.de/TX27-IT-Aussensensor-868MHz-TX-27-IT-fuer-WS-9620-und-WS-9720_p884_x2.htm)
und da http://www.heavyweather.de/TX-29-DTH-IT-Aussensensor-TX29-DTH-IT_p1713_x2.htm (//www.heavyweather.de/TX-29-DTH-IT-Aussensensor-TX29-DTH-IT_p1713_x2.htm)
Die beiden habe ich für Temperatur + Feuchte.
Der ist billiger und müsste auch gehen.
http://www.heavyweather.de/TX-35-Aussensensor-TX-35DTH-IT-TX-35-DTH-IT_p1826_x2.htm (//www.heavyweather.de/TX-35-Aussensensor-TX-35DTH-IT-TX-35-DTH-IT_p1826_x2.htm)
Gruss Billy
Hallo zusammen,
wo habt ihr euren jeelink bestellt?
Gruß
Damian
meiner ist direkt aus dem jeelabs shop.
gruss
andre
Zitat von: justme1968 schrieb am Fr, 27 September 2013 08:03meiner ist direkt aus dem jeelabs shop.
gruss
andre
Danke für die Info.
Gruß
Damian
und noch eine Frage:
Wie oft sendet der TX29DTH?
Gruß
Damian
Auszug aus dem Log sollte deine Frage beantworten!
2013-09-16_05:55:16 LaCrosse_38 temperature: 21.8
2013-09-16_05:55:16 LaCrosse_38 humidity: 63
2013-09-16_05:55:34 LaCrosse_38 temperature: 21.8
2013-09-16_05:55:34 LaCrosse_38 humidity: 63
2013-09-16_05:56:10 LaCrosse_38 temperature: 21.8
2013-09-16_05:56:10 LaCrosse_38 humidity: 63
2013-09-16_05:56:19 LaCrosse_38 temperature: 21.8
2013-09-16_05:56:19 LaCrosse_38 humidity: 63
2013-09-16_05:56:27 LaCrosse_38 temperature: 21.8
2013-09-16_05:56:27 LaCrosse_38 humidity: 63
2013-09-16_05:56:36 LaCrosse_38 temperature: 21.8
2013-09-16_05:56:36 LaCrosse_38 humidity: 63
2013-09-16_05:56:54 LaCrosse_38 temperature: 21.8
2013-09-16_05:56:54 LaCrosse_38 humidity: 63
2013-09-16_05:57:03 LaCrosse_38 temperature: 21.8
2013-09-16_05:57:03 LaCrosse_38 humidity: 63
2013-09-16_05:57:12 LaCrosse_38 temperature: 21.8
2013-09-16_05:57:12 LaCrosse_38 humidity: 63
2013-09-16_05:57:21 LaCrosse_38 temperature: 21.8
2013-09-16_05:57:21 LaCrosse_38 humidity: 63
2013-09-16_05:57:30 LaCrosse_38 temperature: 21.8
2013-09-16_05:57:30 LaCrosse_38 humidity: 63
2013-09-16_05:57:47 LaCrosse_38 temperature: 21.8
2013-09-16_05:57:47 LaCrosse_38 humidity: 63
2013-09-16_05:57:56 LaCrosse_38 temperature: 21.8
2013-09-16_05:57:56 LaCrosse_38 humidity: 63
2013-09-16_05:58:05 LaCrosse_38 temperature: 21.8
2013-09-16_05:58:05 LaCrosse_38 humidity: 63
2013-09-16_05:58:14 LaCrosse_38 temperature: 21.8
2013-09-16_05:58:14 LaCrosse_38 humidity: 63
2013-09-16_05:58:23 LaCrosse_38 temperature: 21.8
2013-09-16_05:58:23 LaCrosse_38 humidity: 63
Billy
Oje, dann scheint diese Aussage http://www.computerbild.de/artikel/cb-Test-PC-Hardware-Conrad-WS-9130-IT-4372794.html (//www.computerbild.de/artikel/cb-Test-PC-Hardware-Conrad-WS-9130-IT-4372794.html) zum TX29-IT mit vier Sekunden (bei Dir wahrscheinlich mit Aussetzern) zu stimmen.
Beim Einsatz vieler FS20 und HM-Komponenten ist das für mich ein K.O.-Kriterium.
Gruß
Damian
Dafür hat Fhem doch das attr event-min-interval reading!
Damit kannst du das Logging Intervall doch bestimmen.
Billy
Zitat von: Billy schrieb am Fr, 27 September 2013 20:50Dafür hat Fhem doch das attr event-min-interval reading!
Damit kannst du das Logging Intervall doch bestimmen.
Billy
Das Senden und damit der Traffic im 868er-Bereich wird dadurch aber nicht reduziert.
Gruß
Damian
Hallo
ein Jeelink funktioniert entweder nur mit LaCrosse oder PCA-301?
ja. entweder oder.
ob die LaCrosse sensoren fs20 oder hm stören würde ich zumindest auf einen versuch ankommen lassen. ich habe inzwischen neben fs20 und hm noch die panstamps und die pca301 im einsatz und würde mal behaupten die stören sich wenn überhaupt nur unmerkbar. ich habe keine verstärten hm aussetzer. selbst wenn ich aus versehen einen panstamp kontinulierich mehrere dutzend nachrichten pro sekunde senden lasse.
gruss
andre
Hi,
Zitat von: Damian schrieb am Fr, 27 September 2013 20:43Beim Einsatz vieler FS20 und HM-Komponenten ist das für mich ein K.O.-Kriterium.
Die Anzahl anderer Komponenten im 433 oder 868 MHz Bereich dürfte doch egal sein, bezüglich der 1% Regel.
Der JeeLink hat ja nix mit den FS20 Geräten zu tun und der FS20-CUL nix mit den Sensoren. Also haben beide Sticks doch jeweils 1% zur Verfügung und behinder sich da nicht gegenseitig.
Schöne Grüße
Zitat von: justme1968 schrieb am Sa, 28 September 2013 00:22ja. entweder oder.
ob die LaCrosse sensoren fs20 oder hm stören würde ich zumindest auf einen versuch ankommen lassen. ich habe inzwischen neben fs20 und hm noch die panstamps und die pca301 im einsatz und würde mal behaupten die stören sich wenn überhaupt nur unmerkbar. ich habe keine verstärten hm aussetzer. selbst wenn ich aus versehen einen panstamp kontinulierich mehrere dutzend nachrichten pro sekunde senden lasse.
gruss
andre
ja, aufgrund verschiedener Modulationen und Kodierungen kann es natürlich sein, dass nur geringe oder sogar gar keine Störungen stattfinden. Aufgrund der 1% Regel müssen dann die Sendesequenzen kleiner 40 msec sein. Bei FS20 sind es schon mal 200 msec (wegen Wiederholung). Der S300TH sendet immerhin alle 180 Sekunden, da ist man noch sehr weit von 1% entfernt. Es sind ja im Gegensatz zu anderen Komponenten immerhin "Dauerstrahler", da sollte man sich schon Gedanken machen, wie viele man sich davon zuhause aufhängt.
Ich warte dann auf eure Erfahrungen.
Gruß
Damian
Zitat von: DannyP schrieb am Sa, 28 September 2013 05:54Hi,
Zitat von: Damian schrieb am Fr, 27 September 2013 20:43Beim Einsatz vieler FS20 und HM-Komponenten ist das für mich ein K.O.-Kriterium.
Der JeeLink hat ja nix mit den FS20 Geräten zu tun und der FS20-CUL nix mit den Sensoren. Also haben beide Sticks doch jeweils 1% zur Verfügung und behinder sich da nicht gegenseitig.
Schöne Grüße
Beide Aussagen sind falsch.
Gruß
Damian
Zitat von: Damian schrieb am Sa, 28 September 2013 10:10Beide Aussagen sind falsch.
Hallo Damian,
kannst du mir bitte auf die Sprünge helfen, wo mein Denkfehler ist?
Wenn ich einen CUL für die FS20 Geräte habe, läuft die Kommunikation für die FS20 Geräte über diesen CUL. Die FS20 Geräte "verbrauchen" dann die zulässige 1% Zeit vom FS-20 CUL.
Dieser FS20-CUL kann aber doch mit dem, was von den Sensoren gesendet wird nix anfangen und geht dann auch nicht zu lasten dieses CULs, oder? Statt dessen brauch ich doch den JeeLink, damit ich auch die Signale dieser Sensoren auffangen kann. Somit verbrauchen die dann die 1% Zeit vom JeeLink Stick.
Umgekehrt kann der JeeLink doch auch nix mit den FS20 Signale anfangen.
Die Frequenz ist zwar die gleiche, aber das Protokoll ein anderes. Oder geht das trotzdem zu Lasten der 1% Regel auf beiden Sticks gleichzeitig, allein durch die Tatsache, dass die Frequenz die gleiche ist?
Danke & schöne Grüße
Daniel
Hallo Daniel,
Tatsache ist dass, Sender für FS20 und Sender für JeeLink im gleichen SRD 868 MHz Frequenzband senden (http://de.wikipedia.org/wiki/Short_Range_Devices (//de.wikipedia.org/wiki/Short_Range_Devices)). D. h. wenn der TX29 und z. B. ein S300TH zur gleichen Zeit senden, dann könnten sie sich (müssen es nicht unbedingt) trotz verschiedener Protokolle und Modulationen stören. Damit die Wahrscheinlichkeit eine Störung, ich nenne es mal Kollision, relativ gering ist, wurde durch die Bundesnetzagentur festgelegt (gilt wohl für Europa), dass in diesem Frequenzbereich maximal nur in einem Prozent der Zeit gesendet werden darf.
Nun komme ich zur Wahrscheinlichkeitsrechnung.
Wenn nun zwei Sender die maximale Sendezeit von 1 % ausnutzen und das scheint mir beim TX29 der Fall zu sein, dann ist das noch nicht schlimm. Denn wenn du zwei Sender hast, die zu einem Prozent senden, dann ergibt sich eine Wahrscheinlichkeit einer Kollision von (1/100+1/100)*(1/100+1/100)=4/10000=0,4 % - also unkritisch.
Anders sieht es aus, wenn die Anzahl der Sender zunimmt.
Bei z. B. 30 solchen Sendern sieht die Welt schon ganz anders aus: 30/100^2+30/100^3+30/100^4... liegt die Wahrscheinlichkeit einer Kollision schon bei ca. 13 % und das ist nicht unerheblich, denn jede 8 Nachricht kollidiert mit einer oder mehreren anderen und dann könnten zwei oder mehr Nachrichten verloren gehen.
Dessen ist sich offenbar ELV auch bewusst, deswegen gibt es von denen keine Sender, zumindest keine, die ich kenne, die so oft regelmäßig senden würden.
Gruß
Damian
Hallo Damian,
super, vielen Dank für deine ausführliche Erklärung! Wieder was gelernt :-)
Schönen Sonntag!
Daniel
Hi,
ich verzweifel gerade dabei einen JeeLink 868 MHz Stick mit der .ino Datei aus dem ersten Posting zu flashen :-(
Ich bekomme in der Arduino IDE nur die folgende Meldung:
ZitatIn file included from C:\Program Files (x86)\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:215,
from LaCrosseITPlusReader05.ino:41:
C:\Program Files (x86)\Arduino\hardware\arduino\avr\variants\standard/pins_arduino.h:43: error: expected unqualified-id before numeric constant
Board ist auf einen Arduino Uno eingestellt und Com Port stimmt auch.
Ich habe auch verschiedene Versionen der IDE getestet, leider immer ohne Erfolg.
Muss ich noch auf etwas achten?
Schöne Grüße
Daniel
Hallo Daniel,
könnte sein, dass es daran liegt, dass in deinen Arduino libraries
der jeelib Anteil fehlt!
Kopiere mal die angehängte jeelib Librarie in deinen libraries Ordner.
Und rufe die dort unter examples / LaCrosseITPlusReader/ vorhandene ino auf.
dann müsste es laufen. Bei mir unter Version arduino-1.0.5.
Gruss
Billy
Hallo Billy,
genau das war es. Danke! Nun läuft alles und funktioniert wie es soll :-)
Schöne Grüße
Daniel
Hi Andre
Sind wir jetzt schon mehr als 2?
Zitat von: justme1968 schrieb am Mo, 16 September 2013 15:33noch ein paar kleine anmerkungen:
- wenn es mehr als zwei anwender gibt checke ich auch 36_LaCrosse.pm ganz normal ein.
gruss
andre
Gruss Billy
ich checke es ein sobald ich von oliver die info zum batterie stand bekommen habe.
gruss
andre
Hallo zusammen,
dank diesen Forums darf ich ebenfalls einpaar Temperatursensoren als meine Eigen nennen.
Ich habe jedoch das Gefühl, dass diese nicht ganz richtig funktionieren.
Beim Einlegen der Batterie in den Sensor wird dieser im FHEM auch gleich angezeigt.
Im Laufe der Stunden werden komischerweise immer mehr Sensoren eingebunden (mit komischen Werten). Es ist jedoch nur einer aktiv.
Das verhalten habe ich mit den TX27TH-IT und den TX 35DTH-IT.
Eingebunden wurden die
36_Jeelink.pm (# $Id: 36_JeeLink.pm 3914 2013-09-16 13:35:50Z justme1968 $)
36_LaCrosse.pm (# $Id: 36_LaCrosse.pm 3889 2013-09-10 10:40:15Z justme1968 $)
Anbei ein Screenshot
der jeelink sketch scheint manchmal nicht sensitiv genug zu sein um 'echte' sensoren von falschem oder anderen signalten zu unterscheiden. vielleicht ist auch der ein oder andere sensor eines nachbarn dabei (das sind vermutlich die bei denen die temperatur stimmt).
oliver will den sketch noch mal anpassen das er batterie meldungen mit liefert. dann werden neue sensoren beim autocreate nur noch angelegt wenn auch die batterie voll ist.
bis dahin hilft erst mal nur autocreate abzuschalten.
gruss
andre
stimmt, ich habe mal vorsichtshalber alle Temp-Sensoren ausgemacht. Trotzdem innerhalb von 24h über angebliche 52 LaCrosse Temperatursensoren gefunden. Und das auf dem Dorf :o :D
Zitat von: Billy am 04 Oktober 2013, 18:06:11
Hi Andre
Sind wir jetzt schon mehr als 2?
Gruss Billy
Es sind wohl mehr als 2. :-)
Ich kann bestätigen, das mit einem Jeenode und den Sensoren von TFA 35.1111.IT und wohl auch Conrad WS9160-IT Temp/Hum bzw nur Temp zu empfangen sind.
Letzeres muss ich aber nochmal genau verifizieren, die Anzahl der Sensoren stieg innerhalb von
2 Stunden auf ca. 15 an.
Gruß Thorsten
Hallo
tut mir leid, durch das Umstellen der Forensoftware bin ich wohl nicht mehr automatisch über Nachrichten in diesem
Thread informiert worden.
@Andre
Zitatoliver will den sketch noch mal anpassen das er batterie meldungen mit liefert. dann werden neue sensoren beim autocreate nur noch angelegt wenn auch die batterie voll ist.
Der sensor liefert 2 Meldungen mit.
1. Den new Battery Indikator der m.W. nichts mit neuer Batterie zu tun hat sondern mit dem Pairing verhalten.
2. Die Zustandsmeldung low Battery --> Da sollte man die Batterie tauschen!
Vorsicht ! Bei jedem Neueinlegen einer Batterie (egal ob voll oder nicht) wird das Pairing verhalten ausgelöst.
Der Sensor erhält normalerweise eine neue ID.
Damit lässt sich auch vermeiden dass man die gleiche ID wie ein Nachbar hat.
Siehe auch Hinweis aus folgendem Link. http://gcrnet.net/node/32 (http://gcrnet.net/node/32)
Zitat:
Principle is that a channel number is randomly chosen by transmitter upon initialisation. The transmitter will use this channel ID forever, up to the next initialization (battery change). To help pairing, a flag telling the transmitter is in this pairing phase is set during approximately 4h30mn.
An der Geschichte ist Oliver gerade dran.
@dima
Um Nachbarsensoren auszublenden hat ja Andre schon was vorbereitet!
Zitat- zu 6. von oben: ich habe inzwischen das attribut ignore für 36_LaCrosse.pm aktiviert damit kann man dann fehlerhaft devices ignorieren bzw. 'verstecken'.
Gruss Billy
Aber verwenden kann man das "Ignore" noch nicht, oder? Konnte es nicht aktivieren.
Werden dieser Sketch anschließend auch ins Contrib übernommen?
Ansonsten funktioniert es sehr gut! Empfange nur leider ca. 30 Sensoren meiner Nachbaren, alle dürften jedoch relativ weit weg sein, da pro Nacht nur 1-10 Werte übermittelt werden!
Kann man auch das Autocreate nur für LaCross-deaktivieren?
das ignorier sollte gehen. aber jeweils nur für ein device das schon da ist.
ich baue noch was ein damit man das autocreate nur für la crosse abschalten kann. zur zeit geht das nur global für alles.
sketch und modul wird noch eingecheckt. ich warte noch auf die änderungen von Oliver zum batterie stand.
gruss
andre
Danke für die Antwort, ich bekomme aber immer folgende Meldung....
LaCrosse_D4: unknown attribute ignore, choose one of verbose:0,1,2,3,4,5 room group comment alias eventMap userReadings IODev event-on-change-reading event-on-update-reading event-min-interval stateFormat devStateIcon devStateStyle icon sortby webCmd or use attr global userattr ignore
Noch eine Frage. Kann ich irgendwie meine Sender wiedererkennen? Nach einem Batterietausch ist es fü mich nicht imme rleicht, die Geräte wieder ordentlich zuzuordnen.
Eine Art Seriennummer oder ähnliches wäre sehr fein ;-)
has du das aktuelle modul das ich oben gepostet hatte? nicht das aus dem ersten beitrag.
dir sensoren haben so viel ich weiß keine eindeutige id und lassen sich nicht automatisch wieder erkennen. ich glaube da hilft nur die batterien nicht in allen sensoren auf einmal zu tauschen.
gruss
andre
Hallo Andre,
sorry, nenn mich Blind, aber ich sehe in diesem Thread keinen anderen Download als den im ersten Post.
Ich habe extra nochmals alles durchgelesen und auch die SuFu des Browsers (nach runtergeladen) verwendet.... hast Du einen Link?
du hast recht. ich finde es auch nicht mehr. sehr seltsam...
ich lade es heute abend noch mal hoch.
gruss
andre
@Andre
Zitatich warte noch auf die änderungen von Oliver zum batterie stand.
Ich war schon vor ein paar tagen mit Oliver in Kontakt.
Er hat im Moment keine Zeit (andere Probleme) bleibt aber dran.
Gruss Billy
hier die version die ignore kann.
ich baue gerde eine option in den das JeeLink modul ein das autocreate nur für eine bestimmte zeit aktiv ist. ähnlich wie das hmPairForSec. aber das dauert noch ein bischen.
gruss
andre
Danke, ignore funktioniert bestens!
Zitat von: justme1968 am 23 Oktober 2013, 09:34:59
dir sensoren haben so viel ich weiß keine eindeutige id und lassen sich nicht automatisch wieder erkennen.
Aber im Sketch gibt es folgendes Kommentar:
// To filter for specific sensors, use a statement like this:
//
// if (sensor_id != 0xAA && sensor_id != 0xBB)
// return "";
Somit müsste von der
JLLaCR_RAWMSG=OK 9 48 1 4 91 99das 48 eine SensorID sein, oder?
das problem ist das die sensoren beim batterie wechsel sich eine neue zufällige id suchen. und das lässt sich nicht verhindern.
gruss
andre
Hast Du eine Idee, warum ich immer 2x in 4 Sekunden eine Temperaturangabe mit "T: " erhalte, und danach wieder 66 Sekunden lang einige mit "temperature: 11.4" ?
2013-10-23_20:33:10 temp.bz.Aussenthermometer T: 11.5
2013-10-23_20:33:14 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:33:14 temp.bz.Aussenthermometer T: 11.4
2013-10-23_20:33:19 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:33:23 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:33:32 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:33:41 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:33:49 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:33:58 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:07 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:16 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:20 temp.bz.Aussenthermometer temperature: 11.5
2013-10-23_20:34:20 temp.bz.Aussenthermometer T: 11.5
2013-10-23_20:34:24 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:24 temp.bz.Aussenthermometer T: 11.4
2013-10-23_20:34:29 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:33 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:42 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:51 temp.bz.Aussenthermometer temperature: 11.4
2013-10-23_20:34:59 temp.bz.Aussenthermometer temperature: 11.4
die temperature zeilen sind für das reading temperaure. die T: sind für state. das state reading wird nur aktualisiert wenn sich der wert geändert hat. temperature immer wenn etwas empfangen wurde.
gruss
andre
anbei die aktuelle version. erst mal nur zum testen für oliver:
- das batterie flag im protokoll wird ausgewertet und autocreate nur noch aufgerufen wenn das flag gesetzt ist. etwa 6 stunden nach dem einlegen sollte es wieder auf 0 wechseln
- es gibt ein neues attribut filterThreshold. werte die vom letzen um mehr als diesen wert abweichen werden ignoriert. der default ist 10
ignore gab es in der letzen version ja schon. ansonsten kann man mit dem attribut ignoreTypes bei autocreate gezielt besimmte device typen vom autocreate ausschliessen.
wenn das alles zusammen immer noch nicht reicht baue ich doch noch ein pairForSecs ein.
gruss
andre
Moin :)
Hab das Batterie-Bit isolieren können. Übertragung erfolgt mit dem Kanal-Byte an Stelle F0. Nach dem (Wieder-)Einlegen der Batterie ist dieses für ca. 6 Stunden gesetzt, anschliessend kippt es auf "0".
Anbei die neue Version für den JeeLink. Bitte erst dann flashen, wenn auch die neue Version des 36_LaCrosse.pm zur Verfügung steht (Andre ist schon dran).
Gruss
Oliver
Also bis jetzt schaut's gut aus. Battery-Reading ist da. Nu heisst es abwarten bis das Bit kippt.
Gruss
Oliver
Toll was Ihr beide da gemacht habt!
@Andre
Zitat- das batterie flag im protokoll wird ausgewertet und autocreate nur noch aufgerufen wenn das flag gesetzt ist. etwa 6 stunden nach dem einlegen sollte es wieder auf 0 wechseln
Was passiert wenn der Nachbar in seinen Sensor eine neue Batterie einlegt? Springt dann bei mir autocreate an?
Aus meiner Erfahrung dürfte
Zitatwenn das alles zusammen immer noch nicht reicht baue ich doch noch ein pairForSecs ein.
das die beste Lösung sein.
Aber vielleicht habe ich da was übersehen.
Billy
ja. mit der version von oben würde autocrate natürlich auch für den nachbarn anspringen.
ich hab mal eine version angehängt die ein set LaCrossePairForSec <sekunden> kann. autocreate wird nur aktiv wenn die batterie frisch eingelegt wurde und LaCrossePairForSec gesetzt wurde.
es müssen beide files aktualisiert werden. bitte mal testen ob das besser ist.
wenn alles geht würde ich es so einchecken.
gruss
andre
Hi Andre,
Habe mal alles neu installiert!
Zitatset LaCrossePairForSec <sekunden>
mal kurz getestet klappt hervorragend! Sensor wird erkannt wie gewünscht.
Nochmals vielen Dank an dich und Oliver für die hervorragende Implementation.
Gruss Billy
@ Andre
Zitat- es gibt ein neues attribut filterThreshold.
Das attribut filterThreshold finde ich nicht, bin ich blind oder ist es in der neuesten Version nicht vorhanden.
Gruss Billy
du hast recht. oben im beitrag hing die falsche version dran. ich habe es dort geändert.
gruss
andre
Ich habe gestern abend die neue Datei eingespielt, er bietet mit im WebGUI nur attr filterThreshold als Wert 1 an, habe ich erstmal genommen. Heißt das 1 oder 0 im Sinne von true/false, oder ist das der Abweichungswert?
Die Temperaturkurve sieht jetzt gut aus, es gibt keine Ausreißer, in der Luftfeuchtekurve aber weiterhin. Läuft der Filter nur auf dem 'T: '-Wert?
Hallo Andre,
der Filter ist jetzt drin und das Battery bit für den Batteriewechsel ist von 1 auf 0 wie erwartet.
Ich vermute dass der
Zitatweak_batt indicator (1 bit) : this bit indicates if the sensor batteries become too old.
Siehe auch decoding Schema in Anlage noch nicht eingebaut ist. Entspricht Battery ok bzw. Battery low
Gruss Billy
filterThreshold ist ein integer und gibt den absolutwert der erlaubten abweichung an. wenn nichts gesetzt ist wird 10 verwendet. das setzen im webgui hab ich eben repariert.
ich hatte die abweichung bis jetzt nur für die temperatur geprüft. und dann beide readings nicht aktualisiert. in der angehängten version werden temperatur und feuchtigkeit beide geprüft. aber immer noch gegen dein einen filterThreshold wert. bitte versuch mal ob das reicht oder ob es zwei unabhängig einstellungen sein müssen.
die beiden werte aus der vorherigen messung stehen jetzt auch in den internal values. da sieht man dann ob und wie gross die ausreisser sind wenn die readings nicht aktualisiert werden.
ich hatte bis jetzt nur das new battery bit geprüft. in der angehängten version gibt jetzt auch ein battery reading. ich weiss aber nicht ob olivers sketch das bit auch durch reicht. ich hab mal wie im schema bit 7 der feuchtigkeit genommen.
gruss
andre
Danke,
das mit
Zitatbattery reading
werde ich testen
Billy
Hallo,
erstmal danke für eure Bemühungen!
Ich habe inzwischen auch einen JeeLink im Einsatz und habe gerade einen Technoline TX29IT Sensor geliefert bekommen.
Leider bekomme ich nur folgende Ausgaben im Logfile:
2013.11.04 11:48:45 3: JLLaCR: Unknown code D:B8: 23.8:99, help me!
2013.11.04 11:48:49 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:48:54 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:48:58 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:49:03 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:49:07 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:49:11 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:49:16 3: JLLaCR: Unknown code D:B8: 23.9:99, help me!
2013.11.04 11:49:20 3: JLLaCR: Unknown code D:B8: 24.0:99, help me!
2013.11.04 11:49:25 3: JLLaCR: Unknown code D:B8: 24.0:99, help me!
Hat jemand eine Idee? Habe ich einen Anfängerfehler gemacht? Oder ist dieser Sensor nicht komatibel?
Gruß,
Gero
@gero: Hast du Autocreate an?
welchen sketch hast du auf dem jeelink? für die lacrosse sensoren muss es der aus diesem post http://forum.fhem.de/index.php/topic,14786.msg104491.html#msg104491 (http://forum.fhem.de/index.php/topic,14786.msg104491.html#msg104491) sein.
gruss
andre
Okay. Jetzt klappt es. Danke!
Ja, autocreate war an.
Ich habe nocheinmal die letzte Version vom Sketch auf den JeeLink geflasht und jetzt funktioniert es.
Gruß,
Gero
Danke für das Update,
ein erster kurzer Test zeigt eine viel glattere Temperaturkurve -> Die sinnlosen spikes auf -20°|+100° bleiben aus.
Ich habe jedoch noch schwierigkeiten mit den Logdateien: Ich bekomme alle 5-15 Sekunden einen Eintrag.
Dabei pendelt die Temperatur oft zwischen 18.1 und 18.2° hin und her.
Folgendes habe ich versucht:
event-min-interval=300
event-on-change-reading=state
Ich dachte, wenn ich
event-on-update-reading
nicht setze, wird imme rnur alle 5 Minuten ein Eintrag geloggt?!?
Danke für eure Hilfe.
die syntax für event-min-interval ist anders: attr <device> event-min-interval reading:interval, ...
also so etwas:
attr <device> event-min-interval state:300
gruss
andre
Batterietest:
Habe ich mit meiner einstellbaren Spannungsquelle nicht hinbekommen! :-[
Wenn der Sensor die Batterieanzeige Low brachte war vorher schon die Kommunikation zum Jeelink abgebrochen!
Billy
schade. aber wie gesagt ich weiß nich ob oliver das bit schon durchreicht.
gruss
andre
schade. aber wie gesagt ich weiß nich ob oliver das bit schon durchreicht.
gruss
andre
@andre
Neueste Erkenntnis zum Battery LOW!
Es scheint so zu sein, dass bei Anzeige des Battery LOW am Sensor keine Daten mehr in FHEM angezeigt werden!
Wenn ich die Spannung minimal uf 2,5V anhebe und die Anzeige Battery LOW am Sensor verschwindet werden in FHEM
wieder Daten angezeigt.
Fast könnte man meinen Oliver nimmt das Bit um den Sensor vom jeelink zu trennen! :-\
Während der ganzen Aktion bleibt die Datenübertragung zur original Anzeige bestehen. Auf dieser wird das Low-Bat des Sensors
auch richtig angezeigt.
Billy
ob noch daten ankommen siehst du oben in den internal values am ..._TIME value. da steht die zeit der letzten
nachricht drin. jeweils im jeelink und lacrosse device.
wenn du für das jeelink device verbose auf 4 bzw 5 setzt sollten die raw messages im log auftauchen.
vielleicht kannst du mal welche mit und ohne low battery erzeugen. da siehst du ob wirklich nichts mehr empfangen wird.
gruss
andre
Das ist schon interessant!
Sobald das Zeichen für LowBat auf dem Sensor erscheint (ca. 2,3V) gibt es keine Raw Messages mehr und
Zitatin den internal values am ..._TIME value.
Wird keine Veränderung mehr angezeigt.
Jetzt wird es interessant! Wenn ich die Spannung wieder auf 2,5 V erhöhe bleibt das Zeichen für LowBat auf dem Sensor!!!
Solange dieses für ca. 5 Minuten angezeigt wird gibt es auch weiterhin keine Meldungen!!!
Wenn das Zeichen für LowBat auf dem Sensor wieder verschwindet (Spannung bleibt auf 2,5V)
Kommen Raw Messages
2013.11.04 16:40:50 5: JLLaCR dispatch OK 9 84 2 4 171 99
2013.11.04 16:40:54 5: JeeLink/RAW: /OK 9 8
2013.11.04 16:40:54 5: JeeLink/RAW: OK 9 8/4 1 4 252 99
und die Anzeige in FHEM ist wieder vorhanden!
Vielleicht fällt Oliver dazu was ein?
Billy
Hi Billy,
aber klar doch, mir fällt da was ein. Hab das Bit nicht gesehen, deshalb ist es durch die Plausibilitätsprüfung gefallen. Hab ich jetzt behoben, wird ebenfalls mit übertragen (im Kanal-Byte an 0x40). Kannste den Spannungstest nochmal machen? Geh aber bitte nicht zu niedrig mit der Spannung, es kann sonst sein, dass der Sensor selbst zwar noch läuft, das eingebaute Funkmodul wegen Unterspannung aber nicht mehr übertragen kann.
Anbei also der neue Sketch zum testen... Andre müsste das Bit noch interpretieren, d.h. es wird auch ne neue Version des 36_LaCrosse.pm fällig.
Gruss
Oliver
EDIT: Neue Version siehe unten...
zum testen anbei eine version die das battery low bit da auswertet wo oliver es jetzt eingebaut hat.
ich finde bit bei humidity aber eigentlich besser aufgehoben. type wird sonst sehr kurz.
mal sehen auf welche version wir uns einigen :)
gruss
andre
edit: attachment entfernt. oliver baut um *gg*
Sorry für die Konfusion, hab nicht gesehen dass es schon ausgewertet wird...
Also hier nochmal ne Version.
Gruss
Oliver
Hi Oliver,
;)
ZitatKannste den Spannungstest nochmal machen? Geh aber bitte nicht zu niedrig mit der Spannung, es kann sonst sein, dass der Sensor selbst zwar noch läuft, das eingebaute Funkmodul wegen Unterspannung aber nicht mehr übertragen kann.
Klar kann ich den Test nochmal machen. Leider dauert das ein Weilchen. Habe gerade noch andere Aktivitäten aber vielleicht gehts
nebenher.
Das Problem ist, dass der Sensor bei der Batterieüberwachung soetwas wie eine Hysterese haben muss. d.h. erst wenn die Spannung eine gewisse Zeit anliegt wird sie auch ausgewertet. --> d.h. Absenkung in kleinen Schritten mit Pausen und das dauert.
Vielen dank an Euch Beiden Oliver + Andre
Gruss Billy
@Andre @Oliver
Batterietest funktioniert! :D
Readings battery low 2013-11-06 09:26:26
erscheint zeitgleich mit dem Symbol auf der Anzeige!!! :) :)
Bei mir bei 2,3V!!!
Gruss Billy
wenn es keine weitern wünsche mehr gibt checke ich es heute abend ein.
gruss
andre
Toll, funktioniert!!!
ich habe eben alles eingecheckt.
es wäre noch schön eine liste mit allen sensoren zu haben die funktionieren. die würde ich dann in der doku noch einpflegen.
gruss
andre
Ich verwende den
TX 29 DT-HT Aussensender
http://www.amazon.de/gp/product/B00392XX5U/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1
Zitates wäre noch schön eine liste mit allen sensoren zu haben die funktionieren.
TX29DTH-IT; TX25IT; TX27TH-IT; alle mit Display :)
TX37-IT ohne Display
Billy
TFA 30.3156.WD
Dieser hier scheint nicht zu funktionieren, erhalte von ihm keinen Wert.
Eine Wetterstation, die auch vom TX 29 DT-HT erfolgreich Daten empfängt, zeigt von diesem Daten an!
Was mich jedoch auch wundert ist, dass
ich mit einem LaCrossePairForSec 300 keinen einzigen neuen Sensor eingetragen bekommen habe.
LaCrossePair war danach auf 1 gesetzt.
Bei meinem ersten Test waren dies fast 20 sensoren innerhalb weniger Minuten.
es werden jetzt nur noch sensoren angelegt die das flag für neue battery gesetzt haben. d.h. zusätzlich zum LaCrossePairForSec muss die batterie raus und wieder rein.
ich glaube ich baue noch schnell ein das hinter der zeit noch ein zweiter parameter angegeben werden kann um auch sensoren anzulegen die das flag nicht gesetzt haben.
gruss
andre
LaCrossePairForSec hat jetzt einen zweiten optionalen parameter 'ignore_battery'. wenn dieser gesetzt ist werden auch sensoren ohne 'new battery' flag angelegt.
gruss
andre
Zitat von: Billy am 06 November 2013, 18:29:26
TX29DTH-IT; TX25IT; TX27TH-IT; alle mit Display :)
TX37-IT ohne Display
Welche Sensoren liefern auch Werte zur Luftfeuchtigkeit?
Von der Namensgebung würde ich tippen, dass es alle Sensoren mit TH im Namen sind. Leider sind die Beschreibungen in den Online-Shops sehr dürftig und die Sensoren werden nur als "Temperatur-Außensensor" bezeichnet.
Hat jemand diesen Sensor schon getestet:
http://www.heavyweather.de/TX-35-Aussensensor-TX-35DTH-IT-TX-35-DTH-IT_c41-42-75_p1826_x2.htm (http://www.heavyweather.de/TX-35-Aussensensor-TX-35DTH-IT-TX-35-DTH-IT_c41-42-75_p1826_x2.htm)
Wieviele Sensoren kann ich parallel mit einem JeeLink empfangen und unterscheiden?
Gruß,
Gero
@Gero
ZitatWelche Sensoren liefern auch Werte zur Luftfeuchtigkeit?
Bei mir alle mit TH im Namen.
Der TX25IT 2xTemp --> ideal für Kühltruhe innen und aussen.
ZitatHat jemand diesen Sensor schon getestet:
http://www.heavyweather.de/TX-35-Aussensensor-TX-35DTH-IT-TX-35-DTH-IT_c41-42-75_p1826_x2.htm
Lt. Beschreibung.
Der Aussensensor / Zusatzsensor TX 35 DTH-IT ist Ersatzsensor für WD 9000, WD 4204, WD 4910, WD 9245
Wenn also einer der obengenannten auch für diese WD's vorgesehen ist, dann müsste der TX-35 auch gehen.
Billy
Hi, danke für den neuen Parameter, der ist sicher sehr hilfreich!
Doch leider erkennt er bei mir auch mit
set JLLaCR LaCrossePairForSec 1200 ignore_battery
keinen einzigen neuen Sensor. Kann eine andere Einstellung daran schuld sein?
setz mal bitte verbose 4 oder 5 für das jeelink device und schau im log ob nachrichten empfangen werden.
die _TIME und _MSGCOUNT internal values sollten sich auch ändern wenn etwas empfangen wird.
gruss
andre
ja, die werte wachsen, cnt. ging von 9969 auf 10025,
jedoch ohne einen neuen Device anzulegen. Im Log habe ich auch nur die 3 bereits registrierten Sensoren gesehen, keine neuen...
hast du im log auch die raw messages gesehen ? sind die auch nur von den drei bekannten sensoren?
ich hab die dinger nicht und kann es nicht testen.
wenn dir danach ist kannst du im LaCrosse modul zeile 137 auskommentieren und in zeile 139 das if...() entfernen. danach ist das verhalten wie vorher. d.h. es wird immer angelegt wenn autocreate aktiv ist.
ich sehe gerade das auch mit dem pair auf jeden fall eine unknown device zeile im log auftauchen sollte wenn ein unbekanntes device empfangen wird. auch ohne autocreate.
vermisst du ein device das es wirklich gibt? oder nur die ganzen falschen?
um ganz sicher zu genen kannst du mal eins deiner drei echten devices löschen. dann sollte ohne die beiden änderungen von oben ohne pair nur die nachricht auftauchen. mit pair und ohne batterie wechsel auch, mit dem flag bzw. mit pair und batterie wechsel sollte es angelegt werden.
gruss
andre
Hm, ich sehe leider keine unknown device-Meldung, und auch keine Raw-Messages, aber vielleicht mache ich da was falsch, denn die habe ich noch nie gesehen!
verbose 5 habe ich eingestellt!
Der _CNT zählt auch brav nach oben, ist jetzt schon bei 10830.
Ich vermisse einen Sensor, den es tatsächlicg gibt und der auf meiner Wetteruhr empfangen wird.
Ich hab jetzt mal die 2 vorgeschlagenen Änderungen gemacht und beobachte, was passiert...
Danke für deine Mühen!
Edit: Rechtschreibfehler korrigiert
attr global verbose 5 oder attr <dein jeelink device> verbose 5 und es muss für jede empfange nachricht etwas im fhem log stehen.
es soll ja schliesslich funktionieren.
gruss
andre
Diese RAW-Nachrichten erhalte ich...
Einen Device hat er jetzt angelegt, jedoch ohne einen Wert in das FileLog_LaCrosse_08
einzutragen. Dann hat vermutlich die CRC nicht gestimmt?
Kann es sein, dass dieser Sensor ein anderes Format sendet?
Ist dieser RAW-Eintrag ein Fehlerhafter? "OK 9 4/8"?
2013.11.07 22:00:57.815 5: JeeLink/RAW: /OK
2013.11.07 22:00:57.821 5: JeeLink/RAW: OK /9 48 1 4 70 99
2013.11.07 22:01:02.231 5: JeeLink/RAW: /OK 9
2013.11.07 22:01:02.238 5: JeeLink/RAW: OK 9 /32 1 4 92 62
2013.11.07 22:01:06.565 5: JeeLink/RAW: /OK 9 48
2013.11.07 22:01:06.570 5: JeeLink/RAW: OK 9 48 /1 4 70 99
2013.11.07 22:01:10.732 5: JeeLink/RAW: /OK 9 32 1 4
2013.11.07 22:01:10.739 5: JeeLink/RAW: OK 9 32 1 4 /92 62
2013.11.07 22:01:15.315 5: JeeLink/RAW: /OK
2013.11.07 22:01:15.322 5: JeeLink/RAW: OK/ 9 48 1 4 70 99
2013.11.07 22:01:19.231 5: JeeLink/RAW: /OK 9
2013.11.07 22:01:19.235 5: JeeLink/RAW: OK 9/ 32 1 4 92 62
2013.11.07 22:01:24.065 5: JeeLink/RAW: /O
2013.11.07 22:01:24.069 5: JeeLink/RAW: O/K 9 48 1 4 70 99
2013.11.07 22:01:27.731 5: JeeLink/RAW: /OK
2013.11.07 22:01:27.735 5: JeeLink/RAW: OK /9 32 1 4 92 62
2013.11.07 22:01:32.816 5: JeeLink/RAW: /OK 9 4
2013.11.07 22:01:32.820 5: JeeLink/RAW: OK 9 4/8 1 4 70 99
2013.11.07 22:01:36.231 5: JeeLink/RAW: /OK
2013.11.07 22:01:36.235 5: JeeLink/RAW: OK /9 32 1 4 92 62
2013.11.07 22:01:41.566 5: JeeLink/RAW: /OK 9 48 1 4
2013.11.07 22:01:41.582 5: JeeLink/RAW: OK 9 48 1 4/ 70 99
2013.11.07 22:01:44.731 5: JeeLink/RAW: /OK
2013.11.07 22:01:44.735 5: JeeLink/RAW: OK/ 9 32 1 4 92 62
2013.11.07 22:01:50.316 5: JeeLink/RAW: /OK 9
2013.11.07 22:01:50.320 5: JeeLink/RAW: OK 9/ 48 1 4 70 99
2013.11.07 22:01:53.231 5: JeeLink/RAW: /OK
2013.11.07 22:01:53.236 5: JeeLink/RAW: OK /9 32 1 4 92 62
2013.11.07 22:01:59.065 5: JeeLink/RAW: /OK
2013.11.07 22:01:59.070 5: JeeLink/RAW: OK /9 48 1 4 70 99
2013.11.07 22:02:01.731 5: JeeLink/RAW: /O
2013.11.07 22:02:01.735 5: JeeLink/RAW: O/K 9 32 1 4 92 62
2013.11.07 22:02:07.815 5: JeeLink/RAW: /OK
2013.11.07 22:02:07.820 5: JeeLink/RAW: OK /9 48 1 4 70 99
2013.11.07 22:02:10.232 5: JeeLink/RAW: /OK 9 3
2013.11.07 22:02:10.236 5: JeeLink/RAW: OK 9 3/2 1 4 92 62
2013.11.07 22:02:16.567 5: JeeLink/RAW: /OK 9 48
2013.11.07 22:02:16.572 5: JeeLink/RAW: OK 9 48 /1 4 70 99
2013.11.07 22:02:18.731 5: JeeLink/RAW: /OK 9
2013.11.07 22:02:18.736 5: JeeLink/RAW: OK 9 /32 1 4 91 62
2013.11.07 22:02:22.981 5: JeeLink/RAW: /OK
2013.11.07 22:02:22.985 5: JeeLink/RAW: OK/ 9 32 1 4 92 62
2013.11.07 22:02:25.315 5: JeeLink/RAW: /O
2013.11.07 22:02:25.320 5: JeeLink/RAW: O/K 9 48 1 4 70 99
2013.11.07 22:02:27.231 5: JeeLink/RAW: /OK 9
2013.11.07 22:02:27.236 5: JeeLink/RAW: OK 9 /32 1 4 92 62
2013.11.07 22:02:31.481 5: JeeLink/RAW: /OK
2013.11.07 22:02:31.485 5: JeeLink/RAW: OK/ 9 32 1 4 92 62
2013.11.07 22:02:34.066 5: JeeLink/RAW: /OK 9 4
2013.11.07 22:02:34.070 5: JeeLink/RAW: OK 9 4/8 1 4 70 99
so lange da ok steht sind die nachrichten ok. der / kommt durch das häppchen weise lesen vom usb port.
ich sehe nachrichten für sensor 48, 32, 4 und 3.
die erste nachricht legt den sensor an. erst die zweite nachricht wird nur intern gespeichert und ab der dritten nachricht werden readings erzeugt wenn die abweichung <= dem filterThreshold ist.
der sensor drei taucht im log auzug nur ein mal auf. wenn das der neu angelegte ist hat er noch keine readings erzeugt.
gruss
andre
ich habe mich verguckt. in deinem log ausschnitt sind nur nachrichten von zwei sensoren.
ich habe aber gerade einen fehler im autocreate entdeckt als ich deine nachrichten in einen dummy jeelink geschickt habe.
morgen mit dem update sollte autocreate wirklich wieder funktionieren. sorry.
gruss
andre
Bei mir sind nur die 2 bekannten angelegt und einer mit dem State=???.
Bei dem sehe ich in FHEM nicht, mit welcher ID er sich gemeldet hat.
Aus der (vollständigen) Logdatei entnehme ich, dass dies der Sensor 8 sein sollte.
2013.11.07 21:54:41.016 5: JLLaCR dispatch OK 9 8 1 5 93 28
2013.11.07 21:54:41.071 3: LaCrosse_08: I/O device is JLLaCR
Habe noch folgende Zeilen in der Log gefunden, falls diese etwas helfen...
2013.11.07 20:51:49.820 5: JLLaCR dispatch OK 9 212 1 4 65 74
2013.11.07 20:58:39.434 5: JLLaCR dispatch OK 9 212 1 2 190 53
2013.11.07 21:39:45.485 5: JLLaCR dispatch OK 9 212 1 4 69 42
2013.11.07 21:38:42.150 5: JLLaCR dispatch OK 9 156 1 5 162 74
Da ich aber sonst nichts empfange, vermute ich fast, dass der eine Temperatursensor(TX 29 DT-HT) vom JeeLink nicht empfangen werden kann....
Die Wetterstation empfängt eine korrekte Temperatur von ihm. FHEM empfängt auf keinem Sensor diese Temperatur.
Danke für die Info für das Autocreate... kein Thema, dann warte ich auf morgen, oder hol es mir aus svn.
Wenn ich das Update mache, werden meine auskommentierte Zeilen auch wieder automatisch zurückgesetzt, oder?
Wie aber oben geschrieben vermute ich, dass der eine Sensor gar nicht empfangen werden kann.....
Hallo JoeALLb,
ich habe nur TX 29 DT-HT, und die werden alle vom JeeLink ordentlich empfangen. Ich habe aber auch mitbekommen das bei der neuen Version irgendwas mit dem Autocreate nicht ganz hinhaut, die Sensoren sehe ich aber im Log und trage momentan per Hand ein, dann ist alles richtig. Da ich aber auf dem JeeLink noch mit LaCrosseITPlusReader05 anstatt -08 fahre glaube ich mein Problem kommt daher. Das Update kann ich erst kommende Woche einspielen...
Grüße
Hi,
heute wurden wieder 37 Sensoren angelegt. Autocreate funktioniert demnach!
Danke!
Interessant fand ich nur, dass er den ganzen Tag über neue Sensoren angelegt hat, den letzten um 17:30, obwohl ich am Vormittag das pair auf nur 600s gesetzt habe.....
Den einen Sensor hat es dennoch nicht angelegt, aber.... das ist nicht so wichtig! Die anderen zeigen brav und zuverlässig ihre Werte an! Vielen Dank nochmals!
hattest du ein update und restart gemacht oder ist das noch die version mit den von hand geänderten zeilen ?
kannst du mal bitte schauen ob beim jeelink device der internal value LaCrossePair wieder verschwunden ist?
gruss
andre
Da, der Wert ist verschwunden, er war 2 (vermutlich wegen dem ignore_battery) und ja, ich habe heute früh das neue Update eingespielt und neu gestartet.
Zur Info will ich aber ergänzen, dass ich seit heute einen weiteren JeeLink für die PCA301-Steckdosen betreibe... Ich hoffe, da kommt sich nichts in die Quere.
Ich lösch einfach nochmal alle "pseude"-sensoren und schaue, ob weiterhin welche angelegt werden.... Oder hast Du einen anderen Vorschlag?
da kommt nichts in die quere wenn das iodev richtig gesetzt ist.
jede jeelink kann ja auch nur den device typ empfangen der zum sketch passt.
ja. bitte lösch noch mal was zu viel angelegt ist. ohne den internal value LaCrossePair sollte nichts per autocreate angelegt werden.
gruss
andre
Hallo,
ich wollte mir in nächster Zeit einige La Crosse Temperatursensoren kaufen.
Gibt es welche, welche nicht alle 4s ein Signal senden? Der TX-29-IT sendet ständig und ich möchte nicht unnötig das Frequenzband zumüllen.
LG
/robin
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?
Hallo fh168,
wie ist es denn bei den Temperatursensoren? Senden sie wirklich von sich aus oder werden sie auch vom JeeLink angestubst?
Im Parallelthread zur PCA301 Schaltsteckdose ist das gleich Problem nämlich im Sketch des JeeLinks erkannt worden, siehe:
http://forum.fhem.de/index.php/topic,11648.msg106526.html#msg106526
Gruß
Spiff
die temperatursensoren senden wirklich von sich aus.
gruss
andre
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?
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.
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%.
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
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
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
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
> 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.
dann ändere ich dir grenze
fhem modul auch von 98 auf 99.
gruss
andre
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.
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
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...
Sorry,
Habe mich wohl missverständlich ausgedrückt. Meine die Typenbezeichnung des Sensors
Bei Fragen ans Forum.
Billy
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
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 (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.
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?!?
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
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...
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
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
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.
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
Hallo Andre,
mit
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...
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
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
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.
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
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?!
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?
T: 3.64093961715698
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
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?
define <Device> JeeLink /dev/ttyUSB1@57600
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
die seriennummer der ftdi chips in den jeelinks ist eindeutig. die kannst du zum identifizieren verwenden.
wenn du ein 'richtiges' linux system hast und keine fritzbox kannst du kannst du alles so anpassen das die device namen immer eindeutig für ein bestimmtes device sind. da gibt es hier mehre threads im forum.
bevor du damit anfängst ist aber vielleicht ein einfacherer versuch auch ok. zumindest dann wenn nicht dauernd neue devices dazu kommen bzw immer wieder abgezogen und angesteckt werden.
beim booten sollte die reihenfolge von der bus id und somit vom port abhängen an dem der stick steckt. also ein mal alles anstecken. dann neu booten und schauen welcher stick welches device bekommen hat und diese dann in fhem verwenden.
gruss
andre
@JoeALLb
Zitatbeim booten sollte die reihenfolge von der bus id und somit vom port abhängen an dem der stick steckt. also ein mal alles anstecken. dann neu booten und schauen welcher stick welches device bekommen hat und diese dann in fhem verwenden.
Das stimmt, habe ich bei mir durch Einsatz eines Farbigen USB-Hub gelöst!
http://www.amazon.de/USB-2-0-external-4-port-cable/dp/B003O3B98W
Billy
Bei USB-Sticks konnte ich feststellen, dass dies auch mit deren Initialisierungszeit zusammenhängt.
Wenn Stick #2 (deutlich? Feststellen konnte ich es ab 5 Sekunden, aber welcher USB-Sticck initialisiert so lange?) schneller initialisiert, wird dieser /dev/sda und nicht /dev/sdb.
Da meine beiden Sticks heute definitiv in FHEM vertauscht waren, fällt mir dazu keine andere Ursache ein.
Wie auch immer, ich habe dies mit festen Zuweisungen anhand der Seriennummer über udev gelöst.
Funktionierte prima!
Hallo,
hat hier jemand die Konfiguration am Laufen: Fritzbox 7390 + JeeLink?
Habe Probleme das der JeeLink richtig von der FB7390 erkannt wird.
Danke und Gruß ingo
Hallo allerseits,
ich dache im Forum mal die Befehle zum abschalten des blauen LED am JeeLink gesehen zu haben, aber auch umfangreiche Suchen danach haben nix sinnvolles zu Tage gefördert....daher die Frage in die Runde: Kann man die LED deaktivieren??? Das blaue Blinken ist schon sehr hell...
Dank & Gruß
Vielleicht hilft das ?
Per Zufall gefunden kommt wenn ich meinen Jeelink ans terminal hänge
[pcaSerial.10.0h]
Available commands:
..,.. s - send data packet
l - list devices
<n> a - turn activity LED on PB1 on or off
<n> c - config (0=fill, 1=load, 2=save, 3=erase)
<n> d - turn off device <n>
<n> e - turn on device <n>
<n> p - poll device <n>
<n> r - list recordings
<n> q - quiet mode (1=suppress TX and bad packets)
<n> v - version and configuration report
Billy
Ich arbeite gerade daran einige Funktionen (IR, PowerPlug, FS20, LaCrosse, ETH200comfort) in meinen JeeLink zu integrieren und werde auch bald mein Projekt in diesem Forum vorstellen.
Ich verwende unter anderem auch dein LaCrosse Modul. Leider fehlt mir aber noch eine Taupunktberechnung.
Vielleicht wäre diese auch für andere User nützlich.
Wollt ihr folgende Berechnung in das Modul einfließen lassen und ein Reading ergänzen, dann könnte ich wieder dein Modul ohne Änderungen übernehmen.
sub LaCrosse_CalcDewpoint (@) {
my ($temp,$hum) = @_;
my($SDD, $DD, $a, $b, $v, $DP);
if($temp>=0) {
$a = 7.5;
$b = 237.3;
} else {
$a = 7.6;
$b = 240.7;
}
$SDD = 6.1078*10**(($a*$temp)/($b+$temp));
$DD = $hum/100 * $SDD;
$v = log($DD/6.1078)/log(10);
$DP = ($b*$v)/($a-$v);
return $DP;
}
Grüße :)
das einbauen ist kein problem.
gibt es einen grund das du es lieber im modul (und potentiell in jedem modul) haben möchtest statt das dewpoint modul zu verwenden ?
wie soll das reading heissen? für alle kanäle oder nur den ersten?
gruss
andre
stand hier eben noch was ... ?
ich bin mir noch nicht so sicher ob es wirklich gut ist das in jedem modul zu duplizieren. aber schau mal ob das so funktioniert wie du es dir vorstellst.
gruss
andre
Zitat von: Billy am 23 November 2013, 21:36:23
Vielleicht hilft das ?
Per Zufall gefunden kommt wenn ich meinen Jeelink ans terminal hänge
[pcaSerial.10.0h]
Available commands:
..,.. s - send data packet
l - list devices
<n> a - turn activity LED on PB1 on or off
<n> c - config (0=fill, 1=load, 2=save, 3=erase)
<n> d - turn off device <n>
<n> e - turn on device <n>
<n> p - poll device <n>
<n> r - list recordings
<n> q - quiet mode (1=suppress TX and bad packets)
<n> v - version and configuration report
Billy
Mh, wenn ich im Seriellen Monitor 'l' tippe passiert nix...egal, ich habe im Sketch einfach den LED Pin von 9 auf 8 gesetzt und dann blinkt die LED nicht mehr. PIN 8 sollte offen (not connected) sein, richtig?
Grüße
Wollte mal einen kleinen Zwischenstand bringen: Die kleinen Ausreißer und manchmal auch große habe ich leider noch immer.
Anbei ein Screenshot, der anzeigt, was bei mir aktuell heute geloggt wurde:
hat dein LaCrosse modul schon das filterThreshold attribut?
selbst beim default von 10 sollte so ein ausreisser von fast 80 nicht auftauchen.
gruss
andre
Ja ich hatte es auf 1 gesetzt und es hat funktioniert. Wie ich aber gerade sehe, ist es nicht mehr da und ich kann es auch nicht mehr setzen :o
Was ist da los? Muss ich mir heute Abend näher ansehen.
Zitat von: Billy am 23 November 2013, 21:36:23
Vielleicht hilft das ?
Per Zufall gefunden kommt wenn ich meinen Jeelink ans terminal hänge
[pcaSerial.10.0h]
Available commands:
..,.. s - send data packet
l - list devices
<n> a - turn activity LED on PB1 on or off
<n> c - config (0=fill, 1=load, 2=save, 3=erase)
<n> d - turn off device <n>
<n> e - turn on device <n>
<n> p - poll device <n>
<n> r - list recordings
<n> q - quiet mode (1=suppress TX and bad packets)
<n> v - version and configuration report
Billy
Nur mal so Billy, die Optionen gibt es nur mit dem PCA301 Sketch! Ich habe aber das LaCrosse Sketch auf dem JeeLink, daher habe ich das Menü nicht...
Seltsam, meine Version war eine ältere Version und wurde bei "update check" nicht angezeigt.
Habe die aktuelle aus svn übernommen. Mich wundert die alte Version jedoch, da ich filterThreshold
bereits im Einsatz hatte, wie ich auch in einem Backup nachvollziehen konnte.
Wird ein Modul, in dem eine Zeile von Hand geändert wurde aus dem Update ausgenommen?
Wie auch immer: Ich teste jetzt wieder mit de raktuellen Version! Danke für den Hinweis.
Hi,
hat jemand das gleiche Verhalten (s.u.) beobachtet?
Ich habe mal ausprobiert, die "Phantome" mit LaCrossePairForSec zu pairen, aber sie tauchen nicht als Device auf.
Auch wenn Autocreate aus ist, erscheint diese Meldung, allerdings hat sich mittlerweile die Zeile des Fehlers durch ein Update auf 2830 verschoben.
Ich würde schätzen, es sind so 10 dieser Meldungen pro Stunde.
Gruß
Spiff.
Zitat von: Spiff am 16 November 2013, 15:52:43
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
Hallo Zusammen,
ich hatte bei einem meiner Sensoren (tx29it), der relativ weit vom Empfänger entfernt steht auch die hier beschriebenen Ausreißer in den Temperaturen. Oft kam es dazu, dass im Trace eine Temperatur von 100 zu sehen war.
Danach hab ich mir den Sketch mal genauer angeschaut. Ich bin mir ziemlich sicher, dass dort ein Fehler bei der CRC Berechnung/Behandlung ist. Ich habe einen FIX gemacht und dabei zum besseren Verständnis den Code ein modifiziert. Ich habe seit gestern die Version am laufen und bis jetzt sind keine Fehler mehr aufgetacht.
Die CRC wurde lediglich über das letzte BYTE berechnet. Hier sollte die CRC über byte0..3 berechnet werden und der Wert muss mit byte 4 übereinstimmen.
Ich denke ebenfalls, dass durch diesen Fix die Bogus checks obsolet sind.
Die modifizierte sketch Version habe ich ebenfalls angehängt. Würde mich freuen wenn jemand mir ein Feedback geben könnte.
Danke,
Heiko
@Spiff: Das habe ich auch!
Vielleicht kann mit der Korrektur von hthiery auch dieses Phänomen behoben werden?!? Mal testen heute Abend!
Hi,
leider habe ich mit dem gepatchten Sketch wieder ein Phantomgerät:
Use of uninitialized value $found[0] in string eq at fhem.pl line 2830.
Log:
2013.12.05 15:00:08 3: LaCrosse Unknown device 88, please define it
Gruß
Spiff.
Hallo,
Wie lange dauert es denn bis das Phantomgerät auftaucht?
Könntest Du bei dem sketch mal die Debug Ausgaben einschalten und die seriellen ausgaben tracen und mir den Trace schicken?
Dann könnte ich evtl. mal nachschauen was es ist!
Heiko
Hallo Heiko!
Zitat von: hthiery am 05 Dezember 2013, 16:33:16
Wie lange dauert es denn bis das Phantomgerät auftaucht?
In dem Fall 28 Minuten vom Serverstart.
ZitatKönntest Du bei dem sketch mal die Debug Ausgaben einschalten und die seriellen ausgaben tracen und mir den Trace schicken?
Nein. Aber auch nur nicht, weil ich nicht weiss, wie das geht.
Wenn du es mir sagst: kein Problem, solange es unter Windows funktioniert. ::)
Edit:
#define DEBUG 1 // set to 1 to see debug messages
Richtig? Wie trace ich?
Viele Grüße
Spiff.
Hallo Heiko,
im Serial Monitor kommen nur komische Schriftzeichen an. Ich habe mal einen anderen installiert, da sieht das ähnlich aus.
0x00 EE EC FE 38 94 FF 43 38 94 FF 43 43 38 94 FF 41 îìþ8"ÿC8"ÿCC8"ÿA
0x10 38 95 FE 38 94 FF 38 94 FF 38 94 FF 38 94 FF 38 8•þ8"ÿ8"ÿ8"ÿ8"ÿ8
0x20 94 FF 38 95 FE 38 94 FE 38 94 FF 38 94 FF 39 94 "ÿ8•þ8"þ8"ÿ8"ÿ9"
0x30 FF 38 94 FF 38 94 FF 38 94 FF 43 FF ÿ8"ÿ8"ÿ8"ÿCÿ
So in der Art?!
Ich habe momentan 5 Sensoren laufen. Dir hilft wahrscheinlich vor allem der Zeitpunkt, an dem der Fehler kommt, richtig?
Ich muss mal sehen, ob ich eine Zeit mit auslesen kann.
Gruß
Spiff.
ja, das ist soweit alles richtig, nur die Ausgabe des sketchs sollte so aussehen! Hast Du die Baudrate auf 57600 gestellt? Im Arduion Serial Monitor unten rechts (zumindest in der Version die ich verwende)
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
Start receiving
End receiving, HEX raw data: 94 6 15 6A 1B
OK 9 16 1 4 191 106
Start receiving
End receiving, HEX raw data: 9E C5 55 6A 64
OK 9 248 1 4 131 106
Start receiving
End receiving, HEX raw data: 95 6 26 6A 1F
OK 9 20 1 4 202 106
Start receiving
End receiving, HEX raw data: 94 6 15 6A 1B
OK 9 16 1 4 191 106
Start receiving
End receiving, HEX raw data: 95 9A FF 7F DF
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 9E C5 55 6A 64
OK 9 248 1 4 131 106
Start receiving
End receiving, HEX raw data: 95 6 26 6A 1F
OK 9 20 1 4 202 106
Start receiving
End receiving, HEX raw data: 94 6 15 6A 1B
OK 9 16 1 4 191 106
Start receiving
End receiving, HEX raw data: 95 6 25 6A 32
OK 9 20 1 4 201 106
Start receiving
End receiving, HEX raw data: 9E C5 55 6A 64
OK 9 248 1 4 131 106
Start receiving
End receiving, HEX raw data: 94 6 15 6A 1B
OK 9 16 1 4 191 106
Start receiving
End receiving, HEX raw data: 95 6 25 6A 32
OK 9 20 1 4 201 106
Start receiving
Gruß,
Heiko
Hallo Heiko,
das mit der Baudrate war's.
Hier ein Log über ein paar Minuten. Ich habe 5 Sensoren mit den Adressen: 0C 68 B0 08 44
Edit: Trace siehe Anhang.
Edit 2: hier ein Ausschnitt aus dem Log mit den Teilen, wo "Phantome" erkannt wurden und die Fehler kamen. Allerdings war das nicht während der Aufzeichnung des Anhangs.
2013.12.05 21:26:04 5: JeeLink_Sensoren dispatch data: 1B 68 1D 98 CF
2013.12.05 21:26:04 5: Triggering JeeLink_Sensoren (1 changes)
2013.12.05 21:26:04 5: Notify loop for JeeLink_Sensoren UNKNOWNCODE data: 1B 68 1D 98 CF
2013.12.05 21:26:04 3: JeeLink_Sensoren: Unknown code data: 1B 68 1D 98 CF , help me!
2013.12.05 21:26:04 5: JeeLink_Sensoren dispatch OK 9 108 129 5 143 152
2013.12.05 21:26:04 3: LaCrosse Unknown device 6C, please define it
2013.12.05 21:26:04 5: JeeLink/RAW: /Start receiving
2013.12.05 22:28:05 5: JeeLink_Sensoren dispatch data: 4D A1 27 21 46
2013.12.05 22:28:05 5: Triggering JeeLink_Sensoren (1 changes)
2013.12.05 22:28:05 5: Notify loop for JeeLink_Sensoren UNKNOWNCODE data: 4D A1 27 21 46
2013.12.05 22:28:05 3: JeeLink_Sensoren: Unknown code data: 4D A1 27 21 46 , help me!
2013.12.05 22:28:05 5: JeeLink_Sensoren dispatch OK 9 180 129 2 215 33
2013.12.05 22:28:05 3: LaCrosse Unknown device B4, please define it
2013.12.05 22:28:05 5: JeeLink/RAW: /Start receiving
Gruß
Spiff.
Ich habe ebenfalls das neue sketch mit meinen 9 Sensoren getestet:
Vorher hatte ich 2-8 mal die Stunde eine "unknown device" Meldung. In den letzten 17 Stunden seit aufspielen des neuen Sketches waren es nur noch 4. Temperatur-Ausreißer hatte ich in dieser Zeit nur noch einen. Auch das war früher viel häufiger.
Serielle Logs kann ich leider nicht liefern, da ich zur Zeit nur remote auf meinen Raspberry zugreifen kann.
@hthiery: Du bist auf dem richtigen Weg.
Gruß,
Gero
@spiff: das ist in der Tat seltsam. die daten die beim FHEM ankommen sind aus meiner Sicht gültig. Zumindest was die CRC betrifft. Ob das richtige Werte von Temperatur Sensoren sind weiss ich an der Stelle noch nicht...
#########################################
data: 0x95 0x06 0x13 0x6a 0xda <<<< Daten von meinem TX29it sensor
header : 0x9
battery : 0x00
device_id : 0x14
tmperature : 21.299999
humidity : 106
#########################################
data: 0x4d 0xa1 0x27 0x21 0x46 <<<< daten von deinem FHEM log
header : 0x4
battery : 0x80
device_id : 0xb4
tmperature : -27.299999
humidity : 33
#########################################
data: 0x1b 0x68 0x1d 0x98 0xcf <<<< daten von deinem FHEM log
header : 0x1
battery : 0x80
device_id : 0x6c
tmperature : 42.300003
humidity : 152
für mich sieht es so aus, als wäre da doch ein Gerät das diese Messages schickt.
Welche Geräte hast Du denn genau in Betrieb? Sind dort noch andere die evtl. alle paar stunden einen Status schicken? Was ich noch einbauen werde ist ein Filter für den Header. Hier sollte auf 9 gefiltert werden. Das hatte ich aus dem alten Sketch rausgenommen.
@Gero: das klnigt doch gut... wenn du doch die Möglichkeit hast hier Infos zu liefern wäre toll. Welche Geräte hast Du im Einsatz?
Weiss jemand wo ich noch Infos über das Messge format herbekommen könnte?
Gruß,
Heiko
die möglichkeit das ein nachbar einen sensor hat gibt es ja immer noch.
schau mal etwas weiter oben im thread. da gibt es eine grafik mit dem format das gesendet wird.
gruss
andre
Hi!
Ich habe 5x TX29DTH.
Das mit den Sensoren der Nachbarn halte ich für unwahrscheinlich - es sei denn, die Batterie ist leer und er sendet dauernd neue IDs. Hier mal ein Ausschnitt des Logs von gestern über eine Stunde:
2013.12.05 13:04:24 3: LaCrosse Unknown device 18, please define it
2013.12.05 13:10:59 3: LaCrosse Unknown device EC, please define it
2013.12.05 13:21:45 3: LaCrosse Unknown device 88, please define it
2013.12.05 13:23:48 3: LaCrosse Unknown device 00, please define it
2013.12.05 13:26:22 3: LaCrosse Unknown device E4, please define it
2013.12.05 13:30:22 3: LaCrosse Unknown device A8, please define it
2013.12.05 13:34:17 3: LaCrosse Unknown device C4, please define it
2013.12.05 13:47:48 3: LaCrosse Unknown device C8, please define it
2013.12.05 13:50:22 3: LaCrosse Unknown device BC, please define it
2013.12.05 13:57:40 3: LaCrosse Unknown device 2C, please define it
2013.12.05 13:58:22 3: LaCrosse Unknown device 48, please define it
2013.12.05 14:00:40 3: LaCrosse Unknown device D0, please define itZitat von: hthiery am 06 Dezember 2013, 08:53:25
#########################################
data: 0x95 0x06 0x13 0x6a 0xda <<<< Daten von meinem TX29it sensor
header : 0x9
battery : 0x00
device_id : 0x14
tmperature : 21.299999
humidity : 106
#########################################
data: 0x4d 0xa1 0x27 0x21 0x46 <<<< daten von deinem FHEM log
header : 0x4
battery : 0x80
device_id : 0xb4
tmperature : -27.299999
humidity : 33
#########################################
data: 0x1b 0x68 0x1d 0x98 0xcf <<<< daten von deinem FHEM log
header : 0x1
battery : 0x80
device_id : 0x6c
tmperature : 42.300003
humidity : 152
Die Werte sind aber komisch, oder? Humidy 152? Ist das der reine Wert, also 152%? :o
Dass sich mehrere Sender irgendwie überlagern ist unwahrscheinlich, bzw. sogar ausgeschlossen wegen der CRC-Prüfung, oder?
Edit: ach so, ich hatte den JeeLink mal für eine viertel Stunde in den Pair-Modus versetzt, da wurde kein Gerät angelegt. Auch habe ich ein Phantom mal manuell definiert, aber da kam nichts an. Weil die IDs ja dauernd wechseln, könnte ich alle 256 Möglichkeiten mal definieren, aber dann ist eigentlich klar, dass dort Werte ankommen, weil die Daten anscheinend korrekt gesendet werden, richtig?
Gruß
Spiff.
die werte an sich sind noch nicht komisch...
vergleich mal mit hier: http://forum.fhem.de/index.php/topic,14786.msg104623.html#msg104623 (http://forum.fhem.de/index.php/topic,14786.msg104623.html#msg104623)
106 -> es gibt keinen feuchtigkeits sensor
156 -> höchstes bit gesetzt -> batterie schwach
sind in der viertel stunde unknown Meldungen aufgetaucht? hast du beim pairForSev auch ignore_battery angegeben ?
gruss
andre
Hi,
ich werde nochmal heute Abend mal eine Version rauslegen, diedie Frames die nicht mit '9' beginnen ignoriert. Dann sollte es wieder besser aussehen.
@justme:
von meinem Sensor ... das ist ok... HEADER 9
data: 0x95 0x06 0x13 0x6a 0xda <<<< Daten von meinem TX29it sensor
header : 0x9
battery : 0x00
device_id : 0x14
tmperature : 21.299999
humidity : 106
von spiff's log: hier ist Header auf 1... das ist kein gültiger Tempsensor Wert!
#########################################
data: 0x1b 0x68 0x1d 0x98 0xcf <<<< daten von deinem FHEM log
header : 0x1
battery : 0x80
device_id : 0x6c
tmperature : 42.300003
humidity : 152
@spiff: kannst du sicherlich ausschließen, dass nicht ein anderes Gerät auf der gleichen Frequenz sendet? Wenn ja dann muss es noch einen Fehler im Empfang geben. Was ich aber für unwahrscheinlich halte, denn die CRC ist hier korrekt?!
Zitat von: hthiery am 06 Dezember 2013, 08:53:25
@Gero: das klnigt doch gut... wenn du doch die Möglichkeit hast hier Infos zu liefern wäre toll. Welche Geräte hast Du im Einsatz?
Ich habe zur Zeit 1x TX 29-IT und 8x TX 29DTH im Einsatz und demnächst kommen noch 5 weitere TX 29DTH dazu.
Den arduino seriell monitor kann ich nicht parallel zu fhem betreiben, oder? Zumindest bei mir scheint dann sowohl FHEM als auch der serielle Monitor durcheinanderzukommen.
Natürlich können die "unknown device" Meldungen immer noch von Nachbarsendern kommen.
Aber welche Erkärung gibt es für die Temperaturausreisser?
Liefert dort der Sensor wirklich falsche Daten?
2013.12.05 13:33:44 3: T_02_Simon 30 skipping reading: T 21.4 -> 55.1 H 39.8 -> 61
2013.12.05 13:33:57 3: T_02_Simon 30 skipping reading: T 55.1 -> 21.6 H 61 -> 40
(ich habe das Logging etwas angepasst)
Gruß,
Gero
du kannst beides nicht parallel betreiben.
du kannst aber in fhem für das jeelink device verbose auf 4 oder sogar 5 setzen. dann werden die empfangenen nachrichten auch ins log geschrieben.
gruss
andre
@hthiery: du hast natürlich recht. ich hatte nur auf den temperatur wert geschaut.
im übrigen danke. von mir ist ja nur das fhem modul. da ich keine passenden sensoren habe hab ich mich noch nicht mit dem sketch befasst. das automatische ändern der id nach batterie wechseln ist für mich leider auch ein k.o. kriterium.
gruss
andre
Hallo!
Was hat das genau mit dem Header auf sich?
Kann es sein, dass die Temperaturausreisser auch einen ganz anderen Header als 9 haben? Vielleicht senden die Sensoren hin und wieder noch irgendwelche anderen Informationen, die dann so aussehen, als würden die Temperaturen nicht passen.
Das Pairen hatte ich ohne den Zusatz ignore_battery gemacht.
Ich kann das nachher nochmal machen und beobachten und dann versuchen, genau das Reading mit dem Fehler zu separieren.
Also ich habe auf 868 MHz sowohl Homematic-Heizungssteller am HMLAN, als auch FS20-Strom/Gas-Zähler am CUL und PCA301-Steckdosen an einem zweiten JeeLink (der direkt neben dem anderen steckt).
Aber selbst wenn die sich stören dürfte doch durch den CRC-Check nichts Korruptes bei fhem ankommen, oder?
Zum Fehler in fhem:
"Use of uninitialized value $found[0] in string eq at fhem.pl line 2822."
-> was ist $found[0]? Ist das die nicht definierte ID des Phantom-Sensors? Kann man den Fehler nicht direkt über das Modul ausschließen? Dass der Nachbar auch Sensoren haben könnte, soll doch keine Fehler in FHEM hervorrufen, das ist bei anderen Modulen doch auch nicht so, oder?
Gruß
Spiff.
die fehlermeldung hat damit zu tun das ich noch nicht das richtige zurück gebe wenn ich das autocreate abbreche.
ich hab es eben repariert und eingecheckt.
gruss
andre
Ach so okay. Vielen Dank! :)
Gruß
Spiff.
So! jetzt hab ich einen Temperaturausreisser erwischt:
2013.12.06 14:10:02 5: JeeLink/RAW: /Start receiving
2013.12.06 14:10:02 5: JLLaCR dispatch Start receiving
2013.12.06 14:10:02 3: JLLaCR: Unknown code Start receiving, help me!
2013.12.06 14:10:03 5: JeeLink/RAW: /End r
2013.12.06 14:10:03 5: JeeLink/RAW: End r/eceiving, HEX raw data: 7B C3
2013.12.06 14:10:03 5: JeeLink/RAW: End receiving, HEX raw data: 7B C3/ E8 6 22
OK 9 236 1 4 24 6
2013.12.06 14:10:03 5: JLLaCR dispatch data: 7B C3 E8 6 22
2013.12.06 14:10:03 3: JLLaCR: Unknown code data: 7B C3 E8 6 22 , help me!
2013.12.06 14:10:03 5: JLLaCR dispatch OK 9 236 1 4 24 6
2013.12.06 14:10:03 3: T_01_Wohnzimmer EC skipping reading: T 21.1 -> 4.8 H 31.9 -> 6
Ich habe im sketch das Debug aktiv gelassen. Das führt zwar zu vielen Ausgaben im FHEM log, aber es sollte nicht stören, da nur die Zeilen, die mit OK anfangen vom LaCrosse Modul interpretiert werden.
Die Überprüfung des Starttags scheint doch wichtig zu sein.
Gruß,
Gero
Ich habe jetzt mal den Header-Check im Sketch eingebaut. Und werde das System bis morgen mal beobachten.
Gruß,
Gero
Hallo
ich bin neu hier im Forum und beginne mir ein FHEM mit ersten Erfolgen aufzubauen-
Nun möchte ich die TX29 IT installieren. Dazu habe ich vorab eine Frage. Im WIKI wird auf sourceforge verwiesen. Dort finde ich letztlich nur LaCrosseITPlusReader08.ino.
Hier im Forum wird auf eine ZIP verwiesen mit den 36_JeeLink.pm und LaCrosseITPlusReader05.ino.
Ist die xxx08.ino eine neuere Version und an Stelle der xxx05.ino zu installieren ?
Danke und Gruß
Jürgen
das zip file am anfang des thread war die erste version.
das fhem modul ist inzwischen eingecheckt und teil von fhem.
der aktuelle sketch ist immer in contrib zu finden.
die version des sketch an der gerade dir crc und header prüfung verbessert/repariert wird findest du ein paar posts weiter oben.
gruss
andre
Hallo,
ich habe hier nochmal eine Version vorbereitet, die auf den START (9) im Header filtert, d.h. alle anderen Frames werden nicht dekodiert und weiter gereicht. Ich hoffe, das hilft hier weiter.
@gero: Du hast ebenfalls den check eingebaut und laufen lassen. Hast Du Ergebnisse?
@justme1968: ist iregendwo das Format der Nachricht die der Jeelink zu FHEM schickt definiert? Mir geht es hauptsächlich um den 3.ten Wert in der Zeil:
OK 9 <ID> <?> <temp1> <temp2> <humidity>
Danke,
Heiko
Zitat von: hthiery am 07 Dezember 2013, 08:55:55
@gero: Du hast ebenfalls den check eingebaut und laufen lassen. Hast Du Ergebnisse?
Ja, ich habe gestern um 15 Uhr den Check auf den korrekten Header eingebaut und bis jetzt (19 Stunden) ist weder ein "Unknown device" noch ein Temperaturausreisser aufgetaucht.
Gruß,
Gero
8 byte: id
8 byte: 1 bit battery new
3 bit type -> 0: temperatur + humidity, es gibt scheinbar auch anemometer oder regenmengen messer
4 bit channel
2 byte: temperatur ->
1 byte: 1 bit battery low
7 bit humidity
feuchtigkeit geht von 0-99, temperatur ist in in 10tel grad plus 1000.
was die anderen device typen senden weiss ich leider nicht.
gruss
andre
Es läuft alles weiterhin stabil und ohne Fehler. Das Problem hat sich damit für mich erledigt.
@hthiery: Danke für die neue CRC Überprüfung!
Gruß,
Gero
wenn der sketch von deiner Seite aus fertig ist würde ich die modifizierte version einchecken. sag einfach bescheid.
gruss
andre
Zitat von: justme1968 am 06 Dezember 2013, 10:30:18
das automatische ändern der id nach batterie wechseln ist für mich leider auch ein k.o. kriterium.
Sehe ich ähnlich, aber der Preis ist einfach zu atraktiv.
Hat eigentlich jemand das Gehäuse des Temperatursensors geöffnet?
Vielleicht gibt es da Jumper um eine ID fix festzulegen.
Gruß
Adrian
Hallo andre
Danke, hab aufgrund deiner Antwort und einigem Trial and Error 5 Sensoren installiert.
Gruß
Jürgen
Zitat von: justme1968 am 08 Dezember 2013, 10:12:18
wenn der sketch von deiner Seite aus fertig ist würde ich die modifizierte version einchecken. sag einfach bescheid.
@hthiery: Hast du noch weitere Änderungen geplant?
Aus meiner Sicht läuft die letzte Version perfekt.
Ich habe jetzt 15 Sensoren am Laufen und sehe keinerlei Probleme mehr
@justme1968:
Nach einem update von fhem heute habe ich gesehen, dass dein gleitender Mittelwert noch gar nicht eingecheckt ist. Ich wäre dafür ihn offiziell zu liefern. Die Plots sehen damit doch etwas schöner aus.
Zur Zeit habe ich die Mittelung vor das if gezogen und runde den Wert auf eine Nachkommastelle:
...
if( defined($rhash->{"previousT$channel"})
&& abs($rhash->{"previousH$channel"} - $humidity) <= AttrVal( $rname, "filterThreshold", 10 )
&& abs($rhash->{"previousT$channel"} - $temperature) <= AttrVal( $rname, "filterThreshold", 10 ) ) {
$humidity = int( 10*($rhash->{"previousH$channel"}*3+$humidity)/4 + 0.5)/10;
$temperature = int(10*($rhash->{"previousT$channel"}*3+$temperature)/4 + 0.5)/10;
readingsBeginUpdate($rhash);
readingsBulkUpdate($rhash, "temperature$channel", $temperature);
...
Gruß,
Gero
Zitat von: gero am 09 Dezember 2013, 22:28:25
@hthiery: Hast du noch weitere Änderungen geplant?
Aus meiner Sicht läuft die letzte Version perfekt.
Ich habe jetzt 15 Sensoren am Laufen und sehe keinerlei Probleme mehr
Die Stellen, die ich mir noch anschauen wollte sind eher kosmetischer Natur. Das Hauptproblem mit den Ausreißern scheint ja durch den korrigierten CRC Check behoben zu sein. Die Header Überprüfung war schon im Ursprünglichen Code vorhanden und wurde von mir in der ersten geänderten Version fälschlicherweise entfernt. Ist aber in der aktuellen Version alles wieder drin.
Aus meiner Sicht kann die letzte Version eingefroren werden.
Grüße und Danke,
Heiko
das ist die version aus dem post hier: http://forum.fhem.de/index.php/topic,14786.msg111928.html#msg111928 (http://forum.fhem.de/index.php/topic,14786.msg111928.html#msg111928)?
gruss
andre
nein die Version aus diesem Post ;-)
http://forum.fhem.de/index.php/topic,14786.msg112644.html#msg112644 (http://forum.fhem.de/index.php/topic,14786.msg112644.html#msg112644)
Gruß,
Heiko
hab es eingecheckt.
gruss
andre
Hallo zusammen,
ich betreibe seit gestern auch einen TX-25 IT zusammen mit einem Jeelink und FHEM. Nachdem der Sensor nicht erkannt wurde - obwohl MSGCNT vom Jeelink alle 4 Sekunden hochzählte - half die Angabe "ignore_battery" beim Pairingmodus. Vermutlich hatte ich einfach nur die Batterien immer zu kurz entnommen. Seitdem funktioniert das ganze wunderbar und ist absolut synchron mit der Original "Wetterstation".
An dieser Stelle einen großen Dank an die Entwickler!
Da der Temperatursensor sehr oft sendet, habe ich zunächst die Einträge im Log etwas begrenzt, damit nur noch stündlich bzw. bei Änderung ein Eintrag erfolgt:
attr Temp_Balkon event-min-interval temperature:3600,temperature2:3600,battery:3600
attr Temp_Balkon event-on-change-reading temperature,temperature2,battery
Nun kommt es aber sehr oft vor, dass der Sensor Werte hintereinander misst, die nur 0,1-0,2°C voneinander abweichen. Ich würde gerne diese minimalen Abweichungen nicht im Log speichern, um ein alternieren zu verhindern.
Wie bekomme ich nun eine Art Hysterese reaisiert, sodass erst bei einer Abweichung ab z.B. 0,3°C vom alten Wert dieser aktualisiert wird?
ich baue diese woche den gleitenden mittelwert und eine konfigurierbare genauigkeit ein.
gruss
andre
Zitat von: justme1968 am 10 Dezember 2013, 12:53:36
ich baue diese woche den gleitenden mittelwert und eine konfigurierbare genauigkeit ein.
gruss
andre
Danke! Dann sollte alles wunderbar laufen!
Zitat von: justme1968 am 10 Dezember 2013, 12:53:36
ich baue diese woche den gleitenden mittelwert und eine konfigurierbare genauigkeit ein.
gruss
andre
Vielen Dank, Andre. ;)
so... bitte mal testen:
- doDewpoint -> 1: der taupunkt wird berechnet
- doAverage -> 1: es wird ein mittelwert über die letzten 4 werte gebildet
- resolution: auflösung in 1/10 grad auf die das Ergebnis gerundet werden soll:
1 -> 1/10 grad, 5 -> 5/10 grad, 10 -> auf ganze grad runden.
für die feuchtigkeit wird zur zeit noch der gleiche wert als 1/1 % interpretiert verwendet
gruss
andre
Das Runden scheint bei mir nicht zu klappen:
Mit resolution=1 zeigt
T: 10.4381022739128 H: 42.4375
an.
Ich habe nur das Perlmodul ersetzt und "reload 36_LaCrosse.pm" abgesetzt.
sorry. da war noch ein tippfehler im modul. ich hab die version aus dem post vorhin aktualisiert.
gruss
andre
Kann es sein, dass Du die gleiche VErsion hochgeladen hast?
diff 36_LaCrosse.pm_3 36_LaCrosse.pm
zeigt keinen Unterschied...
ich bin mir ganz sicher das ich die richtige version hoch geladen hatte. ich falsche habe ich schon gar nicht mehr. aber der anhang war tatsächlich noch mal der falsche.
jetzt ist es wirklich richtig.
gruss
andre
Danke, jetzt klappt es!!
Mein Reading verstehe ich aber noch nicht ganz...
Anbei der aktuelle Status:
* ich finde in der Weboberfläche kein "set <> clear readings. Da das "H" aber länger nicht mehr aktualisiert wurde, gehe ich davon aus, dass ich dieses löschen sollte,
H 0 2013-11-21 02:21:52
T 8.1 H: 46 D: -2.8 2013-12-10 15:30:46
battery ok 2013-12-10 15:30:25
humidity 46 2013-12-10 15:30:25
state T: 8.42032682462331 H: 45.9998277967798 2013-12-10 15:27:39
temperature 8.2 2013-12-10 15:30:25
readings kannst du mit deletereading löschen. am besten mal alle.deletereading <device> .*
gruss
andre
Vielen Dank, hat funktioniert.
Einziges Problem das ich noch habe: Ich habe einen Sensor ohne Feuchtigkeitssensor: Jedoch zeigt der nach einer gewissen Zeit immer wieder Feuchtigkeit: 99 an.
Gibt es dafür eine Lösung/Idee?
Nachtrag:
Hier scheint das Runden noch nicht zu funktionieren:
dewpoint -3.40522891656125
laut protokoll sind werte bis 99 erlaubt. aus irgendeinem grund bekomme ich vom sketch scheinbar noch eine 99 obwohl der sensor sie nicht sendet. ich hab eben mal kurz in den sketch geschaut und mir kommen ein paar dinge noch komisch vor was die feuchtigkeit angeht. da muss noch mal jemand der wirklich die sensoren hat in den sketch schauen.
stimmt dewpoint wird noch nicht gerundet. das ändere ich vor dem einchecken noch.
gruss
andre
Danke nochmals:
doAverage=1
resolution=1
scheint noch nicht das gewünschte Ergebnis zu bringen, anbei ein kurzer Auszug.
2013-12-10_18:18:19 temp.bz.AussenthermometerLaCrosse T: -1
2013-12-10_18:18:23 temp.bz.AussenthermometerLaCrosse T: -0.9
2013-12-10_18:19:07 temp.bz.AussenthermometerLaCrosse T: -1
2013-12-10_18:19:11 temp.bz.AussenthermometerLaCrosse T: -0.9
2013-12-10_18:19:20 temp.bz.AussenthermometerLaCrosse T: -1
schade....
die werte unterscheiden sich um 0.1 grad. mit resolution 1 hast du eingestellt das genau dieser unterschied noch aufgezeichnet wird.
wenn du resolution auf 2 setzt wird alles was sich um weniger als 0.2 grad unterscheidet unterdrückt.
unabhängig davon ist mir aber hoch etwas eingefallen eben: der durchschnitt wird noch immer über die nicht gerundeten werte gerechnet. d.h. die kleinen schwankungen schlagen an dieser stelle immer noch durch.
wenn dir noch nicht die lust vergangen ist nimm mal die angehängte version. da wird erst gerundet und dann getitelt.
gruss
andre
Ich teste auch mal,
ich habe mittlerweile 4 LaCrosse Sensoren, 1 x TX 29 IT , 3 TX 29 DTH-IT von technoline.
Robin
Die neue Version sieht leider nicht gut aus bei mir, wechle wieder zur vorherigen!
tail -n 2000 sensoren-2013.log |grep temp.bz
2013-12-10_18:32:01 temp.bz.AussenthermometerLaCrosse T: -1.2
2013-12-10_19:10:09 temp.bz.AussenthermometerLaCrosse T: -1.4
2013-12-10_19:28:14 temp.bz.AussenthermometerLaCrosse T: -1.6
2013-12-10_19:45:31 temp.bz.AussenthermometerLaCrosse T: -1.8
2013-12-10_20:11:29 temp.bz.AussenthermometerLaCrosse T: -2
2013-12-10_20:51:35 temp.bz.AussenthermometerLaCrosse T: -2.2
2013-12-10_21:21:55 temp.bz.AussenthermometerLaCrosse T: -2.4
2013-12-10_21:57:17 temp.bz.AussenthermometerLaCrosse T: -2.6
2013-12-10_22:13:06 temp.bz.AussenthermometerLaCrosse T: -2.83281249999999
2013-12-10_22:13:15 temp.bz.AussenthermometerLaCrosse T: -2.82460937499999
2013-12-10_22:13:24 temp.bz.AussenthermometerLaCrosse T: -2.81845703125
2013-12-10_22:13:33 temp.bz.AussenthermometerLaCrosse T: -2.8138427734375
2013-12-10_22:13:41 temp.bz.AussenthermometerLaCrosse T: -2.81038208007812
2013-12-10_22:13:50 temp.bz.AussenthermometerLaCrosse T: -2.80778656005859
2013-12-10_22:13:59 temp.bz.AussenthermometerLaCrosse T: -2.80583992004394
Zitat von: justme1968 am 10 Dezember 2013, 18:38:46
die werte unterscheiden sich um 0.1 grad. mit resolution 1 hast du eingestellt das genau dieser unterschied noch aufgezeichnet wird.
wenn du resolution auf 2 setzt wird alles was sich um weniger als 0.2 grad unterscheidet unterdrückt.
Danke! Wie man sieht, habe ich die Resolution bereits auf 2 gesetzt, was auch funktioniert. Dennoch hoffte ich, auch mit 1 bessere
Logs zu erhalten indem ich hoffte, dass das Mitteln einen besseren Effekt zeigt.
ich glaube das schaut gar nicht so schlecht aus wie du denkst. das zappeln ist eigentlich komplett weg und du hast nur eine gleichmässig fallende temperatur.
ich hab nur vergessen nach dem mitteln das ergebnis noch mal zu runden oder auch nur abzuschneiden. die unten angehängte version macht das jetzt auch noch. bitte die version noch mal mit resolution 2 und auch 1.
gruss
andre
Die neueste Version kann FHEM nicht laden:
ZitatCannot load module LaCrosse
ich glaube ich stehe mit der neuen upload funktion auf kriegsfuss.
ich habe die version noch mal ersetzt. jetzt ist es wenigstens die die beabsichtig war.
gruss
andre
Hallo Andre,
Zitat von: justme1968 am 10 Dezember 2013, 16:51:27
laut protokoll sind werte bis 99 erlaubt. aus irgendeinem grund bekomme ich vom sketch scheinbar noch eine 99 obwohl der sensor sie nicht sendet. ich hab eben mal kurz in den sketch geschaut und mir kommen ein paar dinge noch komisch vor was die feuchtigkeit angeht. da muss noch mal jemand der wirklich die sensoren hat in den sketch schauen.
Kannst Du mir sagen was Du genau damit meinst? Ich habe mir einen Sensor bestellt der die Feuchtigkeit misst. Wenn ich ihn habe kann ich mir den Teil nochmal anschauen!
Heiko
wenn ich es beim schnell drüber schauen nicht übersehen habe wird das batterie bit im feuchte wert z.b. sehr seltsam für die vergleiche behandelt und für die 106 die keine feuchte messung bedeutet ebenso.
zumindest wäre es eine stelle die aufgeräumt gehört glaube ich.
irgendetwas muss die 99 ja herbei zaubern und ich bin mir sehr sicher das es nicht das fhem modul ist.
gruss
andre
Falls Du den Code hier meinst, dann kann ich dir zustimmen! Den habe ich auch nicht verstanden und wollte ihn nicht ohne weiteres umstellen. Ich werd mich mal daran machen das zu verstehen und aufzuräumen, sobald ich den neuen Sensor hab.
// bogus check humidity + eval 2 channel TX25IT
// TBD .. Dont understand the magic here!?
if ( (msg->humidity >= 0 && msg->humidity <= 99)
|| msg->humidity == 106
|| (msg->humidity >= 128 && msg->humidity <= 227)
|| msg->humidity == 234)
{
pBuf += 1 | msg->batt_inserted;
pBuf += ' ';
} else if (msg->humidity == 125 || msg->humidity == 253 ) {
pBuf += 2 | msg->batt_inserted;
pBuf += ' ';
} else {
return "";
}
Hallo,
in der aktuellen Version r4354 hat sich ein Fehler beim Setzen des State eingeschlichen. Es wird $humidity anstatt $dewpoint gesetzt.
Gruß
hab es repariert.
gruss
andre
In der aktuellsten Version von eben wird die Luftfeuchtigkeit falsch gerundet. Ich habe hier statt 50% Luftfeuchtigkeit nur 5%. Statt 99% (Sensor ohne Humidity) werden 10% angezeigt.
hallo zusammen,
ich habe gestern schon wieder eine version eingecheckt die in der falschen reihenfolge mittelt und rundet. es ist seit eben korrigiert und ab morgen sollte es dann wirklich gehen. zumdest der angedachte stand.
ich bin aber mit dem mitteln an sich noch nicht wirklich zufrieden. das funktioniert bei dem grundrauschen den der sensor hat noch nicht wirklich gut.
gruss
andre
wenn mir einer von euch die raw messages von ein paar sensoren loggt kann ich das nächste mal besser testen und es geht nicht ganz so viel schief.
sorry noch mal.
gruss
andre
Ich hatte leider die letzten Tage wenig Zeit.
In der aktuellen Version ist zumindest noch ein Fehler beim Runden der Humidity:
$humidity = int($humidity + 0.5) / 10;
Das Teilen durch 10 muß hier weg.
Außerdem habe ich noch ein paar kleine Anmerkungen:
- Der gleitende Mittelwert sollte immer auf den "genauen" Werten berechnet werden. Ansonsten bleiben wir bei einer höheren resolution auf einer Temperatur hängen und benötigen eine hohe Temperaturdifferenz, um den Wert wirklich zu ändern.
- Ungültige Humidity-Werte sollten nicht in die Berechnung einfließen
- Beim Start sollte der erste Wert ohne Mittelung übernommen werden
- Meinen Beobachtungen nach können wir nach den Fixes im Sketch auf den filterThreshold verzichten. Er stört aber nicht.
- Eigentlich müßten Humidity und DewPoint eine eigene resolution bekommen. Für mich ist das aber unnötig
Mein Vorschlag wäre folgender:
if( $type == 0x00 ) {
$channel = "" if( $channel == 1 );
if( AttrVal( $rname, "doAverage", 0 ) ) {
if(defined($rhash->{"previousT$channel"})){
$humidity = ($rhash->{"previousH$channel"}*3+$humidity)/4 if( $humidity && $humidity <= 99 );
$temperature = ($rhash->{"previousT$channel"}*3+$temperature)/4;
}
}
if( defined($rhash->{"previousT$channel"})
&& abs($rhash->{"previousH$channel"} - $humidity) <= AttrVal( $rname, "filterThreshold", 10 )
&& abs($rhash->{"previousT$channel"} - $temperature) <= AttrVal( $rname, "filterThreshold", 10 ) ) {
readingsBeginUpdate($rhash);
my $dewpoint;
if( AttrVal( $rname, "doDewpoint", 0 ) && $humidity && $humidity <= 99 ) {
$dewpoint = LaCrosse_CalcDewpoint($temperature,$humidity);
$dewpoint = int($dewpoint*10 + 0.5) / 10;
readingsBulkUpdate($rhash, "dewpoint$channel", $dewpoint);
}
my $outTemp;
my $outHum;
my $resolution = AttrVal( $rname, "resolution", 1 );
$outTemp = int($temperature*10 / $resolution + 0.5) * $resolution / 10;
$outHum = int($humidity / $resolution + 0.5) * $resolution;
readingsBulkUpdate($rhash, "temperature$channel", $outTemp);
readingsBulkUpdate($rhash, "humidity$channel", $outHum) if( $humidity && $humidity <= 99 );
if( !$channel ) {
my $state = "T: $outTemp";
$state .= " H: $outHum" if( $humidity && $humidity <= 99 );
$state .= " D: $dewpoint" if( $dewpoint );
readingsBulkUpdate($rhash, "state", $state) if( Value($rname) ne $state );
}
readingsBulkUpdate($rhash, "battery$channel", $battery_low?"low":"ok");
readingsEndUpdate($rhash,1);
} else {
readingsSingleUpdate($rhash, "battery$channel", $battery_low?"low":"ok" , 1);
}
$rhash->{"previousH$channel"} = $humidity;
$rhash->{"previousT$channel"} = $temperature;
}
Ich hoffe, ich finde die nächsten Tage Zeit noch etwas mehr zu testen.
Gruß,
Gero
das mit der feuchtigkeit hatte ich gestern schon repariert das sollte behoben sein.
- wenn man den mittelwert auf den original werten rechnet schlägt der nachteil das er bei 'hohen' frequnzen nicht mehr sauber funktioniert aber leider durch. also z.b. ein messert der immer genau +-0.1 grad schwankt wird durchgereicht oder sogar invertiert.
die die hinter dem einstellen der auflösung ist je genau das sich erst grössere schwankungen auswirken sollen. eigentlich ist aber glaube ich ein anderer filter wie gaus oder einfacher binominal viel geeigneter
- mein verständnis war das ungültige humidity werte nur von sensoren kommen die keine humidity senden d.h. der wert immer 99 ist. daran ändert auch die mitteilung nichts. die auflösung schon. du hast recht.
- du hast recht. das übernehmen des ersten wertes ist zur zeit falsch. ursprünglich wurde er garnicht angezeigt sondern nur als previous gespeichert. und erst ab dem zweiten wert wird auch angezeigt. das hat noch mit den ausreissern am anfang auf grund der falschen crc prüfung zu tun. dadurch das die mitteilung ganz an den anfang gewandert ist passt das natürlich so nicht mehr.
- das mit der eigenen resolution für humidity ist richtig ich wollte aber erst mal sehen ob es überhaupt so funktioniert. beim dewpoint bin ich mir aber nicht sicher. der wird ja auf die temperatur die schon in der auflösung beschnitten ist gerechnet. noch mal bescheiden ist glaube ich nicht richtig.
- wenn alle bestätigen das die neue cri prüfung so effektiv ist das es keine ausreisser mehr gibt würde ich den threshold eigentlich gerne rausschmeissen.
gruss
andre
Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
das mit der feuchtigkeit hatte ich gestern schon repariert das sollte behoben sein.
Ich habe erst vor 3 Stunden ein Update gemacht und da war der Fehler noch drin.
Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
- wenn man den mittelwert auf den original werten rechnet schlägt der nachteil das er bei 'hohen' frequnzen nicht mehr sauber funktioniert aber leider durch. also z.b. ein messert der immer genau +-0.1 grad schwankt wird durchgereicht oder sogar invertiert.
die die hinter dem einstellen der auflösung ist je genau das sich erst grössere schwankungen auswirken sollen. eigentlich ist aber glaube ich ein anderer filter wie gaus oder einfacher binominal viel geeigneter
Okay. Ich habe die Forderujg nach der resolution anders verstanden. Ich dachte, es wäre die Auflösung der readings gemeint:
z.B.: resolution = 5, previousT = 20.0, temperature = 21.5
Das führt bei deinem Code dazu, dass
temperature = (20.0*3 + 21.5)/4 = 20.375 -> 20.4
(oder habe ich mich vertan)
Wenn ich den gleitenden Mittelwert immer auf den Originalwerten berechne, wird doch gerade ein Schwanken von +-0.1 Grad herausgefiltert(?) Ich sehe hier kein Problem.
Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
- mein verständnis war das ungültige humidity werte nur von sensoren kommen die keine humidity senden d.h. der wert immer 99 ist. daran ändert auch die mitteilung nichts. die auflösung schon. du hast recht.
Ich habe mich falsch ausgedrückt. Es ging mir um das Einschwingen am Anfang durch die Mittelwertbildung und den nicht gesetzten Startwert. D.h. dein Code liefert bei eingeschalteter Rundung am Anfang Humidity-Werte auch für Sensoren, die konstant 99 liefern.
Zitat von: justme1968 am 13 Dezember 2013, 10:20:55
- das mit der eigenen resolution für humidity ist richtig ich wollte aber erst mal sehen ob es überhaupt so funktioniert. beim dewpoint bin ich mir aber nicht sicher. der wird ja auf die temperatur die schon in der auflösung beschnitten ist gerechnet. noch mal bescheiden ist glaube ich nicht richtig.
Wenn du den dewpoint auf den beschnittenen Werten berechnest, hast du recht. Aber korrekter ist meiner Meinung nach auch hier die Berechnung auf den nicht beschnittenen Werten.
Ich möchte dir aber nicht in deinen Code reinreden und danke dir natürlich für deine Arbeit.
Gruß,
Gero
Zitat von: hthiery am 11 Dezember 2013, 09:22:20
Falls Du den Code hier meinst, dann kann ich dir zustimmen! Den habe ich auch nicht verstanden und wollte ihn nicht ohne weiteres umstellen. Ich werd mich mal daran machen das zu verstehen und aufzuräumen, sobald ich den neuen Sensor hab.
// bogus check humidity + eval 2 channel TX25IT
// TBD .. Dont understand the magic here!?
if ( (msg->humidity >= 0 && msg->humidity <= 99)
|| msg->humidity == 106
|| (msg->humidity >= 128 && msg->humidity <= 227)
|| msg->humidity == 234)
{
pBuf += 1 | msg->batt_inserted;
pBuf += ' ';
} else if (msg->humidity == 125 || msg->humidity == 253 ) {
pBuf += 2 | msg->batt_inserted;
pBuf += ' ';
} else {
return "";
}
Nach meinen Recherchen:
humidity
0..99 -> Hygrosensor vorhanden
106 -> kein Hygrosensor vorhanden
125 -> TX25IT channel 2 (da bin ich mir nicht ganz sicher)
Bit 7 -> battery low indicator
Dadurch kommen die Werte im obigen Code zustande.
Im vorangeganenen Post habe ich mich natürlich vertan:
Sensoren ohne Hygrosensor liefern keine 99, sondern eine 106!
Gruß,
Gero
Zitat von: justme1968 am 12 Dezember 2013, 10:43:39
wenn mir einer von euch die raw messages von ein paar sensoren loggt kann ich das nächste mal besser testen und es geht nicht ganz so viel schief.
Falls du es noch brauchen solltest, als Anhang ein Mitschnitt der Rohdaten von meiner Sensoren. Ich hoffe, du kannst in dieser Form etwas damit anfangen.
Gruß,
Gero
super. danke.
ich werde deinen vorschlag mit der aktuellen version zusammen bringen und dann zum testen hier rein stellen. mit der reparierten crc prüfung kann man glaube ich ein paar altlasten raus schmeissen.
gruss
andre
Hi,
kann man den JeeLink Sketch auch mit panstamps verwenden?
Ich habe hier noch Panstamps herumliegen, würde aber auch ungern noch ein weiteres System integrieren. Mit Panstamps kenne ich mich schon etwas aus.
das funkmodul ist ein anderes. ohne größere änderungen geht es also nicht und auch dann nicht automatisch für alle sketches.
gruss
andre
Hallo zusammen,
ich habe jetzt die neueste Version des Moduls laufen. Dabei kommt es noch zu zwei Problemen:
1) Zwischendurch habe ich in den Logs immer wieder Ausreißer, welche um bis zu 10°C vom tatsächlichen Wert abweichen. Wenn ich den filterThreshold erhöhe (zwischen aus und Wert 10), wird das ganze schlimmer, je höher der Wert eingestellt ist.
=> Kann man hier eine Plausibilitäts-Prüfung in den Code einbauen? Wenn beispielsweise die Werte zeitlich sehr nahe beeinander sind, dann ist maximal eine Temperaturabweichung von x °C zum letzten Wert zugelassen - ansonsten wird der neue Wert verworfen. Da es im Log meist nur ein falscher Wert ist, könnte man diese so herausfiltern.
2) Die Funktion resolution funktioniert bei mir nicht. Ich habe hier als Wert 2 gewählt, aber dennoch wird jede Aktualisierung (auch um nur 0,1°C) angezeigt und geloggt.
die ausreisser sollten weg sein wenn du den neuesten sketch verwendest. in vorherigen versionen war die crc prüfung falsch.
je grösser der filterThreshold wert ist um so grössere temperatur sprünge sind erlaubt. bei 10 sind bis zu 10 grad erlaubt.
genau für diese plausibilitätsprüfung ist der filterThreshold wert.
resolution beschneidet den original wert den der sensor sendet. wenn du auch noch ein doAverage gesetzt hast kann hierbei natürlich wieder ein wert entstehen der um weniger abweicht.
ich werde das mitteln und runden aber noch mal komplett überarbeiten.
gruss
andre
Besten Dank, Andre. Mein Jeelink hatte tatsächlich noch die alte Version 08 und mit der neuen sind die Ausreißer nun seit 12 Stunden weg.
Die Bedeutung von filterThreshold habe ich genau entgegen angenommen, jetzt habe ich es verstanden.
Gibt es so etwas wie eine best practice, um die Logdateien klein zu halten und dennoch sehr genaue Werte zu erhalten?
Hallo,
ich bin ganz neu mit FHEM.
Habe eine FritzBox 7390 mit der Labor-Version.
Dazu habe ich einen JeeLink.
Nun habe ich die Dateien
36_JeeLink.pm ($Id: 36_JeeLink.pm 3871 2013-09-07 10:55:36Z justme1968 )
36_LaCrosse.pm ($Id: 36_LaCrosse.pm 4354 2013-12-10 17:26:35Z justme1968 $)
Habe dabei das Log3 durch Log ersetzen müssen, da Log3 noch nicht unterstützt wird in der Version meiner Fritzbox.
Soweit alles gut,
JeeLink wird erkannt.
Es werden insgesammt 3 LaCrosse-Sensoren erkannt.
Witzigerweise habe ich nur zwei.
Für einen Sensor werden Temperatur und Luftfeuchtigkeit(106, also keine Luftfeuchtigkeitsmessung) ausgegeben, dieses ist aber der Sensor, welcher nicht mir gehört. ;)
Mein Problem:
Meine beiden eigenen TX29DTH-IT werden erkannt,
aber bei der Anzeige erhalte ich nur drei Fragezeichen.
Kann mir jemand sagen was falsch ist?
Die Logfiles für beide Sensoren sind auch leer.
Hier mal mein Log nach einem Neustart:
2013.12.20 12:35:00 1: Including /etc/fhem.cfg
2013.12.20 12:35:00 3: telnetPort: port 7072 opened
2013.12.20 12:35:00 3: WEB: port 8083 opened
2013.12.20 12:35:00 3: WEBphone: port 8084 opened
2013.12.20 12:35:00 3: WEBtablet: port 8085 opened
2013.12.20 12:35:00 3: Opening fbaha device localhost:2002
2013.12.20 12:35:00 3: Can't connect to localhost:2002: Connection refused
2013.12.20 12:35:00 3: Opening JeeLink1 device /dev/ttyUSB0
2013.12.20 12:35:00 3: Setting JeeLink1 baudrate to 57600
2013.12.20 12:35:00 3: JeeLink1 device opened
2013.12.20 12:35:01 3: No I/O device found for LaCrosse_6C
2013.12.20 12:35:01 1: LaCrosse_6C: no I/O device
2013.12.20 12:35:01 3: No I/O device found for LaCrosse_08
2013.12.20 12:35:01 1: LaCrosse_08: no I/O device
2013.12.20 12:35:01 3: No I/O device found for LaCrosse_18
2013.12.20 12:35:01 1: LaCrosse_18: no I/O device
2013.12.20 12:35:01 1: Including /var/log/fhem/fhem.save
LaCrosse_6C ist der Sensor des Nachbarn
LaCrosse_08 und LaCrosse_18 sind meine TX29DTH-IT
Wäre sehr dankbar wenn Ihr mir helfen könntet.
Danke
Rüdiger
du hast von beiden modulen nicht die aktuelle version und solltest in fhem ein 'update' machen.
ansonsten kann ich dir zu fritzbox nicht wirklich viel sagen ausser das hier im forum 'normale' fhem version empfohlen wird und nicht die von avm.
gruss
andre
Hallo Andre,
danke für die schnelle Antwort,
genau das hatte ich "befürchtet".
Also die Labor-Version rausschmeissen und die Community-Version von hier http://www.fhemwiki.de/wiki/FHEM_und_FritzBox_7390
verwenden?
Oder kann mir einer sagen wie ich die Labor-Version auf eine aktuelle FHEM-Version bringen kann??
Vielen Dank nochmal
Rüdiger
such mal hier im forum da wirst du einiges dazu finden.
gruss
andre
Hallo Andre,
Du schreibst ich hätte von beiden Modulen nicht die aktuellste Version,
wo bekomme ich die aktuellen Versionen denn?
Ich habe die genommen, welche hier in diesem Post geschickt wurden.
Im Wiki steht leider nur drin: Wurde in FHEM integriert. :(
Nach Update der FB-Version schaue ich gerade.
Gruß
Rüdiger
du bekommst du neueste version jeweils in dem du in fhem update aufrufst.
alternativ kannst du es auch von hand aus dem svn auschecken. das ist dann aber jedes mal mit inkompatibilitäten (wie z.b. Log3) und handarbeit verbunden
gruss
andre
Hallo Andre,
1.000 Dank,
das mit dem Update habe ich mit offenen Augen übersehen.....
Kaum macht man es richtig funktioniert es.
Habe nun das Update ohne Probleme durchführen können,
die neueste Version ist drauf und alle Temperaturen sind da...
Nun hoffe ich dass die restliche Hardware eintrifft,
dann kann es richtig losgehen.
Ein großes Lob an alle Entwickler.
Viele Grüße
Rüdiger
Hallo,
ich versuche den Sensor TX35DTH-IT ans rennen zu bekommen.
Leider wird dieser Sensor nicht automatisch erkannt.
Ich erhalte auch keine Einträge im Log.
wenn ich den Jeelink an der Arduino IDE betreibe und den Debug Modus aktiviere erhalte ich nur Nachrichten folgender Art:
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
Start receiving
End receiving, HEX raw data: 14 1F 87 CD E6
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 80 FC 27 E6 40
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: A8 88 63 A 41
## CRC FAIL ##
Start receiving
Hat schon jemand diesen Sensor am laufen.
Vielen Dank
Christoph
@andre, @ohweh
hallo ihr beiden, bin gerade beim Saubermachen meiner Festplatte und habe eine
Vergleichsliste gefunden "RFM01_RFM12B_la crosse.xls" siehe auch Anlage vielleicht hilft das Euch
Spezialisten.
Gruss und schönes Fest
Billy
@andre, @ohweh, @hthiery
Ist es eigentlich möglich, das ganze umzudrehen?
Nach längerem Überlegen fände ich es angenehmer, den stabilen Temperaturwert meines 1-wire Sensos über den JeeLink in das IT+ Funkformat umzuwandeln und zu sensen, statt zu empfangen.
Dadurch könnte ich immer die selbe Temperatur in allen Wetterstationen anzeigen und hätte keine Batteriewechsel mehr nötig. Um so länger ich darüber nachdenke, um so besser finde ich die Idee!!! :D
Hallo,
ich bin jetzt mit meinem Sensor TX35DTH-IT einen Schritt weiter gekommen.
Ich erhalte jetzt Datensätze folgender Art:
9E 26 24 33 C2
9E 26 24 36 33
9E 26 25 34 A2
Allerdings wird die Checksumme als fehlerhaft bemängelt.
Ich habe dann die Checksummenprüfung in der Software des JeeLinks deaktiviert.
Der Datensatz wird dann soweit richtig dekodiert.(Temperatur und Luftfeuchtigkeit)
Weiss jemand wie die Checksumme (Byte5) gebildet wird?
Oder ist Byte 5 keine Checksumme?
Vielen Dank
Gruss Christoph
Hallo,
Welcher ist der richtige stick?
JeeLink (v3) - JeeLink 433
JeeLink (v3) - JLink 868
?
Danke
die 868 version.
gruss
andre
Hallo Andre,
ich habe über das Problem der neuen ID beim Batteriewechsel nachgedacht...
Keine Ahnung ob das Programmiertechnisch umsetzbar ist, oder der Aufwand vertretbar, aber wäre es nicht machbar eine Art "Change Battery now" einzuführen.
Das könnte man dann für einen Sensor ausführen (also mit Sensor ID), dann die Batterie wechseln, und die Sensor ID die danach neu erkannt wird, wird automatisch in das define des Sensors geschrieben an dem ich zuvor das "Change Battery now" ausgelöst hatte.
Nur so eine Idee.
Die Sensoren funktionieren nämlich wirklich gut und sind günstig, und es ist doch schade dass davon einige Abstand nehmen aufgrund des "neue ID" Problems.
------------
Dann gleich noch eine Frage:
Jedes mal wenn ich meine Conifg speichere brechen die Werte an den Sensoren total ein und es dauert etwas bis sich das wieder gefangen hat.
Hier mal ein Auszug aus dem Log:
2014-01-05_11:40:02 LaCrosse_Schlafzimmer T: 16.6 H: 61.9 D: 9.2
2014-01-05_11:52:04 LaCrosse_Schlafzimmer T: 16.7 H: 61.9 D: 9.3
2014-01-05_11:55:05 LaCrosse_Schlafzimmer T: 12.8 H: 47.3 D: 1.9 <-- save config
2014-01-05_11:58:27 LaCrosse_Schlafzimmer T: 12.8 H: 47.3 D: 1.9
2014-01-05_12:08:56 LaCrosse_Schlafzimmer T: 16.7 H: 61.9 D: 9.4
Muss ich da noch irgendwas ändern?
Danke!
Gruß
Matze
das mit dem jetzt wechseln könnte gehen. ich brauche nur jemand zum testen.
beim neustart braucht das mitteln noch eine weile weil noch der fehler mit dem anfangswert drin ist. das muss ich noch reparieren.
solange du fehm nicht neu startest sollte es aber kein problem sein.
du solltest das konfig file editieren und nicht rereadcfg verwenden. das ist das gleiche wie ein neustart. es ist viel besser per telnet oder command box oder der device detail ansicht zu konfigurieren und dann save zu sagen.
gruss
andre
Zitat von: justme1968 am 06 Januar 2014, 11:48:20
das mit dem jetzt wechseln könnte gehen. ich brauche nur jemand zum testen.
Ich könnte für dich Testen, wenn du mir ein paar An-/Einweisungen zum debuggen gibst.
Gruß
Matze
anbei zum testen mit zwei änderungen:
- beim neustart sollte es kein einschwingen wegen der mittelwert bildung mehr geben
- neues kommando
replaceBatteryForSec <seconds_active> [ignore_battery]sobald es gesetzt ist wird die adresse dieses device durch die erste unbekannte adresse ersetzt die empfangen wird. wenn ignore_battery nicht gesetzt werden nur nachrichten mit dem new battery flag dafür genommen. das kommando ist nur für jeweils ein device zur zeit möglich.
ich vermute das beste vorgehen ist die batterie zu wechseln, dabei lange genug zu warten das nach dem austausch das new battery flag gesetzt ist und dann in fhem replaceBatteryForSec auf 60 sekunden zu setzen. im log sollte dann
ZitatLaCrosse Changing device <device> from xx to yy
stehen.
gruss
andre
Hallo Andre,
das ging ja schnell. :)
Versuche Heute oder Morgen zu testen.
Vielen Dank schon mal!
Gruß
Matze
Hallo Andre,
gerade getestet.
Leider scheint es nicht zu funktionieren. :(
Ich kann den Befehl in der device detail Ansicht auswählen und absetzten.
Leider sehe ich aber keine Veränderung.
In meinem Log steht nach dem Batteriewechsel nach wie vor:
2014.01.07 17:29:54 3: LaCrosse Unknown device 24, please define it
Wie kann ich denn noch tiefer loggen?
Gruß
Matze
hast du es inklusive ignore-battery probiert?
gruss
andre
ich glaube ich habe den fehler gefunden.
bitte probiere es noch mal. ich habe im post oben das file ausgetauscht.
gruss
andre
Hallo Andre,
habe es noch mal versucht, auch mit ignore_battery, aber leider ohne Erfolg.
Werde heute Abend mal verbose hoch drehen und schauen ob ich was finde.
So weit ich gesehen habe schreibt das Modul aber recht wenig Log Einträge.
In der ganzen replaceBattery Prozedur steht ja nur ein Log3, oder?
Evtl kannst du das zu debug Zwecken mal erweitern.
Oder geht das irgendwie anders einfacher?
Gruß
Matze
ja. ich bau ein paar log zeilen zum debuggen ein.
gruss
andre
jetzt aber. sorry für das hin und her. ich habe es jetzt mit eine fake device getestet und es sollte jetzt wirklich gehen.
die version oben ist noch mal ausgetauscht.
gruss
andre
Hallo,
noch eine Frage was ist der Unterschied von JeeNode USB und JeeLink (v3) ?
Zitat von: justme1968 am 08 Januar 2014, 11:59:55
jetzt aber. sorry für das hin und her. ich habe es jetzt mit eine fake device getestet und es sollte jetzt wirklich gehen.
die version oben ist noch mal ausgetauscht.
gruss
andre
Hallo Andre,
Entschuldigung ist nicht nötig. Für den Support den du hier lieferst muss woanders viel Geld gezahlt werden. :)
Hab noch mal getestet. Grundsätzlich funktioniert es jetzt, aber irgendwie erst beim zweiten mal.
Nach dem ersten mal kommt zwar die Meldung im Log, aber geändert wird die ID nicht.
Nach dem zweiten Mal geht es dann einwandfrei.
Hab es zweimal mit dem selben Ergebnis ausprobiert.
1.
2014.01.08 16:32:32 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:32:36 3: LaCrosse Changing device C0 from 24 to C0 <- erster replaceBatteryForSec
2014.01.08 16:32:40 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:32:44 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:32:48 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:32:52 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:32:56 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:33:00 3: LaCrosse Unknown device C0, please define it
2014.01.08 16:33:04 3: LaCrosse Changing device C0 from C0 to C0 <- zweiterreplaceBatteryForSec
2.
2014.01.08 16:37:43 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:39:53 3: LaCrosse Changing device 98 from C0 to 98 <- erster replaceBatteryForSec
2014.01.08 16:39:57 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:40:01 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:40:06 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:40:10 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:40:14 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:40:18 3: LaCrosse Unknown device 98, please define it
2014.01.08 16:40:22 3: LaCrosse Changing device 98 from 98 to 98 <- zweiterreplaceBatteryForSec
Gruß
Matze
ich hab die version oben noch mal ausgetauscht. jetzt geht es auch direkt beim ersten mal :)
bitte teste es noch mal und dann checke ich es ein.
gruss
andre
Genial! :)
Funktioniert sehr gut.
Man darf sich nur nicht verwirren lassen dass die DEF in der device Ansicht erst nach einem refresh der Seite geändert wird.
Wenn du mir jetzt noch sagst wie ich das replaceBatteryForSec als Knopf in meiner Batterieübersicht einbringe, bin ich ( vorerst ;) ) absolut zufrieden gestellt.
Gruß und tausend Danke
Matze
ja also. geht doch :)
alle internals werden nicht automatisch aktualisiert.
wenn du mit batterie übersicht eine readinsgroup meinst... da gehen noch keine kommandos. jedenfalls nicht pro device. ich bin aber schon eine weile am überlegen wie man das einbauen könnte.
was aber jetzt schon geht ist unter die readingsGroup links zu hängen. das wäre aber nur etwas wenn nicht mehr als eine batterie auf low ist. im wiki ist ein beispiel dafür.
oder von hand mit <{...}> selber die links in jede zeile bauen. dazu müsste man das wiki Beispiel abwandeln.
gruss
andre
Zitat von: justme1968 am 08 Januar 2014, 17:48:03
wenn du mit batterie übersicht eine readinsgroup meinst... da gehen noch keine kommandos. jedenfalls nicht pro device. ich bin aber schon eine weile am überlegen wie man das einbauen könnte.
Ja, das meine ich. Dann warte ich mal bis es da eine Lösung gibt. So wie es jetzt funktioniert reicht es ja erst mal vollkommen. Ist ja nichts was man ständig benötigt. 8)
Hab aber schon wieder eine Frage :-[
Jedes mal wenn ich fhem neu starte hab ich im Log folgenden Eintrag:
2014.01.08 17:25:57 3: JeeLinkLaCrosse: Unknown code OK 9 0 1 4 169 58, help me!Kann ich das ignorieren? Muss ich da noch was machen?
Gruß
Matze
hab die version eingecheckt.
gruss
andre
Hallo,
noch eine Frage was ist der Unterschied von JeeNode USB und JeeLink (v3) ?
der jeelink hat ein gehäuse, zusätzlich flash on board, smd bauteile und keine erweiterungs header.
der jeenode usb hat kein gehäuse, kein extra flash, ist etwas größer, kommt normalerweise als bausatz und hat extra pinheader um weitere jeenodes anzuschließen.
im prinzip sollten für die lacrossse sensoren beide gehen.
gruss
andre
@Agamemnon: schau mal hier: http://forum.fhem.de/index.php/topic,14608.msg126111.html#msg126111 (http://forum.fhem.de/index.php/topic,14608.msg126111.html#msg126111)
gruss
andre
Morgen,
bin vor ca. einer Woche durch Zufall auf FHEM gestoßen und bin seither wie besessen von diesem unfassbar COOLEN Projekt! Bin bei der Suche nach einer kostengünstigen Lösung die Temp und Luftfeuchte an diversen neuralgischen Stellen im Neubau zu erfassen auf diesen Thread gestoßen (und ich habe alle 18 Seiten gelesen *fg*)
Nun die Frage: Ich hätte zufällig Zugriff auf 7-8 dieser Sensoren:
http://www.amazon.de/TFA-Thermo-Hygro-Sender-30-3180-IT-Temperatur-Luftfeuchtigkeit/dp/B004WAWF5W/ref=sr_1_1?ie=UTF8&qid=1390039050&sr=8-1&keywords=tfa+303180+it+aussensender (http://www.amazon.de/TFA-Thermo-Hygro-Sender-30-3180-IT-Temperatur-Luftfeuchtigkeit/dp/B004WAWF5W/ref=sr_1_1?ie=UTF8&qid=1390039050&sr=8-1&keywords=tfa+303180+it+aussensender)
da im Namen das IT und TFA im Grund das gleiche wie La Crosse ist...
Hat einer zufällig schon versucht diese Sensoren zu verwenden?
Denkt ihr, die Teile sollten mit dem jeelink gehen?
Denn dann müsste ich ja quasi echt nur den jeelink kaufen! Hätte ne fritzbox 7390 und als backup sogar ein beagle bone black zuhause!
Schon jetzt vielen Dank für die Hilfe und vorallem _danke_ für die super Arbeit die in diesem Jeelink Projekt steckt
Ich vermute mal stark, dass die Teile gehen
z.B in Diesem Link http://www.amazon.co.uk/TFA-Dostmann-30-3142-Wireless-Rain-Gauge/dp/B005J3ZHHY
steht unter Product Description
This wireless rain gauge is compatible with the TFA Dostmann 35.1067.IT and Lacrosse WS1600 weather station. It transmitts on an 868MHz frequency across 100m open field.
Da geht es zwar um den Regenmesser aber das sollte dann für die TH Sensoren auch passen.
Garantieren kann ich das natürlich nicht.
Gruss
Billy
Hab mir heute morgen den jeelink bestellt und werds einfach versuchen sobald die Fritzbox eingerichtet und die TH Sensoren am Start sind ... ich werds euch wissen lassen obs geht ;-)
Hallo Wissende,
habe mir nun auch eine JeeLink 868MHz V3 zugelegt um meine Technoline TX29DTH-IT Sensoren auszulesen.
Aber es läuft nicht so rund wie gewünscht oder ich sehe die Bäume vor lauter Wald nicht.
Zur Konfiguration: FHEM wird auf einem Raspberry Pi mit Linux-Wheezy und einer COC-Module betrieben.
Geschallten werden FS20-Module und einige LAN-Steckdosen, soweit funktioniert alles.
Der Jeelink wurde mit LaCrosseITPlusReader09 (Hier aus dem Beitrag - Im Fhem-Contrib fand ich es nicht) geflasht. Nach dem anstecken des Sticks an den Raspy machte dieser einen Reset.
Anschließend wurde die Config-Datei mit diesen Werten ergänzt.
################################################################################
# #
# Die Definition des CUL #
# #
define COC CUL /dev/ttyAMA0@38400 0000
attr COC room Empfaenger
define JLLaCR JeeLink /dev/ttyUSB0@57600
attr JLLaCR room Empfaenger
attr JLLaCR verbose 5
# #
################################################################################
Nach einem Neustart finden sich folgende Einträge in der Log-Datei
2014.01.21 17:52:41 0: Server shutdown
2014.01.21 17:52:44 1: Including fhem.cfg
2014.01.21 17:52:45 1: Including ./config/system.cfg
2014.01.21 17:52:45 3: Opening COC device /dev/ttyAMA0
2014.01.21 17:52:45 3: Setting COC baudrate to 38400
2014.01.21 17:52:45 3: COC device opened
2014.01.21 17:52:45 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2014.01.21 17:52:45 3: Opening JLLaCR device /dev/ttyUSB0
2014.01.21 17:52:45 3: Setting JLLaCR baudrate to 57600
2014.01.21 17:52:45 3: JLLaCR device opened
2014.01.21 17:52:46 3: WEB: port 8083 opened
2014.01.21 17:52:46 3: WEBphone: port 8084 opened
2014.01.21 17:52:46 3: WEBtablet: port 8085 opened
2014.01.21 17:52:46 3: WEBconfig: port 9093 opened
2014.01.21 17:52:46 1: configfile: Unknown command , try help.
2014.01.21 17:52:46 1: Including ./log/fhem.save
2014.01.21 17:52:47 0: Server started with 10 defined entities (version $Id: fhem.pl 4663 2014-01-16 09:45:15Z rudolfkoenig $, os linux, user fhem, pid 2132)
2014.01.21 17:52:48 5: JeeLink/RAW: /OK 9 224 1 4 1
2014.01.21 17:52:48 5: JeeLink/RAW: OK 9 224 1 4 1/9 106
In Fhem bekomme ich angezeigt dass der COC initialisiert ist und der JeeLink Opened.
Ist das so korrekt?
s. Anhang.
Dieser Teil wird alle 5-10 Sec wiederholt in die Log-Datei geschrieben, obwohl ich keine Senoren in betrieb habe (vermutlich vom Nachbarn)
2014.01.21 17:52:48 5: JLLaCR dispatch OK 9 224 1 4 19 106
2014.01.21 17:52:48 3: LaCrosse Unknown device E0, please define it
2014.01.21 17:52:56 5: JeeLink/RAW: /OK 9 224
2014.01.21 17:52:56 5: JeeLink/RAW: OK 9 224/ 1 4 19 106
Autolog ist on - es wird kein Sensor erkannt und auch nichts ins Config geschrieben.
Aktiviere ich einen Technoline TX29DTH-IT Sensor wird in seinem LCD folgendes geschrieben
SP06 FC dann Temperatur und Feuchtewert
Im log erscheint
2014.01.21 18:22:17 5: JeeLink/RAW: /OK 9
2014.01.21 18:22:17 5: JeeLink/RAW: OK 9/ 224 1 4 18 106
2014.01.21 18:22:17 5: JLLaCR dispatch OK 9 224 1 4 18 106
2014.01.21 18:22:17 3: LaCrosse Unknown device E0, please define it
2014.01.21 18:22:20 5: JeeLink/RAW: /OK 9
2014.01.21 18:22:20 5: JeeLink/RAW: OK 9/ 252 129 4 196 50
2014.01.21 18:22:20 5: JLLaCR dispatch OK 9 252 129 4 196 50
2014.01.21 18:22:20 3: LaCrosse Unknown device FC, please define it
Autolog ist immer noch an - aber ins FHEM wird immer noch nichts geschrieben.
Benutze ich dieses im Config-flie
set JLLaCR LaCrossePairForSec 600 ignore_battery
so ist der Raspberry, nach einem Neustart, für ca. 10 Minuten nicht erreichbar.
2014.01.21 18:37:05 1: Including fhem.cfg
2014.01.21 18:37:05 1: Including ./config/system.cfg
2014.01.21 18:37:05 3: Opening COC device /dev/ttyAMA0
2014.01.21 18:37:05 3: Setting COC baudrate to 38400
2014.01.21 18:37:05 3: COC device opened
2014.01.21 18:37:06 3: COC: Possible commands: mCFiAZOGMRTVWXefltux
2014.01.21 18:37:06 3: Opening JLLaCR device /dev/ttyUSB0
2014.01.21 18:37:06 3: Setting JLLaCR baudrate to 57600
2014.01.21 18:37:06 3: JLLaCR device opened
2014.01.21 18:47:06 3: WEB: port 8083 opened
2014.01.21 18:47:06 3: WEBphone: port 8084 opened
2014.01.21 18:47:06 3: WEBtablet: port 8085 opened
2014.01.21 18:47:06 3: WEBconfig: port 9093 opened
2014.01.21 18:47:06 1: Including ./log/fhem.save
2014.01.21 18:47:06 5: JeeLink/RAW: /OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 224 1 4 18 106
OK 9 252 129 4 192 41
OK 9 224 1 4 18 106
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 2
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 3: LaCrosse Unknown device FC, please define it
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 224 1 4 18 106
2014.01.21 18:47:06 3: LaCrosse Unknown device E0, please define it
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 224 1 4 18 106
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JLLaCR dispatch OK 9 252 129 4 192 41
2014.01.21 18:47:06 5: JeeLink/RAW: OK 9 2/24 1 4 18 106
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 224 1 4 18 106
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 224 1 4 18 106
OK 9 252 129 4 192 41
OK 9 252 129 4 192 41
OK 9 224 1 4 18 106
OK 9 252 129 4 192 41
OK 9 224 1 4 18
Könnte evtl. ein manueller Eintag in die Config-Datei mein Problem lösen?
und wie müsste dieser Eintrag aussehen?
Besten Dank für eure Hilfe
Thomas
Fehler gefunden!
"set JLLaCR LaCrossePairForSec 600 ignore_battery" als Direktbefehl ausgeführt und nun die zwei Sensoren gefunden.
Herzlichen Dank an Alle.
Hallo,
würde der Sensor auch gehen ? http://www.amazon.de/TFA-Dostmann-30-3147-Aussensender/dp/B003KMAVAE/ref=sr_1_4?ie=UTF8&qid=1391020142&sr=8-4&keywords=868MHz+wetter
Bis jetzt der billigste den ich gefunden habe.
Edit:
Wenn ich
2014.01.22 16:57:49 0: ERROR: Cannot autoload LaCrosse
2014.01.22 16:57:49 3: JLLaCR: Unknown code OK 9 8 1 3 228 106, help me!
2014.01.22 17:00:23 0: ERROR: Cannot autoload LaCrosse
2014.01.22 17:00:23 3: JLLaCR: Unknown code OK 9 8 1 3 228 106, help me!
bekomme geht der Sensor nicht oder?
Hi,
hab gestern die erwähnten "TFA-Thermo-Hygro-Sender-30-3180" bekommen... Auf den Sensoren selbst prankt in epischer Größe das IT+ Symbol
nur leider tut sich da im FHEM-log so garnix (muss allerdings auch zugeben, dass ich der absolute FHEM Anfänger bin). der Jeelink wird zumindest im *.log als Opened angezeigt...
was mir beim rumprobieren aufgefallen ist: beim neu einsetzen der batterien ändert sich bei diesen sensoren keine ID (die ID besteht aus 2 Hex Bytes e.g. 6C A5)
gibts ne möglichkeit mehr Informationen im *.log des FHEM oder am PC in der ARDUINO IDE oder oder oder zu bekommen? Muss doch irgendwie möglich sein die Teile zu betreiben.
Gruß
Hallo,
habe auch eine TFA-Thermo-Hygro-Sender-30-3180 bei mir tut sich auch nichts.
Wie können wir den Entwicklern hier benötigte Daten liedern?
--
Bei dem hier http://www.amazon.de/TFA-Dostmann-30-3147-Aussensender/dp/B003KMAVAE/ref=sr_1_4?ie=UTF8&qid=1391020142&sr=8-4&keywords=868MHz+wetter
Bekomme ich leider auch:
2014.02.05 07:00:50 0: ERROR: Cannot autoload LaCrosse
2014.02.05 07:00:50 3: JLLaCR: Unknown code OK 9 212 129 4 154 106, help me!
2014.02.05 07:00:54 0: ERROR: Cannot autoload LaCrosse
2014.02.05 07:00:54 3: JLLaCR: Unknown code OK 9 212 129 4 155 106, help me!
2014.02.05 07:00:59 0: ERROR: Cannot autoload LaCrosse
2014.02.05 07:00:59 3: JLLaCR: Unknown code OK 9 212 129 4 156 106, help me!
2014.02.05 07:01:03 0: ERROR: Cannot autoload LaCrosse
2014.02.05 07:01:03 3: JLLaCR: Unknown code OK 9 212 129 4 156 106, help me!
2014.02.05 07:01:07 0: ERROR: Cannot autoload LaCrosse
2014.02.05 07:01:07 3: JLLaCR: Unknown code OK 9 212 129 4 157 106, help me!
Kann ich da was machen?
bei dir wird das LaCrosse modul nicht geladen.
was passiert wenn du ein 'reload 36_LaCrosse' eingibst? was steht dann im log?
welche fhem version hat du installiert?
was liefert 'version' ?
gruss
andre
# $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $
# $Id: 01_FHEMWEB.pm 3963 2013-09-26 08:55:32Z martinp876 $
# $Id: 92_FileLog.pm 3759 2013-08-21 08:13:08Z rudolfkoenig $
# $Id: 36_JeeLink.pm 3914 2013-09-16 13:35:50Z justme1968 $
# $Id: 99_SUNRISE_EL.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 99_Utils.pm 3595 2013-08-05 05:38:48Z tobiasfaust $
# $Id: 98_autocreate.pm 3957 2013-09-25 06:21:02Z rudolfkoenig $
# $Id: 91_eventTypes.pm 2982 2013-03-24 17:47:28Z rudolfkoenig $
# $Id: 91_notify.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
# $Id: 98_telnet.pm 3738 2013-08-18 14:13:59Z rudolfkoenig $
-
Can't read ./FHEM/36_LaCrosse.pm: No such file or directory
deine fhem version ist uralt. da gab es noch kein LaCrosse modul.
du solltest ein update machen.
gruss
andre
Super Update gemacht danke.
2014.02.05 13:51:21 3: LaCrosse Unknown device 08, please define it
Was muss ich nun tun ?
ZitatWas muss ich nun tun ?
Hast du schon mal die Suchfunktion benutzt oder in die Commandref geschaut? :-\
Such Funktion "LaCrosse Unknown device" bringt einiges.
Gruss
Billy
Hallo in der Runde,
ich habe ein wohl ein typisches Anfägnerproblem.
Mein Jeelink erscheint disconnected.
Das habe ich gemacht:
Jeelink mit 868 Mhz von Jeelabs
An den PC eingesteckt und die Treiberinstallation abgewartet
Dann Arduino runtergeladen und installiert von hier: http://arduino.cc/en/Main/Software
Den Sketch für den Jeelink gezogen (Version 09 von hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/)
Arduino gestartet und den Sketch geöffnet
Die Einstellungen im Arduino unter Tools-> Board -> Arduino Uno und Serial Port Com 03
Das ganze dann per Upload von den Stick
An die PI
dann in FHEM definiert mit: define JLLaCR JeeLink /dev/ttyUSB1@57600 (habe noch einen Cul dran)
Die beiden pm's eingefügt aus diesem Thread, letzte Version
Der blinkt nun auch wunderbar an der Raspberry nur ich bekomme diese Anzeige:
State: disconnected
An dieser Stelle ist nix geändert:
Zitat# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
Müsste also brav suchen und finden.
der usb autocreate greift nicht für den jeelink. den musst du von hand richtig konfigurieren.
schau mal mit dmesg nach welches usb device es wirklich ist. also jeelink raus und rein und schauen was dmesg sagt.
gruss
andre
Mit gestecktem Jeelink
Zitat3.634718] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[ 3.651733] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber
Zitat3.479612] usb 1-1.3: new full-speed USB device number 5 using dwc_otg
[ 3.634718] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[ 3.651733] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 3.669415] usb 1-1.3: Product: FT232R USB UART
[ 3.675612] usb 1-1.3: Manufacturer: FTDI
[ 3.697179] usb 1-1.3: SerialNumber: AM01YSF8
gezogenem
Zitatusb 1-1.3: USB disconnect, device number 5
[ 212.258839] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 212.258980] ftdi_sio 1-1.3:1.0: device disconnected
dein jeelink war auf ttyUSB0. nicht 1.
gruss
andre
Fürchte, dann brauche ich wohl ein Workaround damit der Stick sich nicht auf 0 sondern auf 1 anmeldet. Der weigert sich beharlich sich mit 1 anzumelden...
Und warum ist dir das so wichtig? Er nimmt den ersten freien, und da auf 0 bei dir nichts anderes hängt, nimmt er den?
Natürlich kann man über UDEV einen fixen Einhängepunkt vergeben....
Gesendet von meinem Xperia Pro mit Tapatalk
Auf 0 hängt der Cull, dann kommen die sich in die Quere ;) Abgesehen davon ist der Jeelink dann disconnected, was ja dann Sinn macht.
wenn im log steht das der jeelink auf 0 war dann war er es auch und nicht der cul.
entweder du konfigurierst dir per udev das jeelink und cul feste devices bekommen oder du steckst alles an, schaltest ein mal komplett aus und wieder an und schaust dir die reihenfolge an dir dabei raus kommt und verwendest diese.
gruss
andre
Danke, dein Tipp hat gefruchtet.
Als Alternativen, wenn man mehrere USB-Geräte hat:
1. Wie oben vorgeschlagen per udev-Regel
2. anstatt /dev/ttyXX über /dev/serial/by-id/... gehen
Das 2. ist mein Favorit. z.B. sieht mein System mit 2 CUL und 1 JeelLink wie folgt aus:
hedwig ~ # ls -1 /dev/serial/by-id/
usb-FTDI_FT232R_USB_UART_A702GD6P-if00-port0
usb-busware.de_CUL433-if00
usb-busware.de_CUL868-if00
Entsprechend "einfach" und Definiert können dann die Geräte in fhem angemeldet werden.
Einziger Nachteil:
"usb autocreate" erkennt nicht, das solche Geräte schon mal angemeldet wurde. Lösung: Abschalten ;o)
Hallo!
Ich bin am überlegen mir noch einen JeeLink für die Tx Temperatursensoren zu bestellen.
Wie ich gesehen hab gibt es ja eine Menge verschiedener Sensoren zu relativ günstigen Preisen. Ich hab da 2 Fragen dazu.
- Gibt es irgendwo eine List welche unterstützt werden?
- Im ersten post steht das es 868er Sensoren sind. Hab nach den Sensoren gegooglt und bin auf diese Seite gekommen. https://www.lacrossetechnology.com/sensors.php#915 Da stehen die Sensoren und 915Mhz.
Grüße
die 915mhz sind die für amerika.
gruss
andre
Hallo,
ich habe seit einiger Zeit (Dank Fhem und diesem Forum) 2 Technoline TX 29 DT-HT in unseren Bädern installiert. Die Sensoren laufen sehr stabil. Die Außentemperatur versuche ich mit einem TX40-IT zu empfangen. Hier habe ich die schon früher geschilderten Aussetzer. Heute bei durchschnittlich 5°C ab und an 21,5 °C.
Der Sketch auf dem Jeelink ist aktuell.
Meine Config:
define T_EG LaCrosse XX
attr T_EG event-min-interval temperature:300
attr T_EG event-on-update-reading temperature
attr T_EG filterThreshold 5
Funktioniert der FilterThreshold auch, wenn das Device mehrere Fehlwerte hintereinander sendet?
Die besten Grüße aus dem Norden
Ich hab jetzt diesen Thread nach funktionierenden Sensoren durchsucht. Könnten da ein paar Leute drüber schauen und schreiben welche 100%ig funktionieren? Dann such ich alle Einzelheiten raus und stell das dann ins Wiki.
Zitattx25-it
tx27-it
tx29 it
tx34-it
tx27 th
tx29 dth
tx35 dth
tx37 it
WS9160-IT
TFA Dostmann IT Serie (http://tfa-dostmann.de/index.php?id=117)
Grüße
Hat jemand den hier: http://www.elv.de/technoline-windsensor-tx-56-fuer-die-wetterstation-ws2800.html ausprobiert?
Hallo Leute,
wie sieht es bei euch mit der Reichweite aus?
Im selben Raum kein Problem 2 Räume weiter kein Signal.
Was kann ich da tun?
Hallo QuesT,
meine beiden TX 29 DT-HT senden sauber durch eine Betondecke (mit meinem WLAN habe ich hier Probleme). Der TX40-IT ist eher unzuverlässig.
Gruss
an alle mit empfangsproblemen: habt ihr dir antennenlänge des jeelink angepasst?
bei auslieferung ist die antenne länger als es für die 868mhz richtig ist.
gruss
andre
Daran wollte ich erst was ändern, wenn's Probleme gibt ;)
Wielange soll den die Antenne sein?
Gesendet von meinem GT-I9505 mit Tapatalk
17,3 cm bei 868 Mhz
ohne löten kann man nur abschneiden. und da wäre die richtige länge dann 1/4 wellenlänge statt 1/2. also 8,6cm.
wenn du unter anderem aber hier schaust: https://code.google.com/p/panstamp/wiki/antennalengths (https://code.google.com/p/panstamp/wiki/antennalengths) ist aus aus physikalischen gründen kürzer. 82,6cm scheint der richtige wert zu sein.
gruss
andre
Der Draht ist def. kürzer.
Ich verwende den Jeelink im Dachgeschoss für den Empfang von 14 Sensoren verteilt über das komplette Haus (3 Etagen) inkl. Sensor im Garten mit der Originalantenne und habe keinerlei Empfangsprobleme.
Gruß,
Gero
Hat jemand von Euch schon mal sich an das Maximum der möglichen Temperatursensoren herangetestet?
Momentan verwende ich 10 Sensoren; plane aber etwa weitere 10-15 Stück in Haus und Garten zu installieren. Kann es hier zu Problemen - auch mit HomeMatic, PCA301 oder FS20 - kommen?
Komisch bei mir geht's schon eine Raum weiter nicht.
Gesendet von meinem GT-I9505 mit Tapatalk
Vielleicht liegt es am Sensor? Mit den TX29DTH-IT habe ich keinerlei Probleme.
Gruß,
Gero
Hallo zusammen,
ich habe auch gerade die Module zum Laufen gebracht, allerdings mit einer alternativen Hardware: statt eines Jeelinks habe ich einen Arduino Nano mit einem RFM12-Funkmodul (z.B. von Pollin) verbunden. Verbindungen entsprechend der Jeelink-Doku auf JeeLabs.org:
- RFM12-Anschluß SDO -> Arduino Nano-Pin D12/MISO
- nIRQ -> Pin D2
- nSEL -> Pin D10
- SCK -> Pin D13/SCK
- SDI -> Pin D11/MOSI
- GND -> Pin GND
- VDD -> Pin 5V
Dann noch eine einfache Drahtantenne, fertig!
Die Software-Installation erfolgt dann exakt nach den Hinweisen hier im Tread bzw. im FHEMWIKI, keine Besonderheiten zu beachten.
Der Charme dieser HW-Lösung: im Vergleich zum Jeelink günstiger. :D
Danke Euch Programmierern für die tolle Arbeit!
Gruß
Jens
@Jens: Sehr interessanter Ansatz. Kostet also in etwa gut die Hälfte des Jeelinks. Hast Du mal ein Foto von dem Aufbau?
@Alex8508:
Ja, habe es in einen neuen Thread gestellt: http://forum.fhem.de/index.php/topic,20181.0.html
Hallo,
bisher hat mein Jeelink tadellos funktioniert. Nun habe ich heute ein Update von FHEM gemacht und seitdem steht der Jeelink auf disconnected.
Hat hier jemand eine Idee?
Ein lsusb in der Fritzbox zeigt ihn leider auch nicht mehr an. In der Fritzbox-Weboberfläche erscheint aber ein unbekanntes USB-Gerät wie vorher auch. Fernanschluss ist deaktiviert.
Gruß
Christian
gelöst: ein Neustart der Fritzbox hat das Problem behoben!
Für die Entwickler: Vielleicht hat jemand hierfür eine Idee?
Würde gerne Temperaturwerte für IT+ "versenden", anstatt sie zu empfangen.
http://forum.fhem.de/index.php/topic,20319.0.html
Edit: Rechtschreibfehler
Sollte mit dem Jeenode kein Problem sein.
Zitat von: fhainz am 10 Februar 2014, 22:25:20
Ich hab jetzt diesen Thread nach funktionierenden Sensoren durchsucht. Könnten da ein paar Leute drüber schauen und schreiben welche 100%ig funktionieren? Dann such ich alle Einzelheiten raus und stell das dann ins Wiki.
Grüße
Würde diesen Beitrag gerne nochmal aufgreifen, da es sowohl für mich als auch sicherlich für alle anderen, die auf diesen Thread stoßen, ziemlich mühselig ist, herauszufinden welche Sensoren jetzt eigentlich gehen oder nicht ...
Daher hier die ersten Infos:
- TFA Dostmann 30.3187.IT GEHT! (allerdings offensichtlich nur 1x)
Ich hab mir 2x 30.3187 gekauft, wovon ich allerdings nur einen verwenden kann, da diese offensichtlich keine "unique-ID" besitzen. Wenn beide Sensoren aktiv sind, werde alle Daten so interpretiert als würde es sich um ein Gerät handeln.
-TFA Dostmann 30.3180.IT GEHT NICHT!
Ich habe insgesamt 6 von diesen Sensoren (jeder funktioniert und wird von der orig. Wetterstation fehlerfrei angezeigt). Im FHEM werden diese jedoch nicht erkannt. Selbst mit verbose 5 werden keine Informationen zu diesen Sensoren angezeigt. Wäre (da ich ja 6 davon habe) sehr daran interessiert, diese vllt doch noch zum laufen zu bringen und möchte mich auch gerne dazu einbringen...
Die Verallgemeinerung, dass alle IT+ Sensoren von TFA gehen, kann ich (zumindest vorerst) nicht bestätigen. Die Erstellung einer Liste mit allen funktionierender Sensoren ist aus meiner Sicht überaus hilfreich und sinnvoll :)
Gruß,
La_Si_Hong
Ich habe drei TX29DTH-IT problemlos im Einsatz. Laufen seit drei Wochen problemlos und die Reichweite ist tadellos (Server im Keller, TX29DTH-IT im 1. OG wird empfangen)
Von meinen zwei TX35DTH-IT empfange ich absolut nichts.
Ich habe 2* TX29DTH-IT die funktionieren. Meine 2* TX35DTH-IT empfange ich nur weil ich die Checksummenprüfung im Jeelink Sketch ausgeschaltet habe. Diese würde ich also nicht auf die Liste schreiben.
Zitat von: brocky am 16 Februar 2014, 21:23:52
Ich habe 2* TX29DTH-IT die funktionieren. Meine 2* TX35DTH-IT empfange ich nur weil ich die Checksummenprüfung im Jeelink Sketch ausgeschaltet habe. Diese würde ich also nicht auf die Liste schreiben.
ob man so die 30.3180.IT auch überreden kann? Was hast du dafür genau gemacht? Dann versuch ich das auch einfach mal ;-)
Ich habe im Sketch diese Zeilen auskommentiert:
// if (crc8(data, 4) != data[MSG_CRC_OFFSET]) {
// if (DEBUG) { Serial.println("## CRC FAIL ##"); }
// return -1;
// }
Cool, danke!
ich werds so schnell wie möglich ausprobieren (hoffentlich morgen).
Da das mit dem CRC deaktivieren funktioniert, könnte das bedeuten, dass noch ein kleiner Käfer im code ist, und man evtl noch viele Sensoren ans laufen bekommen könnte die aktuell noch nicht gehen ... klingt auf jeden sehr vielversprechend ;-)
gruß
Ich glaube nicht das das ein Fehler ist, sondern das die Berechnung der Checksumme variiert.
ich habe auch einen Sensor, der nicht empfangen werden kann. Vielleicht sollten wir einen Mode kreieren, der es uns erlaubt, auch solche RAM Meldung zu loggen...
Gesendet von meinem Xperia Pro mit Tapatalk
Wenn einfach ein anderer crc berechnet wird (startwert oder polygon) könnte man auch einfach bei fehlschlag des std crc eine oder mehrere else Zweige mit alternativen polygonen anbieten
Bedeutet "kann man" in dem Fall, dass du das kannst, oder müssen, wir dazu erst einen Programmierer finden?
Schon wäre auch, wenn gleich eine Versionsubertragung der Firmwareversion implementiert werden würde. Nach x Monaten bin ich mir nicht mehr ganz sicher, ob ich die aktuellste FW drauf habe ;-).
Die PCA301 Firmware hat so eine Versionsübertragung.
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: JoeALLb am 17 Februar 2014, 06:32:58
Bedeutet "kann man" in dem Fall, dass du das kannst, oder müssen, wir dazu erst einen Programmierer finden?
Schon wäre auch, wenn gleich eine Versionsubertragung der Firmwareversion implementiert werden würde. Nach x Monaten bin ich mir nicht mehr ganz sicher, ob ich die aktuellste FW drauf habe ;-).
Die PCA301 Firmware hat so eine Versionsübertragung.
Gesendet von meinem Xperia Pro mit Tapatalk
"kann man" würde in diesem Fall tatsächlich bedeuten, dass ich das können müsste... Ich muss nur Zeit dafür finden:-/
Falls ich etwas beitragen kann, dann helfe ich auch gerne mit. Der Sketch ist ja in C, das kann ich. Vielleicht kann ich ja mit meinen TX35DTH mal experimentieren. Ich warte gerade noch auf den zweiten JeeLink, da ich mein "Produktiv-System" nicht stoppen will.
Ich könnte das ziemlich schnell integrieren. Ihr müsstet nur heraus finden wodurch sich die Berechnung unterscheidet.
In meiner Firmware habe ich einen Schalter integriert der den crc Check überspringt.
http://forum.fhem.de/index.php/topic,17697.0.html
Ich kann euch heute abends mehr Details geben.
Hallo Ulli,
habe deinen verlinkten thread gelesen und verstehe ihn leider nicht ganz. sollten wir unsere jeelinks dann besser mit deiner firmware flashen?
Bräuchte ich dann, wenn ich PCA301 und die IT+ Thermostate im 868er betreibe, nur noch einen JeeLink?
Guten Abend,
also empfangen tut der JeeLink was vom 30.3180.IT. Zumindest seh ich bei aktiviertem debug, dass Daten kommen. Diese sind aber sowohl was CRC als auch Header angeht nicht in der Form wie es der sketch erwarten würde ... mal guggen ob ich mit meinen begrenzten Fähigkeiten da was ermitteln kann ...
gerne könnte ich aber mal einen Log des Serial Monitors posten; dann könnten die Profies mal nen blick drauf werfen ;-)
Mach doch mal, schadet nichts! Wenn du mir sagst, wie das geht, hänge ich meinen Sensor, der nicht mag, auch mal dran.
Du hängst deinen JeeLink an den PC (idealerweise genau der PC mit dem du auch schon den sketch geflashed hast) und machst in der Arduino IDE den Sketch auf. Dort änderst du
#define DEBUG 0 zu #define DEBUG 1
und uploadest das ganze.
Dann den Serial Monitor in der Arduino IDE aktivieren (Tools -> Serial Monitor) und schon gehts los ;-)
Guten Abend,
ich hab mal, auf Basis des LaCrosseITPlusReader09.zip (hier aus diesem Thread), eine qick'N'dirty Version 0A erstellt welche die Größen-Info des "Headers" nutzt. Außerdem habe ich die Anwendung des CRC leicht angepasst.
@ Brocky: vllt kannst du damit ja deine TX35DTH-IT überreden auch mit CRC zu laufen.
Bei meinen 30.3180.IT bin ich mir jetzt relativ sicher, dass diese nicht gehen ... Das was ich anfangs dachte zu empfangen, bekomme ich auch dann rein, wenn alle meine 30.3180.IT ohne Batterien sind (scheint also vom Nachbarn, Störungen oder sonst was zu sein). Vllt packts mich ja die Tage nochmal und ich versuchs mit den Freunden nochmal *g*
Grüße
Hallo,
ich habe die 0A-Version von La_Si_Hong mit meinem TX35DTH-IT ausprobiert. Funktioniert leider auch nicht... Ich vermute, ähnliche CRC fails wie bisher...
Mit eingeschaltetem DEBUG sieht man im LOG:
2014.02.17 22:44:52 5: JeeLink/RAW: /End
2014.02.17 22:44:52 5: JeeLink/RAW: End /receiving, HEX raw data: 60 F1
2014.02.17 22:44:52 5: JeeLink/RAW: End receiving, HEX raw data: 60 F1/ EB 7C
Number of received B
2014.02.17 22:44:52 5: jeelink1 dispatch data: 28 F1 EB 7C
2014.02.17 22:44:52 3: jeelink1: Unknown code data: 28 F1 EB 7C , help me!
2014.02.17 22:44:52 5: JeeLink/RAW: Number of received B/ytes: 4
## CRC FAIL ##
2014.02.17 22:44:52 5: jeelink1 dispatch Bytes: 4
2014.02.17 22:44:52 3: jeelink1: Unknown code Bytes: 4, help me!
2014.02.17 22:44:52 5: jeelink1 dispatch ## CRC FAIL ##
2014.02.17 22:44:52 3: jeelink1: Unknown code ## CRC FAIL ##, help me!
2014.02.17 22:44:52 5: JeeLink/RAW: /Start receiving
2014.02.17 22:44:52 5: jeelink1 dispatch Start receiving
2014.02.17 22:44:52 3: jeelink1: Unknown code Start receiving, help me!
2014.02.17 22:47:10 5: JeeLink/RAW: /End re
2014.02.17 22:47:10 5: JeeLink/RAW: End re/ceiving, HEX raw data: BF FF
2014.02.17 22:47:10 5: JeeLink/RAW: End receiving, HEX raw data: BF FF /B7 FC DF 7F
Number of recei
2014.02.17 22:47:10 5: jeelink1 dispatch DF 7F
2014.02.17 22:47:10 3: jeelink1: Unknown code DF 7F , help me!
2014.02.17 22:47:10 5: JeeLink/RAW: Number of recei/ved Bytes: 6
## CRC FAIL ##
2014.02.17 22:47:10 5: jeelink1 dispatch Bytes: 6
2014.02.17 22:47:10 3: jeelink1: Unknown code Bytes: 6, help me!
2014.02.17 22:47:10 5: jeelink1 dispatch ## CRC FAIL ##
2014.02.17 22:47:10 3: jeelink1: Unknown code ## CRC FAIL ##, help me!
2014.02.17 22:47:10 5: JeeLink/RAW: /Start receiving
2014.02.17 22:47:10 5: jeelink1 dispatch Start receiving
2014.02.17 22:47:10 3: jeelink1: Unknown code Start receiving, help me!
2014.02.17 22:47:25 5: JeeLink/RAW: /End r
2014.02.17 22:47:25 5: JeeLink/RAW: End r/eceiving, HEX raw data: B9 F9
2014.02.17 22:47:25 5: JeeLink/RAW: End receiving, HEX raw data: B9 F9 /5D 6F CF FF
Number of
2014.02.17 22:47:25 5: jeelink1 dispatch F9 5D 6F CF FF
2014.02.17 22:47:25 3: jeelink1: Unknown code F9 5D 6F CF FF , help me!
2014.02.17 22:47:25 5: JeeLink/RAW: Number of/ received Bytes: 6
## CRC FAIL ##
2014.02.17 22:47:25 5: jeelink1 dispatch Bytes: 6
2014.02.17 22:47:25 3: jeelink1: Unknown code Bytes: 6, help me!
2014.02.17 22:47:25 5: jeelink1 dispatch ## CRC FAIL ##
2014.02.17 22:47:25 3: jeelink1: Unknown code ## CRC FAIL ##, help me!
2014.02.17 22:47:25 5: JeeLink/RAW: /Start receiving
2014.02.17 22:47:25 5: jeelink1 dispatch Start receiving
2014.02.17 22:47:25 3: jeelink1: Unknown code Start receiving, help me!
2014.02.17 22:47:27 5: JeeLink/RAW: /End re
2014.02.17 22:47:27 5: JeeLink/RAW: End re/ceiving, HEX raw data: BF BD F
2014.02.17 22:47:27 5: JeeLink/RAW: End receiving, HEX raw data: BF BD F/3 2F 75 FF
Number of receiv
2014.02.17 22:47:27 5: jeelink1 dispatch F3 2F 75 FF
2014.02.17 22:47:27 3: jeelink1: Unknown code F3 2F 75 FF , help me!
2014.02.17 22:47:27 5: JeeLink/RAW: Number of receiv/ed Bytes: 6
## CRC FAIL ##
2014.02.17 22:47:27 5: jeelink1 dispatch Bytes: 6
2014.02.17 22:47:27 3: jeelink1: Unknown code Bytes: 6, help me!
2014.02.17 22:47:27 5: jeelink1 dispatch ## CRC FAIL ##
2014.02.17 22:47:27 3: jeelink1: Unknown code ## CRC FAIL ##, help me!
2014.02.17 22:47:27 5: JeeLink/RAW: /Start receiving
2014.02.17 22:47:27 5: jeelink1 dispatch Start receiving
2014.02.17 22:47:27 3: jeelink1: Unknown code Start receiving, help me!
Streue ich zwischendurch ein "set LaCrossePairForSec" mit entsprechender Sekundenzahl und mit oder ohne "ignore_battery" ein, ist genau für diesen Zeitraum Ruhe im Logfile (überhaupt keine Meldungen)....
Irgendwelche Ideen?
Grüße,
Marko
du könntest das ganze mal ohne FHEM und dafür mit dem serial Monitor der Arduino IDE machen, dann ist da nicht dieser ganze FHEM interpreter sums mit drin ... was sehr interessant ist, ist das mit den pairForSec ... kommen denn dann auch gültige Daten?
OK, hier das ganze aus dem Arduino Monitor:
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
Start receiving
End receiving, HEX raw data: CF 18 21 BC 79 F8 7F
Number of received Bytes: 7
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: CD B 8D 13 D 1D C8
Number of received Bytes: 7
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 9C 86 2E 97 FF
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 63 1F 40 8C
Number of received Bytes: 4
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 24 DC
Number of received Bytes: 2
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 3D 7
Number of received Bytes: 2
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: F
Number of received Bytes: 1
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 7F E0 7F 3C
Number of received Bytes: 4
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 7F EE 71 1F
Number of received Bytes: 4
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 3D BF
Number of received Bytes: 2
## CRC FAIL ##
Start receiving
Das mit dem pairForSec: soweit ich das FHEM-seitig beurteilen kann, kommen keine Daten, es ist einfach "Ruhe"... Wo würde ich denn sehen, ob Daten ankommen? Müsste dann eine "Erfolgsmeldung" im fhem.log sein?
Grüße,
Marko
Kannst du mir noch ein paar von den 5 Bytes großen Paketen a la
Start receiving
End receiving, HEX raw data: 9C 86 2E97 FF
Number of received Bytes: 5
## CRC FAIL##
Aufnehmen? Ist leider nur ein einziger drin. Ich hab da nen Verdacht... Wenn ich recht habe, gehen die 35er morgen
Ok, hier ein paar 5er-Beispiele:
Start receiving
End receiving, HEX raw data: 84 3E B5 DD A8
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 98 BE F C3 CB
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 84 36 41 EF 79
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 97 91 96 A4 F8
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 84 36 9 7C A5
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 8C F6 E6 DA 7
Number of received Bytes: 5
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: 93 39 69 6F 9
Number of received Bytes: 5
## CRC FAIL ##
Und ein Novum: der allererste Wert eben beim Testen im Arduino Monitor war ok... Das hatte ich bisher noch nie:
Start receiving
End receiving, HEX raw data: ED 78 77 9E F0 43 F0 0
Number of received Bytes: 8
OK 9 116 129 5 197 158
Vielleicht hilft ja beides weiter...
Danke im Voraus!
Grüße,
Marko
Zitat von: brocky am 16 Februar 2014, 21:23:52
Ich habe 2* TX29DTH-IT die funktionieren. Meine 2* TX35DTH-IT empfange ich nur weil ich die Checksummenprüfung im Jeelink Sketch ausgeschaltet habe. Diese würde ich also nicht auf die Liste schreiben.
Sind die Daten die du ohne CRC empfangen hast sinnvoll?
Denn aus den Daten die mgenzel gepostet hat, werd ich nicht so richtig schlau ... zumal selbst bei Paketen die mit der "korrekten 9" beginnen würde, weder eine einheitliche ID noch sonst was sinniges zu erkennen ist (wenn man das Frame zugrundelegt was im aktuellen sketch verwendet wird).
@mgenzel: wenn du Zeit und Lust hast könntest du nochmal so einen Log der Daten mit der Arduino IDE machen, allerdings mit der original 09er Firmware und ohne zu filtern (also einfach alles) und idealerweise etwas länger. Kannst es ja als *txt anhängen.
Bei meiner heutigen Recherche habe ich außerdem herausgefunden, dass IT+ nicht gleich IT+ ist. Der Frame (das Aussehen der Daten) und sogar die Größe des Frames kann sich unterscheiden ( wir haben ja auch schon gelernt, dass manche Sensoren die ID beim Batteriewechsel ändern und andere nicht). Man müsste also für jeden weiteren Sensoren, der mit dem jeelink empfangbar sein soll, die Frames rausfinden.
gruß
@La_Si_Hong: Ich bin auf die offizielle 09-er Version gegangen, habe einzig DEBUG auf 1 gesetzt im Arduino-Code. Nachdem da immer noch nichts sinnvolles rauskam, habe ich die Batterien aus dem tx335-DTH-IT rausgenommen und es kamen immer noch meldungen auf der arduino-Serial-console (immer 5-Byte-Patterns) in regelmäßigen Abständen... Dann habe ich nochmal intensiv nachgedacht, ob ich noch irgendwelche 868MHz-Störquellen habe und mir fiel noch der Hörmann-Garagenantrieb ein. Also auch da den Stecker gezogen und die Batterien aus der Garagenfernbedienung raus. Dann sind da immer noch 5-Byte-Patterns, nicht mehr ganz so oft wie vorher (also vielleicht waren da ein paar Hörmann 5-Byte-Pattern dabei?), aber immer noch 5-Byte-Traffic, den ich mir nicht erklären kann....
Will sagen: die für dich verwirrenden 5-Byte-Muster kommen höchstwahrscheinlich nicht vondem TX35DTH, sondern irgendwo anders her. Nur ich kann mir aktuell nicht erklären, wo die her kommen, außer vom Nachbarn. Alle meine Funkquellen sind abgeklemmt...
Any ideas?
Zitat von: La_Si_Hong am 18 Februar 2014, 21:59:49
Sind die Daten die du ohne CRC empfangen hast sinnvoll?
Ja die Daten sind sinnvoll.
@mgenzel: Das deckt sich mit meinen Erfahrungen. Ich empfange nichts von meinen TX35DTH.
Das Problem scheint folgendes zu sein:
TX29DTH-IT: 17.241 kbit/s
TX35DHT-IT: 9.579 kbit/s
Der Sketch initialisiert den RFM12 auf 17.241 kbit/s darum funktioniert der 29er aber der 35er wohl nicht.
Wenn ich morgen dazu komme, dann probiere ich es mal mit einer geänderten Datenrate, also rf12_xfer(0xC623); falls ich richtig gerechnet habe.
Zitat von: HCS am 18 Februar 2014, 23:23:15
@mgenzel: Das deckt sich mit meinen Erfahrungen. Ich empfange nichts von meinen TX35DTH.
Das Problem scheint folgendes zu sein:
TX29DTH-IT: 17.241 kbit/s
TX35DHT-IT: 9.579 kbit/s
Der Sketch initialisiert den RFM12 auf 17.241 kbit/s darum funktioniert der 29er aber der 35er wohl nicht.
Wenn ich morgen dazu komme, dann probiere ich es mal mit einer geänderten Datenrate, also rf12_xfer(0xC623); falls ich richtig gerechnet habe.
Meinst Du das hier? http://www.seegel-systeme.de/index.php?page=funkthermometer-tx-29-it
Zitat von: mgenzel am 18 Februar 2014, 23:36:19
Meinst Du das hier? http://www.seegel-systeme.de/index.php?page=funkthermometer-tx-29-it
Ja
Mit 9.579 kbit/s funktionieren die TX35DTH-IT beide einwandfrei, die TX29DTH-IT natürlich nicht mehr.
Events:
2014-02-19 08:28:06 LaCrosse LaCrosse_50 temperature: 21.6
2014-02-19 08:28:06 LaCrosse LaCrosse_50 humidity: 57
2014-02-19 08:28:06 LaCrosse LaCrosse_50 battery: ok
2014-02-19 08:28:07 LaCrosse LaCrosse_34 temperature: 21.8
2014-02-19 08:28:07 LaCrosse LaCrosse_34 humidity: 56
2014-02-19 08:28:07 LaCrosse LaCrosse_34 battery: ok
2014-02-19 08:28:11 LaCrosse LaCrosse_50 temperature: 21.6
2014-02-19 08:28:11 LaCrosse LaCrosse_50 humidity: 56
2014-02-19 08:28:11 LaCrosse LaCrosse_50 T: 21.6 H: 56
2014-02-19 08:28:11 LaCrosse LaCrosse_50 battery: ok
2014-02-19 08:28:12 LaCrosse LaCrosse_34 temperature: 21.8
2014-02-19 08:28:12 LaCrosse LaCrosse_34 humidity: 56
2014-02-19 08:28:12 LaCrosse LaCrosse_34 battery: ok
JaJa, es ist zu warm, habe gerade die Heizung runtergedreht ;D
Was mich nun wundert ist, wie brocky sinnvolle Daten empfängt. Entweder gibt es auch TX35DTH-IT mit 17.241 kbit/s oder das waren nicht die TX35.
Jetzt könnte ja mal jeder, der Sensoren hat, die nicht empfangen werden, mit 9.579 kbit/s versuchen. Evtl. ist es ja bei den TFA Sensoren auch so.
Zitat von: HCS am 19 Februar 2014, 08:43:23
Mit 9.579 kbit/s funktionieren die TX35DTH-IT beide einwandfrei, die TX29DTH-IT natürlich nicht mehr.
Jetzt könnte ja mal jeder, der Sensoren hat, die nicht empfangen werden, mit 9.579 kbit/s versuchen. Evtl. ist es ja bei den TFA Sensoren auch so.
Was muss ich wo ändern, um die Datenrate auf 9.579 kbit/s zu setzen?
Im Sketch in der Methode rf12_la_init()
rf12_xfer(0xC613); // c613 DATA RATE c613 17.241 kbps
ändern in
rf12_xfer(0xC623); // C613=17.241 kbit/s C623=9.579 kbit/s
Die Änderung des Kommentars kann man sich natürlich auch schenken.
OK, das geht bei mir auch! Kann also bestätigen, dass der TX35DTH-IT mit 9.579 kbit/s im sketch version 09 läuft!
2014-02-19_09:25:29 LaCrosse_30 temperature: 5.8
2014-02-19_09:25:29 LaCrosse_30 humidity: 94
2014-02-19_09:25:29 LaCrosse_30 T: 5.8 H: 94
2014-02-19_09:25:29 LaCrosse_30 battery: ok
Danke für Deine Hilfe!
Prima.
Ich habe gerade einen Sketch getestet, der abwechselnd mit 17.241 kbit/s und 9.579 kbit/s empfängt. Das klappt so weit, ich bekomme Daten von meinen drei TX29 und den beiden TX35.
Muss mich aber noch um das Timeout Problem kümmern, wenn eine Sorte Sensoren nicht mehr sendet, dann dauert es deutlich zu lange, bis wieder empfangen wird.
Bei dieser Taktik verpasst man allerdings einige Aussendungen, was bei sich langsam ändernden Temperaturen nicht so schlimm ist. Eventuell ist es sinnvoller, für die beiden Datenraten jeweils einen eigenen JeeLink zu verwenden, wenn man 29er und 35er gemischt hat.
wenn ihr in den sketch einbaut das man konfigurieren kann welche datenrate verwendet werden soll und ob dazwischen gewechselt werden soll baue ich das uns fhem modul ein.
gruss
anfre
Hat von Euch schon mal jemand den Technoline TX62-IT mit Solarmodul getestet? Funktioniert dieser mit FHEM?
Wird dieser Sketch eigentlich "offiziell" gepflegt, d.h. im SVN von JeeLink zu finden sein?
im svn gibt es den aktuellen sketch. wenn das umschalten der datenrate funktioniert checke ich es mit dem angepassten fhem modul ein.
gruss
andre
Jetzt Frage ich mich warum ich Daten von beiden Sensoren Typen empfange. Wenn ich am Wochenende zu Hause bin werde ich mal ein paar Daten posten.
Gesendet von meinem GT-I9000 mit Tapatalk
Sehr cool, dass das mit den TX35er geht ...
zur Umschalterrei:
Man könnte in die RX Methode einen HW-Timer aufziehen / oder eine variable laufen lassen der/die nach Überlauf (es wurden keine Daten empfangen) das busy-Wait beendet und dann zurück in die main schleife kehrt um mit der jeweils anderen Bitrate fortzufahren ....
Ich bin der Meinung es dem User in fhem zu überlassen wie wichtig welche Signale sind und wie oft diese abgerufen werden sollen.
Ich habe das so für meinen jeenode gelöst.
Mein jeenode ist für den Empfang von fs20 Signalen konfiguriert. Über fhem Stelle ich meinen jeenode jede halbe Stunde auf lacross Empfang um und nach Empfang der Temperatur Signale wieder zurück.
So habe ich die maximale die Flexibilität
Zitat von: justme1968 am 19 Februar 2014, 10:09:48
im svn gibt es den aktuellen sketch. wenn das umschalten der datenrate funktioniert checke ich es mit dem angepassten fhem modul ein.
gruss
andre
Da beginnt das Problem. Als FHEM DAU habe ich leider keine Ahnung, was ich im Sketch einbauen muss, dass man von FHEM aus Einstellungen ändern kann. Würde FHEM dann auf der Seriellen Kommandos schicken, was gesetzt werden soll?
Ich versuche das jetzt erst mal generell vernünftig zu realisieren (also aus meinen Experimenten geistreichen Code machen :) ). Werde aber vermutlich erst am Wochenende weiter machen können. Dann können wir ja mal schauen, wie das mit der Konfiguration geht.
Wie auch immer, es hat sich zumindest ein Weg aufgetan.
Zitat von: ulli am 19 Februar 2014, 11:00:45
Ich bin der Meinung es dem User in fhem zu überlassen wie wichtig welche Signale sind und wie oft diese abgerufen werden sollen.
Ich habe das so für meinen jeenode gelöst.
Mein jeenode ist für den Empfang von fs20 Signalen konfiguriert. Über fhem Stelle ich meinen jeenode jede halbe Stunde auf lacross Empfang um und nach Empfang der Temperatur Signale wieder zurück.
So habe ich die maximale die Flexibilität
Ja, das erscheint mir sinnvoll zu sein.
Hast Du irgend ein Beispiel für mich, wie fhem mit den JeeNode spricht?
Anbei eine Test-Version vom Sketch.
Alle Änderungen sind in //// HCS geklammert
Per define kann die data rate umgestellt werden und das alternierende Empfangen mit den beiden data rates eingeschaltet werden.
//// HCS
#define DATA_RATE_17 0xC613 // 17.241 kbps for TX29DTH-IT
#define DATA_RATE_9 0xC623 // 9.579 kbps for TX35DTH-IT
#define DATA_RATE DATA_RATE_17 // use one of the data rates defined above
// VERY EXPERIMENTAL That's really not the final solution
// and as ulli told, FHEM should set the data rate to be more flexible
#define TOGGLE_DATA_RATE 0 // Set to 1 to alternate between 17.241 kbps and 9.579 kbps after each receive
static bool data_rate_toggler;
//// HCS
Das ist so nicht der gewünschte Endausbau, aber wer möchte kann ja mal damit seine bisher ungesehenen Sensoren probieren.
Meine drei TX29DTH-IT und die zwei TX35DTH-IT habe ich so zumindest mal provisorisch im Griff
ich hab mal schnell eine version zusammengepastet die es erlauben müsste das ganze zur laufzeit zu konfigurieren. ist aber völlig ungetestet. ich habe gerade leider weder einen arduino frei noch einen passenden sensor :)
der sketch sollte jeweils '<n> <c>' verstehen. n kann 0 oder 1 sein, <c> kann sein:
q -> debug ein/aus
r -> datenrate umschalten
t -> toggeln ein/aus schalten
v -> version abfragen
alles andere -> hilfe anzeigen
gruss
andre
Super, freue mich.
Könntet ihr, wenn ihr den Sketch Schöne angreift, auch eine Versions abfrage einbauen? Fhem sollte den Jeelink abfragen können, welch FW aktuell installiert ist.
Wie exakt ist diese bitratenabgrenzung? Könnte ein Wert zwischen den beiden eventuell beide Sensoren empfangen?
Frequenzen verstehe ich noch, hat jemand für einen EMV-DAU einen Link, der erklärt, warum die Bitrate so wichtig ist?
Gesendet von meinem Xperia Pro mit Tapatalk
Sorry, überlesen. Vielen Dank!!
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: justme1968 am 19 Februar 2014, 16:02:46
ich hab mal schnell eine version zusammengepastet die es erlauben müsste das ganze zur laufzeit zu konfigurieren. ist aber völlig ungetestet. ich habe gerade leider weder einen arduino frei noch einen passenden sensor :)
Cool. Funktioniert.
Zwei Änderungen habe ich gemacht:
Ich habe q noch umgedreht weil "- quiet mode (1=suppress TX and bad packets)" entspricht !DEBUG
Ich habe die Ausgabe der Version erweitert:
1v liefert nun:
[LaCrosseITPlusReader.10.0b @17.241 kbps]
oder
[LaCrosseITPlusReader.10.0b @9.579 kbps]
oder
[LaCrosseITPlusReader.10.0b @AutoToggle]
Dann muss man nicht raten, welche data rate gerade gesetzt ist.
Anbei die geänderte 10.0b
Die sollte übrigens kompatibel sein, weil wenn man nichts setzt, macht sie nichts anderes als bisher.
Bekommt das JeeLink device in fhem noch "offizielle Parameter"?
wenn mein internet wieder geht schau ich mal wie ich das am besten ins fhem modul bekomme.
gruss
andre
Funktioniert dein Arduino Sketch wirklich zuverlässig.
Du wechselst alle 100ms die Bitrate. Reicht das aus um die Pakete zuverlässig und vollständig zu empfangen?
Produziert das nicht viele defekte Datenpakete?
Zitat von: ulli am 19 Februar 2014, 19:30:28
Funktioniert dein Arduino Sketch wirklich zuverlässig.
Du wechselst alle 100ms die Bitrate. Reicht das aus um die Pakete zuverlässig und vollständig zu empfangen?
Produziert das nicht viele defekte Datenpakete?
Läuft seit einem halben Tag problemlos.
Das ist auch nicht alle 100ms. Die loop läuft ja nicht durch sondern bleibt in der receive stehen, bis 5 byte empfangen wurden oder ein timeout nach langer zeit kommt. Die data rate wird im prinzip immer dann gewechselt, wenn bei DEBUG=1 ein "Start receiving" ausgegeben wird.
Es ist eher das umgekehrte Problem (momentan noch), weil wenn eine Sorte Sensor nie was sendet, kommt man aus der rf12_rxdata ewig lange nicht raus und somit in der loop nicht weiter, was dazu führt, dass nur noch recht selten mal empfangen wird.
Hallo,
danke für den neuen Sketch, habe einen 30.3156WD von TFA, den ich damit jetzt endlich auch einbinden konnte.
Weis eigentlich jemand, ob man die Wetter direkt Daten auch einbinden kann? Werden die vom Aussensender empfangen und an die Wetterstation gesendet oder direkt von der Wetterstation empfangen?
Mit besten Grüßen
Reinhard
Zitat von: ulli am 16 Februar 2014, 15:43:33
Sollte mit dem Jeenode kein Problem sein.
Könnte einer von euch sketch Programmierern sich das mal ansehen?
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: JoeALLb am 19 Februar 2014, 23:10:10
Könnte einer von euch sketch Programmierern sich das mal ansehen?
Gesendet von meinem Xperia Pro mit Tapatalk
Bitte korrigiert mich wenn ich falsch liege (hab nur nen kurzen Blick in den Sketch geworfen):
Theoretisch ist das senden mit dem JeeLink kein Problem (alle notwendige Hardware ist vorhanden) aber mi Sketch selbst finde ich kein TX (Transmit) Routine. Möglicherweise müsste noch die Initialisierung des RFM 12 angepasst werden und ich habe keine Schnittstelle zwischen FHEM und JeeLink gefunden über welche FHEM an den JeeLink (z.B. Rohdaten) übergeben würde um diese zu übertragen.
Aber: Es dürfen kein allzu großen Klimmzüge nötig sein um auch mit dem JeeLink LaCross Sketch zu senden ... machen müsst mans halt ;-)
ich habe keinen passenden enpfämger und keine ahnug wie man den rfm12 zum passenden senden bringt.
wenn jemand den sketch anpassen kann dann bringe ich dem fhem modul das senden bei.
auf sketch seite wäre mir die normale jeelink pca301 syntax am liebsten.
gruss
andre
Zitat von: justme1968 am 20 Februar 2014, 12:27:41
auf sketch seite wäre mir die normale jeelink pca301 syntax am liebsten.
Heißt das, man baut am besten den Sketch des PCA301, der senden ja schon kann, um, ändert die Datenrate, etc.
und versucht damit ein entsprechendes Paket zu senden?
Vielleicht könnte man ja im Sketch erstmal einen Standardwert(hardcodiert?) senden, beispielsweise"19°, 40% Luftfeuchtigkeit."
Dann könnte man den Empfang der Pakete an einer Wetterstation schon mal testen und müsste danach nur noch
das Senden von variablen Werten ergänzen?
das würde ich nicht. im pca sketch ist recht viel pca spezifisches.
nur die syntax für das senden und die sende routine würde ich kopieren. die sollte auch ziemlich dem jeelabs demo sketch entsprechen.
gruss
andre
Wenn ich da meinen Senf dazu geben darf.
Ich hatte am Oliver (oweh) am 12.9.2013 zu dem Thema Jeelink als virtuellen IT+ Sensor angesprochen.
ZitatIch habe da übrigens noch eine Idee die bisher m.e. noch keiner verwirklicht hat.
Nachdem die La Crosse Schnittstelle ja offen liegt, könnte man aus dem Jeelink einen virtuellen IT+ Sensor machen und
beliebige Temperaturen aus FHEM (von anderen Sensoren z.B. 1Wire) auf kostengünstigen IT+ Anzeigen zur Anzeige bringen.
Leider hatte er keine Zeit für die Umsetzung. :-\
Das hätte sicher Scharm. Frage wäre dann auch ob die Temperaturgrenze der IT-Sensoren von +59,9ºC z.B für die Anzeige
dann bis 99° möglich wäre. --> Vorteil für Heizungstechnik ;)
Gruss Billy
Hallo zusammen,
mit meinem Jeelink-Klon und dem Jeelink-Modul habe ich übrigens folgenden Temperatursensor erfolgreich getestet:
IT1 (30.3147.IT) von TFA Dostmann
Weiter viel Erfolg!
Jens
Zitat von: jm-muc am 21 Februar 2014, 19:15:41
mit meinem Jeelink-Klon und dem Jeelink-Modul habe ich übrigens folgenden Temperatursensor erfolgreich getestet:
IT1 (30.3147.IT) von TFA Dostmann
Mit welcher data rate läuft der?
Zitat von: Laffer72 am 19 Februar 2014, 22:41:10
danke für den neuen Sketch, habe einen 30.3156WD von TFA, den ich damit jetzt endlich auch einbinden konnte.
Mit welcher data rate läuft der?
Da schon mehrmals angeregt wurde, eine übersichtliche Sammlung der funktionierenden Sensoren zu erstellen:
Könnte jemand, der ausreichend Rechte hat, das hier in den ersten Beitrag einfügen?
Getestete Sensoren
TX25IT 17.241 kbps
TX27-IT 17.241 kbps
TX29DTH-IT 17.241 kbps
TX35DTH-IT 9.579 kbps
30.3147.IT ? kbps
30.3156WD ? kbps
Zitat von: Billy am 21 Februar 2014, 11:24:37
Wenn ich da meinen Senf dazu geben darf.
Ich hatte am Oliver (oweh) am 12.9.2013 zu dem Thema Jeelink als virtuellen IT+ Sensor angesprochen.
Leider hatte er keine Zeit für die Umsetzung. :-\
Das hätte sicher Scharm. Frage wäre dann auch ob die Temperaturgrenze der IT-Sensoren von +59,9ºC z.B für die Anzeige
dann bis 99° möglich wäre. --> Vorteil für Heizungstechnik ;)
Gruss Billy
Das drängt mir noch einige Fragen auf:
- Von FHEM aus 5 Bytes an den JeeLink schicken und diese dann einfach dort raussenden?
- ID, Temperatur, Feuchte aus FHEM schicken, auf dem JeeLink encoden und senden?
- Pairing mit der Station die es anzeigen soll: wann wie muss das new battery flag gesetzt sein?
Falls ich irgendwo die Zeit finde, schaue ich mir die Senderei generell mal an.
Allerdings juckt es mich auch, mit einem IT+ Windsensor etwas zu probieren. Wollte schon immer mal wissen, woher der Wind weht ;D
ich würde für die liste das wiki vorschlagen.
wie man die aufteilnug fhem/sketch beim senden macht können wir entscheiden wenn das senden überhaupt geht und die displays etwas empfangen. vermutlich würde ich aber dazu tendieren nicht alles auf dem sketch zu machen. in fhem ist flexibler mal etwas am protokoll geändert als den sketch neu zu flashen.
gruss
andre
TX25-IT läuft auch ohne Anpassungen am Sketch.
=> TX-25IT 17.241 kbps
Sprich sketch soll einfach transparent die Daten von FHEM in die Luft blasen?
das wäre der anfang. wenn das geht können wir weiter überlegen.
gruss
andre
Ich hab halt nix zum testen und blind programmieren ist meist eher müßig... Hat denn einer was zum testen und zeit das auch zu tun? So an einem Samstag oder Sonntag ne kleine Session...
Ich habe 2 Jeelink und 2 Wetterstationen, konnte jeweils eine davon zum testen nehmen. Für das battery flag wurde ich ein sendbatteryforsec oder ähnlich vorschlagen.
Eine Wetterstation kann bis zu 3 Sensoren empfangen. Im Endausbau wäre es schön, wenn ich mehrere mit jeweils eigenen IDs aussenden könnte.
Schön wäre auch, wenn der Jeelink keinen unnötigen traffic produziert, sondern nur alle x Minuten.
Gesendet von meinem Xperia Pro mit Tapatalk
@HCS
ZitatDas drängt mir noch einige Fragen auf:
- Pairing mit der Station die es anzeigen soll: wann wie muss das new battery flag gesetzt sein?
Vielleicht hilft der Link weiter: http://gcrnet.net/node/32
Auszug:
Principle is that a channel number is randomly chosen by transmitter upon initialisation. The transmitter will use this channel ID forever, up to the next initialization (battery change). To help pairing, a flag telling the transmitter is in this pairing phase is set during approximately 4h30mn.Gruss
Billy
Da wir aber die Batterie des Jeelink nie wechseln, benötigen wir dafür eine andere Methodik. Ich würde die id vorgeben lassen.
Gesendet von meinem Xperia Pro mit Tapatalk
Sei mir nicht böse, aber ich glaube da liegst du falsch. :'(
ZitatDa wir aber die Batterie des Jeelink nie wechseln,
Stimmt, meiner hat auch keine.
Der Jeelink muss den Sensor so nachbilden, dass die Wetterstation als Anzeige nicht merkt, dass da kein Original
IT+ Sensor funkt! Und dazu gehört m.E. auch dass der Batteriewechsel vorgetäuscht wird indem das entsprechende Flag gesetzt wird. Sonst kannst du nicht mit der Wetterstation pairen.
Ich stelle mir übrigens diese Anzeige vor.
http://www.amazon.de/Technoline-WS-8301-IT-Temperaturstation-aluminium-silber/dp/B00185OGBA
Gruss
Billy
Ja, da bin ich ganz bei dir. Du kannst aber das Batterie flag auch setzen, ohne die id zu verändern. Und nur dann musst du nicht aus allen Wetterstationen die Batterien entfernen, um nach der neuen id zu suchen. Bei mehreren sensoren/Wetterstationen wird das sonst echt kompliziert.
Gesendet von meinem Xperia Pro mit Tapatalk
Seit einem Update bekomme ich immer folgende Meldung ins Log.
Nun gehe ich davon aus,. dass das an einem falsch gesetzten attribut bei einem der Sensoren ist.
Wie kann ich dem auf die schliche kommen? ein verbose hat keine Veränderung gezeigt ;-)
Use of uninitialized value in string ne at ./FHEM/36_LaCrosse.pm line 193.
was kommt bei zurück wenn du das hier eingibst:{ join(",", grep { !defined($defs{$_}{TYPE}) } keys %defs ) }
gruss
andre
Hm, seltsam
Ergebnis:
FileLog_CUL_FHTTK_1fdfdf
Dazu gibt es in der fhem.cfg nur ein SVG
define SVG_CUL_FHTTK_1fdfdf SVG FileLog_CUL_FHTTK_1fdfdf:fht80tf:CURRENT
attr SVG_CUL_FHTTK_1fdfdf label "CUL_FHTTK_1fdfdf Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr SVG_CUL_FHTTK_1fdfdf room Plots
ansonsten kommt dieser String nirgends vor. Was hat das nun mit dem Modul zu tun?
das problem ist nicht wirklich das jeelink modul sondern das du irgendwo ein device hast das keinen TYPE hat. das sollte eigentlich nicht vorkommen.
mach mal ein list auf dein FileLog_CUL_FHTTK_1fdfdf. was steht da bei TYPE?
gruss
andre
Das, also nichts.
kann ich es einfach löchen, ode rkönnte dadurch ein Fehler ausgelöst werden?
fhem> list FileLog_CUL_FHTTK_1fdfdf
Internals:
Attributes:
fhem>
Vielen Dank für die Hilfe, und sorry, aber eben nur diese Modul hat mir den Fehler angezeigt ;-)
in dem zustand kann das device nicht wirklich viel machen. wenn es nach einem neustart immer noch so unvollständig ausschaut versuch es zu löschen.
es scheint ein plot zu sein. eventuell musst du den neu anlegen.
gruss
andre
den restart hat es überlebt, das löschen nicht!
Vielen Dank, jetzt ist wieder Ruhe eingekehrt. Den Plot benötige ich eh nicht mehr, stelle derzeit alle auf DBLog um.
Wie das jedoch passiert ist, kann ich mir nicht erklären, manuell verändert habe ich hier nichts. wie auch immer!
VIELEN Dank! ;D
Hi
mein Jeelink ist richtig geflasht mit diesem Sketch
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip?format=raw (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip?format=raw)
In FHEM eingebunden mit
define JeeLink JeeLink /dev/ttyUSB1@57600
ttyUSB1 ist richtig.
In FHEM wird er mir als Opened angezeigt.
autocreate ist active
Wenn ich jetzt in meinen TX29IT Batterien einlege passiert garnichts.
Muss ich sonst noch etwas machen?
du musst den pairing mode aktivieren. eventue mit ignorieren der batterie.
gruss
andre
Ich nehme mal an mit
set JeeLink 60 ignore_battery
Das habe ich im laufenden betrieb und auch beim einlegen der Batterien versucht.
Leider ohne erfolg
set JeeLink LaCrossePairForSec 60 ignore_battery
gruss
andre
copy past fehler
genau damit habe ich es versucht.
Was sollte der Jeelink denn normalerweise über Serial Monitor ausgeben wenn er richtig funktioniert?
du solltest zeilen mit 'OK 9 ...' sehen.
gruss
andre
Ich bekomme da garnichts angezeigt.
Jetzt ist nur die frage ob der Jeelink spinnt oder der TX29
wenn du im serial monitor am Anfang die folgende Begrüßungsnachricht bekommst:
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
dann hast du zumindest "eine" (natürlich nicht unbedingt die aktuelle *09) LaCrosse JeeLink firmware aufgespielt
Im Serial Monitor kommt nichts.
Ich habe die Firmware von hier
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip
Die ist vom 2013-12-10 sollte somit halbwegs aktuell sein oder ist die doch veraltet?
das ist die letze offizielle version.
entweder stimmt der port nicht oder die baudrate oder es ist beim flashen etwas schief gegangen.
Zitat von: La_Si_Hong am 26 Februar 2014, 17:07:14
wenn du im serial monitor am Anfang die folgende Begrüßungsnachricht bekommst:
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
dann hast du zumindest "eine" (natürlich nicht unbedingt die aktuelle *09) LaCrosse JeeLink firmware aufgespielt
Setzte mal Debug auf 1 im sketch und schau dann im serial monitor, nur dann kommt die Begrüßung.
Ich glaube langsam der jeelink ist Schrott.
Ich habe jetzt mit der beta von IDE geflasht und hatte dann mal ganz kurz was im status monitor aber nach dem erneuten einstecken nichts mehr.
Auch an fhem nichts.
Mittlerweile habe ich 4 verschidene Firmware getestet und überall das selbe.
Die blaue led blink immer mal wieder wenn ich den jeelink einstecken und beim flashen flackert die rote und orange led.
Das flashen bringt auch keine Fehlermeldung.
Nochmal zur Sicherheit
Sketch laden
Arduino UNO und port auswählen
Upload drücken
Wenn fertig serial monitor öffnen
Dann sollte da eine Ausgabe kommen ?!
Wenn debug=1, sonst nur wenn valide Daten empfangen wurden
ZitatIch glaube langsam der jeelink ist Schrott.
Gewagte These ;D
bei mir funktioniert absolut zuverlässig.
Wurde die Bitrate richtig gewählt?
Mit Debug 1 kommt jetzt wenigstens mal was im Serial Monitor
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
Start receiving
End receiving, HEX raw data: FD 98 FF 98 89
## CRC FAIL ##
Start receiving
End receiving, HEX raw data: A6 EC BF F 9D
## CRC FAIL ##
Start receiving
Wobei mir das CRC FAIL nicht gefällt.
Ich hänge ihn jetzt nochmal an FHEM mal schauen was da passiert
Ist ja auch etwas unbekanntes von fremden sendern. ;)
ein
set JeeLink LaCrossePairForSec 50 ignore_battery
bringt mir im eventmonitor
2014-02-26 19:19:46 JeeLink JeeLink LaCrossePairForSec 50 ignore_battery
aber sonst nichts.
EDIT:
Ich hätte mir zwei TX29 Bestellen sollen.
Dann könnte ich den al defekt ausschließen.
EDIT2
Grade mal den Stick usb dem USB Port raus und wieder rein :
2014-02-26 19:37:41 JeeLink JeeLink DISCONNECTED
2014-02-26 19:37:42 JeeLink JeeLink CONNECTED
2014-02-26 19:37:44 JeeLink JeeLink UNKNOWNCODE *** LaCrosse weather station wireless receiver for IT+ sensors ***
2014-02-26 19:37:44 JeeLink JeeLink UNKNOWNCODE Radio setup complete. Starting to receive messages
2014-02-26 19:37:44 JeeLink JeeLink UNKNOWNCODE Start receiving
2014-02-26 19:37:49 JeeLink JeeLink UNKNOWNCODE data: 3C 63 C2 45 B
2014-02-26 19:37:49 JeeLink JeeLink UNKNOWNCODE ## CRC FAIL ##
2014-02-26 19:37:49 JeeLink JeeLink UNKNOWNCODE Start receiving
2014-02-26 19:37:58 JeeLink JeeLink UNKNOWNCODE F5 23 C1 21 68
2014-02-26 19:37:58 JeeLink JeeLink UNKNOWNCODE ## CRC FAIL ##
2014-02-26 19:37:58 JeeLink JeeLink UNKNOWNCODE Start receiving
Lässt sich auch reproduzieren
2014-02-26 19:46:02 JeeLink JeeLink DISCONNECTED
2014-02-26 19:46:05 JeeLink JeeLink CONNECTED
2014-02-26 19:46:07 JeeLink JeeLink UNKNOWNCODE *** LaCrosse weather station wireless receiver for IT+ sensors ***
2014-02-26 19:46:07 JeeLink JeeLink UNKNOWNCODE Radio setup complete. Starting to receive messages
2014-02-26 19:46:07 JeeLink JeeLink UNKNOWNCODE Start receiving
Soll der Dostmann 30.31.56.WD nun funktionieren?
Ich bekomme hier nur CRC Fehler.
Zitat von: rolandm am 26 Februar 2014, 20:04:41
Soll der Dostmann 30.31.56.WD nun funktionieren?
Ich bekomme hier nur CRC Fehler.
Nimm mal den Sketch aus Antwort #349 und setze die data rate auf 9.579 kbps
Die Zeile
int DATA_RATE = DATA_RATE_17;
änern in
int DATA_RATE = DATA_RATE_9;
Eventuell läuft Dein Sensor ja mit 9.579 kbps. Der User, der bestätigt hat, dass dieser Sensor funktioniert, hat leider keine data rate angegeben, mit der er läuft.
Zitat von: Henno am 26 Februar 2014, 19:26:07
ein
set JeeLink LaCrossePairForSec 50 ignore_battery
bringt mir im eventmonitor
2014-02-26 19:19:46 JeeLink JeeLink LaCrossePairForSec 50 ignore_battery
aber sonst nichts.
Solange der JeeLink nicht etwas, das mit OK 9 beginnt, liefert, brauchst Du in fhem nicht weiter probieren.
Nach dem, was Du vom JeeLink bekommst, würde ich mal behaupten, dass er funktioniert.
Kannst ja auch mal mit 9.579 kbps probieren (siehe vorhergehenden Beitrag)
Ich stelle als Bord übrigens nicht Uno sondern "Arduino Mini ATmega328" ein und verwende Version 1.0.5-r2
Ich habe mal eine senden Routine in die Firmware integriert. Meine Wetterstation reagiert aber nicht darauf. Habe einiger Versuche gestartet, funktioniert aber nicht. Ich vermute das liegt irgendwie an meiner Wetterstation.
Versucht man die Firmware.
Einfach drauf flashen und dann das Kommando
F01... absetzen. (... sind die zu sendenden 4 Datenbytes)
--> Es wird dann alle 4 Sekunden das Kommando in einer Endlosschleife gesendet.
z.B. F019224716A
Sagt mir Bescheid ob es bei euch geht!
Zitat von: HCS am 26 Februar 2014, 20:29:24
Nimm mal den Sketch aus Antwort #349 und setze die data rate auf 9.579 kbps
Die Zeile
int DATA_RATE = DATA_RATE_17;
änern in
int DATA_RATE = DATA_RATE_9;
Eventuell läuft Dein Sensor ja mit 9.579 kbps. Der User, der bestätigt hat, dass dieser Sensor funktioniert, hat leider keine data rate angegeben, mit der er läuft.
Ja, DATA_RATE_9 bzw. TOGGLE hab ich ja schon. Der Dostmann geht aber nicht. Vielleicht noch eine andere Datenrate.
Mit dem Arduino Mini ATmega328 hat es jetzt bei mir auch geklappt.
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio setup complete. Starting to receive messages
Start receiving
End receiving, HEX raw data: FF EF 2D 5F CD
Msg does not start with 9, it's: F
Start receiving
allerdings Sendet wohl der TX29 nichts
Zitat von: Henno am 27 Februar 2014, 09:12:49
allerdings Sendet wohl der TX29 nichts
Poste mal einige mehr "HEX raw data" Zeilen, aus einer kann man recht wenig schließen.
Sind die Aussendungen von Deinem Sensor (also nicht mehr da, wenn Du die Batterie raus nimmst)?
Was für ein Sketch ist das denn? Die Meldung "Msg does not start with 9 ..." kommt in meinem so nicht vor.
Zitat von: ulli am 26 Februar 2014, 20:49:32
Ich habe mal eine senden Routine in die Firmware
z.B. F019224716A
Sagt mir Bescheid ob es bei euch geht!
Kanns erst am Wochenende versuchen. Ist die ino Datei auch verfügbar, dann könnte ich mit den Werten spielen...
Gesendet von meinem Xperia Pro mit Tapatalk
@ulli
ZitatIch habe mal eine senden Routine in die Firmware integriert. Meine Wetterstation reagiert aber nicht darauf. Habe einiger Versuche gestartet, funktioniert aber nicht. Ich vermute das liegt irgendwie an meiner Wetterstation.
Geht bei mir auch nicht. :-\
Hast du das new battery flag in deine Senderoutine integriert?
Gruss Billy
Ich habe einige Erweiterungen / Änderungen an dem Sketch vorgenommen.
Activity LED
Die Activity LED kann nun mit dem Befehl 0a aus- und mit 1a wieder eingeschaltet werden
Data rate toggle
Der Wechsel der data rate funktioniert nun so:
0t deaktiviert den toggle
<n>t aktiviert den toggle. Dabei ist <n> die Zeit in Sekunden, wie lange mit einer data rate empfangen wird.
Beispiel: 20t bedeutet: 20s mit 17.241 kbps empfangen, dann 20s mit 9.579 kbps empfangen, dann 20s mit 17.241 kbps empfangen, usw.
Ich habe drei TX29 (ID:16, 48, 56), die mit 17.241 kbps und zwei TX35 (ID: 124, 156), die mit 9.579 kbps arbeiten
Man kann schön die Blöcke erkennen, wann die data rate wechselt.
OK 9 16 1 4 128 63
OK 9 48 1 4 137 61
OK 9 56 1 4 28 73
OK 9 16 1 4 128 63
OK 9 48 1 4 137 61
OK 9 56 1 4 28 73
OK 9 16 1 4 128 63
OK 9 124 1 4 193 47
OK 9 156 1 4 159 58
OK 9 124 1 4 193 46
OK 9 124 1 4 194 46
OK 9 156 1 4 159 58
OK 9 124 1 4 193 46
OK 9 48 1 4 136 61
OK 9 16 1 4 128 63
OK 9 56 1 4 27 73
OK 9 48 1 4 137 61
OK 9 56 1 4 28 73
OK 9 48 1 4 137 61
OK 9 16 1 4 128 63
OK 9 56 1 4 27 73
OK 9 48 1 4 136 61
OK 9 56 1 4 27 73
OK 9 16 1 4 128 63
OK 9 48 1 4 137 61
OK 9 156 1 4 159 58
OK 9 124 1 4 193 46
OK 9 124 1 4 194 46
OK 9 156 1 4 159 58
OK 9 124 1 4 193 46
usw. usw.
Debug-Mode
Aus quiet mode wurde debug. Irgendwie fand ich es dann doch seltsam, dass das umgekehrt wie der debug mode im Sketch war.
1d schaltet DEBUG ein, 0d schaltet es aus
Änderung der Implementierung für den Datenempfang
Habe ich so geändert, dass die loop kontinuierlich läuft. Bisher war es so, dass sie in der receive festsaß, bis etwas empfangen wurde.
Das war für das Empfangen von Kommandos auf der Seriellen nicht ganz ideal (ist immer nur dann passiert, wenn mal etwas empfangen wurde) und
für das Senden von Daten auch eher unpraktisch (man will ja nicht nur dann was gesendet bekommen, wenn man gerade etwas
Empfangen hat).
Neues command zum Senden von Daten (Rumpf-Implementierung)
Mit b1,b2,b3,b4s können vier Byte (Angabe dezimal), die gesendet werden sollen, übergeben werden.
Das fünfte CRC-Byte wird im Sketch berechnet.
Beispiel: 148,5,82,63s
Das Senden der Daten fehlt momentan noch.
Eventuell könnten wir hier die Senderoutine von ulli dann einbauen, wenn sie läuft. Mit der Senderei habe ich das Problem, dass ich keine
Wetter-Station habe, mit der ich es testen könnte. Da macht implementieren wenig Spaß.
Alle Parameter können natürlich auch im Sketch gesetzt werden
// --- Configuration ---------------------------------------------------------
bool DEBUG = 0; // set to 1 to see debug messages
bool ENABLE_ACTIVITY_LED = 1; // set to 0 if the blue LED bothers
int DATA_RATE = DATA_RATE_17; // use one of the data rates defined above
int TOGGLE_DATA_RATE = 0; // 0=no toggle, else interval in seconds
Anbei die Version 10.0c
Erweiterungen / Änderungen / Problem
Senden
Ich habe Senden implementiert. Die Daten, die gesendet werden, werden in FHEM korrekt empfangen und verarbeitet.
Dann sollte es eigentlich auch mit einer Wetterstation gehen. Kann das mal jemand, der eine hat, testen?
Senden kann man, wie im vorherigen Beitrag schon beschrieben, mit b1,b2,b3,b4s
Die Datenbytes muss man selbst berechnen. Der Aufbau das Daten frame ist im Sketch beschrieben.
Das fünfte Byte (CRC) wird im Sketch berechnet und wird nicht angegeben.
Beispiele (alle Werte Dezimal):
149,38,34,33s: ID=20, 22.2 °C, 33% Feuchte, NewBattaryFlag gesetzt
149,6,34,33s: ID=20, 22.2 °C, 33% Feuchte, NewBattaryFlag NICHT gesetzt
158,37,35,45s: ID=56, 12.3 °C, 45% Feuchte, NewBattaryFlag gesetzt
158,5,35,45s: ID=56, 12.3 °C, 45% Feuchte, NewBattaryFlag NICHT gesetzt
Zusätzlich gibt es zum einfacheren Testen das command <n>x
Dieses sendet den angegebenen Wert mit der ID 20 als Temperatur und Feuchte.
Beispiele(alle Werte Dezimal):
30x: Sende 30°C und 30% mit Sensor ID 20
55x: Sende 55°C und 55% mit Sensor ID 20
Neues Command <n>x
Für Tests gedacht, aktuell siehe oben
RECEIVER_ENABLED
Wenn man nie etwas ampfangen will, kann man im Abschnitt "Configuration" RECEIVER_ENABLED=0 setzen
Problem
Ich glaube, dass die Berechnung der empfangenen ID des Sensors im Sketch flasch ist.
Habe mich beim Testen der Senderoutinen gewundert, warum ich auf dem FHEM-System Sensor-IDs bekomme, die ich nicht sende.
msg->id = 0;
msg->id |= (data[0] & 0xF) << 2;
aktuell: msg->id |= (data[1] & 0xC0);
meine Meinung: msg->id |= (data[1] & 0xC0) >> 6;
Kann da mal jemand drauf schauen, ob ich richtig liege?
Dann stellt sich die Frage, was man tut. Wenn wir es korrigieren, dann bekommen einige Anwender für einige Sensoren neue IDs und müssen das in der fhem.cfg anpassen.
Wenn wir es nicht korrigieren, dann ist es falsch und verwirrend.
Vorschläge?
Anbei die Version 10.0d
Erfolg, funktioniert!!!!
Cool ;-)
Hab die Wetterstation 35.5019.IT versucht.... hat direkt die Temperatur angezeigt!!
Nachtrag:
Seit dem neuen Sketch kann ich auch den Sensor: 30.3156.WD (V35) empfangen...
Zitat von: JoeALLb am 09 März 2014, 16:10:25
Erfolg, funktioniert!!!!
Cool ;-)
Hab die Wetterstation 35.5019.IT versucht.... hat direkt die Temperatur angezeigt!!
Na denn, dann können wir diesen Weg weiterverfolgen.
Zitat von: JoeALLb am 09 März 2014, 16:10:25
Seit dem neuen Sketch kann ich auch den Sensor: 30.3156.WD (V35) empfangen...
Seltsam. Habe nur eine Sache im Empfangsteil geändert, nämlich den FIFO zu leeren, bevor angefangen wird zu empfangen.
Warum das dazu führt, dass der 30.3156.WD nun funktioniert, ist mir unklar. Sicher, dass er mit der Version 10.0c nicht auch schon ging?
soll das zusammenbauen der nachricht lieber in den sketch oder ins fhem modul?
braucht man ein send kommando für beide datenraten?
reicht auf fhem seite eine einfaches send kommando oder ist ein pseudo device sinnvoll das man z.b. an einen temperatur und eine. feuchtigkeitssensor hängen kann und das bei werteänderungen automatisch sendet?
gruss
andre
Ich hätte erwartet dass es ins FHEM Modul kommt und man dann Werte anderer FHEM Devices über
IT+ Anzeigeeinheit zur Anzeige bringen kann.
Z.B Temperatur eines Puffers oder Wassertasche (1-Wire) kann im Wohnzimmer angezeigt werden.
Gruss Billy
Nicht sicher, hatte mit 10c nicht viel gespielt...
Was ich in fhem noch nicht sehe ist die Version der Firmware. Muss da Andre nochmal ran?
Korrektur: Geht doch! nach einem get <> devices
Wird es dann auch möglich sein, mehrere Sensoren zu "imitieren"? Meine Wetterstation kann 3 Sensoren anzeigen.
Wenn eine Wetterstation mit einem Sensor der ID 70 gefahren wurde, sollte ich doch einfach diese ID mitsingen können und deneigentlichen Sensor deaktivieren können, und der Wetterstation sollte dies egal sein, oder? (vorausgesetzt, die ID Berechnung stimmt, wie vorhin angezweifelt wurde)
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: justme1968 am 09 März 2014, 16:40:38
reicht auf fhem seite eine einfaches send kommando oder ist ein pseudo device sinnvoll das man z.b. an einen temperatur und eine. feuchtigkeitssensor hängen kann und das bei werteänderungen automatisch sendet?
Ich vermute, "nur" Wertänderunen reichen nicht, da eine Wetterstation nach einer unbekannten Zeit "--" als Temperatur anzeigt.
das heisst ein einfaches send kommando reicht nicht sondern man braucht ein pseudo sensor in fhem der dann automatisch bei änderungen und regelmäßig sendet.
davon kann man dann in fhem natürlich mehr als eins anlegen
@HCS
ZitatSenden
Ich habe Senden implementiert. Die Daten, die gesendet werden, werden in FHEM korrekt empfangen und verarbeitet.
Dann sollte es eigentlich auch mit einer Wetterstation gehen. Kann das mal jemand, der eine hat, testen?
Würde gerne testen, habe die WS-9140IT Anzeigeeinheit.
Sketch ist geflasht.
Wo muss ich was eingeben?
ZitatSenden kann man, wie im vorherigen Beitrag schon beschrieben, mit b1,b2,b3,b4s
Stehe gerade auf dem Schlauch? :-\
Gruss
Billy
Ich würde die Nachricht im FHEM Modul zusammenbauen, da ist man flexibel.
Falls es aber FHEM-Dinge dramatisch vereinfacht, würde ich mich auch dazu durchringen, zusätzlich ein Command zu implementieren, das Werte entgegennimmt.
So in der Art: i,r,t10,t1,tf,h,n,ws
wobei:
i=ID
r=Datenrate
t10=temperatur 10er (40°C Offset)
t1=temperatur 1er
tf=temperatur Nachkommastelle
h=Feuchte
n=NewBatteryFag
w=WeakBatteryFlag
Datenrate beim Senden: momentan wird mit der aktuell gesetzten Datenrate gesendet (was bei toggle unglücklich ist). Ich sehe zwei Varianten, die ich einbauen könnte:
1. Ein Command, mit dem man die Sende-Datenrate (analog zur Empfangs-Datenrate) festlegt, die dann beibehalten und bei jedem b1,b2,b3,b4s verwendet wird.
2. Bei jedem Senden mitgeben, also r,b1,b2,b3,b4s wobei r die Datenrate ist
Mehrere Sensoren imitieren: Das geht jetzt schon. Die ID, die gesendet wird, ist ja in b1 und b2 drin. Somit kann von FHEM aus mit beliebigen IDs gesendet werden. Die gesendeten IDs sind korrekt, das ID-Problem gibt es nur beim Empfangen.
Zitat von: Billy am 09 März 2014, 17:09:05Wo muss ich was eingeben?
Entweder im SerialMonitor von Arduino oder von FHEM aus bei deinem LeeLink device mit raw absenden.
z.B.
149,38,34,33s ID=20 22.2 °C 33% MIT NewBatt
oder einfach
33x um 33°C und 33% Feuchte zusenden (mit ID 20)
oder einfach
25x um 25C und 25% Feuchte zusenden (mit ID 20)
Das fett markierte musst Du eingeben
Ach ja, dass sich jetzt niemand zu sehr mit dem <n>x Command anfreundet. Das ist wirklich nur vorübergehend zum Testen.
kein problem. ich kann das zusammenbauen ins fhem modul stecken.
ich stehe aber gerade auf dem schlauch wie die 4 bytes kodiert sind und bekomme die 149,38,34,33s nicht mit dem format der Empfangs richtung zur deckung.
gruss
andre
HCS: Jetzt waren wir gleich schnell. Ich hatte mich gestern auch dran gesetzt über den Jeelink auch die Daten senden zu können. :)
justme: Ich habe für den Jeelink von Haus aus die Codierung ins Jeelink.pm genommen, da meine Firmware nur Rohdaten sendet.
Du kannst folgenden Code nehmen, muss nur "invertiert" werden.
my( $addr, $type, $channel, $temperature, $humidity, $batInserted ) = 0.0;
$addr = sprintf( "%02X", ((hex(substr($dmsg,3,2)) & 0x0F) << 2) | (hex(substr($dmsg,5,2)) & 0xC0) );
$type = ((hex(substr($dmsg,5,2)) & 0xF0) >> 4); # not needed by LaCrosse Module
#$channel = 1; ## $channel = (hex(substr($dmsg,5,2)) & 0x0F);
#Log 1, "Addr: " . $addr;
$temperature = ( ( ((hex(substr($dmsg,5,2)) & 0x0F) * 100) + (((hex(substr($dmsg,7,2)) & 0xF0) >> 4) * 10) + (hex(substr($dmsg,7,2)) & 0x0F) ) / 10) - 40;
return if($temperature >= 60 || $temperature <= -40);
$humidity = hex(substr($dmsg,9,2));
$batInserted = ( (hex(substr($dmsg,5,2)) & 0x20) << 2 );
#build string for 36_LaCrosse.pm
$dmsgMod = "OK 9 $addr ";
#bogus check humidity + eval 2 channel TX25IT
if (($humidity >= 0 && $humidity <= 99) || $humidity == 106 || ($humidity >= 128 && $humidity <= 227) || $humidity == 234) {
$dmsgMod .= (1 | $batInserted);
} elsif ($humidity == 125 || $humidity == 253 ) {
$dmsgMod .= (2 | $batInserted);
}
#$humidity = 99 if($humidity > 99 || $humidity < 0); not longer needed
$temperature = (($temperature* 10 + 1000) & 0xFFFF);
$dmsgMod .= " " . (($temperature >> 8) & 0xFF) . " " . ($temperature & 0xFF) . " $humidity";
Mein Test mit der WS-9140IT bringt keinen Erfolg! :(
Sowohl die Eingabe übers Terminal alsauch über FHEM mit set myJeeLink raw 149,38,34,33s
ergibt keine Anzeige.
Nur zur Sicherheit, ich setzte die Batterien in die WS-9140IT ein und setze dann den Befehl ab,
dann sollte ja was angezeigt werden? Oder fehlt da was?
Gruss
Billy
Zitat von: justme1968 am 09 März 2014, 18:02:42
ich stehe aber gerade auf dem schlauch wie die 4 bytes kodiert sind und bekomme die 149,38,34,33s nicht mit dem format der Empfangs richtung zur deckung
Alle Angaben Dezimal, sofern nicht binär
Die ersten 4 bit immer 1001
Dann 6 bit mit der Adresse
Dann ein bit NewBatteryFlag
Dann ein bit, das immer 0 ist
Dann 4 bit temperatur * 10 mit 40°C Offset
Dann 4 bit temperatur * 1
Dann 4 bit temperatur * 0.1
Dann 1 Bit WeakBattery (in unserem Fall wohl immer 0)
Dann 7 Bit Feuchte
Beispiel für ID=20 Temperatur 22.2 °C 33% Feuchte mit NewBatteryFlag:
Start: 1001 = 9
Adresse: 010100 = 20
NewBatt: 1
Unused: 0
Temperatur 10er: 0110 = 6 (20°C + 40 Offset) / 10
Temperatur 1er: 0010 = 2
Temperatur 10tel: 0010 = 2
WeakBattery: 0
Feuchte: 0100001 = 33
Alles hintereinander und als 4 Bytes gesehen:
10010101 00100110 00100010 00100001
149 38 34 33
Falls ich mich nicht vertippt oder verrechnet habe, dann sollte man es so nachvollziehen können
ulli: wenn ich Deinen quellcode richtig verstehe, was bei PERL nicht immer zutrifft, hast Du den ID-Berchnungsfehler mit übernommen (siehe mein Beitrag weiter oben)
justme: nun hast Du Quellcode und eine Beschreibung.
ulli: wir sollten uns koordinieren, dass wir nicht alles doppelt machen, war aber mein Fehler, hatte ja geschrieben, dass ich auf Deine Routine warte und konnte es dann doch nicht lassen :-)
Wir sollten dringend das "ID-Thema" klären, bevor damit zu viel Chaos entsteht.
Zitat von: Billy am 09 März 2014, 18:20:33Nur zur Sicherheit, ich setzte die Batterien in die WS-9140IT ein und setze dann den Befehl ab,
dann sollte ja was angezeigt werden? Oder fehlt da was?
Ja, so sollte es gehen. Evtl. kann ja JoeALLb mal schildern was er getan hat.
Könnte noch an der Datenrate liegen.
Falls Du zwei JeeLink hast, kannst Du auch ein LaCrosse Modul in FHEM manuell mit der Adresse 14 (HEX) = Dezimal 20 einrichten und mit dem Anderen vom serial monitor aus senden. So habe ich meine Senderoutinen getestet.
Also so:
define FakeSensor_14 LaCrosse 14
attr FakeSensor_14 filterThreshold 90
attr FakeSensor_14 room SystemErgebnis siehe Anhang
Nachtrag: was für einen Sensor hast Du den für die WS-9140IT
@HCS
ZitatNachtrag: was für einen Sensor hast Du den für die WS-9140IT
Aktuell liegt der TX29DTH-IT am Tisch und sowohl Jeelink alsauch WS-9140IT funktionieren einwandfrei!
Insofern dürfte es ja nicht an der Datenrate liegen oder sehe ich da was falsch?
Ich warte mal ob JoeALLb noch eine andere Vorgehensweise hatte.
Danke übrigens für die Arbeit.
Billy
Ja, wenn die Station mit dem TX29DTH-IT arbeitet, ist 17.241 kbps richtig.
Vielleicht sind verschiedene Stationen unterschiedlich kritisch für das Timing oder den einleitenden Sync des Datenpakets.
@JoeALLb: gehört zu Deiner Wetterstation der 30.3156.WD dazu?
Irgendwie gewinne ich eh den Eindruck, das bei LaCross nur das, was zusammen in der Schachtel ist, voll kompatibel ist.
Was mich jetzt brennend interessieren würde: ob die 35.5019.IT Wetterstation von JoeALLb mit einem TX29DTH-IT zusammenarbeiten würde.
Die WS-9140IT ist von Technoline und arbeitet original mit Außensender TX37-IT.
Die die 35.5019.IT Wetterstation ist von TFA Dostmann.
anbei eine erste version des LaCrosse moduls das senden kann:
set <device> send [<temperature> [<humidity>]]
wenn die parameter nicht angegeben sind dann werden die aktuell als readings vorhandenen temperatur und humidity werte gesendet.
weiss jemand wie oft mindestens gesendet werden muss damit das display nicht -- anzeigt ?
gruss
andre
Ich habe nichts anderes gemacht, habe den Sketsch aber derzeit auf die wechselnde Datenrate eingestellt. Werde jetzt mal das neue Modul testen!
Über raw kann ich die Temperatur von 22,2 grad senden,
über das Modul pklappt es nicht.
Ich bin so vorgegangen:
ich habe die Wetter station mit dem jeelink über das absenden von
"149,6,34,33s" verbunden.
Daher gehe ich davon aus, dass die Wetterstation jetzt auf ID 20 "hört".
Wenn ich nun ein Device mit ID 20 anlege und dort dann den Senden-Befehl absetze,
ändert sich and er Temperatur nichts.
Mache ich etwas falsch?
setz mal verbose auf 5 dann siehst du was der jeelink zum senden bekommt.
vergleich mal die raw version mit der send version.
das modul sendet zur zeit immer das new battery flag mit. eventuell beisst sich das. du kannst in zeile 165 mal das '| 0x20' in der mitte raus schmeissen und schauen ob es dann geht.
gruss
andre
die id in der modul definition ist in hex. wenn du dezimal id 20 hast musst du das modul mit 14 anlegen.
gruss
andre
Wie schon gesagt, wir sollten mal das ID Thema klären. Wenn das Modul mit dem Code, den ich oben gesehen habe, sendet, dann sendet es eine falsche ID.
Nachtrag: wobei das bei ID 20 egal sein müsste, da in diesem Fall die beiden Bits im zweiten Byte 0 sind.
ZitatDaher gehe ich davon aus, dass die Wetterstation jetzt auf ID 20 "hört".
Sobald man die Batterien rausnimmt wird die ID gelöscht! Zumindest bei der WS-9140IT
Nach dem Einlegen hat man ca. 45 sec Zeit zum Pairen d.h. Übernehmen der neuen ID.
Aber wie gesagt bei mir klappt es mit dem Senden über J-Link nicht.
Könnte aber falls Bedarf meine WS-9140IT ausleihen!
Die läuft übrigens mit allen meinen 4 unterschiedlichen IT+ Sensoren von Technoline!
Gruss Billy
Anbei das Log.
Es funktioniert direkt nach dem einlegen der Batterie in die Wetterstation: Die Temperatur 22,2° wird angezeigt, sobald ich den Befehl absetze!
Wenn ich dann versuche, einen anderen Wert zu übertragen, wird nichts geändert.
Wenn ich warte, bis "--" angezeigt wird, habe ich es auch nicht mehr geschafft, dass wieder etwas angezeigt wird.
egal ob ich mit oder ohne Battery-Flag gesendet habe, der Wert wurde nicht verändert.
2014.03.09 20:56:57 5: JeeLink/RAW: /OK 9 76 1 4
2014.03.09 20:56:57 5: JeeLink/RAW: OK 9 76 1 4 /41 55
2014.03.09 20:56:57 5: JLLaCR dispatch OK 9 76 1 4 41 55
2014.03.09 20:57:08 5: JeeLink/RAW: /OK 9 144 1
2014.03.09 20:57:08 5: JeeLink/RAW: OK 9 144 1 /4 8 106
2014.03.09 20:57:08 5: JLLaCR dispatch OK 9 144 1 4 8 106
2014.03.09 20:57:16 5: JeeLink/RAW: /OK 9 14
2014.03.09 20:57:16 5: JeeLink/RAW: OK 9 14/4 1 4 8 106
2014.03.09 20:57:16 5: JLLaCR dispatch OK 9 144 1 4 8 106
2014.03.09 21:02:08 5: JeeLink/RAW: /OK 9 76 1
2014.03.09 21:02:08 5: JeeLink/RAW: OK 9 76 1 /4 40 55
2014.03.09 21:02:08 5: JLLaCR dispatch OK 9 76 1 4 40 55
2014.03.09 21:02:10 5: JeeLink/RAW: /OK 9 144
2014.03.09 21:02:10 5: JeeLink/RAW: OK 9 144/ 1 4 7 106
2014.03.09 21:02:10 5: JLLaCR dispatch OK 9 144 1 4 7 106
2014.03.09 21:02:17 5: JeeLink/RAW: /OK 9 76 1
2014.03.09 21:02:17 5: JeeLink/RAW: OK 9 76 1/ 4 40 55
2014.03.09 21:02:17 5: JLLaCR dispatch OK 9 76 1 4 40 55
2014.03.09 21:02:22 5: JLLaCR sending 149,38,80,0s
Was mir noch aufgefallen ist: Ich habe 2 Jeelinks, eine für PCA301, eine für LaCross.
Wenn ich das DEF eines Sensores verändere, wird bei mir immer der IODEV von LaCross auf den anderen JeeLink geändert, obwohl ich am Attribut nichts ändere...
Ist das ein Fehler im Modul?
der default in fhem ist zur zeit das im define das letzte 'passende' iodev gesucht wird und du das von hand mit dem IODev attribut selber fest setzen musst damit es keine probleme bei mehreren passenden devices gibt.
ich habe hier schon eine version des moduls die das besser macht und rudi hat gerade eine änderung in fhem eingebaut mit der das verhalten sich auch verbessern sollte.
wenn du mehrere jeelinks hast solltes du bei allen devices das richtige IODev per attribut setzen und speichern.
gruss
andre
Aber genau dieses Attribut, das ich ja gesetzt habe, wird gerade beim Ändern des DEV in der Weboberfläche geändert! Das würde ich als Fehler einstufen.
Zitat von: justme1968 am 09 März 2014, 20:43:26
das modul sendet zur zeit immer das new battery flag mit. eventuell beisst sich das. du kannst in zeile 165 mal das '| 0x20' in der mitte raus schmeissen und schauen ob es dann geht.
Hat leider keine Änderung gebracht... die Anzeige bleibt bei 22,2° stehen.
2014.03.09 21:10:48 5: JLLaCR dispatch OK 9 144 1 4 5 106
2014.03.09 21:10:53 5: JeeLink/RAW: /OK 9 76 1 4 38 56
2014.03.09 21:10:53 5: JLLaCR dispatch OK 9 76 1 4 38 56
2014.03.09 21:11:00 0: HMLAN_Parse: HMLAN1 V:03C1 sNo:JEQ0707897 d:1E9B80 O:1E9B80 t:AEEE4BC5 IDcnt:0000
2014.03.09 21:11:02 5: JeeLink/RAW: /OK 9 144 1 4 5 106
2014.03.09 21:11:02 5: JLLaCR dispatch OK 9 144 1 4 5 106
da steht im log auch nicht das etwas gesendet wird...
Zitat von: JoeALLb am 09 März 2014, 21:06:02
Es funktioniert direkt nach dem einlegen der Batterie in die Wetterstation: Die Temperatur 22,2° wird angezeigt, sobald ich den Befehl absetze!
Wenn ich dann versuche, einen anderen Wert zu übertragen, wird nichts geändert.
Wenn ich warte, bis "--" angezeigt wird, habe ich es auch nicht mehr geschafft, dass wieder etwas angezeigt wird.
egal ob ich mit oder ohne Battery-Flag gesendet habe, der Wert wurde nicht verändert.
Das ist ja interessant. Erwartet die Wetterstation eine bestimmte Vorgehensweise, also während und/oder nach der Paarung etwas besonderes? Wenn sie beim Paaren das Paket versteht, sollte das doch danach auch gehen. Eventuell sollte man mal genau protokollieren, was der Sensor ab dem Einlegen der Batterie genau tut.
Mit welcher Frequenz wird eigentlich. Gesendet? Immer mit der, die per toggle gerade aktiv sein soll?
Warum dauert das absetzen des senden Befehls manchmal 4 Sekunden, manchmal geht es sofort? Ist da der Jeelink gerade belegt?
Gesendet von meinem Xperia Pro mit Tapatalk
Kann ich empfangene RAW-Pakete irgendwie aus dem Log ausblenden, um nur gesendete anzueigen?
Zitat von: JoeALLb am 09 März 2014, 21:21:13
Mit welcher Frequenz wird eigentlich. Gesendet? Immer mit der, die per toggle gerade aktiv sein soll?
Warum dauert das absetzen des senden Befehls manchmal 4 Sekunden, manchmal geht es sofort? Ist da der Jeelink gerade belegt?
Meinst Du mit Frequenz die data rate? Dann siehe weiter oben.
Sind die 4 Sekunden von FHEM aus oder vom serial monitor aus?
Wenn Du sicher mit einer bestimmten data rate senden willst, solltest du die im sketch setzten und toggle auf 0 oder vor dem senden 0t 0r hinschicken. Nur ist leider raw im Modul entfallen. Könnte das oder ein Ersatz wieder rein?
Zitat von: JoeALLb am 09 März 2014, 21:26:51
Kann ich empfangene RAW-Pakete irgendwie aus dem Log ausblenden, um nur gesendete anzueigen?
Und kann man im event monitor einen Filter setzen?
warum ist raw entfallen?
raw ist im JeeLink modul, send ist im LaCrosee modul...
mit einem 'tail -f <fhem-log> | grep sending' bekommst du nur die send nachrichten
du kannst statt dem event monitor 'inform timer' auf der konsole verwenden und da angeben was du loggen willst.
Zitat von: justme1968 am 09 März 2014, 21:30:38
warum ist raw entfallen?
Was meinst du damit?
Ich habe das Modul wieder zurückgebaut um das battery-flag wieder zu senden:
--> mit send kann ich keine Anzeige an der Wetterstation erzeugen
set LaCrosse_EC send 21
fhem> 2014-03-09 21:44:01 LaCrosse LaCrosse_EC send 21
2014-03-09 21:44:12 LaCrosse LaCrosse_EC temperature: 5.9
2014-03-09 21:44:12 LaCrosse LaCrosse_EC battery: ok
2014-03-09 21:44:12 LaCrosse LaCrosse_4C temperature: 5.4
2014-03-09 21:44:12 LaCrosse LaCrosse_4C humidity: 58
2014-03-09 21:44:12 LaCrosse LaCrosse_4C battery: ok
Hier bleibt alles leer.
Die einzigen beiden Befehle, die funktionieren, sind:
set JLLaCR raw 149,38,34,33s:
und
set JLLaCR raw 158,37,35,45s
Zitat von: justme1968 am 09 März 2014, 21:30:38
warum ist raw entfallen?
raw ist im JeeLink modul, send ist im LaCrosee modul...
Klar, sorry, jetzt stand dann ich wohl auf dem Schlauch ...
Noch eine (unbestätigte) Idee: vielleicht muss man während die Wetterstation im pairing mode ist pünktlich alle 4 Sekunden ein paket schicken, um sie zu überzeugen, dass das ein Sensor ist, den sie sich merken soll.
Ich vermute, dass das Problem, dass sie später nicht mehr reagiert, irgend so etwas in der Art ist.
anbei noch ein Auszug aus dem Log mit dem grep.
Warum ich nach 21:14 nichts mehr im Log stehen habe, verstehe ich nicht. Habe bis gerade eben getestet und
mehrere Varianten ausprobiert!
Aktuell schaffe ich es jedoch mit keinem Befehl mehr, eine Anzeige an der Wetterstation zu erzeugen.
Sie bleibt immer leer.
Das deckt sich eventuell mit dem FHEM-Logauszug unten.
2014.03.09 21:01:25 5: JLLaCR sending 149,38,80,0s
2014.03.09 21:02:22 5: JLLaCR sending 149,38,80,0s
2014.03.09 21:08:43 5: JLLaCR sending 149,38,0,0s
2014.03.09 21:10:31 5: JLLaCR sending 149,6,80,0s
2014.03.09 21:10:36 5: JLLaCR sending 149,6,16,0s
2014.03.09 21:10:39 5: JLLaCR sending 149,6,16,0s
2014.03.09 21:10:42 5: JLLaCR sending 149,6,32,0s
2014.03.09 21:14:54 5: JLLaCR sending 149,6,32,0s
b1,b2,b3,b4s - send the passed bytes plus the calculated CRC
b1,b2,b3,b4s - send the passed bytes plus the calculated CRC
Aktuell werden diese beiden Befehle akzeptiert, jedoch vermutlich nicht abgesetzt.
Das Log bleibt leer und die Anzeige ebenfalls.
fhem> set JLLaCR raw 149,38,34,33s
fhem> set LaCrosse_EC send 21
Nach einem FHEM-Neustart wurde
set JLLaCR raw 149,38,34,33s
wieder akzeptiert un hat die Anzeige an der Wetterstation wieder gesetzt, jedoch blieb das Log noch immer leer
tail -n 20000 /opt/fhem/log/fhem-2014-03.log |grep send
2014.03.09 21:10:31 5: JLLaCR sending 149,6,80,0s
2014.03.09 21:10:36 5: JLLaCR sending 149,6,16,0s
2014.03.09 21:10:39 5: JLLaCR sending 149,6,16,0s
2014.03.09 21:10:42 5: JLLaCR sending 149,6,32,0s
2014.03.09 21:14:54 5: JLLaCR sending 149,6,32,0s
b1,b2,b3,b4s - send the passed bytes plus the calculated CRC
b1,b2,b3,b4s - send the passed bytes plus the calculated CRC
Dieser Befehl funktioniert weiterhin nicht.
set LaCrosse_EC send 21
Zitat von: HCS am 09 März 2014, 22:02:52
Noch eine (unbestätigte) Idee: vielleicht muss man während die Wetterstation im pairing mode ist pünktlich alle 4 Sekunden ein paket schicken, um sie zu überzeugen, dass das ein Sensor ist, den sie sich merken soll.
Wenn man mir sagt, wie ich nur einen neuen Sensor loggen kann, kann ich das pairing gerne loggen.
Hier in der Gegend sind >15 Sensoren von Nachbarn, die kann ich nicht alle batterielos machen ;-)
Ich mache morgen wieder weiter ;-)
Habe gerade einen Sensor mit neu eingelegter Batterie geloggt. Da war nichts auffälliges. Ich glaube inzwichen eher an meine 4 Sekunden Theorie.
JoeALLb: Schaffst du es, während die Station im pairing ist, halbwegs zuverlässig alle 4 Sekunden etwas zu senden?
ZitatHabe gerade einen Sensor mit neu eingelegter Batterie geloggt. Da war nichts auffälliges. Ich glaube inzwichen eher an meine 4 Sekunden Theorie.
JoeALLb: Schaffst du es, während die Station im pairing ist, halbwegs zuverlässig alle 4 Sekunden etwas zu senden?
Mit hterm geht das zu machen! http://www.der-hammer.info/terminal/
Da kann man die Wiederholrate und die Pulszeit einstellen. Vielleicht hilfts.
Billy
einfach ein at definieren das alle 4 sekunden sendet.
gruss
andre
Ich denke nicht, dass die Send-Routine funktioniert, da ich damit niemals eine Anzeige auf die Wetterstation bekommen habe. Dies habe ich immer nur mit den beiden raw-befehlen geschafft.
Kann da irgendwo noch etwas nicht stimmen?
Gesendet von meinem Xperia Pro mit Tapatalk
bitte vergleiche noch mal die log ausgaben von send und raw. bei beiden sollte ein 'SW ...' auftauchen.
gruss
andre
RAW
2014.03.10 08:16:25 5: JLLaCR dispatch OK 9 144 1 3 221 106
2014.03.10 08:16:30 4: set JLLaCR raw 149,38,34,33s
2014.03.10 08:16:30 5: SW: 149,38,34,33s
set LaCrosse_EC send 21
produziert:
2014.03.10 08:18:05 5: JLLaCR dispatch OK 9 144 1 3 221 106
2014.03.10 08:18:06 0: HMLAN_Parse: HMLAN1 R:E223636 stat:0000 t:B15140C2 d:FF r:FFCB m:69 8610 223636 000000 0A78C00E0018
2014.03.10 08:18:21 5: JeeLink/RAW: /OK 9 144 1
2014.03.10 08:18:21 5: JeeLink/RAW: OK 9 144 1 /3 222 106
2014.03.10 08:18:21 5: JLLaCR dispatch OK 9 144 1 3 222 106
2014.03.10 08:18:25 5: JeeLink/RAW: /OK 9 144 1
2014.03.10 08:18:25 5: JeeLink/RAW: OK 9 144 1 /3 222 106
2014.03.10 08:18:25 5: JLLaCR dispatch OK 9 144 1 3 222 106
2014.03.10 08:18:26 5: JeeLink/RAW: /OK 9
2014.03.10 08:18:26 5: JeeLink/RAW: OK 9 /76 1 4 31 69
2014.03.10 08:18:26 5: JLLaCR dispatch OK 9 76 1 4 31 69
2014.03.10 08:18:28 5: JeeLink/RAW: /OK 9 236 1 3 253
2014.03.10 08:18:28 5: JeeLink/RAW: OK 9 236 1 3 253/ 106
2014.03.10 08:18:28 5: JLLaCR dispatch OK 9 236 1 3 253 106
2014.03.10 08:18:28 3: LaCrosse Unknown device EC, please define it
Das Device gibt es aber, anbei das List davon.
Da in der Fehlermeldung nur von "EC gesprochen wird, kann es sein, dass das Madul hier den Namen falsch ermittelt?
list LaCrosse_EC
Internals:
DEF 14
IODev PCAJeeLink
NAME LaCrosse_EC
NR 434
STATE T: 5.8
TYPE LaCrosse
addr 14
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1394435988.90966
VALUE send 21
Mydblogsql:
TIME 1394435988.93241
VALUE send 21
Readings:
2014-03-09 21:49:02 battery ok
2014-03-09 21:45:02 state T: 5.8
2014-03-09 21:49:02 temperature 5.8
Attributes:
IODev PCAJeeLink
room LaCrosse
da stimmt irgendetwas nicht. die meldung kommt auch nicht vom senden sondern vom empfangen.
du verwendest für das raw das device JLLaCR. das ist auch das device mit dem empfangen wird.
beim senden verwendest du LaCrosse_EC. der hat aber als IODev PCAJeeLink.
du musst für LaCrosse_EC das attribut IODev auf JLLaCR setzen und dann sollte es auch mit dem senden gehen.
gruss
andre
Das ist das problem, von dem ich gestern gesprochen habe. mir wird ständig das IODev-Attribut geändert,
und ich weiß noch nicht genau, durch welche aktion.
Definitiv wird es geändert, wenn ich in der Weboberfläche das define für ein Device ändere. ärgerlich ;-)
So, anbei ein neuer Logauszug mit neu gesetztem IODev.
2014.03.10 08:39:01 5: JeeLink/RAW: /OK 9 76 1 4 61 63
2014.03.10 08:39:01 5: JLLaCR dispatch OK 9 76 1 4 61 63
2014.03.10 08:39:04 5: JeeLink/RAW: /OK 9 144 1 3 231 106
2014.03.10 08:39:04 5: JLLaCR dispatch OK 9 144 1 3 231 106
2014.03.10 08:39:04 5: JeeLink/RAW: /OK 9 76 1
2014.03.10 08:39:04 5: JeeLink/RAW: OK 9 76 1/ 4 62 63
2014.03.10 08:39:04 5: JLLaCR dispatch OK 9 76 1 4 62 63
2014.03.10 08:39:07 5: JLLaCR sending 149,38,16,0s
2014.03.10 08:39:07 5: SW: 149,38,16,0s
Jedoch bin ich leider gerade nicht vor Ort, um die Wetterstation abzulesen oder zu resetten.
@HCS
Ich würde das ganze mal gerne sauber über Terminalbefehle nachvollziehen.
Habe deshalb 2 Jeelink mit deinem [LaCrosseITPlusReader.10.0d] geflasht.
Beide jeelink loggen sauber wenn ein Sensor aktiviert wird
OK 9 8 129 4 196 106<\r>
Was mir nicht gelingt ist dass der eine jeelink vom andern was empfängt wenn ich z.B.
149,38,34,33s übers Terminal absetzte.
Hast du da eine Idee. Version bringt [LaCrosseITPlusReader.10.0d @17.241 kbps]<\r>
müsste also stimmen.
Gruss
Billy
Genau so habe ich die ganze Zeit getestet, ein JeeLink auf dem FHEM Raspi und einer am Laptop, mit dem ich vom Terminal aus sende.
Sende mal beiden ein 1d um DEBUG zu aktivieren oder setze DEBUG=1 im Sketch und poste dann die Ausgaben.
Habs über Mittag nochmal getestet:
Ich kann den ersten Wert nach dem Batterieeinlegen direkt über RAW wie auch über send setzen. kein Unterschied.
Es gingen bisher auch alle geprüften Temperaturwerte.
Die Wetterstation zeigt das an.
Danach kann ich den Wert jedoch nicht mehr ändern.
Da send ja das Batteryflag mitschickt, habe ich über ein at und raw alle 4 Sekunden
eine die selbe(jedoch eine andere wie zu begin mit dem batteryflag) gesendet: Sie wurde niemals angezeigt!!!
Kann das irgendwie mit dem Frequenztoggle der Firmware zusammenhäüngen?
Anbei das Log
2014.03.10 13:04:31 5: SW: 149,6,34,33s
2014.03.10 13:04:37 5: SW: 149,38,80,33s
2014.03.10 13:04:41 5: SW: 149,38,80,33s
2014.03.10 13:04:45 5: SW: 149,38,80,33s
2014.03.10 13:04:51 5: SW: 149,38,80,33s
2014.03.10 13:04:53 5: SW: 149,38,80,33s
2014.03.10 13:04:57 5: SW: 149,38,80,33s
2014.03.10 13:05:01 5: SW: 149,38,80,33s
2014.03.10 13:05:05 5: SW: 149,38,80,33s
2014.03.10 13:05:09 5: SW: 149,38,80,33s
2014.03.10 13:05:13 5: SW: 149,38,80,33s
2014.03.10 13:05:17 5: SW: 149,38,80,33s
2014.03.10 13:05:21 5: SW: 149,38,80,33s
2014.03.10 13:05:26 5: SW: 149,38,80,33s
2014.03.10 13:05:29 5: SW: 149,38,80,33s
2014.03.10 13:05:33 5: SW: 149,38,80,33s
2014.03.10 13:05:37 5: SW: 149,38,80,33s
2014.03.10 13:05:41 5: SW: 149,38,80,33s
2014.03.10 13:05:45 5: SW: 149,38,80,33s
2014.03.10 13:05:50 5: SW: 149,38,80,33s
2014.03.10 13:05:53 5: SW: 149,38,80,33s
2014.03.10 13:05:57 5: SW: 149,38,80,33s
2014.03.10 13:06:01 5: SW: 149,38,80,33s
2014.03.10 13:06:06 5: SW: 149,38,80,33s
2014.03.10 13:06:09 5: SW: 149,38,80,33s
2014.03.10 13:06:13 5: SW: 149,38,80,33s
2014.03.10 13:06:17 5: SW: 149,38,80,33s
Kann ich noch was testen?
@HCS:
Das habe ich garnicht mitbekommen das ursprünglich ein Fehler in der ID berechnung vorhanden ist.
Du meinstest:
msg->id |= (data[1] & 0xC0) >> 6;
Ich habe jetzt in Perl folgendes:
$addr = sprintf( "%02X", ((hex(substr($dmsg,3,2)) & 0x0F) << 2) | ((hex(substr($dmsg,5,2)) & 0xC0) >> 6) );
So ist es korrekt oder?
@HCS
Also ich habe jetzt mal einen Jeelink an FHEM als FakeSensor_14 definiert wie von dir vorgeschlagen.
Den anderen am Terminal: Dbug Modus ein.
Wenn ich am Terminal --> 149,38,34,33s sende, dann ist die Anzeige am Terminal:
Stop receiver
Sending data: 149 38 34 33 50
Start receiver
Am FHEM FakeSensor_14 passiert nichts.
DEF 14
IODev myJeeLink
NAME FakeSensor_14
NR 379
STATE ???
TYPE LaCrosse
addr 14
Was mache ich falsch?
Billy
Zitat von: Billy am 10 März 2014, 17:01:56
Stop receiver
Sending data: 149 38 34 33 50
Start receiver
Am FHEM FakeSensor_14 passiert nichts.
Der JeeLink könnte defekt sein (vertausche mal Sender und Empfänger)
Du musst mehrmals senden, dass FHEM etwas anzeigt, das liegt wohl am filterThreshold im LaCrosse Modul
Nachtrag:
Du hast die JeeLink nciht an einem Rechner direk nebeneinander stecken, oder?
Das würde eventuell den Empfänger so übersteuern, dass er nicht mehr klar kommt.
Was helfen würde ist die Ausgabe am Terminal des empfangenden JeeLink mit DEBUG=1
Zitat von: ulli am 10 März 2014, 13:24:59
@HCS:
Das habe ich garnicht mitbekommen das ursprünglich ein Fehler in der ID berechnung vorhanden ist.
Du meinstest:
msg->id |= (data[1] & 0xC0) >> 6;
Ich habe jetzt in Perl folgendes:
$addr = sprintf( "%02X", ((hex(substr($dmsg,3,2)) & 0x0F) << 2) | ((hex(substr($dmsg,5,2)) & 0xC0) >> 6) );
So ist es korrekt oder?
Ja, denke ich. Ich suche aber noch jemanden, der meine Ansicht über die 6 ID-Bits und deren decodierung teilt / bestätigt.
Der daten frame: SSSSDDDD DDN_TTTT usw.
Die D sind die ID des Sensors. Das sind 6 Bit die wie folgt als Byte zu decodieren sind: 00DDDDDD
also so:
msg->id = 0;
msg->id |= (data[0] & 0xF) << 2;
msg->id |= (data[1] & 0xC0) >> 6;
Richtig?
Zitat von: HCS am 10 März 2014, 17:16:18
Der JeeLink könnte defekt sein (vertausche mal Sender und Empfänger)
Du musst mehrmals senden, dass FHEM etwas anzeigt, das liegt wohl am filterThreshold im LaCrosse Modul
Nachtrag:
Du hast die JeeLink nciht an einem Rechner direk nebeneinander stecken, oder?
Das würde eventuell den Empfänger so übersteuern, dass er nicht mehr klar kommt.
Was helfen würde ist die Ausgabe am Terminal des empfangenden JeeLink mit DEBUG=1
Also ich habe einen jeelink am Ubuntu Rechner den anderen an Win7. Jeweils am Terminal mit Debug ein.
Die Logs sind in Anlage.
Vielleicht kannst du was erkennen.
Kann mir nicht vorstellen dass beide Jeelink defekt sind! Beide empfangen alle meine Sensoren einwandfrei.
Gruss
Billy
Was mich an den Logs wundert:
Ist [LaCrosseITPlusReader.10.0d] die Antwort auf ein v?
Das sollte eigentlich so aussehen: [LaCrosseITPlusReader.10.0d @17.241 kbps]
Was sendet Du denn an den JeeLink, dass die Hilfe so oft ausgegeben wird?
Wo kommt der ganze Datenschrott her?
Also die alle:
End receiving, HEX raw data: 83 CC 52 CA C5
## CRC FAIL ##
Bist Du sicher, dass der Sketch richtig übertragen ist?
Welches Board hast Du eingestellt?
ZitatIst [LaCrosseITPlusReader.10.0d] die Antwort auf ein v?
Nein, v bringt bei beiden [LaCrosseITPlusReader.10.0d @17.241 kbps]<\r>
ZitatWas sendet Du denn an den JeeLink, dass die Hilfe so oft ausgegeben wird?
Wenn ich b sende kommt [LaCrosseITPlusReader.10.0d] und dann die Hilfe.
ZitatWo kommt der ganze Datenschrott her?
Also die alle:
End receiving, HEX raw data: 83 CC 52 CA C5
## CRC FAIL ##
Frage mich nicht kommt sobald ich debugging einschalte.
ZitatBist Du sicher, dass der Sketch richtig übertragen ist?
Nehme ich an, da alle meine Sensoren richtig anzeigen und funktionieren.
ZitatWelches Board hast Du eingestellt?
Schon immer uno
Auch mein PCA301 sketch läuft hervorragend. Übrigens auf einem anderen BBB damit da nicht passiert.
Billy
Übrigens wenn ich 33x sende kommt folgendes am Terminal!
Sending data: 149 39 48 33 195 <\r>
Stop receiver
End receiving, HEX raw data: 0 0 0 0 0
## UNSUPPORTED START ##
Start receiver
Warum schickst du b raus?
Ich bekam die Versionsinfo angezeigt, als ich die Luftfeuchtigkeit falsch (mit %) ausgesendet habe.
Kann es sein, dass die Wetterstation die Luftfeuchte nicht mag? Der sensor, der dabei war, hat dieses feature nicht.
Was wird von Temperatur only sensoren rausgeschickt? Minus 41 grad?
Gesendet von meinem Xperia Pro mit Tapatalk
Langsam gehen mir die Ideen aus ...
Die Senderei sieht im Log korrekt aus.
Irgend etwas muss doch bei Dir anders sein, als bei mir und JoeALLb
Das Pairing-Problem mit der WS ist dann nochmal ein weiteres, aber senden kann er ja, wie er berichtet.
Zitat von: JoeALLb am 10 März 2014, 21:53:21
Kann es sein, dass die Wetterstation die Luftfeuchte nicht mag? Der sensor, der dabei war, hat dieses feature nicht.
Was wird von Temperatur only sensoren rausgeschickt? Minus 41 grad?
Ich glaube die senden 106 als Feuchte.
Kannst ja mal 149,38,34,106s versuchen
@JoeALLb
ZitatWarum schickst du b raus?
Ich bekam die Versionsinfo angezeigt, als ich die Luftfeuchtigkeit falsch (mit %) ausgesendet habe.
Kann es sein, dass die Wetterstation die Luftfeuchte nicht mag? Der sensor, der dabei war, hat dieses feature nicht.
Darum geht es doch garnicht. ;)
Solange auf der Terminalebene die beiden Jeelink nicht sauber miteinander reden lässt sich das Verhalten zur Wetterstation
schlecht analysieren.
Tatsache ist, dass das was der eine jeelink sendet vom andern zumindest bei mir nicht empfangen wird. (Und umgekehrt)
Während das was die Sensoren aussenden sofort empfangen und decodiert wird.
Ich werde mich jetzt mal wieder eine Weile ausklinken aber den ja von mir eröffneten Thread weiter beobachten.
Danke für eure Unterstützung.
Billy
Anbei ein neuer Versuch. Ich glaube, dass der Frequenzhub beim Senden zu gering war. Habe ihn mal auf 90 kHz hochgesetzt.
Ich vermute, dass das das Pairing-Problem mit der WS nicht löst, aber vielleich geht nun bei Billy die JeeLink zu JeeLink Kommuniktion.
@HCS
ZitatIch vermute, dass das das Pairing-Problem mit der WS nicht löst, aber vielleich geht nun bei Billy die JeeLink zu JeeLink Kommuniktion.
Doch beides gelöst!!! :D
Well done.
Mit 4 sec Wiederholzeit hält auch die Anzeige in der Wetterstation.
Wenn ich 149,38,34,33s übers Terminal absetzte. -->
Anzeige 22.2°C Die Anzeige der WS-9140IT kann nur Temperatur!
Gruss Billy
Na dann bin ich mal gespannt, ob es bei JoeALLb auch funktioniert oder ob es bei ihm jetzt nicht mehr geht :D
kannst du bitte noch mal schauen ob send auch geht? und wie oft mindestens gesendet werden muss damit die anzeige nicht verloren geht?
ich würde dann das automatische senden einbauen und je ein set für temperatur und feuchte.
dann kann mit mit einem einfachen notify das set triggern und das senden geht automatisch.
gruss
andre
Mit der Wiederholzeit muss ich noch spielen.ZitatMit 4 sec Wiederholzeit
Bin jetzt mal auf 5s weil bei 4 sec war nach ca. 5 Minuten Schluss!
Aber wir dind jetzt auf dem richtigen Weg.
Werde das morgen mal über längere Zeit austesten.
Billy
@Andre
Zitatund wie oft mindestens gesendet werden muss damit die anzeige nicht verloren geht?
Siehe oben mit 4-5 sec aber das ist noch nicht ganz sauber. Da brauche ich länger zum Test.
Zitatkannst du bitte noch mal schauen ob send auch geht?
Da gehe ich morgen ran dafür möchte ich mir genügend Zeit nehmen.
Ausserdem habe ich meine Jeelinks gerade noch beide am Terminal. ;)
Gruss
Billy
Geht das nun von terminal. zu terminal?
ZitatGeht das nun von terminal. zu terminal?
Ja hatte ich doch oben schon geschrieben!
Doch beides gelöst!!!
Well done.Billy
Nur ganz kurz noch.
Der Wert in der Anzeige der WS lässt sich im Moment nicht ändern.
d.h. Der gesendete wert wird nach einlegen der Batterien in die WS zwar sofort angezeigt, bleibt dann aber auf diesem wert
selbst wenn ich den Sendewert im Terminal verändere. :-\
Aber vielleicht geht da noch was?
Zitatass der Frequenzhub beim Senden zu gering war. Habe ihn mal auf 90 kHz hochgesetzt.
Könnte es daran noch liegen?
Billy
@billy: das war ja genau das problem, das ich auch hatte, genannt "das pairing problem". Schade, ich hoffte dass wir auch hier etwas weiter sind.
Aber was kann es sein, wenn wir genau das selbe aussenden wie ein sensor?
Hat jnemand mal mitprotokolliert, nach wievielen sendevorgangen der original sensor das batteryflag nicht mehr mitsendet?
@andre: könntest du in die sendmethode noch eine Möglichkeit einbauen, wahlweise mit oder ohne batteryflag zu senden?
Gesendet von meinem Xperia Pro mit Tapatalk
@JoeALLb
ZitatHat jnemand mal mitprotokolliert, nach wievielen sendevorgangen der original sensor das batteryflag nicht mehr mitsendet?
Diese Frage hatte ich hier schon öfters beantwortet. :(
Siehe hier. http://gcrnet.net/node/32 --> To help pairing, a flag telling the transmitter is in this pairing phase is set during approximately
4h30mn.Zitat@andre: könntest du in die sendmethode noch eine Möglichkeit einbauen, wahlweise mit oder ohne batteryflag zu senden?
Bin überzeugt dass wir damit im Moment nicht weiterkommen. Das habe ich schon vom Terminal aus getestet,
ohne Flag wird garnichts angezeigt. d.h. Eingabe von 149,6,34,33s: ID=20, 22.2 °C, 33% Feuchte, NewBattaryFlag NICHT gesetzt
@HCS
Ich vermute ganz stark ein Timing Problem! Könnte es sein, dass das durch das Umschalten im Sketch zwischen Senden und
Empfangen verursacht wird?Die original Sensoren senden etwa im 4,34 sec Takt.
Im debug Modus sieht das für den Jeelink Sender mit 33x so aus.
Sending data: 149 39 48 33 195
Stop receiver
End receiving, HEX raw data: 0 0 0 0 0
## UNSUPPORTED START ##
Start receiver
Sending data: 149 39 48 33 195
Stop receiver
End receiving, HEX raw data: 0 0 0 0 0
## UNSUPPORTED START ##
Start receiver
Die Original Sensoren sind ja nur im Sendebetrieb! Während wir den Jeelink toggeln was zu dem Timing Problem führen könnte?
Gruss
Billy
Zitat von: Billy am 12 März 2014, 08:08:40
To help pairing, a flag telling the transmitter is in this pairing phase is set during approximately 4h30mn.Bin überzeugt dass wir damit im Moment nicht weiterkommen.
Meine Frage war aber: Wie oft? 270/4.34=62.211, also wird 62mal gesendet, oder öfter?
Mich würde auch interessieren: Wird 62 mal der selbe Wert gesendet, oder passt sich dieser der Temperatur an?
Es könnte ja auch sein, dass zu einem erfolgreichen pairing eine bestimmte Temperaturkombination gesendet werden muss, also einmal 22° und als Bestätigung
ein anderer Wert? Oder eben exakt der selbe Wert 62mal?
@JoeALLb
Für mich rechnet sich das so! ;)
4,5 h sind 4,5 x 3600 sec = 16200 sec. --> ergibt 16200:4,34= rund 3732 mal wird in 4,5h gesendet.
Deine anderen Fragen verstehe ich nicht. ;)
Aber ich schlage dir vor teste mal selbst mit einem vernünftigen Terminalprogramm, dann beantwortet sich vieles von selbst.
Billy
Wie schon gesagt, bei mir in der gegend gibt es über 20 Sensoren, da fällt es mir schwer, einen Sensor über 4.5h zu monitoren, ohne die anderen Daten mitzuprotokollieren.
Wie auch immer: Gesucht wird die Methode, wie die Sensoren sich mit der Wetterstation komplett pairen, bzw. was nach dem erstmaligen Anzeigen der Temperaturwerte passiert. Und dafür sind Ideen gesucht , oder?
Um geanu zu loggen, was der Sensor sendet, gibt es im letzten Sketch das Setting ANALYZE_FRAMES. Wenn man es auf 1 setzt, werden auf der seriellen Schnittstelle detaillierte Informationene zu jedem empfangenen frame ausgegeben. In diesem Modus funkitionert der Sketch nicht mit FHEM zusammen. Da sieht man dann z.B. auch, ob das NewBatt flag gesetzt ist.
Also: Sketch mit dieser Einstellung flashen, Terminal-Programm starten und dann die Batterie in den Sensor rein und mal einige Zeit loggen. Am besten mit dem Laptop, JeeLink und Sensor draußen im Wald, wo sonst nichts sendet ;D
Vielleicht lässt sich damit irgend eine Pairing-Magic erkennen.
// --- Configuration ---------------------------------------------------------
bool DEBUG = 0; // set to 1 to see debug messages
bool ENABLE_ACTIVITY_LED = 1; // set to 0 if the blue LED bothers
int DATA_RATE = DATA_RATE_17; // use one of the data rates defined above
int TOGGLE_DATA_RATE = 0; // 0=no toggle, else interval in seconds
bool RECEIVER_ENABLED = 1; // Set to 0 if you don't want to receive
bool ANALYZE_FRAMES = 1; // Set to 1 to display analyzed frame data instead of the normal data
bool USE_CORRECT_ID = 1; // Set to 0 to be compatible with earlier versions
Zitat von: JoeALLb am 12 März 2014, 08:15:56
Mich würde auch interessieren: Wird 62 mal der selbe Wert gesendet, oder passt sich dieser der Temperatur an?
Es könnte ja auch sein, dass zu einem erfolgreichen pairing eine bestimmte Temperaturkombination gesendet werden muss, also einmal 22° und als Bestätigung
ein anderer Wert? Oder eben exakt der selbe Wert 62mal?
Das war auch mein Gedanke, so etwas in der Art könnte es sein. Möglicherweise hat die WS irgend welche Plausibilitätskontrollen, die nach dem Abschluss des Pairings aktiv werden. Z.B. "Temperatur kann sich nicht innnerhalb von einigen Sekunden um mehrere Grad geändert haben". Oder was auch immer ...
Wenn Du verschiedene Werte an die WS sendest,
solange diese noch im Pairing-Mode ist, werden die dann jeweils angezeigt?
Timing der Aussendungen glaube ich eher nicht. Es kann ja durchaus vorkommen, dass die WS eine Aussendung des Sensors mal verpasst, weil er von einem anderen Sender niedergemacht wird. Und ich glaube nicht, dass das Timing der Sensoren über Tage und Wochen hinweg auf die Millisekunde ganau ist.
Zitat von: HCS am 12 März 2014, 09:12:33
Wenn Du verschiedene Werte an die WS sendest, solange diese noch im Pairing-Mode ist, werden die dann jeweils angezeigt?
nein, ich habe keine einzige Änderung der Anzeige jemals geschafft, ausser durch das neu einlegen der Batterie in der WS.
Vielleicht sendet der Sensor im Battery-Modus auch alternierend ein bestimmte temperatur, beispielsweise wenn 22° gemessen werden,
dann 22° und danach (max-22°). Dies könnte man mit solch einem Mitschnitt vermutlich prüfen.
Wohnt jemand im Wald, der einen Mitschnitt ohne störende Sensoren von Nachbarn aufzeichnen kann?
Ich könnte ja mal versuchen, die ID eines schon länger gepairten Sensors zu "kapern" und andere Messwerte zu senden, das sollte doch zu
einer Änderung der Anzeige führen, oder? Ich werde das zuhause versuchen.
Zitat von: JoeALLb am 12 März 2014, 09:21:56
nein, ich habe keine einzige Änderung der Anzeige jemals geschafft, ausser durch das neu einlegen der Batterie in der WS.
Auch mit dem Sketch von gestern nicht?
Den muss ich noch aufspielen, bin auf dienstreise. Versuche es heute abend.
@HCS
ZitatUm geanu zu loggen, was der Sensor sendet, gibt es im letzten Sketch das Setting ANALYZE_FRAMES. Wenn man es auf 1 setzt, werden auf der seriellen Schnittstelle detaillierte Informationene zu jedem empfangenen frame ausgegeben. Da sieht man dann z.B. auch, ob das NewBatt flag gesetzt ist. Am besten mit dem Laptop, JeeLink und Sensor draußen im Wald, wo sonst nichts sendet
Siehe Log in Anlage für den TX29DTH-IT
Für TX37-IT in ca. 10 Minuten
Bin zwar nicht im Wald, aber dein Sketch ist super.
Billy
@HCS
Jetzt noch für TX37-IT
@HCS
Wenn ich vom anderen Jeelink alle 4,3 sec 21x sende sieht das so aus!
Anlage
Übrigens die Erfahrung von JoeALLb
Zitatnein, ich habe keine einzige Änderung der Anzeige jemals geschafft, ausser durch das neu einlegen der Batterie in der WS.
kann ich voll bestätigen.
Billy
Kann es sein, dass sich der jeelink selbst empfängt?
Seit dem Update auf den neuen Sketch bekomme
ich immer die Fehlermeldung des "Unknown device 0D".
Diese Meldung war zuvor NIEMALS im Log enthalten!
Irgendwie bekomme ich mit dem neuen Sketch nur sehr schwer die Werte auf die Wetterstation.
Bei 6 Versuchen haben nur 2 geklappt. Letztens mit dem älteren Sketch hat von 6 versuchen 5 geklappt.
Kann die neue Flanke auch sich negativ auswirken? Oder habe ich immer gerate die falsche Frequenz benutzt,
da ich (wie gestern auch) toggle aktiviert habe.
2014.03.12 19:07:05 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:07:22 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:07:24 5: SW: 149,39,48,106s
2014.03.12 19:07:25 5: SW: 149,39,48,106s
2014.03.12 19:07:35 5: SW: 149,39,48,106s
2014.03.12 19:07:39 5: SW: 149,39,48,33s
2014.03.12 19:07:41 5: SW: 149,39,48,33s
2014.03.12 19:07:45 5: SW: 149,39,32,32s
2014.03.12 19:07:46 5: SW: 149,39,32,32s
2014.03.12 19:07:46 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:07:48 5: SW: 149,39,32,32s
2014.03.12 19:07:52 5: SW: 149,39,32,32s
2014.03.12 19:07:53 5: SW: 149,39,32,32s
2014.03.12 19:07:55 5: SW: 149,39,32,32s
2014.03.12 19:07:58 5: SW: 149,39,32,32s
2014.03.12 19:07:59 5: SW: 149,39,32,32s
2014.03.12 19:08:03 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:08:19 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:08:20 5: SW: 149,39,32,32s
2014.03.12 19:08:22 5: SW: 149,39,32,32s
2014.03.12 19:08:23 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:08:25 5: SW: 149,39,32,32s
2014.03.12 19:08:29 5: SW: 149,39,32,32s
2014.03.12 19:08:37 5: SW: 149,39,32,32s
2014.03.12 19:08:38 5: SW: 149,39,32,32s
2014.03.12 19:08:39 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:08:41 5: SW: 149,39,32,32s
2014.03.12 19:08:42 5: SW: 149,39,32,32s
2014.03.12 19:08:43 5: SW: 149,39,32,32s
2014.03.12 19:09:04 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:09:20 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:09:24 5: SW: 149,39,32,32s
2014.03.12 19:09:35 5: SW: 149,39,32,32s
2014.03.12 19:09:37 5: SW: 149,39,32,32s
2014.03.12 19:09:39 5: SW: 149,39,32,32s
2014.03.12 19:09:40 5: SW: 149,39,32,32s
2014.03.12 19:09:45 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:09:57 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:10:02 3: LaCrosse Unknown device 0D, please define it
2014.03.12 19:10:06 3: LaCrosse Unknown device 0D, please define it
Gilt für den Jeelink auch dieses Datenpaketlimit?
Wo ist das programmatisch hinterlegt?
Im Sketch konnte ich das nicht finden...
JeeLink TRANSMIT LIMIT EXCEEDED
ja das limit gilt auch. es ist im fhem modul hinterlegt.
wobei es nur eine warnung ausspuckt und trozdem noch sendet.
gruss
andre
@Billy: die Logs zeigen absolut nichts, was auf eine bestimmte Taktik beim Pairing hinweisen würde. Die Sensoren senden einfach so vor sich hin, mit gesetztem NewBatt Flag.
Und die empfangenen Daten, die Du von dem anderen JeeLink aus gesendet hast, sind auch tadellos.
Das wird noch spanned, herauszufinden, was die Station von uns haben will.
Zitat von: JoeALLb am 12 März 2014, 19:16:58
Kann es sein, dass sich der jeelink selbst empfängt?
Nein. Und du sendest ja auch nicht die ID 0D sondern die 14.
Zitat von: JoeALLb am 12 März 2014, 19:16:58
Irgendwie bekomme ich mit dem neuen Sketch nur sehr schwer die Werte auf die Wetterstation.
Bei 6 Versuchen haben nur 2 geklappt. Letztens mit dem älteren Sketch hat von 6 versuchen 5 geklappt.
Kann die neue Flanke auch sich negativ auswirken? Oder habe ich immer gerate die falsche Frequenz benutzt,
da ich (wie gestern auch) toggle aktiviert habe.
Den toggle der data rate solltest Du bei Sende-Experimenten abstellen, sonst sendest Du ja die Hälfte der Zeit mit der falschen Datenrate, die die WS garantiert nicht versteht. Also TOGGLE_DATA_RATE = 0;
@HCS
ZitatUnd die empfangenen Daten, die Du von dem anderen JeeLink aus gesendet hast, sind auch tadellos.
Das wird noch spanned, herauszufinden, was die Station von uns haben will.
Das stimmt.Ich tippe immer noch auf das timing.
Hintergrund: Ich habe einen Sensor der von Anfang an die Macke hatte, dass er sich nach dem Einlegen der Batterien
immer mit der ID 08 anmeldet.
d.h. die ID nie wechselt.Wenn ich also zur WS eine einwandfrei Verbindung habe und die Batterien vom Sensor herausnehme und warte bis die WS
Sensorverlust anzeigt (Sendersymbol geht aus) und dann die Batterien wieder einlege wird der Datenempfang trotz gleicher
ID nicht wieder aufgenommen.
Ziemlich langer Satz hoffentlich zu begreifen.
Deshalb vermute ich dass die WS möglicherweise die Pulse Repetition Frequency PRF misst?
Wie gesagt nur eine Vermutung.
Guten abend
Billy
Wenn Du folgendes einstellst:
Empfangen deaktivieren, feste data rate
DATA_RATE = DATA_RATE_17;
TOGGLE_DATA_RATE = 0;
RECEIVER_ENABLED = 0;
geht bei einem b1,b2,b3,b4s oder <n>x Command das Datenpaket fast ohne Verzug raus.
Zitatgeht bei einem b1,b2,b3,b4s oder <n>x Command das Datenpaket fast ohne Verzug raus.
Gehe ich morgen mal ran. 8)
Danke
Billy
Ich habe die WS ausgetrickst. ;)
Es ist definitiv ein Timing Problem!
Nach dem ich die IT+ Schnittstelle schon vor mehr als 2 Jahren mit dem Jeelink decodiert hatte,
habe ich mich daran erinnert dass es da im Netz noch was zu den Wetterstationen gab!
http://fredboboss.free.fr/tx29/tx29_hw.php?lang=en
Hier wird das Verhalten der WS detailliert beschrieben.
Die WS hat demnach 3 Phasen.
1.Boot phase
2.Acquisition phase :
3.Powersaving phase :
Wir treffen m.E. bisher nur die Acquisition phase : deswegen wird der Wert nur 1 mal angenommen.
Ich habe die WS ausgetrickst indem ich alle 0,1 sec gesendet habe!
Damit habe ich immer wohl den Slot im Zeitfenster der Powersaving phase getroffen.
Das ist zwar sicher keine endgültige Lösung, aber jetzt haben wir einen Ansatz.
Mit diesem Verfahren konnte ich auch die Temperaturwerte ändern. Im Beispiel von 33° bis zu 99°C.
Man kann damit jeden Temperaturwert einstellen.
In Anlage auch ein Bild der WS das die Min / Max entsprechend anzeigt.
(http://station.jpg)
Damit ist auch bewiesen, dass die normale Beschränkung der IT+ Sensoren von 59,5 °C nichts mit der WS zu tun hat. :D
Ich hoffe das bringt uns weiter und einer der Stars hier kann aus dem Link noch mehr heraus lesen.
Billy
wenn das timing so kritisch ist würde ich vorschlagen das senden mit dem richtigen timing im sketch zu machen und von fhem modul jeweils nur die werte im sketch zu setzen. das sollte die fhem seite deutlich entlasten und das ganze stabiler machen.
gruss
andre
Das sehe ich auch so.
Könnte das eventuell bedeuten, dass man mit dem Jeelink dann nicht mehr empfangen kann?
Gruss
Billy
Zitat von: Billy am 12 März 2014, 21:57:23
Wenn ich also zur WS eine einwandfrei Verbindung habe und die Batterien vom Sensor herausnehme und warte bis die WS
Sensorverlust anzeigt (Sendersymbol geht aus) und dann die Batterien wieder einlege wird der Datenempfang trotz gleicher
ID nicht wieder aufgenommen.
In diesem Fall sendet er aber das Battery-Flag wieder mit.
Das sollte die WS auch ignorieren!
Ich denke schon, dass nach einem erfolgreichen Peering auch größere Sendeabstände <> 4s möglich sind. Ich denke da an Sensoren, deren Batterien leer sind.
Das habe ich regelmäßig dass im Winter bei <-15° mal ein Außensensor nicht mehr empfangen wird, weil hier die Batterie zu schwach wird. Wenn es dann wieder wärmer wird, werden seine Daten auch plötzlich wieder empfangen.
Zitat von: Billy am 13 März 2014, 12:06:16
Ich habe die WS ausgetrickst. ;)
Cool. Ich beschäftige mich heute Abend mal mit der Problamatik.
Eine Frage noch. Funktioniert das auch über einen längeren Zeitraum, also 1 Stunde oder länger?
Ich werde, sofern ich dazu komme, heute Abend den ANALYZE_FRAMES mode ändern. dass er in der ersten Spalte kleinere Einheiten als Sekunden anzeigt. Dann können wir exakt loggen, mit welchem Timing die verschiedenen Sensoren senden.
Zitat von: HCS am 13 März 2014, 13:57:55
Eine Frage noch. Funktioniert das auch über einen längeren Zeitraum, also 1 Stunde oder länger?
Ja das funktioniert beliebig lange und ich kann auf andere Werte umändern solage die Pausen nicht zu groß werden.
In meinem obigen Link ist dieser Satz vielleicht der Schlüssel?
ZitatHypothesis : Every 4 seconds a radio signal is demodulated by the receiver and the demodulated bits are outputed on the data pin whereas the a clock signal is extrapolated from the received signal (may be by a PLL).
Würde eventuell bedeuten, dass man für die Synchronisation
noch ein clock signal braucht? :-\
Billy
Zitat von: Billy am 13 März 2014, 14:07:20
Ja das funktioniert beliebig lange und ich kann auf andere Werte umändern solage die Pausen nicht zu groß werden.
Prima.
Zitat von: Billy am 13 März 2014, 14:07:20
Würde eventuell bedeuten, dass man für die Synchronisation noch ein clock signal braucht? :-\
Nein. Das macht der RF12 schon. Wir bekommen ja die bytes vom RF12, da ist das Syncen auf AA,AA,AA,2D,D4 bereits erledigt und erfolgreich gewesen.
Zitat von: HCS am 13 März 2014, 14:40:17
Nein. Das macht der RF12 schon.
Könnte ja sein, dass die WS in der 3.Powersaving phase : einen Burst oder einen clock zum aufwachen braucht?
Aber du wirst es schon richten! ;D
Billy
Zitat von: HCS am 13 März 2014, 13:57:55
Ich werde, sofern ich dazu komme, heute Abend den ANALYZE_FRAMES mode ändern. dass er in der ersten Spalte kleinere Einheiten als Sekunden anzeigt. Dann können wir exakt loggen, mit welchem Timing die verschiedenen Sensoren senden.
Wenn du am Sketch was änderst wäre es zum Testen äußerst hilfreich wenn man im Sketch einen Wobbler aktivieren könnte. ;)
Temperatur reicht aus. Dann sieht man bei Temperaturänderung sofort ob man von der 2.Acquisition phase : schon in die 3.Powersaving phase : gekommen ist.
Wobbler in 1°C Schritten +- 10°C. zB. Start bei 30°C bis 40°C und wieder zurück.
Billy
Ich fände es schöner, wenn er die von fhem empfangenen Werte so lange wiederholt, bis fhem einen neuen wert schickt.
So könnte man schön ein Notify in FHEM machen, das jesde Sekunde einen höheren oder niedrigeren Wert schickt.
Dies wäre deutlich flexibler, denk ich.
Und man sollte ja nicht je jede 0.1 Sekunden eine andere Temperatur schicken....
Zitat von: JoeALLb am 13 März 2014, 15:45:17
Ich fände es schöner, wenn er die von fhem empfangenen Werte so lange wiederholt, bis fhem einen neuen wert schickt.
Noch sind wir in der frühen Testphase mit FHEM geht im Moment noch garnichts. ::)
Da muss ich im Sketch erst mal einiges umbauen. Der sieht dann langsam dem ursprünglichen Sketch kaum noch ähnlich. Ich hoffe, dass der urspüngliche Autor mich nicht steinigt.
@Billy: wie verhält sich das denn. Stehst Du mit dem noch in Kontakt? Ist das OK, wenn ich den Sketch langsam komplett umkremple?
Zitat von: HCS am 13 März 2014, 16:01:09
Da muss ich im Sketch erst mal einiges umbauen. Der sieht dann langsam dem ursprünglichen Sketch kaum noch ähnlich. Ich hoffe, dass der urspüngliche Autor mich nicht steinigt.
@Billy: wie verhält sich das denn. Stehst Du mit dem noch in Kontakt? Ist das OK, wenn ich den Sketch langsam komplett umkremple?
Begonnen hat das ganze ja mit meiner Idee Umsetzung durch
ohweh/Oliver --> LaCrosseITPlusReader05.ino
und justme1968/andre --> 36_JeeLink.pm und 36_LaCrosse.pm
Siehe auch erster Beitrag. Ich hatte Oliver auch einen Sensor zur Verfügung gestellt.
An das Thema an dem wir jetzt sind wollte er nicht ran.
So wie ich Oliver kennengelernt habe wird er uns nicht steinigen.Vielleicht braucht man endgültig sowieso 2 Sketche. ( Empfangen vom Sensor - Senden an WS )
Aber die letzten Tage haben mir gezeigt dass das ganze ohne vernünftige Testumgebung nicht sauber nachvollziehbar ist.
Gruss
Billy
@Andre
ZitatSo wie ich Oliver kennengelernt habe wird er uns nicht steinigen.
was meinst du dazu?
Gruss
Billy
natürlich hat er nichts gegen eine weiterentwicklung.
abgesehen davon verwendet er den sketch selber nicht weil er keine eigenen sensoren hat und er war hier auch schon eine ganze weile nicht mehr online.
gruss
andre
Einige Fragen, die mir noch unklar sind:
- Was passiert, wenn zwischendurch mal einige Minuten nicht gesendet wird, und es dann weiter geht (z.B. reboot server, auf dem der JeeLink steckt, usw.) Kannst Du das mal simulieren? Und Joe evtl. auch, um sicher zu sein, dass das nicht nur auf genau einer bestimmten WS geht?
- Soll für mehrere IDs gesendet werden, also mehrere Sensoren gleichzeitig simuliert werden? Das wird dann etwas hefig, wenn das in den Sketch rein soll.
- Prüfen, ob das sich mit dem Empfangen vereinbaren lässt. Ich denke schon, Senden kann Priorität haben, im schlimmsten Fall
verpasst man mal einen Sensor beim Empfangen, was nicht schlimm ist. Bei data rate toggle verpasst man auch 20 Sekunden lang einen Teil seiner Sensoren
Ich denke, dass folgende Vorgehensweise (in dieser Reihenfolge) Sinn macht:
- alle Sende-Tests vorerst von einem Terminal-Programm aus, um nicht ständig das FHEM-Modul nachziehen zu müssen, solange unklar ist, wie der Ablauf genau wird
- exakt ermitteln, in welchem Interval die verschiedenen Sensoren senden
- Test-Sendeschleife, die selbst eine Temperaturrampe fährt
- sicherstellen, dass bei einer kürzeren Unterbrechung der Aussendungen nicht ein neues Binden erforderlich ist
- sicherstellen, das mit einem korrekten Sende-Interval das ganze langzeitstabil (also mehrere Tage) ist
- sicherstellen, dass das nicht nur genau mit der einen WS von Billy funktioniert
- Test der Machbarkeit von Senden und Empfangen in einem Sketch
- ein Command im Sketch, um ID(Hex.), Interval(Sekunden / 10), NewBatt-Dauer(Minuten) und data rate festzulegen mit dem in Schleife gesendet wird
z.B, 14,43,20,0i
- Ein Command im Sketch, um die Werte, die die Schleife sendet, festzulegen (Temperatur 10er, 1er, 0.1 und Feuchte)
z.B, 2,6,5,48s
Der Ablauf, was an den Jee gesendet wird, wäre dann so:
Erst: 2,1,9,44s -> Temperatur, die die Send-Loop sendet, ist 21,9°C und Feuchte ist 44%
Dann: 14,43,20,0i -> ID 14, alle 4.3 Sekunden senden, nach 20 Minuten das NewBatt flag wegnehmen, mit 17.241 kbps senden
ab jetzt sendet die Loop auf dem Jee bis in alle Ewigkeit 21,9°C mit 44% und nimmt nach 20 Minuten das NeBattFlag weg
Dann: 2,6,5,48s -> Temperatur, die die Send-Loop ab sofort eigenständig sendet, ist 26,5°C und Feuchte ist 48%
Irgend wann mal: 2,7,3,51s -> Temperatur, die die Send-Loop ab sofort eigenständig sendet, ist 27,3°C und Feuchte ist 51%
usw.
usw.
Eventuell: 0i -> Senden beenden
- Implementierung der erforderlichen Funktionalitäten in FHEM
Ich bin leider ab übermorgen für 8 Tage auf Dienstreise, kann also nur noch morgen etwas testen uns dann später wieder.
Ich habe 2 verschiedene WS, die ich beide für den Test heranziehen kann. Den sinkenden WAF nehme ich in kauf ;-)
Ich habe mal die Zykluszeiten meiner Sensoren ermittelt. Das ist interessant. Die drei TX29DTH haben jeder eine andere Zeit, die der jeweilige Sensor aber bis auf +- eine Millisekunde konstant hält. Die beiden TX35DTH haben beide genau 5 Sekunden.
TX29DTH: 4,438s / 4,125s / 4,375s
TX35DTH: 5,000s / 5,000s
Eventuell ermittelt die Station beim Pairing oder auch noch danach die Zeit zwischen den letzten Aussendungen des Sensors, um zu wissen, wann sie den Empfänger wieder auf machen muss, nachdem sie einen frame empfangen hat.
Zitat von: JoeALLb am 13 März 2014, 22:07:38
Ich bin leider ab übermorgen für 8 Tage auf Dienstreise, kann also nur noch morgen etwas testen uns dann später wieder.
Ich habe 2 verschiedene WS, die ich beide für den Test heranziehen kann. Den sinkenden WAF nehme ich in kauf ;-)
Eilt auch nicht so. Das "Senden Thema" ist ja schon seit Mitte 2013 offen, da kommt es auf zwei Wochen mehr auch nicht an.
Außerdem muss ich mal zwischendurch noch andere Dinge erledigen.
Zumindest sind wir auf einem Weg, der eine gewisse Chance auf Erfolg am Horizont erkennen lässt.
Zitat von: HCS am 13 März 2014, 22:02:50
Einige Fragen, die mir noch unklar sind:
- Was passiert, wenn zwischendurch mal einige Minuten nicht gesendet wird, und es dann weiter geht (z.B. reboot server, auf dem der JeeLink steckt, usw.) Kannst Du das mal simulieren?
Ich werde das morgen erst mal mit dem TX37-IT Sensor nachvollziehen.
Aus meinetr Erfahrung ist mit dem Jeelink nach etwa 45 sec Schluss. Ist schwer zu testen, deshalb ja der Wobbler.
Denn an der WS bleibt die Anzeige noch stehen auch wenn die Verbindung/Pairing nicht mehr steht.
Zitat- Soll für mehrere IDs gesendet werden, also mehrere Sensoren gleichzeitig simuliert werden? Das wird dann etwas hefig, wenn das in den Sketch rein soll.
Wir sollten erstmal eine ID bedienen können. Ich glaube das wird schon heftig genug.
Zitat- alle Sende-Tests vorerst von einem Terminal-Programm aus, um nicht ständig das FHEM-Modul nachziehen zu müssen, solange unklar ist, wie der Ablauf genau wird
ok
Zitat- exakt ermitteln, in welchem Interval die verschiedenen Sensoren senden
ok wenn der Sketch das hergibt?
Zitat- Test-Sendeschleife, die selbst eine Temperaturrampe fährt
ok wenn der Sketch das hergibt?
Zitat- sicherstellen, dass bei einer kürzeren Unterbrechung der Aussendungen nicht ein neues Binden erforderlich ist
Das bestimmt m.E. die WS
Zitat- sicherstellen, dass das nicht nur genau mit der einen WS von Billy funktioniert
Da bin ich mir ziemlich sicher, dass das so ist, da ich schon mehrere Sensoren im Tausch an unterschiedlichen WS hatte.
Wenn wir soweit sind dann dürfte der Rest nur noch Kür sein.
Billy
Zitat von: HCS am 13 März 2014, 22:16:25
Eventuell ermittelt die Station beim Pairing oder auch noch danach die Zeit zwischen den letzten Aussendungen des Sensors, um zu wissen, wann sie den Empfänger wieder auf machen muss, nachdem sie einen frame empfangen hat.
Das hatte ich ja schon vermutet!
Zitatwhereas the a clock signal is extrapolated from the received signal (may be by a PLL).
Die Idee von meinem Link
Würde Sinn machen. d.H. Im Pairing Vorgang errechnet sich die WS aus der Sensor Zykluszeit den Slot für die nächste Empfangsbereitschaft.
Wäre Ziemlich klever. ;)
Billy
Ich habe aktuell TX35DTH-IT laufen und alles funktioniert gut. Nun wollte ich weitere kaufen und die TX35 sind aktuell nur recht teuer zu haben. Nun habe ich mich gefragt, ob
es noch andere kompatible gibt, die zu den geänderten Parametern vom TX35 passen? z.B. ein Gerät von TFA?
Es fehlt leider aktuell eine Übersicht der Geräte für LaCrosse.
Danke!
In Antwort #368 habe ich mal eine Liste angefangen. Da für die unteren beiden Sensoren niemand eine data rate genannt hat, kann ich momentan nur für den TX35DTH-IT mit Sicherheit sagen, dass er mit 9.579 kbps arbeitet.
Ich glaube, dass das LaCrosse Modul in FHEM bei negativen Temperaturwerten einen Fehler macht.
Es bekommt vom JeeLink "OK 9 20 1 3 187 77"
Das entspricht -4.5°C und 77% Luftfeuchte
STATE zeigt aber "T: -4.4 H: 77"
Temperaturen unter Null werden immer 0.1°C zu niedrig angezeigt.
Der Sketch kann jetzt eigenständig in Schleife die Werte senden.
@Billy: Das könntest Du mal vom Terminalprogramm aus testen (Terminal->Terminal und Terminal->WS)
Alle Werte Dezimal, also dran denken, dass FHEM die IDs der Sensoren Hex verwaltet.
Der Sensor mit der ID 20 im Beispiel unten ist in FHEM mit addr 14 zu definieren
Die neuen commands:
<id>,<int>,<nbt>,<dr>i
----------------------
<id>: ID des Sensores
<int>: Interval (Sekunden * 10)
<nbt>: Minuten, nach denen das NewBatteryFlag weggenommen werden soll
<dr>: data rate (0=17.241 kbps, 1=9.579 kbps)
<t10>,<t1>,<t0>,<hum>c
----------------------
<t10>: Temperatur 10er Stelle (um negative Temperaturen zu senden 128 addieren)
<t1>: Temperatur 1er Stelle
<t0>: Temperatur 10tel
<hum>: Feuchte
Sobald die Sendeschleife mit dem i Command initialisiert ist, sendet sie eigenständig mit dem angegeben Interval
Mit dem c command kann jederzeit ein neuer Wert gesetzt werden, denn die Sendeschleife dann ab sofort verwendet
Ablauf:
20,43,20,0i -> ID 20, alle 4.3 Sekunden senden, nach 20 Minuten das NewBatteryFlag wegnehmen, mit 17.241 kbps senden
2,6,5,48c -> Temperatur, die die Send-Loop ab sofort eigenständig sendet, ist 26,5°C und Feuchte ist 48%
2,7,3,51c -> Temperatur, die die Send-Loop ab sofort eigenständig sendet, ist 27,3°C und Feuchte ist 51%
129,4,5,77c -> Temperatur, die die Send-Loop ab sofort eigenständig sendet, ist -14,5°C und Feuchte ist 77%
128,4,5,77c -> Temperatur, die die Send-Loop ab sofort eigenständig sendet, ist -4,5°C und Feuchte ist 77%
0i -> Sendeschleife stoppen
Könnte man im Sketch auch mit zurückgeben, mit welcher Frequenz ein Paket gerade empfangen wurde?
Dann könnte Andre das beim Device mit anzeigen und wir könnten die Liste mit den kompatiblen Devices leichter vervollständigen...
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: JoeALLb am 16 März 2014, 10:44:32
Könnte man im Sketch auch mit zurückgeben, mit welcher Frequenz ein Paket gerade empfangen wurde?
Generell ja, aber das würde eine Erweiterung des Protokolls zwischen Sketch und FHEM bedeuten.
Ich denke, dass das Hauptproblem darin liegt, dass jemand, der einen neuen Sensor zum Laufen gebracht hat, das hier nicht zurückmeldet.
Ich vermute, andre könnte das Modul so schreiben, es egal ist ob die Frequenz hinten mitgesungen wird oder nicht...
Du wirst recht haben dass es nicht alle melden, aber wir haben ja auch schon einige Sensoren am Start...
Ich finde die Liste auch im Wiki passender als hier in einem Kommentar....
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: JoeALLb am 16 März 2014, 11:11:58Ich finde die Liste auch im Wiki passender als hier in einem Kommentar....
Ja, nur wie kommt sie ins wiki? ;)
Kann man eigentlich auch die sendestärke einstellen?
Gesendet von meinem Xperia Pro mit Tapatalk
Zitat von: HCS am 16 März 2014, 08:56:29
Der Sketch kann jetzt eigenständig in Schleife die Werte senden.
@Billy: Das könntest Du mal vom Terminalprogramm aus testen (Terminal->Terminal und Terminal->WS)
Erstmals vielen dank für deine Arbeit.
Eine erster Test zeigt leider keinen Erfolg! :(
Nach ca. 4 Min geht die Empfangs-anzeige an der WS aus!
Kann es sein, dass da der WS noch auf der HF seite was fehlt? Burst zum aufwecken etc.
Vielleicht hilft ein Spektrumanalizer? Habe ich aber keinen.
Leider habe ich heute nur eine beschränkte Zeit zum testen.
Gruß Billy
Ich habe das selbe Phänomen. Ich sende jetzt zyklisch das Kommando alle 4 Sekunden. Nach einer Zeit von 10sec ändere ich die Temperatur.
Was sehe ich auf der WS:
Das Paaren funktioniert auf anhieb. D.h. einmal wird die Temperatur angezeigt. Ich habe dann aber den Eindruck das nichts mehr von der WS empfangen wird.
Weil sich die Temperatur nie ändert und nach kurzer Zeit das Symbol für den Empfang verschwindet und am Ende keine Temperatur mehr angezeigt wird.
Zitat von: JoeALLb am 16 März 2014, 11:18:20
Kann man eigentlich auch die sendestärke einstellen?
Die Sendestärke ist einstellbar ja
Tja, eine neue Runde Ratlosigkeit.
Mal die Fakten zusammengefasst:
- Ein zweiter JeeLink empfängt stundenlang die ausgesendeten Daten, raus gehen sie also
- Die WS zeigt die gesendeten Daten im Pairing Mode an, sind sind also korrekt
- Ein Log von einem Sensor zeigt, dass er vom Beginn an einfach Daten sendet, nur das NewBatteryFlag geht nach einigen Stunden weg. Da ist keine Magic zu erkennen
- Billy hat im 0,1 Sekunden Takt gesendet und damit über längere Zeit verschiedene Werte anzeigen können
- Meine drei TX29DTH haben ein leicht unterschiedliches Timing, das sie aber jeweils konstant halten
Zitat von: Billy am 16 März 2014, 14:03:16
Kann es sein, dass da der WS noch auf der HF seite was fehlt? Burst zum aufwecken etc.
Falls ja, dann wie? Und, wenn der Empfänger der WS aus ist, wie soll sie den dann empfangen?
Zitat von: HCS am 16 März 2014, 16:54:57
Tja, eine neue Runde Ratlosigkeit.
- Billy hat im 0,1 Sekunden Takt gesendet und damit über längere Zeit verschiedene Werte anzeigen können
- Meine drei TX29DTH haben ein leicht unterschiedliches Timing, das sie aber jeweils konstant halten
Kann es sein, dass da der WS noch auf der HF seite was fehlt? Burst zum aufwecken etc.
Falls ja, dann wie? Und, wenn der Empfänger der WS aus ist, wie soll sie den dann empfangen?
Ich gehe jetzt mal 1 Woche in den Urlaub. ;)
Wenn ich wiederkomme werde ich mal versuchen einen Sensor zu öffnen und mit dem Oszi zu schauen ob ich was finde?
Was besseres fällt mir im Augenblick nicht ein. :-\
Gruß Billy
Schönen Urlaub.
Ich denke auch, dass man ermitteln muss, was die Sender wirklich tun und das eher am Sender herausbekommt.
Kurze Frage zum Thema Temperaturen und resolution 5.
Ich habe für meine TX * resolution 5 in die fhem.cfg geschrieben, weil Sie immer um 0.1 geschwankt sind.
Also z.B.:
20.2 C
20.3 C
20.2 C
20.3 C
20.2 C
20.3 C
nachdem ich nun resolution 5 gesetzt habe, sieht es wie folgt aus:
20.0 C
20.5 C
20.0 C
20.5 C
20.0 C
20.5 C
20.0 C
20.5 C
ist das richtig so? Ich dachte es wird gerundet auf 20.0?
Kurze Frage, mit diesem Sketch
https://github.com/SevenW/wirelessweather
lassen sich sowohl LaCrosse It+ Sensoren als auch Fine Offset Sensoren auslesen, die sehr verbreitet sind. Könnte das dann auch mit dem JeeLik Modul funktionieren?
Da steht wohl auch noch einiges dazu:
http://fredboboss.free.fr/tx29/index.php?lang=en
mit 5 wird auf das nächste vielfache von 0.5 grad gerundet. wenns auf 1 grad runden willst musst du 10 setzen.
du solltest das mitteln zusätzlich aktivieren.
gruss
andre
Zitat von: Aeroschmelz am 23 März 2014, 13:49:28
Kurze Frage, mit diesem Sketch
https://github.com/SevenW/wirelessweather
lassen sich sowohl LaCrosse It+ Sensoren als auch Fine Offset Sensoren auslesen, die sehr verbreitet sind. Könnte das dann auch mit dem JeeLik Modul funktionieren?
In dem verlinkten Sketch sehe ich nichts, was LaCross IT+ Sensoren verarbeiten könnte. Der kann nur WS3000 und WS4000. Die empfangenen Frames haben auch einen anderen Aufbau, da Wind und Regen mit drin ist. Und Fine Offset kann er wohl nur die WH1080. Die LaCrosse It+ wie z.B. TX29DTH sind etwas anderes.
Zitat von: HCS am 16 März 2014, 08:10:49
Ich glaube, dass das LaCrosse Modul in FHEM bei negativen Temperaturwerten einen Fehler macht.
Es bekommt vom JeeLink "OK 9 20 1 3 187 77"
Das entspricht -4.5°C und 77% Luftfeuchte
STATE zeigt aber "T: -4.4 H: 77"
Temperaturen unter Null werden immer 0.1°C zu niedrig angezeigt.
@justme1968: kannst Du bitte mal noch das "0.1°C Thema" anschauen?
Zitat von: HCS am 23 März 2014, 19:17:36
In dem verlinkten Sketch sehe ich nichts, was LaCross IT+ Sensoren verarbeiten könnte. Der kann nur WS3000 und WS4000. Die empfangenen Frames haben auch einen anderen Aufbau, da Wind und Regen mit drin ist. Und Fine Offset kann er wohl nur die WH1080. Die LaCrosse It+ wie z.B. TX29DTH sind etwas anderes.
Stimmt, obwohl das in der Beschreibung behauptet wird, verstehe allerdings noch nicht so ganz die Organisation bei GitHub. Hier scheint wohl ein angepasster Sketch mit dem gleichen Namen und mehr Fiunktionen zu sein
https://github.com/rinie/weatherstationFSK
Im Code wird dann zumindest der TX29 erwähnt...
Hallo guten Abend,
ich habe seit 5 Monaten einen TX 29 am Start und er läuft bestens. Nun möchte ich gerne erweitern.
Leider habe ich keine Zusammenfassung gefunden welche Geräte nun "sicher" funktionieren.
Würde der Funk-Außensensor TX29DTH-IT oder Funk-Außensensor TX35D-TH funktionieren ohne dass ich etwas "Umbauen" muss? Also Batterie rein und wird erkannt wie der TX 29 IT.
Danke schon mal für Eure Hilfe!
Marko
PS: Könnt man evtl. mal eine Liste aller Sensoren erstellen die mit dem 36_LACrosse funktionieren und in den 1. Post einstellen? Ich hätte auch Interesse an Wind od. Regensensoren.
die wind und regen sensoren werden vermutlich noch nicht funktionieren. bis jetzt hatte noch niemand welche zum probieren. ich vermute im sketch muss die nachricht angepasst werden.
im fhem modul sind im prinzup die type bits in der nachricht schon dazu vorgesehen. da müsste es dann auch entsprechend erweitert werden.
gruss
andre
Hallo Andre,
danke für Deine Antwort. Ich werde mal wegen den Wind und Regensensoren schauen.
Die beiden Thermometer würden aber gehen ?
Marko
Zitat von: marko67 am 25 März 2014, 22:24:32
Würde der Funk-Außensensor TX29DTH-IT oder Funk-Außensensor TX35D-TH funktionieren ohne dass ich etwas "Umbauen" muss? Also Batterie rein und wird erkannt wie der TX 29 IT.
Wenn man die Suche in diesem Thread benutzt bekommt man die eindeutige Antwort --> ja! ;)
Gruß Billy
Hallo,
mich hat nun auch das FHEM-Fieber gepackt und ich möche Schritt für Schritt eine kleine Hausautomation aufbauen. Bisher habe ich meine Philips HUE Lampen + eine LivingColors dort eingebunden und gestern kam auch der Jeelink V3 an mit dem ich nun erfolgreich von einem schon vorhandenem TX-37-IT Modul die Temperatur auslesen konnte. Bisher habe ich schon viel über die Suche gefunden, aber für folgendes hab ich noch keine wirkliche Antwort.
Die blaue LED Leuchtet ca. alle 4 Sekunden einmal auf (Sendetakt vom Sensor), ist es möglich diese auszuschalten? Das kurze aufleuchten ist besonders Nachts echt verdammt hell. Wahrscheinlich muss ja was im Sketch geändert werden, hab dazu aber nichts gefunden. Ein paar Seiten vorher wurde diese Frage auch schon einmal gestellt, aber nicht wirklich beantwortet.
Grüße
Mit dem neuesten sketch von HCS müsste das gehen! ;)
[LaCrosseITPlusReader.10.0e]
Available commands:
<n> a - activity LED (0=off, 1=on)
Billy
Das Modul in FHEM müsste nur noch die neuen Optione unterstützen, dann wäre das komfortabel.
Solange:
im Sketch diese Zeile suchen:
bool ENABLE_ACTIVITY_LED = 1;
und auf 0 setzen
du kannst mir 'set raw' direkt etwas an den jeelink schicken.
ich bin gerade dabei die initialisierungssquenz konfigurierbar zu machen.
gruss
andre
Danke für eure Antworten! Wo finde ich den Sketch "LaCrosseITPlusReader.10.0e"? Google oder Github spucken mir da leider nichts aus... Und: Kann ich den Sketch einfach so wieder auf den Jeelink bügeln oder muss der Flash vorher gelöscht werden?
Zitat von: marcel151 am 02 April 2014, 16:07:30
Danke für eure Antworten! Wo finde ich den Sketch "LaCrosseITPlusReader.10.0e"? Google oder Github spucken mir da leider nichts aus... Und: Kann ich den Sketch einfach so wieder auf den Jeelink bügeln oder muss der Flash vorher gelöscht werden?
ZitatWo finde ich den Sketch "LaCrosseITPlusReader.10.0e"?
2 Seiten weiter vorher im Thread!
ZitatUnd: Kann ich den Sketch einfach so wieder auf den Jeelink bügeln oder muss der Flash vorher gelöscht werden?
einfach drüber bügeln. :)
Billy
Hallo zusammen,
kann es sein, dass erwähnte Sketch zwei Seiten vorher neuer ist, als der auf SourceForge (http://sourceforge.net/p/fhem/code/4353/)?
Und noch eine Frage: Ist das Protokoll der La Crosse/Intertechno Sensoren FSK? Oder ASK bzw. OOK?
(FSK ... frequency shift keying, ASK ... amplitude shift keying, OOK ... on/off keying)
Für ASK/OOK müsste aus meiner Sicht dann der Carssi umgebaut werden.
Danke für Infos.
Gruß PeMue
der eingecheckte sketch ist der letzte 'offizielle stand'.
hier im thread gibt es tut zeit mindestens zwei wenn nicht sogar drei versionen mit neueren/anderen features. da ich keineneinzigen der sensoren habe kann ich nicht entscheiden ob die neueren versionen so stabil sind das sie eingecheckt werden können. da bräuchte ich mal ein ok der anwender.
gruss
andre
Bei mir läuft er seit wochen stabil! Auch empfängt er mehr sensorentypen als der alte!
Solange man die experimentellen features (senden) nicht verwendet, sehe ich keinen Grund, beim alten Sketch zu bleiben.
Zitat von: JoeALLb am 06 April 2014, 10:44:23
Bei mir läuft er seit wochen stabil!
Welcher aus dem Thread?
Danke + Gruß
Peter
Zitat von: PeMue am 06 April 2014, 11:02:48
Welcher aus dem Thread?
Ja! Der Sketch aus dem Thread beinhaltet größere Umbauten zue Vorbereitung für das senden von Wemperaturwerten.
Das klappt aber (noch) nicht gut. Das Empfangen funktioniert aber tadellos, und da er die Frequenz umschalten kann, empfängt er auch Werte von Sensoren, die der alte Sketch nicht empfangen konnte.
Zitat von: PeMue am 06 April 2014, 10:02:24
Und noch eine Frage: Ist das Protokoll der La Crosse/Intertechno Sensoren FSK? Oder ASK bzw. OOK?
(FSK ... frequency shift keying, ASK ... amplitude shift keying, OOK ... on/off keying)
Für ASK/OOK müsste aus meiner Sicht dann der Carssi umgebaut werden.
FSK, der Kondensator bleibt wie er ist
Zitat von: JoeALLb am 06 April 2014, 10:44:23Bei mir läuft er seit wochen stabil! Auch empfängt er mehr sensorentypen als der alte!
Bei mir auch, 5 Sensoren, 0 Probleme
Zitat von: PeMue am 06 April 2014, 11:02:48
Welcher aus dem Thread?
Danke + Gruß
Peter
10.0f aus Beitrag 534
Hallo,
ich habe seit kurzem einen Jeelink und zwei TX29DTH-IT. Den Jeelink habe ich mit dem aktuellen Lacrosse Sketch betankt und von fhem wird der Stick auch erkannt.
In fhem habe ich autocreate aktiv. Wenn ich die Batterien in den Sender stecke, passiert auf der fhem Seite leider nichts. Die Sensoren werden nicht erkannt. Ich habe testweise den Parameter "LaCrossePairForSec" auf 300s gestellt. Aber auch das hilft nicht weiter...
Stattdessen bekomme ich im Eventlog folgende Eintrage angezeigt:
2014-04-07 15:57:23 JeeLink myJeeLink UNKNOWNCODE ? 3 223 235 56 191 39 53 43 24 254 28 255 164 77 94 158 138 164 58 243 117
2014-04-07 15:57:25 JeeLink myJeeLink UNKNOWNCODE ? 11 245 187 87 143 254 15 61 201 100 48 35 179 62 70 187 68 105 188 224 2
Ich bin mir nicht sicher, ob ich das Flashen richtig gemacht habe. Dazu habe den IDE heruntergeladen, den Treiber installiert (erkannt wird ein "Arduino Uno"), die "LaCrosseITPlusReader10.ino" im IDE geöffnet und auf Upload geklickt. Am Ende kommt folgende Meldung:
"Upload abgeschlossen" In dem Termialfester steht noch:
Binäre Sketchgröße: 14.362 Bytes (von einem Maximum von 32.256 Bytes)
avrdude: stk500_getsync(): not in sync: resp=0x00
Das "not in Sync" verunsichert mich dabei...
Hat jemand einen Tipp für mich?
Spartacus
Zitat von: Spartacus am 07 April 2014, 16:20:12
Binäre Sketchgröße: 14.362 Bytes (von einem Maximum von 32.256 Bytes)
avrdude: stk500_getsync(): not in sync: resp=0x00
Das bedeutet, dass der Upload nicht funktioiniert hat und der Sketch nicht auf dem JeeLink angekommen ist.
Könnte ein Treiber-Problem sein. Hast Du die richtige serielle Schnittestelle eingestellt und in der IDE als Board den Uno?
Hallo,
Besten Dank! das war es! Ich war davon ausgegangen, dass die SW den ComPort automatisch erkennt, zumindest habe ich das anhand der Infos in der Statusleiste (Uno an COM1) erwartet! Witzig finde ich auch, dass man nach dem Flashen nicht mal eine Rückmeldung kbekommt! Aber gut! Jetzt weiß ich es!
Die beiden Sensoren hat er sofort erkannt. Alles prima!
Eine Frage noch:
Wird das Pairing jetzt über den Parameter "LaCrossePairForSec" gesteuert, oder über autocreate. Im Wiki steht, dass man autocreate wieder ausschalten soll um nicht die Sensoren seiner Nachbarschaft abzufragen! Ist das noch aktuell? Wenn ja, warum dann der Parameter "LaCrossePairForSec"?
Danke und Gruß,
Spartacus
es werden nur dann neue devices angelegt wenn autocreate aktiv ist und LaCrossePairForSec gesetzt wird.
wenn LaCrossePairForSec nicht gesetzt ist kommen nur meldungen im log für unbekannte devices. das können aber recht viele werden.
gruss
andre
Hallo,
Super! Danke! Erstmal sniffen und gucken welchen Sensor ich mitbenutzen kann :-)
NACHTRAG:
die Werte werden alle 4s an fhem gesendet. Kann man das schon irgendwie konfigurieren? Ein Wert alle 5min würde ausreichen..
Gruß,
Spartacus
Hallo,
sorry, das ich noch mal nachfrage: Aber besteht die Möglichkeit das Intervall für die Events (4s Abstand) irgendwie anzupassen? Da laufen schon eine Menge Daten in die Logfiles. Ein Messwert alle 5-10min. wäre dicke genug für mich.
Danke fürs Feedback,
Spartacus
Das kannst du doch mit dem Attribut "event-min-interval" selbst machen. Die Dinger senden nunmal alle 4 Sekunden ;)
Hallo,
danke für die schnelle Antwort. Genau das habe ich gesucht! Bin nicht auf die Idee gekommen, das so zu machen...
Funktioniert auf jeden Fall.
Spartacus
Hallo,
die Events kommen jetzt entsprechend der Einstellungen alle 60s, aber ins Logfile "tempAussen" schreibt er immer noch alle 4s.
Habe folgende Einstellung vorgenommen:
attr tempAussen event-min-interval temperature:60,humidity:60,battery:3600
Gruß,
Spartacus.
Nachtrag:
ich glaube ich habe die Lösung gefunden: Man muss eine regexp für das Logfile definieren. In diesem Fall habe ich es so definiert:
Garten:temperature.*|Garten:humidity.*|Garten:battery.*
Hallo,
Ich habe bei der Länge des Threads etwas die Übersicht verloren. Welche Sensoren von LaCrosse werden denn unterstützt? Sind darunter auch mittlerweile Regen- und Windsensoren? Gibt es ein Wettercenter von LaCrosse, dessen Sensoren (Wind, Feuchtigkeit, Regen, Wind) komplett unterstützt werden? Vielen Dank.
Grüße
Marcus
http://forum.fhem.de/index.php/topic,14786.msg152869/topicseen.html#msg152869 (http://forum.fhem.de/index.php/topic,14786.msg152869/topicseen.html#msg152869)
Da deine Antwort nicht so richtig eindeutig ist. Mir ist klar, dass die diversen LaCrosse IT und auch zwei TFA Temperatur und Feuchtigkeitssensoren unterstützt werden, das beantwortet aber meiner Ansicht nach nicht meine Frage bezüglich der Regen- und Windsensoren bzw. welches Wettercenter unterstützt wird. Weiter vorne existiert nur ein Posting von dir, dass du das bei entsprechender Verfügbarkeit dieser Sensoren planst. Hat sich da etwas geändert. Kann man die Liste der Sensoren eventuell einfach ins Wiki aufnehmen?
Hallo zusammen,
bekomme ich über irgendwelche Abfragen auch die geflashte Firmware/Sketch (so ähnlich wie beim CUL) ausgelesen?
Danke + Gruß
PeMue
wenn du verbose auf 5 stellst sollte die boot message im log auftauchen. die aller ersten versionen des sketch hatten aber noch keine.
gruss
andre
ich habe eben die erweiterungen von ulli aus dem thread hier: http://forum.fhem.de/index.php/topic,17697.0.html (http://forum.fhem.de/index.php/topic,17697.0.html) zum JeeLink modul eingecheckt.
es sollte keine seiteneffekte für die anderen client module haben.
gruss
andre
Bei mir funktioniert das ec3000 client modul nicht mehr stabil. Es kann durch mehrmaliges senden von raw ec zwar verbunden werden
ist aber nach empfangen von einer regulären Nachricht wieder weg.
Erneutes senden von raw ec gleiches Ergebnis.
Es scheint die Kommunikation mit dem sketch bei mir [ec3kSerial.1] durchananderzugeraten.
gruss
und die version vorher ging ohne probleme ?
ich schaue es mir an so bald es geht.
gruss
andre
Ja, bis zum aktuellen Update von FHEM/36_JeeLink.pm, lief es ca. 1/2 Jahr einwanfrei.
Grüsse
Zitat von: My-FHEM am 19 April 2014, 17:05:14
Bei mir funktioniert das ec3000 client modul nicht mehr stabil. Es kann durch mehrmaliges senden von raw ec zwar verbunden werden
ist aber nach empfangen von einer regulären Nachricht wieder weg.
Erneutes senden von raw ec gleiches Ergebnis.
Es scheint die Kommunikation mit dem sketch bei mir [ec3kSerial.1] durchananderzugeraten.
gruss
Bei mir gibt es auch ein Problem mit den EC3000.
Bin zwar noch nicht lange dabei und noch recht -"unerfahren", aber bis zum Upodate heute mittag funktionierten meine 3 EC300.
Seitdem steht bei meinem JeeLink immer "PARTIAL >ec" und "RAWMSG bad command: 'q1'"
Ich meine, daß war vorher nicht da.
das ist genau das was ich vorhin behoben habe. morgen sollte wieder alles gehen.
gruss
andre
Dann sag ich mal Danke!
Das Forum und Euer Support ist top!
Ich hab gerade ein Update auf aktuelle jeelink module gemacht.
Bei meinen Verbindungsproblem mit EC 3000 hat sich gegenüber gestern
nichts verbessert.
Gruss
bitte schau mal welche version du jetzt installiert hast.
gruss
andre
Bei mir klappen mit dem heutigen update sowohl meine EC3000 als auch die La Crosse Sensoren
Sorry, für Störung. Es klappte nicht nach update ; shutdown restart.
Habe dann Fhem noch mal beendet und bin per screen /dev/jeeEC3 57600
auf den sketch gegangen. Habe dort ec eingegeben die Antworten der Plugs
kamen. Nach start von fhem lief alles.
Sketch war wohl irgendwie durcheinander.
Grüsse
Funktioniert der EC3000 zusammen mit den LaCrosse Temperatursensoren und nur einem Jeelink? Oder braucht man dafür je einen Jeelink?
man braucht je einen eigenen jeelink.
gruss
andre
Schade...
Würden sich prinzipiell EC3000 und LaCrosse gegenseitig stören oder funktioniert das auch bei vielen Sensoren einwandfrei?
Liegt die Reichweite des EC3000 wirklich nur bei 30m im freien Feld oder funktioniert die Funkübertragung innerhalb eines Hauses?
Zitat von: justme1968 am 22 April 2014, 22:39:46
man braucht je einen eigenen jeelink.
Zitat von: Alex8508 am 22 April 2014, 22:48:41
Schade...
... oder baut sich aus Arduino Nano, RFM12B und 6 Widerständen einen extra "Jeelink". Kostet reichlich 1/3 vom Original und macht das selbe.
Meine Vorlage: http://openenergymonitor.org/emon/buildingblocks/rfm12b-wireless (http://openenergymonitor.org/emon/buildingblocks/rfm12b-wireless)
Viele Grüße, Ricardo
Hallo,
nachdem die EC3000 bei mir gut laufen, habe ich mir einen 2. JeeLink für die Technoline Sensoren besorgt und mit dem entsprechenden Sketch (10f) geflasht
Eingebunden ist er so:
define JLLaCR JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AM01YPOJ-if00-port0@57600
In FHEM sieht das dann so aus:
Internals
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AM01YPOJ-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AM01YPOJ-if00-port0@57600
FD 25
LaCrossePair 2
NAME JLLaCR
NR 137
PARTIAL
STATE Opened
TYPE JeeLink
Leider wird mein TX35TH-IT nicht empfangen.
Die entsprechenden Optionen habe ich natürlich gesetzt:
set JLLaCR LaCrossePairForSec 600 ignore_battery
Was mich wundert ist, die blaue LED blinkt nicht.
Wenn ich den JeeLink an den Rechner anschließe und den Serial Monitor laufen lassen, bekomme ich folgende Auswertung:
OK 9 22 1 4 226 106
OK 9 22 1 4 226 106
OK 9 22 1 4 226 106
OK 9 22 1 4 226 106
OK 9 22 1 4 227 106
OK 9 22 1 4 227 106
Da blinkt dann auch die blaue LED.
Kann mir mal (wieder) jemande weiterhelfen?
Danke und Gruß
Manni
Edit: Bin etwas weiter. Habe im Sketch die Data_Rate auf 9 gesetzt. Jetzt kommt folgendes an:
2014-04-25 18:02:59 JeeLink JLLaCR UNKNOWNCODE OK 9 49 129 4 68 59
Ein Gerät wird aber nicht angelegt.
Hallo zusammen,
bin gerade per Zufall auf den Thread gestoßen.
Kann mir jemand die Funk-Eckdaten nennen für den TX29-IT?
Frequenz 868,3
Modulation FSK
....
Ich versuch mit einen RFM12B Chip und dem Rasperry die Daten auszulesen.
Vielen Dank Schonmal.
Gruß Schlauby
Zitat von: mannil am 25 April 2014, 17:15:52
Edit: Bin etwas weiter. Habe im Sketch die Data_Rate auf 9 gesetzt. Jetzt kommt folgendes an:
2014-04-25 18:02:59 JeeLink JLLaCR UNKNOWNCODE OK 9 49 129 4 68 59
Ein Gerät wird aber nicht angelegt.
Das sieht so weit OK aus. Hast Du mit "define autocreate autocreate" den autocreate aktiviert?
Zusammen mit LaCrossePaireForSec sollte das dann eigentlich gehen.
Die Daten von Deinem JeeLink sagen
ID: 31 Hex
Temperatur 9,2°C
59% Luftfeuchte
Notfalls kannst Du den Sensor auch manuell definieren:
define howWarmIsIt LaCrosse 31
attr howWarmIsIt IODev JLLaCR
...
Zitat von: schlauby am 26 April 2014, 17:35:27
Kann mir jemand die Funk-Eckdaten nennen für den TX29-IT?
Frequenz 868,3
Modulation FSK
....
Ich versuch mit einen RFM12B Chip und dem Rasperry die Daten auszulesen.
Was für Eckdaten willst Du denn noch. Im Sketch ist die komplette Empfangsroutine incl. Initialisierung.
Genau die Initialisierung und die Emfpangsroute interessiert mich.
Die Firmware "LaCrosseITPlusReader05.ino" konnte ich mir leider nicht anschauen, da dies vermute ich mal bereits kompeliert ist.
Die Sourcen hierzu interessieren mich.
Ist der Quellcode irgendwie zugänglich?
ups - mein Fehler. Vergesst was ich geschrieben habe :-)
Ohh mann schlauby ;D
Zitat von: La_Si_Hong am 17 Februar 2014, 19:48:08
also empfangen tut der JeeLink was vom 30.3180.IT. Zumindest seh ich bei aktiviertem debug, dass Daten kommen. Diese sind aber sowohl was CRC als auch Header angeht nicht in der Form wie es der sketch erwarten würde ... mal guggen ob ich mit meinen begrenzten Fähigkeiten da was ermitteln kann ...
Hallo,
Ich kämpfe nun schon seit Tagen mit 6 Sensoren vom Typ 30.3180.IT - bisher leider ohne Erfolg.
Mit dem Sketch 10.f bekomme ich im Debug Mode zahlreiche Datenpakete, die ich bisher nicht entschlüsseln kann.
@La_Si_Hong: Bist du mit deinen Sensoren schon weitergekommen?
Hat jemand Hinweise, wie die Datenpakete aufgebaut sind? Falls ja, würde ich mich gerne einbringen, das Ganze in FHEM zu integrieren.
Anbei aus dem Logfile - vielleicht kann jemand damit etwas anfangen...
Hallo Experten,
ich bitte um Nachsicht für meine Unwissenheit und gleichzeitig um Hilfe für mein Problem...
Basics:
RaspPi mit FHEM 5.5.
Erfolgreich getestet:
1-Wire 18B20 über GPIO4
433MHz-Modul über WiringPI (sendelro) mit Pollin-Steckdosen
Was nicht funktioniert:
original Jeelink v3 mit 30.3181.IT Sender
Jeelink-Nachbau (Arduino Nano mit RFM12B) mit 30.3181.IT Sender
Da habe ich anscheinend grundsätzliche Probleme:
- Jeelink erfolgreich geflasht, mit dem LaCrosseITPlusReader.ino v10.0f
- Jeelink wird vom RaspPi erkannt (/dev/ttyUSB0)
1. Frage: mit den in verschiedenen Blogs beschriebenem "define myJeelink JeeLink /dev/ttyUSB0" wird zwar ein neues "Gerät" definiert, aber trotz Verbose-Level 5, set lacrossepairforsec 60 ignore_battery, keinerlei Reaktionen im Event Monitor ?
2. Frage: ohne Device-ID, die ich ja eigentlich im Monitor ersehen sollte, kann ich auch kein "define xxname LaCrosse" machen, oder?
3. Feststellung: liegt zu 99,9% nicht am Jeelink oder meinem Nachbau, da bei beiden genau die gleichen Probleme auftreten.
4. Frage: liegt es am 30.3181.IT ?? Da ist eine feste 4-stellige ID auf der Rückseite aufgedruckt, auch beim Batterieeinlegen am Display zu sehen. Geht dieser Sensor überhaupt mit dem Jeelink ??
5. Frage: gibt es eine Möglichkeit, meine beiden "Sticks" im FHEM oder in der RaspPi-Konsole irgendwie zu testen, um die Funktionalität zu prüfen ?? (ohne Sensor ?)
Fragen über Fragen... vielleicht wird mir ja geholfen bzw. der nötige Denkanstoss gegeben, damit mir ein Licht aufgeht ...
Vielen Dank im Voraus
Karl
Hallo Karl,
steht denn bei Fhem unter "unsorted" -> Jeelink das Device ( bei dir Arduino) drin? Sollte "open" oder "initialized" dort stehen.
Hast du einen aktuellen Update-Abruf von fhem (developer) gemacht?
Hast du auch den rfm12b genommen? 868Mhz oder haben deine Temperatursensoren anderen Frequenzbereich?
OOps.. hast bisher alles richtig gemacht. ich war zu schnell.
Ja die sollten bei verbose Level 5 auftauchen, dann nur noch mit der im Log stehenden ID im Define eintragen und schon sollte es klappen.
Im Arduino Serial-Monitor kannst du die Sensoren prüfen ob was ankommt, ich glaube da gab es ein debug-flag. Ich habe in meinem Blog auch einen Screen-Shot davon gemacht, wie das aussehen sollte.
Ich nutze die TX29 IT bzw. TX29DT-HT-IT bin zufrieden. Ich habe davon damals einen Blog-Beitrag gemacht:
http://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz/
Robin
Hallo Robin,
mit geflashtem Lacrosse-Sketch kommt gar nichts im Arduino-Serial-Monitor. Ich habe dann probeweise die RF12demo aus den jeelib-Beispielen geflasht, da kommt dann wenigstens eine Rückmeldung im Monitor mit den geflashten Eckdaten und auch Datenreihen werden empfangen, aber in unregelmäßen Abständen:
[RF12demo.10] A i1 g212 @ 868 MHz
DF I 514 2
Available commands:
<nn> i - set node ID (standard node ids are 1..30)
<n> b - set MHz band (4 = 433, 8 = 868, 9 = 915)
<nnn> g - set network group (RFM12 only allows 212, 0 = any)
<n> c - set collect mode (advanced, normally 0)
t - broadcast max-size test packet, request ack
...,<nn> a - send data packet to node <nn>, request ack
...,<nn> s - send data packet to node <nn>, no ack
<n> l - turn activity LED on PB1 on or off
<n> q - set quiet mode (1 = don't report bad packets)
<n> x - set reporting format (0 = decimal, 1 = hex)
123 z - total power down, needs a reset to start up again
Remote control commands:
<hchi>,<hclo>,<addr>,<cmd> f - FS20 command (868 MHz)
<addr>,<dev>,<on> k - KAKU command (433 MHz)
Flash storage (JeeLink only):
d - dump all log markers
<sh>,<sl>,<t3>,<t2>,<t1>,<t0> r - replay from specified marker
123,<bhi>,<blo> e - erase 4K block
12,34 w - wipe entire flash memory
Current configuration:
A i1 g212 @ 868 MHz
? 178 52 189 70 163 104 43 116 102 117 164 151 254 52 102 78 134 252 12 146 48
? 133 79 45 70 0 71 151 183 37 244 164 40 3 60 125 41 209 33 138 42 67
? 186 118 186 206 68 220 217 214 213 227 68 197 200 220 228 28 100 48 102 12 165
? 162 56 168 211 177 52 164 163 199 51 6 74 217 58 171 28 135 218 92 5 72
? 141 128 55 5 176 206 142 105 174 131 169 232 51 58 238 229
? 140 61 146 125 210 42 19 235 85 4 141 219 200 160 162 152 242 184 235 10 172
? 12 136 32 147 216 153 1 228 84 18 1 180 65 157 74 219 208
? 8 250 64 172 161 3 161 235 239 43 254 242 2 39 254 222 113 220 213 221 227
Ich hab mir jetzt noch zusätlich ein TX29IT bestellt... der Sender sollte jedenfalls von der Kompatibilität passen.
Mal sehen, was dann im Serial-Monitor bzw. Event-Monitor ankommt...
Karl
Zitat von: justme1968 am 18 April 2014, 19:32:24
ich habe eben die erweiterungen von ulli aus dem thread hier: http://forum.fhem.de/index.php/topic,17697.0.html (http://forum.fhem.de/index.php/topic,17697.0.html) zum JeeLink modul eingecheckt.
es sollte keine seiteneffekte für die anderen client module haben.
gruss
andre
Hallo Andre,
wie schon im PCA301-Thread gepostet funktioniert das Senden an die PCA-Steckdosen seit Deiner Integration nicht mehr.
http://forum.fhem.de/index.php/topic,11648.msg163611.html#msg163611
Grüße Jörg
Folgende Sensoren habe ich jetzt erfolgreich in Betrieb nehmen können:
-TX35TH-IT (ohne D)
-WD 30.3155
-WD 30.3156 (nur Temperatur).
Vielleicht hilfts ja jemandem.
Hallo,
ich kann inzwischen ein Status-Update meines Problems von Vorgestern geben:
Sender TX29IT ist heute eingetroffen, wird sofort erkannt, bei mir mit "OK 9 ...."; habe mit der ID eine define Lacrosse mit IODev Jeelink erstellt,
wird dann auch schön angezeigt im Event-Monitor:
2014-05-02 19:36:05 LaCrosse Funktemperatur temperature: 20.2
2014-05-02 19:36:05 LaCrosse Funktemperatur battery: ok
Funktioniert mit beiden Empfängern, dem Selbstbau (Nano+RFM12B) und dem Jeelink v3
Also liegt es definitiv am 30.3181.IT, mit dem die beiden Empfänger nichts reinbekommen...
Aber jetzt taucht ein neues Problem auf... ich kann über die Websymbole keine meiner Steckdosen mehr schalten ?!?
Manuell in der Eingabezeile geht es aber noch, z.B. mit "set F220 on" (die steuern ein 433-Sendemodul direkt am RaspPi an über sendelro)
Ist vielleicht die Web-Oberfläche durch die 4-sekündigen Temperaturmeldungen überlastet ??
Wenn ich den Jeelink deaktiviere, funktionieren die "ON/OFF"-Klicks wieder...
Karl
-----------------------------------------
EDIT
Sorry, hab das Problem selbst entdeckt: es lag am IE ?!?!
Hab jetzt die FHEM-Seite mit Firefox geöffnet, da funktioniert alles ...
vielleicht sollte ich auf meinem Bastel-Laptop auch mal Linux draufpacken ::)
VG
Karl
Zitat von: digital.arts am 30 April 2014, 21:16:56
4. Frage: liegt es am 30.3181.IT ?? Da ist eine feste 4-stellige ID auf der Rückseite aufgedruckt, auch beim Batterieeinlegen am Display zu sehen. Geht dieser Sensor überhaupt mit dem Jeelink ??
Das scheint eines von vermutlich mehreren Problemen zu sein. Bei den bisher implementierten Sensoren ist die ID (Adresse) des Sensors 6 Bit lang. Eine 4-stellige ID passt schon mal nicht in das Schema.
Allerdings sehen die Daten aus dem Log weiter oben auch eher schelcht aus. Da ist keinerlei Sinn zu erkennen, was bedeuten könnte, dass auch die data rate nicht passt. Kann mal jemand mit 9.579 kbps so ein Log erstellen, ob da ein sinnvolleres Log rauskommt? Wenn die empfangenen Bytes zumindest mal korrekt sind, muss es einen gewissen Wiederholfaktor geben, da zumindest der Header und die Adresse eines Sensors konstant sind.
Ohne ein größeres Forschungsprojekt mit so einem Sensor sieht es eher schlecht aus.
Folgende Sensoren wurden bisher als funktioniernd gemeldet (wie bei den Lottozahlen: "Alle Angaben ohne Gewähr"):
TX25-IT 17.241 kbps
TX27-IT 17.241 kbps
TX29DTH-IT 17.241 kbps (garantiert, habe ich welche)
TX37 17.241 kbps
TX35TH-IT 9.579 kbps
TX35DTH-IT 9.579 kbps (garantiert, habe ich welche)
30.3147.IT ? kbps
30.3155WD 9.579 kbps
30.3156WD 9.579 kbps
Edit: Sensor-Liste aktualisiert
TX35-TH
30.3155WD
30.3156WD
sind alle auf 9.579 kbps
ich denke es wäre hilfreich die liste im wiki zu pflegen.
hier geht sie bald verloren.
gruss
andre
Hallo zusammen,
nachdem ich gefühlte zehnmal das Wiki aktualisiert habe, es aber dann doch nicht ging >:( >:( >:(, stelle ich mal hier den Wiki Code hier zur Verfügung, vielleicht ist jemand erfolgreicher (Eintrag unterhalb des LaCrosse Sketches):
[http://forum.fhem.de/index.php/topic,14786.msg164801.html#msg164801 Folgende Sensoren] wurden schon erfolgreich getestet:
{| class="wikitable"
!Bezeichnung !! Datenrate
|-
| TX25-IT || 17.241 kbps
|-
| TX27-IT || 17.241 kbps
|-
| TX29DTH-IT || 17.241 kbps
|-
| TX37 || 17.241 kbps
|-
| TX35TH-IT || 9.579 kbps
|-
| TX35DTH-IT || 9.579 kbps
|-
| 30.3147.IT || ? kbps
|-
| 30.3155WD || 9.579 kbps
|-
| 30.3156WD || 9.579 kbps
|}
Gruß PeMue
Solange im Trunk noch der alte Sketch ist, stimmt das mit den 9.579 kbps - Sensoren natürlich nicht
Zitat von: PeMue am 03 Mai 2014, 08:26:59
nachdem ich gefühlte zehnmal das Wiki aktualisiert habe, es aber dann doch nicht ging >:( >:( >:(,
Ich habe die Tabelle jetzt mal hier (http://www.fhemwiki.de/wiki/Jeelink#Lacrosse_Sketch) eingefügt - ich hoffe, das war es, was Du vorhattest.
Was genau ging denn nicht? Wilde Vermutung meinerseits: nachdem Du einen externen Link (http://...) einfügen wolltest, bist Du beim ersten Drücken des "Speichern" Buttons nach dem Ergebnis einer Rechenaufgabe gefragt worden (
Deine Bearbeitung enthält neue externe Links. Um das Wiki vor automatisiertem Spam zu schützen, bitten wir dich die untenstehende einfache Rechenaufgabe zu lösen und deine Antwort in das Feld einzugeben, ...) ... was Du möglicherweise übersehen hast.
Gruß, Peter
ich hab eben die version 10.0f aus dem beitrag 534 eingecheckt.
gruss
andre
Zitat von: HCS am 02 Mai 2014, 22:32:57
Allerdings sehen die Daten aus dem Log weiter oben auch eher schelcht aus. Da ist keinerlei Sinn zu erkennen, was bedeuten könnte, dass auch die data rate nicht passt. Kann mal jemand mit 9.579 kbps so ein Log erstellen, ob da ein sinnvolleres Log rauskommt?
Die von digital.Arts (Karl) beschriebenen Probleme mit dem 30.3181.IT decken sich mit meinen Erfahrungen mit den 30.3180.IT Sensoren.
Ich habe bereits mit data rate 9.579 und 17.241 bzw. mit wechselnder data rate getestet. Mit 9.579 habe ich valide Daten von meinem WetterDirekt Außensensor ermpfangen, der Rest der empfangenen Daten (mutmaßlich von den 30.3180.IT) haben genau so wenig Sinn ergeben, wie mit data rate 17.241 - ich kann aber gerne wie oben gewünscht noch einmal ein Log mit data rate 9.579 zur Verfügung stellen. Ich bin allerdings gerade verreist und kann die Daten frühestens am Montag aufzeichnen.
Zitat von: ph1959de am 03 Mai 2014, 09:59:32
Wilde Vermutung meinerseits: nachdem Du einen externen Link (http://...) einfügen wolltest, bist Du beim ersten Drücken des "Speichern" Buttons nach dem Ergebnis einer Rechenaufgabe gefragt worden (Deine Bearbeitung enthält neue externe Links. Um das Wiki vor automatisiertem Spam zu schützen, bitten wir dich die untenstehende einfache Rechenaufgabe zu lösen und deine Antwort in das Feld einzugeben, ...) ... was Du möglicherweise übersehen hast.
Hm, äh, *räusper*, 8) 8) 8) 8)
Ja, habe ich echt übersehen.
Danke für den Tipp und für's Einbauen.
Gruß Peter
Neue Version 10.0h
Zwei Neuerungen gibt es in dieser Version:
Relay
Da ich Sensoren habe, die zu weit vom Raspi entfernt sind, habe ich eine Relay-Funktion eingebaut. Muss man sich vorstellen wie einen WLAN Range Extender. Wenn man den Sketch als Relay konfiguriert, dann wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.
Die Konfiguration sieht dann so aus:
// --- Configuration ---------------------------------------------------------
#define RECEIVER_ENABLED 1 // Set to 0 if you don't want to receive
#define ANALYZE_FRAMES 0 // Set to 1 to display analyzed frame data instead of the normal data
#define USE_OLD_IDS 0 // Set to 1 to use the old ID calcualtion
#define RELAY 1 // If 1 all received packets will be retransmitted
bool DEBUG = 0; // set to 1 to see debug messages
bool ENABLE_ACTIVITY_LED = 1; // set to 0 if the blue LED bothers
int DATA_RATE = DATA_RATE_17; // use one of the data rates defined above
int TOGGLE_DATA_RATE = 0; // 0=no toggle, else interval in seconds
Entscheidend ist #define RELAY 1
Den JeeLink steckt man einfach auf einen billigen 5V USB Ladestecker, wie man ihn auch für das Handy usw. verwendet und sucht sich eine Steckdose auf halber Strecke zum eigentlichen Empfänger. Siehe angehängtes Bild.
LevelSender
Der Sketch unterstützt nun einen batteriebetriebenen Eigenbau-Sender, der den Füllstand von z.B. Regenwassertanks sendet. Dieses Projekt stelle ich dann noch in einem eigenen Thread vor.
Edit: hier ist er nun: http://forum.fhem.de/index.php/topic,23217.msg165163.html#msg165163
Zitat von: HCS am 04 Mai 2014, 11:31:13
Relay
Da ich Sensoren habe, die zu weit vom Raspi entfernt sind, habe ich eine Relay-Funktion eingebaut. Muss man sich vorstellen wie einen WLAN Range Extender. Wenn man den Sketch als Relay konfiguriert, dann wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.
Ich könnte mir vorstellen, dass die Relay funktion auch für dei Jeelink Anwender im Forum:
Thema: Einbindung der kostengünstigen Funkschaltsteckdose PCA 301 mit Energiemessunginteressant wäre.
Lässt sich das realisieren?
Gruss Billy
Das wird nicht so einfach gehen. Um keinen Datenmüll unnötig weiter zu verbreiten, wird die empfangene IT+ Aussendung dekodiert und auf korrektes CRC getestet. Nur wenn das OK ist, wird das Paket neu ausgesendet.
Dazu muss man aber den Aufbau der Daten kennen und dieser Sketch kennt momentan nur das IT+ und das LevelSender Format. Ich denke, es ist einfacher, die Relay-Funktionalität in den PCA 301 Sketch einzubauen. Im LaCrosseITPlusReader10 Sketch war es ein Dreizeiler.
Die IT+ Sensoren senden alle 4 Sekunden.
Mit event-min-interval state:60 möchte ich das auf 60 Sekunden begrenzen.
Soweit funktioniert das.
Wenn sich aber zwei Stunden lang der Wert am Sensor nicht ändert, bekomme ich die zwei Stunden kein Event für state und keinen Log-Eintrag, ich hätte aber gerne nach 60 Sekunden wieder einen.
Der Grund scheint darin zu liegen, dass ein Update von state nur erfolgt, wenn es sich ändert.
Das verhindert aber, dass ich das für state mit event-min-interval state:xx selbst bestimme.
Sollte der "if" eher nicht da sein oder habe ich da ein Verständnisproblem?
my $state = "T: $temperature";
$state .= " H: $humidity" if( $humidity && $humidity <= 99 );
$state .= " D: $dewpoint" if( $dewpoint );
readingsBulkUpdate($rhash, "state", $state) if( Value($rname) ne $state );
das modul aktualisiert zur zeit nur temperatur und humidity bei jeder empfangen message. state nur wenn sich wirklich etwas geändert hat.
das möchte ich eigentlich ungern ändern weil es sonst bei allen anderen plötzlich events erzeugt.
warum loggst du denn state und nicht temperature und humidity?
gruss
andre
Zitat von: justme1968 am 05 Mai 2014, 15:57:31
das modul aktualisiert zur zeit nur temperatur und humidity bei jeder empfangen message. state nur wenn sich wirklich etwas geändert hat.
Und das ist SEHR gut so!
Ich wollte nur ein event, und die anderen unterdrücken, was das event log übersichtlicher macht.
Und state ist auch bereits so ein passender "Einzeiler".
Darum habe ich diesen Weg eingeschlagen.
Bekomme ich das mit einem UserReading, das ich aus temperature und humidity bilde, hin?
Also ein UserReading myState bilden und mit event-min-interval myState:60 versehen und das dann loggen?
ja. das geht.
gruss
andre
Super, danke!
Zitat von: HCS am 05 Mai 2014, 15:31:12
Ich denke, es ist einfacher, die Relay-Funktionalität in den PCA 301 Sketch einzubauen. Im LaCrosseITPlusReader10 Sketch war es ein Dreizeiler.
Sorry hatte mich wahrscheinlich nicht deutlich genug ausgedrückt. :-\
Genau das hatte ich gemeint:
die Relay-Funktionalität in den PCA 301 Sketch einzubauenBilly
Zitat von: HCS am 04 Mai 2014, 11:31:13
Neue Version 10.0h
Zwei Neuerungen gibt es in dieser Version:
Relay
Da ich Sensoren habe, die zu weit vom Raspi entfernt sind, habe ich eine Relay-Funktion eingebaut. Muss man sich vorstellen wie ..., direkt nach dem Empfang wieder gesendet.
Entscheidend ist #define RELAY 1
Wie stellst Du sicher, dass die JeeLinks nicht Ping Pong spielen?
Grüße Jörg
Zitat von: HCS am 02 Mai 2014, 22:32:57
Das scheint eines von vermutlich mehreren Problemen zu sein. Bei den bisher implementierten Sensoren ist die ID (Adresse) des Sensors 6 Bit lang. Eine 4-stellige ID passt schon mal nicht in das Schema.
Allerdings sehen die Daten aus dem Log weiter oben auch eher schelcht aus. Da ist keinerlei Sinn zu erkennen, was bedeuten könnte, dass auch die data rate nicht passt. Kann mal jemand mit 9.579 kbps so ein Log erstellen, ob da ein sinnvolleres Log rauskommt? Wenn die empfangenen Bytes zumindest mal korrekt sind, muss es einen gewissen Wiederholfaktor geben, da zumindest der Header und die Adresse eines Sensors konstant sind.
Anbei wie oben gewünscht ein Log mit data rate 9.579 sowie auch mit 17.241 kbps. Beides aufgenommen mit der Sketch-Version 10f.
Mit data rate 9.579 wird ein Außensensor vom Typ 30.3156.WD mit der Adresse 43 korrekt empfangen.
Es sind 6 Sensoren vom Typ 30.3180.IT im Haus verteilt und müssten sich in den empfangenen Datenpaketen wieder finden. Die Adressen der Sensoren lauten:
- 0d4F
- 13C9
- 1285
- 10C7
- 1688
- 1B40
Vielleicht kann jemand von euch in den empfangenen Daten ein Muster erkennen? Sobald bekannt ist, wie die Daten-Frames bei diesen Sensoren aufgebaut sind, ist die Integration in das Sketch vermutlich die leichtere Übung. Aber wahrscheinlich sehe ich bei der Analyse der Daten den Wald vor lauter Bäumen nicht mehr ;)
Bin für jeden Tipp dankbar! :)
Gruß
Pinky
Zitat von: JoWiemann am 05 Mai 2014, 19:39:56
Wie stellst Du sicher, dass die JeeLinks nicht Ping Pong spielen?
Solange man nur ein Relay in Betieb nimmt kann das nicht passieren.
Die Sensoren senden nur, der JeeLink auf dem Raspi empfängt nur und das Relay kann sich nicht selbst empfangen, wenn es sendet.
@Pinky: da erkenne ich nichts. Ob das überhaupt von Deinen 6 Sensoren stammt wäre noch zu ermitteln.
Kannst Du entweder
alle Sender abstellen, und sicherstellen, dass nun nichts mehr empfangen wird und falls das so ist, genau einen in Betrieb nehmen?
oder
mit dem Laptop, dem JeeLink und nur einem Sensor irgend wo hin gehen, wo definitv sonst nichts sendet?
Ich habe bei mir auch mal eine Zeit lang mit dem Problem gekämpft, dass ich allen möglichen Müll versucht habe zu interpretieren, der gar nicht von meinen Sensoren kam.
Zitat von: Billy am 05 Mai 2014, 18:07:10
Genau das hatte ich gemeint:
die Relay-Funktionalität in den PCA 301 Sketch einzubauen
Billy
Ja, vorstellbar, aber da muss dann jemand anderes ran.
Hallo,
mir ging es gestern genauso. Auch bei mir hat der autocreate für den Sensor TX29 DTH mit einem Jeelink Clone und aktuellem Sketch 10h nicht funktioniert.
Zitat von: mannil am 25 April 2014, 17:15:52
Edit: Bin etwas weiter. Habe im Sketch die Data_Rate auf 9 gesetzt. Jetzt kommt folgendes an:
2014-04-25 18:02:59 JeeLink JLLaCR UNKNOWNCODE OK 9 49 129 4 68 59
Ein Gerät wird aber nicht angelegt.
Das globale Attribut autocreate ist gesetzt.
define autocreate autocreateDas Jeelink Log:
2014-05-08_22:26:16 myJeeClone LaCrossePairForSec 60 ignore_battery
2014-05-08_22:28:27 myJeeClone UNKNOWNCODE OK 9 63 129 4 194 57
2014-05-08_22:28:31 myJeeClone UNKNOWNCODE OK 9 63 129 4 194 57
2014-05-08_22:28:36 myJeeClone UNKNOWNCODE OK 9 63 129 4 194 57
2014-05-08_22:28:40 myJeeClone UNKNOWNCODE OK 9 63 129 4 195 57
Erst das manuelle Anlegen hat funktioniert (Hex 63 = 3F):
define TX29 LaCrosse 3FJetzt funktioniert der Sensor einwandfrei.
Gruß
Tobias
ich hab eben eine änderung rückgängig gemacht die vermutlich dazu geführt hat das autocreate nicht funktioniert hat.
der aktuelle LaCrosse sketch sendet beim initialisieren keine kennung. und das fhem modul wusste nicht welcher sketch dran ist. jetzt ist wie früher erst mal eine default matchList gesetzt bis der sketch etwas anderes meldet.
vielleicht könnt ihr es noch mal testen.
der sketch sollte so geändert werden das er nach dem reset den hilfe text inklusive der version ausgibt.
gruss
andre
Hallo Andre,
damit funktioniert das Senden an PCA301 bei mir auch wieder.
Danke Dir Jörg
Ich habe seit heute einen TX35DTH-IT hier. Nachdem ich den Jeelink über set myJeelink raw 20t in den Toggle-Modus versetzt habe, wird der Sensor auch nach einem Pairing erkannt.
Das Problem: Es wird in FHEM nur eine Temperatur angezeigt und die ist viel zu niedrig. Statt ca. 18°C werden nur 11°C angezeigt. Die Luftfeuchtigkeit fehlt ganz, obwohl es sich um einen Sensor mit Luftfeuchtigkeit handelt. Kann es sein, dass der TX35DTH-IT eine festen Adresse hat, die sich beim Batteriewechsel nicht ändert?
Was mache ich falsch?
Hat jemand mal den Sensor TX21-IT getestet? Ich bräuchte einen Sensor, der im Freien steht und entsprechend vor Regen/Schnee geschützt ist.
Hallo zusammen,
ich habe verschieden Wettersensoren und ein Funk-Zusatzsender EMT7110 über JeeNode oder Arduino mit RFM12B an den FHEM angebunden. Vielen Dank an alle, die schon die ganze Vorarbeite geleistet haben. Ich habe das LaCrossITReader10.ino angepaßt. Ist nicht sehr schön aber bei mir funktioniert es. Die Daten der Wettersensoren werden auf LaCross umgeschrieben.
Ich habe aber noch nicht verstanden wie man die Verbrauchsdaten vom EMT7110 auf das Format z.B. des PCA 301 umwandelt.
Vielleicht geht es mit geringem Aufwand.
Sketch ausgetauscht da bei 2x EMT7110 immer die gleiche ID angezeigt wird. ID jetzt 5 stellig.
Hardware für Empfang:
Arduino Uno V3 + RFM12B (868MHz) auf Steckbrett oder JeeNode V6 + RFM12B (868MHz)
FHEM 5.5 auf Fritzbox 7240 (USB-Hub mit 32GB Stick und JeeNode V6)
Temperatursender: WT440XH (zur Wetterstation GT-WS-02), TFA 30.3144.IT (2x zur Wetterstation TFA 30.3012.IT), TX37-IT (zur Wetterstation WS-9130IT) Verbrauchsmessung: Funk-Zusatzsender EMT7110
Zitat von: Alex8508 am 13 Mai 2014, 20:03:52
Das Problem: Es wird in FHEM nur eine Temperatur angezeigt und die ist viel zu niedrig. Statt ca. 18°C werden nur 11°C angezeigt. Die Luftfeuchtigkeit fehlt ganz, obwohl es sich um einen Sensor mit Luftfeuchtigkeit handelt. Kann es sein, dass der TX35DTH-IT eine festen Adresse hat, die sich beim Batteriewechsel nicht ändert?
Geht das jetzt? Ich habe zwei TX35DTH-IT und keinerlei Probleme damit.
Sie senden Temperatur
und Luftfeuchtigkeit und die Adresse ist nicht fix. Ich hatte aber mal das Problem, dass sich ein Sensor nach dem Batterie-Einlegen eine Adresse ausgedacht hat, die ein anderer schon hatte, das gibt dann seltsame Messwerte.
Zitat von: pejonp am 18 Mai 2014, 19:08:21
Ich habe das LaCrossITReader10.ino angepaßt.
Ja, nur unglücklicherweise nicht auf Basis der Version 10.0h, in der die Relay-Funktionalität und der Empfang des LevelSenders drin sind.
http://forum.fhem.de/index.php/topic,14786.msg165153.html#msg165153
Sollen wir versuchen, das irgendwie zusammenzuführen oder sollen das zwei verschiedene Sketches werden?
Zitat von: HCS am 18 Mai 2014, 20:34:52
Geht das jetzt? Ich habe zwei TX35DTH-IT und keinerlei Probleme damit.
Sie senden Temperatur und Luftfeuchtigkeit und die Adresse ist nicht fix. Ich hatte aber mal das Problem, dass sich ein Sensor nach dem Batterie-Einlegen eine Adresse ausgedacht hat, die ein anderer schon hatte, das gibt dann seltsame Messwerte.
Nein, dieser TX35DTH-IT funktioniert noch immer nicht. Er ist aber auch inzwischen defekt. Das Display funktioniert, aber es werden nur °C und % angezeigt, aber keine Werte. Kann man hier was reparieren oder ist der Sensor endgültig defekt?
Zitat von: HCS am 18 Mai 2014, 20:45:15
Ja, nur unglücklicherweise nicht auf Basis der Version 10.0h ..
Sollen wir versuchen, das irgendwie zusammenzuführen oder sollen das zwei verschiedene Sketches werden?
Wir können das gern zusammenführen. Ich habe mal meine Änderungen in den 10.0h eingebaut. Wo soll ich den hinlegen ?
Läuft aber nicht. Die Anzahl Frames für den EMT7110 müssen auf 20 stehen.
// #define FRAME_LENGHT 20 // 20 wird für EMT7110 benötigt
#define IT_PLUS_FRAME_LENGHT 5
Wenn ich das ändere werden die Daten aber nicht weitergereicht, da in einigen Funktionen die 5 fest vorgegeben ist.
Die Erkennungsbytes haben sich auch geändert. Vorher data[0] = 0x51 (WT440XH) und 0x25 (EMT7110). Jetzt ?
Sendet der EMT7110 eigentlich eigenständig von sich aus in bestimmten Intervallen oder wird der von der Anzeigeeinheit angetriggert?
wenn der EMT7110 ein nur senden device ist das man nicht schalten kann ist es besser das ec3000 modul zu verwenden oder gleich ein eigenes fhem modul dafür zu bauen. das ist nicht wirklich aufwändig. siehe ec3000 modul.
gruss
andre
Zitat von: HCS am 20 Mai 2014, 14:25:01
Sendet der EMT7110 eigentlich eigenständig von sich aus in bestimmten Intervallen oder wird der von der Anzeigeeinheit angetriggert?
Der EMT7110 sendet in bestimmten Intervallen. Es kann nur gemessen werden. Hier ist eine Beschreibung zum EMT7110 zu finden. (http://hobbyelektronik.org/w/index.php/EMR7370)
Schalten geht z.B. in Kombination mit einer FS20 Steckdose. Ein Linux z.B. (Raspberry Pi) kann über ein C-Programm (https://git.zerfleddert.de/cgi-bin/gitweb.cgi/fs20pcs) den FS20 PCS Sender (elv) ansteuern und FS20-Befehle senden (geht bei mir).
Oder eine JeeNode zum senden von FS20 Befehle verwenden. Ich habe nur FS20 Steckdosen im Einsatz (hat sich so ergeben).
Meine Frage ist : Wie ist der Aufbau des Protokolls für die PCA301 und EC3000.
Ich habe einmal in die 35_JeeLink.pm gesehen dort steht für PCA301 und EC3000 jeweils ein Eintrag drin.
my %matchListPCA301 = (
"1:PCA301" => "^\\S+\\s+24",
"2:EC3000" => "^\\S+\\s+22",
Der String der beim FHEM ankommt hat den folgenden Aufbau.
OK 22 ... -> ec3000
OK 24 ... -> pca301
Jetzt könnte man die Daten vom EMT7110 doch so aufbereiten, das diese zu einem Protokoll passen. Ich möchte ja nur die gemessenen Daten anzeigen lassen.
Beim Sensor WT440XH sende ich die Daten im LaCross-Format.
Zitat von: pejonp am 19 Mai 2014, 20:07:45
Wir können das gern zusammenführen.
OK. Ich denke dass ich erst mal den sketch modularisieren sollte, bevor wir da noch mehr einbauen. Das ist jetzt schon ein ziemlicher "Spaghetti-Wust". Dann wird es auch einfacher, weitere Sensoren hinzuzufügen.
Es war zwar ganz nett, dass es nur eine einzelne ino ist, aber von der Wartbarkeit her ist es weniger gut.
Zitat von: justme1968 am 20 Mai 2014, 14:46:28
wenn der EMT7110 ein nur senden device ist das man nicht schalten kann ist es besser das ec3000 modul zu verwenden oder gleich ein eigenes fhem modul dafür zu bauen. das ist nicht wirklich aufwändig. siehe ec3000 modul.
Das scheint sinnvoll. Das Prinzip wäre: Der Sketch liefert alles, was er empfangen kann, das JeeLink Modul verteilt es konfigurierbar über "Clients" und "MatchList" und die jeweils zuständigen Module (LaCrosse, LevelSender, ...) verarbeiten es dann.
Ich habe den sketch modularisiert und die Unterstützung für EMT7110 eingebaut. Das FHEM-Modul dazu (36_EMT7110.pm) ist auch fast fertig. Werde es wohl nächste Woche veröffentlichen. Die WT440XH Unterstützung kommt dann später noch.
Eine Frage dazu: hat jemand eine Ahnung, ob und wie man den akkumulierten Energieverbrauch am EMT7110 zurücksetzen kann? Falls das nicht geht, müsste ich in das Modul noch einen Startwert einbauen, um eine neue Messung bei 0 beginnen zu können.
Danke für die ganze Arbeit!!!!
Zitat von: HCS am 25 Mai 2014, 18:04:22
Eine Frage dazu: hat jemand eine Ahnung, ob und wie man den akkumulierten Energieverbrauch am EMT7110 zurücksetzen kann?
Der EMT7110 hat 2 kleine Batterien zur Datenspeicherung. Wenn diese entfernt und wieder eingesetzt werden ist alles auf Null.
Im Sketch habe ich noch eine Anpassung übernommen, so das bei 2x EMT7110 auch 2 verschiedene IDs angezeigt werden.
HCS kann man sich dein überarbeitete Sketch schon ansehen und testen. ;-)
Version 10.1a
Neuerungen:
Sketch modularisiert
Aufgrund der steigenden Anzahl Sensoren wurde der Sketch immer unübersichtlicher und verworrener. Darum habe ich ihn nun modularisiert.
EMT7110
Der Sketch unterstützt nun die Energie-Mess-Steckdose EMT7110.
Das dazu passende FHEM-Modul 36_EMT7110.pm befindet sich im Unterverzeichnis FHEM.
Beim JeeLink muss der EMT7110 im Clients-Attribut hinzugefügt werden (siehe EMT7110-3.jpg)
Die EMT7110 arbeitet mit 9579 kbps, der Sketch muss also entweder auf die Datenrate eingestellt sein (RFM12::DataRates DATA_RATE = RFM12::DataRate9579;) oder auf data rate toggle eingestellt sein (int TOGGLE_DATA_RATE = 30;)
EMT7110-1.jpg: Der obere plot zeigt meinen Luftentfeuchter im Keller, der 18:15 von entfeuchten auf ventilieren umgeschaltet hat. Der unterer Plot ist das Laptop, an dem ich gerade arbeite. Ob ich wohl von der EEG-Umlage befreit werden könnte?
Attribute (siehe EMT7110-2.jpg):
accumulatedPowerOffset:
Der EMT7110 liefert den akkumulierten Verbrauch. Um ihn zurückzusetzen muss man die Batterien rausnehmen. Wenn man sich das ersparen will, kann man accumulatedPowerOffset setzen. Das Reading "accumulatedPower" erechnet sich aus dem vom Sensor gelieferten Wert minus "accumulatedPowerOffset".
pricePerKWH:
Was eine Kilowattstunde kostet. Daraus erechnet sich das reading "costs"
Readings (siehe EMT7110-2.jpg):
Das "values" userReading, das man auf der Hardcopy sieht, einfach ignorieren, spielt keine Rolle hier
accumulatedPower
=accumulatedPowerMeasured - accumulatedPowerOffset
accumulatedPowerMeasured
Der akkumulierte Verbrauch, der vom Sensor geliefert wurde
costs
accumulatedPower * pricePerKWH
current
Der gemessene Strom in mA
power
Die gemessene Leistung in Watt
voltage
Die gemessene Spannung in Volt
values
V=Spannung C=Strom P=Leistung A=akkumulierter Verbrauch
WT440XH
Unterstützung für den Temperature / Feuche Sensor WT440XH
Der Sensor wird empfangen und als LaCrosse IT+ Sensor an FHEM weitergegeben, also FHEM-seitig genau so verarbeitet wie z.B. ein TX29DTH
Der Sensor kann 15 Hauscodes und 4 Adressen. Die ID des Sensors in FHEM ist Hauscode mal Adresse.
Da ich keinen WT440XH habe, konnte ich das leider nicht testen, pejonp: ich bitte um Rückmeldung.
Hallo in der Runde,
ich brauch mal euere Hilfe.
Habe mir den neuen 10er Sketch draufgezogen und nur erkennt er meine Technoline TX29IT nicht mehr.
Den Cul habe nicht abgezogen... Nur den Jeelink.
Im Log sieht das ganze so aus:
Zitat2014.05.30 19:40:06 5: JLLaCR dispatch OK 9 27 1 4 133 106
2014.05.30 19:40:06 3: LaCrosse Unknown device 1B, please define it
2014.05.30 19:40:08 5: JeeLink/RAW: /OK 9 38
2014.05.30 19:40:08 5: JeeLink/RAW: OK 9 38 /1 4 201 106
2014.05.30 19:40:08 5: JLLaCR dispatch OK 9 38 1 4 201 106
2014.05.30 19:40:08 3: LaCrosse Unknown device 26, please define it
2014.05.30 19:40:14 5: JeeLink/RAW: /OK 9 27 1 4 133 106
Opening JLLaCR device /dev/ttyUSB0
2014.05.30 19:08:14 3: Setting JLLaCR baudrate to 57600
2014.05.30 19:08:14 3: JLLaCR device opened
2014.05.30 19:08:15 3: LaCrosse_EC: I/O device is JLLaCR
2014.05.30 19:08:16 3: LaCrosse_A4: I/O device is JLLaCR
2014.05.30 19:08:16 3: LaCrosse_B8: I/O device is JLLaCR
Zusätzlich ist noch ein Cul installiert
Opening CUL_0 device /dev/ttyACM0
2014.05.30 19:08:08 3: Setting CUL_0 baudrate to 9600
2014.05.30 19:08:08 3: CUL_0 device opened
2014.05.30 19:08:08 3: CUL_0: Possible commands:Nu habe ich den Verdacht, dass ich bei der Installation des Sketches irgendwas falsch gemacht habe.
Tippe mal auf das da: Einbinden der Jeelabs Library in die Arduino IDE (http://www.fhemwiki.de/wiki/Jeelink)
Da brauche ich wohl heute ne Anleitung für Noobs... An den Kopf kratz...
Falls Du bisher den ganz alten Sketch drauf hattest, dann liegt das vermutlich daran, dass sich inzwischen die Berechnung der IDs geändert hat. Die war nämlich falsch. Der Sketch liefert lt. Log Daten für Sensoren mit den IDs 1B und 26.
Ändere mal die Definition der Sensoren auf diese IDs ab.
Also so:
define mySenoreName1 LaCrosse 1B
define mySenoreName2 LaCrosse 26
Version 10.1b
Ich habe den Schalter für die alte ID-Berechnung von 2012 wieder eingebaut.
#define USE_OLD_IDS 1 // Set to 1 to use the old ID calcualtion
So konfiguriert liefert der Sketch IDs gem. der alten Berechnung. Ich empfehle aber eher die IDs in der Definition der Sensoren anzupassen.
Danke das war's.
Zitat von: dieda am 30 Mai 2014, 22:07:34
Danke das war's.
Hast Du nun den 10.1a oder 10f drauf?
Ich habe den Offiziellen also 10f drauf und die Def geändert.
Sehe ich das richtig, dass EMT7110 und LaCrosse-Sensoren parallel auf einem Jeelink benutzt werden können? Oder sind hier zwei Jeelinks notwendig?
Hat jemand mal die Genauigkeit des EMT7110 gemessen? Misst er zuverlässig/korrekt Spannung und Strom?
EMT7110, LaCrosse-Sensoren (TX29DTH, TX35, ...) und LevelSender laufen zusammen auf einem JeeLink
Flashen des JeeLink von FHEM aus
Da es mir lästig wurde, immer in den Keller zum Raspi zu laufen, um den JeeLink zu flashen, habe ich eine flash Funktion in das 36_JeeLink.pm Modul eingebaut.
Voraussetzung: avrdude ist auf dem Raspi installiert. Falls nicht, dann mit "sudo apt-get install avrdude" installieren.
Das JeeLink modul hat ein neues Attribut "hexFile". Dieses kann man auf ein beliebiges .hex File setzen. In meinem Fall habe ich im FHEM Verzeichnis ein Verzeichnis hexfiles angelegt, in dem die LaCrosseITPlusReader10.hex liegt. Das Verzeichnis kann aber auch an jeder bleibigen anderen Stelle im Dateisystem liegen. Der fhem user muss dort aber Leserechte haben.
Beispiel: attr myJeeLink hexFile ./hexfiles/LaCrosseITPlusReader10.hex
Flashen:
set myJeeLink flash
verwendet das File aus dem Attribut hexFile
set myJeeLink flash /home/pi/Test.hex
verwendet das angegebene File
Nach dem Flash-Vorgang wird ein Protokoll angezeigt. Beispiel:
flashing JeeLink myJeeLink
hex file: ./hexfiles/LaCrosseITPlusReader10.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./hexfiles/LaCrosseITPlusReader10.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./hexfiles/LaCrosseITPlusReader10.hex"
avrdude: input file ./hexfiles/LaCrosseITPlusReader10.hex auto detected as Intel Hex
avrdude: writing flash (16652 bytes):
Writing | ################################################## | 100% 2.53s
avrdude: 16652 bytes of flash written
avrdude: verifying flash memory against ./hexfiles/LaCrosseITPlusReader10.hex:
avrdude: load data flash data from input file ./hexfiles/LaCrosseITPlusReader10.hex:
avrdude: input file ./hexfiles/LaCrosseITPlusReader10.hex auto detected as Intel Hex
avrdude: input file ./hexfiles/LaCrosseITPlusReader10.hex contains 16652 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.92s
avrdude: verifying ...
avrdude: 16652 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
@justme1968: könntest Du das in den trunk übernehmen?
Dann würde ich bei zukünftigen Versionen vom LaCrosseITPlusReader10 auch das hex File mitliefern.
Ich habe meine Änderungen in
### HCS ###
...
### /HCS ###
geklammert.
die idee ist klasse. vielleicht können wir dir stelle für die firmware noch irgendwie standardisieren. das betrifft nicht nur das jeelink modul. cul und eventuell homematic für ota updates sind auch betroffen. für die panstamps möchte ich auch ein ota firmware update ermöglichen.
gruss
andre
Ja, ein standardisierter Ablageort wäre auch praktisch. Momentan geht das hexFile Attribut und die Angabe bei flash. Reihenfolge der Berücksichtigung könnte sein:
- Angabe bei flash
- hexFile Attribut
- Standard Ort/Dateiname
Ich würde noch gerne am Ende des flashens (anstatt dem JeeLink_SimpleWrite($hash, "v");) ein rereadcfg absetzten. Wie macht man das denn im Modul?
die reihenfolge finde ich auch gut. ich hab mal hier: http://forum.fhem.de/index.php/topic,24190.0.html (http://forum.fhem.de/index.php/topic,24190.0.html) einen thread dazu aufgemacht. mal sehen was die anderen sagen.
ein rereadcfg automatisch anzustossen ist keine gute idee. abgesehen davon das es sowieso kein guter weg ist etwas zu initialisieren weil hierbei fhem komplett angehalten und neu gestartet wird gehen hierbei alle nicht gespeicherten änderungen verloren.
was genau möchtet du denn damit bewirken? ein einfaches neu öffnen des device sollte völlig ausreichen. also genau das was beim abziehen und wieder anstecken auch passieren würde.
gruss
andre
Meine fhem.cfg sieht so aus:
define myJeeLink JeeLink /dev/ttyUSB0@57600
attr myJeeLink Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
attr myJeeLink group Hardware
attr myJeeLink hexFile ./hexfiles/LaCrosseITPlusReader10.hex
attr myJeeLink room System
define JLA1 at +00:00:05 set myJeeLink raw 30t
define JLA2 at +00:00:06 set myJeeLink raw v
Ich muss dem JeeLink in den Toggle mode bringen und evtl. noch einige weitere kommandos senden.
Bedeutet: der "raw 30t" und weitere müssen irgend wo hin (konfigurierbar), wo er beim Start von FHEM, bei einen rereadcfg und nach dem Flashen ausgeführt wird.
Nachtrag: und wie mir gerade klar wurde, auch beim neu anstecken.
ich wollte die kommandos die bei device öffnen gesendet werden per attribut konfigurierbar machen. idee: mit / oder leezreichen retrennte sequenz von init strings. in deinem fall wäre es also einattr myJeeLink initCommands 30t v
das handling von state und STATE wollte ich eigentlich auch noch reparieren. dann kann man die initialisierung in einem notify machen.
für die 'standard' module wie z.b. LaCrosse würde ich einen default der für alle gelten kann aber in JeeLink_Parse unterbringen. da werden auch die anderen sketeches nach einem testet initialisiert. der teil für LaCrosseITPlusReader macht noch nichts.
wenn ich die nächste version einchecke ist auf jeden fall schon 1. oder 2. dabei. wenn du zeit und lust hat kannst du gerne schon etwas davon einbauen.
Zitat von: justme1968 am 01 Juni 2014, 19:23:35
attr myJeeLink initCommands 30t v
Das ist genau das, was ich brauche.
Mit Leerzeichen getrennt sollte gehen, zumindest im LaCrosseITPlusReader10 Sketch gibt es keine Kommandos, die Leerzeichen enthalten müssen.
Das könnte ich nächste Woche mal versuchen einzubauen.
In welche Version von 36_JeeLink.pm denn? Ich glaube den flash habe ich auch nicht in die aktuellste eingebaut.
Den Rest überlasse ich lieber Dir.
wenn du das mit dem attribut versuchen magst am besten mit der aktuell eingecheckten verstion.
wenn du den patch zum flashen auch da ein bauen kannst wäre es für mich einfacher es dann einzuchecken.
gruss
andre
Und noch eine off-topic Frage: wie kann man denn in diesem Forum so auf einen Thread verlinken, dass man immer auf dem aktuell letzten Beitrag landet?
Zitat von: justme1968 am 01 Juni 2014, 19:44:31
wenn du das mit dem attribut versuchen magst am besten mit der aktuell eingecheckten verstion.
wenn du den patch zum flashen auch da ein bauen kannst wäre es für mich einfacher es dann einzuchecken.
OK, dann hole ich mir die aus dem Trunk und baue dort den flash und das initCommands Attribut ein.
Ich melde mich hier wieder, wenn es fertig ist.
Das hier http://forum.fhem.de/index.php/topic,17697.msg173348.html#msg173348
erledige ich dann auch noch.
ich glaube man kann nur auf bestimmte beiträge verlinken. nicht auf den neuesten.
das wichtige ist das der sketch nach dem erst zumindest seine version meldet. das format sollte so sein:
Zitat[LaCrosseITPlusReader.10.1c]
daran wird dann die default init sequenz im fhem modul fest gemacht.
die hilfe an sich ist für fhem nicht wichtig. das ist eher um die sketches einheitlich zu haben.
ich glaube ich hatte da aber schon mal etwas eingebaut. kann natürlich sein das das inzwischen wieder verloren gegangen ist. aber wenn du eh dabei bist schau noch mal danach.
Zitat von: HCS am 30 Mai 2014, 05:12:47
Version 10.1a
Der Sensor kann 15 Hauscodes und 4 Adressen. Die ID des Sensors in FHEM ist Hauscode mal Adresse.
Da ich keinen WT440XH habe, konnte ich das leider nicht testen, pejonp: ich bitte um Rückmeldung.
HCS vielen Dank für die gute Arbeit und auch allen anderen die hier mitwirken.
Habe im WT440XH.cpp die CRC Prüfung angepaßt, da kein WT440XH erkannt wurde.
Und habe die Berechnung der Geräte-ID angepaßt.
frame->ID = (byte)(houseCode * deviceCode);
bei houseCode = 1 und deviceCode = 2 --> ID = 2
bei houseCode = 2 und deviceCode = 1 --> ID = 2 , ist schlecht zu unterscheiden.
OK, werde es übernehmen und nächste Woche eine neue Version veröffentlichen.
Zitat von: HCS am 31 Mai 2014, 17:59:01
EMT7110, LaCrosse-Sensoren (TX29DTH, TX35, ...) und LevelSender laufen zusammen auf einem JeeLink
Bei den ursprünglichen Versionen konnte man auch noch den ETH200comfort (Heizungsthermostat) ansprechen oder verwechsele ich diese jetzt mit einen anderen Sketch.
ja, verwechselt
Kann es sein, dass zu dem Zeitpunkt, zu dem die DefFn läuft, die Attribute noch nicht verfügbar sind? Ich bekomme da mit AttrVal(... keinerlei Werte.
ja.
die attribute werden nach dem define erst gesetzt.
in dern AttrFn bekommst du das setzen und löschen mit.
gruss
andre
Das mit der AttrFn klappt auch nicht so recht. Wenn sich nichts an den Atrributen ändert, kommt man da auch nicht durch. Z.B. JeeLink abziehen und wieder anstecken, ...)
Lässt sich irgend ein Weg finden, in der DefFn an die Attribute zu kommen?
Durch die JeeLink_DoInit (halt dann auch von der JeeLink_Define kommend) kommt man in allen relevanten Fällen durch (FHEM-Start, JeeLink anstecken, firmware flashen, rereadcfg, ...)
In den Fällen, in denen man das Attribut lesen kann, klappt das mit initCommands dann auch prima.
in der DefFn sind die attribute nicht gesetzt. aber da brauchst du sie doch auch gar nicht.
die sketches werden alle in JeeLink_Parse initialisiert. nach dem reset sendet der sketch von sich aus seine identifikation. wenn dabei in parse der state noch auf opened und noch nicht auf initialized steht muss die init sequenz geschickt werden.
das ganze ist asynchron. fhem macht das device auf. irgendwann meldet sich der sketch. unter umständen auch erst später wenn er irgendwann nach dem define angesteckt wird. und dann sendet fhem die init sequenz.
wenn bei (STATE eq "Opened") das attribut gesetzt ist sollte das gesendet werden statt den sketch spezifischen defaults.
gruss
andre
OK, verstanden, wie das gehen soll. Da war ich auf einem ganz anderen Weg.
Funktioniert
Hallo HCS,
habe heute mein Pollin-Paket erhalten und gleich deine Erweiterung für EMT7110 getestet.
Funktioniert soweit prima.Tolle Arbeit :D
Das einzige was mir aufgefallen ist, das das Reading für Power immer bei mir doppelt so viel anzeigt als Verbraucht wird.
Getestet mit einer Glühbirne also bei 60Watt =power 128
bei 40Watt =power 89
die restlichen Werte sind soweit ich das beurteilen kann richtig.
Ist das bei dir auch so? ist meine EMT7110 defekt? oder muß der Wert noch durch 2 geteilt werden?
Gruß Bernd
Zitat von: Bastelbernd am 03 Juni 2014, 15:09:35
Ist das bei dir auch so? ist meine EMT7110 defekt? oder muß der Wert noch durch 2 geteilt werden?
Das ist tatsächlich falsch und ich habe den Fehler gerade gefunden. Sorry, dass mir das entgangen ist, mich hat bisher nur der akkumulierte Verbrauch so richtig interessiert.
Ich muss eh eine neue Version vom Sketch machen, wegen der WT440XH Korrektur und der Initialisierung. Da ist es dann gefixt. Eventuell heute Abend oder am Donnerstag.
Zitat von: Alex8508 am 31 Mai 2014, 11:12:59
Hat jemand mal die Genauigkeit des EMT7110 gemessen? Misst er zuverlässig/korrekt Spannung und Strom?
Ich habe gerade mal mein altes "nicht Funk" Messteil hinter den EMT7110 gesteckt.
EMT7110: 46 Watt das Andere 45 Watt.
EMT7110: 225 Volt, das Andere 226 Volt.
Entweder gehen beide gleich falsch oder beide richtig.
Die 60 Watt Birne von Bastelbernd ergibt ohne den Programmfehler 64 Watt.
Die hat aber auch bestimmt nicht exakt 60 Watt.
Nachtrag: Multimeter sagt 227 Volt.
Zitat von: justme1968 am 02 Juni 2014, 21:40:24
nach dem reset sendet der sketch von sich aus seine identifikation.
Was sendet denn FHEM an den Sketch, um einen Reset auszulösen?
Version 10.1c
ToggleDataRate fix
Toggle von mehr als 32 Sekunden haben nicht funktioniert
EMT7110 Power Reading
Das Reading war doppelt so hooch wie der tatsächliche Wert
WT440XH
Die Änderungen von pejonp (crc und ID Berechnung) wurden übernommen
Initialisierung
Nach der Initialisierung wird die Versionsinfo gesendet
LaCrosseITPlusReader10.zip
Das compilierte .hex File liegt nun im Verzeichnis HexFiles bei.
@justme1968: anbei das JeeLink modul.
Eingebaut habe ich:
- flash
- initCommands
Hallo in der Runde,
könnte es sein, dass sich die Komponenten Cul mit FS20 und Jeelink mit dem Sketch 10.f nicht vertragen?
Ich wollte gerade eine neue Steckdose anlernen und bekam diese Meldung:
2014.06.03 21:15:06 3: JLLaCR: Unknown code ## CRC FAIL ##, help me!
2014.06.03 21:15:06 3: JLLaCR: Unknown code ## UNSUPPORTED START ##, help me!
2014.06.03 21:15:06 3: JLLaCR: Unknown code Start receiver, help me!
2014.06.03 21:15:06 3: JLLaCR: Unknown code Stop receiver, help me!
2014.06.03 21:15:06 3: JLLaCR: Unknown code End receiving, HEX raw data: 9C 86 20 42 28 , help me!
2014.06.03 21:15:07 3: JLLaCR: Unknown code Start receiver, help me!
2014.06.03 21:15:07 3: JLLaCR: Unknown code Stop receiver, help me!
2014.06.03 21:15:07 3: JLLaCR: Unknown code End receiving, HEX raw data: 99 86 34 6A 6F , help me!
2014.06.03 21:15:08 3: JLLaCR: Unknown code Start receiver, help me!
2014.06.03 21:15:08 3: JLLaCR: Unknown code Stop receiver, help me!
2014.06.03 21:15:08 3: JLLaCR: Unknown code End receiving, HEX raw data: 9F F0 E3 BD 3F , help me!
Die Steckdose lies sich nicht anlernen...
Zitat von: dieda am 03 Juni 2014, 21:18:29
2014.06.03 21:15:06 3: JLLaCR: Unknown code Start receiver, help me!
2014.06.03 21:15:06 3: JLLaCR: Unknown code Stop receiver, help me!
2014.06.03 21:15:06 3: JLLaCR: Unknown code End receiving, HEX raw data: 9C 86 20 42 28 , help me!
Warum hast Du denn den LaCrosseITPlusReader10 Sketch im Debug-Mode laufen?
ZitatWas sendet denn FHEM an den Sketch, um einen Reset auszulösen?
fhem schliesst und öffnet das device. dadurch wird bei (allen?) normalen arduinos und jeelinks ein reset ausgelöst.
ich hab das modul mit zwei kleinen änderung eingecheckt:
- das initCommands attribut überschreibt alle eingebauten defaults für den init string. es ist also nicht nur mit dem LaCrosse sketch verwendbar.
- das senden von 'v' in JeeLink_DoInit habe ich raus genommen. das kann nicht drin bleiben weil es sketche gibt die es nicht vertragen wenn man einfach etwas hin sendet. der sketch muss von sich aus nach dem reset aus setup() den versions string senden.
das flashen hab ich erst mal fast so wie es ist drin gelassen.
- geändert habe ich nur den default namen des hex files:
JeeLink-LaCrosseITPlusReader10.hexda müssen wir aber späternoch ein paar dinge anpassen:
- der pfad für das log file sollte aus den fhem defaults geholt werden
- den pfad für die hex files sollten wir anpassen wenn es im anderen thread noch meinungen dazu gibt
- die doku im commandref teil fehlt :)
Zitat von: HCS am 03 Juni 2014, 21:23:14
Warum hast Du denn den LaCrosseITPlusReader10 Sketch im Debug-Mode laufen?
Weil sich die Steckdose eine FS20 nicht koppeln lies.
den sketch hab ich auch eingecheckt.
vielleicht findet sich noch jemand der die wiki seiten aktualisiert und die neuen devices und features beschreibt.
gruss
andre
Zitat von: justme1968 am 03 Juni 2014, 21:38:03
fhem schliesst und öffnet das device. dadurch wird bei (allen?) normalen arduinos und jeelinks ein reset ausgelöst.
OK, dann muss ich nochmal checken, warum bei mir der JeeNode (per FTDI am Raspi) keinen Reset macht.
Zitat von: justme1968 am 03 Juni 2014, 21:38:03
der sketch muss von sich aus nach dem reset aus setup() den versions string senden.
Tut er, nur macht er scheinbar manchmal keinen Reset. Beim Anstecken klapp das, bei einem SHUTDOWN RESTART nicht.
Zitat von: justme1968 am 03 Juni 2014, 21:38:03
da müssen wir aber späternoch ein paar dinge anpassen:
- der pfad für das log file sollte aus den fhem defaults geholt werden
Machst Du oder soll ich?
Zitat von: justme1968 am 03 Juni 2014, 21:38:03
da müssen wir aber späternoch ein paar dinge anpassen:
- die doku im commandref teil fehlt :)
Meinst Du das html am unteren Ende? Landet das dann in der commandref?
Das kann ich gerne noch aktualisieren.
ZitatMachst Du oder soll ich?
mach nur wenn du zeit und lust hast :). ich komme grad nicht dazu.
ZitatMeinst Du das html am unteren Ende? Landet das dann in der commandref?
ja. das ist der text der in der commandref landet. nach änderungen unbedingt ein mal commandref_join.pl drüber laufen lassen und auf fehlermeldungen achten.
ich hab initCommands schon eingebaut. zum flashen aber noch nichts.
gruss
andre
ps: du hattest in deinem file dos zeilenenden. rudi ist da alergisch gegen.
OK ich mache den Pfad für das logfile und kümmere mich um die commandref
Zitat von: justme1968 am 03 Juni 2014, 22:06:33
ps: du hattest in deinem file dos zeilenenden. rudi ist da alergisch gegen.
Ja klar, ich entwickle in Visual Studio ;D
Wenn ich nächstes mal dran denke, dann mache ich sie raus. Aber vermutlich werde ich es vergessen ...
schau mal hier: http://forum.fhem.de/index.php/topic,11648.msg174074.html#msg174074 (http://forum.fhem.de/index.php/topic,11648.msg174074.html#msg174074). da möchte jemand noch zusätzliche parameter an avrdude übergeben.
mein vorschlag wäre ein attribut avrdudeParams das einfach mit auf die kommandozeile gepackt wird. einverstanden ?
gruss
andre
Idee:
Ein Attribut flashCommands: Liste von Kommandos (mit # oder was auch immer getrennt), die Platzhalter enthalten können
[PORT]
[HEXFILE]
[LOGFILE]
werden mit dem jeweiligen Wert ersetzt.
Beispiel:
attr myJeeLink flashCommands /tools/resetMyBoard.sh # avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
führt dann aus:
/tools/resetMyBoard.sh
avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./hexfiles/LaCrosseITPlusReader10.hex 2>./log/JeeLinkFlash.log
Damit kann das dann jeder so gestalten, wie er es braucht.
Wenn flashCommands nicht gesetzt ist, dann als default das machen, was jetzt auch passiert.
ja. einverstanden.
du kannst übrigens in der defineFn das attribut hart setzen. dann ist es default bis es vom anwender überschrieben wird. er sieht was möglich ist und man sparst sich die sonderbehandlung wenn nichts ersetzt ist.
einfach dein default direkt dem attribut hash zuweisen wenn noch nichts ersetzt ist.
gruss
andre
ps: # ist kein gutes trennzeichen. alles dahinter zählt im config file als kommentar. ich denke wir brauchen gar kein trennzeichen. bzw einfach ; und alles in einem rutsch an dir shell übegeben.
Mache ich so.
Da brauche ich aber das kommende lange Wochenende dazu.
Hast Du einen besseren Vorschlag als # für das Trennzeichen oder sollen wir das nehmen?
Nachtrag: Und frag bitte mal den Kollegen aus dem anderen Thread, ob es das ist, was er bräuchte.
ich glaube wir brauchen gar kein trennzeichen.
- entweder kann avrdude den reset selber dann reicht ein kommando
- man kann mehrere kommandos mit ; getrennt in das attribut stecken -> die shell macht das richtige
- wenn das nicht mehr reicht steckt man selber alles in ein shellscript und gibt das als kommando an
das attribut sollte dann aber vielleicht flashCommand heissen. nicht flashCommands.
gruss
andre
Ich denke, das würde mir genügen, um das Platinchen bedienen zu können. Universeller geht es nicht. Es ist dann für praktisch jede Plattform nutzbar.
OK
Zitat von: HCS am 30 Mai 2014, 05:12:47
Version 10.1a
Beim JeeLink muss der EMT7110 im Clients-Attribut hinzugefügt werden ...
Hallo HCS,
könnte diese Erweiterung von Dir auch noch in den 34_JeeLink.pm eingebaut werden oder ist es nicht nötig ? Ich habe es bei mir von Hand eingetragen. Beim "update" wird es doch bestimmt überschrieben. Vielen Dank.
Zitat von: pejonp am 04 Juni 2014, 18:00:32Ich habe es bei mir von Hand eingetragen. Beim "update" wird es doch bestimmt überschrieben. Vielen Dank.
Nicht in die 34_JeeLink.pm eintragen sondern im Clients Attribut ergänzen. Das bleibt auch beim Update erhalten.
Siehe Hardcopy EMT7110-3.jpg in diesem Beitrag: http://forum.fhem.de/index.php/topic,14786.msg172692.html#msg172692
justme1968: man könnte aber auch das 36_EMT7110.pm einchecken und beim JeeLink Modul den EMT7110 als default mit aufnehmen.
Moin!
ZitatNicht in die 34_JeeLink.pm eintragen sondern im Clients Attribut ergänzen.
Das reicht aber noch nicht, um eingene Clients zu betreiben.
Im Code habe ich bei mir folgende Anpassungen:
Zitatmy $clientsJeeLink = ":PCA301:EC3000:RoomNode:LaCrosse:GSD:ETH200comfort:CUL_IR:HX2272:FS20:AliRF";
my %matchListPCA301 = (
"1:PCA301" => "^\\S+\\s+24",
"2:EC3000" => "^\\S+\\s+22",
"3:RoomNode" => "^\\S+\\s+11",
"4:LaCrosse" => "^\\S+\\s+9 ",
"5:AliRF" => "^\\S+\\s+5 ",
"6:GSD" => "^GSD",
);
Mit dem Attribute 'Clients' kann ich die erste Änderung konfigurativ durchführen. Wenn ich jedoch irgendwas in die Attribute MatchList setze, stürzt FHEM kommentarlos ab. Wie ergänze ich die Match-Liste?
Grüße,
Alexander
match list geht noch nicht.
gruss
andre
Ok, danke!
Grüße,
Alexander
Wir haben wohl den Verkauf angekurbelt 8)
sind ja auch schon etwas 200 benutzer :)
Ich überarbeite gerade die Hilfe für das 36_JeeLink.
Kann mir jemand den Hilfetext für "set beep" und "set setReceiverMode" liefern (in Englisch)?
Da die im LaCrosseITPlusReader nicht verwendet werden, habe ich leider keine Anhnung für welchen Sketch die sind und was sie tun.
Danke.
Guten Tag,
Ich möchte gerne ein Feature-Request für das Modul vorschlagen: Ansprechschwelle.
Damit soll dann das leichte 'Zittern' vom Messwert im Bereich von 0,1-0,2°C sicher ausgefiltert und die Datenmenge reduziert werden.
Resolution hat ähnlichen effekt, greift aber anscheinend nicht, wenn der Messwert genau an der Schwelle zwischen 2 Resolution-Stufen schwankt.
Das ganze könnte dann in etwa so aussehen(Excel-Format, PERL kenne ich leider noch nicht):
=WENN(ABS(NEUWERT-ALTWERT)>=SCHWELLE;NEUWERT;ALTWERT)
Die Ansprechschwelle sollte man am besten zusammen mit doAverage verwenden, um die einzelnen Sprünge in der Kurve zu glätten.
@Virgon
ZitatIch möchte gerne ein Feature-Request für das Modul vorschlagen: Ansprechschwelle.
Gute Idee! :)
@ AndreKönnte man das generell für alle Devices einführen die messen?
event-on-change-reading --> müsste dann aber darauf aufsetzen? (Schwellwererkennung)
Hätte den Vorteil dass man, so gewünscht, deutlich weniger Logeinträge hätte.
Gruß Billy
ich habe eine idee wie das gehen könnte. ich muss mal probieren ob das geht.
es muss nicht nur mit event-in-change sondern auch mit event-min-interval zusammen funktionieren.
also zusätzlich ein event-threshold
gruss andre
Zitat von: justme1968 am 07 Juni 2014, 13:09:32
ich habe eine idee wie das gehen könnte. ich muss mal probieren ob das geht.
es muss nicht nur mit event-in-change sondern auch mit event-min-interval zusammen funktionieren.
also zusätzlich ein event-threshold
gruss andre
Genau das wär,s :D
Gruß Billy
ich hab es noch in das event-on-change attribut rein gepackt: http://forum.fhem.de/index.php/topic,24378.0.html (http://forum.fhem.de/index.php/topic,24378.0.html).
gruss
andre
Danke, :)
Ich gehe mal davon aus, dass Rudi den patch in fhem.pl einspielt.
Gruß Billy
das weiß ich nicht :)
ein paar tester Schaden vielleicht nicht.
gruss
andre
Anbei die überarbeitete 36_JeeLink.pm
Erledigt:
set led <on|off>
Funktioniert nun auch mit dem LaCrosse Sketch
Log-File bei set flash
Der Pfad für das log file, das bei set flash geschrieben wird, verwendet nun das Attribut logdir aus global, falls definiert.
Doku
Ist überarbeitet
Neues Attribut flashCommand
Der default ist: avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Die Platzhalter [PORT] [HEXFILE] [LOGFILE] werden beim flash Vorgang mit den entsprechenden Werten ersetzt. Damit kann man den avrdude-Aufruf an seine eigenen Bedürfnisse anpassen.
Zitat von: justme1968 am 07 Juni 2014, 15:29:38
ich hab es noch in das event-on-change attribut rein gepackt: http://forum.fhem.de/index.php/topic,24378.0.html (http://forum.fhem.de/index.php/topic,24378.0.html).
gruss
andre
Hallo Andre, soeben eingecheckt und getestet!
Sieht gut aus. ;D
Geht auch ein threshold mit z.B power:0.01 oder gibt es eine Grenze nach unten?
Habe den Test jetzt mit power:0.1 am Laufen.
Gruss Billy
Die Hilfe im 36_EMT7110.pm habe ich dann auch gleich noch überarbeitet.
Und den Fehler, dass set resetAccumulatedPower fälschlicherweise accumulatedPower anstatt accumulatedPowerMeasured übernommen hat, habe ich auch noch behoben.
@billy: es gibt keine eingebaute grenze außer der rechengenauigkeit.
@HCS: wie wäre es wenn du für das EMT modul selber den zugang zum svn beantragst? dann kannst es selber pflegen. ich habe schon genug module bei denen ich die entsprechende hardware gar nicht habe :)
gruss
andre
-- taptalk hat gesponnen --
Zitat von: justme1968 am 07 Juni 2014, 20:18:42
@HCS: wie wäre es wenn du für das EMT modul selber den zugang zum svn beantragst? dann kannst es selber pflegen. ich habe schon genug module bei denen ich die entsprechende hardware gar nicht habe :)
Wo ist das Antragsformular und wo muss ich es abgeben?
ich hab eben eine aktualisierte 36_JeeLink.pm eingecheckt.
den svn zugang bekommst du über rudi (oder boris?). am besten irgendwo posten so das sie es sehen.
gruss
andre
@hexenmeister: schau mal ob du mit MatchList jetzt was anfangen kannst.
gruss
andre
Zitat von: justme1968 am 07 Juni 2014, 22:01:48
den svn zugang bekommst du über rudi (oder boris?). am besten irgendwo posten so das sie es sehen.
Eine PM ging schon mal nicht. Geblockt >:(
Aber gerne doch. Wie ist Format bei diesem Attribut?
steht in der commandref :)
einfach ein perl ausdruck der den hash zurück liefert:attr myJeeLink MatchList {'5:AliRF' => '^\\S+\\s+5 '}
gruss
andre
Danke, habe auch schon im Quelltext nachgeschaut... (nachdem ich den faulen Schweinehund besiegt habe, der die vorherige Meldung diktiert hat ;D )
Melde gleich das Ergebnis...
Sehr geil ;)
Funktioniert gut. Ich hatte zwar ein (Total)Absturz beim Löschen des Attributes MatchList, konnte ihn aber nicht reproduzieren.
Vielen Dank!
Grüße,
Alexander
Wäre es evtl. praktisch, wenn die angegeben MatchList additiv zu der im Sketch vorhandenen wäre?
Hm, ja. Wohl aber weniger flexibel.
In jedem Fall sollen sich Attribute MatchList und Clients in diesem Sinne gleich verhalten.
Edit: additiv ist für Anfänger sicher weniger fehlerträchtig.
ich denke Clients und MatchList sollten beide nicht additiv sein weil es sonst nicht möglich nur einen neuen client zu spezifizieren.
eben. wenn du mehr als ein modul haben möchtest musst du halt alles hin schreiben.
aus irgendeinem grund geht das editieren in taptalk nicht mehr...
das glaube ich nicht. zum einen ist das attribut sowieso eher weniger anfänger tauglich und zum anderen werden die aller meisten zusätzlichen sketches nur exklusiv ein neues device unterstützen und dann wäre eine MatchList die nur erweitert werden kann kontraproduktiv.
So wie Clients und flashCommand wäre doch praktisch. Ist vorbelegt, kann erweitert aber auch reduziert werden.
Zitat von: justme1968 am 07 Juni 2014, 22:01:48
den svn zugang bekommst du über rudi (oder boris?). am besten irgendwo posten so das sie es sehen
wo wäre den "irgendwo"?
Zitatwerden die aller meisten zusätzlichen sketches nur exklusiv ein neues device unterstützen und dann wäre eine MatchList die nur erweitert werden kann kontraproduktiv
es sei denn man hat zwei JeeLinks mit unterschiedlichen exclusiven sketches ;)
Aber ich sehe das eigentlich auch so. Nicht additiv ist flexibler.
aber eben gerade dann. das attribut ist doch device spezifisch. du setzt es für jeden deiner jeelinks auf genau die liste die das ding kann :)
aus irgendeinem grund geht das editieren in taptalk nicht mehr...
das glaube ich nicht. zum einen ist das attribut sowieso eher weniger anfänger tauglich und zum anderen werden die aller meisten zusätzlichen sketches nur exklusiv ein neues device unterstützen und dann wäre eine MatchList die nur erweitert werden kann kontraproduktiv.
Als Probelmatik hatte ich folgenden use case im Kopf (Beispiel):
Es gibt den LaCrosse Sketch, der kann LaCrosse
Ich erweitere den Sketch, dass er EMT kann und stelle das 36_EMT7110 Modul bereit
Nun muss der Anwender die Matchlist aus dem Quellcode in das Attribut übertragen und EMT hinzufügen
Dann erfinden wir ein weiteres Modul und fügen das der Matchlist im 36_JeeLink als default hinzu.
Nun müssen alle Anwender das im Attribut nachziehen (und natürlich erst mal drauf kommen, dass sie es tun müssen).
Das bedeutet: man kann einem "normalen" Anwender eher nicht empfehlen, das Attribut zu setzen, da er sonst bei zukünftigen Erweiterungen des 36_JeeLink erst mal drauf kommen muss, dass er seine MatchList überarbeiten muss.
Für Clients gilt das wohl auch.
Falls das Attrribut eher für Entwickler gedacht ist, damit sie ohne eine 36_JeeLink Änderung ihre neuen Module austesten können, dann ist das OK so.
Der Benutzer muss das Attribut doch erst dann setzen, wenn er das betroffene Gerät wirklich einsetzt. Da hat er sich mit der Thematik (hoffentlich) auseinandergesetzt und weis, was er tut. Ansonsten soll das in der Liste auch nicht stehen.
Ja, das meinte ich ja im Prinzip.
Das bedeutet aber, dass man dem Anwender nicht schreiben sollte "trag mal ... in Clients und Matchlist" ein (was ich unglücklicherweise für EMT bereits getan habe). Dann hat er sich nämlich vermutlich nicht mit der Thematik auseinandergesetzt und man hat sein zukünftiges Problem vorprogrammiert.
Der muss sich schon einlesen. Ansonsten haben wir irgendwann eine riesige Liste von Geräten, die kein Mensch mehr kennt. ;)
Zitat von: HCS am 07 Juni 2014, 21:50:55
Wo ist das Antragsformular und wo muss ich es abgeben?
Ich habe meinen Zugang über eine private Mail an Rudolf bekommen (nicht hier im Forum).
Gruß PeMue
Zitat von: PeMue am 08 Juni 2014, 13:06:29Ich habe meinen Zugang über eine private Mail an Rudolf bekommen (nicht hier im Forum)
Ja, danke für die Info. Habe inzwischen herausgefunden, dass man das im Profil beantragt. Jetzt warte ich mal ab, was passiert.
Inzwischen kann ich ja die Hilfe im 36_Level ordentlich schreiben. ;D
@ Andre
Add threshhold to event-on-change-readingZitat von: justme1968 am 07 Juni 2014, 15:29:38
ich hab es noch in das event-on-change attribut rein gepackt: http://forum.fhem.de/index.php/topic,24378.0.html (http://forum.fhem.de/index.php/topic,24378.0.html).
Habe jetzt seit ein paar Tagen den Test laufen.
Ergebnis: Das Zusammenspiel von
event-on-change-reading power:0.1 --> mit event-min-interval power:600 funktioniert nicht?
Hintergrund: Ich überwache mit einen HM-ES-PMSw1-Pl über den Verbrauch meines Rasenroboters
ob er sich in der Ladestation
befindet oder am mähen ist.Wenn er mäht verbraucht die Sendeschleife nur ca. power: 1.53 Watt. mit Schwankungsbreite vo +- 0.03 Watt.
Mit event-on-change-reading power:0.1 kann ich jetzt das unnötige Plotten reduzieren.
Um Stützpunkte zu erhalten wollte ich mit --> event-min-interval power:600 alle 10 Minuten einen Ploteintrag erzeugen.
Das scheint nicht zu funktionieren.
2014-06-11_13:58:39 Gardena_PM_Pwr power: 10.74 -->
2014-06-11_14:00:19 Gardena_PM_Pwr power: 3.17 --> Ende letzter Ladezyklus
2014-06-11_14:01:23 Gardena_PM_Pwr power: 1.51 --> Beginn Mähzyklus
--> jetzt fehlen die Einträge über event-min-interval power:600
2014-06-11_15:22:43 Gardena_PM_Pwr power: 1.48 --> Ende Mähzyklus
2014-06-11_15:32:07 Gardena_PM_Pwr power: 17.56 --> Anfang neuer Ladezyklus
Hast du eine Idee? Oder sehe ich was falsch?
Gruß Billy
Hallo,
ich würde gerne den aktuellen LaCrosse Sketch auf meinen Jeelink über fhem flashen. Ich habe es aber nicht ganz kapiert, was man jetzt machen muss. Die zip-Datei (36_LaCrosse-LaCrosseITPlusReader.zip) habe ich geladen.
Wo müssen jetzt die files hingepackt werden, damit ich das Modul mit flash aktualisieren kann?
Kann mir mal jemand auf die Sprünge helfen?
Danke,
Spartacus
Hallo,
hat jetzt geklappt! Der Dateiname aus der Zip Datei stimmte nicht mit dem Default-Namen überein!
Aber doch noch mal eine Frage:
kann man eigentlich mehrere Sketches parallel installieren? Oder geht immer nur ein Sketch pro Modul!
Danke,
Spartacus
Das hex file aus dem ZIP extrahieren und irgendwo hinlegen und dann mit
set myJeeLink flash /WoAuchImmer/LaCrosseITPlusReader10.hex
flashen
OK, gerade Deine Antwort gelesen. Den Dateiname werde ich in der nächsten Version anpassen.
Auf einem JeeLink kann immer nur genau ein Sketch installiert sein. Wenn man unterschiedliche benötigt, dann barucht man mehrere JeeLinks.
Hallo HCS,
danke für die Antwort.
Schade! Das wäre eine gute Sache gewesen, um zusammen mit den günstigen Funksteckdosen temperatur und luftfeuchteabhängig schalten zu können.
Aber generell finde ich das mit dem Flashen aus fhem fantastisch. Jetzt brauche ich den Kram nicht mehr aus dem Gartenhaus zu holen....
Tolle Sache!
Christian.
Hallo,
noch mal eine Frage:
Mit dem Befehl
set myJeelink led off
kann man das nervige Blinken der blauen LED abschalten. nach einem Reboot ist das Dingen aber wieder an. Kann man das nicht als attribut definieren?
Gruß,
Spartacus.
einattr myJeelink initCommands 0amüsste helfen.
gruss
andre
Hi,
super!
Vielen dank,
Christian.
Hallo,
habe am 10.6. abends ein Update gemacht und muss feststellen, das seitdem alles LaCrosse-Sensoren wieder die aus den Anfangszeiten bekannten "Wackelwerte" haben. Bei Temperaturen an der 0.1°C-Grenze wird das Log zugemüllt und die Plot's dauern entsprechend. Hat jemand eine Idee, wo der Fehler liegen könnte? Screenshots anbei.
Viele Grüße, Ricardo
Zitat von: kpwg am 14 Juni 2014, 13:01:39
habe am 10.6. abends ein Update gemacht ...
Hast Du nur FHEM upgedatet oder auch den Sketch auf dem JeeLink?
Kannst Du die 36_LaCrosse.pm aus dem Backup bereitstellen? Dann würde ich mal schauen, was der Unterschied zwischen der und der Aktuellen ist.
Guten Morgen,
ich habe (leider gleichzeitig) beides aufgefrischt. Auf dem Jeelink läuft
[LaCrosseITPlusReader.10.1c @AutoToggle 15 Seconds]
Hier ist noch die 36_JeeLink.pm aus dem Backup vom 10.6. um 19:57
Zitat von: HCS am 15 Juni 2014, 07:44:09
Kannst Du die 36_LaCrosse.pm aus dem Backup bereitstellen? ...
Ich wollte aber die 36_LaCrosse.pm
Stimmt... Sonntagmorgen braucht der Kaffee erst seine "Einwirkzeit" ::)
Die 36_LaCrosse hat sich gegenüber Deinem Backup und seit 2014-02-25 nicht geändert.
In der 36_JeeLink sehe ich keine Änderung, die da einen Einfluss haben könnte.
Der Sketch hat, soweit ich weiß, noch nie irgend welche thresholds oder Ähnliches gemacht.
Wenn mein Kaffee nicht noch mehr Wirkung entfaltet, komme ich da nicht dahinter :)
Eventuell hat es damit zu tun, das vermag ich aber leider nicht zu analysieren:
Zitat von: Billy am 11 Juni 2014, 16:35:45
Zitat von: justme1968 am 07 Juni 2014, 15:29:38
ich hab es noch in das event-on-change attribut rein gepackt: http://forum.fhem.de/index.php/topic,24378.0.html.
@ Andre
Add threshhold to event-on-change-reading
Habe jetzt seit ein paar Tagen den Test laufen.
Ergebnis: Das Zusammenspiel von
event-on-change-reading power:0.1 --> mit event-min-interval power:600 funktioniert nicht?
Sehr seltsam.... Mit threshold habe ich noch gar nichts gemacht.
Anbei nochmal die 36_LaCrosse.pm vom 11.6. 15:33 (Habe zu der Zeit gerade mit HM "gekämpft").
Aktuell habe ich die Sache mit doAverage 1 recht gut im Griff. Aber das ist keine wirkliche Problemlösung, oder?
doAverage mache ich schon immer bei meinen TX29DTH weil die schon immer 0.1 gezittert haben.
An der 36_LaCrosse.pm hat sich seit 25.02.14 nichts geändert, die ist aus dem Spiel.
Der neue treshold bei event-on-change-reading (http://forum.fhem.de/index.php/topic,24378.msg174929.html#msg174929) wurde ja genau aus dem Grund erfunden, um dieses Zittern wegzufiltern. Darum wundert es mich eh, warum das bei Dir ohne doAverage bisher OK war.
@justme1968: irgend eine Idee?
Zitat von: HCS am 15 Juni 2014, 09:02:46
doAverage mache ich schon immer bei meinen TX29DTH weil die schon immer 0.1 gezittert haben.
Ich las "damals" bei Inbetriebnahme auch von dem Zittern, hatte aber nie Probleme damit. Habe soeben ein paar alte Backups durchgesehen und nirgends
doAverage oder andere "Beruhigungs-Einträge" entdeckt. Einfach immer nur Glück gehabt? Wohl kaum... Wenn es nun geht, kann ich damit leben, jedoch wäre die Ursache schon interessant.
Hallo,
ich hoffe meine Frage ist hier richtig, kann man die Technoline TX29 dt-ht Temperatur/Feuchtigkeitsmesser auch mit einem CUL empfangen?
Wenn nein, was ist ein günstiger Weg um mehrere Temperatur/Luftfeucht-Messgeräte an FHEM anzubinden. Aktuell hab ich nur meine Wärmepumpe in FHEM und bin da noch relativ offen. Nur löten oder ähnliches möchte ich nicht.
Danke und Gruß,
Jakl
Zitat von: Jakl am 07 Juli 2014, 15:45:05
Hallo,
ich hoffe meine Frage ist hier richtig, kann man die Technoline TX29 dt-ht Temperatur/Feuchtigkeitsmesser auch mit einem CUL empfangen?
Wenn nein, was ist ein günstiger Weg um mehrere Temperatur/Luftfeucht-Messgeräte an FHEM anzubinden. Aktuell hab ich nur meine Wärmepumpe in FHEM und bin da noch relativ offen. Nur löten oder ähnliches möchte ich nicht.
Danke und Gruß,
Jakl
Siehe hier! http://forum.fhem.de/index.php/topic,24776.0.html
Ausserdem solltest du mitteilen auf welcher Basis FHEM bei dir läuft. :-\
Sonst kann man dir kaum helfen.
Billy
Vielen Dank für die Antwort. Mein FHEM läuft auf einem Raspberry Pi.
Der Thread läuft auf eine Lösung via 433Mhz raus, ich hätte gerne was via 868. :-)
Zitat von: Jakl am 07 Juli 2014, 16:41:24
Der Thread läuft auf eine Lösung via 433Mhz raus, ich hätte gerne was via 868. :-)
Nein, es geht hier um die 868MHz Sensoren mit dem LaCrosse IT+ Protokoll. Ganz am Anfang des Threads wurden jede Menge funktionierende Sensoren genannt.
So gesehen bist Du schon richtig. Ohne löten wird es ein JeeLink werden müssen.
Viele Grüße, Ricardo
Ich habe bereits seit einer ganzen Weile seltsame Ausgaben auf der Console, die allesamt von LaCrosse-Sensoren stammen:
Argument "T: 21.3 H: 59.5" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "T: 25.1" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "T: 25.1" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "T: 21.2 H: 59" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "T: 21.2 H: 59" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Argument "ok" isn't numeric in subtraction (-) at ./fhem.pl line 3567.
Im Logfile selbst ist alles ruhig. Hat jemand 'ne Idee?
Viele Grüße, Ricardo
du hast vermutlich event-on-change mit einem threshold definiert und lässt es auch ein nicht numerisches reading los.
gruss
andre
Ich habe event-on-change-reading .*:300 eingestellt.
eben. du gibst einen threshold für alle readings vor. das macht aber bei state keinen sinn weil es keine zahl ist. 300 als threshold verstehe ich auch nicht du willst ja nicht nur werte wenn sich etwas um mehr als 300 ändert.
mach die :300 weg.
gruss
andre
Danke, Andre, hat funktioniert! Ich wollte ansich bezwecken, das nur alle 300sec ein Eintrag ins Logfile kommt. Das macht aber bereits event-min-interval.
Viele Grüße, Ricardo
Hallo,
ich habe ein Problem mit einem LaCrosse Temperatursensor.
Dieser kann nur die Temperatur liefern, ich sehe im FHEM Gerät aber auch ein reading für die Luftfeuchtigkeit und Battery2.
Beides natürlich mit uraltem Datum und statischen Werten.
Woher kommt das, und wie kann ich das entfernen.
Hab im angehängten Bild markiert was ich meine.
Vielen Dank im Voraus.
Gruß
Matze
du kannst alte readings mit deletereading löschen.
es gab zwischendurch mal eine version des moduls die durch das mitteln falsche feuchtigkeits readings angelegt hat.
gruss
andre
Hat super geklappt.
Wieder mal viel Dank für die schnelle Antwort!
Hallo zusammen,
ich habe ein Problem den aktuellen Jeelin Sketch auf meinen JeeLink zu bekommen.
Ich habe mir die Arduino IDE 1.0.5 besorgt, und das LaCrosse Sketch:
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip
Aber bereits beim Überprüfen des Codes bekomme ich folgende Fehlermeldung:
"RFM12.cpp:2:24: error: util\delay.h: No such file or directory"
Warum ist die delay.h nicht in dem Package dabei? Ich kann ja nicht einfach irgendeine nehmen...
Auch bei dem Projekt RFM12 habe ich diese Datei um util Verzeichnis nicht gefunden.
Irgendwie glaube ich langsam, das ich ein prinzipielles Problem in meiner Installation zu haben, oder?
Bitte helft mir!!! :-)
Du benötigst einmal die RF12 Library und die .cpp und .h Dateien aus dem ZIP Paket gehören in den Arduino libraries Ordner.
https://github.com/jcw/jeelib
Vielen Dank für deine Hilfe Locutus.
Nachdem ich die RF12 Library installiert habe, habe ich trotzdem noch folgenden Fehler bekommen:
"RFM12.cpp:2:24: error: util\delay.h: No such file or directory"
Nach viel Fluchen habe ich herausgefunden woran es liegt:
Auf einem Mac (vermutlich auch Linux) darf der Pfad keinen Backslash \ enthalten.
Ich habe die Zeile entsprechend in
#include "util/delay.h"
angepasst, und jetzt funktioniert das Kompilieren.
Da ich öfter mal den Hinweis lese, dass man für den LaCrosse Sketch die Jeelabs Library installieren soll, habe ich mich gefragt, warum.
Antwort: weil es im FHEMWiki so steht.
Um den JeeLink mit Fhem benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
Für Windows oder Mac OS X den passenden FTDI Treiber installieren, unter Linux ist dieser meist schon vorhanden
Installation der Arduino Software für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
Einbinden der Jeelabs Library in die Arduino IDE
Herunterladen des benötigten Sketches
Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
Start der Arduino Software und JeeLink flashen
Die ist aber nicht erforderlich. Könnte das jemand mit Schreibrechten auf dem Wiki dort rausnehmen?
Also den Part "Einbinden der Jeelabs Library in die Arduino IDE"
Und wenn man schon dabei ist, könnte man dort auch einen Hinweis geben, dass es inzwischen die Möglichkeit gibt, vom JeeLink Modul aus das HEX file auf den JeeLink zu flashen und man sich, wenn man will, die ganze Arduino-IDE Installation sparen kann.
Zitat von: HCS am 24 Juli 2014, 21:26:07
Könnte das jemand mit Schreibrechten auf dem Wiki dort rausnehmen?
Also den Part "Einbinden der Jeelabs Library in die Arduino IDE"
Rausnehmen? Auf gar keinen Fall! Korrigieren bzw. ergänzen wäre der richtige Weg.
Die in der FHEMWiki beschriebene RoomNode benötigt nach wie vor die Jeelabs Library.
die pca301 auch. die lib zu installieren ist nicht wirklch aufwändig und schadet nicht.
ich füge aber einen hinweis hinzu. auch zum flashen.
gruss
andre
Ja, prima.
Weiter unten im Abschnitt "Lacrosse Sketch" ist dann auch noch ein Verweis drauf, und dann auch noch mit einem toten Link.
ich hab den artikel mal etwas überarbeitet und den link korrigiert.
schau mal bitte ob der teil 'flashen aus fhem' ausführlich genug ist.
gruss
andre
Ich denk, dass das ausreicht.
Ich bin gerade an dem Thema "Ablage der firmware Files" dran, dann wird es eh nochmal einfacher.
Hi,
bin neu in der Materie habe ein Raspberry PI mit aktueller Fhem Software, einen JeeLink 868 und einem CUL 868.
Leider bekomm ich den TX25IT nicht richtig zum laufen, er zeigt mir nur eine Temperatur, von zwei an.
Hat vll. jemand eine Idee?
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0@57600
FD 10
NAME myJeeLink
NR 30
PARTIAL
RAWMSG OK 9 18 1 4 223 64
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1c @17.241 kbps]
myJeeLink_MSGCNT 113408
myJeeLink_TIME 2014-08-03 20:24:38
Matchlist:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^\S+\s+9
5:AliRF ^\S+\s+5
Gruß Azze
Zitat von: Azze am 03 August 2014, 20:34:24
Leider bekomm ich den TX25IT nicht richtig zum laufen, er zeigt mir nur eine Temperatur, von zwei an.
Hat vll. jemand eine Idee?
Ich habe (leider) eine Idee. Es sieht so aus, als ob ich bei der ganzen Refakturierung des Sketch den TX25IT ruiniert habe.
Ich schaue mir das mal genauer an. Das Problem liegt wohl mit 99%iger Sicherheit im Sketch.
Also ich habe letzte Woche den TX25IT mit dem Sketch
LaCrosseITPlusReader.10.1c @17.241 kbps
problemlos zum laufen gebracht. :)
Gruß Billy
Dann habe ich es eventuell doch nicht ruiniert ;D
Du hast beide Temperaturen?
Ja selbstverständlich.
Hier die Readings:
Readings
battery ok 2014-08-03 22:00:53
battery2 ok 2014-08-03 22:00:40
state T: 16.9 2014-08-03 22:00:53
temperature 16.9 2014-08-03 22:00:53
temperature2 16.8 2014-08-03 22:00:40
Kann es sein, dass Azze nur auf das state schaut, da sieht man nur die 1. Temperatur. ;)
Lässt sich ändern mit
stateFormat T1: temperature T2: temperature2
Gruss Billy
Na denn ...
Wollte eigentlich im Code schauen, warum es nicht funktioniert.
Nun muss ich wohl schauen, warum das eigentlich funktioniert. ;D ;D ;D
Da gab es einen Part mit dem Kommentar
// bogus check humidity + eval 2 channel TX25IT
// TBD .. Dont understand the magic here!?
Das "TBD .. Dont understand the magic here!?" stammt noch von vor meiner Zeit.
Ich hatte gerade, ohne es anzuschauen, gewettet, dass ich es an der Stelle ruiniert habe.
Dann warten wir mal, was bei Azze rauskommt.
Vermutung ?
ZitatDas "TBD .. Dont understand the magic here!?" stammt noch von vor meiner Zeit.
Da hat wohl einer der Zwischendurch am Sketch war nicht gewusst, dass der TX25IT die 2. Temperatur über den Humidity Wert
darstellt, wenn dieser über einem bestimmten Wert liegt.
Hallo,
ich empfange einen LaCrosse von meinem Nachbarn, den ich bereits ignoriere.
attr LaCrosse_08 ignore 1
Anscheinend bekomme ich aber trotzdem notifies von diesem.
Meine Battery Notify schlägt für den ignorierten LaCrosse an.
Gibt es für die LaCrosse kein do_not_notify, wie es bereits für andere Geräte zu geben scheint?
Oder habe ich was übersehen?
Danke!
Gruß
Matze
Werde es die Tage mal testen mit den TX25IT.
Danke
hab mal mit stateFormat T1: temperature T2: temperature2 probiert, leider gehts damit auch nicht :-(
LaCrosse_2E T1: 24.7 T2: temperature2
das kommt dann
Mach mal ein
list LaCrosse_2E
und stell es hier ein.
Zusatzfrage? Auf dem Display des Sensors siehst du abwechselnd 2 Temperaturen?
Die angezeigte T1 stimmt mit dem Display überein?
Nicht dass du den Sensor eines Nachbarn eingefangen hast.
Billy hat wohl recht. Das ist kein TX25
RAWMSG OK 9 18 1 4 223 64Der hat hinten 64% Feuchte gesendet.
Nimm die Batterien raus und schau dann mal, ob Du immer noch Werte empfängst.
Oder Dein Nachbar soll die Batterien rausnehmen 8)
und: das stateFormat
T1: temperature T2: temperature2 ist OK
Zitat von: Azze am 03 August 2014, 20:34:24
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0@57600
FD 10
NAME myJeeLink
NR 30
PARTIAL
RAWMSG OK 9 18 1 4 223 64
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1c @17.241 kbps]
myJeeLink_MSGCNT 113408
myJeeLink_TIME 2014-08-03 20:24:38
Matchlist:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^\S+\s+9
5:AliRF ^\S+\s+5
Internals:
DEF 2E
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2014-08-09 19:58:00
MSGCNT 14241
NAME LaCrosse_2E
NR 171
STATE T1: 24.1 T2: temperature2
TYPE LaCrosse
addr 2E
myJeeLink_MSGCNT 14241
myJeeLink_RAWMSG OK 9 46 1 4 217 106
myJeeLink_TIME 2014-08-09 19:58:00
Readings:
2014-08-09 19:58:00 humidity 106
2014-08-09 19:58:00 state T: 24.1 H: 106
2014-08-09 19:58:00 temperature 24.1
Attributes:
IODev myJeeLink
room LaCrosse
stateFormat T1: temperature T2: temperature2
Ja, Temp1 stimmt mit Fhem überein.
Im Display wechselt auch die Temp zwischen Temp1 und Temp2
Bei mir sieht das so aus.
Internals:
CHANGED
DEF 28
IODev LaCrosse
LASTInputDev LaCrosse
LaCrosse_MSGCNT 2099
LaCrosse_RAWMSG OK 9 40 1 4 182 106 oder so --> LaCrosse_RAWMSG OK 9 40 130 4 175 125
LaCrosse_TIME 2014-08-09 20:48:50
LaCrosse_lastRcv 2014-08-09 20:48:50
MSGCNT 2099
NAME TX_25
NR 99
STATE T1: 20.6 T2: 20.2
TYPE LaCrosse
addr 28
battery_new 0
previousH 106
previousH2 125
previousT 20.6
previousT2 20.2
Readings:
2014-08-09 20:48:50 battery ok
2014-08-09 20:48:46 battery2 ok
2014-08-09 20:48:50 state T: 20.6
2014-08-09 20:48:50 temperature 20.6
2014-08-09 20:48:46 temperature2 20.2
Attributes:
IODev LaCrosse
stateFormat T1: temperature T2: temperature2
Vielleicht kann HCS da was rauslesen!
Zitat von: Azze am 09 August 2014, 20:02:03
2014-08-09 19:58:00 humidity 106
2014-08-09 19:58:00 state T: 24.1 H: 106
Das ist seltsam. Laut Quellcode kann man eigentlich kein humidity reading > 99 bekommen.
Welche Version hat denn Deine 36_LaCrosse.pm (also die oberste Zeile) ?
Hallo,
nach dem FHEM-Umzug vom Beagle Bone Black auf Cubietruck habe Ich in FHEM seltsamerweise nur noch Werte von 2 der 6 Sensoren (TX 29DTH-IT).
Laut Screen /dev/ttyUSB0 kommen Datensätze von 6 Sensoren an:
OK 9 0 1 4 227 56
OK 9 7 129 4 244 52
OK 9 20 1 4 231 57
OK 9 2 1 4 242 53
OK 9 10 1 4 236 55
OK 9 55 1 4 255 52
OK 9 20 1 4 230 57
OK 9 0 1 4 227 56
OK 9 7 129 4 245 52
OK 9 20 1 4 230 57
OK 9 2 1 4 242 53
OK 9 10 1 4 236 55
OK 9 55 1 4 255 52
OK 9 0 1 4 227 56
OK 9 7 129 4 245 52
OK 9 20 1 4 231 57
OK 9 2 1 4 242 53
OK 9 7 129 4 244 52
Die Sensoren mit Adressen 00 und 14 arbeiten, die Adressen 1C 80 88 und F4 gehen offenbar verloren.
Steht der erste Zahlenblock nach "OK 9" für Sensoradresse in Dezimaler Form? Dann wären ja 0=00H und 20=14H, aber was ist mit dem Rest passiert?
Es ist meines wissens der neueste Sketch und Module im Einsatz, im Gegensatz zum BBB hat sich wohl nur der Sketch geändert, - Ich wollte alles auf den neusten Stand bringen (alleine schon wegen der Abschaltung der LED).
Jemand eine Idee?
Ich bekomme die EMT7110 nicht eingebunden. Außerdem werden LaCrosse Sensoren nicht mehr per autocreate angelegt:
2014.08.10 15:22:00 3: myJeeLink: Unknown code OK EMT7110 84 67 8 247 2 149 0 125 0 40 1, help me!
2014.08.10 15:22:15 3: myJeeLink: Unknown code OK EMT7110 84 67 8 247 2 144 0 120 0 40 1, help me!
2014.08.10 15:22:30 3: LaCrosse Unknown device 39, please define it
2014.08.10 15:22:33 3: LaCrosse Unknown device 23, please define it
Fhem Version:
# $Id: fhem.pl 6348 2014-08-03 08:22:52Z rudolfkoenig $
# $Id: 36_JeeLink.pm 6085 2014-06-07 21:10:24Z justme1968 $
# $Id: 36_EMT7110.pm 6099 2014-06-10 11:43:09Z hcs-svn $
# $Id: 36_LaCrosse.pm 5046 2014-02-25 16:21:16Z justme1968 $
# $Id: 98_autocreate.pm 5268 2014-03-20 20:46:00Z rudolfkoenig $
LaCrosseITPlusReader 10.1c:
// --- Configuration ---------------------------------------------------------
#define RECEIVER_ENABLED 1 // Set to 0 if you don't want to receive
#define ANALYZE_FRAMES 0 // Set to 1 to display analyzed frame data instead of the normal data
#define RELAY 0 // If 1 all received packets will be retransmitted
#define ENABLE_ACTIVITY_LED 0 // set to 0 if the blue LED bothers
#define USE_OLD_IDS 0 // Set to 1 to use the old ID calcualtion
bool DEBUG = 0; // set to 1 to see debug messages
RFM12::DataRates DATA_RATE = RFM12::DataRate17241; // use one of the possible data rates
uint16_t TOGGLE_DATA_RATE = 30; // 0=no toggle, else interval in seconds
Zitat von: Virgon am 10 August 2014, 15:39:46
nach dem FHEM-Umzug vom Beagle Bone Black auf Cubietruck habe Ich in FHEM seltsamerweise nur noch Werte von 2 der 6 Sensoren (TX 29DTH-IT).
Laut Screen /dev/ttyUSB0 kommen Datensätze von 6 Sensoren an:
Es hat sich (ich glaube ca. Februar) die ID-Berechnug geändert. Wenn Deine Konfiguration noch älter ist, dann ist in Deinen Device-Definitiionen teilweise die Adresse falsch.
Und Du vermutest richtig, der erste Zahlenblock nach "OK 9" für Sensoradresse in Dezimaler Form.
Falls das der Grund ist dann zwei Möglichkeiten:
im sketch: #define USE_OLD_IDS 1 um die IDs wie früher (falsch) zu berechnen
Zu bevorzugen: die IDs ermitteln und in den Device-Devinitionen anpassen
Zitat von: locutus am 10 August 2014, 15:43:34
Ich bekomme die EMT7110 nicht eingebunden. Außerdem werden LaCrosse Sensoren nicht mehr per autocreate angelegt:
2014.08.10 15:22:00 3: myJeeLink: Unknown code OK EMT7110 84 67 8 247 2 149 0 125 0 40 1, help me!
2014.08.10 15:22:15 3: myJeeLink: Unknown code OK EMT7110 84 67 8 247 2 144 0 120 0 40 1, help me!
2014.08.10 15:22:30 3: LaCrosse Unknown device 39, please define it
2014.08.10 15:22:33 3: LaCrosse Unknown device 23, please define it
EMT7110 muss im JeeLink Modul im Clents-Attribut hinzugefügt werden:
Besipiel:
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
LaCrosse Sensoren: ohne ein
set LaCrossePairForSec <sec> [ignore_battery] paaren die sich nicht
36_LaCrosse.pm 3889 2013-09-10
Zitat von: Azze am 10 August 2014, 17:19:48
36_LaCrosse.pm 3889 2013-09-10
Die ist alt. Solltest FHEM mal updaten
Zitat von: HCS am 10 August 2014, 17:01:14
Es hat sich (ich glaube ca. Februar) die ID-Berechnug geändert. Wenn Deine Konfiguration noch älter ist, dann ist in Deinen Device-Definitiionen teilweise die Adresse falsch.
OK, vielen Dank.
Habe nun die Sensoren über die ReplaceBattery-Funktion wieder in Betrieb genommen.
Dabei habe ich mir auch die neuen Adressen notiert(links Sensoranzeige, rechts FHEM-Wert):
EC=>3B 94=>25 A8=>2A 74=>1D und dann sind da noch die 2 Sensoren, bei denen beide Werte gleich sind (00 und 14).
Hmm, also ohne es genauer untersucht zu haben kommt es mir doch sehr seltsam vor. Früher stimmten doch alle Werte überein?
Gruß, Viktor
Zitat von: Virgon am 10 August 2014, 17:33:46
EC=>3B 94=>25 A8=>2A 74=>1D und dann sind da noch die 2 Sensoren, bei denen beide Werte gleich sind (00 und 14).
Ja, das kann schon so sein. Die Berechnung der IDs (die Schieberei der Bits) im ganz ursprünglichen Sketch war falsch (das hätte dazu führen können, dass doppelte IDs berechnet werden) und wurde geändert. Der Fehler und somit die Änderung wirkt aber erst ab einer bestimmten ID (glaube ab 16 dez) aufwärts, darunter macht es keinen Unterschied, und das sind genau Deine 00 und 14.
Zitat von: HCS am 10 August 2014, 17:11:33
EMT7110 muss im JeeLink Modul im Clents-Attribut hinzugefügt werden:
Besipiel:
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
Danke! Das ist mir bekannt und es funktioniert trotzdem auf beiden Pi's nicht.
Ähnliches wird auch hier berichtet, allerdings zur EC3000:
http://forum.fhem.de/index.php/topic,16108.msg186332.html#msg186332
Zitat von: locutus am 10 August 2014, 18:44:31
Danke! Das ist mir bekannt und es funktioniert trotzdem auf beiden Pi's nicht.
Bei mir sieht das so aus:
1.jpg JeeLink
2.jpg EMT7110
Wenn Du noch keinen EMT7110 definiert hast. musst Du wohl auch die MatchList noch anpassen.
Hast Du mal ein EMT7110 manuell definiert? Wenn nicht leg mal eins an.
Internals:
DEF 2E
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2014-08-10 18:57:48
MSGCNT 29
NAME LaCrosse_2E
NR 171
STATE T1: 23.7 T2: 23.6
TYPE LaCrosse
addr 2E
battery_new 1
myJeeLink_MSGCNT 30
myJeeLink_RAWMSG OK 9 46 130 4 212 125
myJeeLink_TIME 2014-08-10 18:57:48
previousH 106
previousH2 125
previousT 23.7
previousT2 23.6
Readings:
2014-08-10 18:57:44 battery ok
2014-08-10 18:57:48 battery2 ok
2014-08-10 18:53:05 humidity 106
2014-08-10 18:57:44 state T: 23.7
2014-08-10 18:57:44 temperature 23.7
2014-08-10 18:57:48 temperature2 23.6
Attributes:
IODev myJeeLink
room LaCrosse
stateFormat T1: temperature T2: temperature2
nun gehts, vielen dank ;-)
Zitat von: HCS am 10 August 2014, 17:43:11
Die Berechnung der IDs (die Schieberei der Bits) im ganz ursprünglichen Sketch war falsch
Ich habe das alte und das aktuelle Sketch verglichen und eine Weile an einem TX 29DTH-IT die Batterien neu eingelegt und die ID vom Display abgeschrieben.
Ich bin zu der Erkenntnis gelangt, dass die ID tatsächlich aus 8 Bit besteht, von denen die unteren 2 Bit nicht benutzt werden aber Teil der Zahl bleiben.
HHHH LL00 (H=Obere 4 Bits, L=Untere)Dadurch kann die untere Stelle (in Hex) nur den Zustand 0,4,8 oder C annehmen.
Bei der 'alten' Berechnung wurde daraus(korrigiert mich, wenn ich falsch liege)
LLHH HH00 gebaut, - sehr seltsames Format.
Bei der aktuellen Berechnung sieht's dann wohl so aus:
00HH HHLL - schon viel besser, aber die unteren (nicht unwichtigen) 2 Bit fehlen und der Zahlenwert ist gleich 1/4 vom Original.
Ich vermute also(es ist meine erste Berührung mit Arduino-Code), dass man die ID in etwa so umrechnen müsste:
frame->ID |= (bytes[0] & 0xF) << 4;
...
frame->ID |= (bytes[1] & 0xC0) >> 4;
Gruß, Viktor
Da hast Du wohl recht.
Ich hatte den Code (zweistufig, um es fertig zu rechnen oder auch nicht) schon mal drin.
Der kommt auf Deinen Vorschlag raus.
msg->ID = 0;
msg->ID |= (data[0] & 0xF) << 2;
msg->ID |= (data[1] & 0xC0) >> 6;
// This would calculate the ID that is displayed on the sensor (like TX29DTH)
// Not sure, if it is a good idea to use this.
////msg->id <<= 2;
////msg->id &= 0b11111100;
Da bin ich aber erst irgendwann nach der Variante, die aktuell drin ist, drauf gekommen.
Ich habe mich dann nicht getraut, es zu veröffentlichen, weil ich nicht wollte, dass jeder, der nach der ersten Änderung seine Adressen durchgekämpft hat, das nochmal tun muss.
Generell würde es mir aber auch gefallen, wenn die am Sensor angezeigte ID mit FHEM übereinstimmt.
Allerdings ist das nur bei den TX29DTH so.
Meine TX35DTH zeigen beim Booten etwas an, das nach dieser Berechnung nicht mit der Adresse übereinstimmt.
Somit hätte es nur für Sensoren mit Display und da auch nicht für alle was gebracht und ich habe es dann auf sich beruhen lassen, auch in Ermangelung von Antworten, was die Anwender denn gerne hätten.
Die Frage is, ob man da nun etwas ändern sollte.
Ich habe mich auch gefragt, ob es jetzt noch Sinn macht, die Formel zu ändern?
Ich schätze eher nicht.
Ich wollte eigentlich nur wissen, wieso die ID in FHEM nicht mit der im Sensor übereinstimmt und das ist wohl erledigt.
Bei Bedarf lässt sich die ID recht einfach hin und herrechnen und man braucht sie wohl meistens nur einmal (wenn überhaupt).
Gruß, Viktor
Ja, vermutlich besser nicht ändern.
Bei den Sensoren ohne Display hilft es eh nichts.
Eventuell könnte man im LaCrosse modul ein internal machen, das diesen Wert rechnet. Dann könnte man zumindest nach dem pairing schauen, ob es der Sensor ist, den man wollte.
@HCS
Hallo hier gibt es gerade eine IT+ Wetterstation anstatt Preis: 149.99 EUR für 84.99 EUR incl. MwSt zzgl.
Versandkosten (6.99 EUR)
http://www.heavyweather.de/WS-1600-Funk-Wetterstation-IT_c37-83_p820_x2.htm
Ich vermute mal stark, dass man die auch mit dem Jeelink in FHEM integrieren könnte.
Wenn du mir versprichst mich dabei zu unterstützen, würde ich mir die mal bestellen. ;)
Andre / justme war schon vor längerem an dem Regenmesser interessiert.
siehe hier. http://forum.fhem.de/index.php/topic,14786.msg152869.html#msg152869
Hier noch eine interessante Sensor Vergleichsliste.
http://www.techome.de/ratgeber-welcher-techno-line-sensor-passt.html
Gruss Billy
Gruss Billy
Zitat von: Billy am 12 August 2014, 15:38:16
@HCS
Hallo hier gibt es gerade eine IT+ Wetterstation anstatt Preis: 149.99 EUR für 84.99 EUR incl. MwSt zzgl.
Versandkosten (6.99 EUR)
http://www.heavyweather.de/WS-1600-Funk-Wetterstation-IT_c37-83_p820_x2.htm
...
Hallo Billy,
diese WS gibt es auch hier http://www.pollin.de/shop/dt/NDM0OTYxOTk-/Haustechnik/Wetterstationen_Thermometer/Funk_Wetterstation_TFA_VEGA.html für 84,95 Euro + Versand. Der Nachteil bei dieser WS ist, das die Uhrzeit manuell gestellt werden muss, kein DCF-77. Ich hatte mir mal eine bestellt, aber aus diesem Grund wieder zurückgeschickt. Zur WS-1600 gibt es auch schon einige Sketche. ( https://github.com/SevenW/wirelessweather , http://forum.jeelabs.net/node/110.html )
Ich habe mir diese http://www.pollin.de/shop/dt/NzE2OTYxOTk-/Haustechnik/Wetterstationen_Thermometer/Funk_Wetterstation_WS_0101.html zugelegt. Diese kann per USB ausgelesen werden. Ich hatte schon einmal angefangen und versucht die Daten aufzuzeichnen die per Funk kommen. Bin aber nicht weiter, da zu viele andere Sensoren dazwischen funken. Hätte aber Interesse daran diese WS per Funk zu empfangen.
Vielleicht ist das hier eine Alternative (http://www.pollin.de/shop/dt/NTE0OTYxOTk-/Haustechnik/Wetterstationen_Thermometer/Funk_Wetterstation_OREGON_SCIENTIFIC_WMR180_WMR180A.html) für 99,00 Euro hat viele Extras sendet aber glaube ich auf 433MHz, siehe hier (www.elv.de/oregon-scientific-wmr180-profi-funk-wetterstation-mit-usb-hub.html).
Grüsse pejonp
Zitat von: Billy am 12 August 2014, 15:38:16
Ich vermute mal stark, dass man die auch mit dem Jeelink in FHEM integrieren könnte.
Das könnte möglicherweise gehen, da es IT+ ist. Zumindest stehen die Chancen nicht schlecht.
Zitat von: Billy am 12 August 2014, 15:38:16
Wenn du mir versprichst mich dabei zu unterstützen, würde ich mir die mal bestellen. ;)
Ich kann Dir versprechen, Dich zu unterstützen.
Ich kann Dir aber kein Ergebnis vorhersagen oder gar versprechen. Ausgang ungewiss.
Ich hatte schon mal angefangen, so eine Art IT+ Paket spy zu schreiben. Den könnte ich mit wenig Aufwand fertig machen.
Mach Dich aber drauf gefasst, dass das ein mühseliges Geschäft wird.
Meterweise Logs lesen und Muster erkennen, Werte beobachten, ob sie sich mit der Windrichtung verändern und und.
Hallo pejonp
Zitat von: pejonp am 12 August 2014, 18:30:32
Hallo Billy,
Der Nachteil bei dieser WS ist, das die Uhrzeit manuell gestellt werden muss, kein DCF-77. Ich hatte mir mal eine bestellt, aber aus diesem Grund wieder zurückgeschickt. Zur WS-1600 gibt es auch schon einige Sketche. ( https://github.com/SevenW/wirelessweather , http://forum.jeelabs.net/node/110.html )
Grüsse pejonp
Der Nachteil kein DCF-77 spielt m.E. nach Einbindung in FHEM praktisch keine Rolle, da dann sowieso mit der richtigen Zeit in FHEM geloggt würde.
Der Link http://forum.jeelabs.net/node/110.html war mir bekannt, da habe ich selbst mitgearbeitet das Ergebnis war ja auch Basis unserer Sketche. Ergebnisse für LaCrosse Regenmesser und Windmesser gab es jedoch nicht. :-\
Zitat von: pejonp am 12 August 2014, 18:30:32
Ich habe mir diese http://www.pollin.de/shop/dt/NzE2OTYxOTk-/Haustechnik/Wetterstationen_Thermometer/Funk_Wetterstation_WS_0101.html zugelegt. Diese kann per USB ausgelesen werden. Ich hatte schon einmal angefangen und versucht die Daten aufzuzeichnen die per Funk kommen.
Bist du da schon mit dem Jeelink/Jeenode drangegangen? Der Regenmesser ähnelt zumindest stark dem LaCrosse Modell.
Übertragung der Außensensorwerte in 868 MHz-Technik. Vielleicht könntest du das mal probieren.
Zitat von: pejonp am 12 August 2014, 18:30:32
Vielleicht ist das hier eine Alternative (http://www.pollin.de/shop/dt/NTE0OTYxOTk-/Haustechnik/Wetterstationen_Thermometer/Funk_Wetterstation_OREGON_SCIENTIFIC_WMR180_WMR180A.html) für 99,00 Euro hat viele Extras sendet aber glaube ich auf 433MHz, siehe hier (www.elv.de/oregon-scientific-wmr180-profi-funk-wetterstation-mit-usb-hub.html).
Ich selbst habe die WMR 928 Oregon Scientific Wetterstation im Einsatz mit dem RFXcomUSB.
Insofern brauche ich eigentlich keine neue Wetterstation. ;)
Gruß Billy
Zitat von: HCS am 12 August 2014, 19:18:45
Das könnte möglicherweise gehen, da es IT+ ist. Zumindest stehen die Chancen nicht schlecht.
Ich kann Dir versprechen, Dich zu unterstützen.
Danke schon mal für dein Angebot.
Ich werde jedoch mal abwarten was pejonp mit der Funk_Wetterstation_WS_0101 herausbekommt.
Vielleicht klappt es da mit dem Jeelink?
Außerdem bin ich ja eigentlich versorgt. Mit der IT+ WS war eher für den Spieltrieb. ;)
Danke nochmals Billy
Zitat von: Billy am 13 August 2014, 14:34:52
Bist du da schon mit dem Jeelink/Jeenode drangegangen? Der Regenmesser ähnelt zumindest stark dem LaCrosse Modell.
Übertragung der Außensensorwerte in 868 MHz-Technik. Vielleicht könntest du das mal probieren.
Hallo Billy,
ich habe schon mit verschieden Sketchen versucht z.B. WS1600, WH1080 oder WS2000 die Daten zu empfangen und auch mit dem LaCrosse. Leider habe ich noch nicht die Startbitfolge gefunden die die WS-0101 sendet um diese auszuwerten bzw. auch noch keine Beschreibung des Übertragungsprotokoll. Ich habe schon eine Anpassung versucht (siehe Anlage) und auch im Sketch eingebunden
// Try WS0101
else if (WS0101::TryHandleData(receiveBuffer)) {
frameLength = WS0101::FRAME_LENGTH;
}
aber nichts sinnvolles empfangen. Vielleicht hat jemand noch eine andere Idee.
Vielleicht komme ich am WE dazu weiter zu testen, bin zur Zeit noch im Urlaub.
Grüße pejonp
Zitat von: pejonp am 13 August 2014, 23:08:00
Hallo Billy,
ich habe schon mit verschieden Sketchen versucht z.B. WS1600, WH1080 oder WS2000 die Daten zu empfangen
Grüße pejonp
Hier gibts was zur wh1081 --> die scheinen alle optisch gleich zu sein mit deiner oder auch WS-2080
http://www.susa.net/wordpress/2012/08/raspberry-pi-reading-wh1081-weather-sensors-using-an-rfm01-and-rfm12b/
Vielleicht hilft es weiter.
Billy
Kann man den Sketch so einstellen das nur alle 60 Sekunden die empfangenen Daten ausgegeben werden?
Ich versuche grade die Wakelocks zu reduzieren und meine 11 Sensoren erzeugen viele.
das geht zur zeit nicht. der sketch reicht jedes empfangene darum direkt an fhem weiter.
du kannst in fhem für die devices min-event-interval setzen. dann werden keine events generiert.
den sketch umbauen wäre etwas aufwändiger und das sollte jemand machen der auch die sensoren hat.
gruss
andre
Ich habe " event-min-interval *:60 " eingestellt.
Wenn ich die Seite von fhem aktualisiere kommt trotzdem alle ~20Sekunden ein update.
Durch die Wakelocks von meinen La Crosse und EC3k Sensoren verbraucht mein Server rund 6 Watt mehr also ohne.
6W * 24h = 144Wh * 365 Tage = 52560Wh = 52,56KW * 0,29€ = 15,24€/Jahr
Hallo in der Runde,
ich brauch leider nochmal eure Hilfe. Ich habe mir nach Monaten nochmals einen neuen Technoline Sensor gekauft. Den TX35 DTH-IT. Ich bekomme ihn nicht gekoppelt. Autocreat ist aktiv. Jeelink ist def. und hat auch die anderen Senosoren gefunden. Auf dem Jeelink ist diese Firmware: LaCrosseITPlusReader.10.1c. FHEM ist gerade aktuell gedatet...
hast du LaCrossePairForSec gesetzt ?
gruss
andre
Mir geht es ganz genau so. Habe ein TX-35 DTH-IT mehrfach ergebnislos versucht zu koppeln.
Anbei der Screenshot aus meiner Jeelink-Definition (FHEM auf Ubuntu).
Zitat von: justme1968 am 08 September 2014, 14:09:27
hast du LaCrossePairForSec gesetzt ?
gruss
andre
Ja, habe ich mehrfach... Sieht bei mir fast genauso aus wie im Screenshot. Nur bei den Attributen habe ich noch den Raum, die Clients und die Matchlist, da ich auch die EMT7110 eingebunden habe.
dich kenne den sensor nicht. stimmt die freqenzeinstellung auf jeelink seite ?
gruss
andre
Du meist, ob er ein 868er ist?
Hier habe ich mal die Verkaufsdaten:
http://www.conrad.de/ce/de/product/672635/Techno-Line-Ersatz-Zusatzsensor-TX29DTH
Zitatssend für Funk-Wetterstation WS 9040 IT Best.Nr. 672635, Funk-Wetterstation WS 9032 IT Best.Nr. 672633, WS 9624-IT, WS 7018-IT
Breite 39 mm
Spannungsversorgung Sensor Mignon-Batterie (2x), bitte separat bestellen
Sende-Frequenz 868 MHz
Luftfeuchte 1% bis 99% %
Temperatur -39,9°C bis +59,9°C
Auflösung Temperatur-Auflösung: ± 0,1 °C•Luftfeuchtigkeits-Auflösung: ± 1%
Höhe 128 mm
Drandenken TX35 laufen mit 9.579 kbps.
Toggle Modus einstellen.
Billy kannst du das ein bisschen genauer beschreiben?! Vielen Dank schon mal!
Leider nein, Sitze in der Badehose am Bodensee. :'(
Aber suche doch hier mal HCS hat dazu was geschrieben.
initCommands Attribut auf "30t v" setzten.
Also so:
set myJeeLink initCommands 30t v
Der TX35 sendet mit 9.579 kbps. Ohne diese Einstellung werden nur die TX29... empfangen.
Danke, aber ich denke das war's nicht oder nicht alles. Hatte schon die SuFu gequält und diesen Hinweis gefunden. Diese Toogle wird ja im Thread erwähnt um von EMT auf Lacrosse umzuschalten.
Interessant: Die 35 geben beim Einlegen der Batterien zwei Werte vor. "P32" und dann einen 2-Code, der sich bei jedem Einlegen der Batterien ändert.
Mal schauen. Habe jetzt nochmal alles gespeichert und neu gestartet... Also das Admin ABC ...
Ich habe selbst zwei TX35DTH und drei TX29DTH. Das funktioniert.
Hatte nicht gemerkt, dass da gleich zwei Anwender geschrieben haben. Zumindes der Screenshot von powdaking sagt klar aus, dass die data rate auf 17k steht, was bedeutet, dass kein TX35 empfangen wird.
Wenn die initCommands korrekt gesetzt sind, sollte das so aussehen:
model [LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds]
Und man sollte beim JeeLik device einen RAWMSG Eintrag bekommen, mit anderen Daten halt.
RAWMSG OK 9 55 1 4 205 74
Wenn das so weit klappt, sollte ein LaCrossPairForSec dann auch devices anlegen.
Ok, das 1. sieht schon mal so aus. Auch dieser Eintrag:
ZitatRAWMSG OK 9 50 1 4 213 65
Aber es wird kein Device angelegt.
was steht im log?
Zitat2014.09.08 20:48:06 5: JLLaCR dispatch OK 9 38 1 4 238 106
2014.09.08 20:48:06 5: JLLaCR dispatch OK 9 50 1 4 212 65
2014.09.08 20:48:08 5: JeeLink/RAW: /OK 9 37 1 4 170
2014.09.08 20:48:08 5: JeeLink/RAW: OK 9 37 1 4 170 /106
2014.09.08 20:48:08 5: JLLaCR dispatch OK 9 37 1 4 170 106
2014.09.08 20:48:08 5: JeeLink/RAW: /OK 9 63
2014.09.08 20:48:08 5: JeeLink/RAW: OK 9 63/ 1 4 204 106
2014.09.08 20:48:08 5: JLLaCR dispatch OK 9 63 1 4 204 106
2014.09.08 20:48:10 5: JeeLink/RAW: /OK 9
2014.09.08 20:48:10 5: JeeLink/RAW: OK 9/ 38 1 4 238 106
2014.09.08 20:48:10 5: JLLaCR dispatch OK 9 38 1 4 238 106
2014.09.08 20:48:14 5: JeeLink/RAW: /OK 9 50
2014.09.08 20:48:14 5: JeeLink/RAW: OK 9 50 /1 4 212 65
2014.09.08 20:48:14 5: JLLaCR dispatch OK 9 50 1 4 212 65
2014.09.08 20:48:17 5: JeeLink/RAW: /OK 9 37 1 4 1
2014.09.08 20:48:17 5: JeeLink/RAW: OK 9 37 1 4 1/70 106
2014.09.08 20:48:17 5: JLLaCR dispatch OK 9 37 1 4 170 106
2014.09.08 20:48:17 5: JeeLink/RAW: /OK 9 6
2014.09.08 20:48:17 5: JeeLink/RAW: OK 9 6/3 1 4 204 106
2014.09.08 20:48:17 5: JLLaCR dispatch OK 9 63 1 4 204 106
2014.09.08 20:48:19 5: JeeLink/RAW: /OK 9
2014.09.08 20:48:19 5: JeeLink/RAW: OK 9/ 38 1 4 238 106
2014.09.08 20:48:19 5: JLLaCR dispatch OK 9 38 1 4 238 106
2014.09.08 20:48:23 5: JeeLink/RAW: /OK
2014.09.08 20:48:23 5: JeeLink/RAW: OK /9 50 1 4 212 65
2014.09.08 20:48:23 5: JLLaCR dispatch OK 9 50 1 4 212 65
2014.09.08 20:48:25 5: JeeLink/RAW: /OK 9
2014.09.08 20:48:25 5: JeeLink/RAW: OK 9 /37 1 4 170 106
2014.09.08 20:48:25 5: JLLaCR dispatch OK 9 37 1 4 170 106
2014.09.08 20:48:26 5: JeeLink/RAW: /OK 9 63
2014.09.08 20:48:26 5: JeeLink/RAW: OK 9 63/ 1 4 204 106
2014.09.08 20:48:26 5: JLLaCR dispatch OK 9 63 1 4 204 106
2014.09.08 20:48:31 5: JeeLink/RAW: /OK EMT7110 84 97
2014.09.08 20:48:31 5: JeeLink/RAW: OK EMT7110 84 97 /8 167 0 6 0 1 52 186 1
2014.09.08 20:48:31 5: JLLaCR dispatch OK EMT7110 84 97 8 167 0 6 0 1 52 186 1
2014.09.08 20:48:31 5: JeeLink/RAW: /OK EMT711
2014.09.08 20:48:31 5: JeeLink/RAW: OK EMT711/0 84 108 8 87 0 85 0 10 59 157 1
2014.09.08 20:48:31 5: JeeLink/RAW: OK EMT7110 84 108 8 87 0 85 0 10 59 157 1
So was.
Auch kein EMT7110 ?
LaCrossPairForSec gesetzt ?
Autocreate aktiv ?
Die EMT's findet er, PairForSec ist gesetzt und Autocreate auch. Aber mein Eindruck ist, dass das nicht so richtig rund läuft...
Ja. Habe gerade zum Testen die Defintion von einem EMT und von einem TX35 weggenommen.
Der EMT wurde angelegt, der TX35 nicht.
Warum geht denn das nicht mehr?
Wird ein Forschungsprojekt.
@justme1968: irgend eine Idee?
Finde es beruhigend. Bin beim Forschen dabei. 8)
Welchen Sketch hattest du auf dem Jeelink? Könnte der aktuelle Sketch das Problem sein?
Zitat// --- Configuration ---------------------------------------------------------
#define RECEIVER_ENABLED 1 // Set to 0 if you don't want to receive
#define ANALYZE_FRAMES 0 // Set to 1 to display analyzed frame data instead of the normal data
#define RELAY 0 // If 1 all received packets will be retransmitted
#define ENABLE_ACTIVITY_LED 1 // set to 0 if the blue LED bothers
#define USE_OLD_IDS 0 // Set to 1 to use the old ID calcualtion
bool DEBUG = 0; // set to 1 to see debug messages
RFM12::DataRates DATA_RATE = RFM12::DataRate17241; // use one of the possible data rates
uint16_t TOGGLE_DATA_RATE = 0; // 0=no toggle, else interval in seconds
Gerade habe ich Schlafmütze es kapiert. :D
Wenn die Batterien schon einige Zeit im Sender sind, muss man beim LaCrossePairForSec die battery ignorieren
set myJeeLink LaCrossePairForSec 120 ignore_battery
Und Deine matchlist passt so nicht. Lösche mal das Attribut.
Hat mir gerade alle TX35 und TX29 plus die EMTs angelegt.
So, neuer Bericht:
Attribut gelöscht
PairForSec eingegeben wie du angegeben hast,
Batterien neu rein
aber leider nix.
Gerade nochmal probiert.
Die Entwicklungumgebung mit update force auf Deinen Stand gebracht.
Alle Definitionen gelöscht.
set myJeeLink LaCrossePairForSec 120 ignore_battery
Und sie wurden alle angelegt.
Der sketch ist nicht das Problem. wir haben die gleiche Version drauf und der JeeLink hat ja Daten an FHEM gesendet.
JeeLink:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 9
LaCrossePair 2
NAME myJeeLink
NR 17
PARTIAL
RAWMSG OK EMT7110 84 81 8 222 0 68 0 1 27 39 1
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds]
myJeeLink_MSGCNT 17
myJeeLink_TIME 2014-09-08 23:03:39
Matchlist:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:RoomNode ^\S+\s+11
4:LaCrosse ^\S+\s+9
5:AliRF ^\S+\s+5
6:EMT7110 ^OK\sEMT7110\s,
Attributes:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
group Hardware
initCommands 30t 0a v
room System
Log:
2014.09.08 22:57:48 2: autocreate: define LaCrosse_02 LaCrosse 02
2014.09.08 22:57:48 3: LaCrosse_02: I/O device is myJeeLink
2014.09.08 22:57:48 2: autocreate: define FileLog_LaCrosse_02 FileLog ./log/LaCrosse_02-%Y.log LaCrosse_02
2014.09.08 22:57:50 3: LaCrosse: Unknown device 26, please define it
2014.09.08 22:57:50 2: autocreate: define LaCrosse_26 LaCrosse 26
2014.09.08 22:57:50 3: LaCrosse_26: I/O device is myJeeLink
2014.09.08 22:57:50 2: autocreate: define FileLog_LaCrosse_26 FileLog ./log/LaCrosse_26-%Y.log LaCrosse_26
2014.09.08 22:57:51 3: LaCrosse: Unknown device 1D, please define it
2014.09.08 22:57:51 2: autocreate: define LaCrosse_1D LaCrosse 1D
2014.09.08 22:57:51 3: LaCrosse_1D: I/O device is myJeeLink
2014.09.08 22:57:51 2: autocreate: define FileLog_LaCrosse_1D FileLog ./log/LaCrosse_1D-%Y.log LaCrosse_1D
2014.09.08 22:58:06 3: Level Unknown device 2, please define it
2014.09.08 22:58:19 3: LaCrosse: Unknown device 29, please define it
2014.09.08 22:58:19 2: autocreate: define LaCrosse_29 LaCrosse 29
2014.09.08 22:58:19 3: LaCrosse_29: I/O device is myJeeLink
2014.09.08 22:58:19 2: autocreate: define FileLog_LaCrosse_29 FileLog ./log/LaCrosse_29-%Y.log LaCrosse_29
2014.09.08 22:58:22 3: LaCrosse: Unknown device 37, please define it
2014.09.08 22:58:22 2: autocreate: define LaCrosse_37 LaCrosse 37
2014.09.08 22:58:22 3: LaCrosse_37: I/O device is myJeeLink
2014.09.08 22:58:22 2: autocreate: define FileLog_LaCrosse_37 FileLog ./log/LaCrosse_37-%Y.log LaCrosse_37
2014.09.08 22:58:24 3: EMT7110 Unknown device 5451, please define it
2014.09.08 22:58:24 2: autocreate: define EMT7110_5451 EMT7110 5451
2014.09.08 22:58:24 3: EMT7110_5451: I/O device is myJeeLink
2014.09.08 22:58:24 2: autocreate: define FileLog_EMT7110_5451 FileLog ./log/EMT7110_5451-%Y.log EMT7110_5451
ich habe gerade keine wirkliche idee.
was passiert wenn du ein reload 36_LaCrosse eingibst ?
gruss
andre
Bei mir hat folgendes geholfen:
attr myJeeLink initCommands 30t
-> Toggle-Modus
Dann PairForSec und die Batterien in die Technoline-Dinger einsetzen (autocreate aktiv!)
Viele Grüße und viel Erfolg
Zitat von: powdaking am 09 September 2014, 13:05:18
attr myJeeLink initCommands 30t
Genau so wäre es auch zu erwarten, dass es geht.
@dieda: lösch mal noch das Clients Attribut weg oder setze es genau so, wie in meinem Beitrag von gestern Abend zu sehen.
Wir sollten versuchen, Stück für Stück die gleiche Konfiguraton herzustellen.
Bin mir nicht mehr sicher - FHEM hattest Du aktuell upgedatet?
Wenn FHEM aktuell ist, dann kannst Du auch mal einen
set myJeeLink flashmachen, um definitiv die selbe Firmware wie ich drauf zu haben. Aber ich glaube nicht, das es ein Sketch-Problem ist.
Habe es mittlerweile mehrfach probiert...
Hier nun meine Rückmeldung auf den Flash-Befehl:
Zitatflashing JeeLink JLLaCR
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
JLLaCR closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (16314 bytes):
Writing | ################################################## | 100% 2.36s
avrdude: 16314 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 16314 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 1.83s
avrdude: verifying ...
avrdude: 16314 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
JLLaCR opened
kannst du mal bitte die MatchList und Clients attribute löschen und nach dem save fhem neu starten.
gruss
andre
Erledigt.
und autocreate geht immer noch nicht?
Wenn ich scharf draufschaue, dann toggelt der Jeelink nicht mehr... Wenn ich das richtig verstehe.
Zitat von: dieda am 09 September 2014, 18:02:00Wenn ich scharf draufschaue, dann toggelt der Jeelink nicht mehr... Wenn ich das richtig verstehe.
Ich denke schon, nur wird es nicht angezeigt. Sonst hättest Du den EMT, der in der RAWMSG steht, nicht empfangen.
Setze initCommands auf:
set myJeeLink initCommands 30t vDas "v" ist entscheidend, dass der Sketch die neuen Einstellung nochmal zurückmeldet und FHEM sie anzeigt.
Zitat von: dieda am 09 September 2014, 17:25:20Hier nun meine Rückmeldung auf den Flash-Befehl:
Das sieht absolut korrekt aus.
Langsam gehen mir die Ideen aus.
Was meldet ein
version LaCrosse
version JeeLinkHast Du ein Testsystem, auf dem Du eine "LaCrosse-only" Installation versuchen kannst?
Eventuell gibt es ja Seiteneffekte mit irgend etwas, was bei Dir läuft.
Erst einmal: Vielen Dank für deinen Einsatz
Bei Version LaCrosse kommt dies raus:
Zitat# $Id: 36_LaCrosse.pm 6513 2014-09-07 10:46:22Z justme1968 $
Bei Version Jeelink:
Zitat# $Id: 36_JeeLink.pm 6512 2014-09-07 10:32:23Z justme1968 $
ZitatHast Du ein Testsystem, auf dem Du eine "LaCrosse-only" Installation versuchen kannst?
Eventuell gibt es ja Seiteneffekte mit irgend etwas, was bei Dir läuft.
Ja, ein Testsystem ist vorhanden, aber nicht aktuell. Muss ich dann aufsetzen...
Bin kurz davor den Sensor zurückzuschicken...
Zitat von: dieda am 09 September 2014, 20:43:33
Erst einmal: Vielen Dank für deinen Einsatz
Kein Thema, auch wenn es gerade nichts nützt
Zitat von: dieda am 09 September 2014, 20:43:33
Bin kurz davor den Sensor zurückzuschicken...
Du hast EMT7110, TX29... und nun den TX35DTH ?
Auf die Idee, dass Dein TX35 gar nicht sendet, bin ich noch gar nicht gekommen
Wenn ich mir Dein Log (hier nochmal angehängt) anschaue, beschleicht mich der Verdacht, dass das so sein könnte.
In dem Zeitblock von 17:11:00 bis 17:11:19 hat der JeeLink mit 9k die EMTs empfangen.
Ein TX35 sendet auch mit 9k alle 4 Sekunden. Der hätte in dem Zeitraum auftauchen müssen.
Schau Dir nochmal etwas mehr Log an, ob irgendwann
zwischen den EMTs ein Sensor vorkommt, der sich mit "OK 9" meldet.
Du kannst auch mit
set myJeeLink initCommands 1r vdie data rate auf 9k festnageln, dann empfängst Du nur EMT und TX35
Falls dann im Log nichts mit "OK 9 ..." auftaucht, würde ich sagen der Sensor tut nicht.
Nachtrag: wenn man initCommands ändert, muss man natürlich auch dafür sorgen, dass der JeeLink neu initialisiert
Die 35er sind ja sogar so freundlich und zeigen mir ihren aktuellen Code (Hexcode) an, wenn man die Batterien neu einlegt. Da konnte ich im Log auch auch nach suchen.... Der umgekehrte Weg über Create hat ja auch nicht funktioniert...
Das was die TX... Sensoren im Display anzeigen stimmt nicht mit der Adresse in FHEM überein.
Was man auch schauen kann: Wenn die Batterie neu eingelegt ist, senden die TX.. einige Stunden ein "new battery" flag mit.
Das erkennt man im Log oder in der RAWMSG daran, dass die Daten mit "OK 9 xx 129" beginnen anstatt mit "OK 9 xx 1".
Wenn der Sensor nicht im Log auftaucht, würde ich zusehens auf defekt tippen.
Ah, danke für den Hinweis, dann geht der jetzt zurück.
Hallo,
ich verwende mehrere TX 29 DTH-IT mit dem Jeelink und es funktioniert auch alles bestens. Allerdings empfange ich auch diverse Sensoren der Nachbarn, die leider öfters mal leere Batterien verwenden ??? Von diesen Sensoren erhalte ich Batteriewarnungen, obwohl ich sie mit "ignore 1" ignoriere. Im event monitor tauchen die Daten dieser Sensoren auch nach wie vor auf. Kann ich das irgendwie abstellen?
Weiter habe ich ab und zu solche Meldungen im log-File:
2014.09.10 14:08:20.488 3: JLLaCR: Unknown code OK 9 136 1 4 202 60, help me!
2014.09.10 14:08:20.538 3: JLLaCR: Unknown code OK 9 212 1 4 213 58, help me!
2014.09.10 14:08:20.587 3: JLLaCR: Unknown code OK 9 128 1 4 191 63, help me!
2014.09.10 14:08:20.638 3: JLLaCR: Unknown code OK 9 8 1 4 154 106, help me!
2014.09.10 14:08:20.885 3: JLLaCR: Unknown code OK 9 8 1 , help me!
2014.09.10 14:08:22.847 3: JLLaCR: Unknown code OK 9 128 1 4 192 63, help me!
Es funktioniert aber alles weiterhin. Woran könnte das liegen?
schöne Grüße
Jo
ich habe eben eine version vom LaCrosse modul eingecheckt bei dem die devices bei denen ignore gesetzt ist auch wirklich ignoriert werden sollten.
die 'Unknown code' meldungen verstehe ich gerade nicht. hast du mehr als einen jeelink?
gruss
andre
Super, das ging ja schnell :D
Danke!
Nein, ich betreibe nur einen JeeLink. Auf 868 MHz hab ich sonst nur noch homematic.
schöne Grüße
Jo
Zitat von: Jojo11 am 10 September 2014, 14:56:45
Weiter habe ich ab und zu solche Meldungen im log-File:
2014.09.10 14:08:20.488 3: JLLaCR: Unknown code OK 9 136 1 4 202 60, help me!
2014.09.10 14:08:20.538 3: JLLaCR: Unknown code OK 9 212 1 4 213 58, help me!
2014.09.10 14:08:20.587 3: JLLaCR: Unknown code OK 9 128 1 4 191 63, help me!
2014.09.10 14:08:20.638 3: JLLaCR: Unknown code OK 9 8 1 4 154 106, help me!
2014.09.10 14:08:20.885 3: JLLaCR: Unknown code OK 9 8 1 , help me!
2014.09.10 14:08:22.847 3: JLLaCR: Unknown code OK 9 128 1 4 192 63, help me!
Welche Version hat denn der Sketch auf dem JeeLink?
Müsste Version 09 sein.
schöne Grüße
Jo
Zitat von: Jojo11 am 11 September 2014, 10:25:25
Müsste Version 09 sein.
OK, ist ja schon etwas alt, die Version. Aber selbst bei der würde es mich wundern, wenn die so einen Unsinn richtung FHEM raus lässt.
Kannst ja mal mit der Aktuellen versuchen.
So, habe jetzt mal die Zeit gefunden, die aktuelle Version zu flashen. Wußte noch gar nicht, dass dies mit FHEM geht.
Werde mal beobachten, ob die Meldungen im log-File noch auftauchen.
schöne Grüße
Jo
Hallo
Gibt es schon Neuigkeiten zur WS 1600 Wetterstation? Ich wäre auch ein Tester ;)
Mein Jeelink mit der Firmware [LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds] zeigt nicht mal ein "unknown code" an.
Interessanterweise gibt es wohl noch jemand der daran arbeitet. Leider ist da nix mehr zu hören.
http://forum.fhem.de/index.php/topic,25866.msg197825.html (http://forum.fhem.de/index.php/topic,25866.msg197825.html)
Viele Grüße
Olaf
Zitat von: okiberlin am 19 September 2014, 20:12:05
Hallo
Gibt es schon Neuigkeiten zur WS 1600 Wetterstation? Ich wäre auch ein Tester ;)
Interessanterweise gibt es wohl noch jemand der daran arbeitet. Leider ist da nix mehr zu hören.
http://forum.fhem.de/index.php/topic,25866.msg197825.html (http://forum.fhem.de/index.php/topic,25866.msg197825.html)
Viele Grüße
Olaf
Schreib doch eine PM an
JorElGruß Billy
Hallo,
ich habe mir ein Jeelink Clone gebastelt mit einem Arduino Nano Clone + RFM12B-868-S (Anleitung (http://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz/)).
Es funktioniert alles, nur stört mich die blaue PWR LED am Nano.
Ich habe den Sketch von der FHEM Sourceforge Seite (http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/). Im Code ist eine Konstante für das ausschalter der blauen LED. Diese habe ich auf 0 gesetzt.
#define ENABLE_ACTIVITY_LED 0 // set to 0 if the blue LED bothers
Leider leuchtet die LED immer noch. Kann es daran liegen das der Nano ein Klone ist?
das kommando oben ist für die activity led.
die power led ist immer verbunden und an. die musst du entfernen oder überkleben wenn es zu hell ist.
gruss
andre
Zitat von: Jojo11 am 13 September 2014, 12:27:23
So, habe jetzt mal die Zeit gefunden, die aktuelle Version zu flashen. Wußte noch gar nicht, dass dies mit FHEM geht.
Werde mal beobachten, ob die Meldungen im log-File noch auftauchen.
schöne Grüße
Jo
Hallo,
auch mit der neusten Version bekomme ich Fehlermeldungen. Heute z.B. diese hier:
2014.09.21 14:09:42.242 3: JLLaCR: Unknown code OK 9 50 1 4 210 63, help me!
Argument "\02" isn't numeric in sprintf at ./FHEM/36_LaCrosse.pm line 173.
Argument "1\0" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 174.
Argument "2\001" isn't numeric in addition (+) at ./FHEM/36_LaCrosse.pm line 177.
2014.09.21 14:09:42.608 3: JLLaCR: Unknown code O, help me!
2014.09.21 14:09:43.939 3: JLLaCR: Unknown code OK 9 5 1 4 210 60, help me!
Woran könnte das sonst noch liegen?
schöne Grüße
Jo
Hallo zusammen,
ich bin ganz neu in FHEM eingestiegen.
Zunächst mal vielen Dank für die tolle Arbeit, die hier gemacht wird.
Ich habe erfolgreich einen JeeLink mit dem LaCrosse Sketch aus dem svn geflasht.
Angeschlossen ist er an einer Synology DS1511+, auf der FHEM läuft.
Anlegen konnte ich den Jeelink auch.
Allerdings werden keinerlei Sensoren erkannt (habe die Anleitung mit PairForSec und ignore battery etc. komplett durchgespielt.).
An einem zweiten Jeelink (der soll demnächst mit PC301 Dosen laufen), den ich am Mac angeschlossen habe, empfange ich aber im Arduino-SerialMonitor Daten diverser Sensoren.
OK 9 63 129 4 223 106
OK 9 63 130 4 201 125
OK 9 40 129 4 215 106
OK 9 63 129 4 222 106
OK 9 40 129 4 215 106
OK 9 40 129 4 215 106
OK 9 63 129 4 222 106
OK 9 40 129 4 215 106
OK 9 63 130 4 201 125
OK 9 40 129 4 215 106
OK 9 63 130 4 201 125
OK 9 40 129 4 215 106
OK 9 63 129 4 222 106
OK 9 40 129 4 215 106
OK 9 40 129 4 215 106
OK 9 63 129 4 222 106
OK 9 40 129 4 214 106
OK 9 63 130 4 201 125
OK 9 63 129 4 222 106
OK 9 40 129 4 214 106
Wie kann ich testen, ob der Jeelink an der Syno überhaupt etwas empfängt?
Danke vorab
Claas
Hallo,
inzwischen läuft der Jeelink an der Synology und FHEM loggt fleissig.
Es lag an nicht geladenen Kernel-Treibern nach einem Neustart der Synology.
Weiss zufällig jemand, was der Eintrag "previousH" ist?
Und da die im Wiki noch in der Liste der unterstützten Sensoren fehlen:
Der Sensor TFA 30.3143.IT läuft einwandfrei und liefert sogar die Temperatur beider Sensoren (der hat einen zusätzlichen Kabelsensor, den man nach draussen hängen kann, während der "Hauptsensor" z.B. im Überwinterungszelt bleibt.)
Auch der Conrad TX29IT funktioniert.
Gruss
Claas
Zitat von: claas am 30 September 2014, 15:48:38
Und da die im Wiki noch in der Liste der unterstützten Sensoren fehlen:
Der Sensor TFA 30.3143.IT läuft einwandfrei und liefert sogar die Temperatur beider Sensoren (der hat einen zusätzlichen Kabelsensor, den man nach draussen hängen kann, während der "Hauptsensor" z.B. im Überwinterungszelt bleibt.)
Einstellen ins WIKI kein Problem wenn du noch mitteilst mit welcher Datenrate der TFA 30.3143.IT läuft?
9.579 kbps oder 17.241 kbps
Gruß Billy
Hallo Billy,
gerne, wo sehe ich das? Sorry, bin echt blutiger Anfänger.
Gruss
Claas
Hallo,
ich habe noch eine Frage.
Es werden eindeutig Daten ausgelesen aber nicht ins Log geschrieben.
Daher werden auch keine Plots aktualisiert (denke ich).
Im FHEM log sehe ich diese Meldungen
2014.09.30 16:05:29 1: No Logdevice FileLog_LaCrosse_17
2014.09.30 16:05:29 1: No Logdevice FileLog_LaCrosse_11
Hat das damit zu tun?
Danke
Claas
Zitat von: claas am 30 September 2014, 16:59:57
Hallo Billy,
gerne, wo sehe ich das? Sorry, bin echt blutiger Anfänger.
Gruss
Claas
Was steht denn beim JeeLink device bei Model?
[LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds]
Zitat von: claas am 01 Oktober 2014, 08:04:39
[LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds]
Dann kannst Du es da dran nicht erkennen.
Einzige Möglichlichkeit: die data rate auf 9.579 kbps oder 17.241 kbps festsetzen und schauen, ob der Sensor empfangen wird.
Hab's im Log gefunden.
JeeLink/RAW: [LaCrosseITPlusReader.1/0.1c @17.241 kbps]
Zitat von: claas am 30 September 2014, 15:48:38
Und da die im Wiki noch in der Liste der unterstützten Sensoren fehlen:
Der Sensor TFA 30.3143.IT läuft einwandfrei und liefert sogar die Temperatur beider Sensoren (der hat einen zusätzlichen Kabelsensor, den man nach draussen hängen kann, während der "Hauptsensor" z.B. im Überwinterungszelt bleibt.)
Auch der Conrad TX29IT funktioniert.
Gruss
Claas
WIKI um
TFA 30.3143.IT und
TX29-IT ergänzt
Billy
Zitat von: claas am 30 September 2014, 18:52:08
Es werden eindeutig Daten ausgelesen aber nicht ins Log geschrieben.
Daher werden auch keine Plots aktualisiert (denke ich).
Im FHEM log sehe ich diese Meldungen
2014.09.30 16:05:29 1: No Logdevice FileLog_LaCrosse_17
2014.09.30 16:05:29 1: No Logdevice FileLog_LaCrosse_11
Darauf kann ich mir glaub ich selbst antworten.
Wenn man nach dem Umbenennen eines Device auf "Save config" klickt, wird auch wieder geloggt.
Zitat von: claas am 01 Oktober 2014, 08:23:48
Hab's im Log gefunden.
JeeLink/RAW: [LaCrosseITPlusReader.1/0.1c @17.241 kbps]
In dieser Stelle klinke ich mich auch mal ein. Ein paar Posts vorher hatte ich ja mein Problem geschildert: http://forum.fhem.de/index.php/topic,14786.msg198316.html#msg198316
Haben nen neuen und nu geht der auch nicht, aber dieser Hinweis:
2014.09.30 22:27:23 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds]
Available commands:
<n>a - activity LED (0=off, 1=on)
<n>d - DEBUG mode (0=suppress TX and bad packets)
<n>r - data rate (0=17.241
2014.09.30 22:27:23 5: JeeLink/RAW: <n>r - data rate (0=17.241/ kbps, 1=9.579 kbps)
<n>t - toggle data rate intervall (0=no toggle, >0=seconds)
<n>v - version and configuration report
<n>x - used for tests
<t10>,<t1>,<t0>,<hum>c - set temperatu
2014.09.30 22:27:24 5: JeeLink/RAW: <t10>,<t1>,<t0>,<hum>c - set temperatu/re and humidity for transmit
<id>,<int>,<nbt>,<dr>i - set the parameters for the transmit loop
b1,b2,b3,b4s - send the passed bytes plus the calculated CRCZitat2014.09.30 22:27:23 5: JeeLink/RAW: <n>r - data rate (0=17.241/ kbps, 1=9.579 kbps)
lässt mich doch sehr vermuten, dass es am Toggeln liegt.
Dann schalte das togglen doch mal ab.
Das müsste man ihm doch über das Webinterface mit "set myJeeLink raw" und dann t0 mitteilen können (wie schonmal gesagt, ich fange mit Jeelink & FHEM gerade erst an)?
Gruss
Claas
Hallo zusammen,
ich habe gerade begonnen, mich mit einem JeeLink v3 auseinander zu setzen. Mittlerweile läuft er auch und empfängt einen TFA 30.3144.IT von Dorstmann. Das klappt auch ganz gut. Die Reichweite ist deutlich besser als mit einem HMS 100 T über den CUL.
Gibt es für den Jeelink eigentlich eine Beschreibung der Funktionen und der möglichen Befehle ähnlich der culfw referenz oder der Beschreibung des CUL aus dem Wiki?
Viele Grüße und schönes Wochenende
Harald
eine allgemeine übersicht die über den wiki artikel (http://www.fhemwiki.de/wiki/JeeLink (http://www.fhemwiki.de/wiki/JeeLink)) und die artikel zum jeweiligen sketch eingehen gibt es zur zeit nicht.
die möglichen befehle/funktionen sind auch je nach sketch ziemlich unterschiedlich.
gruss
andre
Hallo zusammen,
ich erhalte immer nach einem Neustart von RasPi und FHEM im Log die Meldung "JeeLink1: Unknown code , help me!" (ohne verbose 5). Hier der Logauszug mit verbose 5:2014.10.13 13:52:01 0: Server shutdown
2014.10.13 13:52:22 1: Perl version: 5.014002
2014.10.13 13:52:22 1: OS version: linux
2014.10.13 13:52:22 1: Loading Unix modules
2014.10.13 13:52:22 1: Including fhem.cfg
2014.10.13 13:52:22 3: telnetPort: port 7072 opened
2014.10.13 13:52:24 3: WEB: port 8083 opened
2014.10.13 13:52:24 3: WEBphone: port 8084 opened
2014.10.13 13:52:24 3: WEBtablet: port 8085 opened
2014.10.13 13:52:25 3: Opening CUL_0 device /dev/ttyACM0
2014.10.13 13:52:25 3: Setting CUL_0 baudrate to 38400
2014.10.13 13:52:25 3: CUL_0 device opened
2014.10.13 13:52:25 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2014.10.13 13:52:26 3: Opening JeeLink1 device /dev/ttyUSB0
2014.10.13 13:52:26 3: Setting JeeLink1 baudrate to 57600
2014.10.13 13:52:26 3: JeeLink1 device opened
2014.10.13 13:52:54 3: TFA: I/O device is JeeLink1
2014.10.13 13:52:58 1: Including ./log/fhem.save
2014.10.13 13:52:59 0: Server started with 106 defined entities (version $Id: fhem.pl 6672 2014-10-04 14:32:17Z rudolfkoenig $, os linux, user fhem, pid 2103)
2014.10.13 13:53:02 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
2014.10.13 13:53:04 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1c @17.241 kbps]
OK 9 20 1 4 183 69
2014.10.13 13:53:04 5: JeeLink1 dispatch
2014.10.13 13:53:05 3: JeeLink1: Unknown code , help me!
2014.10.13 13:53:05 5: SW: 0a
2014.10.13 13:53:05 5: SW: v
2014.10.13 13:53:05 5: JeeLink1 dispatch OK 9 20 1 4 183 69
2014.10.13 13:53:05 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1c @17.241 kbps]
Ich habe keine Änderungen an FHEM vorgenommen, lediglich den Raspi neu gestartet.
Hat jemand eine Idee, wo die Ursache liegen kann, bzw. wie ich das herausbekommen kann?
Über brauchbare Tipps würde ich mich freuen. Viele Grüße
Harald
PS: Hab's gerade nochmal getestet: Beim Neustart des RasPi erscheint diese Meldung, jedoch nicht beim Neustart von FHEM alleine.2014.10.13 13:56:09 0: Server shutdown
2014.10.13 13:56:13 1: Perl version: 5.014002
2014.10.13 13:56:13 1: OS version: linux
2014.10.13 13:56:13 1: Loading Unix modules
2014.10.13 13:56:14 1: Including fhem.cfg
2014.10.13 13:56:14 3: telnetPort: port 7072 opened
2014.10.13 13:56:15 3: WEB: port 8083 opened
2014.10.13 13:56:15 3: WEBphone: port 8084 opened
2014.10.13 13:56:15 3: WEBtablet: port 8085 opened
2014.10.13 13:56:15 3: Opening CUL_0 device /dev/ttyACM0
2014.10.13 13:56:15 3: Setting CUL_0 baudrate to 38400
2014.10.13 13:56:15 3: CUL_0 device opened
2014.10.13 13:56:15 3: CUL_0: Possible commands: BbCFiAZEGMKUYRTVWXefmltux
2014.10.13 13:56:16 3: Opening JeeLink1 device /dev/ttyUSB0
2014.10.13 13:56:16 3: Setting JeeLink1 baudrate to 57600
2014.10.13 13:56:16 3: JeeLink1 device opened
2014.10.13 13:56:17 3: TFA: I/O device is JeeLink1
2014.10.13 13:56:21 1: Including ./log/fhem.save
2014.10.13 13:56:22 0: Server started with 106 defined entities (version $Id: fhem.pl 6672 2014-10-04 14:32:17Z rudolfkoenig $, os linux, user fhem, pid 2398)
2014.10.13 13:56:25 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1c @17.241 kbps]
OK 9 20 1 4 183 69
2014.10.13 13:56:25 5: SW: 0a
2014.10.13 13:56:25 5: SW: v
2014.10.13 13:56:25 5: JeeLink1 dispatch OK 9 20 1 4 183 69
2014.10.13 13:56:26 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1c @17.241 kbps]
Hallo zusammen,
ich habe in der FHEM-Befehlszeile "set JeeLink1 initCommands v" in der Hoffnung eingegeben, dass ich dann die aktuellen Einstellungen des JeeLink angezeigt bekomme. Leider erscheint aber "Unknown argument initCommands, choose one of beep raw led:on,off led-on-for-timer reset LaCrossePairForSec setReceiverMode:LaCrosse,HX2272,FS20 flash ".
Da habe ich bestimmt etwas falsch gemacht oder verstanden :( Kann mir jemand sagen, wie ich die derzeitigen Parameter des JeeLinks ermitteln kann?
Vielen Dank im Voraus und viele Grüße
Harald
initCommands ist ein attribut das mit attr gesetzt wird und bei jedem initialisieren verwendet wird.
du du möchtest einset JeeLink1 raw vdas hilft aber nur wenn du verbose auf 4 oder 5 setzt und danach ins log schaust weil diese start/status zeilen normalerweise rausgefiltert werden.
gruss
andre
Vielen Dank für die Aufklärung. Dann habe ich das wohl hier in den Beiträgen falsch verstanden. Werde das nachher mal ausprobieren. Jetzt gibt es erstmal was zwischen die Zähne 8)
Viele Grüße
Harald
So, besten Dank, das habe ich verstanden und es hat geklappt.
Gibt es auch einen Befehl, der ähnlich des CUL-Befehls "ccconf" Frequenz, Bandbreite usw. usw. ausgibt?
Viele Grüße
Harald
das hängt jeweils von dem sketch ab der auf dem jählink drauf ist. die verhalten sich alle etwas anders.
gruss
andre
Entschuldige bitte, dass ich noch nicht explizid erwähnt habe, dass ich diesen sketch "LaCrosseITPlusReader.10.1c @17.241 kbps" installiert habe.
Gibt es da so etwas?
Harald
Hallo zusammen
Verzweifelt versuche ich seit längerer Zeit meine Temperatursensoren (TX290DTH-IT) anzulegen, ohne Erfolg.
In den beiliegenden Fotos sieht Ihr die Details.
Mein 2. Jeelink mit den PCA 301 läuft ohne Probleme.
Meine Installation läuft unter Windows.
Ich bin totaler Anfänger und wäre froh um Hilfe und ev. einer Kopie einer funktionierenden fhem.cfg, damit ich schauen kann, ob ich hier Fehler gemacht habe.
Vielen Dank
Chres
Hallo,
ich benutze mit einem Jeelink Clone mehrere TX29DTH-IT und TX35DTH-IT Sensoren. Der Empfang der TX29DTH-IT klappt. Der Jeelink steht auf AutoToggle.
[LaCrosseITPlusReader.10.1c @AutoToggle 30 Seconds]
# $Id: 36_JeeLink.pm 6734 2014-10-10 05:56:46Z justme1968 $
# $Id: 36_LaCrosse.pm 6529 2014-09-10 14:13:37Z justme1968 $
Die TX35DTH-IT werden nicht / fast nicht erkannt. Gestern hat es ein Sensor in das fhem.log gschafft
Im Serial Monitor sieht man im
Debug Pakete mit CRC Fehler
Start receiver
Stop receiver
End receiving, HEX raw data: 9E ED 37 A7 76
## CRC FAIL ##
Start receiver
Stop receiver
End receiving, HEX raw data: D4 5A FF A0 EE
## CRC FAIL ##
Ein Orginal Jeelink (zum Test gleicher Standort) empfängt im AutoToggle alle Sensoren.
Gibt es eine Möglichkeit durch Anpassungen im Sketch den Jeelink zu überreden alle Sensoren zu empfangen.
Vielen Dank und Grüße aus dem Norden
Moin Moin,
Ich versuche schon den ganzen Tag einen TX29DTH-IT über nen JeeLink in FHEM einzubinden. und es will mir nicht gelingen.
Im Serial Monitor laufen die Werte sauber rein. Bei FHEM laufen die Werte auch rein nur FHEM erzeugt nichts nur Fehlermeldungen.
Hier mal meine fhem.cfg
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
\
Restart fhem for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global userattr devStateIcon devStateStyle icon sortby webCmd
attr global verbose 5
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
define WEBphone FHEMWEB 8084 global
attr WEBphone stylesheetPrefix smallscreen
define WEBtablet FHEMWEB 8085 global
attr WEBtablet stylesheetPrefix touchpad
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define autocreate autocreate
attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
########################
define JeeLink JeeLink /dev/ttyUSB0@57600
Und hier die Log von FHEM
2014.10.18 17:26:41 1: Including fhem.cfg
2014.10.18 17:26:41 5: Cmd: >attr global autoload_undefined_devices 1<
2014.10.18 17:26:41 5: Cmd: >attr global logfile ./log/fhem-%Y-%m.log<
2014.10.18 17:26:41 5: Cmd: >attr global modpath .<
2014.10.18 17:26:41 5: Loading ./FHEM/99_SUNRISE_EL.pm
2014.10.18 17:26:42 5: Loading ./FHEM/99_Utils.pm
2014.10.18 17:26:42 5: Cmd: >attr global motd SecurityCheck:\
\
WEB,WEBphone,WEBtablet has no basicAuth attribute.\
telnetPort has no password/globalpassword attribute.\
\
Restart fhem for a new check if the problem is fixed,\
or set the global attribute motd to none to supress this message.\
<
2014.10.18 17:26:42 5: Cmd: >attr global statefile ./log/fhem.save<
2014.10.18 17:26:42 5: Cmd: >attr global updateInBackground 1<
2014.10.18 17:26:42 5: Cmd: >attr global userattr devStateIcon devStateStyle icon sortby webCmd<
2014.10.18 17:26:42 5: Cmd: >attr global verbose 5<
2014.10.18 17:26:42 5: Cmd: >define telnetPort telnet 7072 global<
2014.10.18 17:26:42 5: Loading ./FHEM/98_telnet.pm
2014.10.18 17:26:42 3: telnetPort: port 7072 opened
2014.10.18 17:26:42 5: Cmd: >define WEB FHEMWEB 8083 global<
2014.10.18 17:26:42 5: Loading ./FHEM/01_FHEMWEB.pm
2014.10.18 17:26:43 3: WEB: port 8083 opened
2014.10.18 17:26:43 5: Cmd: >define WEBphone FHEMWEB 8084 global<
2014.10.18 17:26:43 3: WEBphone: port 8084 opened
2014.10.18 17:26:43 5: Cmd: >attr WEBphone stylesheetPrefix smallscreen<
2014.10.18 17:26:43 5: Cmd: >define WEBtablet FHEMWEB 8085 global<
2014.10.18 17:26:43 3: WEBtablet: port 8085 opened
2014.10.18 17:26:43 5: Cmd: >attr WEBtablet stylesheetPrefix touchpad<
2014.10.18 17:26:43 5: Cmd: >define Logfile FileLog ./log/fhem-%Y-%m.log fakelog<
2014.10.18 17:26:43 5: Loading ./FHEM/92_FileLog.pm
2014.10.18 17:26:43 5: Cmd: >define autocreate autocreate<
2014.10.18 17:26:43 5: Loading ./FHEM/98_autocreate.pm
2014.10.18 17:26:43 5: Cmd: >attr autocreate filelog ./log/%NAME-%Y.log<
2014.10.18 17:26:43 5: Cmd: >define eventTypes eventTypes ./log/eventTypes.txt<
2014.10.18 17:26:43 5: Loading ./FHEM/91_eventTypes.pm
2014.10.18 17:26:43 5: Cmd: >define initialUsbCheck notify global:INITIALIZED usb create<
2014.10.18 17:26:43 5: Loading ./FHEM/91_notify.pm
2014.10.18 17:26:43 5: Cmd: >define JeeLink JeeLink /dev/ttyUSB0@57600<
2014.10.18 17:26:43 5: Loading ./FHEM/36_JeeLink.pm
2014.10.18 17:26:43 3: Opening JeeLink device /dev/ttyUSB0
2014.10.18 17:26:43 3: Setting JeeLink baudrate to 57600
2014.10.18 17:26:43 3: JeeLink device opened
2014.10.18 17:26:43 5: SW: 1a
2014.10.18 17:26:43 5: SW: 1q
2014.10.18 17:26:43 5: SW: 0x
2014.10.18 17:26:43 5: SW: 0a
2014.10.18 17:26:44 5: SW: l
2014.10.18 17:26:44 1: Including ./log/fhem.save
2014.10.18 17:26:44 5: Cmd: >setstate Logfile active<
2014.10.18 17:26:44 5: Cmd: >setstate autocreate active<
2014.10.18 17:26:44 5: Cmd: >setstate eventTypes active<
2014.10.18 17:26:44 5: Cmd: >setstate global <no definition><
2014.10.18 17:26:44 5: Cmd: >setstate initialUsbCheck active<
2014.10.18 17:26:44 5: Interface "interface": readings "", getters "", setters ""
2014.10.18 17:26:44 5: Interface "switch": readings "onoff", getters "onoff", setters ""
2014.10.18 17:26:44 5: Interface "switch_active": readings "onoff", getters "onoff", setters ""
2014.10.18 17:26:44 5: Interface "switch_passive": readings "onoff", getters "onoff", setters "on:off"
2014.10.18 17:26:44 5: Interface "dimmer": readings "onoff:level", getters "onoff:level", setters "on:off:dimto:dimup:dimdown"
2014.10.18 17:26:44 5: Interface "temperature": readings "temperature", getters "temperature", setters ""
2014.10.18 17:26:44 5: Interface "humidity": readings "humidity", getters "humidity", setters ""
2014.10.18 17:26:44 5: Interface "wind": readings "wind", getters "wind", setters ""
2014.10.18 17:26:44 5: Interface "power": readings "power:maxPower:energy", getters "power:maxPower:energy", setters ""
2014.10.18 17:26:44 5: Triggering global (1 changes)
2014.10.18 17:26:44 5: Notify loop for global INITIALIZED
2014.10.18 17:26:44 4: eventTypes: Global global INITIALIZED -> INITIALIZED
2014.10.18 17:26:44 5: Triggering initialUsbCheck
2014.10.18 17:26:44 5: Cmd: >usb create<
2014.10.18 17:26:44 1: usb create starting
2014.10.18 17:26:45 4: ### ttyAMA0: checking if it is a CUL
2014.10.18 17:26:45 3: Opening CUL device /dev/ttyAMA0
2014.10.18 17:26:45 3: Setting CUL baudrate to 38400
2014.10.18 17:26:45 3: CUL device opened
2014.10.18 17:26:45 5: SW:
2014.10.18 17:26:45 5: SW: V
2014.10.18 17:26:45 4: got wrong answer for a CUL
2014.10.18 17:26:45 4: ### ttyAMA0: checking if it is a TCM310
2014.10.18 17:26:45 3: Opening TCM310 device /dev/ttyAMA0
2014.10.18 17:26:45 3: Setting TCM310 baudrate to 57600
2014.10.18 17:26:46 3: TCM310 device opened
2014.10.18 17:26:46 5: SW: Up8
2014.10.18 17:26:46 4: got wrong answer for a TCM310
2014.10.18 17:26:46 4: ### ttyUSB0: checking if it is a TCM310
2014.10.18 17:26:46 4: already used by the JeeLink fhem device
2014.10.18 17:26:46 1: usb create end
2014.10.18 17:26:46 2: SecurityCheck: WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2014.10.18 17:26:46 0: Server started with 10 defined entities (version $Id: fhem.pl 3872 2013-09-07 11:58:33Z rudolfkoenig $, os linux, user pi, pid 2141)
2014.10.18 17:26:46 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1c @17.241 kbps]
2014.10.18 17:26:46 4: Connection accepted from FHEMWEB:10.70.90.111:55795
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55795 GET /fhem?
2014.10.18 17:26:47 4: /fhem? / RL:952 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2014.10.18 17:26:47 4: Connection accepted from FHEMWEB:10.70.90.111:55796
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55796 GET /fhem/FileLog_logWrapper?room=all&XHR=1&inform=1×tamp=1413646007198
2014.10.18 17:26:47 4: Connection closed for FHEMWEB:10.70.90.111:55796
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55795 GET /fhem/pgm2/style.css
2014.10.18 17:26:47 4: Connection accepted from FHEMWEB:10.70.90.111:55799
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55795 GET /fhem/pgm2/fhemweb_svg.js
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/pgm2/svg.js
2014.10.18 17:26:47 4: Connection accepted from FHEMWEB:10.70.90.111:55800
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/pgm2/fhemweb_time.js
2014.10.18 17:26:47 4: Connection accepted from FHEMWEB:10.70.90.111:55801
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55795 GET /fhem/pgm2/fhemweb_textField.js
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55800 GET /fhem/pgm2/fhemweb.js
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/images/default/icoEverything.png
2014.10.18 17:26:47 4: Connection accepted from FHEMWEB:10.70.90.111:55802
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55801 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/pgm2/fhemweb_noArg.js
2014.10.18 17:26:47 4: Connection accepted from FHEMWEB:10.70.90.111:55803
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55803 GET /fhem/pgm2/fhemweb_slider.js
2014.10.18 17:26:47 4: HTTP FHEMWEB:10.70.90.111:55803 GET /fhem?room=all&XHR=1&inform=1×tamp=1413646008763
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2014-10.log
2014.10.18 17:26:49 4: Connection closed for FHEMWEB:10.70.90.111:55803
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/pgm2/style.css
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55801 GET /fhem/pgm2/svg.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/pgm2/fhemweb.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/pgm2/fhemweb_svg.js
2014.10.18 17:26:49 4: Connection accepted from FHEMWEB:10.70.90.111:55805
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55801 GET /fhem/pgm2/fhemweb_textField.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55795 GET /fhem/pgm2/fhemweb_noArg.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55800 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/pgm2/fhemweb_time.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/images/default/icoEverything.png
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55805 GET /fhem/pgm2/fhemweb_slider.js
2014.10.18 17:26:49 4: HTTP FHEMWEB:10.70.90.111:55805 GET /fhem/FileLog_logWrapper?room=all&XHR=1&inform=1×tamp=1413646010443
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2014-10.log
2014.10.18 17:27:43 4: Connection closed for FHEMWEB:10.70.90.111:55805
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/pgm2/svg.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/pgm2/style.css
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55800 GET /fhem/pgm2/fhemweb.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/pgm2/fhemweb_svg.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55802 GET /fhem/pgm2/fhemweb_textField.js
2014.10.18 17:27:43 4: Connection accepted from FHEMWEB:10.70.90.111:55870
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55801 GET /fhem/pgm2/fhemweb_noArg.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55795 GET /fhem/pgm2/fhemweb_colorpicker.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55800 GET /fhem/pgm2/fhemweb_time.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55799 GET /fhem/images/default/icoEverything.png
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55870 GET /fhem/pgm2/fhemweb_slider.js
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55870 GET /fhem/images/default/fhemicon.png
2014.10.18 17:27:43 4: HTTP FHEMWEB:10.70.90.111:55870 GET /fhem/icons/favicon
2014.10.18 17:27:44 4: HTTP FHEMWEB:10.70.90.111:55870 GET /fhem/FileLog_logWrapper?room=all&XHR=1&inform=1×tamp=1413646064975
2014.10.18 17:27:45 5: JeeLink/RAW: /OK 9 2
2014.10.18 17:27:45 5: JeeLink/RAW: OK 9 2/8 129 4 205 59
2014.10.18 17:27:45 5: JeeLink dispatch OK 9 28 129 4 205 59
2014.10.18 17:27:45 0: ERROR: Cannot autoload LaCrosse
2014.10.18 17:27:45 5: Triggering JeeLink (1 changes)
2014.10.18 17:27:45 5: Notify loop for JeeLink UNKNOWNCODE OK 9 28 129 4 205 59
2014.10.18 17:27:45 4: eventTypes: JeeLink JeeLink UNKNOWNCODE OK 9 28 129 4 205 59 -> UNKNOWNCODE OK .* .* .* .* .* .*
2014.10.18 17:27:45 3: JeeLink: Unknown code OK 9 28 129 4 205 59, help me!
2014.10.18 17:27:49 5: JeeLink/RAW: /OK 9 2
2014.10.18 17:27:49 5: JeeLink/RAW: OK 9 2/8 129 4 205 59
2014.10.18 17:27:49 5: JeeLink dispatch OK 9 28 129 4 205 59
2014.10.18 17:27:49 0: ERROR: Cannot autoload LaCrosse
2014.10.18 17:27:49 5: Triggering JeeLink (1 changes)
2014.10.18 17:27:49 5: Notify loop for JeeLink UNKNOWNCODE OK 9 28 129 4 205 59
2014.10.18 17:27:49 4: eventTypes: JeeLink JeeLink UNKNOWNCODE OK 9 28 129 4 205 59 -> UNKNOWNCODE OK .* .* .* .* .* .*
2014.10.18 17:27:49 3: JeeLink: Unknown code OK 9 28 129 4 205 59, help me!
2014.10.18 17:27:53 5: JeeLink/RAW: /OK 9
2014.10.18 17:27:53 5: JeeLink/RAW: OK 9/ 28 129 4 205 59
2014.10.18 17:27:53 5: JeeLink dispatch OK 9 28 129 4 205 59
2014.10.18 17:27:53 0: ERROR: Cannot autoload LaCrosse
2014.10.18 17:27:53 5: Triggering JeeLink (1 changes)
2014.10.18 17:27:53 5: Notify loop for JeeLink UNKNOWNCODE OK 9 28 129 4 205 59
2014.10.18 17:27:53 4: eventTypes: JeeLink JeeLink UNKNOWNCODE OK 9 28 129 4 205 59 -> UNKNOWNCODE OK .* .* .* .* .* .*
2014.10.18 17:27:53 3: JeeLink: Unknown code OK 9 28 129 4 205 59, help me!
Ich hoffe es kann mir jemand helfen.
Danke schon mal.
Zitat von: Kruech am 18 Oktober 2014, 18:01:09
Moin Moin,
Ich versuche schon den ganzen Tag einen TX29DTH-IT über nen JeeLink in FHEM einzubinden. und es will mir nicht gelingen.
Im Serial Monitor laufen die Werte sauber rein. Bei FHEM laufen die Werte auch rein nur FHEM erzeugt nichts nur Fehlermeldungen.
Suche nach Cannot autoload LaCrosse spuckt bei mir diesen Link aus.!
http://forum.fhem.de/index.php/topic,14786.msg133739/topicseen.html#msg133739
Danach steht einiges. Vielleicht hilfts.
Gruß Billy
Zitat von: Chres am 18 Oktober 2014, 10:13:01
Hallo zusammen
Verzweifelt versuche ich seit längerer Zeit meine Temperatursensoren (TX290DTH-IT) anzulegen, ohne Erfolg.
In den beiliegenden Fotos sieht Ihr die Details.
Mein 2. Jeelink mit den PCA 301 läuft ohne Probleme.
Meine Installation läuft unter Windows.
Ich bin totaler Anfänger und wäre froh um Hilfe und ev. einer Kopie einer funktionierenden fhem.cfg, damit ich schauen kann, ob ich hier Fehler gemacht habe.
Vielen Dank
Chres
Siehe hier und fortfolgend.
http://forum.fhem.de/index.php/topic,14786.810.html
hast du LaCrossePairForSec gesetzt ?
evtl. auch Batterien in die TX290DTH-IT neu einlegen. (Initialisierung)
Gruß Billy
Zitat von: azlanw am 18 Oktober 2014, 13:07:34
ich benutze mit einem Jeelink Clone mehrere TX29DTH-IT und TX35DTH-IT Sensoren. Der Empfang der TX29DTH-IT klappt. Der Jeelink steht auf AutoToggle.
...
Ein Orginal Jeelink (zum Test gleicher Standort) empfängt im AutoToggle alle Sensoren.
Gibt es eine Möglichkeit durch Anpassungen im Sketch den Jeelink zu überreden alle Sensoren zu empfangen.
Nein. Da wüsste ich nichts, was hilft. Das ist eher ein HF-Problem auf der RFM12 Seite.
Hallo HCS,
ich habe Deine Antwort schon befürchtet. Versuche ich halt den Stick mit dem PCA301 Sketch zu verwenden.
Gruß azlan
Was für ein clone ist das denn?
Hallo HCS,
USB Typ A Stecker
FT232R USB UART IC
ATMEGA328P Mikrocontroller
RFM12B 868 MHz Funkmodul
M25P16 Serial Flash Embedded Memory
TX- und RX-LED
Arduino UNO Bootloader
aus dem Forum
Gruß
azlanw meint den hier: http://forum.fhem.de/index.php/topic,21995.0.html
Hat schon mal jemand mit dem SDR die Funksignale von den TX29DTH-IT und TX35DTH-IT Sensoren analysiert? Funken die beiden Sensortypen tatsächlich auf der gleichen Frequenz?
Beim PCA301 Sketch ist eine Anpassung der rf12_center_freq möglich. Wäre auch eventuell für LaCrosse sinnvoll.
an die Änderungen im PCA301 Sketch (Wiki) hatte ich auch gedacht.
Ich habe drei TX29DTH-IT und zwei TX35DTH-IT hier laufen, alle ohne Probleme und mit identischer Reichweite (gleiches Ergebnis mit zwei JeeLink V3 und zwei JeeNode per FTDI).
Ich glaube nicht, dass die Frequenz der TX35DTH-IT anders ist, zumal es ja mit einem original JeeLink und der gleichen Firmware funktioniert.
Ihr dürft aber gerne mal in der RFM12.cpp an der Frequenz drehen.
RFM12::spi(0xA67c); ist die passende Stelle.
Der Command-Calculator hilft: http://tools.jeelabs.org/rfm12b.html
Falls es tatsächlich eine "Frequenzgeschichte" ist, baue ich dann gerne eine Konfiguration in des Sketch ein.
void RFM12::InitialzeLaCrosse() {
// Deselect the RFM and wait until it is up
digitalWrite(m_ss, HIGH);
for (int i = 0; i < 10; i++) { delay(10); }
RFM12::spi(0x8208); // RX/TX off
RFM12::spi(0x80E8); // 80e8 CONFIGURATION EL,EF,868 band,12.5pF (iT+ 915 80f8)
RFM12::spi(0xA67c); // FREQUENCY 868.300
Ich habe aus Neugierde das SDR angeworfen. Der TX29 sendet auf ca. 868,2 MHz (leicht zu erkennen an der stark roten Einfärbung in der waagerechten Linie). TX35 steht mir leider nicht zur Verfügung.
Hallo
Vielen Dank für Eure Unterstützung.
Meine Sensoren laufen nun.
Am meisten geholfen hat mir dieser Blog:
http://blog.moneybag.de/fhem-guenstige-temperatur-und-luftfeuchte-sensoren-von-lacrosse/
Die Anleitung dort ist so gut, dass sogar ein Anfänger wie ich zum Ziel kam.
Gruss Chres
Hallo,
zur Info, der TX37IT scheint nur einen Kanal zu kennen. --> Kanal 08
Bin per Zufall auf diesen Link gestoßen.
http://forum.fhem.de/index.php/topic,27205.0.html
Zitat von: SPucki am 20 September 2014, 12:08:28
Nachdem ich nun ein wenig weiter gegrübelt und experimentiert habe, kommt mir folgender Verdacht:
Es scheint so, als würden die TX37IT ihre Daten alle mit dem gleichen Code übermitteln (vom Battery Changed Flag mal abgesehen).
Die Wetterstationen müssten die gekoppelten Sender dann sozusagen anhand des Timecodes ermitteln, obwohl das Manual dazu etwas anderes sagt.
Hat jemand Erfahrung mit dem TX37IT (gekauft beim großen C)?
Grüße aus München,
Stefan
Ich kann das bestätigen, da mein TX37IT auch immer nur auf Kanal 08 sendet unabhängig von einem Batteriewechsel.
War bisher der Meinung, dass das ein Fehler meines TX37IT ist.
Der Einsatz mehrerer TX37IT mit Jeelink ist deshalb nicht zu empfehlen. (Senden ja alle auf einem Kanal) :(
Falls noch jemand einen TX37IT besitzt bitte mal um Rückmeldung des Kanals.
Wenn sich das bestätigt würde ich einen entsprechenden Vermerk im WIKI einfügen.
Gruß Billy
Hallo
ich habe eine La Crosse Technology WS1501IT Wetterstation, wo ein TX31-it Sender dabei ist und mit Hilfe diesem Blog http://nikseresht.com/blog/?p=99
folgende Daten über ein Jeelink empfangen:
Raw polling RFM12 no error checking !
868.300MHz
A8 E5 6 8 10 72 20 0 36 0 40 0 3F
Temp: 20.8
Humidity: 72
Rain: 0
Wind: 0 Dir: 135
Gust 0
vielleicht hilft es ja.
Mitja
Hallo zusammen,
ich habe seit langem mal wieder ein Update gemacht. Danach war es mir nicht mehr möglich die Temperatursignale in FHEM zu verarbeiten...
Jetzt habe ich raus gefunden an was es liegt.
sub
LaCrosse_Fingerprint($$)
{
my ($name, $msg) = @_;
return ( "", $msg );
}
Das "return ( "", $msg );" muss entfernt werden.
Warum habt ihr dieses Kommando so ergänzt? Gibt es einen Hintergrund? Wäre es möglich dies aus zu kommentieren?
Grüße,
Ulli
Zitat von: ulli am 02 November 2014, 18:49:05
sub
LaCrosse_Fingerprint($$)
{
my ($name, $msg) = @_;
return ( "", $msg );
}
Das "return ( "", $msg );" muss entfernt werden.
Warum habt ihr dieses Kommando so ergänzt? Gibt es einen Hintergrund? Wäre es möglich dies aus zu kommentieren?
Das glaube ich nicht so recht. Laut SVN ist das seit dem initialen commmit vom 6. November 2013 bis heute genau so.
Du meinst doch die 36_lacrosse.pm, oder?
Ja ich mein das LaCrosse Modul.
Komisch...aber wodurch kann es auf einmal relevant werden ob die Fingerprint Routine was returned oder nicht?
Ich habe das Problem, dass nach einem Dispatch aus meinem Modul das Kommando nur von dem LaCrosse Modul ausgewertet wird wenn die Lacrosse Fingerprint Routine nichts zurück gibt...
Also ich habe den LaCrosseITPlusReader.10.1c auf dem JeeLink und bin mit FHEM auf dem trunk-Stand von heute Abend. Das funktioniert wie gehabt.
Zitat von: ulli am 02 November 2014, 18:49:05
Das "return ( "", $msg );" muss entfernt werden.
Warum habt ihr dieses Kommando so ergänzt? Gibt es einen Hintergrund? Wäre es möglich dies aus zu kommentieren?
das halte ich für sehr unwahrscheinlich das es daran liegt. der code teil ist 'seit immer' so...
wie kommst du denn darauf?
gruss
andre
Ja das versteh ich auch nicht. Ich schildere mal die Situation:
Ich habe ein Modul das die Nachrichten über eine RS232 Schnittstelle empfängt, dann denn LaCrosse String zusammen baut (wie "OK 9 32 1 4 91 62") und dann Dispatched.
Das Dispatch Kommando ist wie folgt:
$hash->{"${name}_MSGCNT"}++;
$hash->{"${name}_TIME"} =
$hash->{READINGS}{state}{TIME} = TimeNow(); # showtime attribute
$hash->{RAWMSG} = $rmsg;
my %addvals = (RAWMSG => $rmsg);
Dispatch($hash, $dmsg, \%addvals);
$dmsg ist damit "OK 9 32 1 4 91 62"
Leider kommt diese Nachricht aber nie im ursprünglichen LaCrosse.pm Modul an.
Auf Grund dessen habe ich mich auf die Suche nach der Ursache gemacht.
Im fhem.pl bleibt das Kommando in der Dispatch Routine fest in Zeile 3054:
if( my $ffn = $modules{$m}{FingerprintFn} ) {
($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn);
return rejectDuplicate($name,$idx,$addvals) if($isdup);
}
Wenn ich eben dann das "return ( "", $msg );" aus dem LaCrosse Modul entferne bleibt das Kommando nicht mehr stecken und es wird korrekt Dispatched.
Was denkst du Andre?
der sinn von CheckDuplicate ist es doppelt empfangene nachrichten zu ignorieren. z.b. wenn man mehr als einen cul/jeelink oder was auch immer im system hat um den empfangsbereich zu vergrößern und manche sender von beiden empfangen werden. oder wenn eine nachricht ein mal direkt und ein mal über einen repeater empfangen wird. die FingerprintFn macht aus der empfangenen nachricht einen eindeutigen fingerprint der statt der nachricht verglichen wird weil bei manchen protokollen/systemen sich die nachrichten geringfügig unterscheiden können wenn sie z.b. über einen repeater weiter gesendet werden es aber trotzdem die gleiche nachricht ist. hier würde die finerprint funktion den zähler oder die repeater id oder was auch immer ausblenden. bei LaCrosse ist das nicht relevant und deshalb wir die komplette nachricht als fingerprint verwendet. nachrichten zählen als doppelt wenn sie den gleichen fingerprint haben und in weniger als 0.5 senden aufeinander folgen.
wenn die nachricht hier abgewiesen wird dann weil fhem denkt das sie doppelt angekommen ist die prüfung abzuschalten ist glaube ich der falsche weg.
ohne genauere nachgeschaut zu haben erst mal nur ein paar ideen aus dem stegreif:
wie oft kommen die nachrichten von deinem modul? sind sie wirklich unterschiedlich?
hast du dein modul in die clients und matchlist eingetragen ?
$hash->{READINGS}{state}{TIME} = TimeNow(); btw direkt auf $hash->{READINGS} sollte nicht mehr sein. besser die readingsUpdate funktionen verwenden.
Servus,
ich hab jetzt auch einen Jeelik mit TX29DTH-IT in Betrieb.
ich bekomme folgende Ausgabe:
OK 9 23 1 4 203 70
Kann mir einer plausibel erklären, für das die Zahlen stehen ?
Die einzige Zahl die mit etwas auf dem Display übereinstimmt, ist die 70 für die Luftfeuchte.
Danke!
Gruß Tim
Zitat von: v.i.p.e.r am 05 November 2014, 20:45:21
Kann mir einer plausibel erklären, für das die Zahlen stehen ?
Eine plausible Erklärung:
// OK 9 49 1 4 182 54 ID = 49 T: 20.6 H: 54 no NewBatt
// OK 9 55 129 4 192 56 ID = 55 T: 21.6 H: 56 WITH NewBatt
// OK 9 ID XXX XXX XXX XXX
// | | | | | | |
// | | | | | | --- Humidity incl. WeakBatteryFlag
// | | | | | |------ Temp * 10 + 1000 LSB
// | | | | |---------- Temp * 10 + 1000 MSB
// | | | |-------------- Sensor type (1 or 2) +128 if NewBatteryFlag
// | | |----------------- Sensor ID
// | |------------------- fix "9"
// |---------------------- fix "OK"
Soweit ich mich erinnere, wird der Temperaturwert in etwa so 'übersetzt':
4 * 256 + 192= 1216 > 21,6°C
4 * 256 + 203= 1227 > 22,7°C
Also eigentlich so:
(4 * 256 + 192 - 1000) / 10
(4 * 256 + 203 - 1000) / 10
Und bei der Humidity muss man das WeakBatteryFlag ausmaskieren. Sonst stimmt der Wert nicht, wenn es gesetzt ist.
Danke , das hat sehr geholfen. Ich nutze zwar kein FHEM sondern was eigenes - aber das hat mir noch gefehlt :)
Hi Zusammen.
Ich Habe diese Sensoren bestellt:
http://www.amazon.de/gp/product/B006MD4ARS?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00 (http://www.amazon.de/gp/product/B006MD4ARS?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00)
Das sind Temperatur-Sender 30.3181.IT Sensoren.
Hat die schon jemand zum laufen gebracht?
Ich habe die bestellt, da ich dachte mit dem Externen Fühler kann ich die super im Aquarium einsetzen.
Muss ich die nun wieder zurückschicken weil ich die nicht einbinden kann?
Mit Autocreate bei [LaCrosseITPlusReader.10.1d @17.241 kbps] taucht jedenfalls nichts auf.
Hoffe ihr könnt mir da helfen.
Gibt es andere mit Externem Fühler?
Gruss Daniel
Ja, sogar von Technoline TX25 IT siehe 1. Beitrag ;)
Gruß Billy
Zitat von: 2P4u am 10 November 2014, 21:28:30
Das sind Temperatur-Sender 30.3181.IT Sensoren.
Hat die schon jemand zum laufen gebracht?
Schon mal mit 9579 kbps versucht?
Hallo !
Hatte auch Probleme Sensoren mit 9.579 kbps einzubinden TFA 30.3155 und TX35DH-IT! Sie wurden einfach nicht Empfangen ! Aktuell hatte ich keine Probleme mit Sensoren die mit 17.241 kbps senden ! TX29DTH-IT .
Nach viel rumprobieren mit dem Sketch und div. Configänderungen an dem RFM12B Klappt es nun Super !
Ich habe die Frequenz vom RFM12B in der Config der RFM12.CCP des Sketches angepasst !
Ich habe den Empfänger auf 9.579 kbps fest Eingestellt und Bitweise die Frequenz geändert bis alle Sensoren ohne CRC Fehler mit OK 9 Empfangen wurden !Bei mir passt es so ->
von 0xA67c 868.3000MH auf 0xA681 868.3250MHz
zusätzlich habe ich auch die Werte der AFC geändert !
von 0xC49f auf 0xC481
Eine Änderung der Bandbreite hatte keinen Erfolg !
Die Änderung des Kondensators des RFM12B Modul für den OOK Modus hatte auch kein Erfolg gebracht !Try & ERROR !!
Mir Ist dabei aufgefallen das es bei mir sehr empfindlich reagiert hat bei den Sensoren mit 9.579 kbps! ein Bit daneben und schon hatte ich wieder nur Datenmüll oder nix Empfangen ! Diese Änderungen haten keine Auswirkung auf den Empfang mit 17.241 kbps diese Sensoren wurden auch weiterhin Super empfangen !
Meine Sensoren hatte Ich von hier !
http://www.wetterladen.de/gebrauchter-sender-fuer-wd-geraet-30.3155-wd?c=1156
Soll keine Werbung sein ! Habe nur lange gesucht bis Ich Sensoren gefunden habe die Temp und Feuchte anzeigen und sofort Lieferbar waren und mit 11,95 € sehr günstig ! Die TX29 DTH-IT sind ja derzeit wie es scheint bis Januar vergriffen ! Siehe Völkner oder digitalo SMV ect...
Versandkostenfrei und trotz als Gebraucht verkauft kamen die Dinger in der Original Verpackung und sahen Neu aus !
Vielleicht hat jemand Lust es auszuprobieren.......
Gruß Dirk
Zitat von: HCS am 11 November 2014, 08:29:22
Schon mal mit 9579 kbps versucht?
Ok das probiere ich mal heute Abend.
Danke für die Info.
Ansonsten gehen die einfach wieder zurück zu Amazon.
Die haben mir eben vom Design gefallen.
@Andre:
Ich versteh aber dann nicht warum mein Modul, welches direkt über die Read() Funktion die Nachricht empfängt und dann an Parse() weiter leitet und dann wiederum die Nachricht Dispatched() diese als Duplikat erkannt wird?
Zitat von: justme1968 am 05 November 2014, 20:26:02
der sinn von CheckDuplicate ist es doppelt empfangene nachrichten zu ignorieren. z.b. wenn man mehr als einen cul/jeelink oder was auch immer im system hat um den empfangsbereich zu vergrößern und manche sender von beiden empfangen werden. oder wenn eine nachricht ein mal direkt und ein mal über einen repeater empfangen wird. die FingerprintFn macht aus der empfangenen nachricht einen eindeutigen fingerprint der statt der nachricht verglichen wird weil bei manchen protokollen/systemen sich die nachrichten geringfügig unterscheiden können wenn sie z.b. über einen repeater weiter gesendet werden es aber trotzdem die gleiche nachricht ist. hier würde die finerprint funktion den zähler oder die repeater id oder was auch immer ausblenden. bei LaCrosse ist das nicht relevant und deshalb wir die komplette nachricht als fingerprint verwendet. nachrichten zählen als doppelt wenn sie den gleichen fingerprint haben und in weniger als 0.5 senden aufeinander folgen.
wenn die nachricht hier abgewiesen wird dann weil fhem denkt das sie doppelt angekommen ist die prüfung abzuschalten ist glaube ich der falsche weg.
ohne genauere nachgeschaut zu haben erst mal nur ein paar ideen aus dem stegreif:
wie oft kommen die nachrichten von deinem modul? sind sie wirklich unterschiedlich?
hast du dein modul in die clients und matchlist eingetragen ?
$hash->{READINGS}{state}{TIME} = TimeNow(); btw direkt auf $hash->{READINGS} sollte nicht mehr sein. besser die readingsUpdate funktionen verwenden.
Zitat von: 2P4u am 11 November 2014, 12:50:41
Ok das probiere ich mal heute Abend.
Danke für die Info.
Ansonsten gehen die einfach wieder zurück zu Amazon.
Die haben mir eben vom Design gefallen.
Ich habe mich nun hier durchgekämpft und nochmal ein update gemacht, ausserdem nochmal neu geflashed.
Verunsichert bin ich allerdings darum: http://forum.fhem.de/index.php/topic,28232.msg217966.html#msg217966 (http://forum.fhem.de/index.php/topic,28232.msg217966.html#msg217966)
Mein Status ist nun folgender.
model[LaCrosseITPlusReader.10.1d @17.241 kbps]
RAWMSG OK 9 50 1 4 67 88 Also gehe ich davon aus, das da irgendwas kommt.
Jedoch wird kein Device angelegt, obwohl ich auf autocreate bin.
Hier noch ein Log Auszug:
2014.11.11 22:07:34 3: LaCrosse: Unknown device 32, please define itVielleicht hat das mit dem im Link erwähnten Fehler zu tun?
Kann mir hier jemand weiterhelfen?
@2P4u: was bedeutet du 'bist auf autocreate'?
das du LaCrossePairForSec im jählings device mit dem ignore_battery flag setzen musst hast du gesehen ?
gruss
andre
Das hier habe ich gefunden:
set myJeeLink LaCrossePairForSec 120 ignore_battery
Hab es vorhin schon ausgeführt.
Jetzt nochmal shutdown restart und nochmal ausgeführt und siehe da!
Er findet die Sensoren!
Super vielen Dank!
Grüsse
@ulli: ich habe wie gesagt auf die schnelle keine idee was und warum es mit deinen nachrichten anders läuft. am besten schaust du in rejectDuplicate was genau in deinem fall passiert.
gruss
andre
Zitat von: 2P4u am 11 November 2014, 22:21:09
Das hier habe ich gefunden:
set myJeeLink LaCrossePairForSec 120 ignore_battery
Hab es vorhin schon ausgeführt.
Jetzt nochmal shutdown restart und nochmal ausgeführt und siehe da!
Er findet die Sensoren!
Super vielen Dank!
Grüsse
@2P4u: Bedeutet das, dass Du die Sender vom Typ 30.3180.IT zum Laufen bekommen hast, oder siehst Du andere Sender in Deiner Nähe?
Ich habe auch dieses Modell und bin an einer Lösung sehr interessiert. :)
Grüße
Physikus
Hi,
erst dachte ich, super alle zum laufen gebracht (Wollte einen Aussensensor)
Es kam auch schön ein Sensor mit plausibibler Temp Anzeige. Also habe ich diesen eingebunden.
Kurz drauf haben ich den Aussensensor nach drinnen geholt und der hat in Fhem aber immernoch Aussentemp. angezeigt.
Also habe ich wohl einen von den Nachbarn erwischt (Auch ok, muss ich schon keinen draussen platzieren).
Die 30.3181.IT sind grade auf dem Weg zur Post. Die gehen wieder dahin wo sie hergekommen sind. Also NEIN die wurden nicht erkannt.
Werde mir jetzt wohl die Technoline TX25 IT bestellen.
Gruss
Zitat von: hdp1999 am 11 November 2014, 09:47:11
Hallo !
Hatte auch Probleme Sensoren mit 9.579 kbps einzubinden TFA 30.3155 und TX35DH-IT! Sie wurden einfach nicht Empfangen ! Aktuell hatte ich keine Probleme mit Sensoren die mit 17.241 kbps senden ! TX29DTH-IT .
Nach viel rumprobieren mit dem Sketch und div. Configänderungen an dem RFM12B Klappt es nun Super !
Ich habe die Frequenz vom RFM12B in der Config der RFM12.CCP des Sketches angepasst !
Ich habe den Empfänger auf 9.579 kbps fest Eingestellt und Bitweise die Frequenz geändert bis alle Sensoren ohne CRC Fehler mit OK 9 Empfangen wurden !Bei mir passt es so ->
von 0xA67c 868.3000MH auf 0xA681 868.3250MHz
zusätzlich habe ich auch die Werte der AFC geändert !
von 0xC49f auf 0xC481
Eine Änderung der Bandbreite hatte keinen Erfolg !
Die Änderung des Kondensators des RFM12B Modul für den OOK Modus hatte auch kein Erfolg gebracht !Try & ERROR !!
Mir Ist dabei aufgefallen das es bei mir sehr empfindlich reagiert hat bei den Sensoren mit 9.579 kbps! ein Bit daneben und schon hatte ich wieder nur Datenmüll oder nix Empfangen ! Diese Änderungen haten keine Auswirkung auf den Empfang mit 17.241 kbps diese Sensoren wurden auch weiterhin Super empfangen !
Meine Sensoren hatte Ich von hier !
http://www.wetterladen.de/gebrauchter-sender-fuer-wd-geraet-30.3155-wd?c=1156
Soll keine Werbung sein ! Habe nur lange gesucht bis Ich Sensoren gefunden habe die Temp und Feuchte anzeigen und sofort Lieferbar waren und mit 11,95 € sehr günstig ! Die TX29 DTH-IT sind ja derzeit wie es scheint bis Januar vergriffen ! Siehe Völkner oder digitalo SMV ect...
Versandkostenfrei und trotz als Gebraucht verkauft kamen die Dinger in der Original Verpackung und sahen Neu aus !
Vielleicht hat jemand Lust es auszuprobieren.......
Gruß Dirk
Hallo Dirk,
natürlich hab ich Lust, klappt aber leider nicht.
Ich habe die beschriebenen Sensoren mal geordert.
Ich habe zwar einen älteren Sketch (2012-02-11) und die beschriebenen Werte habe ich gefunden.
zumindest unter fhem sollte irgendwas von "unknown code" auftauchen.
wie ist denn der Code für 9.579 ?
Noch eine Idee?
EDIT: Klappt! Aktuellen Jeelink - Sketch nehmen und die Änderungen von Dirk übernehmen!
Jetzt mache ich noch eine Reichweitenüberprüfung.
EDIT2: Ich habe mit dem Sketch 10.0f getestet und AFC auf 0xC49f belassen. Damit empfange ich die tx 29 DT-h und die obigen DFA Sensor parallel vom Keller bis in die Wohnung. der tx 29 DTH musste ein paar mal neu angelernt werden.
Frage: ich habe das Togglen auf 20 gesetzt , ist das schädlich für den Mikrocontroller oder den RFM-Baustein?
Zitat von: fh168 am 15 November 2014, 12:41:27
EDIT2: Ich habe mit dem Sketch 10.0f getestet und AFC auf 0xC49f belassen. Damit empfange ich die tx 29 DT-h und die obigen DFA Sensor parallel vom Keller bis in die Wohnung
OK, dann werde ich mich mal ans Werk machen und eine Einstellmöglichkeit für die Frequenz im Sketch vorsehen, um es von FHEM aus in InitCommands setzen zu können.
Zitat von: fh168 am 15 November 2014, 12:41:27Frage: ich habe das Togglen auf 20 gesetzt , ist das schädlich für den Mikrocontroller oder den RFM-Baustein?
Nein. Läuft bei mir auch schon seit mindestens Februar auf einem JeeLink und einen JeeNode so.
Hallo, kurze Frage. Ist es möglich mitterweile die Sensoren der WS1080 mit Jeelink zu empfangen?
Weitere Frage, lassen sich die Sensoren der Ws1600 mil Jeelink und FHEM empfangen?
http://www.conrad.de/ce/de/product/672861/Conrad-Funk-Wetterstation-mit-USB-Touchscreen?gclid=Cj0KEQiAkJyjBRClorTki_7Zx8QBEiQAcqwGMRlnzOuBqb6po0qbtAz6VtWSTwaQd_-yUQiYLMRr09IaAiKE8P8HAQ&insert_kz=NA&hk=SEM&WT.srch=1&WT.mc_id=Dynamische_Suchanzeigen&s_kwcid=AL!222!3!47363253081!b!!g!!_inurl:product&ef_id=U63mJAAABD0-AARA:20141116003509:s (http://www.conrad.de/ce/de/product/672861/Conrad-Funk-Wetterstation-mit-USB-Touchscreen?gclid=Cj0KEQiAkJyjBRClorTki_7Zx8QBEiQAcqwGMRlnzOuBqb6po0qbtAz6VtWSTwaQd_-yUQiYLMRr09IaAiKE8P8HAQ&insert_kz=NA&hk=SEM&WT.srch=1&WT.mc_id=Dynamische_Suchanzeigen&s_kwcid=AL!222!3!47363253081!b!!g!!_inurl:product&ef_id=U63mJAAABD0-AARA:20141116003509:s)
Grüße
cerberus
Zitat von: HCS am 15 November 2014, 17:06:20
OK, dann werde ich mich mal ans Werk machen und eine Einstellmöglichkeit für die Frequenz im Sketch vorsehen, um es von FHEM aus in InitCommands setzen zu können.
Nein. Läuft bei mir auch schon seit mindestens Februar auf einem JeeLink und einen JeeNode so.
Ich würde den Sketch so vorbereiten, das Toggle automatisch eingeschaltet ist.
Kann man seit neuestem auch von Fhem aus den Jeelink flashen?
Bei mir tauchen so cryptische Zeilen auf?
flashCommand
avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Aber dafür benötigt man doch avrdude, welches standardmässig doch gar nicht installiert ist ?!
robin
das geht schon eine ganze weile. und ja. avrdude muss vorher installiert sein.
http://www.fhemwiki.de/wiki/JeeLink#JeeLink_aus_Fhem_flashen
gruß
andre
mit dem LaCrosseITPlusReader10 hab ich so meine Probleme version 10.1d
der sagt bei RFM12::DataRates DATA_RATE usw..
immer RFM12 has not been declared, fehlt da eine library? wo finde ich die? die RFM12b hab ich gefunden passt aber nicht
Zitat von: fh168 am 16 November 2014, 17:07:25
mit dem LaCrosseITPlusReader10 hab ich so meine Probleme version 10.1d
der sagt bei RFM12::DataRates DATA_RATE usw..
immer RFM12 has not been declared, fehlt da eine library? wo finde ich die? die RFM12b hab ich gefunden passt aber nicht
http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip
In dem ZIP sind alle erforderlichen libs enthalten
In ein Verzeichnis mit dem Namen LaCrosseITPlusReader10 entpacken, dann muss das gehen.
Habe gerade nochmal reingeschaut, die RFM12 ist mit drin.
Zitat von: fh168 am 16 November 2014, 14:03:00
Ich würde den Sketch so vorbereiten, das Toggle automatisch eingeschaltet ist.
Das lässt sich von FHEM aus sehr einfach mit
attr myJeeLink initCommands 30t verledigen.
Wenn der toogle per default an ist, haben Anwender, die Sensoren auf nur einer data rate haben, den Nachteil, dass sie immer 30 Sekunden lang nichts empfangen.
Zitat von: cerberus am 16 November 2014, 01:35:26
Hallo, kurze Frage. Ist es möglich mitterweile die Sensoren der WS1080 mit Jeelink zu empfangen?
Weitere Frage, lassen sich die Sensoren der Ws1600 mil Jeelink und FHEM empfangen?
http://www.conrad.de/ce/de/product/672861/Conrad-Funk-Wetterstation-mit-USB-Touchscreen?gclid=Cj0KEQiAkJyjBRClorTki_7Zx8QBEiQAcqwGMRlnzOuBqb6po0qbtAz6VtWSTwaQd_-yUQiYLMRr09IaAiKE8P8HAQ&insert_kz=NA&hk=SEM&WT.srch=1&WT.mc_id=Dynamische_Suchanzeigen&s_kwcid=AL!222!3!47363253081!b!!g!!_inurl:product&ef_id=U63mJAAABD0-AARA:20141116003509:s (http://www.conrad.de/ce/de/product/672861/Conrad-Funk-Wetterstation-mit-USB-Touchscreen?gclid=Cj0KEQiAkJyjBRClorTki_7Zx8QBEiQAcqwGMRlnzOuBqb6po0qbtAz6VtWSTwaQd_-yUQiYLMRr09IaAiKE8P8HAQ&insert_kz=NA&hk=SEM&WT.srch=1&WT.mc_id=Dynamische_Suchanzeigen&s_kwcid=AL!222!3!47363253081!b!!g!!_inurl:product&ef_id=U63mJAAABD0-AARA:20141116003509:s)
Grüße
cerberus
Nein, beide nicht.
Zitat von: cerberus am 16 November 2014, 01:35:26
Hallo, kurze Frage. Ist es möglich mitterweile die Sensoren der WS1080 mit Jeelink zu empfangen?
Weitere Frage, lassen sich die Sensoren der Ws1600 mil Jeelink und FHEM empfangen?
http://www.conrad.de/ce/de/product/672861/Conrad-Funk-Wetterstation-mit-USB-Touchscreen?gclid=Cj0KEQiAkJyjBRClorTki_7Zx8QBEiQAcqwGMRlnzOuBqb6po0qbtAz6VtWSTwaQd_-yUQiYLMRr09IaAiKE8P8HAQ&insert_kz=NA&hk=SEM&WT.srch=1&WT.mc_id=Dynamische_Suchanzeigen&s_kwcid=AL!222!3!47363253081!b!!g!!_inurl:product&ef_id=U63mJAAABD0-AARA:20141116003509:s (http://www.conrad.de/ce/de/product/672861/Conrad-Funk-Wetterstation-mit-USB-Touchscreen?gclid=Cj0KEQiAkJyjBRClorTki_7Zx8QBEiQAcqwGMRlnzOuBqb6po0qbtAz6VtWSTwaQd_-yUQiYLMRr09IaAiKE8P8HAQ&insert_kz=NA&hk=SEM&WT.srch=1&WT.mc_id=Dynamische_Suchanzeigen&s_kwcid=AL!222!3!47363253081!b!!g!!_inurl:product&ef_id=U63mJAAABD0-AARA:20141116003509:s)
Grüße
cerberus
Die hier scheint mit dem Jeelink zu gehen.
http://forum.fhem.de/index.php/topic,14786.msg213438.html#msg213438
La Crosse Technology WS1501IT Wetterstation
Gruß Billy
@HCS, Sketch funktioniert jetzt, ich habe die Arduino-Dateistruktur mal wieder neu geordnet.
An welchen Bytes muss man drehen, damit man anstatt eines RFM12 Transceiver Moduls auch ein RFM02 (Empfänger) verwenden kann. Lt Datenblatt ist nur die SPI-Ansteuerung anders.
Zitat von: Billy am 16 November 2014, 21:55:11
Die hier scheint mit dem Jeelink zu gehen.
http://forum.fhem.de/index.php/topic,14786.msg213438.html#msg213438
La Crosse Technology WS1501IT Wetterstation
Gruß Billy
Ich meinte auch nicht, dass man so etwas generell mit dem JeeLink nicht empfangen kann. Der Sketch kann es nicht.
Es müsste also implementiert werden und auch ein passendes Modul in FHEM dafür gemacht oder gefunden werden.
Zitat von: fh168 am 16 November 2014, 21:59:20
An welchen Bytes muss man drehen, damit man anstatt eines RFM12 Transceiver Moduls auch ein RFM02 (Empfänger) verwenden kann. Lt Datenblatt ist nur die SPI-Ansteuerung anders.
Das RFM02 ist ein
Funk-Sendemodul. Der Nachfolger für das abgekündigte RFM12B Funkmodul ist das pinkompatible RFM69CW Funkmodul. RF69 ist bereits in der JeeLib implementiert: https://github.com/jcw/jeelib
ich meinte auch das RFM01
Lieben Gruß an die Fhem Gemeinde. Ich bin eigentlich nur ein stiller Leser des Forum. Aber das Forum hat mir die letzten 6 Monate super oft geholfen. Vielen Dank an alle die so tatkräftig hier unterstützen!
Ich habe mir einen Arduino mit RFM12B gekauft. Hier könnt ihr den RFM12B noch bestellen http://www.csd-electronics.de (http://www.csd-electronics.de)
Dazu die Temperatursensoren TFA 30.3155.
Den Adruino zusammengebaut und geflasht. An meinen FHEM Server gehängt und gewundert, dass nur alle 10 Minuten die Sender aktualisiert wurden. Erst nachdem ich die Frequenz Schrittweise geändert habe, konnten alle Sensoren sauber erkannt werden. Dies soll eine Hilfe sein für diejenigen, die auch dieses Problem haben.
Auf dieser Seite unter
http://tools.jeelabs.org/rfm12b.html (http://tools.jeelabs.org/rfm12b.html)
Im Command Calculator unter Frequency Setting die Frequenz Schrittweise hoch oder runter stellen. Standard ist der Wert bei F 1660. Dann auf 1659 zb. ändern. Den Wert darüber in Rot in der RFM12.cpp (Jeelink Ketch) unter "RFM12::spi(XXXXX); // FREQUENCY 868.300" eintragen. Den Jeelink sketch mit der Adruino Software flashen. Jetzt den Serial Monitor in der Adruiono Software öffnen und schauen ob schneller in kürzerer Zeit Einträge der Sensoren erscheinen. Das Spielchen dann wieder von vorne.
Ich denke das liegt an den hohen Bauteiltoleranz des RFM12 Chip
Ps. Bei mir war die beste Frequenz bei 868.2800MHz
Lieben Gruß
Robert
Zitat von: Riker am 17 November 2014, 16:32:19
Hier könnt ihr den RFM12B noch bestellen http://www.csd-electronics.de (http://www.csd-electronics.de)
hier gibt es ihn billiger: http://www.tme.eu/de/katalog/?idp=1&search=rfm12b&cleanParameters=1
Grüße,
Alexander
Hallo, das halte ich für eine gute Idee. Hat jemand eine Ahnung wie man das in FHEM einbinden kann. Ich habe mir vorgestelle, sollte ich die Platine bekommen, das ganze mit einem 1x RFM12B 868 MHz zu bestücken.
http://www.britishideas.com/category/electronics/ (http://www.britishideas.com/category/electronics/)
Grüße
cerberus
Zitat von: cerberus am 18 November 2014, 07:51:51
Hallo, das halte ich für eine gute Idee. Hat jemand eine Ahnung wie man das in FHEM einbinden kann. Ich habe mir vorgestelle, sollte ich die Platine bekommen, das ganze mit einem 1x RFM12B 868 MHz zu bestücken.
http://www.britishideas.com/category/electronics/ (http://www.britishideas.com/category/electronics/)
Grüße
cerberus
Nur ein Hinweis:
Da steht was von 433 MHz und RFM01 auf der Website, Lacrosse ist 868 MHz und mit RFM12. Also nicht nur die Frequenzen sondern auch die Bausteine sind unterschiedlich.
Hallo Cerberus.
Willst du damit die WH1080 Wetterstation b.z.w. WH1080-Sensoren abfragen?
Die arbeitet meines Wissens mit 868 MHz.
Würde mich auch interessieren wenn man die WH1080 Sensoren direkt über 868 MHz abfragen könnte und nicht über Wetterstation --> USB --> FHEM.
Gruß Uwe
Hallo Uwe, hallo fh168, genau das habe ich vor, da USB immer Kabel beutet was Räumlich nicht immer so einfach ist. Ich habe je geschrieben das ich die Platine dann mit einem 1x RFM12B-S2 mit 868 MHZ bestücken würde. Von seegel-systeme gibt es ja schon so was ähnliches, aber auf der Platine von britishideas.com kann man ja zusätzlich noch den BMP085 bestücken, was mir sehr gut gefällt.
http://shop.seegel-systeme.de/Module/Raspberry-RFM-SMA.html#preisalarm_link (http://shop.seegel-systeme.de/Module/Raspberry-RFM-SMA.html#preisalarm_link)
Gruß
cerberus
Beide Platinen kommunizieren nicht seriell sondern via SPI mit dem Raspberry.
Nach meiner Kenntnis existiert derzeit kein FHEM perl Modul, welches die Kommunikation am SPI-Bus mit dem RFM12B Funkmodul unterstützen würde.
Der BMP085 ist bereits in FHEM eingebunden.
ich habe unten eine version des LaCrosse moduls angehängt die im define zwei zusätzliche parameter als korrekturfaktor für temperatur und feuchte unterstützt. das ganze sollte so funktionieren wie im CUL_WS modul für s300th und co.
bitte mal testen.
danke
andre
Zitat von: fh168 am 17 November 2014, 10:01:32
ich meinte auch das RFM01
Würde mich auch interessieren! (RFM01 statt RFM12)
Zitat von: justme1968 am 19 November 2014, 12:28:40
ich habe unten eine version des LaCrosse moduls angehängt die im define zwei zusätzliche parameter als korrekturfaktor für temperatur und feuchte unterstützt. das ganze sollte so funktionieren wie im CUL_WS modul für s300th und co.
bitte mal testen.
danke
andre
Siehe Anhang. Ein Diff zeigt es Dir.
arg... ich weiss nicht wie oft mir das schon passiert ist...
danke. wenn es jetzt endlich geht würde ich es einchecken.
gruss
andre
Gründlich habe ich es nicht getestet. Nur mal schnell ans Laufen gebracht.
die corr1 in corr2 Änderung bei der humidity aust Du auch gesehen?
Ich lasse es mal bis heute Abend laufen und ändere gelegentlich die Korrekturfaktoren.
Wenn bis da hin nichts passiert würde ich dann einchecken empfehlen können.
Hi,
ich benutze das Modul nun schon seit geraumer Zeit. Nun habe ich einen zusätzlichen Sensor gekauft und versucht ihn anzumelden, und obwohl das mit 6 vorhergehenden letzten Winter geklappt hat, geht es jetzt nicht. Ich habe den Sensor sogar schon einmal umgetauscht. Autocreate ist in FHME an, und ich sehe über Tage auch einige andere Sensoren (vmtl. Nachbarschaft) , die erkannt werden, aber nicht mein eigener.
Wenn ich den Sensor händisch hinzufüge werden auch keine Werte übertragen.
Wo kann ich mit der Suche weitermachen?
Zitat von: justme1968 am 20 November 2014, 16:07:39wenn es jetzt endlich geht würde ich es einchecken.
Sieht gut aus, keine Auffälligkeiten. Aus meiner Sicht kannst Du das einchecken.
habe eingecheckt. deine version :)
gruss
andre
LaCrosseITPlusReader.10.1e
Ich habe den Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann.
Dazu versteht er das neue Kommando "f"
Beispiel:
set myJeeLink raw 868295f
setzt die Frequenz auf 868295 kHz
Sie kann natürlich auch in initCommands mit gesetzt werden. Beispiel:
attr myJeeLink initCommands 30t 0a 868305f v
Setzt die data rate auf 30 Sekunden toggle, die Activity-LED auf aus und die Frequenz auf 868305 kHz.
Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5 kHz -Schritten eingestellt werden.
Die aktuell eingestellte frequenz wird vom Sketch in der "v-Info" mit ausgegeben.
Beispiel:
[LaCrosseITPlusReader.10.1e @AutoToggle 30 Seconds / 868295 kHz]
Wer bisher direkt im Sketch die Frequenz angepasst hat, muss da nun im "// --- Configuration" Abschnitt der LaCrosseITPlusReader10.ino tun. Die Einstellung in RFM12::InitialzeLaCrosse ist entfallen. Hat aber auch den Vorteil, dass man die Frequenz direk in kHz angeben kann und nicht mehr rechnen muss.
Die Anderungen sind eingecheckt und ab sofort verfügbar (das ZIP und auch die JeeLink_LaCrosse.hex für den "set myJeeLink flash")
Evtl. könnte Billy so nett sein und das im wiki aufnehmen?
ZitatEvtl. könnte Billy so nett sein und das im wiki aufnehmen?
Mach ich gerne, nur nicht heute und morgen, bin unterwegs.
Gruß
Billy
Zitat von: hdp1999 am 11 November 2014, 09:47:11
zusätzlich habe ich auch die Werte der AFC geändert !
von 0xC49f auf 0xC481
Ich glaube, dass die von hdp1999 vorgeschlagene AFC Einstellung besser ist. Ich lasse mein Testsystem mal eine Woche damit laufen.
Hat die sonst noch jemand probiert und Erfahrungen?
yep,
meine TFA Sensoren werden jetzt nicht mehr erkannt, tx 29 dt-h ja.
initCommands
30t 0a 868.325f v
ich habe gerade die aktuelle Version geflashed.
Ich teste mit meinen Jeelink-Clones.
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF
/dev/ttyUSB0@57600
DeviceName
/dev/ttyUSB0@57600
FD
5
NAME
jeelinkcross
NR
7
PARTIAL
RAWMSG
OK 9 40 1 4 211 106
STATE
Initialized
TYPE
JeeLink
jeelinkcross_MSGCNT
107
jeelinkcross_TIME
2014-11-24 14:47:17
model
[LaCrosseITPlusReader.10.1e @AutoToggle 30 Seconds / 868325 kHz]
kann man vielleicht die AFC auch noch als Parameter mitgeben?
Zitat von: fh168 am 24 November 2014, 14:06:21
initCommands
30t 0a 868.325f v
868.325f wäre falsch. Der Punkt darf da nicht rein.
868325f wäre richtig.
Setze mal die AFC im Sketch auf 0xC481 und die Frequenz von FHEM aus, um zu sehen, ob Du dann so empfängst wie bisher.
Damit wäre zuminest getestet, dass die Frequenzeinstellung das macht, was sie soll.
AFC sehe ich zwei Varianten: sie generell umzustellen oder sie auch konfigurierbar zu machen.
kuriose Sache,
wenn ich diese Zeile weglasse
initCommands
30t 0a 868325f v
werden meine tx 29 dth einwandfrei, also alle paar sekunden empfangen.
Ansonsten empfange ich über den Event Monitor nur ab und zu nur etwas und nicht alle tx29 sensoren
2014-11-24 17:12:07 LaCrosse WohnzimmerTemperatur temperature: 22.8
2014-11-24 17:12:07 LaCrosse WohnzimmerTemperatur T: 22.8
2014-11-24 17:12:07 LaCrosse WohnzimmerTemperatur battery: ok
2014-11-24 17:12:07 LaCrosse 04Thermo temperature: 23.7
2014-11-24 17:12:07 LaCrosse 04Thermo humidity: 48
2014-11-24 17:12:07 LaCrosse 04Thermo battery: ok
Ich beame mal den sketch auf meinem jeelink-clone.
vorher lief alles takko mit der fest verdrahteten version.
robin
neuen Sketch draufgeladen
AFC im Sketch auf 0xC481 eingebaut ... alle TX 29 DTH Sensoren werden empfangen.
dann in den Eigenschaften:
initcommand frequenz hinzugefügt... shutdown restart -> nur noch ein tx 29 dth Sensor wird empfangen.
TFA soll angelernt werden .. es wird nichts empfangen.
Ansonsten nutze ich immer noch die Tested with JeeLink v3 (2012-02-11) für meine TX-29 DTH - Sensoren.. Das ist meiner Meinung nach die Beste.
LG
/robin
Hallo !
Ich wollte mich nur mal kurz zu Wort melden ! Bei mir laufen die Sensoren seit dem Post vom 11 Nov. ohne Probleme im Toggle Mode !
An dem Sketch habe Ich nix mehr dran gemacht und Einstellungen auch nicht verändert !
Evt für Leute die Probleme haben erst mal im IDE Monitor die Werte ansehen ! Wenn da nicht "ok9" rauskommt brauch man in FHEM nicht weiter zu Testen !
Bei mir werden bis auf ein paar Ausnahmen alle Sensoren sofort mit den Richtigen Werten im Log angezeigt !
Kann heute Abend mal ein Screenshot reinstellen !
Der Raw oder Debug Modus hilft auch um überhaupt zu sehen ob Irgendetwas kommt ! Ich hatte bei mir noch parallel ein RTL Stick mit einer SDR Software laufen um zu sehen wann die Biester senden und ob was gelesen wird ! Je dichter man an die passende Frequenz kommt desto schneller werden die Pakte ausgegeben !
Bei mir hatte Ich den JeelinkClone fest auf 9.579 kbps gestellt und mich NUR um diese Sensoren gekümmert ! und solange mit der Frequenz und AFC gespielt bis es geklappt hat ! Das hat auch alles nicht sofort auf Anhieb geklappt ! Es waren schon ein paar Stunden bis alles richtig eingestellt war !
Bei der ganzen Spielerei haben sich die Sensoren mit 17.241 kbps nur nicht gemeldet wenn die Frequenz komplett daneben war !
Gruß aus Bremen Dirk
@ HCS
ZitatEvtl. könnte Billy so nett sein und das im wiki aufnehmen?
Wenn ich die Diskussion richtig verfolge sollte ich mit der Aufnahme ins WIKI wohl warten bis das endgültig klar ist?
Bin aber erst mal für 2 Wochen im Urlaub.
Gruß Billy
Ich empfange seit zwei Tagen nun ohne nennenswerte Lücken: 3 x TX29DTH, 2 x TX35DTH, einen TX25 und einen 30.3155.WD
mit initCommands: 30t 0a 868280f v
und AFC 0xC481 im Sketch festgelegt.
ergibt: [LaCrosseITPlusReader.10.1f @AutoToggle 30 Seconds / 868280 kHz]
Der 30.3155.WD ist der Einzige, der mit der ursprünglichen AFC und 868300 kHz nicht brauchbar empfangen wurde.
Hallo HCS,
ich habe gerade mal deine Frequenz eingestellt. Jetzt werden die 30.3155 erkannt. Bei den TX 29 - DTH ist bei den Einstellungen die Reichweite etwas eingeschränkt.
LG
/robin
Ich glaube, dass es ist nicht die beste Strategie ist, die unterschiedlichsten Sensoren zu mischen.
Absolut stressfei ist es, wenn man nur TX29xxx hat.
Zitat von: fh168 am 25 November 2014, 14:48:31
ich habe gerade mal deine Frequenz eingestellt. Jetzt werden die 30.3155 erkannt. ...
Stellst Du die Frequenz mit "868280f" ein oder hart im Sketch?
Läuft jetzt stabil durch.
Logo, ist das nicht die feine Englische die Sensoren zu mixen. Aber was will man machen, wenn die TX 29 - Serie bis Ende Januar ausverkauft ist?
Und obwohl ich im Log nicht alle 4 s kein Signal mehr bekomme, wie beim ersten Sketch, so werden alle Sensoren (tx 29 und die TFA) jetzt erkannt. Aber ich habe die AFC auf 0xC481 im Sketch gesetzt.
LG
/robin
Zitat von: HCS am 25 November 2014, 17:20:00
Ich glaube, dass es ist nicht die beste Strategie ist, die unterschiedlichsten Sensoren zu mischen.
Absolut stressfei ist es, wenn man nur TX29xxx hat.
Das kann ich nicht bestätigen.
Beweis durch Widerspruch: Bei mir laufen insgesamt 18 LaCrosse Sensoren seit etwa einem Jahr problemlos: TX25IT, TX29IT, TX29DTH-IT, TFA 30.3155, TFA 30.3156. Die Sensoren benutzen unterschiedliche Datenraten und es gibt keine Probleme bei der Übertragung (selbst über mehrere Stockwerke oder Wände). Die TFA Sensoren scheinen "nur" alle 8 Sekunden zu senden, während die anderen etwa alle 4 Sekunden übertragen. Die Aktualisierung in FHEM ist auch mit der Umschaltung alle 30 Sekunden nahezu sofort nach einer Änderung von Temperatur/Feuchtigkeit. Es gibt keine Ausfälle und keine Ausreißer. Natürlich alles nur über einen Jeelink.
Hallo Alexander,
welche Einstellungen im Sketch verwendest Du? Ansonsten kann ich das unterschreiben, vom Keller bis zum Balkon empfängt der Jeelink-(Clone) alles. :-)
LG
/robin
Ich verwende noch den LaCrosseITPlusReader.10.0f.
Ansonsten wurden nur die LED deaktiviert und die TOGGLE-Rate auf 30 eingestellt.
Solange keine Sensoren beteiligt sind, die mit der Frequenz daneben liegen, ist das alles kein Problem.
Besonders bei den 30.3155.WD scheint es aber einzelne (oder auch viele?) zu geben, die daneben liegen. Ich habe so ein Exemplar.
Und dann hat man die spannende Aufgabe, eine Frequenz zu finden, die irgendwo dazwischen liegt und nicht so weit von allen Sensoren entfernt ist, dass die AFC den Sensor nicht mehr "einfängt". Das ist auch der Grund, warum die AFC-Einstellung die Sache zusätzlich verbessern kann.
Hallo,
erstmal möchte ich mich für die tolle Arbeit hier bedanken.
Ich habe mir jetzt ALLE 66 Seiten (und auch alles andere was ich zum Thema gefunden habe) durchgelesen, trotzdem bin ich am verzweifeln.
Es ist mir einfach nicht möglich die Sensoren in FHEM einzufügen.
ich habe FHEM(5.5 neuste Version) auf einem Raspberry mit einem Jeeclone(Version 10.1e, 9.579 kbps/868325 kHz) und 2x TX35DHT-IT.
Im Serial Monitor kommen auch alle Daten super an, wenn ich den Jeeclone allerdings in den Raspberry stecke, empfängt FHEM gar nichts.
Der Jeelink wird als "opened" erkannt, aber egal was ich versuche, die Sensoren werden nicht erkannt. Nach "set myJeeLink LaCrossePairForSec 120 ignore_battery" passiert nichts. Auch nicht nach einem Restart.
gruß
Marco
Hat vielleicht jemand eine Idee was ich falsch mache?
Hallo Marco,
ich kämpfe seit einer Woche mit genau demselben Problem. Am PC funktioniert der JeeLink einwandfrei, am Raspi kommt nichts an.
Ich habe den rfm12 jetzt mal mit 5 V betrieben und alles ist gut.
Vielleicht funktioniert bei dir ja auch.
Gruß
Mick
Neue Version 10.1f
Ich habe den LaCrosse Sketch überarbeitet, dass er optional auch mit einem RFM69CW anstatt einem RFM12B arbeitet.
Der Sketch ermittelt die verbaute Hardware automatisch, es muss also nicht konfiguriert werden, welchen RFM man drauf hat.
Getestet habe ich es mit einem 3,3V Arduino Uno, auf den ich abwechselnd einen RFM12B und einen RFM69CW gesetzt habe,
mit einem JeeNode, den ich anstatt mit einem RFM12B mit einem RFM69CW bestückt habe
und natürlich mit einem original RFM12B JeeLink.
Für die Bastler: Der RFM69CW (Betonung liegt auf CW) ist anschlusskompatibel zum RFM12B.
Das war's dann aber auch schon, Softwaretechnisch haben die absoult nichts miteinander zu tun.
Verdrahtung siehe JeeLink / JeeNode.
Der Sketch benötigt die IRQ-Leitung zu PD2(INT0) des Arduino nicht, man sollte sie aber trotzdem
verdrahten, falls ich sie doch irgendwann mal brauche.
Zwingend benötigt wird: GND, 3.3V, MISO, MOSI, SCK, NSS und eine 82mm Antenne
Und: Pegelanpassung beachten, wenn der RFM nicht an einem 3.3V board betrieben wird.
Die Version-Info habe ich erweitert, so dass sie anzeigt, welches Radio verbaut ist.
Beispiele:
[LaCrosseITPlusReader.10.1f (RFM69CW) @17241 kbps / 868300 kHz]
[LaCrosseITPlusReader.10.1f (RFM12B) @17241 kbps / 868300 kHz]
Und dann gibt es noch ein neues Kommando, das man von FHEM aus absetzen kann,
um die Relay-Funktionalität ein-/auszuschalten:
set myJeeLink raw 1y -> Relay ein
set myJeeLink raw 0y -> Relay aus
Ich hänge den compilierten Sketch hier an.
Super wäre, wenn ihn jemand testen würde (mit RFM12B und falls jemand bastelt, auch mit einem RFM69CW)
Wenn er zumindest mit dem RFM12B (also original JeeLink) keine Probleme macht, checke ich das Ganze
dann nach einiger Zeit offiziell ein.
Interessant ist: für die TFA 30.3155.WD musste ich mit dem RFM12B die Frequenz auf 868280 kHz setzten,
mit dem RFM69CW empfange ich sie ganz normal mit 868300 kHz
Aktuell empfange ich hier: TX29DTH, TX35DTH, TX25IT, TFA 30.3155.WD, EMT7110 und den LevelSender
Und der RFM69CW ist etwas empfindlicher.
Da er auch OOK "offiziell" beherrscht, werde ich mal bei Gelegenheit schauen, was da so machbar wäre.
Hallo,
tolle Arbeit,
werde es gleich ausprobieren.
Kannst Du bitte die Sourcen (den Sketch) anhängen.
Gruß aus Berlin,
Mickbaer
:)
Finde ich auch. Danke Dir.
Die Sourcen würden mich auch interessieren, da ich das dann versuchen würde in den PCA301 Sketch zu übernehmen.
Grüße Jörg
Genau,
um die Einbindung des PCA301 in den Lacrosse, geht es auch mir.
Ich würde dann Deine Sourcen als Grundlagen nehmen.
Moteino und RF69 warten schon auf Ihren Einsatz.
Gruß
Mickbaer
:)
Zitat von: HCS am 31 Dezember 2014, 00:18:21
Neue Version 10.1f
Ich habe den LaCrosse Sketch überarbeitet, dass er optional auch mit einem RFM69CW anstatt einem RFM12B arbeitet.
Der Sketch ermittelt die verbaute Hardware automatisch, es muss also nicht konfiguriert werden, welchen RFM man drauf hat.
....
Hallo HCS,
vielen Dank für die sehr gute Arbeit. Der Sketch läuft bei mir schon auf einem JeeLink mit RFM69CW und empfängt auch. Da ich aber verschiedene Sensoren habe, habe ich auf Toggeln alle 15sec umgeschaltet. Dann wird im FHEM dieses angezeigt.
model [LaCrosseITPlusReader.10.1f (RFM69CW) @AutoToggle 15 Seconds / 0 kHz] und es wird auch nichts mehr empfangen. Ich werde das mal beobachten. Am Sketch wäre ich auch interessiert.
Ich wünsche einen guten Rutsch ins neue Jahr.
tschüss pejonp
Zitat von: pejonp am 31 Dezember 2014, 14:43:02
alle 15sec umgeschaltet. Dann wird im FHEM dieses angezeigt.
model [LaCrosseITPlusReader.10.1f (RFM69CW) @AutoToggle 15 Seconds / 0 kHz] und es wird auch nichts mehr empfangen.
Ich habe 30s toggle seit gestern laufen, ohne irgend welche Probleme.
Du hast nicht mal versehentlich einen 0f an den Sketch geschickt, was die Frequemz auf 0 setzen würde?
Zitat von: JoWiemann am 31 Dezember 2014, 12:04:14
Die Sourcen würden mich auch interessieren, da ich das dann versuchen würde in den PCA301 Sketch zu übernehmen.
Zitat von: Mickbaer am 31 Dezember 2014, 14:26:48
um die Einbindung des PCA301 in den Lacrosse, geht es auch mir.
Ich würde dann Deine Sourcen als Grundlagen nehmen.
Bei JoWiemann verstehe ich, was er vorhat.
@Mickbaer: willst Du PCA301 in den LaCrosse sketch einbauen oder was ist der Plan?
Anbei der Source.
Hallo,
ich habe den Sketch 10.1f mal durchkompliliert und werde den mit dem RFM12B auf meiner Testumgebung und einem Clone längere Zeit mal testen.
Zur Zeit sieht es gut aus:
2014-12-31 17:15:50 LaCrosse 06Thermo temperature: 21.3
2014-12-31 17:15:50 LaCrosse 06Thermo battery: ok
2014-12-31 17:15:50 LaCrosse WohnzimmerTemperatur temperature: 21.3
2014-12-31 17:15:50 LaCrosse WohnzimmerTemperatur battery: ok
2014-12-31 17:15:51 LaCrosse 02Thermo temperature: 22.6
2014-12-31 17:15:51 LaCrosse 02Thermo humidity: 41
2014-12-31 17:15:51 LaCrosse 02Thermo battery: ok
2014-12-31 17:15:55 LaCrosse 02Thermo temperature: 22.6
2014-12-31 17:15:55 LaCrosse 02Thermo humidity: 41
2014-12-31 17:15:55 LaCrosse 02Thermo battery: ok
2014-12-31 17:15:56 LaCrosse 04Thermo temperature: 21.8
2014-12-31 17:15:56 LaCrosse 04Thermo humidity: 48
2014-12-31 17:15:56 LaCrosse 04Thermo battery: ok
2014-12-31 17:15:57 LaCrosse 05Thermo temperature: 22.4
2014-12-31 17:15:57 LaCrosse 05Thermo humidity: 40
Bind ich blind, oder warum sind mir die ganzen Attribute tune_FS20 usw. nicht aufgefallen? wofür sind die?
LG
/robin
Hallo HCS,
ich lese hier seit dem Frühjahr interessiert mit.
Habe FHEM mit zwei Arduino Nano RFM12B; Lacrosse THI29 & PCA301; am laufen.
Idee war, das auf einen Arduino zusammen zu legen.
Da bei der PCA-Steckdose die Anzeigeneinheit, ca. alle 60s eine Anfrage stellt, mit anschließender Antwort der Steckdose/n. die dann aus dem RFM12B ausgelesen werden können. Also Toggeln der RFM12B Parameter, wie das auch schon bei anderen Sensoren gemacht wird.
Dazu wollte ich dann die aktuellsten Sourcen verwende.
Gruß
Mickbaer
:)
Zitat von: fh168 am 31 Dezember 2014, 17:16:16
Bind ich blind, oder warum sind mir die ganzen Attribute tune_FS20 usw. nicht aufgefallen? wofür sind die?
tune_FS20? Was meinst Du? Das sagt mir absoult nichts.
Zitat von: Mickbaer am 31 Dezember 2014, 18:01:41
Habe FHEM mit zwei Arduino Nano RFM12B; Lacrosse THI29 & PCA301; am laufen.
Idee war, das auf einen Arduino zusammen zu legen.
Ich habe mich auch schon gefragt, ob man aus dem LaCrosse- und dem PCA301 Sketch einen machen kann. Da gibt es so viel doppelt.
@JoWiemann: sollen wir das mal ausloten bzw. schauen, ob man es zumindest auf eine gemeinsame Basis stellen kann?
Da ich den PCA301 Sketch nicht kenne, vermag ich es momentan schwer zu beurteilen.
Für den LaCrosse Sketch habe ich die Funktionalitäten ja schon weitestgehend modularisiert.
die idee den lacrosse und den pca301 sketch zu kombinieren gibt es schon länger.
neben der initualisierung auf den jeweiligen rf mode und automatisch hin und her schalten bräuchte man noch das pollen der pc301 dosen (nicht alle haben eine display unit) und den sofortigen wechsel in de pca301 Mode wenn ein schalt befehl an die dosen gesendet werden soll.
bedenken muss man auch das fhem das schalten an der dose nur noch verzögert oder garnicht mit bekommt.
vermutlich würde es darauf hinaus laufen das die pca301 seite des sketch vorrang hat (z.b. beim schalten und sicher stellen das geschaltet wurde) und der empfang aller anderen protokollle dann passiert wenn zeit ist.
das gleiche würde für fs20 und intertechno gelten.
aber selbst wenn es probleme
gibt alles gleichzeitig in einem sketch zu aktiv zu haben ist es sicher sinnvoll beides quelltext mäßig ohne unnötiges verdoppeln unter einen hut zu bekommen end beim kompilieren zwischen lacrosse und pca301 zu wählen.
gruß
andre
@HCS
Zitat von: HCS am 31 Dezember 2014, 00:18:21
Neue Version 10.1f
Die Version-Info habe ich erweitert, so dass sie anzeigt, welches Radio verbaut ist.
Beispiele:
[LaCrosseITPlusReader.10.1f (RFM69CW) @17241 kbps / 868300 kHz]
[LaCrosseITPlusReader.10.1f (RFM12B) @17241 kbps / 868300 kHz]
Und dann gibt es noch ein neues Kommando, das man von FHEM aus absetzen kann,
um die Relay-Funktionalität ein-/auszuschalten:
set myJeeLink raw 1y -> Relay ein
set myJeeLink raw 0y -> Relay aus
Ich hatte ja versprochen das WIKI noch zu aktualisieren. Hoffe komme jetzt nach den Feiertagen dazu.
Noch eine Frage zum
"neuen Kommando, das man von FHEM aus absetzen kann, um die Relay-Funktionalität ein-/auszuschalten!"Hab ich das richtig verstanden, dass der Relay Jeelink am FHEM Rechner (USB) angemeldet wird, dann wird der Relay Modus eingeschaltet (Kommando siehe oben), dann kann der Jeelink wieder abgenommen werden und im abgesetzten Modus als Relay betrieben werden?
Gruß Billy
Zitat von: Billy am 01 Januar 2015, 09:21:47
Hab ich das richtig verstanden, dass der Relay Jeelink am FHEM Rechner (USB) angemeldet wird, dann wird der Relay Modus eingeschaltet (Kommando siehe oben), dann kann der Jeelink wieder abgenommen werden und im abgesetzten Modus als Relay betrieben werden?
Nein. Er merkt sich das
nicht Reset-übergreifend. Wenn man ihn abzieht und neu ansteckt, ist das Relay wieder aus.
Mein use-case warum ich es eingebaut habe: Ich habe im Keller das Produktivsystem stehen und im 1. OG ein Testsystem, das auch permanent läuft. Und dem Testsystem habe ich 1y in die initCommands mit rein gepackt, dass es etwas "mithilft".
Es geht also darum, ein laufendes FHEM-System "nebenbei" auch Relay machen zu lassen.
Und immer dran denken: nie mehr als ein Relay laufen lassen.
Hallo zusammen,
ich brauche etwas Hilfe, siehe hier:
Habe einen RaspberryPi (Modell B) + JeeLink v3 + TX35DTH-IT und irgendwie klappt das garnicht :(.
http://forum.fhem.de/index.php/topic,31342.0.html
Wer kann helfen?
Vielen Dank und Grüße,
Sebastian
Version 10.1g
Wenn Relay aktiviert war (und nur dann), gab es noch eine Debug-Ausgabe auf der Seriellen, was zu hässlichen "Unknown code ... , help me!" Einträgen im Log geführt hat.
Anbei die korrigierte Version.
Zitat von: HCS am 31 Dezember 2014, 18:55:57
Ich habe mich auch schon gefragt, ob man aus dem LaCrosse- und dem PCA301 Sketch einen machen kann. Da gibt es so viel doppelt.
@JoWiemann: sollen wir das mal ausloten bzw. schauen, ob man es zumindest auf eine gemeinsame Basis stellen kann?
Da ich den PCA301 Sketch nicht kenne, vermag ich es momentan schwer zu beurteilen.
Für den LaCrosse Sketch habe ich die Funktionalitäten ja schon weitestgehend modularisiert.
Der EC3000-Sketch Bedarf auch einer Überarbeitung, da ist nix modularisiert.
Die Idee mit der gleichen Basis ist mir auch schon gekommen, da dann auch das Hinzufügen von weiteren Protokollen deutlich einfacher werden würde.
Wenn alle Jeelink-Sketche auf der gleichen Basis laufen, dürfte es auch nicht mehr so kompliziert werden, die dann in einer FW zusammenzuführen.
Würde da auch seitens EC3000 unterstützen, soweit es meine Kompetenzen zulassen ;D
Zitat von: HCS am 31 Dezember 2014, 18:55:57
@JoWiemann: sollen wir das mal ausloten bzw. schauen, ob man es zumindest auf eine gemeinsame Basis stellen kann?
Da ich den PCA301 Sketch nicht kenne, vermag ich es momentan schwer zu beurteilen.
Für den LaCrosse Sketch habe ich die Funktionalitäten ja schon weitestgehend modularisiert.
Meine Komponenten sind gestern eingetrudelt. Müssen jetzt nur noch zusammenfinden :-) und dann geht's los. Ich werde zunächst den PCA Sketch mit dem neuen Transceiver versuchen ans Laufen zu bringen. Dann kommt die Modularisierung, wobei ich mich dann zunächst an Deiner Vorgabe orientieren werde. Berichte, wenn ich weiter bin.
Grüße Jörg
Gibt's eig eine maximal Anzahl von den tx29dth IT? Das was ich so gelesen hab war 20 das höchste.
Gesendet von meinem HTC One mit Tapatalk
Zitat von: domii666 am 10 Januar 2015, 21:41:40
Gibt's eig eine maximal Anzahl von den tx29dth IT? Das was ich so gelesen hab war 20 das höchste.
Die Adresse im LaCrosse IT+ Protokoll ist 6 Bit lang, also sind nicht mehr als 64 Adressen und somit auch nicht mehr Sensoren möglich.
Aber die Probleme beginnen schon eher. Je mehr Sensoren in Betrieb gehen, umso höher ist die Gefahr, dass sich zwei Sensoren beim Einlegen der Batterien die gleiche ID "ausdenken" (hatte ich mal, das ist echt verwirrend und sieht im log wirklich krass aus).
Und wenn genug Sensoren senden, steigt auch der Datenmüll, da sie sich teilweise überlagern.
Ich habe 10 IT+ Sensoren hier laufen, das ist problemlos.
Zitat von: JoWiemann am 10 Januar 2015, 19:02:04
... Dann kommt die Modularisierung, wobei ich mich dann zunächst an Deiner Vorgabe orientieren werde. Berichte, wenn ich weiter bin.
Ja, melde Dich, wenn es so weit ist. Es eilt ja nicht.
Zitat von: Fuchks am 10 Januar 2015, 18:46:46
Der EC3000-Sketch Bedarf auch einer Überarbeitung, da ist nix modularisiert.
Wusste gar nicht, dass es das auch gibt.
Schaut euch den aktuellen LaCrosse-Sketch an, ob ihr mit den Klassen, so wie sie aufgebaut sind, arbeiten könnt.
Wenn ihr sie als gemeinsame Basis nehmen könnt, mache ich gerne auch Anpassungen und Erweiterunge, die ihr da braucht.
So, habe jetzt mal wie versprochen versucht die Themen
RELAY Betrieb zur Reichweiten Verbesserung und Frequenzanpassung in die
http://www.fhemwiki.de/wiki/JeeLink
einzuarbeiten. Vorsicht, ich bin nicht der optimale WIKI-Schreiber. ;)
Gruß Billy
PS. Gibt es die EMT7110 noch irgendwo?
hi,
gibts denn noch günstige Sensoren mit Display?? Die tx29dth-it sind ja ausverkauft.
Hallo,
dieser hier:
http://www.conrad.de/ce/de/product/672226/TFA-Zusatz-Thermosensor-303144-IT?ref=list (http://www.conrad.de/ce/de/product/672226/TFA-Zusatz-Thermosensor-303144-IT?ref=list)
funktioniert laut Wiki auch.
http://www.amazon.de/gp/aw/d/B001NY416G/ref=mp_s_a_1_29?qid=1421172285&sr=8-29&pi=AC_SY200_QL40
Hab ich im einsatz... funktionieren auch
Hallo,
ich habe von diesen (http://www.amazon.de/gp/product/B0009I9ZLI?psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00) 2 Stück im November 2010 für 14,95 Euro gekauft. Sind ok. Zeigen Temperatur und Luftfeuchte im Wechsel auf dem Display an. Ein Sensor hängt im Garten unter einem Vordach geschütz von Regen. Entfernung ca. 20m, wenn nicht noch mehr und auch einige Störsender dazwischen. Die eigentliche Wetterstation (siehe Signatur) (http://www.amazon.de/gp/product/B000R99816?psc=1&redirect=true&ref_=od_aui_detailpages00) verliert diesen ab und zu. Was nicht so schön ist, das beim Batteriewechsel neue Adressen vergeben werden.
Oder nach "30.3144.it" oder nur "30.3144" bei Amazon suchen, dann kommen einige Angebote.
Tschüss Jörg
Welcher verliert den nicht die Adresse?
30144.it von Tfa gefällt mir gut. Der verliert ja auch seine Adresse. Bedeutet bei jedem Batterie Wechsel ein nach dem anderen neu hinzufügen oder wie läuft das ab?
Wollte da schon 20 stk verwenden.
Gesendet von meinem HTC One mit Tapatalk
@Dominik,
Batterien von dem sensor rausnehmen,
in den Eigenschaften des Sensors gehen und
set myThermo ReplaceBatteryforSec 120 klicken.
dann Batterien wechseln und reinlegen... etwas warten
dann das Signal empfangen und dann save oben in dem Textfeld eingeben.
TFA 30.3155 geht auch, hab ich getestet: http://blog.moneybag.de/fhem-guenstige-temperatur-und-luftfeuchte-sensoren-von-lacrosse/
(siehe Foto)
robin
Zitat von: Billy am 13 Januar 2015, 17:39:12
So, habe jetzt mal wie versprochen versucht die Themen
RELAY Betrieb zur Reichweiten Verbesserung und Frequenzanpassung in die
http://www.fhemwiki.de/wiki/JeeLink
einzuarbeiten. Vorsicht, ich bin nicht der optimale WIKI-Schreiber. ;)
Gruß Billy
Sieht doch gut aus. Vielen Dank.
Zitat von: domii666 am 13 Januar 2015, 19:38:16
Welcher verliert den nicht die Adresse?
Ich glaube keiner. Achtgeben, die Sensoren mir einer festen vierstelligen ID (auf der Rückseite aufgedruckt) verwenden ein anderes Protokoll und können mit diesem Sketch nicht empfangen werden.
Wenn man Sensoren kauft, sollte man welche nehmen, die als "funktionierend" gemeldet sind (siehe z.B. Wiki) oder sich sicher sein, dass man sie zurückgeben kann, wenn sie nicht mit dem JeeLink wollen.
Wenn man einen bisher nicht gemeldeten Typ erfolgreich verwendet hat, wäre es super, das an jemanden zurückzumelden, der das Wiki aktualisieren kann.
Gerade von TFA, WetterDirekt, usw. gibt es die tollsten Sensoren und ich glaube denen ihr größtes Hobby ist "Protokolle und Datenraten erfinden" ::)
Ein Beispiel ist der 30.3181.IT
Nachtrag: also ein Beispiel dafür, was nicht funktioniert
Der günstigste mit Display wäre cool. Muss ich mal suchen. Die tx29it kauf ich für außen und wo man das Display halt nicht braucht :)
Gesendet von meinem HTC One mit Tapatalk
Zitat von: HCS am 13 Januar 2015, 20:06:51
Ich glaube keiner. Achtgeben, die Sensoren mir einer festen vierstelligen ID (auf der Rückseite aufgedruckt) verwenden ein anderes Protokoll und können mit diesem Sketch nicht empfangen werden.
Wenn man Sensoren kauft, sollte man welche nehmen, die als "funktionierend" gemeldet sind (siehe z.B. Wiki) oder sich sicher sein, dass man sie zurückgeben kann, wenn sie nicht mit dem JeeLink wollen.
Wenn man einen bisher nicht gemeldeten Typ erfolgreich verwendet hat, wäre es super, das an jemanden zurückzumelden, der das Wiki aktualisieren kann.
Gerade von TFA, WetterDirekt, usw. gibt es die tollsten Sensoren und ich glaube denen ihr größtes Hobby ist "Protokolle und Datenraten erfinden" ::)
Ein Beispiel ist der 30.3181.IT
Nachtrag: also ein Beispiel dafür, was nicht funktioniert
Ich habe diese 30.3181/30.3180 von Dostmann. Sie werden zusammen mit einem komfortablen Logger "Klimalogg pro"vertrieben.
Eigentlich ein schönes Gerät.
Gibt es in Jeelink einen Debug-Modus, mit dem man das Protokoll mitlesen kann?
Vielen Dank
Andreas
Zitat von: andreas58 am 13 Januar 2015, 21:29:19
Ich habe diese 30.3181/30.3180 von Dostmann. Sie werden zusammen mit einem komfortablen Logger "Klimalogg pro"vertrieben.
Eigentlich ein schönes Gerät.
Gibt es in Jeelink einen Debug-Modus, mit dem man das Protokoll mitlesen kann?
Vielen Dank
Andreas
Bei denen galube ich, dass es nicht nur das Protokoll ist, sondern die Übertragung ansich (PSK und nicht FSK)
Und da der RFM12 nur FSK kann, kann er das wohl generell nicht empfangen.
Ich denke, dass für diese Sensoren die Chancen schlecht stehen.
Zitat von: domii666 am 13 Januar 2015, 19:38:16
Welcher verliert den nicht die Adresse?
........
Wollte da schon 20 stk verwenden.
das sind die WT440XH. Diese können nach dem Wechsel der Batterie wieder per Knopf eingestellt werden.
House code (0 - 15) und Device code (1 - 4) siehe WT440XH.cpp und WT440XH.h im Sketch. Leider gibt es die nicht mehr bzw. ich finde keine mehr. Nachfolger oder Ersatz unbekannt ?? Diese zeigen auch Temp und Luftfeuchte im Wechsel an. Leider wird die Luftfeuchte zu gering angezeigt. Aber der große Vorteil ist, das die Adresse vorgegeben werden kann.
Um bei meiner Wetterstation (Maxim II 30.3013) nach einem Batteriewechsel alle Sensoren wieder neu anzulernen, aber nicht jeden Sensor anzufassen, sende ich mit dem LaCrossSketch die Kennungen der Sensoren an die Wetterstation. Ist ja im Sketch schon sehr schön eingebaut. Dieses für die maximal 3 Kanäle der Wetterstation. 2x TFA 30.3144.IT und 1x TX37-IT (nur Temp).
// 2,1,9,44c -> Temperatur 21,9 C and 44% humidity
set JLLaCR raw 2,1,9,44c;
// 14,43,20,0i -> ID 14, Interval 4.3 Seconds, reset NewBatteryFlagafter 20 minutes, 17.241 kbps
set JLLaCR raw 21,44,2,0i;
Nachtrag: mit Display ist gerade schön, da man dann im Garten oder wo auch immer auch die Daten ablesen kann.
jörg
Das ist ja interessant, basiert ja darauf was hier http://forum.fhem.de/index.php/topic,14786.msg149035.html#msg149035
und fortfolgend entstanden ist. :)
Mich würde interessieren ob die Maxim II 30.3013 als Anzeige auch dann länger funktioniert wenn du
mit dem jeelink auf einem Kanal sendest der nicht von einem Sensor bedient wird?
Billy
Zitat von: Billy am 14 Januar 2015, 17:00:33
...
Mich würde interessieren ob die Maxim II 30.3013 als Anzeige auch dann länger funktioniert wenn du
mit dem jeelink auf einem Kanal sendest der nicht von einem Sensor bedient wird?
Billy
Hallo Billy,
wenn du beim Initialisieren eine (falsche ??!!) ID nimmst und dann mit dem JeeLink in regelmäßigen Abständen sendest, wird es angezeigt. Aber ich glaube bei negativen Zahlen (Temp) kommt in der Anzeige FF oder so. Ich weiß es nicht mehr genau. Kann es aus Zeitgründen aber auch jetzt nicht ausprobieren.
Jörg
Zitat von: pejonp am 14 Januar 2015, 17:11:35
Hallo Billy,
wenn du beim Initialisieren eine (falsche ??!!) ID nimmst und dann mit dem JeeLink in regelmäßigen Abständen sendest, wird es angezeigt. Aber ich glaube bei negativen Zahlen (Temp) kommt in der Anzeige FF oder so. Ich weiß es nicht mehr genau. Kann es aus Zeitgründen aber auch jetzt nicht ausprobieren.
Jörg
Teste das mal bei Gelegenheit.
Mit meiner Technoline WS-9140IT ging das nämlich nicht über längere Zeit.
Billy
so mein Tx29-it kam heute, leider kann er ja nur Temperatur und keine Luftfeuchtigkeit :(
Habe mir die geholt .... haben beides ...
TFA Dostmann Sender Wetterdirekt 30.3155 https://www.amazon.de/dp/B001NY416G/ref=cm_sw_r_awd_ogoUub0HYGPTP
kosten halt auch 20€
Viel günstiger hab ich leider keine gefunden
stimmt, aber das ist mir zuviel. Da kann ich gleich Oregon etc kaufen.
Hallo
Ich habe diesen hier, siehe Eintrag weiter vorn.
http://www.voelkner.de/products/199023/Thermosensor-30.3144-It.html
Jörg
Hallo zusammen,
habe mir aus einem Arduino Nano und dem RFM12B einen JeeLink zusammengebaut nach folgender Anleitung:
http://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz/
Der Zusammenbau hat auch ganz gut funktioniert, jedoch bekomme ich den Arduino nicht geflashed. In der Arduino IDE bekomme ich immer folgende Fehlermeldung:
Zitatavrdude: stk500_getsync(): not in sync: resp=0x00
Hat jemand eine Ahnung, woran das liegen kann, bin für jede Hilfe dankbar.
viele Grüße
Alexander
Hallo Alexander,
in der IDE unter Tools->Serieller Port
- richtigen COM-Port ausgewählt?
in der IDE unter Tools->Board
- richtigen Arduino ausgewählt?
Grüße Jörg
Oder flashe ihn von FHEM aus (siehe commmandref beim JeeLink - "set myJeeLink flash LaCrosse")
Zitat von: JoWiemann am 16 Januar 2015, 12:23:14
Hallo Alexander,
in der IDE unter Tools->Serieller Port
- richtigen COM-Port ausgewählt?
in der IDE unter Tools->Board
- richtigen Arduino ausgewählt?
Grüße Jörg
Hallo Jörg,
COM-Port habe ich nur den einen, den ich auswählen kann und in der IDE hatte ich Arduino Nano w/ ATmega328 ausgewählt, müsste eigentlich so stimmen.
viele Grüße
Alexander
Zitat von: HCS am 16 Januar 2015, 12:43:16
Oder flashe ihn von FHEM aus (siehe commmandref beim JeeLink - "set myJeeLink flash LaCrosse")
Hallo HCS,
wenn ich es so probiere, bekomme ich den gleichen fehler.
Zitatavrdude: stk500_rev(): programmer is not responding
avrdude done. Thank you.
viele Grüße
Alexander
EDIT: In FHEM wird mir der JeeLink auf jeden Fall als connected angezeigt.
Hallo zusammen,
es lag an einem fehlenden USB-Treiber, mein Arduino Nano (Clone) hat einen CH340G Chip darauf, somit waren die Versuche mit dem FTDI-Treiber auch immer so erfolglos gewesen.
Habe gerade meinen JeeLink Clone in FHEM eingebunden. State ist auf opened, Batterien hatte ich in meinen TX 29-IT eingelegt, wie beschrieben, jedoch wird mir über autocreate (natürlich aktiv) kein Device angelegt. Habe es auch mit set JeeLink LaCrossePairForSec 120 probiert, was auch nichts gebracht hatte. Es könnte natürlich daran liegen, das etwas defekt ist, was nicht schön wäre, aber vorkommen könnte. Kann ich irgendwie prüfen, ob der JeeLink senden oder empfangen kann?
viele Grüße
Alexander
Hallo,
hatte nochmal alle Kontakte nachgemessen und auch überprüft, ob sie an der richtigen stelle angesteckt sind. Hat alles gepasst.
Ich kann mir nur nicht erklären warum nichts in FHEM angelegt wird, die USB Treiber sind auf dem FHEM Server (2. FHEM Server mit Windows (FHEM2FHEM)) installiert, der Arduino blinkt nicht sondern leuchtet kontinuierlich und der TX 29-IT wird laut Wiki auch unterstützt.
viele Grüße
Alexander
Datenrate eingestellt?
--- Mobil erstellt daher kurz gehalten --
Die Definition des JeeLink moduls ist falsch (com3@9600)
Der Sketch arbeitet mit 57600 baud
Hallo zusammen,
habe erst einmal auf com3@57600 umgestellt.
Hiernach dann mit
set myJeeLink raw 868295fdie Datenrate festgelegt. Dann die Batterien nochmal aus dem TX 29-IT herausgenommen und neu eingelegt, ein Device wird mir immer noch nicht angelegt.
ZitatDie Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5 kHz -Schritten eingestellt werden.
Ist es egal, was ich in diesem Bereich eingestellt habe oder ist das abhängig vom verwendeten Sensor?
viele Grüße
Alexander
siehst du etwas im log?
hast du das ignore_battery flag beim LaCrossePairForSec kommando gesetzt? sonst werden nur sensoren angelegt die das new battery flag mit senden. das passiert aber nicht wenn die batterie nur kurz raus genommen wird.
gruss
andre
So?
set JeeLink LaCrossePairForSec 60 ignore_battery
ja.
und ins log schauen.
gruss
andre
Dein jeelink steht auf opened .. muss der nicht auf initialisiert stehen?
(http://tapatalk.imageshack.com/v2/15/01/18/4e48f2d31e13c9eb099022931884b94e.jpg)
Hier der Auszug aus dem log:
Zitat2015.01.18 11:31:53 5: Cmd: >2015.01.18 11:28:33 5: Cmd: >set JeeLink LaCrossePairForSec 60 ignore_battery< 2015.01.18 11:28:33 5: Triggering JeeLink (1 changes) 2015.01.18 11:28:33 5: Notify loop for JeeLink LaCrossePairForSec 60 ignore_battery 2015.01.18 11:28:33 4: eventTypes: JeeLink JeeLink LaCrossePairForSec 60 ignore_battery -> LaCrossePairForSec .* ignore_battery<
2015.01.18 11:31:53 4: 4726:FHEMWEB:172.16.0.30:58972: /fhem&cmd=2015.01.18+11%3A28%3A33+5%3A+Cmd%3A+%3Eset+JeeLink+LaCrossePairForSec+60+ignore_battery%3C+2015.01.18+11%3A28%3A33+5%3A+Triggering+JeeLink+%281+changes%29+2015.01.18+11%3A28%3A33+5%3A+Notify+loop+for+JeeLink+LaCrossePairForSec+60+ignore_battery+2015.01.18+11%3A28%3A33+4%3A+eventTypes%3A+JeeLink+JeeLink+LaCrossePairForSec+60+ignore_battery+-%3E+LaCrossePairForSec+.*+ignore_battery / RL:1066 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
ich sehe gerade da steht etwas von dummy und diretio.
schau dir mal das hier an: http://forum.fhem.de/index.php/topic,19329.msg246982.html#msg246982 (http://forum.fhem.de/index.php/topic,19329.msg246982.html#msg246982)
gruss
andre
Zitat von: avg123-de am 18 Januar 2015, 11:18:54
Hiernach dann mitset myJeeLink raw 868295fdie Datenrate festgelegt.
Mit 868295f hast Du keine Datenrate sondern die Frequenz festgelegt und das ist für einen TX29 nicht erforderlich.
Du solltest mal den JeeLink-Clone an einen Rechner hängen und mit einem Terminalprogramm schauen, was der denn sendet.
Der Sketch muss mit den im Header unveränderten Standardeinstellungen eine TX29 empfangen und auf der Seriellen Schnittstelle Daten, die mit "OK 9" beginnen senden.
Bevor Du Dich in FHEM abmühst, sollte erst mal sicher sein, dass Dein clone funktionert und Daten ampfängt.
Zitat von: HCS am 18 Januar 2015, 11:47:19
Du solltest mal den JeeLink-Clone an einen Rechner hängen und mit einem Terminalprogramm schauen, was der denn sendet.
Wie genau kann ich das prüfen? Sorry für die Frage aber das ist mein erster USB-Dongle in FHEM.
@Andre: Ich hatte mir das mal angeschaut und auch die Änderungen aus dem Thread mal eingefügt, hatte jedoch keine Auswirkung gehabt. Ich glaube ich probiere es jetzt erst mal in dem Windows-FHEM zum laufen zu bekommen und wenn das läuft dann über FHEM2FHEM auf den Debian packen.
viele Grüße
Alexander
Hallo.
Mein TFA Lacross Sensor sendet leider nur sehr sporadisch Daten. Ungefähr alle 10 Minuten...Mein zweiter sendet ungefährt alle 30 Sekunden. An was liegt das???
Sendet immer noch nur alle paar Minuten. Hier mal die Fotos:
(http://www.bilder-upload.eu/thumb/c7c351-1422468178.jpg) (http://www.bilder-upload.eu/show.php?file=c7c351-1422468178.jpg)
2015-01-28_18:31:09 Thermo_Kueche temperature: 22.4
2015-01-28_18:31:09 Thermo_Kueche humidity: 63
2015-01-28_18:31:09 Thermo_Kueche T: 22.4 H: 63
2015-01-28_18:31:09 Thermo_Kueche battery: ok
2015-01-28_18:32:59 Thermo_Kueche temperature: 22.4
2015-01-28_18:32:59 Thermo_Kueche humidity: 63
2015-01-28_18:32:59 Thermo_Kueche battery: ok
2015-01-28_18:41:04 Thermo_Kueche temperature: 22.2
2015-01-28_18:41:04 Thermo_Kueche humidity: 63
2015-01-28_18:41:04 Thermo_Kueche T: 22.2 H: 63
2015-01-28_18:41:04 Thermo_Kueche battery: ok
2015-01-28_18:50:09 Thermo_Kueche temperature: 22
2015-01-28_18:50:09 Thermo_Kueche humidity: 63
2015-01-28_18:50:09 Thermo_Kueche T: 22 H: 63
2015-01-28_18:50:09 Thermo_Kueche battery: ok
2015-01-28_18:54:19 Thermo_Kueche temperature: 22
2015-01-28_18:54:19 Thermo_Kueche humidity: 63
2015-01-28_18:54:19 Thermo_Kueche battery: ok
2015-01-28_18:56:09 Thermo_Kueche temperature: 22
2015-01-28_18:56:09 Thermo_Kueche humidity: 63
2015-01-28_18:56:09 Thermo_Kueche battery: ok
2015-01-28_18:56:59 Thermo_Kueche temperature: 22
2015-01-28_18:56:59 Thermo_Kueche humidity: 64
2015-01-28_18:56:59 Thermo_Kueche T: 22 H: 64
2015-01-28_18:56:59 Thermo_Kueche battery: ok
Gib doch mal bitte
Zitatlist Thermo_Kueche
ein und poste das mal.
Internals:
DEF 14
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2015-01-28 19:16:04
MSGCNT 218
NAME Thermo_Kueche
NR 164
STATE T: 21.8 H: 63
TYPE LaCrosse
addr 14
battery_new 0
corr1 0
corr2 0
myJeeLink_MSGCNT 218
myJeeLink_RAWMSG OK 9 20 1 4 194 63
myJeeLink_TIME 2015-01-28 19:16:04
previousH 63
previousT 21.8
Readings:
2015-01-28 19:16:04 battery ok
2015-01-28 19:16:04 humidity 63
2015-01-28 19:07:14 state T: 21.8 H: 63
2015-01-28 19:16:04 temperature 21.8
Attributes:
IODev myJeeLink
icon scene_bath
room Temperaturen
Ich verwende die 30.3155 Sensoren. Geflasht habe ich ihn nach http://www.meintechblog.de/2015/01/fhem-mit-jeelink-luftfeuchte-und-temperatur-zum-low-cost-tarif-messen/ (http://www.meintechblog.de/2015/01/fhem-mit-jeelink-luftfeuchte-und-temperatur-zum-low-cost-tarif-messen/)
Kann es vielleicht an der Datenrate liegen? Ich habe das Thema schon hier schon durch...allerdings kann ich die Datenrate nicht ändern bzw. keine Ahnung wie man am Sketch was macht.
Hast du dir, denn schon mal den Sketch genauer angeschaut? Welchen hast du drauf?
Jetzt gehen die Probleme los :D Wie finde ich heraus welchen ich habe und wie kann man den Sketch anschauen? Ich bin da wirklich nur nach Internet Anleitung vorgegangen... Schon mal danke für deine Hilfe :)
Schau dir das Define des Jeelinks an. 8)
Ah ok!
define myJeeLink JeeLink /dev/ttyUSB0@57600
attr myJeeLink flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr myJeeLink initCommands 0a v
attr myJeeLink room Hardware
Attributes
flashCommand
avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
deleteattr
initCommands
0a v
deleteattr
room
Hardware
Da müsste auch die Firmwareversion stehen.
so was hier:
Zitatmodel
[LaCrosseITPlusReader.10.1f @AutoToggle 30 Seconds / 868300 kHz]
2015.01.28 20:27:42 5: JeeLink/RAW: /
[
2015.01.28 20:27:42 5: JeeLink/RAW: [/LaCrosseITP
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITP/lusRea
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITPlusRea/der.10.1e @1
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1e @1/7.241
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1e @17.241 /kbps /
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1e @17.241 kbps // 868300 kHz]
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1e @17.241 kbps / 868300 kHz]/
2015.01.28 20:27:42 5: SW: 30t
2015.01.28 20:27:42 5: SW: 0a
2015.01.28 20:27:42 5: SW: v
2015.01.28 20:27:42 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1e @AutoToggle 30 Seconds / 86830
2015.01.28 20:27:42 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1e @AutoToggle 30 Seconds / 86830/0 kHz
Ist also LaCrosseITPlusReader.10.1e oder?
Ja, e, aber schau dir nochmals den Sketch genau an. Vlt. gibt es dir irgendeinen Hinweis.
Ich habe das Problem gelöst. Habe die Frequenz angepasst und nun senden Sie alle Sekunde.
ich habe eben die änderungen von bernd aus diesem thread: http://forum.fhem.de/index.php/topic,19329.msg246982.html#msg246982 (http://forum.fhem.de/index.php/topic,19329.msg246982.html#msg246982) eingecheckt um das jeelink modul auch als dummy device verwenden zu können.
gruss
andre
Hallo zusammen,
bin gerade auf diesen Thread hier gestoßen da ich bei mir eine Temp/Luftfeuchte aller Räume in FHEM einbinden möchte.
Bisher habe ich den FHEMduino mit ein paar Conrad KW9010 sensoren.
Nun bin ich auf den Jeelink gestoßen mit der Möglichkeit 868MHz Sensoren in FHEM einzubinden.
Nun zu meiner Frage:
Welches sind die günstigsten Sensoren?
Gibt es schon Erfahrungen mit den TFA Dostmann 30.3198 diese sind stylisch und echt günstig, leider habe ich keine Infos darüber gefunden.
Vielleicht hat die ja jemand von euch schon probiert oder ist gerade dabei oder es kann mir jemand einen Tip für ebensogünstige Sensoren machen.
Danke schonmal im Voraus.
Grüße,a
Dominik
Hallo,
Das mit den TFA Dostmann 30.3198 würde mich auch interessieren. Ich war auf der Suche nach TX29dth-it sensoren. Diese scheinen aber vergriffen zu sein. Mindestens habe ich keinen seriösen shop gefunden, der diese Dinger auf Lager hat. Deshalb schau ich mich nach alternativen um.
Weiss jemand, ob der Sketch auch mit dem JeeLink 433 funktioniert und man dann z.B. TX70DTH sensoren einbinden könnte?
Danke für Hinweise
Marco
Hallo,
ich kämpfe schon den ganzen Tag daran einen TFA 30.3155.WD mit einem Jeelink-Clone ans laufen zu bekommen.
habe erst hier auf den letzten Seiten gelesen das es wohl auch andere gibt die Probleme haben diesen Sensor zum senden zu bringen bzw. ihn in FHEM auszulesen.
Damit ich nicht alles kopieren muss würde ich einfach gerne hier einen Link zu meinem Beitrag in der Rubrik-Anfängerfragen hinterlassen und hoffe das mir jemand helfen kann.
http://forum.fhem.de/index.php/topic,33659.0.html (http://forum.fhem.de/index.php/topic,33659.0.html)
Vielen Dank.
Ich verliere langsam den Mut, weil es einfach nicht klappen will und ich den ganzen Tag am experimentieren bin.
Grüße
Mahlzeit,
habe mir einen Jeelink Clone mit CH340 gebastelt und die Sensoren 30.3155.WD/Technoline TX 29 DTH-IT am Laufen!
Nach dem alles lief dachte ich, baust Du Nr.2 mit einem FTDI Chip und hab die gleiche FW plus Einstellungen geflasht!
[LaCrosseITPlusReader.10.1e @AutoToggle 30 Seconds / 868325 kHz] und AFC ist noch auf Default -> 0xC49f
Egal was ich flashe, AFC auf 481 oder per RAW konfiguriere -> Technoline TX 29 DTH-IT wird sofort erkannt, aber vom 30.3155.WD empfange ich nichts.
Jemand noch einen Tip?
Gruss Lalle
Zitat von: lalle70 am 20 Februar 2015, 12:25:45
Jemand noch einen Tip?
Gruss Lalle
Teste mal AFC: 0xC481
Und die Frequenz auf: 868340
Ich habe auch hier geändert: RFM12::DataRates DATA_RATE = RFM12::DataRate
9579; (ob das notwendig war, weiß ich nicht)
Viel Glück.
Ich habe auch lange daran experimentiert.
Grüße
PS: am Chip kann es doch eigentlich nicht liegen, oder??? (bin da nicht so bewandert, ist ne reine Vermutung)
Irre! ;D
Per set myJeeLink raw 868340f umgestellt und schwupps wird der 30.3155WD erkannt.
Ich bin zwar der Meinung diese Frequenz bereit einmal getestet zu haben !? aber egal! Läuft........
Thx Knallfrosch!
Cheers Lalle
Zitat von: lalle70 am 20 Februar 2015, 13:21:09
Per set myJeeLink raw 868340f umgestellt und schwupps wird der 30.3155WD erkannt.
Klar das geht auch.
Nachdem ich aber sicher war das es funktioniert habe ich alles geflasht.
Damit ist die Einstellung permanent.
Schön das es geklappt hat.
Grüße
Habe es endlich raus gefunden wie mann bei dem Jeelink die Datenrate einstellt.
Ich habe es sehr schwierig raus gefunden.
Auch hier ist es nicht zu finden:
http://www.fhemwiki.de/wiki/JeeLink
Vielleicht kann jemand das da auflisten mit ein bisschen mehr Info wie jetzt? Ich glaube das ist sehr hilfreich@!
Mit diese Kommando versetzt mann dem Jeelink nach 9.579 kbit/s:
Zitatattr myJeeLink initCommands 1r v
Zitat
Zu empfehlen ist, es in das initCommands Attribut des JeeLink Device reinzuschreiben. Sonst ist es nach einem Neustart nicht mehr gesetzt.
Wenn Du nur EMT7110 hast, dann geht auch
Code: [Auswählen]
attr myJeeLink initCommands 1r v
Um den JeeLink auf 9.579 festzusetzen.
Wenn weitere Sensoren wie z.B. TX29DTH im Spiel sind, dann
Code: [Auswählen]
attr myJeeLink initCommands 30t v
was dazu führt, dass der JeeLink alle 30 Sekunden die datenrate wechselt, um sowohl 9.579 kbit/s als auch 17.241 kbit/s Sender zu empfangen.
ZitatDie TFA laufen so am besteb: initCommands
30t 0a 868280f v
Vielleicht kann man es ja kurz im eigentlich Blog ergänzen.
Gruß Sebastian
Hallo,
habe jetzt alles durchgelesen! WOW
Danke für die hervorragende Arbeit die ihr hier hereingesteckt habt!
Hier mal ein Link für günstige TX29DTH-IT in grau (10,13 Euro plus Versand)
http://www.top-elektronikwelt.de/Technoline-TX29DTH-IT-Grau-p689296.html?refID=99&gclid=CKixndql9MMCFcXItAodtmkAbg
(http://www.top-elektronikwelt.de/Technoline-TX29DTH-IT-Grau-p689296.html?refID=99&gclid=CKixndql9MMCFcXItAodtmkAbg)
Oder hier die Technoline-TX-29-IT in weiss:
http://www.top-elektronikwelt.de/Technoline-TX-29-IT-Sender-Weiss-p515492.html
(http://www.top-elektronikwelt.de/Technoline-TX-29-IT-Sender-Weiss-p515492.html)
Ist es richtig, dass die Sensoren alle 3-4sec senden?
Ist dies bei 10 oder mehr Sensoren nicht ziemlich viel Funkfeuer?
Kann man dies auf 3-4min umstellen?
Gruß
Ralf
@pnewman,
Ja, die senden alle 4 Sekunden. Vorteil: Wenn mal ein Datenpaket verloren geht, ist das nicht so schlimm.
Bei mir steht ein TX 29 DT-H 2 Stockwerke tiefer im Keller, da kommt alle paar Minuten mal ein Signal hoch.
Man kann in Fhem alle paar Minuten ein Paket wegschreiben als Log, damit es nicht so vollgemüllt wird.
Ich kenne einen Blog-Leser, der hat 20 Sensoren produktiv im Einsatz:
http://blog.moneybag.de/fhem-lacrosse-tempertursensoren-und-jeelink-clone-ausgereizt/
5-10 Sensoren sind normal.
LG
/robin
@robin
Die Lieferzeit habe ich gesehen.
Bei anderen hatte ich nur gelesen: "derzeit nicht lieferbar"
Und dies schon seid Monaten.
Hast du LaCrosse im Einsatz?
Wenn ja wie viele?
Gruß
Ralf
6 Stück,
TX 25 IT ist jetzt dazu gekommen, siehe Blog.
Tolle Sache von den Jungs hier vom Forum.
LG
/robin
Hi Billy,
ich hab dummerweise 4x TX37IT mit der ID h20 geliefert bekommen. Hab die Sensoren mit TX29IT verwechselt.
Gibt es Jemand, der mit mir 3 tauschen kann(will)? :-\
Meine Sensoren sind nagelneu. ;)
Porto (schwerer Brief) übernehme ich.
Grüße ralphi
Bei mir kommen heute 7tx29dthit und 4 tx29it
Gesendet von meinem HTC One mit Tapatalk
Hi domii666,
ZitatBei mir kommen heute 7tx29dthit und 4 tx29it
Ist das ein Angebot?
Einen von den 3en konnte ich heute, hier im Forum schon tauschen. ;D
Wenn du auch einen mit mir tauscht, hätte ich nur noch 2 doppelte ID's.
Meine Sensoren TX37IT sind auch
nagelneu. Lediglich ein Funktionstest.
(Rück-)Porto würde ich zahlen.
Hilfst du mir? ::)Grüße aus LA
ralphi
Die tx29 Sensoren andern beim erneuten Einlegen der Batterie die ID. Ist das bei den tx37 nicht so?
Gruß,
Gero
kann mir jemand kurz sagen wie ich einen neuen Sensor hinzufüge? Die Anleitung von Robin finde ich gerade nicht, sein Blog ist down.
Gruß Domi
set myJeeLink LaCrossePairForSec 60 "Enter"
und dann die Batterie in den Sensor einlegen.
damit sollte es klappen.
Hi gero,
ZitatDie tx29 Sensoren andern beim erneuten Einlegen der Batterie die ID. Ist das bei den tx37 nicht so?
Die TX37IT haben eine feste ID vom Werk.
D.h. Vorteil:
Beim wechseln der Batterie bleibt die Zuordnung im Prog. gleich und muss nicht geändert werden. :D
Das Problem ist nur, wenn man mehrere mit der selben ID (aus der selben Charge) hat, wie ich (ID h20). :-\
Willst du tauschen? - sind
neu
Tut mir leid. Ich brauche die DTH Variante, da ich die Luftfeuchtigkeit messen muss. Außerdem sind meine Sensoren im Einsatz und ich kann mir keine Ausfälle durch andere Sensoren erlauben. Ich habe noch genügend Baustellen.
Aber ich kann mir irgendwie nicht vorstellen, dass sich die ID nicht andern lässt. Kein Hersteller würde die damit verbundenen Probleme in Kauf nehmen.
Gruß,
Gero
14 TX 29 DT-H Sensoren, alle Achtung :-)
Bei Amazon sind die gerade bei einer Lieferzeit von 2-3 wieder zu haben.
Ein Blog-Leser hat 20 Stück am Laufen: http://blog.moneybag.de/fhem-lacrosse-tempertursensoren-und-jeelink-clone-ausgereizt/
LG
/robin
Hallo,
ich habe mal an der von mir angegebenen Adresse 10x TX29DTH-IT bestellt.
Mal schauen wie lange es dauert.
Und Bauteile für den Jeelink-Clone aus der Bucht. (Auf Robins Blog ist es ja alles sehr schön beschrieben)
Da habe ich jede menge Zeit diese zusammen zu löten.
Gruß
Ralf
Bei mir sind heute 10x TX 29 DTH-IT eingetroffen (vom Händler Technikdirekt.de). Laut deren Webseite sind sowohl DTH-IT als auch die normalen IT noch vorrätig und sofort versandfertig. Die Sensoren laufen bei mir an einem Original JeeLink einwandfrei ;)
Grüsse,
Michael
hab meine auch daher, hab zwar ewig gewartet aber direkt wieder 5 geordert, dann müsste ich alle haben.
Hallo Zusammen,
ich hab in den letzten Tag das Protokoll des Technoline TX38-IT Temp Sensors entschlüsselt. Der Sensor gehört zur WM 5012 oder WM 5412.
Er sendet auch auf 868.3 MHz mit 17.241 Kbit. Er nutzt aber ein kompakteres Datenformat wie der TX29-IT.
Anbei der neue Sketch in der Version 10.1f. An der FHEM Einbindung muss nichts geändert werden. Vielleicht kann jemand mit Schreibzugriff die neue Version ins FHME Repository einpflegen.
Gruss
Berni.
Zitat von: suppenx am 02 März 2015, 07:17:36
Er sendet auch auf 386.3 MHz mit 17.241 Kbit.
sollte das nicht 868.3 MHz heißen?
Gruß PeMue
Zitat von: suppenx am 02 März 2015, 07:17:36
Hallo Zusammen,
ich hab in den letzten Tag das Protokoll des Technoline TX38-IT Temp Sensors entschlüsselt. Der Sensor gehört zur WM 5012 oder WM 5412.
Er sendet auch auf 868.3 MHz mit 17.241 Kbit. Er nutzt aber ein kompakteres Datenformat wie der TX29-IT.
Anbei der neue Sketch in der Version 10.1f. An der FHEM Einbindung muss nichts geändert werden. Vielleicht kann jemand mit Schreibzugriff die neue Version ins FHME Repository einpflegen.
Gruss
Berni.
Ich schaue es mir mal an (geht aber erst nächste Woche) und übernehme es dann. Ich führe den Sketch bei mir in einem SVN-Repository.
Wenn OK, dann stelle ich ihn in FHEM entsprechend zur Verfügung.
Ich bin mir zwar nicht sicher, ob ich hier richtig bin, nehme es aber an.
Ich habe einen Jeelink und einige Sensoren für Temperatur im Betrieb (TX29DTH-IT und TX25-IT). Das funktioniert bestens!
Ich habe aber auch noch eine Wetterstation von TechnoLine (http://www.amazon.de/Technoline-WD-9535-WetterDirekt-weiß-silber/dp/B002Q9YF86/ref=sr_1_9?s=garden&ie=UTF8&qid=1425465348&sr=1-9 (http://www.amazon.de/Technoline-WD-9535-WetterDirekt-wei%C3%9F-silber/dp/B002Q9YF86/ref=sr_1_9?s=garden&ie=UTF8&qid=1425465348&sr=1-9)).
Und da ich die Temperatur dieses Empfängers für die Außentemperatur auch empfangen kann, habe ich ihn in FHEM eingebunden. Allerdings scheint es in meiner Umgebung noch einen Sender zu geben, der die gleiche Adresse besitzt. Die Temperaturangaben im Logfile springen oft hin und her, was aber nur in FHEM zu sehen ist. Auf der Wetterstation bleiben die Werte stabil!
Und der Sensor ist im Schatten auf der Nordseite angebracht!
Hier mal ein Auszug aus der Log:
2015-03-03_17:13:36 Aussentemperatur temperature: 11.4
2015-03-03_17:13:36 Aussentemperatur T: 11.4
2015-03-03_17:14:07 Aussentemperatur temperature: 11.9
2015-03-03_17:14:07 Aussentemperatur T: 11.9
2015-03-03_17:15:01 Aussentemperatur temperature: 11.8
2015-03-03_17:15:01 Aussentemperatur T: 11.8
2015-03-03_17:17:36 Aussentemperatur temperature: 11.3
2015-03-03_17:17:36 Aussentemperatur T: 11.3
2015-03-03_17:18:07 Aussentemperatur temperature: 11.7
2015-03-03_17:18:07 Aussentemperatur T: 11.7
2015-03-03_17:18:36 Aussentemperatur temperature: 11.3
2015-03-03_17:18:36 Aussentemperatur T: 11.3
2015-03-03_17:19:07 Aussentemperatur temperature: 11.7
2015-03-03_17:19:07 Aussentemperatur T: 11.7
2015-03-03_17:19:36 Aussentemperatur temperature: 11.3
2015-03-03_17:19:36 Aussentemperatur T: 11.3
2015-03-03_17:21:05 Aussentemperatur temperature: 11.7
2015-03-03_17:21:05 Aussentemperatur T: 11.7
2015-03-03_17:21:36 Aussentemperatur temperature: 11.3
2015-03-03_17:21:36 Aussentemperatur T: 11.3
2015-03-03_17:26:22 Aussentemperatur temperature: 11.7
2015-03-03_17:26:22 Aussentemperatur T: 11.7
2015-03-03_17:26:31 Aussentemperatur temperature: 11.3
2015-03-03_17:26:31 Aussentemperatur T: 11.3
2015-03-03_17:27:21 Aussentemperatur temperature: 11.7
2015-03-03_17:27:21 Aussentemperatur T: 11.7
2015-03-03_17:27:31 Aussentemperatur temperature: 11.3
2015-03-03_17:27:31 Aussentemperatur T: 11.3
2015-03-03_17:27:51 Aussentemperatur temperature: 11.4
2015-03-03_17:27:51 Aussentemperatur T: 11.4
2015-03-03_17:28:03 Aussentemperatur temperature: 11.7
2015-03-03_17:28:03 Aussentemperatur T: 11.7
2015-03-03_17:28:36 Aussentemperatur temperature: 11.4
2015-03-03_17:28:36 Aussentemperatur T: 11.4
2015-03-03_17:30:10 Aussentemperatur temperature: 11.7
2015-03-03_17:30:10 Aussentemperatur T: 11.7
2015-03-03_17:30:46 Aussentemperatur temperature: 11.4
2015-03-03_17:30:46 Aussentemperatur T: 11.4
2015-03-03_17:34:15 Aussentemperatur temperature: 11.7
Das GPLOT habe ich auch mal angehängt.
Hier meine Definition:
Internals
CHANGED
DEF 1D
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2015-03-04 11:26:51
MSGCNT 4878
NAME Aussentemperatur
NR 128
STATE T: 8
TYPE LaCrosse
addr 1D
battery_new 0
corr1 0
corr2 0
myJeeLink_MSGCNT 4879
myJeeLink_RAWMSG OK 9 29 1 4 56 106
myJeeLink_TIME 2015-03-04 11:26:51
previousH 106
previousT 8
Wie bekomme ich nun diesen doppelten Empfang weg?
Wenn es sich wirlich um die gleich ID handelt ..
Batterie raus ... Kurz warten ... Batterie wieder rein ...
Dann hast du eine neue ID in deinem Sender und kannst sie in FHEM eintragen.
Ansonsten springen die Sensoren ganz gerne ... Machen meine auch.
Hier im Forum gabs eine Anleitung um das mit change-on-.. ruhig zu kriegen.
HBe den Link nur unterwegs leider nicht griffbereit.
Für mich sehen die Temperatursprünge auch nicht unbedingt nach 2 Sendern aus.
Such mal in der FHEM command reference nach
event-aggregator
Bei mir sieht das zur Zeit wie folgt aus:
event-aggregator (temperature|humidity):600:linear:mean
Gruß,
Gero
Ich hab jetzt mittlerweile 8 29dth und 4 29it im Einsatz und lauft super
Gesendet von meinem HTC One mit Tapatalk
auch 11 St. TFA30.3155.WD funktionieren zu meiner Zufriedenheit
Wobei man beim anlernen dann schon etwas Geduld haben muss, da die Sensoren nicht mehr so schnell "autocreatet" werden.
Zitat von: suppenx am 02 März 2015, 07:17:36
Anbei der neue Sketch in der Version 10.1f. An der FHEM Einbindung muss nichts geändert werden. Vielleicht kann jemand mit Schreibzugriff die neue Version ins FHME Repository einpflegen.
Habe es mir angeschaut, super. Vielen Dank dafür. Ich pflege es in die aktuelle Sketch-Version ein und stelle bis zum WE die neue Version zur Verfügung.
Zitat von: suppenx am 02 März 2015, 07:17:36
ich hab in den letzten Tag das Protokoll des Technoline TX38-IT Temp Sensors entschlüsselt. Der Sensor gehört zur WM 5012 oder WM 5412.
Er sendet auch auf 868.3 MHz mit 17.241 Kbit. Er nutzt aber ein kompakteres Datenformat wie der TX29-IT.
Ich habe gerade die Version 10.1h eingecheckt. Vielen Dank für das Ermitteln des Protokolls.
Zu finden in contrib/arduino und flashbar per JeeLink flash
Sollte morgen dann mit dem Update kommen.
der 8,70Euro teure Bodenfeuchte Sensor Opus XT300 soll wohl auch das LaCrosse Protokoll (sendet Temperatur und Humidity), allerdings auf 433Mhz. Hat jemand schon mal versucht diesen zu entschlüsseln? Ein RFXTRX433 soll diesen auf jedenfall unterstützen.
Die ID´s werden leider über Jumper fest eingestellt und es können nur maximal 3 ID´s gejumpert werden.
https://www.plantcaretools.com/de/onlineshop/drahtloser-bodenfeuchte-sensor-detail
Zitat von: HCS am 13 März 2015, 18:28:10
Ich habe gerade die Version 10.1h eingecheckt. Vielen Dank für das Ermitteln des Protokolls.
Zu finden in contrib/arduino und flashbar per JeeLink flash
Sollte morgen dann mit dem Update kommen.
Reicht für die Aufnahme des Sensors
TX38-IT ins fhemwiki.de/wiki/JeeLink ein schlichter Eintrag in die Sensortabelle,
oder müssen noch irgendwelche Besonderheiten/Einstellungen erwähnt werden?
d.h. im Klartext läuft ein TX38-IT parallel mit z.B. einem TX29-IT ohne weitere Einstellungen vornehmen zu müssen? ( Version 10.1h geflasht)
Ich würde dann die entsprechenden Änderungen im WIKI vornehmen.
Billy
Hab leider Probleme mittlerweile, meine logs schreiben teilweise nic mehr. Kann es sein dass der pi überlastet ist?
Gesendet von meinem HTC One mit Tapatalk
Das muss nicht sein. Ich habe wt470 Sensoren (Temp. und Luftfeuchte) die ebensfalls erkannt werden. Aber wenn die Luftfeuchte über 95% steigt erfolgt kein Eintrag mehr. Genau so bei einem zu niedrigen Wert. Sobald der Meßbereich wieder stimmt ist alles i.O.
Gesendet von meinem HUAWEI U9508 mit Tapatalk
Zitat von: Billy am 14 März 2015, 10:03:44
Reicht für die Aufnahme des Sensors TX38-IT ins fhemwiki.de/wiki/JeeLink ein schlichter Eintrag in die Sensortabelle,
oder müssen noch irgendwelche Besonderheiten/Einstellungen erwähnt werden?
Der funktioniert mit der 10.1h ohne weiter Maßnahmen.
Zitat von: Maxel am 14 März 2015, 12:17:37
Das muss nicht sein. Ich habe wt470 Sensoren (Temp. und Luftfeuchte) die ebensfalls erkannt werden. Aber wenn die Luftfeuchte über 95% steigt erfolgt kein Eintrag mehr. Genau so bei einem zu niedrigen Wert. Sobald der Meßbereich wieder stimmt ist alles i.O.
Gesendet von meinem HUAWEI U9508 mit Tapatalk
Nach nem Neustart des pi ist alles weg.
Gesendet von meinem HTC One mit Tapatalk
Zitat von: Maxel am 14 März 2015, 12:17:37
Das muss nicht sein. Ich habe wt470 Sensoren (Temp. und Luftfeuchte) die ebensfalls erkannt werden. Aber wenn die Luftfeuchte über 95% steigt erfolgt kein Eintrag mehr. Genau so bei einem zu niedrigen Wert. Sobald der Meßbereich wieder stimmt ist alles i.O.
Gesendet von meinem HUAWEI U9508 mit Tapatalk
Nach nem Neustart des pi ist alles wieder in Ordnung
Gesendet von meinem HTC One mit Tapatalk
Mhm , hab das Problem alle 2 Tage
Gesendet von meinem HTC One mit Tapatalk
hallo !!
@domi666
ich hatte gestern auch das Problem, das nichts geschrieben wurde und mir sogar das config. file abgeschossen wurde. devices wurden nicht wirklich erkannt oder meine Steckdosen nur noch mit ??? im Status zu sehen waren.
Ich hatte an meinem raspi b+ zwei cul 433/868 von busware und den neuen jeelink inkl. netzwerkkabel, dass hat der raspi nicht gepackt. mit einem 2A netzteil.
habe dann gestern ein usbhub mit netzteil angesteckt und alle cul und jeelink adaper auf hub gesetzt.
seit dem läuft es viel besser und auch keine Probleme im Moment.
habe jetzt sogar kontakt mit den geräten meines Nachbarn 8) ;D, was vorher nicht so war.
also stromprobleme am raspi lösen
Gruß Werner
Hallo zusammen
Ich habe seit wenigen Tagen einen Jeelink mit 2 Sensoren (siehe Signatur im Einsatz). So weit funktioniert alles super. Was mir jedoch aufgefallen ist. Ich habe sehe Meldungen folgender Art im Log:
2015.03.19 22:03:38 3: LaCrosse: Unknown device 3D, please define it
2015.03.19 23:32:08 3: LaCrosse: Unknown device 32, please define it
2015.03.20 01:26:17 3: LaCrosse: Unknown device 1D, please define it
2015.03.20 04:53:45 3: LaCrosse: Unknown device 04, please define it
2015.03.20 07:29:51 3: LaCrosse: Unknown device 3A, please define it
2015.03.20 11:17:55 3: LaCrosse: Unknown device 20, please define it
2015.03.20 23:12:14 3: LaCrosse: Unknown device 0C, please define it
Was könnte dies sein? Könnten das irgendwelche anderen Geräte, bzw Sensoren sein? Von Nachbarn? Oder etwas von mir ? Babyphone, Dect Telefon? Wie finde ich mehr darüber raus? Was auch speziell ist...diese Meldung ist pro Device Id nur 1x erschienen bis jetzt.
Gruss
Alen
Hallo alen,
ja, der Jeelink- (clone) hat noch 7 verschiedene Sensoren entdeckt.
Ist bei mir auch so. Du kannst die ja mal definieren um zu schauen wo die möglicherweise sind. (keller, außen, Wohnung usw.)
LG
/robin
wie kann ich testen, welche Sensoren gerade aktuell noch vom Jeelink erkannt werden ? Gibt es eine Übersicht? Oder kann man bewusst eine Suche nach Sensoren anstossen?
Oder ist das Log das einzige Hilfsmittel das mir sagt: "Da gibt es übrigens noch Sensoren, die ich empfange".
Hallo Alan,
ich würde ad hoc sagen, ja es ist das Log. Eine Übersicht wäre schön, man bräuchte nur einen Filter über das Log laufen lassen. Keine Ahnung ob das geht.
Robin
Ok, das log filtern ist ja kein Problem. Aber meine Frage war eher ob es keinen Scan Befehl gibt in FHEM denn man anstossen kann? Der quasi die Umgebung nach Sensoren sucht, die noch nicht eingebunden sind? Oder macht das FHEM sowieso immer und es steht dann im Log wenn neue Sensoren vorhanden sind?
Gruss
ALen
Scanner gibt es nicht da die Sensoren ja nur senden und nicht empfangen ... alles was im log wird auch erkannt. Was nicht erscheint ist auch nicht vorhanden
ok, alles klar - danke!
Hallo zusammen
Ich habe eine weitere Frage an die Jeelink Spezialisten.
Verstehe ich das richtig, dass man mittels Jeelink eigentlich nur Temperatur und Luftfeuchtesensoren anbinden kann? Oder gibt es noch weitere Sensoren (Wind, Regen) die man anbinden kann? Oder Aktoren: wie z.B. Steckdosen?
Besten Dank für eures Feedback.
Gruss
Alen
Fs20 schalten sollte gehen .. (selbst nicht getestet) allerdings mit anderem Sketch .. ansonsten mal im wiki nachsehen http://www.fhemwiki.de/wiki/JeeLink
Für alles weitere hab ich diverse nanoCULs und den fhemduino ... auch recht einfach nachzubauen
@alen
PCA 301 von ELV Energiesteckdosen kann man mit einem anderen Sketch auch schalten. Habe ich auch im Einsatz.
Also, wenn du Temperaturen und diese genannte Steckdose schalten möchtest, brauchst du zwei Jeelinks mit unterschiedlichen Sketchen.
LG
/robin
Hi
ich nutze seid einiger zeit 6 TX29DTH-IT an einem Original JeeLink mit Aktuellem Sketch 10.1h .
Da der Stromverbrauch meines Servers mit den Steigenden zahl an Komponenten und Diensten immer weiter steigt, versuche ich aktuell den Stromverbrauch etwas zu senken.
Nachdem ich den JeeLink in FHEM deaktiviert habe ist die Leistungsaufnahme um satte 3W gefallen und die wakeups von ~2300/s auf 1100/s zurück gegangen.
Strom gemessen mit Kalibriertem Benning 7-1 vor meiner picoPSU
vorher 1,18A @ 12,2V
nachher 0,91A @ 12,3V
Hat einer von euch ähnliches bemerkt?
Gibt es dafür eine Lösung oder muss ich damit leben?
Das ist heftig. Mein Cubietruck braucht mit einem JeeLink, einem CUL und einer angeschlossenen 128GB SSD (auf der das rootfs liegt) nachts, wenn er die Backups durchzieht gerade mal ca. 3-4W (mit nichts kalibriertem gemessen) und im normalen Betrieb den Tag über so um die 2-3W.
Da läuft FHEM, ein lighttpd und nachts die Datensicherung für das komplette Netzwerk drauf.
Die ~10W für einen i3 mit den sonstigen Komponenten finde ich an sich sehr gut.
Mein FHEM an sich liegt auf SSD.
Für bessere Leistung und geringeren Stromverbrauch lade ich fhem beim booten in eine RAM-Disk und lasse es von da laufen.
Ich nutze häufig PLEX und auch Owncloud dafür wird etwas mehr Rechenleistung benötigt.
Aber das die 5 Lacrosse Sensoren 3W brauchen und meine 7 EC3k nochmal 2,5W.
Das ist zusammen ein drittel mehr!!
Das event-min-interval habe ich schon auf *:60 stehen.
Der Jeelink müsste für 60 Sekunden Schlafen und dann 20s wach bleiben....
Zitat von: Henno am 31 März 2015, 16:28:00Der Jeelink müsste für 60 Sekunden Schlafen und dann 20s wach bleiben....
Tut er aber nicht, der empfängt ständig und sendet auch alle 4 Sekunden an FHEM (bei einem Sensor, bei 6 noch öfter), nur wird es dann halt dort wg. event-min-interval ignoriert. Auch ignorieren braucht Rechenleistung :)
Den Vergleich hatte ich eigentlich gemacht, weil bei Dir der JeeLink alleine ungefähr so viel Leistung verbrät, wie mein komplettes System. Ich vermute mal, dass es bei Dir sehr teuer ist, wenn etwas auf dem USB-Port reinkommt und in FHEM verarbeitet wird.
Bei mir laufen übrigens 12 LaCrosse-Sensoren, zwei EMT7110 und einige LevelSender. Ich habe vom JeeLink kommend eigentlich "Dauertraffic"
Aber: die 5W sind über den Daumen gerechnet €10 im Jahr. Wenn man es schafft, es zu halbieren, hat man €5 im Jahr gespart.
Ja die paar Watt machen nicht viel aus.
Es geht eben ums Prinzip.
Zitat von: justme1968 am 23 Oktober 2013, 20:19:10
das problem ist das die sensoren beim batterie wechsel sich eine neue zufällige id suchen. und das lässt sich nicht verhindern.
gruss
andre
Gibt es inzwischen eine Möglichkeit oder ein Trick, dass beim Batteriewechsel die gespeicherten Daten fortgeführt werden können?
Gruss
Martin
das ändern der id des sensors lässt sich nicht verhindern.
um in fhem weitere änderungen zu vermeiden muss im define die id auf die neue id geändert werden.
mit einem set replaceBatteryForSec geht das halbautomatisch. um es noch einfacher zu haben kannst man das kommando z.b. in einer readingGroup auf das (rote) battery low icon legen und das ändern ist dann mit einem klick erledigt.
gruss
andre
Moin!
Hab versucht einen Jeelink Clone zu bauen...
Arduino nano mit ftdi Chip und ein RFM69CW modul.
Arduino mit dem neuesten Sketch geflasht (h) und serielle console angeworden. Also noch kein fhem benutzt.
Wollte erst einmal testen, ob es klappt und das Ding was empfängt.
-------- So sieht das aus -----------
*** LaCrosse weather station wireless receiver for IT+ sensors ***
Radio is: RFM12B
Radio setup complete. Starting to receive messages
[LaCrosseITPlusReader.10.1h (RFM12B) @17241 kbps / 868300 kHz]
--------------------------------------
Mehr kommt auch nicht.
Was ich nicht verstehe ist, warum er RFM12B anzeigt und nicht RFM69CW ?
Hab gesucht, ob ich irgendwo etwas einstellen kann... nix gefunden.
Hilfe ! :-\
vg
maik
Der sketch erkennt das radio automatisch, das muss man nicht einstellen.
Ich würde spontan drauf tippen, dass Deine Schaltung nicht richtig funktioniert.
Hast Du einen 3,3V Nano? Wenn nicht ist ein Pegelanpassung zum RFM69CW erforderlich.
Zitat von: HCS am 05 April 2015, 22:40:56
Der sketch erkennt das radio automatisch, das muss man nicht einstellen.
Ich würde spontan drauf tippen, dass Deine Schaltung nicht richtig funktioniert.
Hast Du einen 3,3V Nano? Wenn nicht ist ein Pegelanpassung zum RFM69CW erforderlich.
Ja, ist ein Nano.
Wie erkennt er das denn, um welches Modul es sich handelt?
Schaltung nicht richtig... ja, ist möglich :-)
Aktuell sieht das so aus:
Nano RFM69CW
-----------------------
D12 MIS0
D2 DIO0
D10 NSS
D13 SCK
D11 MOSI
GND(29) GND
3V3 3,3V
Danke
--Edit
Vielleicht mach ich ja auch einen Fehler beim programmieren des Arduino?
Ich habe nur die aktuelle Version aus Git gezogen, die INO Datei in die Arduino Umgebung (1.6.3) geladen, kompiliert und hochgeladen.
Da es keine richtige Erkennung gab, hab ich noch die aktuelle Jeelink-Master LIB hinzugefügt und das ganze nochmal... keine Änderung. Er erkennt mein Modul nicht.
Gibt es noch einen Schritt, den man gehen muss?
Da ist noch dieses Firmware Verzeichnis mit einer hex Datei. Wofür ist das denn gut?
---
Ich schlaf nun nochmal drüber...
Was läuft schief?
Nano ist klar. Aber ich vermute, dass es ein 5V Nano ist, und dann musst Du eine Pegelanpassung machen, Du darfst den RFM69CW nicht mit 5V auf den Signalleitungen ansteuern.
Das hat nichts mit Programmierung zu tun, der Sketch hat ja auf der Seriellen korrekt geantwortet, nur hat er das falsch angebundene radio nicht erkannt.
Zitat von: HCS am 05 April 2015, 23:33:22
Nano ist klar. Aber ich vermute, dass es ein 5V Nano ist, und dann musst Du eine Pegelanpassung machen, Du darfst den RFM69CW nicht mit 5V auf den Signalleitungen ansteuern.
Das hat nichts mit Programmierung zu tun, der Sketch hat ja auf der Seriellen korrekt geantwortet, nur hat er das falsch angebundene radio nicht erkannt.
oh.... ok.
Gibt es irgendwo einen Anschlußplan mit Pegelanpassung?
Bis jetzt hatte ich nur eine Beschreibung, die die zu verbindenden Kontakte benannt hatte. Eine Pegelanpassung war da nicht drauf.
Hoffentlich habe ich das Teil nicht zerschossen ...
---edit
so, hab das nun nach diesem muster mit Widerständen auf 3,3V gebracht... naja, eher 3,16, wenn ich messe.
http://lowpowerlab.com/wp-content/uploads/2012/12/rfm12B-arduino-moteino-atmega328_5V_connections.png
Ändert aber nichts an der NICHT-Erkennung.
----edit 2
Kaum macht Mann es richtig, klappts.
Hab noch einmal nachgelötet und nun kommen Daten... Allerdings mehr als ich dachte... Die lieben Nachbarn :-)
Mal sehen was das ist... gibt es irgendwo eine zusammenfassende Erklärung für die LACrosse Daten?
Danke!
Hallo,
ich bin im Moment etwas ratlos, ich habe mir aus einem Arduino nano mit CH340 Chip und einem RMF12B einen Jeelink Clone zusammengebaut, auf meinem Testsystem (Debian auf einem alten Notebook) wurde er sofort erkannt und als ich die Batterien in den TX29-IT eingelegt habe wurde dieser sofort erkannt und via autocreate angelegt.
Da mein Produktiv-FHEM allerdings nicht auf diesem Notebook sondern unter einer virtuellen Maschine (Debian) auf Windows Server 2008 R2 läuft, wollte ich diesem Jeelink-Clone jetzt an meinem Server anschließen und dann mit FHEM2FHEM mit dem Produktiv-FHEM (Debian) verbinden.
Ich habe hierfür allerdings erst einmal getestet, ob der Jeelink-Clone überhaupt unter dem Windows-FHEM erkannt wird, was ja die Voraussetzung dafür ist, das ich ihn mit FHEM2FHEM dann verbinden kann, was jedoch nur Teilweise zutrifft. Der State ist immer nur bei "open" und nicht bei "initialized". Den Treiber für den CH340 Chip habe ich bereits installiert und sicherheitshalber auch den FTDI-Treiber. Es ändert sich jedoch leider nichts an dem State und im Gerätemanager von Windows ist der Arduino aufgelistet, was mir sagt, dass der Treiber eigentlich richtig installiert sein muss.
viele Grüße
Alexander
Zitat von: noice am 23 März 2015, 20:29:07
Fs20 schalten sollte gehen .. (selbst nicht getestet) allerdings mit anderem Sketch .. ansonsten mal im wiki nachsehen http://www.fhemwiki.de/wiki/JeeLink
Im Wiki finde ich nichts zu JeeLink und FS20 schalten und in den diversen Threads auch nichts explizites.
Kurz zu meiner Ausgangssituation: ich habe vier 30.3144.it und einen 30.3147.it über den JeeLink an FHEM angebunden, funktioniert soweit alles super. Danke an dieser Stelle an die Entwickler von FHEM und dem LaCrosse Sketch!
Jetzt würde ich gerne eine Funksteckdose über FHEM schalten. Für den einen(!) Aktor mag ich mir jetzt nicht unbedingt einen CUL zulegen müssen, deshalb wäre mein Plan gewesen, mir eine FS20 Funksteckdose zuzulegen und die mit dem JeeLink zu schalten.
Die Funksteckdose würde ich nur zweimal am Tag schalten, d.h. es wäre auch ok den JeeLink dazu kurzzeitig in einen anderen Modus zu schalten, die währenddessen verlorenen Sensorwerte wären mir egal.
Kann mir hier jemand weiterhelfen? Kann ich mit einem JeeLink parallel LaCrosse empfangen und FS20 (oder etwas anderes) schalten?
Danke für die Hilfe,
Georg
@fichtennadel: vielleicht könntest Du Dir ja auch eine/mehrere PCA301 Funksteckdosen zulegen. Die sind erstens derzeit günstiger, als die FS20, können auch noch den Stromverbrauch messen und es gibt definitv einen Sketch für den Jeelink.
Peter
Zitat von: ph1959de am 12 April 2015, 11:19:28
@fichtennadel: vielleicht könntest Du Dir ja auch eine/mehrere PCA301 Funksteckdosen zulegen. Die sind erstens derzeit günstiger, als die FS20, können auch noch den Stromverbrauch messen und es gibt definitv einen Sketch für den Jeelink.
Interessanter Hinweis, leider finde ich hier nur sich widersprechende Aussagen, zB:
Zitat von: KernSani am 02 Februar 2015, 00:33:46
[...] PCA301 und LaCrosse gleichzeitig geht nur mit zwei JeeLinks
http://forum.fhem.de/index.php/topic,11648.msg281596.html#msg281596
Zitat von: chris_z am 03 April 2015, 17:34:42
Mit
initCommands 30t v
schaltet das Jeelink alle 30sek zwischen Lacrosse und PCA hin und her.
So les ich 4 PCA301 udn einen LaCrosse Sensor problemlos seit ca nem halben Jahr aus.
http://forum.fhem.de/index.php/topic,11648.msg281596.html#msg281596
Geht das Schalten von PCA301/FS20/... und Lesen von LaCrosse mit nur
einem JeeLink?
Zitat von: fichtennadel am 12 April 2015, 11:52:12
Geht das Schalten von PCA301/FS20/... und Lesen von LaCrosse mit nur einem JeeLink?
Nein, soweit ich weiß nicht. Es geht nur entweder oder. Ich habe selber einen Jeelink Nachbau für PCA301 und einen CUNO2 für FS20.
Gruß PeMue
es geht definitiv (zur zeit) nicht. und ich vermute es wird sich niemand finden der das einbaut weil der praktische nutzen recht klein und der aufwand (vor allem auch im vergleich zu den kosten eines jeelink (klones)) sehr groß ist.
ein zweiter jeelink hat übrigens auch aus redundanzgründen vorteile. ist einer kaputt kann man den anderen auf das protokoll flashen das einem wichtiger ist.
Hallo,
ist vielleicht noch jemand, bei dem der Jeelink einfach aussteigt?
Log:
/dev/ttyUSB0 disconnected, waiting to reappear (JeeLink)
Dann passiert gar nichts mehr.
Erst nach Raspineustart geht es wieder.
gruß
Mike
Zitat von: justme1968 am 12 April 2015, 14:37:43
es geht definitiv (zur zeit) nicht. und ich vermute es wird sich niemand finden der das einbaut weil der praktische nutzen recht klein und der aufwand (vor allem auch im vergleich zu den kosten eines jeelink (klones)) sehr groß ist.
Danke für die klaren Worte.
Zitat von: justme1968 am 12 April 2015, 14:37:43
ein zweiter jeelink hat übrigens auch aus redundanzgründen vorteile. ist einer kaputt kann man den anderen auf das protokoll flashen das einem wichtiger ist.
Ich komm aus der Software-Ecke, da tendiere ich eher dazu Aufgaben in der Software und nicht mit zusätzlicher Hardware zu lösen ;)
Dein Argument mit der Redundanz ist natürlich valide, für mich stellte sich nur die Frage, ob ich in einen CUL433 investiere, mit dem ich IT schalten kann oder nicht vielleicht doch mit dem vorhandenen JeeLink was anderes (FS20/PCA301) schalten kann. So wie's aussieht, werde ich jetzt den CUL nehmen, damit kann ich dann vielleicht auch noch meine Markise ansteuern (ohne dass mein RasPi wie ein Igel aussieht).
Zitat von: Killermike007 am 12 April 2015, 14:57:32
Hallo,
ist vielleicht noch jemand, bei dem der Jeelink einfach aussteigt?
Log:
/dev/ttyUSB0 disconnected, waiting to reappear (JeeLink)
Dann passiert gar nichts mehr.
Erst nach Raspineustart geht es wieder.
gruß
Mike
Hallo
Überprüfe mal deine Stromversorgung.
Ich hatte mit einem CUN ein ähnliches Problem (nach Reboot hat er den CUN nicht mehr gefunden)
Nach Tausch vom Netzteil (Besser mit mehr Leistung) war es gelöst
weil ich auch aus der software ecke komme weiß ich das nichts richtig gemachte hardware redundanz schlagen kann :)
Zitat von: AxelSchweiss am 12 April 2015, 19:05:34
Hallo
Überprüfe mal deine Stromversorgung.
Ich hatte mit einem CUN ein ähnliches Problem (nach Reboot hat er den CUN nicht mehr gefunden)
Nach Tausch vom Netzteil (Besser mit mehr Leistung) war es gelöst
Hallo
Jeelink, zusammen mit CUL433, CUL868 und BT-Stickhängt, an einem 8er USB-Hub mit einem 2,6 A Netzteil.
Das sollte doch ausreichen, oder spricht dieser Fehler für eine Stromunterversorgung?
Das sagt so erst mal noch gar nix :-(
Wichtig ist das das Netzteil den Strom sauber unter Last liefert und keine Einbrüche oder ein zu hohen Ripple hat.
Habe auch schon Billig-Netzteile gehabt mit angeblich 2A ... als ich es dann unter Last gemessen habe waren davon nur noch 1,2A bei 4,3 Volt übrig.
Versorg den Pi doch mal direkt über die GPIO mit Strom. Möglichst ein Labornetzteil oder eins das saubere 5 Volt bringt.
Lies dir mal das zum Thema Stromversorgung und PI durch
http://www.forum-raspberrypi.de/Thread-info-stromversorgung-raspberry-pi (http://www.forum-raspberrypi.de/Thread-info-stromversorgung-raspberry-pi)
Zitat von: Killermike007 am 12 April 2015, 14:57:32
ist vielleicht noch jemand, bei dem der Jeelink einfach aussteigt?
Hatte ich noch nie (an meinen Cubies).
Blinkt er dann noch, wenn es so weit ist?
Geht es wieder, wenn man ihn abzieht und neu aufsteckt oder wirklich erst nach einem Neustart vom raspi?
Ich tippe aber auch am ehesten auf Spannungsversorgung.
so, heute sind meine letzen 5 Tx29dth-it gekommen. habe dann 17 Stück im Einsatz, für mich vollkommen ausreichend, da ich ja HM auch noch habe an den Heizungen, später wenn alels mit HM Heizungsregler ausgestattet ist werdens warscheinlich wieder weniger TX29dth-it werden.
Netzteiltausch zeigt Wirkung.
Bisher kein Ausfall mehr. :)
Hat jem. einen "Windmesser" im Einsatz? Wenn ja welchen?
Gemeint ist wohl ein Anemometer - "Messer" sind zum Schneiden da.
Ich habe an meiner WS2800 Wetterstation auch ein Anemometer TX56IT. Allerdings wird dessen Protokoll nicht von JeeLink erkannt, auch nicht das Protokoll der WS2800 bei der Kommunikation mit einem PC.
Fazit: Ich werde dieses Gerät irgendwann auf einen 1-Wire-Counter umrüsten.
LG
pah
Ich habe eine WS-1600 Station mit Regen- und Windmesser. Die ist IT+. Allerdings wird das Gerät bislang vom offizielle Jeelink Sketch und dem LaCrosse Modul nicht unterstützt.
JorEl hat aber von Sketch und Modul eine Version gebaut um die WS-1600 Station auslesen zu können. Das funktioniert bei mir auch seit einiger Zeit ganz gut. Allerdings müsste die Integration in den "offiziellen" Sketch und das Modul jemand übernehmen der sich damit auskennt. Ich konnte mit viel Mühe ein Problem mit dem Adressen beheben. Perlprogrammierung auf diesem Level ist nicht meins.
Viele Grüße
Olaf
@okiberlin
Danke für die Info:
Ich nehme an es geht um http://forum.fhem.de/index.php/topic,25866.msg197825.html!
Hast du die Anpassungen von JorEl per PM bekommen oder sind die im Forum zu finden?
ZitatAllerdings wird das Gerät bislang vom offizielle Jeelink Sketch und dem LaCrosse Modul nicht unterstützt.
Vielleicht kann HCS oder justme da helfen
Gruß Billy
Zitat von: Billy am 04 Mai 2015, 11:53:10
Vielleicht kann HCS oder justme da helfen
Bezüglich dem Sketch evtl. schon.
Kann mal jemand diese Version zur Verfügung stellen, dann schaue ich es mir an.
An das Modul müsste aber justme ran...
Diese Dateien habe ich bekommen. Damit läuft es auch. Allerdings ist im LaCrosse Modul wohl ein Fehler bei der Adressberechnung drin. Ich habe mir mit einer hardcodierten Adresse geholfen. ($id Berechnung in Zeile 220)
Zitat von: okiberlin am 04 Mai 2015, 12:47:46
Diese Dateien habe ich bekommen.
OK. Ich schaue mir mal den Sketch an, ob man was "offizielles" draus machen kann.
Prima, zum Testen stehe ich gern bereit
Richtig! Ich meine ein Aneometer. Also gibt es momentan kein Angenähter welches zuverlässig mit FHEM <=> JeeLink läuft !?
Zitat von: bjoernbo am 05 Mai 2015, 17:20:13
Richtig! Ich meine ein Aneometer. Also gibt es momentan kein Angenähter welches zuverlässig mit FHEM <=> JeeLink läuft !?
Laut Oki läuft doch WS-1600 Station mit Regen- und Windmesser. ☺
Gruss Billy
ok, ich hatte es so verstanden dass es noch nicht im offiziellen Modul übernommen wurde.
@okiberlin: Muss ich mir die komplette Wetterstation anschaffen oder genügt es wenn ich mir lediglich das "Aneomter" anschaffe?
Zitat von: bjoernbo am 05 Mai 2015, 18:45:30
ok, ich hatte es so verstanden dass es noch nicht im offiziellen Modul übernommen wurde.
Wurde es auch noch nicht. Dauert noch ein klein wenig.
Theoretisch würden die Sensoren reichen. Die Wetterstation ist ja nur der Empfänger.
Das Set besteht aus TX22 (Temperatur und Feuchte mit Anschlüssen für Wind- und Regensensor), TX23 (Wind) und TX26 (Regen). Der Empfang erfolgt ja über den Jeelink. Die Station ist nur noch eine zusätzliche Anzeige.
Das muss nicht immer richtig sein. Bei der WS2800 beispielsweise sammelt das Außenthermometer die Daten vom Anemometer und Pluviometer und sendet diese dann an die Zentrale.
Das Anemometer und das Pluviometer der WS2800 sind deshalb besonders interessant, weil sie solarbetrieben sind und somit auch auf Dauer an einer unzugänglichen Position bleiben können (na, zumindest das Anemometer - das andere Teil muss einmal im Jahr gesäubert werden):
@HCS: Ist der Sketch für den Jeelink irgendwo dokumentiert ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 06 Mai 2015, 08:12:03Das muss nicht immer richtig sein. Bei der WS2800 beispielsweise sammelt das Außenthermometer die Daten vom Anemometer und Pluviometer und sendet diese dann an die Zentrale.
Schreck lass nach :-) ich musste erst mal googeln, was ein "Pluviometer" ist. Wikipedia meint, es sei ein "Niederschlagsmesser".
Das ist bei der WS 1600 auch so. Der TX22 liefert alle Daten, die beiden anderen Sensoren senden selbst nicht. Ohne TX22 geht also nichts.
Zitat von: Prof. Dr. Peter Henning am 06 Mai 2015, 08:12:03
@HCS: Ist der Sketch für den Jeelink irgendwo dokumentiert ?
Was meinst Du mit dokumentiert?
Stimmt, das hatte ich nicht klar genug geschrieben. Die TX23 (Wind) und TX26 (Regen) sind per Kabel am TX22 (Temperatur und Feuchte) angeschlossen. Nur der hat Batterien und ist der einzige Sender.
Nun ja, bei der WS2800 sind sowohl Anemometer TX56 als auch Pluviometer TX57 über Funk angeschlossen - laut Doku aber eben nicht an die Zentrale. Sie müssen wirklich erst mit dem Außenthermometer TX59 gepaart werden, dieses wird dann von der Zentrale gelesen. Und die Zentrale wird von einem PC ebenfalls per Funk abgefragt.
@HCS: Mit "dokumentiert" meine ich: "Code verfügbar, kommentiert und erläutert" ? So dass jemand anders etwas damit anfangen kann ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 06 Mai 2015, 12:24:06@HCS: Mit "dokumentiert" meine ich: "Code verfügbar, kommentiert und erläutert" ? So dass jemand anders etwas damit anfangen kann ?
Code verfügbar:hier -> http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip
Kommentiert und erläutert:Die Protokolle sind teilweise im Quellcode dokumentiert:
Beispiel:
/*
* Message Format:
*
* .- [0] -. .- [1] -. .- [2] -. .- [3] -. .- [4] -.
* | | | | | | | | | |
* SSSS.DDDD DDN_.TTTT TTTT.TTTT WHHH.HHHH CCCC.CCCC
* | | | || | | | | | | || | | |
* | | | || | | | | | | || | `--------- CRC
* | | | || | | | | | | |`-------- Humidity
* | | | || | | | | | | |
* | | | || | | | | | | `---- weak battery
* | | | || | | | | | |
* | | | || | | | | `----- Temperature T * 0.1
* | | | || | | | |
* | | | || | | `---------- Temperature T * 1
* | | | || | |
* | | | || `--------------- Temperature T * 10
* | | | | `--- new battery
* | | `---------- ID
* `---- START = 9
*
*/So dass jemand anders etwas damit anfangen kann:Wenn man C++, Arduino, RFM12/RFM69 usw. kann, dann sollte man etwas damit anfangen können
Generell: Ich implementiere aktuell in den Sketch exakt die WS 1600 (TX22). Das wird aber etwas dauern, da der TX22 in den oben angehängten Files recht "wüst" in die Hauptroutine reingepackt wurde (was die Leistung, das Protokoll zu anlaysieren, nicht schmälern soll, vielen Dank, das war tolle Arbeit) und ich das, wie alle bisher implementierten Sensoren, in eine modularisierte Form bringen werde.
In dem Sketch funktionieren z.B. die 9.579 kbps Sensoren (z.B. TX35) nicht mehr. Das bedeutet einiges an Arbeit und wird wohl 1-2 Wochen dauern.
Und dann muss auch noch an dem JeeLink und dem LaCrosse Modul etwas getan werden, oder gar ein weiteres Modul her, da ich erst mal klar sehen muss, ob es sinnvoll ist, die WS 1600 Daten im LaCrosse Modul zu handhaben oder besser sonstwo. Liest eigentlich justme1968 hier noch mit? Würde gerne mit Dir den Plan für die FHEM-Module abstimmen.
ich bin da :)
mehrere module wären zwar sauberer aber der modul spezifische teil ist im vergleich zum overhead meist winzig. ich weiss nicht ob es sich lohnt.
was ich aber auf jeden fall machen würde ist den protokoll spezifische teil für jeden sensor in eine eigene routine auslagern und nicht alles direkt in der parse routine zusammen mischen.
man könnte parse routine dann einen allgemeinen hash aus reading und werte paaren zurück liefern lassen und so alles recht generisch halten.
gruss
andre
ZitatWenn man C++, Arduino, RFM12/RFM69 usw. kann, dann sollte man etwas damit anfangen können
Sehn wir mal, was ich so drauf habe...
Ich würde tatsächlich gerne den TX56 und TX57 einbinden (und die doofe Zentrale sowie ggf. das Außenthermometer) auf den Müll werfen.
LG
pah
Moin,
eventuell lande ich jetzt etwas off-topic - muss gestehen, nicht den gesamten Thread studiert zu haben. Weil aber eingangs nach Regensensoren gefragt wurde: Ich habe mal ein WS-9004-IT (http://www.amazon.de/Technoline-WS-9004-IT-Regenmesser-gr%C3%BCn-Mehrfarbig/dp/B001ALPF1M/ref=cm_cr_pr_product_top) gewonnen. Der beiliegende Regensensor heißt TX24-IT, auf der Packung steht iT+. Mein JeeLink findet zwar meine Temperatur und Luftfeuchtesensoren, den Regensensor ignoriert er aber.
Hat einer von Euch damit schon Erfahrungen gesammelt? Hier im Forum konnte ich nichts helfendes identifizieren.
Viele Grüße
Andreas
@justme1968: habe mich nun doch entschlossen, ein eigenes modul (36_ITPlusWS.pm) zu bauen.
Das Protokoll zwischen sketch und 36_ITPlusWS.pm implementiere ich so, dass es auch für andere IT+ Stationen als die WS 1600, die der Sketch evtl. noch "lernt", funktioniert, und der 36_ITPlusWS.pm das Modul für alle LaCrosse-Wetterstationen wird.
Würdest Du schon mal vorbereitend den angehängten Patch in das 36_JeeLink übernehmen?
Das 36_ITPlusWS.pm habe ich initial (noch nicht fertig) selbst als maintainer committed.
Wenn es gut läuft, dann kann ich am nächsten WE den Sektch mit der WS 1600-Erweiterung und das fertiggestellte Modul als Beta veröffentlichen.
Zitat von: aroesler am 08 Mai 2015, 23:59:29Der beiliegende Regensensor heißt TX24-IT, auf der Packung steht iT+. Mein JeeLink findet zwar meine Temperatur und Luftfeuchtesensoren, den Regensensor ignoriert er aber.
Der TX24 überträgt mit größter Wahrscheinlichkeit ein anderes Protokoll und evtl. auch mit einer anderen data rate.
Somit kann der Sketch nichts mit anfangen.
Wenn das Protokoll bekannt ist, wäre evtl. was machbar.
@HCS: wäre es nicht besser und für die endanwender einfacher wenn das modul mit namen LaCrosse auch für die LaCrosse wetterstationen zuständig ist? wie wäre es wenn du den namen bzw das modul übernimmst? ich denke es wäre besser hier nicht zu forken.
für den jeelink patch habe ich einen wunsch/vorschlag: wir haben jetzt schon das problem das im jeelink modul die clients und match list nicht wirklich sketch spezifisch ist. das hat dann zur folge das das iodev oft nicht richtig automatisch gewählt wird wenn man mehrere jeelinks mit unterschiedlichen sketches betreibt.
kannst du bitte deinen patch so umbauen das in JeeLink_Parse clients und match list passend gesetzt wird wenn dein sketch erkannt wird. es ist schon ein bisschen vorbereitet aber noch nicht durchgezogen. ich würde das dann noch nachziehen.
gruss
andre
Zitat von: justme1968 am 10 Mai 2015, 20:39:44
wie wäre es wenn du den namen bzw das modul übernimmst?
modul übernehmen = maintainer ?
name übernehmen = ??
Zitat von: justme1968 am 10 Mai 2015, 20:39:44wir haben jetzt schon das problem das im jeelink modul die clients und match list nicht wirklich sketch spezifisch ist. das hat dann zur folge das das iodev oft nicht richtig automatisch gewählt wird wenn man mehrere jeelinks mit unterschiedlichen sketches betreibt.
kannst du bitte deinen patch so umbauen das in JeeLink_Parse clients und match list passend gesetzt wird wenn dein sketch erkannt wird. es ist schon ein bisschen vorbereitet aber noch nicht durchgezogen. ich würde das dann noch nachziehen.
Du meinst für
$dmsg =~m /LaCrosseITPlusReader/ eine eigene matchlist und nicht die matchListPCA301 gemeinsam verwenden und dann noch clients getrennt für die verschiedenen Sketches?
Könntet Du das übernehmen, wobei, wenn die WS 1600 in den LaCrosse mit rein kommt, sich an clients ja nichts ändert.
Wenn ich den LaCrosse übernehmen soll, dann baue ich es dort ein und ziehe den 36_ITPlusWS.pm zurück.
Eigentlich habe ich den gebaut, um ohne Nebeneffekte und Risiken in "deinem LaCrosse" ungestört die WS 1600 erledigen zu können.
Müssen wir aber schnell entscheiden, dass ich ihn zurückziehen kann, bevor er morgen mit dem Update mitkommt.
ich habe keinen einzigen lacrosse sensor und das modul sowieso nur weil es kein anderer gemacht hat :) wenn du es übernimmst hat das also nur vorteile für alle.
wenn es eh der gleiche sketch ist ist das mit dem auftrennen der clients und match list nicht ganz so dringend. am status quo ändert sich ja erst mal nichts. ich schaue aber das ich es einbaue sobald es geht. ich muss erst mal versuchen rauszufinden wie viele unterschiedlich sketches es inzwischen gibt.
gruss
andre
Zitat von: justme1968 am 10 Mai 2015, 21:56:33
ich habe keinen einzigen lacrosse sensor und das modul sowieso nur weil es kein anderer gemacht hat :) wenn du es übernimmst hat das also nur vorteile für alle.
OK, gekauft :)
Ich schreibe die maintainer.txt um und nehme den 36_ITPlusWS.pm wieder raus.
Zitat von: justme1968 am 10 Mai 2015, 21:56:33wenn es eh der gleiche sketch ist ist das mit dem auftrennen der clients und match list nicht ganz so dringend. am status quo ändert sich ja erst mal nichts. ich schaue aber das ich es einbaue sobald es geht. ich muss erst mal versuchen rauszufinden wie viele unterschiedlich sketches es inzwischen gibt.
Die matchListPCA301 müsste aber trotzdem erweitert werden, dass das LaCrosse Modul die "OK WS" Pakete bekommt.
ich hab die match list ergänzt.
kannst du es bitte noch kurz testen (und kurz selber reparieren :) ) das morgen im update nicht etwas falsches raus geht?
gruss
andre
Testen geht gerade nicht, sieht aber gut aus.
OK, was kann ich beitragen ?
Ich würde gerne beim Sketch anfangen und den so aufbohren, dass man ggf. auch "unbekannte" IT-Pakete empfangen und an FHEM weiterreichen kann (und damit langfristig dem Ziel der Einbindung neuer Sensoren näher kommen).
LG
pah
Zitat von: Prof. Dr. Peter Henning am 12 Mai 2015, 05:15:54
OK, was kann ich beitragen ?
Aktuell wäre es nicht sinnvoll, an dem Sketch zu ändern, da ich gerade den TX22 implementiere.
Es sein denn, es ist etwas, das ich recht einfach übernehmen kann.
Zitat von: Prof. Dr. Peter Henning am 12 Mai 2015, 05:15:54
Ich würde gerne beim Sketch anfangen und den so aufbohren, dass man ggf. auch "unbekannte" IT-Pakete empfangen und an FHEM weiterreichen kann (und damit langfristig dem Ziel der Einbindung neuer Sensoren näher kommen).
Das ist nicht ganz so einfach.
Zuerst muss die Frequenz (wobei man da recht sicher 868.300 kHz annehmen kann) und die data rate bekannt sein.
Wenn man die data rate nicht kennt, empfängt man nur Müll, der aber auch wie etwas gesendetes aussieht.
Die LaCrosse Sensoren senden mit 17.241 kbps (z.B. TX29DTH), 9.579 kbps (z.B. TX35) und der TX22 der WS 1600 sendet mit 8.842 kbps.
Im Erfinden von Protokollen und data rates sind die LaCrosse Menschen ganz groß.
Auch das sync pattern (bisher bei allen LaCrosse Sensoren, die ich habe, 0x2dd4) muss passen, könnte man also auch erst mal so annehem.
Wenn es keine Quelle gibt, die die data rate usw. benennt, dann hat man fast nur eine Chance: am Sensor oder der Station am RFM mit einem Protokoll-Analyzer den SPI Bus abhören, wie der RFM initialisiert wird. So wurden die meisten IT+ Sensoren "geknackt"
Erst wenn man so weit gekommen ist, kann man beginnen, in den empfangenen Daten nach Mustern zu suchen und das Protokoll zu entschlüsseln, also die Semantik lernen.
Wenn man den Sketch in den Debug-Mode versetzt, liefert er heute schon die empfangenen Rohdaten, nur nützt es nichts, wenn man mit der falschen data rate und evtl. falschen HF-Parametern unterwegs ist. Da wird allerdings noch einiges mehr an debug-log mitgesendet. Ich könnte aber auch recht einfach noch einen Mode implementieren, der nur die Rohdaten rausgibt.
Wenn Du bis zum Wochenende wartest, habe ich eine Sketch Version, die auch die 8.842 kbps für den TX22 unterstützt, dann kannst Du mal mit den drei möglichen data rates schauen, ob etwas empfangen wird, das ein sich wiederholendes Muster aufweist.
Je mehr 868 MHz Sender man im Umkreis hat, ums schwieriger wird das, weil man ständig etwas empfängt. Ich war schon mit dem Laptop und einem Sensor im Wald, um frei von HF-Müll einen Sensor zu analysieren. 8)
Es ist sehr frustrierend, wenn man nach Stunden der Analyse feststellt, dass das, was man beobachtet, auch dann noch empfangen wird, wenn man die Batterie aus dem Sensor nimmt :)
Oh, ich habe sowohl Zugriff auf einen Analyzer, als auch auf eine Zweitausstattung von Sensoren in meinem Hochschullabor.
Warten wir mal das Wochenende ab.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 12 Mai 2015, 15:04:15Oh, ich habe sowohl Zugriff auf einen Analyzer, als auch auf eine Zweitausstattung von Sensoren in meinem Hochschullabor.
Das ist gut. Damit bleibt am Ende dieser Weg schon mal offen. Hat zwar auch einige Hürden wie eingegossene RFM-Module, aber definitiv eine weitere Chance.
Zitat von: Prof. Dr. Peter Henning am 12 Mai 2015, 15:04:15Warten wir mal das Wochenende ab.
Ja, mit etwas Glück muss nicht der "harte Weg" beschritten werden.
So, nun hier anbei vorab zum Testen der erste Anlauf (beta):
Sketch 10.1i:
- Neues Kommando p: 1p aktiviert den raw payload mode, die empfangenen Daten werden 1:1 auf der seriellen Schnitstelle ausgegeben. Beispiel siehe unten.
- TX22 (WS 1600) implementiert
- Neue data rate 8.842 kbps, kann mit 2r gesetzt werden
- Neues Kommando m: bestimmt, welche data rates der toggle mode verwendet. Default=3
m ist bit codiert
1: 17.241 kbps
2: 9.579 kbps
4: 8.842 kbps
Beispiele:
3m -> wechselt zwischen 17.241 kbps und 9.579 kbps
5m -> wechselt zwischen 17.241 kbps und 8.842 kbps
7m -> wechselt zwischen allen drei data rates
Um die WS 1600 (TX22) zu testen:
FHEM muss auf dem aktuellen Update sein, da justme das JeeLink Modul kürzlich angepasst hat.
Den angehängten Sketch flashen (nach .../firmware/JeeLink_LaCrosse.hex legen und mit set myJeeLink flash flashen, oder sonstwie halt)
Die angehängte 36_LaCrosse.pm in FHEM kopieren und neu starten
Batterien aus dem TX22 raus und wieder rein
Mit set myJeeLink LaCrossePairForSec 60 das pairing aktivieren
Danach sollte ein LaCrosse device angelegt werden und nach und nach die Daten eintrudeln.
(Für einen TX22, der schon länger als 5 Stunden läuft, kann man auch im Log schauen, welche ID er hat und das LaCrosse device manuell anlegen.)
Beispiel siehe angehängter Schirmschuss.
Zu beachten ist, dass der TX22 nur die ersten 5 Stunden alle Daten alle 4 Sekunden sendet, danach nur dies und das mal.
Es kann also einige Zeit dauern, bis alle Readings da sind.
Da ich am Sketch einige heftige Umbauten vornehmen musste, wäre es super, wenn auch noch jemand bestätigen könnte, dass die TempHumi-Sensoren noch wie gehabt funktionieren.
Backup vom bisherigen Sketch/Modul nicht vergessen, um im Ernstfall zurück zu können.
Wir sollten nun eine ausreichende Zeit testen, bevor ich das offiziell mache und einchecke.
Nachtrag zu den readings: rain ist in mm und wind in m/s
@Prof. Dr. Peter Henning: Mit 0r, 1r und 2r kannst Du die data rate setzen (17.241 kbps, 9.579 kbps und 8.842 kbps).
Mit 1p wird der neue "raw paylod" mode aktiviert, dann sendet der Sketch die empfangenen Rohdaten über die Schnittstelle raus.
Hier ein Beispiel, wie das aussieht.
Die Zeilen, die mit 25 6A 54 51 beginnen, sind von einem EMT7110
25 6A ist die Kennung, die der EMT7110 sendet
54 51 ist die ID (Adresse) eines meiner EMT7110
Wenn man die Zeilen durchschaut, dann erkennt man das Muster und merkt, dass man da etwas hat, das periodisch etwas wiederkehrendes sendet.
Wenn man es nun nicht schon gewusst hätte, dann hätte man gerade die Pakete eine EMT7110 entdeckt und könnt versuchen, die Daten zu verstehen, indem man am Sensor die Werte ändert und schaut, was passiert.
So kann man nun versuchen, die Aussendungen eines Sensors zu finden und zu verstehen, bis man nachts von Monster-Hex-Werten träumt ;D
Opening port
Port open
[LaCrosseITPlusReader.10.1i (RFM12B) @9579 kbps / 868300 kHz]
97 C3 33 9E B3 92 92 92 49 49 49 49 49 49 49 49 49 A4 A4 A4 A4 A4 A4 A4 A4 D2 52 52 52 52 52 52 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
32 B5 2A 28 A0 1E 80 2D 98 C4 F1 D2 B7 7 83 81 C1 E0 E0 70 78 3C 1C 1E E 7 7 83 81 C1 E0 E0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
B2 11 36 55 54 50 0 15 55 55 45 BA 96 42 26 CA AA 8A 27 97 69 BB BC C3 F8 D5 D3 3E F7 26 EE B7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 16 3A E8 FB 82 97 9A 9F 3F 8F F 1C 50 3E B6 3A 1F 8E 3D CE 15 C8 87 CD E6 F9 BF EB A0 F1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 86 32 42 91 E9 FC 7F BF 9F EF 2F 7B FD FE D FF F9 3F C9 BE CE FA 2E 73 BB 6F 76 1F B9 F 6F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 43 19 90 A4 43 3 1 80 C0 C0 60 30 30 18 C C 6 3 3 1 80 C0 C0 60 70 30 18 1C C 6 7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
97 83 33 8E B3 AA 2A 2A 2A 35 15 1C 29 28 1 FA 11 51 51 51 51 51 51 51 A8 A8 A8 A8 A8 A8 A8 A8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9A 46 42 3D 5C 2 F0 AF BE FA 79 F9 BC 35 C2 7F 78 7B 3F FF DB 7F DD BC D BF F7 C6 40 77 1E FF 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9A 43 21 1F 57 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
25 6A 54 51 40 96 1 6C C4 4F 3A 3C FE 72 F5 6E 82 F 41 19 FE A7 19 C4 24 E3 A3 F8 7E 55 55 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
25 6A 54 50 A0 65 80 2D 98 8C F3 91 E3 BB B9 DD DD CE EE EF 77 77 3B BB B9 DD DD EE EE E7 77 77 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 16 3A E8 74 F1 B9 43 ED FF DF 8D 8F FC 5B C3 BD FF D8 23 73 7D 47 F7 FF 71 34 1F 8F 7F FF 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 86 32 42 91 D3 DF FB DF BF 4F FF C7 3F 21 F3 BE 71 FB 73 53 7F AE FD FA C7 7C 43 1F C6 CB DE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 43 19 90 A4 64 14 A A 5 5 2 82 81 41 40 A0 A0 50 50 28 28 14 14 A A 5 5 2 82 81 41 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
97 86 67 3A CE 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9A 46 42 3D 5C 17 6D 61 CF 59 EC FE 7C 47 C9 A1 C7 17 1C 13 E4 F9 63 B2 E6 FD C4 9B 7A 7F 1F E1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 16 3A E8 6A 1F D5 EB DC EB C3 2F BF F6 3 CF 6B BE 64 F4 FC DC 71 DF 8E AF EC B7 F F3 FB 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 86 32 42 91 8E 7D DB FF BE 75 3E 96 CF 87 61 1F B4 7C E1 D3 6F 17 3A 86 3F FF BD 3 F7 30 DB 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
97 86 67 3A CE 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
25 6A 54 51 40 96 1 68 C5 4F 3A 3F FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9A 46 42 3D 5C 4F 21 F4 27 B0 AE 8D BB F9 89 44 56 5E FE 17 F1 C2 1C 6F F9 F5 BD FD F7 96 9F 8F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9A 46 42 3D 5C 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 16 3A E8 3E 72 B0 B EA 7D 2F D5 BC 7 9B FF 74 F7 FF FF E1 33 F8 DF F4 E3 E7 FA 7E CB 2F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 86 32 42 91 EB 79 F9 BF 36 79 EE 80 F6 E9 38 F8 DC 47 EA FE 25 39 CE 79 47 C5 EA F 96 77 F7 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
97 86 67 3A CE 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 40 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 15 3A C5 F6 58 F3 BF E5 31 FD B1 3E FD DC AF F5 F7 B3 72 E 77 9F FE 97 F8 C3 DB EF 6B A5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9A 46 42 3D 5C 65 1C FB DF 73 E1 3E FE 53 BE F8 79 7F FD 8F DA 3D 7B F5 FF 7F F 3F C4 FE E5 B8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
25 6A 54 51 40 96 1 6A C6 4F 3B 3B FF 18 FE EF FD 93 1D 6 98 20 4D 86 FF 45 9E FB FE AA AA 2D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 16 3A E8 3B FA 7F 78 FF D3 F1 DF 74 DF FE FD A5 1B F2 A7 45 F3 8F FE 76 71 BE 3F D6 F2 68 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 86 32 42 91 CA 6E EB A0 1D C6 47 C7 7F 7F CE FF F9 AF 73 1F 3 CF D5 84 C0 F8 92 EF FD 8F F8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
98 86 32 42 91 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
9D C6 15 3A C5 6F EF 62 3F E7 8C E3 FB 5F 7E EC 62 4E FF 34 FE 6F FF F B6 AB DD C5 1B 87 38 D5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Ich werde mich daran setzen. Allerdings verspreche ich nicht, nachts davon zu träumen - da haben meine echten Forschungsprojekte Vorrang...
LG
pah
Vielen Dank für die Arbeit!
Ich habe den Sketch eingebunden ([LaCrosseITPlusReader.10.1i (RFM12B) @17241 kbps / 868300 kHz]) und die 36_LaCrosse ausgetauscht.
# $Id: 36_JeeLink.pm 8562 2015-05-10 20:25:18Z justme1968 $
# $Id: 36_LaCrosse.pm 7027 2014-11-20 20:08:00Z justme1968 $
Das initcommand des Jeelink ist "7m 0a 30t v"
Leider wird der TX22 noch nicht erkannt. Es gibt aber auch keine Fehlermeldungen über unbekannte Sensoren. Auch nach einem PairForSec taucht kein neues Device auf. Die anderen Sensoren (IDs 2E, 01, 04, 10, 39) funktionieren weiterhin.
Habe ich was vergessen? Brauchst du noch weitere Infos / Logs?
Hier ein Ausszug aus dem FHEM Log
2015.05.17 14:10:15 5: JLLaCR dispatch OK 9 1 1 4 202 37
2015.05.17 14:10:17 5: JeeLink/RAW: /OK 9
2015.05.17 14:10:17 5: JeeLink/RAW: OK 9 /46 130 4 186 125
2015.05.17 14:10:17 5: JLLaCR dispatch OK 9 46 130 4 186 125
2015.05.17 14:10:18 5: JeeLink/RAW: /OK 9
2015.05.17 14:10:18 5: JeeLink/RAW: OK 9 /57 1 4 169 38
2015.05.17 14:10:18 5: JLLaCR dispatch OK 9 57 1 4 169 38
2015.05.17 14:10:24 5: JeeLink/RAW: /OK 9 16 1 4 201 43
OK 9 46 1 4 183 106
OK 9 1 1 4 202 37
2015.05.17 14:10:24 5: JLLaCR dispatch OK 9 16 1 4 201 43
2015.05.17 14:10:25 5: JLLaCR dispatch OK 9 46 1 4 183 106
2015.05.17 14:10:25 5: JLLaCR dispatch OK 9 1 1 4 202 37
2015.05.17 14:10:27 5: JeeLink/RAW: /OK
2015.05.17 14:10:27 5: JeeLink/RAW: OK/ 9 57 1 4 169 38
2015.05.17 14:10:27 5: JLLaCR dispatch OK 9 57 1 4 169 38
2015.05.17 14:10:29 5: JeeLink/RAW: /O
2015.05.17 14:10:29 5: JeeLink/RAW: O/K 9 16 1 4 201 43
2015.05.17 14:10:29 5: JLLaCR dispatch OK 9 16 1 4 201 43
2015.05.17 14:10:30 5: JeeLink/RAW: /OK 9
2015.05.17 14:10:30 5: JeeLink/RAW: OK 9/ 4 1 4 188 35
2015.05.17 14:10:30 5: JLLaCR dispatch OK 9 4 1 4 188 35
2015.05.17 14:10:31 5: JeeLink/RAW: /OK 9 1
2015.05.17 14:10:31 5: JeeLink/RAW: OK 9 1/ 1 4 202 37
2015.05.17 14:10:31 5: JLLaCR dispatch OK 9 1 1 4 202 37
2015.05.17 14:10:34 5: JeeLink/RAW: /O
2015.05.17 14:10:34 5: JeeLink/RAW: O/K 9 46 130 4 186 125
2015.05.17 14:10:34 5: JLLaCR dispatch OK 9 46 130 4 186 125
2015.05.17 14:10:36 5: JeeLink/RAW: /OK 9
2015.05.17 14:10:36 5: JeeLink/RAW: OK 9/ 57 1 4 169 38
2015.05.17 14:10:36 5: JLLaCR dispatch OK 9 57 1 4 169 38
2015.05.17 14:10:37 5: JeeLink/RAW: /OK
2015.05.17 14:10:37 5: JeeLink/RAW: OK/ 9 16 1 4 201 43
Mit 7m 30t kann es mehr als eine Minute dauern, bis der JL auf der richtigen data rate ist. Sicher dass da nichts kommt?
Pakete vom TX22 beginnen im Log mit "OK WS"
Oh, ich liebe es.
Mengen an unbekannten Codes - und der gute alte Temperatursensor wird auch erkannt.
LG
pah
Ich war wohl zu ungeduldig. Stick einmal neu gesteckt und schon ist wieder Wind :D
Kurz gesagt: Alles funktioniert wie gewünscht. Große Klasse.
Zitat von: okiberlin am 17 Mai 2015, 17:49:49
Kurz gesagt: Alles funktioniert wie gewünscht. Große Klasse.
Könntest ja aus Dankbarkeit die WIKI um TX22 (WS 1600) ergänzen. ;)
So hat man mich auch mal überzeugt.
Gruß Billy
Das wäre cool. Aber warte noch, bis es offiziell ist.
Zum Thema "Regen" fehlt noch eine Idee. Das ist die Regenmenge seit dem Einlegen der Batterien in den TX22. Noch nicht unbedingt sehr sinnvoll.
Hat jemand (machbare) Vorschläge, was man daraus machen sollte?
@pah: ich sehe in dem Log einen Temperatursensor und Datenmüll. Da ist nichts dabei, das interessant aussieht -> andere data rate probieren.
Zitat von: HCS am 17 Mai 2015, 18:50:21
Zum Thema "Regen" fehlt noch eine Idee. Das ist die Regenmenge seit dem Einlegen der Batterien in den TX22. Noch nicht unbedingt sehr sinnvoll.
Hat jemand (machbare) Vorschläge, was man daraus machen sollte?
Das müsste doch ähnlich wie beim PCA301 mit userReadings consumptionTotal: --> analog userReadings rainTotal: gehen?
Ich kann mir vorstellen dass das für Andre ein Klacks ist. (Für dich vermutlich auch) ;)
Gruß Billy
Zitat von: Billy am 17 Mai 2015, 19:02:36
Das müsste doch ähnlich wie beim PCA301 mit userReadings consumptionTotal: --> analog userReadings rainTotal: gehen?
Ich kann mir vorstellen dass das für Andre ein Klacks ist. (Für dich vermutlich auch) ;)
Das ist ja schon "total", meiner Meinung nach eher sinnvoll wäre z.B. "letzte 24 Stunden" oder "seit 00:00 Uhr"
Oder macht das, was Du meinst, so was in der Art?
Das was du willst müsste mit den bestehenden Modulen zum Thema rain gehen
Siehe auch hier
http://forum.fhem.de/index.php/topic,23463.msg167706.html#msg167706ttp://forum.fhem.de/index.php/topic,23463.msg167706.html#msg167706
Siehe auch Modul statistics von tupol
Billy
Ja, stimmt, das 98_rain kannte ich nicht. Ich probiere es mal aus.
Dann wäre ja alles OK so weit.
Gibt es noch jemand, der den neuen Sketch und das neue LaCrosse Modul bei sich mal laufen lassen würde?
Man muss keine WS haben, wichtig ist, dass die Temperature/Feuchte-Sensoren noch wie vorher funktionieren (was sie bei mir tun), also TX29, TX35 und die 30... Sensoren.
@HCS: Diesen "Datenmüll" bekomme ich mit 0r.
Bei 1r und 2r gibt es gar keine Daten.
Edit: Ich war zu ungeduldig - 1r liefert etwas.
Auch glaube ich nicht so ganz an "Müll" - dafür tauchen zu viele Sequenzen mehrfach auf.
LG
pah
Zitat von: HCS am 17 Mai 2015, 20:07:36
Gibt es noch jemand, der den neuen Sketch und das neue LaCrosse Modul bei sich mal laufen lassen würde?
Man muss keine WS haben, wichtig ist, dass die Temperature/Feuchte-Sensoren noch wie vorher funktionieren (was sie bei mir tun), also TX29, TX35 und die 30... Sensoren.
Ich nehme an, der EMT7110 läuft auch mit dem neuen Sketch?
Zitat von: Prof. Dr. Peter Henning am 17 Mai 2015, 20:09:23
Auch glaube ich nicht so ganz an "Müll" - dafür tauchen zu viele Sequenzen mehrfach auf.
Die "97 A6" sind der Temperatursensor, bei dem die Temperatur in 10tel Grad Schritten kleiner wird. Sonst sehe ich da nichts.
97 A6 15 ... -> 21,5°C
97 A6 14 ...
97 A6 13 ...
97 A6 12 ...
97 A6 15
6A 2B
6A = 106 -> Die Kennzeichnung von einem LaCrosse Temperatursensor, der keine Luftfeuchtigkeit überträgt.
und das fünfte Byte ist die Prüfsumme.
Temperatursensor
2015.05.17 17:37:03 5: JEELINK dispatch 97 A6 9 6A F1
Genau 4 Sekunden (das LaCrosse Interval) später
vom selben Sensor ein kaputtes Paket empfangen, bei dem die Prüfsumme nicht aufgeht
2015.05.17 17:37:07 5: JEELINK dispatch 97 A2 9 69 F1
Ich glaube nicht, dass in dem Log Regen oder Wind vorkommt.
Zitat von: Billy am 17 Mai 2015, 20:25:32
Ich nehme an, der EMT7110 läuft auch mit dem neuen Sketch?
Es sollten alle bisherigen Sensoren noch funktionieren.
Bei mir laufen die EMT7110 noch, die LevelSender auch und natürlich die TX29DTH, die 35er usw.
Trau Dich und pack ihn drauf ;)
Hab mich getraut! ;D
Läuft alles wie gehabt.
Ich nehme an, dass ich meinen Relay Jeelink nicht flashen muss solange ich keine WS 1600 betreibe?
Gruß Billy
Zitat von: Billy am 17 Mai 2015, 21:37:20Ich nehme an, dass ich meinen Relay Jeelink nicht flashen muss solange ich keine WS 1600 betreibe?
Korrekt. Und selbst dann nicht, wenn die WS 1600 in der Reichweite des FHEM-JL ist.
Wenn jetzt jemand meint er brauche nun auch endlich eine WS 1600 und will aber keine 90 Öre beim blauen C ausgeben :
ebay Kleinanzeigen durchsuchen nach WS1600 , bringt z.Z einen Treffer mit neu für 45 € !
Die gute Frau hatte zwei Stück, eine davon habe ich gerade abgeholt :)
Zitat von: HCS am 17 Mai 2015, 11:25:17
Wir sollten nun eine ausreichende Zeit testen, bevor ich das offiziell mache und einchecke.
Ja gern, würdest du dafür bitte mal alle angepassten Arduino Quelldateien posten ?
Ich kann auf Grund der benutzen Hardware in meinem Testaufbau mit der nackten .hex Datei leider nicht viel anfangen.
Hallo,
habe heute mein Jählings bekommen und suche nun den Artikel in welchem beschrieben ist wie ich diesen flashen kann und LaCrosse zum laufen bekommen. Ich hatte hier mal einen Artikel gefunden der das ausführlich beschrieben hatte.
Danke
am einfachsten direkt aus fhem heraus. im wiki steht wie es geht.
gruß
andre
Danke! Hat soweit auf anhieb alles funktioniert! Sensor im Badezimmer wird erkannt!
@HCS: Gibt es irgendwo eine Quelle, aus der man die Kennungen der LaCrosse-Sensoren erfahren kann ? Wäre für einen Link dankbar.
LG
pah
??? Meinen TFA Sensor Kat.-Nr: 30.3155.WD konnte ich sofort ohne Probleme einbinden.
Allerdings bekomme ich den TX29-IT nicht eingebunden. Muss hierbei etwas besonderes beachtet werden? Laut Wiki wird der TX29-IT unterstützt.
mmmm...ich habe jetzt ca. 15 Minuten gewartet und nun sind alle Sensoren da! :)
Zitat von: Wzut am 19 Mai 2015, 07:12:04
Ja gern, würdest du dafür bitte mal alle angepassten Arduino Quelldateien posten ?
Ich kann auf Grund der benutzen Hardware in meinem Testaufbau mit der nackten .hex Datei leider nicht viel anfangen.
Quellcode anbei
Hast Du andere ports verwendet oder was bedeutet "auf Grund der benutzen Hardware"?
Eventuell könnte man das ja im Sketch universell funktionierend machen.
ich habe eine kleine änderung am jeelink modul eingecheckt. damit kann man jetzt auch einen per ser2net angebunden jeelink ansprechen.
gruss
andre
Zitat von: Prof. Dr. Peter Henning am 19 Mai 2015, 17:45:28
@HCS: Gibt es irgendwo eine Quelle, aus der man die Kennungen der LaCrosse-Sensoren erfahren kann ? Wäre für einen Link dankbar.
Ist mir keine bekannt.
Na, dann sehe ich mir das mal im Labor genauer an. Interessant in diesem Zusammenhang: http://www.jacquet80.eu/blog/post/2011/10/Decodage-capteur-thermo-hygro-TFA
LG
pah
Kann mich mal jemand auf den aktuellen Stand bringen, ich konnte hier beim Drüberlesen über die vielen Seiten nichts neues mehr entdecken:
* Das Senden von Temperaturen geht noch immer nicht, oder?
Ist der Code zum Testen der Sendefunktion noch im Code vorhanden, oder wurde dieser bereits wieder entfernt. Gibt es zwischenzeitlich eine Idee, warum
die Temperaturen jeweis nur einmal gesendet werden konnten?
Hintergrund: Ich möchte in der Wetterstations-Anzeige die Temperatur eines 1-wire Sensors einspeisen, da dieser zuverlässiger funktioniert und keine jährlichen Batteriewechsel benötigt.
Zitat von: JoeALLb am 20 Mai 2015, 12:57:57
* Das Senden von Temperaturen geht noch immer nicht, oder?
Das Senden schon, nur spielen die Stationen irgendwie beim Anzeigen nicht mit
Zitat von: JoeALLb am 20 Mai 2015, 12:57:57Ist der Code zum Testen der Sendefunktion noch im Code vorhanden, oder wurde dieser bereits wieder entfernt
Noch vorhanden
Zitat von: JoeALLb am 20 Mai 2015, 12:57:57Gibt es zwischenzeitlich eine Idee, warum die Temperaturen jeweis nur einmal gesendet werden konnten?
Nein
Zitat von: Prof. Dr. Peter Henning am 20 Mai 2015, 12:30:50Na, dann sehe ich mir das mal im Labor genauer an.
Zu diesem Thema habe ich gerade in Poolthermometerthread eine "Abhandlung" geschrieben: http://forum.fhem.de/index.php/topic,24599.msg296339.html#msg296339
So als richtungsweisende Grundlage, da ist auch ein Link zu noch jemand drin, der so etwas auch schon mal gemacht und schön dokumentiert hat.
Wenn man es durch "Hardware lauschen" ermitteln will, ist das eine gute Vorgehensweise.
Vlt. noch ein Hinweis: Wie kann man den Jeelink mit dem neuen Sketch in der Frequenz ändern ? Ich wollte mal auf 868.45 lauschen...
LG
pah
Zitat von: Prof. Dr. Peter Henning am 20 Mai 2015, 17:48:21Wie kann man den Jeelink mit dem neuen Sketch in der Frequenz ändern ?
"Available commands:" "\n"
" <n>a - activity LED (0=off, 1=on)" "\n"
" <t10>,<t1>,<t0>,<hum>c - set temperature and humidity for transmit" "\n"
" <n>d - DEBUG mode (0=suppress TX and bad packets)" "\n"
" <nnnnnn>f - frequency (5 kHz steps e.g. 868315)" "\n"
" <id>,<int>,<nbt>,<dr>i - set the parameters for the transmit loop" "\n"
" <n>m - toggle mode (1: 17.241 kbps, 2: 9.579 kbps, 4: 8.842 kbps)" "\n"
" <n>p - show raw payload data (0 = off, 1 = on)" "\n"
" <n>r - data rate (0: 17.241 kbps, 1: 9.579 kbps, 2: 8.842 kbps)" "\n"
" b1,b2,b3,b4s - send the passed bytes plus the calculated CRC" "\n"
" <n>t - toggle data rate intervall (0=no toggle, >0=seconds)" "\n"
" <n>v - version and configuration report" "\n"
" <n>x - used for tests" "\n"
" <n>y - Relay (0=no relay, 1=Relay received packets)" "\n"Wenn jemand so nett wäre und das ins wiki packen würde, wäre hilfreich für die Zukunft.
Nachtrag: natürlich in einer etwas ansprechenderen Form ;D
Zitat von: Prof. Dr. Peter Henning am 20 Mai 2015, 17:48:21Ich wollte mal auf 868.45 lauschen...
Da würde es sich anbieten, den Sensor mal neben einen Spectrum Analyzer zu stellen, dann hätte man die Frequenz schon mal sicher und auch das Interval, in dem er sendet. Beides sehr hilfreich, wenn man es weiß.
Natürlich auch mit einem SDR machbar, wie in Deinem link geschehen.
Zitat von: HCS am 20 Mai 2015, 09:17:22
oder was bedeutet "auf Grund der benutzen Hardware"?
Eventuell könnte man das ja im Sketch universell funktionierend machen.
andere Hardware = Arduino Mega ( der liegt immer zm spielen auf dem Schreibtisch :) )
und da sind halt immer die SPI Pins anzupassen :
RFM12 rfm(11, 12, 13, 10, 2);
RFM12 rfm(51, 52, 53, 50, 2); <- Mega
denke aber nicht das sich das lohnt mit aufzunehmen. Habe deine Beta jetzt am laufen mit allen drei Frequenzen und Wechsel alle 30 Sekunden.
Schaut bisher gut aus mit 6x TX29IT , 1x EMT7110 und die WS1600
Oh, der läuft auf einem Mega. Hatte ich nie probiert. Habe ich auch einen rumliegen, der sich langweilt. Muss ich ja glatt mal testen.
Aber dann geht vereinheitlichen eh nicht, weil der Maga ja auch ein anderes Compilat braucht.
Da bin ich dann Deiner Meinung - so selten, wie der Sketch sich ändert, hast Du es auch schnell mal angepasst und für den Mega gebildet.
So wie es aktuell aussieht passt das Ganze wohl, dann werde ich den Sketch und das LaCrosse Modul voraussichtlich am Wochenende einchecken, dass es offiziell zur Verfügung steht.
Einen Schritt weiter: Laut Spektrumanalysator senden die Sensoren der TX56 und TX57 bei 868.50 MHz.
Mit den Frequenzeinstellungen 868.50, 868.55 und 868.60 bekomme ich auch Unmengen an Paketen herein - aber mit allen drei Datenrateneinstellungen bisher nichts Verwertbares.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 22 Mai 2015, 14:53:51Einen Schritt weiter: Laut Spektrumanalysator senden die Sensoren der TX56 und TX57 bei 868.50 MHz.
Prima. Senden die im LaCrosse typischen Intervall von 4 Sekunden?
Nun wäre die data rate zu ermitteln, da es wohl keine der drei bisherigen ist.
Ich hätte da so eine Idee. Ich könnte im Sketch einen scan mode implementieren, der so aussehen könnte (Eckdaten und increments noch genau zu überlegen):
Der Sketch beginnt bei 868100 kHz und empfängt auf jeder möglichen data rate eine Minute lang und gibt die Rohdaten raus, wie beim 1p mode. Danach erhöht er die Frequenz um 5 kHz und arbeitet wieder die data rates durch. Beim Wechsel von Frequenz oder data rate schreibt er dies als Überschrift raus.
Dann könnte man (Du?) auf FHEM Seite eine Mustererkennung implementieren, die Alarm schlägt, wenn in den übermittelten Daten ein sich wiederholendes Muster erkennbar ist.
Damit hätte man die Chance (aber keine Garantie), generell für unbekannte Sensoren die Frequenz und die data rate zu finden.
Eventuell mit Konfiguration, Beispiel: 868200,868600n
würde von 868200 kHz bis 868600 kHz scannen.
Die Daten würden so wie bei 1p aussehen, nur dass bei jedem Wechsel von Frequenz oder data rate eine Überschrift ausgegeben wird, z.B. so:
868205@9579
Wenn dann vom Sensor erst mal Daten empfangen werden können, muss natürlich noch das Protokoll analysiert werden.
Auch von mir: Vielen Dank für die gute Arbeit!
Der Betasketch 10.1i läuft auch bei mir bisher problemlos.
Ich betreibe den JeeLinkClone mit einem RFM69HW und den initCommands: 7m 30t v
{[LaCrosseITPlusReader.10.1i (RFM69CW) @AutoToggle 30 Seconds / 868300 kHz]}
Alle meine Sender werden soweit korrekt empfangen:
TX25TP-IT
TX29DTH-IT
30.3156.WD
Habe das LaCrosse Modul und den Sketch eingecheckt, kommt morgen mit dem Update.
Hier nochmal die Änderungen:
Jetzt wäre es ideal, wenn es jemand ins wiki packen würde ;)
Sketch 10.1i:
- Neues Kommando p: 1p aktiviert den raw payload mode, die empfangenen Daten werden 1:1 auf der seriellen Schnitstelle ausgegeben
- TX22 (WS 1600) implementiert
- Neue data rate 8.842 kbps, kann mit 2r gesetzt werden
- Neues Kommando m: bestimmt, welche data rates der toggle mode verwendet. Default=3
m ist bit codiert
1: 17.241 kbps
2: 9.579 kbps
4: 8.842 kbps
Beispiele:
3m -> wechselt zwischen 17.241 kbps und 9.579 kbps
5m -> wechselt zwischen 17.241 kbps und 8.842 kbps
7m -> wechselt zwischen allen drei data rates
Um die WS 1600 (TX22) zu verwenden:
FHEM mit Update auf den aktuellen Stand bringen
Den Sketch 10.1i flashen (set myJeeLink flash)
In initCommands vom JeeLink die data rate mit 2r auf 8.842 kbps setzten oder einen Toggle Mode verwenden, in dem 8.842 kbps vorkommen
Batterien aus dem TX22 raus und wieder rein
Mit set myJeeLink LaCrossePairForSec 120 das pairing aktivieren
Danach sollte ein LaCrosse device angelegt werden und nach und nach die Daten eintrudeln.
Zu beachten ist, dass der TX22 nur die ersten 5 Stunden alle Daten alle 4 Sekunden sendet, danach nur dies und das mal.
Es kann also einige Zeit dauern, bis alle Readings da sind.
Readings: rain ist in mm und wind in m/s
@HCS.
Hm. Eine Mustererkennung, die aus beliebigen Binärdaten wiederkehrende Sequenzen herausfischt ? Das versucht SETI seit ein paar Jahrzehnten, Software dafür gibt es frei verfügbar. Aber für einen Kleinstcomputer mit FHEM ist das etwas zu anspruchsvoll.
Auch eine KI kann ich mir auf einem Raspberry Pi nur schwer vorstellen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2015, 09:47:09Das versucht SETI seit ein paar Jahrzehnten, Software dafür gibt es frei verfügbar.
Dann könnte ich doch glatt mal mit dem JeeLink nach Aliens suchen.
Wenn man im Gliese 667 System LaCrosse IT+ spricht, dann sollte das klappen ;D ;D ;D
Nun ernsthaft: Die Erkennung von einem LaCrosse Sensor mit SETI zu vergleichen finde ich schon etwas gewagt.
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2015, 09:47:09...Aber für einen Kleinstcomputer mit FHEM ist das etwas zu anspruchsvoll.
Auch eine KI kann ich mir auf einem Raspberry Pi nur schwer vorstellen.
Nicht übertreiben. Es geht darum, in einigen hundert Zeilen herauszufinden, ob es welche gibt, die mit den drei gleichen Bytes beginnen.
Zumal, man kann das auch loggen und dann mit einer Software auf dem PC mal drüber scannen.
Ich glaube ich baue mir da mal was, ich habe hier noch einen TFA 30.3181.IT liegen, der mir sein Protokoll noch nicht verraten hat.
Na, in dem Ansinnen ging es ja nicht um drei gleiche Bytes - sondern um die allgemeine Erkennung von Mustern.
Wir machen so etwas durchaus in einem von mir geführten EU-Forschungsprojekt, darum kann ich die Komplexität einer solchen Aufgabe ganz gut einschätzen.
LG
pah
Zitat von: Prof. Dr. Peter Henning am 24 Mai 2015, 11:11:44Na, in dem Ansinnen ging es ja nicht um drei gleiche Bytes - sondern um die allgemeine Erkennung von Mustern.
Ja, schon gut ... ::)
@HCS, ich habe letzten Stand nun auf dem aktiven JeeLink und sammle seit zwei Tagen fleißig Daten der WS 1600.
Bei den Logs/Plots habe ich so alle 4-5 Stunden einen "unsinnigen" Wert von 24.5 sowohl bei windSpeed als auch bei windGust.
temperatur , humidity und rain haben keine derartigen Ausreißer. Defektes Telegramm was durch die CRC Prüfung rutscht ? oder irgend eine andere Idee ?
Zitat von: Wzut am 25 Mai 2015, 20:12:44Bei den Logs/Plots habe ich so alle 4-5 Stunden einen "unsinnigen" Wert von 24.5 sowohl bei windSpeed als auch bei windGust.
Meintest Du 25.4 oder tatsächlich 24.5 ?
Die 25.4 Ausreißer habe ich auch gerade entdeckt. Muss ich erforschen. Dass defekte Telegramme immer auf 25.4 rauskommen wäre ja schon seltsam.
Das sieht eher nach einem Fehler in der Software aus :(
ja sorry du hast Recht , war ein Zahlendreher
Das mit den 25.4 m/s ist eine seltsame Geschichte.
Das Datenpaket von TX22 hat im dritten nibble zwei Flags. Das 1er Bit ist ein "Error-Flag" und das 2er Bit zeigt an, ob der TX22 in der synchronizing Phase (die ersten ca. 5 Stunden) ist.
Das "synchronizing Bit" ist sicher, das geht nach 5 Stunden weg und entspricht dem "new battery" der sonstigen IT+ Snesoren.
Das 1er Bit ist gesetzt, wenn z.B. am TX22 kein Wind-Sensor angeschlossen ist (gesicherte Erkenntnis) und ich dachte, auch wenn die Battery low ist (Vermutungen).
Bei den Datenpaketen, die WindSpeed=25.4 m/s liefern, ist es aber so, dass dieses Bit gesetzt ist und im 3er Datenblock die unteren beiden nibbles FE sind, was dann eben 25.4 m/s ergeben.
Nun ist die spannende Frage, was der TX22 damit eigentlich mitteilen will. Eigentlich ist die Ansage in solchen Paketen: "hier die Daten (er liefert ja eine WindSpeed), aber sie sind falsch (weil Error Bit gesetzt)"
Generell müsste die Bedeutung von diesem Bit wohl gesichert ermittelt werden, z.B. ob es tatsächlich auch bei "low battery" gesetzt wird.
Nur kann ich das aktuell schwer tun, dazu müsste ich mit Labornetzteil und Laptop zum TX22 auf's Dach sitzen. Hat noch jemand den TX22 samt Sensoren auf dem Schreibtisch liegen um da zu experimentieren?
Man braucht nur einen PC, ein beliebiges Terminal-Programm, einen JeeLink und ein von 1...3V regelbares Netzteil oder alternativ Batterien, die fast leer sind.
Was ich vorerst mal tun kann (und werde) ist, dass ich Pakete, bei denen das "Error-Bit" gesetzt ist, einfach ignoriere, damit ist das "25.4 Thema" erst mal unterdrückt.
Allerdings gibt es nun aktuell dann keine "low Battery" Information, Battery ist also immer "ok".
Angepasster Sketch folgt in Kürze.
aaaahh ok , das erklärt dann auch meine Bat low Meldungen trotz nagelneuer Batterien, Auszug aus der DB von heute :
2015-05-26 12:51:50 Wetterstation battery: ok
2015-05-26 12:51:46 Wetterstation battery: low
2015-05-26 11:56:29 Wetterstation battery: ok
2015-05-26 11:56:25 Wetterstation battery: low
2015-05-26 11:05:07 Wetterstation battery: ok
2015-05-26 11:03:59 Wetterstation battery: low
2015-05-26 11:03:55 Wetterstation battery: ok
2015-05-26 11:03:50 Wetterstation battery: low
2015-05-26 10:47:20 Wetterstation battery: ok
2015-05-26 10:47:16 Wetterstation battery: low
2015-05-26 10:20:11 Wetterstation battery: ok
2015-05-26 10:19:04 Wetterstation battery: low
2015-05-26 06:24:41 Wetterstation battery: ok
2015-05-26 06:24:37 Wetterstation battery: low
vermutlich sind zu den low Zeiten auch 25.4 Meldungen vorhanden, z.Z. habe ich diese direkt im LaCrosse Modul gefiltert. Werde ich mal wieder reinnehmen und schauen ob die beiden Ereignisse immer zusammen auftreten.
Brauchst Du gar nicht testen, wenn das Error bit gesetzt ist, dann gibt der Sketch definitiv auch "low batt" an FHEM rüber. Das ist ein weiterer Nebeneffekt.
Ich würde so gerne mal mit den LaCrosse Entwicklern reden ...
@Wzut: test den hier (V10.1j Beta) bitte mal. Damit sollten keine 25.4 Pakete mehr durchkommen.
Zitat von: HCS am 26 Mai 2015, 13:16:18
Ich würde so gerne mal mit den LaCrosse Entwicklern reden ...
Hallo,
hier wurde auch schon etwas zur WS1600 gemacht (http://nikseresht.com/blog/?p=99) http://www.g-romahn.de/ws1600/Datepakete_raw.txt. Vielleicht hilft es weiter.
Jörg
Zitat von: pejonp am 26 Mai 2015, 22:41:46... Vielleicht hilft es weiter.
Danke, leider nicht.
@Wzut: Wie sieht's aus?
Bei mir finde ich im Log nun keine seltsamen Windgeschwindigkeiten mehr.
Allerdings zweifle ich gerade daran, verstanden zu haben, wie der TX22 die Regenmenge übermittelt.
Hast Du dazu schon Beobachtungen?
Ist dein zweiter Beruf Gedankenleser ? Ich wollte eben gerade "losmeckern" .... :)
Sonntag Morgen eingerichtet und Wasser in den Sensor gekippt : Anzeige Station & FHEM : 5cm
Sonntag Abend ein paar Tropfen Regen : beide gehen auf 5.5
bis heute Nachmittag weiter konstant auf 5.5, dann nach dem ersten echten Regen : 6 , 6.5 , 7, 7.5 , 5
Die Basis Station steht nun auf 8 ( was ich bei fhem nach 7.5 auch erwartet hätte ... )
Zitat von: Wzut am 29 Mai 2015, 21:04:06Ist dein zweiter Beruf Gedankenleser ?
Nö, hatte gerade eine Tasse Kaffee leer und ganz unten im Kaffeesatz stand: "bei Wzut stimmt die Regenmenge nicht" ;D
Exakt das habe ich auch beobachtet. Ich vermute, der TX22 geht irgend wann wieder runter mit dem Wert, den er überträgt, und die Station schaut nur, ob es eine Erhöhung gab und zählt einen eigenen Zähler hoch.
Bei mir war es 10.5, 11.0, 11.5, 12.0, 12.5 und dann wieder 10.5
Die Station ist auf dem richtigen Wert geblieben.
Es ist aber absolut sicher, dass der TX22 nun wieder 10.5 sendet.
Das sollten wir noch etwas beobachten um hinter die Strategie des TX22 zu kommen.
Wie steht's mit dem Wind?
Zitat von: HCS am 29 Mai 2015, 21:14:33
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
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.
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 .... :)
Zitat von: Wzut am 03 Juni 2015, 17:23:31Was die Basis Station direkt anzeigt kann ich leider aus z.Z. ca. 800km Entfernnung nicht erkennen .... :)
Dann hat Deine webCam aber eine schlechte Reichweite ;D
Zitat von: Wzut am 03 Juni 2015, 17:23:31
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
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.
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.
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.
Zitat von: HCS am 07 Juni 2015, 10:00:21
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.
Zitat von: HCS am 07 Juni 2015, 10:00:21Es 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?
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
Zitat von: kpwg am 07 Juni 2015, 10:14:21... 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?
Zitat von: justme1968 am 07 Juni 2015, 10:27:28ich 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?
Zitat von: HCS am 07 Juni 2015, 11:00:59
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.
Zitat von: HCS am 07 Juni 2015, 11:00:59
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.
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
anbei eine erste version einen patches für autocreate.
das attribut ist eine liste aus <type>:<count>:<timeout> tripeln:attr autocreate autocreateThreshold LaCrosse:2:30,EMT7110:2:60
bitte mal testen ob das so funktioniert.
gruss
andre
Zitat von: justme1968 am 07 Juni 2015, 17:27:08
bitte mal testen ob das so funktioniert.
Getestet. Funktioniert mit folgenden Änderungen (gekennzeichnet mit ###HCS)
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.
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_00Ich 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?
Zitat von: kpwg am 07 Juni 2015, 12:12:11Es 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.
Zitat von: Kalli01 am 07 Juni 2015, 13:38:28Nach 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.
Es hatten schon mehrere Anwender nach Austausch der Spannungsversorgung das Problem dann nicht mehr.
Reden wir über einen Raspi als Server?
@HCS: ich würde wie auch von dir vorgeschlagen die log meldungen von autocreate auf level 4 schieben. dann sind die schon mal weg.
und die 'please define it' meldung im LaCrosse modul würde ich auch auf level 4 schieben wenn autocreate aktiv ist oder LaCrosse in den ignoreTypes steht (dann ist hier ja sowieso nichts manuell zu tun) und nur wenn beides nicht der fall ist auf 3 lassen.
dann sollte im normal fall erst mal nichts mehr geloggt werden ohne das noch ein api nötig ist. das mit dem zurück geben wäre auch problematisch weil es völlig asynchron arbeitet.
wenn dir das reicht poste ich für rudi die reparierte version. mal sehen ob er es einbaut.
gruss
andre
Zitat von: justme1968 am 07 Juni 2015, 20:38:17...wenn autocreate aktiv ist oder LaCrosse in den ignoreTypes steht (dann ist hier ja sowieso nichts manuell zu tun) und nur wenn beides nicht der fall ist auf 3 lassen.
Du meintest vermutlich "wenn autocreate aktiv (also definiert und nicht disabled) ist
und LaCrosse
nicht in den ignoreTypes steht" ?
So werde ich es wohl machen.
Zitat von: HCS am 07 Juni 2015, 20:16:50
Es hatten schon mehrere Anwender nach Austausch der Spannungsversorgung das Problem dann nicht mehr.
Reden wir über einen Raspi als Server?
Ja ist es. Das werde ich als nächstes mal versuchen.
ich hatte schon oder gemeint. die idee war die:
autocreate ist aktiv -> log level 4 -> alles geht automatisch, keine meldung
autocreate ist nicht aktiv, LaCrosse in den ignored types -> log level 4 -> alles wird automatisch ignoriert, keine meldnug
autocreate nicht aktiv, LaCrosse nicht in den ignored types -> log level 3 -> es wird nichts automatisch angelegt aber die meldungen sind sichtbar
d.h. der anwender kann zwischen alles automatisch, alles völlig ignorieren oder hinweise auf neue sensoren wählen.
gruss
andre
@justme1968: ja, jetzt wurde understood==true :)
Das muss ich dann aber in der commandref beschreiben, sonst kommt da niemand drauf, wie es sich wann verhält.
ich baue gerade noch ein das man direkt im modul in _Initialize über$hash->{AutoCreate} = { "LaCrosse.*" => { autocreateThreshold => "<count>:<timeout>" } };
einen default vergeben kann so das im einfachsten fall niemand das autocreateThreshold attribut von hand setzen muss.
dann poste ich es für rudi.
gruss
andre
@HCS @andre
Als Ersteller des Threads möchte ich einfach mal sagen Ihr seid einfach Spitze! :)
Und ein herzliches Dankeschön.
Wer hätte gedacht was sich aus dem Thema La Crosse + Jeelink alles entwickelt.
Grüsse Billy
vorschlag hier gepostet: http://forum.fhem.de/index.php/topic,37926.0.html (http://forum.fhem.de/index.php/topic,37926.0.html).
gruss
andre
rudi hat die autocreate änderung eingecheckt. ist also ab morgen im update.
das einfachste ist vermutlich wenn du $hash->{AutoCreate} = { "LaCrosse.*" => { autocreateThreshold => "2:60" } };
oder ähnlich direkt in LaCrosse_Initialize einbaust.
gruss
andre
Hallo,
Kann es sein das es seit neustem Probleme mit der Berechnung der lacrosse sensoren gibt?
Habe hier 2 30.3155 schon seit längerer Zeit laufen. Heute habe ich festgestellt das einer der sensoren die Temperatur falsch anzeigt.
Anbei mal ein Screenshot
(http://images.tapatalk-cdn.com/15/06/09/210e181499e4b6f2cf46bfb58c46b6b6.jpg)
Zitat von: noice am 09 Juni 2015, 23:47:02Kann es sein das es seit neustem Probleme mit der Berechnung der lacrosse sensoren gibt?
Bei mir laufen: 2 x 30.3155.WD, 3 x TX25IT, 3 x TX29DTH, 2 x TX35DTH, 1 x TX38IT, 2 x EMT7110, WS 1600 und LevelSender
Sowohl auf dem Test- als auch Produktivsystem ohne Auffälligkeiten. Die Temperaturen (und sonstige Werte) stimmen alle.
Zitat von: noice am 09 Juni 2015, 23:47:02Habe hier 2 30.3155 schon seit längerer Zeit laufen. Heute habe ich festgestellt das einer der sensoren die Temperatur falsch anzeigt.
Was ich auf der Hardcopy sehe, ist sehr seltsam.
Die rawmsg "OK 9 56 1 4 101 106"
sagt:
ID=38(Hex)
12,5 °C
Sensor sendet keine Luftfeuchtigkeit
Das passt zu den Readings in der Hardcopy
Nur:
Laut Definition sollte aber die ID 10(Hex) empfangen werden.
Ich denke, dass das kein Problem der Temperaturberechnung ist, sondern irgend eine Adressen-Geschichte. Es muss auf alle Fälle einen Sensor (mit ID 10) geben, der 12,5°C und keine Feuchte sendet und dessen Wert sehen wir hier.
Allerdings wurde um 23:10 Uhr eine Feuchte empfangen (vermutlich vom richtigen Sensor)
Wie das zustande kommt ist mir aber noch unklar. Einige Fragen, um da evtl. weiter zu kommen:
Seit wann ist das so?
Version von 36_JeeLink, 36_LaCrosse und vom Sketch?
In letzter Zeit etwas an der Definition des Sensors geändert (der Name LaCrosse_38 passt ja nicht zur Definition mit ID 10)?
Ich muss mir mal (klappt aber heute nicht mehr) die Strecke 36_JeeLink -> 36_LaCrosse anschauen, ob ich irgend etwas sehe, das einen Senosr falsch "zustellen" könnte.
Hallo zusammen,
nach einem Update Heute hagelte es Fehlermeldungen vom 36_LaCrosse (8713) Modul.
2015.06.10 15:54:31 1: reload: Error:Modul 36_LaCrosse deactivated:
Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/36_LaCrosse.pm line 10.
BEGIN failed--compilation aborted at ./FHEM/36_LaCrosse.pm line 10.
2015.06.10 15:54:31 0: Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/36_LaCrosse.pm line 10.
BEGIN failed--compilation aborted at ./FHEM/36_LaCrosse.pm line 10.
Hab erstmal die 36_LaCrosse (8622) aus meinem Backup wiederhergestellt -> Läuft.
Bei meinen Recherchen zum Thema Switch.pm hab ich folgendes gefunden:
Link (https://packages.debian.org/sid/libswitch-perl)ZitatDieses Modul ist veraltet und wird für Kompatibilitätszwecke zur Verfügung gestellt, da es aus dem Perl-Kern entfernt wird.
Für Perl 5.10 und darüber werden die eingebauten Funktionen »given/when« stark bevorzugt.
:o
Grüße Marius
Zitat von: corny456 am 10 Juni 2015, 16:52:352015.06.10 15:54:31 1: reload: Error:Modul 36_LaCrosse deactivated:
Can't locate Switch.pm in @INC (you may need to install the Switch module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/36_LaCrosse.pm line 10.
BEGIN failed--compilation aborted at ./FHEM/36_LaCrosse.pm line 10.
Danke für den Hinweis. Das war mir völlig fremd. Seltsam, mein 5.14.2 und 5.20.2 haben das beide gehabt, drum ist mir nichts aufgefallen.
Werde es umbauen.
Geändert und committed. Kommt dann mit dem Update mit.
Wer es dringend braucht, hier: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/36_LaCrosse.pm
@corny456: wärst Du so nett, diese Version kurz zu testen?
Zitat von: HCS am 10 Juni 2015, 17:55:09
@corny456: wärst Du so nett, diese Version kurz zu testen?
Hallo HCS,
Klar doch... :)
eingespielt und Läuft... Danke dir!
Gruß Marius
Hallo,
Also es scheint am sensor gelegen zu haben. Hab ihm neue Batterien verpasst und nochmals neu eingelernt ... jetzt geht er ... mal sehen wie lang ...
Grüsse
Edit: Fehler gefunden. Mein Nachbar hat an seinem Sender die Batterien gewechselt. Damit hatte der Sensor die gleiche id wie meiner.
Zitat von: HCS am 07 Juni 2015, 20:16:50
Es hatten schon mehrere Anwender nach Austausch der Spannungsversorgung das Problem dann nicht mehr.
Reden wir über einen Raspi als Server?
Also mit einem anderen Netzteil für den Raspberry Pi habe ich noch keine Aussetzer gehabt. Werde es aber nochmal tauschen müssen, da es mit 1A vielleicht etwas zu schwach ist.
Wie genau messen die TX29DTH-IT? Die Messwerte mehrerer Sensoren weichen um 1.0°C ab.
Kann man irgendwo einen Offset einstellen?
Zitat von: Kalli01 am 12 Juni 2015, 18:25:49Wie genau messen die TX29DTH-IT? Die Messwerte mehrerer Sensoren weichen um 1.0°C ab.
Kann man irgendwo einen Offset einstellen?
Meine sind auch nicht genauer.
define <name> LaCrosse <addr> [corr1...corr2]
addr is a 2 digit hex number to identify the LaCrosse device.
corr1..corr2 are up to 2 numerical correction factors, which will be added to the respective value to calibrate the device.
Ok das habe ich hin bekommen.
Jetzt wollte ich noch die resolution auf 2 setzen aber irgendwie ändert sich da die Luftfeuchtigkeit anstelle der Temperatur.
Mache ich da etwas falsch?
Zitat von: Kalli01 am 14 Juni 2015, 13:59:23
Jetzt wollte ich noch die resolution auf 2 setzen aber irgendwie ändert sich da die Luftfeuchtigkeit anstelle der Temperatur.
Hast Du doAverage gesetzt? Average wird nach resolution gerechnet. Wenn man also average gesetzt hat, kommt selten etwas raus, was der resolution entspricht.
Wäre mal zu überlegen, ob man das nicht rumdrehen sollte. Gibt es Meinungen dazu?
Nein doAverage habe ich nicht gesetzt.
Ich habe resolution jetzt mal auf 20 gesetzt, dann springt die Luftfeuchtigkeit von 48 auf 40. Bei der Temperatur ändert sich gar nichts.
Meiner Meinung nach sollte erst der Durchschnitt berechnet werden und danach gerundet werden.
ich denke man sollte beides entfernen und statt dessen das neue event-aggregator attribut verwenden.
gruss
andre
Zitat von: Kalli01 am 14 Juni 2015, 22:35:00
Ich habe resolution jetzt mal auf 20 gesetzt, dann springt die Luftfeuchtigkeit von 48 auf 40. Bei der Temperatur ändert sich gar nichts.
Die resolution wird in 10tel Grad angegeben, da macht 20 ja keinen Sinn.
Zitat von: justme1968 am 14 Juni 2015, 22:43:23ich denke man sollte beides entfernen und statt dessen das neue event-aggregator attribut verwenden.
Dann muss ich mir wohl mal das neue event-aggregator attribut anschauen...
Muss aber jetzt erst mal endlich dazu kommen, das autocreateThreshold und das geänderte Logging einzubauen
Zitat von: HCS am 04 Juni 2015, 19:34:40
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"
Habe mich hier gerade neu registriert um dir auf diesen Beitrag antworten zu können. Ich hatte nämlich erst gestern das Problem dass ich die Werte vom TX22 in einem eigenen Programm nicht richtig verarbeiten konnte, da das LowBattery-Flag gesetzt war. Bei meiner Suche habe ich bemerkt dass dein Code anscheinend dasselbe Problem hat bzw. haben dürfte.
Bei meiner WS1600 ist es nämlich so dass das LowBattery-Flag anscheinend im Bit nach dem Error-Flag gesendet wird, d.h. die weit verbreitete TX22 Analyse dürfte da nicht ganz korrekt sein - die Anzahl der Datenpakete besteht anscheinend nicht aus 4 Bit sondern nur aus 3, da es sich beim 4. Bit vorne um das LowBattery Flag handeln dürfte. Bei gesetzten LowBattery Flag wird ansonsten die Anzahl der Messwert-Pakete falsch interpretiert (Wert+8) und somit können die Datenpakete des TX22 nicht mehr verarbeitet werden.
Nachdem ich das bei mir entsprechend korrigiert habe klappt nun die Auswertung unabhängig vom Status des LowBattery-Flags.
D.h. in deinem Fall müsste ca. Folgendes funktionieren bzw. das Problem lösen (ungetestet!):
// byte ct = bytes[1] & 0xF;
byte ct = bytes[1] & 0x7;
frame->LowBatteryFlag = ((bytes[1] & 0xF) >> 3);
sowie dasselbe weiter unten:
byte TX22IT::GetFrameLength(byte data[]) {
//return 3 + 2 * (data[1] & 0xF);
return 3 + 2 * (data[1] & 0x7);
}
Hoffe das hilft - Korrekturen erwünscht :)
Zitat von: HCS am 14 Juni 2015, 22:56:06
Die resolution wird in 10tel Grad angegeben, da macht 20 ja keinen Sinn.
Das habe ich nur gemacht um eine deutliche Änderung zu sehen.
Nochmal mein Problem. Eine Änderung auf 1 oder 2 oder auch 5 wirkt sich nur auf die Luftfeuchtigkeit aus.
Ich würde aber gerne die Temperatur runden.
Verstehe ich das jetzt falsch?
Hallo Ihr alle
hat jemand Erfolg mit dem Einbinden von Funk-Außensensoren vom Typ TX4-868 (Temperatur u. Luftfeuchte) von LaCrosse?
Theoretisch sollte das mit dem JeeLink 868 funktionieren.
Urs
Zitat von: aj am 15 Juni 2015, 11:04:23Bei meiner WS1600 ist es nämlich so dass das LowBattery-Flag anscheinend im Bit nach dem Error-Flag gesendet wird, d.h. die weit verbreitete TX22 Analyse dürfte da nicht ganz korrekt sein - die Anzahl der Datenpakete besteht anscheinend nicht aus 4 Bit sondern nur aus 3, da es sich beim 4. Bit vorne um das LowBattery Flag handeln dürfte. Bei gesetzten LowBattery Flag wird ansonsten die Anzahl der Messwert-Pakete falsch interpretiert (Wert+8) und somit können die Datenpakete des TX22 nicht mehr verarbeitet werden.
Nachdem ich das bei mir entsprechend korrigiert habe klappt nun die Auswertung unabhängig vom Status des LowBattery-Flags.
D.h. in deinem Fall müsste ca. Folgendes funktionieren bzw. das Problem lösen (ungetestet!):
// byte ct = bytes[1] & 0xF;
byte ct = bytes[1] & 0x7;
frame->LowBatteryFlag = ((bytes[1] & 0xF) >> 3);
sowie dasselbe weiter unten:
byte TX22IT::GetFrameLength(byte data[]) {
//return 3 + 2 * (data[1] & 0xF);
return 3 + 2 * (data[1] & 0x7);
}
Hoffe das hilft - Korrekturen erwünscht :)
Hi, vielen Dank für diese Information. Genau das hat mir noch gefehlt. Das werde ich so übernehmen.
Hast Du das LowBattery flag experimentell durch runterregeln der Spannung ermittelt?
Dann bleibt noch ein Rätsel: ab und zu sendet der TX22 seltsame Pakete, bei denen das error flag gesetzt ist und eine Windgeschwindigkeit von 25.4 m/s übertragen wird. Zu diesen Zeitpunkten verschwindet auch die Wind-Geschwindigkeit und -Richtung auf der Basisstation. Hast Du das auch beobachtet und dazu evtl. auch eine Erklärung?
Dich extra zu registrieren um mir den Tip zu geben ist grandios. Danke!
Zitat von: Kalli01 am 15 Juni 2015, 17:08:20Nochmal mein Problem. Eine Änderung auf 1 oder 2 oder auch 5 wirkt sich nur auf die Luftfeuchtigkeit aus.
Ich würde aber gerne die Temperatur runden.
Gerade nochmal den code studiert und ausprobiert. resolution wirkt bei mir auf humidity und temperature, habe 2, 5 und 10 getestet. Sobald der nächste Wert reinkommt, hat auch die temperature den korrekt gerundeten Wert.
Welche Version hat Deine 36_LaCrosse.pm denn?
Zitat von: Kalli01 am 15 Juni 2015, 17:08:20
Verstehe ich das jetzt falsch?
Eigentlich nicht.
Zitat von: uwirt am 16 Juni 2015, 11:57:50
Hallo Ihr alle
hat jemand Erfolg mit dem Einbinden von Funk-Außensensoren vom Typ TX4-868 (Temperatur u. Luftfeuchte) von LaCrosse?
Theoretisch sollte das mit dem JeeLink 868 funktionieren.
Urs
Also ich bin mir nicht ganz sicher, aber ich glaube schon, dass der TX4 ein anderes Protokoll sendet.
Zitat von: HCS am 16 Juni 2015, 20:12:45
Gerade nochmal den code studiert und ausprobiert. resolution wirkt bei mir auf humidity und temperature, habe 2, 5 und 10 getestet. Sobald der nächste Wert reinkommt, hat auch die temperature den korrekt gerundeten Wert.
Welche Version hat Deine 36_LaCrosse.pm denn?
Eigentlich nicht.
Wie ich die Version her raus bekomme weiß ich nicht aber das sollte helfen:# $Id: 36_LaCrosse.pm 8689 2015-06-04 14:42:19Z hcs-svn $
Mein Problem habe ich auch gefunden. Ich habe immer nur nach dem state geschaut und mich gewundert das es nicht klappt.
Es liegt an corr1 den habe ich auf zB 0.3 gesetzt. Wenn ich das richtig verstanden habe wird erst gerundet und danach noch der offset dazu addiert.
Ich bin davon ausgegangen das erst ganz zum schluss gerundet wird.
Wie ist denn das mit corr1, doAverage und resolution gedacht?
Zitat von: justme1968 am 08 Juni 2015, 21:44:29
das einfachste ist vermutlich wenn du $hash->{AutoCreate} = { "LaCrosse.*" => { autocreateThreshold => "2:60" } };
oder ähnlich direkt in LaCrosse_Initialize einbaust.
Eingebaut und eingecheckt. Default ist 2:120 was bedeutet, dass der Sensor innerhalb zwei Minuten zwei mal empfangen werden muss, um ein autocreate auszulösen.
Das geänderte logging für
"Unknown device xx, please define it" habe ich ebenfalls eingebaut und in der commandref beschrieben.
Kommt dann morgen mit dem Update.
Zitat von: Kalli01 am 16 Juni 2015, 21:29:25
Ich bin davon ausgegangen das erst ganz zum schluss gerundet wird.
Wie ist denn das mit corr1, doAverage und resolution gedacht?
Ich werde es wohl ändern, und die resolution erst am Schluss rechnen. Scheint mir sinnvoll.
Zitat von: justme1968 am 14 Juni 2015, 22:43:23
ich denke man sollte beides entfernen und statt dessen das neue event-aggregator attribut verwenden.
Nach dem, was ich aktuell über das neue event-aggregator attribut weiß, denke ich, dass man damit doAverage erledigen könnte aber resolution nicht.
Zumindest nach der aktuellen Diskussion, die ich gelesen habe, erzeugt der ja noch mehr Nachkommastellen.
Zitat von: HCS am 16 Juni 2015, 19:55:38
Hi, vielen Dank für diese Information. Genau das hat mir noch gefehlt. Das werde ich so übernehmen.
Hast Du das LowBattery flag experimentell durch runterregeln der Spannung ermittelt?
Nein, das wäre der wissenschaftlich/technische Zugang - bei mir sind schlicht und ergreifend die Batterien leer geworden. Ich wollte zufällig ein eigenes altes Programm zur Datenerfassung ausprobieren und habe festgestellt dass es die Pakete der Wetterstation nicht mehr "verstanden" hat - da habe ich dann angefangen mir die Pakete genauer anzusehen und auch mit neuen vs. alten Batterien zu experimentieren. Bei der weiteren Suche, ob noch jemand dieses Problem hat(te), bin ich dann auf deinen Code gestossen.
Zitat von: HCS am 16 Juni 2015, 19:55:38
Dann bleibt noch ein Rätsel: ab und zu sendet der TX22 seltsame Pakete, bei denen das error flag gesetzt ist und eine Windgeschwindigkeit von 25.4 m/s übertragen wird. Zu diesen Zeitpunkten verschwindet auch die Wind-Geschwindigkeit und -Richtung auf der Basisstation. Hast Du das auch beobachtet und dazu evtl. auch eine Erklärung?
Ist mir noch nicht aufgefallen. Ich habe allerdings (noch) keine permanente Auswertung laufen.
OK, dann muss ich mal alle Pakete mit gesetztem error flag separat loggen und schauen, ob sich da ein System und Sinn erkennen lässt.
Habe die Reihenfolge der Berechnungen geändert.
Auf die eingegangenen Werte werden zuerst die Korrekturfaktoren (corr1 / corr2) gerechnet und filterThreshold wird geprüft
Wenn OK, wird average und dewpoint gerechnet
Am Schluss wird resolution gerechnet
Die internals bedeuten folgendes:
rawT/H: die tatsächlich vom Sensor gelieferten Werte
previousT/H: mit corr1/2 korrigiert und avarage gerechnet
Die readings (temperature und humidity) sind dann ggf. mit resoultion versehen.
Kommt morgen mit dem Update.
Hallo zusammen,
ich habe heute einen neuen jeelink erhalten und eingebunden. Dann einen Sensor angelernt mit lacrosse. Hat alles soweit funktioniert. Leider werden aber weder im Jeelink noch bei dem Sensor logilfes erzeigt. aus dem FHEM Log werde ich nicht richtig schlau. Welchen Befehl kann ich eingeben um das zu fixen ?
Danke für eure Hilfe!!!! und ein Auszug aus dem Logfile des FHEM:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (25248 bytes):
Writing | ################################################## | 100% 3.67s
avrdude: 25248 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 25248 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.82s
avrdude: verifying ...
avrdude: 25248 bytes of flash verified
avrdude done. Thank you.
2015.07.14 15:18:18 3: Opening myJeeLink device /dev/ttyUSB0
2015.07.14 15:18:18 3: Setting myJeeLink serial parameters to 57600,8,N,1
2015.07.14 15:18:18 3: myJeeLink device opened
2015.07.14 15:25:26 2: autocreate: define LaCrosse_32 LaCrosse 32
2015.07.14 15:25:26 3: LaCrosse_32: I/O device is myJeeLink
2015.07.14 15:25:26 2: autocreate: define FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log
2015.07.14 15:25:26 1: define FileLog_LaCrosse_32 FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log : wrong syntax: define <name> FileLog filename regexp [readonly]
Zitat von: baybod am 14 Juli 2015, 19:54:59
Hallo zusammen,
ich habe heute einen neuen jeelink erhalten und eingebunden. Dann einen Sensor angelernt mit lacrosse. Hat alles soweit funktioniert. Leider werden aber weder im Jeelink noch bei dem Sensor logilfes erzeigt. aus dem FHEM Log werde ich nicht richtig schlau. Welchen Befehl kann ich eingeben um das zu fixen ?
Danke für eure Hilfe!!!! und ein Auszug aus dem Logfile des FHEM:
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (25248 bytes):
Writing | ################################################## | 100% 3.67s
avrdude: 25248 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 25248 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 2.82s
avrdude: verifying ...
avrdude: 25248 bytes of flash verified
avrdude done. Thank you.
2015.07.14 15:18:18 3: Opening myJeeLink device /dev/ttyUSB0
2015.07.14 15:18:18 3: Setting myJeeLink serial parameters to 57600,8,N,1
2015.07.14 15:18:18 3: myJeeLink device opened
2015.07.14 15:25:26 2: autocreate: define LaCrosse_32 LaCrosse 32
2015.07.14 15:25:26 3: LaCrosse_32: I/O device is myJeeLink
2015.07.14 15:25:26 2: autocreate: define FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log
2015.07.14 15:25:26 1: define FileLog_LaCrosse_32 FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log : wrong syntax: define <name> FileLog filename regexp [readonly]
Probiere es mal so
define FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log FileLog_LaCrosse_32
Mobil erstellt daher kurz gehalten
Hallo,
danke dafür!!!! Jetzt wird ein LOG angelegt, aber leider wird es nicht mit Daten gefüllt, so dass es einfach leer ist. An was kann das liegen?
Danke für eure Hilfe!!!!!
lg
Baybod
define FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log FileLog_LaCrosse_32
logt was wohin ? das FileLog ins FileLog ?
ich würde da
define FileLog_LaCrosse_32 FileLog ./log/LaCrosse_32-%Y.log LaCrosse_32
benutzen :)
Ist doch klasse .. hast ein Backup vom filelog. ..
Wutz hat recht .. mein fehler
Mobil erstellt daher kurz gehalten
Hallo, danke euch, das war es !!!!
Habe zwar noch ein paar Themen mit der graphischen Darstellung, aber das ist ein anderes Thema. Tolle Hilfe von Euch!!!!
Gruss
Baybod
Vielleicht hilft Dir das weiter; Definition eines LaCrosse-Sensors am JeeLink-Clone bei mir.
## Temperatursensor Aussen ##
define Sensor_02 LaCrosse 3B
attr Sensor_02 IODev myJeeLink
attr Sensor_02 alias Außensensor
attr Sensor_02 event-min-interval state:300,temperature:300,humidity:300,battery:3600
attr Sensor_02 group Wetter
attr Sensor_02 room Umwelt
define FileLog_Sensor_02 FileLog ./log/Sensor_02-%Y.log Sensor_02:T:.*
attr FileLog_Sensor_02 logtype temp4hum6:Temp/Hum,text
attr FileLog_Sensor_02 room LaCrosse
define SVG_FileLog_Sensor_02_1 SVG FileLog_Sensor_02:SVG_FileLog_Sensor_02_1:CURRENT
attr SVG_FileLog_Sensor_02_1 label "Außentemperatur - min: $data{min1}°C max: $data{max1}°C akt: $data{currval1}°C"
Ich habe gerade eine neue Version vom LaCrosse Modul eingecheckt.
filterThreshold hat nicht mehr funktioniert. Ist repariert und sollte (wenn SourceForge will) morgen mit dem Update kommen.
SuperJee
Vorab: alles was nun kommt ist optional, für "normale" JeeLinks/Clone ändert sich nichts.
Wer einen Clone gebastelt hat, kann diesen mit einer oder beiden der folgenden Optionen erweitern.
Option 1 (Dual RFM):
Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
Der zweite RFM wird parallel zum ersten angeschlossen (Antenne natürlich eine eigene), nur NSS (also der Chipselect) wird am Arduino an PB0 angeschlossen (siehe angehängte SuperJee-CL.png)
Der Sketch erkennt automatisch, ob der zweite RFM angeschlossen und ob es ein 12er oder 69er ist und verwendet ihn dann entsprechend.
Um den zweiten RFM zu konfigurieren, werden folgende Commands (die natürlich in InitCommands gesetzt werden können) verstanden:
R - DataRate
F - Frequenz
M - Toggle Mode
T - Toggle Time
Das entspricht den Commands wie bisher für den ersten RFM, nur dass es Großbuchstaben sind.
Option 2 (BMP180):
Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Desshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe angehängte SuperJee-CL.png)
Wenn ein BMP180 erkann wurde, sendet der Sketch alle 10 Sekunden den Luftdruck und die Temperature an FHEM, so als ob es eine Wetterstation wäre.
Die Adresse dieses "Fake-Sensors" ist 00.
Da der BMP180 den absoluten Luftdruck liefert, es aber üblich ist, dass der Luftdruck auf NN bezogen angegeben wird, kann dem Sketch die Höhe über NN gesetzt werden. Dazu versteht er das Command "h" Beispiel: "set myJeeLink raw 220h" legt fest, dass sich der Sensor auf 220m befindet.
Der Sketch rechnet dann den Luftdruck auf NN bezogen um und er sollte dann mit der Anzeige der Wetterstation usw. übereinstimmen.
Wenn man mit der Höhe etwas "mogelt", kann man den Sensor damit auch "kalibrieren"
Weitere Infos dazu:
SuperJee-CL.png:
Schaltplan (nur die Erweiterungen)
myJeeLink.png:
Beispiel mit einem voll aufgerüsteten Clone. Zwei RFM69CW, einer läuft mit 8842 und empfängt exclusiv die WS 1600, der zweite toggelt alle 20 Sekunden zwischen 17241 und 9579 um die TX29 und TX35 zu empfangen.
NodeSensorsDefinition.png und NodeSensorsPlot.png:
Die Definition für den BMP180, ist ein ganz normales LaCrosse mit der Adresse 00 und ein Plot dazu
SuperJee-JNUSB.png:
Ein Beispiel, wie man das auf einem JeeNode-USB aufbauen kann (mit RFM69CW und BMP180)
SuperJee-JN1.png und SuperJee-JN2.png:
Ein Beispiel, wie man das auf einem JeeNode aufbauen kann (mit RFM12B und BMP085)
SuperJee-LR.png:
Beispiel Lochraster.
Beispiel initCommands:
0m 0t 2r 3M 0R 20T 868300f 220h 0a v
Erster RFM: kein toggle und 8842 kbps
Zweiter RFM: 20 Sekunden toggle zwischen 17241 und 9579 kbps
868300 MHz
Sensor über NN = 220 Meter
Activity LED aus
Zu beachten:
Das ist alles 3,3V. Wenn ihr auf einem 5V Arduino seid, dann Pegelanpassung usw. beachten.
Das funktioniert ab Sketch Version 10.1k aufwärts und mit einem aktuellen 36_LaCrosse.pm. Beides ist eingecheckt und kommt morgen mit dem Update.
Sonstiges:
In dieser Version ist auch die LowBattery Erkennung der WS 1600 korrekt implementiert. Danke nochmal an aj.
@Billy: bist Du noch der "Wiki-Man"?
falls ja, wäre das super im Wiki aufgehoben, sonst findet es bald keiner mehr hier im Giga-Thread.
Prima Idee, hab es mal bei mir verbloggt.
http://blog.moneybag.de/fhem-jeelink-jetzt-erweitert-superjee/
LG
/robin
checkst auch noch das hex file unter FHEM/firmware ein ?
gruss
andre
Zitat von: justme1968 am 28 Juli 2015, 10:00:54
checkst auch noch das hex file unter FHEM/firmware ein ?
gruss
andre
Habe ich vor 13 Stunden getan. Siehe: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/firmware/
sorry. dann habe ich beim svn update aus irgend einem grund übersehen.
gruss
andre
@justme1968: würdest Du diesen Patch in die 36_JeeLink.pm übernehmen?
Hintergrund: ich würde gerne von extern dem JeeLink Modul Daten unterschieben, die es so weiter verarbeitet, als ob es über die Serielle gekommen wäre.
Also so:
.../fhem?XHR=1&cmd=set myJeeLink data OK 9 48 1 4 188 80
Sketch V10.1m
Es kam vor, dass der RFM69 (der RFM12 nicht) bei der data rate 9579kbps Pakete vom der WS 1600 empfangen hat, obwohl die mit 8842kbps sendet.
Diese Pakete waren aber meistens Müll, haben manchmal den CRC-Check bestanden und das Ergebnis lag manchmal auch noch innerhalb von filterTreshold, mit der Folge, dass Müll geloggt wurde.
Ich habe den Handlern für die verschiedenen Sensor-Typen nun beigebracht, mit welchen data rates der jeweilige Sensor-Typ läuft und behandle die Daten nur noch dann, wenn die Daten mit einer data rate empfangen wurden, die zu dem Sensor passt.
Kommt dann morgen mit dem Update.
ich hab mir erlaubt das kommando in parse umzubenennen und es eben eingecheckt.
gruss
andre
ps: ich weiss nicht was du genau machen möchtest aber der jeelink sollte fhem2fhem raw fähig sein. hast du das mal probiert? ser2net geht auch. du kannst du daten z.b. auch per netcat los werden.
Das Problem meines Vorgängers scheint mit der aktuellen Version des Moduls noch immer zu bestehen:
2015.08.02 12:16:48 2: autocreate: define LaCrosse_35 LaCrosse 35
2015.08.02 12:16:48 3: LaCrosse_35: I/O device is myJeeLink
2015.08.02 12:16:48 2: autocreate: define FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log
2015.08.02 12:16:48 1: define FileLog_LaCrosse_35 FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log : wrong syntax: define <name> FileLog filename regexp [readonly]
2015.08.02 12:16:48 1: ERROR: wrong syntax: define <name> FileLog filename regexp [readonly]
beim autocreate kommt es zu einer Dopplung des Namens
define FileLog_LaCrosse_35 FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log
Habe das Log manuell angelegt bekommen...
Wäre schön wenn der Maintainer des Moduls sich diesem Bug annehmen könnte.
Zitat von: justme1968 am 02 August 2015, 10:27:40
aber der jeelink sollte fhem2fhem raw fähig sein
Nein, nicht
sollte sondern
ist :)
Zitat von: christianb am 02 August 2015, 15:35:05
Das Problem meines Vorgängers scheint mit der aktuellen Version des Moduls noch immer zu bestehen:
2015.08.02 12:16:48 2: autocreate: define LaCrosse_35 LaCrosse 35
2015.08.02 12:16:48 3: LaCrosse_35: I/O device is myJeeLink
2015.08.02 12:16:48 2: autocreate: define FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log
2015.08.02 12:16:48 1: define FileLog_LaCrosse_35 FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log : wrong syntax: define <name> FileLog filename regexp [readonly]
2015.08.02 12:16:48 1: ERROR: wrong syntax: define <name> FileLog filename regexp [readonly]
beim autocreate kommt es zu einer Dopplung des Namens
define FileLog_LaCrosse_35 FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log
Habe das Log manuell angelegt bekommen...
Wäre schön wenn der Maintainer des Moduls sich diesem Bug annehmen könnte.
Ich schaue es mir an.
Das ist nicht nur vorne doppelt. Hinten fehlt auch was.
@justme1968:Zitat von: christianb am 02 August 2015, 15:35:05
2015.08.02 12:16:48 2: autocreate: define LaCrosse_35 LaCrosse 35
2015.08.02 12:16:48 3: LaCrosse_35: I/O device is myJeeLink
2015.08.02 12:16:48 2: autocreate: define FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log
2015.08.02 12:16:48 1: define FileLog_LaCrosse_35 FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log : wrong syntax: define <name> FileLog filename regexp [readonly]
2015.08.02 12:16:48 1: ERROR: wrong syntax: define <name> FileLog filename regexp [readonly]
beim autocreate kommt es zu einer Dopplung des Namens
define FileLog_LaCrosse_35 FileLog_LaCrosse_35 FileLog /opt/fhem/log/LaCrosse_35-%Y.log
Das hat irgend was mit dem autocreateThreshold zu tun.
$hash->{AutoCreate} = { "LaCrosse.*" => { autocreateThreshold => "2:120" } };Wenn ich den aus der Initialisierung vom LaCrosse Modul rausnehme funktioniert es korrekt. Ist er drin, macht das Autocreate beim Anlegen des FileLog etwas falsch.
Das LaCrosse Modul gib in der LaCrosse_Parse "UNDEFINED LaCrosse_35 LaCrosse 35" zurück
Allerdings durchschaue ich das Autocreate Modul nicht so recht, um dahinter zu kommen, wo es da klemmt.
Zitat von: HCS am 27 Juli 2015, 23:32:02
SuperJee
@Billy: bist Du noch der "Wiki-Man"?
falls ja, wäre das super im Wiki aufgehoben, sonst findet es bald keiner mehr hier im Giga-Thread.
@HCS
habe soeben versucht den "Wiki-Man" zu spielen und die WS 1600 sowie den Super Jee eingearbeitet.Mit den entsprechenden Links.
Wenns einer noch besser kann gerne. ;)
Edit: noch eine Frage.
Funktioniert die Relay Möglichkeit mit den Super Jee noch?
Gruß Billy
Guten Morgen,
wenn ich die Version 10.1m auf den Arduino Nano spielen möchte, bricht er mit dieser Fehlermeldung ab "Binäre Sketchgröße: 31.196 Bytes (von einem Maximum von 30.720 Bytes)"
Hat meiner jetzt zu wenig Speicher oder wie habt ihr die Version aufgespielt?
Kalli
Hallo,
bei mir das gleiche, bin erstmal zu alten Firmware zurück.
Ronny
Seltsam, ich habe die auf mehreren drauf.
Wie versucht ihr denn die draufzuspielen? mit "set myJeeLink flash" oder mit der Arduino IDE?
Spielt ihr das binärfile aus dem ZIP bzw. aus FEHM/firmware drauf oder compiliert ihr und spielt das drauf?
Über Fhem habe ich es zuerst versucht nur hat er dort beim Überprüfen einen Fehler festgestellt.
Dann habe ich es über die Arduino IDE versucht. Also die 36_LaCrosse-LaCrosseITPlusReader.zip her runter geladen und die LaCrosseITPlusReader10.ino geöffnet.
Dort zeigt er dann beim Überprüfen den Fehler an.
Ich habs nach dem FHEM Update per "set JELINK1 flash" probiert
Flash Befehl ist
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Klappte immer problemlos.
Beim letzten Flash kam das folgende und der JeeLink war nichtmehr nutzbar (auch im Seriellen kam keine Ausgabe). Auch ein manuelles Flashen, zeigte den gleichen Fehler und keine Funktion.
Ich hab dann die alte Firmware geflasht aus dem RestoreOrdner und alles ist wieder ok.
Flash Log:
# cat JeeLinkFlash.log
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.01s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (30962 bytes):
Writing | ################################################## | 100% 9.98s
avrdude: 30962 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 30962 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 8.25s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x7800
0x20 != 0x0c
avrdude: verification error; content mismatch
avrdude done. Thank you.
Die Firmware hat folgende md5
# md5sum JeeLink_LaCrosse.hex
8a3fdac07a0c8eab8a9716470d5755ad JeeLink_LaCrosse.hex
HTH Ronny
OK, der MD5 von meiner JeeLink_LaCrosse.hex ist auch 8A3FDAC07A0C8EAB8A9716470D5755AD
Gerade nochmal aus FHEM geflasht mit set myJeeLink flash.
Hat funktioniert und läuft, siehe unten.
Wobei, ich könnte es vermutlich wieder weglöschen, denn ich glaube, dass mir das Problem gerade klar wird.
Ich habe auf meinen Arduinos den optibootloader drauf, der ist deutlich kleiner (512 Bytes) als der, den der Nano drauf hat (2k).
Das macht wohl den Unterschied zwischen passt und passt nicht drauf.
30962 bytes Sketch + 2048 Bytes bootloader = 32974 Bytes = zu groß da > 32768 Bytes
30962 bytes Sketch + 512 Bytes bootloader = 31438 Bytes = passt da < 32768 Bytes
Deckt sich dann auch mit dem Ergebnis von Kalli01. Seine 30.720 freien Bytes sind 32k flash size minus 2k boot loader.
Dann muss ich den Sketch etwas eindampfen, dass er auch auf die Nanos geht.
Ein JeeLink hat übrigens auch den optiboot drauf, da funktioniert das.
Sollte nicht ein Clone exakt gleich ... egal, gilt wohl nur bei Schafen :-)
Kann aber ein zwei Tage dauern.
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (30962 bytes):
Writing | ################################################## | 100% 4.71s
avrdude: 30962 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 30962 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.70s
avrdude: verifying ...
avrdude: 30962 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Zitat von: Billy am 03 August 2015, 19:31:46Edit: noch eine Frage.
Funktioniert die Relay Möglichkeit mit den Super Jee noch?
Ja
Zitat von: Billy am 03 August 2015, 19:31:46
habe soeben versucht den "Wiki-Man" zu spielen und die WS 1600 sowie den Super Jee eingearbeitet.
Gruß Billy
Prima, der Dank aller Info-Suchenden ist Dir sicher.
Sieht gut aus.
Zitat von: justme1968 am 02 August 2015, 10:27:40ich hab mir erlaubt das kommando in parse umzubenennen und es eben eingecheckt.
parse ist prima, Danke!
Zitat von: justme1968 am 02 August 2015, 10:27:40ps: ich weiss nicht was du genau machen möchtest aber der jeelink sollte fhem2fhem raw fähig sein. hast du das mal probiert? ser2net geht auch. du kannst du daten z.b. auch per netcat los werden.
Ich will vom ESP8266 aus die LaCrosse Daten loswerden und dem JeeLink Modul unterschieben, als ob es sie von einem angeschlossenen Stick bekommen hätte.
fhem2fhem würde bedeuten, dass ich so tue, als ob ich ein FHEM wäre? Muss ich mir mal anschauen, wie da kommuniziert wird.
Aktuell habe ich einen Probebetrieb laufen, bei dem ein ESP8266 mit einem RFM69 und einem BMP180 LaCrosse empfängt und dem JeeLink über das Frontend die Daten unterjubelt.
Also so:
... fhem?XHR=1&cmd=set myJeeLink parse OK 9 48 1 4 188 80
Das läuft seit einer Woche stabil, ist aber eher POC. Um Logs zu bekommen, dass ich beurteilen kann, ob die Daten dauerhaft korrekt kommen, ist's aber OK.
Wie ich es im Endausbau kommunizieren lasse, muss ich noch überlegen.
kann der ESP8266 nicht auch einfach den uart auf einem port weiter reichen? dann wäre das einfachste in fhem das jeelink device einfach mit <ip>:<port> zu konfigurieren.
gruss
andre
Hatte noch einen Jee-Node USB V03 rumliegen mit BMP180 erweitert, soeben problemlos geflasht und kann u.a. bestätigen. :)
model
[LaCrosseITPlusReader.10.1m (RFM12B f:868300 t:30~3) + BMP180]Zitat von: HCS am 05 August 2015, 18:22:36
OK, der MD5 von meiner JeeLink_LaCrosse.hex ist auch 8A3FDAC07A0C8EAB8A9716470D5755AD
Gerade nochmal aus FHEM geflasht mit set myJeeLink flash.
Hat funktioniert und läuft, siehe unten.
Ein JeeLink hat übrigens auch den optiboot drauf, da funktioniert das.
Werde jetzt noch den RFM69CW mit draufpacken, mir die Wetterstation WS1600 zulegen und die Ergebnisse (insbesondere Regenmenge) mit meiner
OREGON WMR928 vergleichen. (5 J alt 344,--€) zu WS1600 85,--€
Gruß Billy
Zitat von: justme1968 am 06 August 2015, 13:43:13kann der ESP8266 nicht auch einfach den uart auf einem port weiter reichen? dann wäre das einfachste in fhem das jeelink device einfach mit <ip>:<port> zu konfigurieren.
Werde es mal so versuchen
Schaust Du da bitte mal noch drauf?
http://forum.fhem.de/index.php/topic,14786.msg318766.html#msg318766
hat die Meldung
PERL WARNING: Odd number of elements in anonymous hash at /data/fhem//FHEM/36_LaCrosse.pm line 151was zu bedeuten?
Kam nach Installation
Zitat[LaCrosseITPlusReader.10.1m (RFM12B f:868300 t:30~3) + BMP180]
und "shutdown restart"
Edit: Obige Meldung ist nicht mehr reproduzierbar!
Edit zusätzliche Frage?
Kann es sein, dass die Höhenangabe für den Luftdruck nach jedem shutdown restart mit
z.B "set myJeeLink raw 220h" neu gesetzt werden muß? Sorry: Hat sich auch erledigt. Kann ja ins init command aufgenommen werden: mit initCommands 220h
Nochmals vielen dank für die gute Arbeit
Billy
Sketch V10.1n
Ich habe die Größe reduziert, nun sollte er auch wieder auf Arduinos mit 2k Bootloader passen.
Um die Größe zu reduzieren, habe ich die Sendefunktionalität ausgedeft.
Ganz oben ist ein
////#define TRANSMITTER
Damit kann man die Senderei ggf. wieder aktivieren (die //// wegnehmen)
Wenn sich in den nächsten Wochen niemand meldet, der sie verwendet, nehme ich sie endgültig raus.
Ist eingecheckt und sollte morgen mit dem Update kommen.
Dieses mal konnte ich es über Fhem flashen
Tolle Arbeit, ich konnte auch über Fhem flashen und funktioniert!
[LaCrosseITPlusReader.10.1n (None f:868300 t:30~7)]
Einen Luftdruck-Sensor BMP180 werde ich auch bald mit einbauen
LG
/robin
Zitat von: fh168 am 09 August 2015, 20:18:18[LaCrosseITPlusReader.10.1n (None f:868300 t:30~7)]
Hast Du tatsächlich keinen RFM angeschlossen oder hat da die Erkennung versagt?
Bei mir sieht das jetzt mit dem RFM69CW und dem BMP180 so aus! :)
model
[LaCrosseITPlusReader.10.1m (None f:868300 t:30~3) + (RFM69CW f:868300 r:8842) + BMP180]
Tolle Arbeit vielen Dank.
Billy
Zitat von: Billy am 09 August 2015, 21:53:15[LaCrosseITPlusReader.10.1m (None f:868300 t:30~3) + (RFM69CW f:868300 r:8842) + BMP180]
Noch ein None :(
Das sollte eigentlich so aussehen:
[LaCrosseITPlusReader.10.1n (RFM12B f:868300 r:8842) + (RFM12B f:868300 t:20~3) + BMP180]Warum geht denn die Erkennung bei mir und bei euch nicht?
Stimmt, müsste bei mir eigentlich so aussehen
model
[LaCrosseITPlusReader.10.1m (RFM12B f:868300 t:30~3) + (RFM69CW f:868300 r:8842) + BMP180]
Funktioniert aber alles. Was kann ich tun?
Billy
[/quote]
Zitat von: justme1968 am 06 August 2015, 13:43:13
kann der ESP8266 nicht auch einfach den uart auf einem port weiter reichen? dann wäre das einfachste in fhem das jeelink device einfach mit <ip>:<port> zu konfigurieren.
Habe ich mal so implementiert auf dem ESP.
Das funktioniert generell ganz gut. Allerdings gibt es noch ein Problem:
Wenn der ESP8266 im Netzwerk verschwindet, merkt das JeeLink Modul davon nichts. Es bleibt unbeirrt auf "opened" bzw. "initialized" und versucht darum auch nicht, wieder mit dem ESP zu verbinden, wenn er wieder auftaucht.
Es müsste ähnlich wie bei "disconnected" alle Minute schauen, ob der Port noch da ist und ggf. dann auf "disconnected" gehen.
Hallo,
10.1n geflasht, alles ok.
RFM wird auch erkannt:
[LaCrosseITPlusReader.10.1n (RFM12B f:868300 r:17241)]
Zitat von: Billy am 09 August 2015, 22:21:35Funktioniert aber alles. Was kann ich tun?
Ja, funktioniert, weil der Sketch davon ausgeht, dass der erste RFM ein RFM12 ist, wenn nicht RFM69 ermittelt wurde.
Trotzdem ist es unschön, dass die Erkennung es nicht hinbekommt.
Beschreib mal bitte genau Deinen Hardware-Aufbau.
Zitat von: rcmcronny am 09 August 2015, 22:53:11RFM wird auch erkannt:
[LaCrosseITPlusReader.10.1n (RFM12B f:868300 r:17241)]
@rcmcronny: Prima. kannst Du bitte kurz schreiben, was Du an Hardware verwendest?
Um das zu analysieren muss ich einen Aufbau hinbekommen, bei dem der RFM12 nicht erkannt wird.
Moin,
ich hab nen Jeelink Clone vom Robin, also nen Nano mit RFM12B Modul drauf.
Ronny
Zitat von: HCS am 09 August 2015, 22:57:51
Beschreib mal bitte genau Deinen Hardware-Aufbau.
Im Einsatz ist ein
original Jeenode USB V3Verdrahtung wie in deinem Beispiel
« Antwort #1289 am: 27 Juli 2015, 23:32:02 »SuperJee-JNUSB.png: --> Ein Beispiel, wie man das auf einem JeeNode-USB aufbauen kann (mit RFM69CW und BMP180)
Der einzig für mich erkennbare Unterschied dass bei dir die Version5 des Jeenode USB im Einsatz ist.
Gruß Billy
Übrigens wird bei meinem original Jeelink auch none angezeigt.model --> [LaCrosseITPlusReader.10.1m (None f:868300 t:30~3)]
Hallo,
jetzt wollte ich mal meinen Jeelink flashen. Irgendwie klappt es aber nicht. Kann mir einer einenTipp geben woran es hängen könnte? Ich weiß, daß es schonmal geklappt hat. Ist aber schon ein bisserl her.
Angefügt hab ich die Meldung, die ich beim flashen bekomme. Die -v Parameter habe ich eingefügt um mehr Infos zu bekommen.
gestartet habe ich mit
set myJeeLink flash LaCrosseZitatflashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -v -v -v -v -p atmega328P -c arduino -b 57600 -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: Version 5.11.1, compiled on May 23 2012 at 11:08:25
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyUSB0
Using Programmer : arduino
Overriding Baud Rate : 57600
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: ser_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Danke schonmal
Reinhard
Was sagen die Logs?
z.B. ./log/JeeLinkFlash.log
Nimm mal das
-b 57600
raus.
Das obige Zitat ist die Bildschirmausgabe beim flashen, als auch der Logeintrag.
Ohne dem -b Parameter habe ich genau das gleiche Ergebnis.
Sorry.
Im FHEM-Log habe ich folgendes stehen:
Zitat2015.08.10 17:02:57 3: Opening myJeeLink device /dev/ttyUSB0
2015.08.10 17:02:57 3: Setting myJeeLink serial parameters to 57600,8,N,1
2015.08.10 17:02:57 3: myJeeLink device opened
Zitat von: Laffer72 am 10 August 2015, 17:09:46
Das obige Zitat ist die Bildschirmausgabe beim flashen, als auch der Logeintrag.
Ohne dem -b Parameter habe ich genau das gleiche Ergebnis.
Sorry.
Im FHEM-Log habe ich folgendes stehen:
avrdude mal neu installiert?
Zitat von: Laffer72 am 10 August 2015, 17:09:46
2015.08.10 17:02:57 3: myJeeLink device opened
ist denn /dev/ttyUSB0 auch der JL ?
was sagt denn
ls -l /dev/serial/by-id/ ?
Zitat von: Billy am 10 August 2015, 09:29:34Übrigens wird bei meinem original Jeelink auch none angezeigt.
Wird bei mir auch mit einem original JeeLink korrekt erkannt.
Bin etwas ratlos ...
Zitat von: Laffer72 am 10 August 2015, 11:02:55
Hallo,
jetzt wollte ich mal meinen Jeelink flashen. Irgendwie klappt es aber nicht. Kann mir einer einenTipp geben woran es hängen könnte? Ich weiß, daß es schonmal geklappt hat. Ist aber schon ein bisserl her.
Angefügt hab ich die Meldung, die ich beim flashen bekomme. Die -v Parameter habe ich eingefügt um mehr Infos zu bekommen.
gestartet habe ich mit
set myJeeLink flash LaCrosse
Danke schonmal
Reinhard
hatte ähnliches Problem. Habe folgendes gemacht:
- JeeLink entfernt und Raspberry neugestarted
- JeeLink neu eingesteckt
- Flashen gestartet mit 57600 baud.
Manchmal kann auch ein USB Hub die Ursache sein
@Billy: kannst Du bitte mal mit dem Angehängten schauen, ob das "none" weg ist?
Zitat von: HCS am 10 August 2015, 21:58:19
@Billy: kannst Du bitte mal mit dem Angehängten schauen, ob das "none" weg ist?
Interessant:
Beim Jeelink kommt jetzt --> model [LaCrosseITPlusReader.10.1o (
RFM12B f:868300 t:30~7)]
Beim Jeenode USB --> model [LaCrosseITPlusReader.10.1o (
None f:868300 t:30~3) + (RFM69CW f:868300 r:8842) + BMP180]
Immerhin schon einen Schritt weiter :)
Billy
@ Andre
in der Tree [r9058] / trunk / fhem / contrib / JeeStuff / gibt es aus 2011 Zeit noch eine z.B 00_JeeLink.pm
Das könnte man doch löschen ist aus meiner Sicht mit dem was ab 2013 entstanden ist obsolet?
Könnte unnötig zur Verwirrung führen.
Gruß Billy
Zitat von: Billy am 10 August 2015, 22:13:59Immerhin schon einen Schritt weiter :)
Ja, und der Sache auf der Spur. Das ist wohl ein Timing-Problem beim Check.
@Billy: neuer Versuch
Zitat von: HCS am 11 August 2015, 21:32:59
@Billy: neuer Versuch
Sorry hat etwas länger gedauert!
Leider immer noch
model [LaCrosseITPlusReader.10.1o (
None f:868300 t:30~3) + (RFM69CW f:868300 r:8842) + BMP180]
Gruß Billy
Hallo,
danke für Eure Antworten. Leider hat nichts gefruchtet.
Nachdems auch auf der linux-shell nicht geklappt hat (da hatter er immer keinen Zugriff auf das Logfile, dann sync-Probleme), habe ich die Arduino-Software für Windows installiert und siehe da...es hat geklappt.
Jetzt läuft er und die Temperatur-Daten fließen wieder.
Viele Grüße
Reinhard
Ich habe mir heute einen Jeelink-Clone mit BMP 180 gelötet. Interessant ist, daß das BMP 180 ein Temperaturmodul beinhaltet.
Zitatbattery
ok
2015-08-13 20:54:45
error
0
2015-08-13 20:54:45
pressure
1005
2015-08-13 20:54:45
state
T: 23.3
2015-08-13 20:54:26
temperature
23.3
2015-08-13 20:54:45
Jeelink-Clone und die Software funktioniert bei mir einwandfrei, danke an die Programmierer.
LG
/robin
Zitat von: fh168 am 13 August 2015, 20:55:45
Ich habe mir heute einen Jeelink-Clone mit BMP180 gelötet. Interessant ist, daß das BMP 180 ein Temperaturmodul beinhaltet.
Wie hast Du denn den BMP180 angelötet? Mit Drähten, oder hast Du eine Platine? Der BMP280 hat sogar noch einen Feuchtesensor drauf ;)
Gruß PeMue
Zitat von: PeMue am 13 August 2015, 21:56:33
Der BMP280 hat sogar noch einen Feuchtesensor drauf ;)
Bist Du sicher. In den technischen Spezifikationen steht nur Druck und Temperatur.
Grüße Jörg
sorry, sollte BME280 sein ... die beiden verwechsle ich immer :-\
Gruß PeMue
ich habe den mit kabeln gelötet, ohne platine, siehe hier
http://blog.moneybag.de/jeelink-clone-mit-luftdruck-sensor-und-temperatursensor/
frickelige arbeit
Mir ist aufgefallen, das der BMP 180 (Luftdruck) auf dem Jeelink-Clone etwas andere Werte liefert. Als Referenz nehme den Luftdruck von MyWeather (?) und die geniale Hardware von Locutus: http://blog.moneybag.de/raspberry-pi-add-on-board-mit-display-temperatursensor-luftdruck-infrarot/
Add-On-Board und der Webservice Weather liefern den gleichen Wert für meinen Ort.
Beim Jeelink mit dem BMP 180 differeriert er um 1,1 Punkte. Der Parameter h in den Eigenschaften vom Jeelink-Clone wurde angepasst. Aber warum der Unterschied beim Luftdruck? Die Module liegen nebeneinander bei mir auf dem Schreibtisch.
@PeMue: den BMP280 kenne ich nicht. Gibt es dafür auch ein "Arduino-Steckmodul"? Hab ich nirgendwo gefunden.
LG
/robin
Zitat von: fh168 am 13 August 2015, 22:36:47
ich habe den mit kabeln gelötet, ohne platine ...
aber der BMP180 sitzt auf der Platine, den IC einzel anlöten wäre noch viel frickeliger ;D
Gruß PeMue
Zitat von: fh168 am 14 August 2015, 07:15:57Aber warum der Unterschied beim Luftdruck? Die Module liegen nebeneinander bei mir auf dem Schreibtisch.
Mein SuperJee im Keller hat 1011 hPa, der im Arbeitszimmer am Test-Server 1010 hPa und wetter.com meldet aktuell 1010 hPa
Zitat von: fh168 am 14 August 2015, 07:15:57Beim Jeelink mit dem BMP 180 differeriert er um 1,1 Punkte.
Was sind Punkte? Meinst Du damit, dass er um 1,1 hPa abweicht?
yep, der weicht um 1,1 hPa ab
Zitat von: PeMue am 14 August 2015, 08:06:46
aber der BMP180 sitzt auf der Platine, den IC einzel anlöten wäre noch viel frickeliger ;D
Gruß PeMue
Yep, die Platine für den BMP 180 hat auch den Vorteil, das ein Spannungsregler 5V auf 3,3 V verbaut ist. Die Beschaltung gestaltet sich also relativ einfach. Siehe mein Foto im Blog-Beitrag.
Zitat von: HCS am 14 August 2015, 08:15:03
Mein SuperJee im Keller hat 1011 hPa, der im Arbeitszimmer am Test-Server 1010 hPa
Und wie hoch ist der Höhenunterschied zwischen Keller und Arbeitszimmer ?
Die Jungs hier http://www.deutscher-wetterdienst.de/lexikon/index.htm?ID=L&DAT=Luftdruck rechnen 1h Pa pro 8,4 m Höhenunterschied in Bodennähe
Zitat von: Wzut am 14 August 2015, 09:19:49Und wie hoch ist der Höhenunterschied zwischen Keller und Arbeitszimmer ?
Der Höhenunterschied der beiden Sensoren ist ca. 5m
Aber wir wollen jetzt doch wohl nicht über Differenzen von 1 hPa diskutieren?
Wenn Du einen Ventilator ans Fenster stellst, hast Du 2 hPa mehr und wenn Du die Tür zuhaust eine Peak von 5 hPa ;D ;D
Wenn ein Tief durchzieht, rauscht der Luftdruck 10 hPa und mehr nach unten.
Ob der Absolutwert 1 hPa mehr oder weniger ist, ist doch fast egal. Und wenn man mit der Höhe über NN nicht absolut richtig liegt, dann stimmt es halt nicht ganz.
Und wenn es nicht ganz stimmt, dann dreht man etwas an der Höhe, bis es stimmt. Wir sind doch nicht der DWD ::)
Ist ja okay, peanuts, mich hat es nur etwas gewundert: Gleiches Modul, Gleiche Position aber unterschiedliche Werte.
Zitat von: fh168 am 14 August 2015, 11:13:52
Ist ja okay, peanuts, mich hat es nur etwas gewundert: Gleiches Modul, Gleiche Position aber unterschiedliche Werte.
Eigentlich sagt es die technische Spezifikation von Bosch bereits:
Absolute accuracy 300 ... 1100hPa(Temperature=0 ... +65°C, VDD=3.3V)
Pressure: -4.0 ... +2.0 hPa
Temperature: ±1 °C, typ.Lt. Bosch darf er sogar 4 drunter und 2 drüber liegen (absolut). Da ist unsere Abweichung noch super in der Spezifikation.
Ein BMP280 wäre dann etwas genauer, Absolutwert ±1 hPa
Wäre mal zu prüfen, ob der von der Ansteuerung kompatibel ist. BMP085 und BMP180 sind austauschbar, vielleicht ja auch der BMP280
für welchen Bereich in der Hausautomation benutzt ihr denn den Luftdruck? Einfach nur um ein schönen Graph zu haben? Als "nice to know" oder aktiv irgendwo eingebunden?
Nicht falsch verstehen, ich finde es super aber fehlt der Einsatzzweck
Zitat von: Posti123 am 15 August 2015, 12:11:32für welchen Bereich in der Hausautomation benutzt ihr denn den Luftdruck? Einfach nur um ein schönen Graph zu haben? Als "nice to know" oder aktiv irgendwo eingebunden?
Ich: nice to know und für coole Plots.
Als Ersatz für die Hardware-Wetterstation. Ich hatte alle Informationen der Wetterstation im SV-Frontend, bis auf den Luftdruck(-Verlauf). Der hat noch gefehlt. Die Wetterstation kann jetzt also ihren Platz an der Wand räumen, da sie nicht mehr weiß, als mein Frontend.
Bei mir ebenfalls: nice to know und coole Plots.
Ich finde es interessant, wie sich bei den Hochs und Tiefs sich die Plots ändern. Und wenn man mit geringen Aufwand noch den Jeelink (-Clone) erweitern kann, also warum nicht ausnutzen?
LG
/robin
Zitat von: fh168 am 15 August 2015, 12:30:45Ich finde es interessant, wie sich bei den Hochs und Tiefs sich die Plots ändern
Ja, wenn man die Plots für Lufdruck, Temperatur, Feuchte, Wind und Niederschlag übereinander setzt, dann ist das sehr stimmig.
Eventuell könnte man damit ja eine Wettervorwarnung generieren.
Regenmesser WS1600Zitat von: Billy am 06 August 2015, 15:44:51
Werde jetzt noch den RFM69CW mit draufpacken, mir die Wetterstation WS1600 zulegen und die Ergebnisse (insbesondere Regenmenge) mit meiner
OREGON WMR928 vergleichen. (5 J alt 344,--€) zu WS1600 85,--€
Gruß Billy
Hier der Vergleich Oregon zu LaCrosse!Das Bild spricht für sich! Die 12,5 mm decken sich mit dem Ergebnis des glas Regenmessers.
Gruß Billy
Hallo zusammen,
habe gerade einen IT+-Temp/Hydro-Sensor Conrad TX21IT erfolgreich zum Laufen gebracht mit Jeelink-Nachbau und LaCrosse-Modul, Datenrate ist 17.241 kbps.
Danke den fleissigen Entwicklern!
Gruß
Jens
Hallo,
kann man den SuperJee auch mit einem 868er und einem 433er Funkmodul gleichzeitig betreiben?
Vielen Dank
Kohlenmacher
Zitat von: kohlenmacher am 24 August 2015, 15:24:13kann man den SuperJee auch mit einem 868er und einem 433er Funkmodul gleichzeitig betreiben?
Theoretisch eventuell ja, aber welcher Sensor, der auf 433 MHz sendet, hätte denn ein Protokoll, das einem der 866er entspricht?
Spätestens da wird es dann scheitern.
ZitatTheoretisch eventuell ja, aber welcher Sensor, der auf 433 MHz sendet, hätte denn ein Protokoll, das einem der 866er entspricht?
Spätestens da wird es dann scheitern.
Ich würde eigene Sensoren bauen.
An 433 MHz bin ich am überlegen, da 868 MHz bei mir schon von HomeMatic und einigen LaCrosse TemperaturSensoren benutzt wird und ich im 433 Mhz Bereich so gut wie nichts am laufen habe. So kann ich evtl. gegenseitige Störungen entgehen.
Gruß
Kohlenmacher
OK, dann muss ich mir mal die Initialisierung des RFM anschauen, ob die für 433 auch passt.
So ganz generell glaube ich, dass da nichts dagegen spricht.
Zitat von: kohlenmacher am 24 August 2015, 15:41:12
Ich würde eigene Sensoren bauen.
Tipp : lies mal http://forum.fhem.de/index.php/topic,39920.0.html und bleibe bei 868MHz.
Bei mir gibt sich inzwischen der erste Eigenbau als LaCrosse aus :)
Zitat von: Wzut am 24 August 2015, 19:18:34
Tipp : lies mal http://forum.fhem.de/index.php/topic,39920.0.html und bleibe bei 868MHz.
Über welche Frequenz das LaCrosse Protokol läuft ist doch egal. Ich habe halt noch einige 433 MHz Module hier liegen.
Mir ist jetzt noch eine wichtige Frage dazu eingefallen.
@HCS
Kann man beim Senden, über den SuperJee, das Funkmodul angeben, das verwendet werden soll?
Oder brauche ich dann sowieso zwei JeeLinks?
Gruß
Kohlenmacher
Hi,
leider kann ich meinen Jeelink Clone nicht direkt von fhem aus updaten (avrdude: stk500_getsync(): not in sync: resp=0x98) sondern mach das immer über die Arduino Umgebung unter Windows. Jetzt wollte ich auf die 10.1o updaten (weiter will ich die nächsten Tage einen Superjee in Betrieb nehmen und hätte dann gern die neueste FW), aber das bricht mit Fehlern ab.
In file included from BMP180.cpp:1:
BMP180.h:19: error: ISO C++ forbids initialization of member 'm_altitudeAboveSeaLevel'
BMP180.h:19: error: making 'm_altitudeAboveSeaLevel' static
BMP180.h:19: error: ISO C++ forbids in-class initialization of non-const static member 'm_altitudeAboveSeaLevel'
BMP180.cpp: In member function 'int32_t BMP180::GetPressure()':
BMP180.cpp:96: error: 'powf' was not declared in this scope
Liegt das Problem in meiner Arduino-Umgebung oder im Code?
MfG
Marco
Zitat von: marco-f am 27 August 2015, 21:24:27Liegt das Problem in meiner Arduino-Umgebung oder im Code
-> Arduino-Umgebung
;) Ja, dumme Frage. ;D
Hast Du einen heißen Tip für mich wie ich den Sketch dennoch geflasht bekomme?
Zitat von: marco-f am 27 August 2015, 22:28:23
Hast Du einen heißen Tip für mich wie ich den Sketch dennoch geflasht bekomme?
Mangels Information, was Du eigentlich installiert hast und tust, leider nicht.
Arduino IDE 1.6?
Und warum Du nicht von FHEM aus flashen kannst ist mir auch unklar.
avrdude ist aktuell?
Die in JeeLink modul angegebene Schnittstelle stimmt?
Zitat von: kohlenmacher am 25 August 2015, 09:32:44
@HCS
Oder brauche ich dann sowieso zwei JeeLinks?
Ein JeeLink reicht.
Zitat von: kohlenmacher am 25 August 2015, 09:32:44
@HCS
Kann man beim Senden, über den SuperJee, das Funkmodul angeben, das verwendet werden soll?
Kann man nicht angeben. Es wird immer über das erste Modul gesendet, und immer mit 17.241 kbps, egal, was für den Empfang konfiguriert ist.
Zitat von: HCS am 27 August 2015, 22:38:56
Mangels Information, was Du eigentlich installiert hast und tust, leider nicht.
Stimmt. Sorry!
ZitatArduino IDE 1.6?
Hatte noch die 1.0.6 drauf, hab nun das Update auf die 1.6.5 installiert. Musste feststellen, dass ich ohne angeschlossenen JeeLink Clone den Sketch kompiliert bekomme. Sobald der JeeLink am Rechner angesteckt ist kommt beim Kompilierversuch ein Fehler:
java.lang.NullPointerException
at cc.arduino.LoadVIDPIDSpecificPreferences.load(LoadVIDPIDSpecificPreferences.java:48)
at processing.app.debug.Compiler.createBuildPreferences(Compiler.java:592)
at processing.app.debug.Compiler.<init>(Compiler.java:193)
at processing.app.debug.Compiler.build(Compiler.java:96)
at processing.app.Sketch.build(Sketch.java:1109)
at processing.app.Sketch.build(Sketch.java:1084)
at processing.app.Editor$BuildHandler.run(Editor.java:1955)
at java.lang.Thread.run(Thread.java:745) Java ist aktuell.
ZitatUnd warum Du nicht von FHEM aus flashen kannst ist mir auch unklar.
avrdude ist aktuell?
Nein, war es nicht. Wie ich jetzt rausfand wird mit apt-get update/upgrade der avrdude nicht mit aktualisiert wird. Hab manuell auf die 6.1 aktualisiert. Der Fehler bleibt jedoch bestehen.
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x66
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x06
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x86
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xf8
avrdude done. Thank you.
Zitat
Die in JeeLink modul angegebene Schnittstelle stimmt?
Ich definiere die Schnittstelle für den "myJeeLink" nur in den fhem.cfg und diesen versuche ich ja zu flashen. Ohne richtige Schnittstelle würde ich ja keine Daten von meinen Sensoren empfangen. Oder übersehe ich da was!?
Grüße,
Marco
Zitat von: marco-f am 29 August 2015, 22:17:16Musste feststellen, dass ich ohne angeschlossenen JeeLink Clone den Sketch kompiliert bekomme. Sobald der JeeLink am Rechner angesteckt ist kommt beim Kompilierversuch ein Fehler:
Warum Deine Ardunio-IDE nicht richtig läuft, habe ich momentan auch keine Idee dazu.
Da hilft nur experimentieren. Komplett deinstallieren, neu installieren, oder mal auf einem anderen Rechner probieren, ...
Alternativ kannst Du dein Glück auch mal mit dem Arduino Builder versuchen. Den habe ich zwar noch nie verwendet, habe aber in einem anderen Thread Screenshots gesehen, wo ihn jemand verwendet hat, um den Sketch zu compiliern und zu flashen.
Zitat von: marco-f am 29 August 2015, 22:17:16
Nein, war es nicht. Wie ich jetzt rausfand wird mit apt-get update/upgrade der avrdude nicht mit aktualisiert wird. Hab manuell auf die 6.1 aktualisiert. Der Fehler bleibt jedoch bestehen.
Poste mal das komplette Log, das erzeugt wird, nach einem set myJeeLink flash
Zitat von: marco-f am 29 August 2015, 22:17:16Ich definiere die Schnittstelle für den "myJeeLink" nur in den fhem.cfg und diesen versuche ich ja zu flashen. Ohne richtige Schnittstelle würde ich ja keine Daten von meinen Sensoren empfangen. Oder übersehe ich da was!?
Nein, nichts übersehen. Wenn FHEM Daten von den Sensoren bekommt, dann stimmt die Schnittstelle. Dachte das wäre eine Initial-Installation.
Zitat von: HCS am 30 August 2015, 08:52:09Poste mal das komplette Log, das erzeugt wird, nach einem set myJeeLink flash
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x66
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x06
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x86
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xf8
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Kann es sein, dass avrdude nicht mit
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
klarkommt?
Kannst Du mal alternativ
/dev/ttyUSB0
oder was halt die Schnittstelle ist, versuchen?
Der avrdude Aufruf ist OK, nur kann er scheinbar nicht auf die Schnittstelle zugreifen.
Probiere mal als attribut beim Jeelink device folgendes zu setzen:
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Ich hatte auch die Flash Probleme und mit diesem Befehl gings (es wird -b 57600 ergänzt)
Ronny
Zitat von: rcmcronny am 30 August 2015, 09:59:28
Probiere mal als attribut beim Jeelink device folgendes zu setzen:
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Ich hatte auch die Flash Probleme und mit diesem Befehl gings (es wird -b 57600 ergänzt)
Ronny
:) That's it! Und flupp ist der JeeLink auf der 10.1o! Danke!
Zitat von: rcmcronny am 30 August 2015, 09:59:28
Probiere mal als attribut beim Jeelink device folgendes zu setzen:
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Das ist ja interessant, damit geht es bei mir nämlich nicht.
Dann wäre herauszufinden, wann man die baud rate setzen muss und wann man sie nicht setzen darf.
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -b 57600 -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_getsync(): not in sync: resp=0x0a
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Hallo,
ich habe auch einen Nano mit ch340 chip, den Tip habe ich beim Justin im Blog gefunden bei den JeeLink Clone Infos. Vorher kamen genau die not in sync Meldungen auch bei mir.
Ronny
Gerade mal einen Nano V3 rausgekramt. "not in sync", ohne "-b 57600"
Ich vermute, dass das daran liegt, dass der Nano keinen Optibootloader drauf hat, im Gegensatz zu JeeLink und JeeNode.
Hoffentlich kann ich mir das für das nächste mal, wenn jemand eine Clone flashen will, merken, oder dass es nicht vergessen wird, könnte Billy es ins wiki schreiben ;)
Regel:
Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben, ohne "-b 57600"
"Nano Clone" und ähnliches mit "-b 57600"
Ein Clone ist eigentlich nur dann ein Clone, wenn er sich wie das Original verhält ;)
Das ist nämlich bereits der zweite Unterschied zu einem Original, der erste waren 1,5k weniger Speicher.
Wenn man sich per SPI den Optibootloader drauf flasht, dann hätte man einen echten Clone.
Zitat von: HCS am 30 August 2015, 12:55:29Ich vermute, dass das daran liegt, dass der Nano keinen Optibootloader drauf hat, im Gegensatz zu JeeLink und JeeNode.
Das könnte ich dieser Tage mal testen. Hab noch einen jungfräulichen Nano mit CH340 Chip daliegen der diese Woche noch zum SuperJee werden soll. Den kann ich ja mal so bespielen, dann den Optiboot draufpacken (sofern der AVR MKII mitspielt) und erneut probieren.
Zitat von: marco-f am 30 August 2015, 21:34:37Den kann ich ja mal so bespielen, dann den Optiboot draufpacken (sofern der AVR MKII mitspielt) und erneut probieren.
Das wäre prima, dann wäre es bestätigt und ich kann den Nano ohne Opitboot lassen, um diese Sorte Clones zu simulieren.
Zitat von: HCS am 30 August 2015, 12:55:29Ich vermute, dass das daran liegt, dass der Nano keinen Optibootloader drauf hat, im Gegensatz zu JeeLink und JeeNode.
Hoffentlich kann ich mir das für das nächste mal, wenn jemand eine Clone flashen will, merken, oder dass es nicht vergessen wird, könnte Billy es ins wiki schreiben ;)
Regel:
Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben, ohne "-b 57600"
"Nano Clone" und ähnliches mit "-b 57600"
Ja, es ist so! Den jungfräulichen Nano konnte ich nur mit "-b 57600" bespielen, dann hab ich mit dem AVR Studio den optiboot-v5.0a draufgebruzelt und danach ging es nur noch ohne "-b 57600".
Mal noch ne Frage zum BMP 180. Der übergibt ja auch eine Temperatur mit an FHEM. Welche ist das? Denn mit beiden Sensoren die ich habe liegt die übergebene Temperatur ca. 9° über Raumtemperatur.
Zitat von: marco-f am 03 September 2015, 12:34:45
Mal noch ne Frage zum BMP 180. Der übergibt ja auch eine Temperatur mit an FHEM. Welche ist das? Denn mit beiden Sensoren die ich habe liegt die übergebene Temperatur ca. 9° über Raumtemperatur.
Die Temperatur, die der BMP180 misst. Wenn man den direkt neben einem schön warmen Arduino hat, kann das dann schon etwas mehr sein.
Müsstest mal die Temperatur direkt am BMP180 messen, ob das mit dem, was er rausgibt, übereinstimmt.
Bosch gibt eigentlich eine Genauigkeit für die Temperatur von +-1°C an.
Moin, ich habe mit drei verschiedenen BMP180 getestet, und musste feststellen, das die Temperatur bis zu 8 Grad abweicht. Alle BMP180 lagen vorher mindestens 10 Minuten unbenutzt auf dem Tisch und hatten genug Zeit sich an die Raumtemperatur zu "gewöhnen". Ich ignoriere die Temperatur des BMP seither.
Zitat von: Feuerdrache am 03 September 2015, 17:44:15Ich ignoriere die Temperatur des BMP seither.
Habe mich auch noch nie sonderlich für diese Temperatur interessiert. Aber stimmen sollte sie trotzdem.
Habe gerade mal getestet: Der BMP180 meint 26,8 und der TX38 in seiner Nähe meint 23,9
Ist also auch zu hoch.
Muss mir nochmal die Temperaturroutinen anschauen, ob da kein Rechenfehler drin ist.
Ich hatte heute mal den BMP180 weitestmöglich von der Arduino Platine weggebogen und einen 30.3144.IT Sensor daneben gestellt. Der Unterschied betrug immer mind. 7°. Hab das Phänomen mit zwei Sensoren nachgestellt.
Zitat von: marco-f am 03 September 2015, 22:08:49
Ich hatte heute mal den BMP180 weitestmöglich von der Arduino Platine weggebogen und einen 30.3144.IT Sensor daneben gestellt. Der Unterschied betrug immer mind. 7°. Hab das Phänomen mit zwei Sensoren nachgestellt.
Dann muss ich mich doch mal intensiver mit beschäftigen. Steht aber mit Prio. 2 auf der Liste.
ich habe zwei bmp180 an panstamps in betrieb und die temperatur unterscheidet sich nur um 0.1 grad voneinander und unter 0.5 grad von einem s300ht im gleichen raum.
laut datenblat sollten die dinger sehr viel genauer sein als die 7grad abweichung sein die ihr habt. ich vermute das ist etwas anderes faul.
gruss
andre
Zitat von: justme1968 am 04 September 2015, 13:09:19ich vermute das ist etwas anderes faul.
Das deckt sich mit meiner Vermutung. Muss nur noch rausfinden was :(
Zitat von: HCS am 30 August 2015, 12:55:29
Gerade mal einen Nano V3 rausgekramt. "not in sync", ohne "-b 57600"
Ich vermute, dass das daran liegt, dass der Nano keinen Optibootloader drauf hat, im Gegensatz zu JeeLink und JeeNode.
Hoffentlich kann ich mir das für das nächste mal, wenn jemand eine Clone flashen will, merken, oder dass es nicht vergessen wird, könnte Billy es ins wiki schreiben ;)
Habe das im WIKI unter --> JeeLink aus Fhem flashen --> Vorsicht bei Jeelink Clones! aufgenommen.
Kannst ja mal schauen ob es passt.
Gruß Billy
wie ist gerde des Status beim tfa 30.3180 ? Geht da noch was?
Ich habe nun noch einen Jeelink 433 Mhz dazu bekommen. Mit diesem wollte ich eigentlich den Technocline WS 6009 in FHEM integrieren.
Der JeeLink arbeitet wohl richtig!
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF
/dev/ttyUSB1@57600
DeviceName
/dev/ttyUSB1@57600
FD
27
NAME
myJeeLink2
NR
236
PARTIAL
RAWMSG
OK 9 18 129 5 95 106
STATE
Initialized
TYPE
JeeLink
model
[LaCrosseITPlusReader.10.1o (RFM69CW f:433920 t:30~3)]
myJeeLink2_MSGCNT
2
myJeeLink2_TIME
2015-09-11 11:56:19
Leider bekomme ich aber keinen neuen Devices in FHEM angezeigt. Autocreate ist eingeschaltet.
Hab ich was falsch eingestellt?
Zitat von: Toto1973 am 11 September 2015, 12:02:16
Leider bekomme ich aber keinen neuen Devices in FHEM angezeigt. Autocreate ist eingeschaltet.
Hab ich was falsch eingestellt?
Mach mal einen:
set myJeeLink2 LaCrossePairForSec ignore_battery
Nachdem ich nun über die PC-Software Arduino den Jeelink mit der Option #define ANALYZE_FRAMES 1 beschrieben habe, bekomme ich im Log-file von FHEM folgende Einträge:
2015.09.16 19:02:22 3: myJeeLink2: Unknown code 002907 LevelSender [AD 74 C2 AB E5 C1 ] CRC:WRONG, help me!
2015.09.16 19:02:22 3: myJeeLink2: Unknown code 002907 EMT7110 [AD 74 C2 AB E5 C1 D7 1F 17 4B 7B 64 ] CRC:WRONG S:AD 74 ID:C2AB V:0.00 mA:0.00 W:0.00 kWh:0.00 Con.:0 Pair:1 CRC:0, help me!
2015.09.16 19:02:22 3: myJeeLink2: Unknown code 002907 TX38IT [173 116 194 171 ] CRC:WRONG, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code 001495 LaCrosse [53 102 196 110 238 ] CRC:WRONG, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code ## CRC FAIL ##, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code No valid start, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code No valid Level: 336.00, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code No valid Voltage: 15.40, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code 001496 LevelSender [35 66 C4 6E EE 53 ] CRC:WRONG, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code 001494 EMT7110 [35 66 C4 6E EE 53 CE 8B C3 7C C3 49 ] CRC:WRONG S:35 66 ID:C46E V:0.00 mA:0.00 W:0.00 kWh:0.00 Con.:0 Pair:1 CRC:0, help me!
2015.09.16 19:02:23 3: myJeeLink2: Unknown code 001494 TX38IT [53 102 196 110 ] CRC:WRONG, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code 002860 LaCrosse [200 192 179 137 202 ] CRC:WRONG, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code ## CRC FAIL ##, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code No valid start, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code No valid Level: 605.50, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code 002855 LevelSender [C8 C0 B3 89 CA BC ] CRC:WRONG, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code 002856 EMT7110 [C8 C0 B3 89 CA BC 12 60 83 3E 82 4B ] CRC:WRONG S:C8 C0 ID:B389 V:0.00 mA:0.00 W:0.00 kWh:0.00 Con.:0 Pair:1 CRC:0, help me!
2015.09.16 19:02:26 3: myJeeLink2: Unknown code 002856 TX38IT [200 192 179 137 ] CRC:WRONG, help me!
So wie das aussieht, empfange ich da was. Aber mein Regensensor WS9006 scheint da leider nicht dabei zu sein!?
Wie könnte man denn jetzt einer dieser Sensoren in FHEM einbinden?
Hier noch meine Jeelinkdaten, falls da vielleicht noch was falsch läuft:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006RMQ-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL006RMQ-if00-port0@57600
FD 26
NAME myJeeLink2
NR 234
PARTIAL
RAWMSG 001994 TX38IT [44 189 214 161 ] CRC:WRONG
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1h (RFM69CW) @AutoToggle 30 Seconds / 433920 kHz]
myJeeLink2_MSGCNT 849
myJeeLink2_TIME 2015-09-16 19:11:16
#define ANALYZE_FRAMES 1 kannst Du wieder auf 0 setzen, das ist nicht für den Normalbetrieb gedacht.
Ich habe keine Ahnung, ob dein Regensensor WS9006 ein Protokoll sendet, das der Sketch versteht. Falls nicht, dann wird das nichts.
Zitat von: marco-f am 03 September 2015, 22:08:49
Ich hatte heute mal den BMP180 weitestmöglich von der Arduino Platine weggebogen und einen 30.3144.IT Sensor daneben gestellt. Der Unterschied betrug immer mind. 7°. Hab das Phänomen mit zwei Sensoren nachgestellt.
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?
Zitat von: HCS am 18 September 2015, 21:58:02
...Hat jemand noch eine Idee zu dem Thema?
Ich habe Jeelink (Arduino) und BMP180 auf dem Dachboden auf einem Steckbrett nebeneinander; sollten sich also nicht oder nur minimal beeinflussen.
Temperaturdifferenz zu einem TX29 ca. 30cm weiter beträgt ca. +1.2K .
Das deckt sich ungefähr mit Deiner Messreihe.
Werde den TX29 sicherheitshalber mal neben einen anderen stellen, ob die identisch sind.
Sketch 10.1p
neue Command "o"
Der Sketch versteht nun das neue Command o um beliebige Parameter des RFM12 zu setzen.
Das ist nun eher für "RFM12-Versteher" gedacht :)
Dazu muss das Command, das man gem. Command Calculator oder sonstwie ermittelt hat, in dezimal umgerechnet werden.
Beispiel:
Receiver-Control soll gesetzt werden auf: LNA-Gain max, Pin VDI, RX-Bandwidth 200kHz, VDI fast, DRSSI -103db
wäre dann 0x9480 = 38016
um es zu setzen wäre dann ein set myJeeLink raw 38016o erforderlich.
neues command "c"
Die data rate, mit der für einen custom sensor gesendet wird, kann nun konfiguriert werden.
Beispiel: 9579c
verzögerte initialisierung
Da einige FHEM-Installationen die Initialisierung des Sketch nach einem Neustart nicht mitbekommen haben wird diese nun eine Sekunde verzögert gesendet.
seltsame EMT7110-Pakete
EMT7110 können wohl diese Pakete senden: [25 6A 54 AE 2A AA AA AA AA AA AA 49 ]
Der Grund und was der EMT7110 damit mitteilen will ist noch unklar, aber das wären 43,69 Ampere usw. und das kann schlicht nicht sein.
Die werden nun bereits im Sketch weggefiltert.
RFMxx lib
Die RFMxx lib zur Ansteuerung des RFM12 / RFM69 wurde so überarbeitet, dass sie sowohl für Arduinos als auch den ESP8266 funktioniert.
Grund: ich arbeite an einem LaCrosse Gateway, das mit einem ESP8266 und einem RFM69 die LaCrosse-Sensoren per wifi für FHEM bereitstellt.
Das sollte keine Auswirkungen auf den Betrieb mit JeeLinks usw. haben.
@justme1968: würdest Du den angehängten Patch für das 36_JeeLink.pm übernehmen?
Hat folgenden Zweck: wenn man einen Port im Netzwerk verwendet, z.B. mit
define myJeeLink JeeLink 192.168.1.55:8888
dann merkt 36_JeeLink nicht, wenn der Port aus dem Netzwerk verschwindet und bleibt auf "Initialized" stehen. Wenn der Port wieder auftaucht findet aber dann auch keine Kommunikation mehr statt.
Ich habe ein neues Attribut "timeout" erfunden, das so angegeben wird: <timeout, checkInterval>
Beispiel: attr myJeeLink timeout 120,30
Bedeutet: es wird alle 30 Sekunden geprüft, ob der letzte Datenempfang (myJeeLink_TIME) länger als 120 Sekunden zurück liegt.
Falls das so ist, wird ein reset auf dem Port gemacht (zu->auf also wie ein set myJeeLink reset) und zwar alle 30 Sekunden, bis wieder Daten reinkommen.
Die Zeiten kann man nach eigenem Geschmack definieren.
Beim definieren der Zeiten ist zu beachten, dass im ungünstigsten Fall der Reset erst nach timeout + checkInterval Sekunden kommt (in diesem Beispiel also erst nach 120 + 30 = 150 Sekunden).
Das bringt auch JeeLinks(-Clone), die, wie von manchen Anwendern berichtet, manchmal hängen, wieder in Schwung.
Mit einem JeeLink kann man es ganz einfach dadurch testen, in dem man das timeout Attribut setzt und dann mit set myJeeLink raw 868100f die Frequenz wegdreht. Dann empfängt er nichts mehr und nach der definierten Zeit bekommt er einen Reset und arbeitet wieder mit seinen defaults bzw. den Settings aus initCommands.
ich hab es eingecheckt.
gruss
andre
ps: für das erste problem verstehe ich aber nicht warum DevIO das nicht abfängt. ich betreibe meine cul,jeelink und panstamp inzwischen alle per ser2net und wenn ich sie auf dem entfernten system abziehe bekomme ich die 'disconnected, waiting to reappear' meldung die es auch gibt wenn das device lokal abgezogen wird und nach dem einstecken wird der jeelink automatisch wieder gefunden.
kann es sein das die ports nicht 'sauber' aus dem netz verschwinden?
Prima, danke!
Zitat von: justme1968 am 11 Oktober 2015, 10:39:24kann es sein das die ports nicht 'sauber' aus dem netz verschwinden?
Genau so ist es. Da läuft ein ESP8266 im wlan und verschwindet, weil man ihm einfach die Spannungsverorgung kappt, das wlan wegbricht oder was sonst noch so machbar ist, dass er keine Chance mehr hat, den port zu schließen. Und in genau diesen Fällen bekommt man dann halt keinerlei Kommunikation mehr, auch wenn er wieder im Netzwerk auftaucht. Dafür ist das timeout Attribut dann die Rettung.
Hallo,
habe gerade ein update gemacht seit dem:
2015.10.11 13:31:08 1: PERL WARNING: Argument "1OK" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.11 13:31:08 1: PERL WARNING: Argument "OK" isn't numeric in addition (+) at ./FHEM/36_LaCrosse.pm line 211.
2015.10.11 13:31:38 1: PERL WARNING: Argument "58OK" isn't numeric in sprintf at ./FHEM/36_LaCrosse.pm line 204.
2015.10.11 13:31:48 1: PERL WARNING: Argument "K" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.11 13:31:48 1: PERL WARNING: Argument "8OK" isn't numeric in addition (+) at ./FHEM/36_LaCrosse.pm line 211.
2015.10.11 13:31:52 1: PERL WARNING: Argument "204O" isn't numeric in addition (+) at ./FHEM/36_LaCrosse.pm line 211.
2015.10.11 13:32:10 1: PERL WARNING: Argument "199OK" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.11 13:32:31 1: PERL WARNING: Argument "5OK" isn't numeric in sprintf at ./FHEM/36_LaCrosse.pm line 204.
2015.10.11 13:32:46 1: PERL WARNING: Argument "5O" isn't numeric in sprintf at ./FHEM/36_LaCrosse.pm line 204.
2015.10.11 13:33:07 1: PERL WARNING: Argument "9OK" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 205.
2015.10.11 13:33:16 1: PERL WARNING: Argument "1OK" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 205.
2015.10.11 13:33:42 1: PERL WARNING: Argument "204OK" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.11 13:33:55 1: PERL WARNING: Argument "O06" isn't numeric in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 205.
und zb. T: 136.5 , T: -73.9 H: 71 D: -76.1
Das sieht so aus, als ob von der Schnittstelle Müll kommen würde.
Was steht denn im JeeLink Modul in RAWMSG drin (mehrmals einen page reload machen, um zu sehen, was da alles so durchkommt)
Ansonsten:
JeeLink mal abziehen und wieder stecken
Host mal neu booten
JeeLink Modul mal auf verbose 5 und im log schauen, was da so an "myJeeLink dispatch" Zeilen kommt.
Zitat von: justme1968 am 11 Oktober 2015, 10:39:24
ich hab es eingecheckt.
Nanu, ich sehe es auf sourceforge nicht.
jetzt aber.
keine ahnung was da vorhin schief gelaufen ist.
gruss
andre
Kurze Frage an die Experten:
Kann ich statt eines RFM69CW auch ein RFM69W nehmen? Wird der auch erkannt? ok, Pinbelegung ist anders.
LG
/robin
Zitat von: fh168 am 13 Oktober 2015, 12:00:29
Kann ich statt eines RFM69CW auch ein RFM69W nehmen? Wird der auch erkannt?
Ich denke schon, aber getestet habe ich es nicht.
Mit 5€ kann man aber auch nicht viel in den Sand setzen, um es mal zu probieren.
ok ich werde den RFM69W mal testen, im Vergleich zum RFM12B (868)
Danke!
Meine Feststellung mit dem RFM69CW ist, dass er eine bessere Reichweite hat (also der Empfänger empfindlicher ist).
Mit dem empfange ich an der selben Stelle Sensoren (IT+ 868) sicher, die mit dem RFM12 nur sporadisch empfangen wurden.
Zitat von: HCS am 11 Oktober 2015, 09:02:29
....
Hat folgenden Zweck: wenn man einen Port im Netzwerk verwendet, z.B. mit
define myJeeLink JeeLink 192.168.1.55:8888
....
Hallo HCS,
ich habe da mal ein Frage zum verbinden von JeeLink über IP. Was muss ich einstellen damit ich auf einem anderen FHEM-Server die Daten per IP empfangen.
Ich denke das am empfangenden FHEM-Server:
define myJeeLink JeeLink 192.168.1.55:8888
und was beim sendenden FHEM-Server ?? Oder muß der JeeLink einen IP-Port haben.
Ich habe 2 JeeLink einmal mit RFM69CW (sehr gute Reichweite und Empfang) und einmal RFM12B. Der RFM69CW wurde genommen da die Pinbelegung identisch zum RFM12B ist und so einfach der RFM12B ausgetauscht werden kann.
Version: LaCrosseITPlusReader.10.1p (RFM69CW f:868300 r:17241) oder LaCrosseITPlusReader.10.1p (RFM12B f:868300 r:17241)
Vielen Dank.
Jörg
Hallo,
ich habe einen Jeelink Clone, der ab und an auch mal aussteigt. Da habe ich mit Freude den neuen Parameter timeout eingesetzt. Nun bekomme ich aber im Logfile massig Einträge. Ist das so gewollt, oder habe ich was falsch gemacht?
attr Jeelink timeout 120,30
2015.10.12 22:08:01 3: Opening JeeLink device /dev/ttyUSB0
2015.10.12 22:08:01 3: Setting JeeLink serial parameters to 57600,8,N,1
2015.10.12 22:08:01 3: JeeLink device opened
2015.10.12 22:08:31 3: Opening JeeLink device /dev/ttyUSB0
2015.10.12 22:08:31 3: Setting JeeLink serial parameters to 57600,8,N,1
2015.10.12 22:08:31 3: JeeLink device opened
2015.10.12 22:09:01 3: Opening JeeLink device /dev/ttyUSB0
2015.10.12 22:09:01 3: Setting JeeLink serial parameters to 57600,8,N,1
2015.10.12 22:09:01 3: JeeLink device opened
2015.10.12 22:09:31 3: Opening JeeLink device /dev/ttyUSB0
2015.10.12 22:09:31 3: Setting JeeLink serial parameters to 57600,8,N,1
2015.10.12 22:09:31 3: JeeLink device opened
2015.10.12 22:10:01 3: Opening JeeLink device /dev/ttyUSB0
2015.10.12 22:10:01 3: Setting JeeLink serial parameters to 57600,8,N,1
2015.10.12 22:10:01 3: JeeLink device opened
Grüsse, Jens
wenn der entfernte jeelink an einem linux rechner steckt ist das einfachste dort ser2net zu verwenden.
in ser2net.conf trägst du dann etwas in der art ein:2000:raw:0:/dev/ttyACM0:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
dein cul ist dann unter port 2000 zu erreichen.
gruss
andre
Zitat von: justme1968 am 13 Oktober 2015, 20:22:02
wenn der entfernte jeelink an einem linux rechner steckt ist das einfachste dort ser2net zu verwenden.
....
Hallo Andre,
ich denke einmal die Antwort ist für mich. Ich hatte den 2. FHEM-Server über FHEM2FHEM angebunden. Das geht auch sehr gut.
Ich habe nur gedacht das etwas eingebaut wurde was ich so noch nicht mitbekommen habe.
Jörg
Zitat von: jensweber am 13 Oktober 2015, 20:18:52... Nun bekomme ich aber im Logfile massig Einträge. Ist das so gewollt ...
Das ist nicht gewollt. Hast Du verbose höher als 3 eingestellt?
timeout 120,30 bedeutet, dass nach 120 Sekunden ohne Datenempfang die Schnittstelle resettet wird. Wenn dann nach 30 Sekunden keine Daten kommen, dann wird der nächste reset gemacht, usw.
Das sieht so aus, als ob nach dem Reset der Schnittstelle immer noch keine Daten vom Clone kommen (innerhalb 30 Sekunden).
Wenn ein Reset den Clone nicht wiederbelebt, dann hilft das timeout Attribut natürlich auch nichts und es resettet alle 30 Sekunden so vor sich hin.
Normalerweise sollte nach der Initialisierung in dieser Zeit was empfangen werden, da die Sensoren ja alle 4 Sekunden senden.
Kannst mal versuchen mit den Zeiten hoch zu gehen, z.B. auf "timeout 240,120"
Vielleicht dauert es bei Dir ja einfach etwas länger, bis mal Daten reinkommen.
Zitat von: pejonp am 13 Oktober 2015, 21:13:50... Ich hatte den 2. FHEM-Server über FHEM2FHEM angebunden. Das geht auch sehr gut.
Ich habe nur gedacht das etwas eingebaut wurde was ich so noch nicht mitbekommen habe.
Nö, nichts dergleichen eingebaut. Gab es alles schon.
Verbose ist bei mir auf 3 eingestellt.
Ich habe die Zeiten auf 240,120 und auch 240,180 eingestellt. Das Ergebnis ist das selbe, aber in längeren Abständen.
Kann das an dem sketch auf den JeeLinkClone liegen ? Da habe ich die Version 10.1o installiert.
Zitat von: jensweber am 13 Oktober 2015, 23:47:00
Ich habe die Zeiten auf 240,120 und auch 240,180 eingestellt. Das Ergebnis ist das selbe, aber in längeren Abständen.
Kann das an dem sketch auf den JeeLinkClone liegen ? Da habe ich die Version 10.1o installiert.
10.1o ist OK.
Bekommt das jeelink modul denn Daten rein?
Ändert sich myJeeLink_TIME im jeelink modul und ist es eine aktuelle Zeit?
Ja ich bekomme die Daten der Sensoren und Datum und Uhrzeit passt.
JeeLink_MSGCNT 145218
JeeLink_TIME 2015-10-14 23:49:54
Zitat von: jensweber am 13 Oktober 2015, 20:18:52
attr Jeelink timeout 120,30
2015.10.12 22:08:01 3: Opening JeeLink device /dev/ttyUSB0
2015.10.12 22:08:01 3: Setting JeeLink serial parameters to 57600,8,N,1
2015.10.12 22:08:01 3: JeeLink device opened
...
Jetzt bin ich dahinter gekommen, warum das bei Dir nicht geht. Das liegt daran, dass Dein JeeLink device "JeeLink" heißt, also genau so, wie das Modul.
Benenne es mal in "myJeeLink" oder was auch immer Du willst um, dann sollte es funktionieren.
Muss ich heute Abend mal schauen, warum das mit diesem Name nicht geht und ob es gehend gemacht werden kann.
Bin mir aber nicht sicher, ob es generell eine gute Idee ist, eine Instanz wie das Modul zu benennen.
eigentlich sind die namensräume für module und devices unabhängig und es sollte keine probleme machen.
hast du einen verdacht?
gruss
andre
Zitat von: justme1968 am 15 Oktober 2015, 10:44:59
eigentlich sind die namensräume für module und devices unabhängig und es sollte keine probleme machen.
hast du einen verdacht?
Also: wenn ich meine JeeLink Instanz "JeeLink" nenne, habe ich das gleiche Verhalten wie jensweber.
Kann es erst heute Abend debuggen, aber ich würde aus dem Bauch raus drauf tippen, dass der hier
my $jeeLinkTime = InternalVal($name, "myJeeLink_TIME", "2000-01-01 00:00:00");den default Value oder sonst was falsches liefert, wenn $name "JeeLink" ist.
Aber wie gesagt, nur ein Verdacht, debuggen kann ich es erst heute Abend.
der name darf auch nicht harncodiert sein. das internal heisst bei jedem device anders. so sollte es gehen. my $jeeLinkTime = InternalVal($name, "${name}_TIME", "2000-01-01 00:00:00");
der grund für die unterschiedlichen namen ist das der gleiche name verwendet wird um dein timestamp in die internals des devices einzutragen für das die nachricht ist und man so sieht über welches io die letzte nachricht reingekommen ist.
gruss
andre
ps: du kannst bei InternalTimer direkt den device hash als dritten parameter angeben. dann brauchst du dich nicht über den namen wieder aufs device zurück hangeln. d.h. einfach statt $timerName direkt $hash verwenden.
pps: ich hab mal eine version mit den änderungen angehängt. wenn es so funktioniert checke ich es ein.
Zitat von: justme1968 am 15 Oktober 2015, 11:05:13
das internal heisst bei jedem device anders. so sollte es gehen. my $jeeLinkTime = InternalVal($name, "${name}_TIME", "2000-01-01 00:00:00");
Klar, jetzt sehe ich es auch. Das was ich gemacht habe funktioniert ja ausschließlich mit "myJeeLink" :-[
Zitat von: justme1968 am 15 Oktober 2015, 11:05:13
ps: du kannst bei InternalTimer direkt den device hash als dritten parameter angeben. dann brauchst du dich nicht über den namen wieder aufs device zurück hangeln. d.h. einfach statt $timerName direkt $hash verwenden.
Das mache ich üblicherweise bei den Timern so. Hier habe ich es bewusst mühevoll nicht gemacht, weil es in JeeLink Modul Stellen gibt, an denen ein Timer angeworfen wird (z.B. LaCrossePairForSec) und ich dachte, dass das dann kollidiert, wenn dieser hier auch den Hash verwendet, woran er ja dann identifiziert wird.
Zitat von: justme1968 am 15 Oktober 2015, 11:05:13
pps: ich hab mal eine version mit den änderungen angehängt. wenn es so funktioniert checke ich es ein.
Ohne es gerade testen zu können, vermute ich, dass das nicht geht.
my ($hash) = @_;
my $hash = $hash->{NAME};
my $attrVal = AttrVal($name, "timeout", undef);Es müsste aber dann eigentlich mit allein dieser Änderung funktionieren:
my $jeeLinkTime = InternalVal($name, "${name}_TIME", "2000-01-01 00:00:00"); @jensweber: warte erst mal ab, bis wir das geregelt haben.
ps:
Zitat von: justme1968 am 15 Oktober 2015, 11:05:13der name darf auch nicht harncodiert sein.
Das würde bestimmt auch nicht funktionieren ;D ;D
du hast natürlich recht mit den unterschiedlichen timern. ich merke schon ich bin noch nicht wirklich fit. also vergiss das mit dem hash.
man könnte statt eines namens den man wieder splitten muss auch einen hash verwenden:my %thash = { hash => $hash };
InternalTimer(gettimeofday() + $interval, "JeeLink_OnTimer", \%thash, 0);
und in JeeLink_OnTimer dann: my ($thash) = @_;
my $hash = $thash->{hash};
aber ich vermute es macht nicht wirklich einen unterschied.
ich würde dann nur die _TIME namens änderung einchecken.
gruss
andre
ps: kein kommentar...
Zitat von: justme1968 am 15 Oktober 2015, 12:03:00
ich würde dann nur die _TIME namens änderung einchecken.
Ich teste es heute Abend mit dieser Änderung und gebe Bescheid, dann kannst Du einchecken.
Zitat von: justme1968 am 15 Oktober 2015, 12:03:00
... ich merke schon ich bin noch nicht wirklich fit ...
Gute Besserung
@HCS:
Ich habe mir mal den RFM 69W besorgt und sofort einen Jeelink-Clone gebaut. Mehr Sensoren hat er bei mir in der Umgebung nicht empfangen, funktioniert wie er soll. Jetzt hängt er bei mir in der Testumgebung im Langzeittest.
LG
/robin
Zitat@jensweber: warte erst mal ab, bis wir das geregelt haben.
Wenn ich das jeelink modul umbenenne in myjeelink dann funktioniert es bei mir auch ;D
Mal sehen was Ihr nich rausgekommt...
Mit genau nur der Änderung funktioniert es:
my $jeeLinkTime = InternalVal($name, "${name}_TIME", "2000-01-01 00:00:00");
Kannst einchecken.
Zitat von: justme1968 am 15 Oktober 2015, 11:05:13
der name darf auch nicht harncodiert sein.
Wie machst Du das denn, kannst Du mal ein Foto einstellen ?
LG
pah
Hallo Gemeinde,
ich habe jetzt mehrere Tage den RFM69 W getestet. Bei mir empfängt er nicht mehr und nicht weniger als der RFM12B. Ich habe das in meinem Blog auch angemerkt und upgedatet. Ebenfalls hab ich da mal die Pin-Belegung veröffentlicht, falls sich jemand das Teil mal nachbauen möchte:
http://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz/
a) Kann man checken, ob es sich bei dem verwendeten Transceiver sich um ein RFM69 W oder um einen RFM69 C W handelt?
Bei mir meldet er sich immer mit RFM 69 CW, siehe Screenshot.
[LaCrosseITPlusReader.10.1p (RFM69CW f:868300 r:17241)]
b) Ich habe es nicht geschafft mit dem RFM 69 W eine PCA 301 Steckdose anzusprechen.
Natürlich mit dem PCA301 Sketch :-). Und initCommand gelöscht.
Hat das bei Euch in der Runde schon mal jemand getestet? Ich habe bei einigen Versionen vom RFM12B auch Probleme gehabt, die Steckdosen zu schalten.
LG
/robin
Zitat von: fh168 am 18 Oktober 2015, 11:49:05
b) Ich habe es nicht geschafft mit dem RFM 69 W eine PCA 301 Steckdose anzusprechen.
Natürlich mit dem PCA301 Sketch :-). Und initCommand gelöscht.
Hat das bei Euch in der Runde schon mal jemand getestet? Ich habe bei einigen Versionen vom RFM12B auch Probleme gehabt, die Steckdosen zu schalten.
LG
/robin
kann nicht gehen, siehe hier
http://forum.fhem.de/index.php/topic,11648.msg324868.html#msg324868
der pca301 sketch braucht einen jeelink classic mit dem rfm12b funkmodul. Gruß Billy
Danke Billy für die schnelle Antwort!
Sind die Dinger untereinander wohl doch nicht so kompatibel :-)
LG
/robin
Zitat von: fh168 am 18 Oktober 2015, 12:03:55Sind die Dinger untereinander wohl doch nicht so kompatibel :-)
RFM12 und RFM69 sind von der Software 100% inkompatibel.
Da musst Du Dich mal im richtigen Thread beim Autor des PCA301 Sketch erkundigen.
Zitat von: fh168 am 18 Oktober 2015, 11:49:05
a) Kann man checken, ob es sich bei dem verwendeten Transceiver sich um ein RFM69 W oder um einen RFM69 C W handelt?
Bei mir meldet er sich immer mit RFM 69 CW, siehe Screenshot.
Nein, das geht nicht. Ich glaube ich ändere die Ausgabe auf lapidar "RFM12" und "RFM69", dann ist jegliche Verwirrung behoben.
Übrigens: justme1968 hat die Korrektur für das "timeout" Attribut eingecheckt, das sollte nun mit jedem beliebigen Namen gehen.
Zitat von: HCS am 18 Oktober 2015, 12:25:42
Nein, das geht nicht. Ich glaube ich ändere die Ausgabe auf lapidar "RFM12" und "RFM69", dann ist jegliche Verwirrung behoben.
ok, hast du den RFM
HW69 auch getestet?
Zitat von: fh168 am 18 Oktober 2015, 12:47:28
ok, hast du den RFM HW69 auch getestet?
Nein, ich habe ausschließlich RFM12B und RFM69CW
ok, dann werde ich mal HW bestellen und schauen, ob der auch funktioniert.
Hallo
Da ich auch das Problem habe, das der JeeLink immer mal hängen bleibt, wollte ich das neue Timeout Attriubut nutzen.
Habe also bei timeout 120,30 eingetragen aber nach kurzer Zeit bricht die Verbindung zu Fhem ab. Es kommt der Hinweis links oben in der Ecke.
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
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?
ja. habe eingecheckt.
gruss
andre
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
Meine Sensoren kamen über eBay im 5er pack.
Gesendet von meinem iPhone mit Tapatalk
Meine Sensoren kamen über eBay im 5er pack.
Gesendet von meinem iPhone mit Tapatalk
Die hier: http://www.ebay.de/itm/400902076881
Aber die kommen garantiert auch ursprünglich aus China.
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
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.
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.
@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.
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
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.
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
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.
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: okDa 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
Hi,
Zitat von: HCS am 24 Oktober 2015, 11:42:36
...
Kannst Du mal etwas mehr loggen, ob da tatsächlich brauchbare Werte kommen?
...
klar kann ich :)
War leider kein Wind. Und geregnet hat es auch nicht :(
cu
Andreas
Zitat von: fossy am 24 Oktober 2015, 19:54:59
War leider kein Wind. Und geregnet hat es auch nicht :(
Auch ohne Wind und Regen sollte aber eine Temperatur vorhanden sein.
0°C und 99% rH sind nicht plausibel.
Zitat von: HCS am 24 Oktober 2015, 20:27:12
Auch ohne Wind und Regen sollte aber eine Temperatur vorhanden sein.
0°C und 99% rH sind nicht plausibel.
???
Die Temperatur fällt von 8,9 auf 7,9 °C und die relative Luftfeuchtigkeit steigt. 0°C kann ich in der log-Datei nicht finden!
Cubes Andreas
Gesendet von meinem SM-G900F mit Tapatalk
Zitat von: fossy am 24 Oktober 2015, 08:23:05...
[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
Hier steht doch: T= 0.0`C, relH= 99%
Zitat von: HCS am 24 Oktober 2015, 20:41:34
Hier steht doch: T= 0.0`C, relH= 99%
Da waren es draußen 0 ° C und es war neblig! Deshalb gibt es dann noch den Beitrag mit der log-Datei
Zitat von: fossy am 24 Oktober 2015, 20:48:11
Deshalb gibt es dann noch den Beitrag mit der log-Datei
Die angehängte Datei habe ich völlig übersehen. Dann werde ich sie mal lesen ...
Zitat von: HCS am 24 Oktober 2015, 20:49:45
Die angehängte Datei habe ich völlig übersehen. Dann werde ich sie mal lesen ...
OK
Zitat von: gero am 23 Oktober 2015, 14:02:35
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).
Ich habe das LaCrosse Modul erst mal so angepasst, dass der empfangene Batterie-Status nur dann akzeptiert wird, wenn auch die empfangene Temperatur akzeptiert wurde. Damit sind zumindest zerschossene Pakete kein Auslöser mehr dafür.
Ist eingecheckt und kommt morgen mit dem Update mit.
Wenn ihr das jetzt mal beobachten würdet. Wenn es nicht hilft, müssen wir in die nächste Phase eintreten.
Danke für deine Bemühungen! Ich werde die Änderung testen.
Nabend
Im Logfile taucht immer mal eine Warnung auf. Ist das ein Problem?
2015.10.23 15:33:37 1: PERL WARNING: Use of uninitialized value $bytes[4] in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.23 15:33:37 1: PERL WARNING: Use of uninitialized value $bytes[4] in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 212.
Zitat von: HCS am 24 Oktober 2015, 07:40:42
Ich muss mal am Labornetzteil das Verhalten eines Sensors bei sinkender Spannung anschauen, ob der bei low bat noch korrekte Temp und Hum sendet.
Gesagt getan.
Das Verhalten ist so (getestet mit einem TX29DTH und einem 30.3155.WD):
Bis 2,3V ist normal
Unter 2,3V sendet er low battery, korrekt die Werte und zeigt im Display das Batterie-Symbol
Unter 2,2V beginnt er leicht falsche Werte zu senden (Temperatur einige Grad falsch)
Unter 2,1V sendet er nicht mehr
Interessant ist: wenn er einmal unter 2,3V war, dann sendet er immer low battery weiter, auch wenn man die Spannung wieder bis auf 3V erhöht.
Das lässt vermuten, dass die vereinzelten falschen low batt tatsächlich Übertragungsfehler sind.
Zitat von: Kalli01 am 24 Oktober 2015, 22:21:23
Im Logfile taucht immer mal eine Warnung auf. Ist das ein Problem?
2015.10.23 15:33:37 1: PERL WARNING: Use of uninitialized value $bytes[4] in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.23 15:33:37 1: PERL WARNING: Use of uninitialized value $bytes[4] in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 212.
Das sieht so aus, als ob von Deinem JeeLink-Clone manchmal verstümmelte Daten an FHEM übergeben werden.
Was da rüber kommt sollte so aussehen: OK 9 28 129 4 188 59
Der Fehler kann eigentlich nur dann auftreten, wenn das nicht komplett ist, also so z.B.: OK 9 28 129 4 188
Da Du ja auch "gelegentliches Aussteigen" des Clones berichtet hast, würde ich mal vermuten, dass der nicht nur stehenbleiben kann sondern auch Müll schicken kann.
Generell kann ich das aber abfangen, dass wenn die Daten nicht komplett sind, keine seltsame Dinge ablaufen.
Hallo,
kann es sein, dass es beim neuen Timeout-Attribut noch ein Problem bei der Zeitumstellung gibt? Ich habe das Attribut auf 30,120 konfiguriert. Heute Nacht zwischen 2 und 3 Uhr wurde der JeeLink im 2 Minuten Rythmus gereseted...
Gruß,
Nico
Zitat von: Wallmeier am 25 Oktober 2015, 08:21:19kann es sein, dass es beim neuen Timeout-Attribut noch ein Problem bei der Zeitumstellung gibt?
Ja. So ist es.
Gerade eingecheckt.
Das hier sollte nun nicht mehr auftreten. Pakete mit falscher Länge werden nun ignoriert.
Zitat von: Kalli01 am 24 Oktober 2015, 22:21:23
Im Logfile taucht immer mal eine Warnung auf. Ist das ein Problem?
2015.10.23 15:33:37 1: PERL WARNING: Use of uninitialized value $bytes[4] in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 206.
2015.10.23 15:33:37 1: PERL WARNING: Use of uninitialized value $bytes[4] in bitwise and (&) at ./FHEM/36_LaCrosse.pm line 212.
Und dann habe ich noch die battery2 readings eliminiert. Auch ein zweikanaliger Sensor wie z.B. TX25IT hat nur eine Spannungsversorgung.
Somit macht es keinen Sinn, ein battery
und ein battery2 reading zu haben.
Zitat von: fossy am 24 Oktober 2015, 08:23:05
ich habe zu Hause auch eine WS1080
...
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.
Generell sieht das machbar aus.
Allerdings gibt es da noch einige Problemchen:
Der Sketch ist vom Programmspeicher her am Anschlag, da geht eigentlich nichts mehr rein.
Entweder muss ich da noch Platzopimierung hinbekommen oder es muss irgendwie alternativ werde. Eine WS 1600 und eine WS 1080 hat man vermutlich nicht beides gleichzeitig.
Die Implementierung müsste jemand machen, der eine WS 1080 hat. Das blind ohne Station zu imlementieren ist wenig sinnvoll.
Ich könnte das so weit vorbereiten, dass nur noch das Protokoll umgesetzt werden muss.
Mit Unterstützung bekomme ich das wahrscheinlich hin.
alternativ könnte ich dir auch ssh Zugang geben. auf dem raspberry läuft aktuell kein fhem und er ist nur ein Access Point
Gesendet von meinem SM-G900F mit Tapatalk
Zitat von: fossy am 28 Oktober 2015, 06:28:18Mit Unterstützung bekomme ich das wahrscheinlich hin.
Ich bereite es mal soweit vor. Musst eigentlich keine Kenntnisse über RFM12 und Funkprotokolle haben, nur C++ können, um die Routine, die die empfangenen Bytes auswertet und in das, was an FHEM rausgegeben wird umwandelt, schreiben zu können. Die kann ich aber auch schon mal grob vorbereiten.
Zitat von: fossy am 28 Oktober 2015, 06:28:18alternativ könnte ich dir auch ssh Zugang geben. auf dem raspberry läuft aktuell kein fhem und er ist nur ein Access Point
Wenn würde nur helfen, den Port, an dem der JeeLink steckt, mit ser2net freizugeben, dass ich mit der Entwicklungsumgebung auf dem JeeLink arbeiten kann, der die WS 1080 empfängt. Das wäre mal eine spannende Sache, ob das funktioniert. Mit ser2net einen USB-port auf dem Raspi bereitstellen und mit z.B. HW VSP3 auf einem Windows Rechner mit der Entwicklungsumgebung damit arbeiten. Kannst es ja mal ausprobieren.
Hi,
... also ser2net läuft. Ich kann die Ausgaben auch per Telnet anschauen. Ob das aber reicht, damit du darauf zugreifen kannst?! Keine Ahnung :(
Ich schicke dir eine PN mit der Adresse...
cu
Andreas
Zitat von: fossy am 28 Oktober 2015, 18:05:31
... also ser2net läuft. Ich kann die Ausgaben auch per Telnet anschauen. Ob das aber reicht, damit du darauf zugreifen kannst?! Keine Ahnung :(
Klappt leider nur fast.
Ich kann mit dem JL aus der Entwicklungsumgebung kommunizieren, aber flashen klappt nicht, da geht der reset irgendwie nicht durch.
Egal. Ich habe mal einen Versuch gemacht.
Flashe mal den angehängten Sketch drauf und steck den JL dann wieder da hin, wo er gerade ist.
Mal sehen, ob das so schon grob läuft.
Ich schaue dann wieder drauf um zu sehen, was sich tut.
hi,
möglcherweise ist ser2net noch nicht richtig configuriert :\
hab mal genauer in die config geschaut. Der Wert "State" stand auf "telnet". Ich stelle mal auf RAW und schau mal, ob mir nochwas auffällt.
cu
Andreas
P.S. Hast du Telegram oder Hangouts?
ich glaube flashen per ser2net geht nicht. avrdude greift direkt auf das jeweilige device file zu.
gruss
andre
Zitat von: fossy am 28 Oktober 2015, 21:00:42
P.S. Hast du Telegram oder Hangouts?
weder noch, was ist das?
Aber flashe mal bitte den sketch von oben, eventuell hat es sich dann eh erledigt, weil es bereits funktionieren könnte.
Die Daten sehe ich, das ist OK so weit mit ser2net
ok A8 C0 56 63 00 00 00 88 06 5D
2048-10-15 02:01:29 pkt_cnt: 9 ok_cnt: 6 pkt: A8C0566300000088065D
2048-10-15 02:01:29 ID: 8C, T= 8.6`C, relH= 99%, Wvel= 0.0m/s, Wmax= 0.0m/s, Wdir=SE , Rain= 40.8mm
nok 94 EC 3C 26 C7 FC 7B 06 53 90
nok 7C 5F 0B 80 01 03 F8 36 82 1A
nok 06 60 10 10 68 C3 A1 F0 48 10
nok D0 7A A0 C4 36 70 20 01 78 34
ok, ich versuche mal zu flaschen. ich muss das auf dem raspberry machen, da das ding 5km weit weg ist...
beim letzten mal hat das nicht geklappt.
telegram und hangouts ist sowas ähnliches wie whatsapp. da hätte ich einen "schnellen draht" zu dir gehabt :D
... scatch ist drauf!
Das funktioniert. Mit diesem Sketch solltest Du in FHEM ein LaCrosse device bekommen (vermutlich morgen erst, weil ich heute einen fix für autocreate engecheckt habe) und es sollte die Daten der WS 1080 anziegen.
Rain ist evtl. noch falsch, aber Details können wir dann noch richten.
Was der Sketch rausgibt sieht aber schon mal gut aus.
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
OK WS 140 3 4 59 99 0 81 8 202 0 0 0 3 0
OK WS 140 3 4 59 99 0 81 8 202 0 0 0 6 0
OK WS 140 3 4 59 99 0 81 8 202 0 0 0 6 0
OK WS 140 3 4 59 99 0 81 7 8 0 0 0 6 0
OK WS 140 3 4 59 99 0 81 7 8 0 0 0 6 0
OK WS 140 3 4 59 99 0 81 7 8 0 0 0 3 0
OK WS 140 3 4 59 99 0 81 7 8 0 0 0 3 0
das ist ja toll!!! Vielen Dank!!! :)
:-*
Ja,
und cool, habe gerade mal ein JeeLink device auf deinen freigegebenen Port konfiguriert und per autocreate ein LaCrosse device anlegen lassen.
Bin nicht sicher, ob es mir hilft, wenn ich Deine Wetterdaten logge, aber es geht. ;D
Wo ist das denn, wo es immer so feucht ist?
Die Adresse in der definition habe ich verfälscht, um Dich zu schützen.
Den "sensorType 3=unknown" muss ich dann noch im LaCrosse Modul richten.
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF a .... g:54001
DeviceName a ... g:54001
FD 4
NAME myJeeLink
NR 12
PARTIAL
RAWMSG OK WS 140 3 4 58 99 0 81 5 70 0 0 0 0 0
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
myJeeLink_MSGCNT 7
myJeeLink_TIME 2015-10-28 22:05:53
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
Readings:
2015-10-28 22:01:13 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0t 0m 2r 868300f 220h 0a v
internals:
CFGFN
DEF 8C
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2015-10-28 22:04:17
MSGCNT 1
NAME LaCrosse_8C
NR 122
STATE T: 8.3 H: 99
TYPE LaCrosse
addr 8C
battery_new 0
bufferedH 99
bufferedT 8.3
corr1 0
corr2 0
myJeeLink_MSGCNT 1
myJeeLink_RAWMSG OK WS 140 3 4 59 99 0 81 5 70 0 0 0 0 0
myJeeLink_TIME 2015-10-28 22:04:17
previousH 99
previousR 40.5
previousT 8.3
sensorType 3=unknown
Readings:
2015-10-28 22:04:17 battery ok
2015-10-28 22:04:17 error 0
2015-10-28 22:04:17 humidity 99
2015-10-28 22:04:17 rain 40.5
2015-10-28 22:04:17 state T: 8.3 H: 99
2015-10-28 22:04:17 temperature 8.3
2015-10-28 22:04:17 windDirectionDegree 135
2015-10-28 22:04:17 windDirectionText SE
2015-10-28 22:04:17 windGust 0
2015-10-28 22:04:17 windSpeed 0
Attributes:
IODev myJeeLink
room LaCrosse
Das sind sehr gute Neuigkeiten! :)
Der Sensor befindet sich im thüringischen Teil der Rhön. In der Nähe befindet sich ein Fluss - die Ulster :D
... vielleicht ist deshalb die Luftfeuchtigkeit zur Zeit so hoch :\
Zitat von: fossy am 28 Oktober 2015, 22:24:54In der Nähe befindet sich ein Fluss - die Ulster :D
Der Fluss scheint direkt an Deinem Sensor vorbeizufließen.
Wenn Du den JeeLink da stecken lässt, wo er jetzt ist, habe ich morgen einen schönen gplot von Deinem Temperaturverlauf heute Nacht ;D ;D
Hallo,
gibt es hier einen Anzeigefehler?
Auszug aus Log:
...
2015.10.28 23:19:37 3: Opening JeeLink_LaCrosse device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI02IDPC-if00-port0
2015.10.28 23:19:37 3: Setting JeeLink_LaCrosse serial parameters to 57600,8,N,1
2015.10.28 23:19:37 3: JeeLink_LaCrosse device opened
...
2015.10.28 23:19:44 3: SZ_TempLuft: I/O device is JeeLink_LaCrosse
2015.10.28 23:19:44 3: Opening JeeLink_PCA301 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D3R5-if00-port0
2015.10.28 23:19:44 3: Setting JeeLink_PCA301 serial parameters to 57600,8,N,1
2015.10.28 23:19:44 3: JeeLink_PCA301 device opened
2015.10.28 23:19:45 3: TO_Temp: I/O device is JeeLink_PCA301
2015.10.28 23:19:45 3: BA_TempLuft: I/O device is JeeLink_PCA301
2015.10.28 23:19:45 3: DG_Ventilator: I/O device is JeeLink_PCA301
2015.10.28 23:19:45 3: DG_Multimedia: I/O device is JeeLink_PCA301
2015.10.28 23:19:45 3: DG_Steckdose_Ecke: I/O device is JeeLink_PCA301
...
TO_Temp und BA_TempLuft haben aber als IODev JeeLink_LaCrosse und das ist auch richtig. Als Beispiel ein Teil von List:
Internals:
CHANGED
DEF 29
IODev JeeLink_LaCrosse
JeeLink_LaCrosse_MSGCNT 56
JeeLink_LaCrosse_RAWMSG OK 9 41 1 4 218 44
JeeLink_LaCrosse_TIME 2015-10-28 23:47:04
LASTInputDev JeeLink_LaCrosse
LaCrosse_lastRcv 2015-10-28 23:47:04
MSGCNT 56
NAME BA_TempLuft
NR 390
STATE T: 24.2 H: 44
TYPE LaCrosse
...
Versionen:
36_JeeLink.pm 9562 2015-10-20 17:05:44Z justme1968
36_LaCrosse.pm 9678 2015-10-25 21:44:41Z hcs-svn
36_PCA301.pm 8443 2015-04-16 09:12:08Z justme1968
Alles soweit ok. Nur die Ausgabe im Logfile nicht. Gibt es dafür ein Lösung?
MfG
lohnt es schon, die WS zu kaufen, oder soll man noch warten, weil es bei euch weiter klappt....
Zitat von: HCS am 24 Oktober 2015, 21:20:05
Ich habe das LaCrosse Modul erst mal so angepasst, dass der empfangene Batterie-Status nur dann akzeptiert wird, wenn auch die empfangene Temperatur akzeptiert wurde. Damit sind zumindest zerschossene Pakete kein Auslöser mehr dafür.
Ist eingecheckt und kommt morgen mit dem Update mit.
Wenn ihr das jetzt mal beobachten würdet. Wenn es nicht hilft, müssen wir in die nächste Phase eintreten.
Die low battery Warnungen sind gefühlsmäßig etwas weniger geworden. Aber dennoch habe ich gestern und heute wieder jeweils eine empfangen.
Vielleicht ist doch ein Filter notwendig, der auf einen Mehrfachempfang checkt?
Gruß,
Gero
Zitat von: gero am 29 Oktober 2015, 07:29:16
Die low battery Warnungen sind gefühlsmäßig etwas weniger geworden. Aber dennoch habe ich gestern und heute wieder jeweils eine empfangen.
Vielleicht ist doch ein Filter notwendig, der auf einen Mehrfachempfang checkt?
Ja, werde mich mal mit dem Thema beschäftigen.
Zitat von: Ralf W. am 29 Oktober 2015, 00:05:53
gibt es hier einen Anzeigefehler?
Auszug aus Log:
2015.10.28 23:19:45 3: BA_TempLuft: I/O device is JeeLink_PCA301
TO_Temp und BA_TempLuft haben aber als IODev JeeLink_LaCrosse und das ist auch richtig. Als Beispiel ein Teil von List:
Internals:
IODev JeeLink_LaCrosse
NAME BA_TempLuft
Alles soweit ok. Nur die Ausgabe im Logfile nicht. Gibt es dafür ein Lösung?
Die Ausgabe ist tatsächlich falsch. Ich schaue es mir mal an, wenn es dann auf der ToDo Liste auf Platz 1 vorgerückt ist.
Habe ich es jetzt richtig verstanden, das Ihr den Stick per ser2net übers Internet freigegeben hat und es funktioniert?
Zitat von: JoeALLb am 29 Oktober 2015, 06:58:56
lohnt es schon, die WS zu kaufen, oder soll man noch warten, weil es bei euch weiter klappt....
Da muss ich mit einer Antwort mit mir ringen :)
Eigentlich hätte ich gesagt, warte ab, bis fossy es eingereichtet und als funktionstüchtig deklariert hat.
Andererseits sieht es momentan danach aus, dass es funktioniert, soweit ich das mit der station von fossy aus der Ferne testen und beurteilen kann.
Ein weiterer Tester in diesem frühen Stadium wäre natürlich auch praktisch.
Du merkst schon, ich winde mich ... ;)
Zumindest wissen wir jetzt schon mal, wie die Nacht in der Rhön verlaufen ist. ;D
Anbei der Plot. Die Lücke kommt wohl daher, dass die Verbindung zum "fossy Raspi" heute nacht mal weg war.
Aber generell sieht der Plot ganz gut aus.
Rain ist noch nicht geprüft, ob das stimmt und die 99% Feuchte kommen mir immer noch seltsam vor, aber möglicherweise ist es bei fossy tasächlich so feucht.
Ob die Station low battery in irgend einem Bit versteckt sendet ist auch noch unklar, aber da kann notfalls man auch ohne leben.
Zitat von: Wernieman am 29 Oktober 2015, 10:10:29
Habe ich es jetzt richtig verstanden, das Ihr den Stick per ser2net übers Internet freigegeben hat und es funktioniert?
Genau so ist es. fossy hat den Port von seinem Raspi, an dem der JeeLink steckt, mit ser2net feigegeben und ich habe hier ein JeeLink device auf diesem Port eingerichtet, "quer durchs Internet"
Die definition sieht so aus:
define myJeeLink JeeLink wirdnichtverraten.org:54001
Zitat von: HCS am 29 Oktober 2015, 09:28:11
Die Ausgabe ist tatsächlich falsch. Ich schaue es mir mal an, wenn es dann auf der ToDo Liste auf Platz 1 vorgerückt ist.
Danke! Brennt ja auch nichts an, da alles korrekt läuft.
MfG
Die Feuchte mit der WS 1080 scheint doch zu funktionieren, nachdem sie am Nachmittag mal runter und wieder hoch gegangen ist.
Ich dachte schon, dass da ein Fehler vorliegt, weil sie permanent auf 99% stand.
sehr schön. also kann ich dich jetzt "rausschmeißen"? :D
... weil ich bekomme sonst keine Daten zum selber ausprobieren :\
Sag einfach Bescheid, wenn ich dich nochmal "ran lassen soll" ;)
cu
Andreas
bei mir wird kein Gerät angelegt :(
ich dachte, wenn ich den jeelink als Device definiere und autocreate aktiv ist, die WS1080 dann automatisch angelegt wird?!
define myJeeLink JeeLink /dev/ttyUSB0@57600
Was mach ich falsch?!
RAWMSG wird empfangen:
RAWMSG
OK WS 140 3 4 83 99 0 81 7 8 0 0 0 0 0
Zitat von: fossy am 29 Oktober 2015, 19:02:21
Was mach ich falsch?!
FHEM-Update dass Du das LaCrosse-Modul von gestern hast und dann
set myJeeLink LaCrossePairForSec 120 ignore_batteryund dann ein bis zwei Minuten warten, dann sollte das device angelegt sein, incl. filelog
Das update hatte ich gemacht. Aber das Pairing hat gefehlt!
Danke!
... typischer Anfängerfehler :(
Zitat von: fossy am 29 Oktober 2015, 20:34:37
Das update hatte ich gemacht. Aber das Pairing hat gefehlt!
Da bist Du nicht der Erste ... ;D
Check mal bitte, ob die Werte mit denen der Station übereinstimmen. Wenn das so weit passt, dann mache ich den Sketch amtlich, muss noch etwas aufräumen und Platz schaffen, dass das alles wieder rein passt.
Könnte dann in einigen Tagen eine offizielle Version draus machen.
Alles klar. mach ich!
Vielleicht könnte man das pairing mit ins wiki schreiben?
Oder umbenennen/alias anlegen: SucheSenderFürXsekunden
oder so
Guten Abend!
Erst einmal ein großes Lob an alle, die dieses Projekt (laCrosse) möglich gemacht haben.
Zu meinem Problem:
Ich habe 2 TFA 30.3155.WD Sensoren. Einer und ein fremder Sensor im Garten (danke Nachbar ;D ) werden von meinem Jeelink Clone empfangen. der zweite TFA allerdings will ums verrecken nicht erkannt werden. Ich habe ihn schon eingeschickt, weil ich dachte, er wäre defekt. aber der Ersatz meldet sich auch nicht in FHEM.
Ich verwende folgende Einstellungen:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 10
JeelinkClone_MSGCNT 84
JeelinkClone_TIME 2015-10-30 19:53:48
NAME JeelinkClone
NR 25
PARTIAL
RAWMSG OK 9 63 1 4 174 85
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1p (RFM69CW f:868300 t:30~3)]
attr
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>
initCommands 30t v 2m
verbose 5
Ich habe schon versucht:
- über init command die frequenz zu setzen auf: 868280, 868330, 868340
allerdings zeigt mir die Zeile model weiterhin f:868300 und die anderen Sensoren werden nciht mehr empfangen
Lohnt es sich statt einer Labda/4 8,6cm lieber eine Lambda/2 17,5cm Antenne anzulöten?
Wer kann mir hier weiterhelfen? Danke im Voraus.
Zitat von: HCS am 29 Oktober 2015, 23:46:24
Da bist Du nicht der Erste ... ;D
Check mal bitte, ob die Werte mit denen der Station übereinstimmen. Wenn das so weit passt, dann mache ich den Sketch amtlich, muss noch etwas aufräumen und Platz schaffen, dass das alles wieder rein passt.
Könnte dann in einigen Tagen eine offizielle Version draus machen.
hab mir heute mal die werte angesehen. Temperatur und Luftfeuchtigkeit sind i. O.
Bei den Windgeschwindigkeiten kommen m/s an. Ist das so richtig? Also wenn fhem 1 anzeigt, zeigt die Station 3,6 km/h an.
Regen könnte ich noch nicht prüfen
Gesendet von meinem SM-G900F mit Tapatalk
Zitat von: SonOfAbaddon am 30 Oktober 2015, 20:05:21
Ich habe 2 TFA 30.3155.WD Sensoren. Einer und ein fremder Sensor im Garten (danke Nachbar ;D ) werden von meinem Jeelink Clone empfangen. der zweite TFA allerdings will ums verrecken nicht erkannt werden.
Ich glaube, dass man langsam von den 30.3155.WD abraten muss, die machen immer wieder Probleme :(
Also
initCommands 30t v 2mdas ergibt keinen Sinn. Wenn Du fix auf 9579 kbps willst, dann mit:
initCommands 0t 1r vDas v immer hinten, da es die Einstellungen abrufen soll, damit nach einem page reload in FHEM was aktuelles angezeigt wird.
868280, 868330, 868340 ist zu grob, man muss sich in 5kHz Schritten rantasten. Bei mir passt z.B. 868290
Wobei Du einen RFM69CW hast, der sollte das eigentlich ohne Frequenzanpassung packen. Aber evtl. geht das auch nicht immer.
Die Frequenz kannst Du in initcommands oder mit
set JeelinkClone raw 868290f vsetzten. Und danach muss in model auch die aktuelle Frequenz stehen.
Und nicht vergessen, wenn die Batterien lange genug drin waren, sendet er kein "new battery" mehr
also immer zu Sicherheit das pairing so machen:
set JeelinkClone LaCrossePairForSec 120 ignore_batteryZitat von: fossy am 30 Oktober 2015, 20:57:43
Bei den Windgeschwindigkeiten kommen m/s an. Ist das so richtig?
Ja, Wind ist in m/s
Zitat von: fossy am 30 Oktober 2015, 20:57:43
Regen könnte ich noch nicht prüfen
Draußen tanzen und singen, dann regnet es auch ;D
Zitat von: HCS am 30 Oktober 2015, 21:30:22
Die Frequenz kannst Du in initcommands oder mit
set JeelinkClone raw 868290f v
setzten. Und danach muss in model auch die aktuelle Frequenz stehen.
Super, danke. Die Syntax hat bei mir nie funktioniert. Ich bin erst seit 2 Wochen mit FHEM zu gange, da ist jeder Tipp Gold wert. Ergebnis: 868305 passt bei mir.
Danke!
Zitat von: SonOfAbaddon am 30 Oktober 2015, 22:08:19
Ergebnis: 868305 passt bei mir.
Prima. Musst die 868305f aber trotzdem dann in die initCommands reinschrieben, sonst ist es nach einem Neustart weg.
Der Fall ist aber interessant. Drei 30.3155.WD, zwei davon gehen mit 868300 und einer nur mit 868305
Das kann doch nur eins bedeuten: einzelne 30.3155.WD liegen mit der Frequenz daneben, was wohl eine "30.3155.WD Spezialität" ist, bei allen anderen Sensor-Typen, die empfangbar sind, wurde das bisher noch nie beobachtet.
@Billy: Könntest Du im wiki im Abschnitt Frequenzanpassung speziell auf die 30.3155.WD hinweisen, dass es bei denen häufig erforderlich ist und wie man sich in 5kHz Schritten rantastet?
Ich habe den Sketch Version 10.1q eingecheckt.
Unterstützt die WS 1080. Kann dann ab morgen mit set myJeeLink flash aktualisiert werden.
Nachtrag:
Die WS 1080 gibt es (unter gleichem Namen) in einer OOK- und in einer FSK-Version
Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version nicht.
Die FSK-Version erkennt man an:
- Runder grüner Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7"
- Das radio ist ein RFM01, erkennt man auch schon an der Form, es ist fast quadratisch.
Die OOK-Version erkennt man an:
- Runder grüner Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS A14C"
- Das radio ist ein ASK868MA1, erkennt man auch schon an der Form, es ist rechteckig und mit ASK868MA1 beschriftet.
Zitat von: HCS am 31 Oktober 2015, 11:42:04
Ich habe den Sketch Version 10.1q eingecheckt.
Unterstützt die WS 1080. Kann dann ab morgen mit set myJeeLink flash aktualisiert werden.
Unterstützt dieser Sketch Version 10.1q alle bisherigen devices oder musstest du was rauswerfen?
Werde das WIKI entsprechend anpassen, dauert aber etwas.
Billy
Zitat von: Billy am 31 Oktober 2015, 16:22:20
Unterstützt dieser Sketch Version 10.1q alle bisherigen devices oder musstest du was rauswerfen?
Alles noch drin, was es bisher gab. Mit etwas stopfen und quetschen ging es rein :)
Hallo Leute,
ich hab mir eine Mobile Alerts Ausstattung von ELV gegönnt und hätte das nun gern über JeeLink angebunden anstatt über HTTPMOD. Ich hab's dann doch lieber alles gleich in meinem System als es irgendwo anders abholen zu müssen und hoffen, dass keine Änderungen kommen oder ich's irgendwann nicht mehr dort abholen kann.
Ich hab gelesen, dass die Mobile Alerts Sensoren mit dem LaCrosse Protokoll funktionieren sollten. Leider raff ich's irgendwie nicht, denn ich bekomm leider keine Verbindung zwischen FHEM/JeeLink und einem Sensor. Versucht hab ich's mit einem MA10200 und einem MA10350.
Meine JeeLink konfig sieht so aus:
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF
/dev/ttyUSB0@57600
DeviceName
/dev/ttyUSB0@57600
FD
14
LaCrossePair
2
NAME
myJeeLink
NR
52
PARTIAL
RAWMSG
OK 9 49 1 4 239 234
STATE
Initialized
TYPE
JeeLink
model
[LaCrosseITPlusReader.10.1q (RFM69 f:868400 t:30~3)]
myJeeLink_MSGCNT
10
myJeeLink_TIME
2015-11-04 20:38:08
Frequenz hab ich von 868290 bis 868400 in 5KHz Schritten durchprobiert. Leider ebenfalls ohne Erfolg. Laut Infos sollten die Teile auf 868.3 MHz senden. Zumindest würd das die Beschreibung propagieren. Das Pairing hab ich immer so versucht: set myJeeLink LaCrossePairForSec 120 ignore_battery
Ich wär euch sehr dankbar für Input und Hilfe! Ich kann natürlich auch mehr Infos liefern. Bin mir nur nicht sicher was ihr denn noch benötigt.
Gruß Chris
Zitat von: thats am 04 November 2015, 21:33:03Ich hab gelesen, dass die Mobile Alerts Sensoren mit dem LaCrosse Protokoll funktionieren sollten.
Kannst Du bitte mal eine Quelle nennen, wo das zu lesen ist?
Hast Du noch andere LaCrosse Sensoren (also nicht Mobile Alerts) laufen?
Weil empfangen wurde etwas, Du hast eine RAWMSG mit "OK 9 49 1 4 239 234"
Das ist ein Sensor mit 26,3 °C
Könnte der MA10200 sein.
Dass der MA10350 mit dem aktuellen Sketch funktioniert kann ich mir aber nicht vorstellen. Der muss ja zu Temperatur und Feuchte auch noch den Wasseralarm übertragen. Da passt keines der bisherigen Protokolle.
Generell: LaCrosse ist nicht LaCrosse. Bei LaCrosse gibt es unzählige Protokolle, und jedes muss im Sketch implementiert werden.
Wenn die Beschreibung von ELV tatsächlich stimmt und der MA10200 tatsächlich ein Messintervall von 7 Minuten hat, muss man mit
LaCrossePairForSec 120
schon Glück haben, ihn zu erwischen.
Zitat von: HCS am 04 November 2015, 21:59:44
Kannst Du bitte mal eine Quelle nennen, wo das zu lesen ist?
http://forum.fhem.de/index.php/topic,37397.msg351465.html#msg351465 (http://forum.fhem.de/index.php/topic,37397.msg351465.html#msg351465)
MfG
Ja, mit dem MA10101. Er hat aber MA10200 und MA10350
Ja, gesehen.
Aber bisher nirgendwo eine Bestätigung gesehen (nur geschrieben), dass MAirgenwas mit Jeelink empfangen wird.
MfG
[Edit]
Auch mit längerem Intervall nix.
[/Edit]
Guten Morgen,
dann baut das wohl auf meiner Gutgläubigkeit auf. Hab mir auch die Gerätschaften auf der LaCrosse Webseite angesehen und eben dort die gleichen Teile gesehen und hab dann angenommen, dass hier wohl die gleiche Technik verbaut wird.
Komisch ist, dass du etwas mit 26,3° siehst. Ich hab keine anderen LaCrosse Sensoren im Einsatz und schon gar nicht mit dieser Temperatur. Die Sensoren liegen bei mir in einem Bereich von ~ 20°.
Heißt für mich wohl, dass ich nicht über die HTTPMOD Variante rum komme, oder?
Schönen Tag euch allen!
Hallo Developer und Mitlesende,
erstmal möchte ich mich vorstellen. Ich heiße Martin und lese diesen Thread schon gefühlte Ewigkeiten mit und warte schon sehr lange sehnsüchtig darauf das die WS1080 mit in den Sketch eingebaut wird. Nun ist es soweit und leider schaffe ich es irgendwie trotzdem nicht meine Wetterstation kabellos einzubinden...
Es ist eine PCE-FWS 20, das ist doch eine WS1080 ?!
Dazu habe ich einen Jeelink original classic mit folgenden Einstellungen:
define myJeeLink JeeLink /dev/ttyUSB0@57600
attr myJeeLink flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr myJeeLink initCommands 0r 0a v
trotzdem wird nach einem "set myJeeLink LaCrossePairForSec 300 ignore_battery" die Wetterstation einfach nicht gefunden. Dafür habe ich mittlerweile die komplette Nachbarschaft eingefangen und kann die Aussen- und Wohnzimmertemperaturen der umliegenden Häuser sehen *fg* Die Wetterstattion habe ich mittlerweile ins gleiche Zimmer wie den Raspberry geholt...aber ohne Erfolg.
Gibt es irgendein "How to" das ich nicht kenne um die WS1080 einzubinden? Oder kann jemand so nett sein das Wiki entsprechend abzudaten? Sorry, normalerweise finde ich dann irgendwan im Forum eine Lösung zu meinen Fragen aber hier komme ich leider einfach nicht weiter.
Ansonsten ein ganz großes und dickes Danke an die Gemeinde die so ein tolles Projekt ermöglicht (auch wenn einem manchmal alle Haare ausfallen, wenn man nicht ein Programmiergott ist)
viele Grüße
Martin
Zitat von: Tim_Buktu am 05 November 2015, 17:08:33
Es ist eine PCE-FWS 20, das ist doch eine WS1080 ?!
Hmm, keine Ahnung.
Zitat von: Tim_Buktu am 05 November 2015, 17:08:33
define myJeeLink JeeLink /dev/ttyUSB0@57600
attr myJeeLink initCommands 0r 0a v
Das wäre korrekt.
Zitat von: Tim_Buktu am 05 November 2015, 17:08:33Oder kann jemand so nett sein das Wiki entsprechend abzudaten?
Du hast egentlich alles richtig gemacht. Da gibt es nun eine Reihe von möglichen Ursachen:
- Der Sketch ist nicht aktuell (10.1q)
- FHEM ist nicht auf dem aktuelle Stand
- Der eingecheckte Sketch funktioniert nicht mit der WS 1080
- PCE-FWS 20 ist nicht gleich WS 180
Kannst Du folgendes machen: Den JeeLink an einen Rechner mit Terminalprogramm stecken und mal 10 Minuten loggen, was er sendet und das hier anhängen?
Ich will mal sehen, ob der von der Station nichts rausgibt oder ob es in FHEM auf der Strecke bleibt.
Das Problem in diesem Fall ist, dass ich keine WS 1080 habe, das ist ungeschickt, weil ich selbst nicht testen kann.
Da fehlt mir aber auch eine Rückmeldung von fossy.
@fossy: Läuft Deine WS 1080 mit dem Sketch, den ich eingecheckt habe, oder noch mit dem Vorab-Experiment? Und was ist mit rain?
Falls sonst jemand eine WS 1080 am Laufen hat, darf er das gerne hier melden ;)
Zitat von: Tim_Buktu am 05 November 2015, 17:08:33
(auch wenn einem manchmal alle Haare ausfallen, wenn man nicht ein Programmiergott ist)
Glaub mir, die fallen einem auch aus, wenn man sich lange genug mit LaCrosse Implementierung beschäftigt. ;D ;D
sorry, ja, hab gestern dem aktuellen Sketch drauf geladen und es funktioniert!
Gesendet von meinem SM-G900F mit Tapatalk
Hallo HCS,
danke für Deine schnelle Antwort.
Also ich glaube die 4 Möglichkeiten können wir mit fossy´s Hilfe ausschliessen.
Ich habe heute das FHEM Update gemacht und danach den Sketch geupdatet. Aktuell habe ich also FHEM 5.6 von heute Nachmittag und der Sketch ist 10.1q.
Internals
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 11
NAME myJeeLink
NR 32
PARTIAL
RAWMSG OK 9 8 1 4 83 106
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
myJeeLink_MSGCNT 945
myJeeLink_TIME 2015-11-05 18:32:26
Die Wetterstation scheint nach mehreren Seite eine WH1080 zu sein:
z.B. hier
http://wiki.wetterstationen.info/index.php?title=WH1080_/_WS1080
http://baublog.ozerov.de/2011/12/software-fuer-meine-wetterstation-wh1080/
Wie geht das mit dem Loggen und dem Terminalprogramm. Könnte ich auch per Putty auf den Raspberry und von dort etwas loggen? Wie ist der Befehl dafür?
DANKE !!!!
Du kannst die Ausgabe des seriellen Ports mit loggen. Ich glaube "minicom" hieß das Programm.
Gesendet von meinem SM-G900F mit Tapatalk
in einer ssh Sitzung:
cat /dev/ttyUSB0 57600 | tee log.txt
FHEM darf aber die Schnittstelle glaube ich nicht offen haben.
Hallo,
ich habe mal FHEM beendet und mit Minicom geloggt. Es kommt so circa alle 4 Sekunden der gleich Eintrag....sieht dann so aus:
Willkommen zu minicom 2.6.1
Optionen: I18n
Übersetzt am Apr 28 2012, 19:24:31.
Port /dev/ttyUSB0
Drücken Sie CTRL-A Z für Hilfe zu speziellen Tasten
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
OK 9 8 1 4 82 106
OK 9 8 1 4 83 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 83 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
OK 9 8 1 4 81 106
Irgendwie ist das ja nicht viel.... :-(
Zitat von: Tim_Buktu am 05 November 2015, 17:08:33
...
Es ist eine PCE-FWS 20, das ist doch eine WS1080 ?!
Hallo Tim_Buktu,
hier ist eine Seite auf der das so dargestellt wird. http://wiki.wetterstationen.info/index.php?title=WH1080_/_WS1080
pejonp
Zitat von: Tim_Buktu am 05 November 2015, 20:20:36
ich habe mal FHEM beendet und mit Minicom geloggt. Es kommt so circa alle 4 Sekunden der gleich Eintrag....sieht dann so aus:
OK 9 8 1 4 81 106
Irgendwie ist das ja nicht viel.... :-(
Das ist ein Sensor der 10,5 °C und keine Luftfeuchte sendet. Tippe mal auf den Außensensor vom Nachbarn.
aber absoult nichts, was WS 1080 wäre :(
gerade etwas gelesen:
ZitatThe sensor data transmission stops in the 59th minute. Then there are no transmissions for three minutes, apparently to be noise free to acquire the DCF77 signal.
Aber laut deinem Log war das nicht in diesem Zeitraum
und:
ZitatThe Fine Offset weather station switched over to a new RF transmission protocol somewhere in 2012. While the old protocol was a On-Off-Keying (OOK) protocol, the V2 protocol used Frequency-Shift-Keying (FSK)
Kann es sein, dass Du noch die OOK-Version hast? Wir können nur FSK empfangen!
Aktuell gehen mir die Ideen aus ...
Hallo,
erstmal danke an pejonp. Ja, ich gehe eigentlich auch davon das es eine WH1080 ist.
@ HCS
Mhh ich habe die im August 2014 gekauft. Wenn es nicht gerade der Ladenhüter war, dann müsste die schon FSK sprechen. Aber auszuschließen ist das halt nicht.
Bevor ich aufgeben....meinst Du es würde eventuell sinn machen, die Frequenz in irgendwelche Richtungen zu verschieben? Hinten auf dem "echten" Empfänger steht allerdings 868,3
Naja, wenn wir es nicht hinbekommen, dann ist das halt so.
Ich hatte gerade nochmal die minicom laufen, mittlerweile ist da noch ein anderer Sender....sieht aber auch nicht nach sooo vielen Daten aus.
Willkommen zu minicom 2.6.1
Optionen: I18n
Übersetzt am Apr 28 2012, 19:24:31.
Port /dev/ttyUSB0
Drücken Sie CTRL-A Z für Hilfe zu speziellen Tasten
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
OK 9 8 1 4 88 106
OK 9 24 1 4 104 234
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 24 1 4 104 234
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 24 1 4 104 234
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 24 1 4 104 234
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 24 1 4 105 234
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 24 1 4 105 234
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 8 1 4 88 106
OK 9 24 1 4 105 234
An der Wetterstation habe ich mittlerweile auch mehrfach die Batterien entfernt und beim Pairing wieder eingelegt. Alles ohne Erfolg.
Vielleicht hast Du recht und das ist noch eine alte WH1080 mit der alten Verschlüsselung.
Trotzdem vielen Dank, das Ihr Euch die Zeit genommen habt. Jetzt weiß ich wenigstens wie ich dem Jeelink zugucken kann. Ist doch auch was ;-)
viele Grüße
Martin
Ah, interessant, Du hast die Batterien entfernt und eingelegt. Ich dachte, dass das aktuelle Modell Solarzellen hat.
Frage an fossy: hat Deine Station Solar?
Eventuell gibt es ja doch unterschiedliche Modelle die unterschiedlich senden.
Kann es sein, dass fossy eine WS1080 (S wie Solar) und Du eine WH1080 hast?
Der "OK 9 24 1 4 104 234" ist interessant. Da sitzt das weak Battery flag. Kannst mal dem Nachbar sagen, dass die Batterie leer wird ;D
Hilft uns aber leider auch nicht weiter.
Zitat von: HCS am 28 Oktober 2015, 20:10:18
Klappt leider nur fast.
Ich kann mit dem JL aus der Entwicklungsumgebung kommunizieren, aber flashen klappt nicht, da geht der reset irgendwie nicht durch.
Egal. Ich habe mal einen Versuch gemacht.
...
Hallo HCS,
ich habe diesen Sketch genommen und auf je einen JeeLink (RFM12 und RFM69) aufgespielt. Ich habe dann nach einer Weile Daten empfangen und habe von Hand eine WS1080 angelegt. Beim testen habe ich diese Einstellungen verspielt und jetzt bekomme ich es nicht mehr hin.
Wenn ich beim JeeLink: 1z v einschalte erhalte ich diese Daten.
#########
WS1080 [51 5 47 7 34 28 0 24 41 78 ] CRC:WRONG
2015.11.05 22:48:26 5: J1 dispatch 226
2015.11.05 22:48:26 3: J1: Unknown code 226, help me!
2015.11.05 22:48:26 5: J1 dispatch WS1080 [51 1F 48 6 33 F 0 6 21 E2 ] CRC:WRONG
2015.11.05 22:48:26 3: J1: Unknown code WS1080 [51 1F 48 6 33 F 0 6 21 E2 ] CRC:WRONG, help me!
2015.11.05 22:48:26 5: J1 dispatch 120
2015.11.05 22:48:26 3: J1: Unknown code 120, help me!
2015.11.05 22:48:26 5: J1 dispatch WS1080 [51 5 47 7 34 28 0 24 41 78 ] CRC:WRONG
2015.11.05 22:48:26 3: J1: Unknown code WS1080 [51 5 47 7 34 28 0 24 41 78 ] CRC:WRONG, help me!
2015.11.05 22:48:27 5: JeeLink/RAW: /WS1080
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 /[A5 70
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 /FA 0 0 0 0 0 8
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 /39 ] CRC:OK S:A
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A/ ID:57
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 /NewBatt:0 LowBa
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBa/tt:0 Error:0 T
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 T/emp:25.0
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.0/0 Hum:0 Rain:0
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0/.00 Wind
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0.00 Wind/:0.00m/s from:
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0.00 Wind:0.00m/s from:/180.00 Gust:0.0
2015.11.05 22:48:27 5: JeeLink/RAW: WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0.00 Wind:0.00m/s from:180.00 Gust:0.0/0 m/s CRC:39
2015.11.05 22:48:27 5: J1 dispatch WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0.00 Wind:0.00m/s from:180.00 Gust:0.00 m/s CRC:39
2015.11.05 22:48:27 3: J1: Unknown code WS1080 [A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0.00 Wind:0.00m/s from:180.00 Gust:0.00 m/s CRC:39, help me!
2015.11.05 22:48:27 5: JeeLink/RAW:
/
2015.11.05 22:48:30 1: Perfmon: possible freeze starting at 22:48:28, delay is 2.998
2015.11.05 22:48:31 5: JeeLink/RAW: /136
WS1080 [92 4 91 6A 3E 46 A1 B0 F 88 ] CRC:WRONG
135
WS1080 [99 45 50 42 6B EA 28 88 60 87 ] CRC:WRONG
2015.11.05 22:48:31 5: J1 dispatch 136
2015.11.05 22:48:31 3: J1: Unknown code 136, help me!
2015.11.05 22:48:31 5: J1 dispatch WS1080 [92 4 91 6A 3E 46 A1 B0 F 88 ] CRC:WRONG
2015.11.05 22:48:31 3: J1: Unknown code WS1080 [92 4 91 6A 3E 46 A1 B0 F 88 ] CRC:WRONG, help me!
2015.11.05 22:48:31 5: J1 dispatch 135
2015.11.05 22:48:31 3: J1: Unknown code 135, help me!
2015.11.05 22:48:31 5: J1 dispatch WS1080 [99 45 50 42 6B EA 28 88 60 87 ] CRC:WRONG
2015.11.05 22:48:31 3: J1: Unknown code WS1080 [99 45 50 42 6B EA 28 88 60 87 ] CRC:WRONG, help me!
2015.11.05 22:48:31 5: JeeLink/RAW: /130
2015.11.05 22:48:31 5: JeeLink/RAW: 130
WS1080 [A5 70 F7 0 0 0 0 0 C 3C ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:24.70 Hum:0 Rain:0.00 Wind:0.00m/s from:270.00 Gust:0.00 m/s CRC:3C
78
WS1080 [18 F6 AE DA 36 6C 0 C0 99 4E ]
2015.11.05 23:02:53 5: J1 dispatch 160
2015.11.05 23:02:54 3: J1: Unknown code 160, help me!
2015.11.05 23:02:54 5: J1 dispatch WS1080 [92 4 92 6A 13 89 3F F2 25 A0 ] CRC:WRONG
2015.11.05 23:02:54 3: J1: Unknown code WS1080 [92 4 92 6A 13 89 3F F2 25 A0 ] CRC:WRONG, help me!
2015.11.05 23:02:54 5: J1 dispatch WS1080 [A5 70 F7 0 0 0 0 0 C 3C ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:24.70 Hum:0 Rain:0.00 Wind:0.00m/s from:270.00 Gust:0.00 m/s CRC:3C
2015.11.05 23:02:54 3: J1: Unknown code WS1080 [A5 70 F7 0 0 0 0 0 C 3C ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:24.70 Hum:0 Rain:0.00 Wind:0.00m/s from:270.00 Gust:0.00 m/s CRC:3C, help me!
2015.11.05 23:02:54 5: J1 dispatch 78
2015.11.05 23:02:54 3: J1: Unknown code 78, help me!
2015.11.05 23:02:54 5: JeeLink/RAW: WS1080 [18 F6 AE DA 36 6C 0 C0 99 4E ] /CRC:WRONG
######
Es werden alle anderen Tempsensoren und EMT7110 angezeigt und aktuallisiert.
die Einstellung ist : 5t 3m v. Auch wenn ich nur r:17241 einstelle wird die WS1080 nicht erkannt. Auf dem Display der WS1080 werden die Daten angezeigt. Wo und was kann ich noch einstellen ? Vielen Dank.
Tschüß Jörg
PS: Die WS1080 ist eine WX-2008 (http://wiki.wetterstationen.info/index.php?title=WH1080_/_WS1080).
Moin,
... meine WS1080 hat kein Solarpanel. So wie ich das verstehe, hat die WH1080 das Solarpanel. Bei mir ist ein JeeLink Classic im Einsatz.
http://www.elv.de/funk-wetterstation-ws-1080-mit-touch-screen-und-pc-anschluss.html
Zitat von: pejonp am 05 November 2015, 23:08:13
[A5 70 FA 0 0 0 0 0 8 39 ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:25.00 Hum:0 Rain:0.00 Wind:0.00m/s from:180.00 Gust:0.0/0 m/s CRC:39
[A5 70 F7 0 0 0 0 0 C 3C ] CRC:OK S:A ID:57 NewBatt:0 LowBatt:0 Error:0 Temp:24.70 Hum:0 Rain:0.00 Wind:0.00m/s from:270.00 Gust:0.00 m/s CRC:3C
Das ist interessant.Die Pakete sind gem. CRC gültig, aber es wird 0% Humidity übertragen und der Sketch lässt die Daten nur dann durch, wenn die Humidity zwischen 1 und 99 liegt. 0% Humidity kann eigentlich nicht sein.
Fragen:
- hattest Du kurz vorher die Batterien raus?
- Steht die Außeneinheit im Zimmer und sind die 24,7 °C korrekt?
- Was zeigt die Basisstation für eine Luftfeuchtigkeit an?
- Kannst Du nochmal mit 1z loggen und die Windfahne alle 60 Sekunden um 90° drehen?
"1z" Logging für WS 1080 funktioniert übringens nur mit dem Sketch, den ich fossy zum Testen gemacht habe, der aktuell eingecheckte loggt bei 1z nur LaCrosse Temperatusensoren.
Wir müssen erst mal rausfinden, ob diese Pakete tatsächlich von der WS 1080 sind.
Als ich die WS1600 implementiert habe, habe ich einen Ventilator davor gestellt, um Wind zu haben. :)
Wenn Du mit einem Terminalprogramm loggen könntest, wäre mir lieber, das FHEM-Log ist grauenhaft zu lesen
Und:
5t 3m v: 5 Sekunden toggle finde ich zu kurz. Das Intervall sollte länger als das Intervall des Senders sein, in diesem Fall also z.B. 60
Für Tests mit der WS 1080 solltest du r:17241 ohne toggle setzen, dass keine Lücken entstehen.
Hallo,
ich nochmal :D
Also da muss ich nochmal korrigieren....ich habe die Akkus neu eingelegt,. Die Station hat eine Solarzelle oben drauf und dann 2 Mignonakkus als Pufferspeicher.
Ich habe gestern noch ein wenig erfolglos rumprobiert und nun setzt sich bei mir wirklich im Kopf fest das die Station eventuell wirklich noch kein FSK macht. Ist das denn richtig gedacht?
Müsste man nicht trotzdem was mit dem Terminalprogramm sehen, oder wird das dann gar nicht erst empfangen und daher sehe ich dort auch nichts? Ich versuche mal jemanden mit einer neueren Station aufzutreiben um mal testen zu können....
Zitat von: Tim_Buktu am 06 November 2015, 10:54:35... und nun setzt sich bei mir wirklich im Kopf fest das die Station eventuell wirklich noch kein FSK macht.
Das ist eine Möglichkeit. Aber nach dem Log von pejonp bin ich mir nicht so sicher, dass das die Wahrscheinlichste ist.
Du könntest mal den angehängten Sketch auf den JeeLink flashen und dann mit minicom nochmal loggen.
Achtung, dieser Sketch ist
ausschließlich für diesen Test und
nicht für den Normalbetrieb geeignet.
Zitat von: Tim_Buktu am 06 November 2015, 10:54:35
Müsste man nicht trotzdem was mit dem Terminalprogramm sehen, oder wird das dann gar nicht erst empfangen und daher sehe ich dort auch nichts?
Genau so ist es. Wenn sie OOK sendet, dann empfangen wir absolut nichts.
Hallo Hcs
Der Sensor ist leider etwas defekt. Es wird nicht immer die Luftfeuchtigkeit angezeigt bzw ermittelt. Aber so zum testen geht er. Dann werde ich mal sehen ob ich den luftfeuchtsensor ersetzt bekomme oder die Abfrage aus dem Sketch rausnehmen.
Pejonp
Zitat von: pejonp am 06 November 2015, 13:04:50
Der Sensor ist leider etwas defekt. Es wird nicht immer die Luftfeuchtigkeit angezeigt bzw ermittelt.
Du machst tatsächlich mit einer defekten WS 1080 rum und erzählst mir das erst jetzt >:(
Zitat von: HCS am 06 November 2015, 13:08:26
Du machst tatsächlich mit einer defekten WS 1080 rum und erzählst mir das erst jetzt >:(
Hallo Hcs
Hat mich ja keiner gefragt
Zitat von: pejonp am 06 November 2015, 13:34:35
Hallo Hcs
Hat mich ja keiner gefragt
Das ist die blödste Antwort, sie ich seit langem gelesen habe!
Soll ich in Zukunft jedes Problem, dass ich bei jemand versuche zu lösen, mit der Frage "Ist Deine Hardware defekt und Du hast es mir noch nicht verraten" beginnen?
Wissend, dass Deine Station keine korrekten Daten sendet, mich rätseln lassen, was diese seltsamen Rohdaten bedeuten könnten, ist mehr als uncool.
Hallo Hcs
Ich war leider noch nicht fertig ich werde dir dazu aber erst heute Abend antworten zur Zeit bricht hier immer die Verbindung ab. Und nur zur Information ich habe hier zur ws1080 nur ein frage gestellt und weis nicht warum du so angefressen bist.
Pejonp
Zitat von: pejonp am 06 November 2015, 13:50:49...und weis nicht warum du so angefressen bist.
Dann versuche ich es mal geduldig zu erklären:
Du stellst hier ein Log mit raw data ein. Zu welchem Zweck? Na dass ich es mir anschaue und übelege, was das Problem ist. Sonst hättest Du es weglassen können.
Was sehe ich im Log? CRC-gültige Pakete mit Humidity 0. Also fange ich an zu rätseln, was die WS damit sagen will und kämpfe die Rohdaten bitweise durch, studiere meine Decoder-Routine, ob die da was falsch macht usw.
Dann erstelle ich eine Test-Version für Tim_Buktu, um rauszubekommen, ob seine Station das auch so sendet.
Wenn ich gewusst hätte, dass deine Station Schrott ist und darum keine Humidity sendet, hätte ich mir das Ganze sparen können.
Und der Spruch, dass ich ja schließlich nicht danach gefragt hätte, ist schlicht der Gipfel.
Es macht echt keinen Spaß, seine Zeit so zu vertun.
Damit möchte ich das Thema abschließen, mehr gibt es dazu nicht zu sagen oder zu diskutieren.
Ich schließe mich der Meinung von HCS
Zitat...und weis nicht warum du so angefressen bist.
voll umfänglich an.
Er hat das Thema "Jeelik Modul zur Einbindung von La Crosse!" mit viel Engagement voran gebracht.
Ohne Ihn wären wir nicht da wo wir heute sind.
Billy
Hallo HCS,
jetzt muss ich auch mal Partei für Dich ergreifen. Ich finde es wirklich nicht okay, wenn man nicht alle vorhandenen Daten mitgibt wenn es um eine Problemlösung geht.
Ich selbst muss mich teilweise beruflich, teilweise privat mit IT Problemen auseinandersetzen....und nichts bringt einem da mehr aus der Fassung als "ich habe nichts gemacht", "das war schon immer so" oder wie in diesem Fall "Du hast nicht danach gefragt".
Sorry Pejonp, aber HCS steckt hier Zeit und Hirnschmalz rein und das kostenlos, weil er der Community helfen möchte. Er könnte auch genauso gut vor dem TV sitzen und sagen...egal, bei mir läuft alles.
Brauchst Du das Log von der extra gebauten Firmware noch? Ich hänge es mal an, aber wenn nicht dann einfach ignorieren.
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
WS1080 [92 5 45 6A 3F F7 FF FF FF FF ] CRC:WRONG
WS1080 [16 13 81 6E 20 FF FF FF FF BF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF BF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FC ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF F7 ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FB FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F DF FE FF FF FF ] CRC:WRONG
WS1080 [92 19 9B 32 26 4C C8 1B CF 99 ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF F7 FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF EF F7 EF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF DF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FB FF FF FD ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF BF FF 7F ] CRC:WRONG
WS1080 [92 5 45 6A 3F 7F FF FF F7 FB ] CRC:WRONG
WS1080 [92 5 45 6A 3F F7 FB EF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF 7F BF DF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FB FF FF F7 FD ] CRC:WRONG
WS1080 [92 5 45 6A 3F CF FF FF 9F FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F F7 EF FD FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 1 45 6A 3F F7 FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF B7 ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF 7F FF ] CRC:WRONG
WS1080 [92 5 45 6A 1F FF FE FF FF FD ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF EF EF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FD FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FB FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FB ] CRC:WRONG
WS1080 [92 5 45 6A 39 33 66 4C C8 D8 ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF DF FF EF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FB F7 FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F EF FB F7 FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F DF FE FF FF 7F ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FB ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF EF FF ] CRC:WRONG
WS1080 [D2 5 47 7A 3F FF FF FF EF FF ] CRC:WRONG
viel Grüße
Tim
P.S. eben kam noch viel andere Meldungen....
WS1080 [92 1 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FB FF FF ] CRC:WRONG
WS1080 [92 45 5D 6A 3D FF FF FF BF FF ] CRC:WRONG
WS1080 [92 5 67 6A 2F FF FF FF FF FF ] CRC:WRONG
WS1080 [96 7 85 6A 7F FF 7F 97 FE FF ] CRC:WRONG
WS1080 [92 25 C5 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [A6 7A EA 7D ED FF 7F FF FF FF ] CRC:WRONG
WS1080 [B2 25 15 7A 3F FF FF F7 FF FF ] CRC:WRONG
WS1080 [92 5 45 6A 3F FF FF FF FF FF ] CRC:WRONG
WS1080 [9A 5 45 6C 3F FF FF FF BF EF ] CRC:WRONG
WS1080 [D2 5 43 6B 9F F9 FF FF FE FF ] CRC:WRONG
WS1080 [12 45 65 6A 3F FE 7F FF FF FF ] CRC:WRONG
WS1080 [93 7 41 7A 3F FB EF FF BE EB ] CRC:WRONG
WS1080 [98 63 94 EF FF FD FF FF FF FF ] CRC:WRONG
WS1080 [82 25 45 6A 1B F5 FF FF FB FF ] CRC:WRONG
WS1080 [B2 5 45 EE 3F FB FF FF FF FF ] CRC:WRONG
WS1080 [96 5 4D 62 3F FF FF FB FF DF ] CRC:WRONG
WS1080 [92 5 5 6A 3E FF FF FF FF FF ] CRC:WRONG
WS1080 [92 5 45 2A 3D CF FF FF FF FF ] CRC:WRONG
Zitat von: Tim_Buktu am 06 November 2015, 19:11:26
Brauchst Du das Log von der extra gebauten Firmware noch? Ich hänge es mal an, aber wenn nicht dann einfach ignorieren.
Es zeigt zumindest eins: da ist nichts drin, was nach WS 1080 aussieht.
Das ist der LaCrosse Sensor, den wir kürzlich schon gesehen haben und dazwischen HF-Müll, der keinen Sinn ergibt.
Damit würde die OOK Theorie dann doch die am meisten plausible sein.
Um es sicher zu sagen, müsste man jetzt mit RTL-SDR ö.Ä. schauen, was da gesendet wird.
Um mal die Fakten zusammenzufassen:
- Der JeeLink empfängt und decodiert den Temperatursensor vom Nachbarn -> also funktioniert er.
- Der Sketch liefert für diesen Sensor korrekte Daten für FHEM -> er läuft
- Die WS 1080 wird bei fossy und pejonp empfangen -> bedeutet, der Sketch versteht sie generell.
- Deine Basisstation zeigt die Daten -> also sendet die Außeneinheit
Bleiben folgende Möglichkeiten (sortiert nach Wahrscheinlichkeit):
1. Deine WS sendet OOK
2. das tatsächliche Problem, das noch unentdeckt ist :)
3. Sie sendet mit einer anderen data rate
um 3. noch anzuschließen: kannst mal mit 1r oder 2r versuchen, aber meine Hoffnung, dass es das ist, ist extrem gering.
Hallo HCS,
sehe ich eigentlich genauso. Das ist zwar wirklich ärgerlich, da ich die ja faktisch 2 Jahre nach der Umstellung gekauft habe, aber da kann man nicht viel machen.
Ich denke ich schaue mal ob ich irgendwo probeweise eine her bekomme bzw. muss mal sehen ob ich die alte nicht bei eBay verkaufen kann. Ist ja nicht kaputt oder so, sondern nur einfach für meine Zweck nicht geeignet. Ich hatte auch schon mal das mit fosr und Kabel ausprobiert, aber da hängt sich das System nach circa ner Woche weg.
Ich danke Dir jedenfalls für Deine Mühe und Hilfe bei der Analyse und vor allem das Du den Sketch entsprechend erweitert hast.
Falls ich an dieser Stelle mal weiter gekommen bin, melde ich mich nochmal.
viele Grüße
Tim
Das LaCrosseGateway wurde erfunden.
In Stichpunkten:
- Läuft auf ESP8266 ohne Arduino
- Per wifi anbindbar
- Per USB anbindbar
- Deckt alle Sensoren (und künftig vermutlich mehr) ab, die auch dieser LaCrosse Sketch kann
Details und die Diskusion dazu hier:
http://forum.fhem.de/index.php/topic,43672.msg355938.html#msg355938
Das ist eine parallel-Schiene zum LaCrosse-Arduino-Sketch.
Zitat von: Tim_Buktu am 06 November 2015, 23:35:42
...
sehe ich eigentlich genauso. Das ist zwar wirklich ärgerlich, da ich die ja faktisch 2 Jahre nach der Umstellung gekauft habe, aber da kann man nicht viel machen...
Hallo Tim_Buktu,
wenn du einen JeeLink mit RFM69CW hast kannst du ja mal diesen Sketch ausprobieren, dieser empfängt auf 868MHz OOK z.B. FS20 (getestet) und soll auch WH1080 OOK empfangen (nicht getestet). rfm69-ook-receive-rssi (https://github.com/SevenW/embapps/tree/master/ArduinoRFM69)
pejonp
Hallo pejonp,
danke für den Tip. Ich habe aber eine "classic" mit RFM12. Ich gucke mir das aber gerne mal genauer an.
Bin allerdings mittlerweile eher auf dem Trichter die Wetterstation zu tauschen.....aber man weiß ja nie was noch alles passiert.
danke und viele Grüße
Tim
Hallo HCS,
ich habe die Platine für den nano CUL gemacht (siehe Bastelbude). In der v3.1 ist auch ein Jeelink clone drauf. Ich habe dasselbe EEPROM verwendet, was auch JeeLabs verwendet, allerdings ist das arg schwer zu bekommen.
Verwendest Du das in Deinem Sketch überhaupt? Wenn nein, würde es stören, wenn es nicht bestückt ist?
Danke + Gruß
PeMue
Zitat von: PeMue am 08 November 2015, 17:18:45
Verwendest Du das in Deinem Sketch überhaupt? Wenn nein, würde es stören, wenn es nicht bestückt ist?
Für diesen Sketch hier wird kein EEPROM benötigt. Das kannst Du weglassen. Es gibt aber noch den PCA301 und den EC3000 Sketch, evtl. solltest Du dort auch mal nachfragen.
der pca301 sketch verwendet das eeprom um unter anderem die configuration und die angelernten dosen dort abzulegen.
ec3000 muss ich erst nachschauen.
gruss
andre
Hallo Tim_Buktu, entschuldigt bitte, wenn ich mich so unvermittelt mit hier reinhänge. Ich habe auch eine WS1080. Die Basis ist unbrauchbar. Daher möchte ich direkt die Funksignale der funktionierenden Außenstation nutzen.
Mein Jeelink ist der v3c, geflasht mit 10.1q und die Station wird auch nicht erkannt.
Wie kann ich denn den genannten sketch genau einbringen?
Hi Marcus, ;)
der 10.1q sollte die WS1080 schon unterstützen. Hast Du auch die richtigen Einstellungen (ab hier (http://forum.fhem.de/index.php/topic,14786.msg355104.html#msg355104) finden sich ein paar Angaben)?
MfG
Marco
Zitat von: FHEM_Pinguin am 14 November 2015, 13:12:00Ich habe auch eine WS1080.
Wie alt ist die denn ungefähr?
Bevor wir weiter forschen - bist Du in der Lage, einen Arduino Sketch zu kompilieren und auf den JL zu flashen?
Dann könnten wir mal das OOK-Thema untersuchen.
Zitat von: HCS am 14 November 2015, 14:30:23
Wie alt ist die denn ungefähr?
Bevor wir weiter forschen - bist Du in der Lage, einen Arduino Sketch zu kompilieren und auf den JL zu flashen?
Dann könnten wir mal das OOK-Thema untersuchen.
Hallo,
die Station ist von 2013 (sie ist mit PASS A14C im Batt.-Fach gekennzeichnet).
Beim kompilieren muss ich passen. Ich habe das noch nicht gemacht - das würde mich schon interessieren.
Gibt es irgendwo eine verständliche Anleitung? Ist das auch auf dem RaspberryPi möglich?
Zitat von: marco-f am 14 November 2015, 14:25:33
Hi Marcus, ;)
der 10.1q sollte die WS1080 schon unterstützen. Hast Du auch die richtigen Einstellungen (ab hier (http://forum.fhem.de/index.php/topic,14786.msg355104.html#msg355104) finden sich ein paar Angaben)?
MfG
Marco
Hallo Marco,
das habe ich leider nicht ganz korrekt so gemacht. Es gibt eine Abweichung:
-> attr myJeeLink initCommands 30t 0a v
auf der Seite, auf die Du verweist:
-> attr myJeeLink initCommands 0r 0a v
D. h., der "Toggle-Modus" ist aktiviert. Den werde ich erst mal auf 0 setzen.
Gruß
Marcus
Zitat von: FHEM_Pinguin am 14 November 2015, 17:00:56
...
die Station ist von 2013 (sie ist mit PASS A14C im Batt.-Fach gekennzeichnet).
...
Hallo FHEM_Pinguin,
schau mal bitte bei hier http://forum.fhem.de/index.php/topic,38831.msg358572.html#msg358572. Ich habe nur einen TFA 30.3189 Sender der mit OOK auf 868Mhz sendet. Im Batteriefach ist auch der Aufkleber 14c.
Tschüß pejonp
Hallo zusammen,,
mein Jeelink macht leider auch Probleme.
Nachdem sich der Status von Initialized auf Opened verändert hat, habe ich alle Verbindungen verloren.
Hatte den Stick neu aufgesetzt und es kommen leider immer wieder die selben Fehlercodes.....
Jemand eine Idee ?
Habe das FHEM auf Ubuntu(Mac mini laufen.
Evtl liegt es dort an den USB Verbindungen ? Kann das sein ?
2015.11.15 11:51:53 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP3_0)
2015.11.15 11:51:53 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1
2015.11.15 11:51:53 1: /dev/ttyUSB0 reappeared (TCM_ESP3_0)
2015.11.15 11:52:00 3: myJeeLink: Unknown code 14 1 4, help me!
2015.11.15 11:52:01 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)
2015.11.15 11:52:01 3: Setting myJeeLink serial parameters to 38400,8,N,1
2015.11.15 11:52:01 1: /dev/ttyUSB0 reappeared (myJeeLink)
2015.11.15 11:52:05 1: /dev/ttyUSB0 disconnected, waiting to reappear (TCM_ESP3_0)
2015.11.15 11:52:05 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1
2015.11.15 11:52:05 1: /dev/ttyUSB0 reappeared (TCM_ESP3_0)
2015.11.15 11:52:08 3: myJeeLink: Unknown code �A,M.M(�!b��A,!�V�, help me!
2015.11.15 11:52:12 3: myJeeLink: Unknown code K 9 141 55, help me!
2015.11.15 11:52:16 3: myJeeLink: Unknown code 9 141 55, help me!
2015.11.15 11:52:17 3: myJeeLink: Unknown code 0 1 4 06, help me!
2015.11.15 11:52:20 3: myJeeLink: Unknown code 14 1 5, help me!
2015.11.15 11:52:21 3: myJeeLink: Unknown code 0 130 125, help me!
2015.11.15 11:52:24 3: myJeeLink: Unknown code 4 1 4 , help me!
2015.11.15 11:52:29 3: myJeeLink: Unknown code 9 14 155, help me!
2015.11.15 11:52:33 3: myJeeLink: Unknown code 9 14 55, help me!
2015.11.15 11:52:34 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)
2015.11.15 11:52:34 3: Setting myJeeLink serial parameters to 38400,8,N,1
2015.11.15 11:52:34 1: /dev/ttyUSB0 reappeared (myJeeLink)
Hast Du mehrere Devices auf /dev/ttyUSB0 konfiguriert?
TCM_ESP3_0 und myJeeLink
Und JeeLink muss auf 57600 Baud initialisiert werden.
Zitat von: HCS am 30 Oktober 2015, 22:32:03
Prima. Musst die 868305f aber trotzdem dann in die initCommands reinschrieben, sonst ist es nach einem Neustart weg.
Der Fall ist aber interessant. Drei 30.3155.WD, zwei davon gehen mit 868300 und einer nur mit 868305
Das kann doch nur eins bedeuten: einzelne 30.3155.WD liegen mit der Frequenz daneben, was wohl eine "30.3155.WD Spezialität" ist, bei allen anderen Sensor-Typen, die empfangbar sind, wurde das bisher noch nie beobachtet.
@Billy: Könntest Du im wiki im Abschnitt Frequenzanpassung speziell auf die 30.3155.WD hinweisen, dass es bei denen häufig erforderlich ist und wie man sich in 5kHz Schritten rantastet?
Nachdem ich das ganze jetzt ein paar WOchen sauber laufen habe möchte ich gerne noch 3 T/H-Sensoren dazukaufen. Wie sagt hier der Rat der Ältesten: noch 3 weitere 30.3155.WD und hoffen, dass sie auch mit 868305 laufen oder lieber alle 15sek toggeln und auf die älteren TX 29 DT-HT? läuft eine Mischung aus 17,2 und 9,5kb/s gut, wenn man die Frequenz um 5KHz verschoben hat?
Zitat von: SonOfAbaddon am 15 November 2015, 19:33:25
Nachdem ich das ganze jetzt ein paar WOchen sauber laufen habe möchte ich gerne noch 3 T/H-Sensoren dazukaufen. Wie sagt hier der Rat der Ältesten: noch 3 weitere 30.3155.WD und hoffen, dass sie auch mit 868305 laufen oder lieber alle 15sek toggeln und auf die älteren TX 29 DT-HT? läuft eine Mischung aus 17,2 und 9,5kb/s gut, wenn man die Frequenz um 5KHz verschoben hat?
Ich habe 60% 17,2 und 40% 9,5 Sensoren. Problemlos. Die TX29DTH werden trotz 5KHz verschobener Frequenz problemlos empfangen.
Was auch geht ist ein SuperJee mit zwei RFM, dann kann man beide DataRates gleichzeitig empfangen und muss nur bei einem die Frequenz anpassen.
Falls man nun vom JeeLink auf einen ja dann zu bauenden SuperJee umsteigt, kann man auch darüber nachdenken: http://forum.fhem.de/index.php/topic,43672.0.html
Ich tue mir schwer mit einer Empfehlung, aber ich persönlich würde mir keine weiteren 30.3155.WD kaufen, die sind mir inzwischen sehr suspekt.
@HCS
Hast du das schon gesehen?
http://forum.fhem.de/index.php/topic,44092.0.html
Vielleicht kannst du helfen!
Billy
Danke euch!!
Fall gelöst.......mehrere Devices auf /dev/ttyUSB0 konfiguriert?
TCM_ESP3_0 und myJeeLink
Das wars.
:) :)
@ HCS
Ich muss jetzt auch nochmal zu der WS(H)1080 eine Frage stellen.
Welche initCommands müssen nun gesetzt sein, um die Daten der Wetterstation in Fhem zu empfangen (Jeelink 10.1q / RM12B)?
Habe den halben Morgen mit den verschiedenen Parametern getestet, empfange den Mast aber nicht.
Vorgehensweise war:
- Fhem Update
- Neuste Version flashen
- Akkus in Station
- Jeelink in´s paaring versetzt
Bisher habe ich nur folgende RAWMSG empfangen:
OK WS 0 2 4 209 255 255 255 255 255 255 255 255 255 0 3 247
Danke für die Hilfe!
Zitat von: oli82 am 19 November 2015, 11:17:05Ich muss jetzt auch nochmal zu der WS(H)1080 eine Frage stellen.
Welche initCommands müssen nun gesetzt sein, um die Daten der Wetterstation in Fhem zu empfangen (Jeelink 10.1q / RM12B)?
Eigentlich keine, da sie mit 17241 kbps sendet, was der default im Sketch ist.
Oder wenn, dann "0t 0r v"
Aber: vielleicht ist Deine ja auch eine, die OOK sendet?
Zitat von: oli82 am 19 November 2015, 11:17:05
Bisher habe ich nur folgende RAWMSG empfangen:
OK WS 0 2 4 209 255 255 255 255 255 255 255 255 255 0 3 247
Das ist der BMP180 auf Deinem SuperJee
23,2 °C und 1015 hPa
Zitat von: FHEM_Pinguin am 14 November 2015, 17:00:56die Station ist von 2013 (sie ist mit PASS A14C im Batt.-Fach gekennzeichnet).
Könnte auch OOK sein.
@All: Könnte mal jemand, der eine WS 1080 erfolgreich empfängt, versuchen zu ermitteln, woran man die FSK-Version möglicherweise erkennen kann?
Irgendwie beschleicht mich das Gefühl, dass da überwiegend OOK-Versionen im Umlauf sind.
Oder es gibt sonst noch ein Geheimniss, das wir nicht entdecken.
Oder jemand, der ein wenig Arduino drauf hat, müsste mal den OOK-Sketch, der weiter oben genannt wurde, ausprobieren.
Wenn der etwas empfängt, hätten wir zumindest eine Testmethode, um die OOK-Stationen zu identifizieren.
Wenn mir jemand eine WS 1080 zu Weihnachten schenkt, könnte ich auch was ausprobieren, ohne Station ist das alles Theorie ;D
Zitat von: HCS am 19 November 2015, 11:55:33
...
@All: Könnte mal jemand, der eine WS 1080 erfolgreich empfängt, versuchen zu ermitteln, woran man die FSK-Version möglicherweise erkennen kann?
...
würde gerne helfen. Bei mir funktioniert ja alles wunderbar...
aber ich weiß nicht wie
@ HCS:
Danke für die info.
Habe mir nur den Mast gekauft, kann das aber mal checken, wenn ich wieder zuhause bin (solange das dort irgendwo steht).
Zitat von: fossy am 19 November 2015, 12:03:14würde gerne helfen. Bei mir funktioniert ja alles wunderbar...
Eben, generell geht es ja.
Zitat von: fossy am 19 November 2015, 12:03:14aber ich weiß nicht wie
- Inneneinheit öffnen und die Platine fotografieren, und mit jemand, bei dem es nicht geht, vergleichen.
- Auf der Platine versuchen, das radio zu identifizieren, wenn man den Typ weiß, kann man ermitteln, was der senden kann und was nicht (z.B. nur OOK)
Aber wichtiger wäre, dass jemand, der eine hat, mit der es nicht geht, versucht zu ermitteln, wie die sendet. RTL-SDR wäre neben dem Sketch weiter oben auch noch eine Möglichkeit.
Zitat von: oli82 am 19 November 2015, 12:03:52Habe mir nur den Mast gekauft ...
Erst kürzlich? Weil dann wäre die OOK-Theorie nicht so wahrscheinlich, oder es gibt Hersteller, die schlicht nie auf FSK umgestellt haben.
Ich habe übrigens in dem Beitrag weiter oben eine Warnung nachgetragen, dass es WS 1080 gibt, die scheibar nicht geeignet sind.
Und hier dann auch mal noch:
Hinweis: wer auch immer mit dem Gedanke spielt, sich für FHEM eine WS 1080 zuzulegen, sollte auf alle Fälle abwarten, was sich hier noch ergibt.Nicht dass wir einen WS 1080 Skandal bekommen, weil sie auf dem Prüfstand nur OOK sendet ;D ;D ;D
Montag bestellt ;)
Leider habe ich keinen Receiver, der auch OOK kann und mit dem Signalduino läuft.
Zitat von: oli82 am 19 November 2015, 12:31:28Leider habe ich keinen Receiver, der auch OOK kann und mit dem Signalduino läuft.
Wenn Du einen RFM69 hast, dann könntest Du das probieren: http://forum.fhem.de/index.php/topic,14786.msg356161.html#msg356161
Zitat von: HCS am 19 November 2015, 12:50:17
Wenn Du einen RFM69 hast, dann könntest Du das probieren
Ja dann schmeiß ich doch mal den Lötkolben an ;)
Melde mich, wenn ich zuhause bin und testen konnte
Ihr könntet auch mal noch die "Pass 14c" Geschichte im Batteriedeckel vergleichen. Das soll angeblich das Protokoll sein, das verwendet wird.
Zitat von: oli82 am 19 November 2015, 12:31:28
Montag bestellt ;)
Leider habe ich keinen Receiver, der auch OOK kann und mit dem Signalduino läuft.
Hallo oli82,
Schau mal hier http://forum.fhem.de/index.php/topic,38831.msg358572.html#msg358572
Oder hier
http://forum.fhem.de/index.php/topic,39451.msg358606.html#msg358606.
In einem anderen Thread steht auch noch etwas zum Anschluss des rx868...
Such bitte einmal nach dem Empfänger RX868
http://forum.fhem.de/index.php/topic,44010.msg361061.html#msg361061
Tschüss jörg
Danke pejonp
Leider bringen mir die Links nichts, da ich ja schauen muss, welchen Receiver ich habe und nutzen kann. Hab jetzt den RFM69 aufgebaut
Zitat von: oli82 am 19 November 2015, 15:29:56
Danke pejonp
Leider bringen mir die Links nichts, da ich ja schauen muss, welchen Receiver ich habe und nutzen kann. Hab jetzt den RFM69 aufgebaut
Hallo
Du könntest ja deine Daten (Hexstring) gegen das Modul laufen lassen um diese auszuwerten. Jeelink lacross braucht ja ein anderes Format.
Jörg
Zitat von: oli82 am 19 November 2015, 15:29:56
Danke pejonp
Leider bringen mir die Links nichts, da ich ja schauen muss, welchen Receiver ich habe und nutzen kann. Hab jetzt den RFM69 aufgebaut
Hallo
Du könntest ja deine Daten (Hexstring) gegen das Modul laufen lassen um diese auszuwerten. Jeelink lacross braucht ja ein anderes Format.
Jörg
Also ich habe nun mal mit dem rfm69-ook-receive-rssi Sketch, einem Nano und einem RFM69H den Test aufgebaut.
Leider empfange ich keine Nachrichten der Wetterstation. Auf meinem Aufkleber im Batteriefach steht Pass A14C und das Produktionsdatum ist 7/2015.
Ich kann gerne die Station zum Testen bereitstellen, möchte sie aber innerhalb 14 Tagen wieder an den Händler zurücksenden.
Gruß
Oli
Hi fossy, was steht auf Deinem Aufkleber?
Zitat von: oli82 am 19 November 2015, 20:45:45
Ich kann gerne die Station zum Testen bereitstellen, möchte sie aber innerhalb 14 Tagen wieder an den Händler zurücksenden.
Nee, lass mal.
Zitat von: oli82 am 19 November 2015, 20:45:45
Also ich habe nun mal mit dem rfm69-ook-receive-rssi Sketch, einem Nano und einem RFM69H den Test aufgebaut.
Leider empfange ich keine Nachrichten der Wetterstation.
Du schaust aber mit einem Terminalprogramm, was der Sketch liefert und nicht mit FHEM?
HCS...
Schau über´s Terminal und logge seit ner halben Stunde. Abstand vielleicht 50cm
Du könntest mal den Sketch aus diesem Beitrag
http://forum.fhem.de/index.php/topic,14786.msg355471.html#msg355471
auf einen JeeLink flashen und mit dem Terminalprogramm eine Zeit lang loggen und das Log hier reinhängen.
Möchte mal sehen, ob wir absolut nichts oder nur unverständliche Dinge empfangen.
Klar, mache ich!
Wird aber heute Abend, da ich den "Test-Jeelink" aktuell nicht gesteckt habe.
@HCS
Log hängt dem Post an.
Zitat von: oli82 am 20 November 2015, 20:46:38
Log hängt dem Post an.
Ups, da läuft was schief, das Log ist ja teils ganz verstümmelt.
Schwer zu beurteilen, ob da was drin ist, das nach WS 1080 aussieht, aber ich glaube eher nicht.
Wenn Du einen 868 MHz OOK Empfänger hättest, dann könntest Du noch mit SignalDuino probieren, der soll ja scheinbar die WS 1080 OOK Version können.
Würde ich gerne, habe aber keinen zur Hand und so wie ich das gelesen habe, ist das C1101 nicht kompatibel.
Kannst ja mal schauen, warum Dein Log so geschreddert ist. Läuft da was auf der Seriellen nicht richtig?
Falls Du ein nicht geschreddertes Log hinbekommst, schaue ich gerne nochmal drauf.
Hier nochmal ein nicht geschreddertes Log, aber wie es scheint ohne die WS Einträge...
Zitat von: oli82 am 20 November 2015, 23:01:11
Hier nochmal ein nicht geschreddertes Log, aber wie es scheint ohne die WS Einträge...
Ja, das sieht nach LaCrosse Temp/Humi Sensoren aus (hast Du sowas laufen?), aber nichts, was eine WS 1080 sein könnte.
Deine sendet definitiv was anderes als die von fossy. Steht da irgend wo drauf, dass sie 868 MHz hat?
Ja, habe einige LaCrosse Sensoren.
Die WS ist laut Datenblatt 868MHz.
Muss mal schauen, dass ich einen OOK fähigen Sketch für die Hopfe Module oder einen Reveiver mit TTL für signalduino finde.
Hallo,
nachdem ich nun seit einigen Tagen versuche meine Außensensoren einzubinden, bin ich an dem Punkt angekommen, dass ich selbst nicht mehr weiter komme.
Ich bin noch Anfänger und habe mich über Beschreibungen und Tutorials durchgehangelt um die Hardware und software einzurichten.
Hardware:
- 2 funktionierende Wetterstationen ( TFA, ist schon einige Jahre alt, und eine neuere von Tchibo)
- Arduino Nano und RFM12B (868MHz)
Am PC im Arduino Seriellen Monitor empfange ich folgendes:
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
OK 9 8 1 4 36 234
OK 9 8 1 4 36 234
OK 9 8 1 4 36 234
OK 9 8 1 4 36 234
OK 9 8 1 4 36 234
OK 9 42 1 4 32 80
OK 9 8 1 4 36 234
...
In FHEM (etwas andere Position) konnte ich den einen Sensor (mit low Battery) einbinden, den anderen finde ich nicht.
Dieser eine funktioniert auch und sendet alle 4 sek ! Daten.
Es ist allerdings nicht mein Sensor sondern wohl vom Nachbar, da die Temperaturwerte sich etwas von der Anzeige im Display unterscheiden.
Meine Frage an die Experten:
Was kann ich tun um meine Sensoren einzulesen und ist das überhaupt möglich?
Meine Vermutungen:
Irgendwo habe ich gelesen, dass die alten Geräte noch OOK kodiert senden und es deshalb nicht funktionieren.
Wenn dem so ist, dann habe ich keine Chance den Sonsor mit meiner Hardware in FHEM einzubinden?
Die zweite Station sendet möglicherweise auf 434MHz, es gibt zwei sehr ähnliche Anleitungen.
Ich habe hier noch einen RFM12B mit 434MHz rumliegen, den könnte ich mal anschließen.
Was für ein Sketch muss ich aufspielen bzw. ändern, dass ich die Daten von 434Mhz einlesen kann?
Zitat von: Doublefant am 21 November 2015, 14:01:21
nachdem ich nun seit einigen Tagen versuche meine Außensensoren einzubinden, bin ich an dem Punkt angekommen, dass ich selbst nicht mehr weiter komme.
Welche Außensensoren hast du denn? Sind die in der WIKI Kompatibilitätsliste?
Wenn nicht gehört es eigentlich nicht zu dem Thema Einbindung von La Crosse!
Billy
Hi,
Zitat von: HCS am 19 November 2015, 12:12:03
Eben, generell geht es ja.
- Inneneinheit öffnen und die Platine fotografieren, und mit jemand, bei dem es nicht geht, vergleichen.
- Auf der Platine versuchen, das radio zu identifizieren, wenn man den Typ weiß, kann man ermitteln, was der senden kann und was nicht (z.B. nur OOK)
...
anbei Fotos von meinem zerlegte WS1080-Touchinterface-Display:
(https://goo.gl/photos/Mz4yVxDQieRvLPKT9L)
(https://goo.gl/photos/APpymjCv2LmWe8PY6)
(https://goo.gl/photos/qasdtLiQZEGzTdjR9)
(https://goo.gl/photos/GdikuQCYRypzCXuV6)
(https://goo.gl/photos/BpGQAnV24T1J2w3U7)
Falls das einbinden nicht Funktioniert, hier der Link zum Album:
https://goo.gl/photos/8Xy1r4zRvW2xQveA7 (https://goo.gl/photos/8Xy1r4zRvW2xQveA7)
Im Batteriedeckel war kein Code - nur der Prüfaufkleber.
cu
fossy
Zitat von: fossy am 21 November 2015, 16:35:08
anbei Fotos von meinem zerlegte WS1080-Touchinterface-Display
Super fossy, vielen Dank für die Mühe. Das bringt deutlich Licht ins Dunkel.
Bekommt man die ohne Schäden auf und wieder zu? Dann könnte mal jemand, bei dem es nicht geht, schauen was in seiner so drin ist.
Erkenntnisse aus den Bildern:
Dein Batteriefach hat den angesprochenen Aufkleber. Auf dem steht "PASS 7" und sie wurde 08/2011 oder 08/2012 hergestellt, schwer zu interpretieren.
PASS 7 ist das Protokoll.
In der Station ist ein RFM01 868 MHz verbaut. Der RFM01 ist ein FSK-Empfänger.
Das würde bedeuten, dass der Sketch die WS 1080 empfangen kann, bei denen PASS 7 im Batteriefach steht.
Es gibt einen Händler, der deutlich macht, dass nur Kombinationen von Sender und Station funktionieren, bei denen PASS xx übereinstimmt.
http://www.froggit.de/product_info.php/info/p218_ersatz-hydrosensor-pass7.html
Jetzt hilft eigentlich nur, dass jemand von einer Station, die nicht empfangen wird, auch diese Bilder liefert.
Entscheidend sind die Bilder mit dem grünen Aufkleber, die beige Ansicht der Platine mit den beiden aufgesetzten Modulen und die Module in Nahaufnahme.
@pejonp: Du hast doch auch eine WS 1080, die FSK sendet und vom LaCrosse Sketch empfangen wird?
Was steht denn bei Dir im Batteriefach.
Moin,
... aufschrauben geht definitiv ohne bleibende Schäden. Man sieht dann aber erstmal "nur" die weiße Seite der Platine (siehe Bilder). Das Funkmodul ist so aufgelötet, dass man die Seite, wo draufsteht RFM01 nicht sieht (Bild: Platine weiß; "rechts unten" - mit rotem Kabel). Ich hab also für die Fotos die Sensorplatine(n) ausgelötet. Will man die "grüne Seite" der Platine ansehen, muss man hierfür ein Kabel lösen und die Schrauben demontieren. Dann kann man sich auch diese Seite ohne bleibende Schäden ansehen. Ich weiß aber nicht, ob die Bezeichnung "WHP0026D1" bzgl. "Gleichheit" aussagekräftig ist...
cu
fossy
Die "grüne Seite" ist weniger spannend. Das radio ist das Entscheidende und der pass Aufkleber.
Mich beschleicht langsam der Verdacht, dass wir das Protokoll der älteren WS 1080 können und die neueren etwas senden, das wir nicht verstehen.
Kann euch leider keine Bilder liefern, da ich nur den Mast gekauft habe. Der Sender ist leider verklebt und geht ohne Beschädigung nicht auf. Sorry.
Eine kurze Frage:
Wenn ich mir diesen Ersatz-Mast (http://www.froggit.de/product_info.php/info/p145_ersatz-ausseneinheit-komplett-wh1080-solar.html (http://www.froggit.de/product_info.php/info/p145_ersatz-ausseneinheit-komplett-wh1080-solar.html)) mit allen Sensoren kaufen würde, könnte ich den in FHEM mit einem JeeLink empfangen?
... scheinbar nicht! denn dort steht "pass14c" und nicht "pass7"
ZitatNur für versionen Pass14c
Angaben hierzu finden Sie unter den Batterien Ihres Grundgerätes Grüner Aufkleber.
Wenn Sie eine andere Version haben bitte telefonisch anfragen!!!.
Ich tippe auch sehr stark auf Nein.
Achso, stimmt!
Sehr schade. Weil die Station brauch ich nicht. Aber die Sensoren wären interessant gewesen.
Frag doch dort mal, ob es den mit PASS 7 gibt und ob sie ihn zurücknehmen, wenn es nicht funktioniert.
Nachtrag: ich gebe aber keinerlei Prognosen mehr zu diesen ver... WS 1080 ab, ob das dann geht.
Habe gerade gesehen, das es den auch für PASS 18 gibt.
Wegen PASS 7 frage ich mal an.
Das Set von Froggit habe ich und es funktioniert nicht!
Zitat von: HCS am 22 November 2015, 09:00:36
...
In der Station ist ein RFM01 868 MHz verbaut. Der RFM01 ist ein FSK-Empfänger.
@pejonp: Du hast doch auch eine WS 1080, die FSK sendet und vom LaCrosse Sketch empfangen wird?
Was steht denn bei Dir im Batteriefach.
Hallo,
ich habe hier (http://forum.fhem.de/index.php/topic,39451.msg363597.html#msg363597) mal etwas zusammengeschrieben. Vielleicht hilft es ja weiter.
pejonp
Zitat von: pejonp am 23 November 2015, 00:28:54
ich habe hier (http://forum.fhem.de/index.php/topic,39451.msg363597.html#msg363597) mal etwas zusammengeschrieben. Vielleicht hilft es ja weiter.
Super, das hilft erheblich weiter.
Ich fasse mal zusammen:
Die WS 1080 gibt es (unter gleichem Namen) in einer OOK- und in einer FSK-Version
Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version
nicht.
Die FSK-Version erkennt man an:
- Runder grüner Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7"
- Das radio ist ein RFM01, erkennt man auch schon an der Form, es ist fast quadratisch.
Die OOK-Version erkennt man an:
- Runder grüner Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS A14C"
- Das radio ist ein ASK868MA1, erkennt man auch schon an der Form, es ist rechteckig und mit ASK868MA1 beschriftet.
Die OOK-Version kann mit SIGNALDuino und einem RX868SH-DV empfangen werden (habe ich nicht getestet, sondern so aus der Doku von pejonp übernommen)
pejonp und fossy haben ein "PASS 7" und können sie empfangen, oli82 und nochwer haben ein "PASS A14C" und empfangen sie nicht, was das oben geschriebene bestätigt.
Damit wäre der Fall dann hinreichend geklärt.
@Billy: würdest Du das ins wiki übernehmen um weitere Anwender davor zu bewahren, mit der OOK-Version zu scheitern?
Ich werde es dann noch in diesem Thread weiter oben und im LGW Thread so vermerken.
@HCS
So ich habe mal das WIKI angepasst!
Das
@Billy: Könntest Du im wiki im Abschnitt Frequenzanpassung speziell auf die 30.3155.WD hinweisen, dass es bei denen häufig erforderlich ist und wie man sich in 5kHz Schritten rantastet?
und Das
@Billy: würdest Du das ins wiki übernehmen um weitere Anwender davor zu bewahren, mit der OOK-Version zu scheitern?
Zitat von: Billy am 23 November 2015, 16:43:28
So ich habe mal das WIKI angepasst!
Super. Zwei Tippfehler sind noch drin:
- in der Liste steht unten "WS 1800"
- beim 30.3155.WD steht "empfgehlen"
Zitat von: HCS am 23 November 2015, 16:52:47
Super. Zwei Tippfehler sind noch drin:
Danke, geändert, wollte Dich nur mal testen. ;)
@HCS: Es gibt ja den Relay-Modus: Hast Du mal versucht, beim Relaymodus auch die Datenrate zu ändern?
Konret: Ich habe verschiedene Wetterstationen und ein externer Temperatursensor ist mit kaputt gegangen. Nun würde ich gerne alle Wetterstationen an den selben Aussensensor hängen, diese senden aber in anderen Datenraten.
Denkst Du, es wäre möglich, die Temperatur, die ich mit 17.241 kbps empfange, mit 9.579 kbps wieder zu senden?
Zitat von: JoeALLb am 06 Dezember 2015, 18:08:10
@HCS: Es gibt ja den Relay-Modus: Hast Du mal versucht, beim Relaymodus auch die Datenrate zu ändern?
Konret: Ich habe verschiedene Wetterstationen und ein externer Temperatursensor ist mit kaputt gegangen. Nun würde ich gerne alle Wetterstationen an den selben Aussensensor hängen, diese senden aber in anderen Datenraten.
Denkst Du, es wäre möglich, die Temperatur, die ich mit 17.241 kbps empfange, mit 9.579 kbps wieder zu senden?
Das Relay sendet etwas, das es empfangen hat, mit der DataRate weiter, mit der es empfangen hat.
Wenn Deine WS mit 17k und 9k sendet, kommt das bei FHEM mit 17k bzw. 9k relayed an.
Warum willst Du das im Relay umsetzen?
Kann aber auch sein, dass mir das Problem noch nicht ganz klar wurde.
Zitat von: HCS am 06 Dezember 2015, 18:57:44
Das Relay sendet etwas, das es empfangen hat, mit der DataRate weiter, mit der es empfangen hat.
Wenn Deine WS mit 17k und 9k sendet, kommt das bei FHEM mit 17k bzw. 9k relayed an.
Warum willst Du das im Relay umsetzen?
Kann aber auch sein, dass mir das Problem noch nicht ganz klar wurde.
Ich habe 2 Wetterstationen. eine mit 17k, eine mit 9k.
Der Temeratursensor der 17k ist seit gestern defekt. Ich wollte mir sparen, einen neuen zu kaufen, (auch aus Umweltschutzgründen) und einfach die Temperaturdaten des verbleibenden 9ks auf beide Wetterstationen senden!
Noch schöner wäre natürlich, beliebige Temperaturwerte einfach rauszuschicken, das haben wir schon mal auf den Seiten 32-33 versucht, ohne richtigen erfolg.
Ich dachte, dass es eventuell funktionieren könnte, wenn ich die Daten eines Sensors einfach 1:1 mit der anderen Datenrate wieder raus schicke...
Ahh, jetzt habe ich es verstanden. Da sehe ich reichlich schwarz.
Du kannst mal versuchen, in der LaCrosseItPlusReader10.inio die HandleReceivedData Methode so abzuändern:
if (RELAY && frameLength > 0) {
delay(64);
unsigned long currentDataRate = rfm->GetDataRate();
rfm->SetDataRate(9579);
rfm->SendArray(payload, frameLength);
rfm->SetDataRate(currentDataRate);
if (DEBUG) { Serial.println("Relayed"); }
}
Aber meine Hoffnung ist gering.
Das hat schon damals nicht funktiniert, eine WS-Basisistation dazu zu bringen, unsere Aussendungen zu akzeptieren.
Ich vermute auch mal, dass, wenn zwei Sender das liefern, zumindest von einem die Daten zu einem Zeitpunkt kommen, an dem die Station sie nicht erwartet. Und sie müsste ja dann auch noch mit zwei verschiedenen IDs gepaart sein.
Aber wie auch immer, der Code-Schnipsel oben würde jedes empfangene Paket mit 9570 relayen.
... selbes Ergebnis wie Damals: Der initiale Temperaturwert wird angezeigt *JIPIIE* , danach werden leider keine Änderungen mehr angezeigt. :-(
Zitat von: JoeALLb am 07 Dezember 2015, 20:35:55
... selbes Ergebnis wie Damals: Der initiale Temperaturwert wird angezeigt *JIPIIE* , danach werden leider keine Änderungen mehr angezeigt. :-(
Es war zu befürchten. :(
Zitat von: HCS am 07 Dezember 2015, 22:02:11
Es war zu befürchten. :(
Ich hab weiter getestet,... jetzt kann ich bis zu 4x (beliebig) die Temperatur ändern, danach erlischt jedoch das Empfangssymbol in der Wetterstation.
Hallo,
habe ein Problem mit meinem neuen Jeelink.
Habe im JeeLabs Shop einen Jeelink 433 MHz bestellt und laut Verpackung folgendes bekommen:
ZitatJeeLink v3c
RFM69cw433Mhz
. Nach dem installieren und einbinden in FHEM sowie flashen mit LaCrosse (Anleitung aus dem Wiki, allerdings konnte das log-file nicht geschrieben werden) erhalte ich aber diese Anzeige:
ZitatInternals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 33
NAME myJeeLink
NR 585
PARTIAL
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
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:
2015-12-20 17:44:26 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t
room Sonstiges
Die Angabe bei model bedeutet doch, dass es ein 868 MHz Modell ist oder täusche ich mich da?
Aufgefallen ist es dadurch, dass keiner meiner Temperatursensoren erkannt wird.
Gruß Jürgen
Hi Jürgen,
wie und mit welchen Attributen hast Du den Jeelink ins FHEM eingebunden? Aus der Wiki:
Frequenzanpassung über Attribut initCommands
Über das initCommands lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
attr <JeeLinkDevice> initCommands <hhhh>h
MfG
Marco
Zitat von: bmwfan am 20 Dezember 2015, 18:05:47model bedeutet doch, dass es ein 868 MHz Modell ist oder täusche ich mich da?
Der Sketch kann nicht erkennen, welches Radion (868/433) auf dem JeeLink drauf ist und initialisiert es immer auf 868300.
Für 433 MHz musst Du es in den InitCommands mit 433???f initialisieren. Und den 30t braucht man nur, wenn man Sensoren mit unterschiedliche data rates hat. Und noch ein v ans Ende, dass das neue Setting an FHEM zurückgemeldet wird.
Ohh, da war jemand schneller, egal, doppelt hält besser
Hallo,
Danke für die schnelle Antwort.
Das attr initCommands hatte ich gelesen, aber da es unter PCA301 Sketch steht als nicht für den LaCrosse Sketch anwendbar interpretiert.
Welche Frequenz stelle ich denn da am besten ein? Ich würde den Mittelwert das Max- und Min-Frequenzbereiches einstellen, kenne aber beide nicht. Welche Frequenz hat sich denn bewährt?
Gruß Jürgen
Zitat von: bmwfan am 20 Dezember 2015, 18:55:05
Welche Frequenz stelle ich denn da am besten ein? Ich würde den Mittelwert das Max- und Min-Frequenzbereiches einstellen, kenne aber beide nicht. Welche Frequenz hat sich denn bewährt?
Vielleicht solltest Du uns erst mal verraten, welche Sensoren Du denn empfangen willst.
Sorry,
habe momentan zwei GT-WT-02 von Globaltronics, die an meine Wetterstation melden und die ich gerne in FHEM hätte. Hatte gelesen, dass die mit 433 MHz senden und schon in FHEM eingebunden wären.
Gruß Jürgen
Ich glaube, dass ich schlechte Nachrichten habe. Wenn ich mich nicht täusche, ist der mit einem CUL (ohne Garantie) und nicht mit einem JeeLink angebunden. Aber dazu musst Du mal etwas im Forum suchen. Ich glaube, der sendet OOK und dann ist mit diesem Sketch hier definitv nichts zu wollen.
Zitat von: HCS am 11 Oktober 2015, 09:02:29
Ich habe ein neues Attribut "timeout" erfunden, das so angegeben wird: <timeout, checkInterval>
[...]
Bedeutet: es wird alle 30 Sekunden geprüft, ob der letzte Datenempfang (myJeeLink_TIME) länger als 120 Sekunden zurück liegt.
Falls das so ist, wird ein reset auf dem Port gemacht (zu->auf also wie ein set myJeeLink reset) und zwar alle 30 Sekunden, bis wieder Daten reinkommen.
Hi,
nachdem mein JeeLink bestehend aus einem Arduino mit CH340 Chip und RFM69 monatelang problemlos durchlief musste ich auf einen Arduino mit FTDI Chip wechseln. Seitdem hängt sich der Funkteil des JeeLink immer mal wieder auf und ich empfange keinerlei Signale meiner TFA 30.3144.IT mehr. Dadurch dass die Pakete vom BMP180 nach wie vor einlaufen bringt das timeout Attribut leider nichts. Gibt es irgendwelche Möglichkeiten der Fehlersuche? JeeLink ist aktuell auf der 10.1q.
MfG
Marco
Zitat von: marco-f am 22 Dezember 2015, 12:56:14Gibt es irgendwelche Möglichkeiten der Fehlersuche? JeeLink ist aktuell auf der 10.1q.
Das kann nur Hardware sein. Wie sieht denn die Schaltung aus?
Zitat von: HCS am 22 Dezember 2015, 13:57:26
Das kann nur Hardware sein. Wie sieht denn die Schaltung aus?
Aufbau siehe Anhang. Lief so seit Monaten, ich hab nur einen 1:1 Umzug auf den anderen Arduino gemacht indem ich Draht für Draht umgelötet habe.
Ich glaube nach wie vor, dass die Anbindung eines 3.3V RFM69 an einen 5V Arduino ohne Pegelanpassung problematisch ist.
Analyse: der Sketch läuft durch, sonst würde er auch den BMP180 nicht mehr an FHEM übermitteln. Der RFM69 steigt aus und empfängt nicht mehr, nach einem Reset geht es aber wieder, also ist er nicht defekt.
Die wahrscheinlichste Ursache ist, dass der RFM69 irgendwann aussteigt, weil er auf der SPI-Schnittstelle mit einer grenzwertigen Spannung angesteuert wird. Es gab schon reichlich Leute, die mit solchen Clonen Probleme hatten.
Siehe auch hier: http://forum.fhem.de/index.php/topic,44701.msg368238.html#msg368238
Ein Versuch wäre nun, eine Pegelanpassung einzubauen, um den RFM69 gem. Spezifikation zu betreiben.
Allerdings kann auch der Arduino ein Problem haben, der ist ja schließlich das Teil, das getauscht wurde.
Ah ... ok ... zugegeben das Thema Pegelanpassung les ich zum ersten Mal so ausführlich. Widerstände sind vorhanden, ich sehe mal zu dass ich die zeitnah entsprechend mit einlöte.
Zitat von: marco-f am 23 Dezember 2015, 10:38:27
Ah ... ok ... zugegeben das Thema Pegelanpassung les ich zum ersten Mal so ausführlich. Widerstände sind vorhanden, ich sehe mal zu dass ich die zeitnah entsprechend mit einlöte.
Ja, schaden kann das nicht, auch wenn es Fälle gibt, wo es auch ohne Pegelanpassung mehr oder weniger oder tatsächlich läuft.
Aber die Häufung der Problemmeldungen mit dieser Sorte Clone ist schon interessant.
Es kann aber trotzdem auch der Arduino sein, der nicht sauber läuft. In China sollte man immer drei bestellen, um den Qualitätsausreißer aussortieren zu können. ;D ;D
Zitat von: HCS am 23 Dezember 2015, 16:01:12
Ja, schaden kann das nicht, auch wenn es Fälle gibt, wo es auch ohne Pegelanpassung mehr oder weniger oder tatsächlich läuft.
Aber die Häufung der Problemmeldungen mit dieser Sorte Clone ist schon interessant.
Ich hoffe ich gebe hier keine vorzeitige Erfolgsmeldung ab, aber nach Einbau eines entsprechend dimensionierten Spannungsteilers läuft der JeeLink nun schon seit 3,5 Tagen. Kein großer Aufwand, aber große Wirkung. Schade dass dieses Thema in den Nachbauanleitungen so stiefmütterlich behandelt wird.
MfG
Marco
Zitat von: marco-f am 29 Dezember 2015, 09:04:55Schade dass dieses Thema in den Nachbauanleitungen so stiefmütterlich behandelt wird.
Ich habe ja schon in reichlich vielen "Hilfe, mein Clone läuft nicht richtig" Threads darauf hingewiesen, aber das Thema wird so was von ignoriert ...
Zitat von: marco-f am 29 Dezember 2015, 09:04:55
Schade dass dieses Thema in den Nachbauanleitungen so stiefmütterlich behandelt wird.
MfG
Marco
Niemand hindert dich eine Jeelink-Clone WIKI zu erstellen die vollständig ist. ;)
Billy
Zitat von: Billy am 30 Dezember 2015, 17:18:30
Niemand hindert dich eine Jeelink-Clone WIKI zu erstellen die vollständig ist. ;)
Gegen irgend welche Veröffentlichungen, die es bereits gibt und die er nicht ändern kann, nützt das auch nicht viel.
Das Problem müsste an der (den) Quelle(n) beseitigt werden und nicht durch eine Rückrufaktion. ;)
Aber einen Hinweis im wiki könnte evtl. ja jemand entdecken und ernstnehmen ...
Nur zu ...
Wie war das mit dem Lob am Tag und dem Abend!? ??? Ich war wohl doch zu voreilig. Gestern Abend hing er wieder in bekannter Art und Weise. Also warte ich jetzt auf die nächste Arduino Lieferung und dann tausche ich den mal.
@HCS: Wie ich im Thread las hast Du das Timeout Attribut eingeführt weil es wohl diverse Meldungen von JeeLinks gab die sich aufgehangen haben. Weißt Du aus dem Hut ob das einfache JeeLinks waren oder welche mit BMP180 drauf, so wie bei mir!? Denn wenn ich den BMP180 nicht drauf hätte, würde bei mir ja auch das Timeout greifen weil dann einfach nichts mehr kommen würde. Nicht dass das doch der gleiche Fehler ist und irgendwo grundsätzlich n Wurm im System ist!?
Ja, über eine eigene WIKI Seite für die Clones könnte man mal nachdenken.
Zitat von: marco-f am 31 Dezember 2015, 08:55:47Weißt Du aus dem Hut ob das einfache JeeLinks waren oder welche mit BMP180 drauf, so wie bei mir!?
Nee, kann ich nicht zuverlässig sagen, aber bei mir läuft ein Clone, basierend auf einem JeeNode mit zwei RFMs und einem BMP180 (so wie in meinem SuperJee-Beitrag beschrieben) über Wochen hinweg ohne Probleme. Es gab aber auch vereinzelt Probleme mit original JeeLinks, da war es fast immer das USB-Netzteil am Raspi.
Gerade kürzlich gab es einen Thread (finde ihn nur gerade nicht), da hatte jemand das Problem, dass ihm immer nach ca. 5 Minuten sowohl der JeeLink als auch der CUL stehen geblieben sind. Das war auch "Netzteil".
Zitat von: marco-f am 31 Dezember 2015, 08:55:47Denn wenn ich den BMP180 nicht drauf hätte, würde bei mir ja auch das Timeout greifen weil dann einfach nichts mehr kommen würde.
Kannst Dir aber auch einen watchdog (siehe commandref) definieren, der eins Deiner LaCrosse devices überwacht und wenn da nichts mehr kommt, einen "set myJeeLink reset" absetzt. Wobei es natürlich besser ist, das Problem zu beseitigen, anstatt die Symptome.
Kommen die Daten wieder, wenn Du manuell einen "set myJeeLink reset" auslöst?
Was auch bei mehreren Anwendern (nachweislich) geholfen hat: das Netzteil des Hostrechners (Raspi, Cubie, ...) tauschen, speziell am Cubie scheinen die Clones und teils auch die original JeeLink sehr sensibel auf die Spannungsversorgung zu reagieren.
Da Du einen clone hast, könntest Du auch mal auf die 5V des Ardunio einen fetten Elko packen, wäre interessant, ob das hilft.
Evtl. mal noch direkt am RFM mit 100nF blocken.
Und da der RFM von den 3.3V lebt, die der Arduino rausgibt, hier evtl. auch mal noch mit einem Elko stützen.
Möglicherweise sind ja manche China-Arduinos auf den 3.3V etwas wackelig, wer weiß, was die da so als Spannungsregler draufpacken, wenn sie der Geiz reitet ...
Generell die Liste der möglichen Ursachen (die sich gut im wiki machen würde) ;)
- Die Schaltung ohne Pegelanpassung an einem 5V Arduino ist außerhalb der verkraftbaren Toleranz der verwendeten Chips
- Die Spannungsversorgung des Host-Rechners macht Probleme
- Der Arduino läuft nicht zuverlässig, wenn er ein mal dem RFM Müll per SPI geschickt hat, könnte dessen Konfiguration verdreht sein
- Der RFM ist defekt bzw. läuft nicht stabil
- Einstrahlung von Störsignalen (ich glaube es gab mal jemand, der den Clone direkt auf einem Netzteil liegen hatte)
Ist aber nur das, was mir jetzt spontan wieder eingefallen ist.
Generell ist mein Verdacht, dass der RFM aussteigt oder einen Reset macht, warum auch immer, und dann hat er nicht mehr die passenden HF-Parameter und empfängt nichts mehr.
Jetzt habe ich gerade eine Idee bekommen:
Evtl. könnte ich bereits im Sketch prüfen, ob ein RFM eine gewisse Ziet lang nichts mehr empfangen hat (z.B. 10 Minuten) und ihm dann seine Initialisierung nochmal schicken.
Damit bestünde die Chance, dass es weiterläuft, wenn nur der RFM ausgestiegen ist.
Ich nehme es mal auf die ToDo, muss aber jetzt erst mal endlich PCA301 im LGW fertig bekommen ...
Einen guten Rutsch Richtung 2016 @all
PS: wenn der Clone aussteigt, bindet ihn um Mitternacht an eine Rakete und ... ;D ;D ;D
Zitat von: HCS am 31 Dezember 2015, 11:21:43
PS: wenn der Clone aussteigt, bindet ihn um Mitternacht an eine Rakete und ... ;D ;D ;D
Cool .... wusste gar nicht das der Sketch auch schon GPS-Unterstützung für Zielkoordinaten hat.
Man sollte jetzt aber nicht wirklich alles integrieren ... :)
Einen Guten Rutsch @all und besonders an die hier so engagierten Developer.
Gesundes Neues!
Hab den Clone nicht in den Himmel geschossen, hatte nur Batterien da. ;)
Zitat von: HCS am 31 Dezember 2015, 11:04:39
Kannst Dir aber auch einen watchdog (siehe commandref) definieren, der eins Deiner LaCrosse devices überwacht und wenn da nichts mehr kommt, einen "set myJeeLink reset" absetzt. Wobei es natürlich besser ist, das Problem zu beseitigen, anstatt die Symptome.
Danke für den Hinweis, hab mir mal einen Watchdog eingerichtet. Aber inzwischen läuft der schon wieder seit 48h. Grundsätzlich bin ich aber auch eher an der Ursachen- als der Symptombeseitigung interessiert.
ZitatKommen die Daten wieder, wenn Du manuell einen "set myJeeLink reset" auslöst?
Ja, sofort!
ZitatWas auch bei mehreren Anwendern (nachweislich) geholfen hat: das Netzteil des Hostrechners (Raspi, Cubie, ...) tauschen, speziell am Cubie scheinen die Clones und teils auch die original JeeLink sehr sensibel auf die Spannungsversorgung zu reagieren.
Ok, könnte man mal machen. Ich hab alles (Raspi Rev.B, Hub, Wlan Stick, 3x Arduino Nano) an einem Schaltnetzteil hängen welches auf der 5V Schiene 5A liefert, zu schwach sollte es also nicht sein.
ZitatDa Du einen clone hast, könntest Du auch mal auf die 5V des Ardunio einen fetten Elko packen, wäre interessant, ob das hilft.
Evtl. mal noch direkt am RFM mit 100nF blocken.
Und da der RFM von den 3.3V lebt, die der Arduino rausgibt, hier evtl. auch mal noch mit einem Elko stützen.
Möglicherweise sind ja manche China-Arduinos auf den 3.3V etwas wackelig, wer weiß, was die da so als Spannungsregler draufpacken, wenn sie der Geiz reitet ...
Ja, mal Stück für Stück durchprobieren. Nur blöd wenn er wie gerade wieder ziemlich stabil läuft.
MfG
Zitat von: marco-f am 01 Januar 2016, 23:24:23Nur blöd wenn er wie gerade wieder ziemlich stabil läuft
Noch blöder ist, wenn man das Problem gar nicht hat und Rettungsanker in die Software einbauen will ;D
Wenn er nach einem "set myJeeLink reset" wieder kommt, dann glaube ich immer mehr an meine Theorie, dass der RFM ausgestiegen ist.
Die Frage ist nur, warum er es tut, und warum in unregelmäßigen Abständen nach einigen Tagen.
Das wird eher ein Langzeitprojekt, das zu erforschen, ich hoffe Du bist mit Geduld dabei. Es wäre wirklich hilfreich, das mal geklärt zu haben und die definitive Maßnahme dagegen zu kennen.
Netzteil: da gab es auch schon jede Menge Forschung. Wenn das Netzteil mal kurz unter 4,7V runter zuckt, dann könnte es sein, dass der low drop Regler auf dem Arduino mit den 3.3V wackelt und der RFM einen brown out hat. Darum auch der Versuch mit den Stützkondensatoren.
Vielleicht als erstes mal auf den 3.3V, da ja der RFM bei Laune gehalten werden muss.
Nachtrag:Das wäre auch eine plausible Theorie, warum es mit einem anderen Arduino nicht so gut läuft, weil der evtl. einen anderen 3.3V Regler drauf hat oder einen, bei dem die Toleranz für die Differenz zwischen Eingangsspannung und 3.3V etwas anders ist, oder der Arduino selbst keine oder andere Stützkondensatoren für die 3.3V hat.
Kannst Du das mal bei dem vorherigen und dem jetzigen Arduino versuchen zu vergleichen?
Oops jetzt habe ich gestern den jeelink upgedatet (LaCrosse) auf die 10.1q (von 10.1e) und nun funktioniet leider meinen TFA Sensor 30.3155 WD nicht mehr. Ja ich weiss der gilt als problematisch, aber bei mir gab es damit keine Probleme bisher...
Die anderen (TX29DTH-IT und TX35DTH-IT) funktionieren noch problemlos.
Die Einstellungen sind nicht verändert nur der Sketch wurde neu geflasht und fhem neu gestartet.
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103R3UX-if00-port0
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A103R3UX-if00-port0@57600
FD 10
NAME jeelink8
NR 49
PARTIAL
RAWMSG OK 9 13 1 4 184 64
STATE Initialized
TYPE JeeLink
initMessages
jeelink8_MSGCNT 2971
jeelink8_TIME 2016-01-02 00:28:10
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 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-01-02 00:27:46 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t 0a v
Achso: es handelt sich um einen offiziellen Jeenode.
Das ist ja interessant. Ich habe mal die HF-Parameter der 10.1e mit denen der 10.1q verglichen, da gibt es nur einen Unterschied, die AFC.
Kannst Du dem JeeLink mal einen
set jeelink8 raw 50335o
schicken und dann schauen, ob der 30.3155 empfangen wird?
Zitat von: HCS am 02 Januar 2016, 08:46:03
Das ist ja interessant. Ich habe mal die HF-Parameter der 10.1e mit denen der 10.1q verglichen, da gibt es nur einen Unterschied, die AFC.
Kannst Du dem JeeLink mal einen
set jeelink8 raw 50335o
schicken und dann schauen, ob der 30.3155 empfangen wird?
Habe ich gemacht. Zuerst kam folgendes:
2016.01.02 12:34:13 3: jeelink8: Unknown code spi16:50335OK 9 37 1 4 194 59, help me!Das scheint mir aber nicht dazuzupassen. Nachdem ich nun nochmals Lacrosspairforsec mit ignore_battery gesetzt habe kommt plötzlich ein neuer Device:
jeelink8 dispatch OK 9 46 1 4 192 64
2016.01.02 12:38:08 4: LaCrosse: Unknown device 2E, please define it
2016.01.02 12:38:08 2: autocreate: define LaCrosse_2E LaCrosse 2E
2016.01.02 12:38:08 3: LaCrosse_2E: I/O device is jeelink8
Ich bin sicher mehrfach das Pairing neu eingeschaltet zu haben. Also vermute ich, dass der HF-Parameter von oben wirklich einen Unterschied macht (Ach so Frequenz hatte ich nie verändert / verändern müssen).
Soll ich den Parameter so in meine initCommands aufnehmen?
Danke für die schnelle Antwort und Hilfe!
Johannes
Ach so: Zur info ich hatte gestern testweise dann doch mal die batterien kurz entfernt um dann die neue id im log sehen zu können, deshalb war der autocreate jetzt natürlich für ein eigentlich bereits bekanntes gerät und deshalb die erfolgsmeldung!
hi viegener, irgendwie bin ich jetzt nicht ganz schlau draus geworden. Funktioniert der 30.3155 nun nach dem 50335o oder nicht?
Zitat von: HCS am 01 Januar 2016, 23:47:10
Das wird eher ein Langzeitprojekt, das zu erforschen, ich hoffe Du bist mit Geduld dabei. Es wäre wirklich hilfreich, das mal geklärt zu haben und die definitive Maßnahme dagegen zu kennen.
Ja, ich will ja auch einen stabil laufenden JeeLink.
ZitatDarum auch der Versuch mit den Stützkondensatoren.
Vielleicht als erstes mal auf den 3.3V, da ja der RFM bei Laune gehalten werden muss.
Kommt am Montag drauf ... 100nF direkt an den RFM.
ZitatDas wäre auch eine plausible Theorie, warum es mit einem anderen Arduino nicht so gut läuft, weil der evtl. einen anderen 3.3V Regler drauf hat oder einen, bei dem die Toleranz für die Differenz zwischen Eingangsspannung und 3.3V etwas anders ist, oder der Arduino selbst keine oder andere Stützkondensatoren für die 3.3V hat.
Kannst Du das mal bei dem vorherigen und dem jetzigen Arduino versuchen zu vergleichen?
Die 3,3V kommen vom USB/Seriell Wandler, also direkt vom CH340 (auf dem vorherigen Arduino) bzw. dem FT232RL (jetziger Arduino). Der einzige vorhandene Spannungswandler dient zum generieren der 5V Versorgungsspannung, wenn der Arduino mit einer externen Spannungsquelle an Pin 30 und nicht über USB versorgt wird. Da ich via USB versorge kommt der bei mir gar nicht zum tragen.
MfG
Marco
Hmm, der FT232RL kann auf dem 3.3V Ausgang 50mA, das ist nicht viel, sollte aber eigentlich reichen, solange der RFM nicht senden muss. Der BMP braucht so gut wie nichts.
Für den CH340 habe ich kein Datenblatt gefunden, wie viel der auf den 3.3 kann.
Zitat von: HCS am 02 Januar 2016, 18:08:19
hi viegener, irgendwie bin ich jetzt nicht ganz schlau draus geworden. Funktioniert der 30.3155 nun nach dem 50335o oder nicht?
Sorry war vielleicht etwas durcheinander:
Ja nach Setzen von 50335o funktioniert es.
Ich habe es inzwischen in meine initCommands aufgenommen und auch nach Neustart geht es damit problemlos.
Hallo,
ich versuche seit mehreren Tagen den JeeLink v3c und technoline TX29DTH-IT miteinander zu verbinden, leider ohne Erfolg.
Ich hab gelesen, dass der JL v3c den RFM69 hat und das dieser mit dem aktuellem Sketch erkannt wird. Jetzt habe ich den aktuellen Sketch drauf, bekomme aber im Serial Monitor folgendes angezeigt:
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
Wenn ich ihm jetzt im Monitor 1,4o gebe und danach mit v abfrage steht da immer noch das gleiche. Müsste da jetzt nicht das RFM12 mit dem RFM69 ersetzt werden? Oder vermisse ich noch etwas anderes, damit mir im Serial Monitor Daten angezeigt werden?
Bin um jeden Rat sehr dankbar! Vielen Dank und beste Grüße!
Zitat von: DenG am 04 Januar 2016, 18:27:02
Ich hab gelesen, dass der JL v3c den RFM69 hat und das dieser mit dem aktuellem Sketch erkannt wird.
Das ist richtig.
Zitat von: DenG am 04 Januar 2016, 18:27:02
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
Bei einem v3c sollte eigentlich automatisch ein RFM69 erkannt werden.
Zitat von: DenG am 04 Januar 2016, 18:27:02
Wenn ich ihm jetzt im Monitor 1,4o gebe und danach mit v abfrage steht da immer noch das gleiche. Müsste da jetzt nicht das RFM12 mit dem RFM69 ersetzt werden?
Die automatische Erkennung findet beim Start des Sketch statt, man muss nichts tun. 1,4o schon gar nicht. Das ist völlig kontraproduktiv.
Jetzt ist die Frage, warum der RFM69 nicht erkannt wird. Bist Du sicher, dass es ein v3c mit einem RFM69 ist und nicht einer mit einem RFM12?
Ggf. mal reinschauen, auf dem Chip, an dem die Antenne sitzt, steht es drauf.
Könnte natürlich auch defekte Hardware sein.
Hallo HCS,
vielen Dank für Deine Antwort. Auf dem Chip steht:
RF69
1448
W2V995
Gibt es eine Möglichkeit den Hardwaredefekt auszuschließen?
Vielen Dank nochmal für Deine Unterstützung.
Zitat von: DenG am 04 Januar 2016, 20:56:30
vielen Dank für Deine Antwort. Auf dem Chip steht:
RF69
1448
W2V995
Dann ist es also ein RFM69
Zitat von: DenG am 04 Januar 2016, 20:56:30
Gibt es eine Möglichkeit den Hardwaredefekt auszuschließen?
Da fällt mir aktuell nichts dazu ein. Der Prozessor läuft, da er Daten auf der Seriellen schickt.
Es wird versucht, einen RFM69 anzusprechen, falls keiner antwortet, wird angenommen, dass es ein RFM12 ist, was bei Dir passiert.
Direkt nach dem Öffnen der Schnittstelle sollte das, ohne weitere Kommandos zu senden, so aussehen:
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
Könntest mal bei JeeLabs nachfragen, ob die einen Test-Sketch haben, der prüft, ob der RFM69 funktioniert.
Zitat von: HCS am 04 Januar 2016, 22:24:47
Direkt nach dem Öffnen der Schnittstelle sollte das, ohne weitere Kommandos zu senden, so aussehen:
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
Und genau das steht da nicht, sondern RFM12 :(
Zitat von: HCS am 04 Januar 2016, 22:24:47
Könntest mal bei JeeLabs nachfragen, ob die einen Test-Sketch haben, der prüft, ob der RFM69 funktioniert.
Hab ich gemacht. Mal schauen, was da zurückkommt. Melde mich dann nochmal.
Edit:
Nach einigen Test hies es dann laut JeeLabs, dass ich das Ding bitte zurückschicken soll und dafür dann ein Neues bekomme.
Werde es mit dem Neuen nochmal testen und mich dann zurückmelden. Beste Grüße
So dann sage ich mal danke für das Modul, habe gerade erfolgreich 2 Sensoren im Terrarium platziert.
Diese mussten nur noch etwas gegen Spritzwasser geschützt werden. Hierfür konnte sich dann einmal ein Blister nützlich machen ^^
Hoffe nur das die Werte dadurch nicht all zu doll verfälscht werden.
Moin ...
Es gibt wieder Neuigkeiten von mir.
Zitat von: HCS am 31 Dezember 2015, 11:04:39
Was auch bei mehreren Anwendern (nachweislich) geholfen hat: das Netzteil des Hostrechners (Raspi, Cubie, ...) tauschen, speziell am Cubie scheinen die Clones und teils auch die original JeeLink sehr sensibel auf die Spannungsversorgung zu reagieren.
Da Du einen clone hast, könntest Du auch mal auf die 5V des Ardunio einen fetten Elko packen, wäre interessant, ob das hilft.
Evtl. mal noch direkt am RFM mit 100nF blocken.
Und da der RFM von den 3.3V lebt, die der Arduino rausgibt, hier evtl. auch mal noch mit einem Elko stützen.
Also 100n direkt am RFM69 hab ich gestrichen. Zum einen sind da meine Hände zu unruhig, zum anderen sollte ein entsprechender Kondensator auf der Platine mit drauf sein. Leider ist meine so verbaut dass ich da kaum noch rankomme um was zu sehen und einen richigen Plan was auf der Platine wie verbaut ist konnte ich bisher nicht finden. Ich hatte jetzt n paar Tage die 3,3V aus dem Arduino mit nem 47µ Elko gestützt und es kam dennoch zu einem Absturz. Letzter Versuch wäre jetzt n Elko an die 5V, die den Arduino versorgen, wobei ich der Meinung bin dass schon im Schaltnetzteil ein entsprechender Elko verbaut sein sollte.
Mal noch ne Frage zum Thema Programmierung in der fhem.cfg, mir fehlt da schon wieder mal wissen für die richtige Formatierung. Ich habe mir einen Watchdog angelegt für den JeeLink, der soweit auch läuft.
define JeeWatch watchdog SZ.Klimasensor 00:15:00 SAME set myJeeLink resetWie kann ich den korrekt erweitern, dass er mir beim Auslösen noch einen 2. Befehl mit ausführt?
MfG
Marco
Zitat von: marco-f am 11 Januar 2016, 11:52:37
Ich hatte jetzt n paar Tage die 3,3V aus dem Arduino mit nem 47µ Elko gestützt und es kam dennoch zu einem Absturz. Letzter Versuch wäre jetzt n Elko an die 5V, die den Arduino versorgen, wobei ich der Meinung bin dass schon im Schaltnetzteil ein entsprechender Elko verbaut sein sollte.
Ich glaube auch, dass das auf den 5V nicht hilft.
Ich kann bei Gelegenheit mal eine Überwachung direkt im Sketch einbauen, kann aber etwas dauern, bin mit dem LGW und PCA301 aktuell im Stress.
Evtl. lässt es sich ja im Sketch bereits erkennen und neu initialisieren.
Zitat von: marco-f am 11 Januar 2016, 11:52:37
define JeeWatch watchdog SZ.Klimasensor 00:15:00 SAME set myJeeLink resetWie kann ich den korrekt erweitern, dass er mir beim Auslösen noch einen 2. Befehl mit ausführt?
Sorry, watchdog kenne ich mich nicht aus, evtl. mal in Anfängerfragen oder dem entsprechenden Thread erkundigen.
Laut Doku von wathdog:
<command> is a usual fhem command like used in the at or notify
Du müstest als "nur" mit ; die Kommandos trennen (nicht getestet)
Ich glaube ich benötige Eure Hilfe.
Ich habe einen JeeLink 868 v3c.
Am RPI2 am USB Hub
Ich scheitere an der Einbindung der Proficell/Technoline TX 29 DT-HT Aussensender.
Soweit ich das Wiki verstanden habe, bin ich wie folgt vorgegangen:
1. gecheckt, ob avrdude installiert ist.
2. in FHEM eingebunden:
define myJeeLink JeeLink /dev/ttyUSB2@57600
3. Firmwareupdate (gestern FHEM geupdated)
set myJeeLink flash LaCrosse
folgendes Ergebnis:
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB2
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB2 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x0c
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x9b
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x24
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0xa8
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xfc
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x0c
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x9b
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x24
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0xa8
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0xfc
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
4. mein autocreate steht auf "1":
define autocreate autocreate
attr autocreate autosave 1
attr autocreate device_room %TYPE
attr autocreate filelog ./log/%NAME-%Y.log
attr autocreate weblink 1
attr autocreate weblink_room Plots
Nun bin ich davon ausgegangen, dass nach Einlegen der Batterien am TX 29 automatisch ein Device angelegt wird. Leider passiert nichts.
Bei
list myJeeLink
kommt
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB2@57600
DeviceName /dev/ttyUSB2@57600
FD 11
NAME myJeeLink
NR 49
NR_CMD_LAST_H 4
PARTIAL ���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������K������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������K������������������������������������������������������K�����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������;����������������������������������������������������������������������������K����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������K��������������������������������������������������������������������������������������������������K������������������������������������������������������������������������������������������������������������������������������K����������������������������������������������������������������������������������������K����������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������K����������������������������������������������������������������������������������������������������������������������������������������������������������������������K��������������������������������������������������������K������������������������������������������������������������������������������������������������������������������K��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������K������������������������������������������������������K���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������K���������������������������������������������������������
STATE Opened
TYPE JeeLink
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-01-19 19:54:42 state opened
XMIT_TIME:
1453231051.05415
1453231051.18877
1453231065.38275
1453231065.55368
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Habe ich etwas vergessen?
Zitat von: Gunther am 19 Januar 2016, 22:05:17
Ich glaube ich benötige Eure Hilfe.
Habe ich etwas vergessen?
Ich glaube schon!
z.B.
set LaCrosse LaCrossePairForSec 600 --> autocreate alleine reicht nicht
Billy
Zitat von: Gunther am 19 Januar 2016, 22:05:17
Ich habe einen JeeLink 868 v3c.
3. Firmwareupdate (gestern FHEM geupdated)
flashing JeeLink myJeeLink
...
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x0c
Das flashen der Jeelink firmware hat nicht funktioniert. Die Meldungen besagen, dass der Flashvorgang gar nicht gestartet werden konnte.
Mögliche Fehlerursachen sind die falsche Schnittstelle ausgewählt. Versuche das flashen doch mal an einem anderen Rechner und überprüfe ob der richtige USB-Port gewäht ist.
Ist der JeeLink überhaupt richtig bespielt bespielt? Soweit wie ich im Shop nachlese wird der ja nur mit einem Demo Sketch ausgeliefert. Im Punkt 3 wurde versucht den Lacrosse Sketch aufzuspielen aber die Ausgabe zeigt an, dass das nicht geklappt hat.
Ich hab bei der Abfrage von list myJeeLink u.a. folgendes stehen: STATE Initialized
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3) + BMP180]
Das vermisse ich und glaube der JeeLink läuft nicht!
Ich bekomme meinen auch nicht mehr geflashede
Das ist die Meldung, die ich bekomme, wenn ich ihn flashen will
Zitatflashing JeeLink JLLaCR
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
JLLaCR closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
sh: 1: avrdude: not found
--- AVRDUDE ---------------------------------------------------------------------------------
JLLaCR opened
Das ist die List des Jeelinks
ZitatInternals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 11
JLLaCR_MSGCNT 472
JLLaCR_TIME 2016-01-19 22:21:28
NAME JLLaCR
NR 42
PARTIAL
RAWMSG OK 9 63 1 4 176 106
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1o (RFM12B f:868300 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-01-19 22:19:08 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t 0a v
room Gateways
verbose 0
Zitat von: viegener am 19 Januar 2016, 22:17:51
Das flashen der Jeelink firmware hat nicht funktioniert. Die Meldungen besagen, dass der Flashvorgang gar nicht gestartet werden konnte.
Mögliche Fehlerursachen sind die falsche Schnittstelle ausgewählt. Versuche das flashen doch mal an einem anderen Rechner und überprüfe ob der richtige USB-Port gewäht ist.
Wie kann ich den USB Port checken?
Zitat von: dieda am 19 Januar 2016, 22:22:02
Ich bekomme meinen auch nicht mehr geflashede
Das ist die Meldung, die ich bekomme, wenn ich ihn flashen will
Das ist die List des Jeelinks
Zitat von: dieda am 19 Januar 2016, 22:22:02
--- AVRDUDE ---------------------------------------------------------------------------------
sh: 1: avrdude: not found
--- AVRDUDE ---------------------------------------------------------------------------------
Wenn avrdude nicht installiert ist wird das auch nix.
Sollte es doch installiert sein so gib mal bei "flashCommand " den komplette Pfadnamen mit an ... /usr/bin/avrdude ... oder wo immer das auch bei dir liegt an.
Zitat von: AxelSchweiss am 19 Januar 2016, 22:33:06
Wenn avrdude nicht installiert ist wird das auch nix.
Sollte es doch installiert sein so gib mal bei "flashCommand " den komplette Pfadnamen mit an ... /usr/bin/avrdude ... oder wo immer das auch bei dir liegt an.
Mag sein, aber es war installiert und jetzt? Von f bis O bin ich ja so gekommen.
Zitat von: Gunther am 19 Januar 2016, 22:25:29
Wie kann ich den USB Port checken?
pi@raspberrypi /opt/fhem $ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 008: ID 04e8:8001 Samsung Electronics Co., Ltd Handheld
Bus 001 Device 009: ID 0fde:ca05
Bus 001 Device 010: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 007: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUBwelcher isses? ::)
Zitat von: Gunther am 19 Januar 2016, 22:25:29
Wie kann ich den USB Port checken?
Wenn du den Jeelink einsteckst oder raus ziehst loggt der Kernel das in seinen Ringpuffer.
Den kannst du mittels "dmesg" auslesen ... da siehst du dann auch welchen USB er belegt.
Ansonsten gibts noch "lsusb" oder "ls -l /dev/serial/by-id/"
Wenn du sehen möchtest ob der Port physisch in Ordnung ist steck einfach mal einen USB-Stick ein und sieh was im Ringpuffer steht.
Zitat von: dieda am 19 Januar 2016, 22:36:23
Mag sein, aber es war installiert und jetzt? Von f bis O bin ich ja so gekommen.
Wenn du es nicht gelöscht oder das Paket entfernt hast ist es auch noch da.
Eventuell hast du dir dein Environment kaputt gemacht.
Deswegen die absolute Pfadangabe.
Bei mir unter Debian Weezy liegt es hier : /usr/bin/avrdude
pi@raspberrypi /opt/fhem $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-FTDI_FT232R_USB_UART_A900WVZZ-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-Silicon_Labs_Owl_Wireless_Electricity_Monitor_USB_version_connected_0077CF1A-if00-port0 -> ../../ttyUSB2
hmm, keine Ahnung. Ich teste einfach durch.
Zitat von: Gunther am 19 Januar 2016, 22:40:33
pi@raspberrypi /opt/fhem $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-FTDI_FT232R_USB_UART_A900WVZZ-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-Silicon_Labs_Owl_Wireless_Electricity_Monitor_USB_version_connected_0077CF1A-if00-port0 -> ../../ttyUSB2
hmm, keine Ahnung. Ich teste einfach durch.
Jeelink abziehen und schauen welcher dann fehlt! Wieder anstecken, dann ist er wieder da und du weißt es genau!
Zitat von: Gunther am 19 Januar 2016, 22:40:33
pi@raspberrypi /opt/fhem $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-FTDI_FT232R_USB_UART_A900WVZZ-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 19 19:35 usb-Silicon_Labs_Owl_Wireless_Electricity_Monitor_USB_version_connected_0077CF1A-if00-port0 -> ../../ttyUSB2
hmm, keine Ahnung. Ich teste einfach durch.
Jep ... zieh einen raus und sieh welcher fehlt ...
Zitat von: marco-f am 19 Januar 2016, 22:41:52
Jeelink abziehen und schauen welcher dann fehlt! Wieder anstecken, dann ist er wieder da und du weißt es genau!
liege im Bett bei ausgefallener Heizung - da muss ich in den Keller... ;-)
Zitat von: Gunther am 19 Januar 2016, 22:43:30
liege im Bett bei ausgefallener Heizung - da muss ich in den Keller... ;-)
Dann wird Dir wenigstens warm beim Treppensteigen! :P
Zitat von: Gunther am 19 Januar 2016, 22:43:30
liege im Bett bei ausgefallener Heizung - da muss ich in den Keller... ;-)
Dann machs jetzt ... morgen ist es in deiner Bude bestimmt kälter ... da bleibst du bestimmt lieber in der Falle ;D ;D
EDIT
Moment ... mal schauen ..... nö 21°C ... noch läuft meine Heizung 8)
so nun bei usb0:
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (28690 bytes):
Writing |
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0xe6
avrdude: stk500_cmd(): programmer is out of sync
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
war das nu ok?
Zitat von: Gunther am 19 Januar 2016, 22:48:59
so nun bei usb0:
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (28690 bytes):
Writing |
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0xe6
avrdude: stk500_cmd(): programmer is out of sync
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
war das nu ok?
Sieht gut aus!
set myJeeLink LaCrossePairForSec 600
und Batterien aus dem Technoline raus und wieder rein bringt leider nichts.
Es sollte doch nun unten in der fhem.cfg ein neues Device angehängt werden, oder?
Was sagt denn list myJeeLink jetzt? Läuft der JeeLink jetzt überhaupt ordentlich?
Sorry, aber das sieht nicht gut aus:
ZitatWriting |
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0xe6
avrdude: stk500_cmd(): programmer is out of sync
Könnte EInfluss eines anderen Gerätes sein. Fällt mir jetzt erstmal nichts zu ein...
Lesen geht, schreiben geht schief, damit ist er nicht geflashed!
Also .. bitte beim Flashen sicherstellen das das Device nicht schon anderweitig verwendet wird ... daher FHEM runterfahren
Dann gibt es noch zwei unterschiedliche Baudraten mit denen die Jeelinks funktionieren .... hängt vom Serial2USB-Chip ab ... 57600 und 384000 .... glaube ich.
Mach mal einen "list myJeeLink" und poste das hier.
Wenn der Jeelink nicht mit "Initialized" drin steht ... wirds nix mit dem Nachbarn.
Anbei ein Screenshot von meinem Jeelink (original .. kein Clone)
state ist opended... :-(
list:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 118
NAME myJeeLink
NR 49
PARTIAL
STATE Opened
TYPE JeeLink
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-01-19 23:02:14 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Zitat von: AxelSchweiss am 19 Januar 2016, 23:02:23
Also .. bitte beim Flashen sicherstellen das das Device nicht schon anderweitig verwendet wird ... daher FHEM runterfahren
wie kann ich dann über fhem flashen?
Der jeeLink ist immer noch nicht auf Initialized. Du bist Dir sicher, dass der auf ttyUSB0 läuft?
nein sicher nicht
Zitat von: Gunther am 19 Januar 2016, 23:09:57
nein sicher nicht
Ohne dass der auf der richtigen Schnittstelle eingebunden wird kann es nichts werden.
Zitat von: Gunther am 19 Januar 2016, 23:06:02
state ist opended... :-(
Klar ... weil es beim Flash daneben ging ... der Jeelink ist noch "leer".
Wie gesagt ... FHEM runterfahren und das avrdude auf der Komandozeile von Hand ausführen.
Alternativ kannst du das flashen auch aus FHEM machen ... wenn du in der GUI oben bei "set myjeelink" flash ausführst.
Zitat von: Gunther am 19 Januar 2016, 23:09:57
nein sicher nicht
Du solltest erst mal die Hausaufgaben machen ... bevor du deine Helfer im Nebel rumstochern läst .
Zitat von: AxelSchweiss am 19 Januar 2016, 23:11:05
Klar ... weil es beim Flash daneben ging ... der Jeelink ist noch "leer".
Wie gesagt ... FHEM runterfahren und das avrdude auf der Komandozeile von Hand ausführen.
Alternativ kannst du das flashen auch aus FHEM machen ... wenn du in der GUI oben bei "set myjeelink" flash ausführst.
Gunther ... sorry, ich hab vorhin nur halb geschaut. Stimmt, das klappte doch immer noch nicht. Axel hat recht!
Zitat von: AxelSchweiss am 19 Januar 2016, 23:12:22
Du solltest erst mal die Hausaufgaben machen ... bevor du deine Helfer im Nebel rumstochern läst .
Gebe Dir Recht! Kläre morgen den USB Port.
ZitatFHEM runterfahren und das avrdude auf der Komandozeile von Hand ausführen
Eine Frage noch: Wie kann ich auf Konsolenebene flashen? Was muss ich eingeben?
USB Angaben über /dev/ttyUSB* haben aber auch noch das Problem, dass diese dynamisch sind. D.h. wenn Dein JeeLink jetzt ttyUSB1 ist kann es sein, dass er nach einem Neustart und/oder einer Änderung in den USB Geräten eine andere Nummer zugewiesen bekommt. Daher ist es sinnvoller ihn über die Device-ID einzubinden, da diese eindeutig ist (bzw. sein sollte). Wenn Du über das bereits erwähnte ,,ls -l /dev/serial/by-id" herausgefunden hast, welches der Geräte wirklich Dein Stick ist, kannst Du diesen dann in FHEM direkt mit der eindeutigen ID einbinden. z.B.: define myJeeLink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB12C34D-if00-port0
Wenn er so eingebunden ist sollte auch das flashen direkt von fhem aus kein Problem mehr sein.
Hi,
habe das Problem, das autocreate keine Einträge erstellt?
Habt ihr eine Idee, wo ich noch ansetzten kann?
geflasht ist der Jeelink.
liist myJeeLink bringt
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 37
NAME myJeeLink
NR 543
NR_CMD_LAST_H 2
PARTIAL
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:1 r:17241)]
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-01-19 21:39:43 state opened
XMIT_TIME:
1453266953.63304
1453267019.02353
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t v
room Zentral
VG
Christian
Zitat von: HCS am 23 November 2015, 13:20:00
Super, das hilft erheblich weiter.
Ich fasse mal zusammen:
Die WS 1080 gibt es (unter gleichem Namen) in einer OOK- und in einer FSK-Version
Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version nicht.
Die FSK-Version erkennt man an:
- Runder grüner Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7"
- Das radio ist ein RFM01, erkennt man auch schon an der Form, es ist fast quadratisch.
Die OOK-Version erkennt man an:
- Runder grüner Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS A14C"
- Das radio ist ein ASK868MA1, erkennt man auch schon an der Form, es ist rechteckig und mit ASK868MA1 beschriftet.
Die OOK-Version kann mit SIGNALDuino und einem RX868SH-DV empfangen werden (habe ich nicht getestet, sondern so aus der Doku von pejonp übernommen)
pejonp und fossy haben ein "PASS 7" und können sie empfangen, oli82 und nochwer haben ein "PASS A14C" und empfangen sie nicht, was das oben geschriebene bestätigt.
Damit wäre der Fall dann hinreichend geklärt.
@Billy: würdest Du das ins wiki übernehmen um weitere Anwender davor zu bewahren, mit der OOK-Version zu scheitern?
Ich werde es dann noch in diesem Thread weiter oben und im LGW Thread so vermerken.
Hallo
Kann mir jemand sagen, wo ich die richtige Version dieser Wetterstation kaufen kann, um die Daten über den Jeelink mit FHEM auswerten zu können?
Danke schön.
Viele Grüße
Marcus
Hi shorty81,
der JeeLink läuft nicht richtig.
Zitat von: shorty81 am 20 Januar 2016, 07:47:35
model [LaCrosseITPlusReader.10.1q (RFM69 f:1 r:17241)][/quote]
f:1 gibt an, dass Deiner mit einer Frequenz von 1kHz arbeitet, dort müsste aber f:868300 stehen. Warum dies so ist kann ich Dir leider nicht sagen. Offensichtlich hast Du schon die initCommands 30t v gesetzt, mit denen geht er bei mir in den richigen Betriebsmodus und auf die richtige Frequenz.
Grüße,
Marco
Zitat von: Aeroschmelz am 20 Januar 2016, 10:42:16Kann mir jemand sagen, wo ich die richtige Version dieser Wetterstation kaufen kann
Tipp : such im Netz nach der WS1600 (Strassenpreis ca. 95 - 99 €) damit hast das Problem der verschiedenen Versionen nicht :)
[quote author=marco-f link=topic=14786.msg395082#msg395082 date=1453283612]
Hi shorty81,
der JeeLink läuft nicht richtig.
f:1 gibt an, dass Deiner mit einer Frequenz von 1kHz arbeitet, dort müsste aber f:868300 stehen. Warum dies so ist kann ich Dir leider nicht sagen. Offensichtlich hast Du schon die initCommands 30t v gesetzt, mit denen geht er bei mir in den richigen Betriebsmodus und auf die richtige Frequenz.
Grüße,
Marco
[/quote]
Uff, bin eigentlich streng nach Anleitung vorgegangen.
Hat jemand eine Idee,w ie ich den Jeelink zum Lazufen bekomme und warum es an der Stelle trotz "initCommands 30t v" derzeit stockt?
VG
Chris
Zitat von: Wzut am 20 Januar 2016, 11:06:46
Tipp : such im Netz nach der WS1600 (Strassenpreis ca. 95 - 99 €) damit hast das Problem der verschiedenen Versionen nicht :)
Habe mir die WS1600 an Weihnachten geschenkt.
Mit Kombination von Gutschein habe ich beim Conrad ca. 70 Euro bezahlt.
Allerdings hat die Station einen derben Nachteil ..... der Windrichtungsanzeiger friert bei unter 0°C ein wenn er vorher nass war ... steht bei mir jetzt seit fast einer Woche auf NNW >:(
Das scheint aber eine konstruktionsbedingte Schwachstelle zu sein.
Ansonsten läuft dat Ding super.
Das sieht jetzt zumindest besser aus, oder?
Aber autofreie legt trotzdem nichts an?!
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 37
NAME myJeeLink
NR 543
PARTIAL
RAWMSG OK 9 49 1 3 239 106
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]
myJeeLink_MSGCNT 307
myJeeLink_TIME 2016-01-20 13:52:44
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-01-20 12:20:43 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t v
room Zentral
Zitat von: shorty81 am 20 Januar 2016, 13:54:40
Aber autofreie legt trotzdem nichts an?!
klar , warum auch ?
set myJeeLink LaCrossePairForSec 120
ist dein Freund :)
Zitat von: Wzut am 20 Januar 2016, 15:36:19
klar , warum auch ?
set myJeeLink LaCrossePairForSec 120
ist dein Freund :)
Hatte ich gestern schon geschrieben ;) ;)
Danke. Hatte ich auch gestern schon gelesen berücksichtigt ;)
Das mit der habe ich jetzt Kabelnetzwerk bekommen.
Aber auch nachdem der jeelink im pairingmodus ist wird nichts angelegt?
Welche Infos (Logs) könnten denn bei der Fehlersuche helfen?
Danke und viele Grüße
Chris
Zitat von: shorty81 am 20 Januar 2016, 18:47:07
Aber auch nachdem der jeelink im pairingmodus ist wird nichts angelegt?
Du hast ja sicher auch vorher die Batterien in den Sensoren kurz rausgenommen damit
die Sensoren auch im Pairing Modus sind?
Billy
Sogar für mehrere Minuten. Dann pairing aktiviert für 120, dann Batterien in den tx22 eingelegt. Und nix passiert...
Bin ratlos!
Zitat von: shorty81 am 20 Januar 2016, 19:30:10
Sogar für mehrere Minuten. Dann pairing aktiviert für 120, dann Batterien in den tx22 eingelegt. Und nix passiert...
Bin ratlos!
Batterien mehrere Minuten raus ist nicht notwendig! Par sekunden reicht!
Solltest du im Prinzip umgekehrt machen!
Zuerst Batterien einlegen dann set myJeeLink LaCrossePairForSec 300 --> mach mal 300 sec und nimm vorher mit initJeeLink bei den inits vorher mal mal 30t raus!
Wenn du einen Sensor hast brauchst du nicht toggeln.
Vielleicht gehts dann?
Kannst ja mal schauen was an raw messages kommt falls dein autocreate nichts bringt.
Funktioniert leider auch nicht. Passiert nix.
Wie missnich den mit dem raw umgehen? Welche Befehle gibt es? Bzw. was kann wo kommen?
Zitat von: shorty81 am 20 Januar 2016, 19:30:10
... dann Batterien in den tx22 eingelegt ...
Du hast einen TX22 also eine WS 1600.
Der TX22 sendet mit einer data rate von 8842 kbps
Dann sollten Deine initCommands so aussehen:
attr myJeeLink initCommands 8842r v
Moin! Vermutlich lautet die Antwort 'nein', aber ...
Ich habe heute einen JeeLink mit LaCrosse als Relay geflasht. Gibt es irgendeine Möglichkeit (außer einer PCA301) in FHEM zu registrieren ob das Relay 'present' ist?
Zitat von: shorty81 am 20 Januar 2016, 21:57:26
Funktioniert leider auch nicht. Passiert nix.
Falls Du noch Sensoren wie TX29 usw. hast, dann so:
attr myJeeLink initCommands 5m 30t vFalls Du noch Sensoren wie TX29, TX35 hast, die mit 17 und 9K senden, dann so:
attr myJeeLink initCommands 7m 30t vIn dem Fall ist aber eher ein SuperJee oder eine LGW sinnvoll, weil Du sonst von 180 bzw. 60 Sekunden nur 30 Sekunden etwas von der WS empfängst und das ist doof beim Wind.
Zitat von: waschbaerbauch am 20 Januar 2016, 22:04:00
Moin! Vermutlich lautet die Antwort 'nein', aber ...
Die Antwort auf welche Frage?
Zitat von: waschbaerbauch am 20 Januar 2016, 22:04:00
Ich habe heute einen JeeLink mit LaCrosse als Relay geflasht. Gibt es irgendeine Möglichkeit (außer einer PCA301) in FHEM zu registrieren ob das Relay 'present' ist?
Das JeeLink Relay kann kein PCA301
Es kann nur die Sensoren, die vom JeeLink Sketch unterstützt werde. Siehe wiki.
Mann kann es nur dadurch feststellen, dass man einen Sensor außerhalb der Reichweite mit Relay empfangen kann.
So war das auch nicht gemeint - sorry..
Mein 'Fallback' wäre gewesen ein USB Netzteil mit dem autarken JeeLink mit LaCrosse als Relay geflasht in eine PCA301 Steckdose zu packen und anhand des minimalen Verbrauchs versuchen zu registrieren dass das LaCrosse Relay noch arbeitet. Bissel verwirrend, aber ich wollte halt nur schauen ob man es irgendwie mitbekommen kann ob es seinen Dienst (das Relay) einstellt oder nicht mehr empfängt und weiterleitet.
PS: Ja das ist natürlich auch eine Idee - ich werde einen Outdoor Temperatursensor so weit entfernt aufstellen, das er auf keinen Fall den JeeLink im Wohnzimmer erreichen kann, aber das Relay im Anbau! Danke für diese einfache Idee :D
Zitat von: waschbaerbauch am 20 Januar 2016, 22:19:28ob es seinen Dienst (das Relay) einstellt oder nicht mehr empfängt und weiterleitet.
Da gibt es leider nichts.
Ich würde eher die Sensoren in FHEM überwachen, ob noch Daten kommen (watchdog). Wenn ein Sensor nicht mehr empfangen wird, dann ist es so oder so ein Problem, egal ob er über ein Relay kommen sollte oder direkt.
Vielen vielen Dank! Genau so und nicht anders werde ich es machen, muss eh noch einen Temperatursensor in das Spielhaus der Tochter am Ende des Grundstücks einbringen :D
Nur mal aus Interesse: Würde auch eine Verbindung Sensor <-> LaCrosse Relay <-> LaCrosse Relay <-> LaCrosse FHEM funktionieren falls der Weg für ein LaCrosse Relay auf der Strecke zu weit sein sollte?
Zitat von: waschbaerbauch am 20 Januar 2016, 22:30:35
Nur mal aus Interesse: Würde auch eine Verbindung Sensor <-> LaCrosse Relay <-> LaCrosse Relay <-> LaCrosse FHEM funktionieren falls der Weg für ein LaCrosse Relay auf der Strecke zu weit sein sollte?
Nein. Man darf auf keinen Fall mehr als ein Relay laufen haben.
Das relayte Packet unterscheidet sich nicht vom Ursprünglichen, die Relays würden dann "Und täglich grüßt das Murmeltier" spielen.
Wer den Film nicht kennt: Endlosschleife.
Doch den kenne ich - klingt absolut logisch!
Es war auch erstmal nur eine theoretische Frage falls die Verbindung über die gesamte Distanz nicht aufgebaut werden könnte. Vorerst gehe ich davon aus, das es funktionieren wird. Wenn es morgen nicht arg zu kalt ist, dann werde ich das mal in der Praxis austesten.
Hi,
ich habe nen Jeelink-Clone besehend aus einem Arduino und einem RFM69CW (with RFM12B comp Fingerprint).
Jetzt habe ich hier noch nen RFM12B und nen BMP180 rumliegen, kann ich daraus nen SuperJee bauen bzw. hat das schon mal jemand gemacht und hat ne Anleitung bzw. ein Anschlussschema?
Grüße
Deine Antwort gibt Dir Google: fhem superjee oder das FhemWiki.
Grüße Jörg
Gesendet von iPhone mit Tapatalk
Danke aber da habe ich bereits gesucht aber nichts gefunden was auf meine vorhandenen Komponenten zutrifft.
Zitat von: davedeluxe am 21 Januar 2016, 07:55:22
Danke aber da habe ich bereits gesucht aber nichts gefunden was auf meine vorhandenen Komponenten zutrifft.
Google -> superjee -> erster Eintrag geht zu https://blog.moneybag.de (https://blog.moneybag.de) und darin findet sich ein Link zurück ins Forum wo man alles findet.
Zitat von: davedeluxe am 21 Januar 2016, 07:25:40
Jetzt habe ich hier noch nen RFM12B und nen BMP180 rumliegen, kann ich daraus nen SuperJee bauen ...
Ja
Zitat von: davedeluxe am 21 Januar 2016, 07:25:40
... hat das schon mal jemand gemacht
Ja, ich
Zitat von: davedeluxe am 21 Januar 2016, 07:25:40... und hat ne Anleitung bzw. ein Anschlussschema?
Hier: http://forum.fhem.de/index.php/topic,14786.msg316924/topicseen.html#msg316924
Danke HCS, damit bist du der Erste der es schafft ne qualifizierte Antwort zu geben und nicht nur auf google zu verweisen.
Den Post habe ich bereits gelesen, bin/war mir allerdings nicht sicher ob ich mischen kann, sprich RFM69CW und RFM12B.
Ich habe das so verstanden das ich entweder 2x RFM12B oder 2x RFM69CW verbauen muss.
Die Verkabelung kann ich aus den angehängten Bildern nicht übernehmen da ich ja nur nen Clone und dementsprechend andere PINs habe.
Aber wenn du sagst das es generell geht, dann werd ich mal am Breadboard testen :)
Herzlichen Dank!
------------------------------------------------------In eigener Sache----------------------------------------------------------------------------
Ich stelle hier im Forum keine Fragen weil ich kein google nutzen kann oder wissen will wer keine Lösung hat sondern weil ich
eine Lösung für mein Problem suche. Dafür sind Foren gedacht.
Es ist hier wie in den meisten Foren, es gibt immer welche die einem als Antwort schreiben: "Hast mal google benutzt?"
Das ist weder hilfreich noch im Sinne der Wissensverbreitung. Irgendwann gibt es nur noch Foren in denen man auf google
verwiesen wird aberdie entsprechende Quelle ist nicht mehr vorhanden ist.
- sharing is caring
Sicher gibt es auch Dinge die hier schon behandelt wurden (und sicher auch schnon mehrfach) aber tut es dann weh
einfach nen Link zum entsprechenden Thread/Post zu platzieren?
Ist auch nicht viel mehr Arbeit als den Standardsatz: "Hast mal google benutzt?" zu posten.
Und wenn man nichts beizutragen hat, gibt es immer die Option einfach mal nichts zu schreiben.
Dann müllt man das Forum nicht mit unnötigen und teilweise arroganten Antworten zu.
Zitat von: davedeluxe am 21 Januar 2016, 15:47:09
Ich habe das so verstanden das ich entweder 2x RFM12B oder 2x RFM69CW verbauen muss.
Man kann mischen.
Zitat von: davedeluxe am 21 Januar 2016, 15:47:09
Die Verkabelung kann ich aus den angehängten Bildern nicht übernehmen da ich ja nur nen Clone und dementsprechend andere PINs habe.
Du hast keine anderen Pins.
Egal ob Clone, JeeNode oder sonst was, es ist immer ein atmega 328 und die Schaltung wie in meinem Beitrag im Schaltplan dargestellt.
PB0 ist immer PB0, egal wie die Hardware konstruktiv gestaltet ist, der Schaltpan ist das Entscheidende.
Zitat von: davedeluxe am 21 Januar 2016, 15:47:09
Aber wenn du sagst das es generell geht, dann werd ich mal am Breadboard testen :)
Es wird gehen, da bin ich zuversichtlich ;D ;D
Zitat von: HCS am 20 Januar 2016, 21:58:30
Du hast einen TX22 also eine WS 1600.
Der TX22 sendet mit einer data rate von 8842 kbps
Dann sollten Deine initCommands so aussehen:
attr myJeeLink initCommands 8842r v
Soweit alles eingestellt. Danke! Ich empfange tatsächlich auch einen Sender des Nachbarn! Liefert konstant ohne pairing die Temp und wird auch nach dem Löschen erneut angelegt.
Nur meine WS1600/TX22 taucht nirgends auf?!
Die Displays der WS1600 empfangen aber problemlos Daten - auch nach mehrfachem Batteriewechseln
Ergänzung:
Heute morgen stand im Jeelink-Log folgender Eintrag
2016-01-21_23:29:34 myJeeLink UNKNOWNCODE OK LS 14 0 11 254 4 106 103
im fhem-Log
2016.01.22 06:21:36 5: JeeLink/RAW: /OK 9 49 1 3 167 106
2016.01.22 06:21:36 5: myJeeLink dispatch OK 9 49 1 3 167 106
2016.01.22 06:21:36 5: Triggering LaCrosse_31 (3 changes)
Hallo Leute, ich bin verwirrt.
Ich habe hier ein paar ETH 200 Thermostaten von EQ-3 die ich mit einem Jeelink (Arduino Clone CH340) per Taster (weiß noch
nicht - Homematic oder Intertechno) auf 1 Stunde Komforttemperatur schalten will.
Nun gibt es ja hier den All-In-One Sketch von Ulli (http://forum.fhem.de/index.php/topic,17697.0.html), den ich nicht erfolgreich
in Betrieb nehmen konnte. Dafür gibt es wahrscheinlich mehrere Gründe. Mein Clone läuft in FHEM nur mit 38400 (hat mit der Fritzbox
zu tun) und es gibt keinen Sketch sondern nur ein Hexfile, das ich nicht an meine Bedürfnisse anpassen kann.
Grundsätzlich läuft der Empfang von Lacrosse-Sensoren bei mir schon seit längerer Zeit (LaCrosseITPlusReader.10.1o).
Ich schweife ab... meine Frage ist:
Was bedeutet der folgende Eintrag in den Internals meines Jeelink:
Clients: PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
Kann ich mit diesem Sketch die ETH200 steuern und wenn ja, gleichzeitig zum LaCrosse Empfang?
Gruß, Oli
Zitat von: marco-f am 19 Januar 2016, 23:36:54
USB Angaben über /dev/ttyUSB* haben aber auch noch das Problem, dass diese dynamisch sind. D.h. wenn Dein JeeLink jetzt ttyUSB1 ist kann es sein, dass er nach einem Neustart und/oder einer Änderung in den USB Geräten eine andere Nummer zugewiesen bekommt. Daher ist es sinnvoller ihn über die Device-ID einzubinden, da diese eindeutig ist (bzw. sein sollte). Wenn Du über das bereits erwähnte ,,ls -l /dev/serial/by-id" herausgefunden hast, welches der Geräte wirklich Dein Stick ist, kannst Du diesen dann in FHEM direkt mit der eindeutigen ID einbinden. z.B.: define myJeeLink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AB12C34D-if00-port0
Wenn er so eingebunden ist sollte auch das flashen direkt von fhem aus kein Problem mehr sein.
So, heute komme ich mal wieder zum FHEM-Frickeln.
Ich habe gecheckt, welcher Stick es ist und ihn nun direkt über den Port eingebunden:
define myJeeLink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0steht dann leider auf "opened"
Mit
set myJeeLink flash LaCrossebekomme ich folgende Meldung.
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (28690 bytes):
Writing | ########
avrdude: stk500_paged_write(): (a) protocol error, expect=0x14, resp=0x98
avrdude: stk500_cmd(): programmer is out of sync
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened programmer is out of sync scheint ja ein Problem zu sein.
Was kann ich tun?
Danke schonmal.
Habe das Ding nun mal direkt an den RPI2 angedockt.
Nun bekomme ich beim Flashen folgende Meldung:
flashing JeeLink myJeeLink
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (28690 bytes):
Writing | ################################################## | 100% 4.16s
avrdude: 28690 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 28690 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.20s
avrdude: verifying ...
avrdude: 28690 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Sieht zwar anders aus, trotzdem steht hier noch opened und nicht initialised...
zwischendurch wechselt das Ding von opened zu disconnected.
list zeigt
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0@57600
FD 116
LaCrossePair 1
NAME myJeeLink
NR 50
PARTIAL
RAWMSG LaCrosseader.10.1 f:868301)]
STATE Opened
TYPE JeeLink
initMessages
model [LaCrosseader.10.19 f:868301)]
myJeeLink_MSGCNT 107
myJeeLink_TIME 2016-01-22 22:48:19
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-01-22 22:48:16 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 5m 30t v
Zitat von: hmtec99 am 22 Januar 2016, 19:11:38
Was bedeutet der folgende Eintrag in den Internals meines Jeelink:
Clients: PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
Das ist die Liste der Module, an die das JeeLink Modul Daten zustellen kann. Da das JeeLink Modul verscheiden Sketche unterstützt, ist hier alles aufgelistet, was generell geht.
Je nach dem, welcher Sketch auf dem JeeLink drauf ist, geht aber immer nur ein Teil davon, abhängig was der Sketch unterstützt.
Der LaCrosse Sketch kann LaCrosse, Level und EMT7110.
Der PCA301-Sketch kann PCA301
Es hängt also vom Sketch ab, was der kann.
Zitat von: hmtec99 am 22 Januar 2016, 19:11:38
Kann ich mit diesem Sketch die ETH200 steuern und wenn ja, gleichzeitig zum LaCrosse Empfang?
Nein. Siehe oben. Der LaCrosse Sketch kann kein ETH200.
Zitat von: Gunther am 22 Januar 2016, 22:53:42
zwischendurch wechselt das Ding von opened zu disconnected.
Es sieht so aus, als ob das flashen nun funktioniert hätte.
Jetzt sollten wir mal schauen, ob der JeeLink richtig läuft. Aber nicht auf dem Raspi, um "seltsame Dinge mit USB-Ports" auf dem auszuschließen.
Hast Du einen Windows-Rechner?
Wenn ja, installiere Dir ein Terminalprogramm, z.B. HTerm oder ein beliebiges anderes und stelle es auf 57600 Baud ein. JeeLink dran und den Port COM1, ... richtig einstellen.
Schicke vom Terminalprogramm aus ein v, dann sollte der Sketch mit etwas in der Art antworten:
[LaCrosseITPlusReader.10.1q (RFM12 ....
Wenn Du Sensoren empfängst, dann sollte alle paar Sekunden etwas kommen, das so aussieht:
OK 9 48 1 4 126 49
hterm habe ich auf einem Winrechner installiert.
Ich bekomme nur COM 3,4,5,6 angezeigt. Bis auf 4 kann ich conncecten, mit was auch immer.
Baud habe ich eingestellt.
Muss ich noch etwas beachten?
Dann in der Zeile wo "type" vorsteht einfach ein "v" eingeben und auf "ASend"?
Muss da etwas bei Type verändert werden?
Zitat von: Gunther am 24 Januar 2016, 11:57:04
Muss ich noch etwas beachten?
57600 einstellen
Schnittstelle wählen, ggf. schauen, welche dazu kommt, wenn man den JL steckt (wird aktualisiert, wenn man "R" hinter "Port" klickt
"Newline at" auf "CR+LF"
"Show newline characters" aus
"Connect" Button klicken
Hinter "Type ASC" ein v eingeben und Return betätigen, nicht "ASend"
Dann sollte oben
[LaCrosseITPlusReader.10.1q (RFM12 kommen
Leider verändern sich die Ports nicht beim reinstecken.
Connceten kann ich bei allen Ports ausser Com4.
Trotzdem schickt mir das Tool nur ein v als Antwort.
Bei COM4 schreibt er:
Error in OpenPort: 'COM4' blocked by another application
Wenn sich die Ports beim Reinstecken nicht verändern (auch nicht nach einiger Wartezeit) und nach dem Installieren von etwaigen Treibern ist etwas am Device oder den Treibern. Da hilft dann auch eine Verbindung zu anderen Com-Ports nicht.
Was sagt der Devicemanager bzw gibt es eine Fehlermeldung beim ersten Reinstecken (Treiber nicht gefinden oder ein Device mit Rufzeichen im Devicemanager o.ä.)?
Johannes
OK, Treiber habe ich manuell installiert. Nun gibt es COM8 und folgende Meldung:
<\n>[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
Ist das ok und wenn ja, wie bekomme ich das Ding nun an meinem RPI2 mit FHEM zum Rennen?
Danke schonmal für Eure intensive Unterstützung!
Das sieht schon mal gut aus. Kommt da noch mehr, wenn Du einfach eine Zweit lang abwartest?
Irgend etwas das mit "OK 9" beginnt?
Ja kommt
Dann ist der Stick OK und auch korrekt geflasht.
An Deiner FHEM-Installation tippe ich am ehesten drauf, dass irgend etwas weiteres den Port verwendet.
Kann ich das irgendwie testen?
Zitat von: Gunther am 24 Januar 2016, 21:55:08
Kann ich das irgendwie testen?
setzte mal folgenden Befehl ab:
fuser <Device-File>
z.B.:
fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A5047YDG-if00-port0
Der Output sieht dann so aus:
/dev/ttyUSB1: 31088
wobei 31088 die ProzessID des Prozesses ist der das Device nutzt.
mit
ps ax | grep 31088
bekommst du dann den Prozess im Klarnamen raus
Bei mir sieht das z.B. so aus
root@fhem:/opt/fhem# ps ax | grep 31088
4975 pts/0 S+ 0:00 grep 31088
31088 ? S 31:42 perl fhem.pl fhem.cfg
das kommt dann
pi@raspberrypi ~ $ fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0
/dev/ttyUSB1: 6499
pi@raspberrypi ~ $ ps ax | grep 6499
6499 ? R 426:48 /usr/bin/perl fhem.pl fhem.cfg
10206 pts/0 R+ 0:00 grep --color=auto 6499
pi@raspberrypi ~ $
Zitat von: Gunther am 24 Januar 2016, 22:16:22
das kommt dann
pi@raspberrypi ~ $ fuser /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01MZ4B-if00-port0
/dev/ttyUSB1: 6499
pi@raspberrypi ~ $ ps ax | grep 6499
6499 ? R 426:48 /usr/bin/perl fhem.pl fhem.cfg
10206 pts/0 R+ 0:00 grep --color=auto 6499
pi@raspberrypi ~ $
Und was schliest du daraus ?
Dass Prozess 10206 auf dem gleichen Port läuft? ::)
Wenn ich mir den anschaue und den nächsten und den nächsten...
pi@raspberrypi ~ $ ps ax | grep 10206
11596 pts/0 S+ 0:00 grep --color=auto 10206
pi@raspberrypi ~ $ ps ax | grep 11596
11598 pts/0 S+ 0:00 grep --color=auto 11596
pi@raspberrypi ~ $ ps ax | grep 11598
11600 pts/0 R+ 0:00 grep --color=auto 11598
pi@raspberrypi ~ $
Ich glaube ich stehe auf dem Schlauch und brauche nochmal einen "Stups"...
Zitat von: Gunther am 25 Januar 2016, 22:03:48
pi@raspberrypi ~ $ ps ax | grep 10206
11596 pts/0 S+ 0:00 grep --color=auto 10206
pi@raspberrypi ~ $ ps ax | grep 11596
11598 pts/0 S+ 0:00 grep --color=auto 11596
pi@raspberrypi ~ $ ps ax | grep 11598
11600 pts/0 R+ 0:00 grep --color=auto 11598
pi@raspberrypi ~ $
Du merkst nicht das du deinen eigenen Prozess (grep) verfolgst ?
Interessant ist doch diese Zeile:
6499 ? R 426:48 /usr/bin/perl fhem.pl fhem.cfgVersteh mich nicht falsch ... aber
Schaffe dir erst einmal die Linux/Unix Grundkenntnisse drauf bevor du dir FHEM auf Linux gönnst.
Als Einstieg mal folgende URLs
http://ryanstutorials.net/linuxtutorial/ (http://ryanstutorials.net/linuxtutorial/)
http://ryanstutorials.net/linuxtutorial/processes.php (http://ryanstutorials.net/linuxtutorial/processes.php)
http://www.tldp.org/LDP/Bash-Beginners-Guide/html/ (http://www.tldp.org/LDP/Bash-Beginners-Guide/html/)
Es gibt noch bessere die habe ich aber auf die Schnelle nicht gefunden.
EDIT:
Habs noch gefunden
http://www.selflinux.org/selflinux/ (http://www.selflinux.org/selflinux/)
http://www.selflinux.org/selflinux/html/prozessverwaltung.html (http://www.selflinux.org/selflinux/html/prozessverwaltung.html)
Such mal in der fhem.cfg nach /dev/ttyUSB1 ob da noch ein weiteres device definiert ist, das diesen Port verwendet.
Irgend ein log von Dir weiter oben hat schon so ausgesehen, als ob da noch was reingekrätscht hätte.
Wenn möglich so hänge doch mal deine Config hier als Anhang dran.
Dann können wir uns die ansehen.
(Vorher bitte die Passwörter XXXen )
So bröckchenweise wird das nix.
den
1) Der Jeelink scheint ja richtig geflasht zu sein
2) Ein zweiter Prozess schein nicht das Device zu nutzen
bleibt nur noch:
a) falsche Rechte der DeviceNode
b) Fehler in der FHEM-Config
zu a)
mache bitte mal ein : ls -la /dev/ttyUSB* und poste den Output
also:
Ich kann den Jeelink nun nutzen. Habe das Device mit der USB1 (OWL Strommonitor) umgehägt. (Kämpfe gerade das Ding zu Laufen zu bekommen.)
bei einem dmesg sieht es etwas komisch aus. Ist das normal?
[code]
[234522.359472] ftdi_sio ttyUSB1: urb failed to clear flow control
[234522.365108] ftdi_sio ttyUSB1: urb failed to clear flow control
[234569.235604] ftdi_sio ttyUSB1: urb failed to clear flow control
[234590.172778] ftdi_sio ttyUSB1: urb failed to clear flow control
[234624.670489] ftdi_sio ttyUSB1: urb failed to clear flow control
[234650.431945] ftdi_sio ttyUSB1: urb failed to clear flow control
[234659.115457] ftdi_sio ttyUSB1: urb failed to clear flow control
[234663.091147] ftdi_sio ttyUSB1: urb failed to clear flow control
[234765.448869] ftdi_sio ttyUSB1: urb failed to clear flow control
[234769.433960] ftdi_sio ttyUSB1: urb failed to clear flow control
[234769.435527] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[234782.522665] ftdi_sio ttyUSB1: urb failed to clear flow control
[234833.715729] ftdi_sio ttyUSB1: urb failed to clear flow control
[234842.694558] ftdi_sio ttyUSB1: urb failed to clear flow control
[234850.953150] ftdi_sio ttyUSB1: urb failed to clear flow control
[234893.437683] ftdi_sio ttyUSB1: urb failed to clear flow control
[234893.443434] ftdi_sio ttyUSB1: urb failed to clear flow control
[234911.429122] ftdi_sio ttyUSB1: urb failed to clear flow control
[234936.101389] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235089.958010] ftdi_sio ttyUSB1: urb failed to clear flow control
[235102.012147] ftdi_sio ttyUSB1: urb failed to clear flow control
[235102.013732] ftdi_sio ttyUSB1: urb failed to clear flow control
[235209.151412] ftdi_sio ttyUSB1: urb failed to clear flow control
[235222.469075] ftdi_sio ttyUSB1: urb failed to clear flow control
[235251.792273] ftdi_sio ttyUSB1: urb failed to clear flow control
[235251.799457] ftdi_sio ttyUSB1: urb failed to clear flow control
[235264.976099] ftdi_sio ttyUSB1: urb failed to clear flow control
[235265.023145] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[235265.024839] ftdi_sio ttyUSB1: urb failed to clear flow control
[235269.087768] ftdi_sio ttyUSB1: urb failed to clear flow control
[235272.917661] ftdi_sio ttyUSB1: urb failed to clear flow control
[235272.920392] ftdi_sio ttyUSB1: urb failed to clear flow control
[235371.274277] ftdi_sio ttyUSB1: urb failed to clear flow control
[235375.260669] ftdi_sio ttyUSB1: urb failed to clear flow control
[235380.202097] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[235380.209329] ftdi_sio ttyUSB1: urb failed to clear flow control
[235396.821180] ftdi_sio ttyUSB1: urb failed to clear flow control
[235396.823668] ftdi_sio ttyUSB1: urb failed to clear flow control
[235396.829664] ftdi_sio ttyUSB1: urb failed to clear flow control
[235400.647801] ftdi_sio ttyUSB1: urb failed to clear flow control
[235400.652178] ftdi_sio ttyUSB1: urb failed to clear flow control
[235400.654942] ftdi_sio ttyUSB1: urb failed to clear flow control
[235439.797989] ftdi_sio ttyUSB1: urb failed to clear flow control
[235448.138307] ftdi_sio ttyUSB1: urb failed to clear flow control
[235456.540774] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[235520.161393] ftdi_sio ttyUSB1: urb failed to clear flow control
[235541.758756] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235588.317868] ftdi_sio ttyUSB1: urb failed to clear flow control
[235601.715240] ftdi_sio ttyUSB1: urb failed to clear flow control
[235652.923097] ftdi_sio ttyUSB1: urb failed to clear flow control
[235661.196254] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235670.389011] ftdi_sio ttyUSB1: urb failed to clear flow control
[235674.171275] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235674.214653] ftdi_sio ttyUSB1: urb failed to clear flow control
[235674.215887] ftdi_sio ttyUSB1: urb failed to clear flow control
[235678.747014] ftdi_sio ttyUSB1: urb failed to clear flow control
[235720.915131] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235733.323043] ftdi_sio ttyUSB1: urb failed to clear flow control
[235733.330190] ftdi_sio ttyUSB1: urb failed to clear flow control
[235755.089447] ftdi_sio ttyUSB1: urb failed to clear flow control
[235780.634349] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235785.147691] ftdi_sio ttyUSB1: urb failed to clear flow control
[235797.934081] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235798.128671] ftdi_sio ttyUSB1: urb failed to clear flow control
[235798.131530] ftdi_sio ttyUSB1: urb failed to clear flow control
[235806.846980] ftdi_sio ttyUSB1: urb failed to clear flow control
[235823.356070] ftdi_sio ttyUSB1: urb failed to clear flow control
[235827.762751] ftdi_sio ttyUSB1: urb failed to clear flow control
[235844.678552] ftdi_sio ttyUSB1: urb failed to clear flow control
[235921.918464] ftdi_sio ttyUSB1: urb failed to clear flow control
[235934.198576] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[235934.293071] ftdi_sio ttyUSB1: urb failed to clear flow control
[235981.317343] ftdi_sio ttyUSB1: urb failed to clear flow control
[236083.552355] ftdi_sio ttyUSB1: urb failed to clear flow control
[236092.127026] ftdi_sio ttyUSB1: urb failed to clear flow control
[236100.608635] ftdi_sio ttyUSB1: urb failed to clear flow control
[236104.945206] ftdi_sio ttyUSB1: urb failed to clear flow control
[236177.756675] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[236202.991318] ftdi_sio ttyUSB1: urb failed to clear flow control
[236215.748229] ftdi_sio ttyUSB1: urb failed to clear flow control
[236215.750854] ftdi_sio ttyUSB1: urb failed to clear flow control
[236241.143242] ftdi_sio ttyUSB1: urb failed to clear flow control
[236262.703907] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[236262.714101] ftdi_sio ttyUSB1: urb failed to clear flow control
[236266.882784] ftdi_sio ttyUSB1: urb failed to clear flow control
[236279.754774] ftdi_sio ttyUSB1: urb failed to clear flow control
[236289.855359] ftdi_sio ttyUSB1: urb failed to clear flow control
[236289.860971] ftdi_sio ttyUSB1: urb failed to clear flow control
[236305.358785] ftdi_sio ttyUSB1: urb failed to clear flow control
[236322.374600] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[236399.183390] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[236399.228064] ftdi_sio ttyUSB1: urb failed to clear flow control
[236399.235355] ftdi_sio ttyUSB1: urb failed to clear flow control
[236416.218744] ftdi_sio ttyUSB1: urb failed to clear flow control
[236420.706448] ftdi_sio ttyUSB1: urb failed to clear flow control
[236420.709313] ftdi_sio ttyUSB1: urb failed to clear flow control
[236433.390241] ftdi_sio ttyUSB1: urb failed to clear flow control
[236476.154493] ftdi_sio ttyUSB1: urb failed to clear flow control
[236493.001220] ftdi_sio ttyUSB1: urb failed to clear flow control
[236510.176195] ftdi_sio ttyUSB1: urb failed to clear flow control
[236510.179089] ftdi_sio ttyUSB1: urb failed to clear flow control
[236527.292221] ftdi_sio ttyUSB1: urb failed to clear flow control
[236527.293573] ftdi_sio ttyUSB1: urb failed to clear flow control
[236527.294938] ftdi_sio ttyUSB1: urb failed to clear flow control
[236565.561857] ftdi_sio ttyUSB1: urb failed to clear flow control
[236569.829944] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[236608.316318] ftdi_sio ttyUSB1: urb failed to clear flow control
[236638.110295] ftdi_sio ttyUSB1: urb failed to clear flow control
[236668.461955] ftdi_sio ttyUSB1: urb failed to clear flow control
[236680.732955] ftdi_sio ttyUSB1: urb failed to clear flow control
[236701.584628] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[236715.209856] ftdi_sio ttyUSB1: urb failed to clear flow control
[236715.211443] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[236727.846366] ftdi_sio ttyUSB1: urb failed to clear flow control
[236727.857499] ftdi_sio ttyUSB1: urb failed to clear flow control
[236731.969980] ftdi_sio ttyUSB1: urb failed to clear flow control
[236731.971785] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[236745.564521] ftdi_sio ttyUSB1: urb failed to clear flow control
[236821.496583] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[236885.481775] ftdi_sio ttyUSB1: urb failed to clear flow control
[236889.263392] ftdi_sio ttyUSB1: urb failed to clear flow control
[236936.629326] ftdi_sio ttyUSB1: urb failed to clear flow control
[236945.161224] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[236970.799275] ftdi_sio ttyUSB1: urb failed to clear flow control
[236983.171164] ftdi_sio ttyUSB1: urb failed to clear flow control
[236983.234054] ftdi_sio ttyUSB1: urb failed to clear flow control
[236991.827937] ftdi_sio ttyUSB1: urb failed to clear flow control
[237021.984706] ftdi_sio ttyUSB1: urb failed to clear flow control
[237098.876246] ftdi_sio ttyUSB1: urb failed to clear flow control
[237159.800250] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237159.804825] ftdi_sio ttyUSB1: urb failed to clear flow control
[237170.988253] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237170.994316] ftdi_sio ttyUSB1: urb failed to clear flow control
[237210.645236] ftdi_sio ttyUSB1: urb failed to clear flow control
[237218.267420] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237243.803467] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237320.581040] ftdi_sio ttyUSB1: urb failed to clear flow control
[237320.585169] ftdi_sio ttyUSB1: urb failed to clear flow control
[237333.398495] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237333.401219] ftdi_sio ttyUSB1: urb failed to clear flow control
[237376.104197] ftdi_sio ttyUSB1: urb failed to clear flow control
[237384.577928] ftdi_sio ttyUSB1: urb failed to clear flow control
[237384.579162] ftdi_sio ttyUSB1: urb failed to clear flow control
[237388.877537] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237418.710118] ftdi_sio ttyUSB1: urb failed to clear flow control
[237418.711461] ftdi_sio ttyUSB1: urb failed to clear flow control
[237418.712835] ftdi_sio ttyUSB1: urb failed to clear flow control
[237435.710869] ftdi_sio ttyUSB1: urb failed to clear flow control
[237478.473218] ftdi_sio ttyUSB1: urb failed to clear flow control
[237495.786129] ftdi_sio ttyUSB1: urb failed to clear flow control
[237495.788987] ftdi_sio ttyUSB1: urb failed to clear flow control
[237508.301933] ftdi_sio ttyUSB1: urb failed to clear flow control
[237525.291065] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[237529.722932] ftdi_sio ttyUSB1: urb failed to clear flow control
[237559.427241] ftdi_sio ttyUSB1: urb failed to clear flow control
[237559.430005] ftdi_sio ttyUSB1: urb failed to clear flow control
[237563.862334] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237573.408857] ftdi_sio ttyUSB1: urb failed to clear flow control
[237632.833647] ftdi_sio ttyUSB1: urb failed to clear flow control
[237632.837679] ftdi_sio ttyUSB1: urb failed to clear flow control
[237696.930068] ftdi_sio ttyUSB1: urb failed to clear flow control
[237725.775544] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[237734.382584] ftdi_sio ttyUSB1: urb failed to clear flow control
[237777.015372] ftdi_sio ttyUSB1: urb failed to clear flow control
[237777.055270] ftdi_sio ttyUSB1: urb failed to clear flow control
[237802.191984] ftdi_sio ttyUSB1: urb failed to clear flow control
[237802.195080] ftdi_sio ttyUSB1: urb failed to clear flow control
[237841.074656] ftdi_sio ttyUSB1: urb failed to clear flow control
[237849.570957] ftdi_sio ttyUSB1: urb failed to clear flow control
[237858.055319] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237858.060934] ftdi_sio ttyUSB1: urb failed to clear flow control
[237867.075411] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[237930.566710] ftdi_sio ttyUSB1: urb failed to clear flow control
[237930.573485] ftdi_sio ttyUSB1: urb failed to clear flow control
[237964.787814] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[237964.825405] ftdi_sio ttyUSB1: urb failed to clear flow control
[238020.920127] ftdi_sio ttyUSB1: urb failed to clear flow control
[238032.954999] ftdi_sio ttyUSB1: urb failed to clear flow control
[238114.003671] ftdi_sio ttyUSB1: urb failed to clear flow control
[238152.159761] ftdi_sio ttyUSB1: urb failed to clear flow control
[238152.209761] ftdi_sio ttyUSB1: urb failed to clear flow control
[238182.300903] ftdi_sio ttyUSB1: urb failed to clear flow control
[238190.800945] ftdi_sio ttyUSB1: urb failed to clear flow control
[238250.634406] ftdi_sio ttyUSB1: urb failed to clear flow control
[238250.637269] ftdi_sio ttyUSB1: urb failed to clear flow control
[238310.727043] ftdi_sio ttyUSB1: urb failed to clear flow control
[238336.967143] ftdi_sio ttyUSB1: urb failed to clear flow control
[238336.968408] ftdi_sio ttyUSB1: urb failed to clear flow control
[238345.320882] ftdi_sio ttyUSB1: urb failed to clear flow control
[238374.449774] ftdi_sio ttyUSB1: urb failed to clear flow control
[238388.131357] ftdi_sio ttyUSB1: urb failed to clear flow control
[238421.621303] ftdi_sio ttyUSB1: urb failed to clear flow control
[238421.629605] ftdi_sio ttyUSB1: urb failed to clear flow control
[238446.852051] ftdi_sio ttyUSB1: urb failed to clear flow control
[238489.417501] ftdi_sio ttyUSB1: urb failed to clear flow control
[238523.513021] ftdi_sio ttyUSB1: urb failed to clear flow control
[238527.466801] ftdi_sio ttyUSB1: urb failed to clear flow control
[238527.468273] ftdi_sio ttyUSB1: urb failed to clear flow control
[238527.469526] ftdi_sio ttyUSB1: urb failed to clear flow control
[238532.032060] ftdi_sio ttyUSB1: urb failed to clear flow control
[238544.881239] ftdi_sio ttyUSB1: urb failed to clear flow control
[238557.325790] ftdi_sio ttyUSB1: urb failed to clear flow control
[238604.711016] ftdi_sio ttyUSB1: urb failed to clear flow control
[238608.531493] ftdi_sio ttyUSB1: urb failed to clear flow control
[238613.230515] ftdi_sio ttyUSB1: urb failed to clear flow control
[238613.236622] ftdi_sio ttyUSB1: urb failed to clear flow control
[238617.201514] ftdi_sio ttyUSB1: urb failed to clear flow control
[238673.409635] ftdi_sio ttyUSB1: urb failed to clear flow control
[238681.131561] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[238707.007493] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[238707.187752] ftdi_sio ttyUSB1: urb failed to clear flow control
[238707.190389] ftdi_sio ttyUSB1: urb failed to clear flow control
[238723.759473] ftdi_sio ttyUSB1: urb failed to clear flow control
[238723.763826] ftdi_sio ttyUSB1: urb failed to clear flow control
[238754.257836] ftdi_sio ttyUSB1: urb failed to clear flow control
[238754.259648] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[238754.262179] ftdi_sio ttyUSB1: urb failed to clear flow control
[238822.088918] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[238822.094929] ftdi_sio ttyUSB1: urb failed to clear flow control
[238826.316638] ftdi_sio ttyUSB1: urb failed to clear flow control
[238869.151492] ftdi_sio ttyUSB1: urb failed to clear flow control
[238873.339566] ftdi_sio ttyUSB1: urb failed to clear flow control
[238890.542693] ftdi_sio ttyUSB1: urb failed to clear flow control
[238895.095678] ftdi_sio ttyUSB1: urb failed to clear flow control
[238911.343274] ftdi_sio ttyUSB1: urb failed to clear flow control
[238911.344737] ftdi_sio ttyUSB1: urb failed to clear flow control
[238975.663675] ftdi_sio ttyUSB1: urb failed to clear flow control
[238975.669848] ftdi_sio ttyUSB1: urb failed to clear flow control
[238979.488207] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[239020.542822] ftdi_sio ttyUSB1: urb failed to clear flow control
[239171.929458] ftdi_sio ttyUSB1: urb failed to clear flow control
[239209.983038] ftdi_sio ttyUSB1: urb failed to clear flow control
[239240.128174] ftdi_sio ttyUSB1: urb failed to clear flow control
[239240.132548] ftdi_sio ttyUSB1: urb failed to clear flow control
[239248.669698] ftdi_sio ttyUSB1: urb failed to clear flow control
[239257.189202] ftdi_sio ttyUSB1: urb failed to clear flow control
[239265.720637] ftdi_sio ttyUSB1: urb failed to clear flow control
[239265.725113] ftdi_sio ttyUSB1: urb failed to clear flow control
[239283.301323] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[239321.206611] ftdi_sio ttyUSB1: urb failed to clear flow control
[239321.217755] ftdi_sio ttyUSB1: urb failed to clear flow control
[239330.696909] ftdi_sio ttyUSB1: urb failed to clear flow control
[239402.218664] ftdi_sio ttyUSB1: urb failed to clear flow control
[239402.225683] ftdi_sio ttyUSB1: urb failed to clear flow control
[239465.756014] ftdi_sio ttyUSB1: urb failed to clear flow control
[239465.938795] ftdi_sio ttyUSB1: urb failed to clear flow control
[239465.943515] ftdi_sio ttyUSB1: urb failed to clear flow control
[239517.061243] ftdi_sio ttyUSB1: urb failed to clear flow control
[239517.066992] ftdi_sio ttyUSB1: urb failed to clear flow control
[239530.481509] ftdi_sio ttyUSB1: urb failed to clear flow control
[239530.485420] ftdi_sio ttyUSB1: urb failed to clear flow control
[239530.489891] ftdi_sio ttyUSB1: urb failed to clear flow control
[239560.657915] ftdi_sio ttyUSB1: urb failed to clear flow control
[239560.658940] ftdi_sio ttyUSB1: urb failed to clear flow control
[239560.660533] ftdi_sio ttyUSB1: urb failed to clear flow control
[239628.051399] ftdi_sio ttyUSB1: urb failed to clear flow control
[239632.722146] ftdi_sio ttyUSB1: urb failed to clear flow control
[239666.887947] ftdi_sio ttyUSB1: urb failed to clear flow control
[239666.890577] ftdi_sio ttyUSB1: urb failed to clear flow control
[239666.899193] ftdi_sio ttyUSB1: urb failed to clear flow control
[239683.792571] ftdi_sio ttyUSB1: urb failed to clear flow control
[239683.795094] ftdi_sio ttyUSB1: urb failed to clear flow control
[239696.343413] ftdi_sio ttyUSB1: urb failed to clear flow control
[239704.998036] ftdi_sio ttyUSB1: urb failed to clear flow control
[239705.002412] ftdi_sio ttyUSB1: urb failed to clear flow control
[239726.370390] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[239730.309794] ftdi_sio ttyUSB1: urb failed to clear flow control
[239773.299134] ftdi_sio ttyUSB1: urb failed to clear flow control
[239786.089832] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[239786.181482] ftdi_sio ttyUSB1: urb failed to clear flow control
[239786.185628] ftdi_sio ttyUSB1: urb failed to clear flow control
[239786.190100] ftdi_sio ttyUSB1: urb failed to clear flow control
[239790.001376] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[239790.006947] ftdi_sio ttyUSB1: urb failed to clear flow control
[239790.010114] ftdi_sio ttyUSB1: urb failed to clear flow control
[239790.012968] ftdi_sio ttyUSB1: urb failed to clear flow control
[239811.934785] ftdi_sio ttyUSB1: urb failed to clear flow control
[239854.389343] ftdi_sio ttyUSB1: urb failed to clear flow control
[239884.053161] ftdi_sio ttyUSB1: urb failed to clear flow control
[239884.055785] ftdi_sio ttyUSB1: urb failed to clear flow control
[239931.122417] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[239931.943063] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[239931.945900] ftdi_sio ttyUSB1: urb failed to clear flow control
[239935.769443] ftdi_sio ttyUSB1: urb failed to clear flow control
[240011.849916] ftdi_sio ttyUSB1: urb failed to clear flow control
[240011.852762] ftdi_sio ttyUSB1: urb failed to clear flow control
[240025.158124] ftdi_sio ttyUSB1: urb failed to clear flow control
[240025.168581] ftdi_sio ttyUSB1: urb failed to clear flow control
[240174.368653] ftdi_sio ttyUSB1: urb failed to clear flow control
[240174.371011] ftdi_sio ttyUSB1: urb failed to clear flow control
[240187.112074] ftdi_sio ttyUSB1: urb failed to clear flow control
[240187.115036] ftdi_sio ttyUSB1: urb failed to clear flow control
[240336.510850] ftdi_sio ttyUSB1: urb failed to clear flow control
[240340.498259] ftdi_sio ttyUSB1: urb failed to clear flow control
[240340.502537] ftdi_sio ttyUSB1: urb failed to clear flow control
[240353.482381] ftdi_sio ttyUSB1: urb failed to clear flow control
[240353.489503] ftdi_sio ttyUSB1: urb failed to clear flow control
[240366.601788] ftdi_sio ttyUSB1: urb failed to clear flow control
[240366.603602] ftdi_sio ttyUSB1: urb failed to clear flow control
[240366.604858] ftdi_sio ttyUSB1: urb failed to clear flow control
[240366.607627] ftdi_sio ttyUSB1: urb failed to clear flow control
[240370.549431] ftdi_sio ttyUSB1: urb failed to clear flow control
[240400.198493] ftdi_sio ttyUSB1: urb failed to clear flow control
[240404.656728] ftdi_sio ttyUSB1: urb failed to clear flow control
[240404.661170] ftdi_sio ttyUSB1: urb failed to clear flow control
[240481.494550] ftdi_sio ttyUSB1: urb failed to clear flow control
[240481.495785] ftdi_sio ttyUSB1: urb failed to clear flow control
[240481.497529] ftdi_sio ttyUSB1: urb failed to clear flow control
[240499.000280] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[240499.006126] ftdi_sio ttyUSB1: urb failed to clear flow control
[240515.719875] ftdi_sio ttyUSB1: urb failed to clear flow control
[240523.659561] ftdi_sio ttyUSB1: urb failed to clear flow control
[240523.664523] ftdi_sio ttyUSB1: urb failed to clear flow control
[240527.965125] ftdi_sio ttyUSB1: urb failed to clear flow control
[240626.538435] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[240639.221588] ftdi_sio ttyUSB1: urb failed to clear flow control
[240673.348015] ftdi_sio ttyUSB1: urb failed to clear flow control
[240673.402152] ftdi_sio ttyUSB1: urb failed to clear flow control
[240673.406650] ftdi_sio ttyUSB1: urb failed to clear flow control
[240733.006226] ftdi_sio ttyUSB1: urb failed to clear flow control
[240733.013574] ftdi_sio ttyUSB1: urb failed to clear flow control
[240737.332410] ftdi_sio ttyUSB1: urb failed to clear flow control
[240737.583848] ftdi_sio ttyUSB1: urb failed to clear flow control
[240756.843020] ftdi_sio ttyUSB1: urb failed to clear flow control
[240757.086090] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[240797.114506] ftdi_sio ttyUSB1: urb failed to clear flow control
[240805.582137] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[240827.219856] ftdi_sio ttyUSB1: urb failed to clear flow control
[240827.221622] ftdi_sio ttyUSB1: urb failed to clear flow control
[240831.276433] ftdi_sio ttyUSB1: urb failed to clear flow control
[240844.152565] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[240848.434482] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[240848.435516] ftdi_sio ttyUSB1: urb failed to clear flow control
[240848.440100] ftdi_sio ttyUSB1: urb failed to clear flow control
[240873.678457] ftdi_sio ttyUSB1: urb failed to clear flow control
[240882.438645] ftdi_sio ttyUSB1: urb failed to clear flow control
[240955.213329] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[240955.218392] ftdi_sio ttyUSB1: urb failed to clear flow control
[240967.291306] ftdi_sio ttyUSB1: urb failed to clear flow control
[240967.300060] ftdi_sio ttyUSB1: urb failed to clear flow control
[240967.302712] ftdi_sio ttyUSB1: urb failed to clear flow control
[240980.985775] ftdi_sio ttyUSB1: urb failed to clear flow control
[240985.123028] ftdi_sio ttyUSB1: urb failed to clear flow control
[240993.747101] ftdi_sio ttyUSB1: urb failed to clear flow control
[241001.802306] ftdi_sio ttyUSB1: urb failed to clear flow control
[241002.055602] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[241010.837222] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[241010.843365] ftdi_sio ttyUSB1: urb failed to clear flow control
[241014.950547] ftdi_sio ttyUSB1: urb failed to clear flow control
[241023.188554] ftdi_sio ttyUSB1: urb failed to clear flow control
[241031.791309] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[241048.762330] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[241048.765162] ftdi_sio ttyUSB1: urb failed to clear flow control
[241048.770946] ftdi_sio ttyUSB1: urb failed to clear flow control
[241087.082539] ftdi_sio ttyUSB1: urb failed to clear flow control
[241087.085188] ftdi_sio ttyUSB1: urb failed to clear flow control
[241087.090910] ftdi_sio ttyUSB1: urb failed to clear flow control
[241099.979230] ftdi_sio ttyUSB1: urb failed to clear flow control
[241130.865375] ftdi_sio ttyUSB1: urb failed to clear flow control
[241172.539798] ftdi_sio ttyUSB1: urb failed to clear flow control
[241189.640086] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[241189.821863] ftdi_sio ttyUSB1: urb failed to clear flow control
[241189.825999] ftdi_sio ttyUSB1: urb failed to clear flow control
[241193.914654] ftdi_sio ttyUSB1: urb failed to clear flow control
[241193.924785] ftdi_sio ttyUSB1: urb failed to clear flow control
[241206.661100] ftdi_sio ttyUSB1: urb failed to clear flow control
[241228.094984] ftdi_sio ttyUSB1: urb failed to clear flow control
[241240.396226] ftdi_sio ttyUSB1: urb failed to clear flow control
[241240.401838] ftdi_sio ttyUSB1: urb failed to clear flow control
[241279.069789] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[241351.895839] ftdi_sio ttyUSB1: urb failed to clear flow control
[241351.898486] ftdi_sio ttyUSB1: urb failed to clear flow control
[241368.693843] ftdi_sio ttyUSB1: urb failed to clear flow control
[241368.702697] ftdi_sio ttyUSB1: urb failed to clear flow control
[241390.176946] ftdi_sio ttyUSB1: urb failed to clear flow control
[241415.613082] ftdi_sio ttyUSB1: urb failed to clear flow control
[241415.615823] ftdi_sio ttyUSB1: urb failed to clear flow control
[241415.618601] ftdi_sio ttyUSB1: urb failed to clear flow control
[241436.988308] ftdi_sio ttyUSB1: urb failed to clear flow control
[241436.992931] ftdi_sio ttyUSB1: urb failed to clear flow control
[241445.921156] ftdi_sio ttyUSB1: urb failed to clear flow control
[241445.926501] ftdi_sio ttyUSB1: urb failed to clear flow control
[241454.143222] ftdi_sio ttyUSB1: urb failed to clear flow control
[241454.150122] ftdi_sio ttyUSB1: urb failed to clear flow control
[241454.151605] ftdi_sio ttyUSB1: urb failed to clear flow control
[241505.188081] ftdi_sio ttyUSB1: urb failed to clear flow control
[241505.192758] ftdi_sio ttyUSB1: urb failed to clear flow control
[241543.579904] ftdi_sio ttyUSB1: urb failed to clear flow control
[241543.587050] ftdi_sio ttyUSB1: urb failed to clear flow control
[241543.588764] ftdi_sio ttyUSB1: urb failed to clear flow control
[241543.589802] ftdi_sio ttyUSB1: urb failed to clear flow control
[241560.604284] ftdi_sio ttyUSB1: urb failed to clear flow control
[241560.644290] ftdi_sio ttyUSB1: urb failed to clear flow control
[241586.198823] ftdi_sio ttyUSB1: urb failed to clear flow control
[241586.296219] ftdi_sio ttyUSB1: urb failed to clear flow control
[241612.408830] ftdi_sio ttyUSB1: urb failed to clear flow control
[241612.409974] ftdi_sio ttyUSB1: urb failed to clear flow control
[241620.538295] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[241620.548171] ftdi_sio ttyUSB1: urb failed to clear flow control
[241624.561986] ftdi_sio ttyUSB1: urb failed to clear flow control
[241628.901775] ftdi_sio ttyUSB1: urb failed to clear flow control
[241628.911313] ftdi_sio ttyUSB1: urb failed to clear flow control
[241663.034240] ftdi_sio ttyUSB1: urb failed to clear flow control
[241671.589705] ftdi_sio ttyUSB1: urb failed to clear flow control
[241688.704631] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[241714.604331] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[241731.230207] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[241783.092745] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[241783.094314] ftdi_sio ttyUSB1: urb failed to clear flow control
[241783.098451] ftdi_sio ttyUSB1: urb failed to clear flow control
[241799.527635] ftdi_sio ttyUSB1: urb failed to clear flow control
[241799.531685] ftdi_sio ttyUSB1: urb failed to clear flow control
[241842.176070] ftdi_sio ttyUSB1: urb failed to clear flow control
[241889.430930] ftdi_sio ttyUSB1: urb failed to clear flow control
[241897.275679] ftdi_sio ttyUSB1: urb failed to clear flow control
[241897.284083] ftdi_sio ttyUSB1: urb failed to clear flow control
[241897.287166] ftdi_sio ttyUSB1: urb failed to clear flow control
[241923.105501] ftdi_sio ttyUSB1: urb failed to clear flow control
[241927.657992] ftdi_sio ttyUSB1: urb failed to clear flow control
[241939.912858] ftdi_sio ttyUSB1: urb failed to clear flow control
[241944.807283] ftdi_sio ttyUSB1: urb failed to clear flow control
[241944.809903] ftdi_sio ttyUSB1: urb failed to clear flow control
[241944.815407] ftdi_sio ttyUSB1: urb failed to clear flow control
[241944.817444] ftdi_sio ttyUSB1: urb failed to clear flow control
[242088.185763] ftdi_sio ttyUSB1: urb failed to clear flow control
[242153.989742] ftdi_sio ttyUSB1: urb failed to clear flow control
[242166.501815] ftdi_sio ttyUSB1: urb failed to clear flow control
[242166.504471] ftdi_sio ttyUSB1: urb failed to clear flow control
[242192.000481] ftdi_sio ttyUSB1: urb failed to clear flow control
[242235.214105] ftdi_sio ttyUSB1: urb failed to clear flow control
[242303.363823] ftdi_sio ttyUSB1: urb failed to clear flow control
[242307.721416] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[242311.720565] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[242311.823699] ftdi_sio ttyUSB1: urb failed to clear flow control
[242315.654756] ftdi_sio ttyUSB1: urb failed to clear flow control
[242354.077594] ftdi_sio ttyUSB1: urb failed to clear flow control
[242358.362035] ftdi_sio ttyUSB1: urb failed to clear flow control
[242396.763520] ftdi_sio ttyUSB1: urb failed to clear flow control
[242421.977503] ftdi_sio ttyUSB1: urb failed to clear flow control
[242421.982049] ftdi_sio ttyUSB1: urb failed to clear flow control
[242430.897817] ftdi_sio ttyUSB1: urb failed to clear flow control
[242503.318604] ftdi_sio ttyUSB1: urb failed to clear flow control
[242537.667434] ftdi_sio ttyUSB1: urb failed to clear flow control
[242541.755099] ftdi_sio ttyUSB1: urb failed to clear flow control
[242546.071446] ftdi_sio ttyUSB1: urb failed to clear flow control
[242557.974634] ftdi_sio ttyUSB1: urb failed to clear flow control
[242557.977181] ftdi_sio ttyUSB1: urb failed to clear flow control
[242561.756949] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[242561.979840] ftdi_sio ttyUSB1: urb failed to clear flow control
[242607.541518] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[242627.027223] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[242661.191392] ftdi_sio ttyUSB1: urb failed to clear flow control
[242712.369752] ftdi_sio ttyUSB1: urb failed to clear flow control
[242780.620063] ftdi_sio ttyUSB1: urb failed to clear flow control
[242818.691140] ftdi_sio ttyUSB1: urb failed to clear flow control
[242818.693894] ftdi_sio ttyUSB1: urb failed to clear flow control
[242835.624666] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[242840.444414] ftdi_sio ttyUSB1: urb failed to clear flow control
[242840.448668] ftdi_sio ttyUSB1: urb failed to clear flow control
[242895.496538] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[242896.558663] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[242934.179102] ftdi_sio ttyUSB1: urb failed to clear flow control
[242976.421311] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[243045.092467] ftdi_sio ttyUSB1: urb failed to clear flow control
[243142.759112] ftdi_sio ttyUSB1: urb failed to clear flow control
[243142.838879] ftdi_sio ttyUSB1: urb failed to clear flow control
[243196.851069] ftdi_sio ttyUSB1: urb failed to clear flow control
[243207.214942] ftdi_sio ttyUSB1: urb failed to clear flow control
[243211.563026] ftdi_sio ttyUSB1: urb failed to clear flow control
[243211.564373] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[243211.565579] ftdi_sio ttyUSB1: urb failed to clear flow control
[243215.822473] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[243236.565473] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[243241.339260] ftdi_sio ttyUSB1: urb failed to clear flow control
[243330.437991] ftdi_sio ttyUSB1: urb failed to clear flow control
[243446.085556] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[243471.721584] ftdi_sio ttyUSB1: urb failed to clear flow control
[243497.324615] ftdi_sio ttyUSB1: urb failed to clear flow control
[243535.305867] ftdi_sio ttyUSB1: urb failed to clear flow control
[243591.515924] ftdi_sio ttyUSB1: urb failed to clear flow control
[243744.669528] ftdi_sio ttyUSB1: urb failed to clear flow control
[243778.792435] ftdi_sio ttyUSB1: urb failed to clear flow control
[243782.619182] ftdi_sio ttyUSB1: urb failed to clear flow control
[243788.328945] ftdi_sio ttyUSB1: urb failed to clear flow control
[243829.976727] ftdi_sio ttyUSB1: urb failed to clear flow control
[243829.977871] ftdi_sio ttyUSB1: urb failed to clear flow control
[243876.532176] ftdi_sio ttyUSB1: urb failed to clear flow control
[243876.533408] ftdi_sio ttyUSB1: urb failed to clear flow control
[243902.002902] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[244043.338289] ftdi_sio ttyUSB1: urb failed to clear flow control
[244064.171446] ftdi_sio ttyUSB1: urb failed to clear flow control
[244081.262511] ftdi_sio ttyUSB1: urb failed to clear flow control
[244163.719245] ftdi_sio ttyUSB1: urb failed to clear flow control
[244171.543629] ftdi_sio ttyUSB1: urb failed to clear flow control
[244171.544880] ftdi_sio ttyUSB1: urb failed to clear flow control
[244175.327264] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[244192.073548] ftdi_sio ttyUSB1: urb failed to clear flow control
[244192.218270] ftdi_sio ttyUSB1: urb failed to clear flow control
[244192.221157] ftdi_sio ttyUSB1: urb failed to clear flow control
[244205.818716] ftdi_sio ttyUSB1: urb failed to clear flow control
[244226.641614] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[244230.936795] ftdi_sio ttyUSB1: urb failed to clear flow control
[244230.945421] ftdi_sio ttyUSB1: urb failed to clear flow control
[244251.856337] ftdi_sio ttyUSB1: urb failed to clear flow control
[244285.952914] ftdi_sio ttyUSB1: urb failed to clear flow control
[244329.051525] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[244329.055654] ftdi_sio ttyUSB1: urb failed to clear flow control
[244346.226946] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[244350.383342] ftdi_sio ttyUSB1: urb failed to clear flow control
[244384.469776] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[244414.359616] ftdi_sio ttyUSB1: urb failed to clear flow control
[244414.363876] ftdi_sio ttyUSB1: urb failed to clear flow control
[244418.182394] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[244448.499437] ftdi_sio ttyUSB1: urb failed to clear flow control
[244465.768604] ftdi_sio ttyUSB1: urb failed to clear flow control
[244465.808734] ftdi_sio ttyUSB1: urb failed to clear flow control
[244465.811571] ftdi_sio ttyUSB1: urb failed to clear flow control
[244512.081373] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[244571.782106] ftdi_sio ttyUSB1: urb failed to clear flow control
[244576.519749] ftdi_sio ttyUSB1: urb failed to clear flow control
[244593.578278] ftdi_sio ttyUSB1: urb failed to clear flow control
[244593.579656] ftdi_sio ttyUSB1: urb failed to clear flow control
[244678.886018] ftdi_sio ttyUSB1: urb failed to clear flow control
[244687.365932] ftdi_sio ttyUSB1: urb failed to clear flow control
[244708.772872] ftdi_sio ttyUSB1: urb failed to clear flow control
[244734.300288] ftdi_sio ttyUSB1: urb failed to clear flow control
[244738.552725] ftdi_sio ttyUSB1: urb failed to clear flow control
[244747.077615] ftdi_sio ttyUSB1: urb failed to clear flow control
[244747.113729] ftdi_sio ttyUSB1: urb failed to clear flow control
[244772.700412] ftdi_sio ttyUSB1: urb failed to clear flow control
[244811.202286] ftdi_sio ttyUSB1: urb failed to clear flow control
[244815.334865] ftdi_sio ttyUSB1: urb failed to clear flow control
[244836.633719] ftdi_sio ttyUSB1: urb failed to clear flow control
[244870.756617] ftdi_sio ttyUSB1: urb failed to clear flow control
[244913.413414] ftdi_sio ttyUSB1: urb failed to clear flow control
[244922.008209] ftdi_sio ttyUSB1: urb failed to clear flow control
[244930.511308] ftdi_sio ttyUSB1: urb failed to clear flow control
[244930.512686] ftdi_sio ttyUSB1: urb failed to clear flow control
[244930.515548] ftdi_sio ttyUSB1: urb failed to clear flow control
[244985.933463] ftdi_sio ttyUSB1: urb failed to clear flow control
[244985.963452] ftdi_sio ttyUSB1: urb failed to clear flow control
[244985.967829] ftdi_sio ttyUSB1: urb failed to clear flow control
[244985.970482] ftdi_sio ttyUSB1: urb failed to clear flow control
[245003.193658] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[245058.489761] ftdi_sio ttyUSB1: urb failed to clear flow control
[245075.542890] ftdi_sio ttyUSB1: urb failed to clear flow control
[245118.164203] ftdi_sio ttyUSB1: urb failed to clear flow control
[245156.174434] ftdi_sio ttyUSB1: urb failed to clear flow control
[245182.210026] ftdi_sio ttyUSB1: urb failed to clear flow control
[245217.261551] ftdi_sio ttyUSB1: urb failed to clear flow control
[245217.267056] ftdi_sio ttyUSB1: urb failed to clear flow control
[245241.929827] ftdi_sio ttyUSB1: urb failed to clear flow control
[245254.257142] ftdi_sio ttyUSB1: urb failed to clear flow control
[245297.356591] ftdi_sio ttyUSB1: urb failed to clear flow control
[245301.735711] ftdi_sio ttyUSB1: urb failed to clear flow control
[245348.092370] ftdi_sio ttyUSB1: urb failed to clear flow control
[245369.923434] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[245369.926264] ftdi_sio ttyUSB1: urb failed to clear flow control
[245369.929015] ftdi_sio ttyUSB1: urb failed to clear flow control
[245395.469679] ftdi_sio ttyUSB1: urb failed to clear flow control
[245395.471170] ftdi_sio ttyUSB1: urb failed to clear flow control
[245433.858658] ftdi_sio ttyUSB1: urb failed to clear flow control
[245433.867168] ftdi_sio ttyUSB1: urb failed to clear flow control
[245476.587414] ftdi_sio ttyUSB1: urb failed to clear flow control
[245510.642294] ftdi_sio ttyUSB1: urb failed to clear flow control
[245604.486780] ftdi_sio ttyUSB1: urb failed to clear flow control
[245604.489568] ftdi_sio ttyUSB1: urb failed to clear flow control
[245664.167864] ftdi_sio ttyUSB1: urb failed to clear flow control
[245664.197996] ftdi_sio ttyUSB1: urb failed to clear flow control
[245702.655279] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[245702.657870] ftdi_sio ttyUSB1: urb failed to clear flow control
[245715.440513] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[245715.446575] ftdi_sio ttyUSB1: urb failed to clear flow control
[245715.447833] ftdi_sio ttyUSB1: urb failed to clear flow control
[245715.452316] ftdi_sio ttyUSB1: urb failed to clear flow control
[245762.306349] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[245796.471820] ftdi_sio ttyUSB1: urb failed to clear flow control
[245796.477879] ftdi_sio ttyUSB1: urb failed to clear flow control
[245877.483917] ftdi_sio ttyUSB1: urb failed to clear flow control
[245903.224393] ftdi_sio ttyUSB1: urb failed to clear flow control
[245928.888183] ftdi_sio ttyUSB1: urb failed to clear flow control
[245962.958953] ftdi_sio ttyUSB1: urb failed to clear flow control
[245975.710674] ftdi_sio ttyUSB1: urb failed to clear flow control
[246043.907891] ftdi_sio ttyUSB1: urb failed to clear flow control
[246067.520466] ftdi_sio ttyUSB1: urb failed to clear flow control
[246067.523588] ftdi_sio ttyUSB1: urb failed to clear flow control
[246067.524953] ftdi_sio ttyUSB1: urb failed to clear flow control
[246078.098085] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[246080.167839] ftdi_sio ttyUSB1: urb failed to clear flow control
[246114.155579] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[246114.320137] ftdi_sio ttyUSB1: urb failed to clear flow control
[246118.794635] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[246257.159675] ftdi_sio ttyUSB1: urb failed to clear flow control
[246282.878657] ftdi_sio ttyUSB1: urb failed to clear flow control
[246312.143550] ftdi_sio ttyUSB1: urb failed to clear flow control
[246376.620354] ftdi_sio ttyUSB1: urb failed to clear flow control
[246376.621589] ftdi_sio ttyUSB1: urb failed to clear flow control
[246411.491251] ftdi_sio ttyUSB1: urb failed to clear flow control
[246478.961258] ftdi_sio ttyUSB1: urb failed to clear flow control
[246478.962398] ftdi_sio ttyUSB1: urb failed to clear flow control
[246491.710620] ftdi_sio ttyUSB1: urb failed to clear flow control
[246513.145446] ftdi_sio ttyUSB1: urb failed to clear flow control
[246516.925111] ftdi_sio ttyUSB1: urb failed to clear flow control
[246517.006740] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[246525.437736] ftdi_sio ttyUSB1: urb failed to clear flow control
[246530.137836] ftdi_sio ttyUSB1: urb failed to clear flow control
[246555.691111] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[246569.639345] ftdi_sio ttyUSB1: urb failed to clear flow control
[246615.443975] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[246615.451560] ftdi_sio ttyUSB1: urb failed to clear flow control
[246632.510606] ftdi_sio ttyUSB1: urb failed to clear flow control
[246667.179348] ftdi_sio ttyUSB1: urb failed to clear flow control
[246670.991733] ftdi_sio ttyUSB1: urb failed to clear flow control
[246670.996100] ftdi_sio ttyUSB1: urb failed to clear flow control
[246692.638990] ftdi_sio ttyUSB1: urb failed to clear flow control
[246774.416892] ftdi_sio ttyUSB1: urb failed to clear flow control
[246777.554058] ftdi_sio ttyUSB1: urb failed to clear flow control
[246782.389206] ftdi_sio ttyUSB1: urb failed to clear flow control
[246798.888553] ftdi_sio ttyUSB1: urb failed to clear flow control
[246820.162415] ftdi_sio ttyUSB1: urb failed to clear flow control
[246833.880563] ftdi_sio ttyUSB1: urb failed to clear flow control
[246858.546229] ftdi_sio ttyUSB1: urb failed to clear flow control
[246888.411469] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[246931.158409] ftdi_sio ttyUSB1: urb failed to clear flow control
[246978.109174] ftdi_sio ttyUSB1: urb failed to clear flow control
[246982.566893] ftdi_sio ttyUSB1: urb failed to clear flow control
[246986.608714] ftdi_sio ttyUSB1: urb failed to clear flow control
[247042.079861] ftdi_sio ttyUSB1: urb failed to clear flow control
[247046.736194] ftdi_sio ttyUSB1: urb failed to clear flow control
[247046.738729] ftdi_sio ttyUSB1: urb failed to clear flow control
[247046.743182] ftdi_sio ttyUSB1: urb failed to clear flow control
[247144.727633] ftdi_sio ttyUSB1: urb failed to clear flow control
[247157.362844] ftdi_sio ttyUSB1: urb failed to clear flow control
[247161.498028] ftdi_sio ttyUSB1: urb failed to clear flow control
[247166.200143] ftdi_sio ttyUSB1: urb failed to clear flow control
[247170.999637] ftdi_sio ttyUSB1: urb failed to clear flow control
[247174.944058] ftdi_sio ttyUSB1: urb failed to clear flow control
[247178.722817] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[247199.847229] ftdi_sio ttyUSB1: urb failed to clear flow control
[247212.765989] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[247242.023223] ftdi_sio ttyUSB1: urb failed to clear flow control
[247332.123867] ftdi_sio ttyUSB1: urb failed to clear flow control
[247349.159162] ftdi_sio ttyUSB1: urb failed to clear flow control
[247349.161756] ftdi_sio ttyUSB1: urb failed to clear flow control
[247349.166032] ftdi_sio ttyUSB1: urb failed to clear flow control
[247387.547024] ftdi_sio ttyUSB1: urb failed to clear flow control
[247397.704739] ftdi_sio ttyUSB1: urb failed to clear flow control
[247397.708994] ftdi_sio ttyUSB1: urb failed to clear flow control
[247451.707471] ftdi_sio ttyUSB1: urb failed to clear flow control
[247477.284349] ftdi_sio ttyUSB1: urb failed to clear flow control
[247541.139108] ftdi_sio ttyUSB1: urb failed to clear flow control
[247541.143351] ftdi_sio ttyUSB1: urb failed to clear flow control
[247566.775521] ftdi_sio ttyUSB1: urb failed to clear flow control
[247566.867057] ftdi_sio ttyUSB1: urb failed to clear flow control
[247566.874401] ftdi_sio ttyUSB1: urb failed to clear flow control
[247575.185535] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[247634.955892] ftdi_sio ttyUSB1: urb failed to clear flow control
[247643.901560] ftdi_sio ttyUSB1: urb failed to clear flow control
[247643.904104] ftdi_sio ttyUSB1: urb failed to clear flow control
[247643.905682] ftdi_sio ttyUSB1: urb failed to clear flow control
[247643.911875] ftdi_sio ttyUSB1: urb failed to clear flow control
[247647.725838] ftdi_sio ttyUSB1: urb failed to clear flow control
[247660.526772] ftdi_sio ttyUSB1: urb failed to clear flow control
[247660.529408] ftdi_sio ttyUSB1: urb failed to clear flow control
[247660.533902] ftdi_sio ttyUSB1: urb failed to clear flow control
[247703.154339] ftdi_sio ttyUSB1: urb failed to clear flow control
[247737.486323] ftdi_sio ttyUSB1: urb failed to clear flow control
[247763.122751] ftdi_sio ttyUSB1: urb failed to clear flow control
[247779.934458] ftdi_sio ttyUSB1: urb failed to clear flow control
[247797.635426] ftdi_sio ttyUSB1: urb failed to clear flow control
[247797.641159] ftdi_sio ttyUSB1: urb failed to clear flow control
[247822.785040] ftdi_sio ttyUSB1: urb failed to clear flow control
[247882.309728] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[247882.352728] ftdi_sio ttyUSB1: urb failed to clear flow control
[247890.939634] ftdi_sio ttyUSB1: urb failed to clear flow control
[247963.405550] ftdi_sio ttyUSB1: urb failed to clear flow control
[247974.764416] ftdi_sio ttyUSB1: urb failed to clear flow control
[247974.767283] ftdi_sio ttyUSB1: urb failed to clear flow control
[248006.014719] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[248006.058975] ftdi_sio ttyUSB1: urb failed to clear flow control
[248129.447941] ftdi_sio ttyUSB1: urb failed to clear flow control
[248159.659805] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[248176.720489] ftdi_sio ttyUSB1: urb failed to clear flow control
[248224.592395] ftdi_sio ttyUSB1: urb failed to clear flow control
[248224.596962] ftdi_sio ttyUSB1: urb failed to clear flow control
[248236.444824] ftdi_sio ttyUSB1: urb failed to clear flow control
[248261.954571] ftdi_sio ttyUSB1: urb failed to clear flow control
[248262.044594] ftdi_sio ttyUSB1: urb failed to clear flow control
[248262.051715] ftdi_sio ttyUSB1: urb failed to clear flow control
[248287.590757] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[248287.591783] ftdi_sio ttyUSB1: urb failed to clear flow control
[248287.597987] ftdi_sio ttyUSB1: urb failed to clear flow control
[248300.588354] ftdi_sio ttyUSB1: urb failed to clear flow control
[248317.705026] ftdi_sio ttyUSB1: urb failed to clear flow control
[248317.706508] ftdi_sio ttyUSB1: urb failed to clear flow control
[248317.709394] ftdi_sio ttyUSB1: urb failed to clear flow control
[248317.715375] ftdi_sio ttyUSB1: urb failed to clear flow control
[248330.567865] ftdi_sio ttyUSB1: urb failed to clear flow control
[248373.166942] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[248398.502426] ftdi_sio ttyUSB1: urb failed to clear flow control
[248415.819262] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[248416.012366] ftdi_sio ttyUSB1: urb failed to clear flow control
[248432.622718] ftdi_sio ttyUSB1: urb failed to clear flow control
[248432.623847] ftdi_sio ttyUSB1: urb failed to clear flow control
[248450.707533] ftdi_sio ttyUSB1: urb failed to clear flow control
[248458.544300] ftdi_sio ttyUSB1: urb failed to clear flow control
[248462.350174] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[248517.947973] ftdi_sio ttyUSB1: urb failed to clear flow control
[248527.413113] ftdi_sio ttyUSB1: urb failed to clear flow control
[248564.707776] ftdi_sio ttyUSB1: urb failed to clear flow control
[248611.844371] ftdi_sio ttyUSB1: urb failed to clear flow control
[248611.849899] ftdi_sio ttyUSB1: urb failed to clear flow control
[248700.965602] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[248735.337933] ftdi_sio ttyUSB1: urb failed to clear flow control
[248739.708893] ftdi_sio ttyUSB1: urb failed to clear flow control
[248744.417649] ftdi_sio ttyUSB1: urb failed to clear flow control
[248744.457672] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[248744.460414] ftdi_sio ttyUSB1: urb failed to clear flow control
[248744.464685] ftdi_sio ttyUSB1: urb failed to clear flow control
[248744.469046] ftdi_sio ttyUSB1: urb failed to clear flow control
[248747.645824] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[248747.645917] ftdi_sio ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[248747.901319] usb 1-1.3.1: USB disconnect, device number 12
[248747.901963] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[248747.902023] ftdi_sio 1-1.3.1:1.0: device disconnected
[248765.032422] usb 1-1.3.1: new full-speed USB device number 13 using dwc_otg
[248765.160177] usb 1-1.3.1: New USB device found, idVendor=0403, idProduct=6001
[248765.160206] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[248765.160221] usb 1-1.3.1: Product: FT232R USB UART
[248765.160255] usb 1-1.3.1: Manufacturer: FTDI
[248765.160270] usb 1-1.3.1: SerialNumber: AL01MZ4B
[248765.168782] ftdi_sio 1-1.3.1:1.0: FTDI USB Serial Device converter detected
[248765.169014] usb 1-1.3.1: Detected FT232RL
[248765.169960] usb 1-1.3.1: FTDI USB Serial Device converter now attached to ttyUSB1
[248765.917270] ftdi_sio ttyUSB1: urb failed to clear flow control
[248765.947394] ftdi_sio ttyUSB1: urb failed to clear flow control
[248795.421704] ftdi_sio ttyUSB1: urb failed to clear flow control
[248812.387088] ftdi_sio ttyUSB1: urb failed to clear flow control
[248854.594723] ftdi_sio ttyUSB1: urb failed to clear flow control
[248884.777617] ftdi_sio ttyUSB1: urb failed to clear flow control
[248884.780247] ftdi_sio ttyUSB1: urb failed to clear flow control
[248910.819103] ftdi_sio ttyUSB1: urb failed to clear flow control
[248923.244491] ftdi_sio ttyUSB1: urb failed to clear flow control
[248965.425494] ftdi_sio ttyUSB1: urb failed to clear flow control
[248987.136035] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[248987.179014] ftdi_sio ttyUSB1: urb failed to clear flow control
[249004.363300] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[249004.367710] ftdi_sio ttyUSB1: urb failed to clear flow control
[249012.998599] ftdi_sio ttyUSB1: urb failed to clear flow control
[249068.776403] ftdi_sio ttyUSB1: urb failed to clear flow control
[249123.654611] ftdi_sio ttyUSB1: urb failed to clear flow control
[249133.074295] ftdi_sio ttyUSB1: urb failed to clear flow control
[249133.079587] ftdi_sio ttyUSB1: urb failed to clear flow control
[249187.480853] ftdi_sio ttyUSB1: urb failed to clear flow control
[249187.482087] ftdi_sio ttyUSB1: urb failed to clear flow control
[249217.503376] ftdi_sio ttyUSB1: urb failed to clear flow control
[249217.509135] ftdi_sio ttyUSB1: urb failed to clear flow control
[249234.204322] ftdi_sio ttyUSB1: urb failed to clear flow control
[249234.211339] ftdi_sio ttyUSB1: urb failed to clear flow control
[249238.810185] ftdi_sio ttyUSB1: urb failed to clear flow control
[249246.651986] ftdi_sio ttyUSB1: urb failed to clear flow control
[249246.732130] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[249277.792360] ftdi_sio ttyUSB1: urb failed to clear flow control
[249311.844173] ftdi_sio ttyUSB1: urb failed to clear flow control
[249337.139054] ftdi_sio ttyUSB1: urb failed to clear flow control
[249341.251613] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[249358.523152] ftdi_sio ttyUSB1: urb failed to clear flow control
[249366.851014] ftdi_sio ttyUSB1: urb failed to clear flow control
[249392.500936] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[249400.929319] ftdi_sio ttyUSB1: urb failed to clear flow control
[249400.935171] ftdi_sio ttyUSB1: urb failed to clear flow control
[249409.455058] ftdi_sio ttyUSB1: urb failed to clear flow control
[249409.457725] ftdi_sio ttyUSB1: urb failed to clear flow control
[249498.996881] ftdi_sio ttyUSB1: urb failed to clear flow control
[249630.837696] ftdi_sio ttyUSB1: urb failed to clear flow control
[249699.080708] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[249699.083676] ftdi_sio ttyUSB1: urb failed to clear flow control
[249738.461472] ftdi_sio ttyUSB1: urb failed to clear flow control
[249774.917084] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[249793.814952] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[249793.819048] ftdi_sio ttyUSB1: urb failed to clear flow control
[249814.260429] ftdi_sio ttyUSB1: urb failed to clear flow control
[249840.404270] ftdi_sio ttyUSB1: urb failed to clear flow control
[249840.409782] ftdi_sio ttyUSB1: urb failed to clear flow control
[249861.799751] ftdi_sio ttyUSB1: urb failed to clear flow control
[249861.804242] ftdi_sio ttyUSB1: urb failed to clear flow control
[249912.846790] ftdi_sio ttyUSB1: urb failed to clear flow control
[249921.381434] ftdi_sio ttyUSB1: urb failed to clear flow control
[249929.827074] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[250010.910897] ftdi_sio ttyUSB1: urb failed to clear flow control
[250032.233464] ftdi_sio ttyUSB1: urb failed to clear flow control
[250045.041425] ftdi_sio ttyUSB1: urb failed to clear flow control
[250105.720575] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[250105.724806] ftdi_sio ttyUSB1: urb failed to clear flow control
[250173.019120] ftdi_sio ttyUSB1: urb failed to clear flow control
[250224.199316] ftdi_sio ttyUSB1: urb failed to clear flow control
[250228.022599] ftdi_sio ttyUSB1: urb failed to clear flow control
[250228.023961] ftdi_sio ttyUSB1: urb failed to clear flow control
[250228.031098] ftdi_sio ttyUSB1: urb failed to clear flow control
[250343.646624] ftdi_sio ttyUSB1: urb failed to clear flow control
[250365.349747] ftdi_sio ttyUSB1: urb failed to clear flow control
[250365.356988] ftdi_sio ttyUSB1: urb failed to clear flow control
[250375.278628] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[250375.287348] ftdi_sio ttyUSB1: urb failed to clear flow control
[250382.933978] ftdi_sio ttyUSB1: urb failed to clear flow control
[250429.290198] ftdi_sio ttyUSB1: urb failed to clear flow control
[250429.331833] ftdi_sio ttyUSB1: urb failed to clear flow control
[250429.334894] ftdi_sio ttyUSB1: urb failed to clear flow control
[250454.807435] ftdi_sio ttyUSB1: urb failed to clear flow control
[250471.682693] ftdi_sio ttyUSB1: urb failed to clear flow control
[250471.691300] ftdi_sio ttyUSB1: urb failed to clear flow control
[250501.065847] ftdi_sio ttyUSB1: urb failed to clear flow control
[250506.423193] ftdi_sio ttyUSB1: urb failed to clear flow control
[250552.990141] ftdi_sio ttyUSB1: urb failed to clear flow control
[250552.991374] ftdi_sio ttyUSB1: urb failed to clear flow control
[250637.835711] ftdi_sio ttyUSB1: urb failed to clear flow control
[250637.839718] ftdi_sio ttyUSB1: urb failed to clear flow control
[250642.239188] ftdi_sio ttyUSB1: urb failed to clear flow control
[250646.544857] ftdi_sio ttyUSB1: urb failed to clear flow control
[250676.618370] ftdi_sio ttyUSB1: urb failed to clear flow control
[250680.635408] ftdi_sio ttyUSB1: urb failed to clear flow control
[250697.693245] ftdi_sio ttyUSB1: urb failed to clear flow control
[250702.022912] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[250702.025776] ftdi_sio ttyUSB1: urb failed to clear flow control
[250702.030167] ftdi_sio ttyUSB1: urb failed to clear flow control
[250707.253955] ftdi_sio ttyUSB1: urb failed to clear flow control
[250707.255318] ftdi_sio ttyUSB1: urb failed to clear flow control
[250707.261591] ftdi_sio ttyUSB1: urb failed to clear flow control
[250765.896413] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[250765.930536] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[250817.099724] ftdi_sio ttyUSB1: urb failed to clear flow control
[250817.651310] ftdi_sio ttyUSB1: urb failed to clear flow control
[250847.129608] ftdi_sio ttyUSB1: urb failed to clear flow control
[250851.305457] ftdi_sio ttyUSB1: urb failed to clear flow control
[250857.024300] ftdi_sio ttyUSB1: urb failed to clear flow control
[250861.005727] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[250893.461193] ftdi_sio ttyUSB1: urb failed to clear flow control
[250902.442100] ftdi_sio ttyUSB1: urb failed to clear flow control
[250932.660394] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[250932.663343] ftdi_sio ttyUSB1: urb failed to clear flow control
[250932.668534] ftdi_sio ttyUSB1: urb failed to clear flow control
[250957.889273] ftdi_sio ttyUSB1: urb failed to clear flow control
[250966.703327] ftdi_sio ttyUSB1: urb failed to clear flow control
[250978.305714] ftdi_sio ttyUSB1: urb failed to clear flow control
[250978.309944] ftdi_sio ttyUSB1: urb failed to clear flow control
[250985.993492] ftdi_sio ttyUSB1: urb failed to clear flow control
[250996.334903] ftdi_sio ttyUSB1: urb failed to clear flow control
[250996.339138] ftdi_sio ttyUSB1: urb failed to clear flow control
[251017.347174] ftdi_sio ttyUSB1: urb failed to clear flow control
[251017.351211] ftdi_sio ttyUSB1: urb failed to clear flow control
[251025.703911] ftdi_sio ttyUSB1: urb failed to clear flow control
[251030.618817] ftdi_sio ttyUSB1: urb failed to clear flow control
[251115.279860] ftdi_sio ttyUSB1: urb failed to clear flow control
[251133.828366] ftdi_sio ttyUSB1: urb failed to clear flow control
[251133.831436] ftdi_sio ttyUSB1: urb failed to clear flow control
[251162.642929] ftdi_sio ttyUSB1: urb failed to clear flow control
[251162.644299] ftdi_sio ttyUSB1: urb failed to clear flow control
[251166.421935] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[251166.500465] ftdi_sio ttyUSB1: urb failed to clear flow control
[251179.829104] ftdi_sio ttyUSB1: urb failed to clear flow control
[251179.837948] ftdi_sio ttyUSB1: urb failed to clear flow control
[251200.627888] ftdi_sio ttyUSB1: urb failed to clear flow control
[251205.305121] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[251205.310761] ftdi_sio ttyUSB1: urb failed to clear flow control
[251248.528742] ftdi_sio ttyUSB1: urb failed to clear flow control
[251307.715534] ftdi_sio ttyUSB1: urb failed to clear flow control
[251307.718649] ftdi_sio ttyUSB1: urb failed to clear flow control
[251316.167261] ftdi_sio ttyUSB1: urb failed to clear flow control
[251316.258664] ftdi_sio ttyUSB1: urb failed to clear flow control
[251367.390717] ftdi_sio ttyUSB1: urb failed to clear flow control
[251465.612676] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[251486.791938] ftdi_sio ttyUSB1: ftdi_set_termios error from disable flowcontrol urb
[251508.175507] ftdi_sio ttyUSB1: urb failed to clear flow control
[251508.178359] ftdi_sio ttyUSB1: urb failed to clear flow control
[251512.421600] ftdi_sio ttyUSB1: urb failed to clear flow control
[251512.424784] ftdi_sio ttyUSB1: urb failed to clear flow control
[251546.592485] ftdi_sio ttyUSB1: urb failed to clear flow control
[251550.777597] ftdi_sio ttyUSB1: ftdi_set_termios urb failed to set baudrate
[251583.897699] ftdi_sio ttyUSB1: urb failed to clear flow control
[251584.903221] ftdi_sio ttyUSB1: urb failed to clear flow control
Nein ... normal ist das nicht.
@ Gunther
Zitatbei einem dmesg sieht es etwas komisch aus. Ist das normal?
[234522.359472] ftdi_sio ttyUSB1: urb failed to clear flow control
[234522.365108] ftdi_sio ttyUSB1: urb failed to clear flow control
[234569.235604] ftdi_sio ttyUSB1: urb failed to clear flow control
Könntest du den Beitrag so ändern, dass deine Meldungen im Code verschwinden?
also statt
[234522.359472] ftdi_sio ttyUSB1: urb failed to clear flow control
[234522.365108] ftdi_sio ttyUSB1: urb failed to clear flow control
[234569.235604] ftdi_sio ttyUSB1: urb failed to clear flow control
...
so
[234522.359472] ftdi_sio ttyUSB1: urb failed to clear flow control
[234522.365108] ftdi_sio ttyUSB1: urb failed to clear flow control
[234569.235604] ftdi_sio ttyUSB1: urb failed to clear flow controlwird ja sonst alles zugemüllt
Billy
Hallo zusammen,
ich bin auf der Suche nach einer Lösung für folgende Anforderungen:
- Messung folgender Werte: Innen/Außentemperatur, Niederschlag, Windgeschwindigkeit.
Regen und Windgeschwindigkeit benötige ich um notifications abzusetzen um z.b. Fenster zu schließen, bzw. in Zuunft möglicherweise eine Markise einzufahren.
Perfekt wäre, wenn es dann noch eine kleine Zentrale/Display gäbe, auf der zumindest die Temperaturen angezeit werden.
Habe bereits mal nach der homematic Wetterstation / Netatmo geschaut, aber bin nun auf diesen Thread gestoßen und wenn ich das richtig verstehe, sollte ich mit einer WS1600 + jeelink ja lles abbilden können, oder?
Gibt es ansonsten irgendwelche Nachteile, weshalb ihr mir davon abraten würdet?
Danke & Gruß,
Tobi
Zitat von: onkel-tobi am 27 Januar 2016, 14:37:07
- Messung folgender Werte: Innen/Außentemperatur, Niederschlag, Windgeschwindigkeit.
Die Innentemperatur misst die WS1600 nur im Display und gibt sie nicht per Funk weiter.
Daher benötigst du noch einen Innensensor wofür es aber bei einem Jeelink genug gibt.
Die Wetterstation sendet auch mit 8k Baud und nicht wie die "normalen" Temperatursensoren auf 17k Baud.
Daher macht es Sinn wenn du dir mal das LaCrosseGateway http://forum.fhem.de/index.php/topic,43672.0.html (http://forum.fhem.de/index.php/topic,43672.0.html) anstatt eines Jeelink ansiehst.
Dort kannst du drei verschiedene Radios mit unterschiedlichen Baudraten gleichzeitig betreiben.
Dadurch gehen dir keine Daten der Wetterstation verloren.
Desweiteren friert bei mir der Windrichtungsanzeiger immer ein wenn es unter 0°C hat.
Hi Axel,
danke für Deine Antwort. Bin zwar nicht so de Lötexperte, aber so schwer sieht das ja nicht aus.
Das mit der Innentemperatur wäre nicht mal so schlimm, ich möchte halt nur eine Lösung haben, die auch funktioniert wenn ich mal nicht (mehr) da sein sollte.
Das ist mit fhem natürlich immer eine Sache, aber ich versuche das wo es geht auch autark zu halten ;)
Wie sind deine Erfahrungen sonst so?
Kann fast nicht glauben, dass ich dann quasi mit ca. 100 € durch bin.
Da würde ich bei HM /Netatmo ja nicht mal 2 Sensoren für bekommen und hier ist noch ein Display dabei.
Gruß,
Tobi
Zitat von: onkel-tobi am 27 Januar 2016, 16:59:14
Wie sind deine Erfahrungen sonst so?
Nun ... bist jetzt läuft die Wetterstation ... habe sie aber erst seit Weihnachten.
Die Qualität ist dem Preis angemessen. Der Regenmesser soll ungenau sein ... genauer der Reedkontakt soll ab und an nicht schalten ... muss ich mir noch anschauen.
Die Wetterstation bekommst du schon für 70-80 Euro. Einen Temperatur mit Luffeuchtesensor für ca. 18 EURO
Zitat von: AxelSchweiss am 27 Januar 2016, 18:23:28
Nun ... bist jetzt läuft die Wetterstation ... habe sie aber erst seit Weihnachten.
Die Qualität ist dem Preis angemessen. Der Regenmesser soll ungenau sein ... genauer der Reedkontakt soll ab und an nicht schalten ... muss ich mir noch anschauen.
Reagiert er denn zuverlässig auf Regen an sich?
Wenn die Menge nicht ganz genau ist, damit könnte ich leben, wenn er sich aber gar nicht meldet, wäre das fatal.
Zitat von: onkel-tobi am 27 Januar 2016, 22:39:10
Reagiert er denn zuverlässig auf Regen an sich?
Wenn die Menge nicht ganz genau ist, damit könnte ich leben, wenn er sich aber gar nicht meldet, wäre das fatal.
Siehe mein Beitrag hier:
http://forum.fhem.de/index.php/topic,14786.msg323208/topicseen.html#msg323208
Billy
Hi Billy,
danke für die Info. Da Du die WS 1600 ja dann jetzt min ca. ein halbes Jahr hast, kannst Du sie denn weiterempfehlen?
Oder würdest Du sie dir nicht noch einmal kaufen?
Gruß,
Tobi
Zitat von: onkel-tobi am 28 Januar 2016, 14:17:12
Hi Billy,
danke für die Info. Da Du die WS 1600 ja dann jetzt min ca. ein halbes Jahr hast, kannst Du sie denn weiterempfehlen?
Oder würdest Du sie dir nicht noch einmal kaufen?
Gruß,
Tobi
Um das Geld gibt es nichts besseres. ;) Für grobe Übersicht ausreichend.
Hängt von deinen Ansprüchen ab.
Wenn du was Profi mäßiges willst dann eine Vantage. Siehe auch JeeLink v3c zur Einbindung von Davis Vantage hier
http://forum.fhem.de/index.php/topic,44092.msg359492.html#msg359492
Billy
Guten abend
Ich hab mir nen JeeLink selber gebaut und auch erfolgreich geflasht.
Aber leider kann ich den TX29DTH-IT nicht hinzufügen.
Bei Verbose 5 bekomme ich diesen Fehler
2016.01.28 23:51:22.108 3: Opening myJeeLink device /dev/ttyUSB1
2016.01.28 23:51:22.123 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.01.28 23:51:22.159 3: myJeeLink device opened
2016.01.28 23:54:23.446 5: JeeLink/RAW: /OK WS 8 3 4 136 32 0 76 0 0 2 32 2 32 0
2016.01.28 23:54:23.448 5: myJeeLink dispatch OK WS 8 3 4 136 32 0 76 0 0 2 32 2 32 0
2016.01.28 23:54:23.466 4: LaCrosse: Unknown device 08, please define it
2016.01.28 23:55:24.172 5: JeeLink/RAW: /OK WS 8 3 4 136 32 0 76 0 0 2 32
2016.01.28 23:55:24.178 5: JeeLink/RAW: OK WS 8 3 4 136 32 0 76 0 0 2 32/ 2 32 0
2016.01.28 23:55:24.180 5: myJeeLink dispatch OK WS 8 3 4 136 32 0 76 0 0 2 32 2 32 0
2016.01.28 23:55:24.199 4: LaCrosse: Unknown device 08, please define it
2016.01.28 23:58:10.554 5: JeeLink/RAW: /OK WS 8 3 4 104 96 0 76 0 0 2 32
2016.01.28 23:58:10.559 5: JeeLink/RAW: OK WS 8 3 4 104 96 0 76 0 0 2 32/ 2 32 0
2016.01.28 23:58:10.561 5: myJeeLink dispatch OK WS 8 3 4 104 96 0 76 0 0 2 32 2 32 0
2016.01.28 23:58:10.579 4: LaCrosse: Unknown device 08, please define it
2016.01.28 23:59:02.154 5: JeeLink/RAW: /OK WS 10 3 4 136 32 0 76 0 0 1 1
2016.01.28 23:59:02.159 5: JeeLink/RAW: OK WS 10 3 4 136 32 0 76 0 0 1 1/79 1 179 0
2016.01.28 23:59:02.161 5: myJeeLink dispatch OK WS 10 3 4 136 32 0 76 0 0 1 179 1 179 0
2016.01.28 23:59:02.180 4: LaCrosse: Unknown device 0A, please define it
2016.01.28 23:59:03.396 5: JeeLink/RAW: /OK WS 10 3 4 136 32 0 76 0 0 1 1
2016.01.28 23:59:03.402 5: JeeLink/RAW: OK WS 10 3 4 136 32 0 76 0 0 1 1/79 1 179 0
2016.01.28 23:59:03.404 5: myJeeLink dispatch OK WS 10 3 4 136 32 0 76 0 0 1 179 1 179 0
Hier noch ein list vom JeeLink
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB1@57600
DeviceName /dev/ttyUSB1@57600
FD 10
NAME myJeeLink
NR 578
PARTIAL
RAWMSG OK WS 14 3 4 168 64 0 96 0 0 2 32 1 179 0
STATE Initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
myJeeLink_MSGCNT 7
myJeeLink_TIME 2016-01-29 00:00:54
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-01-28 23:51:22 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] -b 57600
verbose 5
LG Kasslerks
Schau doch mal hier im Thread nach: Nur autocreate reicht nicht, Du musst auch LaCrossePairForSec setzen.
Das steht auch so in der commandref ;)
Das hab ich ja gemacht
Das ist aus dem list aber nicht erkennbar, denn da müsste soetwas stehen wie:
LaCrossePair 2
Was hast Du denn angegeben für LaCrossePairForSec?
Johannes
@kasslerks, autocreate wird völlig überbewertet :) leg dir doch die beiden Wetterstationen von Hand an , die Adressen hast ja jetzt :
Zitat von: kasslerks am 29 Januar 2016, 00:04:00
2016.01.28 23:54:23.466 4: LaCrosse: Unknown device 08, please define it
2016.01.28 23:59:02.180 4: LaCrosse: Unknown device 0A, please define it
von einem TX-29 ist in deinem Logs nichts zu sehen, OK WS = Wetterstation,
ein TX-29 würde mit OK 9 beginnen.
2016.01.28 23:54:23.466 4: LaCrosse: Unknown device 08, please define it
versuche doch mal ein Device anzulegen z.b.
define Test Lacrosse 08
Gruß Werner
Super danke für die antworten.
Werde es heute abend mal testen und dann berichten.
Lg kasslerks
Hallo zusammen,
ich hab mir aufgrund der Anregungen hier auch ein Jeelink mit Tx29DTH Sensoren gekauft, da ich jedoch viel Erfahrung mit Check_MK (Monitoring-Software) besitze, habe ich mir ein Python Skript geschrieben welches die Rohdaten vom Jeelink decodiert und dann dann Check_MK übergibt.
https://github.com/christianbur/check_mk/blob/master/jeelink_TX29DTH/jeelinkD.py
Jetzt meine Frage wie kann ich diese blaue LED am Jeelink deaktivieren. In FHEM wird dies mit "set myJeeLink initCommands 0a v" gemacht.
Ich habe bisher folgendes versucht, leider ohne Erfolg(einfaches Beispiel):
#!/usr/bin/env python
import serial, sys
jeelink = serial.Serial('/dev/ttyUSB0', 57600)
-- Versuch1: jeelink.write("initCommands 0a v \r\n")
-- Versuch2: jeelink.write("0a v \r\n")
-- Versuch3: jeelink.write("0a \r\n")
while True:
sys.stdout.write(jeelink.readline())
hat jemand eine Idee wie ich die blaue LED am Jeelink mit Python deaktivieren kann?
PS:
Bei der Erstellung des Skriptes ist mir auch aufgefallen, dass die TX29DTH beim einlegen der Batterien immer "SP6" und danach die Adresse anzeigen. Erst war mich nicht klar wie ich von den Rohdaten auf diese Adresse komme, nach etwas teste ergibt sich folgender Weg: dezimal2hex(ID * 4) = ID auf dem Display
['OK', '9', '8', '1', '4', '151', '55'] -> 20 (dezimal2hex(8 * 4) = 20)
['OK', '9', '35', '1', '4', '150', '56'] -> 8C (dezimal2hex(35 * 4) = 8C)
['OK', '9', '45', '1', '4', '158', '55'] -> B4 (dezimal2hex(45 * 4) = B4)
['OK', '9', '43', '1', '4', '40', '106'] -> AC (dezimal2hex(43 * 4) = AC)
['OK', '9', '35', '1', '4', '149', '56'] -> 8C
['OK', '9', '52', '1', '4', '159', '54'] -> D0
['OK', '9', '45', '1', '4', '157', '55'] -> B4
In FHEM fehlt das meiner Meinung nach noch
Zitat von: Christian1982 am 31 Januar 2016, 13:15:37
hat jemand eine Idee wie ich die blaue LED am Jeelink mit Python deaktivieren kann?
Versuch 3
Aber Du musst nach dem Öffnen der Schnittstelle etwas warten, bevor Du es schickst.
Wenn die Schnittstelle geöffnet wird, macht der JL einen Reset und braucht etwas Zeit (mindesten 1500ms) bis die Initialisierung durch ist und er auf der Seriellen Kommandos akzeptiert.
Danke, jetzt nervt die LED nicht mehr :-)
time.sleep(10)
jeelink.write(" 0a\r\n")
Hallo Fhem'ler,
ich habe mir seit Kurzem eine Wetterstation WS1600 gegönnt. Leider funzt das pairen nicht.
Ich habe bereits einen TX29DTH-IT am Jeelink V3 (classic) laufen. Dieser wurde problemlos über "LaCrossePairForSec" angelegt.
Folgendes habe ich konfiguriert und ausgeführt:
1. CUL Jeelink config:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB2@57600
DeviceName /dev/ttyUSB2@57600
FD 21
NAME cul_jeelink
NR 166
PARTIAL
RAWMSG OK 9 60 1 4 174 62
STATE Initialized
TYPE JeeLink
cul_jeelink_MSGCNT 2454
cul_jeelink_TIME 2016-01-31 14:10:44
initMessages
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 t:30~7)]
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-01-31 13:56:52 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 7m 30t 0a v
room LaCrosse
verbose 5
2. Mit verbose 5 werden nur die Daten "OK 9" vom TX29 empfangen.
2016.01.31 14:10:26 5: cul_jeelink dispatch OK 9 60 1 4 174 62
2016.01.31 14:10:35 5: JeeLink/RAW: /OK 9 60 1
2016.01.31 14:10:35 5: JeeLink/RAW: OK 9 60 1 /4 174 62
3. Fhem version ist 5.7
4. Ich habe es mit "set cul_jeelink LaCrossePairForSec 120" und "set cul_jeelink LaCrossePairForSec ignore _battery" probiert.
Leider ohne Erfolg. Der einzigste Unterschied ist das der Parameter "LaCrossePair" 1 oder 2 ist.
5. Um festzustellen das die Sensor (TX22 etc...) funktionieren, habe ich kurz Batterien in die Basisstation getan. Es wurden alle Daten korrekt angezeigt.
Was habe ich übersehen! Über jeden Hinweis bin ich dankbar....
Viele Grüsse
Axel
Wenn du nur neben der ws1600 einen TX29DTH-IT laufen hast müsste als init auch das reichen.
attr myJeeLink initCommands 5m 30t v
mach auch mal LaCrossePairForSec 300 etwas länger. (autocreate an?)
Gruß Billy
Hallo Billy,
danke für den Hinweis, ich werde es heute Abend ausprobieren.
Autocreate ist an:
Internals:
NAME autocreate
NOTIFYDEV global
NR 18
NTFY_ORDER 50-autocreate
STATE active
TYPE autocreate
Attributes:
filelog ./log/%NAME-%Y.log
Noch eine Frage: Ich habe die WS1600 Basisstation nicht angeschlossen, ist das vielleicht mein Problem?
Gruss
Axel
Zitat von: axel.mohnen am 31 Januar 2016, 15:20:30
Noch eine Frage: Ich habe die WS1600 Basisstation nicht angeschlossen, ist das vielleicht mein Problem?
Nein Dein Problem sind die unterschiedlichen Datenraten (siehe hier http://www.fhemwiki.de/wiki/JeeLink (http://www.fhemwiki.de/wiki/JeeLink)dazu muss der Jeelink die Datenraten umschalten um beides empfangen zu können (Dafür das initcommand)
Hi Viegener,
das ist richtig, dafür habe ich ja das initCommanf 7m (7m -> wechselt zwischen allen drei data rates) eingestellt.
Aber ich werde jetzt noch mal mit 5m versuchen, wie Billy vorgeschlagen hat....
Gruss
Axel
Zitat von: axel.mohnen am 31 Januar 2016, 14:28:25
4. Ich habe es mit "set cul_jeelink LaCrossePairForSec 120" und "set cul_jeelink LaCrossePairForSec ignore _battery" probiert.
Richtig wäre
set cul_jeelink LaCrossePairForSec 120 ignore_batteryDu kannst aber auch mal ein 2r setzen, dass Du exklusiv auf den 8842 kbps der WS 1600 bist, um zu sehen, ob da was kommt.
Hallo Billy,
ich habe es mit 5m 30t 0a v probiert und für 300 sek. "gepairt". Leider wird keine WS1600 erkannt.
Auch im Log mit verbose = 5 sehe ich keine "WS" Raw data.
2016.01.31 20:41:18 5: cul_jeelink dispatch OK 9 60 1 4 176 59
2016.01.31 20:41:27 5: JeeLink/RAW: /OK 9 60 1
2016.01.31 20:41:27 5: JeeLink/RAW: OK 9 60 1/ 4 176 59
2016.01.31 20:41:27 5: cul_jeelink dispatch OK 9 60 1 4 176 59
2016.01.31 20:42:12 5: JeeLink/RAW: /OK 9 60 1 4 176 59
2016.01.31 20:42:12 5: cul_jeelink dispatch OK 9 60 1 4 176 59
2016.01.31 20:42:20 5: JeeLink/RAW: /OK 9 60 1 4 176 59
Gruss
Axel
Hallo HCS,
sorry, das war ein Tippfehler meinerseits. Ich habe natürlich mit "set cul_jeelink LaCrossePairForSec 120 ignore_battery" getestet ;-)
Als nächstes Versuche ich ich mal mit "2r". Lautet der initCommand dann "2r 8.842 0a v"?
Wo finde ich den eine Liste aller initCommands?
Merci,
Gruss
Axel
Zitat von: axel.mohnen am 31 Januar 2016, 20:57:27
Als nächstes Versuche ich ich mal mit "2r". Lautet der initCommand dann "2r 8.842 0a v"?
2r 0a v
Zitat von: axel.mohnen am 31 Januar 2016, 20:57:27
Wo finde ich den eine Liste aller initCommands?
Wenn Billy mal so nett ist sie ins wiki zu packen, dann im wiki ;)
Bis da hin im Quellcode:
// The following settings can also be set from FHEM
#define ENABLE_ACTIVITY_LED 1 // <n>a set to 0 if the blue LED bothers
unsigned long DATA_RATE_S1 = 17241ul; // <n>c use one of the possible data rates (for transmit on RFM #1)
bool DEBUG = 0; // <n>d set to 1 to see debug messages
unsigned long INITIAL_FREQ = 868300; // <n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515)
int ALTITUDE_ABOVE_SEA_LEVEL = 0; // <n>h altituide above sea level
byte TOGGLE_MODE_R1 = 3; // <n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
byte TOGGLE_MODE_R2 = 3; // <n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
// <n>o set HF-parameter e.g. 50305o for RFM12 or 1,4o for RFM69
byte PASS_PAYLOAD = 0; // <n>p transmitted the payload on the serial port 1: all, 2: only undecoded data
unsigned long DATA_RATE_R1 = 17241ul; // <n>r use one of the possible data rates (for RFM #1)
unsigned long DATA_RATE_R2 = 9579ul; // <n>R use one of the possible data rates (for RFM #2)
// <id,..>s send the bytes to the address id
uint16_t TOGGLE_INTERVAL_R1 = 0; // <n>t 0=no toggle, else interval in seconds (for RFM #1)
uint16_t TOGGLE_INTERVAL_R2 = 0; // <n>T 0=no toggle, else interval in seconds (for RFM #2)
// v show version
// x test command
bool RELAY = 0; // <n>y if 1 all received packets will be retransmitted
bool ANALYZE_FRAMES = 0; // <n>z set to 1 to display analyzed frame data instead of the normal data
Zitat von: axel.mohnen am 31 Januar 2016, 20:48:56
Hallo Billy,
ich habe es mit 5m 30t 0a v probiert und für 300 sek. "gepairt". Leider wird keine WS1600 erkannt.
Auch im Log mit verbose = 5 sehe ich keine "WS" Raw data.
Ich hatte das Problem Anfangs auch
Dann habe ich den Jeelink komplett auf die WS1600 eingestellt und verbose auf 5 gesetzt.
Ein Pair mit 300 habe ich mehrfach gemacht.
Irgendwann (ca. nach einer Stunde) stand dann die WS im Logfile und somit auch die ID der Station.
Dann habe ich sie von Hand in die fhem.cfg eingetragen und den Jeelink wieder auf den vorigen Stand eingestellt.
Jetzt läufts wunderbar.
Das pairing sollte man lange genug setzten, da ein Sensor innerhalb 120 Sekunden zwei mal empfangen worden sein muss, dass der angelegt wird.
Mit toggle kann es einem passieren, dass man in diesem Zeitfenster die Station nur einmal empfängt. Besonders, wenn das toggle recht lange ist oder alle drei data rates durchkaut.
Das ist vermutlich der Grund, warum das Vorgehen von AxelSchweiss erfolgreich war.
Wenn ich ein Pair mehrmals mit 300 mache, soll ich dann die Batterien vorher jedesmal nochmals entfernen aus dem TX22?
Zitat von: axel.mohnen am 01 Februar 2016, 14:04:26
Wenn ich ein Pair mehrmals mit 300 mache, soll ich dann die Batterien vorher jedesmal nochmals entfernen aus dem TX22?
Brauchst du nicht, da das Battery Flag erst nach 4h30min seinen Status ändert.
(wenn ich mich an meine Anfänge hier richtig erinnere. ;)
Billy
Hallo zusammen,
gibt es auch eigentlich eine Möglichkeit Temperatur oder Luftfeuchtigkeitswerte in fhem zu korrigieren? Ich habe aktuell mehrere TX 29 DT-HT Sensoren im Einsatz. Wenn ich diese direkt nebeneinander lege weichen die Luftfeuchtigkeitswerte um 5 - 6 Prozent voneinander ab.
Gruß Micha
Zitat von: Micha_88 am 01 Februar 2016, 21:07:00
gibt es auch eigentlich eine Möglichkeit Temperatur oder Luftfeuchtigkeitswerte in fhem zu korrigieren?
Ein Blick in die commandref (den man gerne mal werfen darf) offenbart das hier:
LaCrosse
FHEM module for LaCrosse Temperature and Humidity sensors and weather stations like WS 1600 (TX22 sensor).
It can be integrated in to FHEM via a JeeLink as the IODevice.
The JeeNode sketch required for this module can be found in .../contrib/36_LaCrosse-pcaSerial.zip.
Define
define <name> LaCrosse <addr> [corr1...corr2]
addr is a 2 digit hex number to identify the LaCrosse device.
corr1..corr2 are up to 2 numerical correction factors (corr1 for the temperature and corr2 for the humidity), which will be added to the respective value to calibrate the device.
Hallo,
jetzt hat es endlich gefunzt ;D (Mit intcommand "2r 0a v" und mehrmals "pairen").
Die WS1600 wurde über autocreate angelegt.
Nochmals vielen Dank an Alle für den super Support!! :)
Viele Grüsse
Axel
Hi
Kannst du die ConfigSektion der WS1600 mal hier posten?
Da ich sie ja von Hand angelegt habe interessiert mich ob ich sie auch vollständig angelegt habe.
Danke
Hi Axel,
anbei findest du die Config. Die "Event" Attribute habe ich selbst angelegt alles Andere wurde automatisch generiert.
Wie hast du deine Events konfiguriert um die Logeinträge zu begrenzen?
Config:
define LaCrosse_2A LaCrosse 2A
attr LaCrosse_2A IODev cul_jeelink
attr LaCrosse_2A event-min-interval state:600,battery:3600,temperature:300,humidity:300, rain:300
attr LaCrosse_2A event-on-change-reading state
attr LaCrosse_2A event-on-update-reading .*
attr LaCrosse_2A room LaCrosse
define FileLog_LaCrosse_2A FileLog ./log/LaCrosse_2A-%Y.log LaCrosse_2A
attr FileLog_LaCrosse_2A logtype text
attr FileLog_LaCrosse_2A room LaCrosse
Internals:
Internals:
DEF 2A
IODev cul_jeelink
LASTInputDev cul_jeelink
LaCrosse_lastRcv 2016-02-03 21:18:56
MSGCNT 51
NAME LaCrosse_2A
NR 171
STATE T: 65535
TYPE LaCrosse
addr 2A
battery_new 0
bufferedH
bufferedT
corr1 0
corr2 0
cul_jeelink_MSGCNT 51
cul_jeelink_RAWMSG OK WS 42 1 255 255 255 0 5 255 255 255 255 255 255 0
cul_jeelink_TIME 2016-02-03 21:18:56
previousH 255
previousR 2.5
previousT 65535
sensorType 1=TX22
Readings:
2016-02-03 21:18:47 battery ok
2016-02-03 21:18:47 error 0
2016-02-03 21:17:44 humidity 51
2016-02-03 21:18:56 rain 2.5
2016-02-03 21:17:57 state T: 65535
2016-02-03 21:15:47 temperature 21.2
2016-02-03 21:18:42 windDirectionDegree 22.5
2016-02-03 21:18:42 windDirectionText NNE
2016-02-03 21:18:47 windGust 0
2016-02-03 21:18:42 windSpeed 0
Attributes:
IODev cul_jeelink
event-min-interval state:600,battery:3600,temperature:300,humidity:300, rain:300
event-on-change-reading state
event-on-update-reading .*
room LaCrosse
Ich habe im Jeelink das initCommand wieder auf 5m 30t gesetzt, jetzt werden mein TX29 und TX22 sauber empfangen :)
Gruss
Axel
Mir ist noch aufgefallen das die Temperatur im State merkwürdig ist:
STATE T: 65535 H: 51
Ist das normal?
Zitat von: axel.mohnen am 03 Februar 2016, 21:35:48
Mir ist noch aufgefallen das die Temperatur im State merkwürdig ist:
STATE T: 65535 H: 51
Ist das normal?
das ist nicht der Normalfall.
Kommt vermutlich von den Internals previousT 65535 --> STATE T: 65535
Passiert bei mir wenn ich zu weit von der WS1600 (TX22) weg bin.geh mal auf eine bessere Empfangsposition ob es dann besser wird.
Merkwürdig ist dass trotzdem die temperature 21.2 immer (auch bei mir) richtig angezeigt wird.
Vielleicht ist da noch ein Bug im Modul?
Zitat von: axel.mohnen am 03 Februar 2016, 21:35:48
Mir ist noch aufgefallen das die Temperatur im State merkwürdig ist:
STATE T: 65535 H: 51
Ist das normal?
Habe ich auch ab und zu mal im Log stehen aber es schein nicht "durchzuschlagen" da die Graphen keine Ausreisser zeigen.
Ansonsten habe ich noch zwei abweichende Einträge in der Definition stehen
attr Wetterstation event-min-interval state:600,battery:3600,temperature:300,humidity:300,windDirectionDegree:300,windDirectionText:300,windGust:300,windSpeed:300,rain:300,error:300
attr Wetterstation stateFormat Windrichtung: windDirectionText Windgeschwindigkeit: windSpeed m/s Regen: rain mm/m^2
Zitat von: AxelSchweiss am 03 Februar 2016, 21:58:50
aber es schein nicht "durchzuschlagen" da die Graphen keine Ausreisser zeigen.
denn Fall hat HCS auch abgefangen , siehe 36_LaCrosse.pm :
# Round and write temperature and humidity
if ($temperature != 0xFFFF) { 0xFFFF = 65535 :)
aber ein paar Zeilen tiefer wird state zusammengebaut und da gibt es keine Prüfung mehr ob temp noch den vorbesetzten Wert von 0xFFFF hat :
# STATE
if( !$channel ) {
my $state = "T: ". $temperature;
Das 65535 Thema habe ich schon einige Zeit auf der Agenda, bin nur noch nicht dazu gekommen.
Wird irgend wann aber mal noch ...
Hintergrund: die WS 1600 sendet nicht immer alle Daten (Temp, Humi, Wind, ...) sondern mal dies und mal das und die 0xFF setzt der Sketch auf dem JeeLink als Kennzeichen, dass diese Information (z.B. Temperatur) aktuell nicht vorliegt. Nur wird es, wie wzut schon bemerkt hat, nicht ganz vollständig im 36_LaCrosse weggefiltert.
Hallo,
ich habe eine generelle Frage zu den Sensoren und komme nicht wirklich weiter.
Ich habe einen CUL mit 868 MHz für FHEM. Habe dann dazu einen JeeLink mit 433 MHz gekauft, da ich der Meinung war (irgendwo im Forum gelesen), dass die preislich interessanten LaCrosse Sensoren mit 433 MHz senden. Jeelink bestellt und, da ich im Moment viel an Tablet-UI herummache, liegen gelassen. Nachdem ich die ersten Seiten auf dem Tablet-UI fertig habe wollte ich jetzt die Sensoren bestellen und merke zu meinem Schreck, dass alle LaCrosse Sensoren, die im Wiki als Funktionsfähig geführt werden, auf 868 MHz senden. Ergo: Geht mit meinem JeeLink nicht.
Zurücksenden is nich mehr => Frage 1: Gibt es funktionsfähige und preislich akzeptable Sensoren mit 433 MHz?
Frage 2: Wenn nicht: Muss es ein Jeelink mit 868 MHz sein oder gibt es dazu Alternativen?
Hoffe, jemand hat hiermit Erfahrung und kann mir weiterhelfen.
Gruß Jürgen
Hallo zusammen,
ich wollte nochmal nachfragen warum die FHEM Implementierung nicht die Adressen verwendet, die auf dem TX29DTH Display angezeigt werden?
In FHEM werden die Sensoren mit "LaCrosse_XX" angelegt, XX ist dabei die hex-Adresse aus den Rohdaten.
Aus mir bisher nicht bekannten Gründen wird dieser Adresse jedoch nicht auf dem TX29DTH Display angezeigt sondern dezimal2hex(ID-Rohdaten * 4) = ID.
Warum verwendet FHEM diese IDs vom TX29DTH Display nicht auch, dann wäre die Zuordnung wesentlich einfacher, so muss ich immer umrechnen.
Bei der Erstellung eines eigenen Skriptes ist mir auch aufgefallen, dass die TX29DTH beim einlegen der Batterien immer "SP6" und danach die Adresse anzeigen. Erst war mich nicht klar wie ich von den Rohdaten auf diese Adresse komme, nach etwas teste ergibt sich folgender Weg: dezimal2hex(ID * 4) = ID auf dem Display
['OK', '9', '8', '1', '4', '151', '55'] -> 20 (dezimal2hex(8 * 4) = 20) ---> FHEM verwendet dezimal2hex(8 ) = 8
['OK', '9', '35', '1', '4', '150', '56'] -> 8C (dezimal2hex(35 * 4) = 8C) ---> FHEM verwendet dezimal2hex(35) = 23
['OK', '9','43', ....] -> AC (dezimal2hex(43 * 4) = AC) ---> FHEM verwendet dezimal2hex(43) = 2b
Zitat von: Christian1982 am 06 Februar 2016, 22:54:29
ich wollte nochmal nachfragen warum die FHEM Implementierung nicht die Adressen verwendet, die auf dem TX29DTH Display angezeigt werden?
Das ist ein "Geburtsfehler" des LaCrosse-Sketch. Das Thema gab es vor geschätzt ca. einem Jahr schon mal.
Die Adressen, die der Sketch übermittelt zu ändern würde aber bedeuten, dass alle Anwender ihre bereits eingerichteten Sensoren anpassen müssen. Darum wurde es belassen, wie es ist.
Zitat von: bmwfan am 04 Februar 2016, 21:25:27
Frage 1: Gibt es funktionsfähige und preislich akzeptable Sensoren mit 433 MHz?
Mir sind aktuell keine bekannt. Die meisten 433MHz Sensoren senden OOK, was vom LaCrosse-Sketch nicht unterstützt wird.
Zitat von: bmwfan am 04 Februar 2016, 21:25:27
Frage 2: Wenn nicht: Muss es ein Jeelink mit 868 MHz sein oder gibt es dazu Alternativen?
Kann man auch mit einem Arduino und einem RFM69 selbst basteln.
Oder den 433MHz RFM vom JeeLink runterlöten und einen 868er drauflöten.
Allerdings muss man dazu seine Lötkünste vorher realistisch einschätzen. Ich habe mal von einem JeeLink den RFM12 runtergelötet und einen RFM69CW draufgelötet. Machbar ist es, aber man muss sehr achtgeben, dass man die Pads auf der Platine nicht killt.
Zitat von: HCS am 06 Februar 2016, 23:54:54
Das ist ein "Geburtsfehler" des LaCrosse-Sketch.
Ich verstehe.
Das könnte man ja einfach mit einem zusätzlichen Parameter für "initCommands" lösen, um bei gesetztem Parameter die "korrekten" Adressen auszugeben.
Mir ist auch aufgefallen, das bei TECHNOLINE TX25 in der Übersicht nur die erste "temperature" ("T:") angezeigt wird, die "temperature2" sehe ich nur in den Details.
Müsste hier die Anzeige nicht "T: 19 T2: 22" sein, bei TX29DTH werden ja auch Temperatur und Feuchtigkeit (T: 18.3 H: 45) angezeigt.
Zitat von: Christian1982 am 07 Februar 2016, 00:40:18
Müsste hier die Anzeige nicht "T: 19 T2: 22" sein, bei TX29DTH werden ja auch Temperatur und Feuchtigkeit (T: 18.3 H: 45) angezeigt.
Das kann man sehr einfach mit stateFormat regeln:
attr LaCrosse_02 stateFormat T: temperature T2: temperature2
Ich glaube, ich hätte diesen Beitrag in diesen Thread posten müssen, oder? Sicherheitshalber hier mal einen Querverweis: http://forum.fhem.de/index.php/topic,48944.msg405982.html#msg405982 (http://forum.fhem.de/index.php/topic,48944.msg405982.html#msg405982)
Für Homematic Sensoren git es einen "ActionDetector", der dann wohl Activity mit "dead" oder "alive" füllt.
Gibt es sowas für die LaCrosse Sensoren auch, denn ich habe z.B. ein Sensor abgebaut, in FHEM wir mir dies jedoch nicht angezeigt?
Oder wie erkennt man z.B. das 10 min nichts vom Sensor empfangen wurde?
Ich habe mir mal vor einiger Zeit ein Modul geschrieben, das fast genau das macht.
Es fügt zu jeden Device das Attribut readingsSupervision hinzu.
Wenn man das dann z.B. bei einem LaCrosse device so setzt:
900,---,temperature,humidity
wird geprüft, ob sich der Zeitstempel der Readings temperature und humidity seit 900s nicht mehr geändert hat und dann das Reading auf --- gesetzt.
Damit habe ich alle Sensoren, die ausfallen könnten, versehen.
Bei einem Ausfall schlägt dann die Anzeige im Frontend (bei mir SmartVISU) für Temperatur und Feuchte des Sensors auf --- um.
Das ist mir lieber, als einen Wert zu sehen, der evtl. schon drei Tage alt ist, ohne dass ich es bemerke.
Eventuell gibt es ja so was auch in "Offiziell", das das kann.
Watchdog wäre wohl das Stichwort.
in contrib gibt es den DeviceMonitor.
gruss
andre
@justme1968: Ich habe da einen patch für 36_JeeLink.pm um ein OTA-Update für das LaCrosseGateway zu ermöglichen.
Übernimmst Du den?
Zitat von: HCS am 10 Februar 2016, 15:16:52
Ich habe mir mal vor einiger Zeit ein Modul geschrieben, das fast genau das macht.
Und wie nennt sich das Modul und wo hast du es versteckt ?
Zitat von: Wzut am 13 Februar 2016, 09:28:53
Und wie nennt sich das Modul und wo hast du es versteckt ?
Es nennt sich 98_ReadingsSupervision.pm und ich habe es auf meiner Festplatte versteckt.
Wenn es jemand möchte, kann er es gerne haben, ich werde es aber nicht offiziell supporten.
Es darf sich auch gerne jemand zu eigen machen und offiziell einbringen.
Das hab ich mal irgendwann quick 'n dirty gemacht, ohne commandref usw. aber schon lange auf dem Prduktivsystem laufen.
@HCS: hab es eingecheckt.
gruss
andre
Zitat von: HCS am 13 Februar 2016, 09:37:27
Es nennt sich 98_ReadingsSupervision.pm und ich habe es auf meiner Festplatte versteckt.
Nachdem nun Anfragen nach 98_ReadingsSupervision.pm per PM kommen, hänge ich es hier an.
As is.
Ohne Support, keine Gewährleistung, kein Rückgaberecht, kein Umtausch und auch keine Nachverhandlungen ;D
Nachtrag: Anhang entfernt, da es Wzut überommen hat.Es ist nun hier zu finden: http://forum.fhem.de/index.php/topic,49408.msg410767.html#msg410767
Zitat von: HCS am 13 Februar 2016, 09:37:27
Es darf sich auch gerne jemand zu eigen machen und offiziell einbringen.
Du hast schon so viel gute Arbeit zum Thema LaCrosse gemacht, wäre für mich jetzt ne gute Gelegenheit etwas davon zurück zu geben .
D.h. ich werde mir das Modul die Tage anschauen und würde es dann mit deinem Segen übernehmen bzw. aufpolieren und einchecken.
Zitat von: Wzut am 13 Februar 2016, 13:32:16
D.h. ich werde mir das Modul die Tage anschauen und würde es dann mit deinem Segen übernehmen bzw. aufpolieren und einchecken.
Du hast meinen Segen.
Zitat von: HCS am 13 Februar 2016, 11:40:08
Nachdem nun Anfragen nach 98_ReadingsSupervision.pm per PM kommen, hänge ich es hier an.
As is.
Ohne Support, keine Gewährleistung, kein Rückgaberecht, kein Umtausch und auch keine Nachverhandlungen ;D
Vielen Dank dafür. Funktioniert prima!
Zitat von: justme1968 am 13 Februar 2016, 10:40:06
@HCS: hab es eingecheckt.
Hi justme1968 - irgendwie ist der Part
use LWP::UserAgent;
use HTTP::Request::Common;oben im patch auf der Strecke geblieben (war im patch schon nicht dabei :o)
Ich habe es der Einfachheit wegen selbst geändert und eingecheckt.
ich bin mir nicht sicher ob die beiden module auf jeden FHEM system das das LaCrosse modul verwendet auch vorhanden sind. d.h. es kann sein das nach einem update einige nicht mehr gehen.
kannst du bitte entweder die HttpUtils verwenden oder per eval prüfen ob die module tagsächlich da sind und die funktionalität nur dann aktivieren.
gruß
andre
So ich habe das Modul 98_ReadingsSupervision.pm jetzt mal ausprobiert
- Datei nach /opt/fhem/FHEM/98_ReadingsSupervision.pm kopiert
- define LaCrosse_Check ReadingsSupervision (im Modul steht was von "Usage: define <name> ReadingsSupervision" daher hab ich das mal gemacht)
- Für jeden LaCrosse-Sensor dann noch das readingsSupervison Attribut festlegen:
TX29DTH: "attr <Sensor-Name> readingsSupervision 120,---,temperature,humidity,state"
TX25: "attr <Sensor-Name> readingsSupervision 120,---,temperature,temperature2,state"
Danach habe ich die Batterien aus dem Sensor genommen und 120 sec gewartet, danach wird dann temperature,humidity und state auf "---" gesetzt.
Prima genau das was ich wollte, danke
Zitat von: justme1968 am 14 Februar 2016, 09:57:20
kannst du bitte entweder die HttpUtils verwenden oder per eval prüfen ob die module tagsächlich da sind und die funktionalität nur dann aktivieren.
Klar, anbei der patch.
danke. habs etwas abgewandelt und eingecheckt.
gruss
andre
Zitat von: HCS am 13 Februar 2016, 16:27:22
Du hast meinen Segen.
Ist jetzt hier eigentlich OffTopic (werde auch später für das Modul einen eigenen Fred aufmachen),
aber hier mal meine erste umgebastelte Beta Version :
- Das Modul hat Log Ausgaben wenn man Readings angibt die das Device gar nicht hat oder dort zuwenig Parameter einträgt
- Das Modul hat den Status der zu überwachenden Device Readings als eigene Readings, state dient als Sammelmeldung :
ok = keine Reading mit Zeitüberschreitung , timeout = min ein Reading hat einen Timeout
- Ich wollte nicht das mir das Modul Device Readings in jedem Fall überschreibt, daher kann der zweite Parameter errorValue auch leer bleiben (,,)
die Überwachung findet dann nur innerhalb der Readings von ReadingsSupervision bzw. dessen state statt.
Edit : ich habe den / in den Readings durch einen Punkt ersetzt , Grund :
a. stand der / in Readings Namen vor einigen Wochen schon auf der Abschussliste der verbotenen Zeichen
b. macht er Probleme bei der Weiterverarbeitung mit MQTT
Zitat von: Wzut am 14 Februar 2016, 18:28:00
Ist jetzt hier eigentlich OffTopic (werde auch später für das Modul einen eigenen Fred aufmachen),
aber hier mal meine erste umgebastelte Beta Version
Habe ich es doch geahnt, dass man da noch was Vernünftiges draus machen kann. ;D
Da ich es Dir geschenkt habe, darfst Du jetzt machen mit was Du willst, nur eines nicht: meine bestehenden Definitionen inkompatibel machen.
Zitat von: HCS am 14 Februar 2016, 19:02:06
meine bestehenden Definitionen inkompatibel machen.
die sollten eigentlich nicht betroffen sein , imGegenteil du hast jetzt noch eine Option mehr :)
BTW:
Man kann mit dem Modul schön einen CUL überwachen ob er noch etwas tut, beim JeeLink schlägt das leider fehl da dort im Gegensatz zum CUL state im laufenden Betrieb nicht mehr angefasst wird.
@Andre würdest du bitte eventuell im JeeLink Modul in der Sub Parse ganz am Ende direkt vor
Dispatch($hash, $dmsgMod, \%addvals);noch diese Zeile (wie beim CUL ) einfügen :
readingsSingleUpdate($hash, "state", $hash->{READINGS}{state}{VAL}, 0);dann verhält sich der JeeLink wie der CUL beim Überwachen
habs für jeelink und panstamp eingecheckt.
gruss
andre
THX Andre, hast am Samstag ein Getränk auf meine Rechnung frei :)
@HCS : hiermit ist nun Schluss mit OT , weiter geht es da : http://forum.fhem.de/index.php/topic,49408.0.html
Hallo,
Ich nutze schon lange einen JeeLinkClone erfolgreich mit LaCrosse Sensoren in der kompletten Wohnung zur Überwachung von Temp/Hum.
Vorgestern habe ich von einem Raspberry Pi B+ auf einen Pi 3 B hochgerüstet. Neues Raspbian Image (Jessie) und FHEM neu installiert. Seitdem habe ich das Problem das der JeeLink ständig die Verbindung verliert und keine Daten mehr empfängt. Ich habe mir schon Abhilfe geschafft mit dem "timeout" Attribut, so das ich den reset nicht mehr automatisch durchführen muss, aber vielleicht hat ja noch jemand einen Tipp an was es liegen könnte.
Das Modul ist bereits via serial-by-id eingebunden, am anderen USB-Port kann es also nicht liegen.
2016.03.22 23:06:27 3: Opening JeeLinkLaCrosse device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.03.22 23:06:27 3: Setting JeeLinkLaCrosse serial parameters to 57600,8,N,1
2016.03.22 23:06:27 3: JeeLinkLaCrosse device opened
2016.03.23 03:04:32 3: Opening JeeLinkLaCrosse device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.03.23 03:04:32 3: Setting JeeLinkLaCrosse serial parameters to 57600,8,N,1
2016.03.23 03:04:32 3: JeeLinkLaCrosse device opened
2016.03.23 03:52:03 3: Opening JeeLinkLaCrosse device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.03.23 03:52:03 3: Setting JeeLinkLaCrosse serial parameters to 57600,8,N,1
2016.03.23 03:52:03 3: JeeLinkLaCrosse device opened
2016.03.23 05:04:04 3: Opening JeeLinkLaCrosse device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.03.23 05:04:04 3: Setting JeeLinkLaCrosse serial parameters to 57600,8,N,1
2016.03.23 05:04:04 3: JeeLinkLaCrosse device opened
2016.03.23 05:37:35 3: Opening JeeLinkLaCrosse device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.03.23 05:37:35 3: Setting JeeLinkLaCrosse serial parameters to 57600,8,N,1
2016.03.23 05:37:35 3: JeeLinkLaCrosse device opened
2016.03.23 09:42:40 3: Opening JeeLinkLaCrosse device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.03.23 09:42:40 3: Setting JeeLinkLaCrosse serial parameters to 57600,8,N,1
2016.03.23 09:42:40 3: JeeLinkLaCrosse device opened
Kann es an den USB-Settings des Pi3 liegen?
Hi,
es gab mal ein Problem mit einer Kernelversion:
https://forum.fhem.de/index.php/topic,41836.0.html (https://forum.fhem.de/index.php/topic,41836.0.html)
Evtl. liegt es daran.
Gruß
Maik
Hi,
hast Du auch das Netzteil hochgerüstet? 2 A sollte es schon sein.
LG
/robin
Hallo zusammen,
ich hoffe meine Frage ist hier richtig. 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.
Seit irgendwann tauchen plötzlich komische readings auf wie z.B. windspeed. Anbei mal ein List.
Internals:
DEF 08
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2016-03-24 08:58:01
MSGCNT 31158
NAME KZ.Thermo
NR 211 STATE T: 18.3 H: 36 D: 3
TYPE LaCrosse
addr 08 battery_new 0
corr1 0
corr2 0
myJeeLink_MSGCNT 31161
myJeeLink_RAWMSG OK 9 8 1 4 159 36
myJeeLink_TIME 2016-03-24 08:58:01
previousH 36
previousT 18.3 s
ensorType 0=T(H)
Readings:
2016-03-24 08:58:01 battery ok
2016-03-24 08:58:01 dewpoint 3.0
2016-03-24 08:58:01 humidity 36
2016-02-08 03:53:59 rain 1060.5
2016-03-24 07:59:55 statHumidityTendency 1h: +1 2h: -2 3h: -3 6h: -3
2016-03-24 07:59:55 statTemperatureTendency 1h: +2.2 2h: +0.4 3h: +0.2 6h: +0.1
2016-03-24 08:55:51 state T: 18.3 H: 36 D: 3 2016-03-24 08:58:01 temperature 18.3
2016-02-08 03:53:59 windDirectionDegree 292.5
2016-02-08 03:53:59 windDirectionText WNW
2016-02-08 03:53:59 windGust 2.8
2016-02-08 03:53:59 windSpeed 20.9
Helper:
_98_statistics statistic_KZ.Thermo
Attributes:
IODev myJeeLink
doDewpoint 1 event-min-interval state:600
group Temperaturen room Kinderzimmer,LaCrosse
Kann mir jemand sagen, woher die Daten kommen?
Hat ein Nachbar eine neue Wetterstation in Betrieb genommen? Oder es wurde bei dir neue Firmware installiert, die nun auch die Wetterstationsdaten auswerten kann.
Wenn es zu Empfangsproblemen kommt, musst du bei deinen betreffenden Sendern, mal die Batterie entfernen, damit die eine neue ID sich aussuchen.
Gruß
Maik
Zitat von: istler am 24 März 2016, 10:03:45
Hat ein Nachbar eine neue Wetterstation in Betrieb genommen?
nicht das ich wüsste, wobei es nicht ausgeschlossen ist. Aber eigentlich ist die Entfernung zu groß.
ZitatOder es wurde bei dir neue Firmware installiert, die nun auch die Wetterstationsdaten auswerten kann.
Ich habe dem JeeLink keine neue Firmware verpasst und automatisch geht das nicht oder?
Zitat von: skuggy am 24 März 2016, 09:29:00
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.
Vielen Dank für die Info, dann werde ich die Readings einfach löschen...
Zitat von: HCS am 24 März 2016, 13:16:37
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
Zitat von: fh168 am 23 März 2016, 18:05:16
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.
Hast du den von mir aus meiner Testumgebung?
LG
/robin
Hat es schon jemand geschafft die ID an einem TX37-IT zu ändern?
Zitat von: rretsiem am 31 März 2016, 10:02:18
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.
Zitat von: Fredi69 am 04 April 2016, 21:43:03
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.
Zitat von: chrissi323 am 05 April 2016, 08:38:08
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. :D
Zitat von: Hollo am 07 April 2016, 09:07:18
Manche "Probleme" kommen und gehen bei regelmäßigen Updates. :D
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 nichtsDas 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:
ZitatDuring 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.
Zitat von: HCS am 07 April 2016, 17:26:34
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. 8) 8) 8)
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
Zitat von: HCS am 07 April 2016, 17:26:34
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. ;D ;D ;D
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.
Zitat von: Hollo am 07 April 2016, 21:44:58
... 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"
Zitat von: HCS am 08 April 2016, 09:56:01
...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. :-X
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 (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:
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:
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.
versuche es mal mit
define 01Thermo LaCrosse 25
Zitat von: fh168 am 13 April 2016, 17:54:38
versuche es mal mit
define 01Thermo LaCrosse 25
Hi,
define 01Thermo
myJeeLink 25
Bitte LaCrosse durch myJeeLink ersetzten.
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 myJeeLinkpejonp
yep, danke pejonp, da war ich zu schnell.
Zitat von: pejonp am 13 April 2016, 18:01:34
define 01Thermo myJeeLink 25
und was soll das dann werden?
Zitat von: fh168 am 13 April 2016, 18:02:53
yep, danke pejonp, da war ich zu schnell.
Bitte gerngeschehen.
pejonp
Wollt ihr das mal testweise eingeben?
Also nach dem gefühlten hundersten mal hat FHEM den Sensor jetzt automatisch angelegt, allerdings mit 29
In der FHEM Config steht nun:
define LaCrosse_29 LaCrosse 29
Der Name meines JeeLinks ist "myJeeLink", angelegt wurde es aber wie gesagt mit "LaCrosse".
Funktionieren tut es, bekomme alle Werte..also gehe ich mal davon aus, es ist nun korrekt so.
Bleibt die ID eigentlich bei Batteriewechsel oder muss dann wirklich immer neu angelernt werden?
Vielen Dank euch.
Zitat von: HCS am 13 April 2016, 18:19:50
Wollt ihr das mal testweise eingeben?
Hallo HCS,
so sehen meine define für LaCross aus:
define J1 JeeLink /dev/jeelink@57600
attr J1 flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr J1 initCommands 7t 3m v
attr J1 verbose 0
define 0.Strasse_Temperatur LaCrosse 08
attr 0.Strasse_Temperatur IODev J1
attr 0.Strasse_Temperatur room Haus-Temp,LaCrosse
define FileLog_0.Strasse_Temperatur FileLog ./log/0.Strasse_Temperatur-%Y-%m.log 0.Strasse_Temperatur
attr FileLog_0.Strasse_Temperatur logtype text
attr FileLog_0.Strasse_Temperatur room LaCrosse
richtig müsste es lauten:
define 01Thermo
LaCrosse 25
attr 01Thermo IODev
myJeeLinkDanke HCS.
pejonp
Zitat von: pejonp am 13 April 2016, 18:27:46
richtig müsste es lauten:
define 01Thermo LaCrosse 25
attr 01Thermo IODev myJeeLink
Er hat die Batterien raus gehabt, darum hat auch die 25 nicht mehr gestimmt.
Zitat von: errazzor am 13 April 2016, 18:27:21
Also nach dem gefühlten hundersten mal hat FHEM den Sensor jetzt automatisch angelegt, allerdings mit 29
Der 30t in den InitCommands ist auch nicht hilfeich, ein 1r wäre besser.
Und ob die Frequenz genau passt ist auch noch eine Frage
Zitat von: errazzor am 13 April 2016, 18:27:21
Bleibt die ID eigentlich bei Batteriewechsel oder muss dann wirklich immer neu angelernt werden?
Bleibt nicht erhalten, kann aber nach einem Batteriewechsel automatisch aktualisiert werden.
Siehe commandref -> replaceBatteryForSec
Aber die Frage stellt sich erst in einem Jahr oder so. ;D
du hast ein device für den jeelink und pro sensor ein device.
wenn sich die id beim batterie wechsel ändert kannst du das in fhem mit dem replaceBatteryForSec kommando abfangen. das kannst du sogar auf einen mausklick z.b in einer readingsGroup die den batterie zustand anzeigt legen.
gruss
andre
Gut, dass zumindest zwei einer Meinung sind ;D :D
du warst nur schneller :)
Ok, habe mir jetzt eine Readingsgroup mit dem klickbaren Icon für replaceBattery gebaut - coole Sache! Danke für den Hinweis.
Habe weiterhin entdeckt, dass der von mir verwendete 30.3155 der wohl ungeeignetste ist...da ich mir noch weitere Fühler zulegen möchte, habe ich mir jetzt diese ausgekuckt:
TX35DTH-IT 9.579 kbps
Die würden dann zumindest auf der (hoffentlich) gleichen Frequenz wie der 30.3155 senden.
Findet ihr die TX35 ok oder gibt es Gründe für ein anderes Modell?
Zitat von: errazzor am 13 April 2016, 19:31:49
Habe weiterhin entdeckt, dass der von mir verwendete 30.3155 der wohl ungeeignetste ist...
Ja
Zitat von: errazzor am 13 April 2016, 19:31:49
... habe ich mir jetzt diese ausgekuckt:
TX35DTH-IT 9.579 kbps
Die würden dann zumindest auf der (hoffentlich) gleichen Frequenz wie der 30.3155 senden.
9.579 kbps ist die data rate. Die Frequenz (die Du eingestellt hast) ist 868280 kHz wobei die LaCrosse Sensoren eigentlich auf 868300 senden.
Ich habe aber auch zwei 30.3155 die etwas daneben liegen.
Eventuell musst Du mit der Frequenz ein wenig probieren, um beide Sorten zu empfangen.
Ich habe hier u.A. zwei TX35DTH-IT laufen, die funktionieren bei mir problemlos.
@HCS
Zitat
Option 1 (Dual RFM):
Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
Der zweite RFM wird parallel zum ersten angeschlossen (Antenne natürlich eine eigene), nur NSS (also der Chipselect) wird am Arduino an PB0 angeschlossen (siehe angehängte SuperJee-CL.png)
Der Sketch erkennt automatisch, ob der zweite RFM angeschlossen und ob es ein 12er oder 69er ist und verwendet ihn dann entsprechend.
Um den zweiten RFM zu konfigurieren, werden folgende Commands (die natürlich in InitCommands gesetzt werden können) verstanden:
R - DataRate
F - Frequenz
M - Toggle Mode
T - Toggle Time
Das entspricht den Commands wie bisher für den ersten RFM, nur dass es Großbuchstaben sind.
Habe mir meinen jeelink 868 mit einem 2. Rfm12b zusammen gelötet.
Du schreibst oben, dass chipselect von dem 2. An den pb0 vom Arduino muss.
Ich verwende einen arduino nano. Da finde ich keinen pb0 Anschluss.
Kannst du mir da weiter helfen?
Greez Sascha
Siehe Bild
D8. Sehe ich das richtig?
Danke
Gesendet von meinem SM-T560 mit Tapatalk
D8 von nano mit nSEL (Chip select) vom rfm12b verbinden?
Gesendet von meinem SM-T560 mit Tapatalk
Zitat von: sash.sc am 22 April 2016, 14:22:02
D8 von nano mit nSEL (Chip select) vom rfm12b verbinden?
Gesendet von meinem SM-T560 mit Tapatalk
Habe es gelötet. Der zweite rfm12b wird auch erkannt, aber mit 868 MHz. Der 2.ist aber ein 433 MHz. Klappt das nicht mit 433 und 868 MHz zusammen?
Gruß Sascha
Gesendet von meinem SM-T560 mit Tapatalk
Ein RFM ist von der Software nicht als 433 oder 868 MHz RFM zu erkennen.
Musst für einen mit dem f command die Frequenz setzen.
Was willst Du denn auf 433MHz eigentlich empfangen?
Temp. Sensoren. , Wetterstation, etc....
Danke für die Hilfe
Gesendet von meinem SM-T560 mit Tapatalk
Zitat von: sash.sc am 22 April 2016, 15:24:57
Temp. Sensoren. , Wetterstation, etc....
Dir ist aber schon klar, dass der Sketch nicht einfach irgend etwas empfangen kann, wofür er nicht geschrieben wurde?
Ich habe (und kenne) nichts, das er auf 433MHz empfängt
Die beiden rfm12b parallel laufen zu lassen war auch nur ne idee. Habe noch 2 Sensoren die mit nix, was ich habe, empfangen werden. Deshalb 433 und 868 MHz parallel. Spart man sich einen USB Port am raspi! ;-)
Gesendet von meinem SM-T560 mit Tapatalk
Hallo,
habe heute meinen JeeLink erhalten. Und direkt in Fhem mit LaCrosse erfolgreich geflasht.
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
Status ist immer initialized. Habe noch kein JeeLink Sensor, habe aber mal ein set myJeeLink LaCrossePairForSec 120 ignore_battery gemacht. Danach steht in den Internals bei LaCrossePair: die Ziffer "2".
es wird aber nichts neues angezeigt. Kein "LaCrosse-Raum". Da ich hier sehr dicht bebaut wohne dachte ich ich könnte vielleicht irgendwas empfangen..
Danke und Gruß
Christoph
Hallo zusammen, ich habe ein kleines Problem. Ich habe 2 "TX 29 DTH" an meinem jeelink laufen. Diese tun ihren Dienst auch ohne Murren.
Nun habe ich seit gestern noch eine WS1600 mit dem TX22.
Ich bekomme es momentan nicht hin, das der TX22 erkannt wird. Mein Jeelink ist wie folgt konfiguriert:
define myJeeLink JeeLink /dev/ttyUSB0@57600
attr myJeeLink flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr myJeeLink initCommands 5m 30t v
attr myJeeLink room System
Allerding wird nach dem PairforSeconds Kein neues Gerät angelegt, über Autocreate.
Habt ihr eine Idee?
Danke
Marcel
Ist die WS1600 denn in Funkreichweite?
Stelle mal deine Basisstation neben deinen Jeelink um das zu prüfen.
Dann kann es sein das durch den Toggle-Mode die Signale der WS am Anfang "verpasst" werden.
Stelle mal den Jeelink nur für die Wetterstation ein und lasse das pairing mal 5 Minuten laufen.
Wenn dann die WS erkannt ist und das Device angelegt kannst du ja wieder zurückstellen.
Wichtig ist das du die ID der Wetterstation im Log stehen hast.
Dann kannst du sie zur Not auch von Hand eintragen.
Ach so ... die WS1600 sendet nur ca. 15 Minuten lang nach dem Einschalten alle paar Sekunden.
Danach sendet sie nur noch das was sich verändert.
Also Pairing ist im Prinzip nur 15 Minuten nach dem "batterieeinlegen" in den Sender sinnvoll möglich.
Ok danke für die schnelle Rückmeldung. Dann muss ich jetzt nochmal eine etwas doofe Frage stellen. Welcher von beiden sendet denn, bzw wird gepairt? Die Station oder der TX22?
Die Basisstation ... also das mit dem Display ... ist der Empfänger.
Der Sender ist das wo du den Wind- und Regenmesser mit dem Kabel anschliest.
Ja aber welcher von beiden wird mit dem Jeelink gepairt?
Der Sender
Kommt drauf an. Vielleicht hat LaCrosse ja inzwischen eine Station im Programm, bei der man an der Zentrale das Wetter einstellen kann - das müsste dann natürlich den Sensoren mitgeteilt werden ;)
LG
pah
So langsam komme ich ins zweifeln. Habe es jetzt noch einmal probiert. Habe den Jeelink auf 2r gestellt und dann mal 5min pairen lassen.
-> Leider ohne Ergebnis. Kein neuer Eintrag über AutoCreate.
Der Jeelink ist wie folgt konfiguriert:
Clients:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 10
NAME myJeeLink
NR 60
RAWMSG OK 9 28 1 4 208 39
STATE initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:8842)]
myJeeLink_MSGCNT 1
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 2r v
room System
Hallo mordrad,
hatte ein ähnliches Problem und habe es dann mit dem
initCommands 7m 2p 868260f v 30t geschafft.
Ich habe die Frequenz solange verändert, bis ich den Eintrag hatte.
Gruß rippi
Danke für den Tipp. Jetzt schreibt er mir fleißig sowas ins LOG:
2016-05-03 20:38:05 JeeLink myJeeLink UNKNOWNCODE 5E 45 3E 6A 17 8A B8 5B A2 34 BC D3 58 DA 6E B F8 E2 12 B 16 A8 73 6F C2 C1 9F FD 2F 46 20 B1 4C 46 3B AB 46 15 B1 50 F0 9 EA 44 89 84 BE FD FF 77 DE FA 2A 39 E7 76 36 98 6B 2 52 FA DB 65
2016.05.03 20:38:05 3 : myJeeLink: Unknown code 5E 45 3E 6A 17 8A B8 5B A2 34 BC D3 58 DA 6E B F8 E2 12 B 16 A8 73 6F C2 C1 9F FD 2F 46 20 B1 4C 46 3B AB 46 15 B1 50 F0 9 EA 44 89 84 BE FD FF 77 DE FA 2A 39 E7 76 36 98 6B 2 52 FA DB 65 , help me!2016-05-03 20:38:10 JeeLink myJeeLink UNKNOWNCODE AB 75 6 64 10 40 20 0 30 FE 41 FE 48 0 3E 83 22 BC 3A F4 A9 8 82 91 3B C7 60 9B 5C DD 50 FE C3 2F A6 82 D6 1A A3 63 3A 92 6E BF B3 81 CB 1C FF BD AA 14 1E 75 EF 86 A 36 B2 F9 34 F7 19 CA
2016.05.03 20:38:10 3 : myJeeLink: Unknown code AB 75 6 64 10 40 20 0 30 FE 41 FE 48 0 3E 83 22 BC 3A F4 A9 8 82 91 3B C7 60 9B 5C DD 50 FE C3 2F A6 82 D6 1A A3 63 3A 92 6E BF B3 81 CB 1C FF BD AA 14 1E 75 EF 86 A 36 B2 F9 34 F7 19 CA , help me!2016-05-03 20:38:15 JeeLink myJeeLink UNKNOWNCODE AB 75 6 64 10 40 20 0 30 FE 41 FE 48 0 1B 9B A6 A9 AF A3 36 84 8C 30 16 3A B2 4A 83 ED C3 2B 18 BE F4 8E 16 52 54 44 7E 93 81 A BB 0 DB A5 80 DB 40 91 A6 D6 33 7D 30 6A 95 1D 60 9C 20 FD
Soll ich jetzt die ganzen möglichen Frequenzen durchgehen?
Ich habe in 10er Schrtten solange erhöht, bis ich so etwas wie OK WS ........ stehen hatte.
Zitat von: rippi46 am 03 Mai 2016, 20:07:40
initCommands 7m 2p 868260f v 30t geschafft.
Das 2p gehört da nicht rein. Das ist der Grund für den Datenwust, den mordrad nun empfängt.
Damit kann es unmöglich funktionieren.
Der JeeLink funktioniert generell mal, in Deinem List steht ein "RAWMSG OK 9 28 1 4 208 39" drin. Das ist ein LaCrosse Sensor, z.B. ein TX29DTH, der 23.2°C und 39% Feuchte sendet.
Die WS 1600 sendet mit einer DataRate von 8842 kbps auf 868300 und es gab bisher keine Anzeichen, dass welche mit der Frequenz daneben liegen.
Die initCommands "2r v" waren richtig.
Also wieder zurück und JeeLink abziehen und neu stecken, dass dass er das p vergisst.
Wenn die Batterien schon länger im TX22 drin sind, dann sendet er kein newBattery-Flag mehr, pairing muss man dann mit:
set myJeeLink LaCrossePairForSec 120 ignore_battery
Wenn Du ein Laptop mit einem Terminalprogramm hast, dann steck den JL dran, stelle 57600 baud ein, sende ihm ein 2r und marschiere zum TX22 um sicher in der Reichweite zu sein.
Daten vom TX22 sehen so aus: OK WS 7 1 255 255 74 5 59 10 140 0 10 255 255 0
Hallo HCS,
sollte natürlich 2r sein und nicht 2p.
Die Autokorrektur des Handy hat zugeschlagen.
Gruß rippi.
PS: hatte tatsächlich bei mir 2p stehen; funktionierte aber trotzdem seit 2 Monaten so. Hatte mit der Option 1p probiert und vermutlich dann aus 1p ein 2p gemacht anstatt 2r.
in 7m ist ja eigentlich 2r enthalten.
Hallo,
ich hab einen Nano+RFM69W als Clone zusammengebastelt.
Flashen über fhem funktionierte. Leider bleibt der STATE auf opened und nicht auf initialized.
Funktioniert das mit dem RFM69W nicht, muss es der RFM69CW sein?
Ich dache nur die Pinbelegung ist anders bzw. beim 69W ein DIO mehr ?
edit:
Sorry avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE] war falsch,
es musste lauten:
avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
und schon gehts !
Hallo zusammen,
ich habe auch ewig gesessen und hier schon gelesen, da ich mit dem Jeelink v3c auch nicht klarkomme. Nach ewigen Probieren lief der flashvorgang durch und ich konnte meine TL29DTH-it auf die ich ewig gewartet habe endlich anlegen. Funktionierte auch prima. Wollte nun noch einen anlernen bzw. pairen - nix geht mehr keine aktuellen Readings.
Ich hab den Stick nochmal geflasht. Die Modellbezeichnung war beim ersten mal wo es lief glaube RFM96 zumindest anders.
Internals: Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 20
NAME myJeeLink
NR 118
PARTIAL
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 t:7~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-05-06 19:50:24 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 7t 3m v
vielleicht hat ja jemand ne Idee oder ist das Teil defekt?
Zitat von: -Floh- am 06 Mai 2016, 20:12:30
Ich hab den Stick nochmal geflasht. Die Modellbezeichnung war beim ersten mal wo es lief glaube RFM96 zumindest anders.
Ja, sollte eigentlich einen RFM69 melden. Wenn es den nicht erkennt, dann geht es von einem RFM12 aus, was dann natürlich nicht funktioniert, wenn auf dem Stick ein RFM69 drauf ist.
Einen defekten Stick kann man natürlich nicht ausschließen.
Zitat von: -Floh- am 06 Mai 2016, 20:12:30
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 7t 3m v
Die initCommands 7t 3m v sind eher nicht so gut.
Der toggle mit 7 Sekunden ist zu kurz. 30 wäre sinnvoller.
Wenn Du nur TX29DTH hast, brauchst Du gar keine initCommands.
Also: erst mal das initCommands Attribut löschen und dann den Stick abziehen und wieder stecken.
Was auch ein beliebtes Problem ist: Spannungsversorgung auf dem USB-Port. Ggf. mal auf einem anderen Rechner probieren.
Hallo HCS,
Habe die initCommand gelöscht und neu verbunden. Hat prima funktioniert. Der JeeLink hat wieder RFM69 und die Readings stimmen auch wieder.
Danke für die schnelle Hilfe. :)
Grüße Jörg
Zitat von: HCS am 07 April 2016, 17:26:34
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.
Um das für mich zum Abschluss zu bringen. Offensichtlich hat es wirklich den Clone zerlegt, ein originaler Jeelink funktioniert nach Einstecken und flashen sofort und auf Dauer stabil. Der Empfang ist auch besser.
Ich hatte bei dem Clone das Funkmodul direkt angeschlossen, vielleicht ist es wirklich so, dass es auf die Dauer die fünf Volt nicht verträgt. Wenn das jemand genauer analysieren will, stelle ich meinen krude zusammengedengelten Clone gerne zur Verfügung.
Sorry für die späte Rückmeldung, aber die Lieferung des Originals hat etwas gedauert :-)
Chrissi
Ohne dass ich nun alle Seiten durchlesen muss...ist der WS1600 der einzige Windmesser der mit dem Jeelink funktioniert? Falls ja, was sind die Langzeiterfahrungen damit? Taugt das Ding etwas? Ich möchte die Windstärke und Winrichtung über einen längeren Zeitraum aufzeichnen.
Vielen Dank für eure Rückmeldungen.
Gruss
Alen
Mein WS-1600 funktioniert seit ziemlich genau einem Jahr ohne Probleme. Zur Windrichtung kann ich allerdings nichts sagen. Das Teil hängt dafür zu dicht am Haus.
Zitat von: alen am 10 Mai 2016, 16:06:48
Ohne dass ich nun alle Seiten durchlesen muss...ist der WS1600 der einzige Windmesser der mit dem Jeelink funktioniert? Falls ja, was sind die Langzeiterfahrungen damit? Taugt das Ding etwas? Ich möchte die Windstärke und Winrichtung über einen längeren Zeitraum aufzeichnen.
Theoretisch geht die WS 1080 noch. Aber die ist heikel, weil es sie unter gleichem Namen in zwei Versionen gibt, von denen nur eine mit diesem Sketch funktioniert.
Ich rate davon ab, eine zu kaufen, ist eher für Leute, die schon eine haben und mal schauen können, ob sie passt.
Die WS 1600 habe ich seit recht genau einem Jahr auf dem Dach und sie funktioniert noch problemlos. Das Maximum an Wind war gemäß Log etwas um die 80 Km/h, was sie bei mir aushalten musste.
Billy (glaube ich) ist der Ansicht, dass der Regenmesser nicht besonders genau geht. Mangels Vergleichsmöglichkeit kann ich es nicht beurteilen.
An Genauigkeit darf man aber von Stationen in dieser Preisklasse auch keine Wunder erwarten.
Im Wesentlichen hängt es davon ab, wozu man die Daten überhaupt braucht. Mich interessiert hauptsächlich die grobe Windrichtung und ob es windstill, etwas windig oder stürmisch ist und dafür ist sie OK.
Wie viele weitere Winter und Stürme sie überleben wird? Keine Ahnung.
Zitat von: chrissi323 am 10 Mai 2016, 13:35:25
... ein originaler Jeelink funktioniert nach Einstecken und flashen sofort und auf Dauer stabil. Der Empfang ist auch besser.
Schön, dass es jetzt funktioniert.
Zitat von: chrissi323 am 10 Mai 2016, 13:35:25
Ich hatte bei dem Clone das Funkmodul direkt angeschlossen ...
Ja, es ist echt übel, dass es Anleitungen gibt, die das so beschreiben.
Ich muss euch jetzt nochmal nerven.
Habe jetzt nochmal die Zeit gefunden, dass mit der WS1600 in Angriff zu nehmen.
Habe den Jeelink abgezogen und neu angeschlossen.
Dann mit set myJeeLink LaCrossePairForSec 120 ignore_battery ein pairen gestartet.
Leider ohne Erfolg.
Es wird kein neues Device angelegt. Habt ihr noch eine Idee?
Zitat von: mordrad am 16 Mai 2016, 14:19:34
Ich muss euch jetzt nochmal nerven.
Habe jetzt nochmal die Zeit gefunden, dass mit der WS1600 in Angriff zu nehmen.
Habe den Jeelink abgezogen und neu angeschlossen.
Dann mit set myJeeLink LaCrossePairForSec 120 ignore_battery ein pairen gestartet.
Leider ohne Erfolg.
Es wird kein neues Device angelegt. Habt ihr noch eine Idee?
Häng mal ein list myJeeLink hier an.
Gerne, hier das Ergebnis:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 10
NAME myJeeLink
NR 60
PARTIAL
RAWMSG OK 9 28 1 4 220 35
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:8842)]
myJeeLink_MSGCNT 9
myJeeLink_TIME 2016-05-16 14:13:21
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-05-16 14:13:21 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 2r v
room System
Zitat von: mordrad am 16 Mai 2016, 18:22:37
Gerne, hier das Ergebnis:
Das ist alles korrekt so.
Stell mal das JeeLink device eine Zeit lang auf verbose 5 und schau dann im FHEM-Log, ob so etwas auftaucht:
OK WS 7 1 255 255 74 5 59 10 140 0 10 255 255 0
Entscheidend ist, dass es mit "OK WS" beginnt.
Ja sowas wirft er raus:
2016.05.16 19:51:45 5 : JeeLink/RAW: /OK WS
2016.05.16 19:51:45 5 : JeeLink/RAW: OK WS /35 1 4 223 36 0 0
2016.05.16 19:51:45 5 : JeeLink/RAW: OK WS 35 1 4 223 36 0 0/ 255 255
2016.05.16 19:51:45 5 : JeeLink/RAW: OK WS 35 1 4 223 36 0 0 255 255 /255 255 255 255
2016.05.16 19:51:45 5 : JeeLink/RAW: OK WS 35 1 4 223 36 0 0 255 255 255 255 255 255 /0
2016.05.16 19:51:45 5 : myJeeLink dispatch OK WS 35 1 4 223 36 0 0 255 255 255 255 255 255 0
2016.05.16 19:51:45 4 : LaCrosse: Unknown device 23, please define it
Zitat von: mordrad am 16 Mai 2016, 19:52:29
2016.05.16 19:51:45 5 : myJeeLink dispatch OK WS 35 1 4 223 36 0 0 255 255 255 255 255 255 0
2016.05.16 19:51:45 4 : LaCrosse: Unknown device 23, please define it
Das sieht schon mal gut aus. Keine Ahnung, warum autocreate bei Dir nicht funktioniert.
Leg sie von Hand an mit:
define WS1600 LaCrosse 23
Wunderbar, dass scheint geklappt zu haben. Danke.
Internals:
CFGFN
DEF 23
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2016-05-16 20:14:24
MSGCNT 1
NAME WS1600
NR 1896
STATE T: 24.9 H: 36
TYPE LaCrosse
addr 23
battery_new 0
bufferedH 36
bufferedT 24.9
corr1 0
corr2 0
myJeeLink_MSGCNT 1
myJeeLink_RAWMSG OK WS 35 1 4 225 36 0 0 255 255 255 255 255 255 0
myJeeLink_TIME 2016-05-16 20:14:24
previousH 36
previousR 0
previousT 24.9
sensorType 1=TX22
Readings:
2016-05-16 20:14:24 battery ok
2016-05-16 20:14:24 error 0
2016-05-16 20:14:24 humidity 36
2016-05-16 20:14:24 rain 0
2016-05-16 20:14:24 state T: 24.9 H: 36
2016-05-16 20:14:24 temperature 24.9
Attributes:
IODev myJeeLink
room System
Jetzt muss ich nur noch die TX29 wieder dazu packen.
Zitat von: mordrad am 16 Mai 2016, 20:15:49
2016-05-16 20:14:24 temperature 24.9
Steht die in der Wohnung oder lebst Du in der Karibik?
;) Liegt auf meinem Bürotisch ^^
Funktioniert die Anzeige denn theoretisch noch Parallel? Also auf dem Display?
Zitat von: mordrad am 16 Mai 2016, 20:29:42
Funktioniert die Anzeige denn theoretisch noch Parallel? Also auf dem Display?
Ja.
Zitat von: HCS am 16 Mai 2016, 20:32:53
Ja.
Ok klappt ... Dann also nur noch auf den Wechsel umschalten und dann sollte alles gut sein.
Hallo zusammen
Bei meine Jeelink habe ich 3 Temp/Feuchte Sensoren von Technoline eingebunden. Funktioniert super. Und sehe ich aber in meinem logfile dauernd Einträge von unbekannten Geräten:
Es sind immer die Id's 13 und 14.
2016.05.09 12:40:51 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:40:55 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:40:59 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:41:53 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:42:02 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:42:10 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:42:47 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:42:51 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:42:56 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:43:00 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:43:15 3: LaCrosse: Unknown device 14, please define it
2016.05.09 12:43:45 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:43:50 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:43:56 3: LaCrosse: Unknown device 14, please define it
2016.05.09 12:43:58 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:44:02 3: LaCrosse: Unknown device 13, please define it
2016.05.09 12:44:06 3: LaCrosse: Unknown device 13, please define it
Gibt es eine Möglichkeit rauszufinden, was das für Sensoren/Geräte sind? Ich habe noch eine Messtation von Oregon mit 3 Sensoren (Einer heisst THGR122N, der andere THGR122NX). Kann es sein, das die zwei Geräte 13/14 sind? Oder könnte es etwas von meinem Nachbar sein...der ist aber mindestens 20m-30m entfernt.
Habe gerade gesehen unter http://www.fhemwiki.de/wiki/RFXtrx dass der THGR122 ebenfalls unter 433Mhz sendet..könnte das der Grund sein weshalb mein Jeelink dieses Signal auch empfängt...aber nix damit anfangen kann?
Gruss
alen
Zitat von: alen am 16 Mai 2016, 23:59:36
Es sind immer die Id's 13 und 14.
Lass sie doch mal anlegen und schaue, was sie für Werte senden, das gibt manchmal einen Hinweis, was es sein könnte.
Zitat von: alen am 16 Mai 2016, 23:59:36
Habe gerade gesehen unter http://www.fhemwiki.de/wiki/RFXtrx dass der THGR122 ebenfalls unter 433Mhz sendet..könnte das der Grund sein weshalb mein Jeelink dieses Signal auch empfängt...aber nix damit anfangen kann?
Hast Du einen 433 JeeLink?
Wenn nicht, dann empfängt er auch nichts auf 433.
Hallo,
ich habe nun soeben meinen 2. Jeelink Clone zusammengelötet.
Nun hab ich mal ne Grundsatzfrage die ich per SUFU nicht lösen konnte, zu der wirksamen Antennenlänge.
Ich baue meine Clones immer auf Lochraster auf, und verwende grundsätzlich LevelShifter und Sockel.
Nun wird die exakte Antennenlänge bei 868 MHz mit 82,2 mm angegeben.
Von wo genau wird dass nun gemessen?
Schaut Euch mal das Foto an:
Dort seht Ihr, das ich den Antennendraht noch etwas über die Platine führen muß um an den Pin für die Antenne des RFM Modul zu kommen.
Die Gesamtlänge meines Drahtes ist nun 82mm. Ist der Teil der auf der Platine verläuft überhaut wirksam (abgesehn von den ca 10mm die der Sockel noch hoch ist)?
Soll ich den Draht ab Platinenkante auf 82mm länge machen ?
Spielen dann die 10mm Sockel ne Rolle ?
Wie ist es optimal ?
Zitat von: Skusi am 29 Mai 2016, 20:18:33
Ich baue meine Clones immer auf Lochraster auf, und verwende grundsätzlich LevelShifter und Sockel.
Wie hast Du den RFM gesockelt?
Zitat von: Skusi am 29 Mai 2016, 20:18:33
Wie ist es optimal ?
Optimal ist, wenn die Antenne mit ihren kompletten 82mm senkrecht gestreckt über einer möglichst guten Massefläche steht.
Aber das ist weder bei einem original JeeLink noch bei den LaCrosse Sensoren so.
Die Faktoren, die den Empfang bestimmen, sind so vielfältig, dass es da auch nicht so elementar drauf ankommt.
siehe auch: https://forum.fhem.de/index.php/topic,45594.msg452932.html#msg452932
Zitat von: HCS am 29 Mai 2016, 20:48:59
Wie hast Du den RFM gesockelt?
Mit Stift- und Buchsenleisten, siehe Foto
Zitat von: HCS am 29 Mai 2016, 20:48:59
Optimal ist, wenn die Antenne mit ihren kompletten 82mm senkrecht gestreckt über einer möglichst guten Massefläche steht.
Also wäre es optimal, wenn ich den Teil der Antenne bis zum Platinenende abschirme, und dann den Draht ab dort mit 82mm ohne Schirm stehen lasse !?
Der Teil der hinter der Platine über die Lötaugen läuft, wird ja sicher durch das Lochraster mindestens zu einer Seite behindert.
Naja, mal sehen ob mir da was praktikabeles einfällt. Mein erster Jeelink läuft schon fast ein Jahr mit der Antenne wie sie auf dem Foto ist. Bisher keine Empfangsprobleme zu den 12 LaCrosse Sensoren im ganzen Haus verteilt.
Aus Antennen kann man mehr Wissenschaft machen als es am Schluss was bringt.
Ich würde die 82mm Antenne schlicht direkt an den RFM löten und irgendwie kunstvoll verlegen, dass sie so frei wie möglich liegt.
Wenn Du das Bild von dem LaCrosse-Sensor anschaust, dann stellst Du fest, dass man da bei der Antennenverlegung auch sehr kreativ war.
Nachtrag: das angehängte Bild, das Forum mag ja eingebunden nicht mehr.
Hi, tolles FHEM-Modul.
Habe einen Jeelink 868 und mehrere TFA-Hygrometer.
Würde gerne mehrere Zimmer mit den Hygrometern ausstatten - was mich allerdings daran stört, ist dass Sie so oft funken - alle 4? Sekunden?
Befürchte hier auch eine Daten-Überlagerung, wenn ich am Ende 5, 6 oder mehr im Haus rum stehen hab.
Gibt es andere Sensoren in Kombination mit Jeelink, die nicht so oft funken, oder gibt es andere Lösungen um die Luftfeuchtigkeit mit FHEM zu monitoren?
Mfg
Markus
Meine Sensoren funken auch alle 4 Sekunden und ich hab 12 davon. Überlagerungsprobleme hab ich noch nicht festgestellt.Aber der eelektro Smog macht mir auch sorgen. Der ganze Rest funkt ja nur wenn man was bedient, aber das funk Feuer der LaGrosse dinger ist schon nicht ohne. Ich sehe mit Sorge wie die LEDs des Jeelink flackern.
Hallo zunächst möchte ich mich bei den Entwicklern für die tolle Arbeit bez. Jeelink bedanken.
Hab den ganzen Thread durchgelesen. JeeLink (v3c) - JeeLink 868 ist auf dem Weg zu mir.
Hab jetzt folgende Frage:
Hab einen TX29IT das sollte funktionieren. Habe aber noch eine "Wetterstation" mit Poolthermometer von TFA. Auf der Packung steht IT+.
Es sind zwei Sender drin 30.3182IT und der Poolthermometer 30.3199.IT. Es gab schon einen anderen Thread https://forum.fhem.de/index.php/topic,24599.30.html (https://forum.fhem.de/index.php/topic,24599.30.html), der aber unergiebig endete.
Im Wiki sind alle getesteten (TFA?) Sensoren (30.xxxx.IT) mit einer Rate von 17.241 kbps (30.3143.IT, 30.3144.IT, 30.3147.IT, 30.3187.IT) angegeben. Kann man davon ausgehen, dass die o.g. Sensoren auch in einem ähnlichen Muster senden, also ggf. zu empfangen sind? Weiss jemand ob IT+ eine hinreichende Spezifikation ist, die einen solchen Sensor prinzipiell "empfangbar" macht.
Gruß docfred
Zitat von: docfred am 07 Juni 2016, 10:29:30
Hab einen TX29IT das sollte funktionieren.
Ja
Zitat von: docfred am 07 Juni 2016, 10:29:30
Es sind zwei Sender drin 30.3182IT und der Poolthermometer 30.3199.IT.
Ich gehe mit großer Wahrscheinlichkeit davon aus, dass sie nicht empfangen werden.
Zitat von: docfred am 07 Juni 2016, 10:29:30
Im Wiki sind alle getesteten (TFA?) Sensoren (30.xxxx.IT) mit einer Rate von 17.241 kbps (30.3143.IT, 30.3144.IT, 30.3147.IT, 30.3187.IT) angegeben. Kann man davon ausgehen, dass die o.g. Sensoren auch in einem ähnlichen Muster senden, also ggf. zu empfangen sind?
Nein, nicht unbedingt.
Zitat von: docfred am 07 Juni 2016, 10:29:30
Weiss jemand ob IT+ eine hinreichende Spezifikation ist, die einen solchen Sensor prinzipiell "empfangbar" macht.
Meiner Meinung nach: Nein.
Die verschiedenen Sensoren, die ich implementiert habe, senden teils unterschiedliche Protokolle, Datenraten, usw.
Meine (etwas scherzhafte) Meinung: IT+ sagt nur aus, dass es recht oft irgendwo bei 868300 kHz sendet, üblicherweise mit FSK.
Ich habe hier einen 30.3181.
IT liegen und es bisher nicht geschafft, auch nur ansatzweise etwas von ihm zu empfangen.
Vielen Dank für die prompte Antwort. Das hört sich sehr ernüchternd an. Ich hatte jetzt gedacht, das TFA für seine Sensoren ein "vergleichbares" Protokoll verwendet
Werde trotzdem mal testen, ob ich was geliefert bekomme.
P.S. hab mal bei TFA geschaut, welcher IT+ 868MHz Sensor mit welcher Station kompatibel ist. Leider scheint es da eine babylonische Sprachverwirrung zu geben, da manche Sensor
en anscheind nur zu einer Station kompatibel sind, obwohl alle IT+ 868 sind.
Zitat von: docfred am 07 Juni 2016, 13:43:52
P.S. hab mal bei TFA geschaut, welcher IT+ 868MHz Sensor mit welcher Station kompatibel ist. Leider scheint es da eine babylonische Sprachverwirrung zu geben, da manche Sensor
en anscheind nur zu einer Station kompatibel sind, obwohl alle IT+ 868 sind.
Eben. Wenn IT+ == IT+ wäre, dann müsste jeder Sensor mit jeder Station gehen, was definitiv nicht der Fall ist.
Im Erfinden von Protokollen und Datenraten sind die ganz groß. Ich habe den Verdacht, dass das Methode hat, verstehe nur noch nicht warum.
Eigentlich gehört da eine ISO Norm her ;D ;D
Kompatibilität laut TFA-Webseite (Anhang). Wäre toll wenn du deine Sensor zum laufen bringen würdest, dann läuft der Poolsensor vielleicht auch.
Zitat von: docfred am 07 Juni 2016, 17:09:55
Wäre toll wenn du deine Sensor zum laufen bringen würdest, dann läuft der Poolsensor vielleicht auch.
Die Chance ist gering, da habe ich schon erfolglos Stunden mit zugebracht.
Da müsste jemand ermitteln, was für ein RF-Chip in dem Ding drin ist und auf dem SPI-Bus mit einem Analyzer die Initialisierungssequenz mitschneiden, dann könnte man der Sache näher kommen.
Hallo,
kann mir jemand sagen, ob der La Crosse TX34-IT Regensensor mit dem Jeelink funktioniert?
Danke und Grüße,
Jörg
Hallo alles zusammen ich habe da mal ne kurze Frage habe es endlich hinbekommen meine WS1600 Wetterstation einzubinden.
An alle die es auch probieren und bei denen es nicht klappt der Knackpunkt war das ausstecken und wieder einstecken vom Jeelink damit er die initCommands übernimmt.
Ich nutze noch die TX 29 DTH - IT.
zur Hardware
Jeelink
Raspberry pi2
FHEM auf neustem stand
Nun die Frage lasse es momentan im Toggel Mode mit dem attr "5m 30t 0a v" laufen.
Das heißt ja wen ich alles richtig verstanden habe das alle 30 sec zwischen 17xxx und 8xxx gewechselt wird.
Ist es möglich das auch asynchron zu machen also z.b. 50 sec 8xxx und 10 sec 17xxx???
Habe mir auch noch bei ELV die WS1080 bestellt mal schauen welche Version da kommt hoffe ja auf die FSK-Version aber mal schauen rechne schon damit das ich die wieder zurück schicken muss.
Gruß
Dennis
Zitat von: Blablubblaber am 15 Juni 2016, 19:06:23
Nun die Frage lasse es momentan im Toggel Mode mit dem attr "5m 30t 0a v" laufen.
Das heißt ja wen ich alles richtig verstanden habe das alle 30 sec zwischen 17xxx und 8xxx gewechselt wird.
Richtig verstanden
Zitat von: Blablubblaber am 15 Juni 2016, 19:06:23
Ist es möglich das auch asynchron zu machen also z.b. 50 sec 8xxx und 10 sec 17xxx???
Nein
Eine Alternative wäre z.B. das LaCrosseGateway, das kann drei RFM69 und damit mehrere data rates gleichzeitig empfangen, ohne toggeln zu müssen
http://www.fhemwiki.de/wiki/LaCrosseGateway
hallo alle zusammen
ich habe mit die WS1080 bei ELV bestellt zum testen.
Im Batterie Fach ist mittlerweile ein Aufkleber mit dem text "PASS 14C"
Auf der Platine steht "WHP0063F1V04" falls das jemandem was sagt.
Habe es getestet mit der Version 5.7 von Fhem und dem Sketch [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~5)]
Leider ohne Erfolg. :(
Auch wenn ich Vermute die Antwort wird geht nicht sein ist es möglich die Station funktionstüchtig zu bekommen wenn nicht muss ich sie nämlich wieder zurück schicken.
Gruß
Dennis
@HCS wäre es möglich in das jeelink Modul eine Definition einzubauen für "minsecs"?
Diese Definition gibt es z. B im cul_tx Modul für tfa Sensoren.
Dies besagt das erst nachdem minsecs abgelaufen sind, dass nächste Signal wieder gültig ist!?
Gruß Sascha
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 17 Juni 2016, 18:01:58
@HCS wäre es möglich in das jeelink Modul eine Definition einzubauen für "minsecs"?
Das JeeLink Modul gehört justme1968
Ok, sorry
Von mobil gesendet daher kurze Antwort
Dann nochmal..... ;-)
@justme1968 wäre es möglich in das jeelink Modul eine Definition einzubauen für "minsecs"?
Diese Definition gibt es z. B im cul_tx Modul für tfa Sensoren.
Dies besagt das erst nachdem minsecs abgelaufen sind, dass nächste Signal wieder gültig ist!?
Gruß Sascha
was genau soll denn das attribut machen was mit event-min-interval nicht geht?
gruss
andre
ich habe ein Problem mit der WS1600 Wetter Station oder besser mit den Readings die es mir anzeigt aber seht selbst.
Fhem Version: 5.7
Sketch eigentlich Version 10.1q
Aber da stimmt glaube ich auch etwas nicht denn es Zeit mir auch nicht mehr den Punkt "model" an wo normal steht welcher sketch drauf ist Bild dazu auch im Anhang.
Ist das Problem schon bekannt?
Zitat von: Blablubblaber am 18 Juni 2016, 22:57:24
Aber da stimmt glaube ich auch etwas nicht denn es Zeit mir auch nicht mehr den Punkt "model" an wo normal steht welcher sketch drauf ist Bild dazu auch im Anhang.
Das liegt daran, dass der STATE "opened" und nicht "initialized" ist.
Setz mal ein
set myJeeLink resetab, ob es dann "initialized" wird und nach einem refresh der Page in FHEM das model da ist.
habe den Reset und das refresh gemacht leider hat sich nichts geändert.
habe gerade noch verbose auf 5 gesetzt und nochmal ein Reset gemacht hier der Auszug aus dem log
2016.06.20 10:26:11 3: Opening myJeeLink device /dev/ttyUSB0
2016.06.20 10:26:11 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.06.20 10:26:11 3: myJeeLink device opened
2016.06.20 10:26:32 5: JeeLink/RAW: /OK 9 0
2016.06.20 10:26:32 5: JeeLink/RAW: OK 9 0 /1 4 198
2016.06.20 10:26:32 5: JeeLink/RAW: OK 9 0 1 4 198 /52
2016.06.20 10:26:32 5: myJeeLink dispatch OK 9 0 1 4 198 52
2016.06.20 10:26:36 5: JeeLink/RAW: /OK 9 50
2016.06.20 10:26:36 5: JeeLink/RAW: OK 9 50/ 1 4 171 59
2016.06.20 10:26:36 5: myJeeLink dispatch OK 9 50 1 4 171 59
2016.06.20 10:26:39 5: JeeLink/RAW: /OK 9 48 1
2016.06.20 10:26:39 5: JeeLink/RAW: OK 9 48 1/ 4 185 5
2016.06.20 10:26:39 5: JeeLink/RAW: OK 9 48 1 4 185 5/5
2016.06.20 10:26:39 5: myJeeLink dispatch OK 9 48 1 4 185 55
2016.06.20 10:26:40 5: JeeLink/RAW: /OK 9 0
2016.06.20 10:26:40 5: JeeLink/RAW: OK 9 0/ 1 4 198
2016.06.20 10:26:40 5: JeeLink/RAW: OK 9 0 1 4 198/ 52
@justme1968
hast du das Problem schon mal gehabt oder ist eine Einstellung falsch?
Zitat von: Blablubblaber am 20 Juni 2016, 10:28:30
habe gerade noch verbose auf 5 gesetzt und nochmal ein Reset gemacht hier der Auszug aus dem log
Auf welcher Hardware läuft der LaCrosse sketch?
Zieh das Ding mal ab und steck es neu an, ob es dann initialized wird.
Läuft auf einem JeeLink (v3c).
Fhem läuft auf einem Raspberry Pi2.
Nach dem neu einstecken funktioniert alles wieder wie es soll aber normal ist es nicht das er es verliert mal schauen wie lange es hält bis es wieder passiert.
Kann ich schon mal etwas machen was wenn es wieder passieren sollte hilft den Fehler zu finden?
Verbose auf 5 dauerhaft ist keine Lösung dann ist das Logfile zu sehr zugemüllt.
Zitat von: Blablubblaber am 21 Juni 2016, 07:22:02
Nach dem neu einstecken funktioniert alles wieder wie es soll aber normal ist es nicht ...
Ja, ist nicht normal. Üblicherweise geht das.
Zitat von: Blablubblaber am 21 Juni 2016, 07:22:02
Kann ich schon mal etwas machen was wenn es wieder passieren sollte hilft den Fehler zu finden?
Kein Ahnung. Wenn FHEM den USB-Port öffnet (also auch nach einem "set myJeeLink reset") wird am JeeLink über DTR ein Reset ausgelöst.
Wenn der Sketch einen Reset macht, schickt er seine Kennung, was das JeeLink Modul dazu veranlasst, von "opened" auf "initialized" zu gehen und die InitCommands zu schicken.
Aus irgend einem Grund löst bei Dir scheinbar das Öffnen der Schnittstelle keinen Reset aus. Beim Draufstecken macht er natürlich einen Reset, darum geht das dann.
Zitat von: Blablubblaber am 21 Juni 2016, 07:22:02
Verbose auf 5 dauerhaft ist keine Lösung dann ist das Logfile zu sehr zugemüllt.
Vebose 5 ändert auch nichts am Problem, das kannst Du wieder weg nehmen.
Lässt sich das Problem irgendwie beheben.
Das er kein Reset macht hat nämlich noch den nachteil das wen ich die InitCommands ändere immer den Jeelink ausstecken und wieder einstecken muss damit er die Änderungen übernimmt.
ist das ein original jeelink? könnte es sein das es tatsächlich ein hardware defekt ist? ich glaube weiter oben hatte schon mal jemand das problem mit einem falsch gelöteten clone.
das beim abziehen ein 'reset' passiert ist klar und nicht ganz vergleichbar. das ding ist ja komplett stromlos und startet deshalb neu.
gruss
andre
Wir hatten auch schon den Fall, dass der Sketch die Kennung geschickt hat, aber FHEM sie irgendwie irgendwo geschluckt hat.
Aus diesem Grund hatte ich mal vor längerer Zeit ein weiteres delay im Sketch eingebaut, dass FHEM mehr Zeit hat, nach dem Öffnen der Schnittstelle "empfangsbereit" zu werden.
Bei dem User damals hat das geholfen und das Problem war weg.
Man könnte den JeeLink an einen Rechner mit einem Terminalprogramm (z.B. hTerm auf Windows) stecken und mal DTR schalten und schauen, ob er einen Reset macht (also das, was in model steht, schickt)
Falls ja, liegt das Problem auf Raspi und/oder FHEM-Seite.
Da er es aber irgendwie geschafft hat, ihn zu flashen, muss ja auch ein reset gegangen sein, ohne den bekommt man die Firmware eher nicht drauf.
Wäre auch noch ein Test: funktioniert ein "set myJeeLink flash" ?
ja ein original kein clone.
Einfach nur ein "set myJeeLink flash" oder ein "set myJeeLink flash LaCrosse" ?
Ich habe das selbe Problem mit einem Clone. Selbst nach aus und einstecken funktioniert er nicht (mehr) .
Seither konnte ich, durch aus- und einstecken den Jeelink wieder verwenden. Seit ein paar Tagen geht er nicht mehr ?
Ich verwende den Clone seit Anfang 2015 ohne Störungen. Am Anfang auch ohne das Problemchen.
Jens
Zitat von: jensweber am 21 Juni 2016, 12:47:32
Ich habe das selbe Problem mit einem Clone.
Mit oder ohne Pegelanpassung?
Zitat von: HCS am 21 Juni 2016, 13:07:43
Mit oder ohne Pegelanpassung?
Ähm, keine Ahnung. Ich habe einen SainSmart Nano V3,0 ATmega328 mit RFM12B zusammengebaut.
-> ohne Pegelanpassung. Habe den thread gefunden. Naja dann sollte ich wohl mal noch ein paar Widerstände einlöten.
Dankschee.
Zitat von: jensweber am 21 Juni 2016, 12:47:32
Ich habe das selbe Problem mit einem Clone. Selbst nach aus und einstecken funktioniert er nicht (mehr) .
Seither konnte ich, durch aus- und einstecken den Jeelink wieder verwenden. Seit ein paar Tagen geht er nicht mehr ?
Moin,
Genau das Problem hatten ich auch neulich. Die LED hat bei mir hektisch geblink, als wenn der Nano leer wäre. Hab ihn dann neu geflasht und seit dem tut er wieder wie er soll.
Gruß FD
Gesendet mit einer zu kleinen Tastatur
Zitat von: jensweber am 21 Juni 2016, 22:18:26
Naja dann sollte ich wohl mal noch ein paar Widerstände einlöten.
Was nur dann was nutzt, wenn der RFM noch lebt ...
Einen 3.3V Arduino nehmen ist auch eine Alternative.
Guten Tag FHEM Forum,
ich habe auch das Problem, dass sich der original Jeelink V3c nach ein paar Stunden Betrieb verabschiedet.
Bisher half ein rausziehen/reinstecken.
Das geht seit ca. 2 Tagen auch nicht mehr.
Flashen aus FHEM mit "set myJeeLink flash LaCrosse" geht. (die rote und grüne LED´s gehen dann dauernd an und flackern danach noch einmal kurz). Die blaue LED bleibt dunkel (ich habe sie NICHT mit (0a v) deaktiviert).
Nach dem Flash kommt die Meldung:
flashing JeeLink myJeeLink
detected Firmware: LaCrosse.hex
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (28690 bytes):
Writing | ################################################## | 100% 4.18s
avrdude: 28690 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 28690 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.23s
avrdude: verifying ...
avrdude: 28690 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
Ein "set myJeeLink reset"
löst im Logfile:
2016.06.23 12:12:28 3: Opening myJeeLink device /dev/ttyUSB0
2016.06.23 12:12:28 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.06.23 12:12:29 3: myJeeLink device opened
Eine weitere Funktion ist auf dem Jeelink Stick nicht zu erkennen (alle LED bleiben dunkel).
Hat jemand eine Idee, wie ich wieder mehr Leben in den Jeelink (zurück)bekomme?
Grüße aus dem Münsterland
Ralf
Zitat von: rabbitlman am 23 Juni 2016, 12:26:39
Hat jemand eine Idee, wie ich wieder mehr Leben in den Jeelink (zurück)bekomme?
Poste mal ein
list myJeeLink
da ich das selbe Problem hatte (momentan läuft er) poste ich auch mal mein Ergebnis.
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 87
NAME myJeeLink
NR 373
PARTIAL
RAWMSG OK WS 26 1 255 255 255 0 4 255 255 255 255 255 255 0
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~5)]
myJeeLink_MSGCNT 106725
myJeeLink_TIME 2016-06-23 16:06:45
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-06-23 16:06:45 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 5m 30t 0a v
room LaCrosse
dann haben wir auch eine Referenz falls es bei mir wieder aussteigen sollte und können eventuell ein unterschied finden.
/dev/ttyUSB0@57600
Kleiner Tip:
Wenn Du mehr als einen "Stick" hast, ist eine Definition über /dev/serial/by-id besser.
Hintergrund:
Die Nummerierung der ttyp erfolgt in der Reihenfolge, in der die Geräte beim Booten gefunden werden. Webb man mehr als eines hat, kann durch diverse Toleranzen sich die Reihenfolge Ändern und s wird versucht, den "falschen" Stick zu initialisieren.
Wenn man mehrere Geräte ohne Seriennmmr hat (z.B. Eigenbau), kann man auch über /dev/serial/by-path gehen ...
da habe ich ne Frage zu.
Ich habe ja beim Raspberry ein Knoten anlegen müssen mit
sudo mknod /dev/ttyUSB0 c 188 0
muss ich den dann auch neu anlegen mit der s/n?
und in Fhem wird aus
/dev/ttyUSB0@57600
/dev/xxxxxxx@57600
richtig??
Du kannst Deine Vorhandene Definition editieren.
Und einfach aus /dev/ttyUSB0@57600 -> /dev/serial/by-id/XXXXX@57600
bekomme ich die id irgendwie raus ohne sie vor Ort abzulesen?
Maches Dir nicht so schwer!
Einfach per Konsole (putty?) auf dem Rechner und mal folgendes eingeben:
ls -lha /dev/serial/by-id
Was siehst Du da??
Dann erscheint Folgendes
insgesamt 0
drwxr-xr-x 2 root root 120 Jun 21 06:25 .
drwxr-xr-x 4 root root 80 Jan 1 1970 ..
lrwxrwxrwx 1 root root 13 Jun 21 06:25 usb-FTDI_FT232R_USB_UART_AI03D97R-if00-p ort0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jun 8 22:28 usb-HUAWEI_Technology_HUAWEI_Mobile-if00 -port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jun 8 22:28 usb-HUAWEI_Technology_HUAWEI_Mobile-if03 -port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Jun 8 22:28 usb-HUAWEI_Technology_HUAWEI_Mobile-if04 -port0 -> ../../ttyUSB3
Gehe ich recht der Annahme das die S/N dann "AI03D97R" Lautet?
Zitat von: Blablubblaber am 24 Juni 2016, 11:41:20
Gehe ich recht der Annahme das die S/N dann "AI03D97R" Lautet?
Richtig, das ist die Seriennummer des FTDI, aber als Device mußt du den gesammten Pfad und die Baudrate eingeben also:
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0@57600Gruß Friedrich
Und Du siehst hier auch gleich Dein Problem:
ttyUSB1-3 sind ein HUAWEI_Technology_HUAWEI_Mobile (Hast Du ein Handy angeschlossen?)
Wenn Du jetzt rebootest, könnte eines von diesen zu dem "neuen" ttyUSB0 werden und damit der JeeLink mit Deiner bisheriegen Konfiguration nicht funktionieren
so also habe es jetzt geändert auf
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0@57600
anschließend habe ich ein
set myJeeLink reset
ausprobiert.
Hier ein
list myJeeLink
Vor dem Reset
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0@57600
FD 87
NAME myJeeLink
NR 373
PARTIAL
RAWMSG OK 9 1 129 4 223 66
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~5)]
myJeeLink_MSGCNT 151689
myJeeLink_TIME 2016-06-25 09:35:27
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-06-25 09:35:27 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 5m 30t 0a v
room LaCrosse
und das hier ist nach dem Reset
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0@57600
FD 87
NAME myJeeLink
NR 373
PARTIAL
RAWMSG OK WS 26 1 255 255 255 0 5 255 255 255 255 0 0 0
STATE opened
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~5)]
myJeeLink_MSGCNT 151711
myJeeLink_TIME 2016-06-25 09:36:05
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-06-25 09:36:05 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 5m 30t 0a v
room LaCrosse
Dazu auch der log auf verbose 5 bei dem Reset befehl
2016.06.25 09:38:46 5: JeeLink/RAW: /O
2016.06.25 09:38:46 5: JeeLink/RAW: O/K 9 0 1 4
2016.06.25 09:38:46 5: JeeLink/RAW: OK 9 0 1 4/ 217 68
2016.06.25 09:38:46 5: JeeLink/RAW: OK 9 0 1 4 217 68/
2016.06.25 09:38:46 5: myJeeLink dispatch OK 9 0 1 4 217 68
2016.06.25 09:38:48 5: JeeLink/RAW: /OK 9 1
2016.06.25 09:38:48 5: JeeLink/RAW: OK 9 1/ 129 4 22
2016.06.25 09:38:48 5: JeeLink/RAW: OK 9 1 129 4 22/2 66
2016.06.25 09:38:48 5: myJeeLink dispatch OK 9 1 129 4 222 66
2016.06.25 09:38:49 3: Opening myJeeLink device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0
2016.06.25 09:38:49 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.06.25 09:38:49 3: myJeeLink device opened
2016.06.25 09:38:49 5: JeeLink/RAW (ReadAnswer): OK 9
2016.06.25 09:38:49 5: JeeLink/RAW (ReadAnswer): 39 1 4
2016.06.25 09:38:49 5: JeeLink/RAW (ReadAnswer): 207 70
2016.06.25 09:38:49 5: JeeLink/RAW (ReadAnswer): OK
2016.06.25 09:38:49 5: JeeLink/RAW (ReadAnswer): 9 50 1 4
2016.06.25 09:38:49 5: JeeLink/RAW (ReadAnswer): 207 71
2016.06.25 09:38:51 5: JeeLink/RAW: /OK 9 48 1 4 209 69
2016.06.25 09:38:51 5: myJeeLink dispatch OK 9 48 1 4 209 69
2016.06.25 09:38:52 5: JeeLink/RAW: /OK 9 1 129 4 222 66
2016.06.25 09:38:52 5: myJeeLink dispatch OK 9 1 129 4 222 66
2016.06.25 09:38:54 5: JeeLink/RAW: /OK 9
2016.06.25 09:38:54 5: JeeLink/RAW: OK 9/ 39 1 4 2
2016.06.25 09:38:54 5: JeeLink/RAW: OK 9 39 1 4 2/07 69
2016.06.25 09:38:54 5: myJeeLink dispatch OK 9 39 1 4 207 69
2016.06.25 09:38:54 5: JeeLink/RAW: /OK 9 0
2016.06.25 09:38:54 5: JeeLink/RAW: OK 9 0 /1 4 217 6
2016.06.25 09:38:54 5: JeeLink/RAW: OK 9 0 1 4 217 6/8
2016.06.25 09:38:54 5: myJeeLink dispatch OK 9 0 1 4 217 68
2016.06.25 09:38:56 5: JeeLink/RAW: /OK WS 2
2016.06.25 09:38:56 5: JeeLink/RAW: OK WS 2/6 1 255 2
2016.06.25 09:38:56 5: JeeLink/RAW: OK WS 26 1 255 2/55 255
2016.06.25 09:38:56 5: JeeLink/RAW: OK WS 26 1 255 255 255 /0 5 255 2
2016.06.25 09:38:56 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 2/55 255 2
2016.06.25 09:38:56 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 255 2/55 255 2
2016.06.25 09:38:56 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 255 255 255 2/55 0
2016.06.25 09:38:56 5: myJeeLink dispatch OK WS 26 1 255 255 255 0 5 255 255 255 255 255 255 0
und ebenfalls mit verbose 5 beim aus und ein stecken
2016.06.25 09:41:11 5: myJeeLink dispatch OK WS 26 1 255 255 255 0 5 11 109 0 0 255 255 0
2016.06.25 09:41:16 5: JeeLink/RAW: /OK WS 26
2016.06.25 09:41:16 5: JeeLink/RAW: OK WS 26/ 1 255 25
2016.06.25 09:41:16 5: JeeLink/RAW: OK WS 26 1 255 25/5 255 0
2016.06.25 09:41:16 5: JeeLink/RAW: OK WS 26 1 255 255 255 0/ 5 255 255
2016.06.25 09:41:16 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255/ 255 25
2016.06.25 09:41:16 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 255 25/5 255 255
2016.06.25 09:41:16 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 255 255 255 255/ 0
2016.06.25 09:41:16 5: myJeeLink dispatch OK WS 26 1 255 255 255 0 5 255 255 255 255 255 255 0
2016.06.25 09:41:25 5: JeeLink/RAW: /OK
2016.06.25 09:41:25 5: JeeLink/RAW: OK /WS 26 1 255 255 255 0 5 25
2016.06.25 09:41:25 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 25/5 255 2
2016.06.25 09:41:25 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 2/55 255 25
2016.06.25 09:41:25 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 255 255 25/5 255 0
2016.06.25 09:41:25 5: JeeLink/RAW: OK WS 26 1 255 255 255 0 5 255 255 255 255 255 255 0
/
2016.06.25 09:41:25 5: myJeeLink dispatch OK WS 26 1 255 255 255 0 5 255 255 255 255 255 255 0
2016.06.25 09:41:25 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0 disconnected, waiting to reappear (myJeeLink)
2016.06.25 09:41:29 3: Setting myJeeLink serial parameters to 57600,8,N,1
2016.06.25 09:41:29 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0 reappeared (myJeeLink)
2016.06.25 09:41:32 5: JeeLink/RAW: /
[LaCr
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCr/osseITPl
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPl/usReader.
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader./10.1q (R
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1q (R/FM69 f:8
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1q (RFM69 f:8/68300 r:
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:/17241)]
2016.06.25 09:41:32 5: SW: 5m
2016.06.25 09:41:32 5: SW: 30t
2016.06.25 09:41:32 5: SW: 0a
2016.06.25 09:41:32 5: SW: v
2016.06.25 09:41:32 5: JeeLink/RAW: /
[La
2016.06.25 09:41:32 5: JeeLink/RAW: [La/CrosseITP
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITP/lusReade
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReade/r.10.1q (
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1q (/RFM69 f:
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1q (RFM69 f:/868300 t
2016.06.25 09:41:32 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t/:30~5)]
2016.06.25 09:41:33 5: JeeLink/RAW: /OK 9 39
2016.06.25 09:41:33 5: JeeLink/RAW: OK 9 39/ 1 4 207
2016.06.25 09:41:33 5: JeeLink/RAW: OK 9 39 1 4 207 /69
2016.06.25 09:41:33 5: myJeeLink dispatch OK 9 39 1 4 207 69
2016.06.25 09:41:36 5: JeeLink/RAW: /OK 9
2016.06.25 09:41:36 5: JeeLink/RAW: OK 9 /1 129 4
2016.06.25 09:41:36 5: JeeLink/RAW: OK 9 1 129 4 /222 66
2016.06.25 09:41:36 5: myJeeLink dispatch OK 9 1 129 4 222 66
2016.06.25 09:41:36 5: JeeLink/RAW: /OK 9 50
2016.06.25 09:41:36 5: JeeLink/RAW: OK 9 50/ 1 4 207
2016.06.25 09:41:36 5: JeeLink/RAW: OK 9 50 1 4 207 /71
2016.06.25 09:41:36 5: myJeeLink dispatch OK 9 50 1 4 207 71
2016.06.25 09:41:37 5: JeeLink/RAW: /O
2016.06.25 09:41:37 5: JeeLink/RAW: O/K 9 48 1
2016.06.25 09:41:37 5: JeeLink/RAW: OK 9 48 1 /4 209 69
2016.06.25 09:41:37 5: JeeLink/RAW: OK 9 48 1 4 209 69/
und das an ttyUSB1-3 ist ein UMTS Stick damit FHEM mir falls z.B. ein Rauchmelder oder Wassermelder Alarm gibt eine SMS aufs Handy schickt.
ich hoffe das hilft bei der Fehlersuche.
Zitat von: Blablubblaber am 25 Juni 2016, 09:45:27
ich hoffe das hilft bei der Fehlersuche.
Hilft nicht.
Hast Du das getestet?
https://forum.fhem.de/index.php/topic,14786.msg464253.html#msg464253
Du meinst das mit HTerm oder?
Nein habe ich noch nicht gemacht.
Habe es aber schon runtergeladen.
Kannst du mir sagen was ich genau machen muss kenne das Programm nicht.
Zitat von: Blablubblaber am 25 Juni 2016, 19:27:03
Kannst du mir sagen was ich genau machen muss kenne das Programm nicht.
JeeLink anstecken
Wie auf dem Bild konfigurieren (den richtigen COM Port nehmen, kann bei Dir was anderes als COM3 sein)
DTR an / ausschalten (zwei mal draufklicken)
Nach jedem "DTR an/aus" muss nach ca. einer Sekunde das hier kommen:
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
So habe es ausprobiert funktioniert siehe Bild.
Was soll ich als nächstes machen?
Zitat von: Blablubblaber am 27 Juni 2016, 21:29:03
Was soll ich als nächstes machen?
Mit einer großen Keule auf Deinen Raspi hauen. ;D ;D ;D
Der Test zeigt, dass der JeeLink mitsamt der Firmware drauf korrekt funktioniert.
Also liegt Dein Problem entweder im Betriebssystem oder in FHEM.
Als nächstes wäre der Test auf dem Raspi zu wiederholen.
FHEM stoppen, dass es nicht dazwischen funkt und dann sinngemäß diesen Test durchführen, ob es da auch funktioniert.
Habe aber keine Ahnung, womit man das auf dem Raspi macht.
Eventuell kann ja sonstwer weiterhelfen.
Entweder wird kein Reset ausgelöst, wenn FHEM die Schnittstelle öffnet, oder das "[LaCrosseITPlusReader..." dringt nach dem Reset nicht bis zum JeeLink Modul durch, worauf ich eher tippe.
unter linux kann screen benutzt werden
screen /dev/... 57600
Wie schaltet man DTR mit screen?
wird automatisch bei jedem open gesetzt. ggf. wird der serielle port nicht richtig geschlossen (hupcl in der stty ausgabe suchen).
Wollte kurze mal meine Erfolge posten:
Habe jetzt auch den Jeelink mit dem LaCrosse Sketch am Laufen und jetzt auch schon einige TECHNOLINE TX25 (Kühl- und Gefrierschränke) eingebunden. Habe jetzt auch noch etliche IROX/TFA/Hideki-Sensoren ersetzt. Da hatte ich immer wieder Probleme mit Reichweite, den einstellbaren Kanälen und Kollisionen mit Nachbars Sensoren.
Habe gestern auch noch meinen Helligkeitssensor von einem IROX-Temperatursensor in einen TX25 umgebaut. Die Helligkeit wird mit dem wetterfesten Helligkeitssensor (Lichtempfindlicher Widerstand) von Hygrosens Instruments GmbH gemessen (Einfach an den Stecker des Temperatur2-Kanals angelötet). Das Passt perfekt: Bei absoluter Dunkelheit zeigt das Thermometer -22,8°C bei maximalem Sonnenschein 29,8°C. Differenz sind 52,6 K
mit dem
Userreadings: brightness { (ReadingsVal("Aussen.Klima.Sonne","temperature2",0)+22.8)*1,9;; }
wandle ich den Wert in %-Helligkeit um. Später vielleicht mal in Lux. Der Sensor soll von 50 bis 20 000Lux messen. Möchte dann auch die Sonnenscheindauer messen. Das kann ich glaube mit statistics machen.
Danke die Programmierer für die hervorragende Arbeit am Sketch und am FHEM-Modul.
also habe screen nun auf meinem Raspberry installiert aber leider bekomme ich es irgendwie nicht zum funktionieren.
Welche befehle muss ich genau eingeben das es funktioniert?
zeige aktuelle config der seriellen Verbindung (hupcl ist interessant)
stty -a /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0
wenn du screen startest, sollte zu Beginn diese Zeile ausgegeben werden
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
screen starten:
screen /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03D97R-if00-port0 57600
screen beenden (Tastatur)
- Strg-a
- Strg-k
- y
was kannst du mit dmesg auslesen, wenn du den Stick abziehst und wieder dran steckst?
Hallo zusammen.
Wollte mal nachfragen, ob es möglich ist, in den internals oder readings die via jeelink clone empfangen werden, RSSI Empfangswerte darzustellen.? Ich kenne das z.b. Von nanocul bzw cul_usb.
Gruß Sascha
Gesendet von meinem SM-T560 mit Tapatalk
ein rfm12b liefert keine rssi werte.
ob der rfm69 welche liefert weiss ich nicht. falls ja müsste man den lacrosse sketch anpassen damit er die rssi werte auch an fhem weiter meldet.
gruss
andre
Zitat von: justme1968 am 03 Juli 2016, 22:11:18
ob der rmm69 welche liefert weiss ich nicht. falls ja müsste man den lacrosse sketch anpassen damit er die rssi werte auch an fhem weiter meldet.
Generell kann er welche liefern, aber so wie er in die Firmware eingebunden ist, geht es nicht.
Das zu ändern würde den kompletten Sketch auf den Kopf stellen.
Danke für die Info
Von mobil gesendet daher kurze Antwort
Hi,
ich bin nicht sicher ob ich hier richtig bin:
Früher wurden die Taupunkte geloggt.
(Früher = Stand Dezember, dann habe ich letzte Woche meinen Cubie geschossen und baue grade alles wieder auf.)
List von einem Sensor:
Internals:
CFGFN
CHANGED
DEF 1D
IODev myJeeLink
LASTInputDev myJeeLink
LaCrosse_lastRcv 2016-07-04 10:31:17
MSGCNT 5690
NAME du_TF_TEMPERATUR
NR 1591
STATE T: 16.8 H: 72 D: 11.7
TYPE LaCrosse
addr 1D
battery_new 0
corr1 0
corr2 0
myJeeLink_MSGCNT 5690
myJeeLink_RAWMSG OK 9 29 1 4 144 72
myJeeLink_TIME 2016-07-04 10:31:17
previousH 72
previousT 16.8
sensorType 0=T(H)
Readings:
2016-07-04 10:31:17 battery ok
2016-07-04 10:31:17 dewpoint 11.7
2016-07-04 10:31:17 humidity 72
2016-07-04 10:04:40 state T: 16.8 H: 72 D: 11.7
2016-07-04 10:31:17 temperature 16.8
Attributes:
IODev myJeeLink
doDewpoint 1
event-min-interval temperature:1800,humidity:1800,battery:3600
event-on-change-reading temperature:0.2,humidity:2,battery
room LaCrosse
Das List vom Logfile:
Internals:
CFGFN
DEF ./log/du_TF_TEMPERATUR-%Y.log du_TF_TEMPERATUR
NAME FileLog_du_TF_TEMPERATUR
NOTIFYDEV du_TF_TEMPERATUR
NR 1595
NTFY_ORDER 50-FileLog_du_TF_TEMPERATUR
REGEXP du_TF_TEMPERATUR
STATE active
TYPE FileLog
currentlogfile ./log/du_TF_TEMPERATUR-2016.log
logfile ./log/du_TF_TEMPERATUR-%Y.log
Attributes:
logtype text
room LaCrosse
Und was im Logfile steht:
Zitat
2016-07-04_10:29:19 du_TF_TEMPERATUR battery: ok
2016-07-04_10:10:35 du_TF_TEMPERATUR humidity: 72
2016-07-04_10:01:51 du_TF_TEMPERATUR temperature: 16.7
2016-07-04_09:40:34 du_TF_TEMPERATUR humidity: 72
2016-07-04_09:31:50 du_TF_TEMPERATUR temperature: 16.7
2016-07-04_09:28:15 du_TF_TEMPERATUR battery: ok
2016-07-04_09:10:34 du_TF_TEMPERATUR humidity: 72
2016-07-04_09:01:50 du_TF_TEMPERATUR temperature: 16.6
2016-07-04_08:53:44 du_TF_TEMPERATUR temperature: 16.4
2016-07-04_08:40:33 du_TF_TEMPERATUR humidity: 72
2016-07-04_08:28:14 du_TF_TEMPERATUR battery: ok
2016-07-04_08:27:57 du_TF_TEMPERATUR humidity: 71
2016-07-04_08:23:39 du_TF_TEMPERATUR temperature: 16.3
2016-07-04_07:57:52 du_TF_TEMPERATUR humidity: 71
2016-07-04_07:53:38 du_TF_TEMPERATUR temperature: 16.4
2016-07-04_07:37:22 du_TF_TEMPERATUR temperature: 16.1
2016-07-04_07:31:02 du_TF_TEMPERATUR temperature: 15.9
2016-07-04_07:28:08 du_TF_TEMPERATUR battery: ok
2016-07-04_07:27:51 du_TF_TEMPERATUR humidity: 71
2016-07-04_07:01:35 du_TF_TEMPERATUR temperature: 15.7
2016-07-04_06:57:47 du_TF_TEMPERATUR humidity: 70
2016-07-04_06:56:05 du_TF_TEMPERATUR humidity: 69
2016-07-04_06:31:34 du_TF_TEMPERATUR temperature: 15.7
2016-07-04_06:28:03 du_TF_TEMPERATUR battery: ok
2016-07-04_06:26:05 du_TF_TEMPERATUR humidity: 69
2016-07-04_06:01:34 du_TF_TEMPERATUR temperature: 15.7
2016-07-04_05:56:00 du_TF_TEMPERATUR humidity: 69
2016-07-04_05:31:33 du_TF_TEMPERATUR temperature: 15.7
2016-07-04_05:27:58 du_TF_TEMPERATUR battery: ok
Wie bekomme ich die Taupunkte wieder in das Logfile?
Mercy,
Rince
Du hast in deinen Attributen ja auch nur die 3 Daten drin,wie sie geloggt werden .
Hilfreich wäre wie dein log definiert ist
Von mobil gesendet daher kurze Antwort
Hallo Rince,
einfach state mitloggen und die Plotdefinition anpassen. Da steht der Taupunkt drin:
ZitatSTATE T: 16.8 H: 72 D: 11.7
2016-07-04 10:31:17 battery ok
2016-07-04 10:31:17 dewpoint 11.7
2016-07-04 10:31:17 humidity 72
2016-07-04 10:04:40 state T: 16.8 H: 72 D: 11.7
2016-07-04 10:31:17 temperature 16.8
Gruß PeMue
Argh.
Wieder was gelernt.
Attributes:
IODev myJeeLink
doDewpoint 1
event-min-interval dewpoint:1800,temperature:1800,humidity:1800,battery:3600
event-on-change-reading dewpoint:0.2,temperature:0.2,humidity:0.2,battery
=> läuft.
Komisch, warum es früher geklappt hat. Aber egal. Besten Dank :)
Ich habe da mal noch ne Frage wie setzte ich die Niederschlagsmenge bei der WS1600 Wetterstation wieder auf 0 mit Hilfe von FHEM?
Bin übrigens noch nicht dazu gekommen das Problem weiter zu untersuchen mit screen steht aber noch aufem plan =)
Hallo,
ich bin neu hier und möchte erstmal Hallo und Danke sagen für alles was es hier schon gibt.
Ich habe mir einen JeeLink USB Stick zugelegt und ein paar TX35DTH-IT Sensoren. Da ich komplett neu war auf dem Gebiet hat es eine weile gedauert aber schließlich hab ich alles zum Laufen gebracht. Ich war sehr happy :)
Leider hielt das Glück nur kurz an, denn in der Nacht gab es keine Daten mehr vom JeeLink. Mein Setup:
JeeLink v3c mit dem LaCrosse Sketch (v10q)
FHEM auf einem Windowsrechner
Wenn ich jetzt ein Terminal auf meinen COM Port öffne bekomme ich nichts mehr auf die Konsole geschrieben. Das hat gestern noch funktioniert...Ich habe heute schonmehrfach neu geflasht aber es bringt keine Veränderung. Auch schon ein zweiten Rechner und andere USB Ports hab ich probiert.
Der Ouput im Terminal:
[LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
danach kommt nichts mehr. Eigentlich sollte der Stick aber periodisch seine internen Sensoren da abloggen. Ohne die wird natürlich in FHEM nix passieren, da er keine RAWMSG bekommt.
Bin leider echt grad etwas verzweifelt :( Kann mir da jemand helfen?
@ useratfhem: Einmal posten reicht. Antwort siehe hier: https://forum.fhem.de/index.php/topic,55648.msg472543.html#msg472543
Hallo,
inzwischen habe ich nach Lektüre des Wikis 4x vergeblich Händler nach der Wetterstation WS 1080 in der FSK-Version angefragt - alle hatten nur die OOK-Version, die ja nicht in FHEM einzubinden ist.
Jetzt gerade schreibt mir ein Händler, dass die FSK-Version bereits seit drei Jahren nicht mehr hergestellt wird.
Wenn das so ist, könnte man die WS 1080 aus dem Wiki streichen.
Gruß
Wolfgang
Hi @all ich habe eine Frage zur WS1600.
Sie läuft bei mir nun seit gut einer Woche in Verbindung mit LaCrosse und habe mir hier den kompletten Post durchgelesen.
Habe ich es richtig verstanden, das wenn ich in FHEM bei der WS1600 ein
replaceBatteryForSec <sec> auslöse, in dieser Zeit die Batterien auswechseln kann ohne das ich in FHEM irgendetwas ändern muss!? (Name, ID)
Also nach Batteriewechsel alles wieder passt, die alte ID der WS1600 beibehalten bleibt und all meine Logs/SVG`s beibehalten bleiben, sowie die Verknüpfungen weiterhin passen!?
Werden die Daten des "statistics" Moduls die mit der WS1600 verknüpft sind auch beibehalten?
Ich nutze bisher die WS1600 sowie TX 29 DTH - IT Sensoren, welche initCommands sollte ich nun am besten setzen?
Anfangs hatte ich "30t 0a v" damit habe ich die WS1600 aber nicht gepaired bekommen.
Als ich auf "5m 10t 0a v" gewechselt habe kam dann irgendwann die WS1600.
Nun hat sich heut früh der Jeelink aufgehangen, nach Neustart lief alles wieder.
Sollte ich daher die initCommands wieder auf "30t 0a v" setzen oder noch ganz anders?
Weiterhin würde ich gern wissen ob man die Regenmenge "Reading rain" löschen kann?
Viele Grüße
Thomas
Siehe hier fortfolgend:
https://forum.fhem.de/index.php/topic,14786.msg401308.html#msg401308 (https://forum.fhem.de/index.php/topic,14786.msg401308.html#msg401308)
ZitatWenn du nur neben der ws1600 einen TX29DTH-IT laufen hast müsste als init auch das reichen.
attr myJeeLink initCommands 5m 30t v
mach auch mal LaCrossePairForSec 300 etwas länger. (autocreate an?)
ZitatHabe ich es richtig verstanden, das wenn ich in FHEM bei der WS1600 ein
Code: [Auswählen]
replaceBatteryForSec <sec>
auslöse, in dieser Zeit die Batterien auswechseln kann ohne das ich in FHEM irgendetwas ändern muss!? (Name, ID)
Zuerst Batterien wechseln, dann replaceBatteryForSec <sec> mit 300sec sollte es gehen.
Der La Crosse Kanal wird automatisch angepasst, der Rest bleibt gleich und sollte funktionieren.
Billy
Danke Billy
Die Regenmenge wird aber wieder auf 0 gesetzt. Bei dem Wert hat das statistics Modul dann einen Aussetzer.
Zitat von: sinus61 am 20 Juli 2016, 21:27:49
Die Regenmenge wird aber wieder auf 0 gesetzt. Bei dem Wert hat das statistics Modul dann einen Aussetzer.
Was bewirkt der Aussetzer? Besonders beim Monats- und Jahreswert?
Hallo zusammen.
Habe ne bescheidene Frage.
Ist es möglich mit nem JeeLink Clone und 2 Empfängern möglich, TX29 Sensoren und PCA301 Funkmessteckdose zu empfangen ?
Wenn ja, welche Empfänger muß ich dann verlöten ? Muß die Firmware für den Clone umgeschrieben werden ?
Gruß und danke
Sascha
Zitat von: sash.sc am 18 September 2016, 18:40:56
Ist es möglich mit nem JeeLink Clone und 2 Empfängern möglich, TX29 Sensoren und PCA301 Funkmessteckdose zu empfangen ?
Nein, das geht nicht.
Damit würde es gehen: https://forum.fhem.de/index.php/topic,43672.0.html
Aber mit 2 funk Modulen?
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 18 September 2016, 19:16:08
Aber mit 2 funk Modulen?
Nein. Die Firmware kann es nicht und wird es nicht können.
Die tx29 und pca301 werden über das selbe funkmodul empfangen?
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 18 September 2016, 19:23:03
Die tx29 und pca301 werden über das selbe funkmodul empfangen?
Verstehe die Frage nicht.
Habe gelesen, dass für die tx Sensoren und für die pca301 messsteckdose 2 Empfänger benötigt werden, da das 2 verschiedene Protokolle sind!
Von mobil gesendet daher kurze Antwort
Zitat von: sash.sc am 18 September 2016, 19:27:19
Habe gelesen, dass für die tx Sensoren und für die pca301 messsteckdose 2 Empfänger benötigt werden, da das 2 verschiedene Protokolle sind!
Genau. Und der LaCrosse Sketch kann nur das LaCrosse Protokoll und der PCA301 Sketch nur das PCA301 Protokoll.
Man brauch zwei verschiedene Sketche und die können nicht gleichzeitig auf dem JeeLink(-Clone) laufen.
Glaub mir, es geht nicht.
Nur mit zwei JeeLinks oder dem LaCrosseGateway geht es.
Ok. Ein Grund mehr auf das Gateway umzustellen!
Von mobil gesendet daher kurze Antwort
Zitat von: Depechem am 20 Juli 2016, 21:32:10
Die Regenmenge wird aber wieder auf 0 gesetzt. Bei dem Wert hat das statistics Modul dann einen Aussetzer.
Was bewirkt der Aussetzer? Besonders beim Monats- und Jahreswert?
Musste noch nie jemand Batterien bei einer WS 1600 wechseln?
Wird dann definitiv immer die Regenmenge auf 0 gesetzt?
Sind dann alle Monats und Jahreswerte aus dem Statistikmodul weg oder verschoben?
Vielen Dank für eure Antworten
Zitat von: Depechem am 21 September 2016, 18:32:38
Wird dann definitiv immer die Regenmenge auf 0 gesetzt?
Sind dann alle Monats und Jahreswerte aus dem Statistikmodul weg oder verschoben?
ja, die Regenmenge wird auf null gesetzt. Wirkt sich im Log z-B- so aus.
Vor dem Batteriewechsel!
2016-09-25_07:44:28 WS1600 statRain: Hour: 0.0 Day: 0.0 Month: 25.0 Year: 534.5
Nach dem Batteriewechsel!
2016-09-25_07:49:52 WS1600 statRain: Hour: -727.0 Day: -727.0 Month: -702.0 Year: -192.5
Mit einem
setreading WS1600 statRain: Hour: 0.0 Day: 0.0 Month: 25.0 Year: 534.5
müsste alles wieder auf Stand sein.
Billy
Zitat von: Billy am 27 September 2016, 08:22:34
ja, die Regenmenge wird auf null gesetzt. Wirkt sich im Log z-B- so aus.
Vor dem Batteriewechsel!
2016-09-25_07:44:28 WS1600 statRain: Hour: 0.0 Day: 0.0 Month: 25.0 Year: 534.5
Nach dem Batteriewechsel!
2016-09-25_07:49:52 WS1600 statRain: Hour: -727.0 Day: -727.0 Month: -702.0 Year: -192.5
Mit einem
setreading WS1600 statRain: Hour: 0.0 Day: 0.0 Month: 25.0 Year: 534.5
müsste alles wieder auf Stand sein.
Billy
Vielen Dank für deine Info!! :)
Hallo,
ich habe eine WS1600 und wollte sie in FHEM einbinden.
Mit der autocreate-Funktion gelang es leider nicht, warum auch immer. Also habe ich sie entsprechend dem log des Jeelink per define eingebunden. Das ist zwar gelungen, aber sie liefert leider nur die readings für battery, state und temperature. Die Daten den Windsensors und Regemessers werden nicht in den FHEM-Readings angezeigt, wohl aber auf dem Display der Wetterstation selbst.
Kann da jemand helfen?
Gruß
Wolfgang
Bist du sicher das du auch die Wetterstation empfängst und nicht irgendeinen Temperatursensor ?
Bei mir hat ein :
define Wetterstation LaCrosse 32
attr Wetterstation IODev LaCrosseGateway
gereicht
Beim Jeelink bzw. LGW solltest du folgende Einstellung haben (wenn du exklusiv nur die WS1600 damit empfängst)
attr LaCrosseGateway initCommands 2r v
Beim LGW findest du folgende Einträge der WS1600 im Log-Fenster:
22:23:20: OK WS 50 1 4 160 255 3 90 7 233 0 9 255 255 0 [AC 83 05 84 23 5A 39 09 E8]
22:23:24: OK WS 50 1 255 255 255 3 90 8 202 0 9 255 255 0 [AC 82 23 5A 3A 09 F4]
Wobei die 50 vorne die ID (Dezimal) der Wetterstation ist. (Das define will sie aber in HEX!)
Soweit ich weiss kannst du den Jeelink auch in einen RAW-Modus zum mitlesen schalten
Hallo,
ich habe leider keinen LaCrosseGateway, sondern nur einen Jeelink. Da ich auch noch einige andere Temperatur- und Feuchtesensoren benutze, muss ich leider im Toggle-Modus arbeiten und benutze als init 0a 30t v. Die weiteren Einstellungen kannst du im Anhang sehen.
Als ich vorhin die SD-Karte aus dem Raspi genommen habe, um ein Backup zu machen, hat sich der Empfang der WS1600 übrigens nicht wiederhergestellt im Gegensatz zu den übrigen Sensoren. Merkwürdig.
Gruß
Wolfgang
Ich bin jetzt nicht der Experte .... aber was ich da bei RAWMSG lese ist keine Wetterstation.
Lasse deinen Jeelink mal mindestens 30 Minuten nur auf den Empfangsparametern des Wetterstation laufen und schneide mit.
Meines Wissens steht bei der WS1600 dann das "WS" im String.
Die WS1600 sendet nämlich nur die ersten 10 Minuten nach einlegen der Batterie alle Parameter (quasi Anlernmodus) danach reduziert sie kräftig und sendet nur nach Bedarf.
Suche mal im Forum ... zu der WS1600 wurde schon eine Menge geschrieben.
PS: Das mit dem Toggle-Modus habe ich mir abgewöhnt .... es gehen einfach zu viele Daten verloren ... und ein Selbstbau Jeelink bzw. LGW kost ja nicht viel.
Zitat von: WolfgangV am 30 September 2016, 08:24:34
Als ich vorhin die SD-Karte aus dem Raspi genommen habe, um ein Backup zu machen, hat sich der Empfang der WS1600 übrigens nicht wiederhergestellt im Gegensatz zu den übrigen Sensoren. Merkwürdig.
Nö, nicht merkwürdig. Mit initCommands "0a 30t v" kannst Du sie auch nicht empfangen und hast sie sicher auch nie empfangen.
Siehe hier: https://forum.fhem.de/index.php/topic,14786.msg297293.html#msg297293
Zitat von: AxelSchweiss am 30 September 2016, 08:47:56
PS: Das mit dem Toggle-Modus habe ich mir abgewöhnt .... es gehen einfach zu viele Daten verloren ... und ein Selbstbau Jeelink bzw. LGW kost ja nicht viel.
Und wenn schon neu bauen, dann ein LGW, der JeeLink-Sketch wird zum Auslaufmodell.
Also was AxelSchweiss meinte: mit einem LGW kannst Du mit drei RFM69CW dran auf drei data rates gleichzeitig (ohne toggle) empfangen, also z.B. TX29DTH mit 17.241 kbps, TX35DTH mit 9.579 kbps und die WS1600 mit 8.842 kbps
Hallo,
danke für die schnelle Hilfe!
Mit dem Init-Command 0a 7m 10t v funktioniert es dann tatsächlich. Bin halt kein Computerfreak und klaue mir hier und da etwas Code zusammen, ohne es manchmal so richtig zu verstehen... :-)
Das mit dem LaCrosse Gateway habe ich zwar schon gelesen, aber nicht intensiv weiter verfolgt, weil ich vom Löten gar nichts verstehe. Habe aber jetzt weiter unten gesehen, dass es anscheinend auch ohne geht und werde mich mal entsprechend umschauen.
Danke nochmals auch für die Geduld, die ich hier im Forum immer wieder mit solch Ahnungslosen wie mir erlebe.
Gruß
Wolfgang
Hallo,
Auch ich haben einen WS1600.
Autocreate hat auch bei mir nicht geklappt.
Habe es also manuel gemacht.
Soweit ist auch alles gut.
Meine Frage nun...
Kann ich nun die Aktualisierung runtersetzen?
Es wird ja alle 3 sek Aktualisiert.
Kann ich die Regenmenge automatisch jeden Tag auf Null setzen?
Wie habt ihr den Log bzw Aufzeichnungen der Wetterdaten gelöst?
Gruß
Stefan
Hallo Leute hat hier jemand den TX35-IT Sensor angelernt bekommen ??
Hab den jeelink Clone
Neustes update und 0a 7m 10t v
Aber bekomme den nicht angezeigt
Gesendet von meinem SM-N915FY mit Tapatalk
Zitat von: Gasmast3r am 03 Oktober 2016, 22:12:58
Hallo Leute hat hier jemand den TX35-IT Sensor angelernt bekommen ??
Ja, zwei TX35DTH.
Arbeitet mit 9.579 kbps. Wenn Du sonst keine Sensoren hast, wäre
0a 1r 0t v
eher geeignet.
LaCrossePairForSec ggf. mit ignore_battery gesetzt?
Hy hab noch ein IT Sensor dran der funzt 30-3164 oder so.
Kenne die kbps davon aber nicht :(
Und den TX35-IT nicht DTH
Zitat von: Gasmast3r am 03 Oktober 2016, 22:29:10
Und den TX35-IT nicht DTH
Sollte egal sein, müsste funktionieren.
Hab 120 ignore_battery gesetzt
Dein Vorschlag auch getestet aber nix
(http://uploads.tapatalk-cdn.com/20161004/e2e95d204695744b0e75eb79e8132839.jpg)
Zitat von: spacecowboy.21 am 03 Oktober 2016, 11:48:57
Meine Frage nun...
Kann ich nun die Aktualisierung runtersetzen?
Es wird ja alle 3 sek Aktualisiert.
Kann ich die Regenmenge automatisch jeden Tag auf Null setzen?
Wie habt ihr den Log bzw Aufzeichnungen der Wetterdaten gelöst?
Gruß
Stefan
Das Thema Regenmege und Auswertung der Regendaten lässt sich u.a. mit dem Modul statistics lösen.
http://fhem.de/commandref_DE.html#statistics
Für die Reduzierung der Daten im Log sollte das attr --> event-on-change-reading hilfreich sein.
Billy
Hy habe es trotz lesen und versuchen den TX35-IT nicht dazu bewegen können mit FHEM zu kommunizieren.
Sonst noch jemand Ideen ??
(http://uploads.tapatalk-cdn.com/20161006/54e7f43b22fb11b80aad6d51a2e29b7e.jpg)
(http://uploads.tapatalk-cdn.com/20161006/e2347a99505cffa72e195caeec069239.jpg)
Hallo zusammen,
ich hoffe ich bekomme hier passende hilfe.
Ich habe mir 2 JeeLink Sticks von jeelabs bestellt, einen für 433 MHz und einen für 868 MHz.
ich habe den 433 MHz Stick laut Anleitung eingebunden und mit LaCrosse geflashed, im FHEM wird dieser mir aber mit 868 MHz angezeigt und Tests mit ELRO Funksteckdosen liefen auch erfolglos ab.
Im FHEM wird mir der Stick so angezeigt:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/ttyUSB0
DeviceName /dev/ttyUSB0@57600
FD 11
NAME jeelink433stick
NR 24
PARTIAL
RAWMSG OK 9 8 1 4 140 106
STATE Initialized
TYPE JeeLink
jeelink433stick_MSGCNT 22
jeelink433stick_TIME 2016-10-14 13:52:27
model [LaCrosseITPlusReader.10.1q (RFM12 f:868300 r:17241)]
Habe ich den falschen Stick geliefert bekommen oder habe ich manchmal beim flashen etwas falsch gemacht?
Geflashed habe ich im FHEM mit dem Befehl:
set jeelink433stick flash LaCrosse
was mir auch erfolgreich angezeigt wurde.
flashing JeeLink jeelink433stick
detected Firmware: LaCrosse
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
jeelink433stick closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e950f
avrdude: reading input file "./FHEM/firmware/JeeLink_LaCrosse.hex"
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: writing flash (28690 bytes):
Writing | ################################################## | 100% 4.17s
avrdude: 28690 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: load data flash data from input file ./FHEM/firmware/JeeLink_LaCrosse.hex:
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/JeeLink_LaCrosse.hex contains 28690 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 3.20s
avrdude: verifying ...
avrdude: 28690 bytes of flash verified
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
jeelink433stick opened
Ich bin für jede Hilfe dankbar
Gruß neotron
Zitat von: neotron am 14 Oktober 2016, 14:08:21
ich habe den 433 MHz Stick laut Anleitung eingebunden und mit LaCrosse geflashed, im FHEM wird dieser mir aber mit 868 MHz angezeigt und Tests mit ELRO Funksteckdosen liefen auch erfolglos ab.
Der LaCrosse-Sketch kann keine ELRO Funksteckdosen und auch sonst nichts, das 433 MHz OOK sendet.
Hmm,
und wo finde ich diese Informationen?
Oder besser gesagt, wie muss ich den JeLink flashen um die ELRO's zu schalten?
Gruß neotron
Zitat von: neotron am 14 Oktober 2016, 14:17:54
Oder besser gesagt, wie muss ich den JeLink flashen um die ELRO's zu schalten?
Bin mir nicht 100% aber fast sicher, dass es keinen JeeLink-Sketch gibt, der die ELRO kann.
okay...
dann mal andersrum, ich habe um die 15 ELRO's im Betrieb und will demnächst auch HM-CC-RT-DN per FHEM zentral steuern.
Liege ich dafür zumindest mit dem JeeLink 868 MHz Stick auf der richtigen Seite oder waren beide Sticks somit Fehlkäufe?
Wenn ja, was empfehlt ihr als Lösung um die ELRO's sowie die Thermostate zu schalten und von den Thermostaten auch Infos zu bekommen?
Also derzeit habe ich ein lauffähiges FHEM auf nem Raspi3.
Ich wollte eigentlich nicht selber löten, wenn es keine andere Lösung gibt würde ich jedoch auch zum Kolben greifen.
Gruß neotron
Ich denke für die IT bräuchtest du sowas (https://techblog.one/funksteckdosen-mit-fhem-schalten/). Das gibt es aber auch fertig. Weitere Informationen dazu im FHEM-Wiki (http://fhemwiki.de/wiki/CUL)
Für die Stellthermostate dann einen CUL868 und den rfmode 'HomeMatic' siehe -> FHEM-Wiki (http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat)
Die CULs von Busware kosten allerdings locker 50€/Stück, daher macht es vielleicht Sinn die selber zu bauen (selfCUL im Wiki) wenn du dazu technisch in der Lage bist. Mehr kannst du da wirklich nicht sparen ;)
Ich befürchte, dass Du mit beiden JeeLinks falsch liegst.
Schau mal hier:
http://www.fhemwiki.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat
Und zur generellen Beratung besser mal hier fragen:
https://forum.fhem.de/index.php/board,18.0.html
Ohh, der waschbär war schneller ;D
Ach ich brauchte grad mal etwas Abstand von den ganzen Excel Blättern ;)
Zitat von: waschbaerbauch am 14 Oktober 2016, 14:51:44
Ach ich brauchte grad mal etwas Abstand von den ganzen Excel Blättern ;)
Welcher Sketch kann die denn empfangen? ;D ;D ;D
Zitat von: HCS am 14 Oktober 2016, 14:52:31
Welcher Sketch kann die denn empfangen? ;D ;D ;D
Iris2Bra.ino ;)
Zitat von: neotron am 14 Oktober 2016, 14:37:19
dann mal andersrum, ich habe um die 15 ELRO's im Betrieb und will demnächst auch HM-CC-RT-DN per FHEM zentral steuern.
Liege ich dafür zumindest mit dem JeeLink 868 MHz Stick auf der richtigen Seite oder waren beide Sticks somit Fehlkäufe?
Gruß neotron
Um Fehlkäufe zu vermeiden sollte man vorher die jeweiligen FHEM Wikis lesen. ;)
Außerdem entlastet das die Modulentwickler bezüglich Beantwortung unnötiger Fragen. :)
Im Jeelink WIKI steht z.B. was der Jeelink im Umfeld FHEM kann. Da dürfte z.B nichts von ELRO etc. stehen.
Billy
Hallo,
Ich möchte mir gerne eine passende WS1080 zu meinem Jeelink mit LaCrosse Sketch kaufen, finde aktuell aber bei den aktuell verfügbaren Modellen entweder gar keine Angaben oder nur welche mit OOK (PASS14c). Kann mir eventuell jemand das passende Modell nennen, das mit FSK (Pass7) läuft und damit mit dem LaCrosse Sketch betrieben werden kann?
Herzlichen Dank
Viele Grüße
Marcus
Zitat von: Aeroschmelz am 12 November 2016, 19:41:31
Kann mir eventuell jemand das passende Modell nennen, das mit FSK (Pass7) läuft und damit mit dem LaCrosse Sketch betrieben werden kann?
Ich glaube, dass die FSK-Version schon seit längerer Zeit nicht mehr hergestellt wird.
Hm blöde, dachte eigentlich FOSHK wäre von OOK auf FSK gewechselt und nicht umgekehrt 😀 Gibt es eine andere Wetterstation, die Regenmenge und Wind messen kann und mit dem La Crosse Sketch kompatibel ist? Muss man bei der WS1600 auf irgendetwas achten?
kann es sein, dass es seit dem letzten Update Probleme mit dem Modul gibt ?
Nach dem Neustart des Raspberry läuft es einige Minuten reibungslos. Allerdings tut sich dann nach einigen Minuten nichts mehr.
D. h. von keinem Sensor werden Daten empfangen/verarbeitet. Die "myJeeLink_TIME" bleibt auch stehen.
Nach erneutem Reboot wieder....einige Minuten alles i. O., dann wieder "Stillstand.
Nach dem Einspielen der Module vor dem Update alles tadellos.
Zitat von: rr725 am 18 November 2016, 14:37:24
kann es sein, dass es seit dem letzten Update Probleme mit dem Modul gibt ?
Zumindest keine generellen. Läuft bei mir dauerhaft.
Zitat von: rr725 am 18 November 2016, 14:37:24
Nach dem Einspielen der Module vor dem Update alles tadellos.
Welche Module?
evtl. noch zur info.....
ich benutze mehrere lac crosse sensoren als helligkeitssensoren- wen nun einer davon einen relativ hohen negativwert meldet, tritt dieses problem auf.
wie gesagt, ich habe 36_JeeLink.pm, sowie 36_LaCrosse.pm von vor dem update eingespielt und damit läufts einwandfrei
Zitat von: rr725 am 19 November 2016, 13:11:30
wie gesagt, ich habe 36_JeeLink.pm, sowie 36_LaCrosse.pm von vor dem update eingespielt und damit läufts einwandfrei
Kannst Du die beiden alten (36_JeeLink.pm und 36_LaCrosse.pm) mal hier anhängen, dass ich schauen kann, was der Unterschied ist?
Und dann lass mal bitte das 36_LaCrosse.pm alt und aktualisiere das 36_JeeLink.pm auf die neuste Version, ob es dann noch funktioniert.
Wie negativ sind die Werte denn?
Wobei das bei mir auch mit den aktuellen Versionen geht.
sorry, ich dachte erst durch den tausch der beiden module sei das problem erledigt gewesen, doch es bestand weiterhin.
nun habe ich ein älterers komplettes backup (aus dem august) zurüclgespielt.
damit scheint es nun wieder fehlefrei zu funktionieren. alle sensoren liefern damit regelmässig daten.
leider, da ziemlich viele module seitdem geändert wurden, habe ich keine ahnung welches das problem verursacht :-(
Hallo, ich empfange leider keinerlei Daten :-(
FHEM ist aktuell und der Nano gerade via FHEM auf RPi geflashed.
Da ich erst einen defekten RFM69C (868) vermutet hatte, habe ich einen 2. besorgt. aber auch bei dem kommt nichts von der WS1600 an.
Woran könnte es liegen ?
Bin für jeden Tip dankbar.
Hallo, habe mit p1 mal mir alle RAW Daten ausgeben lassen:
2016-11-28_12:47:58 myJeeLink UNKNOWNCODE A6 B5 6 58 10 39 20 0 30 FE 41 FE 53 0 9 97 41 75 A 70 48 49 2C E3 9C 40 B2 11 80 A4 C1 71 58 97 8D 90 AA B0 AA 41 B3 D1 C B2 55 27 40 E2 A8 B2 2E BD 23 A2 35 28 C5 90 A 55 1 C3 20 20
2016-11-28_12:48:03 myJeeLink UNKNOWNCODE A6 B5 6 58 10 39 20 0 30 FE 41 FE 53 0 4 21 A8 1E 44 D 74 22 12 9 8 71 1B 2A C8 0 7 1C E0 17 60 4D 68 C0 40 A 83 80 0 40 82 9 CD 62 10 2D 34 10 AE D 82 9C 42 20 9A 8D 81 E7 CA A3
2016-11-28_12:48:07 myJeeLink UNKNOWNCODE A6 B5 6 58 10 39 20 0 30 FE 41 FE 53 0 2 83 E8 98 A6 17 30 48 44 74 8E B0 4F 74 AD 0 5 8 5D A4 42 40 29 E 4E C9 6B 41 B0 1E B3 68 91 7A F8 66 52 4D 94 57 89 14 6A 4 21 F0 11 40 21 48
2016-11-28_12:48:12 myJeeLink UNKNOWNCODE A6 B5 6 58 10 39 20 0 30 FE 41 FE 53 0 23 9D 12 1B CA 31 76 3 62 EC B1 FB A1 18 C4 4C 22 E1 5E 9 25 14 F9 4C 6B 81 97 1A E0 8B 0 14 84 72 F DA F2 1A 44 B3 97 A7 98 E9 D7 F8 CC 91 94 75
2016-11-28_12:48:13 myJeeLink UNKNOWNCODE 4E 44 C4 E CB A2 89 49 F0 8F CF 61 15 28 E0 1 40 88 CB 91 2E C8 53 C0 9 46 7A 84 45 25 5C 70 27 20 11 C6 10 19 F0 20 D0 A5 61 C1 0 E7 AF 8 E 22 2E 30 84 A A8 9C 35 4D 25 36 E8 49 98 D0
2016-11-28_12:48:16 myJeeLink UNKNOWNCODE A6 B5 6 59 10 39 20 0 30 FE 41 FE E6 0 3E 86 80 8 CA 77 66 39 23 31 D2 C 21 9C 9B 2A BF 9A 52 67 C 57 E0 4F 92 9 1C 80 80 61 2B 30 18 60 16 6C 1 44 A2 70 60 65 10 5 FD FD 31 22 6D 5C
2016-11-28_12:48:19 myJeeLink UNKNOWNCODE 69 56 71 15 60 A1 D8 3 15 8 4A 2 40 1 82 8 D9 39 44 70 ED F5 1 85 16 61 21 8C 84 87 3A 0 E0 AD 62 C1 85 6A 66 43 2 2E A1 1 8 6E 4B 1 54 92 B6 4 DC D8 22 7E D2 92 55 CA 35 B0 1A 0
2016-11-28_12:48:21 myJeeLink UNKNOWNCODE A6 B5 6 59 10 39 20 0 30 FE 41 FE E6 0 13 38 E0 EB 8B 0 E8 B4 F0 A7 C7 C3 8D 59 12 21 C 42 32 21 18 5 9A 96 EC B6 22 8 32 8D 46 3E 62 40 4 C4 42 C0 36 E8 3C 6D D7 44 40 9C 72 78 79 36
2016-11-28_12:48:25 myJeeLink UNKNOWNCODE A6 B5 6 60 10 39 20 0 30 FE 41 FE F1 0 1A 78 C3 80 15 4C 36 4A 23 4C 7C 0 75 6F 5 59 6A 0 52 5D 2 0 45 62 84 13 21 39 C9 6C 4E A6 1 0 C5 95 21 88 C6 16 6 BF E9 B2 16 E8 8A E8 C1 68
2016-11-28_12:48:30 myJeeLink UNKNOWNCODE A6 B5 6 61 10 39 20 0 30 FE 41 FE 44 0 1 49 2 62 CE F8 E0 0 22 C0 E0 3 F1 14 2E 0 D0 2A D1 92 D4 A 18 26 84 24 30 9A CB 23 98 11 B2 16 51 45 2 4F 4 51 30 48 19 D0 2 32 B4 A0 1C 3
2016-11-28_12:48:34 myJeeLink UNKNOWNCODE A6 B5 6 61 10 39 20 0 30 FE 41 FE 44 0 22 20 69 8 66 D3 FB 17 1B 8B 4C 22 32 C2 A1 20 45 78 7 68 10 90 77 E1 CA 60 A4 BB 35 89 58 D6 18 D9 9A 81 3B F0 57 2 1E 10 CE 41 81 8E 33 A 51 8E
2016-11-28_12:48:39 myJeeLink UNKNOWNCODE A6 B5 6 62 10 39 20 0 30 FE 41 FE AA 0 27 32 12 A9 27 D1 1A 8D 48 26 5C C8 1A 83 42 80 C2 4B 24 CD E8 71 B4 64 B1 8C 34 C4 A1 83 DC 4D A5 2 4E 2F 21 90 A1 23 27 38 61 5A A0 25 F3 82 3B 96
2016-11-28_12:48:43 myJeeLink UNKNOWNCODE A6 B5 6 63 10 38 20 0 30 FE 41 FE F6 0 22 48 F4 8E B4 B2 7A 42 2E 4C B8 8 80 DA D0 2 F2 19 68 CF 3B E0 4C 83 86 F8 57 8 87 84 83 88 A1 3D 98 80 52 40 80 D3 56 44 2D A2 F9 63 99 3A 25 1A
2016-11-28_12:48:46 myJeeLink UNKNOWNCODE 18 8C 1 A5 42 3A 69 36 0 4 E7 6B 2 6B 14 7A 1F B8 40 43 9E C7 9A 3B 95 14 4 24 3A 69 C8 65 BB 62 61 4 8A 14 8A 14 4A 80 13 1A 41 53 53 D1 7D 81 28 2A C0 BC 26 25 76 6 2 16 28 D6 D3 C9
2016-11-28_12:48:48 myJeeLink UNKNOWNCODE A6 B5 6 63 10 38 20 0 30 FE 41 FE F6 0 31 44 E9 44 8 1F CE 15 35 10 A0 68 64 42 A1 CD 63 24 2 8 6A 42 8E 9 58 C 8C 10 21 29 E9 82 DE EE 1D D8 53 BA 4A D9 4D 2D F8 E2 85 8E 8A 83 8F A
2016-11-28_12:48:52 myJeeLink UNKNOWNCODE C2 4C 1 4 1A 85 51 2 AC 24 81 2 93 50 46 A6 BB A 2B 5 55 75 1B A6 D2 8C 50 C7 1 5B 28 1A F9 C4 D1 A1 FC 3D 6C 20 14 41 1D 59 1 29 75 3 9E B 5D 70 70 14 7D B 55 4 C EB 98 58 90 40
2016-11-28_12:48:52 myJeeLink UNKNOWNCODE A6 B5 6 64 10 38 20 0 30 FE 41 FE AE 0 11 16 19 C8 5F 81 6A 92 BA 63 82 11 88 DC 20 1 13 48 38 28 80 5F 2A 13 29 7 2 21 4 3 94 95 8C 7D 78 1A B0 C B0 3 1C 24 4 CE 31 68 3C 4 58 55
2016-11-28_12:48:53 myJeeLink UNKNOWNCODE 51 4F 8C 65 26 10 D0 1C 68 80 9 2B 9E 36 46 4C 13 80 1 70 60 9A 26 3 73 36 E1 D8 C 7D C2 28 24 D D1 0 73 D0 23 1B EF E1 1B B2 85 68 0 F9 AF 38 45 77 32 58 83 AC C4 7E 3F CA 24 30 13 42
2016-11-28_12:48:53 myJeeLink UNKNOWNCODE 2C 7D 21 81 32 9 39 A2 65 13 33 BC 9A E 13 70 CB B4 A1 2 4 C1 AD ED 70 D2 13 70 37 72 30 B7 7D F0 B7 78 68 B 69 6B A8 4B 98 40 82 46 5E 88 90 A 10 4A 41 D0 17 98 49 B0 33 D0 58 CF B3 6F
2016-11-28_12:48:57 myJeeLink UNKNOWNCODE A6 B5 6 64 10 38 20 0 30 FE 41 FE AE 0 27 8 7D 90 74 36 71 4A 2F 8F 40 A0 81 64 C0 2A 0 49 20 59 D2 AA A3 64 80 21 D3 42 8 50 F3 40 7A 81 92 4E 1 B4 C0 65 0 0 5A 10 E7 68 49 6 C3 32
2016-11-28_12:49:01 myJeeLink UNKNOWNCODE A6 B5 6 65 10 38 20 0 30 FE 41 FE 1B 0 14 BE E3 F7 10 11 70 3 41 54 49 50 36 86 B3 98 41 C A6 0 E1 DE C2 84 A 1 48 A2 54 F5 2B 3 C3 84 61 2B CF 62 0 4 8D C2 0 71 B2 19 8D 0 2C 26
2016-11-28_12:49:06 myJeeLink UNKNOWNCODE A6 B5 6 66 10 38 20 0 30 FE 41 FE F5 0 33 C0 FF B8 3F 5C 6B 18 DD 7B 9C C8 9 8F 24 69 D 0 A2 90 5E 42 AD 62 1 7 9B 48 32 81 C2 64 2 85 C1 C0 42 18 1B DD 70 3 8 64 A4 55 90 16 D1 FE
2016-11-28_12:49:10 myJeeLink UNKNOWNCODE A6 B5 6 66 10 38 20 0 30 FE 41 FE F5 0 2B 5F 40 24 88 F A8 11 E7 B7 3C 17 4E A4 53 10 A3 E4 4A 1 5A 12 A4 89 9 F5 BC 97 41 2 28 70 F4 C9 5 BB B3 D2 43 A E2 67 96 25 40 5A 2 60 10 21
2016-11-28_12:49:15 myJeeLink UNKNOWNCODE A6 B5 6 67 10 38 20 0 30 FE 41 FE 40 0 0 11 35 C 32 3B C F1 C 79 43 C0 8B 57 93 DC 30 87 43 B 41 24 91 9A 26 26 9F CC 22 BD 3 33 74 21 2B 82 8 4B E8 1F 98 20 E A0 FE 19 5E 10 5C A1
2016-11-28_12:49:19 myJeeLink UNKNOWNCODE A6 B5 6 68 10 40 20 0 30 FE 41 FE 64 0 11 63 46 2 45 80 2B C2 2C 64 86 B4 82 12 13 20 DB 7D 2E 95 0 11 24 3C 9 62 A0 15 62 4C 12 C4 2 C2 E0 45 B1 4 C0 99 34 E8 C9 F2 8E 47 A1 6 0 9F
2016-11-28_12:49:20 myJeeLink UNKNOWNCODE 5C AA 44 AA 8 A9 4D F B7 4F 85 E4 B8 6E 5A 54 29 99 94 58 44 29 18 62 1C E9 C5 40 6A 84 30 E E7 45 C DB 64 96 94 37 E8 C5 42 81 10 1D 2A F8 BD 73 C8 26 DB 57 87 49 13 6A 42 C9 86 50 20 2C
2016-11-28_12:49:22 myJeeLink UNKNOWNCODE 11 8D 2E 1E C 47 4 98 A4 8A 74 0 1A AA 80 14 E6 18 A3 EB BA BB 22 81 B8 E1 69 64 F0 1B 60 CE 92 29 22 62 5F 8C 3 80 A1 91 B1 8C F0 A9 4A A 41 A8 4 20 4 3A 92 3E 59 EA 24 50 89 4E 18 58
2016-11-28_12:49:31 myJeeLink UNKNOWNCODE AF A5 6 69 10 41 20 0 34 0 40 0 21 0 0 C5 CE 10 42 4F 41 A4 11 0 8D 80 48 4 D0 3 89 27 DE 64 A9 8C 5D 40 B8 51 89 80 E6 BD 28 A2 20 46 13 BA CA 44 95 62 C3 90 3 41 D4 59 2F 21 D B
2016-11-28_12:49:36 myJeeLink UNKNOWNCODE AF A5 6 69 10 40 20 0 34 0 40 0 C8 0 1F 18 59 14 95 84 16 7 0 29 8 24 7 E0 B4 76 8A 35 38 45 69 93 F2 38 92 93 92 86 4D 54 1E 5D 6B CC 5F 6E 39 91 AC 8B 16 0 F3 93 6 81 52 60 DC 47
2016-11-28_12:49:40 myJeeLink UNKNOWNCODE AF A5 6 69 10 39 20 0 34 0 40 0 0 0 2E C1 81 88 2 56 14 1D 69 A 25 9 4 45 F1 28 A8 95 81 0 C7 81 7C C5 21 80 59 4E E3 D5 8C 28 8E 9A 51 49 62 BE 74 3B 3 A4 2C 10 FB D6 36 DE D7 99
2016-11-28_12:49:45 myJeeLink UNKNOWNCODE AF A5 6 69 10 39 20 0 34 0 40 0 0 0 36 98 69 A7 11 3C C3 30 FA AD 40 83 16 64 82 14 31 62 91 50 95 CA CE 1 0 CC F5 23 8A A4 F7 E5 AE B6 6A 58 FA 66 44 49 4C 1E 50 92 18 58 C1 BD 24 E1
2016-11-28_12:49:50 myJeeLink UNKNOWNCODE AF A5 6 70 10 39 20 0 34 0 40 0 52 0 16 F0 65 4E 58 C0 0 32 F2 3E 4A 60 C2 FB 50 3E 90 97 D6 9 9F 1F 4D CE 82 88 4D C7 29 14 5C 6C 92 8B 22 8 3B 51 2B 2B 70 45 62 61 51 FC 98 38 1B 2C
2016-11-28_12:49:55 myJeeLink UNKNOWNCODE AF A5 6 71 10 39 20 0 34 0 40 0 E7 0 0 D0 51 21 22 C5 1D 94 D E2 C4 B2 21 15 63 50 95 BC DA 89 4B E 11 CD 86 8B 0 7A 27 B1 2E 80 19 59 44 95 56 30 4C 82 B1 D8 0 FC 9A EC 9 48 C3 C
2016-11-28_12:49:59 myJeeLink UNKNOWNCODE AF A5 6 71 10 38 20 0 34 0 40 0 E 0 10 8A 84 49 81 FB DB FA 44 D3 E 1 90 1D 4F 4C 80 80 40 C2 E4 81 36 C0 8C 89 E8 80 89 F7 F4 C 40 46 21 4 A1 97 C8 25 64 4D 32 6A E2 42 A 7F 4E 1
2016-11-28_12:49:59 myJeeLink UNKNOWNCODE 10 10 8A C3 6A C2 40 A0 81 45 F6 E3 C1 40 B E4 40 B8 45 C1 CE CF 44 44 94 2B 88 C1 A4 95 C1 4A 82 A8 4C 0 1E D D5 A3 B6 14 6 20 AA 6 CD 28 2 2 6 A0 FA 33 2 A4 E4 4 10 82 51 5 79 CE
Internals:
Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF
/dev/ttyUSB0@57600
DeviceName
/dev/ttyUSB0@57600
FD
6
NAME
myJeeLink
NR
1274
PARTIAL
RAWMSG
AF A5 6 71 10 38 20 0 34 0 40 0 E 0 18 28 5E 20 CA 64 13 45 C2 58 F A2 C0 0 1 41 E8 58 6 CF 93 68 46 20 10 6 12 19 38 4 3A B1 9 10 76 78 C 7 F0 18 87 B0 2 D9 42 53 B7 9 84 41
STATE
initialized
TYPE
JeeLink
initMessages
model
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:8842)]
myJeeLink_MSGCNT
106
myJeeLink_TIME
2016-11-28 12:51:06
Jemand ein Idee was schief läuft ?
gott sei dank....bei mir ist das problem behoben....nach nun tagelangem forschen und suchen, woran es liegt/lag
ganz komischen verhalten...nach reboot des rechners lief alles eine gewisse zeitlang einwandfrei. dann wurden keine daten mehr des myjeelink verarbeitet. timestamp ist stehengeblieben.
teilweise ist ab und zu ist der komplette rechner hängengeblieben.
die lösung : jedes fs20 device, jeder bewegungsmelder hatte plötzlich als IO/Dev den myjeelink eingetragen.
alles wieder "umgebogen" und nun läuft wieder alles. oh mein gott.....ich frag mich nur....wieso wurde überall der myjeelink als IO/DEV eingetragen....egal...es läuft wieder ;)
Habe noch die Frequenz auf 868290f gestellt und bekomme jetzt einheitliche Werte vom TX22 / WS1600-1, die aber immer unknown sind :-(
Oder habe ich die falsche WS1600 gekauft ?
https://www.conrad.de/de/funk-wetterstation-ws-1600-ws1600-646188-646188.html
2016-11-28_14:22:28 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 2B 76 D6 A0 B9 A4 B7 E5 A9 3E 11 FD 58 FB FD 1B D6 FF 4 BC B1 FF 91 D7 66 BB FC 54 90 57 DA 8C 7F 3F FB 73 EB EA FB EB 41 C1 B7 B6 DE 3B 1F 7E FE 37
2016-11-28_14:22:33 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 27 E7 5B 9C 74 76 F7 DD DA D1 ED CE F9 6F BD B2 E6 59 4 C8 96 8B E2 56 DE 78 D0 9D E1 7F D0 7F F9 E1 7D CE 87 3D FF F6 5D C7 95 FC A6 7F 77 D FE BC
2016-11-28_14:22:37 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 37 E9 77 AF 7E B0 7F 7E 6B F9 FF D4 CF 98 7E AF B9 C6 B5 5A 65 65 B6 E1 F5 9B DB F9 7F F0 BE BB 7B 9F FE 7A 5F FE DF 7A F4 3F 7F 23 FB 94 CF CC B9 FB
2016-11-28_14:22:42 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 B 57 B7 E1 94 BB E5 86 FB F9 7A 5A EA DB F9 B9 EB 7F F5 7F B7 1A E4 25 C4 D7 FE 7E F5 DF 45 DF B7 31 FF 9E E6 BD 8A 43 DD DE FC 95 FD FA 5E F7 C5 AB
2016-11-28_14:22:46 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 34 BC 15 44 47 A0 D6 9B D4 30 42 9F 26 90 B8 78 2A 7F 79 CA D7 E7 7A F3 D3 9E B6 10 11 3 CE A7 B6 FA 70 24 FA D FB A9 81 A1 56 DA C3 B4 78 5D 49 D9
2016-11-28_14:22:51 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 6 39 FF EB 4C BB EF 80 33 7E 7F BF BF EF D4 CD 4B 7D 5F 8F B2 86 D6 9A F4 DC 5E 9D D0 DE DB D1 EF 3D 93 74 B DF 9D F7 BF 48 DB BF 98 8F F2 65 BE 9C
2016-11-28_14:22:55 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 C 4C 80 55 6C 97 57 50 3E 4F 56 77 D8 66 B6 6D A4 A6 AE 55 EA D2 63 C5 7D 6A 8 FE F4 FE DE 63 7E 64 73 37 63 F7 DD 5B B4 F 87 2F 8E 3F B3 8B 55 FF
2016-11-28_14:23:00 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 1C FF FA FD 4F 21 AF 74 FB DA 39 A5 E8 B5 97 B7 3A 77 4D 63 FE 5F 3C F6 1E 2F C7 6F A2 97 BF 5B BE E4 4A BB FB D8 97 9F 9B DE DF EC F7 FC FD C4 65 27
2016-11-28_14:23:04 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3D EB FF FA 18 B7 BB 66 F7 3B D5 7 86 EF 5F 86 67 F1 FE EF FA EF 67 F8 72 A7 E3 1F E9 FF 7F B7 D5 FD FB 84 5D 5E EC DB BA DC BD 49 F7 CD F7 F6 FF FC
2016-11-28_14:23:09 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 30 F9 46 FD 7B F6 B7 7E ED 7B DF 17 CF 5A 7D 9A D7 FE CB EF FE B9 E9 3A FF E7 5B BE 26 53 F4 EB 78 F6 A4 5E 5A FF F7 3B CD 38 A2 DF D4 EF DF 53 9B DE
2016-11-28_14:23:13 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 2B 2E 3B FF D6 7F B8 CD 63 15 D0 BE 1A 9F 90 AD 7E 83 DD FD F3 84 6B CC 7E B5 DC 7F FC B8 24 C7 FC 5C 95 F3 58 D7 D4 6F F9 8A F7 E7 7A E3 DC 8A 2A 7C
2016-11-28_14:23:18 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 C 7B FB B3 65 DE D7 A2 B6 D6 29 E5 F6 1B AF B 57 81 9D 25 FC BA 85 40 4E D9 DD 1E BA C D4 E9 FB B2 8C CD 5A 6A 65 BA 4D A5 8F BB 1A 9B FB 8F 7C 3D
2016-11-28_14:23:22 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 F 2D A5 53 FC CD 15 3B ED 53 EB 4D DE EE 98 45 AF 4B 7B 77 F8 CE 5C FC A6 F1 E FE 2F F6 35 39 47 FF FE E1 1D B9 76 A9 7B DF 59 DA 5B BD B7 7B DE 8C
2016-11-28_14:23:27 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 12 FF FC 33 C7 71 BA 35 FA 1D DF 23 7C 2F CE E5 2 F8 F4 6 EE A1 2B 9F 95 67 9B 54 9B 3D BF 63 BE 7 8F 7F AC 8E F6 73 F1 F6 EB 76 5D B4 A0 67 F5 88
2016-11-28_14:23:31 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 17 A3 BF BE 79 8A E 2D 95 EF 35 2F 76 2E 5E A8 D9 BD 73 A9 DC F3 DF AF 5F DB F9 EF 4B B9 EF FF D7 FE EF D9 F7 49 D7 BF 7F EB 92 47 B6 AD FE 96 B3 1A
2016-11-28_14:23:36 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 1D 9F 7B A9 63 9F C2 6A 7C EE 94 C3 45 DB 39 ED 18 77 CB 7E A7 DE 58 A1 77 D9 D5 A6 D1 D9 ED BE F9 9F 63 A5 CA EC 57 5D 83 34 A7 9 D6 A6 73 FE 74 B2
2016-11-28_14:23:40 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 37 DF FF 8F DE 3F 63 5E C0 B7 97 3B 9F 9B A 9E EC BF A1 8D BE F5 69 76 75 4F F5 5C F4 13 FD DE BF 4F 89 4B 89 6E FA 3F 37 22 B5 AB 40 77 B7 FF BF FF
2016-11-28_14:23:45 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 16 BD B2 A5 27 5C D7 4B D7 83 78 72 7B F8 9C 5F B3 D9 7E 59 D5 DF C4 F5 B3 FD EC A6 F7 D D7 4F B6 FA BD E6 D2 F2 C6 A6 6D 77 B9 F9 87 69 E1 FD ED C9
2016-11-28_14:23:49 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 5 79 4C 83 7A EF 3E B6 71 F5 F9 FB 19 7 F7 46 8B F8 A4 E7 FE 76 A7 DD 5B 37 62 BD 8E B5 7B 9B 51 75 6E A5 DA F1 76 AD C2 A1 F7 F5 9E 85 EE ED BB C8
2016-11-28_14:23:54 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 12 5B 97 FF EC DC E6 E7 FD E1 C9 2F FB 76 9D 7 C7 3F A5 EB 15 8B 4F F9 A3 BF FF 7B E9 DD 5F AF 73 43 F7 B7 F8 2C 87 C5 DD E5 D1 E7 76 FD DB F9 FE E0
2016-11-28_14:23:58 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 B D3 EA 7B 7D 93 9B 59 ED E7 72 BF B9 63 65 67 FD 2A 7A FA 74 3F F0 B3 4F E7 77 1C A6 9D 54 35 EF 7C E6 CF FF F9 BF C6 57 FF 18 FB F7 4F 96 76 17 AD
2016-11-28_14:24:03 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 F 45 FA F1 AF DE EF 7E D3 EA 57 1A F5 9B 71 17 F8 E7 D7 FE DF ED E0 FE B1 E8 5F DB E3 5E 36 BF AB 75 6F FF AE 33 4F 39 AF B2 79 ED A3 FE B0 A5 42 97
2016-11-28_14:24:07 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 15 F8 F7 B4 BD BC 3E CF D7 7 3F E3 A5 AA 7A 46 F6 BF 7C DF A4 89 72 D6 DC 26 BF F2 67 F 7E 35 BF CF FD 9F B2 EE 7C 6A ED 2F A7 27 FB F0 38 DD B6 C2
2016-11-28_14:24:12 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 F 5C 39 FA 8F AF E2 B7 D8 5F AF FA 2A F BA CF FB F7 FF 91 A6 FB 67 3B 2E 2D 22 E3 F5 BD FF D4 9F 4E 34 3B 5D 3E FF A8 CB 15 E6 6F AF BB BF 59 A9 5A
2016-11-28_14:24:16 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3F 5B CE 43 57 9D 2A CB 3 21 A9 DF 3F FD 47 EE BD A9 FA 93 FD 92 D9 A7 93 9F 9B BF C7 69 9D F3 78 D7 EB 3F 75 21 A3 9F F5 EE BF F5 37 87 F1 9F 7F B9
2016-11-28_14:24:21 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 1B 7E C6 7B 36 3B 4F D1 BE 7F A0 F0 7D 46 92 3B DD FF 1F 75 9C D5 FE D4 4A B1 E4 BE FD 81 66 B3 EE DE B7 97 6 3E B9 4A EB 6 83 4C DE BE D2 5B AA 16
2016-11-28_14:24:25 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 2E 97 8A 77 AB F0 FE 17 4B DA 61 3F 6D FF 24 F7 B5 C2 F8 5B 4E F7 7F D7 3B B4 7E 7C EF 1B 4F 9F FD A3 D2 FA E8 12 C7 FF DE DB FA C1 33 D1 E0 6 9A 89
2016-11-28_14:24:30 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 D A 8D EB BF 1C DF D6 F2 25 B3 B3 FB 5E 97 ED 7D B9 7F 3A E2 BA EF 7F DF F7 4C 77 6B BD 84 68 7C D7 57 AF 4A 5F EF 3C 12 BF F7 95 A7 6A F7 F0 C8 E6
2016-11-28_14:24:39 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 1 C9 D6 E7 16 A 75 F8 D6 8F F3 E7 F2 19 3B A7 F7 CE 37 B8 F8 68 2F D7 B7 9F D6 8F 3 DF 37 97 C9 7F E6 4A F1 C 9F 9E B7 1F A4 B7 DF 39 6D F9 AE 4C
2016-11-28_14:24:48 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 35 39 36 8A D6 FC 7F 7F BF 87 EF 42 DF AE 94 B8 BB ED D6 F9 D6 EC F9 39 EC F8 94 3F 9D AF 95 FD 95 3E D7 BB 37 F4 C7 C9 EA EE AC 79 6C 79 B1 53 EA C6
2016-11-28_14:24:52 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3B D2 77 DD 4B E9 D5 7F 7F BE 48 BB F7 3D A4 B6 8D BF D6 FD E9 9C E7 47 89 ED EE CC FC 54 8F AF EB 0 FC DE 1B 6D F5 D4 E3 3E 7F 1D B9 DB D5 4B 9C 3A
2016-11-28_14:24:57 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 F FF 4E 36 E0 AB BB 7E 3B 9F E9 FE 9B FC 74 63 B7 89 77 4B EE E5 1F A7 F7 AD 35 3D 21 DC EB DE EF 7F FC 72 7F CF EB 9B D1 D0 B3 73 6D 8 FE F8 B9 9E
2016-11-28_14:25:01 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 B 7F D 44 35 FB D3 57 27 B5 4E CF 99 3B CA 6F 35 29 80 6B 7A EC 2E F5 7E 91 CA 3B DE 1D 9F 7F CF FF 50 93 BB DD FD 5E 3 51 DE 19 77 7A AF 54 EC 12
2016-11-28_14:25:06 myJeeLink UNKNOWNCODE A4 A5 6 22 10 45 20 0 34 0 40 0 2D 0 1F F9 7F B7 59 C9 E8 AD CF F7 9F BE 83 F8 F7 EE C8 FD FD 76 FC 43 7A D7 E7 7E AE 13 DD 56 5E 8B F8 A7 F9 B7 BD A9 B7 FD E2 1A 7D FC 7D 3F FA D2 C1 7B
2016-11-28_14:25:10 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 33 BA 7F F7 F7 F2 EB 8B 39 F6 92 8D 4E F2 BD 6B B6 BA 79 A8 70 7F DF 6A AE 69 59 66 DC 9E 72 5E 45 FE FC 5E E6 C2 D6 3A FB BD F3 7D AF 5E ED F5 EE DE
2016-11-28_14:25:15 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 25 CA BF 4E F7 9D C9 52 8E 7E BF F7 EA FD FF B1 6F D7 BD 52 BB 9A DB 5D 9D 56 F7 F3 D7 4F B6 1A 4F CB FA 75 61 F1 AD DF AF 3A 41 BA 8F C6 67 9A 53 EE
2016-11-28_14:25:19 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 25 F B1 F7 AE E5 E9 EB DF BD 86 E7 40 FA 57 29 DB ED FC 5A BC B4 13 F3 A5 7D 46 D5 BB CF 12 7E BD D7 66 CE B7 FA B7 50 C5 BE D7 2B 3E B8 ED FB F7 D6
2016-11-28_14:25:24 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 26 BF 87 3D 7D DE C1 7A 3F 72 DF D5 BB 45 9F BB BC C1 6 1 ED B1 77 7D ED ED E9 5D F9 F4 EF F5 E8 BA 2A 5E CE A BA F8 77 B9 B2 DE E8 6F 4E E4 6A F7
2016-11-28_14:25:28 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3E BC 5F D7 B6 96 29 FE 1 7F DC 7F F4 89 4A D4 73 8D F5 DD 58 A0 7A F3 F5 35 3E E5 EB B5 13 DF 3F DF F9 B8 75 C7 62 7A FD 28 66 A5 9A 7D FE F4 DB DE
2016-11-28_14:25:33 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3F F2 6E 9F BF DC 87 FF 6F ED CE FF 2E FD 28 73 8E 9A F4 BB BE C7 AF 69 D7 50 B5 BF 63 7E 61 B7 E3 BE FF 7B 71 7F 9F D3 BC 9D AB 5D C7 D5 A6 97 E9 86
2016-11-28_14:25:37 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 2C AC BE 9A 71 29 D8 AE 7E EF 79 3 90 6F 62 FD F6 88 EB E7 CE 1D EF 7C 73 9F 9F 17 B9 F4 B7 54 30 3F C9 BD F7 F2 7C FD AF FA 5F 7F FA E3 DB FE 9F EF
2016-11-28_14:25:42 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 26 6F 86 CC F0 EB 78 37 7F D7 77 20 F9 37 37 FE A8 97 5F 97 3F 5C CE FF 6E D0 2A 50 FF E5 EA 56 CB 1F E9 6C BE 3 62 7B 93 F0 BB 6F DA A5 3F F 4A FB
2016-11-28_14:25:46 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3F 3A 36 AB 56 A2 5E 9C BC 17 EB 2A BF AA 2D AF CA CE F1 DD 19 3D E0 F0 1B F4 EB 5D BA DC 59 58 3B D7 87 D7 AD D7 FD 66 17 97 73 FD 3F B4 B2 D8 93 A7
2016-11-28_14:25:51 myJeeLink UNKNOWNCODE A4 A5 6 23 10 45 20 0 34 0 40 0 98 0 3A 34 17 58 4B 2 AB EC 3A E0 6F A8 E9 63 1D FE EE AF C9 5E D7 FF FF 3E CE B9 69 1D D3 BD DF C5 17 C7 BE 75 E9 B0 EF C7 14 7F 67 FF ED B8 AF BD 9A D7
Zitat von: Freibeuter am 28 November 2016, 14:29:45
Habe noch die Frequenz auf 868290f gestellt und bekomme jetzt einheitliche Werte vom TX22 / WS1600-1, die aber immer unknown sind :-(
Aus Deinen Werten lese ich:
a4 a5 6 23 10 45 20 0 34 0 40 0 98ID 12 (Hex) 22.3 °C und 45 % rH und sie sendet das "new battery" flag, die Batterien sind also noch nicht so lange drin
a4 a5 6 22 10 45 20 0 34 0 40 0 2d22.20 °C 45 % rH
In beiden Fällen Windstille. Ich vermute, die liegt in der Wohnung.
Zitat von: Freibeuter am 28 November 2016, 12:51:44
Hallo, habe mit p1 mal mir alle RAW Daten ausgeben lassen
Mach das mal wieder rückgängig (mit den Rohdaten kann das LaCrosse device in FHEM nichts anfangen) und definiere in FHEM manuell ein device:
define WS1600 LaCrosse 12und schau mal, ob da Daten eintrudeln.
Die 12 stimmt nur, wenn du seit diesem Log die Batterien nicht raus hattest.
You made my Day !
Ein herzliches Dankeschön, klappt jetzt prima :-)
Als Nordlicht bevorzuge ich die Beaufortskala statt km/h für den Wind, daher habe ich die Funktion kmh2bft in meine 99_myUtils.pm eingefügt, und
das STATE angepasst:
attr WS1600 userReadings WBft {kmh2bft(ReadingsVal("WS1600", "windSpeed", "0"))},WBftB {kmh2bft(ReadingsVal("WS1600", "windGust", "0"))}
attr WS1600 stateFormat T:temperature H:humidity R:rain Wind:windDirectionText WBft - WBftB Bft
###############################
### kmh in Bft
###############################
sub
kmh2bft
{
my $kmh = $_[0];
my $bft = 0;
if ($kmh > 1 ) {$bft = 1};
if ($kmh > 6 ) {$bft = 2};
if ($kmh > 12 ) {$bft = 3};
if ($kmh > 20 ) {$bft = 4};
if ($kmh > 29 ) {$bft = 5};
if ($kmh > 39 ) {$bft = 6};
if ($kmh > 50 ) {$bft = 7};
if ($kmh > 62 ) {$bft = 8};
if ($kmh > 75 ) {$bft = 9};
if ($kmh > 89 ) {$bft = 10};
if ($kmh > 103 ) {$bft = 11};
if ($kmh > 118) {$bft = 12};
return( $bft);
} # end sub kmh2bft
@justme1968: könntest Du im JeeLink Modul alles wegfiltern, was mit LGW beginnt?
Das verhindert, dass unnötige "Unknown code LGW ..." in log entstehen, wenn jemand noch das JeeLink Modul für das LaCrosseGateway verwendet.
Anbei der patch.
hab es eingecheckt.
gruss
andre
Danke!
Das ging ja mit Lichtgeschwindigkeit 8)
Hi , ich habe ein kleines Problem mit meinem Jeelink .
Habe seid heute 5 Temperatur Sensoren am laufen ..
4 laufen seid dem einbinden perfekt durch nur einer macht immer wieder Schluss .
Es scheint so als ob der toggle Modus nickt mehr funktioniert ..
Wenn ich alles wieder neu starte funktioniert es meistens wieder ..
Kennt einer das Problem
Gruß Mikes
schau einmal nach, welchem io/device der sensor, welcher probleme bereitet, zugewiesen ist.
ich hatte letztens ähnliches, dort waren alle meine jeelink sensoren, warum auch immer, dem CUL und nicht dem jeelink zugewiesen.
dies hatte die gleichen auswirkungen. nach einem neustart alles in ordnung, doch nach einem gewissen, undefinierten zeitraum war "funkstille" was jeelink anging.
alles andere lief weiterhin problemlos.
Zitat von: Freibeuter am 29 November 2016, 10:52:08
Als Nordlicht bevorzuge ich die Beaufortskala statt km/h für den Wind, daher habe ich die Funktion kmh2bft in meine 99_myUtils.pm eingefügt, und
das STATE angepasst:
Gute Idee, aber liefert der Wert windSpeed nicht das Ergebnis in m/s ?
kann man von technoLine das Thermostat WS9119 einbinden? Gibt es dazu Erfahrungswerte?
Zitat von: bjoernbo am 24 Dezember 2016, 12:49:26
kann man von technoLine das Thermostat WS9119 einbinden? Gibt es dazu Erfahrungswerte?
Die sendet doch gar nichts, oder?
Zu 99.995 -> nein
Zitat von: sinus61 am 24 Dezember 2016, 10:50:33
aber liefert der Wert windSpeed nicht das Ergebnis in m/s ?
Ja
Hallo,
ich habe gestern abend 2 TX29DTH-IT bekommen und am Jeelonk angelernt. Hat auch sofort geklappt. Allerdings empfange ich nur sporadisch Daten. Dann Device gelöscht und neu angelernt. Wieder sofort geklappt, allerdings dasselbe Verhalten. Heute die Frequenz etwas verstellt, aber jetzt lernt er den 2.ten TX29DTH-IT gar nicht mehr an. Anbei das List:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 13
NAME myJeeLink
NR 82
PARTIAL
RAWMSG OK 9 6 129 5 102 234
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868280 t:30~3)]
myJeeLink_MSGCNT 1
myJeeLink_TIME 2016-12-24 17:09:44
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-12-24 17:39:03 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>
initCommands 30t 0a 868280f v
room 9.6_System
verbose 3
List des LaCrosse:
Internals:
DEF 18
IODev myJeeLink
NAME LaCrosse_18
NR 1381
STATE T: 22.2 H: 48
TYPE LaCrosse
addr 18
corr1 0
corr2 0
Readings:
2016-12-24 02:22:30 battery ok
2016-12-24 02:22:30 humidity 48
2016-12-24 02:19:09 state T: 22.2 H: 48
2016-12-24 02:22:30 temperature 22.2
Attributes:
IODev myJeeLink
room LaCrosse
Das log-File:
2016-12-23_22:58:30 LaCrosse_18 battery: ok
2016-12-23_22:58:30 LaCrosse_18 temperature: 23.7
2016-12-23_22:58:30 LaCrosse_18 humidity: 48
2016-12-23_22:58:30 LaCrosse_18 T: 23.7 H: 48
2016-12-23_23:18:27 LaCrosse_18 battery: ok
2016-12-23_23:18:27 LaCrosse_18 temperature: 23.2
2016-12-23_23:18:27 LaCrosse_18 humidity: 48
2016-12-23_23:18:27 LaCrosse_18 T: 23.2 H: 48
2016-12-23_23:31:14 LaCrosse_18 battery: ok
2016-12-23_23:31:14 LaCrosse_18 temperature: 23.1
2016-12-23_23:31:14 LaCrosse_18 humidity: 48
2016-12-23_23:31:14 LaCrosse_18 T: 23.1 H: 48
2016-12-23_23:32:17 LaCrosse_18 battery: ok
2016-12-23_23:32:17 LaCrosse_18 temperature: 23
2016-12-23_23:32:17 LaCrosse_18 humidity: 48
2016-12-23_23:32:17 LaCrosse_18 T: 23 H: 48
2016-12-23_23:38:21 LaCrosse_18 battery: ok
2016-12-23_23:38:21 LaCrosse_18 temperature: 23
2016-12-23_23:38:21 LaCrosse_18 humidity: 48
2016-12-24_02:19:09 LaCrosse_18 battery: ok
2016-12-24_02:19:09 LaCrosse_18 temperature: 22.2
2016-12-24_02:19:09 LaCrosse_18 humidity: 48
2016-12-24_02:19:09 LaCrosse_18 T: 22.2 H: 48
2016-12-24_02:19:13 LaCrosse_18 battery: ok
2016-12-24_02:19:13 LaCrosse_18 temperature: 22.2
2016-12-24_02:19:13 LaCrosse_18 humidity: 48
2016-12-24_02:19:17 LaCrosse_18 battery: ok
2016-12-24_02:19:17 LaCrosse_18 temperature: 22.2
2016-12-24_02:19:17 LaCrosse_18 humidity: 48
2016-12-24_02:19:30 LaCrosse_18 battery: ok
2016-12-24_02:19:30 LaCrosse_18 temperature: 22.2
2016-12-24_02:19:30 LaCrosse_18 humidity: 48
2016-12-24_02:22:30 LaCrosse_18 battery: ok
2016-12-24_02:22:30 LaCrosse_18 temperature: 22.2
2016-12-24_02:22:30 LaCrosse_18 humidity: 48
Habe noch einen CUL für die Homematic-Device am Raspi.
Hat jemand eine Idee?
Gruss Jürgen
Zitat von: bmwfan am 24 Dezember 2016, 17:53:52
Hat jemand eine Idee?
Üblicherweise gehören die TX29DTH nicht zu den Sensoren, für die man die Frequenz ändern muss / sollte
Wenn die Batterien schon lang genug drin sind, senden die TX29DTH kein "new battery" flag mehr und man muss ignore_battery mit angeben, also:
set myJeeLink LaCrossePairForSec 60 ignore_battery
Zitat von: bmwfan am 24 Dezember 2016, 17:53:52
initCommands 30t 0a 868280f v
Gerde noch aufgefallen: das 30t ist nicht erforderlich, wenn Du nur TX29DTH hast.
0a v reicht.
Danke für die Infos. Seit ich gestern Abend beim attr initCommands 30t noch folgendes 0a 868280f v ergänzt habe, geht es problemlos. Ob das allerdings daran liegt oder daran, das ich auch den Raspi neu gestartet habe kann ich nicht genau sagen. Versuche es jetzt mal ohne Frequenzverstellung, wie HCS empfohlen hat.
Hat das battery-Flag den Hintergrund, dass man dann beim Batteriewechsel keinen neuen Namen für das Device bekommt?
Wie ich bei meinen Versuchen gesehen habe, wird jedesmal nach dem Batterie einlegen eine neue Nummer vergeben (LaCrosse_24 wurde zu LaCrosse_18). Das würde aber bedeuten, dass jedesmal im Code die Bezeichnung angepaßt werden müßte. Das macht so doch keinen Sinn. Vergibt FHEM dann beim Anlernen mit [ignore_battery] dieselbe Nummer wieder?
Gruß Jürgen
Zitat von: bmwfan am 25 Dezember 2016, 17:14:41
Das macht so doch keinen Sinn. Vergibt FHEM dann beim Anlernen mit [ignore_battery] dieselbe Nummer wieder?
Ja, es macht keinen Sinn und nein, FHEM vergibt die ID nicht, sondern der Sensor vergibt sich nach jedem Einlegen der Batterien selbst eine zufällig ID.
Wenn man die Batterien tauscht, dann lässt man das LaCrosse device, das man ein mal ordentlich benannt hat (z.B. TemperaturWohnzimmer), die neue ID mit
set LaCrosse_18 replaceBatteryForSec 60neu lernen.
Und wenn man nur TX29DTH hat, macht "30t" keinen Sinn, weil man immer 30 Sekunden nichts empfängt, wenn man auf der anderen data rate ist.
Läuft auch ohne 868280f im initcommands, wie HCS bemerkt hat. Dann vermute ich, dass ich den Raspi nach Anstecken des JeeLink hätte sofort neu booten müssen. Da er aber initialisiert wurde, dachte ich alles ist in Ordnung.
Gibt es eine Möglichkeit, von FHEM aus den Sensor nicht so häufig abzufragen? Die Temperaturdaten benötige ich nicht so häufig, wie sie momentan gesendet werden.
Zitat von: bmwfan am 26 Dezember 2016, 09:53:33
Gibt es eine Möglichkeit, von FHEM aus den Sensor nicht so häufig abzufragen?
Der Sensor wird nicht abgefragt. Er sendet von sich aus alle vier Sekunden, ohne dass man da etwas dagegen machen kann.
Aber man kann die events in FHEM mit event-min-interval drosseln.
Zitat von: Gasmast3r am 06 Oktober 2016, 19:29:09
Hy habe es trotz lesen und versuchen den TX35-IT nicht dazu bewegen können mit FHEM zu kommunizieren.
Sonst noch jemand Ideen ??
(http://uploads.tapatalk-cdn.com/20161006/54e7f43b22fb11b80aad6d51a2e29b7e.jpg)
(http://uploads.tapatalk-cdn.com/20161006/e2347a99505cffa72e195caeec069239.jpg)
Hallo,
ich habe hier auch so ein Teil und bekomme es neben dem TX29-DTH nicht zum laufen. Der TX29 läuft 1a mit dem JeeLink V3
Ich habe mittlerweile erkannt, dass die Geräte unterschiedliche Datenraten haben. Allerdings weiß ich nicht, was ich einstellen muss, um die Datenraten zu togglen.
Auf meiner Suche bin ich nur über Beiträge gestolpert, die für mich als einfachen Anwender, nicht verständlich sind.
Könnte mir bitte jemand sagen, was man einstellen muss, damit die Datenraten getoogled werden?!
Vielen Dank!
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 23
NAME myJeeLink
NR 183
NR_CMD_LAST_H 1
PARTIAL
RAWMSG OK 9 51 1 4 180 50
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
myJeeLink_MSGCNT 72491
myJeeLink_TIME 2016-12-29 12:19:12
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-12-29 12:19:12 state initialized
XMIT_TIME:
1483008893
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t v
room Jeelink MfG
SouzA
Zitat von: SouzA am 29 Dezember 2016, 12:21:06
Könnte mir bitte jemand sagen, was man einstellen muss, damit die Datenraten getoogled werden?!
Die
initCommands 30t vsind korrekt.
Zur Sicherheit kann man noch ein 3m angeben.
Somit wären die initCommands:
initCommands 3m 30t vToggle wird mit zwei Kommandos gesteuert:
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist also 17.241 kbps (TX29) und 9.579 kbps (TX35)
t: toggle time
30t = alle 30 Sekunden die data rate wechseln
Aber:
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)] sagt, dass es noch nicht übernommen wurde. Die firmware läuft fix auf 17241 kbps
Ein
set myJeeLink resetsollte das erledigen
danach sollte es so aussehen:
model [LaCrosseITPlusReader.10.1q (RFM69 f:868300 t:30~3)]
Hallo,
vielen Dank für die ausführliche Antwort und Anleitung.
So hat es jetzt geklappt!
Kann es sein, dass solche Infos noch in der COMMANDREF und/oder Wiki fehlen?
Wird generell noch an dem Modul gearbeitet, dass sich das nicht lohnt?
Also nochmal vielen Dank und bis denn.
SouzA
Zitat von: SouzA am 29 Dezember 2016, 17:29:42
Kann es sein, dass solche Infos noch in der COMMANDREF und/oder Wiki fehlen?
Wird generell noch an dem Modul gearbeitet, dass sich das nicht lohnt?
Die commandref gehört zum Universal-JeeLink-Modul und die commands sind unterschiedlich für die verschiedenen Sketches, die das JeeLink-Modul unterstützt. Und es gehört mir nicht.
Im Wiki würde es sich gut machen, es werden immer Leute gesucht, die so was gerne übernehmen ;)
Hallo,
Toggle und Datenrate im Wiki eingepflegt. Wem das zu spartanisch ist, kann gerne selbst Hand anlegen ;)
MfG
Ich hätte da noch was:
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)
Hab ich jetzt auch in Wiki getut ...
MfG
Zitat von: Ralf W. am 29 Dezember 2016, 19:23:59
Hab ich jetzt auch in Wiki getut ...
Du bekommst eine Auszeichnung als Mitarbeiter des Tages 8)
Diese Seite ist im Wiki auch sehr, sehr zu empfehlen:
https://wiki.fhem.de/wiki/FHEMWiki:Administratoren (https://wiki.fhem.de/wiki/FHEMWiki:Administratoren)
::)
Hallo zusammen,
ich bin gerade dabei, mich bei aliexpress mit Bauteilen für einen SuperJee einzudecken und habe festgestellt, dass BMP180 dort gar nicht mehr angeboten wird, sondern als Ersatz BMP280 angepriesen wird. Hat das Ding schon jemand im Einsatz? Kann das 1:1 anstelle des BMP180 verwendet werden?
Hallo,
ist es auch möglich die Sensoren Technoline MA 10100 und MA 10200 per Jeelink anzubinden?
Habe den Jeelink (v3c) und mich ein paar Stunden mit dem MA 10100 gespielt.
Bisher konnte ich dem Sensor jedoch nur ganze 3 Datensätze entlocken. Jeweils nach wechseln der Batterie und ein paar Minuten warten. Klappt auch nicht immer.
Danke,
Martin
Zitat von: TheBlackLion am 22 Januar 2017, 10:54:08
ist es auch möglich die Sensoren Technoline MA 10100 und MA 10200 per Jeelink anzubinden?
Kann ich nicht sagen, da ich keine habe.
Lt. Beschreibung senden die nur alle 7 Minuten, was schon mal anders ist, als das was Sensoren wie TX29... und TX35... machen.
Ob Frequenz, data rate und Protokoll dem von TX... entspricht? Keine Ahnung.
Spontanes googeln hat auch keine Informationen zu data rate, Protokoll, ... geliefert.
Zitat von: tndx am 14 Januar 2017, 22:50:45
ich bin gerade dabei, mich bei aliexpress mit Bauteilen für einen SuperJee einzudecken und habe festgestellt, dass BMP180 dort gar nicht mehr angeboten wird, sondern als Ersatz BMP280 angepriesen wird. Hat das Ding schon jemand im Einsatz? Kann das 1:1 anstelle des BMP180 verwendet werden?
Hier gilt das Gleiche, da ich keinen BMP280 habe, kann ich es nicht sagen.
Das wäre dann ein auch Forschungsprojekt.
Ich bin der Meinung hier irgendwo mal gelesen zu haben, dass die MA Sensoren nicht funktionieren...
Hatte mir aus Unkenntnis einfach den v3c und den nächst besten technoline (in dem Falle MA) bestellt. Die beiden bekamm ich auch nicht zusammen. Oder stand das in der Wiki? Naja, es geht aber nicht... Den MA zurück schicken und einen der Geräte aus dem Wiki besorgen. Dann funzt es.
Bis denn
SouzA
Zitat von: SouzA am 23 Januar 2017, 05:40:35
Ich bin der Meinung hier irgendwo mal gelesen zu haben, dass die MA Sensoren nicht funktionieren...
Hatte mir aus Unkenntnis einfach den v3c und den nächst besten technoline (in dem Falle MA) bestellt. Die beiden bekamm ich auch nicht zusammen.
Bin inzwischen auch zu dem Schluss gekommen, dass es mit den MA Sensoren nicht klappt.
Habe auch den MA 10200 probiert und da kommt nichts rein. Auch wie sie sich verhalten deutet auf ein anderes Protokoll hin. Hatte den Sensor eine Woche im Büro außer Reichweite des Gateways, inkl. ein paar "Batteriewechsel" zwecks test. Wieder in der Reichweite des Gateways hatte ich dann gleich wieder aktuelle Daten in der Mobile Alerts App. Und auch das hinzufügen von Sensoren in der App per QR Code deutet auf eine Global eindeutige ID im Sensor hin, was es in den unterstützen Sensoren nicht gibt.
Fand aber beim Testen auch noch ein anderes interessantes (und ärgerliches) Problem:
Verwende ich meinen Jeelink 3vc (Sketch LaCrosseITPlusReader.10.1q) mit meinem PINE64 (Ubuntu 16.04), dann bekomme ich keine Daten. Versionsnummer mit "v" auslesen, Frequenz und Datenrate setzen sowie LED ausschalten klappt alles. (Getestet mit picocom und auch per echo / tail -f)
Stecke ich den Jeelink an mein Microsoft Surface Book (Windows 10), dann bekomme ich alle paar Sekunden Daten von den Sensoren meines Nachbarn.
Habe auch ein 2m USB3 Verlängerungskabel verwendet um Sörungen durch den PINE64 auszuschließen und sogar den PINE64 bei unveränderter Positionierung laufen lassen während ich erfolgreich Daten in Windows bekommen habe.
Einzig auffällige beim PINE64 ist, dass sich für gewöhnlich erst ab dem 2. Kommandos was tut. Also "v" --> nichts, "v" --> meldet Version, "v" --> meldet Version ... - so als ob man das den Jeelink / den USB Port erst aufwecken müsste.
Das Problem schon mal jemandem untergekommen?
Auch hatte ich angenommen dass
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>r use one of the possible data rates (for RFM #1)bedeutet:
1r = 17.241 kbps
2r = 9.579 kbps
4r = 8.842 kbps
Tatsächlich macht mein Jeelink aber:
0r = 17.241 kbps
1r = 9.579 kbps
2r = 8.842 kbps
Hab ich da die Beschreibung im Wiki nicht kapiert bzw. versucht zu viel zwischen den Zeilen raus zu lesen?
Danke,
Martin
Zitat von: TheBlackLion am 26 Januar 2017, 09:23:24
Das Problem schon mal jemandem untergekommen?
Nö, noch nie davon gehört. Scheint was PINE64+Ubuntu 16.04 USB spezifisches zu sein. Habe ich zumindest mit meinen Raspis, Cubies und den Bananen mit Debian noch nie beobachtet.
Zitat von: TheBlackLion am 26 Januar 2017, 09:23:24
Tatsächlich macht mein Jeelink aber:
0r = 17.241 kbps
1r = 9.579 kbps
2r = 8.842 kbps
Hab ich da die Beschreibung im Wiki nicht kapiert bzw. versucht zu viel zwischen den Zeilen raus zu lesen?
Das kannst Du Dir jetzt aussuchen ;D ;D
Man muss erst mal unterschieden zwischen den Commands r und m
r setzt eine feste data rate mit
0r = 17.241 kbps
1r = 9.579 kbps
2r = 8.842 kbps
alternativ kann man auch 9579r oder z.B. 17241r, oder ... setzen.
m legt fest, welche data rates im toggle mode (den man zusätzlich mit dem t command aktivieren muss) verwendet werden
Dazu kann man die untersten drei bits mit den Wertigkeiten 1, 2 und 4 (und beim LaCrosseGateway auch 8 ) setzen.
Zitatbits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps
3m macht also einen toggle 17.241 kbps / 9.579 kbps
Weitere Beispiele:
5m: toggle 17.241 kbps / 8.842 kbps
6m: toggle 9.579 kbps / 8.842 kbps
7m: toggle 17.241 kbps / 9.579 kbps / 8.842 kbps
Hi hat jemand mal probiert, ob die Kombisensoren der neuen FOSHK Wetterstationen (HP1001/HP1003/WH2600) mit einem Jeelink ausgelesen werden können?
Hallo zusammen, ich habe mal wieder Probleme mit meinem TX22. Nachdem die Batterie unbemerkt leer war, bekomme ich den TX22 nicht mehr eingebunden.
Habe das alte Gerät inzwischen komplett aus FHEM gekickt. Allerdings wird auch mit verbose 5 und init 2r v nichts im Log angezeigt und auch kein neues Gerät angelegt.
Habt ihr vielleicht noch eine Idee? Ansich funktionieren tut der TX22, am Display wird alles korrekt angezeigt.
Danke im voraus.
hi,
hast Du vor dem Batteriewechsel
set <Device> replaceBatteryForSec 60
oder ähnlich ausgeführt?
Gruß
Nein leider nicht, da wie gesagt "ungemerkt leer".
ok, aber Du hättest den TX nicht löschen müssen.
die oben beschriebene Funktion ist eigentlich "dumm". einmal aktiviert, z.B. für 60sek, wird das erste device, also der TX, in den eine Batterie eingelegt wird, für den richtigen "gehalten" und gesetzt.
Das Problem bei den Lacrosse-Sensoren ist, dass diese wohl bei jedem Batteriewechsel Ihren Code ändern.
Es könnte also auch vorkommen, dass wenn Du die 60 Sekunden "raplaceBatteryForSec" aktivierst und Dein Nachbar genau in dieser Zeit auch eine Batterie in einen anderen TX einlegt, Dein Device denkt, das sei Deiner!
Also ich teste das dann immer gleich mit einem Vergleich der angezeigten Werte Sensor<>Fhem (z.B. mit der Hand erwärmen).
VG
Ok, dann werde ich das das nächste Mal beachten. Allerdings bekomme ich das gute Stück ja aktuell gar nicht mehr angelernt.
Trotz 2r v und verbose 5 ist nichts zu finden. AutoCreate legt auch kein Device an.
Jemand noch eine Idee?
Zitat von: mordrad am 01 März 2017, 13:22:34
Jemand noch eine Idee?
wenn die Batterie schon lange genug drin ist, muss man beim LaCrossePairForSec noch den Parameter ignore_battery angeben.
Variante zwei: der Sensor hat nach dem Batteriewechsel eine ID bekommen, die bereits ein anderer hat -> Batterie nochmal raus und rein
Variante drei: die Batterie war nicht leer sondern der Sensor hat den Geist aufgegeben
Habe meinen Fehler jetzt gefunden. Es funktioniert nun wieder.
Die letzten Drei Varianten konnte ich ausschließen.
Habe aber dann gesehen, dass der Jeelink scheinbar nur unbekannten Code empfing. Woraufhin ich feststellen musste, dass FHEM den TX22 scheinbar nicht versteht, wenn Regen- und Windsensor nicht angeschlossen sind. Dachte der ignoriert das einfach. Naja jetzt bin ich schlauer.
Zitat von: mordrad am 01 März 2017, 15:20:05
Woraufhin ich feststellen musste, dass FHEM den TX22 scheinbar nicht versteht, wenn Regen- und Windsensor nicht angeschlossen sind. Dachte der ignoriert das einfach. Naja jetzt bin ich schlauer.
Das ist interessant. Dann erkennt er wohl, was dran ist und sendet je nach dem ein unterschiedliches Protokoll.
Wusste ich auch nicht.
Aber ohne Regen- und Windsensor ist das Ding ja eh langweilig ;D
Langweilig trifft es schon ganz gut. Aber einrichten, wenn das Ding auf dem Schreibtisch liegt ist angenehmer als jedesmal rauslaufen. ;)
Hallo zusammen,
ich versuche gerade den JeeLink Stick mit dem LaCross Scatch und einem TX25TP-IT zu verbinden, leider pairen sich die beide nicht?
Zitat von: aGeftw am 16 März 2017, 16:13:32
ich versuche gerade den JeeLink Stick mit dem LaCross Scatch und einem TX25TP-IT zu verbinden, leider pairen sich die beide nicht?
Stell mal eins der Radios fix auf 17241 kbps und falls die Batterien schon länger drin sind, dann muss an das LaCrossePairForSec noch ein ignore_battery dran.
Hast Du Sensoren auf 17.241 kbps, 9.579 kbps und 8.842 kbps oder sind die "7m" Zufall?
habe eigentlich nur den tx25 aktuell, habe nur 7m gemacht wegen zukunft, falls ich noch mehr holen will. was wäre der befehl für reine 17.241 kbps ?
Zitat von: aGeftw am 16 März 2017, 16:31:22
was wäre der befehl für reine 17.241 kbps ?
Nix, also schlicht keine initCommands, weil 17241 der Default für das erste Radio ist.
oder 0r, falls man ihn auf 17241 zwingen will, egal was es vorher war.
geht leider trotzdem nicht :(
wo kann ich ein bugging oder so einschalten?
wenn ich die batterie einlege sagt das ding 301 und dann immer verschiedene buchstaben oder zahlen.
mein state springt ständig zwischen opened und initializing.. ist das normal?
Zitat von: aGeftw am 16 März 2017, 17:40:54
wenn ich die batterie einlege sagt das ding 301 und dann immer verschiedene buchstaben oder zahlen.
Du hast einen LaCrosse-Sensor mit Sprachausgabe? :o ;D ;D
Zitat von: aGeftw am 16 März 2017, 17:40:54
mein state springt ständig zwischen opened und initializing.. ist das normal?
Absolut nicht. Gibt es noch etwas, das auf die gleiche Schnittstelle konfiguriert ist?
Oder: JeeLink an einen Rechner mit Terminalprogramm anschließen (57600 Baud) und schauen, was er übermittelt.
Es muss erst mal geklärt sein, ob der JeeLink oder FHEM das Problem ist.
nunja, sagen tut er es nicht, er schreibt es ins dispaly ;)
das mit dem springen habe ich herausgefunden, das war durch den befehl timeout 120,30 somit hat er alle 30 sek sich neu initialisiert.
nochmal andere frage, die blaue led, soll die ständig blinken oder durchgehend leuchten? bei mir blinkt sie wie im strobo-mode
habe den stick gerade mal bei mir angesteckt und mit den ftdi treibern über putty aufgemacht:
[LaCrosseITPlusReader.10.1r (RFM69CW f:868300 r:17241) + (RFM12B f:868300 r:9579)]
[LaCrosseITPlusReader.10.1r (RFM69CW f:868300 r:17241) + (RFM12B f:868300 r:9579)]
wird geschrieben.
Zitat von: aGeftw am 17 März 2017, 08:10:42
nochmal andere frage, die blaue led, soll die ständig blinken oder durchgehend leuchten? bei mir blinkt sie wie im strobo-mode
Lässt sich "strobo-mode" in eine Frequenz umrechnen?
Aber das kling nicht normal.
Ich tippe am ehesten auf Hardware-Probleme beim JeeLink.
Wie sieht denn die aufgebaute Schaltung aus?
Ist da tatsächlich ein RFM69 und ein RFM12 dran?
Hi,
auf der grünen Platine auf dem Stick steht:
H
RF69
1448
W2V995
von einem RF12 finde ich nix drauf.
Hier noch ein Video dazu:
https://videobin.org/+gvj/kv2.html
habe mit den JeeLink Jungs aus England Kontakt aufgenommen, die würden sagen da jeder Stick vor auslieferung auf Funktion geprüft wird, sollte es wohl eher etwas anderes sein. Sendet der TX 25 vielleicht nix? kann ich das irgendwie feststellen?
Zitat von: aGeftw am 17 März 2017, 08:10:42
[LaCrosseITPlusReader.10.1r (RFM69CW f:868300 r:17241) + (RFM12B f:868300 r:9579)]
Dass als zweites Radio ein RFM12B erkannt wird, ist nicht korrekt.
Und die Blinkerei ist auch nicht korrekt.
Ich muss heute Abend mal was probieren, ich melde mich dann.
Brauchst erst mal nichts weiter versuchen, habe genug gesehen.
Ok, danke dir. ich warte auf antwort :)
@aGeftw: probier mal bitte mit der angehängten Version.
Mit der empfange ich meine TX25IT definitiv (ohne Strobo)
Bei mir wird mit der 10.1r auch ein RFM12B als zweites Radio für einen JeeLink v3c angezeigt:
[LaCrosseITPlusReader.10.1r (RFM69CW f:868300 t:20~3) + (RFM12B f:868300 r:9579)]
Zitat von: mahowi am 21 März 2017, 00:22:52
Bei mir wird mit der 10.1r auch ein RFM12B als zweites Radio für einen JeeLink v3c angezeigt
Ja, das Problem konnte ich nachvollziehen und beheben.
Ich denke, dass es heute Abend wohl eine 10.1s gibt.
ich probiers gleich aus, wenn ich zu hause bin.
danke
aber eine frage, wie flash ich den mit dem hex file? ich habe bis jetzt über fhem geflashet mit set myJeeLink flash und über arduino, aber da benötige ich den kompletten sketch.
Hi,
leg doch die hex unter dem richtigen Namen in /opt/fhem/firmware ab und flash über fhem ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Also der Chip wird jetzt richtig angezeigt:
model
[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
aber irgendwie empfängt er den TX25 nicht ?
kann es soch sein, dass der defekt ist?
ich hatte vorgestern mal eine ältere Version geflashed, und da hatte ich zumindest genau 1 mal im log stehen, unknown device 25 for LaCrosse.
nun steht mit verbose 5 aber gar nichts drin, wenn ich die battery einlege
Zitat von: aGeftw am 22 März 2017, 07:34:34
Der TX25IT funktioniert bei mir auch mit der "Strobo-Variante", die das zweite Radio falsch anzeigt.
Bei Dir ist das ein anderes Problem.
Habe gerade nochmal nachgeschaut, Du hast TX25
TP-IT geschrieben, mir sind aber nur TX25-IT geläufig, das "TP" kenne ich nicht.
Kannst Du mal verdeutlichen, was das genau für ein Sensor ist? Foto vom Typenschild?
Hier ein Foto der Rückseite.
Zitat von: aGeftw am 22 März 2017, 19:13:32
Hier ein Foto der Rückseite.
Ich befürchte, dass ein TX25TP-IT ein anderes Protokoll als ein TX25IT sendet.
Oder er ist defekt.
Habe gerade die Version 10.1s eingecheckt.
Da ist die Radio-Erkennung korrigiert.
Die Änderungen für den jeelink, fließen diese auch in das LaCrosse Gateway ein?
Gesendet von meinem E6653 mit Tapatalk
Zitat von: sash.sc am 22 März 2017, 23:36:14
Die Änderungen für den jeelink, fließen diese auch in das LaCrosse Gateway ein?
Ja, sofern erforderlich. In diesem Fall war das LGW nicht betroffen.
Zitat von: HCS am 22 März 2017, 08:13:18
Habe gerade nochmal nachgeschaut, Du hast TX25TP-IT geschrieben, mir sind aber nur TX25-IT geläufig, das "TP" kenne ich nicht.
Der TX25TP-IT wird mit der Wetterstation WS8301 geliefert und ist ein Zweikanal-Sender: Ein interner Messkanal und ein Sondenkanal.
Gruß Friedrich
Hallo,
habe den TX25TP-IT aber einzeln gekauft und der Lieferant hat gesagt, dieser ist nicht von dem Verbund mit der WS8301 rausgenommen worden.
Er hat noch 49 Stück im Karton liegen, wovon alle TX25TP-IT drauf stehen haben.
Er behauptet, die Chinesen schreiben immer irgendwas drauf und es ändert sich ständig.
Zitat von: aGeftw am 23 März 2017, 10:33:34
habe den TX25TP-IT aber einzeln gekauft und der Lieferant hat gesagt, dieser ist nicht von dem Verbund mit der WS8301 rausgenommen worden.
Er hat noch 49 Stück im Karton liegen, wovon alle TX25TP-IT drauf stehen haben.
Was erst mal keinerlei Relevanz hat.
Zitat von: aGeftw am 23 März 2017, 10:33:34
Er behauptet, die Chinesen schreiben immer irgendwas drauf und es ändert sich ständig.
Was auch für die Protokolle, die die Sensoren senden, gilt. Neue Protokolle und neue data rates erfinden, da sind die ganz groß drin.
Ohne so ein Ding zu haben, vermag ich nicht zu sagen ob:
- TX25TP-IT kompatibel zu TX25IT ist
- Dein TX25TP-IT nicht sendet
- Dein JeeLink nicht empfängt
Was sicher ist: ich habe drei TX25IT (siehe Foto weiter oben) auf denen vorne LaCrosse IT+ und hinten TX25IT draufsteht und die funktionieren alle drei.
Das sind meine Wasseralarmgeber.
Hallo zusammen,
neuer Sender mit selber Bezeichnung aus der selben Lieferung vom Lieferanten heute bekommen, funktioniert sofort.
Also ist wohl der TX25 defekt (der erste)
Habe eine Frage, kann ich den Tempfühler2 (die Sonde) direkt draußen anzeigen lassen im Device? Momentan zeigt er die Tempfühler1 an.
Zitat von: aGeftw am 24 März 2017, 18:33:07
Habe eine Frage, kann ich den Tempfühler2 (die Sonde) direkt draußen anzeigen lassen im Device? Momentan zeigt er die Tempfühler1 an.
set blabla stateFormat T1: temperature T2: temperature2
Hallo
Weiß nicht ob ich hier richtig bin, Aber kann man den TX23 auch ohne Wetterstation betreiben?
Zb. mit Arduino und nen Funkchip?
Würde gerne nur den TX23 Windsensor haben. Habe im haus schon mehrere Lacrosse Temperatur Fühler.
Frage die alle mit meinem Jeelink Clone ab.
Danke
Müsste gehen: https://forum.fhem.de/index.php/topic,14786.msg297293.html#msg297293
Zitat von: KernSani am 01 April 2017, 18:32:05
Müsste gehen: https://forum.fhem.de/index.php/topic,14786.msg297293.html#msg297293
Nein
Zitat von: Wuffi_steel am 01 April 2017, 17:22:15
Weiß nicht ob ich hier richtig bin, Aber kann man den TX23 auch ohne Wetterstation betreiben?
Zb. mit Arduino und nen Funkchip?
Würde gerne nur den TX23 Windsensor haben. Habe im haus schon mehrere Lacrosse Temperatur Fühler.
Frage die alle mit meinem Jeelink Clone ab.
Der geht von Haus aus mit dem JeeLink-Sketch nur in Verbindung mit einem TX22 und dem Regenmesser.
Wenn, dann müsstes Du ihm eine eigene Auswerteelektronik verpassen, die das Protokoll vom TX22 sendet.
ZitatWenn, dann müsstes Du ihm eine eigene Auswerteelektronik verpassen, die das Protokoll vom TX22 sendet.
Ich suche schon danach aber bin leider erfolglos. Wird wohl noch keiner gemacht haben.
Werde mir wohl einen TX22 um 100€ kaufen müssen :'( :'(
@Wuffi_steel
Wenn du dir nur den Mast einer WH3080/WH1080 (http://www.ebay.de/itm/Ersatz-Wettermast-fur-WH1080-Pass14c-/330832213045?hash=item4d0722f435:g:KrcAAOSwstxU22lm)
holst und einen Nano + CC1101 (Signalduino) hast du einen Windmesser mit Temp, Hum, Regen, ggf. Solar UV/Lux. (https://forum.fhem.de/index.php/topic,67587.msg590469.html#msg590469 oder https://forum.fhem.de/index.php/topic,39451.msg316447.html#msg316447)
Hinweise beachten: https://forum.fhem.de/index.php/topic,14786.msg363766.html#msg363766 oder Wiki zur WS 1080 (https://wiki.fhem.de/wiki/JeeLink).
pejonp
@pejonp
Ich habe schon einen Jeelink Clone https://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz (https://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz)
Arbeite mit 868 MHz und den TX23 habe ich auch schon.
Bräuchte nur den Wind weil ob es regnet oder nicht ist mir ehrlich gesagt egal. Temp und Hum habe ich von den Lacrosse Sensoren.
Wollte das alles über einen Empfänger laufen lassen.
Stecken eh schon 4 am Pi Jeelink,Cul,MySensor,Homatik
Der Pi wird langsam voll :)
@Wuffi_steel
Wenn du eine WH1080 mit einem FSK Sender bekommst kannst du diese mit dem JeeLink empfangen.
Diese wirst du wahrscheinlich schwer bekommen, deshalb der Hinweis. Die man jetzt so zu kaufen bekommt, senden OOK.
pejonp
Hallo,
Frage zur Einbindung von TFA Dostmann 30.3060.01 Funkthermo-Hygrometer Klima Home + Inklusive 3 Funksender für Temperatur und Luftfeuchtigkeit...
Ich habe bisher nix darüber im Net / Forum zu den Sensoren gefunden... aber vielleicht kann mir hier ja jemand weiterhelfen.
Es geht um folgende Wetterstation + Funksensoren (30.3180.IT).
https://www.amazon.de/TFA-Dostmann-30-3060-01-Funkthermo-Hygrometer-schwarz/dp/B014WB3EY6/ref=sr_1_5?ie=UTF8&qid=1491473539&sr=8-5&keywords=tfa
Ich habe einen JeeLink im Einsatz mit LaCrosse Sketch... (neben einem Cul)
Autocreate an. InitCommand momentan: 7m 30t v (aber schon verschiedene Einstellungen versucht)
Der Jeelink empfängt auch etwas allerdings sehr unregelmäßig und immer mit einer anderen ID...
siehe Auszug aus dem Log im Anhang...
Hat hier jemand eine Idee?
Geht der TFA Dostmann / Wertheim 30.3180.IT überhaupt?
Gruss Tczerny
So endlich habe ich einen Sketch für den Arduino gefunden was funktioniert.
/**
# Arduino-LaCrosse-TX23-Library
LaCrosse TX23 is a wind speed and direction sensor. It uses 3 wires for communication and power:
Pin1 - Brown(Black) - DATA
Pin2 - Red - Vcc
Pin3 - Green - N/C
Pin4 - Yellow - GND
DATA pin is to be connected directly to one of Arduino ports.
Created by Krzysztof Egzmont, 06.11.2016.
Based on https://www.john.geek.nz/2012/08/la-crosse-tx23u-anemometer-communication-protocol/
Big thanks for John.
Donations:
Bitcoin - 1JrHQwJWt1JNZepT1EXqPSioXcwD227nnU
Ethereum - 0xFC9713013e78f6F14bA5064E36f875dbbB32B94a
BSD license, all text above must be included in any redistribution
*/
#include <LaCrosse_TX23.h>
//DATA wire connected to arduino port 4
LaCrosse_TX23 anemometer = LaCrosse_TX23(4);
void setup()
{
Serial.begin(9600);
}
void loop()
{
String dirTable[]= {"N","NNE","NE","ENE","E","ESE","SE","SSE","S","SSW","SW","WSW","W","WNW","NW","NNW"};
float speed;
int direction;
if(anemometer.read(speed, direction))
{
Serial.println("Speed = " + String(speed,1) + " m/s");
Serial.println("Dir = " + dirTable[direction]);
}
else
{
Serial.println("Read error");
}
//delay between succesive read requests must be at least 2sec, otherwise wind speed will read 0.
delay(2000);
}
Serial ausgabe Speed = 0.0 m/s
Dir = W
Aber wie kann ich das zu meinen JeelinkClone Senden?
RFM12B-868 + Arduino ok, Aber der sketch?
Da laufe ich im kreiss. ???
Kann mir das wer helfen? Danke
@Wuffi_steel
mit diesem Sketch wirst du nicht weiter kommen.
Schau mal hier -> https://github.com/bunnyhu/ESP8266_TX20_wind_sensor . Stromversorgung ??
Jetzt must du vielleicht noch ein Protokoll nehmen was FHEM versteht z.B. KeyValue-Protokoll.
Oder http://www.ebay.de/itm/Wetterstation-WS-1600-Wind-Regen-Temperatur-TOP-/252844254617?hash=item3adeb12599:g:t14AAOSwt5hYhIyy
pejonp
Danke für die fielen Infos.
Hab das ganze mit MYSENSOR gebaut. (TX23 to FHEM)
RAW vom Keller PI defmod WindSensor MYSENSORS_DEVICE 93
attr WindSensor IODev MSG
attr WindSensor mapReading_direction1 1 direction
attr WindSensor mapReading_wind1 1 wind
attr WindSensor mode node
attr WindSensor room MySensors
attr WindSensor version 2.1.1
setstate WindSensor 2017-04-09 19:54:27 SKETCH_NAME Wind Sensor
setstate WindSensor 2017-04-09 19:54:27 SKETCH_VERSION 1.0
setstate WindSensor 2017-04-09 20:02:08 direction1 270.0
setstate WindSensor 2017-04-09 19:54:25 parentId 0
setstate WindSensor 2017-04-09 20:02:08 wind1 0.0
RAW fom Live PI defmod WindSensor dummy
attr WindSensor room 06_Wetter
attr WindSensor stateFormat windSpeedmps km/h | windDirectionTXT
attr WindSensor userReadings windDirectionTXT {deg2heading(ReadingsVal("WindSensor","direction1",0));;;;}
setstate WindSensor 0 km/h | W
setstate WindSensor 2017-04-09 20:02:54 direction1 270.0
setstate WindSensor 2017-04-09 17:24:42 pressure2 4
setstate WindSensor 2017-04-09 20:02:54 wind1 0.0
setstate WindSensor 2017-04-09 20:02:54 windDirectionTXT W
setstate WindSensor 2017-04-09 20:02:54 windSpeedmps 0
99_myUtils.pm### setzt Windrichtung (1-360 Grad) in Text um
sub deg2heading
{
my $point = int ((($_[0] + 11.25) % 360) / 22.5);
return (qw/N NNO NO ONO O OSO SO SSO S SSW SW WSW W WNW NW NNW/)[$point];
}
PS: Sketch für nen Arduini nano oder pro mini!
Langsam wird das so was on off topic hier ...
Zitat von: HCS am 09 April 2017, 21:05:49
Langsam wird das so was on off topic hier ...
Kein Wunder nach 141 Seiten und einem über 3 Jahren alten Thread :-), aber es ist doch immer wieder erfrischend zu lesen, wie aktiv die Benutzergruppe ist.
LG
/robin
Hallo,
ich habe auch etliche TX29DTH mit einem JeeLink Clone laufen.
Ich steuere damit seit langem erfolgreich meine Fußbodenheizung.
Nun ist mir im Log aufgefallen das ich oft folgende Meldungen erhalte:
Use of uninitialized value $value in concatenation (.) or string at fhem.pl line 4422.
Argument "" isn't numeric in numeric lt (<) at (eval 350612) line 1.
Argument "" isn't numeric in numeric gt (>) at (eval 350612) line 1.
Argument "" isn't numeric in numeric lt (<) at (eval 350614) line 1.
Argument "" isn't numeric in numeric gt (>) at (eval 350614) line 1.
Ich vergleiche die gesendeten werte per DOIF mit festgelegten Grenzen (Feuchte / Temp Alarm)
Nun habe ich mal die Werte der Sensoren über längere Zeit mitgeloggt und folgendes festgestellt:
2017-04-19_21:33:39 TH_Buero temperature: 19.7
2017-04-19_22:06:18 TH_Buero temperature: 19.4
2017-04-19_22:50:28 TH_Kueche temperature:
2017-04-19_22:50:57 TH_Bad temperature:
2017-04-19_23:03:33 TH_Buero temperature: 19.1
2017-04-19_23:14:25 TH_Bad temperature: 19.5
2017-04-19_23:20:27 TH_Ankleide temperature:
2017-04-19_23:29:22 TH_Wohnzimmer temperature:
2017-04-19_23:45:40 TH_Buero temperature: 18.9
2017-04-19_23:55:36 TH_Schlafzimmer temperature:
Ab und zu senden die Sensoren leere readings.
Das DOIF kann damit nix anfangen und dann kommt es zu den Fehlermeldungen (denke ich)
Wie kann es sein das eine Event abgesetzt wird ohne das es einen Wert gibt ?
Hier noch die Def eines Sensors:
define TH_Bad LaCrosse 1A
attr TH_Bad IODev JeeLink
attr TH_Bad doAverage 1
attr TH_Bad doDewpoint 1
attr TH_Bad event-aggregator temperature:600:linear:mean,humidity:600:linear:mean,dewpoint:600:linear:mean
attr TH_Bad event-on-change-reading temperature:0.2,humidity:2,dewpoint:0.2,battery
attr TH_Bad group Raumklima
attr TH_Bad room 7.0_Klima
Hat jemand sowas auch schon gehabt ???
Zitat von: Skusi am 20 April 2017, 19:00:01
Hat jemand sowas auch schon gehabt ???
Kommt in meinen Logs nicht vor.
Nimm mal testweise für einen Sensor event-aggregator und event-on-change-reading weg, ob es dann immer noch auftritt.
Zitat von: HCS am 28 November 2016, 21:57:11
Aus Deinen Werten lese ich:
a4 a5 6 23 10 45 20 0 34 0 40 0 98
ID 12 (Hex) 22.3 °C und 45 % rH und sie sendet das "new battery" flag, die Batterien sind also noch nicht so lange drin
a4 a5 6 22 10 45 20 0 34 0 40 0 2d
22.20 °C 45 % rH
In beiden Fällen Windstille. Ich vermute, die liegt in der Wohnung.
Mach das mal wieder rückgängig (mit den Rohdaten kann das LaCrosse device in FHEM nichts anfangen) und definiere in FHEM manuell ein device:
define WS1600 LaCrosse 12
und schau mal, ob da Daten eintrudeln.
Die 12 stimmt nur, wenn du seit diesem Log die Batterien nicht raus hattest.
Hallo, wie bist Du auf die 12 gekommen, habe die Batterie wechseln müssen und jetz wird die WS1600 mit replaceBatteryForSec 1200 ignore_battery nicht mehr gefunden :-(
Zitat von: Freibeuter am 14 Mai 2017, 21:38:58
habe die Batterie wechseln müssen und jetz wird die WS1600 mit replaceBatteryForSec 1200 ignore_battery nicht mehr gefunden :-(
Genau das habe ich mit meiner WS1600 (also TX22) am Wochenende mindestens fünf mal gemacht, als ich sie repariert habe (Schaden am Kabel zum Windrad) und sie wurde jedes mal erkannt.
Allerdings mit neu eingelegten Batterien und ohne ignore_battery und mit 120 und nicht mit 1200.
Und mit einem LaCrosseGateway und nicht einem JeeLink.
Aber zumindest ungefähr ähnlich war es ;D ;D
Zitat von: Freibeuter am 14 Mai 2017, 21:38:58
Hallo, wie bist Du auf die 12 gekommen
Aufbau der Pakete, wobei in DDDD DD die Adresse übertragen wird:
SSSS.DDDD DDAE.LQQQ ... usw.
a 4 a 5 ... usw.
Berechnug der Adresse:
ID = ((bytes[0] & 0xF) << 2) | ((bytes[1] & 0xC0) >> 6)
Beispiel, warum "a4 a5 6 23 10 45 20 0 34 0 40 0 98" die ID 0x12 ergibt:
(a4 & 0xF) << 2 = 0x10
(a5 & 0xC0) >> 6 = 0x02
0x10 | 0x02 = 0x12
====
Hallo,
ich habe meinen Raspi 2 Modell B mit FHEM 5.8 neu aufgesetzt und den JeeLink Clone neu geflashed, seit dem werden mein TX29-IT u. TX37-IT nicht mehr erkannt.
[LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
Die Behehle:
set myJeeLink LaCrossePairForSec 300 ignore_battery
set myJeeLink LaCrossePairForSec 120
(auch mit varialblen Zeitwerten) haben nichts geholfen.
Wenn ich den Jeelink Clone and meinen PC anschließe und in der Arduino Entwicklungsumgebung den seriellen Monitor öffne, empfange ich:
OK 9 17 129 4 246 106
OK 9 8 1 4 173 106
Ich bin für jeden Tipp dankbar.
Gruß
Carpy
Zitat von: Carpy am 01 Juli 2017, 19:57:22
Ich bin für jeden Tipp dankbar.
Zeig mal ein
list myJeeLink
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9AL9B3R-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9AL9B3R-if00-port0@57600
FD 4
NAME myJeeLink
NR 20
PARTIAL
RAWMSG OK 9 11 129 4 224 42
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
myJeeLink_MSGCNT 46
myJeeLink_TIME 2017-07-01 20:05:57
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:
2017-07-01 20:05:57 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Hmmm, sieht gut aus, keine Ahnung, warum autocreate bei Dir nicht funktioniert.
Grundsätzlich funktioniert autocreate schon (meine FS20 wurden erkannt) nur die Temperatursensoren wollen nicht :(
Aktuel habe ich den CUL-Clone 433MHz und den Jeelink-Clone 868 MHz angeschlossen.
Bisher habe ich den Jeelink-Clone als Empfänger für meine TX 29/39-IT gesehen, meine FS20 wurden aber auch erkannt und können auch geschaltet werden.
Ist es richtig dass ich mit dem Jeelink-Clone meine FS20 schalten kann??
Hi,
Schau in Dein Device unter LastIO dann weisst Du es ;-) oder zeig uns ein list <dev>!
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
list Jeelink:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9AL9B3R-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9AL9B3R-if00-port0@57600
FD 11
NAME myJeeLink
NR 20
PARTIAL
RAWMSG OK 9 9 129 4 212 234
STATE initialized
TYPE JeeLink
initMessages
model [LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
myJeeLink_MSGCNT 93
myJeeLink_TIME 2017-07-03 19:23:12
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:
2017-07-03 19:23:12 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
Manuell (Schalter):
2017.07.03 19:05:09 3: FS20 set FS20_d14b00 on
2017.07.03 19:05:10 3: FS20 set FS20_d14b01 on
2017.07.03 19:05:41 3: FS20 set FS20_d14b00 off
2017.07.03 19:05:41 3: FS20 set FS20_d14b01 off
über FHEM:
2017.07.03 20:07:25 3: FS20 set FS20_d14b00 on
2017.07.03 20:07:26 3: FS20 set FS20_d14b01 on
2017.07.03 20:07:29 3: FS20 set FS20_d14b00 off
2017.07.03 20:07:30 3: FS20 set FS20_d14b01 off
Woch sehe ich für ein Device das "LastIO"?
Hi im
list FS20_d14b01
würde ich sagen ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Was ein Ratespiel :o
Um es abzukürzen: der JeeLink kann kein FS20
Aha: https://forum.fhem.de/index.php?topic=31979.msg244206#msg244206
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: RaspiLED am 03 Juli 2017, 21:04:44
Aha: https://forum.fhem.de/index.php?topic=31979.msg244206#msg244206
Zitat von: Carpy am 03 Juli 2017, 20:05:21
model [LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
Und nun erklärst Du mir mal, wie der LaCrosseITPlusReader.10.1s das machen soll.
@Arnd: danke für die Info!
Internals:
BTN 01
CUL433_MSGCNT 4
CUL433_RAWMSG 810b04xx0101a001d14b010000
CUL433_RSSI -61
CUL433_TIME 2017-07-03 20:02:56
DEF d14b 01
IODev CUL433
LASTInputDev CUL433
MSGCNT 4
NAME FS20_d14b01
NR 38
STATE off
TYPE FS20
XMIT d14b
Code:
1 d14b 01
Readings:
2017-07-03 20:07:30 state off
Attributes:
IODev CUL433
room FS20
@HCS: Ich hab's verstanden..
Gibt es nicht irgendeine "Monitoring-Funktion" in FHEM was über den Jeelink-Clone empfangen wird (wenn ich am PC über die serielle Schnittstelle sehe dass der Jeelink-Clone Daten empfängt)?
Zitat von: Carpy am 03 Juli 2017, 21:48:55
@HCS: Ich hab's verstanden..
Das ist gut.
Aber eigentlich war die Frage, wie der LaCrosseITPlusReader.10.1s FS20 empfangen soll, an RaspiLED gerichtet :)
Zitat von: Carpy am 03 Juli 2017, 21:48:55
Gibt es nicht irgendeine "Monitoring-Funktion" in FHEM was über den Jeelink-Clone empfangen wird (wenn ich am PC über die serielle Schnittstelle sehe dass der Jeelink-Clone Daten empfängt)?
Wenn das JeeLink device Daten von der Schnittstelle bekommt, steht das zuletzt erhaltene Datenpaket in RAWMSG.
myJeeLink_TIME zeigt an, wann es eingegangen ist.
Die Internals werden nur dann aktualisiert angezeigt, wenn man einen Refresh im Browser macht.
Internals:
...
RAWMSG OK 9 57 130 2 213 125
STATE initialized
...
myJeeLink_TIME 2017-07-03 22:04:10
Attributes:
...
verbose 5 Mit verbose 5 sollte man, sofern Daten eingehen, so etwas im Log haben:
2017.07.03 22:08:21 5: JeeLink/RAW: /OK 9 28 1 4 213 54
2017.07.03 22:08:21 5: myJeeLink: dispatch OK 9 28 1 4 213 54
2017.07.03 22:08:23 5: JeeLink/RAW: /OK 9 41 1 4 214 54
2017.07.03 22:08:23 5: myJeeLink: dispatch OK 9 41 1 4 214 54
2017.07.03 22:08:24 5: JeeLink/RAW: /OK 9 57 1 4 211 106
2017.07.03 22:08:24 5: myJeeLink: dispatch OK 9 57 1 4 211 106
2017.07.03 22:08:26 5: JeeLink/RAW: /OK 9 47 1 4 182 76
Verbose = 5 und "set myJeeLink LaCrossePairForSec 600 ignore_battery"
abgesetzt, jetzt "taucht" im Event monitor
2017-07-03 22:51:26 Global global UNDEFINED LaCrosse_0C LaCrosse 0C
auf was zu
myJeeLink_TIME 2017-07-03 22:51:26
passt.
Logfile:
2017.07.03 22:51:26 5: JeeLink/RAW: /OK 9 1
2017.07.03 22:51:26 5: JeeLink/RAW: OK 9 1/2 129 4 191 138
2017.07.03 22:51:26 5: myJeeLink: dispatch OK 9 12 129 4 191 138
2017.07.03 22:51:26 5: Loading ./FHEM/36_LaCrosse.pm
2017.07.03 22:51:26 4: LaCrosse: Unknown device 0C, please define it
2017.07.03 22:51:26 5: Starting notify loop for global, 1 event(s), first is UNDEFINED LaCrosse_0C LaCrosse 0C
2017.07.03 22:51:26 4: autocreate: received 1 event(s) for 'LaCrosse 0C' during the last 120 seconds
2017.07.03 22:51:26 4: autocreate: ignoring event for 'LaCrosse 0C': at least 2 needed
einer wird erkannt aber nicht eingebunden.
Jetzt setze ich verbose erstmal wieder auf 3 zurück..
Was mich wundert: "set myJeeLink LaCrossePairForSec 600 ignore_battery" => "during the last 120 seconds"
Moin,
habe gerade folgendes im meinem Logfile entdeckt:
...
2017.07.04 04:33:23 3: myJeeLink: Unknown code OK LS 6 0 5 30 3 202 55, help me!
...
2017.07.04 15:54:53 3: myJeeLink: Unknown code OK LS 6 0 11 94 2 196 70, help me!
...
hilft das irgendwie weiter?
Gruß
Carpy
Zitat von: Carpy am 05 Juli 2017, 00:23:31
hilft das irgendwie weiter?
Nein. Da hat der Sketch auf dem JeeLink irgend einen Funkmüll als LevelSender erkannt.
Es zeigt nur, dass der JeeLink Dinge empfängt und diese in FHEM im JeeLink device ankommen.
Kann es sein, dass Dein FHEM nicht ganz auf dem aktullen Stand ist?
Das solltest Du eigentlich seit dem 15.06.2017 gar nicht mehr zu sehen bekommen.
Zu diesem Thema:
Zitat2017.07.03 22:51:26 5: myJeeLink: dispatch OK 9 12 129 4 191 138
2017.07.03 22:51:26 5: Loading ./FHEM/36_LaCrosse.pm
2017.07.03 22:51:26 4: LaCrosse: Unknown device 0C, please define it
2017.07.03 22:51:26 5: Starting notify loop for global, 1 event(s), first is UNDEFINED LaCrosse_0C LaCrosse 0C
2017.07.03 22:51:26 4: autocreate: received 1 event(s) for 'LaCrosse 0C' during the last 120 seconds
2017.07.03 22:51:26 4: autocreate: ignoring event for 'LaCrosse 0C': at least 2 needed
Steck den JeeLink nochmal an den PC und schaue, in welchem Zeitabstand Daten einlaufen, die mit "OK 9 12" beginnen und ob das konstant über einen längeren Zeitraum (5-10 Minuten) stattfindet.
Der LaCrosse Sensor sendet alle 4 Sekunden, also müsste alle 4 Sekunden ein "OK 9 12 ..." kommen.
Letztes Update war:
2017.07.03 22:37:42 1: update finished, "shutdown restart" is needed to activate the changes.
Jeelink-Clone an PC:
19:32:00 [LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
19:33:30 OK 9 8 1 5 40 106
19:38:20 OK 9 8 1 5 38 106
19:38:20 OK 9 8 1 5 38 106
(Zeitstempel sind von mir)
Zitat von: Carpy am 05 Juli 2017, 19:45:51
19:32:00 [LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
19:33:30 OK 9 8 1 5 40 106
19:38:20 OK 9 8 1 5 38 106
19:38:20 OK 9 8 1 5 38 106
(Zeitstempel sind von mir)
Das kann icht stimmen, zumindest die letzten beiden. Die können nicht beide um 19:38:20 gewesen sein.
Wenn das aber alles war, was in 10 Minuten kam, dann liegt das Problem auf der Sensor/JeeLink Seite.
Dann hat autocreate mit "nur ein mal in 120 Sekunden" recht gehabt.
Was für ein Sensor ist das?
ZitatDas kann ich stimmen, zumindest die letzten beiden. Die können nicht beide um 19:38:20 gewesen sein.
Die Daten sind mit einer Abweichung von wenigen Sekunden im Log angekommen (die zwei Einträge mit :20 sind nicht 100%tig korrekt).
Als Jeelink-Clone verwende ich einen Arduino Nano mit RFM12B.
Als ich mit FHEM angefangen habe hat alles wunderbar funktioniert. Bei einigen Updates (in diesem Jahr) habe ich dann z.B. keine Temperaturwerte mehr empfangen und ein paar Updates später ging es wieder (halbwegs), d.h. meistens hatte ich nach den Updates Probleme ich im Bereich Temperaturmessung...
Zitat von: Carpy am 06 Juli 2017, 10:46:20
Als Jeelink-Clone verwende ich einen Arduino Nano mit RFM12B.
Darf ich mal den Schaltplan sehen?
Zitat von: Carpy am 06 Juli 2017, 10:46:20
Bei einigen Updates (in diesem Jahr) habe ich dann z.B. keine Temperaturwerte mehr empfangen und ein paar Updates später ging es wieder (halbwegs), d.h. meistens hatte ich nach den Updates Probleme ich im Bereich Temperaturmessung...
Das hat nichts mit FHEM-Updates zu tun.
Wenn der JeeLink-Clone in 10 Minuten nur drei mal Daten für einen Sensor liefert, liegt das Problem beim JeeLink-Clone.
Der Aufbau ist nach folgender Anleitung erfolgt:
https://blog.gummibaer-tech.de/jeelink-433-868-mhz-selbstbau/
das ganze lief wunderbar (z.B. Überwachung der Temp. im Kühlschrank)..
Auf die Hardware habe ich aktuell keinen Zugriff
Ich habe den Jeelink-Clone noch mal mit dem PC verbunden und in der Arduino Entwicklungsumgebung den Seriellen Monitor geöffnet, dann habe ich den Kursor im oberen Feld positioniert und Enter gedrückt: kurz hintereinander wurde zwei Datensätze eingelesen (s. Anhang), in der zweiten Minute wurden ca. 11 Datensätze eingelesen und in Minute 3 wurden 3 Datensätze eingelesen
Zitat von: Carpy am 06 Juli 2017, 11:06:26
Der Aufbau ist nach folgender Anleitung erfolgt:
https://blog.gummibaer-tech.de/jeelink-433-868-mhz-selbstbau/
OK, mal wieder ein Clone ohne Pegelanpassung.
Zitat von: Carpy am 06 Juli 2017, 23:07:26
in der zweiten Minute wurden ca. 11 Datensätze eingelesen und in Minute 3 wurden 3 Datensätze eingelesen
Zu wenig. Du hast zwei Sensoren, die jeweils alle 4 Sekunden senden.
Hol sie mal näher ran, ob das nur ein Reichweitenproblem ist.
Aber vielleicht hat es ja der RFM12 ohne LevelShifter auch schon so halb hinter sich ...
Es ist wirklich auffällig, dass bei fast allen "Das geht nicht / nicht zuverlässig / nur manchmal" fast immer das Wort "Clone" vorkommt ...
Und diese "Clone" sind kein Clone, das Original ist völlig anders aufgebaut.
Eine Alternative: Du kaufst Dir ein NODEMCU devikit V2.0 für ca. 8€ und einen RFM69CW für ca. 3€ (wenn man beide in DE bestellt, aus China noch billiger)
und baust Dir ein LaCrosseGateway.
https://forum.fhem.de/index.php/topic,43672.0.html
Das hier entspricht dann sinngemäß dem JeeLink-Clone und hat jede Menge Vorteile, z.B. dass es per WiFi angebunden ist und man es an eine für den Empfang günstige Stelle stellen kann:
https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=40037
Oder du nimmst hier ein fertig gelötetes, getestetes Gateway:
https://forum.fhem.de/index.php/topic,70425.0.html (https://forum.fhem.de/index.php/topic,70425.0.html)
Ich glaube eh, dass ich mal mit Billy reden muss, dass er in Beitrag #1 eine Abhandlung über JeeLink, Clone und ob und warum evtl. ein LGW besser wäre, reinpackt.
Ich will den JeeLink-LaCrosse-Sketch jetzt nicht als Auslaufmodell darstellen, aber ein LGW kann bei gleich teurem Materialeinsatz deutlich mehr und in dem JeeLink-Sketch werde ich auch nur noch gröbste Fehler korrigieren, da hat es sich "ausgefeatured".
Nur muss man dann Glück haben, dass wenn man nach LaCrosse sucht, man zuerst das LGW entdeckt und nicht den JeeLink.
Ich denke, dass wir es erreichen müssen, dass jemand zumindest die Optionen kennt, um sich entscheiden zu können, was für ihn besser ist oder warum er unbedingt auf die JeeLink-Schiene will/muss.
@HCS: vielen Dank für Deinen Einsatz, die o.g. Informationen, Links u. Tipps, da ich eh schon einen NODEMCU in der Schublade habe werde ich damit befassen und den Jeelink-Clone dann mal lieber "begraben"....
@gloob: wenn ich nicht klar komme melde ich mich bei Dir, danke für das Angebot.
Mittlerweile funktioniert mein LaCrosseGateway :-) und ich sehe endlich wieder meine Tempearturdaten..
Zitat von: Carpy am 07 Juli 2017, 11:17:33
und den Jeelink-Clone dann mal lieber "begraben"....
Und bitte zusammen mit dem RFM12 begraben. Nimm einen RFM69CW.
@justme1968: ich bin gerade dabei, das LaCrosseGateway Modul zu ändern, dass die neue Statistik (https://fhem.de/stats/statistics.html) mit den models einen Sinn ergibt.
Dabei habe ich es auch gleich für das JeeLink Modul erledigt.
Im internal "model" steht nur noch das Modell mit Versionsnummer
Im internal "settings" der Rest, der danach kam
Hier der Patch:
--- 36_JeeLink.pm (revision 14692)
+++ 36_JeeLink.pm (working copy)
@@ -708,8 +708,18 @@
}
if($dmsg =~ m/^\[/ ) {
- $hash->{model} = $dmsg;
-
+ if($dmsg =~ m/^\[LaCrosseITPlusReader/) {
+ my $model = "";
+ my $settings = "";
+ ($model, $settings) = split(/ /, $dmsg, 2);
+ chop($settings);
+ $hash->{model} = substr($model, 1);
+ $hash->{settings} = $settings;
+ }
+ else {
+ $hash->{model} = $dmsg;
+ }
+
if( ReadingsVal($name,"state","" ) eq "opened" ) {
if( my $initCommandsString = AttrVal($name, "initCommands", undef) ) {
my @initCommands = split(' ', $initCommandsString);
habs eingecheckt.
gruss
andre
Zitat von: Tczerny am 06 April 2017, 12:26:41
Frage zur Einbindung von TFA Dostmann 30.3060.01 Funkthermo-Hygrometer Klima Home + Inklusive 3 Funksender für Temperatur und Luftfeuchtigkeit...
Ich habe bisher nix darüber im Net / Forum zu den Sensoren gefunden... aber vielleicht kann mir hier ja jemand weiterhelfen.
Es geht um folgende Wetterstation + Funksensoren (30.3180.IT).
[...]
Hat hier jemand eine Idee?
Geht der TFA Dostmann / Wertheim 30.3180.IT überhaupt?
Inzwischen ist es möglich, die Temperatur/Feuchte-Sensoren
TFA 30.3180 über einen DVB-T-Stick in FHEM zu integrieren. Ich habe dazu eine Anleitung (https://github.com/git-developer/fhem-examples/wiki/Temperatur-Feuchte-Sender-mit-tfrec-und-MQTT) geschrieben.
Hallo Zusammen,
erstmal vielen Dank für die tolle Unterstützung und die vielen Tipps hier im Forum.
Habe mich nun endlich registriert :-)
zum Thema:
Ich habe 2 Sensoren über den Jeelink mit LaCrosse-Sketch pairen können. Hat alles gut geklappt.
Leider bekomme ich keine Luftfeuchtigkeit. Lt. Dok. sollten die Sensoren das unterstützen.
Modelle sind: TFA30.3143.IT und TX35-IT.
Beispiel Raw-Message ist OK 9 9 1 4 218 106.
Lt. dem Post bedeutet wohl die 106 kein Sensor.
Ist das tatsächlich so oder hat jemand eine Idee, was falsch sein könnte?
Danke Euch schon mal.
Bernd
Zitat von: justme1968 am 06 Dezember 2013, 09:47:02
die werte an sich sind noch nicht komisch...
vergleich mal mit hier: http://forum.fhem.de/index.php/topic,14786.msg104623.html#msg104623 (http://forum.fhem.de/index.php/topic,14786.msg104623.html#msg104623)
106 -> es gibt keinen feuchtigkeits sensor
156 -> höchstes bit gesetzt -> batterie schwach
sind in der viertel stunde unknown Meldungen aufgetaucht? hast du beim pairForSev auch ignore_battery angegeben ?
gruss
andre
Zitat von: berndEEE am 02 August 2017, 21:04:12
Leider bekomme ich keine Luftfeuchtigkeit. Lt. Dok. sollten die Sensoren das unterstützen.
Modelle sind: TFA30.3143.IT und TX35-IT.
Meiner Meinung nach senden die beide nur Temperatur.
Verwechselst Du das evtl. mit TX35-DTH, der Temperatur und Feuchte sendet?
Zitat von: berndEEE am 02 August 2017, 21:04:12
Beispiel Raw-Message ist OK 9 9 1 4 218 106.
Mit der 106 "sagt" der Sensor definitiv, dass er keine Feuchte sendet.
Hi,
ich habe die WS1600 und einen Temperatursensor TX29-IT mit Hilfe dem Jeelink im Toggle Modus. (5m 30t 0a v)
Das bedeutet ja das er alle 30s die Datenrate ändert. Demzufolge verpasst man evtl. Windboen von der WS1600 aufzuzeichnen.
Wie ist es wenn innerhalb der besagten 30s der Regensensor durch seinen Kontakt die Regenmenge meldet. Wird die dann bei fhem auch nicht mit geloggt oder kommt die trotzdem danach an?
Ich möchte die Daten der WS1600 gern so genau wie möglich geloggt bekommen.
Gruß Thomas
Zitat von: Depechem am 15 August 2017, 09:28:13
Das bedeutet ja das er alle 30s die Datenrate ändert. Demzufolge verpasst man evtl. Windboen von der WS1600 aufzuzeichnen.
Ja.
Zitat von: Depechem am 15 August 2017, 09:28:13
Wie ist es wenn innerhalb der besagten 30s der Regensensor durch seinen Kontakt die Regenmenge meldet. Wird die dann bei fhem auch nicht mit geloggt oder kommt die trotzdem danach an?
Kommt an. Die Wippe erhöht einen Counter im Sensor, der irgend wann mal übertragen wird. Spätestens beim nächsten Wippen.
Zitat von: Depechem am 15 August 2017, 09:28:13
Ich möchte die Daten der WS1600 gern so genau wie möglich geloggt bekommen.
Dann wäre ein LaCrosseGateway sinnvoll, das kann mit mehreren RFM69 mehrere DataRates und Protokolle parallel.
Oder ein SuperJee.
Oder zwei JeeLink.
Meine Empfehlung ist das LaCrosseGateway.
Am Wochenende habe ich mit großem Interesse die 143 Seiten zu dem Thema durchgelesen. Was den TX-56 angeht... Dieser wurde zu Beginn hier mal kurz erwähnt.
Ist das zum aktuellen Stand wirklich so aussichtslos an seine Daten ranzukommen?
@HCS: Danke (und Sorry für das späte Danke :-))
Habe die Empfänger gegen andere Typen getauscht und es geht nun mit der Luftfeuchtigkeit.
Was mache ich falsch? Ich habe den JeeLink v3c und ein Temperatur Fühler läuft damit.
Aber meine gestern aufgestellte WS1600 bekomme ich nicht hin, sie wird nicht mal gefunden.
Eingestellt ist der Empfänger wie folgt:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04PI9J-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI04PI9J-if00-port0@57600
FD 22
NAME myJeeLink
NR 487
PARTIAL
RAWMSG OK 9 8 1 4 132 106
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 126279
myJeeLink_TIME 2017-08-14 00:45:46
settings (RFM69CW f:868280 t:30~3)
Helper:
DBLOG:
state:
logdb:
TIME 1501954770.11755
VALUE initialized
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:
2017-08-14 00:45:46 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 30t 0a 868280f v
Die mitgelieferte Basis Station empfängt Daten, also generell läuft es.
Zitat von: Christian72D am 23 August 2017, 20:46:54
initCommands 30t 0a 868280f v
initCommands 5m 30t 0a vwäre richtig.
Einen toggle setzen, ohne den Mode für die DataRates, hilft nicht.
Siehe hier: https://wiki.fhem.de/wiki/JeeLink#Toggle_und_Datenrate
OK, umgestellt, wird trotzdem nicht gefunden. :(
Noch jemand eine Idee?
Zitat von: Christian72D am 25 August 2017, 05:51:32
OK, umgestellt, wird trotzdem nicht gefunden. :(
Mach mal den toggle raus und setze die data rate testweise fest auf 8.842 kbps
Und dran denken, die initCommands werden nur angewendet, wenn sich FHEM neu verbindet.
Zitat von: HCS am 25 August 2017, 11:46:51
Und dran denken, die initCommands werden nur angewendet, wenn sich FHEM neu verbindet.
DAS war mein "Fehler". Steht aber nicht im Wiki, oder?
Danke auf jeden Fall.
Super... ganze 24 Stunden hat es geklappt, jetzt ist die Verbindung zur Wetter Station weg, die anderen beiden Sensoren klappen noch.
An der Entfernung kann es eigentlich auch nicht liegen, das sind keine 10m, da liegen zwei Zeigelstein- und eine Ytong Wand dazwischen, kein Stahl, keine großen elektrischen Leitungen...
Und ich hatte mich heute schon so auf den Regen gefreut...
Hallo ich nutze schon eine Weile das Jeelink Modul / LaCrosse zum Empfang meiner Wetterstation, gestern habe ich nun die Schaltung mit einem BMP 180 erweitert, dieser wird auch in den settings angezeigt aber leider bekomme ich keine Daten von dem BMP 180. Hier mal ein list, die Schaltung habe ich hier aus dem Thread (von HCS). Was mache ich da falsch?
VG
Frank
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A506AXVV-if00-port0@57600
FD 17
JLLaCrosse_MSGCNT 123309
JLLaCrosse_TIME 2017-09-20 17:26:02
NAME JLLaCrosse
NR 2059
PARTIAL
RAWMSG OK 9 10 1 4 185 106
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
settings (RFM69CW f:868300 r:17241) + BMP180
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:
2017-09-20 17:26:02 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -b 57600 -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
room System
timeout 300,3600
verbose 1
OK, kaum macht man es richtig, funktioniert es auch ;)
War falsch definiert.
Internals:
CFGFN
DEF 00
IODev JLLaCrosse
JLLaCrosse_MSGCNT 34
JLLaCrosse_RAWMSG OK WS 0 2 4 255 255 255 255 255 255 255 255 255 255 0 3 238
JLLaCrosse_TIME 2017-09-20 18:28:51
LASTInputDev JLLaCrosse
LaCrosse_lastRcv 2017-09-20 18:28:51
MSGCNT 34
NAME LaCrosse_00
NR 99660
STATE T: 27.9 P: 1006
TYPE LaCrosse
addr 00
battery_new 0
bufferedT 27.9
corr1 0
corr2 0
previousH 255
previousT 27.9
sensorType 2=NodeSensor
READINGS:
2017-09-20 18:28:51 battery ok
2017-09-20 18:28:51 error 0
2017-09-20 18:28:51 pressure 1006
2017-09-20 18:28:51 state T: 27.9
2017-09-20 18:28:51 temperature 27.9
Attributes:
IODev JLLaCrosse
alias Luftdruck Sensor
room Garten,LaCrosse
stateFormat T: temperature P: pressure
VG
Frank
Habe heute mal mit einem neuen RFM69CW, einem BMP180 und LaCrosse einen Testaufbau gemacht aber der RFM wird mir als RFM12B angezeigt, defekt oder was könnte da nicht stimmen?
Hat sich erledigt, war ein Kabel auf dem Breadboard kaputt :(
VG
Frank
@HCS
Hallo, eine Frage zum BMP und dem LaCrosseITPlusReader. Wäre es möglich, in einer zukünftigen Version, pressure bitte doch mit einer Nachkommastelle zu liefern. Das würde nicht nur mir weiterhelfen sondern auch anderen Usern die den Luftdruck plotten möchten. Ich scheitere leider daran das ich keinerlei c++ Kenntnisse habe um die erforderlichen Files anpassen zu können.
Viele Grüße
Frank
Zitat von: franky08 am 01 Oktober 2017, 19:07:13
@HCS
Hallo, eine Frage zum BMP und dem LaCrosseITPlusReader. Wäre es möglich, in einer zukünftigen Version, pressure bitte doch mit einer Nachkommastelle zu liefern. Das würde nicht nur mir weiterhelfen sondern auch anderen Usern die den Luftdruck plotten möchten. Ich scheitere leider daran das ich keinerlei c++ Kenntnisse habe um die erforderlichen Files anpassen zu können.
Zitat von: franky08 am 24 September 2017, 08:32:20
Ist aber egal, ich kann ja den Sensor über Firmata nehmen, dann lass ich das mit dem Larosse Gateway.
Ich dachte Du nimmst Firmata?
Nur um sicher zu sein, willst Du das jetzt für SuperJee oder LaCrosse Gateway?
Ich muss mir das mal anschauen. Das ist eine größere Nummer als nur ein wenig c++ Files anpassen.
Das Protokoll zw. JeeLink und dem LaCrosse-Modul in FHEM muss erweitert werden und das LaCrosse-Modul muss es dann natürlich können.
Da dieses aber auch vom LGW verwendet wird, muss das damit auch noch kompatibel sein.
Und konfigurierbar sollte es auch sein, weil ich auf keinen Fall das Verhalten bei allen bisherigen Anwendern einfach mal anders machen will.
Nix was man mal schnell in einer Werbepause macht.
@HCS
Ich habe z.Zt. LaCrosse und Firmata, parallel auf zwei Arduinos, laufen und nehme Firmata nur für den BMP180. Wenn LaCrosse oder LGW den Luftdruck mit der Nachkommastelle liefert, könnte ich den zweiten Arduino einsparen. Zur Zeit warte ich noch auf mein LGW Modul von Peter (PeMue) und wollte dieses dann nutzen.
Vielleicht kommst du ja irgendwann dazu den Code anzupassen, wäre ja auch was für die Zukunft.
Vielen Dank
Frank
Zitat von: franky08 am 01 Oktober 2017, 21:14:24
Zur Zeit warte ich noch auf mein LGW Modul von Peter (PeMue) und wollte dieses dann nutzen.
OK, für das LGW kann ich es mir schon eher vorstellen. PeMue hat ja gerade Platinen bestellt.
Dann sind wir hier im falschen Thread mit dem Thema.
Zitat von: franky08 am 01 Oktober 2017, 21:14:24
LaCrosse oder LGW den Luftdruck mit der Nachkommastelle liefert, könnte ich den zweiten Arduino einsparen. Zur Zeit warte ich noch auf mein LGW Modul von Peter (PeMue) und wollte dieses dann nutzen.
Da ich gerade den BME680 in das LaCrosseGateway implementiere, mache ich "nebenbei" die Nachkommastellen für BMP180, BME280 und BME680 mit.
Wichtig: im LGW,
nicht im alten JeeLink sketch
angepasste Version (WH24,WH25,W136): https://forum.fhem.de/index.php/topic,93280.msg859226.html#msg859226
Hallo,
ich habe LaCrosseITPlusReader10 und LaCrossGateway um die Sensoren WH25A (Innensensor HP1003) und W136 Ausseneinheit (Ventus W266 Wetterstation)
(https://github.com/letscontrolit/ESPEasyPluginPlayground/blob/master/_P124_Ventus_W266_RFM69.ino) erweitert.
W136:
Beim W136 muß die Empfangsfrequenz auf 869.820 MHz eingestellt sein und die Datenrate auf 4800. Die Daten werden im KeyValueProtokoll gesendet, da die normalen Daten der Wetterstation nicht gepasst haben (UV + Blitzerkennung).
Getest habe ich nur mit dem RFM69 Transceiver. Auf dem LaCrossGateway habe ich 2x RFM69 (1. und 4.)
Die Init-Einstellung ist: 3#4r 868300#4f 33#4t 4800r 0t 869820f v
Der W136 wird auch nur auf dem 1.RFM69 empfangen, beim 4.RFM69 kommt nichts.
WH25A:
Der WH25A ist der Innensensor der HP1003/HP1000 und die Datenrate ist 17.241 .
In den Sourcen habe ich folgende Anpassungen vorgenommen:
WSBase.cpp/.h
- KVProtokoll hinzugefügt: static String BuildKVDataString(struct Frame *frame, byte sensorType);
- weiter Parameter UV,strikesTotal, strikesDistance
LaCrosseITPlusReader10.ino / LaCrosseGateway.ino
- Baudrate 4800
- Einträge für W136 und WH25
neue Dateien für WH25.cpp/.h und W136.cpp/.h
Währe schön wenn es noch jemande gebrauchen könnte und dann auch noch mittestet.
Als Anlage die gepackten Sourcen und ein Bild vom Aufbau des LaCrossGateways.
Habe die aktuelle Source LaCrosseITPlusReader10t+WH25+W136.rar angepaßt.
Wiki habe ich keine Zugang, deshalb hier die Ergänzungen.
WH25A 17.241 kbps sendet KVP, RFM69CW
W136 4.800 kbps sendet KVP,RFM69CW init: 869820f 4r
pejonp
mal eine bestimmt einfache Frage: ich hab durch Zufall zwei Sensoren am selben Platz aufgestellt und dabei eine dauerhafte Abweichung von 1,5 Grad festgestellt. Gibt es ein Attribut womit man so eine Standard-Abweichung einstellen kann damit immer der korrekte Wert gezeigt wird?
Hab in der Wiki leider nichts dazu gefunden
Zitat von: commandref zu LaCrossedefine <name> LaCrosse <addr> [corr1...corr2]
addr is a 2 digit hex number to identify the LaCrosse device.
corr1..corr2 are up to 2 numerical correction factors (corr1 for the temperature and corr2 for the humidity), which will be added to the respective value to calibrate the device.
Du kannst also im DEF für
corr1 den Wert 1.5 bzw. -1.5 setzen.
hat geklappt! vielen Dank:-)
Kurze Frage,
kann man mit einem Arduino Nano und einem RFM69W ein Relay bauen?
Mit dem älteren Tranceiver (RFM12b?) klappt das, hab ich schon getestet.
LG
/robin
Hi,
Wer braucht das denn noch?
a) esp und RFM sind überall platzierbar und empfangen alle Protokolle
b) Relays können nur ausgewählte Protokolle relayen
Oder übersehe ich Fakten?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
ist zwar nicht die Antwort auf meine Frage, aber der Kollege hat überall auf seinem Hof lacrosse im Einsatz.
da kommt er mit einem Wlan - Gateway nicht hin.
Zitat von: RaspiLED am 23 Dezember 2017, 12:26:47
Hi,
Wer braucht das denn noch?
a) esp und RFM sind überall platzierbar und empfangen alle Protokolle
b) Relays können nur ausgewählte Protokolle relayen
Oder übersehe ich Fakten?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Guten Abend
ich bekomme keine Verbindung zu meinen beiden Sensoren, TX29DTH-IT + TX35DTH-IT. Sie werden nicht gefunden, auch im log steht nichts (verbose 5).
JeeLink 868MHz für FHEM Mini-USB - PCA301 <<<< das wird der Fehler sein.... PCA301 und nicht LaCrosse :(
list myJeeLink
Internals:
CFGFN
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 34
LaCrossePair 1
NAME myJeeLink
NR 1388
PARTIAL
STATE opened
TYPE JeeLink
initMessages
model [pcaSerial.10.1]
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:
2018-01-04 22:10:18 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 3m 30t v
room 83 Wetter,99 System
set myJeeLink flash LaCrosse
flashing JeeLink myJeeLink
detected Firmware: LaCrosse.hex
hex file: ./FHEM/firmware/JeeLink_LaCrosse.hex
port: /dev/ttyUSB0
log file: ./log/JeeLinkFlash.log
myJeeLink closed
command: avrdude -p atmega328P -c arduino -P /dev/ttyUSB0 -D -U flash:w:./FHEM/firmware/JeeLink_LaCrosse.hex 2>./log/JeeLinkFlash.log
--- AVRDUDE ---------------------------------------------------------------------------------
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x80
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x9e
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x66
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0xe0
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x66
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0xe6
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x98
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x66
avrdude done. Thank you.
--- AVRDUDE ---------------------------------------------------------------------------------
myJeeLink opened
auch
set myJeeLink LaCrossePairForSec 360 ignore_battery
bringt keine Änderung. Hat jemand eine Idee, was ich falsch mache ?
Gruß und einen schönen Abend
Hallo Jörg,
Super Arbeit. Kann ich einen Technloline TX 29 DTH - IT parallel zu dem W137 betreiben? Datenraten sind zumindest gleich und Empfangsfrequenz ebenso. Dann würde ich das gerne mal mit einem Jeelink ausprobieren wollen.
VG
Marcus
Zitat von: Aeroschmelz am 06 Januar 2018, 13:57:35
.. Kann ich einen Technloline TX 29 DTH - IT parallel zu dem W137 betreiben? Datenraten sind zumindest gleich und Empfangsfrequenz ebenso. Dann würde ich das gerne mal mit einem Jeelink ausprobieren wollen.
Hallo Marcus,
die kannst den JeeLink im Togglemodus betreiben (https://wiki.fhem.de/wiki/JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600).
z.B.
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)
Ich kann dir aber nicht sagen ob W137 im Toolemodus gut funktioniert und ob auch die Umschaltung zuverlässig funktioniert, da ja noch eine Frequenzanpassung vorgenommen wird.
Den JeeLink kannst du auch mit zwei RFM69 betreiben (SuperJeeLink). Bitte beachten, für die W137 müssen RFM69 Sensoren genommen werden. Die RFM12 werden nicht unterstüzt. Oder du nutzt eine LaCrossGateway wie auf dem Bild zu sehen (https://forum.fhem.de/index.php/topic,14786.msg708729.html#msg708729) da können 4x RFM69 oder auch CC1101 (CUL oder SignalDuino) usw. (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x) angeschlossen werden.
Jörg
Hi Jörg,
danke, hatte fälschlicherweise auf die Datenrate von dem WH24A geschaut. Das wäre ja auch zu schön gewesen, wenn ich den Jeelink Clone in Rente hätte schicken können ;-) Dann flashe ich mal meinen WeMos mit RFM69HW Funkmodul der aktuell mit ESP Easy läuft.
Viele Grüsse
Marcus
Zitat von: Aeroschmelz am 06 Januar 2018, 15:27:18
hatte fälschlicherweise auf die Datenrate von dem WH24A geschaut. Das wäre ja auch zu schön gewesen, wenn ich den Jeelink Clone in Rente hätte schicken können ;-) Dann flashe ich mal meinen WeMos mit RFM69HW Funkmodul der aktuell mit ESP Easy läuft.
Hi,
ich habe mal eine neue Version für LaCrosseITPlusReader10 angehangen(https://forum.fhem.de/index.php/topic,14786.msg708729.html#msg708729). Wenn du noch eine RFM12 hast könntest du diesen als zweiten RFM anschließen und darüber einen TX29 auslesen. Oder du machst dir einen Timer der alle x sec den LaCrosseITPlusReader10 neu setzt. Wie lange das gutgeht kann ich aber nicht sagen.
W137:
set J1 raw 869820f 4r 0t v
TX29 (TX29DTH-IT 17.241 kbps):
set J1 raw 868300f 0r 0t v
Jörg
Hallo Jörg,
du schreibst man könnte einen RFM12 nehmen für die TX29. Auf der Wiki Seite zum LGW steht, dass der RFM12 nicht mehr unterstützt wird. Ich stehe gerade vor der gleichen Herausforderung wie Marcus und möchte W136 als auch div. TX29 Sensoren erreichen, zum Einsatz kommt ein Jeelink und der LGW. Ich würde gerne den LGW für TX29 und W136 nutzen. Funktioniert der RFM12 doch mit dem LGW aber eben nur für die TX29 oder durch deinem neuen Sketch?
Wäre super wenn Du ein Tipp hast. Worst case bestell ich mir noch einen RFM69.
Danke Sven
Hallo hoods,
Beim lacrossgateway werden die rfm12 nicht mehr unterstützt. Beim jeelink werden die rfm12 noch unterstützt. Ich habe auch noch einen jeelink mit zwei rfm12 im Einsatz. Bei Gelegenheit versuche ich mal eine Anpassung für den jeelink um dort den w137 mit einem rfm12 zu empfangen.
Beim LGW können ja bis zu 5 rfm69 eingesetzt werden. Und die einzelnen Receiver können auf verschieden Sensoren eingestellt werden oder ein Receiver kann zwischen den verschieden baudraten tooglen. Der w137 hat eine andere frequenz und die frequenzumschaltung ist nicht so einfach.
Jörg
Super, vielen Dank für die Info.
Ich stelle allerdings gerade fest, dass ich was überlesen habe. Ich habe den Ersatz All-in-One Sensor für die W266 Wetterstation namens W136 und Marcus nutzt in Kombination mit der Ventus 266 offensichtlich den Aussensensor W137.
Ist evt. das nur ein Schreibfehler? Ich finde in Kombination mit W137 auch keinen Sensor der UV + Blitzerkennung (wie Du weiter oben schreibst) unterstützt ...
Wird in beiden Fällen das geiche Protokoll verwendet?
Gruss Sven
Nachtrag:
Jeelink entsprechend geflasht, initCmds gesetzt und siehe da ich bekomme Daten .... puhhh.
Internals:
CFGFN
DEF W137 196
ID W137_196
IODev myJeeLink
LASTInputDev myJeeLink
MSGCNT 11
NAME Wetterstation_W136
NR 18426
STATE Initialized
TYPE KeyValueProtocol
model W137
myJeeLink_MSGCNT 11
myJeeLink_RAWMSG OK VALUES W137 196 Header=26,Temperature=21.10,Humidity=49,Rain=1.75,WindSpeed=0.00,WindDirection=22.50,WindGust=0.00,UV=0.00,strikesDistance=-1,strikesTotal=0,
myJeeLink_TIME 2018-01-09 21:13:53
READINGS:
2018-01-09 21:13:53 Header 26
2018-01-09 21:13:53 Humidity 49
2018-01-09 21:13:53 Rain 1.75
2018-01-09 21:13:53 Temperature 21.10
2018-01-09 21:13:53 UV 0.00
2018-01-09 21:13:53 WindDirection 22.50
2018-01-09 21:13:53 WindGust 0.00
2018-01-09 21:13:53 WindSpeed 0.00
2018-01-09 21:13:53 strikesDistance -1
2018-01-09 21:13:53 strikesTotal 0
Attributes:
IODev myJeeLink
room Labor
An dieser Stelle übrigens ein RIESEN Lob für die unermüdliche Arbeit!
Gruss Hoods
Zitat von: hoods am 09 Januar 2018, 21:16:41
Nachtrag:
Jeelink entsprechend geflasht, initCmds gesetzt und siehe da ich bekomme Daten .... puhhh.
Hi hoods,
was hast du jetzt im Einsatz ? Einen JeeLink mit eine RFM69 ?
Ich habe gerade gesehen das der Kombisensor der W136 ist und der W137 nur der Regensensor. Da muß ich wohl noch meine Bezeichnung anpassen.
Du kannst ja mal darauf achten ob du UV-Werte empfängst. Bei einigen Sensoren schein dieses ja ein großes Problem zu sein.
Jörg
PS: Ich habe gerade gesehen das es die W137-R für 433MHz gibt. (http://www.nshnordic.com/sites/default/files/products/files/w137r_manual_0.pdf)
Hi Jörg,
ja einen Jeelink mit RFM69.
Bzgl. UV geb ich bescheid sobald der Aussensensor draußen aufgestellt ist.
Gruss hoods
Hallo Jörg,
anbei wie versprochen nochmal Feedback zu den readings.
READINGS:
2018-01-11 19:36:10 Header 26
2018-01-11 19:36:10 Humidity 99
2018-01-11 19:36:10 Rain 0.00
2018-01-11 19:36:10 Temperature 6.00
2018-01-11 19:36:10 UV 0.00
2018-01-11 19:36:10 WindDirection 337.50
2018-01-11 19:36:10 WindGust 1.20
2018-01-11 19:36:10 WindSpeed 0.20
2018-01-11 19:36:10 strikesDistance -1
2018-01-11 19:36:10 strikesTotal 0
UV ist Tag wie Nacht aktuell 0.00. Lt. www.wetterlonline.de sollte der Wert aktuell zwischen 0 - 1 liegen, ok bleibt also ein Sonnentag abzuwarten.
Was Header bedeutet habe ich noch nicht rausfinden können, hast Du einen Tipp?
Humidity ist perm. auf 99, ein LaCrosse Sensor ca. 1m entfernt meldet monentan "T: 6 H: 89". Entweder sind die Meßwerte so ungenau oder die Messwerte des W136 All-in-one Sensors werden noch nicht korrekt verarbeitet.
Wie können wir das weiter eingrenzen?
Danke & Gruss, Sven
Hallo hoods,
da ist der Aufbau des Protokolls:
Header = 0x1A = 26 ist das 2. Byte. Ich habe es einfach übernommen. Ich kann dir jetzt nicht sagen ob es sich bei einem anderen Sensor oder Serie verändert.
UV ist bei mir auch schon seit Tagen 0.
Für meine HP1003 muß ich erst noch eine Auswertung zusammenbauen.
// The following information can be received:
// Humidity, temperature, wind direction, wind average, wind gust, rainfall, UV and lightning.
// That is more than te maximum of 4 values per device for espeasy. The plugins functionality is therefore
// divided per sensorgroup.
// The plugin can (and should) be used more then one time, however only one plugin instance can be
// the main plugin. The plugin function can be selected by a dropdown and only the MAIN plugin has
// the ability to set the sensor address (remote unit ID).
// To find out the current ID of your Ventus remote unit, simply setup a task with instance type "MAIN Temp/Hygro" and observe the LOG.
// Everytime the RFM69 receives a valid packet from a Ventus W266 it shows up in the LOG (approx. every 30 seconds)
// The first number after the "RX:" is the ID of the unit received.
// This ID-number then has to be entered in the "Unit ID" field in the task setup of the "MAIN Temp/Hygro" instance.
// Data is sent to the specified server as soon as it is received.
// RFM69 RX-buffer content:
// ************************
// IDhh 1A tlth ?b tlth wb alahglgh rlrh?? uv ld?? lllhcrc
// 9827 1A B100 00 B100 06 00000000 1E0000 00 3F8A 2A0017
// 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
//
// ID ..... ID of the remote unit. Changes randomly each time the batteries are removed. Is needed to identify "your" unit.
// hh ..... humidity -> Humidity bcd encoded
// tlth ... temperature (low/high byte) > Temperature is stored as a 16bit integer holding the temperature in degree celcius*10
// b ...... battery low > This uint8 is 00 when battery is ok, 01 when battery is low
// wb ..... bearing (cw 0-15) > The wind bearing in 16 clockwise steps (0 = north, 4 = east, 8 = south and C = west)
// alah ... wind average (low/high byte) > A uint16 holding the wind avarage in m/s
// glgh ... wind gust (low/high byte) > A uint16 holding the wind gust in m/s
// rlrh ... rainfall (low/high byte) > Accumulated rainfall in 1/4mm
// uv ..... uv-index > The UV value * 10
// ld ..... lightningstorm-distance (3F max) > The distance to the stormfront in km
// lllh ... strike count (low/high byte) > A uint16 holding the accumulated number of detected lightning strikes
// crc .... CRC checksum > Poly 0x31, init 0xff, revin&revout, xorout 0x00. Like Maxim 1-wire but with a 0xff init value
// If you got any questions, send me an email to: huawatuam@gmail.com
Jörg
Hallo Jörg,
ich habe nun wie geplant einen zweiten RFM69CW am ESP angeschlossen. Leider bekomme ich es einfach nicht hin, dass der LGW mit deiner Firmware LaCrosseITPlusReader.Gateway.1.30w137 die Daten der Wetterstation W137 (aka W136) empfängt.
Wenn ich wieder umstelle auf den Jeelink USB Stick werden die Readings wieder aktualisiert. Um den Fehler einzugrenzen habe ich den zweiten RFM vom LGW abgezogen und den ersten RFM, der bisher die TX29 empfangen hat umkonfiguriert.
Verwendete Konfig:
W137:
set LGW/Jeelink raw 869820f 4r 0t v
TX29 (TX29DTH-IT 17.241 kbps):
set LGW/Jeelink raw 868300f 0r 0t v
Frage zur Konfig, muss es nicht "4800r 0t 869820f v" heisen wenn ich W137 empfangen möchte oder ist "4r" einfach die Kurzform der Datenrate 4800?
Konfig des Jeelinks die funktioniert:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL014L1V-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL014L1V-if00-port0@57600
FD 9
NAME myJeeLink
NR 48
PARTIAL
RAWMSG OK VALUES W137 232 Header=26,Temperature=2.20,Humidity=83,Rain=0.00,WindSpeed=0.60,WindDirection=0.00,WindGust=1.20,UV=0.00,strikesDistance=-1,strikesTotal=0,
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1w137
myJeeLink_MSGCNT 4
myJeeLink_TIME 2018-01-14 21:53:57
settings (RFM69CW f:869820 r:4800)
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:
2018-01-14 21:53:57 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
group LaCrosse
icon cul_868
room Gateways
verbose 0
Konfig des LGW das Probleme bereitet beim Empfang von W137/W136:
Internals:
Alive 2018-01-14 22:03:39
Clients LaCrosse
DEF 192.168.178.38:81
DeviceName 192.168.178.38:81
FD 18
NAME myLaCrosseGateway
NR 284
NTFY_ORDER 50-myLaCrosseGateway
PARTIAL
RAWMSG OK VALUES LGW 14559234 UpTimeSeconds=1030,UpTimeText=0Tg. 0Std. 17Min. 10Sek. ,WIFI=chocomel,ReceivedFrames=200,FramesPerMinute=0,RSSI=-62,FreeHeap=17144,LD.Min=0.17,LD.Avg=0.17,LD.Max=0.60,OLED=none
STATE initialized
TIMEOUT 0.5
TYPE LaCrosseGateway
model LaCrosseITPlusReader.Gateway.1.30w137
myLaCrosseGateway_MSGCNT 47
myLaCrosseGateway_TIME 2018-01-14 22:03:57
nextOpenDelay 2
settings (1=RFM69 f:869820 r:4800) {IP=192.168.178.38}]
MatchList:
1:PCA301 ^\S+\s+24
2:EC3000 ^\S+\s+22
3:LaCrosse ^(\S+\s+9 |OK\sWS\s)
4:EMT7110 ^OK\sEMT7110\s
5:Level ^OK\sLS\s
6:KeyValueProtocol ^OK\sVALUES\s
READINGS:
2018-01-14 20:08:49 FreeHeap 17328
2018-01-14 20:08:49 OLED none
2018-01-14 20:08:49 ReceivedFrames 32
2018-01-14 20:08:49 UpTimeSeconds 300
2018-01-14 22:03:57 state initialized
helper:
Attributes:
Clients LaCrosse
group myLaCrosseGateway
icon cul_wlan
mode WiFi
room Gateways
timeout 60
usbFlashCommand ./FHEM/firmware/esptool.py -b 921600 -p [PORT] write_flash -ff 80m -fm dio -fs 4MB-c1 0x00000 [BINFILE] > [LOGFILE]
watchdog 300
Fhem Log zeigt keine Fehlermeldungen und das einzige was mir aufgefallen ist, der LGW nutzt angeblich einen "RFM69" ohne das "CW". Obwohl ich explizit RFM69CW gekauft hatte.
Bin gerade mit meinem Latein am Ende und wäre dankbar für einen Schubser.
Gruss Sven
Hi hoods,
Ich schau es mir heute Abend mal an. Du kannst ja mal im Gateway Konsole: 1d v
Eingeben. Damit schaltest du den debugmodus an. Schau mal ob hex daten ankommen, die an der 3. stelle ein 1A haben.
Jörg
Hallo Jörg,
der Jeelink zeigt den entsprechenden Output sobald der debug Modus aktiviert ist. Der LGW zeigt leider nichts mit 1A.
Output des LGW:
2018.01.15 20:48:57 4: set myLaCrosseGateway raw 4800r 0t 869820f 1d v
2018.01.15 20:48:57 5: SW: 4800r 0t 869820f 1d v
2018.01.15 20:49:04 5: myLaCrosseGateway: dispatch OK VALUES LGW 14559234 UpTimeSeconds=90,UpTimeText=0Tg. 0Std. 1Min. 30Sek. ,WIFI=chocomel,MacAddress=18:FE:34:DE:28:02,ReceivedFrames=0,FramesPerMinute=0,RSSI=-54,FreeHeap=17456,Version=1.30w137,LD.Min=0.17,LD.Avg=0.17,LD.Max=17.05,OLED=none
...
2018.01.15 20:53:44 4: set myLaCrosseGateway raw 868300f 0r 0t v
2018.01.15 20:53:44 5: SW: 868300f 0r 0t v
2018.01.15 20:53:44 5: myLaCrosseGateway: dispatch OK VALUES LGW 14559234 UpTimeSeconds=370,UpTimeText=0Tg. 0Std. 6Min. 10Sek. ,WIFI=chocomel,MacAddress=18:FE:34:DE:28:02,ReceivedFrames=0,FramesPerMinute=0,RSSI=-60,FreeHeap=17288,Version=1.30w137,LD.Min=0.17,LD.Avg=0.17,LD.Max=7.82,OLED=none
2018.01.15 20:53:46 5: myLaCrosseGateway: dispatch OK 9 13 130 3 24 125
2018.01.15 20:53:47 5: myLaCrosseGateway: dispatch OK 9 16 1 4 46 106
2018.01.15 20:53:48 5: myLaCrosseGateway: dispatch OK 9 10 1 4 109 106
2018.01.15 20:53:48 5: myLaCrosseGateway: dispatch OK 9 8 1 4 35 106
2018.01.15 20:53:49 5: myLaCrosseGateway: dispatch OK 9 42 1 4 32 86
2018.01.15 20:53:52 5: myLaCrosseGateway: dispatch OK 9 39 130 2 183 125
2018.01.15 20:53:52 5: myLaCrosseGateway: dispatch OK 9 10 130 2 178 125
2018.01.15 20:53:52 5: myLaCrosseGateway: dispatch OK 9 8 1 4 35 106
2018.01.15 20:53:52 5: myLaCrosseGateway: dispatch OK 9 36 130 2 177 125
2018.01.15 20:53:53 5: myLaCrosseGateway: dispatch OK 9 42 1 4 31 86
2018.01.15 20:53:53 5: SW: "WATCHDOG Ping=300"
Anbei der Output des Jeelink USB Sticks:
2018.01.15 20:56:29 5: myJeeLink: dispatch End receiving, HEX raw data: 9E 99 1A 39 0 0 39 0 0 A 0 1E 0 19 0 0
2018.01.15 20:56:30 3: myJeeLink: Unknown code End receiving, HEX raw data: 9E 99 1A 39 0 0 39 0 0 A 0 1E 0 19 0 0 , help me!
2018.01.15 20:56:30 5: myJeeLink: dispatch OK VALUES W137 233 Header=26,Temperature=5.70,Humidity=99,Rain=6.25,WindSpeed=1.00,WindDirection=0.00,WindGust=3.00,UV=0.00,strikesDistance=-1,strikesTotal=0,
2018.01.15 20:56:33 5: JeeLink/RAW: /
End receiving, HEX raw data: 6F 29 14 AA 86 BB F1 CC 29 D0 E9 F6 A4 ED 91 C2
Gruss Sven
Hallo hoods,
ich habe hier eine neue Datei "LaCrosseGateway_WH25+W137.rar" angehangen (https://forum.fhem.de/index.php/topic,14786.msg708729.html#msg708729).
Es waren noch Fehler drin, die ich in der alten Version nicht behoben hatte.
pejonp
Hallo pejonp,
kurzer Update. Mit der neuen Firmware empfängt das LGW auch Daten des W137/W136 Sensors.
Kleine Anmerkung:
Wenn für den LGW Debug aktiviert ist und verbose 5 gesetzt wurde, tauchen der Debug Output / die Zeilen mit A1 nicht im Fhem Log auf sondern sind nur auf der Weboberfläche des ESP zu sehen. Vielleicht hift's anderen nicht-Experten wie mir bei der Problemanalyse ...
Log Infos vom LGW Web Interface:
19:59:29: DataPort: #81 received '"WATCHDOG Ping=300" '
19:59:32: RFM69: 9E 99 1A 0F 00
20:00:03: RFM69: 9E 99 1A 0F 00
Nun habe ich noch ein Phänomen, dass das W136 Device mit der Zeit mehrfach angelegt wird. D.h. ich erstelle es über autocreate / LaCrossePairForSec und es wird ein Device erzeugt. 24h später habe ich manchmal 3-4 Devices zusätzlich die die gleiche Konfig haben. Aktualisiert wird mal das erste Device manchmal aber auch eines der neuen Devices allerdings immer nur eins.
Hast Du hierzu noch ne Idee oder einen Tipp?
Gruss hoods
Hallo hoods,
sind in deiner Gegend noch mehrer Wetterstationen installiert (dichte Bebauung oder eher ländlich) ?
Sind noch andere Sensoren im Einsatz ? Regen, nur Wind, nur Temp/Hum... ? Diese gibt es ja auch von Ventus.
pejonp
Hallo pejonp,
ist eher ländlich und in den Gärten habe ich bisher keine Wetterstation entdecken können. Allerdings meldet mir mein signalduino (433Mhz) schon ne Reihe Sensoren in der Nachbarschaft. Also kurzum, ganz ausschliessen dass noch jemand eine Ventus in der Nachbarschaft hat kann ich nicht.
Interessanterweise wurde seit gestern Abend kein neues Device angelegt, seit dem der LGW die Arbeit übernommen hat. Unterschied: Der Jeelink hängt im Dachgeschoss, Luftlinie ca. 20m zum Sensor durch Stahlbeton und der LGW steht aktuell im Wohnzimmer. Luftlinie LGW - Sensor, vielleicht 8m und nur ne Glassscheibe dazwischen.
Sehr komisch ... ich beobachte weiter.
Gruss hoods
Hallo!
Ich habe mir letzte Woche einen Orginal Jee-Link besorgt und in Fhem eingebunden.
Alles soweit ok, jedoch zeigten die rain Werte völlig andere Daten als es der Wirklichkeit entspricht. Am Display der Orginal WS1600 wird 74.0 mm Regenmenge angezeigt. Das LaCrosse Modul in Fhem zeigt zur gleichen Zeit 692 an.
Zuerst dachte ich, das ist der Orginalwert mal Faktor 10. Bei Aktivierung des LaCrosse Moduls vor einer Woche zeigte die WS1600 Station 69.5 mm und das Modul 695, aber das Modul zählt bei Regen in Kommaschritten hoch (z. B. 693,4 -> 693,8 usw., während die gefallene Regenmenge in der WS1600 Station korrekt angezeigt wird.
So sieht das list des Jee-Link aus:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 35
NAME myJeeLink
NR 1018
PARTIAL
RAWMSG OK WS 48 1 4 7 255 5 104 255 255 255 255 255 255 0
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 25604
myJeeLink_TIME 2018-02-01 10:18:15
settings (RFM69CW f:868300 r:8842)
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:
2018-02-01 10:18:15 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 2r 0a v
room System
Bild der Werte des LaCrosse Moduls im Anhang.
Vielleicht hat jemand eine Idee woran es liegen könnte.
Danke erstmal
VG
Alex
Zitat von: Homalix99 am 01 Februar 2018, 10:36:47
Vielleicht hat jemand eine Idee woran es liegen könnte.
Eigentlich habe ich aktuell keine Idee.
OK WS 48 1 4 7 255
5 104 255 255 255 255 255 255 0
ergibt 692mm, bedeutet, die 692 kommen so schon vom Jeelink.
Du könntest eins machen: den JeeLink an einen Rechner mit Terminalprogramm stecken (57600 baud) und
2r
1p
schicken, dass die Empfangenen Rohdaten ausgegeben werden.
Wir müssten mal sehen, was da auf der HF-Seite reinkommt.
ok, werde ich morgen machen, hab den Lapi heut schon weggeräumt. Kann es vielleicht auch daran liegen, dass ich eine Wetterstation von Conrad habe?
Eigentlich sollte die ja identisch zu einer Technotrend IT sein, oder?
VG
Alex
Zitat von: Homalix99 am 04 Februar 2018, 20:10:49
Kann es vielleicht auch daran liegen, dass ich eine Wetterstation von Conrad habe?
Eigentlich sollte die ja identisch zu einer Technotrend IT sein, oder?
Genau das will ich mal an den Rohdaten versuchen nachzuvollziehen.
Hallo!
mea culpa!
Die Daten kamen schon korrekt. Ich dachte ich hätte bei Inbetriebnahme des Jeelink auch gleich die Batterien im TX22 und der Wetterstattion gewechselt. Naja rausgelegt hatte ich sie schon, aber nicht gewechselt. Hab dann den Jeelink mit "ignore battery" in Betrieb genommen und, was mich so verwirrte, war, dass die Regenmenge an der WS1600, welche ich am 1.1.18 resetet hatte (aber eben nur in der Station) bei Inbetriebnahme des LaCrosse Moduls genau 68 mm zeigte und die im TX22 den Wert seit letztem Jahr zufällig das 10 fache davon, nähmlich 680 mm war. Beim Vergleich der Werten in Fhem mit deren in der Station habe ich dann gedacht: "Komisch, naja dann teile ich den Wert einfach durch 10".
Nee, alles gut
Nochmal vielen Dank!
PS: Jetzt fehlt mir nur noch der Luftdruck in Fhem, da dieser ja in der WS1600 direkt gemessen wird. Welchen möglichst preiswerten Sensor kann man da über Jeelink mit einbinden?
VG
Alex
Zitat von: Homalix99 am 05 Februar 2018, 17:50:08
Nee, alles gut
Besser als wenn ich Bugs beheben müsste ... :)
Zitat von: Homalix99 am 05 Februar 2018, 17:50:08
PS: Jetzt fehlt mir nur noch der Luftdruck in Fhem, da dieser ja in der WS1600 direkt gemessen wird. Welchen möglichst preiswerten Sensor kann man da über Jeelink mit einbinden?
Mir ist keiner bekannt, der den Luftdruck in einem Format senden würde, das der JeeLink-Sketch versteht.
Aber schau mal nach I2C und BME180/BME280.
Ich glaube, da gibt es Anbindungen per I2C direkt an die GPIOs vom Raspi.
Und was ist dem TX29 von Technoline?
Zitat von: Homalix99 am 05 Februar 2018, 19:08:25
Und was ist dem TX29 von Technoline?
Der sendet doch keinen Luftdruck?
Die Jeelink-Erweiterung zum "SupperJee" kann auch Luftdruck per BME .
Hallo,
Der WH25A kann temp, human und press Eintrag #2158 (ist der Innensenators der HP1003/WH2621). Ich weiß jetzt aber nicht ob es diesen auch einzeln oder als Ersatzteil gibt. Oder du bindest dieser über hp1000 Modul an. Manchmal gibt es eBay defekte Stationen da ist dann im allgemeinen so ein Sensor dabei.
Pejonp
Oder: https://fhem.de/commandref.html#I2C_BMP180
Oder: https://fhem.de/commandref.html#I2C_BME280
Hi,
ich bin gerade begeistert von ESP8266 (z.B. NodeMCU V2) mit EasyESP Firmware und an I2C Pins die BME280.
In FHEM dann einmal ESPBridge Modul und das ESPDevice per Autocreate ;-) mit Temp und Luftdruck.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Danke erstmal für die vielen Hinweise zum Betrieb von Luftdrucksensoren.
Am elegantersten wäre, einen BMP180 direkt mit einem Jeelink clone zu verbinden. Ich habe meinen Clone rausgeworfen, weil er trotz Antennenoptimierung die Messwerte vom TX22 nicht sauber empangen hat. Mit dem Orginal Jeelink funktioniert es super, aber den möchte ich ungern öffnen und was dranbasteln.
Die 2. Variante mit i2C klingt gut, aber ich habe die I2C Pins leider nicht abgreifbar an meiner Anschlu0platine gemacht (Die RPI ist verbaut und mit 2x40 pol Flachbandkabel mit der A.-Platine verbunden). Die möchte ich ungern wieder zerlegen. Auch auf dem Arduino Uno sind alle Pins schon belegt (digitale sowie analoge) so dass der Vorschlag:
https://draeger-it.blog/sainsmart-lektion-10-bmp180/
unter Verwendung von A4 und A5 auch nicht fkt. Ich hätte aber Zugriff auf die SDA und SLC des Arduino. Das wird aber wohl nicht nützen, oder?
VG
Alex
Hey Leute,
hab heute mal meinen Jeelink Clone geflasht, jedoch finde ich keine Anleitung wie man die .hex auf 433 Mhz umschreibt. Ich flashe mit Arduino Builder. Kann mir das vielleicht jemand erklären wie das geht?
Zitat von: Quick am 08 Februar 2018, 22:25:46
jedoch finde ich keine Anleitung wie man die .hex auf 433 Mhz umschreibt. Ich flashe mit Arduino Builder. Kann mir das vielleicht jemand erklären wie das geht?
Was willst Du denn auf 433 MHz empfangen?
Guten Abend zusammen,
ich verwende eine WS1600. Soweit alles problemlos.
Nun musste ich heute das erste mal die Batterie wechseln. Lief mit "replaceBatteryForSec" ohne Probleme.
Meine Frage bezieht sich nun aber auf das Reading "rain".
Nach dem Batteriewechsel wird das ja wieder zu "0" gesetzt. Ich verwende das statistics-Modul und logischerweise bringt dieser nun vorhandene Offset die statistics-Werte durcheinander. Im Device selbst kann man ja leider kein Offset eintragen bzw. bei einem Batteriewechsel merkt sich Fhem den alten Wert leider nicht.
Nun konkret gefragt, wäre das eine denkbare Verbesserung einen Offset-Wert (als Attribut o.ä.) für das rain-Reading hinterlegen zu können (manuell oder automatisch), um nach einem Batteriewechsel den rain-Wert wieder auf den alten Stand "anzuheben"?
Bei meiner Suche habe ich solch eine Fragestellung/Lösung noch nicht gefunden.
Danke schonmal und VG...
schau dir mal userReadings monotonic an.
damit kannst du z.b. ein rainTotal reading erzeugen und dieses dann mit statistics weiter verarbeiten.
Zitat von: justme1968 am 14 Februar 2018, 11:44:36
schau dir mal userReadings monotonic an.
damit kannst du z.b. ein rainTotal reading erzeugen und dieses dann mit statistics weiter verarbeiten.
hi und danke für den Tip. Ist ja eigentlich der gleiche Ansatz wie bei der PCA301, hätte ich auch drauf kommen können - sorry ::)
Kannst Du sagen, ob das statistics-Modul auch über alle Werte zurückrechnen kann? Also, wenn ich die bisher erfassten "rain"-Werte in "rainTotal"-Werte überführe (also DBLog-werte kopiere)?
rückwirkend nicht.
Orginal JeeLink geht sporadisch (alle 2-3 Tage) in den Status Disconnected
Hier hilft nur noch ein Ziehen und Stecken des Sticks vor Ort, oder?
Meine Definition ist wie folgt:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 35
NAME myJeeLink
NR 1021
PARTIAL
RAWMSG OK WS 46 1 255 255 75 0 13 255 255 255 255 255 255 0
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 72594
myJeeLink_TIME 2018-02-20 14:29:41
settings (RFM69CW f:868300 r:8842)
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:
2018-02-20 14:29:41 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 2r 0a v
room System
timeout 120,30
verbose 5
Was mir auffällt, dass der JeeLink nach restet nur ein paar Sekunden im Zustand "opened" bleibt und dann sofort nach "initialized" fällt. Es kommen aber Daten. Dann kann es nach wenigen Std. vorkommen, dass die Daten ausbleiben. Da habe ich mir mit dem Attr. " timeout 120,30" beholfen, jedoch kann ich damit nur 2-3 Tage überbrücken, bis er seinen Dienst einstellt.
Im Log stell sich ein zwischenzeitlicher Reset des JeeLink folgendermaßen dar:
2018.02.20 12:43:20.042 5: myJeeLink: dispatch OK WS 46 1 3 243 255 0 13 255 255 255 255 255 255 0
2018.02.20 12:43:24.527 5: JeeLink/RAW: /OK
2018.02.20 12:43:24.531 5: JeeLink/RAW: OK /WS 46 1 3 244 255 0 13 25
2018.02.20 12:43:24.534 5: JeeLink/RAW: OK WS 46 1 3 244 255 0 13 25/5 255 255 255 255
2018.02.20 12:43:24.538 5: JeeLink/RAW: OK WS 46 1 3 244 255 0 13 255 255 255 255 255/ 255 0
2018.02.20 12:43:24.541 5: myJeeLink: dispatch OK WS 46 1 3 244 255 0 13 255 255 255 255 255 255 0
2018.02.20 12:43:29.030 5: JeeLink/RAW: /OK WS
2018.02.20 12:43:29.033 5: JeeLink/RAW: OK WS /46 1 3 243 255 0
2018.02.20 12:43:29.037 5: JeeLink/RAW: OK WS 46 1 3 243 255 0 /13 255 255 255 255 255 25
2018.02.20 12:43:29.040 5: JeeLink/RAW: OK WS 46 1 3 243 255 0 13 255 255 255 255 255 25/5 0
2018.02.20 12:43:29.043 5: myJeeLink: dispatch OK WS 46 1 3 243 255 0 13 255 255 255 255 255 255 0
Nach Reset des JeeLink:
2018.02.20 12:43:29.422 3: Opening myJeeLink device /dev/ttyUSB0
2018.02.20 12:43:29.428 3: Setting myJeeLink serial parameters to 57600,8,N,1
2018.02.20 12:43:30.457 3: myJeeLink device opened
2018.02.20 12:43:32.165 5: JeeLink/RAW: /
[L
2018.02.20 12:43:32.168 5: JeeLink/RAW: [L/aCrosseITPlusRead
2018.02.20 12:43:32.170 5: JeeLink/RAW: [LaCrosseITPlusRead/er.10.1s
2018.02.20 12:43:32.173 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1s/ (RFM69CW f:86830
2018.02.20 12:43:32.175 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1s (RFM69CW f:86830/0 r:17241)]
2018.02.20 12:43:32.177 5: SW: 2r
2018.02.20 12:43:32.187 5: SW: 0a
2018.02.20 12:43:32.198 5: SW: v
2018.02.20 12:43:32.341 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1s (RFM69CW f:868300 r:8842)]
2018.02.20 12:43:33.531 5: JeeLink/RAW: /OK WS 46
2018.02.20 12:43:33.534 5: JeeLink/RAW: OK WS 46/ 1 3 244 255 0 13 255 255
2018.02.20 12:43:33.538 5: JeeLink/RAW: OK WS 46 1 3 244 255 0 13 255 255/ 255 255 255 255
2018.02.20 12:43:33.542 5: JeeLink/RAW: OK WS 46 1 3 244 255 0 13 255 255 255 255 255 255 /0
2018.02.20 12:43:33.545 5: myJeeLink: dispatch OK WS 46 1 3 244 255 0 13 255 255 255 255 255 255 0
2018.02.20 12:43:38.398 5: JeeLink/RAW: /OK WS 46 1 3 243 78 0 13 255 255 255 255 255 255 0
2018.02.20 12:43:38.402 5: myJeeLink: dispatch OK WS 46 1 3 243 78 0 13 255 255 255 255 255 255 0
2018.02.20 12:43:42.836 5: JeeLink/RAW: /OK WS 46 1 255 255 255 0 13 0 225 0 0 255 255 0
2018.02.20 12:43:42.838 5: myJeeLink: dispatch OK WS 46 1 255 255 255 0 13 0 225 0 0 255 255 0
c2018.02.20 12:43:47.171 5: JeeLink/RAW: /OK WS 46 1 3 244 255 0 13 255 255 255 255 255 255 0
2018.02.20 12:43:47.173 5: myJeeLink: dispatch OK WS 46 1 3 244 255 0 13 255 255 255 255 255 255 0
Hat jemand eine Idee, woran es liegen könnte?
Die Spannungsversorgung scheint stabil zu sein. Ich betreibe den RPI an einem 2,5 A Netzteil, welches an einer USV hängt.
Der JeeLink Stick ist aber in unmittelbarer Nachbarschaft zu einem HomeMatic LAN Gateway und über eine USB-Verlängerung (5 Meter) an den PI angeschlossen.
VG
Alex
Hi,
Unter Linux könntest Du remote den USB Port resetten: https://www.computerhilfen.de/info/usb-reset-am-raspberry-pi-usb-ports-zuruecksetzen.html
Eine 5m USB Verlängerung ist keine gute Idee, da diese ohne Spannungsversorgung außerhalb der Spec ist. Probiere erstmal ein normales Kabel und schaue ob es da auch Abbrüche gibt ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: Homalix99 am 20 Februar 2018, 14:41:29
Was mir auffällt, dass der JeeLink nach restet nur ein paar Sekunden im Zustand "opened" bleibt und dann sofort nach "initialized" fällt. Es kommen aber Daten.
Das ist OK. Erst opened, wenn die Schnittstelle auf geht, wenn sich der Sketch auf dem JeeLink gemeldet hat wird es initialized worauf hin das JeeLink-Modul die initCommans schickt. Das ist OK so, kann man auch im angehängten Log so mitverfolgen.
Zitat von: Homalix99 am 20 Februar 2018, 14:41:29
Es kommen aber Daten. Dann kann es nach wenigen Std. vorkommen, dass die Daten ausbleiben.
Das ist nicht OK.
Zitat von: Homalix99 am 20 Februar 2018, 14:41:29
und über eine USB-Verlängerung (5 Meter) an den PI angeschlossen.
Das würde ich zum Testen mal ändern, also den JeeLink direkt an den Pi anschließen und schauen, ob es dann nicht mehr auftritt.
Zitat von: pejonp am 02 November 2017, 20:22:57
Hallo,
ich habe LaCrosseITPlusReader10 und LaCrossGateway um die Sensoren WH25A (Innensensor HP1003) und W137 Ausseneinheit (Ventus W266 Wetterstation)
(https://github.com/letscontrolit/ESPEasyPluginPlayground/blob/master/_P124_Ventus_W266_RFM69.ino) erweitert.
W137:
Beim W137 muß die Empfangsfrequenz auf 869.820 MHz eingestellt sein und die Datenrate auf 4800. Die Daten werden im KeyValueProtokoll gesendet, da die normalen Daten der Wetterstation nicht gepasst haben (UV + Blitzerkennung).
Getest habe ich nur mit dem RFM69 Transceiver. Auf dem LaCrossGateway habe ich 2x RFM69 (1. und 4.)
Die Init-Einstellung ist: 3#4r 868300#4f 33#4t 4800r 0t 869820f v
Währe schön wenn es noch jemande gebrauchen könnte und dann auch noch mittestet.
Als Anlage die gepackten Sourcen und ein Bild vom Aufbau des LaCrossGateways.
pejonp
Hallo Pejonp,
Habe den Sketch auf einem Jeelink installiert. Es funktioniert soweit alles auf den ersten Blick. Zwei Dinge sind mir aufgefallen:
1. Taupunkt wird mit dem Dewpoint Modul oder mit attr dodewpoint 1 nicht berechnet
2. wird das Reading Rain_lasthour vom Sensor gesendet oder intern berechnet? Bei EspEasy auf einem ESP gab es das jedenfalls.
Als weitere Frage: die Windgeschwindigkeit wird in m/s ausgegeben?
Herzlichen Dank für deine Umsetzung. Ich teste weiter....
@Aeroschmelz
1. Taupunkt/Dewpoint ist ein extra Modul. Bitte da nachsehen.
2. Rain_lasthour wurde intern im ESPeasy berechnet. Wer es benötigt kann es über FHEM Funktionen/Module nachbilden.
3. Windgeschwindigkeit wird in m/s angegeben. Wer es anders benötigt kann es sich ja berechnen. Ich habe dieses im Modul 14_SD_WS09.pm eingebaut. Wenn andere Werte im Module benötigt werden. bitte an den Modulentwickler wenden.
14_SD_WS09.pm
...
# "Unit_of_Wind:m/s,km/h,ft/s,bft,knot "
# my %uowind_unit= ("m/s",'1',"km/h",'3.6',"ft/s",'3.28',"bft",'-1',"mph",'2.24',"knot",'1.94');
# B = Wurzel aus ( 9 + 6 * V ) - 3
# V = 17 Meter pro Sekunde ergibt: B = Wurzel aus( 9 + 6 * 17 ) - 3
# Das ergibt : 7,53 Beaufort
$windstat[0]= " Ws:$windSpeed Wg:$windguest m/s";
Log3 $hash, 4, "SD_WS09_Wind $windstat[0] : Faktor:$wfaktor" ;
$wfaktor = $uowind_unit{"km/h"};
$windguest_kmh = round ($windguest * $wfaktor,01);
$windSpeed_kmh = round ($windSpeed * $wfaktor,01);
$windstat[1]= " Ws:$windSpeed_kmh Wg:$windguest_kmh km/h";
Log3 $hash, 4, "SD_WS09_Wind $windstat[1] : Faktor:$wfaktor" ;
....
pejonp
Hi
1.) Taupunkt:
Hat wohl etwas länger gedauert, jetzt erscheint das Reading
2.) Rain_Lasthour
kein Problem, mache ich dann mit dem Statistik Modul. Gut war, dass das rain_lasthour Reading direkt innerhalb der Periode kontinuierlich aktualisiert wurde, während das Statistik Modul das erst dann macht, wenn die Stund rum ist.
3.) Windgeschwindigkeit
kein Problem, bin mir nicht mehr ganz sicher, warum ich das in der Firmware umgerechnet habe
4.) Plotten von Graphen
Zusätzlich scheint er aber das event-min-interval und das event-change-reading zu ignorieren und plottet wild die Temperaturen. Ich verwende dblog. Übersehe ich da etwas? Grundsätzlich scheint FHEM auch Unterschiede bei Readings mit "temperature" oder "Temperature" zu machen. Es wäre daher gut, wenn man sich an die Konventionen der Kleinschreibung wie bei anderen Devices halten würde.
# Kombi-Sensor Ventus W266 auf dem Balkon Richtung Süden
define Balkon KeyValueProtocol W137 191
attr Balkon DbLogExclude WindSpeed,WindDirection
attr Balkon IODev JeeLinkWeather
attr Balkon event-min-interval Temperature:1200,Humidity:1200,windDirAverage:1200,WindGust:1200,windVelAverage:1200,statTotal_rainHour:1200,statTotal_rainDay:3600,statTotal_rainYear:3600,UV:3600,strikesTotal:3600,strikesDistance:3600
attr Balkon event-on-change-reading Temperature:0.5,Humidity:4,windDirAverage:22.5,WindGust:1,windVelAverage:0.5,statTotal_rainHour:0.1,statTotal_rainDay:0.1,statTotal_rainYear:0.1,UV:0.2,strikesTotal:1,strikesDistance:1
attr Balkon group Wetterinfo
attr Balkon room Umwelt
attr Balkon sortby 1
attr Balkon stateFormat H: Humidity %, T: Temperature C, D: dewpoint C, WD: windDirAverage °, WV: windVelAverage mps, WG: WindGust mps, R: Rain mm
attr Balkon userReadings windVelAverage {movingAverage("Balkon","WindSpeed",300);; }, windDirAverage {myWindDirAverage('Balkon','WindSpeed','WindDirection',1200,0.8,0);; }
5.) Blitze: Die Blitze der letzten 5 Minuten sind vermutlich auch berechnet und kommen nicht vom Protokoll oder? Kann man die Blitzentfernung von -1 auf 0 setzen, wenn es nicht gewittert.
6.) Auslesegeschwindigkeit: Wie häufig werden denn die Werte vom Sensor ausgelesen? Gibt es da Unterschiede zwischen ESPEasy und Jeelink Sketch? Zu ähnlichen Zeitpunkten unterscheiden sich die abgelesenen Werte. Nach Aussage des Displays liegt der EspEasy näher dran.
Grüsse
Marcus
Hallo,
ich betreibe einen JeeLink an USB (Raspberry) mit TX29xx und TX35xx Sensoren.
Das funktioniert mit aktiviertem Toggle Mode seit 2 Jahren problemlos.
Ein neuer Sensor im Keller ist jetzt aber zu weit vom Raspi entfernt, weshalb ich einen 2. JeeLink mit Relay=1 in Betrieb genommen habe.
Da ich auch nach intensiver Suche keine Antworten zu 3 Fragen gefunden habe, erlaube ich mir diese hier im Forum zu stellen.
Frage1: Muss ich beim Relay JeeLink auch den Toggle Mode aktivieren, damit sowohl TX29 und TX35 Sensoren verstärkt werden?
Oder funktioniert Relay immer nur auf einer Frequenz?
Frage2: Wie kann ich überprüfen ob und was der Relay JeeLink überträgt?
Frage3: Lt. Doku filtert FHEM doppelt empfangene Signale vom JeeLink aus. Muss das aktiviert werden oder wie funktioniert das?
Vielen Dank für eure Erläuterungen
Gruß
Robert
Hallo,
ich bin schon eine Weile im Forum angemeldet und habe bislang meine Problemchen immer über die Suchfunktion lösen können. Nun habe ich aber ein Problem mit meinem Jeelinkclone (Arduino Nano mit RFM69HCW von Pollin). Der State in FHEM wird mit "initizialized" angezeigt, allerdings sehe ich meine TX29DTH-Sensoren nicht und kann daher auch kein Pairing durchführen.
Mir fiel auf, dass der Funkchip wohl nicht korrekt erkannt wird.
model LaCrosseITPlusReader.10.1s
settings RFM12B f:868300 t:30~7)
Ich bin mir ganz sicher, nicht nur einen RFM69HCW bestellt, sondern von Pollin auch erhalten zu haben. Ich gehe daher davon aus, dass das Problem irgendwie in der Firmware steckt?!
Hat jemand einen Rat, wie ich meinen Jeelinkclone zur Arbeit bewegen kann?
Viele Grüße
emiglio
Könnt Ihr uns den Gefallen tuen und für neue Probleme ein neuen Thread aufmachen? Ein Thread mit 147 Seiten ist doch etwas .... lang ...
Zitat von: treborst am 25 Februar 2018, 16:07:32
Frage1: Muss ich beim Relay JeeLink auch den Toggle Mode aktivieren, damit sowohl TX29 und TX35 Sensoren verstärkt werden?
Oder funktioniert Relay immer nur auf einer Frequenz?
Das Relay schickt alle korrekt erkannten Pakete, also solche, die es auch an FHEM zustellen würden, weiter.
Bei mehreren DataRates wird es genau so konfiguriert, wie wenn es an FHEM dran wäre.
Zitat von: treborst am 25 Februar 2018, 16:07:32
Frage2: Wie kann ich überprüfen ob und was der Relay JeeLink überträgt?
Mit einem Terminalprogramm schauen, was es au der Schnittstelle ausgibt. Genau das wird auch weitergeschckt, sofern es als Relay konfiguriert ist.
Zitat von: treborst am 25 Februar 2018, 16:07:32
Frage3: Lt. Doku filtert FHEM doppelt empfangene Signale vom JeeLink aus. Muss das aktiviert werden oder wie funktioniert das?
Das macht FHEM per dafault immer.
Siehe auch hier: http://forum.fhem.de/index.php/topic,14786.msg165153.html#msg165153
Zitat von: Wernieman am 26 Februar 2018, 08:10:04
Könnt Ihr uns den Gefallen tuen und für neue Probleme ein neuen Thread aufmachen? Ein Thread mit 147 Seiten ist doch etwas .... lang ...
Da stimme ich zu. Noch hat es die "pejonp-spezial-Version" nicht in die offizielle Schiene geschafft. Ein eigener Thread wäre da wirklich sinnvoll.
Zitat von: emiglio am 25 Februar 2018, 21:21:18
Nun habe ich aber ein Problem mit meinem Jeelinkclone ...
Das ist jetzt wiederum kein neues Problem ;D
Zitat von: emiglio am 25 Februar 2018, 21:21:18
Der State in FHEM wird mit "initizialized" angezeigt ...
Also läuft der Sketch und meldet sich korrekt bei FHEM
Zitat von: emiglio am 25 Februar 2018, 21:21:18
Mir fiel auf, dass der Funkchip wohl nicht korrekt erkannt wird.
Das ist zu 99,x% ein Hardware-Problem, entweder defekter RFM69 oder falsch angeschlossen.
Pegelanpassung drin?
Wie sieht der Schaltplan aus?
Zitat von: emiglio am 25 Februar 2018, 21:21:18
Ich gehe daher davon aus, dass das Problem irgendwie in der Firmware steckt?!
Was bringt Dich zu dieser Annahme?
Hunderte von JeeLinks laufen und auch clone schaffen es manchal zu laufen.
Hallo HCS,
vielen Dank für deine Hilfe.
Ja Pegelanpassung ist über Spannungsteiler realisiert.
Schaltplan zunächst wie hier aufgebaut:
https://haustech.files.wordpress.com/2016/03/bestueckungsplan.png
und in der 6. Reihe von oben auf der Lochrasterplatine über Kabelbrücken dann den RFM69HCW angeschlossen.
Anschlussschema:
RFM Arduino (6. Reihe auf der Lochrasterplatine von oben)
DIO0 -> D2
3,3V -> 3V3
NSS -> D10
MOSI -> D11
MISO -> D12
SCK -> D13
GND -> GND
Annahme Firmware:
Grund für die Annahme ist, dass der Clone als initialized in Fhem erkannt wird nur eben der Funkchip nicht. Wenn beim Flashen o.ä. was schief gelaufen wäre, würde der Clone wahrscheinlich nicht als initialized angezeigt werden.
Viele Grüße
emiglio
Moin zusammen,
ich wollte auch eine Wetterstation W266 (Außeneinheit) von Ventus mit FHEM verbinden, jedoch empfange ich keine Daten.
Weder mit ESPeasy und dem zugehörigen Modul noch mit den LacrosseGateway.
Kann mir jemand sagen, was ich genau einstellen muss und wie ich das Gerät koppel? Muss die Wetterstation noch gekoppelt werden?
Am Liebsten wäre es, die Daten mit dem vorhandenen LacrosseGateway zu Empfangen. Bisher emfange ich damit die Temperatur und die Feuchtigkeit von einem TX35.
Zitat von: joe.lee am 07 März 2018, 09:40:19
ich wollte auch eine Wetterstation W266 (Außeneinheit) von Ventus mit FHEM verbinden, jedoch empfange ich keine Daten.
... noch mit den LacrosseGateway.
Ich gehe mal zu 99.x% davon aus, dass das mit dem LGW nicht geht, da es die W266 nicht explizit unterstützt und es nur dann gehen würde, wenn sie das gleiche Protokoll wie die WS 1600 (TX22) senden würde.
Also laut diesem Beitrag soll es schon gehen.
https://forum.fhem.de/index.php/topic,14786.msg750056.html#msg750056 (https://forum.fhem.de/index.php/topic,14786.msg750056.html#msg750056)
ZitatHallo pejonp,
kurzer Update. Mit der neuen Firmware empfängt das LGW auch Daten des W137/W136 Sensors.
Aber vielleicht sollte ich mit der Frage auch ein neues Thema aufmachen.
@joe.lee
hier ist der Anfang (https://forum.fhem.de/index.php/topic,14786.msg708729.html#msg708729).
pejonp
Klasse, danke.
Hat geklappt. Jetzt werden die Daten geloggt. Gibt es eine Möglichkeit, die Datenrate auch zu togglen oder brauche ich dafür ein zweites Funkmodul? Die 4800 werden auf der Wiki Seite nicht aufgeführt.
Zitat von: pejonp am 07 März 2018, 14:03:14
@joe.lee
hier ist der Anfang (https://forum.fhem.de/index.php/topic,14786.msg708729.html#msg708729).
pejonp
Vielleicht zur Diskussion ein weiteren Thread aufmachen?
@pejonp: ich habe die Erweiterung für WH25A und W137 in die offizielle Schiene übernommen.
Anbei vorab zum Testen, besonders, ob es mit dem binary (firmware\JeeLink_LaCrosse.hex) im Zip funktioniert.
Wenn es OK ist, checke ich es dann ein.
Zitat von: HCS am 11 März 2018, 17:19:16
@pejonp: ich habe die Erweiterung für WH25A und W137 in die offizielle Schiene übernommen.
Anbei vorab zum Testen, besonders, ob es mit dem binary (firmware\JeeLink_LaCrosse.hex) im Zip funktioniert.
Wenn es OK ist, checke ich es dann ein.
Er legt ein Device mit W136 an Stelle von W137 an, ansonsten scheint es zu funktionieren.
@Aeroschmelz
ich habe W137 in W136 umbenannt weil der Sensor so richtig heißt. Ich hatte es hier auch angepaßt (https://forum.fhem.de/index.php/topic,14786.msg708729.html#msg708729).
pejonp
Heute ist mir leider erst aufgefallen, dass seltsamerweise nach dem Firmware Update die Readings "UV" und "WindGust" nicht mit Zahlen gefüllt werden, das Reading "strikesTotal" wird erst gar nicht angelegt, siehe Screenshots. Kann das jemand reproduzieren? Bei der Version "10.1w137" ging das noch.
Zusätzlich erscheinen vereinzelte Readings mehrfach, das war aber bei der Version "10.1w137" von pejonp auch schon so.
Dann scheint es noch nicht so recht ausgereift zu sein.
Ich kann da leider nichts dazu sagen, ich habe keine w136, da muss pejonp danach schauen.
@HCS
bin leider noch nicht zum testen deiner Version gekommen. Versuche es am WE.
@Aeroschmelz
der W136 wird per KeyValue angelegt.
Frequenz und Baud sind richtig eingestellt ? Was wird angezeigt wenn du "1d v" beim JeeLink eingibst, dann sollten debug-Nachrichten kommen.
Hänge bitte einmal den Hex-String vom w136 an (debug jeelink).
pejonp
Hallo pejonp,
bin gestern wieder auf die alte angegebene Version zurück, der Jeelink wird mit folgender Definition betrieben:
define JeeLinkWeather JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1074P1M-if00-port0@57600
attr JeeLinkWeather flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
attr JeeLinkWeather group Tranceiver/Sensoren
attr JeeLinkWeather initCommands 0a 3#4r 868300#4f 33#4t 4800r 0t 869820f v
attr JeeLinkWeather room System
Der Sensor wird folgendermaßen angelegt:
define Balkon KeyValueProtocol W137 191
attr Balkon DbLogExclude WindSpeed,WindDirection,Temperature,Humidity,Rain
attr Balkon IODev JeeLinkWeather
attr Balkon event-min-interval temperature:1200,humidity:1200,windDirAverage:1200,WindGust:1200,windVelAverage:1200,statRainHour:1200,statRainDay:3600,statRainYear:3600,UV:3600,strikesTotal:3600,strikesDistance:3600,Rain:3600
attr Balkon event-on-change-reading temperature:1,humidity:4,windDirAverage:22.5,WindGust:1,windVelAverage:0.5,statRainHour:0.1,statRainDay:0.1,statRainYear:0.1,UV:0.2,strikesTotal:1,strikesDistance:1,Rain:0.1
attr Balkon group Wetterinfo
attr Balkon room Umwelt
attr Balkon sortby 1
attr Balkon stateFormat Luftfeuchtigkeit: humidity %, Temperatur: temperature C, Taupunkt: dewpoint C
attr Balkon userReadings windVelAverage {movingAverage("Balkon","WindSpeed",300);; }, windDirAverage {myWindDirAverage('Balkon','WindSpeed','WindDirection',1200,0.8,0);; }, temperature { ReadingsVal("Balkon","Temperature",0);; }, humidity {ReadingsVal("Balkon","Humidity",0);; }
Hier die debug Nachrichten:
2018.03.19 18:17:45 4: set JeeLinkWeather raw 1d v
2018.03.19 18:17:45 5: SW: 1d v
2018.03.19 18:17:46 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1w137 (RFM69CW f:869820 r:4800)]
2018.03.19 18:17:54 5: JeeLink/RAW: /
End re
2018.03.19 18:17:54 5: JeeLink/RAW: End re/ceiving, HEX raw data: 7E CD E
2018.03.19 18:17:54 5: JeeLink/RAW: End receiving, HEX raw data: 7E CD E/7 B9 66 EC 6 60 91 90 B
2018.03.19 18:17:54 5: JeeLink/RAW: End receiving, HEX raw data: 7E CD E7 B9 66 EC 6 60 91 90 B/E D3 6B E2 E0 1C
2018.03.19 18:17:54 5: JeeLinkWeather: dispatch End receiving, HEX raw data: 7E CD E7 B9 66 EC 6 60 91 90 BE D3 6B E2 E0 1C
2018.03.19 18:17:54 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: 7E CD E7 B9 66 EC 6 60 91 90 BE D3 6B E2 E0 1C , help me!
2018.03.19 18:17:55 5: JeeLink/RAW: /
End rec
2018.03.19 18:17:55 5: JeeLink/RAW: End rec/eiving, HEX raw data: 52 4C D
2018.03.19 18:17:55 5: JeeLink/RAW: End receiving, HEX raw data: 52 4C D/D B8 66 45 F8 31 80 F2
2018.03.19 18:17:55 5: JeeLink/RAW: End receiving, HEX raw data: 52 4C DD B8 66 45 F8 31 80 F2 /51 F8 AD 90 77 FA
2018.03.19 18:17:55 5: JeeLinkWeather: dispatch End receiving, HEX raw data: 52 4C DD B8 66 45 F8 31 80 F2 51 F8 AD 90 77 FA
2018.03.19 18:17:55 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: 52 4C DD B8 66 45 F8 31 80 F2 51 F8 AD 90 77 FA , help me!
2018.03.19 18:18:15 5: JeeLink/RAW: /
End re
2018.03.19 18:18:15 5: JeeLink/RAW: End re/ceiving, HEX raw data: 1D 6A
2018.03.19 18:18:15 5: JeeLink/RAW: End receiving, HEX raw data: 1D 6A /4C 6F 4E 54 CE 83 22 9B A0 63
2018.03.19 18:18:15 5: JeeLink/RAW: End receiving, HEX raw data: 1D 6A 4C 6F 4E 54 CE 83 22 9B A0 63 /CF E2 10 90
2018.03.19 18:18:15 5: JeeLinkWeather: dispatch End receiving, HEX raw data: 1D 6A 4C 6F 4E 54 CE 83 22 9B A0 63 CF E2 10 90
2018.03.19 18:18:15 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: 1D 6A 4C 6F 4E 54 CE 83 22 9B A0 63 CF E2 10 90 , help me!
2018.03.19 18:18:15 5: JeeLink/RAW: /
End receiv
2018.03.19 18:18:15 5: JeeLink/RAW: End receiv/ing, HEX raw data: 7D 79 1A 2
2018.03.19 18:18:15 5: JeeLink/RAW: End receiving, HEX raw data: 7D 79 1A 2/8 D4 F4 14 FD 9F C1 1 29
2018.03.19 18:18:15 5: JeeLink/RAW: End receiving, HEX raw data: 7D 79 1A 28 D4 F4 14 FD 9F C1 1 29/ F3 82 67 D2
2018.03.19 18:18:15 5: JeeLinkWeather: dispatch End receiving, HEX raw data: 7D 79 1A 28 D4 F4 14 FD 9F C1 1 29 F3 82 67 D2
2018.03.19 18:18:15 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: 7D 79 1A 28 D4 F4 14 FD 9F C1 1 29 F3 82 67 D2 , help me!
2018.03.19 18:18:25 5: JeeLink/RAW: /
End re
2018.03.19 18:18:25 5: JeeLink/RAW: End re/ceiving, HEX raw data: 7A 1B
2018.03.19 18:18:25 5: JeeLink/RAW: End receiving, HEX raw data: 7A 1B /96 A9 22 98 9A 70 6A 50 ED E6
2018.03.19 18:18:25 5: JeeLink/RAW: End receiving, HEX raw data: 7A 1B 96 A9 22 98 9A 70 6A 50 ED E6 /F7 9F F 7B
2018.03.19 18:18:25 5: JeeLinkWeather: dispatch End receiving, HEX raw data: 7A 1B 96 A9 22 98 9A 70 6A 50 ED E6 F7 9F F 7B
2018.03.19 18:18:25 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: 7A 1B 96 A9 22 98 9A 70 6A 50 ED E6 F7 9F F 7B , help me!
2018.03.19 18:18:33 5: JeeLink/RAW: /
End rece
2018.03.19 18:18:33 5: JeeLink/RAW: End rece/iving, HEX raw data: EE 72 1B
2018.03.19 18:18:33 5: JeeLink/RAW: End receiving, HEX raw data: EE 72 1B /79 3C E 3A AD BE 29 4F 3F B8
2018.03.19 18:18:33 5: JeeLink/RAW: End receiving, HEX raw data: EE 72 1B 79 3C E 3A AD BE 29 4F 3F B8 /8 33 47
2018.03.19 18:18:33 5: JeeLinkWeather: dispatch End receiving, HEX raw data: EE 72 1B 79 3C E 3A AD BE 29 4F 3F B8 8 33 47
2018.03.19 18:18:33 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: EE 72 1B 79 3C E 3A AD BE 29 4F 3F B8 8 33 47 , help me!
2018.03.19 18:18:42 5: JeeLink/RAW: /
End r
2018.03.19 18:18:42 5: JeeLink/RAW: End r/eceiving, HEX raw data: EB EC 72 2F
2018.03.19 18:18:42 5: JeeLink/RAW: End receiving, HEX raw data: EB EC 72 2F /D8 1E 6C 4F 3A D3 4B E1
2018.03.19 18:18:42 5: JeeLink/RAW: End receiving, HEX raw data: EB EC 72 2F D8 1E 6C 4F 3A D3 4B E1/ 8B A1 F0 BC
2018.03.19 18:18:42 5: JeeLinkWeather: dispatch End receiving, HEX raw data: EB EC 72 2F D8 1E 6C 4F 3A D3 4B E1 8B A1 F0 BC
2018.03.19 18:18:42 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: EB EC 72 2F D8 1E 6C 4F 3A D3 4B E1 8B A1 F0 BC , help me!
2018.03.19 18:18:46 5: JeeLink/RAW: /
End rece
2018.03.19 18:18:46 5: JeeLink/RAW: End rece/iving, HEX raw data: BF 60 1A
2018.03.19 18:18:46 5: JeeLink/RAW: End receiving, HEX raw data: BF 60 1A /E6 FF 0 E6 FF 6 0 0 0 0 31 4
2018.03.19 18:18:46 5: JeeLink/RAW: End receiving, HEX raw data: BF 60 1A E6 FF 0 E6 FF 6 0 0 0 0 31 4 /0
OK VALUES W137 191 H
2018.03.19 18:18:46 5: JeeLinkWeather: dispatch End receiving, HEX raw data: BF 60 1A E6 FF 0 E6 FF 6 0 0 0 0 31 4 0
2018.03.19 18:18:46 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: BF 60 1A E6 FF 0 E6 FF 6 0 0 0 0 31 4 0 , help me!
2018.03.19 18:18:46 5: JeeLink/RAW: OK VALUES W137 191 H/eader=26,Temperature=-2.60,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=135.00,WindGust=0.00,UV=0.00,strikesDistance=-1,strikesTotal=8,
2018.03.19 18:18:46 5: JeeLinkWeather: dispatch OK VALUES W137 191 Header=26,Temperature=-2.60,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=135.00,WindGust=0.00,UV=0.00,strikesDistance=-1,strikesTotal=8,
Genügen die? Offensichtlich gibt es da ein Problem! Demnächst flashe ich dann mal die neue Version....
@Aeroschmelz
das sind die Daten für die W136 (3.Byte 1A) und so wie es aussieht passen die.
2018.03.19 18:18:46 5: JeeLink/RAW: End rece/iving, HEX raw data: BF 60 1A
2018.03.19 18:18:46 5: JeeLink/RAW: End receiving, HEX raw data: BF 60 1A /E6 FF 0 E6 FF 6 0 0 0 0 31 4
2018.03.19 18:18:46 5: JeeLink/RAW: End receiving, HEX raw data: BF 60 1A E6 FF 0 E6 FF 6 0 0 0 0 31 4 /0
OK VALUES W137 191 H
2018.03.19 18:18:46 5: JeeLinkWeather: dispatch End receiving, HEX raw data: BF 60 1A E6 FF 0 E6 FF 6 0 0 0 0 31 4 0
2018.03.19 18:18:46 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: BF 60 1A E6 FF 0 E6 FF 6 0 0 0 0 31 4 0 , help me!
2018.03.19 18:18:46 5: JeeLink/RAW: OK VALUES W137 191 H/eader=26,Temperature=-2.60,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=135.00,WindGust=0.00,UV=0.00,strikesDistance=-1,strikesTotal=8,
2018.03.19 18:18:46 5: JeeLinkWeather: dispatch OK VALUES W137 191 Header=26,Temperature=-2.60,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=135.00,WindGust=0.00,UV=0.00,strikesDistance=-1,strikesTotal=8,
Wenn du aber das hier eingestellt hast, hast du doch ein LaCross Gateway, den der JeeLink hat nicht 4x RFM69CW.
attr JeeLinkWeather initCommands 0a 3#4r 868300#4f 33#4t 4800r 0t 869820f v
beim JeeLink ist das InitCommand anders und wenn du 2x RFM69CW (SuperJee) auch z.B. 4r (1. RFM) 0R (2. RFM).
attr JeeLinkWeather initCommands 0t 4r 869820f v
ich hoffe ich habe nichts durcheinander gebracht.
pejonp
Peinlich ;-) Ich hatte vorher ein laCrosse Gateway und da habe ich die Definitionen wohl durcheinander gebracht. Wenn wir schon dabei sind, lasse ich mal alles raus ;-)
Wie kann ich denn mit m und t zwischen dem W136 und einem TX29DTH-IT togglen?
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)
Da taucht die notwendige Datenrate leider nicht auf...
Im übrigen tritt mit der 10.1t immer noch der gleiche Fehler wie schon beschrieben mit den Readings "UV", "WindGust" (leer) und "strikesTotal" (wird nicht angelegt) auf.
2018.03.19 20:51:39 4: set JeeLinkWeather raw 1d v
2018.03.19 20:51:39 5: SW: 1d v
2018.03.19 20:51:39 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1t (RFM69CW f:869820 r:4800)]
2018.03.19 20:51:41 5: JeeLink/RAW: /
End receivi
2018.03.19 20:51:41 5: JeeLink/RAW: End receivi/ng, HEX raw data: BF 60 1A DD
2018.03.19 20:51:41 5: JeeLink/RAW: End receiving, HEX raw data: BF 60 1A DD/ FF 0 DD FF D 0 0 0 0 31 4 0
2018.03.19 20:51:41 5: JeeLink/RAW: End receiving, HEX raw data: BF 60 1A DD FF 0 DD FF D 0 0 0 0 31 4 0
/
OK VALUES W136 191 Header=26
2018.03.19 20:51:41 5: JeeLinkWeather: dispatch End receiving, HEX raw data: BF 60 1A DD FF 0 DD FF D 0 0 0 0 31 4 0
2018.03.19 20:51:41 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: BF 60 1A DD FF 0 DD FF D 0 0 0 0 31 4 0 , help me!
2018.03.19 20:51:41 5: JeeLink/RAW: OK VALUES W136 191 Header=26/,Temperature=-3.50,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=292.50,WindGust=,UV=,strikesDistance=,8
2018.03.19 20:51:41 5: JeeLinkWeather: dispatch OK VALUES W136 191 Header=26,Temperature=-3.50,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=292.50,WindGust=,UV=,strikesDistance=,8
2018.03.19 20:51:43 5: JeeLink/RAW: /
End rec
2018.03.19 20:51:43 5: JeeLink/RAW: End rec/eiving, HEX raw data: F6 99 D1
2018.03.19 20:51:43 5: JeeLink/RAW: End receiving, HEX raw data: F6 99 D1/ 56 3F 27 8D 29 A8 91 8 36 A
2018.03.19 20:51:43 5: JeeLink/RAW: End receiving, HEX raw data: F6 99 D1 56 3F 27 8D 29 A8 91 8 36 A /4F 46 BA
2018.03.19 20:51:43 5: JeeLinkWeather: dispatch End receiving, HEX raw data: F6 99 D1 56 3F 27 8D 29 A8 91 8 36 A 4F 46 BA
2018.03.19 20:51:44 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: F6 99 D1 56 3F 27 8D 29 A8 91 8 36 A 4F 46 BA , help me!
2018.03.19 20:51:47 5: JeeLink/RAW: /
End rec
2018.03.19 20:51:47 5: JeeLink/RAW: End rec/eiving, HEX raw data: 17 D6 6
2018.03.19 20:51:47 5: JeeLink/RAW: End receiving, HEX raw data: 17 D6 6/4 30 C8 1 91 34 90 A8 D5 B8 4F
2018.03.19 20:51:47 5: JeeLink/RAW: End receiving, HEX raw data: 17 D6 64 30 C8 1 91 34 90 A8 D5 B8 4F/ BF 27 43
2018.03.19 20:51:47 5: JeeLinkWeather: dispatch End receiving, HEX raw data: 17 D6 64 30 C8 1 91 34 90 A8 D5 B8 4F BF 27 43
2018.03.19 20:51:47 3: JeeLinkWeather: Unknown code End receiving, HEX raw data: 17 D6 64 30 C8 1 91 34 90 A8 D5 B8 4F BF 27 43 , help me!
Hallo HCS,
Zitat von: HCS am 11 März 2018, 17:19:16
@pejonp: ich habe die Erweiterung für WH25A und W137 in die offizielle Schiene übernommen.
Anbei vorab zum Testen, besonders, ob es mit dem binary (firmware\JeeLink_LaCrosse.hex) im Zip funktioniert.
wirst Du das dann auch in die LGW Firmware implementieren?
Danke + Gruß
Peter
@Aeroschmelz
das umschalten zwischen W136 und einem TX29DTH-IT wird wahrscheinlich nicht so richtig funktionieren, da ja nicht nur die Daterate sondern auch die Frequenz umgeschaltet werden muss. Das ist so nicht vorgesehen, glaube ich. Die Frequnz wird ja nur einmal eingestellt. Dann lieber einen Jeelink mit 2x RFM69CW nehmen. Bei einem die Frequenz auf 869.820 MHz und 4800 baud einstellen und beim anderen 868.300 MHz und den toggeln lassen.
pejonp
PS: du kannst ja jetzt wieder den debugmodus ausschalten "0d v"
@HCS
Das Problem mit den fehlenden Daten hängt mit der KeyValue Ausgabe beim WH25 und dem W136 zusammen und wahrscheinlich dem fehlendem Speicher beim JeeLink ?!? Oder ich habe es nicht richtig umgesetzt.
2018.03.19 20:51:41 5: JeeLink/RAW: OK VALUES W136 191 Header=26/,Temperature=-3.50,Humidity=60,Rain=268.25,WindSpeed=0.00,WindDirection=292.50,WindGust=,UV=,strikesDistance=,8
WH25.cpp
..
String WH25::GetFhemDataString(byte *data) {
String fhemString2 = "";
struct Frame frame2;
DecodeFrame(data, &frame2);
if (frame2.IsValid) {
--> fhemString2 = BuildFhemDataString(&frame2, 5);
//fhemString2 = BuildKVDataString(&frame2, 5); <---
}
..
Wenn ich in der WH25.cpp "fhemString2 = BuildFhemDataString(&frame2, 5);"nutze und das andere auskommentiere, dann geht das KeyValue im W136.cpp richtig. Der WH25 wird/muss dann als LaCross Device angelegt werden.
...
String W136::GetFhemDataString(byte *data) {
String fhemString = "";
if ((data[2]) == 0x1A) {
struct Frame frame;
DecodeFrame(data, &frame);
if (frame.IsValid) {
//fhemString = BuildFhemDataString(&frame, 6);
fhemString = BuildKVDataString(&frame, 6);
}
}
..
Die beiden Sensoren erben Ihre Felder aus WSBase.h, vielleicht fehlt dort noch eine Definition.
class W136 : public WSBase {
...
class WH25 : public WSBase {
...
pejonp
PS: Als Anlage die angepaßte Version für die WH25.
Hallo pejonp,
habe die Version gerade eben geflasht. Es sieht soweit gut aus. Ich werde das mal weiter beobachten.
Viele Grüsse
Marcus
Hallo,
Wollte nur berichten, dass alle notwendige Readings geloggt werden, allerdings werden sie teilweise immer noch mehrfach angelegt. InitCommands lautet
0a 0t 4r 869820f v
VG
Marcus
Zitat von: justme1968 am 05 Mai 2014, 15:57:31warum loggst du denn state und nicht temperature und humidity?
Mache ich genau so. Nicht nur wegen der besseren Übersichtlichkeit, sondern auch wegen dem Datensparen und SD-Karte schonen: Es benötigt weniger als die Hälfte an Platz. Datum/Uhrzeit und Sensorname wird nur einmal statt zweimal geschrieben, und statt "Temperature" und "Humitidy" steht nur T und H.
Prinzipiell bin ich damit sehr zufrieden, nur das "ab und zu Wert loggen auch ohne Änderung" hätte ich gerne.
Dass state kein Event wirft ohne Änderung, okay. Aber leider reagiert state auch nicht auf das "EventMinIntervall" - was bei Battery klaglos geht. (Battery logge ich 1x je Stunde.) Soll das so?
Andernfalls, HCS, wie hast du es mit dem UserReading genau gelöst? Bevor ich das Rad jetzt neu erfinde...
Zitat von: didy am 04 August 2018, 15:53:12
Andernfalls, HCS, wie hast du es mit dem UserReading genau gelöst? Bevor ich das Rad jetzt neu erfinde...
Mein Rad:
Internals:
DEF 0C
IODev lgw210
LASTInputDev lgw210
LaCrosse_lastRcv 2018-08-06 21:00:00
MSGCNT 48485
NAME Temperature_Cellar_Hobby
NR 60
STATE T: 22.8 H: 77 D: 18.4
TYPE LaCrosse
addr 0C
battery_new 0
bufferedH
bufferedT
corr1 0
corr2 0
lgw210_MSGCNT 47904
lgw210_TIME 2018-08-06 21:00:00
lgwUSB_MSGCNT 925
lgwUSB_TIME 2018-07-30 00:57:03
previousH 77
previousT 22.7
sensorType 0=T(H)
READINGS:
2018-08-06 21:00:00 battery ok
2018-08-06 21:00:00 dewpoint 18.4
2018-08-06 21:00:00 humidity 77
2018-08-06 20:23:05 state T: 22.8 H: 77 D: 18.4
2018-08-06 21:00:00 temperature 22.8
2018-08-06 21:00:00 values T: 22.8 H: 77 D: 18.4 B: ok
Attributes:
IODev lgw210
comment TX29DTH
doAverage 1
doDewpoint 1
event-min-interval values:300
event-on-update-reading values,battery,temperature,humidity
filterThreshold 5
resolution 2
room Entfeuchter,System
userReadings values { "T: " . ReadingsVal("Temperature_Cellar_Hobby","temperature",0) . " H: " . ReadingsVal("Temperature_Cellar_Hobby","humidity",0) . " D: " . ReadingsVal("Temperature_Cellar_Hobby","dewpoint",0) . " B: " . ReadingsVal("Temperature_Cellar_Hobby","battery","??") ;; }das FileLog device hat diese DEF:
./log/Temperature_Cellar_Hobby-%Y.log Temperature_Cellar_Hobby:values.*
Ergibt im Log:
2018-08-06_18:23:49 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_18:29:08 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_18:34:28 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_18:39:47 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_18:45:15 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_18:50:26 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_18:55:45 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:01:04 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:06:24 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:11:51 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:17:11 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:22:30 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:27:49 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:33:08 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:38:28 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:43:47 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:49:06 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:54:26 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_19:59:49 Temperature_Cellar_Hobby values: T: 22.8 H: 76 D: 18.2 B: ok
2018-08-06_20:05:04 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:10:28 Temperature_Cellar_Hobby values: T: 22.8 H: 76.2 D: 18.4 B: ok
2018-08-06_20:15:47 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:21:10 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:26:30 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:31:45 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:37:04 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:42:32 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:47:51 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
2018-08-06_20:53:10 Temperature_Cellar_Hobby values: T: 22.8 H: 77 D: 18.4 B: ok
Hallo,
wo findet man denn die Firmware für den Relay-Betrieb des JeeLink ?
Wäre super wenn jemand einen Link hätte oder die FW hier hochladen könnte.
Und Frage2: Wie kann ich sehen / testen, ob der Relay-Jeelink funktioniert? RSSI Werte wie bei HM gibt es ja nicht.
Wenn ich oben in diesem Thread in die Suche Relay eingebe kommen alle Antworten! ;)
Kurz gesagt das ist die normale FW man muß nur vor dem Flashen als relay konfigurieren.
Siehe auch in der Wiki
https://wiki.fhem.de/wiki/JeeLink#Relay-Betrieb (https://wiki.fhem.de/wiki/JeeLink#Relay-Betrieb)
https://forum.fhem.de/index.php/topic,14786.msg165153.html#msg165153 (https://forum.fhem.de/index.php/topic,14786.msg165153.html#msg165153)
etc. etc.
Gruß
Billy
OK, Billy war schneller, ich schicke es trotzdem ab :)
Zitat von: errazzor am 10 August 2018, 18:45:40
wo findet man denn die Firmware für den Relay-Betrieb des JeeLink ?
Wäre super wenn jemand einen Link hätte oder die FW hier hochladen könnte.
Es gibt keine separate Firmware für den Relay-Betrieb.
Siehe hier und hier:
https://forum.fhem.de/index.php/topic,14786.msg165153.html#msg165153
https://wiki.fhem.de/wiki/JeeLink#Relay-Betrieb
Und bei allen weiteren treffern zum Thema "Relay" in diesem Thread
Zitat von: errazzor am 10 August 2018, 18:45:40
Und Frage2: Wie kann ich sehen / testen, ob der Relay-Jeelink funktioniert? RSSI Werte wie bei HM gibt es ja nicht.
Daran, dass man den Sensor, der zu weit weg ist, dann empfängt?
@HCS
Meine Jeelinks laufen und laufen, :D
musste mich erst wieder einlesen trotzdem schönen Abend .
Gruß
Billy
Danke. Die verlinkten Beiträge hatte ich gefunden, allerdings hatte ich damals bei der Einrichtung eine "fertige" FW zum flashen per FHEM.
Ich dachte das gäbe es auch für den Relay-Betrieb.
Also ich habe nun den Sketch als Relay konfiguriert und geflasht und den Jeelink dann testweise an verschiedenen Stellen platziert. Bringt leider gar nichts, die Sensoren werden trotzdem nicht empfangen.
Gibt es sonst noch etwas zu beachten? Muss ich um Sketch sonst noch etwas einstellen , Frequenz oder ähnliches?
Konkret geht es darum - TempSensoren im Keller, RPI mit Jeelink im OG. Empfang = Null.
Stelle ich diese Sensoren ins EG, werden sie empfangen.
Mit Relay-Jeelink im KG an verschiedenen Stellen oder auch im EG an verschiedenen Stellen absolut kein Unterschied.
Der Relay-Jeelink gibt auf der Konsole folgendes aus:
[LaCrosseITPlusReader.10.1s (RFM69CW f:868300 r:17241)]
OK 9 8 1 4 209 106
OK 9 8 1 4 209 106
OK 9 8 1 4 209 106
OK 9 8 1 4 209 106
OK 9 8 1 4 208 106
OK 9 8 1 4 208 106
Ein List meines JeeLink am RPI:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 12
NAME myJeeLink
NR 60
PARTIAL
RAWMSG OK 9 5 1 4 214 42
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 34681
myJeeLink_TIME 2018-08-12 11:38:13
settings (RFM69CW f:868300 t:30~7)
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:
2018-08-12 11:38:13 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0a 7m 30t v
room LaCrosse
timeout 1800,300
Für weitere Hilfe wäre ich dankbar.
Das muss @HCS klären ob das mit Version 10.1s geht?
Habe im Netz folgendes gefunden.
ZitatThema Reichweitenerhöhung :
Nachdem ich mit dem JeeLink-Clone am RASPI zusammen mit den Sensoren TX29 und TFA 30.3147.IT einen erfolgreichen Test mit FHEM 5.7 erledigen konnte sollte jetzt ein Sensor mit über 30 Meter Entfernung plus 4 Wände erreicht werden.
Leider funktionierte der Aufbau mit einem JeeLink-Relais LaCrosse-Sketch Version 10.q in der Mitte nicht. Mit Debug sieht man das der Empfänger arbeitet und auch wohl senden will aber am Raspi kommt nichts an.
Workaround: Mit der alten LaCrosse-Version 10.e läuft die Kommunikation super !!
Vielleicht hilft das weiter?
Gruß
Billy
Hm..ich probiers, wenn ich die alte 10.e Version irgendwo finden kann...ich nehme an nur der Relay-Jeelink braucht dann die ältere Version?
Zitat von: errazzor link=topic=14786.msg826470#msg826470
ich nehme an nur der Relay-Jeelink braucht dann die ältere Version?
/quote]
Sieht so aus.
Ich glaube ich kann Erfolg vermelden.
Ich habe den Relay-Jeelink jetzt mit dem Sketch in der Version "h" geflasht und zusätzlich noch "toggle" aktiviert. Hat offenbar funktioniert, meine Kellersensoren melden sich nun fleissig.
Die Version "e" ging übrigens überhaupt nicht bei mir, da hat der Jeelink wie wild geblinkt und nicht ausgesendet. Keine Ahnung wieso.
Bin mir nur noch nicht sicher ob der Erfolg jetzt an der Sketch-Version "h" oder dem "toggle" liegt. Werde ich mal noch austesten.
Aber erstmal bin ich zufrieden, endlich hat mal wieder was geklappt ;D
Nachtrag: Was übrigens sehr genial ist - ich konnte den Relay-Jeelink in die im Erdgeschoss vorhandene Fritzbox zur Stromversorgung stecken. Brauche also kein extra Netzteil. *Happy*
Danke für die Hilfe hier.
Gratuliere,
Zitat von: errazzor am 12 August 2018, 22:27:22
Bin mir nur noch nicht sicher ob der Erfolg jetzt an der Sketch-Version "h" oder dem "toggle" liegt. Werde ich mal noch austesten.
Aber aus meiner Sicht kann es nicht am toggle liegen. Eine Datenrate hätte ja immer angezeigt werden müssen.
Billy
Hallo HCS,
ich habe dein LaCrossGateway noch um das Protokoll WH24 erweitert (https://forum.fhem.de/index.php/topic,93280.msg859226.html#msg859226).
Jörg
Hallo kann mir bitte jemad helfen bevor ich etwas falsch mache.
Ich verwende seit einigen Jahren den:
- LaCrosse JeeLink Stick für die WS1600 sowie einen TX29 DTH
- dort sind beide Sensoren gleichzeitig im Togglemodus angebunden
- die initCommands sind so eingestellt 5m 30t 0a v
- Problem darin ist das die WS1600 immer 30s Pause machen muss.
Daher möchte ich jetzt den TX29 DTH ablernen und nur noch die WS1600 als Dauerempfang haben.
Nun meine Frage.
- wie müssen die initCommands jetzt neu aussehen
- und kann ich diese einfach ändern und der Jeelink empfängt die WS1600 dann dauerhaft. oder muss auch die Ws1600 neu angelernt werden? (ich habe dann immer das Problem mit flaschen Statistikwerten wenn ich sie neu anlernen müsste) < daher diese Frage.
Vielen Dank Gruß Thomas
Hallo Depechem,
so sehen meine Einstellungen aus:
4m 2r v
So viel ich weiss muss nichts neu eingelernt werden.
Ich boote nur den Stick neu.
Gruß rippi
Zitat von: rippi46 am 07 Juni 2019, 11:39:17
Hallo Depechem,
so sehen meine Einstellungen aus:
4m 2r v
So viel ich weiss muss nichts neu eingelernt werden.
Ich boote nur den Stick neu.
Gruß rippi
vieln Dank. es hat funktioniert
Ich nutze das Jeelink Modul nun schon seit mehreren Jahren und have mehrere LaCrosse Wettersensoren von TFA Dostmann damit in FHEM integriert.
Da es unlängst ein ganz gutes Angebot gab, habe ich 2 IT+ Klima Logg Pro Sensoren dazu gekauft und möchte diese nun einbinden.
Die Rückseite eines der beiden Sensoren ist wie folgt beschriftet:
08/2018
V026 C2
und
ID: 75C2 R08C
Es gelang mir bislang nicht diesen Sensor in FHEM einzubinden.
Da ich mein "Produktivsystem" nicht verkonfigurieren wollte, habe ich mir einen 2. Jeelink gekauft und teste nun den Empfang unter OSX mit einer frischen und nackten Installation der letzten FHEM Version.
Ich verwende diesen Jeelink https://www.amazon.de/JeeLink-LaCrosse-868MHz-FTDI-USB-Antenne-Adapter/dp/B07T61BXLX
mit der Firmware LaCrosseITPlusReader.10.1s
Setings sind: (RFM69CW f:868300 r:17241)
Die bisherigen Sensoren werden einwandfrei empfangen, der neue nicht.
Wie ich unter https://wiki.fhem.de/wiki/JeeLink gesehen habe, scheinen diese Sensoren vom Typ TX22/WS1600/TI 30.3180 zu sein und mit einer anderen Datenrate zu senden, weswegen ich den Test-Jeelink wie folgt mit initCommands versehen habe:
4m v
(Also fix auf 8.842 kbps eingestellt)
Leider empfange ich nach einem Restart von FHEM/Neustecken des Jeelinks nach wie vor nichts.
Witzigerweise werden aber auch weiterhin die Daten der alten Sensoren empfangen? Das dürfte doch gar nicht mehr funktionieren, da diese doch mit einer Datenrate von 17.241 kbps senden?
Folgende Meldungen sehe ich mit verbose Level 5 im Log:
2019.10.24 12:28:09 5: JeeLink/RAW: /
[LaCrosseITPlusReader.10.1s (RFM69CW f:868300 r:17241)]
2019.10.24 12:28:09 5: SW: 4m
2019.10.24 12:28:09 5: SW: v
2019.10.24 12:28:09 5: JeeLink/RAW: /OK 9 42 1 4 197 52
[LaCrosseITPlusReader.10.1s (RF
2019.10.24 12:28:09 5: myJeeLink: dispatch OK 9 42 1 4 197 52
2019.10.24 12:28:09 5: JeeLink/RAW: [LaCrosseITPlusReader.10.1s (RF/M69CW f:868300 r:17241)]
2019.10.24 12:28:10 5: JeeLink/RAW: /OK 9 47 1 4 200 54
2019.10.24 12:28:10 5: myJeeLink: dispatch OK 9 47 1 4 200 54
2019.10.24 12:28:13 5: JeeLink/RAW: /OK 9 5 1 4 189 54
2019.10.24 12:28:13 5: myJeeLink: dispatch OK 9 5 1 4 189 54
2019.10.24 12:28:13 5: JeeLink/RAW: /OK 9 42 1 4 197 52
Die Sensoren 42, 47, 5 sind alles existierende Sensoren, die bereits angelernt sind. Der neue ist nicht dabei
Die Einträge für "4m v" sind vorhanden - werden diese nicht genutzt?
Zitat von: daubsi am 24 Oktober 2019, 12:30:43
Die Rückseite eines der beiden Sensoren ist wie folgt beschriftet:
08/2018
V026 C2
und
ID: 75C2 R08C
Sensoren wir die TX29DTH-IT, TX22, usw. haben eine zwei Byte lange ID.
Die von Dir beschriebenen laut Rückseite ein vier Byte ID.
Ich bin mir zu 99,9999% sicher, dass der JeeLink-Sketch das Protokoll, das diese Sensoren senden, nicht kann.
Das JeeLink-Modul auf FHEM-Seite kann es genausowenig.
Ich vermute Du meinst 30.3180.IT oder 30.3181.IT oder so was in der Art?
Zitat von: daubsi am 24 Oktober 2019, 12:30:43
Die Einträge für "4m v" sind vorhanden - werden diese nicht genutzt?
Eine fixe data rate 8842 setzt man mit:
8842r oder 2r
Allerdings glaube ich nicht, dass die mit 8842 senden sondern vermutlich mit 38400.
Ist aber eigentlich eh egal, weil das Protokoll nicht übereinstimmt.
Und ich glaube sie senden NRZS (wovon ich wiederum vermute, dass das der RFM69 generell nicht kann) und nicht NRZ wie die TX22.
Hallo,
ja, der RfM69 kann das NRZS nicht, daher ist es nicht möglich diese Sender mit den JeeLink oder einen Clone zu empfangen.
Wenn es unbedingt solche Sender sein müssen, bei mir ein Regenmesser und das Pool-Thermometer, dann guckt dir doch mal dieses Projekt an:
https://github.com/baycom/tfrec
Damit kannst du diese Sensoren empfangen:
https://github.com/baycom/tfrec/blob/master/sensors.txt
Gruß
Maik
Hallo,
ich habe seit ein paar Tagen ein Problem mit meine JeeLink Clone. Dieser ist/war seit ca. 4 Jahren in Betrieb und hat gut an 12 Sensoren (TFA 303155) funktioniert.
Vor ein paar Tagen habe ich einen Signalduino am Raspberry hängen und hatte ein paar Probleme mit der Zuordnung der USB Schnittstelle.
Nachdem ich dann beide mit /dev/serial/by-id/ eingerichtet hatte, war soweit alles OK.
Komischerweise habe ich aber 3 Sensoren nicht mehr empfangen können.
Ich habe dies und das probiert und dann letztendlich auch den JL-Clone mit der neuen LaCrosse 10s.hex geflasht. (Vorher war es 10e)
Seither empfange ich sogar nur noch 2 der 12 Sensoren.
Ich habe auch wieder hin und her probiert, aber ohne Erfolg.
So sieht mein Clone derzeit aus:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
FD 14
FUUID 5da6ce0c-f33f-a358-1206-74bd2ff18ac5b4c7
NAME myJeeLink
NR 39
PARTIAL
RAWMSG OK 9 42 1 4 165 71
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 5
myJeeLink_TIME 2019-10-26 11:55:49
settings (RFM12B f:868300 r:9579)
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:
2019-10-26 11:55:49 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 0a 1r 0t 868290v
room Interface
Der myJeeLink_MSGCNT steigt auch nicht an. Also empfängt der Stick keine Daten.
Was mich aber auch etwas stört, aber finde keine Lösung, dass sich die Frequenz nicht über initcommands ändern lässt (weder per set myJeelink reset und auch nicht über ein Reboot des RPI)
Ebenso bin ich verwundert das bei mir unter model nur LaCrosseITPlusReader.10.1s und (RFM12B f:868300 r:9579) unter settings steht.
Das habe ich so auf keinem Screenshot gefunden.
Ich hoffe das mir jemand helfen kann.
Ärgere mich ohne Ende, das es plötzlich nicht mehr richtig funktioniert.
Never change a running system!!! >:(
Grüße
Hi,
guck mal ob die Datenrate im JeeLink passend zu deinen Sendern gesetzt ist:
https://wiki.fhem.de/wiki/JeeLink#Toggle_und_Datenrate
Momentan hört dein JeeLink nur auf einer Datenrate.
Gruß
Maik
Zitat von: istler am 26 Oktober 2019, 12:22:53
Hi,
guck mal ob die Datenrate im JeeLink passend zu deinen Sendern gesetzt ist:
https://wiki.fhem.de/wiki/JeeLink#Toggle_und_Datenrate
Momentan hört dein JeeLink nur auf einer Datenrate.
Gruß
Maik
Ja, auch damit habe ich gespielt.
Aber die TFA 303155WD funken mit 9.579 kbps.
Auch wenn ich toggle aktiviere bliebt es bei den 2 Sensoren die empfangen werden.
Warum nimmt der JeeLink Clone aber keine Änderung der Frequenz an?
Weder über InitCommands noch über Raw?
Grüße
NACHTRAG:
ich habe mir nun den JeelinkClone mal noch am Windows Rechner mit ArduinoBulider angeschaut:
Serial port COM5 opened at baudrate of 57600bps
[LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
OK 9 42 1 4 165 71
OK 9 2 1 4 214 61
OK 9 42 1 4 165 71
OK 9 2 1 4 214 61
OK 9 42 1 4 165 71
OK 9 2 1 4 214 61
OK 9 42 1 4 165 71
Dort empfange ich auch nur die zwei einsamen Sensoren, wie eben auch mit FHEM.
Mich verwundert aber das scheinbar per default die Datenrate auf 17241 steht und ich trotzdem die TFA empfange die eigtl. auf 9579 senden.
NACHTRAG2:
Nach erneutem flashen und anpassen der Frequenz auf 868340f empfange ich wieder 9 meiner 12 Sensoren.
Keine Ahnung warum das jetzt plötzlich wieder klappt.
Es bleibt mir aber ein Rätsel warum der JKClone nun drei Sensoren einfach "überhört".
Ich habe mir aber eben auch ein NodeMCU und einen RF69HW bestellt. Werde dannn mal noch versuchen ein LaCrosse Gateway aufzubauen.
Freue mich aber trotzdem über Hilfe bei der Fehlersuche/behebung.
Hallo,
Liest hier jemand mit der ein TX29 DTH-IT hat?
Kann es sein, daß beim TX29 DTH-IT das new battery Bit immer gesetzt ist, oder dauert dies nach einem Batteriewechsel länger (ca wie lange) bis das new battery Bit gelöscht wird?
Gruß Ralf
Zitat von: Ralf9 am 05 Januar 2020, 23:01:00
Liest hier jemand mit der ein TX29 DTH-IT hat?
Kann es sein, daß beim TX29 DTH-IT das new battery Bit immer gesetzt ist, oder dauert dies nach einem Batteriewechsel länger (ca wie lange) bis das new battery Bit gelöscht wird?
Ich habe mehrere TX29DTH-IT. Das new battery flag geht definitiv nach einiger Zeit weg. Habe gerade vor einigen Tagen bei einem die Batterien gewechselt und eben nochmal nachgeschaut. Sendet kein new battery mehr.
Allerdings habe ich noch nie darauf geachtet, wann er das Flag nach dem Einlegen der Batterien wieder weg nimmt.
Dann dauert es mehrere Stunden bis das new battery flag weg geht. Ich hatte den TX29DTH-IT bis jetzt zum Testen nur max ca 1-2 Stunden inbetrieb.
Ich bin mir nicht sicher ob der TX29DTH-IT meine Homematic Geräte stören oder beeinträchtigen kann, er sendet ja sehr oft ca alle 5 Sekunden und die Frequenz und Modulation ist gleich.
Falls es jemand genau wissen will, ich hatte es am So, 29 September 2013 17:23
bei der Initialisierung der La Crosse Geschichte an Oweh übermittelt.
ZitatBilly schrieb am So, 29 September 2013 17:23
Nur noch ein Hinweis aus folgendem Link. http://gcrnet.net/node/32
Zitat:
Principle is that a channel number is randomly chosen by transmitter upon initialisation. The transmitter will use this channel ID forever, up to the next initialization (battery change). To help pairing, a flag telling the transmitter is in this pairing phase is set during approximately 4h30mn.
d.h. (wenn ich das richtig lese) dass das Battery Flag erst nach 4h30min seinen Status ändert.
Zitat:
damit ist alles gesagt!
dass das Battery Flag erst nach 4h30min seinen Status ändert.Seitdem läuft übrigens mein (meine) TX29 DTH-IT problemlos.
Mit Homematic stört sich da nichts! ;)
Hallo zusammen,
ich habe mit meinem JeeLink und den angebundenen Sensoren ein Problem, bei dem ich nicht weiter komme.
Ich betreibe seit ca. 4 Jahren - bisher ohne größere Probleme - ca. 10 Technoline TX29DTH-IT, die ich per JeeLink auslese. Der JeeLink steckt direkt im Raspberry (es sind alle USB-Ports belegt). Der Raspberry mit Jeelink steht im EG im HWR, die Sensoren sind im Haus und draußen verteilt. Vor einigen Tagen stand ein größerer Umzug meiner Heimautomatisierung an - die FHEM-Installation ist von einem Raspberry Pi 3B mit Raspbian Wheezy auf einen Raspberry Pi 4B mit Raspbian Buster umgezogen.
Seit dem Umzug habe ich Probleme mit einigen der Sensoren im OG - ich empfange keine Messwerte mehr. Da die Sensoren seit inzwischen 4 Jahren noch mit dem ersten Batteriesatz liefen und inzwischen das Batterie-Symbol anzeigten, bin ich davon ausgegangen, dass die Empfangsprobleme Folge zu schwacher Batterien sind. Also Batterien gewechselt - bringt aber nicht. Hole ich die Sensoren runter in's EG, empfängt der Pi Werte, bringe ich die Sensoren zurück in's OG, bleiben die Werte aus. Der neue Pi ist ziemlich genau so positioniert wie der alte, der Jeelink steckt in vergleichbarer Position.
Was könnte ich noch probieren? Habe zwischenzeitlich auch den Sketch neu geflashed, das ändert nichts. Meine Konfiguration:
model LaCrosseITPlusReader.10.1s
settings (RFM12B f:868300 r:17241)
Ein generelles Konfigurationsproblem meine ich ausschließen zu können, die gesamte fhem.cfg wurde 1:1 übernommen, und sämtliche Sensoren im EG und im Außenbereich sowie die Hälfte der Sensoren im OG funktioniert nach wie vor...
Hi,
evtl. macht der neue Pi mehr Funk Störfeuer?
Probiere doch mal ein USB Verlängerungskabel aus. Geht es dann?
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Hallo Schachti,
das gleiche Problem hatte ich auch nach einem Umzug auf den aktuellen Raspi.
Immer wieder hatten meine (beiden!) Jeelink-Sticks Empfangsprobleme. Auch ein Aktualisieren/Neuflashen hat nichts gebracht.
Bei mir hat es geholfen, den Jeelink-Sticks den Befehl
attr myJeelink timeout 120,30
hinzuzufügen.
Gruß
Wolfgang
Danke für Eure Tipps - Neupositionierung mittels USB-Verlängerung und Setzen des Timeout haben nicht gereicht, was letztlich funktioniert hat (vielleicht gemeinsam mit den beiden anderen Tipps, denn die habe ich als erstes probiert und nicht mehr rückgängig gemacht): dadurch, dass die Sensoren mehrere Jahre mit dem ersten Batterie-Satz liefen, waren in einigen Sensoren die Batterien ganz leicht ausgelaufen. Ist mir beim Wechseln zunächst nicht aufgefallen, habe dann aber eine hauchdünne weißliche Verkrustung auf den Kontakten in den Sensoren entdeckt. War wohl nicht so schlimm, dass die Sensoren mit frischen Batterien gar nicht mehr laufen, aber wohl doch so, dass es die Sendeleistung beeinträchtigt hat. Kann ich mir zumindest nur so erklären, denn nach gründlicher Reinigung der Kontakte steht die Verbindung prinzipiell wieder, wenn auch mit gelegentlichen Aussetzern.
Hallo zusammen
Ich bin neu hier und versuch gerade die ID's für meine La Crosse zu finden. Ich hab hier die Wetter Station MA10421. Die Sensoren sind TX49D-IT. Aktuell versuch noch mit pylacrosse überhaupt irgendwelche IDs zu finden. Hat jemand eine Idee? Oder gehen die Dinger sowieso gar nicht?
Vorab schonmal denke für euere Hilfe.
Moin,
bist du sicher, dass es die MA10421 ist oder ist es MA10241? eine WS MA10421 kann ich nicht finden, ebenso den TX49D-IT. Oder ist das der TX29D-IT?
Ansonsten mal hier mit probieren: https://github.com/baycom/tfrec
Dazu wird aber ein DVB-T-Stick benötigt, dafür kann dieser dann mehr Sensoren (mit unterschiedlichen Signalcodierungen) empfangen als der Jeelink.
Gruß
Maik
Ich bin mir ziemlich sicher. Es ist folgende Wetterstation http://www.lacrossetechnology.fr/P-25-A1-MA10421.html
Gemäss Datenblatt werden auch hier die Daten auf 868MHz übertragen: http://www.lacrossetechnology.fr/donnees/documents/produits/MA10421/PDF-fr-MA10421.pdf
Ist ja interessant, die sind nicht leicht zu finden..
Die senden zwar alle IM 868 MHz Bereiche (ISM-Band), aber die Sensoren verwenden unterschiedliche Modulierung / Signalcodierungen. Ich meine, dass der Jeelink nur die FM-NRZ Codierung kann. Die Mobile Alerts Sensoren senden aber mit einer PSK-NRZM Modulierung.
https://github.com/baycom/tfrec/blob/master/sensors.txt
Da wird der Jeelink die MA-Sensoren gar nicht sehen.
Gruß
Maik
Zitat von: istler am 02 September 2020, 17:16:38
Ich meine, dass der Jeelink nur die FM-NRZ Codierung kann.
Korrekt
Zitat von: istler am 02 September 2020, 17:16:38
Die Mobile Alerts Sensoren senden aber mit einer PSK-NRZM Modulierung.
Oder NRZS mit 6000 baud, schwer zu sagen.
Ist aber egal, beides kann der JeeLink (oder besser gesagt das Radio, das er drauf hat) nicht.
Hallo zusammen,
ich betreibe neben einem Lacrosse Jeelink auch einen PCA-Jeelink und einen Busware-CUL für FS20.
Ansich funken, bzw. Empfangen die Jeelinks die Temperatursensoren bzw. Steckdosenaktoren fehlerfrei.
Nur bekomme ich im Log zu nicht festen Zeiten folgende Einträge.
2020.11.01 17:08:18 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.2:1.0-port0 disconnected, waiting to reappear (myJeeLink)
2020.11.01 17:08:18 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.3:1.0-port0 disconnected, waiting to reappear (PCA301_JeeLink)
2020.11.01 17:08:21 3: Setting myJeeLink serial parameters to 57600,8,N,1
2020.11.01 17:08:22 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.2:1.0-port0 reappeared (myJeeLink)
2020.11.01 17:08:22 3: Setting PCA301_JeeLink serial parameters to 57600,8,N,1
2020.11.01 17:08:23 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.3:1.0-port0 reappeared (PCA301_JeeLink)
2020.11.01 17:15:48 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.2:1.0-port0 disconnected, waiting to reappear (myJeeLink)
2020.11.01 17:15:48 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.3:1.0-port0 disconnected, waiting to reappear (PCA301_JeeLink)
2020.11.01 17:15:53 3: Setting PCA301_JeeLink serial parameters to 57600,8,N,1
2020.11.01 17:15:54 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.3:1.0-port0 reappeared (PCA301_JeeLink)
2020.11.01 17:15:54 3: Setting myJeeLink serial parameters to 57600,8,N,1
2020.11.01 17:15:55 1: /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1.2:1.0-port0 reappeared (myJeeLink)
Beide Jeelinks, aber auch der CUL sind über einen aktiven Hub mittel "by-path" eingebunden.
Dieses Verhalten hatte ich aufm Raspi3b mit Jessie, aber auch jetzt nach dem Umzug auf einen Raspi4 mit Buster.
Teilweise wird auch der CUL immer wieder disconnected und reappeared.
Es scheint keine grösseren Einflüsse aufs Empfangen und Senden zu haben, will aber dass das System sauber läuft und sich nichts hochschaukelt.
Schönen Abend noch,
Gruß und Danke
Adrian
Ich vermute mal es hat nichts mit Jeelink (oder CUL) zu tun, sondern eher mit Stromversorgung (oder mit der USB-Kompatibilität des Hubs).
Ein Ansatz wäre mal den Jeelink direkt am Raspberry anzustecken und prüfen ob das etwas verändert.
Gucke mal, ob Du im kern.log bezüglich usb etwas findest
Die USB-Jeelinks sind zu breit und dick, die passen nicht alle drei an die USB Ports am Raspi.
Wollte durch die Verwendung eines Hubs den Raspi stromtechnisch entlasten.
Da hätte ich eine Rückfrage
Welche USB Hubs sind kompatibel?
GNU nano 3.2 kern.log
Nov 1 17:08:18 raspberrypi kernel: [70079.801259] usb 1-1.1: clear tt 1 (9061) error -71
Nov 1 17:08:18 raspberrypi kernel: [70079.801753] usb 1-1.1: clear tt 1 (9041) error -71
Nov 1 17:08:18 raspberrypi kernel: [70079.802247] usb 1-1.1: clear tt 1 (9061) error -71
Nov 1 17:08:18 raspberrypi kernel: [70079.802866] usb 1-1.1: clear tt 1 (9041) error -71
Nov 1 17:08:18 raspberrypi kernel: [70079.803504] usb 1-1.1: clear tt 1 (9061) error -71
GNU nano 3.2 kern.log
Nov 2 18:31:02 raspberrypi kernel: [161445.528385] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.528883] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.529380] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.529999] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.530697] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.531143] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.531769] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.532394] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.532892] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.533381] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.534003] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.534708] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.535207] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.535774] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.536443] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.536892] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.537384] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.538006] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.538709] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.539210] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.539924] usb 1-1.1: clear tt 1 (9061) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.540401] usb 1-1.1: USB disconnect, device number 18
Nov 2 18:31:02 raspberrypi kernel: [161445.540411] usb 1-1.1.1: USB disconnect, device number 19
Nov 2 18:31:02 raspberrypi kernel: [161445.540421] usb 1-1.1.1.4: USB disconnect, device number 21
Nov 2 18:31:02 raspberrypi kernel: [161445.540744] usb 1-1.1: clear tt 1 (9041) error -71
Nov 2 18:31:02 raspberrypi kernel: [161445.541337] cdc_acm 1-1.1.1.4:1.0: failed to set dtr/rts
Nov 2 18:31:02 raspberrypi kernel: [161445.545845] usb 1-1.1.2: USB disconnect, device number 20
Nov 2 18:31:02 raspberrypi kernel: [161445.546071] ftdi_sio ttyUSB0: error from flowcontrol urb
Nov 2 18:31:02 raspberrypi kernel: [161445.546486] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Nov 2 18:31:02 raspberrypi kernel: [161445.546523] ftdi_sio 1-1.1.2:1.0: device disconnected
Nov 2 18:31:02 raspberrypi kernel: [161445.547289] usb 1-1.1.3: USB disconnect, device number 22
Nov 2 18:31:02 raspberrypi kernel: [161445.547488] ftdi_sio ttyUSB1: error from flowcontrol urb
Nov 2 18:31:02 raspberrypi kernel: [161445.547909] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
Nov 2 18:31:02 raspberrypi kernel: [161445.547962] ftdi_sio 1-1.1.3:1.0: device disconnected
Nov 2 18:31:03 raspberrypi kernel: [161445.841591] usb 1-1.1: new high-speed USB device number 23 using xhci_hcd
Nov 2 18:31:03 raspberrypi kernel: [161445.971975] usb 1-1.1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
Nov 2 18:31:03 raspberrypi kernel: [161445.971983] usb 1-1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Nov 2 18:31:03 raspberrypi kernel: [161445.971990] usb 1-1.1: Product: USB 2.0 Hub
Nov 2 18:31:03 raspberrypi kernel: [161445.973111] hub 1-1.1:1.0: USB hub found
Nov 2 18:31:03 raspberrypi kernel: [161445.973193] hub 1-1.1:1.0: 4 ports detected
Nov 2 18:31:03 raspberrypi kernel: [161446.391733] usb 1-1.1.1: new high-speed USB device number 24 using xhci_hcd
Nov 2 18:31:03 raspberrypi kernel: [161446.622085] usb 1-1.1.1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11
Nov 2 18:31:03 raspberrypi kernel: [161446.622102] usb 1-1.1.1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Nov 2 18:31:03 raspberrypi kernel: [161446.622116] usb 1-1.1.1: Product: USB 2.0 Hub
Nov 2 18:31:03 raspberrypi kernel: [161446.623648] hub 1-1.1.1:1.0: USB hub found
Nov 2 18:31:03 raspberrypi kernel: [161446.623764] hub 1-1.1.1:1.0: 4 ports detected
Nov 2 18:31:04 raspberrypi kernel: [161446.821691] usb 1-1.1.2: new full-speed USB device number 25 using xhci_hcd
Nov 2 18:31:04 raspberrypi kernel: [161447.067858] usb 1-1.1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
Nov 2 18:31:04 raspberrypi kernel: [161447.067877] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 2 18:31:04 raspberrypi kernel: [161447.067894] usb 1-1.1.2: Product: FT232R USB UART
Nov 2 18:31:04 raspberrypi kernel: [161447.067910] usb 1-1.1.2: Manufacturer: FTDI
Nov 2 18:31:04 raspberrypi kernel: [161447.067925] usb 1-1.1.2: SerialNumber: AI04NS58
Nov 2 18:31:04 raspberrypi kernel: [161447.074564] ftdi_sio 1-1.1.2:1.0: FTDI USB Serial Device converter detected
Nov 2 18:31:04 raspberrypi kernel: [161447.074727] usb 1-1.1.2: Detected FT232RL
Nov 2 18:31:04 raspberrypi kernel: [161447.078831] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB0
Nov 2 18:31:04 raspberrypi kernel: [161447.251638] usb 1-1.1.1.4: new full-speed USB device number 26 using xhci_hcd
Nov 2 18:31:04 raspberrypi kernel: [161447.492144] usb 1-1.1.1.4: New USB device found, idVendor=03eb, idProduct=204b, bcdDevice= 0.00
Nov 2 18:31:04 raspberrypi kernel: [161447.492152] usb 1-1.1.1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Nov 2 18:31:04 raspberrypi kernel: [161447.492159] usb 1-1.1.1.4: Product: CUL868
Nov 2 18:31:04 raspberrypi kernel: [161447.492166] usb 1-1.1.1.4: Manufacturer: busware.de
Nov 2 18:31:04 raspberrypi kernel: [161447.494834] cdc_acm 1-1.1.1.4:1.0: ttyACM0: USB ACM device
Nov 2 18:31:05 raspberrypi kernel: [161447.681633] usb 1-1.1.3: new full-speed USB device number 27 using xhci_hcd
Nov 2 18:31:05 raspberrypi kernel: [161447.927872] usb 1-1.1.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
Nov 2 18:31:05 raspberrypi kernel: [161447.927885] usb 1-1.1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Nov 2 18:31:05 raspberrypi kernel: [161447.927892] usb 1-1.1.3: Product: FT232R USB UART
Nov 2 18:31:05 raspberrypi kernel: [161447.927899] usb 1-1.1.3: Manufacturer: FTDI
Nov 2 18:31:05 raspberrypi kernel: [161447.927905] usb 1-1.1.3: SerialNumber: AL01MYK7
Nov 2 18:31:05 raspberrypi kernel: [161447.934544] ftdi_sio 1-1.1.3:1.0: FTDI USB Serial Device converter detected
Nov 2 18:31:05 raspberrypi kernel: [161447.934682] usb 1-1.1.3: Detected FT232RL
Nov 2 18:31:05 raspberrypi kernel: [161447.938807] usb 1-1.1.3: FTDI USB Serial Device converter now attached to ttyUSB1
Gruss
Adrian
Bei mir läuft der am Raspi4
https://www.amazon.de/dp/B01K7RR3W8/ref=cm_sw_r_cp_apa_i_F3fOFbXBFJPVK?_encoding=UTF8&psc=1 (https://www.amazon.de/dp/B01K7RR3W8/ref=cm_sw_r_cp_apa_i_F3fOFbXBFJPVK?_encoding=UTF8&psc=1)
Bis denn
SouzA
Aso
Mit Jeelink, EnOcean und Homematic-Dongle...
Zitat von: adrian am 02 November 2020, 20:05:58
Die USB-Jeelinks sind zu breit und dick, die passen nicht alle drei an die USB Ports am Raspi.
Wollte durch die Verwendung eines Hubs den Raspi stromtechnisch entlasten.
Da hätte ich eine Rückfrage
Welche USB Hubs sind kompatibel?
Ich meinte auch nicht alle devices umzustecken, sondern erstmal nur einen, damit sich zeigt, ob es die devices sind oder der hub. (auch genannt Fehler eingrenzen). Zum umstecken gibt es auch USB-Verlängerungen mit USB-A Buchse und Stecker...
Aus dem Log sieht es für mich so aus, als ob der Hub (usb 1-1.1) Probleme macht und "disconnected" (wird ?) und damit natürlich alle daran angeschlossenen devices. Ich bin aber kein kernel log experte.
Also würde es vermutlich immer noch Sinn machen einen Teil der Devices direkt am raspberry anzuschliessen um zu prüfen, ob das das Problem löst - zumindest für den Device der umgehängt wird.
Es kann auch sein, das EIN Gerät ein Problem auf dem USB-Bus erzeugt. Hatte so etwas mal ... das stand aber auch was von "USB reboot" o.Ä. im Log
Den Lacrosse-Jeelink habe ich direkt an den Raspi angeschlossen und mit Serial/by-id definiert, und siehe da, dieser taucht in dem fhem.log nicht mehr auf, nur noch der PCA-Jeelink.
Da hat der USB-Hub wohl nen Schuss.
Hab auf der Seite https://elinux.org/RPi_Powered_USB_Hubs (https://elinux.org/RPi_Powered_USB_Hubs) geschaut, welcher Hub unterstützt wird, bzw. kompatibel ist. Da hatte ich auch meinen ersten her, von Ultron den UHN710.
Werde mir einen neuen Hub gönnen, gibts Vorschläge, welchen Ihr empfehlen könnt?
ich schwanke zwischen dem
LogiLink UA0085 USB 2.0 Hub, 4-Port with PSU 5 V, 2 A
D-Link DUB-H7/B
Ist eine hohe Amperangabe besser? Benötigt man Backpower, der Raspi4 hat eh sein eigenes Netzteil.
danke und verregnete Grüße vom Bodensee
Zitat von: adrian am 02 November 2020, 20:05:58
Die USB-Jeelinks sind zu breit und dick, die passen nicht alle drei an die USB Ports am Raspi.
Tipp : kurze USB Verlängerung :)
Mit ner Verlängerung würde ich aber den Strom vom Raspi nutzen, und bei 3 USB Devices ist das ne unnötige Belastung. Daher die Idee mit dem aktiven Hub.
Zitat von: adrian am 04 November 2020, 17:55:50
bei 3 USB Devices ist das ne unnötige Belastung.
ah ja ... ich habe bei meinen beiden alle 4 Ports mit SSD , CULs , JeeLinks usw. vollgesteckt :)
Hallo zusammen,
vor ein paar Jahren hat der User HCS bei der Antwort #619 geschrieben, dass der Jeelink auch im Relay Modus in einer USB Adapter betrieben werden kann.
Wie muß ich denn diesen Relay-Jeelink definieren? muß der zuerst an den Raspi dran um ihn mit /DEV/Serial zu definieren und hänge diesen dann ab? ansonsten wäre die Frage wie der Jeelink gefunden werden kann ohne eine serial-ID oder Path, wenn er nicht am Raspi hängt.
danke und Gruß
Adrian
Zitat von: adrian am 06 Januar 2021, 18:21:40
Hallo zusammen,
vor ein paar Jahren hat der User HCS bei der Antwort #619 geschrieben, dass der Jeelink auch im Relay Modus in einer USB Adapter betrieben werden kann.
Wie muß ich denn diesen Relay-Jeelink definieren? muß der zuerst an den Raspi dran um ihn mit /DEV/Serial zu definieren und hänge diesen dann ab? ansonsten wäre die Frage wie der Jeelink gefunden werden kann ohne eine serial-ID oder Path, wenn er nicht am Raspi hängt.
danke und Gruß
Adrian
Die Beschreibung ist im fhemwiki:
https://wiki.fhem.de/wiki/JeeLink#Relay-Betrieb (https://wiki.fhem.de/wiki/JeeLink#Relay-Betrieb)
Zitat von: adrian am 06 Januar 2021, 18:21:40
Hallo zusammen,
vor ein paar Jahren hat der User HCS bei der Antwort #619 geschrieben, dass der Jeelink auch im Relay Modus in einer USB Adapter betrieben werden kann.
Wie muß ich denn diesen Relay-Jeelink definieren? muß der zuerst an den Raspi dran um ihn mit /DEV/Serial zu definieren und hänge diesen dann ab? ansonsten wäre die Frage wie der Jeelink gefunden werden kann ohne eine serial-ID oder Path, wenn er nicht am Raspi hängt.
danke und Gruß
Adrian
Und hier:
https://forum.fhem.de/index.php/topic,14786.msg165153.html#msg165153
Den Blog kenn ich auch, danke dennoch.
Aber konkret wie der define aussieht finde ich auch hier nicht.
Weiterhin habe ich bei moneyblog gelesen, dass es einen separaten Sketch für den Relaybetrieb gibt. Leider gibts den nach nun 5 Jahren nicht mehr.
Zitat von: adrian am 07 Januar 2021, 08:20:05
Aber konkret wie der define aussieht finde ich auch hier nicht.
Siehe meinen Post oben:
Zitat#define RELAY 1 // If 1 all received packets will be retransmitted
Sorry, ich steh aufm Schlauch. Ich muss das Gerät doch erstmal anlegen und das tue ich bei einem normalen jeelink mit "define myjeelink JEELINK /dev/ttyUSBx@57600", den ich dann flashe.
Wenn ich "#define RELAY 1" verwende passiert nichts. "1" ist ja auch kein Modul.
Gibts keine Schritt für Schritt Anleitung?
Zitat von: adrian am 07 Januar 2021, 12:27:23
Sorry, ich steh aufm Schlauch. Ich muss das Gerät doch erstmal anlegen und das tue ich bei einem normalen jeelink mit "define myjeelink JEELINK /dev/ttyUSBx@57600", den ich dann flashe.
Wenn ich "#define RELAY 1" verwende passiert nichts. "1" ist ja auch kein Modul.
Gibts keine Schritt für Schritt Anleitung?
Es geht darum den Code für den Jeelink neu zu ersetzen -> im Wiki artikel steht sketch für den Arduino-Code des Jeelinks.
Als muss der #define in dem Quellcode für den entsprechenden Jeelink code (links finden sich auch im fhemwiki-Artikel)
Dazu brauchst Du auch die entsprechende Umgebung (Arduino IDE) - das würde jetzt aber vermutlich die Länge eines Forumsbeitrages sprengen und passt hier eigentlich auch nicht unbedingt her und entsprechende Anleitungen sind auch wohl bereits verfügbar
Ist aber an sich relativ einfach - erfordert nur etwas googlen und einen Rechner auf dem man das durchführen kann (ein raspberry reciht bereits, kann aber auch ein PC oder so sein).
Hoffe das hilft etwas mit der Aufklärung - bei konkreten Fragen können wir auch
Zitat von: adrian am 07 Januar 2021, 12:27:23
Sorry, ich steh aufm Schlauch.
Dann tritt einen Schritt zur Seite und mach dies:
- den Quellcode hier runterladen: https://svn.fhem.de/trac/export/23489/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip
- den Inhalt vom ZIP in ein Verzeichnis mit dem Name LaCrosseITPlusReader10 legen
- In der LaCrosseITPlusReader10.ino die Zeile
bool RELAY = 0;
ändern in
bool RELAY = 1;
- Die Arduino IDE hier runterladen und installieren: https://www.arduino.cc/en/software
- Den geänderten Quellcode damit compilieren und auf den JeeLink hochladen
Zitat von: HCS am 08 Januar 2021, 11:49:08
- den geänderten Quellcode damit compilieren und auf den JeeLink hochladen
Gruß Peter
Zitat von: PeMue am 08 Januar 2021, 12:49:54
Gruß Peter
Wirst lachen, aber als ich fertig war mit Beitrag tippen dachte ich: "hätte es schneller compiliert als geschrieben gehabt" ;D
Das ist wirklich ein full service forum hier 8)
Guten Abend miteinander :-)
Ein Super Support Service hier im Forum. Für die Profis mögen die Schlagwörter im Wiki einleuchtend gewesen sein. Ich konnte die Verwendung der Arduino IDE nicht daraus herauslesen.
Euch allen, vielen Dank für die Anleitung, jetzt ist der Jeelink mit dem Relay-Sketch geflasht - siehe Bild. :-)
Tolles Tool dieses Arduino IDE.
Der Relay-Jeelink blinkt nun kräftig vor sich hin. Reicht es wie HCS geschrieben hat den über einen USB-Ladestecker laufen zu lassen, oder muß ich den noch im FHEM irgendwie ansprechen. Hab zwar mit set myjeelink LaCrossePairForSec 60 versucht ihn erkennen zu lassen, bekomme aber kein weiteres Gerät angzeigt. ich hätte halt gern die blinkende LED noch deaktivert.
Sieht man im Eventmonitor oder Log, dass der Relay-Jeelink auch etwas tut, bzw. was und welche Lacrosse Sensoren er weitergleitet hat?
danke und schönen Abend Euch
Adrian
Zitat von: adrian am 08 Januar 2021, 18:30:54
Guten Abend miteinander :-)
Guten Abend
Zitat von: adrian am 08 Januar 2021, 18:30:54
Euch allen, vielen Dank für die Anleitung, jetzt ist der Jeelink mit dem Relay-Sketch geflasht - siehe Bild. :-)
Glückwunsch
Zitat von: adrian am 08 Januar 2021, 18:30:54
Reicht es wie HCS geschrieben hat den über einen USB-Ladestecker laufen zu lassen, oder muß ich den noch im FHEM irgendwie ansprechen.
Es gibt nichts weiter zu tun als nur mit Strom zu versorgen.
Zitat von: adrian am 08 Januar 2021, 18:30:54
Hab zwar mit set myjeelink LaCrossePairForSec 60 versucht ihn erkennen zu lassen, bekomme aber kein weiteres Gerät angzeigt.
Der kann nicht als Gerät in FHEM auftauchen.
Zitat von: adrian am 08 Januar 2021, 18:30:54
ich hätte halt gern die blinkende LED noch deaktivert.
#define ENABLE_ACTIVITY_LED 1 // <n>a set to 0 if the blue LED bothers1 in 0 ändern und nochmal compilieren und flashen.
Zitat von: adrian am 08 Januar 2021, 18:30:54
Sieht man im Eventmonitor oder Log, dass der Relay-Jeelink auch etwas tut, bzw. was und welche Lacrosse Sensoren er weitergleitet hat?
Nein. Man merkt es nur da dran, dass man Sensoren empfängt, die man ohne nicht empfangen hat.
Zitat von: adrian am 08 Januar 2021, 18:30:54
danke und schönen Abend Euch
Gerne, ebenso.
Jetzt suchen wir nur noch ein*e Freiwillige*n, der*die*das es ins wiki übernimmt, damit es für alle Zeit erklärt ist :)
Zitat von: HCS am 08 Januar 2021, 20:32:54
Jetzt suchen wir nur noch ein*e Freiwillige*n, der*die*das es ins wiki übernimmt, damit es für alle Zeit erklärt ist :)
erledigt (https://wiki.fhem.de/wiki/JeeLink#Relay-Betrieb)
Hallo zusammen,
ich habe zwei Nano Jeelink Clone, einen mit Level Shifter und einen ohne, beide (nach einander getestet) funktionieren super am FHEM Raspi.
Alle Sensoren werden korrekt erkannt und eingebunden...
Nun habe ich zur Reichweiten Erhöhung einen mit der Arduino IDE als Relay geflasht.
Den Abstand eines Sensors soweit vom FHEM Raspi erhöht bis dieser ihn nicht mehr empfangen hat.
Nun JeeLink Relay dazwischen.... jedoch bekommt FHEM die Sensordaten vom JeeLink Relay nicht.
Die Arduino IDE sagt das die Daten des fehlenden Sensors Relayed wurden.
Habe folgende LaCrosse-Versionen getestet:
LaCrosseITPlusReader 10.0h / 10.1a / 10.1b / 10.1q / 10.1s / 10.1t und "11.1 Joerg"
alle als Relay im Toggle Modus und ohne t30~7
die Daten werden immer empfangen aber nicht korrekt weiter gegeben.
Was mache ich falsch ?
@adrian
Funktioniert den "Relay" ?
Hier:
https://forum.fhem.de/index.php?topic=14786.2235 (https://forum.fhem.de/index.php?topic=14786.2235)
wird beschrieben das ein Relay Jeelink mit der Version 10b funktioniert.
Diese Version ist jedoch nicht mehr downloadbar.
Wer kann mir weiter helfen.
Danke im vorraus
Hallo Leusel,
der origianle Jeelink hat einen "Garagen-LaCrosse-Sensor" sehr sporadisch bei mir erkannt. Jetzt mit dem Relay bekomm ich immer Werte in Fhem angezeigt ohne größeren Zeitverzug, daher würde ich sagen JA, es funktioniert. Da man aber leider nicht auf den Relay-Jeelink zugreifen kann, ist schwer zu sagen ob er tatsächlich arbeitet. Ich muß der Weiterleitung jetzt vertrauen, dass die zeitnahe Übermittlung des Garagensensors jetzt durch den Relay sicher gestellt ist.
Ich habe die 10.1s Version vom User HCS verwendet.
einfach die Parameter anpassen für Relay und ggf. für die LED und hochladen. evtl. kannst die LED noch aktiv lassen um zu sehen, dass der Jeelink was tut.
Sorry, mehr kann ich dazu auch nicht helfen.
dennoch viel Erfolg.
Adrian
Hallo Adrian,
habe die 10.1s.zip noch einmal "frisch" entpackt, in den Arduino-libraryordner geschoben und den Nano mit der Relay Funktion neu geflasht.
Leider ohne "Relay" funktionalität
auch verschiedenste Einstellungen führten nicht zum Erfolg.
Die Daten werden empfangen und "relayed", doch am FHEM kommt nichts an.
Danke für deine Info
Gruß Leusel
Hier mein NANO Jeelink Eigenbau:
Hallo zusammen,
als ich meine Frage zu JeeLink - LaCrosse als eigenen Post erstellte, wusste ich noch nicht, dass es anscheinend diesen langen Thread genau zu dieser Konstellation gibt, daher zur Vermeidung von Doppelposts hier der Link: https://forum.fhem.de/index.php/topic,122283.0.html
Ich bin seitdem nicht weitergekommen, wobei ich nicht weiß, ob es daran liegt, dass ich die genau Frequenz im 868er-Bereich nicht kenne oder ob die WH-65A-Version des Sensors, im Gegensatz offensichtlich zur WH-65B-Version, mit der es zu funktionieren scheint (https://forum.fhem.de/index.php/topic,93280.msg971758.html#msg971758) schlicht nicht empfangen werden kann.
Ich habe versucht, den nRFMon-Sketch auf den Nano-/JeeLink-Klon zu flashen, aber nichts außer Fehlermeldungen.
Im Thread habe ich irgendwo gelesen, dass mal über die Integration einer Art von Frequenz-Scanners nachgedacht wurde. Scheint es aber (noch) nicht zu geben.
Daher meine Frage: Könnte man das mit einem Notify- bzw. DOIF mal über Nacht abscannen lassen?
Ich meine grob gesprochen so etwas wie
$frequenz =860480
while $frequenz < 879515
set JeeLinkLaCrosse initCommands $Frequenzf v
set JeeLinkLaCrosse reset
set JeeLinkLaCrosse LaCrossePairForSec 60
sleep 65
$frequenz = $frequenz + 5
Wenn dann die korrekte Frequenz dabei wäre, müsste ja bei aktivem autocreate ein neues fhem-Device angelegt werden, da der Sensor nicht extra in einen Kopplungsmodus gesetzt werden müsste, sondern anhand der ausgesendeten Daten erkannt wird. =der verstehe ich da etwas falsch?
Wäre super, wenn Ihr mir da helfen könntet. Bin auch gern bereit, das im Erfolgsfall im Wiki zu ergänzen.
Viele Grüße
Martin
Antwort hier https://forum.fhem.de/index.php/topic,122283.0.html
pejonp
@Leusel
ab einer Version von LaCrosseITPlusReader wurde die Relay-Funktion glaube ich deaktiviert. Frag mal beim Entwickler nach.
pejonp
Hallo zusammen,
bin vom NANO-CUL Projekt auf das LaCrosseGateway umgestiegen.
Nutze nun zwei ESP8266 Node-MCU mit Funkmodul HOPERF RFM69HW.
Anleitung aus dem WIKI: https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x)
Leider sind nach ca. 20min. die Funkmodule "eingeschlafen" und haben nichts mehr weitergeleitet,
danach habe ich in dem Source-Code einen automatischen RESET alle 10min. eingefügt.
Seither laufen die ESP8266 schon Wochen problemlos....
Vielen Dank an alle hier im Forum... eine wirklich starke Community ;)
Besonderen dank an HCS und alle Entwickler die hier ausgezeichnete Arbeit leisten.
Gruß Leusel ;D
Hier noch die Änderung im Sketch:
nach void loop(void) {
das hier eingefügt:
if (millis()>=60000*10){ ESP.restart(); } // Reset nach 10 min
Falls jemand das gleiche Problem hat.
Gruß Leusel
Hallo,
liest hier jemand mit der einen TX38IT hat?
https://forum.fhem.de/index.php/topic,43672.0.html
@HCS: hast Du Deinen TX38IT noch?
Gruß Ralf
Zitat von: Ralf9 am 31 August 2021, 08:18:55
@HCS: hast Du Deinen TX38IT noch?
Nein, ist gestorben und wurde somit Teilnehmer beim Elektroschrott :-(
Hallo Zusammen,
nach dem Upgrade von Raspbian Buster auf Bullseye hängt sich mein Jee Link nach kurzer Zeit auf (ca. 20 min.):
2021.10.15 08:00:38 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)
2021.10.15 08:00:43 3: Setting myJeeLink serial parameters to 57600,8,N,1
2021.10.15 08:00:44 1: /dev/ttyUSB0 reappeared (myJeeLink)
2021.10.15 08:00:45 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)
2021.10.15 08:00:50 3: Setting myJeeLink serial parameters to 57600,8,N,1
2021.10.15 08:00:50 1: /dev/ttyUSB0 disconnected, waiting to reappear (myJeeLink)
Löschen und neues Einbinden (auch über by-id) hat nichts gebracht.
Bevor ich mich in die Fehlersuche weiter vertiefe, kurze Frage: Hat jemand Raspbian Bullseye + Jee Link erfolgreich in Betrieb?
Hallo zusammen,
ich habe gestern mein FHEM von Jessie auf Bullseye umgezogen (Neuinstallation und FHEM Verzeichnis kopiert). Es läuft auch alles bis auf meinen JeeLink. Die Hardware (Intel NUC NUC5CPYH) ist die selbe geblieben und der Stick steckt auch noch im selben physischen USB-Port. Der Jeelink blink munter vor sich hin und wird per lsusbgefunden:
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Ich habe per mknod /dev/ttyUSB0 c 188 0 das Device angelegt und mir ist klar, dass ich den USB-Port im FHEM Device anpassen muss. Allerdings erhalte ich beim Ausführen des ls -l /dev/serial/by-id per sudo oder auch direkt als root die Fehlermeldung:
ls: Zugriff auf '/dev/serial/by-id' nicht möglich: Datei oder Verzeichnis nicht gefunden
Ein lsusb -v zeigt mir zu dem device foglendes an:
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Couldn't open device, some information will be missing
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0403 Future Technology Devices International, Ltd
idProduct 0x6001 FT232 Serial (UART) IC
bcdDevice 6.00
iManufacturer 1 FTDI
iProduct 2 FT232R USB UART
iSerial 3 AI03DG43
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0020
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 90mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Hat jemand eine Idee warum das ls -l /dev/serial/by-id nicht funktioniert?
Viele Grüße und frohe Weihnachten!
Slanesh
SuFu benutzt?
https://forum.fhem.de/index.php?topic=108467.0 (https://forum.fhem.de/index.php?topic=108467.0)
Hallo Wernieman,
danke für deine Antwort. Ja, ich hatte tatsächlich schon einige Stunden mit Suchen verbracht und war auch über diesen Thread gestolpert. Ich nehme an, dass du dich auf diesen Teil hier beziehst:
Zitatsudo umount /boot
sudo mount /dev/mmcblk0p1 /boot
sudo apt install --reinstall raspberrypi-bootloader raspberrypi-kernel
sudo reboot
Das hatte ich gelesen, aber aus verschiedenen Gründen nicht weiter verfolgt:
- In dem Post ging es um Buster
- Es ging um einen Raspberry (arm)
- Mir war unklar welches Device mmcblk0p1 ist
- Ich dachte, dass der Raspberry Bootloader und Kernel nicht für mein System geeignet sind
Müsste ich statt mmcblk0p1 meine Boot-Partition angeben (also sda1)?
Wie müsste der Reinstall-Befehl für Bootloader (GRUB) und Kernel denn bei einem amd64 Bullseye lauten?
Danke & Gruß
Slanesh
Was ist es denn für ein System? Also HW?
Ein Intel NUC NUC5CPYH.
Hast Du mal geguckt, was in den Logfiles steht, wenn Du die Geräte aus/einsteckst?
Muß gestehen, das ich mit Bullseye noch nicht so viel gemacht habe, setze Privat eher auf Ubuntu-Server. Aber im Prinzip sollte es funktionieren .....
Hallo Wernieman,
Danke für die Hilfe zur Selbsthilfe, habe es wieder hinbekommen.
Ein dmesg | grep tty lieferte folgendes:
# Stick entfernt
[ 0.123140] printk: console [tty0] enabled
[ 4.819323] systemd[1]: Created slice system-getty.slice.
[ 5.992948] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 8.342932] usb 1-4: usbfs: interface 0 claimed by ftdi_sio while 'brltty' sets config #1
[ 8.346149] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
# Stick wieder gesteckt
[ 2307.107314] usb 1-4: FTDI USB Serial Device converter now attached to ttyUSB0
[ 2308.527380] usb 1-4: usbfs: interface 0 claimed by ftdi_sio while 'brltty' sets config #1
[ 2308.532457] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Habe das Paket brltty (wird benötigt für Braille Displays) per apt-get remove brltty entfernt. Danach lief alles wieder.
Nochmals Danke und frohe Weihnachten!
Slanesh
Ach soooo ..... der definiert es als Human Input und damit fliegt es aus dem Bereich "Serieller Schnittstelle" ... logisch...
Hallo in die Runde. Seit dem Batteriewechsel vom WH1080 device heute findet der JeeLink das Device nicht mehr. replaceBatteryForSec brachte keinen Erfolg, ein erneutes LaCrossePairForSec vom JeeLink brachte auch keine neue Adresse. Ist es irgendwie möglich die neue device Addr. rauszubekommen? Ein händisches eintragen von 00 bis FF ist mir etwas aufwändig :-)
Ja einfach mal die dispatch Nachricht posten (in der Form OK WS 140 3 4 64 94 0 80 8 202 0 0 0 0 0 , dies ist device 8C)
war bei mir jetzt auch die 8C :) :)
irgendwann war nach dem PairForSec das device dann da
P.S. wie wird die Dispatch Nachricht denn interpretiert?
ZitatP.S. wie wird die Dispatch Nachricht denn interpretiert?
siehe Anlage
Hat die WH1080 ein NewBattery- und LowBatteryFlag und werden diese im Device angezeigt?
Gruß Ralf
"NewBattery- und LowBatteryFlag" ist leider nicht vorhanden, ich bekomme immer battery OK, egal wieviel Spannung sie noch hat. Die Interpretation der gesendeten Daten habe ich vor Jahren (als ich die Wetterstation in fhem eingebunden habe) schon mal gesehen, ist aber lange her.
Internals:
CHANGED
DEF 8C
IODev JLLaCrosse
JLLaCrosse_MSGCNT 302
JLLaCrosse_RAWMSG OK WS 140 3 4 46 59 0 0 10 140 0 0 0 0 0
JLLaCrosse_TIME 2022-02-14 22:15:15
LASTInputDev JLLaCrosse
LaCrosse_lastRcv 2022-02-14 22:15:15
MSGCNT 302
NAME LaCrosse_9D
NR 1976
STATE T: 7 H: 59 D: -0.4
TYPE LaCrosse
addr 8C
battery_new 0
bufferedH 59
bufferedT 7
corr1 0
corr2 0
previousH 59
previousR 0
previousT 7
sensorType 3=WS1080
READINGS:
2022-02-14 22:15:15 battery ok
2022-02-14 22:15:15 dewpoint -0.4
2022-02-14 22:15:15 error 0
2022-02-14 22:15:15 humidity 59
2018-10-29 20:52:14 pressure 997
2022-02-14 22:15:15 rain 0
2022-02-14 22:08:03 state T: 7 H: 59 D: -0.4
2022-02-14 22:15:15 temperature 7
2022-02-14 22:15:15 windDirectionDegree 270
2022-02-14 22:15:15 windDirectionText W
2022-02-14 22:15:15 windGust 0
2022-02-14 22:15:15 windSpeed 0
Attributes:
IODev JLLaCrosse
alias WS1080
doDewpoint 1
event-min-interval .*:300
event-on-change-reading .*
room LaCrosse
Weißt Du ob die LowBattery nur nicht in fhem angezeigt wird oder ob die WS1080 es gar nicht sendet?
Ich denke das die WS1080 es nicht sendet. Ich hab noch einen zweiten Transmitter (wird mal der Nachfolger) der ist mit Signalduino empfangbar und der sendet permanent Batt low.
Internals:
CODE WH1080
DEF WH1080
FUUID 5fa6e1ea-f33f-cf17-71e0-9125075d3106095f
LASTInputDev SignalDuino_1
MODEL WH1080
MSGCNT 5264
NAME WH1080
NR 21
STATE T: 20.8 H: 45 Ws:0.0 Wg:0.0 m/s Wd: N R: 0
SignalDuino_1_DMSG P9#FF54A4C05A000000010022
SignalDuino_1_MSGCNT 5264
SignalDuino_1_Protocol_ID 9
SignalDuino_1_RAWMSG MU;P0=-224;P1=479;P2=-993;P3=1449;P4=-10440;D=0121212121212121232123212321232321232123232123232121232323232323232123212123212323232323232323232323232323232323232323232323232323232323232323212323232323232323232321232323214;CP=3;R=0;
SignalDuino_1_RSSI -74
SignalDuino_1_TIME 2022-02-14 22:28:35
TYPE SD_WS09
bitMSG
lastMSG FFAA52602D000000008011
lastReceive 1644874115.69839
READINGS:
2022-02-14 22:28:35 battery low
2022-02-14 22:28:35 batteryState low
2022-02-14 22:28:35 humidity 45
2022-02-14 22:28:35 id 165
2022-02-14 22:28:35 rain 0
2022-02-14 22:28:35 rain_total 9.6
2022-02-14 22:28:35 state T: 20.8 H: 45 Ws:0.0 Wg:0.0 m/s Wd: N R: 0
2022-02-14 22:28:35 temperature 20.8
2022-02-14 22:28:35 windDirection 0
2022-02-14 22:28:35 windDirectionAverage 0
2022-02-14 22:28:35 windDirectionDegree 0
2022-02-14 22:28:35 windDirectionText N
2022-02-14 22:28:35 windGust 0.0
2022-02-14 22:28:35 windGust_fts 0.0
2022-02-14 22:28:35 windGust_kmh 0.0
2022-02-14 22:28:35 windGust_kn 0.0
2022-02-14 22:28:35 windGust_mph 0.0
2022-02-14 22:28:35 windSpeed 0.0
2022-02-14 22:28:35 windSpeed_fts 0.0
2022-02-14 22:28:35 windSpeed_kmh 0.0
2022-02-14 22:28:35 windSpeed_kn 0.0
2022-02-14 22:28:35 windSpeed_mph 0.0
helper:
history:
ARRAY(0x55617a0aa5a8)
ARRAY(0x55617b064d80)
ARRAY(0x55617b2818c0)
ARRAY(0x55617b0484c8)
ARRAY(0x55617b073fe0)
ARRAY(0x55617b04ea40)
ARRAY(0x55617b04dfd0)
ARRAY(0x55617b0786a8)
ARRAY(0x55617b281dd0)
ARRAY(0x55617b0918a0)
ARRAY(0x55617b165480)
ARRAY(0x55617b0adb50)
ARRAY(0x55617b091f78)
Attributes:
event-min-interval .*:180
room SD_WS09
ZitatSignalduino empfangbar und der sendet permanent Batt low.
und Du bist sicher, daß die Batterien voll sind?
Die WH1080 sendet ASK/OOK und da sollte das Bat eigentlich mit gesendet werden.
Meine WH3080 hat das selbe Protokoll und da paßt das Bat
Batterien hab ich ja heute getauscht und dadurch die device Adresse verloren. Der zweite Sender (Signalduino) hat erst bei der Inbetriebnahme vor ca. 8 Wochen neue Batterien bekommen. Ich verwende keine 0815 Batterien sondern, wie bei meiner Arbeit Industriestandart.
P.S. die wh1080 hat ja heute vormittag auch noch in fhem Batt OK gemeldet nur auf dem Display der Wetterstation konnte man das Symbol für TX low Batt sehen und die Station hat dann auch keine Daten mehr empfangen
Zitatdie wh1080 hat ja heute vormittag auch noch in fhem Batt OK gemeldet nur auf dem Display der Wetterstation konnte man das Symbol für TX low Batt sehen und die Station hat dann auch keine Daten mehr empfangen
Du meinst damit wahrscheinlich die WS1080 (FSK Jeelik La Crosse), ich hab mal nach der Protokollbeschreibung gesucht und gefunden wo in der raw Nachricht das Bat mitgesendet wird. Es wurde bis jetzt nur noch nicht in die Jeelik/La Crosse Firmware eingebaut.
Ist die WS1080 bei Dir gut erreichbar? Ich habe die WS1080 (FSK) bei mir in das Signalduino Modul eingebaut und könnte noch HEX raw Nachrichten von einer leerer Batterie gebrauchen.
Der Jeelik / La Crosse müsste sich so konfigurenen lassen, daß auch die HEX raw Nachrichten ausgegeben werden
Die HEX raw Nachrichten sehen ungefähr so aus, ich habe es rot markiert wo die lowBat und evtl das NewBat drin sein müssten
A8 C0 58 5E 00 00 00 86 0A D8
"Du meinst damit wahrscheinlich die WS1080 (FSK Jeelik La Crosse)" ja, genau.
"Ist die WS1080 bei Dir gut erreichbar?" leider nicht, dass ist immer ein größeres Unterfangen da rann zu kommen und ich bin froh erst mal wieder 1 Jahr Ruhe zu haben (bis zum nächsten Batteriewechsel). Leider habe ich diese Woche ziemlich viel um die Ohren aber vlt. kann ich in der nächsten Woche mal den TX vom Signalduino mit fast leeren Batterien bestücken.
Vielleicht findet sich jemand anders mit einer WS1080 die besser ereichbar ist.
Ohne das newBatteryFlag muß nach einem Batterie wechsel beachtet werden, daß beim "set replaceBatteryForSec" ein ignore_battery hinten angehängt wird
Hallo zusammen,
ich hoffe, hier ist mein Problem besser aufgehoben als in meinem alten LaCrosse-Thread (https://forum.fhem.de/index.php/topic,122283.msg1208402.html#msg1208402): wenn ich mein fhem aus dem letzten Spätsommer remote im Ferienhäusl per "update all" auf den neuesten Stand bringe, funktioniert danach mein Jeelink/LaCrosse nicht mehr, d.h. es werden keine Readings aktualisiert. Das Log füllt sich damit :
2022.03.17 16:03:49 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 4 0 20 0 30 0 0 0 246 104, help me!
2022.03.17 16:04:05 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 0 220 0 18 0 20 0 0 0 253 22, help me!
2022.03.17 16:04:21 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 134 0 32 0 60 0 0 0 253 22, help me!
2022.03.17 16:04:37 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 234 0 33 0 50 0 0 0 184 16, help me!
2022.03.17 16:04:53 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 0 80 0 12 0 20 0 0 0 111 104, help me!
2022.03.17 16:05:09 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 14 0 12 0 20 0 0 0 96 64, help me!
2022.03.17 16:05:25 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 204 0 10 0 20 0 0 0 118 12, help me!
2022.03.17 16:05:41 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 224 0 17 0 20 0 0 0 98 172, help me!
2022.03.17 16:05:57 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 114 0 18 0 30 0 0 0 64 46, help me!
2022.03.17 16:06:13 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 13 182 0 12 0 20 0 0 0 51 114, help me!
2022.03.17 16:06:29 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 34 0 15 0 20 0 0 0 53 72, help me!
2022.03.17 16:06:45 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 12 88 0 42 0 70 0 0 0 75 20, help me!
2022.03.17 16:07:01 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 2 168 0 46 0 80 0 0 0 92 8, help me!
2022.03.17 16:07:17 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 2 8 0 41 0 50 0 0 0 104 186, help me!
2022.03.17 16:07:33 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 84 0 26 0 30 0 0 0 96 64, help me!
2022.03.17 16:07:49 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 14 0 11 0 20 0 0 0 85 90, help me!
2022.03.17 16:08:05 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 4 0 5 0 10 0 0 0 72 168, help me!
2022.03.17 16:08:21 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 7 148 0 15 0 50 0 0 0 70 210, help me!
2022.03.17 16:08:37 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 64 0 33 0 50 0 0 0 65 250, help me!
2022.03.17 16:08:53 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 0 20 0 16 0 20 0 0 0 76 224, help me!
2022.03.17 16:09:09 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 1 74 0 21 0 30 0 0 0 89 156, help me!
2022.03.17 16:09:25 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 2 98 0 32 0 50 0 0 0 118 12, help me!
2022.03.17 16:09:41 3: myJeeLink: Unknown code OK WS 130 6 4 101 93 82 38 2 8 0 32 0 40 0 0 0 119 226, help me!
Wenn ich die Daten aus dem restoreDir zurück kopiere geht es wieder.
Dabei werden beim Update die 36_JeeLink.pm und die 36_LaCrosse.pm nicht upgedated, erstere, weil es wohl nichts Neueres gibt, letztere weil "skipping FHEM/36_LaCrosse.pm, matches exclude_from_update", da eine angepasste Version, s.u..
Meine Konstellation ist wie folgt:
- JeeLink (auf Arduino basierend),
- Sketch von Andreas (https://forum.fhem.de/index.php/topic,93280.msg971758.html#msg971758) (der u.a. die WH65B integriert hat) geflashed, der auf der Vorarbeit von Jörg "pejonp" basiert
- initCommands 868345f v gesetzt
- das modifizierte 36_LaCrosse.pm von Andreas (s. obigen Link)
Mit dem aktuellen Standard-36_LaCrosse.pm geht es auch nicht.
Bevor ich nun Datei für Datei einzeln aus dem restoreDir zurück ins Live kopiere, um zu sehen, ob es wieder geht: Könnt Ihr mir einen Tipp geben, was bei einem fhem Update noch die Funktion von Jeelink/LaCrosse beeinflussen könnte?
Vielen Dank & viele Grüße
Martin
ZitatDabei werden beim Update die 36_JeeLink.pm und die 36_LaCrosse.pm nicht upgedated, erstere, weil es wohl nichts Neueres gibt, letztere weil "skipping FHEM/36_LaCrosse.pm, matches exclude_from_update", da eine angepasste Version, s.u..
Evtl liegt es daran, bei der "$hash->{Match}" regex war ein Fehler
https://svn.fhem.de/trac/changeset/25537/trunk/fhem/FHEM/36_LaCrosse.pm
Könnte sein, aber 36_LaCrosse.pm soll ja so oder so nicht upgedated werden, da das Modul in der Standardversion die WH65B nicht unterstützt.
Habe es jetzt mal mit dem stufenweisen Zurückkopieren versucht.
- Wenn ich alles aus restoreDir zurückkopiere außer fhem.cfg und fhem.pl, geht Jeelink/LaCrosse nach Neustart immer noch nicht.
- Wenn ich alles incl. fhem.cfg und fhem.pl aus restoreDir zurückkopiere, geht es nach Neustart wieder völlig normal.
Kann ich daraus schließen, dass sich in fhem.pl etwas geändert hat, was Auswirkungen auf Jeelink/LaCrosse hat - und wenn ja: Wie finde ich heraus, was das ist?
Bin ratlos.
Grüße
Martin
ZitatKann ich daraus schließen, dass sich in fhem.pl etwas geändert hat, was Auswirkungen auf Jeelink/LaCrosse hat
Ja, in der 36_LaCrosse.pm war seither die "$hash->{Match}" regex fehlerhaft, vor der Änderung in der fhem.pl hat es trotzdem funktioniert.
Wenn Du in der 36_LaCrosse.pm bei "$hash->{Match}..." das Leerzeichen vor "ok" entfernst sollte es wieder funktionieren
https://svn.fhem.de/trac/changeset/25537/trunk/fhem/FHEM/36_LaCrosse.pm
Ja, die Leerstelle war's, ganz herzlichen Dank. Dass ich da nicht gleich von selbst draufgekommen bin 8) 8) 8)
Hallo zusammen,
ich betreibe mit meinem Jeelink-Clone schon länger zwei TX29DTH-IT Sensoren ohne Probleme.
Nun will ich die seid langem rumliegende WS1600 an FHEM anbinden.
Ich bekomme sie aber leider nicht an meinen Jeelink angelernt. Bin wie folgt vorgegangen. Batterien an der Innenstation raus und am TX22raus. Dann in FHEM LaCrossePairForSec 120, anschliessend Batterie am TX22 wieder rein. FHEM findet da aber nichts neues. Auch im Verbose 5 Log sehe ich nichts unbekanntes...
Hier mal ein list von meinem Jeelink:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF /dev/ttyUSB0@57600
DeviceName /dev/ttyUSB0@57600
FD 17
FUUID 62226bac-f33f-487e-4e97-6f80a320f98dfbd8
FVERSION 36_JeeLink.pm:0.147070/2017-07-13
NAME myJeeLink
NR 48
PARTIAL
RAWMSG OK 9 63 1 4 106 46
STATE initialized
TYPE JeeLink
initMessages
model LaCrosseITPlusReader.10.1s
myJeeLink_MSGCNT 412
myJeeLink_TIME 2022-03-25 20:38:07
settings (RFM69CW f:868300 r:8842)
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:
2022-03-25 20:38:08 state initialized
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
initCommands 4m 2r v
room Schnittstellen
verbose
Was meint ihr?
Hallo michisa86888,
habe auch eine WS1600 seit mehreren Jahren im Betrieb. Deine Einstellungen sehen eigentlich ganz gut aus.
Vielleicht bist du zu weit entfernt von der Wetterstation.
Hier ein List von meinem JeeLink:
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
DEF 192.168.178.106:23
DeviceName 192.168.178.106:23
FD 20
FUUID 5c463c12-f33f-51ca-bb54-1e6b4242cfea38d2
NAME myJeeLink
NR 242
PARTIAL
RAWMSG OK WS 36 1 4 7 255 1 247 255 255 255 255 255 255 4
STATE opened
TYPE JeeLink
myJeeLink_MSGCNT 9007
myJeeLink_TIME 2022-04-01 09:54:00
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:
2022-04-01 09:54:00 state opened
Attributes:
event-on-change-reading .*
flashCommand avrdude -p atmega328P -c arduino -P net:192.168.178.106:23 -D -U flash:w:/opt/fhem/FHEM/firmware/JeeLink_LaCrosse.hex 2>[LOGFILE]
initCommands 4m 2r v
room Büro,Culs,Garten,LaCrosse,Wetter
verbose 2
Ich bin relativ nahe an der Wetterstation und habe eine Serialbridge über ein ESP8266.
So sieht die Ausgabe auf der Console aus:
[LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:17241)]
[LaCrosseITPlusReader.10.1s (RFM12B f:868300 r:8842)]
OK WS 36 1 255 255 255 1 247 11 109 0 17 0 52 4
OK WS 36 1 255 255 255 1 247 12 78 0 23 255 255 4
OK WS 36 1 255 255 255 1 247 11 109 0 26 255 255 4
OK WS 36 1 255 255 89 1 247 12 78 0 29 255 255 4
Gruß rippi
Hallo zusammen,
Habe seit Jahren einen Jeelink mit dem pcaSerial.10.0i Sketch und 7 PCA301 Steckdosen erfolgreich im Betrieb.
Jetzt würde ich gerne über einen zweiten Jeelink die Reichweite mit dem Sketch LaCrosseITPlusReader10 und dem Relay = 1 Mode erweitern.
Das Flashen hat soweit funktioniert, aber eine verbesserung der Reichweite kann ich nicht feststellen.
Ausgabe des Orginal jeelinks mit pcaSerial.10.0i Sketch
[pcaSerial.10.0i]
Available commands:
..,.. s - send data packet
l - list devices
<n> a - turn activity LED on PB1 on or off
<n> c - config (0=fill, 1=load, 2=save, 3=erase)
<n> d - turn off device <n>
<n> e - turn on device <n>
<n> p - poll device <n>
<n> r - list recordings
<n> q - quiet mode (1=suppress TX and bad packets)
<n> v - version and configuration report
OK 24 7 4 1 156 75 0 0 0 0 0
OK 24 1 4 5 86 105 1 1 128 2 11
OK 24 2 4 5 60 249 0 0 0 0 59
OK 24 1 4 15 166 242 1 0 210 0 242
OK 24 7 4 2 116 86 1 0 154 0 165
OK 24 7 4 1 156 75 0 0 0 0 0
OK 24 1 4 5 86 105 1 1 128 2 11
OK 24 1 4 15 166 242 1 0 209 0 243
OK 24 7 4 2 116 86 1 0 154 0 165
OK 24 2 4 5 60 249 0 0 0 0 59
Und auszug aus dem LaCrosseITPlusReader10 und dem Relay = 1 Mode
[LaCrosseITPlusReader.10.1s (RFM69CW f:868300 r:17241)]
OK 9 0 1 4 60 71
OK 9 0 1 4 60 71
OK 9 0 1 4 59 71
OK 9 0 1 4 59 71
OK 9 0 1 4 59 71
Was kann hier falsch sein, oder geht der Relay Modus garnicht mit dem PCA301 Dosen?
Die Jeelinks haben unterschiedliche Radio Module RFM12B und RFM69CW - Kann das etwas damit zu tun haben?
Danke für euere Hilfe!