Hallo Moderatoren.
Es gibt bereits ein Thema mit dem Titel: "Problem Jeelink Lacrosse - State opened" dieser passt aber nicht zu meinem Problem. Deshalb habe ich ein neues Thema eröffnet. Falls einer der Moderatoren das für unglücklich hält, dann bitte zusammenfügen.
## ja, ich nutze die Sufu......
Hallo Forum.
Nachdem ich einen Cul nach dieser Anleitung nachgebaut habe, habe ich mich daran versucht, einen JeeLink nachzubauen.
http://blog.gummibaer-tech.de/cul-stick-868433-im-selbstbau/
Als Hardware habe ich einen chinesischen Arduino Nano und dieses Funkmodul.
http://www.ebay.de/itm/HopeRF-RFM12B-868S1-Transceiver-Sende-Emfangs-Modul-868MHz-/371256001938?hash=item5670950592
Als Firmware habe ich dir Firmware ./ fhem/firmware/JeeLink_LaCrosse.hex geflasht. (aktuell)
Dies hat auch fehlerfrei funktioniert. Danach habe ich alles nach Anleitung verkabelt und den JeeLink in Fhem angelegt.
define JeeLink868 JeeLink /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@57600
attr JeeLink868 flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>
attr JeeLink868 initCommands 30t 868280f v
( Status: Initialized)
Eingeschaltet und ....... :( kein Empfang.
Fhem: get RFMconfi und alle anderen get-Befehle funktionieren nicht / liefern kein Ergebnis.
Also x-mal die Verkabelung überprüft und Google befragt. Ergebniss, es gibt einige andere Anleitungen aber keine neuen Erkenntnisse.
Also alle Verbindungen vom Atmel zum Funk-Chip durchgemessen. // alles i.O und der Quarz schwingt mit 10 MHz.
Im Zweifel an meinen Fähigkeiten, meinen Kumpel gebeten nochmal alles zu Prüfen. // nein alles i.O
Ich habe so ein Bauchgefühl, daß das Funkmodul defekt ist. Aber wie überprüfe ich das?
Bzw. mache ich einen Denkfehler? Empfangen möchte ich übrigens die Temperatur von so einem Sensor.
http://tfa-dostmann.de/index.php?id=118 // ist IT+ 868 MHz
Dank und Gruß
beSmart
a. Leider verschweigst du was bei den Internals unter model aufgeführt ist - und da sollte was stehen spätestens nach set <name> raw v
b. bei deinem Init steht u.a 30t , aber kein m dazu ? was willst den toggeln ? im Zweifel setze 7m dazu
warum 868280f ? Ich musste bisher nie die Frequenz nachträglich anpassen.
c. lass mal fhem ganz links liegen und rede direkt seriell mit dem JL (putty , picocom , etc)
hm, da sind wie dann schon zu zweit. gleiche anleitung und gleiches ergebnis.
nur ist mr dabei aufgefallen, das man scheinbar auch den modus nicht ändern kann. z.b. von lacross auf fs20 oder HX2272.
selbst venn ich auf 600 sec beim pairing gehe, scheint es nicht angenommen zu werden.
updatestaus vom FHEM ist von grade eben, nur flashe ich nicht per hex (wie auch immer das geht), ich gehe per isp (Diamex AVR mkII)mit der arduino ide dran.
@BlackStone:was hast Du getan, dass die Frequenz 0 ist?
hm, eigendlich nur eingebunden, hab ich grad auch erst gesehen das die freq. auf 0 steht.
edit:/ habe ich evtl, die 868 mhz einstellung im sketch übersehen. ?
@beSmart: mit den 30.3155 hast Du Dir genau die problematischsten Sensoren rausgesucht. Meine Erfahrung damit: mit vielen RFM12 kritisch, mit RFM69 deutlich besser zu empfangen.
Einige Leute haben es tatsächlich mit der Änderung der Frequenz hinbekommen, aber ich glaube jeder mit einer anderen.
Auf alle Fälle laufen die mit 9.579 kbps. Somit wäre eine Initialisierung wie z.B.
0t 1r v
sinnvoll.
@BlackStone: wenn Du im Sketch nichts geändert hast, muss die Frequenz stimmen. Alle Defaults dort sind OK.
versuch mal
set myJeeLink raw 868300f
set myJeeLink raw v
Edit: musst natürlich den Namen von Deinem JeeLink Device nehmen
ich hab gerade versuch über die initCommands die freq. auf 868295f zu setzen. entsprechend dem Wiki .
lustigerweise ist die da auf 1 gesprungen. :o
mit raw 868300f hat er sie angenommen.
Geht bei mir:
model [LaCrosseITPlusReader.10.1p (RFM12B f:868295 t:20~7)]
hm, jetzt mach er es bei mir auch. denke mal ich muss bei mir chmod vom fhem verzeichnis mal prüfen. da hatte ich letztens schon mal spass mit.
ist es denn normal das ich raw v dennoch per hand eingeben muss ?
denn die nimmt er aus der initCmd scheinbar nicht und ich muss es per hand reinzimmern, damit er auf Initialized springt.
Zitat von: BlackStone am 27 August 2015, 22:21:41ist es denn normal das ich raw v dennoch per hand eingeben muss ?
denn die nimmt er aus der initCmd scheinbar nicht und ich muss es per hand reinzimmern, damit er auf Initialized springt.
Ist nicht normal.
Kann es sein, dass Deine Kommunikation über usb-1a86_USB2.0-Serial-if00-port0 nich so richtig gut funktioniert?
meine initCommands
3m 0r 20t 0M 2R 0T 868300f 220h 0a vSind allerdings für einen SuperJee. Das initialisiert immer.
Musst achtgeben, dass Du nicht zwei Leerzeichen oder sonstwas zwischen den einzelnen commands hast.
hab deine init mal eingetragen, mit gleichem ergebnis. also wieder auf meine zeileinitCommands
7m 30t 868295f v
nach raw v war die init aktiv, restart wieder wie gehabt.
und dann bin ich auf was interessantes gestolpert, ich habe den recivermode mal umgestellt erst auf hx2270, ergebnis die init lief durch, jedoch die frequenz ist auf 0 gesprungen, dann habe ich auf Fs20 gestellt frequens ist auf 0 gegangen, dann einfach nochmal lacross ausgewählt und ergebnis die freq. ist auch auf 0 gegangen. neustart und raw v. schon passte die init erstmal. dann habe ich testweise nochmal den lacross mode eingestellt, und die freq. stimmte weiterhin.
denke mal das sich da etwas verschluckt.
recivermode und so ziemlich der ganze Rest ist nicht für den LaCrosse sketch. Wenn man die verwendet, werden commands geschickt, die für einen anderen sketch sind und vom LaCrosse sketch falsch interpretiert werden.
nur raw und reset sind für den LaCrosse sketch
Kannst Du mal ein list myJeeLink posten?
Und bist Du sicher, dass er nicht initialisiert, oder Du nur mal nach dem Anstecken deinen Browser mit F5 refreshen musst, dass Du es siehst?
Zitat von: beSmart am 27 August 2015, 21:03:15
Fhem: get RFMconfi und alle anderen get-Befehle funktionieren nicht / liefern kein Ergebnis.
Gleiches Thema wie oben gerade, die sind alle nicht für den LaCrosse sketch
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
FD 24
NAME JLLaCross
NR 116
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
Readings:
2015-08-27 23:01:38 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 7m 30t 868295f v
verbose 2
einmal nach neustart.
und nach raw V
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
FD 24
NAME JLLaCross
NR 116
PARTIAL
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1o (RFM12B f:868295 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
Readings:
2015-08-27 23:01:38 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 7m 30t 868295f v
verbose 2
Zitat von: BlackStone am 27 August 2015, 23:05:55
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
FD 24
NAME JLLaCross
NR 116
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
Readings:
2015-08-27 23:01:38 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 7m 30t 868295f v
verbose 2
einmal nach neustart.
und nach raw V
Internals:
Clients :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A98FRHXD-if00-port0@57600
FD 24
NAME JLLaCross
NR 116
PARTIAL
STATE Initialized
TYPE JeeLink
model [LaCrosseITPlusReader.10.1o (RFM12B f:868295 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
Readings:
2015-08-27 23:01:38 state opened
Attributes:
flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
icon cul
initCommands 7m 30t 868295f v
verbose 2
Hast Du im sketch evtl. debug 1 gesetzt ?
Wie meldet sich denn der Sketch im arduino serial monitor ?
nein debug habe ich nicht gesetzt. der Sketch ist so wie er im git vorliegt.
und im Monitor kommt nur die Meldung.
[LaCrosseITPlusReader.10.1o (RFM12B f:868300 r:17241)]
Tante Edit:/ der Hinweis mit dem debug war ne Idee. hab den mal gesetzt, und den Monitor im Auge behalten.
und was soll ich sagen, es hageln Daten rein. ok, laufend falsche Daten (crc werte aber immerhin)
Mal so aus neugier, für welche Sketche sind die anderen Einstellungen?
Tante edit die 2:/ hab den debug wieder ausgestellt im Sketch, da ich gesehen habe, das dafür ein Parameter für den Monitor vorhanden ist.
Nach ein paar paar Parametern, die es etwas leserlicher machen kommen nun zumindest per Monitor Daten rein, die zeigen, das ein Empfang da ist.
009056 LaCrosse [114 40 94 94 110 ] CRC:WRONG
## CRC FAIL ##
No valid start
No valid Temperature: 106.40
009053 LevelSender [72 28 5E 5E 6E 1D ] CRC:WRONG
009052 EMT7110 [72 28 5E 5E 6E 1D F BE 2 9F DE 90 ] CRC:WRONG S:72 28 ID:5E5E V:129.00 mA:4030.00 W:5902.00 kWh:81.58 Con.:1 Pair:0 CRC:144
009053 TX38IT [114 40 94 94 ] CRC:WRONG
CustomSensor [72 28 5E 5E 6E 1D F BE 2 9F DE 90 F8 1B C5 3 9C 41 E8 F 1B C9 FC 7F A5 93 F0 F 80 82 C2 C8 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 8 F3 1 3 8 E9 67 BD 13 62 11 D7 11 D6 2A D3 1 3 2C 9B 0 D2 0 0 87 6 80 0 CC 3F D 0 3 ] CRC:WRONG
was ich definitiv sagen kann von mir ist da nur einer drunter.
jetzt frage ich mich nur warum fhem auf dem raspberry pi 2 da nichts reinbekommt.
Guten Morgen.
Den Sender hatte ich noch herumliegen. Das der schwierig ist einzubinden habe ich vorher nicht gewusst.
Welchen würdet ihr den empfehlen? So teuer sind die ja nicht.
Im Anhang noch 2 Screenshots.
Init mit 0t 1r v habe ich versucht. Es kommen keine Daten im Terminal.
Ich vermute, daß das Funkmodul defekt ist bzw. nicht mit dem Arduino kommuniziert, da bei " get RFMconfig" nichts passiert. Kann man das irgendwie testen?
Dank und Gruß
beSmart
Hallo,
ich habe auch schon einige RFM-Transceiver gesehen, entweder waren die ab Werk defekt oder wie auch immer funktionierten die nicht. Vielleicht nochmal die Lötstellen nachsehen, oder den RFM austauschen.
Ich habe jetzt den Thread nicht komplett durchgelesen, du hast den Jeelink-Clone direkt an der Arduino-Gui gehangen? Der sollte mit dem PCA 301 oder Lacrosse-Sketch auch schon Daten liefern, z. B. OK 1 3 2 2 3 4 usw.
Siehe Foto in meinem Blog:
http://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz/
Edit: Sorry ich sehe gerade, Daten empfängt das Teil.
Trotzdem: Auf dem Foto im Blog sieht man, wie die Daten "normalerweise" aussehen. (Für PCA 301 Sketch und Lacrosse-Sketch). Das Phänomen hatte ich noch nie. Den Jeelink-Clone einzubinden ist eigentlich nicht schwer, das Zusammenlöten ist frickelig :-)
LG
/robin
@beSmart: Da der Sketch erst mal auf 17241 kbps initialisiert ist, kannst Du von den 30.3155 in putty so auch nichts bekommen.
Musst in putty mal ein 1r schicken, um die richtige data rate zu setzen.
Danach noch ein v schicken, um zu sehen, ob es übernommen wurde
Danach müssten Daten wie von fh168 beschrieben eintrudeln, die so aussehen: OK 9 30 1 4 210 74
Wenn dann nichts kommt, kannst Du anfangen mit 868295f usw. mit der Frequenz zu spielen, bis etwas empfangen wird.
Erst wenn da was kommt, macht es Sinn, wieder in FHEM zu schauen und dort die entsprechenden initCommands zu setzen.
Der Sensor sendet ca. alle 4 Sekunden
@BlackStone: Dein Sketch meldet sich mit [LaCrosseITPlusReader.10.1o (RFM12B f:868300 r:17241)]
Das ist absolut richtig. Daran erkennt das JeeLink Modul, welcher sketch es ist und geht auf initialized, nur scheint es Dein FHEM zu übersehen.
Den debug mode kannst Du wieder raus nehmen.
Bei Dir gilt eigentlich das Gleiche: häng den JeeLink an putty oder sonst ein Terminal, schicke ihm von Hand die erforderlichen commands (data rate, ...) und schaue,
ob Daten in der Form OK 9 30 1 4 210 74 eintrudeln.
In beiden euren Fällen sollten wir erst mal sicherstellen, dass der Sketch liefert, und dann erst eventuelle Probleme auf der FHEM-Seite suchen.
Generell: wenn ich heute einen JeeLink clone bauen würde, dann würde ich einen RFM69CW nehmen und nicht einen RFM12.
Der RFM12 ist weniger empfindlich und eigentlich auch mehr oder weniger vom Hersteller abgeschafft und durch den RFM69CW ersetzt.
Der RFM69CW hat nur Vorteile und ist von der Beschaltung voll kompatibel und im Sketch implementiert.
Nachtrag:
Ich habe auch zwei 30.3155. Mit beiden ist der Empfang mit dem einen oder anderen RFM12 kritisch, die RFM69 empfangen den problemlos.
Die TX29, TX35, TX38, WS 1600 und der ganze ander Sensor-Zoo, der bei mir läuft, sind unkritisch.
Für die 30.3155 muss man tatsächlich manchmal etwas an der Frequenz drehen, mit RFM69 musste ich das noch nie.
Sie laufen aber beide bei mir im Produktivbetrieb konstant gut, wenn man sie halt erst mal am Haken hat :-)
Nachtrag 2:
Wenn man von einem Terminaprogramm (z.B. putty) commands an den sketch schickt, muss man jedes einzeln scheicken, man darf sie nicht wie in initCommand hintereinanderhängen.
Immer hinterher ein v schicken, um zu sehen, ob der sketch die neue Einstllung "verstanden" hat.
@HCS : Ich kenne mich mit dem RFM69 gar nicht aus. Wie sieht die Beschaltung aus? Die gleiche Beschaltung wie beim RFM12b? Und was ist der Unterschied zwischen dem RFM69HW und dem RFM69W ? Kann man beide nehmen?
LG
/robin
Zitat von: fh168 am 28 August 2015, 10:35:00Wie sieht die Beschaltung aus? Die gleiche Beschaltung wie beim RFM12b? Und was ist der Unterschied zwischen dem RFM69HW und dem RFM69W ? Kann man beide nehmen?
Hatte ich doch oben geschrieben: "Der RFM69CW hat nur Vorteile und ist von der Beschaltung voll kompatibel und im Sketch implementiert."
Du kannst einen RFM12 rauslöten und einen RFM69CW reinlöten und es läuft (was ich bereits mal getan habe, JeeNode V6 von RFM12 auf RFM69CW gepusht)
Nur von der Software-Ansteuerung ist er völlig anders, aber der Sketch erkennt automatisch, was es ist und arbeitet dementsprechend.
Voraussetzung ist nur, dass der Sketch mindesten Version 10.1f (Dezember 2014) hat.
siehe auch: http://forum.fhem.de/index.php/topic,14786.msg237739/topicseen.html#msg237739
Da hatte ich auch bereits die Vorteile bezüglich 30.3155 beschrieben.
RFM69HW und RFM69W sind
nicht pinkompatibel zum RFM12, nur der RFM69CW ist das.
Ich würde auch keinen HW nehmen, ich vermute mal, dass man den schon aufgrund seiner Sendeleitung nicht in de_DE betreiben darf.
Zitat von: HCS am 28 August 2015, 11:16:28
RFM69HW und RFM69W sind nicht pinkompatibel zum RFM12, nur der RFM69CW ist das.
Ich würde auch keinen HW nehmen, ich vermute mal, dass man den schon aufgrund seiner Sendeleitung nicht in de_DE betreiben darf.
ok, sofern die Pinbelegung nun anders ist, ist es ja egal, sofern sie von der Software erkannt werden. Und wir senden ja nicht, sondern empfangen ja die Daten von den Temperatursensoren. Ich werde mal von jedem Typ mal einen ordern und ausprobieren.
Zitat von: fh168 am 28 August 2015, 11:46:25Und wir senden ja nicht, sondern empfangen ja die Daten von den Temperatursensoren.
Soso ...
http://forum.fhem.de/index.php/topic,39920.0.html
Zitat von: HCS am 28 August 2015, 11:52:18
Soso ...
http://forum.fhem.de/index.php/topic,39920.0.html
na gut, Sonderfall.
Aber viele nutzen ihn als Empfänger für die TX Temperatursensoren.
Ich werde die trotzdem mal ausprobieren :-)
Hallo ihr fleißigen Helfer.
.........es funktioniert jetzt.
Habe etwas mit Minicom herumgespielt und die Tips von HCS umgesetzt.
Also 1r dann v anschl. 868320f nochmal v zur Kontrolle
Die Frequenz ist 868,320 MHz.
Vielen Dank an alle für die super Unterstützung , besonders an HCS
@Robin deinen Blog kenne ich natürlich. Ist Pflichtlektüre in die ich immer mal reinschaue. Auch dir vielen Dank.
Gruß
Dirk
PS: BlackSone // wie sieht es bei dir aus? Hinbekommen?
Zitat von: beSmart am 28 August 2015, 15:50:45.........es funktioniert jetzt.
Na also. Bisher hat es bei fast jedem irgendwann funktioniert ;)
Zitat von: beSmart am 28 August 2015, 15:50:45PS: BlackSone // wie sieht es bei dir aus? Hinbekommen?
Der hat ein anderes Problem, aber das bekommen wir hoffentlich auch noch in den Griff ...
ich glaube ich habe das problem gefunden. ::)
es ist das aus redmond, sprich ich habe wohl etwas auf meiner box das quer schießt, denn komischerweise will nichts mehr auf den chip schreiben.
weder mein AVRISP mkII, da meldet avrdude von gestern auf heute auf einmal das usb leer ist. :o
arduino ide, bringt per usb die not in sync, usw...
also die goldene kette, es scheint alles zu funzen, aber der sandberg hängt hinterm filter- ich denke mal das sich da die letzen tage, schon fehler eingeschlichen haben.
jetzt werde ich erstmal meine platten putzen, bis ich das durch habe, sollte auch die post aus frankreich angekommen sein, habe da am mittwoch noch 2 rfm69hw bestellt. darf halt nur nicht die ^flotten 915 mhz zum senden nutzen. ^^
edit:/
so neu geflasht, an anderem rechner. nu trudelt per putty entsprechend etwas rein.
[LaCrosseITPlusReader.10.1o (RFM12B f:868300 r:17241)]
OK 9 23 129 6 24 234
nur bei fhem bleibt dat dingen auf open, bis ich per hand ein raw v setze.
Zitat von: BlackStone am 28 August 2015, 19:24:42nur bei fhem bleibt dat dingen auf open, bis ich per hand ein raw v setze.
Hat sich dieses Problem eigentlich inzwischen irgendwie gelöst?
ähh meine bleiben auch auf open , bis zum manuellen v ,
Das ist aber total wurscht, denn wenn Daten kommen werden sie an die Module durchgereicht egal was der JL state gerade meint.
Bei mir ist das leider auch noch so. Ich setze grade mein test Chip neu auf. Gleich auf jessie, statt whezzy. Mal schauen was dann ist.
Gesendet von meinem SM-G920F mit Tapatalk
Das könnte auch ein Timing-Problem sein.
Der Sketch sendent am Ende seiner Initialisierung das [LaCrosseITPlusReader.10.1o (RFM12B f:868300 r:17241)]
Eventuell kommt das bei manchen FHEM-Installationen zu schnell nach dem Öffnen des Ports.
Generell von FHEM verstanden wird es ja, sonst hätte ein "raw v" auch keinen Effekt.
@Wzut: Du bist doch Arduino-Profi. Könntest (nur wenn Du willst) folgendes probieren:
In der LaCrosseITPlusReader10.ino wird ganz am Ende der
void setup(void)
ein
HandleCommandV();
aufgerufen, das den
[LaCrosseITPlusReader.10.1o (RFM12B f:868300 r:17241)]
rausschickt.
Da könntest Du mal ein delay(1000) (und falls keine Verbesserung noch mehr) davorsetzen, dass FHEM das etwas später bekommt und schauen, ob es das Problem beseitigt.
Da wir schon in irgend welchen serial monitoren gesehen haben, dass sich der Sketch korrekt meldet, muss es eigentlich so etwas in der Art sein, warum FHEM das nicht sieht.
*gg* da war ich grad am rumpfuschen, und hab nen delay von 1500 gesetzt, hab bei 2000 angefangen. und muss sagen es passt dann, zumindest mit der init im lacrossmode.
den rest muss ich noch testen, den eigendlich will ich dem auf hx2272 laufen lassen, einige meiner lampen nutzen den. so das es handlicher ist.
edit:/ nop beim umstellen ist der wieder freq. los. und geht auf 0f egal ob auf fs20 oder hx2272.
Zitat von: BlackStone am 01 September 2015, 16:20:18den rest muss ich noch testen, den eigendlich will ich dem auf hx2272 laufen lassen, einige meiner lampen nutzen den. so das es handlicher ist.
edit:/ nop beim umstellen ist der wieder freq. los. und geht auf egal ob auf fs20 oder hx2272.
Ähm, Bahnhof. Wovon sprichst Du?
der lacross läuft jetzt auch mit der selbst-tätigen initialisierung.
nur wenn ich den recivermode umstell fällt die frequens auf 0 zurück.
z.b. möchte ich den recivermode auf HX2272 umstellen, und flups ist er weg, jedoch denke ich mal das ich da wieder einen denk fehler habe. und der HX2272 ein eigenständiger sketch ist, den ich noch ned gefunden habe. ^^
den den einen sensor den ich auf lacross im garten habe, naja den kann ich auch auf my sensors umbauen. das ist son tschibo dingen. lustigerweise auf arduino328 basis.
Ja, der LaCrosse Sketch kann nur LaCrosse und sonst nichts.
recivermode sollte man nicht setzen, das hat beim LaCrosse Sketch das unerwünschte Ergebnis, dass die Frequenz weggestellt wird.
Es gibt irgendwo einen Thread, in dem justme1968 das JeeLink Modul irgendwann mal so anpassen wollte, dass nach der Initialisierung nur noch die sets da sind, sie auch zu dem erkannten Sketch passen. Bis da hin darf man sie einfach nicht setzen.
Initialisierung mit Delay: wenn Wzut das evtl. auch noch verifizieren würde, dann übernehme ich den Delay "offiziell" in den Sketch.
also, doch mein denkfehler. ;D
habe das delay jetzt auf 1000 gesetzt. und initCommands auf "3m 30t v" gesetzt. es läuft, wie geplant. auch ein kompletter kaltstart, und die init, geht auf meinem raspi 2b sauber von statten.
Zitat von: HCS am 01 September 2015, 17:05:05
Initialisierung mit Delay: wenn Wzut das evtl. auch noch verifizieren würde, dann übernehme ich den Delay "offiziell" in den Sketch.
Sorry , kann ich nicht bestätigen - allerdings ist mir auch unklar was das delay in der Setup Schleife bringen soll, denn bei einem fhem Start durchläuft doch der JL keinen Reset ??? Allerdings löst man im laufenden Betrieb einen aus dann wechselt der state auch brav.
Ich habe dann beim JL verbose auf 5 gesetzt und ein beliebiges initCommand und was soll ich sagen : ich war doch etwas verwundert über das Ergebnis.
Ich hatte erwartet durch den Level 5 im Log die Abarbeitung des InitCommands durch SW: zu sehen, aber Fehlanzeige.
[OT on]
Ein kleiner Schönheitsfehler den viele Module haben die xxx_SimpleWrite vermutlich vom 00_CUL übernommen haben ist die Zeile :
Log3 $name, 5, "SW: $msg"; könnte man ändern in Log3 $name, 5, $name." SW: $msg"; dann sieht man im log von welchem Device die Ausgabe ist :)
[OT off]
Ich habe dann mal etwas weiter im 36_JeeLink gesucht wo denn da überhaupt der initCommands String abgearbeitet wird und habe nur eine Stelle gefunden :
im sub Parse. Nun stelle ich mir die Frage, wann sollte denn der Teil durchlaufen werden ? Doch wohl dann (und nur dann) wenn vom JL etwas geschickt wird ( if($dmsg =~ m/^\[/ ) { ), der schickt aber beim fhem Neustart nichts .... (vllt ein Henne <-> Ei Prob ?) anders als der Cul , diese hat im DoInit Zweig ein CUL_SimpleWrite($hash, "V");
Ich habe bisher selbst das attr initCommands beim JL nie genutzt, da ich die erforderlichen Parameter immer gleich im Arduino Sketch gesetzt habe,
vllt kan ja Andre als Autor mehr dazu sagen.
Die iniCommands funktionieren auch bei einem Neustart von FHEM.
Wenn FHEM die Schnittstelle öffnet, macht der Arduino im JeeLink einen Reset. Und wenn er einen Reset macht, dann durchläuft er void setup(void).
Aus diesem Grund funktioniert auch "set myJeeLink reset", was nichts anderes macht, als die Schnittstelle zu schließen und wieder zu öffnen.
Hast Du Deinen Clone evtl. mit einem FTDI ohne DTR angeschlossen? Das wäre auch noch eine denkbare Erklärung, warum nichts kommt, weil dann nämlich gar kein Reset ausgelöst wird, wenn die Schnittstelle auf geht.
Zitat von: Wzut am 01 September 2015, 20:16:30Ich habe dann mal etwas weiter im 36_JeeLink gesucht wo denn da überhaupt der initCommands String abgearbeitet wird und habe nur eine Stelle gefunden :
im sub Parse. Nun stelle ich mir die Frage, wann sollte denn der Teil durchlaufen werden ? Doch wohl dann (und nur dann) wenn vom JL etwas geschickt wird
Richtig, wenn vom JL etwas geschickt wird. Und das passiert, wie oben beschrieben, durch: Schnittstelle öffnen -> Ardunio macht reset -> void setup(void) läuft und schickt [LaCrosseITPlusReader... -> die parse läuft und schickt die initCommands.
Zitat von: HCS am 01 September 2015, 22:02:02
Hast Du Deinen Clone evtl. mit einem FTDI ohne DTR angeschlossen?
Oh oh, wie peinlich .... man lernt doch nie aus :)
Ja klar, mein Bastel JeeLink ist ein nackter ATmega328p der direkt an den GPIO Pins des Raspberry hängt, autoreset ist da natürlich nicht vorhanden ! Ich habe aber für das nächste Projekt noch einen JeeLink Nachbau von locutus, werde mit dem es nochmal testen.
sodele , kleines Update :
mit dem USB JeeLink Clone von locutus funzt alles so wie es soll.
Ein zusätzliches delay ist zumindest auf meinen Systemen nicht nötig.
Zitat von: Wzut am 04 September 2015, 10:07:59mit dem USB JeeLink Clone von locutus funzt alles so wie es soll.
Das erwartete Ergbnis :)
Zitat von: Wzut am 04 September 2015, 10:07:59Ein zusätzliches delay ist zumindest auf meinen Systemen nicht nötig.
Das hatte ich auch noch nie gebraucht oder gehört. Keine Ahnung, warum das System von BlackStone die Antwort verpasst. Oben sind ja schon 200ms drin, um der Schnittstelle Luft zu geben.
Aber wenn es bei ihm mit einem zusätzlichen Delay von 1000ms geht, ist es ja definitiv ein Timing-Problem.
Ich kann aber die 1000ms unten reinpacken, dann ist diesem und ähnlichen Fällen in Zukunft vorgebeugt. Wenn nach einem Neustart das JeeLink Modul eine Sekunde später initialisiert ist, ist ja auch nicht dramatisch.
Hm, evtl liegt es am raspberry pi 2b. Der heizt dermaßen durch beim booten das ich vermute das der usb Port nicht nachkommt. Denn der edimax verschluckt sich manchmal auch. Ebenfalls der RTC der wird initialisiert nur die system Uhr später. Bisher wurde Uhrzeit und Datum erst gesetzt nachdem fhem bereits oben war (logfile Datum 1.1.1970) und dann erst das richtige. Ich habe nun im init. d/fhem gleich am Anfang nen SLEEP 10 rein geballter. Beim Boot merkt man es fast nicht. Aber die RTC hat zugeschlagen wenn es weitergeht. Und es ist nicht dir ntp die die setzt.
Gesendet von meinem SM-T230 mit Tapatalk
OK. Initialisiert das JeeLink modul bei einem FHEM-Neustart? Also nicht bei einem Raspi-Boot sondern einem
shutdown restart
in FHEM?
mit, dem delay schon, ohne nicht.
jedoch da ja die ports dichtgemacht werden, und dann wieder geöffnet werden kommt es ja aufs gleiche wie beim booten.
Mir fiel auf, dass die Einstellung der Frequenz essentiell ist. Insbesondere der Default Wert 868200 Khz funktioniert nur bei den TX Sensoren mit 17KBit. Die TFA Dostmann WD Sensoren mit 9Kbit werden von dem Jeelink Clone mit einem RFM12B gar nicht mehr empfangen. Hier hilft ein Mittelweg von 868310 Khz. Mit der Eingabe im FHEM Fenster attr (CULNAME) initCommands 30t 3m 868310f v konnte ich im Zyklus von 30 Sekunden (30t) auf den Baudraten 9Kbit und KBit (3m) auf der Frequenz 868,310MHz beide Sensorentypen stabil empfangen. Eine Korrektur in 5Khz Schritten kann man ggf. noch nach oben oder unten in Betracht ziehen. DAS war zumindest bei mir der Grund, weswegen ich mit neueren Arduino Sketches erst mal keine Dostmann Sensoren mehr empfangen konnte.
Zitat von: BlackStone am 01 September 2015, 17:13:57
habe das delay jetzt auf 1000 gesetzt.
Siehe hier: http://forum.fhem.de/index.php/topic,14786.msg340076.html#msg340076