Alternative culfw

[RaspiLED]

Hi madronix,
bitte KölnSolar nicht falsch verstehen. Das ist kein Problem der FW sondern der Hardware, da er und übrigens auch ich letzte Woche noch einen Busware V3 erfolgreich mit a-culfw über die flash.sh  geflasht haben

Der eigene Thread von Dir sollte die genaue Bezeichnung des CULs enthalten, beschreiben ob noch eine alte CUL FW drauf ist, falls ja ein list des Devices in FHEM in Code Tags zeigen. Und ganz wichtig: Was genau Du machst, um den Fehler zu erhalten (fertige a-culfw Firmware Dateien von mediafire oder selbst compiliert von github, etc...)!

Meine Glaskugel vermutet, dass Du eine selbstgebaute FW 433MHz mit zu vielen aktivierten Protokollen flashen willst !?

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...

[hme]

Hi, ich würde gern mit der a-culfw die Technoline TX29DTH-IT Sensoren empfangen. Momentan habe ich die (m.W.) neueste Version der a-culfw (V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) nanoCUL868 (F-Band: 868MHz)) und leider werden die Sensoren nicht empfangen (bzw. per autocreate angelegt). Komischerweise kommt der nanoCUL auch aus dem "Initialized" state nicht heraus...

Gibt es da einen Trick, oder was mache ich falsch?

[cs-online]

Hallo,

der Status "initialized" ist beim Cul der normale Betriebsstatus, soweit also in Ordnung.

Ob Deine FW-Version Lacrosse (das Protokollder Technolines auf 868MHZ) kann, hängt davon ab, wie sie compiliert worden ist. Hast Du eine fertig compilierte genommen oder selber compiliert ?

[hme]

Habe die fertig kompilierte aus dem Mediafire Archiv von https://forum.fhem.de/index.php?topic=35064.0 genommen.

[cs-online]

wenn ich mich nicht ganz täusche, dann compiliert Björn die immer auf 433MHZ, d.h. da wird dann wahrscheinlich zunächst kein Lacrosse drin sein. Bedeutet, Du musst dich leider ein wenig hier einlesen, wie man die einzelnen Komponenten aktiviert und dann compiliert...

[cs-online]

...würde Dir empfehlen, das hier mal anzuschauen, habe ich nachgebaut, kann irgendwo im WLAN eingesetzt werden und läuft TOP !!!

https://forum.fhem.de/index.php/topic,70425.0.html

bzw.

https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x

Ich habe einen WEMOS und den RFM69CW genommen, Platine und ein paar Drähtchen, mehr brauchst Du nicht... Fertich... Sketch ist fertig, einfach aufspielen, konfigurieren, Autocreate an und Pairing für 120s aktivieren, dann legt FHEM alles an was Du brauchst

[E-J-D]

Ich muss noch mal auf das Hideki Protokoll Problem zurückkommen. Ich bekomme über meinen 433er CUL laufend die Meldungen ...

Unknown code P12#751346B5BF1B07B6, help me!

Mein CUL ist aktuell mit a-culfw 1.25.01 und FHEM samt "update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt" auf dem aktuellen Stand.

Wie kann ich diese nervigen Nachrichten nur loswerden!?! Die spammen mein Log total voll...

LG, Eike

[pantau]

Ich habe a-culfw für den CUBe selber übersetzt. Nach dem flashen der CUBEx4_BL.bin ist der CUBe über USB normal zu erreichen, allerdings nicht über Telnet (Connection refused). Er holt sich eine IP Adresse und reagiert auf ping.
Über das Terminal (USB) bekomme ich bei einen Rxx aber immer FF zurück, so dass ich vermute das irgendwas mit dem EEPROM nicht stimmt. Wxx oder e ändert nichts, EEPROM bleibt auf FF.
Compiliert habe ich den unveränderten GIT download unter Linux.
Mit den vorkompilierten HEX File funktioniert alles wie gewünscht.

Hat jemand irgendeine Idee was da beim Selbstkompilieren schief gehen kann? 

[sash.sc]

Ich muss noch mal auf das Hideki Protokoll Problem zurückkommen. Ich bekomme über meinen 433er CUL laufend die Meldungen ...

Unknown code P12#751346B5BF1B07B6, help me!

Mein CUL ist aktuell mit a-culfw 1.25.01 und FHEM samt "update all https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r32/controls_signalduino.txt" auf dem aktuellen Stand.

Wie kann ich diese nervigen Nachrichten nur loswerden!?! Die spammen mein Log total voll...

LG, Eike

Hast du die a-fw drauf oder die FW für den Signalduino?
Laut deinem Update Text die von Signalduino.

Gruß Sascha

Gesendet von meinem SM-T560 mit Tapatalk

[Ralf9]

Ich muss noch mal auf das Hideki Protokoll Problem zurückkommen. Ich bekomme über meinen 433er CUL laufend die Meldungen ...
Unknown code P12#751346B5BF1B07B6, help me!

Wenn ich das richtig überblicke dann kommt das Unknown code von der 14_CUL_REDIRECT
Als Workaround kannst Du hier

Code Auswählen Erweitern

    if ($message_dispatched == FALSE) {
        return undef;
    }

das
return undef;
in

Code Auswählen Erweitern

return"";
ändern.

Oder Du wechselst zum Signalduino.

Gruß Ralf

[Telekatz]

Ich habe a-culfw für den CUBe selber übersetzt. Nach dem flashen der CUBEx4_BL.bin ist der CUBe über USB normal zu erreichen, allerdings nicht über Telnet (Connection refused). Er holt sich eine IP Adresse und reagiert auf ping.
Über das Terminal (USB) bekomme ich bei einen Rxx aber immer FF zurück, so dass ich vermute das irgendwas mit dem EEPROM nicht stimmt. Wxx oder e ändert nichts, EEPROM bleibt auf FF.
Compiliert habe ich den unveränderten GIT download unter Linux.
Mit den vorkompilierten HEX File funktioniert alles wie gewünscht.

Hat jemand irgendeine Idee was da beim Selbstkompilieren schief gehen kann?

Welche GCC Version hast du benutzt?

[pantau]

Welche GCC Version hast du benutzt?

arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)

Das ist die Standardversion von Ubuntu 16.04 LTS

Gibt es eine bevorzugte Version des gcc?

[Telekatz]

Ich verwende aktuell diese Version:
https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update

[pantau]

Ich verwende aktuell diese Version:
https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update

Die Version bekomme ich irgendwie nicht zum Laufen bekommen:
bash: /opt/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: Datei oder Verzeichnis nicht gefunden
Obwohl Pfad und Berechtigungen stimmen. Vermutlich weil das eine 32bit Version ist und ich ein 64bit Linux laufen habe? Die 64bit Version dieser  gcc Ausgabe habe ich nicht gefunden.
Ich habe dann mal mit der allerneusten 6er Version compiliert, gleiches Ergebnis, Firmware läuft, nur all EEPROM Werte sind FF und lassen sich nicht ändern.
Auch ein telnet ip-adresse 65535 geht, wie ich inzwischen rausgefunden habe.

Außerdem habe ich jetzt mal genau den vorgeschlagenen Compiler unter Windows installiert => gleiches Ergebnis
Muss man evtl den Bootloader neu Flashen? Ich habe den Bootloader aus den vorkompilierten Paket drauf und versuche nur die selbst kompilierte CUBEx4_BL.bin zu flashen.

Hast Du denn mit dem Compiler genau die CUBe Firmware aus a-culfw_1.26.01_build_272.zip übersetzt? Die läuft ja bei mir und im Git ist seit September auch nichts geändert. Nur wenn ich selber den make ausführe läuft die CUBEx4_BL.bin nicht...

[Telekatz]

Die Firmwaredateien zum herunterladen bei Mediafire werden von Björn compiliert. Ich weiß es nicht genau, aber ich denke schon, dass er auch die Version 5.4 verwendet.

Mit einer 6er Version von GCC habe ich es glaube ich auch schon mal probiert. Da hat dann aber irgend eine Optimierungseinstellung das Ergebnis versaut. Du kannst es ja mal testweise ohne Optimierung mit -O0 kompilieren.