Jeelink-Clone will nicht - Funkmodul defekt ?

[HCS]

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

Code Auswählen Erweitern

void setup(void)
ein

Code Auswählen Erweitern

HandleCommandV();
aufgerufen, das den

Code Auswählen Erweitern

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

Da könntest Du mal ein

Code Auswählen Erweitern

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.

[BlackStone]

*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.

[HCS]

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  egal ob auf fs20 oder hx2272.

Ähm, Bahnhof. Wovon sprichst Du?

[BlackStone]

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.

[HCS]

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.

[BlackStone]

also, doch mein denkfehler.

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.

[Wzut]

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.

[HCS]

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.

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

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.

[Wzut]

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.

[Wzut]

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. 

[HCS]

mit dem USB JeeLink Clone von locutus funzt alles so wie es soll.

Das erwartete Ergbnis 

Ein 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.

[BlackStone]

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

[HCS]

OK. Initialisiert das JeeLink modul bei einem FHEM-Neustart? Also nicht bei einem Raspi-Boot sondern einem

Code Auswählen Erweitern

shutdown restart
in FHEM?

[BlackStone]

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.

[weihnachtsmann]

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.