Jeelik Modul zur Einbindung von La Crosse!

Begonnen von Billy, 16 September 2013, 15:12:15

Vorheriges Thema - Nächstes Thema

Billy

#510
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
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Billy

Das sehe ich auch so.
Könnte das eventuell bedeuten, dass man mit dem Jeelink dann nicht mehr empfangen kann?

Gruss
Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

JoeALLb

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.
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

HCS

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.

Billy

#515
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
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

HCS

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.

Billy

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
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

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

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

JoeALLb

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....
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Billy

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. ::)
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

HCS

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?

Billy

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

FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

Billy

@Andre
ZitatSo wie ich Oliver kennengelernt habe wird er uns nicht steinigen.

was meinst du dazu?

Gruss
Billy
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968