Jeelik Modul zur Einbindung von La Crosse!

[HCS]

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:
 

Code Auswählen Erweitern

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

[JoeALLb]

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

[HCS]

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.

[HCS]

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.

[Billy]

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.

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

- 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

- exakt ermitteln, in welchem Interval die verschiedenen Sensoren senden

ok wenn der Sketch das hergibt?

- Test-Sendeschleife, die selbst eine Temperaturrampe fährt

ok wenn der Sketch das hergibt?

- sicherstellen, dass bei einer kürzeren Unterbrechung der Aussendungen nicht ein neues Binden erforderlich ist

Das bestimmt m.E. die WS

- 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

[Billy]

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!

whereas 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

[disaster123]

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!

[HCS]

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.

[HCS]

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.

[HCS]

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:

Code Auswählen Erweitern

<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)

Code Auswählen Erweitern

<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:

Code Auswählen Erweitern

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

[JoeALLb]

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

[HCS]

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.

[JoeALLb]

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

[HCS]

Ich finde die Liste auch im Wiki passender als hier in einem Kommentar....

Ja, nur wie kommt sie ins wiki? 

[JoeALLb]

Kann man eigentlich auch die sendestärke einstellen? 

Gesendet von meinem Xperia Pro mit Tapatalk