culfw@ARM

[kFieLd]

Was muss ich machen, um dem ins Netzwerk einzubinden - die IP habe ich, aber welche Port ?

Meinst du vielleicht das hier, um den Cube als Netzwerk-CUL einzurichten?

Code Auswählen Erweitern

define MaxCubeLAN CUL 192.168.0.55:2323 0000

[Telekatz]

Wenn deine IP Adresse 192.168.0.55 ist, ja.

[Bennemannc]

Hallo,

so habe ich das auch gemacht. Die IP und der Port ist 2323. Beim CFG-LAN ist es 1000 bei ESP-Link die 23 --- sehr verwirrend. Könnte man sich - zumindest für die selbstgeschriebenen Sachen nicht auf einen Port einigen? Das wäre für Leute die damit neu anfangen einfacher.

Gruß Christoph

[Telekatz]

Die Leute, die damit neu anfangen, können und sollten sich auch die Dokumentation in der commandref ansehen. Da steht es auch drin.

Code Auswählen Erweitern

Define

    define <name> CUL <device> <FHTID>

    USB-connected devices (CUL/CUN):
        <device> specifies the serial port to communicate with the CUL. The name of the serial-device depends on your distribution, under linux the cdc_acm kernel module is responsible, and usually a /dev/ttyACM0 device will be created. If your distribution does not have a cdc_acm module, you can force usbserial to handle the CUL by the following command:
            modprobe usbserial vendor=0x03eb product=0x204b In this case the device is most probably /dev/ttyUSB0.

        You can also specify a baudrate if the device name contains the @ character, e.g.: /dev/ttyACM0@38400

        If the baudrate is "directio" (e.g.: /dev/ttyACM0@directio), then the perl module Device::SerialPort is not needed, and FHEM opens the device with simple file io. This might work if the operating system uses sane defaults for the serial parameters, e.g. some Linux distributions and OSX.

    Network-connected devices (CUN(O)):
        <device> specifies the host:port of the device, e.g. 192.168.0.244:2323

    If the device is called none, then no device will be opened, so you can experiment without hardware attached.
    The FHTID is a 4 digit hex number, and it is used when the CUL talks to FHT devices or when CUL requests data. Set it to 0000 to avoid answering any FHT80b request by the CUL.

[dbeu]

Ich habe leider ein Problem mit meinem auf culfw geflashten Cube.
Viele Wochen problemlos im Einsatz, wurde er auf einmal von fhem nicht mehr erkannt ("no answer").
Auf dem seriellen Interface konnte ich ihm dann nur ein "Cubeloader V1.01" entlocken, woraus ich nehme das er wohl irgentwie seine Firmware verloren hat ?
Versuche ihn neu zu flaschen (habe die Versionen 1.20.08(von dieser der Bootloader), 1.21.01 sowie die aktuelle 1.23.05 versucht) enden entweder in einem nicht vollständigen Transfer (alle Led sind aus) oder darin, das D3 permanent leuchtet und D1 etwa im sekundentakt blinkt. Jedoch erhalte ich kein serielles Interface und wenn ich den Cube neu verbinde ist er wieder im flash-Modus (D1 schnell am blinken) und ich erhalte wieder nur "Cubeloader V1.01" auf ein großes V.

Was ist zu tun?
Grüße und besten Dank

[Telekatz]

Schau mal nach, ob der Taster an der Unterseite hängt.

[dbeu]

Nein, der scheint freigängig zu sein.
Edit:
Muss mich korrigieren, nachdem ich den Plastiktaster hochgebogen hatte und den Taster mehrfach betätigt habe scheint das Problem gelöst.
Vielen Dank, schon merkwürdig das der Schalter das auf einmal macht - hattest du so einen Fehler schon?

[Telekatz]

Nein, aber das ist der einzige Grund, warum er trotz geladener Firmware immer wieder in den Bootloader springen würde.

[freetz]

Hallo,

vielleicht habe ich es auf den 46 Seiten des Threads überlesen, aber zumindest in der aktuellen Version auf Mediafire gibt es im CUBe Verzeichnis keine bootloader_CUBE.bin Datei, nur die CUBE_BL.bin. Wo finde ich den Bootloader?

Danke schon mal und Gruß,

F.

[Oern]

Mehrfach überlesen  Habe auch lange gesucht.

Schau mal in den Vorgängerversionen, dort findest du sie.

Gesendet von meinem HTC One_M8 mit Tapatalk

[freetz]

Danke für die schnelle Rückmeldung! Nun habe ich den Bootloader geflasht (unter Mac OSX mit bossash), habe nun aber das Problem, dass beim Einstecken die D1-LED nur einmal kurz aufblinkt. Auch beim Drücken des Reset-Tasters ändert sich das nicht, nur bei jedem 10. Versuch leuchtet die LED durchgängig auf. Ich habe dann in beiden Modi immer mal wieder einen XModem-Upload probiert, und ich weiß nicht, ob es damit zusammenhängt, aber manchmal erschien dann in dem Zusammenhang im Terminal Programm die Kennung CUBELOADER V1.01. Aber auch dann startete der XModem-Upload nicht.

Von daher meine Frage, ob man den Upload im Bootloader noch irgendwie aktivieren muss (ich habe irgendwo was von Shift + V gelesen)?
Und kann/sollte ich sonst den Bootloader noch einmal neu flashen? Unter bossash wird mir nun allerdings nach einem Scan kein Gerät mehr angezeigt, das geflasht werden könnte, auch nach erneutem Schließen von JP1.
Edit: Das Schließen des Jumpers hat nun doch dazu geführt, dass ich den Bootloader neu schreiben konnte, aber jetzt mit dem Ergebnis, dass danach nun gar keine LED mehr leuchtet (außer D2 und D3 für den Bruchteil einer Sekunde beim USB-Kabel-Einstecken) und ich nurmehr über JP1 wieder zum Bootloader-Flashen zurück muss. Sehr seltsam...
Edit: Nach gefühlten Dutzend Versuchen jetzt einmal mit der Bossa GUI probiert, geschrieben, verified, zuerst nichts, dann auf Info geklickt (wo mir vorher die Chip-Infos des Cube angezeigt wurden), da kam dann eine Fehlermeldung und die LED D1 blinkt nun wieder 4x pro Sekunde. Upload klappt immer noch nicht, wenn ich dann den Cube abziehe und wieder anstecke, blinkt die LED zuerst wieder, um dann dauernd zu leuchten.

Freue mich über jeden Hinweis, vielen Dank und gute Nacht,


F.

[freetz]

Folgendes konnte ich jetzt reproduzieren:
- Der Flash-Speicher scheint nicht immer korrekt geschrieben zu werden. Wenn ich nach dem Schreiben das Flash auslese, sind in mehreren Fällen nur "ff" in den Speicherstellen gewesen. Manchmal (mit unterschiedlichen Kabeln getestet) hatte ich Glück und das Verify hat keine Fehler ergeben.

- Wenn das Verify erfolgreich war, hat LED D1 nach dem Wiedereinstecken ein paar Sekunden lang realtiv schnell geblinkt, dann war sie aus. Beim Wiedereinstecken leuchtet sie jetzt einmal kurz auf und ist dann aus.

- Ein Zugriff über minicom hat auch mit Shift-V nichts gebracht, obwohl zwei Devices beim Einstecken angelegt werden (cu.usbmodem1421 für das USB-Device und tty.usbmodem1421 für das serielle).

Entweder habe ich mehrere schlechte Kabel, von denen einige weniger schlecht sind als andere und dann zumindest beim Schreiben mal funktionieren oder es gibt sonst noch eine Schwachstelle, die dafür sorgt, dass die Kommunikation zum einen beim Flashen, zum anderen beim späteren Zugriff über das Terminal nicht in Ordnung ist.

Freue mich über jeden Tipp, vielen Dank schon mal,


F.

[freetz]

Ok, habe es nun selber lösen können, vielleicht sind meine Problemschilderungen aber für andere Mac-Besitzer von Nutzen:
Mit einem alten Ubuntu-Laptop hat das Flashen nun gleich auf anhieb geklappt (gleich auch mehrfach getestet). Allerdings hat der selbst kompilierte Bootloader den Effekt gezeigt, dass die LED D1 eben nur 1-2 Sekunden schnell geblinkt hat und dann auf Dauerleuchten gegangen ist. Ein Flashen der Firmware über ein Terminalprogramm (hier auch minicom) funktionierte hier nicht.
Ich habe dann aus der Version 1.20.08_build_220 die bootloader_CUBE.bin genommen, diese geflasht und dann blinkte D1 dauernd schnell. Nach dem Ab- und Anstecken des Cubes konnte ich dann mit minicom die Firmware hochladen. Hier funktioniert interessanterweise auch die selbst kompilierte Version (mit Toolchain 5.4.1). Nach dem Flashen konnte ich dann mit dem Terminal den Cube (bzw. jetzt CUL ) konfigurieren und er empfängt fleißig die Nachrichten meiner Max-Geräte .

Was das Problem jetzt am Mac war, konnte ich nicht weiter identifizieren. Seltsam ist das schon, denn das Flashen meines Busware-Sticks hat ohne Probleme funktioniert. Im Übrigen hatte ich auch kein Glück mit Windows XP unter Parallels Desktop auf dem Mac, dort wurde zwar der resettete Cube von Windwos auch erkannt, aber Bossa hat ihn nicht als flashbares Gerät gesehen. Ich habe da dann auch nicht weiter Zeit hineingesteckt. Ein alter Laptop mit einem Linux-Derivat ist da vielleicht doch immer noch die einfachste Variante.

Gruß und Danke auf jeden Fall noch mal an Telekatz für diese tolle Arbeit!


F.

[tca]

Hallo,

ich habe einen Max!Cube mit der Version a-culfw_1.23.05 geflashed und in fhem eingebunden. Jetzt möchte ich meine TechemHKV über WMBus_T empfangen, es wird aber nichts angezeigt/empfangen. Bis jetzt hat das über eine andere CUL (COC) gut funktioniert.

Sollte das auch mit a-culfw funktionierten, bzw. muss man noch etwas einstellen?

Danke im Voraus,
Tom

[Telekatz]

Probier mal, ob es mit der angehängten Version funktioniert.