Alternative culfw

Mike767 · 03 Januar 2017, 20:30:50

Hallo Björn,

erstmal vielen Dank für die Software.
Ich benutze diese in meinem CUL 433 von Busware.
Bis Heute morgen habe ich auch Daten vom GT_WT_02 bekommen, seit dem werden die Daten zwar empfangen aber nicht ausgewertet.
Ich denke es liegt an der Luftfeuchtigkeit, da diese jetzt über 90% ist un an der Station mit "HH" angezeigt werden.

Code Auswählen



2017.01.03 19:38:19 5: CUL/RAW: /s800025DD40F0;  480: 9008

2017.01.03 19:38:19 4: CUL_Parse: CUL1 s800025DD40F0;  480: 9008
2017.01.03 19:38:19 5: CUL1: dispatch s800025DD40F0;  480: 9008
2017.01.03 19:38:20 5: CUL/RAW: /s800025DD40F2;  480: 8992

2017.01.03 19:38:20 4: CUL_Parse: CUL1 s800025DD40F2;  480: 8992
2017.01.03 19:38:20 5: CUL1: dispatch s800025DD40F2;  480: 8992
2017.01.03 19:38:20 5: CUL/RAW: /s800025DD40F0;  464: 9088

2017.01.03 19:38:20 4: CUL_Parse: CUL1 s800025DD40F0;  464: 9088
2017.01.03 19:38:20 5: CUL1: dispatch s800025DD40F0;  464: 9088
2017.01.03 19:38:20 5: CUL/RAW: /s800025DD40F0;  496: 9008

2017.01.03 19:38:20 4: CUL_Parse: CUL1 s800025DD40F0;  496: 9008
2017.01.03 19:38:20 5: CUL1: dispatch s800025DD40F0;  496: 9008

Danke,
Gruß Mike

bjoernh · 03 Januar 2017, 20:36:03

Zitat von: Mike767 am 03 Januar 2017, 20:30:50
Hallo Björn,

erstmal vielen Dank für die Software.
Ich benutze diese in meinem CUL 433 von Busware.
Bis Heute morgen habe ich auch Daten vom GT_WT_02 bekommen, seit dem werden die Daten zwar empfangen aber nicht ausgewertet.
Ich denke es liegt an der Luftfeuchtigkeit, da diese jetzt über 90% ist un an der Station mit "HH" angezeigt werden.

Code Auswählen Erweitern
2017.01.03 19:38:19 5: CUL/RAW: /s800025DD40F0; 480: 9008 2017.01.03 19:38:19 4: CUL_Parse: CUL1 s800025DD40F0; 480: 9008 2017.01.03 19:38:19 5: CUL1: dispatch s800025DD40F0; 480: 9008 2017.01.03 19:38:20 5: CUL/RAW: /s800025DD40F2; 480: 8992 2017.01.03 19:38:20 4: CUL_Parse: CUL1 s800025DD40F2; 480: 8992 2017.01.03 19:38:20 5: CUL1: dispatch s800025DD40F2; 480: 8992 2017.01.03 19:38:20 5: CUL/RAW: /s800025DD40F0; 464: 9088 2017.01.03 19:38:20 4: CUL_Parse: CUL1 s800025DD40F0; 464: 9088 2017.01.03 19:38:20 5: CUL1: dispatch s800025DD40F0; 464: 9088 2017.01.03 19:38:20 5: CUL/RAW: /s800025DD40F0; 496: 9008 2017.01.03 19:38:20 4: CUL_Parse: CUL1 s800025DD40F0; 496: 9008 2017.01.03 19:38:20 5: CUL1: dispatch s800025DD40F0; 496: 9008

Danke,
Gruß Mike

Hi Mike,
siehe hier: https://forum.fhem.de/index.php/topic,28519.msg552278.html#msg552278
Gruß
Björn

t1me2die · 05 Januar 2017, 20:26:06

Hallo liebe Community,

ich habe mittlerweile ein OREGON THGR228N erfolgreich in FHEM eingebunden. Dieses Gerät wurde direkt erkannt und angelegt via autocreate.

Nun habe ich mir noch ein OREGON THGN132N besorgt, dies soll laut https://wiki.fhem.de/wiki/RFXtrx auch funktionieren.
Leider wird dies nicht automatisch angelegt und im Eventmonitor sehe ich leider auch nichts.

Muss ich noch irgendwas einstellen oder muss ich dies evtl. manuell anlegen?

Gruß
Mathias

KölnSolar · 05 Januar 2017, 21:36:01

Das hat hier wohl gar nichts verloren

und auch noch ein Doppelpost

Im richtigen Unterforum hab ich Dir bereits geantwortet.

steffen-kiess · 06 Januar 2017, 20:06:04

Ich bin auf ein Problem auf der CUBe-Hardware gestoßen, der Native RF mode ("Nr1") funktioniert dort nicht. Wenn man versucht, ihn zu aktivieren, startet sich die Firmware neu. Das Problem scheint die Funktion fromdec() zu sein, die als zweites Argument ein "uint8_t* out" kriegt, aber einen 16-bit-Wert reinschreibt:

Code Auswählen

*(uint16_t*)out = h;

In native_func() wird fromdec() dann aber mit einem Zeiger auf eine uint8_t aufgerufen, was schiefgeht. (Ich weiß nicht, warum das auf anderer Hardware funktioniert, vermutlich ist die Endianess oder der Stack-Layout anders.)

Code Auswählen


  uint8_t mode = 0;
[...]
      fromdec(in+2, &mode);

Mit dem folgenden Patch funktioniert der Native RF mode auch auf der CUBe-Hardware:

Code Auswählen


diff --git a/culfw/clib/rf_native.c b/culfw/clib/rf_native.c
index 17749c2..53541e1 100644
--- a/culfw/clib/rf_native.c
+++ b/culfw/clib/rf_native.c
@@ -221,13 +221,13 @@ void native_task(void) {
 
 
 void native_func(char *in) {
-  uint8_t mode = 0;
+  uint16_t mode = 0;
 
   if(in[1] == 'r') {                // Reception on
     
     // "Er<x>" - where <x> is mode
     if (in[2])
-      fromdec(in+2, &mode);
+      fromdec(in+2, (uint8_t *)&mode);
 
     if (!mode || mode>MAX_MODES) {
       DS_P(PSTR("specify valid mode number\r\n"));

Telekatz · 06 Januar 2017, 20:54:46

Es liegt an der Speicherausrichtung bei der ARM Architektur.

Wenn ein Cast eines uint8_t* auf uint16_t* durchgeführt wird funktioniert das nur, wenn der Pointer auf eine gerade Adresse zeigt. Tut er das nicht und man versucht von einer ungeraden Adresse ein uint16_t zu lesen, wird eine Data Abort exception ausgelöst und der Watchdog wird nicht mehr gefüttert. Dadurch startet der Cube neu.

Allerdings ist dieser Bug bereits mit Version 1.23.05 korrigiert worden.

bjoernh · 06 Januar 2017, 20:56:27

Zitat von: steffen-kiess am 06 Januar 2017, 20:06:04
Ich bin auf ein Problem auf der CUBe-Hardware gestoßen, der Native RF mode ("Nr1") funktioniert dort nicht. Wenn man versucht, ihn zu aktivieren, startet sich die Firmware neu. Das Problem scheint die Funktion fromdec() zu sein, die als zweites Argument ein "uint8_t* out" kriegt, aber einen 16-bit-Wert reinschreibt:

Code Auswählen Erweitern
*(uint16_t*)out = h;

In native_func() wird fromdec() dann aber mit einem Zeiger auf eine uint8_t aufgerufen, was schiefgeht. (Ich weiß nicht, warum das auf anderer Hardware funktioniert, vermutlich ist die Endianess oder der Stack-Layout anders.)

Code Auswählen Erweitern
uint8_t mode = 0; [...] fromdec(in+2, &mode);

Mit dem folgenden Patch funktioniert der Native RF mode auch auf der CUBe-Hardware:

Code Auswählen Erweitern
diff --git a/culfw/clib/rf_native.c b/culfw/clib/rf_native.c index 17749c2..53541e1 100644 --- a/culfw/clib/rf_native.c +++ b/culfw/clib/rf_native.c @@ -221,13 +221,13 @@ void native_task(void) { void native_func(char *in) { - uint8_t mode = 0; + uint16_t mode = 0; if(in[1] == 'r') { // Reception on // "Er<x>" - where <x> is mode if (in[2]) - fromdec(in+2, &mode); + fromdec(in+2, (uint8_t *)&mode); if (!mode || mode>MAX_MODES) { DS_P(PSTR("specify valid mode number\r\n"));

Bist Du sicher, dass Du von der a-culfw sprichst?
In der a-culfw wird der Fall nämlich behandelt:

Code Auswählen

#ifdef ARM
  uint16_t mode = 0;
#else
  uint8_t mode = 0;
#endif

@Telekatz: Du warst wohl schneller

steffen-kiess · 06 Januar 2017, 22:31:54

Zitat von: bjoernh am 06 Januar 2017, 20:56:27
Bist Du sicher, dass Du von der a-culfw sprichst?
In der a-culfw wird der Fall nämlich behandelt:
Code Auswählen Erweitern
#ifdef ARM uint16_t mode = 0; #else uint8_t mode = 0; #endif

@Telekatz: Du warst wohl schneller

Ja, das Problem war nur, dass meine Version zu alt war (von Anfang Dezember), und ich nicht geschaut habe, ob sich was geändert hat :-$

sirnoname · 06 Januar 2017, 23:56:08

Hallo,

ich habe von nanoCUL 1.66 auf die aktuelle a-cul firmware gewechselt. Ein nanoCUL mit 433, eines mit 868. Beim 433 geht nun mein globaltec Sensor GT-WT-01, wenn ich eine IT Steckdose per Fernbedienung schalte bekommt es das CUL mit. Allerdings kann ich nicht mehr Senden und die Steckdosen damit schalten.
Beim 868 gehen sofort die FHT Raumregler nicht mehr (anscheinend auch nicht Senden). Mit der alten Firmware ist das Problem sofort behoben. Hier habe ich mal das EEPROM zurückgesetzt ohne eine Verbesserung festzustellen.

Insgesammt meine ich das etwas mit Senden nicht stimmt. Muss ich beim Umstieg was beachten?
Ich nehme mal an der alte raw write zum Erhöhen der Sendeleistung belibt gleich wie bei der Standard CUL FW?

Wäre um Erfahrungen dankbar!

Master_Nick · 07 Januar 2017, 00:29:47

"Allerdings kann ich nicht mehr Senden und die Steckdosen damit schalten."

Was sagt er denn im Log? Die Berechnung/Anwendung des Codes der IT ist dir geläufig?
Mein 433er nanoCUL schaltet hier mehr als ein Dutzend IT Stecker und Schalter.

sirnoname · 07 Januar 2017, 08:04:53

Hi, verstehe deine Antwort nicht.
Meine Aussage war ja, das die Stecker mit der alten Firmware vollständig funktionieren.
Nur die a-culfw hat nach einem Flash Probleme. Wenn ich auf die Standard zurückwechsle dann passt alles wieder. Die Codierung ist in der cfg File fest hinterlegt.
Die FHT80b empfangen auch nichts mehr von der a-culfw. So als wäre das Senden deaktiviert.

define Schalter_A IT F0000F0FFF F0 0F
attr Schalter_A IODev nanoCUL433
attr Schalter_A ITrepetition 12
attr Schalter_A group Schalter
attr Schalter_A model itswitch

Der Empfang funktioniert! Drücke ich eine Taste auf der Fernbedienung, dann wechselt die Anzeige. Das tat aber schon die Standard Firmware.

bjoernh · 07 Januar 2017, 08:33:39

Also ich komme leider auch nicht ganz mit was Du für Probleme hast.

1. Für die 868er nim die original CUL FW, die a-culfw bringt dir keinen mehrwert.

@All ich glaube ich lösche die Variante für 868 jetzt

2. Nach einem Umstieg kannst Du das EEProm im CUL neu initialisierten (raw e). Damit sollte eigentlich alles klappen.

ZitatDie FHT80b empfangen auch nichts mehr von der a-culfw. So als wäre das Senden deaktiviert.

Im Modul Code zur FHT Implementierung gibt es keinen unterschied zur culfw, sollte also klappen. Aber wie gesagt, siehe 1.

Master_Nick · 07 Januar 2017, 10:19:00

@sirnoname Ok dann wird es schon mal nicht die Codierung sein.
Blinkt der nanoCUL wie verrückt?
Ansonsten mach mal beim ihm und bei FHEM Verbose auf 5 und mach mal deine Vorgänge, die nicht gehen sollen. Dann kann man sich das LOG mal ansehen.

*Edit: was sagt dein nanoCUL bei get ccconf ?

Da sollte so etwas stehen:
"freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB"

Ich glaube ich sehe den Fehler!
attr Schalter_A ITrepetition 12 <--

Mit dem Attribut gesetzt konnte ich nicht eine Sache mehr schalten von IT. Lösche es starte FHEM neu (shutdown restart) und dann schalte erneut (Sobald du eine IT schalten willst die das Argument gesetzt hast ging bei mir nix mehr). Ja man bekommt bei zu niedrigem Log-Level dann Fehler von wegen die Devices hätten nicht korrekte geantwortet - können sie aber ja auch gar nicht. Ich habe im Standard die Verbose Level bei mir auf 1.

Kleiner Tipp noch solltest du schon selbstlernende Stecker besitzen nutze den langen Code der bietet mehr Vielfalt und ist sicherer gegen Störer: https://wiki.fhem.de/wiki/Intertechno_Code_Berechnung#Mit_neuem_Protokoll_anlernen

RaspiLED · 07 Januar 2017, 12:16:46

Moin,
Kann mir bitte mal jemand Nachhilfe bei Hoermann geben? Auf welcher Frequenz laufen die genau und mit welcher a-culfw Version habt ihr getestet? Autocreate geht bei mir, aber entweder die Garage ist zu weit weg oder ich habe Freq/Bandbreiten Probleme

Gruß Arnd

Gesendet von iPhone mit Tapatalk

bjoernh · 07 Januar 2017, 12:20:26

Zitat von: RaspiLED am 07 Januar 2017, 12:16:46
Moin,
Kann mir jemand Nachhilfe bei Hoermann geben? Auf welcher Frequenz laufen die genau und mit welcher Version habt ihr getestet? Autocreate geht bei mir, aber entweder sie Garage ist tu weit weg oder ich habe Freq/Bandbreiten Probleme
Gruß Arnd

Gesendet von iPhone mit Tapatalk

Was für eine Firmware? Welches Device?
Im CUL ist z.B. Hoermann abgeschaltet (Speichermangel). Wenn Du es brauchst musst Du es aktivieren und kompilieren.

Hörmann Frequenzen siehe http://www.hoermann-faq.com/antriebe-funk/welche-sendefrequenz-nutzt-mein-handsender/