Senden via Jeelink/LaCrosse

[user1]

Ich verschiebe mal den im "Anfängerforum" begonnenen Thread (http://forum.fhem.de/index.php/topic,39909.0.html) hierher:

Die Frage war, ob es möglich sein, Custom-Funktelegramme im LaCrosse-Format via Jeelink aus FHEM heraus abzusetzen, um eigene Hardware anzusteuern.

Antwort von Wzut: Genau das Thema ( LaCrosse bidirektional ) habe ich z.Z. auf meiner Wunschliste und auch schon konkrete Vorstellungen zur Umsetzung.

[HCS]

Na prima. habe gerade vor einer Woche die Senderoutinen (wegen Speichermangel) im Sketch stillgelegt.
Kann sie aber auch wieder aktivieren, dann muss ich halt wo anders den Platz rauskitzeln.

Generell geht das. Das s command ist noch drin, müsste aber für dieses Vorhaben evtl. etwas angepasst werden.
Funktioniert generell nach diesem Prinzip: 10,20,30,40s rechnet über die angegebenen Bytes die Prüfsumme, hängt diese an und schickt das dann über das Radio raus. Allerdings ist momentan die Anzahl Bytes fix. Das könnte ich aber universeller machen, so dass der Sketch eine beliebige Anzahl Bytes akzeptiert, die Prüfsumme rechnet und das dann raus schickt. Was die Bytes bedeuten ist ihm egal. Das kann man dann irgend wo empfangen und interpretieren.

Das Protokoll könnte man so gestalten, dass es der angepasste Sketch beim Empfang akzeptiert und man könnte über die matchlist in FHEM im JeeLink Modul ein eigenes Modul dran hängen, das die Daten in FHEM weiter verarbeitet.

Die Software für die Gegenstelle müsste aber ja dann auch noch von jemand implementiert werden.

Das ursprüngliche Thema "Daten an eine LaCrosse Basisstation senden", die dann eine Temperatur anzeigt habe ich aber endgültig verworfen.

[Wzut]

Na prima. habe gerade vor einer Woche die Senderoutinen (wegen Speichermangel) im Sketch stillgelegt.

Habe ich im LaCrosse Thread mitbekommen Ich verwende allerdings noch die Version 10.1j  und da sind noch 3K Luft ( 27020 vs. 30720 )
Das Thema LaCrosse senden hat mich auch die Tage beschäftigt (beim Nachbau deines  Level Senders), da entstand auch die Idee meinen aktuellen Hardware Zoo zu verkleinern und für das nächste Bastel Projekt statt WLAN auch auf diese 868MHz RFM Schiene zu setzten.   

[HCS]

Ich verwende allerdings noch die Version 10.1j  und da sind noch 3K Luft ( 27020 vs. 30720 )

Und nach 10.1j kam dann der BMP180 und der zweite RFM rein, das hat das Fass dann voll gemacht.

Das Thema LaCrosse senden hat mich auch die Tage beschäftigt (beim Nachbau deines  Level Senders), da entstand auch die Idee meinen aktuellen Hardware Zoo zu verkleinern und für das nächste Bastel Projekt statt WLAN auch auf diese 868MHz RFM Schiene zu setzten.

Wie schon geschrieben, ich würde die universelle Sende- und Empfangsroutine im Sketch passend machen, den "sende an LaCrosse Basisstation" Teil rauswerfen, dann könnt ihr das vermutlich realisieren, was ihr wollt. Eure "Gegenstellen" müsstet ihr aber schon selbst implementieren.

Ganz grob das Prinzip:
ihr sagt dem Sketch über das JeeLinkModul mit "set myJeeLink raw 1,2,3,4,5,6,7,8s", dass ihr diese 8 Bytes versendet haben wollt
der Sketch packt CRC dran und schickt es mit den aktuell konfigurierten HF-Parametern (Frequenz, data rate) raus
Eure Gegenstelle antwortet mit einem Paket, das sich von TX..., EMT, WS 1600, usw. unterscheiden lässt
Der Sketch gibt diese Pakete an das JeeLink Modul, mit einem Start wie wenn es eine neue Sorte LaCrosse Sensor wäre
Das JeeLink Modul gibt gem. seiner MatchList diese Daten an ein 99_SonstWas Modul, das ihr euch schreibt, das dann mit den Daten machen kann was es will.

Würde sich damit das realisieren lassen, was ihr vorhabt?

Das Ganze funktioniert parallel zum "normalen" Empfangsbetrieb für die LaCrosse Sensoren und am JeeLink Modul müsste vermutlich auch nichts geändert werden.

[user1]

Genau so was habe ich mir vorgestellt.

Falls der Platz nicht reicht gäbe es ja ev noch die Variante, per #define Blöcke die man im Code drin haben möchte an bzw. abzuwählen und separate Sketches zu generieren. Aber wenn alles reinpasst um so besser!

[HCS]

Das Thema LaCrosse senden hat mich auch die Tage beschäftigt

Kannst Dich in Kürze intensiver mit beschäftigen. Am WE werde ich es vermutlich verfügbar machen, klappt schon ganz gut...
Bidirektionale Kommunikation mit Eigenbausensor parallel zum normalen LaCrosse-Empfang

[Wzut]

sehr schön, thx

[fh168]

finde ich ja cool. Ich habe mir neulich einen MQ-7 Sensor (misst co2) gekauft und wollte den mit MySensors-Logik ausstatten. Und ja, just for fun. Vielleicht werde ich das mal mit der Jeelink-LaCrosse Logik bauen und drüber bloggen.

LG
/robin

[HCS]

Und ja, just for fun.

90% ist "just for fun", früher konnten Menschen noch Lichtschalter benutzen, wenn sie etwas sehen wollten bei Nacht und haben dem Hersteller geglaubt, dass die Glühbirne 60W verbraucht, wenn 60 Watt draufsteht, auch ohne einen EMT7110 davor zu packen. 

Darum macht das hier auch Spaß, weil es etwas ist, das man einfach machen kann, es aber zum Überleben nicht braucht.

Ein co2 Sensor - das wäre auch noch was. Bin irgendwie auch auf dem "just for fun messen, was zu messen ist" Trip 

[fh168]

wenn du noch einen benötigst mq 7 pm me

[Wzut]

Darum macht das hier auch Spaß, weil es etwas ist, das man einfach machen kann, es aber zum Überleben nicht braucht.

Vollkommen richtig , ich vormuliere es immer etwas härter :
Warum leckt der Hund sich die Eier ? Antwort : weil er es kann ...

[HCS]

So, da ist es: LaCrosse bidirektional

Anbei ein funktionsfähiges Beispiel für einen Sensor, mit dem man kommunizieren kann.

Voraussetzung: auf dem JeeLink, der an FHEM dran ist, muss mindesten Version 10.1o sein und FHEM muss auf dem trunk Stand sein.

Sketch (im ZIP) CustomSensorExample
Der Beispielsensor hat die ID 11 und sendet alle 10 Sekunden ein Paket, das so aussieht:  "1 ctr"
wobei ctr immer um eins hochzählt

Wenn er ein Paket empfängt, das für ihn ist, dann nimmt er die ersten beiden Bytes, addiert sie und sendet das Ergebnis zurück.
Das macht alles keinen Sinn, funktioniert trotzdem und zeigt, wie so ein Sensor funktioniert.
Man könnte z.B. etwas schalten, und zurückmelden, ob es ausgeführt wurde, ein HMS für Arme also.

FHEM Beispiel Modul (im ZIP) 36_CustomSensorExample.pm
Ein Beispiel, wie das auf FHEM-Seite aussehen kann.
Definieren mit: define myCS CustomSensorExample 0B
Das Modul hat zwei readings. "periodic" ist der Wert, den der Beispielsketch alle 10 Sekunden sendet.
result ist die Antwort, die der Sketch vom CustomSensor erhalten hat.
mit "set myCS SendToSensor" kann man Daten an den Sensor senden. Beispiel "set myCS SendToSensor 10,15" sendet die Bytes 10 und 15 an den Sensor.
Darauf antwortet der der Senor mit dem Ergebnis 25, was man dann als Ergebnis im reading "result" haben sollte.

Der LaCrosseITPlusReader10 Sketch sendet richtung CustomSensor immer mit 17242 kbps, egal, was für den "normalen" LaCrosse Betrieb aktuell konfiguriert ist.

Zu beachten: wenn man den Sketch toggeln lässt, kann es passieren, dass man die Antwort vom CustomSensor verpasst. Ideal für dieses Vorhaben ist ein SuperJee, bei dem man einen RFM dann fix auf 17241 kbps laufen lässt.

Und wichtig: das ist ein Beispiel, das die Technologie veranschaulicht, es hat erst dann einen Nutzen, wenn man sich etwas daraus weiterentwickelt, das etwas sinnvolles tut.

Hier noch ein list für das JeeLink modul und den CS.
Beim JeeLink sind die Attribute Clients und MatchList zu beachten, die gesetzt werden müssen, um den CustomSensor zu definieren.

Ihr könnt ja dann mal berichten,was ihr eigentlich gebaut habt.

Code Auswählen Erweitern

Internals:
   CustomSensorExample_lastRcv 2015-08-15 19:46:28
   DEF        0B
   IODev      myJeeLink
   LASTInputDev myJeeLink
   MSGCNT     1991
   NAME       myCS
   NR         195
   STATE      6
   TYPE       CustomSensorExample
   addr       0B
   myJeeLink_MSGCNT 1991
   myJeeLink_RAWMSG OK CC 11 2 46 0 0 7
   myJeeLink_TIME 2015-08-15 19:46:28
   CHANGETIME:
   Readings:
     2015-08-15 19:46:28   periodic        46
     2015-08-15 19:44:53   result          6
     2015-08-15 19:44:53   state           6
Attributes:
   IODev      myJeeLink
   room       .Test

Code Auswählen Erweitern

Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:CustomSensorExample
   DEF        /dev/ttyUSB0@57600
   DeviceName /dev/ttyUSB0@57600
   FD         4
   NAME       myJeeLink
   NR         12
   PARTIAL
   RAWMSG     OK 9 11 1 4 252 106
   STATE      Initialized
   TYPE       JeeLink
   model      [LaCrosseITPlusReader.10.1o (RFM12B f:868300 r:17241) + (RFM12B f:868300 t:20~6) + BMP180]
   myJeeLink_MSGCNT 108463
   myJeeLink_TIME 2015-08-15 19:45:44
   CHANGETIME:
   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
     7:CustomSensorExample ^OK\sCC\s
   Readings:
     2015-08-15 14:18:13   state           opened
Attributes:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:CustomSensorExample
   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", "7:CustomSensorExample" => "^OK\\sCC\\s" }
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   group      JeeLink
   initCommands 0m 0r 0t 6M 2R 20T 868300f 220h 0a v
   room       System

[fh168]

Hallo HCS,

vielleicht in diesem Thread etwas offtopic, ich habe mir mal eine Stand-Alone Lösung gebastelt mit dem MQ-7 Sensor.
Mal sehen, vielleicht kann man auch ein Jeelink-Sender jetzt noch mit dazu packen. Den Programm-Code von Dir schaue ich mir auf jeden Fall an. Hört sich interessant an. Vielleicht schreibe ich darüber, wenn er regulär eingecheckt ist.

Viel Spaß beim Lesen: http://blog.moneybag.de/rauchsensor-mq-7-mit-lcd-display-und-arduino-nano/

LG
/robin

[fh168]

bei den Clients fehlt mir noch das CustomsSensorsExample, muss ich da nochwas beachten?
Auf der Sender-Seite: Reicht ein RFM12B 868 MHz?
Auf der Empfänger-Seite: Reicht ein RFM12B 868 MHz oder müssen da zwei Transceiver auf dem Nano drauf sein?

Code Auswählen Erweitern

Clients
:PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110
DEF
/dev/ttyUSB0@57600
DeviceName
/dev/ttyUSB0@57600
FD
5
NAME
jeelinkcross
NR
5
PARTIAL
RAWMSG
OK WS 0 2 5 27 255 255 255 255 255 255 255 255 255 0 3 248
STATE
Initialized
TYPE
JeeLink
jeelinkcross_MSGCNT
71
jeelinkcross_TIME
2015-08-16 10:20:20
model
[LaCrosseITPlusReader.10.1o (RFM12B f:868300 t:30~7) + BMP180]

[HCS]

bei den Clients fehlt mir noch das CustomsSensorsExample, muss ich da nochwas beachten?

Musst Clients und Matchlist setzten, siehe mein Beispiel

Auf der Sender-Seite: Reicht ein RFM12B 868 MHz?

Ja

Auf der Empfänger-Seite: Reicht ein RFM12B 868 MHz oder müssen da zwei Transceiver auf dem Nano drauf sein?

Ich gehe mal davon aus, dass Du mit "Empfänger-Seite" FHEM meinst.
Da reicht ein RFM. Der muss aber fix auf 17241 kbps laufen.

[fh168]

Musst Clients und Matchlist setzten, siehe mein Beispiel
Ja
Ich gehe mal davon aus, dass Du mit "Empfänger-Seite" FHEM meinst.
Da reicht ein RFM. Der muss aber fix auf 17241 kbps laufen.

Clients und Matchlist über Attr einstellen... wieder was gelernt.

mit den 17241 komme ich klar, das sind ja die TX 29 DT-H Sensoren, togglen geht nicht? Wäre vielleicht wichtig zu wissen, wenn User mit den 30.3155 Sensoren arbeiten, die ja bekanntlich mit 9.579 arbeiten.

Noch was: Wofür ist die hex-Datei im zip? ich habe die auf meinem Jeelink-Clone mal geflashed, ist nix passiert. Ich dachte es wäre die o- Version oder höher.

Lustig: verbose=5 ... wieder 2 neue Sensoren gefunden (vom Nachbarn), bin mittlerweile bei 15 Stück .. ziemlich empfangsstark der Jeelink-Clone.

[fh168]

Ungewöhnlich... mal eben nachgebaut. funktioniert  !
Ich musste nur aus der 11 ein 0B machen, ist aber wohl bei jedem anders.

Code Auswählen Erweitern

CustomSensorExample_lastRcv
2015-08-16 12:36:54
DEF
0B
IODev
jeelinkcross
LASTInputDev
jeelinkcross
MSGCNT
9
NAME
myCS
NR
446
STATE
???
TYPE
CustomSensorExample
addr
0B
jeelinkcross_MSGCNT
9
jeelinkcross_RAWMSG
OK CC 11 2 37 0 0 7
jeelinkcross_TIME
2015-08-16 12:36:54
Readings
periodic
38
2015-08-16 12:37:04

[fh168]

ok, und wo muss ich den Programmcode ändern um 3 Zahlen zu übertragen?

Auf der Empfänger-Seite sollen dann 3 Readings erzeugt werden.

Es geht dabei um dieses Projekt: http://blog.moneybag.de/rauchsensor-mq-7-mit-lcd-display-und-arduino-nano/

Möglicherweise wäre es für andere User auch interessant, wenn sie was übertragen wollen.
Hardwaremäßig dürfte es alles passen, LCD, Sensor und RFM12b kommen sich nicht in die Quere.

[Wzut]

@HCS, ersteinmal vielen Dank für deine umfangreiche Vorarbeit, werde mir das alles in Ruhe anschauen und testen.
Bei meinem aktuellen Projekt geht es um diei Ablösung eines einfachen Wandthermostaten für eine elektische Fussboden Zusatzheizung.
Im ersten Schritt wollte ich als Fake TX25 zwei Temp Werte schicken ( Soll und Ist ) , wenn das läuft kommt die Gegenrichtung ins Spiel wie z.B. neuer Sollwert.   

[HCS]

Noch was: Wofür ist die hex-Datei im zip? ich habe die auf meinem Jeelink-Clone mal geflashed, ist nix passiert. Ich dachte es wäre die o- Version oder höher.

Das ist das compilierte CustomSensorExample.
Der LaCrosse-Sketch 10.1o ist im FHEM Repository eingecheckt und kann ganz normal mit set myJeeLink flash geflasht werden

Ich musste nur aus der 11 ein 0B machen, ist aber wohl bei jedem anders.

Hatte ich auch falsch hingetippt. 0B ist richtig.

ok, und wo muss ich den Programmcode ändern um 3 Zahlen zu übertragen?

So (Beispiel für drei Bytes):

Code Auswählen Erweitern

frame.ID = 0xB;
frame.NbrOfDataBytes = 3;
frame.Data[0] = 10;
frame.Data[1] = 20;
frame.Data[2] = 30;


In NbrOfDataBytes eine beliebige Anzahl Bytes setzen (max. 128) und dann die Bytes in frame.Data reinpacken

Wenn es mit dem Beispiel-Modul für FHEM kompatibel sein soll, dann so, um z.B. die Werte 10, 20 und 30 zu senden:

Code Auswählen Erweitern

frame.ID = 0xB;
frame.NbrOfDataBytes = 4;
frame.Data[0] = 2;
frame.Data[1] = 10;
frame.Data[2] = 20;
frame.Data[3] = 30;



[fh168]

Teilweiser Erfolg.
Mein LCD-Display (LiquidCrystal.h) hakt mit dem RFM12B. Es wurde nichts übertragen. Ich habe die Library vom LCD-Display erst mal entfernt, jetzt klappt es.

Aber nach dem Define steht in den Readings immer noch periodic. Die Werte scheinen aber rüberzukommen. Da sollten ja 3 neue Readings auftauchen.

Jetzt wirft er das raus:

Code Auswählen Erweitern

jeelinkcross_MSGCNT
18
jeelinkcross_RAWMSG
OK CC 11 2 0 0 0
jeelinkcross_TIME
2015-08-16 18:51:11
Readings
periodic
0
2015-08-16 18:55:08

[HCS]

Aber nach dem Define steht in den Readings immer noch periodic. Die Werte scheinen aber rüberzukommen. Da sollten ja 3 neue Readings auftauchen.

Nein, sollten nicht.

Ich befürchte, das Ganze wurde falsch verstanden. Das 36_CustomSensorExample.pm ist ein Beispiel, das absolut keinen vernünftigen Zweck erfüllt und lediglich als Vorlage für ein eigenes Modul dient. Wenn Du einen Sensor erfindest, dann musst Du Dir ein dazu passendes Modul schreiben, und 36_CustomSensorExample.pm ist die Vorlage, die zeigt, wie man so was machen kann.

Für den CustomSensorExample Sketch gilt das ebenfalls, er ist die Vorlage, um sich daraus einen eigenen Sensor zu bauen.

Oder in anderen Worten: der Sketch und das Modul zeigen, wie die Technologie funktioniert, sind aber beide nichts, das man so wie sie sind, für etwas Vernünftiges verwenden könnte.

Und der eigentliche Focus war das Senden von Daten an den Sensor.

[fh168]

ok, habe ICH falsch verstanden. Andere wahrscheinlich nicht, bin halt der typische Anwender. Und im Grunde funktioniert alles.
Trotzdem super Arbeit von Dir! Und prima Support. Ich bin mit dem BMP180 Jeelink schon glücklich.

LG und Daumen hoch!
/robin

[Wzut]

Zum zurück senden werde ich erst die Tage kommen, mein Wandthermostat verhält sich schon mal wie ein echter TX29IT.
Hier mal ein Beispiel in aller einfachster Form wie man so einen Fake TX29IT mit einem RFM12 / RFM69CW  und einem Arduino bauen kann :

Code Auswählen Erweitern


#include "RFMxx.h"
#define TRANSMIT_INTERVAL     15    // Transmit interval in seconds
#define SENSOR_ID                       1   // 1 - 63
 
RFMxx rfm(11, 12, 13, 10,2);   

byte bytes[5];
float Temperature;
byte Hum;

void setup() {
   delay(200);
  // Initialize the RFM12
  rfm.InitialzeLaCrosse();
  Serial.begin(38400);
  Serial.println(rfm.GetRadioName());
}

void loop() {
  if (rfm.GetRadioName() == "RFM69CW") 
  { Temperature = rfm.GetTemperature();}
   else
  { Temperature = 12.3; }

  Hum = (micros() >> 24) & 0x7F;

   // Encode it
  EncodeFrame(bytes);
 
   // Send with all configured data rates
    rfm.SetDataRate(17241ul);
    rfm.SendArray(bytes, 5);
    rfm.SendArray(bytes, 5);
    rfm.SetDataRate(9579ul);
    rfm.SendArray(bytes, 5);
    rfm.SendArray(bytes, 5);

  Serial.print(Temperature);
  Serial.print(" | ");
  Serial.println(Hum);
 
  delay(TRANSMIT_INTERVAL * 1000);
}

void EncodeFrame(byte *bytes) {
/* Message Format:
*
* .- [0] -. .- [1] -. .- [2] -. .- [3] -. .- [4] -.
* |       | |       | |       | |       | |       |
* SSSS.DDDD DDN_.TTTT TTTT.TTTT WHHH.HHHH CCCC.CCCC
* |  | |     ||  |  | |  | |  | ||      | |       |
* |  | |     ||  |  | |  | |  | ||      | `--------- CRC
* |  | |     ||  |  | |  | |  | |`-------- Humidity
* |  | |     ||  |  | |  | |  | |
* |  | |     ||  |  | |  | |  | `---- weak battery
* |  | |     ||  |  | |  | |  |
* |  | |     ||  |  | |  | `----- Temperature T * 0.1
* |  | |     ||  |  | |  |
* |  | |     ||  |  | `---------- Temperature T * 1
* |  | |     ||  |  |
* |  | |     ||  `--------------- Temperature T * 10
* |  | |     | `--- new battery
* |  | `---------- ID
* `---- START = 9
*/

uint8_t i, j, k ,val;
for ( i = 0; i < 5; i++) { bytes[i] = 0; }

  // ID
  bytes[0] = 9 << 4;
  bytes[0] |= SENSOR_ID >> 2;
  bytes[1] = (SENSOR_ID & 0b00000011) << 6;

  // Temperatur
  float temp = Temperature + 40.0;
  bytes[1] |= (int)(temp / 10);
  bytes[2] |= ((int)temp % 10) << 4;
  bytes[2] |= (int)(fmod(temp, 1) * 10 + 0.5);

  // Feuchte
  bytes[3] =  Hum & 0x3f ;

  // CRC
  for (j = 0; j < 4; j++)
  {
    val = bytes[j];
    for (i = 0; i < 8; i++)
    {
      k = (uint8_t)((bytes[4] ^ val) & 0x80);
      bytes[4] <<= 1;
      if (0 != k) { bytes[4] ^= 0x31; }
      val <<= 1;
    }
  }
}


[HCS]

Ups, die GetTemperature() habe ich gerade aus RFMxx zwecks Reduzierung der Größe ausgebaut, da ich dachte , dass die eh keiner braucht, weil niemand die Temperatur eines sich beim Senden erwärmenden radio wissen will.

Brauchst Du die ernsthaft oder kann ich es dabei belassen?

[Wzut]

*lach* , das war doch nur ein Beispiel um einen halbwegs sinnvollen Wert zu senden
Ich denke mal wer sich so einen Fake zusammenbaut hat "echte" Quellen die einen Temperaturwert liefern.

[HCS]

Gut dass wir uns da einig sind 

Wenn Du einen TX29 o.Ä. simulierst, müsstest Du eigentlich meine LaCrosse Klasse verwenden können, um den frame zu encoden. Das würde noch etwas aus diesem Sketch rausnehmen, das es schon gibt.

[Wzut]

Sodele , gestern Abend hatte ich nun endlich die Zeit mir den CustomSensor vorzunehmen.
Erstes Fazit : schaut verdammt gut aus !!
Was mir besonders gefällt  : die Telegrammlänge von fhem zum Sensor ist variabel
Ich werde hier wieder Bericht erstatten wenn das Wand-Thermostat Projekt etwas weiter fortgeschritten ist. Jetzt erst einmal 1000 Dank für deine tolle Arbeit, das ist ein prima Grundbaukasten zum weiteren Basteln.   

[HCS]

Was mir besonders gefällt  : die Telegrammlänge von fhem zum Sensor ist variabel

Die vom Sensor Richtung FHEM auch

Viel Erfolg

[user1]

Danke für die Implementierung. Ich bin nun soweit, dass meine Hardware senden und empfangen kann, allerdings verwende ich 9579 Baud, da dies die einzige Frequenz ist die bei mir im Einsatz ist.

Deshalb meine Frage:

> Der LaCrosseITPlusReader10 Sketch sendet richtung CustomSensor immer mit 17242 kbps, egal, was für den "normalen" LaCrosse Betrieb aktuell konfiguriert ist.

Weshalb nicht die eingestellte Baudrate verwenden, jedenfalls wenn kein "toggle" eingestellt ist? Das scheint mir eine unnötige Einschränkung zu sein.

Habe jetzt erst mal für meine Zwecke die Firmware mit abgeänderter Baudrate übersetzt.

[HCS]

Weshalb nicht die eingestellte Baudrate verwenden, jedenfalls wenn kein "toggle" eingestellt ist? Das scheint mir eine unnötige Einschränkung zu sein.

Weil ich auf die Idee schlicht nicht gekommen bin

Kann ich einbauen.

Zusätzlich (oder alternativ?) könnte ich auch ein Kommando (das man dann in die initCommands setzen kann) bereitstellen, um die data rate für das Senden festzulegen.
z.B. so: 9579c

[user1]

Die Sendebaudrate auswählen zu können wäre natürlich eine gute Sache.

Eine andere Frage: Ich kriege das Beispiel mit dem Modul "36_CustomSensorExample.pm" nicht zum laufen... irgendetwas klappt mit dem einbinden von des CustomSensorExample nicht.

## folgendes geht:
define XYZ LaCrosse 3C
attr XYZ IODev myJeeLink

## aber hier gibt's einen Fehler:
define myCS CustomSensorExample 0B
attr myCS IODev myJeeLink

## im log file steht dann:
2015.09.08 21:46:36 1: myCS: no I/O device

Leider blicke ich in FHEM nicht so recht durch, wie die verschiedenen Teile hier zusammenspielen...

[Wzut]

## aber hier gibt's einen Fehler:
define myCS CustomSensorExample 0B

Ahh ja ... und wir dürfen/sollen nun raten wie der Fehler aussieht und was man dagegen tun kann ?

[user1]

Also nochmals eine detailliertere Zusammenfassung:

Ich versuche, 36_CustomSensorExample.pm zu verwenden. Eine Node sendet Daten, welche der JeeLink auch empfängt (ich sehe "OK CC ...", wenn ich direkt über ttyUSBx connecte und den Output des JeeLinks anschaue).

Mir gelingt es nun aber nicht, diese Meldung in FHEM zu verwenden. Im config-File habe ich besagte Zeilen:

Code Auswählen Erweitern


define myCS CustomSensorExample 0B
attr myCS IODev myJeeLink


Im Log-File erhalte ich aber

Code Auswählen Erweitern


(...)
1: myCS: no I/O device
(...)
3: myJeeLink: Unknown code OK CC 11 119 , help me!


Meiner Vermutung ist nun, dass die Message nicht korrekt dispatched wird, und deshalb nicht in CustomSensorExample landet, weil dieser eben nicht mit dem JeeLink assoziert ist.

Über "attr IODev" (wie das bei z.B. LaCrosse klappt) funktioniert das nicht, siehe oben.

Frage: Was mache ich hier falsch, bzw. wie komme ich zum Ziel?

Danke für Input.

[user1]

Funktioniert jetzt alles mit zusätzlich gesetzter MatchList, von daher erledigt.

Seltsam sind die Logeinträge beim Starten aber trotzdem, auch wenn sie keine Konsequenz haben:

Code Auswählen Erweitern


1: myCS: no I/O device
(...)
3: No I/O device found for myCS


[HCS]

Seltsam sind die Logeinträge beim Starten aber trotzdem, auch wenn sie keine Konsequenz haben

Keine Ahnung wo es bei Dir klemmt.
Hast Du in der fhem.cfg den "define myCS ..." evtl. von Hand vor den "define myJeeLink ..." gepackt?

Bei mir sieht das so aus:

Code Auswählen Erweitern

2015.09.09 11:29:17 1: Including fhem.cfg
2015.09.09 11:29:17 3: telnetPort: port 7072 opened
.
.
2015.09.09 11:29:18 3: Opening myJeeLink device /dev/ttyUSB0
2015.09.09 11:29:18 3: Setting myJeeLink serial parameters to 57600,8,N,1
2015.09.09 11:29:18 3: myJeeLink device opened
.
.
2015.09.09 11:29:22 3: NodeSensors: I/O device is myJeeLink
2015.09.09 11:29:23 3: myCS: I/O device is myJeeLink
.
.


Funktioniert jetzt alles mit zusätzlich gesetzter MatchList, von daher erledigt.

Hatte ich doch geschrieben:

...
Beim JeeLink sind die Attribute Clients und MatchList zu beachten, die gesetzt werden müssen, um den CustomSensor zu definieren.
...

[user1]

Wegen der fehlenden MatchList: war mein Fehler, hatte ich übersehen.

Was den log-Eintrag angeht: Die Meldung war weil ich auch den Clients-Eintrag nicht richtig gesetzt hatte war wohl etwas spät...

Die LaCrosse-Jeelink Firmware habe ich unterdessen an meine Zwecke angepasst. Dabei sind mir zwei Dinge aufgefallen

- RFMxx::ClearFifo() ist als bool deklariert, liefert aber keinen Wert zurück. Hat keine Bedeutung, aber der Compiler warnt:

Code Auswählen Erweitern


bool RFMxx::ClearFifo() {
  if (IsRF69) {
    WriteReg(REG_IRQFLAGS2, 16);
  }
  else {
    for (byte i = 0; i < PAYLOADSIZE; i++) {
      spi16(0xB000);
    }
  }
}


- In CustomSensor::SendFrame wird rfm 'by value' übergeben, und nicht als Pointer oder Referenz, was mir eigenartig erscheint:

Code Auswählen Erweitern


void CustomSensor::SendFrame(struct CustomSensor::Frame *frame, RFMxx rfm) { ... }



Zur Frage, was das Ganze am Ende gibt:

Ein Mikrokontroller wird bei meiner Heizung Funktionen umschalten (via Relais). Gleichzeitig überwacht er Temperatur und Feuchtigkeit im Keller und kann Lüftung bzw. Entfeuchter anwerfen. Da diese Funktionen wichtig sind, habe ich einen Rückkanal implementiert. Die gesamte Kommunikation läuft über LaCrosse-5-Byte Frames, da ich bereits ein paar TechnoLine-Sensoren im Einsatz habe und einen Protokoll-Zoo vermeiden möchte. Drei Bytes Nutzdaten reichen mir allemal. Statt der '9' im ersten Nibble sind jetzt auch je ein Werte für Custom Frames und für Rückkanal vorgesehen (das Acknowedge geht so, dass der Empfänger bei Erhalt das erste Nibble abändert, die CRC neu berechnet, und das Frame direkt wieder zurücksendet).

Die Behandlung des Rückkanals findet vollständig im Jeelink statt (in einer Funktion, die von loop() aus aufgerufen wird). Diese sendet die Frames wiederholt in definierbaren Intervallen, bis ein Acknowledge vom Empfänger kommt (z.B. alle 100ms, z.B. max 10 Mal). Die ACK-Meldung wird an FHEM durchgereicht, bzw. ein NAK wenn keines eintrifft. Damit lassen sich auch Nodes sicher "aufwecken", welche im stromsparenden Listen-Modus des RFM69 warten; der Preis dafür ist dann eine gewisse Latenz.

Danke für das Beipiel mit dem CustomSensor, und die diversen Posts.

[HCS]

- RFMxx::ClearFifo() ist als bool deklariert, liefert aber keinen Wert zurück. Hat keine Bedeutung, aber der Compiler warnt:

Habe es für die kommende Version geändert. Seltsam, dass ich da keine Compiler Warnung sehe.

- In CustomSensor::SendFrame wird rfm 'by value' übergeben, und nicht als Pointer oder Referenz, was mir eigenartig erscheint:

Im Prinzip ist es egal, an der RFM Instanz wird ja in der SendFrame nichts geändert. Habe es aber geändert, dann spart es etwas Arbeitsspeicher.

Ein Mikrokontroller wird bei meiner Heizung Funktionen umschalten (via Relais). Gleichzeitig überwacht er Temperatur und Feuchtigkeit im Keller und kann Lüftung bzw. Entfeuchter anwerfen ...

Off Topic:
Etwas ganz ähnliches habe ich hier auch laufen, allerdings auf einer völlig anderen Basis:
Die Steuerung der Heizung läuft im Heizungskeller auf einem Android-Tablet als Android-App, das per IOIO (https://www.sparkfun.com/products/12633) über Relais zum Steuern der Heizung, Optokopplern für die Eingänge um Ist-Zustände zu haben, Temperatursensoren usw. mit der Heizung und dem Rest im Keller kommuniziert. Diese Steuerung läuft völlig Autark. Vorteil: Das Tablet als Steuerung hat sozusagen Display, USV, WiFi usw. schon integriert und braucht kein FHEM, um die Heizung sinnvoll weiter zu fahren. Es stellt einen REST Web Service zur Verfügung, über den FHEM sich die aktuellen Werte abholt und Soll-Vorgaben setzen kann.

Wie das in FHEM mit SmartVisu als Frontend aussieht, kann man hier sehen (http://fhem.de/SmartVisu.png), in den Blöcken mit dem Titel "Heizung"

[HCS]

Die Sendebaudrate auswählen zu können wäre natürlich eine gute Sache.

Die gute Sache wurde impementiert.
Siehe hier: http://forum.fhem.de/index.php/topic,14786.msg340076.html#msg340076

[DokHasenbein]

Hallo,

Entschuldigung, dass ich dieses Thema wieder neu anfasse. Ich versuche mich gerade an einem kleinen Bastelprojekt zum etablieren einer FHEM zu IR Funkstrecke (um meine alte Stereoanlage steuern zu können). Ich habe das Beispielprojekt erfolgreich nachgebaut, allerdings nur mit der 10.1o Firmware auf dem Jeelink-Nachbau. Mit der aktuellen 10.1q funktioniert es nicht mehr.
Es werden zwar die periodischen Sendungen vom CustomSensorExample empfangen, das Senden scheint aber nicht richtig zu funktionieren, denn es kommt keine Antwort vom CustomSensorExample.

[HCS]

Mit der aktuellen 10.1q funktioniert es nicht mehr.
Es werden zwar die periodischen Sendungen vom CustomSensorExample empfangen, das Senden scheint aber nicht richtig zu funktionieren, denn es kommt keine Antwort vom CustomSensorExample.

Ich schaue mal, warum das so sein könnte.
Verwendest Du RFM12 oder RFM69?

[DokHasenbein]

Vielen Dank. Ich verwende einen RFM12.

[HCS]

Ich kann das Problem nicht nachvollziehen.
Habe auf einen JeeLink die 10.1q geflasht

Code Auswählen Erweitern

[LaCrosseITPlusReader.10.1q (RFM69 f:868300 r:17241)]
und auf den Anderen das original CustomSensorExample.

wenn ich ein

Code Auswählen Erweitern

11,4,5s
sende, kommt ein

Code Auswählen Erweitern

OK CC 11 1 9
zurück.

OK, hat sich überschnitten. Dann probiere ich es mal anders herum.
Also mit dem JeeLink-Sketch auf dem RFM12 und demCustomSensorExample auf dem RFM69 (habe nur einen mit RFM12)

[HCS]

Ich verwende einen RFM12.

So rum kann ich es anchvollziehen. Die Senderei auf dem RFM12 geht wohl nicht mehr.
Ich schaue mal, ob man es reparieren kann.

Hast ja aber aktuell zwei Optionen:
- 10.1o nehmen
- RFM69 nehmen

[DokHasenbein]

Bin erstmal beruhigt, dass der Fehler nicht bei mir liegt (was ich natürlich erst nach einigen Tagen rumprobieren rausgekriegt habe). Ich habe jetzt die 10.1o in Betrieb. Hat das irgendwelche gravierenden Nachteile? Ich benutze sonst nur LaCrosse-TempHum-Sensoren und jetzt eben den IR-Sender-Prototypen damit.

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