LaCrosse für CUL

[juergs]

2018-05-21 13:14:27 JeeLink my_jeelink UNKNOWNCODE OK CC 6 6 24 53 16 1 1 119 0 0 80 86 137 0

Ist der SensorTyp: "CC" und nicht "09" bei mir .... => " 4:LaCrosse ^(\S+\s+9 |OK\sWS\s)"
Siehe auch hier: https://forum.fhem.de/index.php/topic,39920.msg747663.html#msg747663
und hier: https://gitlab.cs.fau.de/PoempelFox/foxtemp2016/raw/master/36_Foxtemp2016viaJeelink.pm
zum Gerätetyp "CC".

JeeLink mit RFM12:

Code: [Auswählen]

Internals:
   Clients    :PCA301:EC3000:RoomNode:LaCrosse:ETH200comfort:CUL_IR:HX2272:FS20:AliRF:Level:EMT7110:KeyValueProtocol
   DEF        COM21@57600
   DeviceName COM21@57600
   NAME       my_jeelink
   NR         3
   PARTIAL   
   RAWMSG     OK CC 6 6 24 53 16 1 1 119 0 0 80 86 137 0
   STATE      initialized
   TYPE       JeeLink
   initMessages
   model      LaCrosseITPlusReader.10.1q
   my_jeelink_MSGCNT 2
   my_jeelink_TIME 2018-05-21 13:14:27
   settings   (RFM12 f:868300 r:17241)
   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:KeyValueProtocol ^OK\sVALUES\s
   READINGS:
     2018-05-21 13:14:27   state           initialized
Attributes:
   flashCommand avrdude -p atmega328P -c arduino -P [PORT] -D -U flash:w:[HEXFILE] 2>[LOGFILE]
   initCommands 30t
   room       HARDWARE,RECEIVER, JEELINK

/
^(\S+\s+9 |OK\sWS\s)
/
gm
^ asserts position at start of a line
1st Capturing Group (\S+\s+9 |OK\sWS\s)
1st Alternative \S+\s+9
\S+
matches any non-whitespace character (equal to [^\r\n\t\f\v ])
+ Quantifier — Matches between one and unlimited times, as many times as possible, giving back as needed (greedy)
\s+
matches any whitespace character (equal to [\r\n\t\f\v ])
+ Quantifier — Matches between one and unlimited times, as many times as possible, giving back as needed (greedy)
9 matches the characters 9 literally (case sensitive)
2nd Alternative OK\sWS\s
OK matches the characters OK literally (case sensitive)
\s matches any whitespace character (equal to [\r\n\t\f\v ])
WS matches the characters WS literally (case sensitive)
\s matches any whitespace character (equal to [\r\n\t\f\v ])
Global pattern flags
g modifier: global. All matches (don't return after first match)
m modifier: multi line. Causes ^ and $ to match the begin/end of each line (not only begin/end of string)

[Hallmackenreuther]

Hallöchen,

ich bin auch an dem Punkt, wo es "Unknown code" regnet und kein Autocreate stattfindet.
Wenn ich die Vorposts richtig verstehe, müsste ich unter "MatchList:" LaCrosse finden (trifft nicht zu) und andernfalls neu kompilieren, wo es bei mir mit der Erfahrung aufhört.
Gibt es dazu eine Schritt-für-Schritt Erklärung mit benötigtem Material, idealerweise unter Windoofs?

Code: [Auswählen]

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   CUL_3_MSGCNT 1374
   CUL_3_TIME 2018-06-02 03:06:08
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.1.18:2323 0100
   DeviceName 192.168.1.18:2323
   FD         35
   FHTID      0100
   NAME       CUL_3
   NR         44
   PARTIAL   
   RAWMSG     N019C26296A78AAAA000048F49A
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: 300 (2018-04-15_20-15-39) CUBe (F-Band: 868MHz)
   initString X21
   MatchList:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-06-01 18:27:08   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-06-02 03:00:25   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2018-06-02 02:58:59   raw             No answer
     2018-06-02 03:06:08   state           Initialized
Attributes:
   rfmode     SlowRF

[locutus]

ich bin auch an dem Punkt, wo es "Unknown code" regnet und kein Autocreate stattfindet.

Ich besitze zwar keinen CUBe, aber in board.h fehlt definitiv die HMS Device Emulation für LaCrosse:

Code: [Auswählen]

#define LACROSSE_HMS_EMU

... andernfalls neu kompilieren, wo es bei mir mit der Erfahrung aufhört.
Gibt es dazu eine Schritt-für-Schritt Erklärung mit benötigtem Material, idealerweise unter Windoofs?

Und hier die richtige Anlaufstelle:
https://forum.fhem.de/index.php/topic,38404.0.html

[Hallmackenreuther]

Hallo locutus,

ich war inzwischen etwas weiter und hatte die Änderung vorgenommen, aber bei verschiedenen Versuchen ist das an verschiedenen Stellen fehlgeschlagen.
Ich wende mich dann an den verlinkten Thread - sehr herzlichen Dank für Deine Antwort!

[juergs]

Noch zur Info:
Arnd hat hier eine LaCrosse-Version der Alternative-CULFW für den nanoCUL (CC1101 mit 868MHz) gebaut:
Forum

[subseven]

Gibt es eine Möglichkeit das

Code: [Auswählen]

set rav Nr1 als initString oder so zu setzen? Immer nach einem reconnect oder reboot muss das Kommando eingegeben werden. Derzeit löse ich das mit einem Notify, was natürlich nicht ganz elegant ist.

[juergs]

Hallo SubSeven,
ich vermute, man kann dieses Init in die Initialisierungsroutine mit hinein nehmen, um diesen Modus dauerhaft zu halten.

Allerdings bin ich schon seit einiger Zeit auf die LaCrosseGateway umgestiegen, welche komfortablere Möglichkeiten in Bezug auf LaCrosse-Sensoren bietet.

https://forum.fhem.de/index.php/topic,45594.750.html
https://forum.fhem.de/index.php/topic,51329.msg935676.html#msg935676

[subseven]

Danke für die Info.

Vom LaCrosseGateway bin ich gerade wieder weg... Die Variante auf dem Maple gefällt mir besser, da ich ein zusätzliche Gerät sparen kann.

EDIT:
Hab das benötigte Attribut gefunden
connectCommand Nr1

[MrAlbi]

Hallo zusammen,
habe per nanoCUL (868Mhz) und a-culfw einen TX29-IT Temperatur-Sensor eingerichtet. Per at-Befehl setze ich alle 10 Minuten

Code: [Auswählen]

set CUL868 raw Nr1, damit die Werte aktuell bleibt. Das funktioniert alles schon mal sehr gut. Es gibt aber auch noch andere Sensorgen, die über "Nr2" senden.
In der Doku zu Jeelink habe ich gesehen, dass man zwischen den Datenraten automatisch alle X Sekunden wechseln lassen kann. Geht so etwas für den nanoCUL auch?
Gruß Dirk

[subseven]

Das geht nicht autonatisch. Entweder du brauchst ein weiteres CUL oder du musst das Umschalten zwischen den Modi selbst bewerkstelligen

[MrAlbi]

Da es keine automatische Umschaltung gibt, habe ich mir den folgenden at-Befehl erstellt, der durch die unterschiedlichen Datenraten schaltet.

Code: [Auswählen]

+*00:15 {fhem "set CUL868 raw Nr1; set CUL1 raw Nr1; sleep 300; set CUL868 raw Nr2; set CUL1 raw Nr2; sleep 300; set CUL868 raw Nr3; set CUL1 raw Nr3"}

[subseven]

Deine Lösung kann ich so nicht ganz nachvollziehen. Wenn du eh zwei CULs hast und nur Lacrosse empfangen willst reicht dir ein
set CUL868 raw Nr1; set CUL1 raw Nr2
doch aus. Nr3 Brauchst du für PCA301 Dosen. und ein "set" des selben Modus zur selben Zeit macht nur Sinn, wenn die CULs weit auseinander sind und du somit die Empfangsreichweite erhöhen willst.

[RaspiLED]

Hi,
Oder einer 433 und einer 868 MHz hat.
Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...

[MrAlbi]

Der CUL868 ist ein 868Mhz NanoCUL, der CUL 1 ist bei mir ein 433Mhz NanoCUL. Die Nr3 setze ich bei mir nicht, habe sie nur der Vollständigkeithalber mit im Code gepostet.

[subseven]

Ich hab jetzt ein merkwürdiges Verhalten nach einem Batteriewechsel festgestellt.

Alle Sensoren hatten bis zu diesem Zeitpunkt bei den beiden Batterie-Readings:

Code: [Auswählen]

battery:  ok
batteryState:  ok
Nach dem Tausch der Batterien an einem Sensor wird dieser, durch die neue ID, neu erkannt. Allerdings sind die Readings nun anders:

Code: [Auswählen]

battery:  replaced
batteryState:  ok
Das Problem ist, dass nun mein Batterie-Notify und auch meine Readingsgroups nicht mehr korrekt funktionieren. Wenn möglich würde ich diese auch nicht ändern müssen. Eigenartig finde ich, dass die anderen Sensoren weiterhin wie gewohnt die erst genannten Werte liefern.
Im Forum habe ich dazu nichts brauchbares gefunden (https://forum.fhem.de/index.php/topic,37047.msg293319.html / https://forum.fhem.de/index.php/topic,80859.msg729150.html)

Hat jemand einen Lösungsansatz für mich?

Edit: Nach ein paar Stunden ist der Wert wieder auf "ok" zurückgegangen. Also hat nach einem Batteriewechsel das Device eine Zeitlang den Wert "replaced" für das Reading. Damit kann ich leben. Problem somit für mich gelöst