Senden via Jeelink/LaCrosse

[HCS]

Probier mal bitte die angehängte 10.1r Beta, ob es damit bei Dir auch geht.

[DokHasenbein]

Ja. Klappt.

[HCS]

Ja. Klappt.

Bei Dir alles im Lot.
Wenn Du keine (auch sonstige) Probleme mit dieser Version hast, dann würde ich sie demnächste offiziell rausgeben.

[DokHasenbein]

Also mit dem Jeelink ist alles im Lot. Leider ist mein HM-LAN-CFG am sterben (ständige Disconnects), weshalb bei mir im Moment alles mögliche nicht richtig funktioniert. Deshalb hab ich leider nicht viel testen können .
Auf jeden Fall vielen Dank nochmal für deine schnelle Hilfe. Ist echt super!

[HCS]

Habe die Version gerade offiziell eingecheckt.

Version 10.1r

[DokHasenbein]

Hallo HCS,

mein Projekt kommt langsam aber stetig voran. Ich habe einige Fragen zu den verwendeten Bibiliotheken, von denen ich hoffe, dass Du sie beantworten kannst:
1.) RFMxx hat einen IRQ-Pin, der aber soweit ich es verstehe gar nicht zum Einsatz kommt. Weder als Interrupt noch überhaupt als Input-PIN. Richtig?
2.) Woher kommt eigentlich RFMxx? Ist das Dein Werk? Wie ist die Lizenz?
3.) Die 1%-Regel müsste man selbst auf höherer Ebene beachten, oder ist das irgendwo drin?
4.) ACKs oder so von FHEM müsste man auch auf höherer Ebene verarbeiten, oder?

[HCS]

1.) RFMxx hat einen IRQ-Pin, der aber soweit ich es verstehe gar nicht zum Einsatz kommt. Weder als Interrupt noch überhaupt als Input-PIN. Richtig?

Richtig.

2.) Woher kommt eigentlich RFMxx? Ist das Dein Werk? Wie ist die Lizenz?

Ja, mein Werk, ist eine Lib, die RFM12 und RFM69 kann und automatisch erkennt, ob und welcher es ist.
Die Lizenz ist "kanst machen mit, was Du willst"

3.) Die 1%-Regel müsste man selbst auf höherer Ebene beachten, oder ist das irgendwo drin?

Muss man selbst beachten

4.) ACKs oder so von FHEM müsste man auch auf höherer Ebene verarbeiten, oder?

Ja. Die RFMxx ist pur die Ansteuerung des RFM und dessen Konfiguration der HF-Parameter usw. aber keine "höheren" Protokolle.

Allgemein
Ich stelle aber auch kein "Produkt" RFMxx.h/RFMxx.cpp zur Verfügung. Sie ist Bestandteil der Firmware für den JeeLink und das LGW.
Du darfst sie Dir aber gerne abgreifen und für was auch imme verwenden, in eigener Verantwortung im Kontext von dem, was Du machst.

[Harst]

Ich habe gerade versucht, meinem Temperatur-Display per JeeLink Daten zu schicken. Als das nicht ging habe ich mir die Sourcen angesehen und glaube, das das vom Konzept nicht geht (Die Geräteart ist CC statt 09, Das Protokoll ist anders)?

Hintergrund ist, dass ich Sensoren habe, die das Display versteht, aber die geben Temperatur und keine Luftfeuchte. Die anderen geben die Feuchte, aber sprechen das falsche Protokoll.

Leichtsinnig dachte ich, dann kann ja der JeeLink die Werte aus FHEM senden, dann sind alle mit einem Sensor glücklich.

Habe ich was übersehen oder geht das zur Zeit nicht?

Danke

Horst

PS: Wenn noch Speicher da ist wäre die Erweiterung vielleicht sogar für mich machbar.

[FFHEM]

Auf die Gefahr hin, dass ich mich im falschen Board befinde, stelle ich dennoch einfach mal die Frage, ob ich für diesen Sensor:

https://adko.eu/Sender-868MHz-fuer-3-Temperatur-Feuchtigkeit-Sensoren-DS18B20-DHT-22-IP65

der über einen JeeLink v3c mit eigener Firmware empfangen wird, in FHEM eingebunden werden kann.
Lt. Hersteller soll das gehen, aber er selbst kennt FHEM nicht und kann nicht weiterhelfen.

Der JeeLink ist mit der Hersteller-Firmware geflasht

Code Auswählen Erweitern

model: [ADKO_JeeLinkReader.1.2_HMS_mod4 (RFM69 f:868300 r:17241)]
(Update: mit der Original-JeeLink-Firmware kommen keine RAW-Messages an)
und liefert als RAW-Message z. B. :

Code Auswählen Erweitern


H000040510245

Laut Hersteller soll dies durch ein LaCrosse-Device in FHEM realisiert werden können.
Aber weder wird beim

Code Auswählen Erweitern

set myJeeLink LaCrossePairForSec 60
ein neues Device angelegt, noch kann man es manuell machen.

Die RAW-Message hat diesen Aufbau lt. Hersteller:

Code Auswählen Erweitern


*HMS 100 TF  (Temperatur / Luftfeuchtesensor)
*HMS 100 T   (Temperatur)
*
* H 00 00 2 1 1  2  0  4  0  0         ID=0000 ; T=41.2  ; sensorTyp= HMS100T; schwache Batterie
* H 00 00 0 0 1  2  0  4  5  6         ID=0000 ; T=41.2  ; RF=56  ; sensorTyp= HMS100TF
* H 00 00 8 0 1  2  0  4  5  6         ID=0000 ; T=-41.2  ; RF=56  ; sensorTyp= HMS100TF;
* H AA AA F T T1 T2 H1 T3 H2 H3 RR
* |  | |  | |  |  | |  |  |  |  |
* |  | |  | |  |  | |  |  |  |  `---- RSI-Wert vom Empfang (optional)   
* |  | |  | |  |  | |  |  |   `------ Humidity H3*1 (10*H2 + H3 + H1/10)
* |  | |  | |  |  | |  |  `---------- Humidity H2*10 (10*H2 + H3 + H1/10)
* |  | |  | |  |  | |   `------------ Temperature T3*10 (10*T3 + T1 +T2/10) * Vorzeichen
* |  | |  | |  |  | `---------------- Humidity H1*0.1 (10*H2 + H3 + H1/10)  immer 0 da LaCross nur im 1% Schritten
* |  | |  | |  |  `------------------ Temperature T2 * 0.1 (10*T3 + T1 +T2/10) * Vorzeichen
* |  | |  | |  `--------------------- Temperature T1*1 (10*T3 + T1 +T2/10) * Vorzeichen
* |  | |  | `------------------------ Sensor-Typ: 0.. HMS100TF, 1.. HMS100T
* |  | |  `-------------------------- Flags und Temperatur-Vorzeichen Vorzeichen: kleiner 0°C => 8   schwache Batter => 2 oder gemischt als HEX
* |  |  `---------------------------- ID = AA 
* |   `-------------------------------fix = 00
* `---------------------------------- fix = H

Nachdem ich mir das LaCrosse-Modul angesehen habe, ist mir auch klar, warum das nicht geht.
Seht Ihr die Möglichkeit, dieses Format in das LaCrosse-Modul (oder auch ein eigenes später) einzubauen?
Hab das noch nie gemacht und mit Perl sehr wenig Erfahrung.
Reicht es nicht, einen ähnlichen LaCrosse-Sensoren in der 36_LaCrosse.pm zu kopieren und den Code anzupassen, der die Dekodierung macht?
Reicht das??

Ihr seht, viele Fragen, deshalb vielen Dank im voraus!

Gruß,
Friedhelm

[pdbjjens]

Ich gehöre zu den stillen Mitlesern dieses ausgesprochen produktiven und kompetenten Forums.
Da ich aus den Beiträgen in diesem Forum schon häufig profitiert habe, möchte ich mich nun mal revanchieren
und eine Information zum Thema ,,Senden via Jeelink/LaCrosse" teilen, die ich so bisher nirgendwo,
auch nicht außerhalb dieses Forums im Internet gefunden habe und von der ich hoffe,
dass sie für den einen oder anderen Leser interessant sein mag.
Dies ist mein erster Beitrag. Daher bitte ich, mögliche Formfehler zu entschuldigen.

Das ursprüngliche Thema "Daten an eine LaCrosse Basisstation senden", die dann eine Temperatur anzeigt
hat HCS leider 2015 verworfen (siehe seinen Beitrag zu Beginn dieses Threads) und auch die entsprechenden
Transmitter Routinen aus dem LaCrosseITPlusReader10 Sketch entfernt.

Aus der Diskussion von 2014 im LaCrosseITPlusReader10 Thread (Jeelik Modul zur Einbindung von La Crosse! )
https://forum.fhem.de/index.php/topic,14786.msg148830.html#msg148830
und folgende habe ich entnommen, das es zwar gelungen war, die Daten einmalig an eine Lacrosse Basisstation zu senden,
dass sich aber die Anzeige nach Ende der Aquisitionsphase nicht mehr updaten ließ und dann irgendwann nichts mehr anzeigte.
Ursache war, dass das Timing der Sensordaten ( ca. alle 4 Sekunden ) offenbar sehr kritisch für den Empfang der Basisstation
in der Powersaving Phase war.

Da mir das ungelöste Problem keine Ruhe gelassen hat, habe ich für die TFA DIVA GO IT+ Basisstation und Sensor
(TFA 30.3018.IT mit Dualtemperatursensor 30.3143.IT) das Timing analysiert. Dabei habe ich gefunden,
dass es durch leichte Modifikationen der ursprünglich im LaCrosseITPlusReader10 Sketch enthaltenen Transmitter Routinen möglich ist,
die Basisstation dauerhaft als Anzeige zu nutzen.

Der Trick dabei ist, dass das exakte Intervall zwischen den Datagrammen des Sensors von grob 4 Sekunden
abhängt von der zufälligen ID ( 0-63 ) mit der sich der Sensor anmeldet. Wie genau, siehe folgenden Text.

Bei dem o.g. Sensor handelt es sich um einen Dualtemperatursensor. Er sendet abwechselnd die Temperatur
des ersten Kanals und des zweiten Kanals. Die Datagramme unterscheiden sich dadurch, dass im Feld für
die Humidity beim 1. Kanal 106 und beim 2. Kanal 125 fest eingetragen ist.
Daher ergibt sich für jeweils einen Kanal betrachtet ein Sendeabstand von grob 8 Sekunden.
Der Sendeabstand für einen Kanal ist folgendermaßen definiert:

Kanalintervall              KI = 8000ms + (ID + 1) * 1/64 * 1000ms

Es wird also 1/64 Sekunde je ID-Wert zum Basisintervall von 8 Sekunden dazugerechnet.
Zu beachten ist, dass der ID-Wertebereich statt von ( 0-63 ) von ( 1-64 ) läuft.
Dadurch soll offenbar erreicht werden, dass Datagramme verschiedener Sensoren,
die zufällig gleichzeitig gesendet werden, nicht auf Dauer Kollisionen erzeugen.
Das Sendeintervall zwischen Kanal 1 und Kanal 2 bei einem zweikanaligen Sensor beträgt daher:

                                m_intervall =  KI /2

m_intervall in der Transmitter::SetParameters Methode ist ein Integer. Daher muss entsprechend gerundet werden.

Code Auswählen Erweitern


                       m_interval = (uint16_t)(((8000 + (id+1) * (float)1000/64)/2)+0.5);


Da dieses Timing strikt einzuhalten ist, um die Synchronisation von Sensor und Basisstation nicht zu verlieren,
ist in der Transmitter::Transmit Methode eine Korrektur nötig, um eine mögliche Verzögerung des Aufrufs der
Methode zu korrigieren.
Das geschieht durch Subtraktion des Offsets zwischen der tatsächlichen Zeit des Methodenaufrufs und der geplanten Aufrufzeit.

Code Auswählen Erweitern


if (m_enabled && timenow >= m_lastTransmit + m_interval) {
    offset = timenow - (m_lastTransmit + m_interval);
    m_lastTransmit = timenow - offset;
}


Es ist möglich, das Sendeintervall zu vergrößern ohne die Synchronisation zu verlieren. Bei der DIVA GO Basisstation
ist eine Verlängerung um den Faktor 4 ohne Probleme möglich. Das bedeutet ein Kanalintervall von grob 32 Sekunden,
was in den meisten Fällen ausreichend ist um eine zeitgerechte Temperaturanzeige zu gewährleisten.
Die Verlängerung geschieht am besten beim Ablauf der NewBatteryFlag Zeit:

Code Auswählen Erweitern


    if (m_newBatteryFlag && millis() >= m_newBatteryFlagResetTime) {
      m_newBatteryFlag = false;
      m_interval *= 4;            //extended interval time after expiry of newBatteryFlagResetTime
    }


Um den Dualtemperatursensor zu simulieren, ist in der Transmitter::Transmit Methode noch einzubauen:

Code Auswählen Erweitern


bool m_channel2

    LaCrosse::Frame frame;
if (!m_channel2) {
frame.ID = m_id;
frame.NewBatteryFlag = m_newBatteryFlag;
frame.Bit12 = true;
frame.Temperature = m_temperature;
frame.WeakBatteryFlag = false;
frame.Humidity = m_humidity;
m_channel2 = true;
}
else {
frame.ID = m_id;
frame.NewBatteryFlag = m_newBatteryFlag;
frame.Bit12 = true;
frame.Temperature = m_temperature2;
frame.WeakBatteryFlag = false;
frame.Humidity = 125;
m_channel2 = false;
}


Außerdem ist eine zusätzliche Erweiterung der Transmitter::SetValues Methode nötig,
um die Temperaturwerte ( m_temperature2 ) des zweiten Kanals setzen zu können.

Ich möchte noch darauf hinweisen, dass die beschriebenen Modifikationen nur für die o.g. Basisstation / Sensor
geeignet sind. Für andere IT+ Sensoren, z.B. TX29 DTH-IT mit nur einem Kanal und andere IT+ Basisstationen
müssen die Transmitter Methoden entsprechend angepasst werden. Da ich nicht über solche Hardware verfüge,
kann ich es nicht verifizieren, aber ich gehe davon aus, dass das grundsätzliche Prinzip des von der ID abhängigen
Sendeabstands auch dort implementiert ist.

Vielleicht hat ja ein Leser dieses Forums mit der entsprechenden Hardware und Interesse an dem
Thema "Daten an eine LaCrosse Basisstation senden" die Zeit, das mal auszuprobieren.
Möglicherweise kann man daraus eine universelle Transmitter Class entwickeln, die mehrere
unterschiedliche Basisstationen und Sensortypen mit 1 oder mehr Kanälen unterstützt.

Es würde mich freuen, wenn HCS dann die Transmitter Routinen wieder in den LaCrosseITPlusReader10 Sketch einbauen würde.
Das kann aus Speicherplatzgründen natürlich nur als Compilierungsoption erfolgen, z.B. alternativ zu dem Code für die onboard Sensoren.

[HCS]

Es würde mich freuen, wenn HCS dann die Transmitter Routinen wieder in den LaCrosseITPlusReader10 Sketch einbauen würde.

Das (also der Rest vom Beitrag) ist interessant.
Allerdings habe ich keinelei Basisstation mehr, mit der ich das Testen/machen könnte.
Und den JeeLink-Sketch habe ich auch mehr oder weinger zu den Akten gelegt.
Aber wenn es jemand einbaut und es nicht nach schrägen Nebenwirkungen aussieht und er dann für den Teil auch Support und Beratung im Forum übernimmt, dann checke ich es gerne ein.

[Raymund]

Ich habe die Intervalberechnung von pdbjjens an einer WS-9130IT ausprobiert. Den Sketch hatte ich früher schon mal aus dem Forum herunter geladen, aber es hatte nie funktioniert. Jetzt klappt das schon seit ein paar Stunden.

Nach dem Einlegen der Batterien starte ich das folgende notify  (im Moment noch testweise) per trigger-Befehl (trigger jeelink init):

Code Auswählen Erweitern

jeelink:init {
my $id = '50'; my $id_dec = hex("x$id");
my $ki = 8 + ($id_dec + 1) / 64; $ki = sprintf ('%.1f', $ki);
Log3 'global', 1, "ID_hex: $id ID_dec: $id_dec Interval: $ki s";
;
$ki = $ki * 10;
my $cmd = "set jeelink raw ${id},${ki},2,0i";
Log 1, $cmd; fhem ($cmd);
;
$cmd = 'set jeelink raw 1,2,3,0c';
Log 1, $cmd; fhem ($cmd);
}

Danach wird mit dem folgenden notify der Wert aktualisiert:

Code Auswählen Erweitern


LC01:temperature.+ {
my $t = abs($EVTPART1); $t = sprintf('%04.1f', $t);
my $z = substr ($t,0,1); $z += 128 if ($EVTPART1 < 0);
my $cmd = "set jeelink raw ${z}," . substr ($t,1,1) . ',' . substr ($t,3,1) . ',' . '0c';
Log 1, $cmd; fhem ($cmd);
}

Danke an pdbjjens für die Vorarbeit. Ich hätte auch nichts dagegen, wenn die Senderoutinen wieder Bestandteil des aktuellen Sketches wären. Änderungen daran wären für mich soweit nicht nötig. Allerdings verliert sich die Synchronisation zwischen Sender und Empfänger, wenn ich das Interval mit 10 multipliziere, wie im Sketch dokumentiert. Ich arbeite noch dran ...

[HCS]

Ich hätte auch nichts dagegen, wenn die Senderoutinen wieder Bestandteil des aktuellen Sketches wären. Änderungen daran wären für mich soweit nicht nötig.

Ich werde an dem Jeelink-Sketch nichts mehr machen.
Wenn es jemand einbauen will, darf er das gerne machen und den Support dafür übernehmen.

[pdbjjens]

@Raymund
Es freut mich, dass das Prinzip der von mir ermittelten Intervallberechnung auch mit einer anderen Basisstation verifiziert werden konnte.

Leider habe ich in der Zwischenzeit festgestellt, dass die in meinem obigen Code-Schnipsel vorgeschlagene Implementation der Sendeintervall-Korrektur Fehler enthält die dazu führen, dass nach einigen Wochen Laufzeit die Senderoutine das Senden einstellt.

Ursache ist, dass im obigen Code der millis() Overflow nicht korrekt behandelt wurde.

Hintergrund: Der der millis() Funktion zugrunde liegende Zähler ist ein unsigned long (32 bit)
und hat daher nach ungefähr 49,7 Tagen einen Überlauf nach 0.

Deshalb empfehle ich, obigen Code-Schnipsel zur Intervallkorrektur in der Transmitter::Transmit Method durch den folgenden zu ersetzen:

Code Auswählen Erweitern


.
.
.
  unsigned long offset = 0;
  unsigned long timenow = millis();

  if (m_enabled && timenow - m_lastTransmit >= m_interval) {
  // adjust for any delays in the loop to ensure constant intervals
   offset = timenow - m_lastTransmit;
   offset -=  m_interval;
        // Reset the NewBatteryFlag, if it's time to do it
        if (m_newBatteryFlag && timenow - m_firstTransmit >= m_newBatteryFlagResetTime) {
           m_newBatteryFlag = false;
       m_interval *= 4;            //extended interval time after expiry of newBatteryFlagResetTime
      }
m_lastTransmit = timenow - offset;
.
.
.


Der Code zum Rücksetzen des newBatteryFlag und Vergrößern des Sendeintervalls wurde auch ersetzt
weil er ebenfalls auf der millis() Funktion basiert.

Die neue Variable unsigned long m_firstTransmit sollte beim Setzen der Transmit Parameter mit den aktuellen millis() initialisiert werden.