Alternative culfw

hjgode · 26 Dezember 2016, 07:36:28

Zitat von: Master_Nick am 26 Dezember 2016, 01:20:04
Guten Abend,

heißt folgernder Part im Changelog:

"1.20.00
- Implement receive of Manchester coded signals linke Oregon2, Oregon3 or Hideki"

es können auch Sensoren von Oregon empfangen werden mit der a-culfw mit dem nanoCUL?
Generell hatte ich eher Aussagen gefunden, dass geht nicht mit dem...

Hideki und Oregon geht ab Version 1.20. Bei mir wird allerdings nur der Selbstbau Hideki und Oregon Sensor empfangen. Die drei anderen Hideki Sensoren von TFA Dostmann dekodiert mein nanoCUL433 nicht (nano mit echtem CC1101 für 433MHz). Stört mich nicht weiter, da alle 4 Hideki Sensoren vom Singalduino empfangen werden.

nanoCUL433:

Code Auswählen

2016.12.24 07:34:08 4: nanoCUL433: hideki protocol converted to hex: 757CBACAD0BF3355056A001E with 104 bits, mes
sagestart 0
2016.12.24 07:34:08 5: nanoCUL433 Dispatch now to Hideki Module.
2016.12.24 07:34:08 5: converted Data to (P12#757CBACAD0BF3355056A001E)
2016.12.24 07:34:08 5: nanoCUL433: dispatch P12#757CBACAD0BF3355056A001E
2016.12.24 07:34:08 4: Hideki_Parse nanoCUL433 incomming P12#757CBACAD0BF3355056A001E
2016.12.24 07:34:08 4: Hideki_Parse SensorTyp = 30 decodedString = 7584ce5e70c155ff0fbe0022
2016.12.24 07:34:08 4: nanoCUL433 decoded Hideki protocol model=Hideki_30, sensor id=84, channel=4, temp=17, hum
idity=55, bat=ok, rain=0
2016.12.24 07:34:08 5: deviceCode: Hideki_30_4
2016.12.24 07:34:08 5: Triggering Hideki_30_4 (7 changes)
2016.12.24 07:34:08 5: Starting notify loop for Hideki_30_4, 7 event(s), first is T: 17 H: 55 Bat: ok

Und beim Oregon stimmt noch was nicht:

Code Auswählen

2016.12.24 07:34:08 5: CUL_REDIRECT: OSV3 protocol converted to hex: (583A7C742983F66B4695 26A) with length (96)
 bits 

2016.12.24 07:34:08 5: nanoCUL433 Dispatch now to Oregon Module.
2016.12.24 07:34:08 5: converted Data to (583A7C742983F66B4695 26A)
2016.12.24 07:34:08 5: nanoCUL433: dispatch 583A7C742983F66B4695 26A
2016.12.24 07:34:08 5: OREGON: decoding delay=1647 hex=583A7C742983F66B4695 26A
2016.12.24 07:34:08 4: OREGON: ERROR: Unknown sensor_id=3a7c bits=88 message='583A7C742983F66B4695 26A'.
2016.12.24 07:34:08 1: ERROR: >OREGON: ERROR: Unknown sensor_id=3a7c bits=88.
< returned by the OREGON ParseFn is invalid, notify the module maintainer
2016.12.24 07:34:08 5: CUL_REDIRECT decode Hideki (AE1F174A60B7EB3154A02B000F)

Frohes Fest noch

~Josef

bjoernh · 26 Dezember 2016, 08:31:03

Zitat von: Master_Nick am 26 Dezember 2016, 01:20:04
Guten Abend,

heißt folgernder Part im Changelog:

"1.20.00
- Implement receive of Manchester coded signals linke Oregon2, Oregon3 or Hideki"

es können auch Sensoren von Oregon empfangen werden mit der a-culfw mit dem nanoCUL?
Generell hatte ich eher Aussagen gefunden, dass geht nicht mit dem...

Hallo,

ja das geht in Verbindung mit der a-culfw.

Gruß
Björn

Bennemannc · 26 Dezember 2016, 16:21:07

Hallo,

ich habe einen SignalDuino und einen WIFICUL 433 gebaut - der Signalduino empfängt mehr (keine Ahnung warum) Bei meinem Test war der Duino sehr viel besser, obwohl er auch das Oregon Modul nimmt zum decodieren.

Gruß Christoph

bjoernh · 26 Dezember 2016, 16:38:37

Zitat von: Bennemannc am 26 Dezember 2016, 16:21:07
Hallo,

ich habe einen SignalDuino und einen WIFICUL 433 gebaut - der Signalduino empfängt mehr (keine Ahnung warum) Bei meinem Test war der Duino sehr viel besser, obwohl er auch das Oregon Modul nimmt zum decodieren.

Gruß Christoph

Hi, das liegt an der andren Empfangsmethode.
Der Cul dekoriert die single im Prozessor. Der duino im PC. Dadurch ist der duino etwas unempfindlicher gegen Störungen.

Gesendet von meinem Mobile Device.

t1me2die · 27 Dezember 2016, 10:48:55

Hallo liebe Community, ich habe einen Selbstbau nanoCUL, den ich zu Beginn mit der culfw (http://sourceforge.net/p/culfw/code/HEAD/tarball) geflasht habe. Nun wollte ich die a-culfw rauf flashen um eine Auriol Wetterstation benutzen zu können.

Habe mir die zip Datei von GitHub gezogen (https://github.com/heliflieger/a-culfw), entpackt und danach "make" ausgeführt, leider fällt er hier wohl schon auf die Schnauze.
Was mache ich verkehrt?

Zitat
Linking: nanoCUL433.elf
Creating load file for Flash: nanoCUL433.hex
Creating load file for EEPROM: nanoCUL433.eep
Creating Extended Listing: nanoCUL433.lss
Creating Symbol Table: nanoCUL433.sym
sh: 1: bc: not found
sh: 1: bc: not found

Size after:
AVR Memory Usage
----------------
Device: atmega328p

Program: 28168 bytes (86.0% Full)
(.text + .data + .bootloader)

Data: 842 bytes (41.1% Full)
(.data + .bss + .noinit)

sh: 1: test: -gt: unexpected operator
make[1]: Leaving directory '/opt/a-culfw-master/culfw/Devices/nanoCUL'

Gruß
Mathias

RaspiLED · 27 Dezember 2016, 12:00:35

Hi,
Probiere mal folgendes:
Mittels ssh auf Deinen Pi einloggen. Falls Du noch kein Unzip hast:
sudo apt-get install unzip
Dann im Ordner der a-culfw Datei:
unzip Dateiname
Dann ins richtuge Verzeichnis wechseln:
cd a-culfw[Tabulator-Taste]/culfw/nanoCUL
Dann flashen mit:
sudo ./flash.sh
Und dann den Fragen folgen...
Viel Spaß
Gerade Arnd

Gesendet von iPhone mit Tapatalk

t1me2die · 27 Dezember 2016, 12:09:25

Hallo Arnd,

recht herzlichen Dank, dass flashen hat nun laut ssh auf jeden Fall geklappt.

Habe den nanoCUL nun wie in dem Wiki definiert:

Zitat
define nanoCUL CUL /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 1234

Die ID habe ich wie folgt ermittelt:

Zitat
pi@raspberrypi:~ $ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Dec 26 22:39 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0

Im Log steht folgendes:

Zitat
2016.12.27 12:13:32 3: Opening nanoCUL device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.12.27 12:13:32 3: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.27 12:13:41 1: Cannot init /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0, ignoring it (nanoCUL)

Leider bleibt der CUL in FHEM nur auf "opened" stehen. Habe ich noch was vergessen?

Gruß
Mathias

RaspiLED · 27 Dezember 2016, 12:55:03

Ja dieses Problem habe ich mit der aktuellen 1.23.xx auch. Ich glaube die ist "zu voll" gepackt

mit der 1.22.xx lief es bei mir immer.
Gruß Arnd

Gesendet von iPhone mit Tapatalk

t1me2die · 27 Dezember 2016, 12:57:09

Das heißt ich habe soweit alles richtig gemacht, aber es kann mit Version 1.23.xx nicht funktionieren?

Nun bin ich etwas verwirrt

RaspiLED · 27 Dezember 2016, 13:48:25

Oh nein! Nicht falsch verstehen, die a-culfw ist super! Und der Funktionsumfang wird immer mehr! Jetzt haben die Nanos halt einen begrenzten Speicherplatz. Manchmal sind die "Untermodule" so viel, das der Speicher halt nicht reicht. Grundsätzlich wird das auch beim flashen angezeigt. Aber was soll ich sagen: Mein Nano ist aus China und vielleicht hat der ein wenig weniger Speicher, jedenfalls ist bei mir die etwas ältere Version super easy geflasht und geht auf initialized, die neue nur auf open. Vielleicht ist die neue auch für 8 statt 16 MHz compiliert!? Kurze Antwort: Etwas ältere Version nehmen, bis eine neue wieder läuft oder selbst compilieren und etwas über die Module dabei erfahren

Gruß Arnd

Gesendet von iPhone mit Tapatalk

Dummbatz · 27 Dezember 2016, 15:01:12

Folgende Version läuft hier einwandfrei:

V 1.23.02 a-culfw Build: 119 (2016-12-04_20-46-20) nanoCUL433 (F-Band: 433MHz)

Wenn mir einer sagen kann wie ich die Speicherbelegung ausgelesen werden kann füge ich das gerne bei.

LG

Dummbatz

mahowi · 27 Dezember 2016, 16:02:31

In der aktuellen Version von github bricht make bei CUNO2 ab:

Code Auswählen

In file included from ../../clib/ntp.c:9:0:
../../clib/fncollection.h:50:5: warning: "CDC_COUNT" is not defined [-Wundef]
 #if CDC_COUNT > 1
     ^
Compiling C: ../../clib/mdns_sd.c
../../clib/mdns_sd.c:33:0: error: unterminated #ifdef
 #ifdef HAS_MDNS
 ^
makefile:353: recipe for target '../../clib/mdns_sd.o' failed
make[1]: *** [../../clib/mdns_sd.o] Error 1
make[1]: Leaving directory '/usr/local/src/a-culfw/culfw/Devices/CUNO2'
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 2

t1me2die · 27 Dezember 2016, 16:07:11

So, mein nanoCUL steht nun auf "Initialized", musste den Stick einmal vom USB Port abziehen und neu definieren, sofort sprang er auf Initialized

hjgode · 27 Dezember 2016, 17:46:26

Zitat von: t1me2die am 27 Dezember 2016, 16:07:11
So, mein nanoCUL steht nun auf "Initialized", musste den Stick einmal vom USB Port abziehen und neu definieren, sofort sprang er auf Initialized

Ja, das ist immer wieder komisch: Nach dem Flashen muss man die nanCULs immer von USB trennen und wieder anstecken. Bei mir blinkt sonst eine LED auf dem Nano wie verrückt und nix geht. Kann wohl keinen anständigen Reset nach dem Flashen...

~Josef

Bennemannc · 27 Dezember 2016, 19:29:16

Hallo,

noch mal zum SignalDuino und CUL443

ZitatDer Cul dekoriert die single im Prozessor. Der duino im PC. Dadurch ist der duino etwas unempfindlicher gegen Störungen.

Ich dachte die Decodierung wird im OREGON Modul gemacht - und das nutzen beide. Liegt es daran, das der CUL433 erst prüft, was für ein Protokoll das sein könnte? Was passiert, wenn man Protokolle abschaltet?

Gruß Christoph