Alternative culfw

pejonp · 17 März 2016, 18:55:29

Zitat von: scooty am 17 März 2016, 17:52:52
...
mmh, meine Frage nach möglicher Einbindung SD_WS09 ...

Hallo andreas,

ich habe jetzt erst deine Frage gesehen. Was für eine WH1080 hast du den ? Schau mal hier ->https://forum.fhem.de/index.php/topic,39451.msg363597.html#msg363597, dort werden die Unterschiede beschrieben. Machbar ist sicherlich vieles. Aber einen Nano + 868MHz Empfänger (OOK) + esp6288 geht auch sehr gut.

pejonp

scooty · 18 März 2016, 08:56:27

Hallo pejonp,

danke für Deine Antwort.
Meine WH-1080 ist wohl die

Zitat2. Wetterstation 868MHz FSK Protokoll

Bezeichne mich selbst als "elektrotechnische Wildsau"

und traue mir weder eine Bestellung der richtigen Komponenten für einen SIGNALduino/anderen Empfänger noch einen Zusammenbau zu. Daher meine (vielleicht trotzdem blöden) Idee der Integration der Empfangsmöglichkeit in der a-culfw.

Nochmals zu meiner Idee:

ZitatKönnte die a-culfw (und/oder noch andere Komponenten?) erweitert werden, um den 868MHz Empfang im Zusammenspiel mit dem Modul 14_SD_WS09.pm zu ermöglichen?
Ähnliches (zumindest habe ich es so verstanden) ist ja auch schon mit für den 433MHz Empfang im Zusammenspiel mit dem Modul 14_SD_WS07.pm in der a-culfw implementiert.

Ist so was überhaupt ein Ansatz?

Viele Grüße,
Andreas

Waldmensch · 18 März 2016, 17:40:16

Ich habe bei meiner Fehlersuche bezüglich RFR auch die alternative culfw probiert. Dort tritt aber das gleiche Kommunikationsproblem auf. Zur genauen Beschreibung und Logs bitte mal hier schauen, auch wenn der Betreff etwas irreführend ist geht es letztlich um ein Kommunikationsproblem CUL <-> RFR https://forum.fhem.de/index.php/topic,50756.0.html

Das Problem ist, so vermute ich, das der RFR ein abgesetztes FS20 Schaltsignal einfängt und an den CUL/COC der am FHEM hängt zurückliefert. Dieser kann damit aber nichts anfangen. FS20 Signale werden somit komplett verschluckt.

Was mir aufgefallen ist, im "nanoCUL" Device ist die RFR Option überhaupt nicht enthalten. Auch FHT fehlt in der board.h komplett.

Ist der RFR bewußt aus dem nanoCUL entfernt?

bjoernh · 18 März 2016, 18:53:37

Zitat von: Waldmensch am 18 März 2016, 17:40:16

Was mir aufgefallen ist, im "nanoCUL" Device ist die RFR Option überhaupt nicht enthalten. Auch FHT fehlt in der board.h komplett.

Ist der RFR bewußt aus dem nanoCUL entfernt?

Bewusst nicht, da der nanoCUL aber etwas wenig Speicher hat, macht es keinen Sinn alles per default an zu machen.

Waldmensch · 18 März 2016, 19:34:21

Alles per default an muss ja nicht. Die Lösung mit der Gruppierung der Protokolle nach 433 und 868 ist schon super. Eventuell könnte man noch ein #define slow_rf machen und da dann die FHT etc reinpacken und die HM etc ausklammern. Der RFR geht ja auch nur mit slowrf. Im makefile könnte der Verweis auf die rf_router.c standardmässig mit rein. Über die Compiler Direktiven kommt es ja eh nur ins Image, wenn es in der board.h definiert ist, oder seh ich das falsch? Da die NanoCUL quasi saubillig sind, könnte man ja durchaus für jedes Protokoll einen separaten nehmen

Gesendet von iPhone mit Tapatalk

HansDampfHH · 19 März 2016, 18:19:51

Hallo, ich stehe leider noch etwas auf dem Schlauch.
Ich habe einen Selbstbau-CUL433 und CUL868. Beide funktionieren tadellos.

Mit dem 433 steuer ich meine IT1500 Steckdosen und mit dem 868 einen FS20 Dämmerungssensor.

Versionen

Code Auswählen


nanoCUL433 raw => V 1.65 nanoCUL433 
nanoCUL868 raw => V 1.65 nanoCUL868

Wenn ich es richtig verstehe könnte ich auf diesen CULs auch die alternative Firmware flashen?
Gerne würde ich nämlich Temperatursensoren (GT-WT-01) nutzen die man wohl mit der alternativen Firmware nutzen kann.

Kann mir jemand bitte sagen, ob ich diese Sensoren mit:

der alternativen Firmware nutzen kann?
welchen meiner CUL ich umflashen müsste?
wenn ich einen CUL umflashe, kann ich dann weiterhin den Dämmerungssensor (CUL868) oder die IT1500 Steckdosen (CUL433) steuern?
oder müsste ich hier einen anderes Protokoll nutzen und würde somit noch einen weiteren CUL benötigen?

christian-ruh · 20 März 2016, 12:57:21

Guten Tag,
es geht in meiner Frage um das Aufspielen der a-culfw.

Nach dem ich nun die 55 Seiten (fast) vollständig gelesen habe sehe ich wohl den Wald vor lauter Bäumen nicht.
Habe einen 433 CUL_V3 am laufen (RasPi2) ud schalte damit Steckdosen. Funktioniert gut.
Nun habe ich gelesen dass es möglich ist die Pearl Außenthermometer zu empfangen mit der alternativen Firmware.
Habe diese runtergeladen (a-culfw_1.20.06_build_199_master.zip).
So, und nun meine Frage.
Wie schaffe ich es diese Firmware auf den Stick zu bringen? Gibt es dafür eine einfache Anleitung?
Hab die entpackten Dateien auf den RasPi kopiert. Wie läuft nun das aufspielen / flashen?
Vielen Dank im Voraus für Eure Infos.
Ich wünsche noch einen schönen Sonntag und einen schönen Frühlingsanfang.
LG Christian

cs-online · 20 März 2016, 13:55:48

Hallo,

Vorausgesetzt, Du hast den AVRDUDE installiert, dann normalerweise das .zip auf den Raspi runterladen und in einem Verzeichnis entpacken, in dem Du Schreibrechte hast, dann mit dem Terminal in das Verzeichnis, in dem die .hex für Dein Device liegt, dann mit

Code Auswählen


sh flash.sh

das Flashskript starten. Device auswählen und los...

Wenn Du die Source runtergeladen hast, dann ebenfalls mit dem Terminal in das Verzeichnis, wo Dein Device (CUL) drin ist, mit

Code Auswählen


make

den Compilervorgang starten, wenn das fertig ist, wie oben mit dem Skript flashen

Grüße

Christian

cs-online · 20 März 2016, 14:10:28

Zitat von: HansDampfHH am 19 März 2016, 18:19:51
Kann mir jemand bitte sagen, ob ich diese Sensoren mit:

der alternativen Firmware nutzen kann?
welchen meiner CUL ich umflashen müsste?
wenn ich einen CUL umflashe, kann ich dann weiterhin den Dämmerungssensor (CUL868) oder die IT1500 Steckdosen (CUL433) steuern?
oder müsste ich hier einen anderes Protokoll nutzen und würde somit noch einen weiteren CUL benötigen?

Hallo Hans,

ob Bjoern die integriert hat, habe ich leider nicht gefunden, aber lt. Ebay senden die auf 433Mhz, also wenn, dann den 433er umflashen und probieren.
Den 868 so lassen, dann ändert sich dort auch nichts.
Ob IT dann weiter funktioniert, ist so eine Sache, bei einigen geht es, bei anderen (mir z.B.) geht Empfang, aber nicht senden, auch das einmal probieren... Im Zweifel kannst Du ja wieder auf 1.65 zurück flashen...

Und dann bitte hier berichten.

Grüße

Christian

cs-online · 20 März 2016, 14:12:34

Hi Bjoern,

Du hast ja schon irre viele Protokolle für etliche Geräte implementiert, super Arbeit ! Gibt es eigentlich auch irgendwo eine Liste analog der Jeelink-Liste, welche Geräte / Sensoren mit der a-FW laufen ?

Grüße

Christian

christian-ruh · 20 März 2016, 15:16:09

Hallo CS-online,
danke für die schnelle Info. Ich habe für das erste flashen dfu-programmer installiert.
AVRDUDE hab ich nicht installiert.
Ich hab die Dateien entpackt auf einem Windows Rechner und auf den RasPi kopiert.
Diese Dateien sind im Verzeichnis:

Code Auswählen

CUL_V2_433MHZ.hex
CUL_V2_868MHZ.hex
CUL_V2_HM_433MHZ.hex
CUL_V2_HM_868MHZ.hex
CUL_V2_MAX_433MHZ.hex
CUL_V2_MAX_868MHZ.hex
CUL_V3_433MHZ.hex
CUL_V3_868MHZ.hex
CUL_V3_ZWAVE_868MHZ.hex
CUL_V4_433MHZ.hex
CUL_V4_868MHZ.hex
flash.sh
README.md

Wenn ich nun sh flash.sh eingebe kommt folgendes:

Code Auswählen

flash.sh: 15: flash.sh: Bad substitution
-------------------------------------------------------------
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):

Dann habe ich 9 eingeben da es ja ein CUL3 433MHZ ist.
Dann kommt:

Code Auswählen

Please select device (1-5): 9
flash.sh: 45: [: X9: unexpected operator
flash.sh: 49: [: 9: unexpected operator
flash.sh: 52: [: 9: unexpected operator
flash.sh: 55: [: 9: unexpected operator
flash.sh: 58: [: 9: unexpected operator
flash.sh: 61: [: 9: unexpected operator
flash.sh: 64: [: 9: unexpected operator
flash.sh: 67: [: 9: unexpected operator
flash.sh: 70: [: 9: unexpected operator
flash.sh: 73: [: 9: unexpected operator
flash.sh: 76: [: 9: unexpected operator

The device will now be flashed
Continue (y/n)?y
flash.sh: 85: [: y: unexpected operator
Abort flash

Was ist hier denn falsch?

Nochmals vielen Dank
Gruß
Christian

Update:
Sollte es jemanden interessieren, ich hab das jetzt manuell gemacht und folgende codes im Putty eingegeben (vorher im FHEM "set CUL1 raw B01"):

Code Auswählen

dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash CUL_V3_433MHZ.hex
dfu-programmer atmega32u4 start

Funktioniert

thitcher · 31 März 2016, 21:33:54

Hallo FHEM-Begeisterte.
Ich bin gerade dabei mich in die Materie einzuarbeiten.
Ich benutze seit einigen Jahren den Lightmanager (inzwischen bin ich auf die AIR-Version Umgestiegen) und habe mir damit bisher alles schön automatisiert.
Nun möchte ich aber der Vielfalt wegen auch mal mit FHEM experimentieren.
Also habe ich mir FHEM auf meinen Raspberry 2 gezogen und mir einen nanoCUL aus einem 433MHz-Modul und einem Arduino zusammengebastelt.
Dann ahbe ich das ganze mit der culfw geflashed (neueste Version) und meine schaltbefehle des Lightmanagers mitgesniffed und devices angelegt.
Das hat bisher alles wunderbar funktioniert....Bis ich dimmen wollte

Das ging leider mit meinen Intertechno Dimmern nicht.
Also habe ich mich weiter umgesehen und bin auf die alternative culfw gestoßen.
Diese habe ich geflashed und kann nun dimmen.
Allerdings kann ich keinerlei Signale mehr von meinem Lightmanager (im folgenden LM genannt) mitsniffen, wenn ich mit dem LM die Aktoren steuere, dann bleibt mein Eventmonitor einfach leer.
Die Aktoren selbst kann ich aber mit FHEM bedienen und mein LM zeigt mir im Live-Modus dann auch an das FHEM den richtigen Code sendet...
Flashe ich wieder auf die originale Version, klappt alles wunderbar. Ich bediene mit dem LM einen Aktor und FHEM zeigt es mit an.

Ich kann natürlich erstmal alle Aktoren mit der original culfw anlernen und dann umflashen, dennoch würde ich gerne wissen wo der Hase im Pfefer liegt.
Hat vielleicht jemand einen Tipp für mich?

Greez

Matze

sash.sc · 01 April 2016, 08:14:46

Wenn du die afw drauf hast und den cul definiert, dann stelle doch mal auf verbose 5 hoch und schaue was in Event Monitor passiert.

Von mobil gesendet daher kurze Antwort

thitcher · 01 April 2016, 09:40:51

werd ich heute Abend machen, danke für den Hinweis!

thitcher · 01 April 2016, 19:14:15

So,
jetzt hab ich mal verbose auf 5 gestellt.
Dann mit meiner Fernbedienung (ITT-1500) einen Aktor geschaltet.
Dabei meldete der Monitor folgendes:

Code Auswählen

2016-04-01 18:44:42 Global global UNDEFINED IT_0100001100100101111111111000000 IT 01000011001001011111111110 0 0000
2016-04-01 18:44:42 Global global DEFINED IT_0100001100100101111111111000000
2016-04-01 18:44:42 Global global DEFINED FileLog_IT_0100001100100101111111111000000
2016-04-01 18:44:42 Global global SAVE
2016-04-01 18:44:42 IT IT_0100001100100101111111111000000 off

Danach habe ich denselben Aktor mit dem Lightmanager angesteuert, der Event Monitor blieb leer, der Aktor schaltete.

Im LM kann ich den HEXcode des Aktors ablesen (siehe screenshot), dieser lautet 4325FF80.
Diesen code habe ich dann im Taschenrechner in Binär umgerechnet.
Das Ergebnis lautet:
‭

Code Auswählen

‭01000011001001011111111110000000‬

Vergleiche ich nun beide Binärcodes, so stellt sich folgendes Bild dar:

erster Code: mit Fernbedienung gesendet, im Event Monitor ausgegeben
zweiter Code: vom LM gesendet, taucht im Event Monitor nicht auf, HEX in BIN umgerechnet.

Code Auswählen


‭1: 01000011001001011111111110000000‬
2: 0100001100100101111111111000000

beim LM fehlt eine Null.....
Oder mach ich was falsch?

Alternative culfw

thitcher

thitcher

thitcher