Alternative culfw

[bjoernh]

Hallo, ich habe die aktuelle FW auf meinem SCC, bekomme es aber nicht auf 433 MHz umgestellt.

Grüße
Cerberus

Ruf mal ccconf neu ab, oder starte Fhem neu.

[cerberus]

ccconf sagt das

Code Auswählen Erweitern

SCC2 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB



Neustart bringt auch nichts. Das 433 SCC ist STACKABLE auf einem 868 SCC welches die normal CUL FW V 1.66 CSM868 drauf hat. Ist ein Mischbetrieb mit der a-culfw auf dem SCC 433 möglich?

Grüße
cerberus

[bjoernh]

ccconf sagt das

Code Auswählen Erweitern

SCC2 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB



Neustart bringt auch nichts. Das 433 SCC ist STACKABLE auf einem 868 SCC welches die normal CUL FW V 1.66 CSM868 drauf hat. Ist ein Mischbetrieb mit der a-culfw auf dem SCC 433 möglich?

Grüße
cerberus

Kann es sein, dass Du den CUL auf HomeMatic anstatt auf SlowRF gestellt hast?

[cerberus]

Genau das war es   

Danke schön 

[juliusha]

Hallo Björn und natürlich auch alle anderen,

ich versuche meinen CUL_868_V3 mit der a-culfw_v1.21.00_build_71 zu flashen.
Ich habe dazu den CUL zum Flashen vorbereitet und dann im Pi sh ./flash.sh aufgerufen.
Als Auswahl habe ich die '4' genommen. Daraufhin habe ich die folgenden Meldungen bekommen.

Code Auswählen Erweitern

The device will now be flashed
Continue (y/n)?y
Flash now device
Call: dfu-programmer atmega32u4 erase
dfu-programmer: no device present.
Call: dfu-programmer atmega32u4 flash CUL_V3_868MHZ.hex
dfu-programmer: no device present.
Call: dfu-programmer atmega32u4 start
dfu-programmer: no device present.
Kann mir jemand sagen was ich da falsch mache oder evtl. falsch verstanden habe.
Danke in Voraus
Es grüßt der Julius

[mahowi]

Hallo Julius!
Ich würde sagen, Du hast entweder das falsche Device gewählt oder den CUL nicht in den Bootloader gebootet zum Flashen.

[juliusha]

Hallo mahowi, ich habe in der FHEM-Console den Befehl 'set CUL1 raw B01' eingegeben.
Danach auf dem Raspi als sudo 'sh ./flash.sh' aufgerufen.
Kurz vorher hatte ich mir noch die aktuellste CUL-FW 'culfw-1.66' heruntergeladen und erfolgreich geflasht.
Allerdings da mit dem aufruf 'sudo make usbprogram_v3'. Hier hatte alles reibungslos geklappt.
Im Verzeichnis der culfw-1.66 ist allerdings die cul.c-datei vorhanden, die hier bei der alternativen FW fehlt.
Aber wenn ich alles richtig verstehe, dann müsste eigentlich alles in der bash-datei enthalten sein?!

Danke für evtl. Antworten sagt
der Julius

[cerberus]

Hallo, ich setze eine Oregon Wetterstation mir verschieden Sensoren ein. Dazu gehören 2x THGR800 und 1x THGR810 für Temperatur/Feuchte, UVN800 für UV Strahlung, WGR800 für Windgeschwindigkeit und Richtung sowie ein PCR800 für die Regenmenge. Alle Sensoren senden sehr regelmäßig an die Wetterstation, was man hier deutlich hier sehen kann www.wetter-walschleben.de. Nun möchte ich einige Werte der Sensoren auch für FHEM verwenden um mir weitere Sensoren z.B. von Homematic zu sparen. Ich habe dazu schon einen nanoCUL und eine Signalduino gebaut sowie letztlich ein SCC erstanden welches ich mit der a-culfw einsetze. Was ich bei allen Versuchen feststelle ist, das die THGR800 sehr unregelmäßig empfangen werden, obwohl alle Sensoren in ähnlicher Reichweite sind. Auch mit einer größeren Antenne 6dbi habe ich nur mäßigen Erfolg. Der THGR810 hingegen wird viel besser gelesen, was ihr in den Plots auch sehen könnte. Im Plot sieht am auch bei den Sensoren Garage und Carport ganze Bereiche ohne jegliche Daten, insbesondere in der Nacht. Auch der Windsensor wird nur mäßig gelesen. Die Sensoren für UV und Regen werden zudem nicht erkannt.

Was ist die Ursache für den schlechten Empfang oder evt. das schlechte decodieren das Funksignal der THGR800? Sind die Sensoren UVN800 und PCR800  überhaupt implementiert?

Grüße
cerberus

[KölnSolar]

schwierig zu sagen, da es bei den Oregon-Sensoren nicht DAS Protokoll gibt. Es gibt wohl 3 "technische" Protokolle, davon sind nach meinem Verständnis V2 und V3 in der aculfw implementiert. Damit sollten auch eigentlich ALLE Sensoren technisch empfangen werden. ABER: Die Interpretation der empfangenen Daten ist wohl je nach Gerätetyp unterschiedlich u.a. auch die Methode zur Berechnung von Checksummen.

Edit: wg. geistiger Verwirrung gestrichen
Ich hatte mir mal die Oregon-Implementierung zum FHEMduino angesehen. Damit ließe sich sogar OREGON senden ! Und nun kommt der Laie: Kannst Du einen nanoCUL oder Signalduino auf FHEMduino umflashen oder sind die hardwaremäßig anders aufgebaut ?
Grüße, Markus

[bjoernh]

Die Hardware ist anderes aufgebaut. Zumindest zwischen cul und SIGNALduino gibt es große Unterschiede.

Zum Empfang: Das der Cul die Oregons nicht richtig erkennt kann schon sein. 
Ich habe selber keine Oregon Sensoren und habe mir dann mit einem Arduino  einen Testsender gebaut. Gegen diesen Testsender habe ich dann den Code implementiert. Ich denke dass man am Code bestimmt noch etwas tunen kann,  so dass er besser empfängt.
Um einen besseren Empfang zu bekommen, kann man alle nicht benötigten Protokolle im Code deaktiviert.  Vorallem das TCM und IT ist kritisch.  Da muss der Cul sehr genau berechnen was das für ein empfangenes  Paket ist.
Die original Wetterstation empfangen ja auch nur ihr Protokoll und verwerfen alles andere.
Der sinalduiono geht deshalb  einen anderen Weg als der Cul.  Er schickt alles was empfangen wird an das Fhem.  Fhem muss dann die Decodierung übernehmen und entscheiden was empfangen würde.

[juliusha]

Hallo, ich habe meinen Fehler gefunden!
Anstelle 'sh ./flash.sh' wie es in der 'README.md' steht habe ich nun 'sh flash.sh' eingegeben.
Doch nun bekomme ich die Meldung 'Bootloader and code overlap'
Hier:

Code Auswählen Erweitern

pi@raspberrypi ~/a-culfw_v1.21.00_build_71/Devices/CUL $ sudo sh flash.sh
-------------------------------------------------------------
This program flash the cul device with new firmware.
Please change the device into the bootloader
-------------------------------------------------------------
Please choose a device:
1 = CUL_V2 868MHZ
2 = CUL_V2_HM 868MHZ
3 = CUL_V2_MAX 868MHZ
4 = CUL_V3 868MHZ
5 = CUL_V4 868MHZ
6 = CUL_V2 433MHZ
7 = CUL_V2_HM 433MHZ
8 = CUL_V2_MAX 433MHZ
9 = CUL_V3 433MHZ
0 = CUL_V4 433MHZ
Please select device (1-5): 4

The device will now be flashed
Continue (y/n)?y
Flash now device
Call: dfu-programmer atmega32u4 erase
Call: dfu-programmer atmega32u4 flash CUL_V3_868MHZ.hex
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore
Call: dfu-programmer atmega32u4 start
Die Meldung 'Use --suppress-bootloader-mem to ignore' verstehe ich nicht.
Sollte ich -und wenn ja- wie ignoriere ich dies?
Über freundliche Antworten würde ich mich freuen!
Der Julius

[bjoernh]

Hallo, ich habe meinen Fehler gefunden!
Anstelle 'sh ./flash.sh' wie es in der 'README.md' steht habe ich nun 'sh flash.sh' eingegeben.
Doch nun bekomme ich die Meldung 'Bootloader and code overlap'
Hier:

Code Auswählen Erweitern

pi@raspberrypi ~/a-culfw_v1.21.00_build_71/Devices/CUL $ sudo sh flash.sh
-------------------------------------------------------------
This program flash the cul device with new firmware.
Please change the device into the bootloader
-------------------------------------------------------------
Please choose a device:
1 = CUL_V2 868MHZ
2 = CUL_V2_HM 868MHZ
3 = CUL_V2_MAX 868MHZ
4 = CUL_V3 868MHZ
5 = CUL_V4 868MHZ
6 = CUL_V2 433MHZ
7 = CUL_V2_HM 433MHZ
8 = CUL_V2_MAX 433MHZ
9 = CUL_V3 433MHZ
0 = CUL_V4 433MHZ
Please select device (1-5): 4

The device will now be flashed
Continue (y/n)?y
Flash now device
Call: dfu-programmer atmega32u4 erase
Call: dfu-programmer atmega32u4 flash CUL_V3_868MHZ.hex
Bootloader and code overlap.
Use --suppress-bootloader-mem to ignore
Call: dfu-programmer atmega32u4 start
Die Meldung 'Use --suppress-bootloader-mem to ignore' verstehe ich nicht.
Sollte ich -und wenn ja- wie ignoriere ich dies?
Über freundliche Antworten würde ich mich freuen!
Der Julius

Die Option solltest du auch nicht verwenden,  sonst zerstörst du den Bootloader.
Der Punkt ist,  dass der Code mal wieder zu groß für den verfügbaren Speicher ist.
Da hilft nur abspecken bzw aufsplitten.

Was willst du überhaupt empfangen?
Viele meiner Erweiterungen sind nur 433Mhz relevant.  Du kannst also z. B für  HomeMatic auch die Original Firmware verwenden.  Da hat sich nichts im HomeMatic Code geändert.

Aber ich schau trotzdem mal was man noch deaktivieren kann.

[KölnSolar]

Ahh, danke für die Aufklärung zum Prinzip des Signalduino !
Und noch was hab ich gelernt: Den Käse den man schreibt VORM posten lesen 
Björn, kannst Du bitte das Zitat wie aus meinem Post streichen. Ich hatte OREGON und das Protokoll für Flamingo-Rauchmelder gedanklich in einen Topf geworfen. Nochmal 
Markus

[juliusha]

Hallo bjoernh,
ich möchte zusätzlich zu den 'normalen FS20'-Geräten auch noch 433Mhz-Devices empfangen.
Ich hoffe damit einige der hier vorhandenen Temp/hum-Sender empfangen zu können.
Gruß

Julius

[noice]

Hallo bjoernh,
ich möchte zusätzlich zu den 'normalen FS20'-Geräten auch noch 433Mhz-Devices empfangen.
Ich hoffe damit einige der hier vorhandenen Temp/hum-Sender empfangen zu können.
Gruß

Julius

das lässt sich nur durch 2 "CUL´s" verwirklichen. optimaler Weise einer mit 433 und einer mit 868 Sende Empfangseinheit.