culfw@ARM

[Pythonf]

hab den widerstand sogar dran gelötet, jumper sind sicher gelöst (habs sogar nachgemessen).
Gibts es dazu eine Anleitung, wie ich die FW direkt aufspielen kann?

[Telekatz]

Du brauchst dazu einen RS232 zu TTL oder USB zu TTL Schnittstellenadapter. Dessen Ausgang wird mit ST1 verbunden (GND mit GND, TXD mit RXD und RXD mit TXD). Die Belegung von ST1 ist Pin1:3,3V, Pin2:TXD, Pin3:RXD und Pin4:GND. In SAM-BA wählst du dann den COM Port des Schnittstellenadapers aus.

[Pythonf]

Einmal konnte ich connecten, aber leider liefert er nun can't connect to at91sam7s128-ek - Das war es dann wohl - Ich hab aber sowieso die Vermutung, das irgendwas Hardware-Technisch nicht einwandfrei ist. Dennoch danke - vielleicht bekomm ich ja nochmal einen MAX Cube oder HMUSB in die Hand an dem ich das ganze erfolgreich austesten kann.

Grüße
Fabian

[rainstormer]

Hallo zusammen,

bin relativ neu in dem Thema und bräuchte etwas Hilfe. Ich habe einen Cube geflasht, jedoch weiß ich nicht so ganz ob ich alles richtig gemacht habe. Von meinem eigenen empfinden her scheint es geklappt zu haben, aber irgendwie scheinen die Settings in FHEM nicht ganz richtig zu sein. Zu sehen im Anhang.

Die Definition in FHEM ist folgende:

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456
attr cm IODev CUL0


Vielleicht kann mir ja jemand helfen.

Danke und Gruß
Chris

[Tatsu]

Hallo zusammen,

bin relativ neu in dem Thema und bräuchte etwas Hilfe. Ich habe einen Cube geflasht, jedoch weiß ich nicht so ganz ob ich alles richtig gemacht habe. Von meinem eigenen empfinden her scheint es geklappt zu haben, aber irgendwie scheinen die Settings in FHEM nicht ganz richtig zu sein. Zu sehen im Anhang.

Die Definition passt soweit. Der State darf aber nicht "opened" sein. Was steht denn im fhem Logfile? Bist Du Dir sicher, dass der Flashvorgang der Firmware erfolgreich war? Beim Cube hatte ich das noch nicht, aber bei einem NanoCUL nach Flashvorgang - da half ein ab- und anstecken vom USB.

[rainstormer]

Die Definition passt soweit. Der State darf aber nicht "opened" sein. Was steht denn im fhem Logfile? Bist Du Dir sicher, dass der Flashvorgang der Firmware erfolgreich war? Beim Cube hatte ich das noch nicht, aber bei einem NanoCUL nach Flashvorgang - da half ein ab- und anstecken vom USB.

Hey, erstmal danke für die Antwort. Bin mir nicht ganz sicher wie ich erkennen kann ob die Firmware korrekt installiert wurde.

Habe jetzt nocheinmal geflashed und das Log im SAM-BA sieht so aus:

loading history file ... 0 events added
SAM-BA console display active (Tcl8.5.9 / Tk8.5.9)
(sam-ba_2.16) 1 %
(sam-ba_2.16) 1 % send_file {Flash} "C:/Users/Chris/Desktop/bootloader_CUBE.bin" 0x100000 0
-I- Send File C:/Users/Chris/Desktop/bootloader_CUBE.bin at address 0x100000
first_sector 0 last_sector 0
-I-    Writing: 0x3AC0 bytes at 0x0 (buffer addr : 0x202A24)
-I-    0x3AC0 bytes written by applet
Do not lock
(sam-ba_2.16) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.16) 1 %

Ist das soweit korrekt? Das FHEM-Log kann ich heute Abend mal nachschauen.

Danke und Gruß,
Chris

[Telekatz]

Hey, erstmal danke für die Antwort. Bin mir nicht ganz sicher wie ich erkennen kann ob die Firmware korrekt installiert wurde.

Habe jetzt nocheinmal geflashed und das Log im SAM-BA sieht so aus:

loading history file ... 0 events added
SAM-BA console display active (Tcl8.5.9 / Tk8.5.9)
(sam-ba_2.16) 1 %
(sam-ba_2.16) 1 % send_file {Flash} "C:/Users/Chris/Desktop/bootloader_CUBE.bin" 0x100000 0
-I- Send File C:/Users/Chris/Desktop/bootloader_CUBE.bin at address 0x100000
first_sector 0 last_sector 0
-I-    Writing: 0x3AC0 bytes at 0x0 (buffer addr : 0x202A24)
-I-    0x3AC0 bytes written by applet
Do not lock
(sam-ba_2.16) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.16) 1 %

Ist das soweit korrekt? Das FHEM-Log kann ich heute Abend mal nachschauen.

Sieht korrekt aus.

[stenny]

@rainstormer

Ist zwar schon länger her bei mir....

Hast du den manuell angelegt oder ist der automatisch angelegt worden?
Hat anfangs auch ein wenig Probleme beim anlegen.
Lösche ggf mal die Definition, abziehen und einstecken vom Stick und dann mal denn Stick über USB create hieß es glaube ich erkennen (Befehl weiß ich nicht mehr ganz genau, ü d nicht vor Ort zum nachsehen.....)

stenny

Gesendet von meinem HTC One_M8 mit Tapatalk

[rainstormer]

Ok, also das FHEM-Log sagt folgendes:

2016.03.28 15:56:28 1: Including fhem.cfg
2016.03.28 15:56:28 3: telnetPort: port 7072 opened
2016.03.28 15:56:28 3: WEB: port 8083 opened
2016.03.28 15:56:28 3: WEBphone: port 8084 opened
2016.03.28 15:56:28 3: WEBtablet: port 8085 opened
2016.03.28 15:56:28 3: Opening CUL0 device /dev/ttyACM0
2016.03.28 15:56:29 3: Setting CUL0 serial parameters to 9600,8,N,1
2016.03.28 15:56:29 3: CUL0 device opened
2016.03.28 15:56:42 1: Cannot init /dev/ttyACM0, ignoring it (CUL0)
2016.03.28 15:56:42 2: Switched CUL0 rfmode to MAX
2016.03.28 15:56:42 1: CUL_MAX_Check: No IODev has no VERSION
2016.03.28 15:56:42 3: CUL_MAX_Check: Detected firmware version 0 of the CUL-compatible IODev
2016.03.28 15:56:44 2: eventTypes: loaded 581 events from ./log/eventTypes.txt
2016.03.28 15:56:44 3: HUEDevice1: I/O device is hueBridge1
2016.03.28 15:56:44 3: HUEGroup0: I/O device is hueBridge1
2016.03.28 15:56:44 1: Including ./log/fhem.save
2016.03.28 15:56:44 0: Featurelevel: 5.7
2016.03.28 15:56:44 0: Server started with 25 defined entities (fhem.pl:11109/2016-03-21 perl:5.014002 os:linux user:fhem pid:8743)

Kann das eventuell ein Berechtigungsproblem sein? Oder liegt es vielleicht an der Version der Datei? Genommen habe ich a-culfw_1.20.06_build_208_master.zip

Gruß
Chris

[Tatsu]

Ok, also das FHEM-Log sagt folgendes:


Kann das eventuell ein Berechtigungsproblem sein? Oder liegt es vielleicht an der Version der Datei? Genommen habe ich a-culfw_1.20.06_build_208_master.zip

Da du bisher nur auf den Bootloader Teil, also SAM-BA eingegangen bist - das hochladen der eigentlichen Firmware über Terminal/XModem hat auch geklappt?

[rainstormer]

Da du bisher nur auf den Bootloader Teil, also SAM-BA eingegangen bist - das hochladen der eigentlichen Firmware über Terminal/XModem hat auch geklappt?

Ok, das ist jetzt echt mega peinlich. Den Teil habe ich natürlich übersprungen... Wer lesen kann ist klar im Vorteil...

Jetzt läuft das ganze. Sorry für die Unanehmlichkeiten, hätte ich auch selbst drauf kommen können. Trotzdem danke, dass ihr euch so bemüht habt

[Tatsu]

Ok, das ist jetzt echt mega peinlich. Den Teil habe ich natürlich übersprungen... Wer lesen kann ist klar im Vorteil...

Jetzt läuft das ganze. Sorry für die Unanehmlichkeiten, hätte ich auch selbst drauf kommen können. Trotzdem danke, dass ihr euch so bemüht habt

Na Hauptsache ist doch es klappt jetzt, viel Spass damit:)

[Christian1982]

Hallo,

ich hätte da auch mal drei Frage zu culfw@ARM.
Ich habe bereits einen Cube (nutze ich erfolgreich mit ser2net) und einen HM-CFG-USB-2 erfolgreich mit Windows geflasht, jedoch nutze ich normalweise kein Windows sondern einen MAC und diverse Linux Server.

Frage1: Ist es möglich die Firmware auch unter Linux (zur Not auch unter MAC) zu flashen, bzw. direkt aus FHEM?
Frage2: Es kommen ja immer wieder Updates der Software, sollte man dabei auch immer den Bootloader (bootloader_HM_CFG.bin, bootloader_CUBE.bin) aktualisieren oder ist es ausreichend NUR die Culfw Firmware (HM_CFG_BL.bin, CUBE_BL.bin) zu aktualisiert, weil der Bootloader nur einmal initial benötigt wird?
Frage3: für die Anbindung von TX 29 DTH Sensoren wird normal der JeeLink empfohlen, seit 1.05 kann jedoch auch culfw@ARM LaCrosse Sensoren empfangen,  was würdet ihr heute empfehlen?

[Telekatz]

Zu Frage 1:
Als Alternative zu SAM-BA gibt es unter Linux BOSSA: https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455
Anleitung zum flashen der Firmware unter Linux: https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429

Zu Frage 2:
Den Bootloader muss man nur einmal flashen. Wäre ja sonst unnütz weil man dann gleich eine Version ohne Bootloader flashen könnte.

Zu Frage 3:
Kann ich nichts dazu sagen, verwende keine LaCrosse Sensoren.

[JSG]

Hallo,

erst mal vielen Dank an Telekatz für die Portierung der Firmware! Das Flashen verlief einwandfrei, mein CUBE werkelt nun seit einigen Tagen unter FHEM über LAN (Firmware V 1.20.06 a-culfw Build:208).

Nun zu meinem 'Problem': Ich steuere unter anderem 5 Stück FHT80b an. Setze ich nun bei allen z.B. die Temperatur auf 20.0 C°, klappt dies auch einwandfrei. Allerdings verbleiben im FHT Buffer des CUBE zumeist Telegramme von 1-2 FHTs (telnet: T02), obwohl die betreffenden FHTs die Temperaturänderung längst übernommen haben. Laut RSSI Wert in FHEM ist der Empfang von allen FHTs ausgezeichnet, auch die Batterien in allen FHTs sind neu. Die Telegramme verschwinden auch nach Stunden nicht aus dem Buffer. Es scheint dass die FHTs entweder keine Quittierung an den CUBE senden oder der CUBE diese nicht korrekt interpretiert. Komplett verwirrend ist, dass die FHTs die Änderungen ja korrekt übernehmen und nicht immer dieselben FHTs betroffen sind. 

Hat jemand von Euch ein ähnliches Problem? Ich bin mit meinem Latein am Ende und überlege schon jede Nacht einfach mit 'set CUBE1 raw T011234' den FHT Buffer zu löschen oder auf die wesentlich weniger kapriziösen MAX Heizungsregler umzustellen.