Hauptmenü

LaCrosse für CUL

Begonnen von tostmann, 23 April 2015, 01:44:34

Vorheriges Thema - Nächstes Thema

mac973

Nachtrag:
Jetzt kommen wieder Einträge
CUL2: unknown message N0295263630ADFEFFFF7FFFFFFF
Im Abstand von meist 5 Sekunden.

Habe allerdings 3 Thermometer aufgestellt, ist aber kein Unterschied der Einträge ersichtlich.

Gruß
Sascha

x000x

#16
moin moin,

vorweg - ich bin erst gestern in das Thema "Home-Automatisierung" eingestiegen. Die Woche vorher hatte ich mir diverse Hardware bestellt - unter anderem auch ein "Technoline TX 29 DT-HT" und ein CUL V3 868.

Habe hier nun die Anleitung gefunden wie ich dem TX29 unter fhem nutzen könnte - kompilieren hat soweit wohl auch alles gut funktioniert. Beim einspielen der Firmware auf den CUL habe ich dann allerdings folgenden Fehler bekommen:
$ make usbprogram_v3
dfu-programmer atmega32u4 erase || true
dfu-programmer atmega32u4 flash CUL_V3.hex
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore
make: *** [do_usbprogram] Error 1


Habe nun vermutet, dass die erstellte Firmware zu groß ist für meinen CUL... Also habe ich in der board.h noch folgende Zeilen aaskommentiert:
//#  define HAS_MBUS
//#  define MBUS_NO_TX

Ich habe keine Ahnung was ich damit jetzt rausgenommen habe (hab auch nicht weiter recherchiert). Diesmal hat das einspielen der Firmware funktioniert.

Dann bin ich in fhem wie in diesem Thread beschrieben vorgegangen und erhalte nun in der log folgende Ausgaben:
2015.10.18 15:08:02 3: set nanoCUL raw Nr1
2015.10.18 15:08:02 4: CUL_send:  nanoCULNr 1     
2015.10.18 15:08:02 5: CUL/RAW: /01

2015.10.18 15:08:02 4: CUL_Parse: nanoCUL 0 1     
2015.10.18 15:08:02 2: nanoCUL: unknown message 01
2015.10.18 15:08:06 5: CUL/RAW: /N019E06183B0FAAAA0000FADAA2

2015.10.18 15:08:06 4: CUL_Parse: nanoCUL N 01 9E 0618 3B0FAA AA0000 FADAA2
2015.10.18 15:08:06 2: nanoCUL: unknown message N019E06183B0FAAAA0000FADAA2
2015.10.18 15:08:06 5: CUL/RAW: /H433800180259FF

2015.10.18 15:08:06 4: CUL_Parse: nanoCUL H 43 38 0018 0259FF   -74.5
2015.10.18 15:08:06 5: nanoCUL dispatch 810e04xx0510a0014338000000180259
2015.10.18 15:08:06 4: HMS device 4338 not defined, using the wildcard device 1000
2015.10.18 15:08:06 3: Unknown HMS device 1000/4338, please define it
2015.10.18 15:08:06 2: autocreate: define HMS100TF_4338 HMS 4338
2015.10.18 15:08:06 2: autocreate: define FileLog_HMS100TF_4338 FileLog ./log/HMS100TF_4338-%Y.log HMS100TF_4338:T:.*
2015.10.18 15:08:06 2: autocreate: define SVG_HMS100TF_4338 SVG FileLog_HMS100TF_4338:temp4hum6:CURRENT
2015.10.18 15:08:15 5: CUL/RAW: /A1E70FACF18412C86DC8A00602440355C4E823EBE9EBA1161A158C16A320304F
2015.10.18 15:08:15 5: CUL/RAW: A1E70FACF18412C86DC8A00602440355C4E823EBE9EBA1161A158C16A320304F/3
N01A2085F228F368CFD8DBF527FC8FEBFE09FE17FA1FE0A06183B0FAAAA00


Jetzt zu meiner Frage: Wie bekomme ich denn jetzt die Temperatur/Luftfeuchte angezeigt. Habt ihr eventuell einen Link für mich wie ich jetzt hier weiter vorgehe? (EDIT: Hat sich mittlerweile erledigt - jetzt wird die Temp schon eine weile ausgelesen und ich sehe es auf der Grafik)

Ich möchte eigentlich die Raumtemperatur mit diesem Thermometer und meinen ELV Thermostaten steuern. Nun steht hier aber, dass der Parallelbetrieb nicht möglich ist. Es würde mir reichen, wenn ich z.b. alle 5 Minuten nur die Temperatur von diesem Thermometer über den CUL abfrage. Danach sollte der CUL wieder in den "ELV-Betrieb" umgeschaltet werden und die Thermostate entsprechend der ausgelesenen Temperatur steuern. (So ähnlich wird es ja auch auf den ersten Beiträgen hier im Thread vorgeschlagen).
Mein Problem: Wie kann ich in FHEM einstellen, dass nach dem auslesen der Temperatur der "Betriebsmodus" von CUL wieder umgeschaltet wird? Hat dazu eventuell jemand links wo ich diese Info finden könnte? Mir fehlen hier vermutlich noch die Fachbegriffe für eine erfolgreiche google-suche...

Vielen Dank
Peter

Tedious

Hi,

prinzipiell müsstest Du den Betriebsmodus umschalten, aber "abfragen" wird nix - die Temperaturstationen senden die Signale und der CUL muss "parart" sein um das Signal zu empfangen. Wenn es um einen Regelkreis geht würde ich Dir definitv einen JeeLink empfehlen, der kostet nicht die Welt und lässt sich (prinzipiell) auch selbst löten. Den denn allerdings so konfigurieren dass er die Readings nur protokolliert wenn sich die Werte ändern - sonst wird extrem viel geloggt. Allerdings sind wir hier im Bereich "Ankündigungen", würde also ggf. einen neuen Thread aufmachen wenns pressiert und den hier nicht fluten wenn die FW soweit läuft ;)
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

lkoe

Hi,

ich habe hier eine WS1600 mit der Datenrate 8.842 kbps (siehe auch http://www.fhemwiki.de/wiki/JeeLink). Besteht eine Hoffnung, dass diese Datenrate in zukünftigen Versionen auch unterstützt wird?

Danke!

micha_g

Hallo,

ich habe mir einen CUL aus einem Arduino und dem CC1101 zusammengebaut und nanoCUL geflasht. Nach etwas recherche habe ich dann gesehen, dass es notwendig ist die entsprechenden header und Definitionen in der nanoCUL.c einzutragen.
Anschließend konnte ich den CUL im Modus Nr2 betreiben (erst mal mit minicom getestet).
Die Einbindung im FHEM klappte auch über
define nanoCUL CUL /dev/serial/by-id/usb-XXXXXXX-port0@38400 1234

Wie sorge ich nun dafür das der CUL von sich aus immer im Modus Nr2 arbeitet?
Ich kann zwar set nanoCUL raw Nr2 manuell ausführen, dann geht es erst mal. Komisch ist nur, dass er dann nur am Anfang daten empfängt.

Ich lasse momentan über AT alle 10 Sekunden  set nanoCUL raw Nr2  laufen, aber das kann sicher nicht die Lösung sein oder?
Sobald ich diesen AT deaktiviere, empfange ich auch keine Daten mehr von meinem LaCrosse.

Gruß
Micha

Tatsu

#20
Hallo,

nach kleineren Startschwierigkeiten konnte ich nun den MAX Cube mit der alternativen Firmware culfw@ARM von Telekatz (siehe https://forum.fhem.de/index.php?topic=38404) erfolgreich mit einen Lacrosse TX29-IT einsetzen. Die hier beschriebene Herausforderung, dass CUL/CUN mit AT immer wieder auf SET Nr gestellt werden muss konnte ich bislang noch nicht feststellen, verwende aber Nr1.

Tatsu

#21
Jetzt habe ich doch noch eine Auffälligkeit bemerkt. Die Werte werden zwar bei den per Autocreate erstellten HMS Devices protokolliert und tauchen auch im Plott auf, allerdings schreibt fhem dafür auch "unknown messages":


2016.03.18 17:32:16 2: CUL_1: unknown message N0197E6436A64AAAA0000063896
2016.03.18 17:32:17 2: CUL_1: unknown message N019566366AFAAAAA00002CCD2A
2016.03.18 17:32:21 2: CUL_1: unknown message N0197E6436A64AAAA00003ACBE3
2016.03.18 17:32:21 2: CUL_1: unknown message N019566366AFAAAAA00004A7C4C
2016.03.18 17:32:25 2: CUL_1: unknown message N0197E6436A64AAAA000048E8CD
2016.03.18 17:32:25 2: CUL_1: unknown message N019566366AFAAAAA00003A9858


Es handelt sich dabei auch tatsächlich um die beiden eingesetzten TX-29IT. Wenn ich jeweils die Batterie rausnehme, gibt es auch keine unknown messages mehr.

Kann ich das noch irgendwie unterdrücken bzw. habe ich da etwas falsch konfiguriert bzw. gibt es eine Möglichkeit, das irgendwie zu unterdrücken?

Nachtrag: die Lösung lautet 'verbose 0', danke an Telekatz


chris1284

Danke! die technoline wd4008 (aldi ca 30€ damals) lässt sich übrigens mit dem cul868 im raw Nr2 mode empfangen. der außensender ist der technoline TX38WD-IT (neu einzeln ca 10€ liefert bat und temp).

chris1284

hat noch jemand das problem das die firmware auf zeit nicht stbil läuft und es immer mal wieder notwendig ist den cul per set raw Nr2 wieder in den lacrosse mode zu versetzen?
danach läuft er eine ganze weile sauber durch bis er wieder aussetzt. ich habe die vermutung das dies irgendwie mit zuvielen  "unknown messages" zu tun hat

fhemfreund

#24
Zitat von: locutus am 17 Oktober 2015, 21:34:59
Das Makefile sollte folgende Einträge beinhalten:
../../clib/rf_native.c      \
../../clib/lacrosse.c      \


board.h:
#define HAS_RFNATIVE
#define LACROSSE_HMS_EMU


Die Zeile muss weg oder wird auskommentiert:
//# define OFF_LACROSSE_HMS_EMU

In CUL.c dürfen diese Einträge nicht fehlen:
#ifdef HAS_RFNATIVE
#include "rf_native.h"
#endif

#ifdef HAS_RFNATIVE
  { 'N', native_func },
#endif

#ifdef HAS_RFNATIVE
    native_task();
#endif


Wenn alles richtig ist, dann wird ein HMS Device per autocrate angelegt.
2015.10.17 21:00:06 3: set CUL raw Nr1
2015.10.17 21:00:06 2: CUL: unknown message 01
2015.10.17 21:00:30 2: CUL: unknown message N0191860140EBAAAA0000210022
2015.10.17 21:00:30 3: Unknown HMS device 1000/4306, please define it
2015.10.17 21:00:30 2: autocreate: define HMS100TF_4306 HMS 4306
2015.10.17 21:00:30 2: autocreate: define FileLog_HMS100TF_4306 FileLog ./log/HMS100TF_4306-%Y.log HMS100TF_4306:T:.*
2015.10.17 21:00:30 2: autocreate: define SVG_HMS100TF_4306 SVG FileLog_HMS100TF_4306:temp4hum6:CURRENT
2015.10.17 21:00:34 2: CUL: unknown message N0191860140EBAAAA0000000240
2015.10.17 21:00:42 2: CUL: unknown message N0191860140EBAAAA0000400094
2015.10.17 21:00:50 2: CUL: unknown message N0191860140EBAAAA0000516090


Habe das jetzt auch mal bei mit probiert ...

- Compilieren geht (1.66er culfw) auf Busware CUL V3
- FHEM neuster Stand pl11756/2016-07-07
- LaCrosse Sensor TX35DTH-IT
- CUL auf raw Nr2 gesetzt

Aber leider bekomme ich auch nur die


CUL2: unknown message N029C27083182036D7BAB39FA01


Messages. Wenn ich meinem Sensor die Batterien wegnehme stoppen diese sofort - d.h. empfangen wird etwas, aber leider kein Device per autocreate angelegt.

Kann es sein, dass noch etwas anderes fehlt? Hat das jemand mit den gleichen Komponenten (wie ich) am Laufen?

Andreas

chris1284

probier doch auch nochmal die aculfw, da ist der lacrosse empfang auch drin...insgesamt ist die integration recht instabil finde ich. in unregelmäßigen abständen stell der cul seinen dienst im raw Nr2 ein  (er bleibt Initialized). andere modi laufen ewig problemlos durch. man muss ihn per set raw wieder beleben

juergs

#26
Hallo Zusammen,

hatte auch das Problem mit nicht vorhandem "N" Command in der "CULFW-code-555".

Unter Windows hatte ich Problem mit der make-Datei:
Beim Einfügen von:
../../clib/rf_native.c      \
../../clib/lacrosse.c      \

kam make mit den Tabs nicht zurecht. Ersetzen der TABs duch Spaces löste das Problem.

Obwohl ich beide
#define HAS_RFNATIVE
#define LACROSSE_HMS_EMU

in der board.h definiert hatte, wurde in der fntab dieser Part nicht mitkompiliert ...

Um das zu erzwingen habe ich in der nanoCUL.c das
#define HAS_RFNATIVE
nochmal definiert.

Nachprüfen lässt sich das nach dem make in der nanoCUL.lst -Datei, dort muss der Sprung zu native_func mit enthalten sein.
Was vorher nicht erfolgte.

168 001c 0000      .word gs(ks_send)
169 001e 4E        .byte 78
170 001f 0000      .word gs(native_func)
171 0021 55        .byte 85
172 0022 0000      .word gs(ur_send)



Ok nicht schön, aber geht.

Es kommt zwar immer noch "unknown message":
Zitat2016.09.11 18:18:17 0: Server started with 53 defined entities (fhem.pl:12095/2016-08-30 perl:5.020001 os:MSWin32 user:J�rgen pid:11776)
2016.09.11 18:18:25 3: set CUL raw Nr1
2016.09.11 18:18:25 5: SW: Nr1
2016.09.11 18:18:25 5: CUL/RAW: /01
2016.09.11 18:18:25 4: CUL_Parse: CUL 01
2016.09.11 18:18:25 2: CUL: unknown message 01

Aber dafür empfange ich jetzt 868MHz-LaCrosse-Sensoren:

Zitat2016.09.11 18:32:02 4: CUL_Parse: CUL N019207136A0EAAAA000014D88D
2016.09.11 18:32:02 2: CUL: unknown message N019207136A0EAAAA000014D88D
2016.09.11 18:32:02 4: CUL_Parse: CUL H430801130300FF -74.5
2016.09.11 18:32:02 5: CUL dispatch 810e04xx0511a0014308000001130300
2016.09.11 18:32:14 5: CUL/RAW: /N019207136A0EAAAA00002E3F1B

/edit:
meine Variante/Code funktioniert nur in der Kombination Nano/RFM12 (Jeelink!). hier und hier
Hatte ich mal so aufgebaut. Allerdings benutze ich jetzt die Lacrosse-Gateway (über WLAN) von HCS für diesen Zweck.

DazDavid

Hi,

tut mir leid das ich dieses Thema wieder hochhole aber ich denke ihr passt meine Frage immernoch am besten rein.
Ich habe mir gestern einen nanoCUL zusamengebaut so wie in der Wiki beschrieben. Anschließend habe ich die aktuellste Firmware (556) geflasht und einen Test mit Screen gemacht. Die Version wurde angezeigt und bei Eingabe des Befehls X08 wie in der Wiki beschrieben erschienen viele rf´s was glaube so viel heißt wie "läuft" :)

Nun habe ich den nanoCUL in FHEM eingebunden und das erste was mich irritiert ist der state "disconnected". Ist das korrekt so?
Außerdem ist mir leider nicht ganz klar wie es jetzt weiter geht. Mein Ziel ist es momentan mit diesem CUL den Außensensor meine Wetterstation (TFA Wetterstation) anzuzapfen. Der Außensensor ist ein TFA Dostmann, sieht genauso aus wie der Lacrosse und hinten steht was von IT+ 868Mhz drauf somit denke ich er müsste kompatibel sein.

Kann mir vielleicht jemand freundlicherweiße einen kurzen "Guide" geben wie genau ich jetzt die Daten in FHEM bekomme? Ich bin leider aus keiner Anleitung und keinen Blog wirklich schlau geworden.
FHEM (up2date) on Raspberry Pi 3B | nanoCUL 868 MHz | Raspbee Zigbee Gateway | Philips Hue | Osram Lightify | MAX Thermostate

DazDavid

Ok, das Problem mit "Disconnected" habe ich beheben können indem ich den CUL per /dev/ttyUSB0 definiert habe anstatt mit der Serial. Jetzt kann ich immerhin die Version usw. auslesen, weiß aber immer noch nicht so recht wie ich an die Daten des Außensensors komme.
FHEM (up2date) on Raspberry Pi 3B | nanoCUL 868 MHz | Raspbee Zigbee Gateway | Philips Hue | Osram Lightify | MAX Thermostate