Alternative culfw

Intruder1956 · 11 April 2015, 15:27:53

hallo, ich habe gerade versucht das neue File auf meinen Busware 433 zu flashen, mit Windows und Flip.
Es kommt eine Meldung nach laden vom File in FLIP: Adress is out of range
bis zur Version 1.02.00 built 70 hat es immer geklappt.

Ist das File nicht in Ordnung ??

Gruß Werner

chris1284 · 11 April 2015, 15:42:40

einfach ohne m-bus neu kompilieren und dann gehts

da die eigentliche änderung an der 02.02. aber nur m-bus betrifft gibts keinen grund diese zu flashen wenn man auf die m-bus änderungen verzichten kann

bjoernh · 11 April 2015, 16:20:39

Zitat von: chris1284 am 11 April 2015, 15:23:26
das hexfile ist auch zu groß von der 1.02.02.

Habs gelöscht....

Neue Version ist die 1.03.01

Änderungen:
- Split CULs in 433MHz and 868MHz version
- Implement Oregon 3, disabled by default. Define HAS_OREGON3

locutus · 12 April 2015, 14:40:50

Hallo Björn,

inwieweit ist die Implementierung von Oregon Scientific insgesamt fortgeschritten? Reicht das Auskommentieren der Zeile

Code Auswählen

//# define HAS_OREGON3
aus oder muss ich den Inhalt des C-Files ergänzen?

Code Auswählen

#ifdef HAS_OREGON3
#include "rf_receive_oregon.h"
#endif

Wird das vorhandene 41_OREGON.pm Modul zur Decodierung genutzt?

bjoernh · 12 April 2015, 15:46:49

Zitat von: locutus am 12 April 2015, 14:40:50
Hallo Björn,

inwieweit ist die Implementierung von Oregon Scientific insgesamt fortgeschritten? Reicht das Auskommentieren der Zeile
Code Auswählen Erweitern
//# define HAS_OREGON3
aus oder muss ich den Inhalt des C-Files ergänzen?
Code Auswählen Erweitern
#ifdef HAS_OREGON3 #include "rf_receive_oregon.h" #endif

Wird das vorhandene 41_OREGON.pm Modul zur Decodierung genutzt?

Hallo,

also ergänzen musst Du nichts, lediglich den define einschalten.
Probiert habe ich es allerdings nicht, da ich keine Oregon Komponenten habe. Deshalb habe ich es auch per default abgeschaltet.
Wenn Du es getestet hast, würde ich mich über eine Rückmeldung freuen.

Gruß
Björn

OliS. · 12 April 2015, 19:33:25

Hallo Björn,

ich habe mir die 1.03.01 runtergeladen, finde aber leider den String

Code Auswählen

//# define HAS_OREGON3

nicht in der "board.h". Habe ich etwas übersehen?

Ich habe nämlich die Hoffnung, damit mein Santos Grillthermometer empfangen zu können. Dies wird in den USA wohl von Oregon Scientific vertrieben. Irgendwie gefällt mir die Vorstellung, dass mein Küchen-Sonos mir Bescheid sagt, wenn mein Steak medium ist.

Gruß Oli

bjoernh · 12 April 2015, 19:42:06

Zitat von: OliS. am 12 April 2015, 19:33:25
Hallo Björn,

ich habe mir die 1.03.01 runtergeladen, finde aber leider den String

Code Auswählen Erweitern
//# define HAS_OREGON3

nicht in der "board.h". Habe ich etwas übersehen?

Ich habe nämlich die Hoffnung, damit mein Santos Grillthermometer empfangen zu können. Dies wird in den USA wohl von Oregon Scientific vertrieben. Irgendwie gefällt mir die Vorstellung, dass mein Küchen-Sonos mir Bescheid sagt, wenn mein Steak medium ist.

Gruß Oli

Schreib es einfach in die board.h rein.
Du siehst ja dann, dass die Größe vom Code größer wird.
Ich habe das define nicht in allen Devices vorgemerkt.
Wenn es bei Euch klappt, werde ich es sicherlich fest reinnehmen.

Im nächsten Build 01.03.02 ist im CUL-V3 das Oregon3 eingeschaltet.

Gruß
Björn

pejonp · 12 April 2015, 23:17:20

Hallo,

ich habe im Modul den "LIFETEC LT3594" eingetragen. Wurde aus dem aus dem FHEMduino Modul 14_FHEMduino_Env.pm entnommen. Hier sind die Änderungen im 14_CUL_TCM97001.pm Modul.
my %models = (
"TCM97..." => 'TCM97...',
"ABS700" => 'ABS700',
"TCM21...." => 'TCM21....',
"Prologue" => 'Prologue',
"Rubicson" => 'Rubicson',
"NC_WS" => 'NC_WS',
"GT-WT-02" => 'GT-WT-02',
"AURIOL" => 'AURIOL',
"LIFETEC" => 'LIFETEC',
"Unknown" => 'Unknown',
);

ab Zeile 538 eingefügt:

if ($readedModel eq "LIFETEC" || (hex($a[0]) == 0x4 && $readedModel eq "Unknown")) {
# aus dem FHEMduino Modul 14_FHEMduino_Env.pm entnommen. (pejonp 12.4.2015)
# $bitsequence = substr($bitsequence,0,24); # Only 24 Bits
# $bin = substr($bitsequence,0,8);
# $deviceCode = sprintf('%X', oct("0b$bin"));
# $bat = int(substr($bitsequence,16,1)) eq "1" ? "ok" : "critical";
# $sendMode = int(substr($bitsequence,17,1)) eq "0" ? "automatic" : "manual";
# $temp = bin2dec(substr($bitsequence,9,7));
# $temp = $temp + (bin2dec(substr($bitsequence,20,4))/10.0);
# if (substr($bitsequence,8,1) eq "1") {
# $temp = $temp * (-1);
# }
# $hum = (-1);
# $val = "T: $temp H: $hum B: $bat";

# LIFETEC LT3594
# /--------------------------------- Sensdortype DeviceCode
# / / ---------------------------- ID, changes after every battery change
# / / /-------------------------- neg Temp: if 1 then temp = temp * -1
# / / //-------------------------- Temp high (9 + 7)
# / / //
# / / // /----------------- Battery state 1 == Ok
# / / // / /---------------- SendMode 0 = automatic
# / / // / / /------------- Temp low (20 +4)
# / / // / / /
# 0101 0010 1001 0000 0 010 0011 0000 1 101 1101
# Bit 0 4 8 12 16 17 20 28 29 36
#$def = $modules{CUL_TCM97001}{defptr}{$idType3};
$def = $modules{CUL_TCM97001}{defptr}{$idType1};
if($def) {
$name = $def->{NAME};
}
$temp = (hex($a[2].$a[3])) & 0x7F;
$temp = $temp + (hex($a[5]));
my $negative = (hex($a[2])) & 0x8;

if ($negative == 0x8) {
$temp = ~$temp * (-1);
}
$temp = $temp / 10;

$batbit = (hex($a[5]) & 0x8) >> 3;
$mode = (hex($a[3]) & 0x4) >> 2;
if (checkValues($temp, $humidity)) {
if(!$def) {
#Log3 $name, 2, "CUL_TCM97001 Unknown device $idType3, please define it";
#return "UNDEFINED CUL_TCM97001_$idType3 CUL_TCM97001 $idType3" if(!$def);
Log3 $name, 2, "CUL_TCM97001 Unknown device $idType1, please define it";
return "UNDEFINED CUL_TCM97001_$idType1 CUL_TCM97001 $idType1" if(!$def);
}
$hashumidity = TRUE;
$hasbatcheck = TRUE;
$packageOK = TRUE;
$model="LIFETEC";
$readedModel=$model;
} else {
$name = "Unknown";
}
}

Vielleicht kann das ja übernommen werden. Der Sensor sendet in sehr unregelmäßigen Abständen.
Tschüß Jörg

ChiliApple · 13 April 2015, 13:00:55

hallo björn,

kann es sein das ab 01.03.01 für den CUL V3, 433 mit 868 beim Hex File vertauscht ist? ich kann meinen CULV3 868 nur mit dem 433ér HEX flashen

bjoernh · 13 April 2015, 13:03:18

Zitat von: ChiliApple am 13 April 2015, 13:00:55
hallo björn,

kann es sein das ab 01.03.01 für den CUL V3, 433 mit 868 beim Hex File vertauscht ist? ich kann meinen CULV3 868 nur mit dem 433ér HEX flashen

Vertauscht glaube ich nicht.
Passt es wieder von der Größe nicht?
Was kommt denn für eine Fehlermeldung?

ChiliApple · 13 April 2015, 14:07:39

"Bootloader and code overlap. Use --suppress-bootloader-mem to ignore". Trying to use the option --suppress-bootloader-mem"

mir ist auch aufgefallen er nimmt nur mehr SlowRF und Homematic, die anderen Modis akzeptiert er nicht mehr

bjoernh · 13 April 2015, 15:13:07

Zitat von: ChiliApple am 13 April 2015, 14:07:39
"Bootloader and code overlap. Use --suppress-bootloader-mem to ignore". Trying to use the option --suppress-bootloader-mem"

mir ist auch aufgefallen er nimmt nur mehr SlowRF und Homematic, die anderen Modis akzeptiert er nicht mehr

Hast Du mal die 01.03.02 probiert? Die sollte sich flashen lassen.

bjoernh · 13 April 2015, 20:43:28

Zitat von: pejonp am 12 April 2015, 23:17:20
Hallo,

ich habe im Modul den "LIFETEC LT3594" eingetragen. Wurde aus dem aus dem FHEMduino Modul 14_FHEMduino_Env.pm entnommen. Hier sind die Änderungen im 14_CUL_TCM97001.pm Modul.

Hallo Jörg,

hast Du mir mal ein paar RAW Werte?
Fangen die Lifetecs immer mit 4 an?

Probehalber habe ich es bei mir eingebaut. Ich habe blos keinen in der näheren Umgebung empfangen. (Hier funkt alles, von AURIOL, Rubicson, TCM21..., NC_WS, GT-WT-02, Prologue, TCM97... aber leider kein Lifetec)

Danke für deine Vorarbeit.
Das Batteriebit muss denke ich umgedreht werden.
Des weiteren muss das $hashumidity = TRUE; raus.
Kannst Du den Sensor auch mal in die Gefriertruhe packen?

Anbei mal mein angepasstes Modul.

Gruß
Björn

ChiliApple · 13 April 2015, 21:04:29

ich habe leider nicht eindeutig geschrieben, (ich schrieb ab 01) ich habe beide probiert ...

wird die FW den neuen CUNX auch unterstützen? ich bin grad am neu bestellen und hab gesehen die haben Einiges was neu ist, der CUNO wird vom CUNX ersetzt. http://busware.de/tiki-index.php?page=CUNX

ich denke ich werde aber 2 SCC nehmen da ich ja nur IT und 866 getrennt haben möchte ...

bjoernh · 13 April 2015, 21:41:09

Zitat von: ChiliApple am 13 April 2015, 21:04:29
wird die FW den neuen CUNX auch unterstützen? ich bin grad am neu bestellen und hab gesehen die haben Einiges was neu ist, der CUNO wird vom CUNX ersetzt. http://busware.de/tiki-index.php?page=CUNX

Ob ich den CUNX mit integriere muss ich mal schauen. Dirk Tostmann hat da schon einiges an der culfw angepasst und der FW den Namen culfw-2.0 gegeben (siehe github)
Ich brauche den CUNX nicht und werde mir nur zum integrieren keinen kaufen. Vielleicht hat ja Dirk Tostmann interesse daran die Änderungen der a-culfw mit der neuen 2.0 zu verschmelzen.

Die a-culfw für den CUL sollte in kürze wieder gehen. Ich habe nun bei der 868MHz variante das senden der IT rausgenommen. Ich denke es macht dann sowieso Sinn, dass man die ITs auch mit einem 433MHz CUL ansteuert. Da ist dann auch die Reichweite zufriedenstellend.