Native RF mode Nr2 bringt nur UNKNOWNCODE

[dad401]

Hallo,

ich habe heute auf die neueste Fw geupdatet, so dass mein CUL (Busware V3) nun auch den "N" Befehl (Native RF mode) versteht.

Ein Setzen von Nr1 oder Nr2 liefert auch erstmal CUL868 UNKNOWNCODE 01 bzw. 02.
Nach einem Test mit Nr2 bekomme ich aber im EventMonitor folgende Meldungen:

Code Auswählen Erweitern

2016-11-08 18:37:22 CUL CUL868 UNKNOWNCODE N029784536A0DAFFD084B6AD47E
2016-11-08 18:37:23 CUL CUL868 UNKNOWNCODE N029F84786AD7A93DC19EA9E900
2016-11-08 18:37:32 CUL CUL868 UNKNOWNCODE N029784536A0DABBE42EE3F9E7C
2016-11-08 18:37:33 CUL CUL868 UNKNOWNCODE N029F84786AD7AECDB48A6922E9
2016-11-08 18:37:42 CUL CUL868 UNKNOWNCODE N029784536A0DAF09066BCCD9E2
2016-11-08 18:37:43 CUL CUL868 UNKNOWNCODE N029F84786AD7AA3EF58D49DE52
2016-11-08 18:37:53 CUL CUL868 UNKNOWNCODE N029F84786AD7AB9E5C298838E4


Trotz autocreate wird aber kein Device etc. angelegt.

Muss ich hierfür in jedem Fall

Code Auswählen Erweitern

/#  define LACROSSE_HMS_EMU in der board.h auskommentieren? Was bewirkt dieses define eigentlich genau?

Geflasht habe ich die V1.66 von http://culfw.de/culfw.html.
Nutze ich die aktuelle SVN Version, meckert er beim Flashen meiner Meinung nach wegen der Größe (boot overlap etc.).

Ich vermute die Meldungen sind von meiner Bresser Wetterstation - es wäre schön, wenn ich diese in FHEM einbinden könnte.

[KölnSolar]

Was der CUL so alles kann  Nur: fhem hat (noch) kein Modul für die Verarbeitung des modes  Musst Du wohl Pionierarbeit leisten.
Grüße Markus

[dad401]

Mhh, ein erster Anhaltspunkt wäre ja das Message-Format aus der lacrosse.c (culfw):

/*
* Message Format:
*
* .-

• -. .- [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
  *
  */
  => besser hier nachsehen, da dort nichts verschoben ist.
  
  Aber irgendwie bekomme ich das nicht einer Message zugeordnet:
  Beispiel wo N02 schon entfernt ist: 9784536A0DAFFD084B6AD47E
  Dies sind doch dann 12 Byte?
  97 84 53 6A 0D AF FD 08 4B 6A D4 7E
  
  Was entsprechen dann diese Blöcke - wenn SSSS der 9 entspräche, wäre es ja das erste Nibble von 97 - aber 24 Nibbles sind es dann auch wieder nicht?
  SSSS.DDDD DDN_.TTTT TTTT.TTTT WHHH.HHHH CCCC.CCCC
  

[KölnSolar]

Warum Lacrosse ? Bedenke, dass es einige Protokolle gibt, die sich Lacrosse schimpfen. Ich würd nach Bresser googeln(hast Du bestimmt auch schon gemacht) und mir ein manuelles Log anlegen: CUL-Daten und zeitlich die Daten der Bresser dazu. Und dann versuchen ein Muster zu erkennen. Beginnend mit den sich nicht ändernden Bytes/Nibbles, über selten bis häufig. Außerdem könntest Du mal set CUL raw X67 ausführen. Das versetzt den CUL in den Debug-Modus und Du solltest einiges mehr an Info im Log/Event-Monitor bekommen.