FHEM Forum

CUL => Hard- und Firmware => Thema gestartet von: Telekatz am 22 Juni 2015, 22:42:29

Titel: culfw@ARM
Beitrag von: Telekatz am 22 Juni 2015, 22:42:29
Hallo,

ich möchte euch meine Portierung der culfw für AT91SAM7-Controller vorstellen. Lauffähig ist diese Version auf dem HM-CFG-USB-2 und dem MAX! Cube.
Die beiden Geräte können dann wie ein CUL in FHEM eingebunden werden.

Quellcode:
Der Quellcode ist in der a-culfw (https://github.com/heliflieger/a-culfw) enthalten. Zum Erstellen der Firmware wurde diese Toolchain  (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update) verwendet.

Firmware flashen :
Die kompilierten Bin Dateien findet Ihr unter https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw (https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw). Die Firmware besteht aus zwei Teilen. Einem Bootloader (bootloader_CUBE.bin bzw. bootloader_HM_CFG.bin) und der eigentlichen culfw (CUBE_BL.bin bzw. HM_CFG_BL.bin). Zum flashen des Bootloaders wird die  SAM-BA (https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/Atmel%20SAM-BA%20In-system%20Programmer) Software von Atmel benötigt.
Alternativ kann unter Linux BOSSA verwendet werden:https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455 (https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455)

Bootloader (MAX! Cube):

Bootloader (HM-CFG-USB-2):

Culfw:
Der Bootloader wird beim Cube durch Drücken des Knopfes an der Unterseite während des Einsteckens des USB Kabels aktiviert. Beim HM-CFG-USB2 muss von ST1 Pin 3 mit Pin 4 beim Einstecken verbunden werden. Außerdem startet er automatisch solange noch keine Firmware gelagen wurde und kann bei bereits installierter culfw mit dem Kommando „B01“ aktiviert werden. Bei aktivierten Bootloader blinkt die LED D1 schnell.
Zum Übertragen der culfw wird ein Terminalprogramm benötigt, das Dateien per XModem übertragen kann, z.B. Tera Term  (http://ttssh2.osdn.jp/index.html.en). Nachdem man bei Tera Term mit Datei -> Transfer -> XMODEM -> Senden die richtige Firmware Datei ausgewählt hat, starten die Übertragung und der Flashvorgang automatisch. Anschließend erfolgt ein Reboot und die culfw startet.
Anleitung zum flashen unter Linux: https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429 (https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429)
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 23 Juni 2015, 07:35:48
Gerade mit dem HM-CFG-USB-2 sehr interessant -> CUL 868 für 25€. Ich werde mir wohl direkt einen 2. bestellen müssen. Danke für das veröffentlichen. Würdest du ggf noch eine Version mit der alternativen culfw http://forum.fhem.de/index.php?topic=35064.0 bereitstellen können?

Wie sehen spätere updates der firmware aus? Hex-file vom cul und los geht denke ich nicht
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 23 Juni 2015, 12:00:20
Nein, die HEX Files vom CUL passen nicht, die sind für ATMega Controller. Im HM-CHG-USB-2 und im Cube steckt ein ARM drin. Das muss neu compiliert werden.

Und mit der alternativen culfw müsste ich erst mal schauen, wieweit der Code dort von der culfw abweicht. Da in der culfw kein HAL vorhanden ist, muss der gesamte Code durchforstet werden, um das auf einer anderen Plattform zum laufen zu bringen.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 24 Juni 2015, 16:40:14
Danke für die ausführliche Anleitung, so kann der inzwischen durch einen CUL abgelöste Cube doch noch sinnvoll weiter verwendet werden.
Wenn ich deine Anleitung richtig verstanden habe ist es allerdings dann vorbei mit Netzwerkzugriff, da dann der Datenaustausch noch via USB läuft ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Juni 2015, 20:07:49
Richtig, der Netzwerkzugrif funktioniert momentan noch nicht. Da muss ich mir erstmal den Beispielcode von Atmel ansehen, um den uIP Stack auch zu aktivieren.
Titel: Antw:culfw@ARM
Beitrag von: ccier am 29 Juni 2015, 14:44:52
Ist denn heute schon Weihnachten?  ;D

Erst das hier:
http://forum.fhem.de/index.php/topic,38317.msg305426.html#msg305426

Und jetzt auch noch eine ARM-variante von CUL für den HM-CFG-USB-2.

Super!

Hat das auch schon jemand in Kombination getestet?





Titel: Antw:culfw@ARM
Beitrag von: bjoernh am 01 Juli 2015, 18:21:54
Nein, die HEX Files vom CUL passen nicht, die sind für ATMega Controller. Im HM-CHG-USB-2 und im Cube steckt ein ARM drin. Das muss neu compiliert werden.

Und mit der alternativen culfw müsste ich erst mal schauen, wieweit der Code dort von der culfw abweicht. Da in der culfw kein HAL vorhanden ist, muss der gesamte Code durchforstet werden, um das auf einer anderen Plattform zum laufen zu bringen.
Die a-culfw ist im prinzip auf der culfw aufgebaut. Einzig die Empfangsmodule habe ich aufgeräumt und erweitert. D.h. die Hardwareanbindung ist noch 100% identisch zur culfw.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Juli 2015, 20:59:36
Der Quellcode für die ARM Version ist jetzt in der a-culfw enthalten.

Noch ein Hinweis zur Hardware des HM-CFG-USB-2 und des MAX! Cube. Mir aufgefallen, dass bei diversen MAX und Homematic Geräten Funkmodule mit einem Si4431 anstelle eines CC1101 Chips verwendet werden. In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul. Die beiden HM-CFG-USB-2 Adapter die ich habe, haben einen CC1101 verbaut. Allerdings könnte es auch welche geben, die einen SI4431 haben. Bitte dies vor dem löschen der Originalfirmware kontrollieren.
Auf meinem Cube steht hingegen nur TRX868. Den habe ich allerdings auch schon seit 2012. Könnte hier bitte mal jemand der sich kürzlich einen Cube gekauft hat nachsehen, ob der Typ des Funkmoduls jetzt auch genauer angegeben ist?
Titel: Antw:culfw@ARM
Beitrag von: Loctotex am 13 Juli 2015, 22:31:06
Hallo Telekatz,

vielen Dank dafür. Habe es mit einem HM-CFG-USB2 ausprobiert. Funktioniert perfekt. Ich musste den 10k Widerstand einlöten. Er kann aber nach dem Flashen wieder entfernt werden.
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 12 August 2015, 12:55:32
Hallo

Bisher hatte ich zwar noch keine Probleme eines Senilen Cube.... Aber da ich eine Ersatgerät liegen habe würde ich es einfach mal
ausprobiren.....

Im Vorfeld noch zwei Frage...
- Fungiert ein Cube oder USB-CFG dann genau wie ein CUL - also man könnte den Cube auch auf HomeMatic umstellen?
- Wird der Netzwerkanschluss noch mit intregiert?



stenny
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 August 2015, 15:57:09
Bis auf den Firmwareupdate aus FHEM heraus ist alles möglich, was mit dem CUL auch möglich ist. Der Netzwerkanschluss vom Cube wird auch noch integriert.
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 12 August 2015, 16:02:00
Genial!!!!!!!!!!!!!!!!!

Dann wird der zweite heute umgebastellt....



Nachtrag: Und läuft..... Perfekt
Titel: Antw:culfw@ARM
Beitrag von: Blizzard am 22 August 2015, 21:14:17
Hallo Telekatz,

zuerst einmal vielen Dank für die geniale Idee und deine Umsetzung!

Ich habe gleich mal einen alten Cube geflasht, der hin- und wieder an der vielleicht bekannten Amnesie gelitten hatte (alle 2-3 Monate waren alle Daten weg --> Werksreset!). Jetzt weiß ich nicht, ob es ein Einzelfall ist, oder ob es vielleicht auch mit der Amnesie zu tun hat, aber ich musste am Debug-Port (ST2) noch einen Pull-up-Widerstand zwischen Pin1 und Pin3 einlöten.
Ohne diesen hatte ich ein paar seltsame Fehlerbilder:
- beim Verbinden mit PC oder RPi startete die Fw immer wieder neu (alle 2-3 sec. flackerten kurz die LEDs und der Cube verschwand kurz aus dem Gerätemanager).
- Falls eine stabile Verbindung mal hergestellt war, kam neben den richtigen Daten auch häufig viel Datenmüll an.
- das Flashen hatte interessanterweise auch ohne den Pull-up Widerstand fehlerfrei funktioniert...

Wird in der Firmware eigentlich ein interner Pull-up auf diesen Port gesetzt? Habe leider vor einiger Zeit den Schaltplan vom Cube entsorgt und konnte es auf die Schnelle nicht mehr in der Firmware nachvollziehen...
Mit dem Pull-up Widerstand schnurrt das Teil jetzt wie ein Kätzchen, ich freue mich schon auf die Netzwerk-Anbindung! Echt geniale Arbeit von Dir! :-)

Viele Grüße,
Martin



Titel: Antw:culfw@ARM
Beitrag von: Blizzard am 22 August 2015, 21:48:18

Noch ein Hinweis zur Hardware des HM-CFG-USB-2 und des MAX! Cube. Mir aufgefallen, dass bei diversen MAX und Homematic Geräten Funkmodule mit einem Si4431 anstelle eines CC1101 Chips verwendet werden. In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul. Die beiden HM-CFG-USB-2 Adapter die ich habe, haben einen CC1101 verbaut. Allerdings könnte es auch welche geben, die einen SI4431 haben. Bitte dies vor dem löschen der Originalfirmware kontrollieren.
Auf meinem Cube steht hingegen nur TRX868. Den habe ich allerdings auch schon seit 2012. Könnte hier bitte mal jemand der sich kürzlich einen Cube gekauft hat nachsehen, ob der Typ des Funkmoduls jetzt auch genauer angegeben ist?

Auf meinem Cube (gekauft Anfang 2015) steht TRX868-TI, ähnlich dem HM-CFG-USB-2 . :)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 23 August 2015, 20:23:15
Hallo Martin,

dein Cube empfängt wohl irgend einen Datenmüll über die serielle Schnittstelle der Debug Unit. Dort hatte ich zu Testzwecken einen einen Befehl eingebaut, mit dem sich die USB Verbindung lösen und wieder verbinden lässt. Dadurch verschwindet der Cube immer wieder aus dem Gerätemanager. Der restliche Datenmüll wird dann noch von der Debug Unit zur Konsole der USB Verbindung weitergeleitet.

Ein Pull-up für diesen Port war nicht gesetzt. Das habe ich jetzt geändert, das Problem sollte dadurch gelöst sein. Außerdem habe ich auch noch die Netzwerkunterstützung für den Cube mit in die a-culfw eingecheckt.

Auf meinem Cube (gekauft Anfang 2015) steht TRX868-TI, ähnlich dem HM-CFG-USB-2 . :)
Ja, das ist das passende Funkmodul.
Titel: Antw:culfw@ARM
Beitrag von: Olly am 23 August 2015, 20:51:06
Außerdem habe ich auch noch die Netzwerkunterstützung für den Cube mit in die a-culfw eingecheckt.
Hallo,

heißt das, dass man den Cube jetzt quasi wie einen CUNO (CUL im Netzwerk, ohne USB) verwenden kann? Da würde ich mir glatt einen Cube schießen und via PowerLAN an geeigneter Stelle platzieren um meine Reichweite zu erhöhen.

Gruß

     Olly
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 23 August 2015, 21:01:44
Man kann ihn wie einen CUN benutzen. Ein CUNO hat zusätzlich noch 1Wire.
Titel: Antw:culfw@ARM
Beitrag von: adb76 am 25 August 2015, 22:43:21
Hallo Telekatz,

super, da werde ich auch direkt mal meinen Cube umwidmen!
Eine Frage noch hierzu: wenn ich den Cube über USB anschließe, welche Baudrate nehme ich dann bei der Definition des CUL in Fhem? 9600, 38400, 115200 oder ganz was anderes?

Danke und Gruß.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 25 August 2015, 23:07:28
Da ja nicht wirklich eine RS232 Verbindung existiert ist das eigentlich egal. Es funktioniert auch mit 42 Baud.
Titel: Antw:culfw@ARM
Beitrag von: adb76 am 26 August 2015, 20:46:17
So, habe heute meinen CUBE entsprechend geflasht. Er empfängt auch die opened/closed Stati von meinen MAX! Fenstersensoren. Soweit ok.

Aber: Es kommen permanent irgendelche Daten über die Schnittstelle, was dazu führt, dass einzelne Telegramme verwurstelt werden bzw. FHEM bei einem "shutdown restart" komplett blockiert und erst weiterläuft, wenn ich den CUBE abziehe. Habe mal mit einem Verbose 5 auf den CUL geloggt, was dann so aussieht:

2015.08.26 20:38:29 3: Setting CUL_0 serial parameters to 9600,8,N,1
2015.08.26 20:38:29 1: /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00 reappeared (CUL_0)
2015.08.26 20:38:29 5: SW: V
2015.08.26 20:38:29 5: CUL/RAW (ReadAnswer): V 1.65 CUBe

2015.08.26 20:38:29 5: SW: ?
2015.08.26 20:38:29 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A Z E G M K U Y R T V W X e f l t x

2015.08.26 20:38:29 3: CUL_0: Possible commands: BCFiAZEGMKUYRTVWXefltx
2015.08.26 20:38:29 5: SW: X21
2015.08.26 20:38:29 5: SW: Zr
2015.08.26 20:38:29 5: SW: Za123456
2015.08.26 20:38:29 5: SW: Zw111111
2015.08.26 20:38:29 5: SW: T01
2015.08.26 20:38:29 5: CUL/RAW (ReadAnswer): 1034

2015.08.26 20:38:29 5: GOT CUL fhtid: 1034
2015.08.26 20:38:30 5: CUL/RAW: /
2015.08.26 20:38:30 5: CUL/RAW: /
2015.08.26 20:38:32 5: CUL/RAW: /�
2015.08.26 20:38:32 5: CUL/RAW: �/
2015.08.26 20:38:32 5: CUL/RAW: �/
2015.08.26 20:38:33 5: CUL/RAW: �/
2015.08.26 20:38:33 5: CUL/RAW: �/
2015.08.26 20:38:34 5: CUL/RAW: �/
2015.08.26 20:38:34 5: CUL/RAW: �/�
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/�
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:36 5: CUL/RAW: ���/�
2015.08.26 20:38:36 5: CUL/RAW: ����/
2015.08.26 20:38:36 5: CUL/RAW: ����/�
2015.08.26 20:38:36 5: CUL/RAW: �����/
2015.08.26 20:38:36 5: CUL/RAW: �����/0
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/�
2015.08.26 20:38:36 5: CUL/RAW: �����0�/
2015.08.26 20:38:36 5: CUL/RAW: �����0�/
2015.08.26 20:38:36 5: CUL/RAW: �����0�/�
2015.08.26 20:38:36 5: CUL/RAW: �����0��/`
2015.08.26 20:38:36 5: CUL/RAW: �����0��`/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`/~
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~/?
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/�
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:37 5: CUL/RAW: �����0��`~?�/?>>�

list CUL_0 ergibt:
Internals:
   CMDS       BCFiAZEGMKUYRTVWXefltx
   CUL_0_MSGCNT 1
   CUL_0_TIME 2015-08-26 20:39:03
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@9600 1034
   DeviceName /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@9600
   FHTID      1034
   NAME       CUL_0
   NR         146
   PARTIAL
   RAWMSG     Z0B1A06300FFDEA123456001029
   RSSI       -53.5
   STATE      disconnected
   TYPE       CUL
   VERSION    V 1.65 CUBe
   initString X21
Zr
Za123456
Zw111111
   CHANGETIME:
   Helper:
     Dblog:
       State:
         Mydblog:
           TIME       1440614349.80468
           VALUE      DISCONNECTED
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2015-08-26 20:23:05   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2015-08-26 20:38:29   cmds             B C F i A Z E G M K U Y R T V W X e f l t x
     2015-08-15 09:40:39   credit10ms      900
     2015-08-13 20:05:19   fhtbuf          AE
     2015-08-26 20:39:09   state           disconnected
     2015-08-26 20:23:10   version         V 1.65 CUL868
Attributes:
   rfmode     MAX
   verbose    5

Habe auch schon versucht neu geflasht, aber irgendwie sendet der CUBE dauernd. Woran kann das liegen?  :(

Danke und Gruß.

P.S. mit eine CUL 868 in der gleichen Konfiguration habe ich diese Probleme nicht.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 August 2015, 20:59:36
Klingt so, als ob es das gleiche Problem wie bei Blizzard (http://forum.fhem.de/index.php/topic,38404.msg325171.html#msg325171) ist. Probier mal die neueste Version, die in der a-culfw enthalten ist: https://www.mediafire.com/folder/tf16radvztfd9/a-culfw (https://www.mediafire.com/folder/tf16radvztfd9/a-culfw)
Titel: Antw:culfw@ARM
Beitrag von: Blizzard am 26 August 2015, 21:07:43
Ich habe seit gestern die neuste Version drauf.Sowohl der Datenmüll ist verschwunden (auch ohne Hardware-Pullup ;D), als auch die Netzwerk-Funktionalität funktioniert bisher fehlerfrei. 2x 100 Punkte! 8)
Ich betreibe den "Cube-CUNO" zusammen mit Homegear um ein paar Homematic-Geräte zu steuern. :)
Titel: Antw:culfw@ARM
Beitrag von: adb76 am 26 August 2015, 21:08:21
Klingt so, als ob es das gleiche Problem wie bei Blizzard (http://forum.fhem.de/index.php/topic,38404.msg325171.html#msg325171) ist. Probier mal die neueste Version, die in der a-culfw enthalten ist: https://www.mediafire.com/folder/tf16radvztfd9/a-culfw (https://www.mediafire.com/folder/tf16radvztfd9/a-culfw)

Super! Das war's! Erste Tests sehen sehr gut aus.

Vielen Dank!

EDIT: Ich hatte nach einem Neustart von FHEM plötzlich Probleme, dass mein Fensterkontakte den Status "opened (rf error)" oder "closed (rf error)" hatten. Im Log war daneben noch folgendes zu finden:
2015.08.26 22:17:08 1: PERL WARNING: Argument "04 a-culfw Build: 151 (2015-08-25_20-48-08) CUBe (F-Band..." isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 147.
2015.08.26 22:17:08 2: CUL_MAX_Check: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update

Nach Durchsicht von 14_CUL_MAX habe ich festgestellt, dass offensichtlich in Abhängigkeit von der Firmware-Version die Initialisierung anders verläuft. Nachdem ich mal versuchsweise in 14_CUL_MAX die Version hart auf 165 gesetzt habe (aktuelle Original-Firmware) läuft es nun wieder. Werde den Punkt mal im MAX-Unterforum melden.
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 28 August 2015, 20:14:02
Kann man man Cube eigentlich eine feste IP einstellen?
Titel: Antw:culfw@ARM
Beitrag von: Blizzard am 28 August 2015, 20:19:04
Kann man man Cube eigentlich eine feste IP einstellen?

Ja, das ist kein Problem, hier gibts ein Beispiel dafür http://culfw.de/commandref.html (http://culfw.de/commandref.html)

Zitat
Sample CUN(O) setup

This section describes how to setup CUN for ethernet access with the following settings:
  DCHP client:      off
  IP address/netmask:   192.168.31.126/255.255.255.0
  Gateway:      192.168.31.1
  NTP server:      192.168.31.2
  Time zone offset:   GMT+2
Connect CUN to your PC via USB. On Linux a device /dev/ttyACM0 will appear (on subsequent experiments, the device may be named /dev/ttyACM1, /dev/ttyACM2 and so forth). Use screen /dev/ttyACM1 to talk to CUN and screen /dev/ttyACM1@38400 for CUNO. Enter the following commands:
  V                     output version, e.g. V 1.39 CUN
  Wid00                 disable DHCP
  Rid
  Wia192.168.31.126     set IP address
  Ria
  Wig192.168.31.1       set gateway
  Rig
  Win255.255.255.0      set netmask
  Rin
  WiN192.168.31.2       set NTP server
  RiN
  Wio02                 set time zone offset
  Rio
  En                    request time from NTP server
  c03                   show date and timeslot
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 29 August 2015, 16:18:14
Moin Telekatz,

danke ersteinmal für die Portierung.
für Dich und andere vielleicht interessant, mein CUBE hat einen at91sam7x512 an Board.

Jetzt zu meinem eigentlichen Problem:
Wegen des MAX-Problems:
Zitat adb76
Zitat
Nach Durchsicht von 14_CUL_MAX habe ich festgestellt, dass offensichtlich in Abhängigkeit von der Firmware-Version die Initialisierung anders verläuft. Nachdem ich mal versuchsweise in 14_CUL_MAX die Version hart auf 165 gesetzt habe (aktuelle Original-Firmware) läuft es nun wieder. Werde den Punkt mal im MAX-Unterforum melden.
wollte ich mir eine "frisierte" Firmware selber Kompilieren, dabei komme allerdings auf keinen grünen Zweig, vielleicht kannst Du mir dabei helfen, das Problem zu finden.
Virtuelle Maschine mit Ubuntu 12:04 aufgesetzt,
den von Dir vorgeschlagenen Toolchain als ppa ( https://launchpad.net/~terry.guo/+archive/ubuntu/gcc-arm-embedded )installiert,
im CUBe-Verzeichnis make ausgeführt,
keine Fehlermeldungen erhalten,
die gebaute CUBE_BL.bin mit CuteCom auf den Cube geschoben,
und geht nicht,
die von Dir kompilierte bin (a-culfw_1.05.04_build_151_master   CUBE_BL.bin) funktioniert.
Ich denke, ich habe eine Kleinigkeit vergessen, nur welche?
Wenn weitere Infos benötgt werden, bescheid sagen.

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 29 August 2015, 16:41:46
Hast du die Version 4.9 installiert? Die hat bei mir nicht funktioniert. Deshalb verwende ich die Version 4.8.
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 29 August 2015, 17:14:47
Danke Telekatz, guter Tipp,
es ist die Version 4.9.3.
Werde das jetzt mal mit der Version 4.8 versuchen, und mich bei Problemen nocheinmal melden.

Gruß Joachim

Edith:
So, jetzt diese Version genommen:
https://launchpad.net/gcc-arm-embedded/4.8/4.8-2013-q4-major
gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
Makefile angepasst:
###############################################################
#####
##### Makefile for boop - OpenSource firmware for Betty
##### Created at 30.8.2007 02:26 am
#####
##### boop V0.1 by netguy - ck@mamalala.net
##### Makefile V0.1 by alterego - alteregon@gmx.net
##### Makefile v0.2 by Tobias - tobias-betty@23.gs
#####
###############################################################

###############################################################
#####
##### PATHS (default installation)
#####
##### You can put your path-config into Makefile.local
##### to override these defaults
#####
###############################################################

ARMBASE = /home/joachim/Downloads/gcc-arm-none-eabi-4_8-2013q4     <------------------------------------------

INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin/                                   <-------------------------------------------------------------
TOOLPREFIX = arm-none-eabi-
OPENOCDPATH = F:\Tools\OpenOCD
OPENOCD = $(OPENOCDPATH)\openocd.exe -f $(OPENOCDPATH)\target\sam7x256.cfg -f $(OPENOCDPATH)\interface\uniprog.cfg

GENDEPFLAGS = -MMD -MP -MF .dep/$(@F).d
make gestartet, und geflasht.
--> es geht!

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 10 September 2015, 19:14:04
Thanks in advance for all the effort by everybody towards FHEM and firmwares.
Sorry for post in English, but I am struggling a little installing to Max cube.

I think I have successfully deleted previous firmware, by shorting J1, connecting USB, disconnecting short on J1, waiting for a second or so, hear usb drop and reconnect from computer notification then power off by disconnecting USB. When firmware has been deleted and you power back on light D1 is then permanently out. (Normally it should be on solid to indicate power on in normal mode with firmware loaded?)
I think I have loaded the boot loader with the SAM-BA software as D1 is now flashing approx 3 times per second when powered on, but I can't get past that stage to get the firmware loaded.

I used the instructions from the Atmel  sam-ba Software to install its USB driver, which installed ok.

Started the software
Connected to the device as per instructions
Loaded the Bin file
Pressed the send
To the question about wanting to lock the involved lock regions, I say no, then
execute the script to boot from flash.

This is the log output from SAM-BA session:

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


Then on powering back off and back on the D1 light is now flashing approx 3 times per second, which I think indicates it has booted in boot loader mode as it has no firmware.

The USB is still detected as a AT91 USB to serial converter but to a different com port.

I then start up the teraterm software.
Connect to the port
File > Transfer > XMODEM > Send
Select the bin file from the dialogue and it start writing ok, but progress window seems to disappear before it finishes entirely (about half way), and you hear the USB disconnect and re-connect notification.
The light D1 is still flashing at about 3 times per second.

If I disconnect and re-connect the power the D1 led is still flashing at 3 times per second.
I think that means the Firmware flash has not worked.

How long does the flash process take?
Any suggestions as to what I am doing wrong.

I am also a little unclear as to which version of the firmware allows the device to function as a CUN. (IP based CUL device.)

Hopefully there are some instructions in here which might help some other users past the bit I have been able to get to.

I have attached document with screenshots to help other people if it can, and perhaps to help someone show me the error of my ways?

Regards
Chapelhill





Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 September 2015, 23:09:03
Your procedure looks good for me. I think it is the same problem that Blizzard noticed with the missig pull up resistor on the debug port. This could lead to disconnect the USB connection before teraterm can upload the entire firmware. I fixed this problem in the a-culfw version.

You can find the a-culfw on https://github.com/heliflieger/a-culfw (https://github.com/heliflieger/a-culfw). The compiled binaries are available on https://www.mediafire.com/folder/tf16radvztfd9/a-culfw (https://www.mediafire.com/folder/tf16radvztfd9/a-culfw).
Try again with the bootloader and the firmware from Build 151.

Regards
Alex

Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 11 September 2015, 08:36:50
Hi thanks for the quick response.

I have tried with build 151 and the previous build, it seems to make no difference. Are there any other builds to try, all the other builds appear to be too early for this development. I presume the problem is with the bootloader?

Which pins can I connect a resistor to, too see if I can resolve with hardware pull up resistor and approx what resistor value?

Board has
ST1
1x 2x 3x 4x
ST2
1x 2x 3x 4x

My cube was bought early this year, but has lost its settings twice, so I want to convert to using the CUL FW since I need functionality for switching heating on and off based on radiator demand. It is marked with the TRX868-TI and has AT91SAM7X256 ARM chip.

Regards
Chapelhill.
 
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 10:03:14
The resistor has to be connected between pin 1 and 3 on ST2. Use a 10k resistor.

Did you also try to use the bootloader from build 151?
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 11 September 2015, 11:06:54
Just to confirm.
I have retried with bootloader from build 151 and build 138 and no difference.
I did a file compare between bootloader from those two builds and it did not find any difference.

I have tried with 10k resistor between pins 1 and 3 on ST2 debug connections.
It made no difference.
Checking with a volt meter on dc voltage it showed both pin 1 and pin 3 at 3.3v without the resistor anyway.

Perhaps there is a problem with my cube?

I have tried with minicom on raspberry pi and this is the output. I think it is also aware that the connection drops before completing transfer.
Interestingly when connected to pi, the D1 led goes to constant on after 7 seconds, but returns to flashing at 3 times per second once minicom connection is established.

         +-----------[xmodem upload - Press CTRL-C to quit]------------+
         |Sending CUBE_BL.bin, 618 blocks: Give your local XMODEM recei|
         |ve command now.                                                                          |
         |Xmodem sectors/kbytes sent: 618/77kRetry 0: No ACK on EOT   |
         |                                                                                                       |
         |Transfer incomplete                                                                        |
         |                                                                                                       |
         | READY: press any key to continue...                                             |
         +-------------------------------------------------------------+


Chapelhill
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 13:29:42
I then start up the teraterm software.
Connect to the port
File > Transfer > XMODEM > Send
Select the bin file from the dialogue and it start writing ok, but progress window seems to disappear before it finishes entirely (about half way), and you hear the USB disconnect and re-connect notification.
The light D1 is still flashing at about 3 times per second.

If I disconnect and re-connect the power the D1 led is still flashing at 3 times per second.
I think that means the Firmware flash has not worked.

Check the switch on the bottom of the cube. Normaly after a firmware is loaded on a empty cube, the bootloader jumps direct to the firmware after power on. Even if the firmware upload fails.
Pressing the switch while power on the cube activates the bootloader. This is indicated with the fast flashing of D1. If the switch is always closed, the bootloader is always active.
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 11 September 2015, 16:50:16
Hi I have checked the switch and that seems ok.

I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SSAM7X256 not the AT91SSAM7X512
The version number written on my circuit board is 1113596J and not 1113596H

I presume we might need some different settings in firmware for the differing Atmel chips as they have differing amount of memory and ram.

Is there any other information I can provide?
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 11 September 2015, 17:02:15
Hi I have checked the switch and that seems ok.

I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SAM7X256 not the AT91SAM7X512
The version number written on my circuit board is 1113596J and not 1113596H

I presume we might need some different settings in firmware for the differing Atmel chips as they have differing amount of memory and ram.

Is there any other information I can provide?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 17:30:04
Hi I have checked the switch and that seems ok.
Did you also measure the level of the input? You can measure it on MP8 and it should be pulled up to +3.3V.

I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SSAM7X256 not the AT91SSAM7X512
The version number written on my circuit board is 1113596J and not 1113596H
The firmware is intended to run on the AT91SAM7X256.

Attached you can find a version of the firmware you can flash with SAM-BA direct to the cube without the need of a bootloader. The flash procedure is the same as for bootloader_CUBE.bin.


 
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 11 September 2015, 17:57:09
Hi all.

I have checked MP8 and it shows 3.3 volts normally, and drops to 0 volts when the switch is pressed, returning back to 3.3v on release of the switch.

I have loaded the firmware you attached and flashed with SAM-BA and upon reboot we have D3 on continuously D2 off and D1 flashing slowly approximately once every two seconds. That is with the cube connected to usb only, no ethernet connection.

Looks like it has succesfully flashed firmware and booted normally.

I will see if I can work out how to use the device and update the thread accordingly.

Many thanks for the patience you have shown me.

Regards
Chapelhill.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 19:16:02
Hat jemand von euch die a-culfw auf einem Cube mit der Version 1113596J installiert und kann bestätigen, dass das Flashen mit dem Bootloader normal funktioniert? Ich hab hier auch nur welche mit der Version 1113596H.
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 11 September 2015, 19:56:37
Moin Telekatz,
Ich kann Dir bestätigen, dass die a-culfw auf einem CUBE mit der Version 1113596J nicht funktioniert.
Das angepasste file von Heute um 17:30:04 funktioniert einwandfrei.

Insgesamt habe ich bisher 2 CUBE's (die älter als 3 Jahre sind erfolgreich geflasht, und den mit der Version 1113596J nur über das von Dir angehängte.

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 20:31:03
Hallo Joachim,

Hast du den Cube mit der Version 1113596J als Bausatz gekauft und eine Anleitung mit Schaltplan dazu bekommen? Mich würde interessieren, ob der Taster TA2 bei dieser Version noch am Pin 22 (PA14) angeschlossen ist, oder ob dieser Pin jetzt auf Masse liegt. Der Bootloader verwendet ein Low Signal an diesem Pin, um den Bootloader Modus zu aktivieren. Ansonsten wird die Firmware gestartet, die im Flash nach dem Bootloader geschrieben ist.

Das File von Heute ist im Prinzip die gleiche Version wie die für den Bootloader. Der einzige Unterschied ist, das es an den Anfang des Flashs geladen wird und dann direkt startet.

Gruß
Alex
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 11 September 2015, 21:02:35
Moin Telekatz,
Ich habe den CUBE nicht als Bausatz gekauft, und damit leider auch keinen Schaltplan.
Der CUBE, mit dem das Flashen geklappt hat, ist Version 1113596I und hat einen at91sam7x512 an Board.
Ich habe hier beide geöffnet neben mir stehen. sag mir was ich suchen oder messen soll, und ich mache es.
Pin 22 (PA14) finde ich leider nicht.

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 21:55:28
Könntest du bitte je ein Foto von beiden Platinenseiten der Version 1113596J machen, auf denen man die Leiterbahnen erkennen kann?
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 11 September 2015, 22:31:55
Bitteschön
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 September 2015, 23:34:37
Der Anschluss von TA2 sieht genauso aus wie bei mir. Das scheint es wohl nicht zu sein.

Du könntest mal folgendes probieren:
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-In SAM-BA die Address von 0x100000 auf 0x104000 ändern
-In SAM-BA CUBE_BL.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.

Wenn die a-culfw jetzt normal startet, liegt das Problem wohl an der Flash Funktion im Bootloader. Startet hingegen direkt der Bootloader, funktioniert anscheinend die Erkennung, ob bereits eine Firmware geladen wurde im Bootloader nicht.

Titel: Antw:culfw@ARM
Beitrag von: Joachim am 11 September 2015, 23:47:31
Zitat
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-In SAM-BA die Address von 0x100000 auf 0x104000 ändern
-In SAM-BA CUBE_BL.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.

Getan, funktioniert.

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 September 2015, 13:12:16
Hallo Joachim,
 
könntest du mal den angefügten Bootloader ausprobieren. 

Gruß
Alex
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 12 September 2015, 14:04:12
Moin Telekatz,

Der neue Bootloader funktioniert nicht.
Flogenden Ablauf habe ich gewählt:
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.
-starten von CuteCom unter Linux Mint 17
-open Device
-SendFile a-culfw_1.05.04_build_151_master/CUBe/CUBE_BL.bin
-USB trennen und Cube neu starten.
-D1 blinkt weiterhin mit ca. 3x/sec

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 September 2015, 19:39:59
Hast du die Möglichkeit, mit einem Treminalprogramm den Debugoutput auf ST2 aufzuzeichnen? Ich würde dann mal einen Bootloader mit TRACE Ausgaben erstellen, um den Fehler etwas eingrenzen zu können.
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 13 September 2015, 11:55:08
Moin Telekatz,

habe ich noch nie gemacht, sollte aber machbar sein.
Ich gehe davon aus, dass Ich auf ST 2  einen Pfostenstecker einlöten muss, und dann mit einem serial 3,3 V auf USB-Konverter an einenPC gehen soll.
Die Belegung ist wie in diesem Bild?

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 September 2015, 13:23:37
Ja, die Belegung ist so richtig. Die Baudrate am Debugport ist 115200.

Anbei der modifizierte Bootloader und die dazu passende a-culfw.
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 13 September 2015, 19:10:47
Moin Telekatz,
lange gesucht, um den richtigen Adapter zu finden (wer Ordnung hält...)
ich habe zwar kein Ahnung, was das Log aussagt, deshalb bekommst Du es.

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 September 2015, 20:50:13
Danke für das Log. Es sagt aus, dass das Beschreiben des Flash nicht funktioniert und dass dein at91sam7x256 eine neuere Revision hat als meiner.

Ich denke, dass ich im AT91 Forum die Lösung für dieses Problem gefunden habe. Könntest du nochmal die beiden angefügten Bootolader ausprobieren?
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 13 September 2015, 21:05:45
Sieht gut aus.
Hier die beiden Log's passend zu den Bootloadern.
Dann ist es jetzt wohl gelöst?

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 September 2015, 21:42:29
Hallo Joachim,

ja, passt. Problem gelöst. Danke fürs Testen.
Anbei dann auch der korrigierte Bootloader für die veröffentlichte a-culfw.

Gruß Alex
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 13 September 2015, 21:58:37
So, noch einmal schnell gegengetestet,
rennt auch mit selbst kompilierter Firmware.

Hast Du super gemacht, danke Joachim
Titel: Antw:culfw@ARM
Beitrag von: Bujakka am 13 September 2015, 22:19:20
Hallo,
danke für diese tolle Leistung! Als ich dies gelesen habe musste ich es direkt mit meinem Cube ausprobieren.
Leider hänge ich an einer Stelle.
Ich habe den Bootloader geschrieben und wie beschrieben blinkt die LED D1 schnell.
Nun habe ich aber lediglich ein device CUBELOADER unter "Andere Geräte" kann aber mit keinem Terminalprogramm (auch Tera Term) auf den Cube zugreifen. Die Schaltfläche für Serielle Verbindungen ist schlicht ausgegraut.
Habe ich etwas übersehen?

Danke und Gruß,
Thorsten
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 September 2015, 22:57:29
Hat Windows nach einen Treiber gefragt oder hast du schon versucht den Treiber zu aktualisieren?
Titel: Antw:culfw@ARM
Beitrag von: Bujakka am 13 September 2015, 23:03:32
Hat Windows nach einen Treiber gefragt oder hast du schon versucht den Treiber zu aktualisieren?

Windows hat nicht gefragt.
Ich habe versucht den Treiber zu aktualisieren: aus dem Atmel sam-ba Verzeichnis und allem was ich sonst noch finden konnte, ohne Erfolg.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 September 2015, 23:11:46
Schonmal versucht, den Treiber zu deinstallieren und den Cube danach nochmal anzuschließen?
Titel: Antw:culfw@ARM
Beitrag von: Bujakka am 14 September 2015, 02:26:44
Schonmal versucht, den Treiber zu deinstallieren und den Cube danach nochmal anzuschließen?

Ich habe nun für den CUBELOADER den selben Treiber unter Windows ausgewählt (den schon installierten, welchen er bei Treiberneuinstallation ignoriert), welcher für das Flashen des Bootloader funktioniert hatte. Ergebnis: OK.
Ich konnte das Image nun ohne Probleme übertragen.
Werde später versuchen den Cube in FHEM einzubinden.
Habe ich es richtig verstanden, dass Netzwerk mittlerweile auch schon funktioniert, oder muss ich mittels USB anschließen?
OK ist eingebunden...morgen kommen ein paar Geräte dran.
Aber ich muss mich für den Modus entscheiden: also ob ich den Cube für MAX, Homematic oder SlowRF benutzen möchte? Mischen ist vermutlich nicht möglich?!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 14 September 2015, 11:46:20
Bezüglich des Modus gilt das gleiche wie für den CUL. Solange nur ein Transceiver eingebaut ist geht auch nur ein Modus gleichzeitig.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 18 September 2015, 22:15:10
Hallo Leute,

habe heute meinen Cube geflasht. hat nach dem zweiten mal einwandfrei funktioniert.
Beim ersten mal(Windows 10) ist Samba abgestürzt.

Nutze ihn übers Netzwerk.
empfängt HM Geräte(zum testen) einwandfrei.

vielen vielen dank für diesen Port an Telekatz

Jetzt habe ich den den Cube(aus dem Marktplatz hier im Forum) für 25€ bekommen und habe nun einen CUL 868 MHZ mit dem man sogar über
Netzwerk seine Reichweite erhöhen kann.
Ich werde ihn allerdings im Slow RF Bereich nutzen um FS20 steuern zu können.

Mfg Marcel
Titel: Antw:culfw@ARM
Beitrag von: Joachim am 21 September 2015, 10:10:29
Moin Telekatz,

nachdem meine beiden CUBE's nun super mit MAX laufen, wollte ich mal einen für Homematic verwenden.
Dank des Netzwerkanschlusses ist er dafür eigentlich wie geschaffen. Haken an der Sache ist, das es meine Fähigkeiten leider übersteigt, die angepasste
Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1 http://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466 auf den CUBE zu portieren.
Wenn Du dabei helfen könntest, wäre das genial.

Gruß Joachim
Titel: Antw:culfw@ARM
Beitrag von: larsi am 24 September 2015, 08:58:22
Hallo Leute,

ich habe meinen CUBE nach Anleitung geflasht. Als Firmware habe ich die 1.05.04 Build 151 drauf.
Danach habe ich den CUBE per IP in FHEM eingebunden und meine MAX Geräte neu angelernt.
Ausser das mir bei 3 +Thermostaten die valvePosition nicht gemeldet wird, funktioniert alles.

Das echte Problem ist, das der CUBE nach einer gewissen Zeit nicht mehr im Netzwerk erreichbar ist.
Nicht mal ping geht. Der Switch zeigt aber noch den Link an.

Als erstes habe ich dann DHCP deaktiviert und ihm eine statische IP verpasst.
Danach ging es natürlich erstmal wieder. Habe dann sicher knapp 4 Stunden versucht das valvePosition Problem zu lösen.
Dabei war der CUBE die ganze Zeit ansprechbar.

Heute früh war er wieder nicht erreichbar. Im Log steht:

2015.09.23 21:17:19 1: 192.168.178.247:2323 disconnected, waiting to reappear (CUL_CUBE)

Seitdem isser DOWN.
Das gab heute früh mächtig ärger, da das Bad kalt war  ???

Bis zum flashen gabs mit original MAX Firmware keine Probleme.
Der CUBE ist, wie Telekatz seiner, ein TRX868, also schon was älter.

Hat dieses Problem noch einer?

Gruß Larsi
Titel: Antw:culfw@ARM
Beitrag von: Funsailor am 24 September 2015, 17:02:59
Hallo,
ich wollte den CUBe mal kompilieren, allerdings bricht der compiler mit der folgenden Meldung an:

E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe>cd E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe

E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe>make
arm-none-eabi-gcc -g -Os -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S
process_begin: CreateProcess(NULL, arm-none-eabi-gcc -g -Os -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [../../at91lib/board_cstartup.o] Error 2

E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe>

Das Verzeichniss ../../at91lib/ ist mit der Datei "board_cstartup.S" ist vorhanden.

Allerdings habe ich WinAVR-20100110 installiert, liegt es daran?

Danke
Michael
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 September 2015, 21:06:53
Nimm die Toolchain aus dem Eröffnungspost und pass den Pfad zur Toolchain im Makefile an.
Titel: Antw:culfw@ARM
Beitrag von: neckartown am 27 September 2015, 15:56:51
Hallo,
habe hier einen (älteren) HM-CFG-USB-2. Auf diesem steht nur TRX868-TFK / 868.3 MHz. Wie kann ich feststellen, ob hier ein CC1101 Funkmodul verbaut ist?
Auch im Innern des Stick sind keine Hinweise vorhanden.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 27 September 2015, 20:59:06
Sry falsche info.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 September 2015, 21:28:22
Nein, der falsche Chip ist es nur, wenn TRX868-SL oder TRX868-TFK-SL drauf steht. Wenn nur TRX-TFK drauf steht, ist das Funkmodul wohl produziert worden, als nur der CC1101 verwendet wurde und deshalb der Typ nicht extra gekennzeichnet wurde.

Außerdem kann man es noch an der Leiterbahnführung an der Stiftleiste des Moduls erkennen. Wenn es wie hier http://www.fhemwiki.de/wiki/Datei:Tranceiver_CutGradScaleUSM800x600_85P_IMGP8367.JPG (http://www.fhemwiki.de/wiki/Datei:Tranceiver_CutGradScaleUSM800x600_85P_IMGP8367.JPG) aussieht, ist es ein CC1101 Modul.
Titel: Antw:culfw@ARM
Beitrag von: neckartown am 27 September 2015, 21:56:48
Es ist das Modul rechts auf dem Bild verbaut. Somit handelt es sich wahrscheinlich um ein CC1101-Modul. Werde demnächst mal einen Versuch wagen.

Gesendet von meinem SM-P600 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 29 September 2015, 14:18:28
Habe einen Cube erfolgreich geflasht. Windows7 erkennt nun einen "cubeloader", ohne dass dazu ein Treiber gefunden wird. Nun habe ich manuell einen Com-Port Treiber zugewiesen und habe einen Com3 der nicht gestartet werden kann.

In Folge kann ich auch nicht mit Teraterm auf die Kiste zugreifren

Die erste Frage:
Beim Strom anlegen blinkt die LED einige Sekunden lang schnell... Somit gehe ich davon aus dass der Bootloader korrekt geflasht ist. (Ich habe auch das 512KB Modell der ARM-Controllers, daher diese beim Flashen mit SAM-BA ausgewählt, sonst war kein Connect möglich.)


PS: so sieht das syslog unter Linux aus wenn man das Gerät einsteckt.
Zitat
Sep 29 14:11:27 martin-ws kernel: [23329.513994] usb 3-5: new full-speed USB device number 42 using ohci-pci
Sep 29 14:11:27 xx-ws kernel: [23329.685226] usb 3-5: New USB device found, idVendor=03eb, idProduct=6119
Sep 29 14:11:27 xx-ws kernel: [23329.685236] usb 3-5: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Sep 29 14:11:27 xx-ws kernel: [23329.685241] usb 3-5: Product: CUBELOADER
Sep 29 14:11:27 xx-ws kernel: [23329.687501] cdc_acm 3-5:1.0: This device cannot do calls on its own. It is not a modem.
Sep 29 14:11:27 xx-ws kernel: [23329.687554] cdc_acm 3-5:1.0: ttyACM0: USB ACM device
Ich habe versucht mit CuteCom unterLinux auf das Kistchen zu kommen bekomme aber keine Verbindung zustande zu /dev/ttyACM0 (auch nicht /dev/tty/ttyACM0, vor allem mit 9600, 56- und 115K und 8N1).

Somit ist meine erste Frage natürlich ober der Bootloader passt, oder ab er angepasst werden muss auf den größeren Flash.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 29 September 2015, 15:50:56
Der Bootloader passt. Er meldet sich ja mit seinem Namen und das schnelle Blinken zeigt auch an, dass er gestartet ist.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 01 Oktober 2015, 19:45:52
Hallo Leute ich weis nicht ob ich die Frage hier richtig stelle.

Ich habe mir einen Cube umgeflasht und würde nun gerne damit 433 Mhz signale empfangen.

Hab denm Cube bereits auf 433.92Mhz eingestellt und eine Passende Antenne dran.
Senden an Elro steckdosen funktioniert auch super.


Nun weis ich leider nicht weiter was ich als nächstes machen muss um signale auszuwerten bzw anzeigen zu lassen........

Danke für eure hilfe
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 01 Oktober 2015, 20:50:15
Da der Cube ja einen 868,3MHz Empfänger hat sind die 433,92MHz Protokolle nicht enthalten. Um die Signale dennoch zu empfangen musst du in der board.h folgende Änderung am Code vornehmen und die Firmware neu erstellen:

#define _433MHZ

#  if defined(_433MHZ)
#    define HAS_TCM97001
#    define HAS_IT
#    define HAS_HOMEEASY
#    define HAS_OREGON3
#    define HAS_BELFOX
#    define DEBUG_SYNC
#  endif
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 01 Oktober 2015, 21:02:52
Ja das hört sich gut an. Nur leider stehe ich noch sehr am anfang und bin total froh das das flashen überhaupt geklapt hat.  Wäre es zu viel verlangt wenn du mir das machst? Wäre dir sehr dankbar. Ausser es braucht zu viel zeit. Danke für die schnelle antwort.
Titel: Antw:culfw@ARM
Beitrag von: strauch am 02 Oktober 2015, 11:05:45
Hat dieses Problem noch einer?

Gruß Larsi

Erstmal vorweg, auch wenn ich Probleme habe, vielen vielen Dank an Telekatz für die tolle Arbeit und diese Möglichkeit.

Ich hab das gleiche Problem. Ich wollte ihm eine feste IP zuweisen, das hat er aber nach dem ab und anklemmen vergessen. Dann hab ich per DHCP ihm die IP zugewiesen. Das hat gestern Abend auch funktioniert. Aktuell ist er nicht zu erreichen. Wenn ich nachher zuhause bin, klemm ich ihn noch mal ab und an. Zum Glück ist er für nichts wichtiges zuständig.

Ich hab den Bootloader vom 13.9 verwendet, ist ein ganz neuer Cube und die Firmware aus dem aktuellesten Archiv von Ende August. @Telekatz kannst du vielleicht deine Archive die im ersten Post sind aktualisieren?

Vielleicht klappt das mit dem zuweisen einer IP nicht richtig, hat das jemand am laufen?

P.S: Gibt es eigtl. ein kleineres Gehäuse in das der Cube reinpasst, oder muss ich das einfach mal in der Mitte durchsägen und neu zusammenkleben? ;-)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Oktober 2015, 09:43:20
Ja das hört sich gut an. Nur leider stehe ich noch sehr am anfang und bin total froh das das flashen überhaupt geklapt hat.  Wäre es zu viel verlangt wenn du mir das machst? Wäre dir sehr dankbar. Ausser es braucht zu viel zeit. Danke für die schnelle antwort.
Ist jetzt enthalten in der Firmware, siehe erster Post.

Vielleicht klappt das mit dem zuweisen einer IP nicht richtig, hat das jemand am laufen?
Hast du nach dem Zuweisen der IP auch DHCP auf dem Cube mit "Wid00" deaktiviert?
Mein Testcube läuft mit DHCP ohne Probleme. Ich hab in meiner Fritzbox aber auch eingestellt, dass sie den Cube immer die gleiche IP Adresse zuweisen soll.
Titel: Antw:culfw@ARM
Beitrag von: strauch am 03 Oktober 2015, 09:46:19
Also irgendwann kann ich nicht mehr über den cube senden oder empfangen, wenn ich dann ein set cube reopen mache geht es wieder. Aber er steht nicht auf disconnected.
Ich hatte den DHCP abgeschaltet. Ich werde ihn noch mal neu konfigurieren und testen. Vielleicht hab ich irgendwo murks gemacht.

Gesendet von meinem Nexus 4 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Oktober 2015, 10:00:06
FHEM merkt es nicht sofort, wenn der Cube nicht erreichbar ist. Wenn ich durch resetten des Cube einen Verbindungsabbruch provoziere dauert es genau zwei Stunden, bis FHEM den diconnect bemerkt. Dann erfolgt aber sofort ein reopen und der Cube ist wieder erreichbar.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 03 Oktober 2015, 13:16:16
Danke Telekatz,

du bist echt der beste. der 433mhz empfang funktioniert super.
Titel: Antw:culfw@ARM
Beitrag von: mannil am 07 Oktober 2015, 21:18:56
Nabend!

Ich hab da mal eine (wahrscheinlich doofe) Frage.
Momentan setze ich einen Cube ein um 3 Heizungsthermostate damit zu steuern. Es ist noch die originale Firmware installiert.

Wenn ich den Cube jetzt zum CUN umflashe, kann ich dann diesen ganz normal für die MAX! Geräte weiterverwenden und zusätzlich Befehle an meine Intertechno Schaltern senden (das der CUN-CUBE dann zum Zeitpunkt des sendens taub ist, ist mir bewußt)?

Gruß
Manni
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 Oktober 2015, 20:21:29
Intertechno senden funktioniert neben dem MAX Mode, hat aber natürlich eine geringere Reichweite als ein auf 433MHz abgestimmter Sender.
Titel: Antw:culfw@ARM
Beitrag von: mannil am 08 Oktober 2015, 21:12:34
Danke für die Antwort.
Habe schon selber herausgefunden.

Gesendet von meinem ONE A2003 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 12 Oktober 2015, 18:10:06
Ist das Netzwerkproblem jetzt gelöst?
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 12 Oktober 2015, 19:53:42
Ich habe mich am WE auch mal an meinen CUBE gesetzt. Version 1113596 I BS (siehe Bild) , denke den I hatten wir bis jetzt noch nicht nur J & H ?
Bootloader mit sam-ba  ist soweit kein Problem , linux legt nach dem Cube Neustart brav /dev/ttyACM0 an und ich kann mich mit einem Terminalprog und beliebiger Baudrate verbinden - Ausgabe bei Eingabe von Shift +v -> CUBELOADER V1.01
Was bei mir nicht läuft ist die a-culfw , egal welche Version ich mit XMODEM übertragen habe , das Ergebnis ist immer das gleiche :
Nach dem USB trennen und neu starten kann linux keinen USB Port zuordnen ( es leuchtet auch keine  der drei LEDs )
[ 2785.144057] usb 3-2: new full speed USB device using ohci_hcd and address 27
[ 2785.552029] usb 3-2: device not accepting address 27, error -62
[ 2785.728049] usb 3-2: new full speed USB device using ohci_hcd and address 28
[ 2786.136030] usb 3-2: device not accepting address 28, error -62
[ 2786.136056] hub 3-0:1.0: unable to enumerate USB device on port 2

Versuche die a-culfw statt mit XMODEM zu übertragen sondern mit dieser Methode :

-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-In SAM-BA die Address von 0x100000 auf 0x104000 ändern
-In SAM-BA CUBE_BL.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.

Wenn die a-culfw jetzt normal startet, liegt das Problem wohl an der Flash Funktion im Bootloader. Startet hingegen direkt der Bootloader, funktioniert anscheinend die Erkennung, ob bereits eine Firmware geladen wurde im Bootloader nicht.

führen zum gleichen Ergebnis - kein USB Device und keine LED. Soll ich schon mal den Lötkolben vorwärmen und Pfosten in D2 einlöten um eine Debugausgabe zu bekommen oder kann ich zuvor noch etwas anderes probieren ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 Oktober 2015, 21:00:04
Löte ST2 ein und schau, was an Debug rauskommt.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 13 Oktober 2015, 07:54:14
ok, mal schauen ob ich heute Abend dazu komme.
Kann der aktuelle Bootloader Debug Ausgaben oder soll ich die Versionen durchtesten die du auf Seite drei gepostet hast ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 Oktober 2015, 12:23:31
Probier es erst mal mit der aktuellen Version des Bootloaders und der Firmware. Der Bootloader selbst hat keinen Debugausgaben, interessanter ist hier jedoch die Debugausgabe der Firmware.
Sollte nichts ausgegeben werden kannst du es auch noch mit der CUBE.bin von Seite drei probieren, die ohne Bootloader geladen wird.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 13 Oktober 2015, 17:48:02
PFFF , kaum macht man es richtig geht es auch ....
Ich hatte zuvor schon deine CUBE.bin vom 11. September probiert , allerdings zusammen mit dem Bootloader :(
Die CUBE.bin mit SAM-BA direkt und alleine auf den CUBE geschoben und das Mistding rennt :)
Vielen Dank nochmal für deine tolle Arbeit !!!
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 13 Oktober 2015, 18:30:14
Moin!

Meine Frage nach dem Netzwerkproblem scheint untergegangen zu sein... Ist das jetzt behoben?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 Oktober 2015, 19:37:32
Ich habe an der Netzwerkfunktion nichts geändert. Und solange ich das Problem nicht reproduzieren kann, kann ich auch schlecht was dagegen unternehmen.
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 13 Oktober 2015, 19:48:11
Dann werde ich nachher mal testen. :-)
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 13 Oktober 2015, 21:08:28
Hm. Jetzt hab ich wohl ein Problem.

Nach dem Verbinden von J1, dem Einstecken und trennen der USB-Verbindung passiert nun mit meinem Cube (1113596 I) beim Widerherstellen der USB-Verbindung nichts mehr. Windows erkennt keinen neuen USB-Port, und irgendeine LED blinkt auch nicht.
Mit gedrücktem Taster auf der Unterseite ebenfalls kein Erfolg.
Anderen USB-Port am Laptop (WIN7) versucht, ebenfalls kein Erfolg.

Und nun?

Grüße

anfichtn
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 13 Oktober 2015, 21:56:51
Ok, das erste Problem saß wohl vor dem PC.

Nach Tausch des USB-Kabels erscheint zumindest der COM-Port.
Aber Sam-Ba? Gestartet, Port ausgewählt, Board eingestellt, Connect geklickt. Warten... Warten.. Warten.. 5 Minuten später hat sich der Prozess beendet. WTF?

Es geht weiter....
Titel: Antw:culfw@ARM
Beitrag von: cdn am 14 Oktober 2015, 16:38:01
Also bei mir erscheint der Com Port leider nicht. Sondern nur ein nicht identifiziertes Gerät. Welchen Widerstand nehme ich genau und wo muss ich diesen einlöten? Direkt an den Kontakten oder an einem USB Kabel?

Ach wenn ich hier in dem Bereich noch relativ grün hinter den Ohren bin wäre super, wenn mir jemand helfen könnte.

Viele Grüße
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 14 Oktober 2015, 17:46:37
Gib dem nicht identifizierten Gerät mal bitte den Treiber, den du auf der atmel -seite herunter laden kannst.

Grüße
Titel: Antw:culfw@ARM
Beitrag von: cdn am 15 Oktober 2015, 09:56:49
Habe ich gemacht und im Gerätemanager dann die Treiber aktualisiert. Klappt leider nicht: Die Treiber sind auf dem aktuellen Stand bekomme ich als Meldung.
Ich habe die Jumper jeweils mit einer Büroklammer überbrückt, wuste nicht wie ich es sonst machen sollte...

Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 15 Oktober 2015, 11:04:54
Alten Treiber deinstallieren, und entfernen lassen. Dann klappts auch mit dem neuen Treiber
Titel: Antw:culfw@ARM
Beitrag von: cdn am 15 Oktober 2015, 11:22:52
Leider nicht ...
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 15 Oktober 2015, 11:48:35
Also bei mir erscheint der Com Port leider nicht. Sondern nur ein nicht identifiziertes Gerät. Welchen Widerstand nehme ich genau und wo muss ich diesen einlöten? Direkt an den Kontakten oder an einem USB Kabel?

Nimm einen 10 kOhm Widerstand und stecke ihn an den markierten Kontakten in den USB Stecker. Den Wiederstand etwas festdrücken, damit er auch richtig Kontakt bekommt. Der Widerstand wird nur temporär benötigt, bis der Bootloader mit SAM-BA aufgespielt ist. Danach kann er wieder entfernt werden.
Titel: Antw:culfw@ARM
Beitrag von: cdn am 15 Oktober 2015, 11:59:39
Es gibt da doch auch verschiedene Widerstände von der Form/Art oder? Welchen nehme ich am besten?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 15 Oktober 2015, 12:32:13
Nimm den erstbesten bedrahteten 10kOhm Widerstand, der sich finden lässt und in die Kontakte des USB Steckers reinpasst.
Titel: Antw:culfw@ARM
Beitrag von: cdn am 15 Oktober 2015, 12:51:38
Okay nochmal zum Verständnis: Ich werde vorne in den USB Stecker den Widerstand stecken und das Ganze dann in den USB Port am PC richtig?

Danke für die Hilfe!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 15 Oktober 2015, 13:01:22
Nein, hinten! Da wo der Pfeil hin zeigt.
Titel: Antw:culfw@ARM
Beitrag von: cdn am 15 Oktober 2015, 13:04:25
OK. Ich dachte schon. Danke
Titel: Antw:culfw@ARM
Beitrag von: SmokeMaster am 17 Oktober 2015, 12:10:48
Coool!!!!11einself

Da war ich mal ein halbes Jahr nicht im Forum aktiv und da baut Telekatz hier so was geniales zusammen! Da ich nen Cube zu viel habe, meine Heizungssteuerung mit MAX die Tage den "Release 1.1" (so ganz fertig ist man ja nie ^^) erreicht haben werden sollte, wollte ich als nächstes in Homematic einsteigen. Da trifft sich das doch wunderbar! Wieder mal ein paar Euro gespart auf dem Weg zum smart Home.

Hab zwar noch nix geflasht, dennoch schon mal: Vielen Dank an Telekatz für den Port. Du bist mein persönlicher Oktober-Held!
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 21 Oktober 2015, 12:56:12
Hallo Telekatz!
Mit wachsender Begeisterung habe ich Deinen Beitrag hier verfolgt und habe mir nun selbst einen Cube gekauft, da ich bei mir zu Hause nun auch in die Hausautomation einsteigen möchte.
Ich hatte auch Glück, mein Modell, welches ich bekommen habe ist ein TRX868-TI und somit kompatibel zu Deinem Projekt.
Ich habe bisher erfolgreich den Bootloader geflasht und das Cube-Board wartet nun mit blinkender D1 LED auf eine Firmware...
Leider kann ich ihm keines senden, da Windows 7 für die neu entdeckte Hardware "CUBELOADER" keinen Treiber findet! Ich habe zwar auf das Verzeichnis von "Atmel" verwiesen, jedoch findet es keinen passenden Treiber... ;-(
Ich würde mich wirklich sehr freuen, wenn Du mir an der Stelle einen Tipp geben könntest! Vielen Dank im Voraus!

Ergänzung:
Ich habe den Treiber nun manuell erzwungen, indem ich bei der Treibersuche (Manuell aus Liste wählen -> COM Port -> Atmel -> AT91 USB to Serial Converter) ausgewählt habe! Hat geklappt! Nun werde ich fhem einrichten und den CUBE anschließen per LAN... ich werde berichten! Vielen Dank nochmal für dieses Projekt Telekatz!

Ergänzung2:
Ich habe erfolgreich einen MAX! Heizkörperthermostat Basic damit auslesen und steuern können! Perfekt!!! Jetzt wird das ganze Haus ausgestattet! ;-)
Titel: Antw:culfw@ARM
Beitrag von: SmokeMaster am 22 Oktober 2015, 21:19:10
Ich noch mal. Nachdem ich den Bootloader wie oben beschrieben vor ein paar Tagen auf meinen CUBE geflasht hatte, habe ich jetzt die Firmware geflasht.
Hier mal eine Anleitung für die Linux Nutzer zum flashen des MAX CUBE.
Kommt sich darauf an welche Distri ihr nutzt: Installiert das Programm minicom und seid Root.
Schließt den Cube an und öffnet ein Terminal.
dann schaut nach wie das gerät heißt das ihr ansprechen wollt: dmsg | grep ttyeines wird sicher etwas mit USB im Namen haben, etwa: ttyACM diesen Namen braucht ihr.
nun geht es weiter (auf Root achten!) minicom -s im folgenden menü geht ihr in die Einstellungen zur Seriellen Verbindung, drückt a, und gebt den Namen (z.B. ttyACM) anstelle der voreinstellung ein (meist auch ttyIRGENDWAS) nur das letzte mus geändert werden, nicht der ganze Pfad. zB: aus /dev/ttyBLUB macht ihr /dev/ttyACM
nun das Menü schließen und in minicom die Tastenkombination Strg+A verwenden und dann die Taste Z drücken. Jetzt wählt ihr Datei Senden aus indem ihr den entsprechenden Buchstaben drückt (es war meine ich "S") dann noch zum Ort Navigieren an dem die zu Flashende Datei liegt und diese auswählen.
Die Datei sollte gesendet werden und wenn alles fertig ist drückt ihr die berühmte beliebige Taste.
Fertig.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 23 Oktober 2015, 14:07:44
So... Ich wollte doch berichten: Super! Ich habe Empfang durch drei(!) Betondecken, vom Gateway im Keller bis unter das Dach zum letzten Regler, klasse!

Der Cube ist auch zuverlässig und fleißg, vielleicht zu fleißig. Habe zwei sich häufende Einträge im Log:
Alle 30 Sekunden: CUN1: unknown message V 1.10.01 a-culfw Build: 167 (2015-10-13_18-19-02) CUBe (F-Band: 868MHz)
Unregelmäßig, aber oft: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update.

Kann mir jemand hierbei weiterhelfen?
Vielen Dank im Voraus!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 23 Oktober 2015, 14:28:57
Mach mal einen Update von FHEM. Für die erste Meldung gab es im April eine Änderung in 00_CUL.pm, um diese Nachrichten auszufiltern. Wegen der zweiten Meldung wurde kürzlich 14_CUL_MAX.pm geändert.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 23 Oktober 2015, 15:16:44
Hat geklappt! Vielen, vielen Dank!  ;D
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 24 Oktober 2015, 14:18:16
Hallo,
ich will mich auch erst einmal vielmals für die Arbeit die hier drinnen steckt bedanken. Leider habe ich aber ein kleines Problem:
bei mir steigt der Cube mit der Firmware hier immer nach recht kurzer Zeit komplett aus. Es dauert so etwas zwischen 4h und 16h (hab es erst 2 - 3 mal probiert) und dann ist der Cube nicht mehr erreichbar. Weder per Telnet noch per Ping. Wenn er vorher mit FHEM verbunden war, dann kommt die folgenden Meldungen:
2015.10.21 20:20:06 1: 192.168.10.30:2323 disconnected, waiting to reappear (CUBE1)
2015.10.21 20:20:06 1: Error in CUL_MAX_SendQueueHandler: CUL CUBE1 did not answer request for current credits. Waiting 5 seconds.

Allerdings muss er vorher nicht unbedingt mit FHEM verbunden gewesen sein um nicht mehr erreichbar zu sein. Ich hatte ihn heute einfach ungefähr 4h angeschlossen ohne das sich was mit ihm verbunden hat und jetzt ist er weder per Ping noch per Telnet erreichbar.
Da ich bei dem niegelnagelneuen Cube auch noch die Fehlermeldung CUBE1: unknown message ZERR30D hatte, benutze ich gerade die Firmware von hier http://forum.fhem.de/index.php/topic,25745.msg332883.html#msg332883
Irgendwas läuft auf alle Fälle noch auf dem Cube, da die eine LED noch blinkt. Eine neue Verbindung kriege ich leider nur nach einem Power Cycle wieder hin.

Hat eventuell irgendjemand eine Idee woran das ganze liegen kann? Ich habe gerade mal im Git probiert zu schauen, ob sich etwas an den Netzwerkroutinen geändert hat aber leider habe ich da nicht wirklich was gefunden.
Ich kann auch gerne mal per JTAG hochschauen (wenn es aktiviert ist, hab im uC Forum gelesen das es eventuell deaktiviert ist) und sehen, wo es hängt. Nur bräuchte wäre ich da über einen Anhaltspunkt sehr froh :)

Mit besten Grüßen
Andreas
Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 25 Oktober 2015, 09:07:18
dmsg | grep tty


Danke für die super Beschreibung. Nur muss es dmesg heissen... (Ein Buchstabe vergessen)
Titel: Antw:culfw@ARM
Beitrag von: SmokeMaster am 25 Oktober 2015, 11:33:35

Danke für die super Beschreibung. Nur muss es dmesg heissen... (Ein Buchstabe vergessen)
oops, war keine böse Absicht :) Habe das auf die schnelle zwischen firmware flashen und CUL(CUBE) in FHEM einrichten runtergerattert. Mir ist auch ein Fehler unterlaufen in dem Punkt:
Zitat von: SmokeMaster
eines wird sicher etwas mit USB im Namen haben, etwa: ttyACM diesen Namen braucht ihr.

Ist ja nicht wirklich USB im Namen, aber der zweite Teil ist richtig: ttyACM
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 25 Oktober 2015, 12:09:50
Hallo,
ich will mich auch erst einmal vielmals für die Arbeit die hier drinnen steckt bedanken. Leider habe ich aber ein kleines Problem:
bei mir steigt der Cube mit der Firmware hier immer nach recht kurzer Zeit komplett aus. Es dauert so etwas zwischen 4h und 16h (hab es erst 2 - 3 mal probiert) und dann ist der Cube nicht mehr erreichbar. Weder per Telnet noch per Ping. Wenn er vorher mit FHEM verbunden war, dann kommt die folgenden Meldungen:
2015.10.21 20:20:06 1: 192.168.10.30:2323 disconnected, waiting to reappear (CUBE1)
2015.10.21 20:20:06 1: Error in CUL_MAX_SendQueueHandler: CUL CUBE1 did not answer request for current credits. Waiting 5 seconds.

Allerdings muss er vorher nicht unbedingt mit FHEM verbunden gewesen sein um nicht mehr erreichbar zu sein. Ich hatte ihn heute einfach ungefähr 4h angeschlossen ohne das sich was mit ihm verbunden hat und jetzt ist er weder per Ping noch per Telnet erreichbar.
Da ich bei dem niegelnagelneuen Cube auch noch die Fehlermeldung CUBE1: unknown message ZERR30D hatte, benutze ich gerade die Firmware von hier http://forum.fhem.de/index.php/topic,25745.msg332883.html#msg332883
Irgendwas läuft auf alle Fälle noch auf dem Cube, da die eine LED noch blinkt. Eine neue Verbindung kriege ich leider nur nach einem Power Cycle wieder hin.

Hat eventuell irgendjemand eine Idee woran das ganze liegen kann? Ich habe gerade mal im Git probiert zu schauen, ob sich etwas an den Netzwerkroutinen geändert hat aber leider habe ich da nicht wirklich was gefunden.
Ich kann auch gerne mal per JTAG hochschauen (wenn es aktiviert ist, hab im uC Forum gelesen das es eventuell deaktiviert ist) und sehen, wo es hängt. Nur bräuchte wäre ich da über einen Anhaltspunkt sehr froh :)

Mit besten Grüßen
Andreas

Hallo Telekatz,
ich muss mich Mr.OS anschließen, ich habe exakt das gleiche Problem (inkl. Fehlermeldungen im Log!)... Nach ein paar Stunden ist der CUBE komplett offline... Kannst Du hier helfen? Vielen Dank im Voraus!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 25 Oktober 2015, 15:00:43
Hat eventuell irgendjemand eine Idee woran das ganze liegen kann? Ich habe gerade mal im Git probiert zu schauen, ob sich etwas an den Netzwerkroutinen geändert hat aber leider habe ich da nicht wirklich was gefunden.
Der UIP Stack ist der selbe wie er auch für den CUNO verwendet wird. Neu hinzugekommen ist der Netzwerktreiber für den CUBE, den ich aus der at91lib von Atmel übernommen habe.

Kannst du mal die angefügte Firmware ausprobieren, ob hier das Netzwerk stabil funktioniert. Ich habe hier die Netzwerkfunktionen aus der neuesten Version der at91lib genommen, die ich finden konnte.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 25 Oktober 2015, 19:26:10
@chris_fiesta  bzw. Mr.OS, wie ist die Stromversorgung des Cube realisiert ?
Ich hatte meinen am Anfang zum testen ein paar Tage direkt an einer Fritzbox (sowohl USB als auch das LAN Kabel) , dort hat er sich auch regelmäßig verabschiedet :(
Seit ca. einer Woche steht er nun im Keller an einem Cisco Switch , Strom kommt von einem alten USB Netzteil ohne einen einzigen Disconnect :)
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 26 Oktober 2015, 07:59:12
@Wzut:
Das mit dem Netzteil ist ein guter Hinweis. Ich habe den Cube allerdings an dem mittgelieferten Netzteil ebtrieben und glaube, dass es schon funktionieren sollte. Das hatte ja 0,5A am Ausgang. Ich habe ihn aber heute früh mal schnell an ein anderes Netzteil angeschlossen und werde heute Nachmittag/Abend sehen, ob er noch lebt.

@Telekatz:
Vielen Dank für die neue Version. Wenn es das Netzteil nicht ist (was ich glaube), dann werde ich die Version mal probieren.

Was mich ein wenig beschäftigt ist die Tatsache, dass der Cube die Telnet-Verbindung aktiv beendet. Wenn ich einfach nur den Strom von ihm abziehe merkt Fhem das ja nicht (so schnell). Sollte man eventuell finden können.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 26 Oktober 2015, 09:44:34
Kannst du mal die angefügte Firmware ausprobieren, ob hier das Netzwerk stabil funktioniert. Ich habe hier die Netzwerkfunktionen aus der neuesten Version der at91lib genommen, die ich finden konnte.
Ich habe nun diese Version mal geflasht... ich werde berichten, ob der CUBE nun zuverlässig läuft.
Nur folgende Fehlermeldung habe ich nun im Log:
CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 113. Waiting 111 seconds.
und die ist auch wieder da:
CUN1: unknown message ZERR30D
Im Übrigen verwende ich auch das original Netzteil, an der Stromversorgung sollte es also nicht liegen, aber danke für den Tipp.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 27 Oktober 2015, 10:46:02
Hallo Telekatz,
leider hat auch diese neue Firmware von Dir nicht geholfen. Der CUBE ist wieder nach ein paar Stunden reproduzierbar ausgestiegen...
Kann ich irgendetwas tun, dass Dir bei diesem Problem weiterhelfen könnte?
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 27 Oktober 2015, 11:10:06
Ich habe egstern morgen noch schnell das Netzteil gewechselt um das sicherheitshalber auszuschließen. Es ist dann aber gegen 20:00 wieder ausgestiegen.
Seit dem läuft jetzt die neue Firmware mit dem ZERR30D Fehler.

Welche Toolchain Version hast du genutzt? Vielleicht kriege ich es ja ins Atmel Studio oder wo anders rein und kann mal den Debugger mitlaufen lassen.
Ich werde auch mal schauen, an welchen Stellen aus welchen Gründen im Code der uIP Stack gekillt wird. Es wird ja noch ordentlich die Verbindung beendet ...
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 Oktober 2015, 11:51:49
Das Problem ist halt, das mein Cube ohne Probleme durchläuft. Ich kann kann den Fehler bei mir nicht reproduzieren.

Die Toolchain die ich verwende steht im ersten Beitrag. Der SAM7 wird im Atmel Studio soweit ich weiß gar nicht unterstützt. Da wirst du dir wohl Eclipse mit GDB zum Debuggen einrichten müssen.

Welche Revision hat eigentlich der SAM7 auf euren CUBEs (B oder C)?

Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 27 Oktober 2015, 13:37:46
Welche Revision hat eigentlich der SAM7 auf euren CUBEs (B oder C)?

Ich vermute, dass steht auf dem Chip selbst drauf? Ich werde Dir nachher mal ein, zwei Bilder des Boards posten...
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 27 Oktober 2015, 13:48:22
Mein Cube hat die Rev. B.

Grüße

anfichtn
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 Oktober 2015, 14:26:00
Mein Cube hat die Rev. B.

Läuft bei dir die Netzwerkverbindung stabil?
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 27 Oktober 2015, 17:44:02
Bei mir ist auch die neue uIP Version heute 13:30 ausgestiegen.
Mein SAM7 hat die Rev C

Ist ja blöd dass der SAM7 nicht mit dem Atmel Studio geht. Soweit hatte ich gar nicht gedacht. Mal schauen, ich werde nachher mal ein wenig probieren.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 28 Oktober 2015, 09:14:31
Grüß Dich Telekatz,
ich hatte nun Gelegenheit den Cube mal zu "zerlegen". Ich habe auch Revision C, wenn ich das "C" auf dem Chip richtig interpretiere. Zur Sicherheit habe ich Dir mal Bilder meines Boards angehängt, in der Hoffnung Du kannst mir/uns helfen!?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Oktober 2015, 10:53:27
Ja, der SAM7 hat die Revision C. Was mich noch interessieren würde ist, ob die Netzwerkverbindung nur im MAX Modus instabil ist oder auch im SlowRF Modus.

@Wzut
Bei deinem Cube läuft die Netzwerkverbindung stabil. In welchen Modus betreibst du den Cube und hat dein SAM7 die Revision B?
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 28 Oktober 2015, 11:03:51
Wenn ich es richtig sehe, wird der RF-Modus doch erst von FHEM konfiguriert oder?
Ich hatte den Cube nämlich einfach am Wochenende an Strom und Netzwerk gehangen ohne das sich FHEM mit ihm verbunden hatte oder eine andere Telnet Verbindung da war. Der war dann nach ungefähr 4-5h auch nicht mehr ansprechbar als ich FHEM gestartet habe. Weder per Telnet auf 2323 noch per Ping.

Ich ahbe leider gestern nicht die sonst von mir genutzte IDE (em::blocks) zum kompilieren überreden können. Ich bin aber dabei.
Titel: Antw:culfw@ARM
Beitrag von: ThommyTom am 28 Oktober 2015, 11:04:12
Hallo zusammen,

ich werde leider nicht ganz schlau, woran kann ich genau erkennen ob mein Cube geeignet ist!? Auf dem Cube selber steht "nur" TRX868.
Kann ich den Cube mit der alternativen FW flashen?

Und noch eine Frage. In der Anleitung steht die Pins J11 verbinden, heisst das ich muss die einfach nur mit nem Draht echt verbinden?

Frage nur vorsichtshalber, will meinen Cube nicht gleich zerschiessen!  ???

Gruß Thommy
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 28 Oktober 2015, 11:40:26
Und noch eine Frage. In der Anleitung steht die Pins J11 verbinden, heisst das ich muss die einfach nur mit nem Draht echt verbinden?
Hallo ThommyTom,
ja, es bedeutet echt verbinden. Ich habe das einfach mit einem Stück Litze gemacht, so 2 bis 3 Sekunden lang, nach dem ich den USB-Stecker angeschlossen hatte, das reicht.

@Telekatz
ich betreibe ihn im MAX Modus... ich schließe ihn aber nun mal an im SlowRF Modus - ich werde berichten.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Oktober 2015, 11:51:54
ich werde leider nicht ganz schlau, woran kann ich genau erkennen ob mein Cube geeignet ist!? Auf dem Cube selber steht "nur" TRX868.
Kann ich den Cube mit der alternativen FW flashen?
Wenn nur TRX868 drauf steht dann ist der Cube geeignet.

Wenn ich es richtig sehe, wird der RF-Modus doch erst von FHEM konfiguriert oder?
Ich hatte den Cube nämlich einfach am Wochenende an Strom und Netzwerk gehangen ohne das sich FHEM mit ihm verbunden hatte oder eine andere Telnet Verbindung da war. Der war dann nach ungefähr 4-5h auch nicht mehr ansprechbar als ich FHEM gestartet habe. Weder per Telnet auf 2323 noch per Ping.

Richtig, der Modus wird erst von FHEM gesetzt. Dann sieht es für mich immer mehr so aus, daß das Problem irgend etwas mit der Revision C des SAM7 zu tun hat.

Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 28 Oktober 2015, 11:56:39
Richtig, der Modus wird erst von FHEM gesetzt. Dann sieht es für mich immer mehr so aus, daß das Problem irgend etwas mit der Revision C des SAM7 zu tun hat.
Kann ich etwas tun, damit du leichter erkennen kannst woran genau?  :-[
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 28 Oktober 2015, 12:09:11
Ich habe gerade mal ins Errata der Rev C geschaut und was sich zur Rev B getan hat ist das folgende:
EFC: Embedded Flash Access Time 2
The embedded Flash maximum access time is 20 MHz (instead of 30 MHz at zero Wait State (FWS = 0).
The maximum operating frequency with one Wait State (FWS = 1) is 48.1 MHz (instead of 55 MHz). Above 48.1 MHz and
up to 55MHz, two Wait States (FWS = 2) are required.
Problem Fix/Workaround
Set the number of Wait States (FWS) according to the frequency requirements described in this errata.
Ich habe jetzt meiner Meinung nach im Code rausgelesen, dass er FWS auf 1 stellt. Leider hab ich jetzt auf die schnelle nicht den Takt gefunden.
Eventuell prophylaktisch einfach hoch stellen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Oktober 2015, 12:24:09
Kann ich etwas tun, damit du leichter erkennen kannst woran genau?  :-[
Ich denke nicht. Ich muss mir selber mal einen aktuellen Cube besorgen.

Ich habe gerade mal ins Errata der Rev C geschaut und was sich zur Rev B getan hat ist das folgende:
EFC: Embedded Flash Access Time 2
The embedded Flash maximum access time is 20 MHz (instead of 30 MHz at zero Wait State (FWS = 0).
The maximum operating frequency with one Wait State (FWS = 1) is 48.1 MHz (instead of 55 MHz). Above 48.1 MHz and
up to 55MHz, two Wait States (FWS = 2) are required.
Problem Fix/Workaround
Set the number of Wait States (FWS) according to the frequency requirements described in this errata.
Ich habe jetzt meiner Meinung nach im Code rausgelesen, dass er FWS auf 1 stellt. Leider hab ich jetzt auf die schnelle nicht den Takt gefunden.
Eventuell prophylaktisch einfach hoch stellen?
Der Takt liegt bei 48MHz, FWS = 1 sollte deshalb passen. Aber man kann ja trotzdem mal ausprobieren, FWS auf 2 zu setzen.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 28 Oktober 2015, 16:22:36
@Wzut
Bei deinem Cube läuft die Netzwerkverbindung stabil. In welchen Modus betreibst du den Cube und hat dein SAM7 die Revision B?
Modus = MAX , Revision kann ich erst heute Abend checken wenn ich den Cube aufmache.
K.A. ob es eine Rolle spielt : aber ich hatte ja das Problem das ich nicht mit bootloader + xmodem flashen konnte und musste daher deine zu Anfang gepostete .bin Datei nehmen ( die hat auch noch den  unknown message ZERR30D Fehler)

V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Oktober 2015, 17:00:00
K.A. ob es eine Rolle spielt : aber ich hatte ja das Problem das ich nicht mit bootloader + xmodem flashen konnte und musste daher deine zu Anfang gepostete .bin Datei nehmen ( die hat auch noch den  unknown message ZERR30D Fehler)
Lag da nicht das Problem daran, dass du versucht hast die Version für die Verwendung ohne Bootloader mit dem Bootloader zu verwenden?
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 28 Oktober 2015, 18:55:29
Ich habe es jetzt endlich geschafft es zu compilieren - wenn auch nicht in der IDE die ich will. Leider kann ich so nicht per JTAG drauf.
Ich habe aber mal die WaitStates geändert und das uIP logging angeschalten. Jetzt läuft das Ganze mal und ich logge die Ausgabe mit.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 28 Oktober 2015, 19:40:17
Ich habe nun den Cube mal per USB angeschlossen und beobachte mal so das Verhalten, was ich jetzt schon sagen kann, ist das der Fehler unknown message ZERR30D auch via USB geloggt wird...  :o
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 28 Oktober 2015, 19:42:52
Ich denke nicht. Ich muss mir selber mal einen aktuellen Cube besorgen.
@Telekatz
Ich kann dir auch einfach mal meinen zuschicken und du schickst mir den einfach nach deinen Tests unfrei wieder zu mir zurück. Dann würden Dir wenigstens keine Kosten entstehen... hast ja schon genug Arbeit damit!  :-[
Schick mir einfach eine PN, wenn Du damit einverstanden bist.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 28 Oktober 2015, 19:54:39
Lag da nicht das Problem daran, dass du versucht hast die Version für die Verwendung ohne Bootloader mit dem Bootloader zu verwenden?

das war ein Fehler von mir nachdem bootloader + a-culfw via xmodem in allen Versionen nicht ging - Letztendlich lief der Cube nur mit der Datei von dir ohne Bootloader.
Aber anway , die Schrift auf dem Atmel ist so schwach das ich es nicht schaffe ein brauchbares Foto davon zu machen.
die Beschriftung unterhalb des ATMEL Logo :
              AT91SAM7X256
                    AU
1122                B
1PO750                   ARM
 
Gekauft wurde der Cube als Neuware im Frühjahr 2012.
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 28 Oktober 2015, 20:12:41
Moin!

Läuft bei dir die Netzwerkverbindung stabil?

Ich kann mich nicht beklagen, Ausfälle konnte ich bisher nicht feststellen, trotzdem taucht auch bei mir der eigenwillige Fehler auf.
Internals:
   CMDS       BCFiAZEGMKLUYRTVWXefltx
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
   Cube_MSGCNT 58
   Cube_TIME  2015-10-28 20:07:30
   DEF        192.168.178.80:2323 4321
   DeviceName 192.168.178.80:2323
   FD         17
   FHTID      4321
   NAME       Cube
   NR         178
   NR_CMD_LAST_H 3
   PARTIAL
   RAWMSG     Z0EC502020E02FE0F39350001380F2D37
   RSSI       -46.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za0d9874
Zw111111
   CHANGETIME:
   Helper:
     Dblog:
       State:
         Mydblog:
           TIME       1446056025.98194
           VALUE      UNKNOWNCODE ZERR30D
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2015-10-14 22:56:41   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2015-10-28 19:13:14   cmds             B C F i A Z E G M K L U Y R T V W X e f l t x
     2015-10-28 19:13:44   credit10ms      900
     2015-10-28 20:07:30   state           Initialized
     2015-10-28 20:05:25   uptime          10 22:24:12
     2015-10-14 22:59:42   version         V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1446055994.32879
     1446055994.62965
     1446056024.94958
Attributes:
   rfmode     MAX
   room       99_System

Grüße

anfichtn
Titel: Antw:culfw@ARM
Beitrag von: Blizzard am 28 Oktober 2015, 20:12:56
Habe auch eine B-Version und kann das Netzwerkproblem bestätigen. Einen genauen Zeitraum kann ich nicht fest machen; mal steigt der Cube nach Stunden aus, mal nach Tagen und mal nach 1-2 Wochen....
Ich verwende den Cube in Verbindung mit Homegear um Homematic-Geräte zu steuern...

Mein zweiter Cube hängt über USB direkt am Rechner und steuert die Max!-Geräte. Dieser Cube läuft seit Wochen einwandfrei, auch wenn am Tag mehrere Male die ZERR30D-Meldung geloggt wird.

Viele Grüße,
Martin
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 28 Oktober 2015, 20:42:55
Ich glaube, ich habe schon die Ursache gefunden. Ich probiere gerade, sie zu reproduzieren.
Ich habe aber schon mal eine neue Firmware gebastelt und wer will, kann probieren. An den Wait States lag es übrigens nicht.
Edit: Die Firmware ist weiter hinten zu finden

Wenn ich es reproduzieren kann sag ich natürlich auch, woran es liegt.

Das ZERR30D sollte aber schon mal weg sein.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 29 Oktober 2015, 10:08:38
Ich habe gestern Abend den Cube mal per USB angeschlossen und nicht per LAN, denn ich wollte ausschließen, dass es mit etwas anderes als dem Netzwerk zu tun haben könnte, warum der Cube sich stumm stellt. Er läuft jetzt seit fast 15 Stunden ohne Ausfall, solange lief er noch nie! Es hat also definitiv etwas mit dem Netzwerk zu tun... Ich habe aber dennoch den unknown message ZERR30D Fehler.

@mr.os
Sollte der Cube heute Abend immer noch funktionieren, werde ich Deine FW mal probieren! Ich würde mich aber dennoch darüber freuen zu lesen, was Du gefunden hast?!?
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 29 Oktober 2015, 10:52:53
Gestern Abend musste es schnell gehen, deshalb jetzt etwas mehr:
Der ZERR30D Fehler kommt durch ein sehr unglückliches Stückchen Code für den CC1100 im MAX! Teil der Firmware. Da hatte schon mal wer hier im Forum was genaueres dazu geschrieben. Siehe hier: http://forum.fhem.de/index.php/topic,25745.msg218980.html#msg218980 Da hab ich nur den Code kopiert und bei mir eingefügt. Die Firmware aus dem Thread lief bei auch ohne den ZERR30D Fehler.

Das die Netzwerkverbindung immer mal wieder zusammen bricht lag daran, dass der uIP Stack so konfiguriert ist, dass er maximal Packete mit 1500 Bytes Länge empfangen kann. Das reicht eigentlich auch. Aber zumindest bei mir im Netzwerk kamen am Cube auch welche mit 1510 Bytes an. Er hat auch ordentlich erkannt dass es zu lang ist. Normalerweise sollte er das verwerfen und auf das nächste warten. Hat er aber nicht gemacht. Er hat es einfach immer und immer wieder probiert abzurufen und das hat alles lahmgelegt.
Ich hab jetzt was eingebaut das er solche Packete verwirft und einfach weitermacht als ob nichts gewesen wäre. Gestern Abend hat er bei mir auch noch mehrere zu lange Packete empfangen und geht trotzdem noch.
Die Leute bei Atmel die den Stack auf den SAM7 adaptiert haben, haben sich echt nicht mit Ruhm beckleckert. In einer Bibliothek ein hart reincodiertes printf ...

Dein Cube wird also per USB gehen. Ich würde heute Abend auch noch mal ein diff fertig machen und es Telekatz zukommen lassen wenn es recht ist. Kann man ja vielleicht ne neue Version draus machen.
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 29 Oktober 2015, 12:17:05
@mr.os
Vielen Dank für Deine Nachricht und Arbeit, die Du investierst! Ich werde heute Abend nach der Arbeit Deine Firmware ausprobieren!  ;D
Titel: Antw:culfw@ARM
Beitrag von: Blizzard am 29 Oktober 2015, 12:27:49
@Chris-Fiesta:
Ich kann die Aussage von Mr. OS bestätigen. Habe zwei Cubes parallel laufen; einer am Netzwerk (Homematic), einer an USB (MAX!). Der USB-Cube läuft seit Monaten störungsfrei.

@Mr. OS:
Ich habe heute morgen deine Version auf den Netzwerk-Cube aufgespielt. Bin schon ganz gespannt und werde berichten! Vielen Dank dafür!  :)

Viele Grüße,
Martin
Titel: Antw:culfw@ARM
Beitrag von: cdn am 29 Oktober 2015, 14:26:50
Nimm einen 10 kOhm Widerstand und stecke ihn an den markierten Kontakten in den USB Stecker. Den Wiederstand etwas festdrücken, damit er auch richtig Kontakt bekommt. Der Widerstand wird nur temporär benötigt, bis der Bootloader mit SAM-BA aufgespielt ist. Danach kann er wieder entfernt werden.

So habe jetzt endlich meinen 10k Widerstand bekommen und angeschlossen. Leider wird der Stick immer noch nciht erkannt -.-
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 29 Oktober 2015, 17:32:07
@Mr. OS , TOP JOB !! Respekt das du den Bug mit den 1500 byte gefunden hast.
Also war bei mir auch nicht unbedingt das Netzteil schuld sondern eventuell die Position im Netzwerk ...
Titel: Antw:culfw@ARM
Beitrag von: mr.os am 29 Oktober 2015, 18:25:27
Ich hab noch mal neu compiliert und die Wait States und einige Debug-Ausgaben wieder zurückgesetzt. Das hatte ich gestern Abend in der Eile des Gefechts nicht gemacht.
Bie mir ist der Cube seit gestern Abend bis jetzt durchgelaufen (jetzt hab ich noch mal schnell meine neue Version hochgespielt). Es ist wirklich (scheinbar) nur das eine Problem gewesen.

(Wer die andere Firmware von gestern drauf hat muss nicht unbedingt tauschen - die geht auch)
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 29 Oktober 2015, 20:06:47
@mr.os
Danke für Deine Mühen! Ich habe Deine Firmware nun aufgespielt... Was ich bis jetzt sagen kann ist: KEINE FEHLERMELDUNGEN! Spitze!
Wenn das Dingen jetzt auch noch durchrennt, bin ich höchst zufrieden.
Hast Dich auch schön verewigt: get MAXCUBE version -> ...build by mr.os...   8)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 29 Oktober 2015, 21:25:40
@Mr. OS: Danke für den Patch. Ich hab ihn in den Sourcecode eingearbeitet und committed. Die Änderungen sollten dann bald in der a-culfw enthalten sein.

So habe jetzt endlich meinen 10k Widerstand bekommen und angeschlossen. Leider wird der Stick immer noch nciht erkannt -.-
Wird der Stick im Gerätemanager gar nicht angezeigt oder als unbekanntes Gerät? Und hast du SAM-BA auch schon installiert?
Titel: Antw:culfw@ARM
Beitrag von: chris_fiesta am 30 Oktober 2015, 08:06:43
Mit der Firmware von mr.os läufts!
Mein Cube hängt jetzt über 12 Stunden per LAN im Netz und arbeitet zuverlässig und OHNE Fehlermeldungen! Perfekt! Danke vielmals an Telekatz & mr.os!  ;D ;D ;D
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 30 Oktober 2015, 16:03:55
Die Änderungen sollten dann bald in der a-culfw enthalten sein.
würde es dir etwas ausmachen nochmal mit der jetzigen Version eine .bin Datei zu posten die ohne Bootloader läuft ?
Mein Netzwerk war zwar (noch) nicht betroffen aber ich hätte gerne den ZERR30D Error weg :)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 30 Oktober 2015, 17:40:12
Anbei die Version ohne Bootloder.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 31 Oktober 2015, 12:31:58
Hallo telekatz.
Kann ich mit dieser version auch immernoch meine homeeasy schalter 433 mhz empfangen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 31 Oktober 2015, 18:23:06
Die 433 MHz Protokolle sind weiterhin im Cube enthalten.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 04 November 2015, 10:52:45
Hallo zusammen,

wo ist denn nun die letzte aktuelle Version zu finden ?

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 November 2015, 11:42:58
Die aktuelle Version findest du in der a-culfw:
http://forum.fhem.de/index.php/topic,35064.0.html (http://forum.fhem.de/index.php/topic,35064.0.html)
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 04 November 2015, 14:12:04
Ich meinte die mit der ich den MAX! Cube neu flashen kann

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 November 2015, 14:22:20
Die ist dort auch enthalten.
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 06 November 2015, 20:34:34
Hallo, 
Danke erst einmal für die tolle Arbeit und deinen Support.

Ich habe bereits meinen Cube erfolgreich geflasht und nutze ihn für meine max! Thermostate.
Nun habe ich bei ebay einen zweiten erstanden und wollte ihn auch flashen.
Ich komme bis zum Starten von Sam-ba und kann dort den com-port auswählen. Wenn ich nun auf Connect klicke,  dann öffnet si h kein Fenster. Das andere verschwindet und es passiert nichts mehr.

Hat jemand einen Hinweis oder Rat für mich?

Edit:
Habe es bereits an 2 Laptops probiert(winxp und win8)

Mfg
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 12:19:06
habe nochmal das Vergrösserungsglas rausgeholt.

auf dem Chip steht

AT91SAM7X256 AU

kann mir niemand helfen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 November 2015, 13:36:58
Kommt wenigstens eine Fehlermeldung nach dem Drücken von Connect?
Welche SAM-BA Version?
Steht da bei der Auswahl des Com Ports etwas in der Art "\USBserial\COMx"?
Richtiges Board ausgewählt?
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 14:25:22
Hallo,
Danke erstmal für deine Antwort.
Ich kann das richtige Board nicht auswählen, es gibt bei der Auswahl kein at91sam7x256-Au.

Es gibt nur eins mit -ek am ende.
Wenn ich dieses auswähle kommt keine Fehlermeldung. Beim Klick auf Connect verschwindet das Fenster und dann passiert nichts mehr.
Als version benutze ich 2.15.
habe auch schon 2.8 probiert, dort bekomme ich wenigstens eine Fehlermeldung (No valid Processor ID found) oder so ähnlich.
Aber auch hier gibt es das Board mit der Endung -Au nicht.
Habe jetzt das ganze WE am Laptop verbracht und Google gequält aber nichts gefunden.

Mit freundlichen Grüßen
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 November 2015, 14:48:14
Das richtige Board ist at91sam7x256-ek.

Steht da bei der Auswahl des Com Ports etwas in der Art "\USBserial\COMx"?
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 14:51:21
Wenn ich das Board mit der Endung ek nehme bekomme ich obige Fehlermeldung bei v2.8 und bei v2.15 passiert nichts.

Bei der Auswahl des ComPorts steht \USBserial\COM8

Mfg
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 November 2015, 15:09:42
Wo hast du die Version 2.8 her? Die neueste Version, die ich auf der Atmel Seite finden konnte war V2.15.
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 15:16:10
Von der Atmel-Seite.
War ein Programm-Bundle mit Sam-Prog v2.4
AT91-ISP v1.2

Hast du evtl noch eine Tip wie ich das wieder hinbiegen kann?
Wie gesagt, beim ersten Cube hat es wunderbar geklappt.
Dieser hatte allerdings einen at91sam7x512 Chip.
Titel: Antw:culfw@ARM
Beitrag von: anfichtn am 08 November 2015, 15:32:44
Moin!

Meines Erachtens liegt dein Problem am verwendeten usb-kabel. Probier einfach mal ein anderes Kabel aus.
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 15:35:25
Mh, wenn ich ehrlich bin habe ich schon 4 verschiedene probiert.
Das vom neuen und vom alten Cube(hat beim alten Cube funktioniert) und eins von einer DigiCam und noch eins von einer USB Festplatte.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 November 2015, 15:36:39
Ich würde alle SAM-BA Versionen deinstallieren, den USB Treiber deinstallieren, SAM-BA V2.15 installieren, den USB Treiber aus dem SAM-BA V2.15 Verzeichnis manuell installieren, am Cube nochmal einen Flash Erase durchführen und es nochmal probieren.

Der at91sam7x256 ist eigentlich der übliche µC für den Cube. Einen at91sam7x512 hatten glaube ich nur die frühen Versionen des Cube.

Hast du ein JTAG Interface?
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 15:42:20
Habe es sogar schon an einem jungfräulichen Rechner probiert. Hier ist es identisch zu meinem.

Nein, habe kein JTAG-Interface
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 15:51:42
So, alles noch einmal deinstalliert und Rechner neu gestartet.
Sam-ba v2.15 installiert und Treiber ebenfalls.
J1 Pink geschlossen und kurz mit usb verbunden und wieder getrennt.

J1 Brücke entfernt und wieder am usb angeschlossen.

Gleiches Ergebnis wie vorher,
Sam-ba gestartet, Com-Port vom at91usbtoSerialdriver ausgewählt und Connect gedrückt.
Das Fenster verschwindet und das wars dann.
Keine weitere Reaktion.
Schade eigentlich

Gibt's evtl. die Möglichkeit etwas mit TeraTerm zu senden?
Habe gerade mit dem "sendFile" probiert, allerdings schreibt er den Bootloader nur zu 29%, dann ist wohl der Speicher voll.
Jedenfalls klappt die Verbindung mit TeraTerm.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 November 2015, 16:09:57
Meldet sich der Atmel Bootloader unter TerraTerm nach Eingabe von V# mit z.B. "v1.4 Feb 02 2005 17:55:46"?
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 16:20:44
Also mit TeraTerm kann ich keine Eingaben machen.
Kann auf der Tastatur rumhacken wie ich will, es erscheint kein Buchstabe.


Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 November 2015, 16:58:25
Irgendwie passt das nicht zusammen. Da du eine USB Verbindung mit TerraTerm aufbauen kannst muss der Atmel Bootloader auch laufen. Dann müsste aber auch  nach der Eingabe von # ein Kommandopromt ">" und nach der Eingabe von V# "v1.4 Feb 02 2005 17:55:46" erscheinen.
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 08 November 2015, 17:03:37
Wie gesagt,
Egal welche Taste ich auf der Tastatur tippe, in TeraTerm erscheint kein Zeichen.
Habe auch schon die Schriftfarbe und die Hintergrundfarbe geändert, aber es erscheint kein Buchstabe auf dem Terminal.
Fahre jetzt mal den 2.PC hoch und versuche es dort.
Evtl liegt es ja an winXP

Edit:
So, habe am Laptop meiner Tochter probiert, keine Änderung.
Auch hier ist keine Eingabe am Terminal möglich.

Ich bin ja echt ein geduldiger Mensch, aber wenn man das ganze WE mit einem so kleinen Cube verbringt, kann die Laune schon mal sinken.
Bin kurz davor das Ding einfach in den Müll zu werfen.

Am Pc kann es doch aber eigentlich nicht liegen, habe ja bereits einen Cube erfolgreich geflasht
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 09 November 2015, 11:07:32
Hallo,

mein Cube ist inzwischen auch angekommen. Nun wollte ich ihn auch neu flashen. Habe extra bei J1 Pfosten eingelötet und eine Brücke gesteckt. Dann kurz mit USB verbunden, bis zum ersten kurzen Blinken. Danach Brücke entfernt und USB wieder verbunden (mit dem mitgelieferten Kabel).

Habe den Gerätemanager offen aber es wird kein neues Gerät erkannt.

Die Powerled blinkt 10 mal kurz und leuchtet dann konstant.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 November 2015, 12:24:09
Wenn ich einen Flash erase an meinem Cube mache blinkt und leuchtet danach gar nichts mehr. Wenn die Power Led immer noch blinkt und leuchtet, dann ist der Flash nicht gelöscht. Probier mal aus, ob sich über Netzwerk immernoch die MAX Firmware meldet.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 09 November 2015, 12:42:00
Das Problem mit dem Lan ist, dass die IP 192.168.0.222 aufgedruckt ist. Also müsste ich wohl oder übel den Cube mit einem crossover Kabel anschliessen un den PC netzwerkmässig kurz in diese Range heben.

Wie kann ich dann feststellen wie sich der Cube meldet ?

Edit:  ok, wahrscheinlich mit der PC Software  ::)
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 09:34:44
Die Brücke war anscheinend nicht ok. Jetzt blinkt nichts mehr. Am Windowssystem wird auch ein neues Gerät erkannt und nach der Treiberinstallation als AT91 USB to Serial Converter (COM 3) angezeigt. Wenn ich nun SAM-BA 2.15 starte und den COM 3 sowie den at91sam7s128-ek eintrage und mich verbinde kommt:

Can´t connect atsam7s128-ek - Invalid chip ID

und nun  :-[

Auch bei mir ist der Chip der AT91SAM7X256 AU
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 November 2015, 10:14:47
Falsches Board. Nimm at91sam7x256-ek.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 11:17:46
ok, jetzt verbindet er sich. Ist die folgende Ausgabe ok ?

(sam-ba_2.15) 1 % send_file {Flash} "C:/Cube/bootloader/bootloader_CUBE.bin" 0x100000 0
-I- Send File C:/Cube/bootloader/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.15) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.15) 1 %

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 November 2015, 11:34:19
Sieht nicht schlecht aus. Blinkt D1 auf dem Cube jetzt schnell?
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 11:44:04
Ja, sie blinkt schnell, aber der installierte COM3 ist aus dem Gerätemanager verschwunden. Angezeigt wird nun beim Gerätemanager nur bei andere Geräte ein Cubeloader über den ich mich mit Terra Term natürlich nicht verbinden kann.

und nun  ???
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 November 2015, 11:57:30
Weise dem Cubeloader aus anderen Geräten manuell den Treiber aus dem SAM-BA Installationsverzeichniss zu.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 12:02:12
Das habe ich natürlich schon probiert aber er meint, dass er die Treibersoftware für das Gerät in dem amtel drv Verzeichnis nicht finden kann
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 November 2015, 12:09:09
Hast du es auch wirklich auf die ganz Manuelle weise probiert, also Manuelle Auswahl, Treiber aus Liste auswählen und dann auf Datenträger den Treiber im Verzeichnis auswählen?
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 12:28:42
Natürlich, ich habe es auch über Legacy Hardware versucht. Keine der Vorgehensweisen brachte Erfolg
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 November 2015, 12:52:18
Dann probier mal den atm6124 USB CDC signed driver for Windows (http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx) von der Atmel Seite.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 13:12:18
Auch der funktioniert nicht
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 November 2015, 19:55:18
Ich habe das jetzt unter Linux geflasht. Nun blinkt die Powerled langsam und die Batterieled konstant. Ist das korrekt so ?

minit meinte dass die Datei nicht komplett übertragen würde.

Aus den einzelnen Beiträgen entnehme ich, dass die Netzwerkfunktion wieder komplett arbeitet, richtig ?

IP wird per DHCP gezogen ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 November 2015, 20:33:43
Ich habe das jetzt unter Linux geflasht. Nun blinkt die Powerled langsam und die Batterieled konstant. Ist das korrekt so ?
Das langsame blinken der Powerled signalisiert, dass die a-culfw läuft. Die Batterieled leuchtet, wenn das Netzwerk verbunden ist.

minit meinte dass die Datei nicht komplett übertragen würde.
Das kann daran liegen, dass das ACK für das letzte übertragene Paket nicht mehr ankommt, weil der Cube bereits einen Reset nach dem Flashen ausgeführt hat.

Aus den einzelnen Beiträgen entnehme ich, dass die Netzwerkfunktion wieder komplett arbeitet, richtig ?
Es gab zumindest es seit der letzten Änderung keine Meldungen über disconnects mehr.

IP wird per DHCP gezogen ?
Per Defaulteinstellung ist DHCP aktiviert.
Titel: Antw:culfw@ARM
Beitrag von: GregPac am 16 November 2015, 10:41:17
So, ich wollte mich mal für die Arbeit von euch nd die gute Anleitung bedanken. Ich habe meinen Cube am Sa. innerhalb von 15 min am laufen gehabt.
Derzeit betreibe ich Ihn über einen VPN Tunnel und es läuft Top.

Ist es richtig das ich derzeit beim Mode MAX kein Pairing machen kann? Beim Versuch wird mir angezeigt das pairing im Mode Max nicht geht.

VG
Greg
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 16 November 2015, 11:30:44
Du musst auf das Subdevice z.B. CULMAX0 gehen und dort pairmode auswählen
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 16 November 2015, 11:45:00
Was bedeutet broadcastTime ?

In der Befehlsreferenz ist das nicht zu finden.
Titel: Antw:culfw@ARM
Beitrag von: GregPac am 18 November 2015, 15:45:39
Du musst auf das Subdevice z.B. CULMAX0 gehen und dort pairmode auswählen

Danke für den Tip, das war es natürlich was ich falsch gemacht habe.
Titel: Antw:culfw@ARM
Beitrag von: Shadow3561 am 26 November 2015, 18:01:56
@Telekatz

Moin, nachdem ich ja nun massive Probleme mit dem 2.Cube hätte kann ich jetzt Erfolg melden.
Habe den 2.Cube getauscht und konnte den neuen erfolgreich flashen.

Jetzt noch eine Frage nebenbei, auch wenn ich befürchte die Antwort schon zu kennen.

Ist es evtl. möglich mit dem Cube auch Lacrosse/TFA Temperatursensoren zu empfangen?

MfG
Titel: Antw:culfw@ARM
Beitrag von: scooty am 26 November 2015, 20:15:50
Habe meinen Cube mit aFW auf 433 MHz und SlowRF eingestellt und bevor ich mich versah wurden (mit autocreate an) meine 433MHz Temperatursensoren verschiedener "Standard"-Wetterstationen von FHEM erkannt und angelegt (als CUL_TCM97001 (http://fhem.de/commandref.html#CUL_TCM97001)). Empfang der Daten läuft wirklich zuverlässig.

List des MAXCUBES:
Internals:
   CMDS       BCFiAZEGMKLUYRTVWXefltx
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        192.168.0.155:2323 0000
   DeviceName 192.168.0.155:2323
   FD         14
   FHTID      0000
   MAXCUBE_MSGCNT 1407
   MAXCUBE_TIME 2015-11-26 20:05:51
   NAME       MAXCUBE
   NR         36
   PARTIAL
   RAWMSG     s62F01F60D5
   RSSI       -80.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CUBe (F-Band: 433MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
   Readings:
     2015-11-24 14:45:46   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2015-11-26 09:20:34   cmds             B C F i A Z E G M K L U Y R T V W X e f l t x
     2015-11-06 08:44:38   credit10ms      900
     2015-11-26 20:05:51   state           Initialized
     2015-11-16 14:21:08   uptime          0 01:37:56
     2015-11-24 18:45:11   version         V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CUBe (F-Band: 433MHz)
Attributes:
   addvaltrigger RSSI
   event-on-change-reading .*
   model      CUN
   rfmode     SlowRF

Echt tolle Sache, vielen Dank!
 :) :) :)

Andreas

PS:
Perfekt wäre noch eine aFW-/CUL_TCM97001-Einbindung der in diesem Thema (http://forum.fhem.de/index.php/topic,39451.0.html) beschriebenen preislich sehr interessanten Wetterstationen WH-1080/ WS-1080 (http://www.ebay.de/itm/Ersatz-Wettermast-fur-WH1080-Pass14c-/330832213045) / CTW600 (http://) .
 
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 November 2015, 18:45:59
Jetzt noch eine Frage nebenbei, auch wenn ich befürchte die Antwort schon zu kennen.

Ist es evtl. möglich mit dem Cube auch Lacrosse/TFA Temperatursensoren zu empfangen?
Meinst du dieses Protokoll?
http://forum.fhem.de/index.php/topic,36565.0.html (http://forum.fhem.de/index.php/topic,36565.0.html)
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 28 November 2015, 20:10:19
hi,

falls jemand wie ich mehrer CUBEs gleichzeitig am USB Port nutzen möchte, kann man in der Datei
a-culfw/culfw/at91lib/usb/device/cdc-serial/CDCDSerialDriverDescriptors.c individuelle USB-Id vergeben

Dazu im Bereich productStringDescriptor, ganz unten in der Datei, anpassen.

Nachfolgend ein Beispiel:
 
Zitat
/// Product string descriptor
const unsigned char productStringDescriptor[] = {

#if defined(bootloader_CUBE) ||defined(bootloader_HM_CFG)

   USBStringDescriptor_LENGTH(10),
   USBGenericDescriptor_STRING,
   USBStringDescriptor_UNICODE('C'),
   USBStringDescriptor_UNICODE('U'),
   USBStringDescriptor_UNICODE('B'),
   USBStringDescriptor_UNICODE('E'),
   USBStringDescriptor_UNICODE('L'),
   USBStringDescriptor_UNICODE('O'),
   USBStringDescriptor_UNICODE('A'),
   USBStringDescriptor_UNICODE('D'),
   USBStringDescriptor_UNICODE('E'),
   USBStringDescriptor_UNICODE('R')
#else
    USBStringDescriptor_LENGTH(15),
    USBGenericDescriptor_STRING,
    USBStringDescriptor_UNICODE('F'),
    USBStringDescriptor_UNICODE('H'),
    USBStringDescriptor_UNICODE('E'),
    USBStringDescriptor_UNICODE('M'),
    USBStringDescriptor_UNICODE('_'),
    USBStringDescriptor_UNICODE('C'),
    USBStringDescriptor_UNICODE('U'),
    USBStringDescriptor_UNICODE('B'),
    USBStringDescriptor_UNICODE('E'),
    USBStringDescriptor_UNICODE('_'),
    USBStringDescriptor_UNICODE('8'),
    USBStringDescriptor_UNICODE('6'),
    USBStringDescriptor_UNICODE('8'),
    USBStringDescriptor_UNICODE('_'),
    USBStringDescriptor_UNICODE(USB_DESCRIPTOR_SN)
#endif
};


Zitat
root@minibian:~# ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Nov 28 17:24 usb-03eb_AT91USBSerial1-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Nov 28 18:19 usb-03eb_FHEM_CUBE_888_1-if00 -> ../../ttyACM1


Danach einmal make clean && make und anschließend ganz normal flaschen

Grüße,
Stephan
Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 29 November 2015, 03:48:56
hm, ich habe nun meinen 2 ten hm-usb2 umgeflascht, und bekomme auch per putty mit v eine versionsrückmeldung. nur komischerweise bekommt fhem mit der default "define CUL CUL /dev/ttyAMA0@38400 0000" keine verbindung.
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 29 November 2015, 08:15:33
Hi,

Kannst du mal die Ausgabe von ls -l /dev/ttyACM* posten?
Und vllt noch ls -l /dev/serial/by-id/
Grüße Stephan

Gesendet von meinem SM-T335 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 29 November 2015, 11:41:14
jupp, das kann ich

root@FHEMrpi:/home/pi#  ls -l /dev/ttyACM*
crw-rw---T 1 root dialout 166, 0 Nov 29 03:17 /dev/ttyACM0

root@FHEMrpi:/home/pi#  ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Jan  1  1970 usb-03eb_AT91USBSerial1-if00 -> ../../ttyACM0

der raspi, ist ein neu aufgesetzter, mit wheezy und fhem ( stand gestern). und kernel 3.18.

edit:/
 FHEM hat nu selbst Ständig den eingebunden. ^^

define CUL_0 CUL /dev/ttyACM0@9600 1034

hm, warum das 1034 *kopfkratz*
List :
 
Internals:
   CFGFN
   CMDS       BCFiAZEGMKLUYRTVWXefltx
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         5
   FHTID      1034
   NAME       CUL_0
   NR         47
   PARTIAL
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CUL-HM-CFG (F-Band: 868MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
   Readings:
     2015-11-29 03:17:55   cmds             B C F i A Z E G M K L U Y R T V W X e f l t x
     2015-11-29 03:17:55   state           Initialized
Attributes
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 29 November 2015, 12:08:56
Hi,
super dann läuft es ja ;)
Nutzt du beide HM-CFG-USB an einem PI?

Die 1034 ist eine "Zufalls-ID" für FHT bzw. Homematic.

Grüße,
Stephan
Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 29 November 2015, 12:35:37
ich habe den einen jetzt an einer Testumgebung, auf der Haupt Box einem raspi 2b, nutze ich eine ccd2, einen mysensor Gateway, und einen nanocul auf 433 MHz, dazu noch eine Anbindung an den Stromzähler, mit dem volkszähler.org usb-ir lese schreibkopf.
das ganze per WLAN an eine Fritz.Box gekoppelt. der HM-CFG-USB wird denke ich mal den ccd2 ersetzen, der ccd2 kommt dann in meine Testumgebung, da ich den zurzeit eh nur als Basis für die homematic nutze und den Schirm da meist aus habe.
Titel: Antw:culfw@ARM
Beitrag von: Gator99 am 06 Dezember 2015, 15:55:49
Vielen Dank für die tolle Arbeit hier.
Zusätzlich zu meinem original Busware CUL läuft nun schon der erste MAX! Cube als CUN. Dieser Bedient den IT Bereich in 433.9 Mhz.

Der zweite Würfel liegt schon bereit und wird Wahrscheinlich im HM Modus arbeiten.

Eine Frage habe ich allerdings noch:
Gibt es einen technischen Grund warum die Würfel keinem WMBus Mode unterstützen, oder ist es nur in der Software nicht drin?
Könnte das Gut brauchen ;-)


Liebe Grüße
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Dezember 2015, 21:54:45
Eine Frage habe ich allerdings noch:
Gibt es einen technischen Grund warum die Würfel keinem WMBus Mode unterstützen, oder ist es nur in der Software nicht drin?
Könnte das Gut brauchen ;-)

Es hat halt bis jetzt noch niemand danach verlangt. Und selber brauche ich den Mode auch nicht. Aber ich werde ihn der nächsten Version aktivieren.
Titel: Antw:culfw@ARM
Beitrag von: Gator99 am 07 Dezember 2015, 11:45:43
 :D
*jubel* *jubel* *freu* *freu*

Besten Dank, sehr nett von dir.
Wenn du in der Nähe bist, sag bescheid. Ich zahle in Bier ;-)

Gruss
Titel: Antw:culfw@ARM
Beitrag von: Kharim am 07 Dezember 2015, 22:16:05
Hallo Zusammen,

um mal "ganz dumm" in die Runde zu fragen....wie kann ich die Firmware selbst kompilieren?
(Vorzugsweise im Windows)

(((Ich hab seit dem Umstieg des MAX!Cubes auf CUL und Fhem aktuell massive Credit Probleme und würde gern, zumindest für den Übergang das Limit erhöhen.)))

Danke,
Kharim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 Dezember 2015, 18:16:05
Es gibt einen neue Version in der jetzt auch Mbus, ZWave, LaCrosse/IT+ und Kopp-fc aktiviert ist.

....wie kann ich die Firmware selbst kompilieren?

- Toolchain aus dem ersten Beitrag herunterladen und installieren
- Sourcecode aus dem ersten Beitrag herunterladen
- Optional IDE (z.B. Eclipse) installieren
- Im Verzeichnis ...\culfw\Devices\CUBe "make CUBE_BL" ausführen

Titel: Antw:culfw@ARM
Beitrag von: Kharim am 09 Dezember 2015, 08:19:35
Dank dir,

nach Installation des Make-Tools und Anpassung der PATH Variable ist auch das nun geschafft *gg*
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 10 Dezember 2015, 07:20:17
Der Quellcode für die ARM Version ist jetzt in der a-culfw enthalten.

Noch ein Hinweis zur Hardware des HM-CFG-USB-2 und des MAX! Cube. Mir aufgefallen, dass bei diversen MAX und Homematic Geräten Funkmodule mit einem Si4431 anstelle eines CC1101 Chips verwendet werden. In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul. Die beiden HM-CFG-USB-2 Adapter die ich habe, haben einen CC1101 verbaut. Allerdings könnte es auch welche geben, die einen SI4431 haben. Bitte dies vor dem löschen der Originalfirmware kontrollieren.
Auf meinem Cube steht hingegen nur TRX868. Den habe ich allerdings auch schon seit 2012. Könnte hier bitte mal jemand der sich kürzlich einen Cube gekauft hat nachsehen, ob der Typ des Funkmoduls jetzt auch genauer angegeben ist?
Hi,
Auf meinem Cube steht auch nur TRX868.
Er ist auch schon älter. Geht es mit diesem?
Und nach Bootloader und fw (welche nehme ich genau) wie kann ich ihn zum CUN machen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 Dezember 2015, 17:20:19
Auf meinem Cube steht auch nur TRX868.
Er ist auch schon älter. Geht es mit diesem?
Ja, es geht mit dem.

Und nach Bootloader und fw (welche nehme ich genau) wie kann ich ihn zum CUN machen?
Du nimmst Bootloader und Firmware aus dem verlinkten Archiv im ersten Beitrag.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 10 Dezember 2015, 17:43:16
Ok und wie wird er cun?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 Dezember 2015, 18:12:52
Indem man das Netzwerkkabel ansteckt.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 12 Dezember 2015, 13:21:10
Hallo zusammen,

ich versuche mich auch gerade daran, meinen Cube zu flashen. Allerdings klappt das nicht so wie erwartet.
Das löschen der Original-Firmware scheint geklappt zu haben, im Gerätemaneger wurde mir ein neues unbekanntes Gerät gezeigt, das ich dann mittels des Treibers erfolgreich zu einem "AT91 USB to Serial Converter" machen konnte.
Wenn ich SAM-BA starte und COM7 sowie das Board at91sam7x256-ek wähle, schließt sich beim connecten SAM-BA ganz einfach und das war es. Wenn ich dann SAM-BA neu starte, erscheint die Meldung "Open a new SAM-BA Instance?". Anscheinend läuft das Programm also noch aber es passiert nix. Im Task-Manager finde ich keine verdächtigen Tasks.
Auf dem Cube steht TRX868-TI, nachdem was ich hier gelesen habe sollte es damit doch eigentlich klappen, oder?

LG,
petjek
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 12 Dezember 2015, 14:31:47
Ich komm nicht weiter

habe j1 verbunden und gelöst nach neu anschließen zeigt windows
bossa program port
nun kommt die frage
Ich habe einen atmel at91sam7x512. diesen wähle ich bei Samba aus (at91sam7x512-ek)
bei flash wähle ich die adress statt 0x100000 0x104000.
Welches File muss ich nun flashen?
und welches file muss ich dann mit teraterm flashen?
im CUBe Ordner liegt CUBE_BL.bin und da im bootloader liegt bootloader_CUBE.bin beides in a-culfw_1.20.01_build_176_master
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 12 Dezember 2015, 15:24:58
ich habe CUBE_BL.bin genommen und danach ging es schon sofort
nur weiß ich nicht wie ich dann maxmode definen muss
den cul habe ich auf port 2323 defined nur wie mache ich weiter?
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 12 Dezember 2015, 17:36:20
In fhem auf das Device gehen.  Und rfmode unten als Attribut setzen.  Da kannst du kann Homematic slowrf oder max wählen.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 12 Dezember 2015, 17:45:25
Danke auf max und geht. Bis aufs pairen. Da error.

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 13 Dezember 2015, 12:28:55
Hat keiner eine Idee was ich falsch mache? Kann das am Treiber liegen?
Titel: Antw:culfw@ARM
Beitrag von: Gator99 am 13 Dezember 2015, 13:37:10
Hey Petjek,
Um ganz sicher zu gehen, versuche doch mal einen kompletten Neuanfang in einer virtuellen Maschine.
Ich empfehle Linux, dort hast du erheblich weniger Ärger mit Treiber für Com und Co. Zusätzlich kannst du diese Installation bequem als Testumgebung für FHEM nutzen.

Für Anfänger ist Mint Linux gut geeignet.

Auch eine der vielen Linux Live CDs wäre vielleicht eine Möglichkeit.

Gruss
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 Dezember 2015, 20:18:12
Hallo petjek,
welches SAM-BA Version hast du verwendet? Und hast du SAM-BA als Administrator gestartet?
Titel: Antw:culfw@ARM
Beitrag von: petjek am 14 Dezember 2015, 07:40:32
Moin
SAM-BA 2.15 habe ich installiert. Und da ich als Administrator angemeldet war habe ich das doch auch als Administrator gestartet oder?

LG,
petjek
Titel: Antw:culfw@ARM
Beitrag von: MAC66666 am 14 Dezember 2015, 11:15:22
Hi alle,
ich hab jetzt alles zweimal durchgelesen, aber bei Klenigkeiten bin ich mir nicht 100%ig sicher:

Da ich FHEM nur in einer VM ohne USB-Ports habe: Nach dem Flashen an einem lokalen PC, ist da Ganze denn dann direkt Netzwerkfähig? Ging ja wohl am Anfang noch nicht, aber geht es inzwischen?

Ich kann dann mit FHT und FS20 kommunizieren? (Ja, mit MAX gleichzeitig geht's dann nicht mehr)...

Bin zwar blutiger FHEM Anfänger, aber für mich geht da jetzt kein Weg mer dran vorbei ;-)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 14 Dezember 2015, 17:03:35
@petjek
Verbinde den Cube mal mit einen Terminalprogramm und gib V# ein. Wenn der SAM-BA Bootloader läuft solle etwas in der Art "v1.4 Feb 02 2005 17:55:46" ausgegeben werden.

@MAC66666
Ja, der Cube ist Netzwerkfähig. FHT und FS20 geht damit natürlich auch.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 15 Dezember 2015, 23:13:34
Erstmal vielen Dank für die Firmware.  :)

Nachdem ich SAM-BA unter Windows 10 nicht zum Laufen gebracht habe, habe ich den Cube direkt am RasPi mit bossa und minicom geflashed. Soweit funktioniert auch alles, an USB wird der Cube als CUL erkannt.

Aber wie bekomme ich ihn jetzt ins Netz? Er hängt jetzt wieder direkt am Lan-Port des Routers, bekommt aber keine IP-Adresse.

Ein "list CUL0" ergibt:
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefltxz
   CUL0_MSGCNT 21
   CUL0_TIME  2015-12-15 23:10:10
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/ttyACM1@9600 0000
   DeviceName /dev/ttyACM1@9600
   FD         12
   FHTID      0000
   NAME       CUL0
   NR         131
   NR_CMD_LAST_H 2
   PARTIAL
   RAWMSG     Z0E80020206856102A8230001182F2822
   RSSI       -57
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za123456
Zw111111
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2015-12-15 23:01:21   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l t x z
     2015-12-15 23:10:10   state           Initialized
     2015-12-15 22:24:26   uptime          0 00:11:37
     2015-12-15 22:24:32   version         V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1450215554.14902
     1450215554.45074
Attributes:
   rfmode     MAX
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 15 Dezember 2015, 23:17:12
Ich vermute entweder LAN oder usb ? Leuchtet die LED?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 15 Dezember 2015, 23:20:38
Ich vermute entweder LAN oder usb ? Leuchtet die LED?

Ich habe es auch schon ohne USB-Verbindung zum Raspi probiert, ohne Erfolg.  :-\
Die LED für die Netzwerk-Verbindung leuchtet, sobald ich das LAN-Kabel anschließe.

Edit: Nach dem ich nach dieser Anleitung (http://culfw.de/commandref.html#cuno_setup) den Cube ohne DHCP eingerichtet hatte passierte erstmal wieder nix. Nach einem Factory Reset ist er jetzt im Netz.
Nachdem ich den Cube wieder vom Raspi getrennt und direkt ans Ladegerät gehängt habe verbindet er sich wieder nicht mit dem Router.  :-\
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 16 Dezember 2015, 18:38:58
So, ich habe jetzt alles probiert. Solange der Cube per USB am Pi hängt, bekommt er eine IP-Adresse und findet sich auch im Netzwerk. Ich komme mit screen direkt über USB und auch per telnet übers Netz auf Cube als CUNO. (BTW: Gibt's kein Kürzel zum Beenden der Verbindung?)

Sobald ich den Cube vom Pi trenne und nur über LAN mit dem Netz verbinde (USB-Kabel im Netzstecker) stellt er sich tot. Firmware ist die aktuellste Build 176 vom 07.12.

Mit der Originalfirmware gab es keine Netzwerkprobleme. Welchen Unterschied kann es geben zwischen USB-Kabel am Pi oder am Netzstecker?


Edit: Es läuft!  ;D

Ich habe am Pi jetzt die aktuellste Firmware von Github gezogen und selbst kompiliert. Auf den Cube aufgespielt, und siehe da, er meldet sich übers Netz, ohne am Pi zu hängen.
V 1.20.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
P.S.: Zum Kompilieren habe ich folgendes Makefile.local erstellt:
###############################################################

INCLUDEPATH = /usr/lib/arm-none-eabi/include
LIBPATH = /usr/lib/arm-none-eabi/lib
#ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-

######################## EOF ##################################

Dazu habe auf dem Pi noch binutils-arm-none-eabi und gcc-arm-none-eabi installiert.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 17 Dezember 2015, 13:44:19
@petjek
Verbinde den Cube mal mit einen Terminalprogramm und gib V# ein. Wenn der SAM-BA Bootloader läuft solle etwas in der Art "v1.4 Feb 02 2005 17:55:46" ausgegeben werden.
Terminalprogramm? Dazu muss ich ihn wieder ins LAN hängen, oder? Per USB wird das nicht gehen, woll?
Muss ich dann die IP-Range des Rechners auf die des Cubes anpassen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 17 Dezember 2015, 14:32:49
Terminalprogramm? Dazu muss ich ihn wieder ins LAN hängen, oder? Per USB wird das nicht gehen, woll?
Muss ich dann die IP-Range des Rechners auf die des Cubes anpassen?

Dein Problem war doch, dass SAM-BA unter Windows nicht lief. Das läuft über USB. Netzwerk geht ja erst, nachdem die Firmware geflasht wurde.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 17 Dezember 2015, 17:28:16
@Telekatz , Joachim hat ja in Antwort #49 die Pinbelegung des ST2 gepostet, ist diese serielle Schnittstelle am ST2 nur im Debugmodus aktiv oder sind die Ein/Ausgaben im laufenden Betrieb identisch mit denen am USB Port ?
Hintergrund : die vier Pins schreien direkt danach einen ESP8266-01 aufzustecken und den Cube damit zum Wireless Cube zu machen :)   
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 17 Dezember 2015, 17:50:43
Nein, am ST2 kommen auch im laufenden Betrieb Debugausgaben.

Man könnte den Datenverkehr vom USB Port aber auch an ST1 duplizieren. Dort ist auch eine serielle Schnittstelle mit der selben Pinbelegung wie auf ST2 vorhanden.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 17 Dezember 2015, 17:54:36
Dein Problem war doch, dass SAM-BA unter Windows nicht lief. Das läuft über USB. Netzwerk geht ja erst, nachdem die Firmware geflasht wurde.
So ich habe jetzt mal probiert, den Cube über Putty anzusprechen. Angeschlossen, COM7 als Port gewählt (im Gerätemanager taucht das Board als "AT91 USB to Serial Converter (COM7)" auf) und dann sagt Putty mir "Unable to open connection to COM7. Unable to open serial port."
Sollte ich mir sorgen um den Cube machen? Nebenbei, da leuchtet unter Strom derzeit keine einzige LED. Ist das korrekt so?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 17 Dezember 2015, 18:12:56
Damit die LEDs leuchten muss da erst eine passende Firmware drauf. Der SAM-BA Bootloader steuert die nicht an. Wenn du allerdings auch mit Putty keine Verbindung zu Cube bekommst, dann ist irgendwas nicht mit dem SAM-BA Bootloader nicht in Ordnung. Versuch nochmal einen Flash erase.

Woher hast du eigentlich den Treiber genommen, den du dem Unbekannten Gerät zugewiesen hast? Aus dem SAM-BA Verzeichnis?
Titel: Antw:culfw@ARM
Beitrag von: petjek am 18 Dezember 2015, 12:30:52
Hab ich gemacht. Leider kein Erfolg. Keine Reaktion auf Putty oder SAM-BA.

Den Treiber hab ich aus dem Verzeichnis C:\Program Files (x86)\Atmel\sam-ba_2.15\drv
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 18 Dezember 2015, 12:51:29
Kannst du nochmal zusammen fassen was du wie von wo genommen hast?kann ja nicht sein das so viele keine Probleme hatten. Das kriegen wir schon hin.

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 18 Dezember 2015, 13:06:46
Du meinst wie ich den Treiber installiert habe?
Ich habe mich als Administrator am Rechner angemeldet, Flash erase wie beschrieben durchgeführt und anschließend den Cube wieder verbunden. Im Gerätemanager tauchte dann ein unbekanntes Gerät auf. Dort habe ich über Rechtsklick den Treiber manuell installiert und dabei den aus dem o.g. Verzeichnis genommen.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 18 Dezember 2015, 13:11:50
welches OS hast du.
Ich wundere mich nur, da ich gar keine Treiber installieren mussen.
Flash per Jumper gelöscht.
Dann Kabel rann undper SAM-BA aktiv gewesen.
Alles tutti
Titel: Antw:culfw@ARM
Beitrag von: petjek am 18 Dezember 2015, 13:35:55
An OSsen habe ich die Wahl zwischen MacOS, Win7, Ubuntu und einen ungenutzten Raspberry Pi hätte ich auch noch. Probiert habe ich es aber bis jetzt nur unter Win7.
Per Jumper gelöscht? Wie und wo denn?
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 18 Dezember 2015, 13:49:06
Per Jumper gelöscht? Wie und wo denn?

wie im ersten Post beschrieben :
Bootloader (MAX! Cube):
  • Die Pins J1 auf dem Cube verbinden und die USB Verbindung kurz ein- und wieder ausstecken um die vorhandene Firmware zu löschen und den Flashspeicher zu entsperren.
    Achtung: Die original Firmware ist danach weg und kann auch nicht wiederhergestellt werden, da keine unverschlüsselte Version davon verfügbar ist!   
  • Verbindung  J1 lösen und USB Kabel wieder Verbinden. Im Gerätemanager sollte jetzt ein neuer COM Port erscheinen.

da J1 nur zwei Löcher sind kann man auch ne aufgebogene Büroklammer reinstecken ....
Titel: Antw:culfw@ARM
Beitrag von: petjek am 18 Dezember 2015, 14:02:44
Ach so. Ja klar. So hab ich das auch gemacht. Ich habe dazu ein Stück Kupferdraht genommen, den ich schräg abgeknipst habe, damit er in die beiden kleinen Löcher passt.
Jumper klang für mich so als gäbe es da noch irgendwo Pins die ich übersehen hätte auf die man einen Jumper stecken könnte.
Ich denke schon dass der Flash erase funktioniert hat. Seitdem sind die LEDs aus. Wäre da noch die Firmware drauf würde das doch anders aussehen, oder?
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 18 Dezember 2015, 14:27:43
Probier doch nochmal das löschen oder hast du schon?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 18 Dezember 2015, 14:43:31
Mehrfach.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 18 Dezember 2015, 14:45:43
Muss man unter Win 7 nen Treiber zwingend nehmen? Welchen Chip hast du drauf?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 18 Dezember 2015, 15:13:10
Nutzt hier noch jemand den Cube als CUN in Verbindung mit einem Speedport Hybrid der Telekom?

Nachdem der Cube jetzt 2 Tage im Netz erreichbar war ist er jetzt nach einem Neustart des Routers (und auch des Cube selbst) wieder weg.  ???

Ich habe so langsam den Verdacht, daß es vielleicht am Router liegen könnte, obwohl ich mir das nicht erklären kann. Andererseits macht es auch keinen Sinn, daß er sich im Netz anmeldet, wenn er per USB am Pi hängt.

Dummerweise hab ich keinen weiteren Cube oder CUL als Backup.

Edit: Wieder zur Diagnose an den Pi gehängt, angeblich hat er eine IP aus meinem Netz. Hier die Ausgaben nach factory reset (e) von V, Rid, Ria, Rig:
V 1.20.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
01
192.168.2.101
192.168.2.1
255.255.255.0
Trotzdem ist er über die 192.168.2.101 nicht erreichbar, dabei ist er gerade sogar wieder im Router sichtbar.

So langsam weiß ich keinen Rat mehr. Ethernet-Kabel habe ich bereits getauscht, statt an den Router an einen Powerlan-Adapter gehängt. Kein Ergebnis.  :-\
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 18 Dezember 2015, 16:49:17
Ich hab es gerade mal ausprobiert. Cube mit aktueller Firmware direkt am Speedport Hybrid angeschlossen, Stromversorgung über Nertzteil, IP Adresse über DHCP vom Speedport. Nach dem Neustart des Speedport war der Cube noch unter seiner IP Adresse erreichbar. Nach dem Neustart des Cube hat dieser vom Speedport eine neue IP Adresse bezogen. Nachdem die neue IP Adresse in FHEM geändert wurde war der Cube auch wieder erreichbar.

Auf dem Speedport selbst war in der "Übersicht der Geräte im Heimnetzwerk" immernoch die alte IP Adresse vorhanden. Nach dem anklicken von "Liste aktualisieren" war dann auch im Speedport die neue IP Adresse angegeben.

Noch etwas zum Thema Treiber. Dass manche keinen Treiber installieren mussten könnte daran liegen, dass die Arduino IDE installiert war. Mit der wird auch ein kompatibler Treiber installiert. Im Gerätemanager taucht der Cube dann als "Bossa Program Port" auf.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 18 Dezember 2015, 19:22:46
Nein habe die IDE nicht aber vllt hat Windows 10 das dabei. Genau hieß bei mir auch Bossa...

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Wzut am 18 Dezember 2015, 19:28:52
Nein, am ST2 kommen auch im laufenden Betrieb Debugausgaben.

Man könnte den Datenverkehr vom USB Port aber auch an ST1 duplizieren. Dort ist auch eine serielle Schnittstelle mit der selben Pinbelegung wie auf ST2 vorhanden.
hmm schade. Wie hoch schätzt du den Aufwand dafür ?
Beim ATmega328 ist das ganze Thema serielle Ausgabe mit vier Zeilen abgehandelt:
#define HAS_UART 1
#define UART_BAUD_RATE 38400
uart_init( UART_BAUD_SELECT_DOUBLE_SPEED(UART_BAUD_RATE,F_CPU) );
uart_task();
wenn ich aber sehe was du beim CUBe mit USART0, USART1 und USB da machst muss ich leider zugeben ist das ne Nummer zu groß für mich :(
Titel: Antw:culfw@ARM
Beitrag von: petjek am 20 Dezember 2015, 14:18:14
Muss man unter Win 7 nen Treiber zwingend nehmen? Welchen Chip hast du drauf?

Gesendet von meinem Huawei Honor 7
So ich habe es jetzt noch mal mit einer Win7-VM auf dem Mac versucht. Auch da musste ich den Treiber aus dem Programmverzeichnis manuell installieren. Leider führt das zu dem gleichen Ergebnis.
Ich würde es ja auch noch mal unter Linux probieren, wenn mir jemand sagen kann, wie das damit geht.
Der Chip ist ein AT91SAM7X256.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 20 Dezember 2015, 22:42:01
Versuch doch mal ne Win 10 vm

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 22 Dezember 2015, 08:17:19
Ich hab es gerade mal ausprobiert. Cube mit aktueller Firmware direkt am Speedport Hybrid angeschlossen, Stromversorgung über Nertzteil, IP Adresse über DHCP vom Speedport. Nach dem Neustart des Speedport war der Cube noch unter seiner IP Adresse erreichbar. Nach dem Neustart des Cube hat dieser vom Speedport eine neue IP Adresse bezogen. Nachdem die neue IP Adresse in FHEM geändert wurde war der Cube auch wieder erreichbar.

Auf dem Speedport selbst war in der "Übersicht der Geräte im Heimnetzwerk" immernoch die alte IP Adresse vorhanden. Nach dem anklicken von "Liste aktualisieren" war dann auch im Speedport die neue IP Adresse angegeben.

Vielen Dank fürs Testen!  :)
Zur Zeit ist der Cube auch wieder brav im Netz angemeldet. Aber so ganz stabil scheint das bei mir nicht zu sein. Also lasse ich ihn erstmal als CUL per USB am Pi.

Irgendwie scheine ich hier ein Montagsgerät erwischt zu haben.  :-\ Beschriftet ist er nur mit "TRX868" ohne weitere Kürzel, scheint also einer der ersten zu sein. Nachdem ich Sam-Ba unter Win10 nicht zum Laufen gebracht habe, war das Flashen nach einiger Recherche unter Linux auf dem Pi kein Problem. Ich komme auch per telnet oder screen drauf und kann die Netzwerkparameter auslesen. Es werden nach Umschalten auf rfmode MAX auch alle Geräte gefunden (7 HT, 1WT+, 3 SC). Ich habe also alle "gepaired" und bekomme auch den Status angezeigt.

Und dann fangen die Probleme an.  :(
[/list]2015.12.22 07:42:08 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 0f1d040312345600a8f1000f1607ea05
2015.12.22 07:43:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 64, but we need 121. Waiting 57 seconds.
2015.12.22 07:44:12 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 191e001012345600a8f1000240b44cfc40004520452045204520
2015.12.22 07:44:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 121. Waiting 117 seconds.
2015.12.22 07:46:16 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:48:16 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:50:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:52:14 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 191f001012345600a8f1000340b44cfc40004520452045204520
2015.12.22 07:52:14 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 121. Waiting 117 seconds.
2015.12.22 07:54:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:56:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:58:19 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 08:00:17 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 1920001012345600a8f1000440b44cfc40004520452045204520

Erneutes Pairing habe ich schon diverse Male probiert, ohne Erfolg. Hat irgendjemand noch nen guten Tipp, was ich noch probieren kann? Bzw. gibt es noch irgendwelche Debugging-Parameter zum mitloggen? "verbose 5" auf CUL und CUL_MAX zeigen nicht wirklich was an.
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 22 Dezember 2015, 08:44:04
Hi,

eine Möglichkeit zum Auslesen der Verbindung wäre traumhaft... gib es aber meines Wissens nach nciht....

Die meisten Thermostate lassen sich weder manuell noch per FHEM auf auto schalten.Wenn Kein wochenprogramm hinterlegt ist kannst du auch nicht auf Auto schalten, weder mit FHEM noch am Thermostat

ich bekomme keine neuen Wochenprogramme auf die Thermostate. Der Versuch scheitert regelmäßig mit zu wenigen Credits und "missing ack":Das Übertragen den Wochenprogramme frisst credits ohne ende.... mit etwas "krimineller Energie" könntest du das maximale creditlimit deines CUBe erhöhn, dazu einfach  die datei rf_send.h modifizieren und anstatt 900 z.B. 3600 eintragen.
Achtung: Dadurch überschreitest du ggf. die maximale Sendezeit pro Stunde (1% Regel ...)

Danach neu compilieren und neu flashen.

Grüße,
Stephan



Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 22 Dezember 2015, 08:52:58
Missing ack deutet doch auf nicht gepairt oder?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 22 Dezember 2015, 09:23:34
Hi,

eine Möglichkeit zum Auslesen der Verbindung wäre traumhaft... gib es aber meines Wissens nach nciht....
Schade! Im Wohnzimmer habe ich z.B. 2 Thermostate, 1 Fensterkontakt und 1 Wandthermostat. Da wäre es super, wenn ich sehen könnte, ob alle associates untereinander funktioniert haben.

Zitat von: CaptainHook
Die meisten Thermostate lassen sich weder manuell noch per FHEM auf auto schalten.Wenn Kein wochenprogramm hinterlegt ist kannst du auch nicht auf Auto schalten, weder mit FHEM noch am Thermostat
In den Readings wird mir ein Wochenprofil angezeigt, also müsste ich doch eigentlich darauf umschalten können.

Zitat von: CaptainHook
ich bekomme keine neuen Wochenprogramme auf die Thermostate. Der Versuch scheitert regelmäßig mit zu wenigen Credits und "missing ack":Das Übertragen den Wochenprogramme frisst credits ohne ende.... mit etwas "krimineller Energie" könntest du das maximale creditlimit deines CUBe erhöhn, dazu einfach  die datei rf_send.h modifizieren und anstatt 900 z.B. 3600 eintragen.
Achtung: Dadurch überschreitest du ggf. die maximale Sendezeit pro Stunde (1% Regel ...)

Danach neu compilieren und neu flashen.
Dann werde ich das mal zumindest testweise ändern, um zu sehen, ob es daran liegt. Mit der Original-Firmware vom Cube hatte ich eigentlich keine Probleme.

Missing ack deutet doch auf nicht gepairt oder?
Das dachte ich eigentlich auch, aber der Versuch, erneut zu pairen, brachte auch nichts. pairmode auf 2 Minuten, Thermostat auf Pairing stellen, dann laufen die 30 Sekunden ab ohne Reaktion.  :-\
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 22 Dezember 2015, 09:30:54
Ich musste meine HT resetten dann ging es korrekt. Das mit dem woxhenplan hatte ich auch. Ich habe dann per Handy App einfach einen gesetzt und dann wurde der auch in den readings angezeigt.

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 22 Dezember 2015, 10:22:38
So, a-culfw mit creditlimit 3600 neu kompiliert und aufgespielt. Pairing ging jetzt auch bei 2 Geräten, auch ohne erneuten Reset.

Aber irgendetwas scheint hier Credits zu fressen ohne Ende:
2015.12.22 10:10:44 3: CUL_MAX_Parse: Pairing device 007fed of type HeatingThermostat with serial IEQ0195899
2015.12.22 10:11:42 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 109, but we need 110. Waiting 1 seconds.
2015.12.22 10:14:29 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 57, but we need 110. Waiting 53 seconds.
2015.12.22 10:15:28 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 110. Waiting 103 seconds.
2015.12.22 10:17:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 110. Waiting 103 seconds.

Zwischen dem Pairing und den "Not enough credit"-Warnungen habe ich nur versucht, an einem Thermostat per fhem die Temperatur zu ändern, um zu sehen, ob es wieder einen "missing ack" gibt.

Seit dem Aufspielen der neuen Firmware habe ich also nur an 2 Thermostaten die Temperatur geändert, nach "missing ack" die beiden gepairt und das ganze an einem dritten Thermostat versucht. Das darf doch noch nicht sämtliche Credits verbrauchen, oder?
Titel: Antw:culfw@ARM
Beitrag von: petjek am 22 Dezember 2015, 18:17:58

Nachdem ich Sam-Ba unter Win10 nicht zum Laufen gebracht habe, war das Flashen nach einiger Recherche unter Linux auf dem Pi kein Problem.
Darf ich fragen wo du das recherchiert hast? Ich komme mit Win7 nicht weiter, Win10 ist keine Option. Ich hätte aber eine Ubuntu-VM und einen weiteren Raspi zur Verfügung.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 22 Dezember 2015, 21:49:39
Ich habe ne Weile gegoogelt, welche Alternativen zu Sam-Ba es gibt. Dabei bin ich auf BOSSA (http://www.shumatech.com/web/products/bossa) gestoßen. Gibt es auch als Paket für Ubuntu oder Debian bzw. Raspbian:
bossa - Atmel SAM ARM microcontroller flash programming GUI
bossa-cli - Atmel SAM ARM microcontroller flash programming utility
Die GUI habe ich nicht getestet. Ich habe im terminal einfach die BOSSA Shell (bossash) aufgerufen. Sollte dann in etwa so aussehen:
$ bossash
Press Ctrl-D or enter "exit" to end session.
Enter "help" to display a command list.
bossa>
Dann einfach mit "scan" nach dem CUBe suchen. Dabei sollte er automatisch verbunden werden. Dann mit "write bootloader_CUBE.bin" den Bootloader schreiben.  Dann "bootf true" und der CUBe bootet neu in den Bootloader. Danach kannst Du mit einem Terminalprogramm (z.B. minicom) die Firmware auf den CUBe bringen.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 24 Dezember 2015, 07:32:24
Danke fuer die Infos.
Allerdings bekomme ich auch unter Ubuntu mit Bossa keine Verbindung zum Board. Bossa findet beim Scan kein Geraet.
Ich habe so langsam den Verdacht, dass das Board hin ist. Wodurch auch immer.  :(
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 24 Dezember 2015, 08:25:55
Hi,
Du machst das ganze in einer VM? Bist du sicher das der Port auch richtig durchgereicht wird?
Als weitere Möglichkeit könntest du ein Linux Live System von DVD booten und es damit versuchen... 

Gesendet von meinem A0001 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: petjek am 24 Dezember 2015, 12:15:41
Ich habe das an einem Windows-Laptop mit Windows 7 probiert, an einem Mac mit Windows-VM und am selben Mac mit einer Ubuntu-VM. Die Windows-VM erkennt das USB-Gerät, wenn ich es anschließe, daher vermute ich, dass es auch in der Ubuntu-VM so wäre. Wie auch immer, es ist jedes mal das gleiche Ergebnis, nämlich keines. Ich könnte es jetzt noch nativ am Mac mit Bossa probieren, da habe ich aber Probleme, die Dateien aus der .dmg nach /usr/bin zu verschieben. Keine Berechtigung.
Der Flash erase ist ja eine ziemlich einfache Sache, daher vermute ich, dass ich da nichts falsch gemacht habe. Aber allem Anschein nach habe ich jetzt hier einen kleine quadratischen Schrotthaufen produziert, wie auch immer ich das geschafft habe.
 :(
Naja, ist ja Weihnachten, da kann ich mir ja noch schnell einen CUNX wünschen.   ::)
Ach ja: Fröhliche Weihnachten allen hier! ;)

Titel: Antw:culfw@ARM
Beitrag von: Ralle am 24 Dezember 2015, 15:06:20
Hallo zusammen,
fange erst gerade mit FHEM an und der Groschen ist leider noch nicht gefallen.
Bin auch kein Entwickler und komme mit der techn. Beschreibung zu diesem Thema nicht immer ganz mit.
Habe aber einen MAX Cube von einem Freund geschenkt bekommen, allerdings ohne Aktoren und frage mich was ich am Ende mit dem Ding machen kann wenn ich ihn flashe?

Ist das dann ein Gerät (von der Funktion her) ähnlich einem Busware CUL? (CUL ist ja lokal am USB Port und CUN wäre die Netzwerkversion, soviel habe ich schon begriffen)
Welche Protokolle (Geräte) kann ich denn damit zur Zeit ansprechen ?
Unter http://www.meintechblog.de/2015/02/fhem-welches-gateway-fuer-welches-system/ (http://www.meintechblog.de/2015/02/fhem-welches-gateway-fuer-welches-system/) gibt es ja eine brauchbare Auflistung was mit einem Busware CUL alles geht.
Da ich auch schon einzelne Komponenten z.B. aus der FS 20 Serien besitze würde ich gerne den MAX flashen wenn ich ihn am Ende dafür gebrauchen kann?
433 MHz Steckdosen gehören ebenfalls schon zu meiner Sammlung, die ich zur Zeit über einen eigenen Sender über GPIO schalte.
Könnte man die MAX Aktoren nach dem flashen noch ansprechen?
Und was passiert wenn beim flashen was schiefgeht, ist der Cube dann für die Tonne?

Vielen Dank für Eure Antworten
Titel: Antw:culfw@ARM
Beitrag von: petjek am 24 Dezember 2015, 16:25:13
Und was passiert wenn beim flashen was schiefgeht, ist der Cube dann für die Tonne?
Anscheinend kann da was schiefgehen. Mein Cube gibt auf jeden Fall keinen Mucks mehr von sich. Aber ich scheine wohl ein Einzelfall zu sein.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 24 Dezember 2015, 16:31:55
Was passiert denn genau?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 24 Dezember 2015, 16:46:19
Na eben nichts (mehr)!
Ich habe inzwischen gefühlte 98 mal einen Flash erase durchgeführt.
Also J1 mit einem Kupferdraht gebrückt, USB angeschlossen, 5 sek gewartet, Kabel wieder ab, Brücke raus, Kabel wieder dran. Anschließend zeigt Windows 7 ein unbekanntes Gerät, dass ich mit den Treibern aus dem SAM-BA- Programmverzeichnis versehen habe. SAM-BA macht nach Auswahl des Ports und des Chips die Biege, zumindest die GUI verschwindet einfach. Im Hintergrund scheint noch was zu laufen, da ich beim erneuten Start von SAM-BA gefragt werde, ob ich eine weitere Instanz öffnen will.
Das gleiche Verhalten habe ich unter einer Windows-VM am Mac reproduzieren können.
Unter Ubuntu (VM) hab ich's mit Bossa versucht, das findet beim Scan kein Gerät.
Unter MacOS bekomme ich Bossa nicht ans Laufen, da mangelt es einerseits an den Rechten, die erforderlichen Programme nach /usr/bin zu verschieben und mir an der Fähigkeit, dass im Terminal mit den erforderlichen Rechten auszuführen.
Alles in Allem sehr ärgerlich aber so langsam gebe ich auf.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 24 Dezember 2015, 17:33:14
Kannst du mir auch per Post schicken mit Rückporto dann schau ich mal oder der Ersteller des threads vllt auch?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Dezember 2015, 17:38:18
Du könntest es noch über die die Debugschnittstelle an ST2 probieren, falls du einen Seriellen Wandler mit TTL Pegel hast. Damit könnte man dann den USB Treiber als Fehlerquelle ausschließen. Oder falls vorhanden mit einem JTAG Interface.

Auf einen Raspberry hab ich es gerade mit Bossa auch noch probiert. Hat funktioniert

Ist das dann ein Gerät (von der Funktion her) ähnlich einem Busware CUL? (CUL ist ja lokal am USB Port und CUN wäre die Netzwerkversion, soviel habe ich schon begriffen)
Da die selbe Firmware wie auf dem CUL läuft, hat er die selben Funktionen wie ein CUL.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 25 Dezember 2015, 08:00:22

Du könntest es noch über die die Debugschnittstelle an ST2 probieren, falls du einen Seriellen Wandler mit TTL Pegel hast. Damit könnte man dann den USB Treiber als Fehlerquelle ausschließen. Oder falls vorhanden mit einem JTAG Interface.
Ähm, also... wah?
Mal ernsthaft, Telekatz, könnte man aus meinen bisherigen Posts ableiten, dass ich sowas haben könnte?
Ich weiß noch nicht mal ob es sich dabei um Krankheiten, Grillzubehör oder Geheimdienstslang handelt. James Bond habe ich sowas auf jeden Fall noch nicht sagen hören.

Titel: Antw:culfw@ARM
Beitrag von: Wzut am 25 Dezember 2015, 15:05:04
@petjek, wenn ich deinen Leidensweg bis jetzt richtig gelesen habe hast du entweder unter Windoof oder innerhalb einer VM gearbeitet.
Mal ganz banal : Hast du schon mal das USB Kabel gewechselt ?
Dann schreibst du mehrfach das du auch einen Rpi besitzt, hast den aber noch nie mit dem Cube verbunden und ganz primitiv versucht mit einem Term Prg anzusprechen ( putty / minicom /miniterm )  ?
Das das kleine SAM-BA Fenster beim connect verschwindet ist normal.  Es bleibt verschwunden bis erfolgreich der Connect zum Cube durchgeführt wurde und kommt dann wieder als großes Fenster, dauert bei meiner alten Hardware  so ca. 1 Sekunde.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 25 Dezember 2015, 15:27:39
Das mit dem USB Kabel ist ja nicht so einfach. Bei mir zumindest ist das ein Mini-USB Kabel und davon besitze ich genau eines. Den RPi kann ich natürlich auch noch testen.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 25 Dezember 2015, 16:46:54
Super Idee wzut

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Wzut am 25 Dezember 2015, 17:36:04
Mensch petjek, nun sei doch mal ein bissel kreativ ... es ist Weihnachten die Geschäfte sind zwar zu aber deine Nachbarn sitzen zu Hause und warten nur darauf das du klingelst und Sie bittest dir mal kurz das Kabel auszuleihen mit dem sie ihr Smartphone laden :)
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 25 Dezember 2015, 17:43:19
Ne cube ist doch Mini und nicht micro usb oder

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 25 Dezember 2015, 18:04:00
Ja ebent!
Titel: Antw:culfw@ARM
Beitrag von: petjek am 26 Dezember 2015, 09:59:43
@petjek, wenn ich deinen Leidensweg bis jetzt richtig gelesen habe hast du entweder unter Windoof oder innerhalb einer VM gearbeitet.
Mal ganz banal : Hast du schon mal das USB Kabel gewechselt ?
Ja, habe gerade eines gefunden. Funktioniert ebenfalls nicht.
Dann schreibst du mehrfach das du auch einen Rpi besitzt, hast den aber noch nie mit dem Cube verbunden und ganz primitiv versucht mit einem Term Prg anzusprechen ( putty / minicom /miniterm )  ?
Und das macht man dann wie? Putty kenne ich nur unter Windows. Damit habe ich es auch schon versucht, ebenfalls ohne Erfolg. Auch mit dem zweiten Kabel. minicom und miniterm kenne ich nicht. Muss man das erst installieren? Und wenn ja wie? Und was macht man dann?
Ich kann verstehen, dass man in diesem Forum von einem gewissen Grund-Know-how ausgeht. Da scheint mir aber noch einiges zu fehlen, sorry.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 Dezember 2015, 10:45:33
Kannst du mal im Gerätemanager nachsehen, mit welcher VID und PID sich der Cube meldet.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 26 Dezember 2015, 11:35:41
Wenn ich das richtig lese ist VID 03EB und PID 6124.
Ich glaube durch meine Probiererei habe ich jetzt einiges strubbelig gemacht. Wenn ich den Cube an dem vorderen der beiden seitlichen USB-Ports anschließe wird er als AT91 USB to Serial Converter (COM7) erkannt, benutze ich den USB-Port daneben ist es ein BOSS Programm Port (COM8). So oder so sagt Bossa mir aber
Could not connect to device on COM7 //bzw. COM8//beim Versuch zu verbinden.

Titel: Antw:culfw@ARM
Beitrag von: Wzut am 26 Dezember 2015, 14:04:09
Muss man das erst installieren? Und wenn ja wie? Und was macht man dann?
ja , muß man :) , putty gibt es auch für Linux und hat halt den Charme ausser ein ssh Client zu sein auch Verbindungen zu seriellen Ports herzustellen zu könen und das via Klicki-Bunti (wenn man den Rpi X Desktop nutzt) , wird installiert mit
sudo apt-get install putty
minicom ist gut wenn auf der Konsole arbeitet, Installation mit 
sudo apt-get install minicom
Hilfe mit minicom --h
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 27 Dezember 2015, 12:24:42
Ich würde den Cube mal an den Pi anschließen und bossa installieren. (sudo apt-get install bossa-cli) Dann bossash starten und scan eingeben. Dann sollte der Cube gefunden werden. Eventuell mal mit dmesg anzeigen lassen, ob der Cube überhaupt erkannt wurde. Sollte an /dev/ttyACMx als Cubeloader erkannt werden. Sollte dann so aussehen:
[Di Dez 22 09:58:23 2015] usb 1-1.3: new full-speed USB device number 78 using dwc_otg
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=6119
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Di Dez 22 09:58:23 2015] usb 1-1.3: Product: CUBELOADER
[Di Dez 22 09:58:23 2015] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Titel: Antw:culfw@ARM
Beitrag von: petjek am 27 Dezember 2015, 14:46:52
Ok. Probiere ich aus wenn ich wieder in der Heimat bin. ;)
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 28 Dezember 2015, 18:50:12
Hallo zusammen,

Bin absoluter fhem Neuling und bin beim Beschaffen der Komponenten über das culfw@arm gestolpert. Zum Glück! :-) Vielen Dank an Telekatz für die tolle Arbeit. Ich habe den Max Cube auch erfolgreich flashen können und als cul über USB eingebunden. Nach und nach möchte ich gerne drei weitere CUBEs einsetzen, u.a. für 433 MHz und FS20. Wenn ich richtig verstanden habe, muss ich bei USB selbst kompilieren wg. GeräteID. Gilt das auch für den Anschluss als CUN? Wäre es evtl. möglich im nächsten Build weitere Firmware Dateien anzuhängen für diesen Zweck? Wäre echt super, traue mich noch nicht so recht an Toolchain ran um selbst zu kompilieren :-(

falls jemand wie ich mehrer CUBEs gleichzeitig am USB Port nutzen möchte, kann man in der Datei
a-culfw/culfw/at91lib/usb/device/cdc-serial/CDCDSerialDriverDescriptors.c individuelle USB-Id vergeben
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 28 Dezember 2015, 19:20:57
möchte ich gerne drei weitere CUBEs einsetzen, u.a. für 433 MHz und FS20.
sorry , aber das würde ich nicht machen,
a. weil der Cube für 868MHz ausgelegt ist
b. seine Stärken darin liegen ihn via LAN einzusetzen
für 433 und FS20 via USB gibt es wesentlich preiswertere  Alternativen ->  http://forum.fhem.de/index.php/topic,17022.0.html oder für knapp 10€ selber bauen
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 28 Dezember 2015, 20:12:34

sorry , aber das würde ich nicht machen,
a. weil der Cube für 868MHz ausgelegt ist
b. seine Stärken darin liegen ihn via LAN einzusetzen
für 433 und FS20 via USB gibt es wesentlich preiswertere  Alternativen ->  http://forum.fhem.de/index.php/topic,17022.0.html oder für knapp 10€ selber bauen

Hallo Wzut. Danke für den Link zu den alternativen CULs und den Hinweis, dass der Cube dafür weniger zu empfehlen ist. Für 433 hatte ich auch hinsichtlich Reichweite erst etwas anderes nehmen wollen, zumindest in der Bucht gehen die fertigen Selbstbauten für meist über 35 Euronen weg. Den MAX Cube kriegt man effektiv doch  günstiger. Ich schaue mir die Variante als CUN aber auf jeden Fall mal an. Ich bin bisher davon ausgegangen, sie nicht über mehrere Etagen verteilen zu müssen (spielt sich fast alles im EG ab, was eingebunden werden soll) und wollte mir einen zusätzlichen Switch sparen. Hoffe ich bin nicht schon zu Offtopic geworden...
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 28 Dezember 2015, 22:30:24
Mir sind jetzt auch zwei zusätzliche Cubes in die Hände gefallen und überlege jetzt einen als Cuno für 433MHz zu nutzen.
Bevor ich jetzt die Firmware lösche....
Wenn ich den kleinen Antennen Draht durch einen in der Länge von 17cm ersetze, sollte das doch gut funktionieren?
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 28 Dezember 2015, 22:36:45
Hi,
Dadurch passt die Abstimmung trotzdem nicht...  Wenn dann müsstest du das Funkmodul tauschen. Sprich das original auslöten und ein 433-Modul einlöten.. 

Gesendet von meinem A0001 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 28 Dezember 2015, 22:40:05
Ok schade, dann werde ich nur einen für Homematic nehmen und den zweiten evtl. auf Reserve.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 29 Dezember 2015, 08:36:24
Hallo Leute.
Ich habe momentan Dank euch 2 Cubes erfolgreich mit der neuesten aculfw geflasht und in Betrieb.  1 für. Max + IT schalten und einen für. 433mhz senden und empfangen.  Nun möchte ich an den Cubes gerne eine SMA Buchse anlöten um eine anständige Antenne dran machen zu können.

Nun zu meinem Problem. Ich weiß zwar welchen Pin ich an die Buchse löten muss, nur wo soll ich die Masse(Schirm) der SMA Buchse anlöten?

Vom Mobiltelefon gesendet.

Titel: Antw:culfw@ARM
Beitrag von: Ralle am 29 Dezember 2015, 13:52:55
Hallo zusammen,
stehe im Moment auf den Schlauch und komme einfach nicht weiter(Newbie)
Habe mit den MAX Cube erfolgreich geflasht und er ist nun auch im Netzwerk anzupingen.

Nun muss ich ja die Konfiguration in FHEM erstellen.
Meine Ersten Versuche mit define MAX_Lan <|IP> funktionieren ja nun nicht mehr.
Wie bekomme ich den CUL der ja jetzt ein CUN ist in die Konfig eingebunden ?
Define name CUL <adresse> ist ja keine IP möglich.
Define CUN gibt es nicht ?



Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 29 Dezember 2015, 14:09:10
define maxcube CUL 192.168.0.123:2323 0000
attr maxcube rfmode MAX
attr maxcube room CUL
define cmax CUL_MAX 654321
attr cmax IODev maxcube

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Ralle am 29 Dezember 2015, 14:29:36
define maxcube CUL 192.168.0.123:2323 0000
attr maxcube rfmode MAX
attr maxcube room CUL
define cmax CUL_MAX 654321
attr cmax IODev maxcube

Gesendet von meinem Huawei Honor 7

Danke, das ist die Info die mir gefehlt hat  :)
Titel: Antw:culfw@ARM
Beitrag von: petjek am 30 Dezember 2015, 16:15:54
Ich würde den Cube mal an den Pi anschließen und bossa installieren. (sudo apt-get install bossa-cli)
So, wieder zuhause und gleich mal ausprobiert.

sudo apt-get install bossa-cli liefert folgendes Ergebnis:

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden gelesen.... Fertig
E: Paket bossa-cli kann nicht gefunden werden.

Muss ich da noch irgendwas an Quellen hinzufügen? Und wenn ja, wie?
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 30 Dezember 2015, 16:23:10
Vorher sudo apt-get update

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 30 Dezember 2015, 16:24:44
Das hab ich wohl gemacht!
Titel: Antw:culfw@ARM
Beitrag von: petjek am 30 Dezember 2015, 16:36:42
Eventuell mal mit dmesg anzeigen lassen, ob der Cube überhaupt erkannt wurde. Sollte an /dev/ttyACMx als Cubeloader erkannt werden. Sollte dann so aussehen:
[Di Dez 22 09:58:23 2015] usb 1-1.3: new full-speed USB device number 78 using dwc_otg
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=6119
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Di Dez 22 09:58:23 2015] usb 1-1.3: Product: CUBELOADER
[Di Dez 22 09:58:23 2015] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device

So sieht es leider nicht aus sondern so:
[1233.192024] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[1233.295001] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6124
[1233.295043] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1233.374988] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

:(
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 30 Dezember 2015, 18:32:36
Als Cubeloader wird er erst erkannt, wenn der Bootloader aufgespielt wurde. Der SAM-BA Bootloader meldet sich so:
[ 1276.790543] usb 1-1.2: new full-speed USB device number 20 using dwc_otg
[ 1276.893472] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6124
[ 1276.893512] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1276.972259] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device

Bossa mit sudo apt-get install bossa-cli installieren funktioniert bei mir auch nicht. Aber man kann Bossa auch selber bauen:
cd /usr/src
sudo git clone git://git.code.sf.net/p/b-o-s-s-a/code b-o-s-s-a-code
sudo apt-get install libreadline-dev wx2.8-headers libwxgtk2.8-0 libwxgtk2.8-dev
cd b-o-s-s-a-code
sudo make bin/bossash

#Starten
/usr/src/b-o-s-s-a-code/bin/bossash
Titel: Antw:culfw@ARM
Beitrag von: petjek am 31 Dezember 2015, 13:27:47
Soweit scheint das jetzt zu klappen. Bossa habe ich erfolgreich selbst gebaut und konnte mit
bossa> scan
Checking port ttyACM0...
Device found on ttyACM0
bossa> connect ttyACM0
Connected to device on ttyACM0
bossa> write /home/pi/Desktop/bootloader_CUBE.bin
Write 196 bytes to flash
[==============================] 100% (1/1 pages)
bossa> bootf true
Boot to flash flag set to true
bossa>
den Bootloader installieren. Einen reboot hat er aber nicht gemacht. Auch den connect musste ich manuell durchführen.
Also habe ich ihn vom USB angezogen und wieder angeschlossen.
Sollte dann nicht wie im ersten Beitrag geschrieben die LED D1 schnell blinken? Tut sie nicht. Auch nachdem ich den Resetbutton gedruckt habe beim Anschließen.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 31 Dezember 2015, 13:38:07
bossa> write /home/pi/Desktop/bootloader_CUBE.bin
Write 196 bytes to flash

Sind 196 Byte nicht etwas wenig ? der aktuelle Bootloader hat doch knapp 15 kB ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 31 Dezember 2015, 15:52:57
Es sollten etwa 15040 Bytes sein.
bossa> scan
Checking port ttyACM0...
Device found on ttyACM0
bossa> write /home/pi/bootloader_CUBE.bin
Write 15040 bytes to flash
[==============================] 100% (59/59 pages)
bossa> bootf true
Boot to flash flag set to true
bossa>
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 31 Dezember 2015, 16:23:36
Wie hast du das bin File besorgt? Ggf falscher download. Nochmal runterladen und dann sollte das passen

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 31 Dezember 2015, 19:50:54
Hab ich vorhin frisch gezogen von der Adresse aus dem ersten Beitrag.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 31 Dezember 2015, 20:01:34
Mit Windows oder wie?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 31 Dezember 2015, 20:02:19
Am Raspi
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 31 Dezember 2015, 20:17:40
Lade mal per Windows und kopiere dann rueber

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 01 Januar 2016, 12:38:50
OK, das lag wahrscheinlich alles am Jahr. In 2015 sollte das wohl nicht mehr klappen. ;)
Der Fehler lag bei mir. Ich hatte die Datei noch mal neu geladen und auf meinem NAS abgelegt. Ich habe dann nicht bemerkt, dass ich die Datei nicht kopiert sondern nur einen Link abgelegt hatte. Das kann man am Raspi aber auch nur beim vermeintlichen Kopieren selbst sehen, woll? Danach sah die Datei für mich wie jede andere auch aus.
Egal, nachdem ich nun also das Wunder der Strg-Taste entdeckt habe lag die Datei mit 15040 Bytes auf dem Desktop und mit bossa habe ich sie dann auf den CUBE bekommen.
Was soll ich sagen: er blinkt! Er blinkt wirklich! Dass ich das noch erleben darf! :)
Aber - und wie könnte es anders sein? - wie geht es nun weiter?
Mein erster Versuch galt Windows 7. Da taucht das Gerät nun als CUBELOADER unter Andere Geräte im Gerätemanager auf. Unter Tera Term steht es nicht zur Auswahl. So also schon mal nicht. :(
Also ran an den Raspi, da Putty installiert und eine serielle Verbindung zu /dev/ttyACM0 aufgebaut. Das scheint irgendwie zu klappen aber ich sehe nur einen schwarzen Bildschirm... :(
Nächster Kandidat wäre nun also minicom aber da blicke ich nun gar nicht durch. Ich hab's mal mit minicom -D /dev/ttyACM0 probiert. Das heißt mich dann zwar herzlich Willkommen, danach wird es aber undurchsichtig. Was muss da nun gemacht werden?
Ahc ja, falls es von Interesse ist, hier noch das Ergebnis von dmesg:
[   87.424648] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[   87.529862] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6119
[   87.529905] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   87.529926] usb 1-1.2: Product: CUBELOADER
[   87.604905] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[   87.609116] usbcore: registered new interface driver cdc_acm
[   87.609193] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Hat sich die idProduct jetzt geändert?

PS: Ein frohes neues Jahr an alle! Trotz meiner beharrlichen Nerverei. ;)

---
Nachtrag: habe gerade noch was interessantes entdeckt, als ich den CUBE am Mac angeschlossen habe.

(http://content.screencast.com/users/petjek/folders/Snagit/media/e3b9621e-6322-4cf0-86c8-0b2e3afcfbb8/2016-01-01_15-35-22.png)

Ist mein CUBE jetzt ein Telefon???
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 01 Januar 2016, 17:26:11
Hallo zusammen,

nach Stunden der Suche muss ich mich hier doch nochmal melden. Bei mir hatte das Flashen mit der Amtelsuite nicht funktioniert. Ich erhielt dann einen Hinweis wie ich den Maxcube unter linux flashen kann. Diesen Threat finde ich nicht mehr.

Kann mir jemand weiterhelfen wie ich diese Anleitung wieder finde ?

Danke
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 01 Januar 2016, 20:28:51
Mein erster Versuch galt Windows 7. Da taucht das Gerät nun als CUBELOADER unter Andere Geräte im Gerätemanager auf. Unter Tera Term steht es nicht zur Auswahl. So also schon mal nicht. :(
Er muss als COM Port in Anschlüsse auftauchen. Weise ihm den Treiber aus dem SAM-BA Verzeichnis zu. Wenn das nicht hilft, installiere die Arduino IDE und versuch den dort mit installierten Treiber.

Hallo zusammen,

nach Stunden der Suche muss ich mich hier doch nochmal melden. Bei mir hatte das Flashen mit der Amtelsuite nicht funktioniert. Ich erhielt dann einen Hinweis wie ich den Maxcube unter linux flashen kann. Diesen Threat finde ich nicht mehr.

Kann mir jemand weiterhelfen wie ich diese Anleitung wieder finde ?

Danke
Meinst du diese hier: http://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429 (http://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429)
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 02 Januar 2016, 10:06:43
Danke, genau das wars
Titel: Antw:culfw@ARM
Beitrag von: petjek am 02 Januar 2016, 11:11:32
OK, jetzt bin ich mir nicht sicher ob es das war, bzw. ob ich jetzt fertig bin.
Die Treiber aus dem AMTEL-Verzeichnis wurden nicht akzeptiert, allerdings funktionierte die automatische Installation der Treiber.
Der CUBE wurde dann wieder als AT91 USB to Serial Converter (COM9) angezeigt. Die Verbindung über Tera Term kam auch zustande, die Übertragung wurde gestartet und nach ein paar USB-Disconnect und -Connect Sounds blinkt nun die Power-LED und die Battery-LED leuchtet permanent.
War's das? Hab ich es wirklich geschafft? Ich kann es noch nicht so recht glauben.
---
Nachtrag: Ich glaube es! Unfassbar! Das ich das noch erleben darf!

(http://content.screencast.com/users/petjek/folders/Snagit/media/0c96f540-1b67-4eba-9b7b-2dcb8afd2d40/2016-01-02_11-29-26.png)

Danke an Alle, die hier die Geduld gezeigt haben mir weiterzuhelfen. War ein hartes Stück Arbeit, was?
Jetzt werde ich mich mal daran begeben herauszubekommen, wie ich nun meine Thermostate und Fensterkontakte da wieder angelernt bekomme. ;)
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 02 Januar 2016, 22:33:52
Na endlich. Glückwunsch

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 03 Januar 2016, 10:38:04
Danke für den Link. Hatte ich doch übersehen  :-\

Aber eine Frage habe ich noch:

wenn ich den Cube neu flashen will, muss ich erst nochmal den Bootloader übertragen oder reicht es die neue Firmware per minicom zu übertragen ?

Danke Klaus
Titel: Antw:culfw@ARM
Beitrag von: petjek am 03 Januar 2016, 12:00:44
Na endlich bekomme ich die Chance mal was hilfreiches beizutragen. :)
Beim Einstecken des USB-Kabels die Reset-Taste gedrückt halten, das aktiviert den Bootloader. Dann kann die FW neu aufgespielt werden. Musste ich auch machen weil ich beim ersten Versuch nicht XMODEM ausgewählt hatte.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 03 Januar 2016, 13:13:52
Hab da noch auch noch ne Frage. Wie bekomme ich den maxcube nun in den pairmodus?
Ich hab es mit set maxcube pairmode versucht. Da bekomme ich als Antwort
Unknown argument pairmode, choose one of ITClock bWidth freq hmPairForSec hmPairSerial led patable rAmpl raw reopen sensSo also schon mal nicht.
Der hmPairForSec gilt nur für Homematic-Komponenten, richtig?

Ich habe
Ich habe nun alle Komponenten einmal resetet, danach die Wohnzimmergeräte wie in der Raumlösung gepairt. (Kann ich mir das nicht eigentlich sparen?)
Inzwischen tauchen der Fensterkontakt und das Wandthermostat wieder auf, der Rest (also alle Heizkörperthermostate) glänzen noch durch Abwesenheit.
Ich habe mal das heutige Protokoll angefügt. Die Thermostate scheinen nicht erkannt zu werden, richtig? Weiterhin steht da sehr häufig...
Can't connect to socket!... was wohl eher auch nichts Gutes bedeutet, oder?

LG,
petjek
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 03 Januar 2016, 13:47:43
Schau mal hier http://forum.fhem.de/index.php?topic=38404.msg381162.msg#381162

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: petjek am 03 Januar 2016, 13:58:50
Öhm, der Link bringt mich zu meinem eigenen Beitrag auf Seite 20.
Oder meinst du den Hinweis, wie man den maxcube definiert? Das hat geklappt. Darum geht's grad nicht.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 03 Januar 2016, 14:26:42
Mir ging es um das definieren. Wie sieht es bei dir aus?

define maxcube CUL 192.168.0.123:2323 0000
attr maxcube rfmode MAX
attr maxcube room CUL
define cmax CUL_MAX 654321
attr cmax IODev maxcube

Titel: Antw:culfw@ARM
Beitrag von: petjek am 03 Januar 2016, 15:06:32
Genau so. Bis auf die IP natürlich
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 03 Januar 2016, 15:08:29
Hast du hm oder max? Und das pairen muss auf cmax stattfinden nicht auf maxcube

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Basegate am 07 Januar 2016, 03:10:39
Hey Leute.  Ich würde mir gerne einen sma Anschluss an den cube löten um eine richtige Antenne dran machen zu können. Hab alles da.  Kann mir jemand sagen wo ich den Schirm (masse) anlöten soll??

Vom Mobiltelefon gesendet.

Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 07 Januar 2016, 08:15:31
Hi,

Die Masse deines Antennen Steckers kannst du direkt an das Metallgeäuse des Funkmoduls löten, das sollte mit Masse verbunden sein

Grüße,
Stephan
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 07 Januar 2016, 11:53:02
Hab nun an meinen 433mhz cube die sma Buchse und antenne dran.  Senden und empfangen ist viel besser bzw reagiert schneller. Danke für den Tipp mit der Masse.
Demnächst kommt die Antenne für meinen cube 868mhz. Werde mal die rssi Werte vorher checken und vergleichen.

 (https://uploads.tapatalk-cdn.com/20160107/eefd3326046a3772ddf19732f7e591c3.jpg)

Vom Mobiltelefon gesendet.

Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 07 Januar 2016, 12:23:09
Hi,

Hast du das Funkmodul im Cube ausgetauscht oder "einfach nur" ne Externe Antenne drangelötet?

Grüße,
Stephan
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 07 Januar 2016, 12:26:56
Hi.
Ist das gleiche funkmodul . Hab eine SMA Verlängerung genommen.  Den Stecker abgeschnitten und den Schirm ans Gehäuse des funkmoduls gelötet und die Antenne an den antennenanschluss.




Vom Mobiltelefon gesendet.

Titel: Antw:culfw@ARM
Beitrag von: noice am 07 Januar 2016, 12:36:41
Hab nun an meinen 433mhz cube die sma Buchse und antenne dran.  Senden und empfangen ist viel besser bzw reagiert schneller. Danke für den Tipp mit der Masse.
Demnächst kommt die Antenne für meinen cube 868mhz. Werde mal die rssi Werte vorher checken und vergleichen.

 (https://uploads.tapatalk-cdn.com/20160107/eefd3326046a3772ddf19732f7e591c3.jpg)

Vom Mobiltelefon gesendet.
... und die schöne Power lampe geopfert :-\

Mobil erstellt daher kurz gehalten

Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 07 Januar 2016, 12:42:55
Na ja, die Power-LED ist meinermeinung nach "unwichtig". Sollange die Battery-LED Blinkt ist doch alles in Butter.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 07 Januar 2016, 14:03:10
Kannst du bitte ein Platinen Foto Posten und eins von drinnen

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Basegate am 08 Januar 2016, 01:43:07
Mach ich beim nächsten cube (868 mhz) ok?  Will den ungern wieder auseinander bauen.

Vom Mobiltelefon gesendet.

Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 08 Januar 2016, 16:43:41
Hab mich auch hinreisen lassen :)

Alles wie gehabt durchgeführt... Hardware soweit verglichen und bei Connect kam immer Invalide Chip ID.. nach dem Versuch diverser Kabel und 2ten Rechner hab ich dann mal statt at91sam7x256-ek diesen at91sam7x512-ek genommen ??? UPS Funktioniert die Verbindung. Meiner ist aber auch schon ein altes Eisen ca 4 Jahre Alt kann auch Älter sein, lag lange im Baumarkt. Evtl. hat der wohl mehr Internen Speicher.. geh ich mal von der Zahl 512 aus. Evtl. haben sie bei den Neueren schon gespart.  Bei mir steht auch nur auf dem Gehäuse (TRX868) Ohne TI oder sonst was. Das Bild zum Vergleich des Funkmoduls ist aber Identisch.

Versuche jetzt zu Flashen :)

EDIT: Scheint zu Funktionieren... Batterie Leuchtet dauernd und Power Blinkt. So mal sehen wie es weiter geht :)  PUH hab das Pairen jetzt auch hinbekomen ...pfui spinne, lol ..gewusst wie.
Titel: Antw:culfw@ARM
Beitrag von: Basegate am 08 Januar 2016, 18:34:09
Hab meinen zweiten cube nun fertig mit sma Anschluss. Max empfang zwischen 10 und 15 Dezibel besser. Siehe bilder

Vom Mobiltelefon gesendet.

Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 08 Januar 2016, 22:26:02
Habe aber im Moment. Zu wenige Credit zum kompletten einrichten. Habe aber auch beim Thermostat einen RF error gehabt.  Ich warte ab,  da ich jetzt eh auf Arbeit bin, wie es morgen mit den Credits aussieht.
Titel: Antw:culfw@ARM
Beitrag von: darth am 09 Januar 2016, 00:06:46
Hallo zusammen,

ich habe soeben zwei max cube (TRX868) versucht zu flashen. Dabei habe ich unter Linux mit minicom bei beiden folgende Fehlermeldung erhalten:

         +-----------[xmodem upload - Press CTRL-C to quit]------------+
Press CTR|Sending fw.hex, 279 blocks: Give your local XMODEM receive command now.                                                   
         |Xmodem sectors/kbytes sent: 279/34kRetry 0: No ACK on EOT
                                                                     
         |Transfer incomplete                                         
                                                                   
         | READY: press any key to continue...                         
         +-------------------------------------------------------------+

Der Bootloader ist korrekt installiert:
[   49.614360] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[   49.719642] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6119
[   49.719684] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[   49.719703] usb 1-1.2: Product: CUBELOADER

Ebenfalls habe ich es probiert unter Windows zu flashen, hierbei wurden keine Fehlermeldungen ausgegeben.

Wo liegt der Fehler?

Wenn ich den cube einfach per USB anschließe, dann blinkt keine LED. Nur wenn ich den Taster vor dem anschalten gedrückt halte blinkt die LED D1. Wie geschrieben bekomme ich aber keine Firmware geflasht.

Vielen Dank vorab.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 Januar 2016, 12:05:06
         +-----------[xmodem upload - Press CTRL-C to quit]------------+
Press CTR|Sending fw.hex, 279 blocks: Give your local XMODEM receive command now.                                                   
         |Xmodem sectors/kbytes sent: 279/34kRetry 0: No ACK on EOT
                                                                     
         |Transfer incomplete                                         
                                                                   
         | READY: press any key to continue...                         
         +-------------------------------------------------------------+
Die Fehlermeldung ist normal, da der Cube schon neustartet bevor das Letzte ACK empfangen wurde. Ich denke du hast die falsche Firmware geflasht. Die Firmware ist deutlich größer als 34k und auch kein .hex File sondern eine .bin File.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 10 Januar 2016, 07:11:24
So alles Wunderbar bis jetzt am Laufen.. auch mit Zicken (Batterietausch schafte soweit abhilfe beim Anlernen). oder auch mehrmaliges Reset der Thermostaten von Max. Wobei dann auch die Credits zu neige gehen.

Positiv ist aber das ich ohne Max Software egal welche Fimware 1.0/1.3/1.5 alle Firmware der Aktoren die Korrekte Temperatur wiedergeben, was mit der Max Software nicht der fall ist. Da musset man ja Korregieren von 0.5 bis 1 Grad, Gemessen mit einen Infrarotthermometer.

Gruß 8)
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 10 Januar 2016, 22:45:58
Hab jetzt auch schon geschaft meine Unitec Steckdosen zu steuern. 
Wie sieht das aus mit einer Multiband Antenne?  Weil die Reichweite ist eher Mager auf 433 MHz. Gibt da welche für 868 und 433 Mhz. bzw. für beides mit SMA Anschluss...evtl. schon jemand erfahrung gemacht mit diesen Antennen.
Und ist es nicht besser einen 2 Cube zu besorgen wegen der Lebensdauer beim umschalten. Da hab ich gelesen das ja dabei das Eprom neu geflasht wird?
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 12 Januar 2016, 22:30:38
Hab jetzt auch schon geschaft meine Unitec Steckdosen zu steuern. 
Wie sieht das aus mit einer Multiband Antenne?  Weil die Reichweite ist eher Mager auf 433 MHz. Gibt da welche für 868 und 433 Mhz. bzw. für beides mit SMA Anschluss...evtl. schon jemand erfahrung gemacht mit diesen Antennen.
Und ist es nicht besser einen 2 Cube zu besorgen wegen der Lebensdauer beim umschalten. Da hab ich gelesen das ja dabei das Eprom neu geflasht wird?

Hier wurde ja schon mehrfach erläutert, dass nur die Antenne zu wechseln die Sendeleistung nicht (wesentlich) verbessert. Dafür wäre ein anderes Funkmodul für 433 MHz erforderlich. Die gleiche Erfahrung haben andere Fhem Nutzer z.B.auch schon beim Selbstbau eines NanoCUL gemacht, wenn sie aus China als 433MHz deklarierte 868 MHz Module erhalten haben. Wenn man das unbedingt machen will wäre also wohl eher die Frage, kann man so einfach ein anderes Funkmodul im Cube verwenden/verlöten? Ich bin mittlerweile so vorgegangen wie mir hier im Thread auch empfohlen wurde: für 433 Mhz tut es ein Arduino Nano (Empfehlung: auf FTDI Chipsatz achten, falls man mehrere NanoCULs verwenden will!) mit passenden Funkmodul. Materialkosten mit Versand aus DE knapp 20 Euro. Hat gut geklappt und mit Reichweite habe ich keine Probleme. Für den/die Cubes gibt es ja auch für 868 MHz genügend andere Einsatzzwecke :-)

Gruß

Tatsu
Titel: Antw:culfw@ARM
Beitrag von: daniel85 am 14 Januar 2016, 09:50:50
Hallo zusammen,

hab folgendes Problem:

Hab einen MAx!Cube mit der aktuelle Firmware zu einem CUN geflasht. Feste IP vergeben und in FHEM bekannt gemacht. Funktioniert auch alles soweit allerdings scheint der Cube Komunikationsprobleme mit FHEM zu haben. Ich bekomme ständig folgende Fehlermeldung:

016.01.14 08:07:03 1: 192.168.1.2:2323 disconnected, waiting to reappear (MAXCUBE1)
2016.01.14 08:07:03 1: Error in CUL_MAX_SendQueueHandler: CUL MAXCUBE1 did not answer request for current credits. Waiting 5 seconds.
2016.01.14 08:07:08 1: 192.168.1.2:2323 reappeared (MAXCUBE1)
2016.01.14 08:07:08 3: MAXCUBE1: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.01.14 09:07:03 1: 192.168.1.2:2323 disconnected, waiting to reappear (MAXCUBE1)
2016.01.14 09:07:03 1: Error in CUL_MAX_SendQueueHandler: CUL MAXCUBE1 did not answer request for current credits. Waiting 5 seconds.
2016.01.14 09:07:08 1: 192.168.1.2:2323 reappeared (MAXCUBE1)
2016.01.14 09:07:08 3: MAXCUBE1: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz

Das auslesen bzw. aktualisieren von Werte und schreiben von Befehlen an den Cube funktionert auch nur sehr sporadisch.
Ein get info über die FHEM Oberfläche meldet beim ersten Ausführen immer "No data" und die obige Fehlermedlung im Log. Bei zweiten Ausführen bekomme ich dann die Firmware Version zurück.
Selbes Verhalten habe ich auch wenn ich es direkt mit telnet und -V versuche.
Aber schon nach 1 min hab ich das selbe problem. Irgendwie so als wenn der Cube in eine Art Standby geht und nicht mehr antwortet. Das anpingen klappt jedoch problem los.

Hat jmd eine Idee woran es liegen könnte??? Hab ich evtl beim flashen noch etwas in der FW einstellen müssen ???
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 14 Januar 2016, 09:59:58
Ich hatte auch Probleme, eine stabile Verbindung über LAN zu bekommen. Letztlich habe ich den Cube dann doch als CUL per USB angeschlossen. Seitdem hab ich keine Probleme mehr.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 14 Januar 2016, 15:44:44
Hat jmd eine Idee woran es liegen könnte???
deine Fehlerbeschreibung klingt nach dem Fehler den mr.os im Oktober gefixt hat,
( siehe : http://forum.fhem.de/index.php/topic,38404.msg351896.html#msg351896 )
kannst ja mal die dort angehängte Version flashen vllt. ist der Bugfix wieder im aktuellen Source Code verloren gegangen.
Titel: Antw:culfw@ARM
Beitrag von: daniel85 am 15 Januar 2016, 21:52:50
Fhem läuft bei mir auf einem QNAP Nas. Dafür muss man erst treiber und kernel kompilieren. Jedoch steck ich da nicht so tief drinn und habe auch keine Lust/Zeit mich da einzuarbeiten.
Daher fällt Cul über USB wohl erstmal flach.

Mit der Firmware von Mr.Os sieht es auch nicht besser aus!  Allerdings vestehe ich nicht was daran so schwer sein kann. Der Cube hängt an der zweiten Netzwerkschnittstelle und ist direkt verbunden, ohne Switch dazwischen !

Läuft das Ding denn bei anderen Störungsfrei ???? ich kann mir schwer vorstellen, dass es an der Netzwerkkonfiguration liegt.
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 15 Januar 2016, 21:57:39
Ich habe inzwischen drei Stück mit der aktuellen Firmware nach der Anleitung hier geflasht und auch über Netzwerk angebunden.
Bisher keine Probleme.
Liegt also sicher an was anderem.
Titel: Antw:culfw@ARM
Beitrag von: daniel85 am 15 Januar 2016, 22:26:11
Ich habe inzwischen drei Stück mit der aktuellen Firmware nach der Anleitung hier geflasht und auch über Netzwerk angebunden.
Bisher keine Probleme.
Liegt also sicher an was anderem.

Irgendwelche besonderen Einstellungen bzgl. des Cubes vorgenommen ??

Ich bekomme nächste Woche noch einen zweiten...mal schauen wie es mit dem aussieht
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 15 Januar 2016, 22:40:46
Nein eigentlich nicht, die IP bekommt der Cub von der Fritzbox per DHCP und in Fhem normal nach Anleitung definiert.
Mache noch nicht so viele Experimente da ich noch Anfänger mit Fhem bin und erst mal versuche die Anleitungen sicher um zu setzen.
Titel: Antw:culfw@ARM
Beitrag von: dieda am 15 Januar 2016, 23:09:19
Nein eigentlich nicht, die IP bekommt der Cub von der Fritzbox per DHCP und in Fhem normal nach Anleitung definiert.
Mache noch nicht so viele Experimente da ich noch Anfänger mit Fhem bin und erst mal versuche die Anleitungen sicher um zu setzen.

setzte mal im Router das Häkchen, nicht das der sich ständig ne andere IP schnappt.
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 15 Januar 2016, 23:12:40
Ja das hab ich natürlich.  :) Wie schon geschrieben, mit den Cubes habe ich keine Probleme.
Ist für mich eine wirklich zuverlässige, günstige und gut zu beschaffende Alternative zu den Cul oder Cun.
Titel: Antw:culfw@ARM
Beitrag von: dieda am 15 Januar 2016, 23:17:20
Würde es ja gerne machen. Aber den Cub vom Life-System nehmen geht nicht. In der Bucht gerade nachgeschaut. Nur einer, der günstig ist. Der Rest ... Da sind sogar Preise über 60 €...
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 15 Januar 2016, 23:25:08
Bei uns im Globusbaumarkt gab es die Heute noch für 40€. Glaube die sind noch bis Morgen im Angebot.

Ps.:Oder bei ELV als Bausatz (ist in 10Min zusammen) für ebenfalls 40€
Titel: Antw:culfw@ARM
Beitrag von: dieda am 16 Januar 2016, 13:31:07
Hm, ist noch viel, wenn ich daraus einen Pflasterstein mache...
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 16 Januar 2016, 14:18:39
Das Flashen ist ziemlich unkompliziert und in 10 Minuten erledigt.
Da würde ich mir keine großen Gedanken machen. Einfach genau nach der Anleitung auf Seite 1 gehen.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 16 Januar 2016, 14:59:26
kann ich bestätigen beim cube. meiner wurde gerade vom postboten gebracht (gebraucht inkl versand 30€ als XAVAX  green eco Max cube).
J1 mit schraubendreher überbrückt, tools aus post 1 genutzt < 5 min und der cubeCUL ist eingebunden.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 16 Januar 2016, 15:09:44
allerdings muss ich sagen das der cube gegenüber gleich platziertem HM-CFG-LAN,HM-CFG-USB und selbstbauCUL die schlechteren rssi werte zeigt (getestet mit hm-fernbedienung aus ca 2m entfernung)

Zitat
rssi_at_HMLAN1 avg:-15.93 min:-21 max:-15 lst:-21 cnt:15
rssi_at_HMLAN_USB avg:-19.46 min:-25 max:-18 lst:-24 cnt:185
rssi_at_cubeCUL868 avg:-26.53 min:-33 max:-24 lst:-24.5 cnt:57
rssi_at_nanoCUL868 avg:-23.15 min:-23.5 max:-22.5 lst:-23.5 cnt:23
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 16 Januar 2016, 15:24:34
was muss man tun um den cul-cube mit lan zu nutzen? habe wie in post 1 die CUBe draufgeflashed. per usb läuft er aber steck ich ihn ans lan hat er keinen link (kein zeichen am switsch das ein lan-gerät dran hängt). muss ich ihm vorher per usb das lan aktivieren oder sowas?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 Januar 2016, 15:47:57
LAN ist automatisch aktiv und wenn DHCP vorhanden ist, wird die Netzwerkadresse auch automatisch gesetzt. Du kannst ja mal versuchen, die Netzwerkadresse manuell zu setzen http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten)

Dass der Cube eine Verbindung zum Netzwerk hat, sieht man auch daran, das D2 (INTERNET) am Cube leuchtet.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 17 Januar 2016, 18:33:36
per usb läuft er aber steck ich ihn ans lan hat er keinen link
das USB Kabel hast aber trotzdem zur Stromversorgung des Cubes dran gelassen ? denn PoE kann der Cube nicht :)
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 17 Januar 2016, 19:24:10
das USB Kabel hast aber trotzdem zur Stromversorgung des Cubes dran gelassen ? denn PoE kann der Cube nicht :)

LOL..... fehler war den cube per strom am pc zu versorgen....
Titel: Antw:culfw@ARM
Beitrag von: tobby am 19 Januar 2016, 02:31:50
Habe mir einen HM-CFG-USB-2 Stick gekauft und heute nach der Anleitung vorne umgeflasht. Vorher habe ich die Firmware noch selbst kompiliert, das hat auch geklappt, nachdem ich im Thread gelesen hatte, dass die 4.9er Toolchain nicht geht - und ich mich gewundert habe, warum der Stick nicht will... ^^ Mit der 4.8er ging es dann und der Stick meldet sich korrekt, kann mich per serieller Konsole mit ihm verbinden und auf das Kommando "V" nennt er mir seine Versionsnummer. Das funktioniert sowohl an meinem Windows-Rechner als auch am Linux-Host.
Zitat
V 1.20.03 a-culfw Build: private build (unknown) CUL-HM-CFG (F-Band: 868MHz)

Allerdings läuft mein FHEM als VM. Mit KVM reiche ich den USB Stick vom Hypervisor dann an die VM durch. Ab dann reagiert der Stick auf nichts mehr. Keine Ausgabe, kein nichts. Mit dem ebenfalls angeschlossenen originalen CUL V3 funktioniert das dagegen einwandfrei. Wenn ich die VM wieder runterfahre, taucht er natürlich wieder auf dem Host auf, aber läuft auch dort nicht mehr. Der "echte" CUL natürlich schon... Ich muss den Stick dann erst einmal ausstöpseln und wieder einstöpseln, damit es geht. Natürlich nur so lange, bis ich die VM wieder starte...

Jemand eine Idee, was das Problem sein könnte? So kann ich ihn leider nicht benutzen :(

//EDIT: Habe es gerade auch nochmal an meinem Windows-Rechner probiert, da gehts... Nur unter Linux nicht. Eben ist er auch im Hypervisor abgeschmiert, also liegt es nicht (nur) am Durchreichen. Wobei er im Hypervisor manchmal eine Weile läuft. In der VM dagegen nie. Unter Windows dagegen einwandfrei. Habe es auch nochmal mit der vorkompilierten Firmware probiert, gleiche Symptome. Liegt also nicht an meiner selbstkompilierten.
Titel: Antw:culfw@ARM
Beitrag von: tucka am 19 Januar 2016, 02:40:33
Hi,

ich wollte meinen Cube auch flashen. Da ich MAC-User bin kann ich das SAM_BA tool leider nicht verwenden. Unter einer Windows VM und Linux VM konnte ich nach mehreren Versuchen nicht auf den CUBE zugreifen (liegt wohl an Virtual Box).

Nun habe ich den Cube an meinen Raspberry PI angeschlossen. Dort wird er auch erkannt. Soweit schon mal gut.

Kann ich den Bootloader und die Firmware dort auch mit einem anderen Tool flashen. AVRDUDE wäre eine möglichkeit aber AT91 werden darüber ja nicht unterstützt.

Hat jemand eine Idee? (...oder evtl. direkt über MAC).

Danke!!

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 19 Januar 2016, 08:10:40
Ich habe ne Weile gegoogelt, welche Alternativen zu Sam-Ba es gibt. Dabei bin ich auf BOSSA (http://www.shumatech.com/web/products/bossa) gestoßen. Gibt es auch als Paket für Ubuntu oder Debian bzw. Raspbian:
bossa - Atmel SAM ARM microcontroller flash programming GUI
bossa-cli - Atmel SAM ARM microcontroller flash programming utility
Die GUI habe ich nicht getestet. Ich habe im terminal einfach die BOSSA Shell (bossash) aufgerufen. Sollte dann in etwa so aussehen:
$ bossash
Press Ctrl-D or enter "exit" to end session.
Enter "help" to display a command list.
bossa>
Dann einfach mit "scan" nach dem CUBe suchen. Dabei sollte er automatisch verbunden werden. Dann mit "write bootloader_CUBE.bin" den Bootloader schreiben.  Dann "bootf true" und der CUBe bootet neu in den Bootloader. Danach kannst Du mit einem Terminalprogramm (z.B. minicom) die Firmware auf den CUBe bringen.
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 13:15:52
Hallo zusammen,
Ich habe ich jetzt auch mal drangegeben den Cube zu flashen. Es will aber nicht so richtig. Ich habe J1 überbrückt. Dann habe ich mit Bossa (auf dem Mac) den Cube mit der Firmware gefüttert. Habe auch eine korrekte Rückmeldung erhalten. Danach per Zterm die cubefw raufgespielt. Die Fortschrittsanzeige lief bis 100 %. Dann kam eine Fehlermeldung. Den Cube abgezogen und neu gestartet. Die LED leuchten nicht.
Die Prozedur habe ich jetzt schon einige Male wiederholt. Jedoch wird der Modemport nicht mehr erkannt.
In Bossa kann ich jedesmal die Firmware neu aufspielen mit Erfolgsmeldung. Stecke ich den Cube (auch mit gedrückter Taste unterhalb) jetzt ein, leuchten aber keine LED mehr. Zterm erkennt den Cube nicht mehr. In der MAC Netzwerkumgebung erscheint der Cube als "Cubeloader"
Also scheint er noch nicht "tot" zu sein. Wo mache ich denn da noch einen Fehler?
Gruß an alle Bastler.

Carsten

Update: Habe den "Cubeloader" Eintrag mal in der Übersicht gelöscht. Kommt jetzt beim Neueinstecken nicht wieder. Also ein alter Eintrag. Aber wie gesagt, kann ich die FW über Bossa immer neu aufspielen. Also muß der Cube ja irgendwie erreichbar sein.
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 20 Januar 2016, 13:32:24
Was mir an deiner Beschreibung aufgefallen ist: Du hast während dem Flashen den J1 überbrückt?
Dieser muss NUR am Anfang kurz gebrückt werden dann kurz das USB Kabel dran und wieder ab. Jetzt J1 entfernen und dann flashen.....
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 13:34:58
Ok, mißverständlich geschrieben. Ich hatte natürlich die Brücke vor dem Flashen wieder entfernt. Sorry
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 20 Januar 2016, 13:38:10
Ah ok, nutzt du ein 64bit Windows 7? Hatte damit auch Probleme den Bootloader zu flashen. Bin dann auf ein 32Bit Windows 7 ausgewichen und dort lief es dann perfekt.
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 13:42:41
Nein, ich flashe das ganze auf einem Mac. Das Programm heißt Bossa. Das flashen scheint ja auch zu funktionieren. Beim ersten Mal hatte ich sogar die blinkenden LED. Leider gab es ja den Fehler beim uploaden der CubefW. Dann habe ich die Prozeduren wiederholt. Jetzt blinken die LED nicht mehr. Aber der Flashvorgang läßt sich fehlerfrei durchführen.
Jetzt erscheint der Cube wieder mit der Bezeichnung USBModem 1421, aber der Upload klappt nicht und es blinkt auch nichts.
Titel: Antw:culfw@ARM
Beitrag von: marty29ak am 20 Januar 2016, 13:49:06
Mit einem MAC kann ich leider nicht weiter helfen.
Aber versuch doch mal den Cube direkt am PI zu flashen. Da soll dieses Bossa ja auch laufen....Wie ist ja weiter oben beschrieben.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 20 Januar 2016, 14:19:41
@CarstenF, deine Fehlerbeschreibung liest sich wie meine Probleme damals mit dem Cube.
Fang mal an auf Seite 6 ab Posting #85 meinen Leidens und Lösungsweg zu lesen mit einer anderen Firmware von Telekatz die keinen extra Bootloader benötigt. ( letzte Version im Posting #156 , Seite 11)
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 16:55:59
Ne, klappt alles nicht. Bossa bekomme ich nicht auf den PI installiert. (Habe es auf zweien versucht, erhalte jedesmal eine Fehlermeldung)
Tot ist der Cube auf jeden Fall nicht. Am Mac wird er am USB Port noch als Device angezeigt. Egal. Leihe mir am Wochenende mal ne Windows Maschine und versuche es erneut. Trotzdem Danke erstmal.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 20 Januar 2016, 19:04:23
Ne, klappt alles nicht. Bossa bekomme ich nicht auf den PI installiert. (Habe es auf zweien versucht, erhalte jedesmal eine Fehlermeldung)
Welche Fehlermeldung bringt der PI?
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 21:00:21
Die Fehlermeldung kam hier im Board schon mal vor. Ich habe nur nichts gefunden wie es gefixt wurde. Auch im Netz habe ich nichts gefunden. Update des PI habe ich vorher gemacht.

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden gelesen.... Fertig
E: Paket bossa-cli kann nicht gefunden werden.

Das ganze stand aber in Englisch dort.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 20 Januar 2016, 21:05:11
Hattest du vorher ein sudo apt-get update gemacht

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 21:09:38
Ja, hatte ich gemacht....
Bleibt bei

Unable so locate package bossa-cli
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 20 Januar 2016, 21:55:32
Dann bau es doch selber:

Bossa mit sudo apt-get install bossa-cli installieren funktioniert bei mir auch nicht. Aber man kann Bossa auch selber bauen:
cd /usr/src
sudo git clone git://git.code.sf.net/p/b-o-s-s-a/code b-o-s-s-a-code
sudo apt-get install libreadline-dev wx2.8-headers libwxgtk2.8-0 libwxgtk2.8-dev
cd b-o-s-s-a-code
sudo make bin/bossash

#Starten
/usr/src/b-o-s-s-a-code/bin/bossash
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 20 Januar 2016, 22:16:39
Danke Telekatz,
Damit läuft Bossa jetzt auf dem PI. Habs gerade per VPN Tunnel von Unterwegs installiert. Morgen werde ich dann mal den Flashvorgang erneut anstupsen und berichten. Hoffe ich bekomme den Cube irgendwie ans laufen. Finde dieses Projekt wirklich Klasse!!!
Titel: Antw:culfw@ARM
Beitrag von: daniel85 am 21 Januar 2016, 08:09:52
setzte mal im Router das Häkchen, nicht das der sich ständig ne andere IP schnappt.


hab ich gemacht. bzw auch dem CUBE ne feste IP gebgen und DHCP deaktiviert. Keine veränderung. Betreibe ihn jetzt als CUL. Da klappt alles einwandfrei.
Am Netzwerk kann es eigentlich nicht liegen, da der Cube der einzige Teilnehmer ist und Ping auch durchweg klappt. Bin mir sicher das noch etwas in der Firmware spinnt (evtl ist es auch der CUBE)
Naja muss ich wohl mit dem CUL vorlieb nehmen.
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 21 Januar 2016, 13:54:37

Hallo, ich konnte jetzt den Cube vom Pi aus mit dem Bootloader beschreiben. Wenn ich den Cube jetzt booten will mit

"bootf true"

kommt   Boot to flash flag set to true. Was muß ich denn da machen?

Danke, Gruß Carsten
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 Januar 2016, 14:18:28
Da musst du nichts machen, da das die Bestätigung von "bootf true" ist und er beim nächsten mal vom Flash bootet.
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 21 Januar 2016, 14:43:52
Oh mann, ich seh schon, ich muß doch mal nen Linuxkurs in der Abendschule belegen.....
Danke. Dir. Jetzt werde ich mal schauen, das die Firmware draufkommt.
Titel: Antw:culfw@ARM
Beitrag von: PeMue am 21 Januar 2016, 20:37:13
Oh mann, ich seh schon, ich muß doch mal nen Linuxkurs in der Abendschule belegen.....
8) 8) 8) Ein Englischkurs würde für den Anfang schon reichen (sorry, das war eine Steilvorlage von Dir)  8) 8) 8)

Gruß PeMue
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 21 Januar 2016, 20:46:33
Menno, ich konnte doch nur mit der Meldung nix anfangen...... ;D. Aber ist schon ok  :)
Titel: Antw:culfw@ARM
Beitrag von: CarstenF am 24 Januar 2016, 14:54:07
So, erstmal vielen an die Entwickler dieses Projekts. Auch ich habe es hinbekommen. Ich konnte den Cube mit dem Bootloader versorgen über Bossa. Das ganze vom Mac Rechner. Allerdings konnte ich die Firmware weder vom Mac aus, noch über den PI hochladen. Hatte mit dann einen Windows Rechner (Windows 10)  geliehen und dann per Tera Term geflasht. Das lief ohne Probleme. Danach blinkten zwei LED (Power blinkt langsam durchgängig, Internet ist die ganze Zeit an). Der Cube ist dann im Netzwerk zu finden und ich kann ihn per "define maxcube_868 CUL 192.168.1.59:2323 0000" in Fhem einbinden. Die ersten Schaltungen sind auch schon erfolgt. Also scheint alles zu laufen.
Hat mal wieder totalen Spaß gemacht, so ein Projekt umzusetzen. Dieses Board ist einfach der Hammer!!!
Titel: Antw:culfw@ARM
Beitrag von: bernd_zwo am 27 Januar 2016, 17:04:18
Danke für die SW! Ich habe sie auf einem HM-CFG-USB-2 im Einsatz, läuft seit 24 h ohne Aussetzer an FHEM auf raspi.
Zum flashen habe ich vier Anläufe gebraucht, wahrscheinlich wegen der winzigen Jumperfelder und meiner dicken Finger...
Ich habe einen 9 kOhm-Widerstand eingesetzt, der hatte dickeren Draht als der 10er, den ich gefunden habe. Hat auch funktioniert.
Läuft bei mir als Homematic.

Gruß, Bernd
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 28 Januar 2016, 16:45:19
Wenn ich den Cube (CUNO) mit dem Somfy Modul anspreche gehen alle LED´s aus was er ja normal nicht macht. Normal geht die Power LED ja kurz an für einen Sendecommando. ? Funktioniert bzw ist das Gerät nicht in der Firmware ?

Gruß
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Januar 2016, 21:59:22
Wenn ich den Cube (CUNO) mit dem Somfy Modul anspreche gehen alle LED´s aus was er ja normal nicht macht. Normal geht die Power LED ja kurz an für einen Sendecommando. ? Funktioniert bzw ist das Gerät nicht in der Firmware ?
Somfy ist in der Firmware schon enthalten. Aber anscheinend war die ARM Implementierung von malloc(), das im Somfy Teil verwendet wird, fehlerhaft und hat den Cube abstürzen lassen. Ich hab malloc() aus dem Code entfernt und jetzt müsste es funktionieren.


@Telekatz , Joachim hat ja in Antwort #49 die Pinbelegung des ST2 gepostet, ist diese serielle Schnittstelle am ST2 nur im Debugmodus aktiv oder sind die Ein/Ausgaben im laufenden Betrieb identisch mit denen am USB Port ?
Hintergrund : die vier Pins schreien direkt danach einen ESP8266-01 aufzustecken und den Cube damit zum Wireless Cube zu machen :)

Hallo Wzut,
die Ein/Ausgaben sind jetzt auch am ST1 verfügbar. Da die culfw aber nicht dafür ausgelegt ist mehrere serielle Konsolen gleichzeitig zu bedienen, funktioniert die Ausgabe an ST1 nur, wenn USB nicht verbunden ist.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 29 Januar 2016, 08:59:42
funktioniert die Ausgabe an ST1 nur, wenn USB nicht verbunden ist.
Das klingt doch schon mal verdamt gut (BIG THX) , hast du eine auto Erkennung für USB drin oder müsste ich irgendwie dann manuell von USB auf ST1 Ausgabe wechseln ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 29 Januar 2016, 10:42:25
Es wird automatisch erkannt, das der Cube an einem Host angeschlossen ist. Wenn der Cube nur an einem USB Netzteil hängt ist die Ausgabe auf ST1 aktiv.
Falls notwendig könnte man aber auch einen Befehl einbauen, dass sobald ein bestimmter Befehl über ST1 empfangen wird, die USB Verbindung manuell getrennt wird und die Ausgabe an ST1 übergeben wird.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 02 Februar 2016, 23:46:04
Nabend zusammen,

meinen hm-usb habe ich wie in Post#1 beschrieben bearbeitet. Das Ergebnis aktuell ist, die LED ist an, Linux erkennt aber kein Gerät.
Ausgabe von dmesg:
[1135772.654015] usb 4-2: device descriptor read/64, error -71
[1135772.868021] usb 4-2: device descriptor read/64, error -71
[1135773.071016] usb 4-2: new full-speed USB device number 10 using uhci_hcd
[1135773.185017] usb 4-2: device descriptor read/64, error -71
[1135773.400016] usb 4-2: device descriptor read/64, error -71
[1135773.603015] usb 4-2: new full-speed USB device number 11 using uhci_hcd
[1135774.013019] usb 4-2: device not accepting address 11, error -71
[1135774.115018] usb 4-2: new full-speed USB device number 12 using uhci_hcd
[1135774.525015] usb 4-2: device not accepting address 12, error -71
[1135774.525079] usb usb4-port2: unable to enumerate USB device

Ist das Teil jetzt kaputt?
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 02 Februar 2016, 23:50:57
Direkt angeschlossen oder über USB Hub?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: tboston am 02 Februar 2016, 23:56:51
Direkt angeschlossen, hatte aber auch schon das Kabel versucht.

---
Tony

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Februar 2016, 08:47:09
Nabend zusammen,

meinen hm-usb habe ich wie in Post#1 beschrieben bearbeitet. Das Ergebnis aktuell ist, die LED ist an, Linux erkennt aber kein Gerät.
Ausgabe von dmesg:
[1135772.654015] usb 4-2: device descriptor read/64, error -71
[1135772.868021] usb 4-2: device descriptor read/64, error -71
[1135773.071016] usb 4-2: new full-speed USB device number 10 using uhci_hcd
[1135773.185017] usb 4-2: device descriptor read/64, error -71
[1135773.400016] usb 4-2: device descriptor read/64, error -71
[1135773.603015] usb 4-2: new full-speed USB device number 11 using uhci_hcd
[1135774.013019] usb 4-2: device not accepting address 11, error -71
[1135774.115018] usb 4-2: new full-speed USB device number 12 using uhci_hcd
[1135774.525015] usb 4-2: device not accepting address 12, error -71
[1135774.525079] usb usb4-port2: unable to enumerate USB device

Ist das Teil jetzt kaputt?
Wie weit hat es nach Anleitung noch funktioniert? Konntest du den Bootloader noch laden?
Titel: Antw:culfw@ARM
Beitrag von: tboston am 03 Februar 2016, 09:04:39
Hi,

den Bootloader konnte ich nicht flashen. Hatte auch erst v3.0 sa-mba versucht, die erwartete aber Argumente wo ich nicht wusste  welche...

Ist es eventuell wichtig, dass ich da eine andere Firmware drauf hatte vorher? Siehe hier: http://forum.fhem.de/index.php/topic,13071.0.html

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Februar 2016, 17:28:10
Die Firmware, die vorher drauf war, ist egal. Die wird durch das setzen von J2 sowieso gelöscht.
Hast du danach mit J1 den internen SAM-BA Bootloader geladen und anschließend auch den 10k Ohm Widerstand beim erneuten Einstecken mit verbunden? 
Titel: Antw:culfw@ARM
Beitrag von: tboston am 03 Februar 2016, 17:30:57
bis zu Schritt J1 überbrücken bin ich gekommen ja. Einen 10k Ohm Widerstand habe ich nicht. Der nächste schritt war ja sa-mba starten. Da passierte aber nix, da der Stick nicht gefunden wurde.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Februar 2016, 17:44:23
Wenn nach dem Schritt mit J1 der Stick nicht gefunden wird war der nächste Schritt den 10k Ohm Widerstand zu verwenden.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 03 Februar 2016, 17:50:20
Wenn nach dem Schritt mit J1 der Stick nicht gefunden wird war der nächste Schritt den 10k Ohm Widerstand zu verwenden.
Sowas habe ich leider nicht. Gibt noch nen anderen Weg?

---
Tony

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Februar 2016, 18:04:40
Es kann auch ein 1k Ohm Widerstand sein. Oder jeder beliebige Wert dazwischen. Aber ein Widerstand muss da rein.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 03 Februar 2016, 18:09:46
Verstehe, da ich mich mit sowas leider nicht auskenne, bleibt das Gerät nun wohl tot :(

---
Tony

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Februar 2016, 19:04:37
Es würde auch funktionieren, wenn man die richtigen zwei Pins am µC mit einer spitzen Nadel Überbrückt. Ich hab die entsprechende Stelle mal auf dem Foto markiert. Man muss den zweiten mit dem dritten Pin an der markierten Stelle überbrücken (während des gesamten SAM-BA Flashvorgangs).

Die Chance mit dieser Methode den Stick wirklich zu töten ist hier natürlich größer als mit der Widerstandsmethode. Insbesondere für Grobmotoriker.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 03 Februar 2016, 19:10:17
Danke für die Mühe, ich denke aber ich zähle zu den Grobmotorikern. Mir hat jemand aus dem Forum angeboten, den Stick zu löten. Ich denke darauf werde ich zurückkommen und dann wieder ein hmlan draus bauen. Habe mir gestern noch einen CUL868 bestellt der hoffentlich diese Woche noch kommt.
Danke euch!
Titel: Antw:culfw@ARM
Beitrag von: tboston am 04 Februar 2016, 11:36:13
Was für einen Widerstand brauche ich da genau?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 Februar 2016, 11:51:20
z.B. so einen:
http://www.reichelt.de/1-4W-5-10-k-Ohm-91-k-Ohm/1-4W-10K/3/index.html?&ACTION=3&LA=2&ARTICLE=1338&GROUPID=3066&artnr=1%2F4W+10K (http://www.reichelt.de/1-4W-5-10-k-Ohm-91-k-Ohm/1-4W-10K/3/index.html?&ACTION=3&LA=2&ARTICLE=1338&GROUPID=3066&artnr=1%2F4W+10K)
siehe auch:
http://forum.fhem.de/index.php/topic,38404.msg344668.html#msg344668 (http://forum.fhem.de/index.php/topic,38404.msg344668.html#msg344668)
Titel: Antw:culfw@ARM
Beitrag von: tboston am 05 Februar 2016, 07:14:29
Guten Morgen,

da ich mir nun den CUL868 zugelegt habe, würde ich gerne den hmusb wieder mit der FW von hier http://forum.fhem.de/index.php/topic,13071.0.html betreiben.
Ist das noch möglich?
Weiter würde mich interessieren ob es Sinn machen würde den 10kOhm Widerstand anzulöten oder nur zum flashen jetzt dranstecken?

Grüße
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 05 Februar 2016, 07:43:54
das ist keine firmware sondern nur hmland welches quasi ein stück software ist welches sich mit der (bei dir wohl nun nicht mehr vorhandenen) original firmware "unterhält"

siehe post 1 den du dir vor dem flashen natürlich durchgelesen hast:

Achtung: Die original Firmware ist danach weg und kann auch nicht wiederhergestellt werden, da keine unverschlüsselte Version davon verfügbar ist!
Titel: Antw:culfw@ARM
Beitrag von: tboston am 05 Februar 2016, 07:47:49
Ja habe ich durch gelesen. Dann kommt also nur a-culfw in Frage, was ja auch Homematic kann.

---
Tony

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Februar 2016, 07:59:17
Weiter würde mich interessieren ob es Sinn machen würde den 10kOhm Widerstand anzulöten oder nur zum flashen jetzt dranstecken?
Der Widerstand wird nur solange benötigt, bis der Bootloader aufgespielt ist. Dafür reicht es, ihn in die Kontakte des USB Steckers zu stecken. Ihn anzulöten ist nicht notwendig.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 05 Februar 2016, 08:40:23
Kann mir jemand sagen wie ich das andere Stück Plastik noch lösen kann?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Februar 2016, 13:30:08
Du musst die beiden Plastiknasen, die durch die Befestigungslöcher der Platine gehen, mit einem scharfen Messer bündig mit der Platineoberseite abschneiden.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 05 Februar 2016, 20:01:30
Also, der Widerstand ist drin, Stick wird aber nicht erkannt, jedenfalls via 'dmesg'.
Wer von den Linux'ern hier kann mir sagen wie er das mit sam_ba angestellt hat?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Februar 2016, 10:49:07
Der Widerstand hat nicht immer zuverlässig Kontakt zu den Anschlüssen vom USB Stecker wenn er gesteckt wird. Drücke ein bisschen am Widerstand , damit seine Drähte besser gegen die die Kontakte des USB Steckers gedrückt werden.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 06 Februar 2016, 10:55:51
Okay, hat scheinbar funktioniert. Ich weiß dennoch nciht was ich nun mit sam-ba tun soll :(
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 06 Februar 2016, 12:42:15
Sam-ba brauchst du nur, um den neuen Bootloader auf den Stick zu kriegen. Wenn das erledigt ist, brauchst du künftig nur noch eine Terminalsoftware, die Xmodem kann. Wenn der Bootloader mal drauf ist, kannst den aktivieren (wie das bei dem Stick geht, weiß ich nicht - bei nem CUL oder nem Maxcube gibts dafür dann nen Taster - den hält man gedrückt und steckt das Ding am USB-Port ein, dann meldet es sich als Serial Port am OS, auf den man dann das Terminalprogramm verbindet), dann via Xmodem die Firmware auf diesen Port geschubst - fertig.
Titel: Antw:culfw@ARM
Beitrag von: tboston am 06 Februar 2016, 12:44:27
Okay, ich weiß aber leider nicht wie ich per sam-ba den bootloader der aufschieben kann

---
Tony

Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 06 Februar 2016, 12:46:04
Äh - um Missverständnissen vorzubeugen - soweit ich weiß, geht das mit Xmodem "nur" bei den Teilen mit dem Bootloader aus diesem Fred. :)
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 06 Februar 2016, 12:47:19
Habs nur unter Windows gemacht lt Anleitung am Anfang dieses Theads - unter Linux gabs aber doch auch eine?
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 06 Februar 2016, 12:50:02
Such mal hier im Thread nach Antworten von mir. Ich hab mit bossash den Bootloader installiert. Damit ist es ganz einfach.
Titel: Antw:culfw@ARM
Beitrag von: pneuman1 am 06 Februar 2016, 21:23:33
Hallo zusammen,

ich wollte mir die Dateien herunterladen. Das Verzeichnis ist bei mir aber leer.
Mache ich da etwas falsch, oder muss man sich bei mediafire registrieren (was bei mir irgendwie nicht funktioniert)

"Firmware flashen :
Die kompilierten Bin Dateien findet Ihr unter https://www.mediafire.com/folder/tf16radvztfd9/a-culfw "

Der Cube liegt noch versiegelt auf dem Tisch und Sam-ba 3 wartet schon in meinem Home Verzeichnis

Soweit ich das als Anfänger alles verstanden habe, bringt die alternative Firmware mehr und läuft wohl auch stabiler als die Originale.
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 06 Februar 2016, 21:26:27
Media fire muss man sich nicht anmelden. Leer ist es auch nicht

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: pneuman1 am 06 Februar 2016, 22:51:43
So siehts bei mir im Browser aus.
Win 7 - Firefox 43.0.4 - Scripte erlaubt, ABP für die Seite deaktiviert.
Unter Ubuntu das gleiche Bild.
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 07 Februar 2016, 10:31:23
Das Problem hatte ich komischerweise auf meinem Windows 7 Notebook (mit Chrome) auch, auf meinem Mac (mit Chrome) wurden alle Datei angezeigt.
Keine Ahnung warum.
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 10 Februar 2016, 00:18:01
Hallo an die Runde,

ich würde gerne nochmal das Thema "Mehrere Cubes via USB" nach vorne holen. Habe ich richtig verstanden, dass dafür die Firmware mit Toolchain und angepasster Device ID neu kompiliert werden muss? Möchte einen zweiten (vorhandenen) Max! Cube gerne für LaCrosse verwenden (Ziel: die TX Temparatursensoren auszulesen zur Steuerung eines Stellantriebs der Fußbodenheizung via Max! Zwischenstecker) und den zweiten Cube ebenfalls über USB einbinden. Würde mich sehr über Tipps freuen. 

tatsu
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 10 Februar 2016, 08:12:42
Hi Tatsu,

wenn du zwei oder mehrere CUBEs via usb und FHEM nutzen möchtest. Muss jeder CUBE eine eindeutige USB-Id haben.
Sonst hast du das Problem, das du die CUBEs nicht eindeutig addressieren kannst.

Die nötige Änderung habe ich hier http://forum.fhem.de/index.php/topic,38404.msg366448.html#msg366448 (http://forum.fhem.de/index.php/topic,38404.msg366448.html#msg366448) beschrieben.

Solltest du Fragen haben, helfe ich gerne ;)

Grüße,
Stephan
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 Februar 2016, 10:34:02
Anstatt die CDCDSerialDriverDescriptors.c zu ändern kannst du einen unterschiedliche USB-ID auch in der board.h (zeile 31) einstellen:

#define USB_DESCRIPTOR_SN '1'Einfach die 1 durch ein anderes Zeichen erstetzen.
Titel: Antw:culfw@ARM
Beitrag von: CaptainHook am 10 Februar 2016, 10:50:39
Anstatt die CDCDSerialDriverDescriptors.c zu ändern kannst du einen unterschiedliche USB-ID auch in der board.h (zeile 31) einstellen:

#define USB_DESCRIPTOR_SN '1'Einfach die 1 durch ein anderes Zeichen erstetzen.

 :o Das wäre ja zu einfach  :o
Frag mal, wie lange ich nach dem anderen gesucht habe bis es bei mir lief ;)
Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 13 Februar 2016, 11:55:48
Hi,

Habe nun schon ein paar mal diese Meldung bekommen beim Versuch upzudaten:

Zitat
Willkommen zu minicom 2.7                                                     
                                                                               
Optionen: I18n                                                                 
Übersetzt am Jan  1 2014, 17:13:19.                                           
Port /dev/ttyACM0, 11:52:42                                                   
         +-----[xmodem Upload - Drücken Sie Strg-C zum Verlassen]------+       
Drücken S|angsprogramm.                                                |       
        |Ymodem Sektoren/Kilobytes gesendet: 725/90kWiederholungsversu|       
         |ch 0: Keine Bestätigung für Übertragungsende erhalten        |       
         |                                                             |       
         |Übertragung nicht abgeschlossen                              |       
         |                                                             |       
         | Fertig: Drücken Sie eine beliebige Taste zum Fortfahren ... |       
         +-------------------------------------------------------------+                                                                                   

Nehme mal an dieser Firmware kann man nun nicht vertrauen ?


ed: Version laut FHEM: version
V 1.20.04 a-culfw Build: 180 (2016-01-28_21-57-20) CUBe (F-Band: 433MHz)

PS. Ich versuche damit meine Intertechno Funksteckdosen zu belauschen, aber bis jetzt ohne größeren Erfolg.
Zitat
ccconf freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:4dB
Wenn ich in das Eventlog gehe sehe  meist genau einmal einen Befehl nachdem der Cube Strom bekommen hat. Egal wieviele Tasten ich auf dem Sender drücke.
Er hat mir einen neuen Raum "IT" mit genau einem Gerät angelegt. Egal wieviele Tasten von verschiedenen Geräten ich drücke.
(Steckdosen sind z.B. diese: http://www.pollin.de/shop/dt/MzMzOTQ0OTk-/Haustechnik/Funkschaltsysteme/Funksteckdosen_Set_mit_3_Steckdosen.html )
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 13 Februar 2016, 14:01:35
Wie schon ein paarmal hier im Thread beschrieben ist die Meldung von minicom normal. Die Übertragung ist abgeschlossen und der Arduino bootet schon neu, während minicom noch auf eine Bestätigung wartet.
Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 14 Februar 2016, 16:57:15
Danke, das bedeutet, die Firmware ist OK. Empfang von 433 MHz Funksteckdosen Signalen & co klappt trotzdem nicht.  (1 oder 10m Entfernung)

Hätte mir jemand nen Tipp ob das so passt ?
(Man sieht: Zwei Codes wurden erkannt. Vier waren mehrfach ohne andere Störsignale in der Luft in kurzem Abstand)

Zitat
define CUN1 CUL 192.168.1.31:2323 1234
attr CUN1 hmId E2D32A
attr CUN1 rfmode SlowRF
attr CUN1 room 8.00_Zentral
define IT_00FF00FFFF IT 00FF00FFFF 0F F0
attr IT_00FF00FFFF IODev CUN1
attr IT_00FF00FFFF room IT
define FileLog_IT_00FF00FFFF FileLog ./log/IT_00FF00FFFF-%Y.log IT_00FF00FFFF
attr FileLog_IT_00FF00FFFF logtype text
attr FileLog_IT_00FF00FFFF room IT
define IT_FFF0F00FFF IT FFF0F00FFF FF F0
attr IT_FFF0F00FFF IODev CUN1
attr IT_FFF0F00FFF room IT
define FileLog_IT_FFF0F00FFF FileLog ./log/IT_FFF0F00FFF-%Y.log IT_FFF0F00FFF
attr FileLog_IT_FFF0F00FFF logtype text
attr FileLog_IT_FFF0F00FFF room IT
Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 14 Februar 2016, 17:25:33
Vllt ein itclock Thema oder?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: masterpete23 am 14 Februar 2016, 17:25:51
Vllt ein itclock Thema oder?

Gesendet von meinem Huawei Honor 7

Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 20 Februar 2016, 08:43:41
Hmmm. Habe einiges hin und herprobiert. Mit itclock 400 kann ich meine Steckdosen zuverlässig schalten. Empfangen tut es diese trotzdem nur extrem selten und wenn dann nur die erste Aussendung nachdem der Cube gestartet wurde.
Titel: Antw:culfw@ARM
Beitrag von: bjoernh am 20 Februar 2016, 21:54:03
Hmmm. Habe einiges hin und herprobiert. Mit itclock 400 kann ich meine Steckdosen zuverlässig schalten. Empfangen tut es diese trotzdem nur extrem selten und wenn dann nur die erste Aussendung nachdem der Cube gestartet wurde.
Hast Du selbst kompiliert? Wenn ja, schmeiß mal testweise das Manchester raus.
Dies ist eigentlich das einzige wo ich mir als Problem vorstellen kann. Am Rest wurde schon lange nichts geändert.
Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 21 Februar 2016, 09:50:12
Hi, ich habe das fertige Binary genommen.

Soll ich mal selbst kompilieren ?
Titel: Antw:culfw@ARM
Beitrag von: Snop007 am 24 Februar 2016, 13:05:26
Hallo,

vielen Dank für den Einblick. Habe nun die 29 Seiten gelesen.

Habe noch ein paar Fragen zum Verständnis:
1.Zu den möglichen Modi
Es ist ja der Max und Homematic modus möglich.

Ist beim Max Modi die Max Software (auf dem PC) weiter nutzbar?

Oder geht die Steuerung nur über FHEM auf z.B. Rasperry Pi

Würde auch die Einbindung des Cun lediglich in meinem Handy möglich sein?


Vielen Dank 
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Februar 2016, 22:45:12
Die Max Software kann danach nicht mehr verwendet werden. Die Steuerung des Cube funktioniert dann nur noch über FHEM.

Würde auch die Einbindung des Cun lediglich in meinem Handy möglich sein?
Nein.
Titel: Antw:culfw@ARM
Beitrag von: Snop007 am 26 Februar 2016, 12:18:10
Ok, vielen Dank.

hat jemand Erfhrungen mit der Synology Diskstation 213j und der Beta, was FHEM angeht?

Oder ist es grundsätzlich sinnvoller ein Rasperry Pi für FHEM zu nutzen, wo dann der "MAX-Cube/CUN" angeschlossen wird.

Nutze gerade für ein Ambilightnachbau Openelec auf einem Rasperry. Nach Recherchen habe ich jedoch nichts finden können, wie ich da dann noch FHEM drauf bekomme --> Sprich ob das geht. Weiß das Jemand, oder hat es auch in dieser Kombination im Einsatz?
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 26 Februar 2016, 12:23:27
Openelec ist eigentlich rein auf Kodi ausgelegt und hat kein Paketmanagement. Du müsstest also alle benötigten Programme und Libs "zu Fuß" installieren.

Einfacher wäre es dann wahrscheinlich, auf Raspbian zu setzen und Kodi darauf zu installieren.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 26 Februar 2016, 17:16:41
Sprich ob das geht. Weiß das Jemand, oder hat es auch in dieser Kombination im Einsatz?

schuster bleib bei deinen leisten^^ ein pi mit openelec ist ein mediacenter, ein nas ein nas und ein stück hardware mit linux+fhem ein fhem-server.
kauf dir noch nen pi für 20-30€ und werd glücklicher als mit allem anderne gefrickel
Titel: Antw:culfw@ARM
Beitrag von: schmello am 03 März 2016, 17:48:29
Wie bekomme ich denn den Cul-Cube über Lan Fhem verbunden...
Im Wiki habe ich nur etwas über usb gefunden.
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 03 März 2016, 17:52:04
@schmello

Ich habe meinen so angeleldet....

define CUL1_LAN CUL 192.xxx.yyy.zzz:2323 1034


Gesendet von iPad mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: cdn am 08 März 2016, 19:09:59
Ist es auch möglich den Stick als RFR zu nutzen? Ich habe es probiert nur leider ist es nicht möglich den raw entsprechend zu ändern wie hier beschrieben:

http://fhemwiki.de/wiki/RFR_CUL
Titel: Antw:culfw@ARM
Beitrag von: ThommyTom am 08 März 2016, 19:55:23
Hallo zusammen,

ich bräuchte mal Eure Hilfe. Ich habe es letztendlich geschafft, meinen Cube über Bananian mit dem Bootloader zu füttern. Jetzt versuche ich vergeblich die Firmware aufzuspielen. Ente Windows habe ich keinen Erfolg, mit minicom komme ich nicht klar und bei ZTerm unter Mac OS reagiert der Cube ABER es kommt folgende Fehlermeldung:

CUBELOADER V1.01
###  Error: 6 in SerGetBuf
### Send (x) CUBE_BL.bin: 93696 bytes, 1:13 elapsed, 1270 cps, 33%

Habe mal versucht den Cube anzuschließen. Zwei LEDS leuchten dauerhaft, eine blinkt...
Leider bekomme ich keine Verbindung zum Cube. Weder über die Fritzbox oder über FHEM oder sonst wie??

Hätte jemand vielleicht eine Idee was ich machen kann?

Vielen Dank an Euch!
LG Thommy
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 März 2016, 20:15:46
Hast du es schon mal mit Tera Term unter Windows ausprobiert?
Titel: Antw:culfw@ARM
Beitrag von: ThommyTom am 08 März 2016, 21:16:12
Hast du es schon mal mit Tera Term unter Windows ausprobiert?

Habe ich auch versucht. Da habe ich das Problem, dass der Cube zwar als Cubeloader erkannt wird, aber kein Treiber geladen wird. Ich habe schon versucht das Atmen Studio zu installieren, da ich hier gelesen habe, dass das helfen könnte!?

Hm, aber das ich Windows 7 64bit in einer virtuellen Maschine nutze ist uninteressant!?

Edit:

Hmm, komisch!? Ich habe jetzt nochmals versucht den Cube unter Windows mit TeraTerm zu beschreiben. Hat jetzt ohne Probleme funktioniert. Die Firmware wurde hochgeladen, es kam diese Geräusch unter Windows wenn ein Gerät entfernt wird und zwei Sekunden später das Geräusch das ein Gerät hinzugefügt wird.

Ich habe den Cube jetzt angeschlossen und es leuchten die Battery und Internet LED dauerhaft, die Power LED blinkt.

Mal ne dumme Frage, wenn ich den Cube per Lan und per USB anschließen würde, welchen Port bevorzugt er? Ich bin gerade am Überlegen, ich versorge den Cube mit Strom eines USB Ports meiner FritzBox!? Kann das eine Auswirkung haben? Schaue ich nämlich bei der Fritzbox unter USB, steht da unbekanntes Gerät?

Gruß Thoma
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 März 2016, 21:43:57
LAN und USB könne gleichzeitig verwendet werden. Da wird nichts bevorzugt.
Titel: Antw:culfw@ARM
Beitrag von: ThommyTom am 09 März 2016, 09:24:47
Ich bin jetzt echt am verzweifeln... :-\

Ich habe die halbe Nacht damit verbracht und habe versucht Firmware auf den Cube zu bringen.

Alles wie bisher beschrieben:

Windows 7 wird der Cubeloader erkannt und nach ein wenig gefrickel habe ich da einen ComPort mit a91 to serial, dann mit TeraTerm das bin File hochgeladen. Battery und Internet leuchten durchgehend, Power blinkt. Aber ich finde den Cube nicht im Netzt. Die Fritze zeigt nur an das was in Lan2 steckt aber keine Ip oder Sonstiges...

MacOs mit ZTerm erkennt den Cubeloader, lädt die Bin hoch und spuckt am Ende nur den o.g. Fehler aus...

Jetzt habe ich Linux Mint unter Virtualbox versucht, da spuckt minicom immer nur den Fehler aus : Fehler bitte Taste drücken. Der Cubeloader wird aber ohne Probleme erkannt

Ich wäre so dankbar wenn mir einer helfen könnte? Notfalls würde ich den Cube auch jemanden zuschicken inkl. Rückporto...

LG Thoma
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 März 2016, 09:46:56
Windows 7 wird der Cubeloader erkannt und nach ein wenig gefrickel habe ich da einen ComPort mit a91 to serial, dann mit TeraTerm das bin File hochgeladen. Battery und Internet leuchten durchgehend, Power blinkt. Aber ich finde den Cube nicht im Netzt. Die Fritze zeigt nur an das was in Lan2 steckt aber keine Ip oder Sonstiges...
Das schaut doch schon so aus, als ob die Firmware erfolgreich hochgeladen wurde. Hast du danach auch probiert, den Cube über USB anzusprechen? Wenn das geht kannst du dem Cube auch manuell eine IP Adresse zuweisen: http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten)
Titel: Antw:culfw@ARM
Beitrag von: ThommyTom am 09 März 2016, 09:51:14
Oh freude, oh freude!

Ich habe es geschafft den Cube über USB anzusprechen!   :D :D

 Danke Telekatz, ich werde jetzt mal deinen Link anschauen und es weiter versuchen!!!

lg Thommy
Titel: Antw:culfw@ARM
Beitrag von: max333 am 11 März 2016, 11:11:45
Anstatt die CDCDSerialDriverDescriptors.c zu ändern kannst du einen unterschiedliche USB-ID auch in der board.h (zeile 31) einstellen:

#define USB_DESCRIPTOR_SN '1'Einfach die 1 durch ein anderes Zeichen erstetzen.

Hallo,
ich habe die Änderungen vorgenommen und neu Compiliert, jedoch scheint der CUBe nach den Flashen immer im Bootloadermodus zu bleiben. Selbst ohne Änderungen, aber selbst compilierten Code geht nichts. Habe das Ganze mit der Toolchain unter Windows gemacht.

Was mach ich falsch?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 März 2016, 11:36:01
Welche Version der Toolchain? Welches make target hast du erzeugt?
Titel: Antw:culfw@ARM
Beitrag von: max333 am 11 März 2016, 12:06:10
Ich benutze die Toolchain gcc-arm-none-eabi-5_2-2015q4-20151219-win32.exe und will nur für den CUBe das File erzeugen, dazu habe ich make im CUBe Verzeichnis gestartet.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 März 2016, 12:16:24
Nimm mal die Version 4.8 der Toolchain, die im Eröffnungspost auch verlinkt ist.
Welche der erzeugten Dateien hast du danach geflasht? CUBE.bin oder CUBE_BL.bin?
Titel: Antw:culfw@ARM
Beitrag von: max333 am 11 März 2016, 12:49:15
Bei mir wird nur eine CUBE_BL.bin erstellt, welche ich auch geflasht habe. Jedenfalls mit der 4.8 geht es jetzt, vielen DANK!
Titel: Antw:culfw@ARM
Beitrag von: cdn am 11 März 2016, 18:25:42
Ist es auch möglich den Stick als RFR zu nutzen? Ich habe es probiert nur leider ist es nicht möglich den raw entsprechend zu ändern wie hier beschrieben:

http://fhemwiki.de/wiki/RFR_CUL

Hmm ist das vielleicht untergegangen? Oder hat keiner eine Idee?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 März 2016, 19:00:39
Die RF Router Funktion habe ich mal auskommentiert, weil sie bei meinem Cube Probleme beim Betrieb mit mehreren Transceivermodulen verursacht hat. Das war einfacher, als dem Problem auf den Grund zu gehen. Aber prinzipiell müsste die Router Funktion funktionieren, wenn man sie in der board.h wieder aktiviert. Getestet hab ich die Funktion allerdings nie.
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 16 März 2016, 16:48:29
Habe jetzt den zweiten CUBE geflasht in der Hoffnung, ihn als CUN im RAW Modus für Lacrosse Sensorik verwenden zu können. Ich habe verstanden, dass ich ihn dafür in den RAW Mode mit z.B. 'SET CUN_0 RAW Nr1' versetzen muss. Siehe dazu auch https://forum.fhem.de/index.php?topic=36565 (https://forum.fhem.de/index.php?topic=36565).

Allerdings verabschiedet sich der CUBE (V 1.20.06 a-culfw Build: 199) dann kurz darauf mit folgendem Logeintrag:

2016.03.16 16:23:34 3: set CUN_0 raw Nr1
2016.03.16 16:24:00 1: 192.168.1.9:2323 disconnected, waiting to reappear (CUN_0)
2016.03.16 16:24:00 1: 192.168.1.9:2323 reappeared (CUN_0)
2016.03.16 16:24:00 3: CUN_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz

Das passiert auch mit meinem zweiten CUBE (V 1.20.01 a-culfw Build: 176, via USB):

2016.03.16 16:38:28 3: set CUL_0 raw Nr2
2016.03.16 16:38:30 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.03.16 16:38:31 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.03.16 16:38:31 1: /dev/ttyACM0 reappeared (CUL_0)

Stehe ich gerade auf der Leitung bzw. hat jemand eine Idee was da schief geht? Ich hatte gehofft, dass ich dafür nicht extra einen Jeelink Stick kaufen muss.

Ich würde natürlich ggf. mit #define LACROSSE_HMS_EMU u. lacrosse.c im Makefile etc. neu kompilieren, aber mit dem SET RAW (also RFNATIVE) sollte ich doch trotzdem ein Datenpaket vom Sensor  im Logfile sehen statt der Disconnects - oder sehe ich das falsch?

Danke für jeden Tipp!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 März 2016, 22:15:18
Mach mal folgende Änderung in rf_native.c, dann sollte es funktionieren:

diff --git a/culfw/clib/rf_native.c b/culfw/clib/rf_native.c
index 3f973c0..9e308c2 100644
--- a/culfw/clib/rf_native.c
+++ b/culfw/clib/rf_native.c
@@ -219,13 +219,13 @@
 
 
 void native_func(char *in) {
-  uint8_t mode = 0;
+  uint16_t mode = 0;
 
   if(in[1] == 'r') {                // Reception on
     
     // "Er<x>" - where <x> is mode
     if (in[2])
-      fromdec(in+2, &mode);
+      fromdec(in+2, (uint8_t *)&mode);
 
     if (!mode || mode>MAX_MODES) {
       DS_P(PSTR("specify valid mode number\r\n"));
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 16 März 2016, 22:41:20
Mach mal folgende Änderung in rf_native.c, dann sollte es funktionieren:


Wow das ging ja fix,danke erstmal :) Habs nur kurz testen können, aber scheint geholfen zu haben. Bisher kein Disconnect mehr
und ich sehe jetzt auch die Einträge die ich erwartet hätte:

2016.03.16 22:38:19 2: CUN_0: unknown message N019C45956A1CAAAA0000975273
2016.03.16 22:38:28 2: CUN_0: unknown message N019C45956A1CAAAA0000E5A23B
2016.03.16 22:38:37 2: CUN_0: unknown message N019C45956A1CAAAA00004DAC9F
2016.03.16 22:38:45 2: CUN_0: unknown message N019C45956A1CAAAA00003D8F76

Ich würde als nächstes den LACROSSE_HMS_EMU mit reinnehmen, muss ich dabei auch etwas beachten (andere Protkolle raus wg. Speicherplatz o.ä.) ?

Danke & Gruß

Tatsu
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 März 2016, 22:48:03
Speicherplatz ist beim Cube noch genügend vorhanden. Da muss man nichts raus nehmen.
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 17 März 2016, 01:46:39
Hat funktioniert  :) Ein Lacrosse Temperatursensor (TX29-IT) ist nach 'SET RAW Nr1' direkt mit Autocreate als HMS Device erkannt worden und liefert seitdem alle 10 Sekunden neue Werte. Also genau das, was ich mir erhofft hatte. Jetzt komme ich dem Ziel, meine Fußbodenheizung mit Max Zwischenstecker zu schalten anhand der Lacrosse Temparaturwerte wieder ein Stückchen näher.

Bei der Gelegenheit habe ich auch gleich eine andere USB ID mitkompiliert, warum ich mich ja sowieso noch mit der Toolchain beschäftigen wollte. Meine "make" Zeiten waren schon eine ganze Weile her ;-)

Danke nochmal Telekatz!
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 19 März 2016, 11:14:57
Ich versuche jetzt nur noch verzweifelt diese 'unknown message' Einträge wegzukriegen. Obwohl die Sensoren mit dem HMS Lacrosse Emulator eingebunden sind und im RAW Mode auch Readings erzeugt und protkolliert werden, bleiben die Unknown Einträge erhalten. Anfangs dachte ich mir noch nichts weiter dabei, aber seit dem zweiten Sensor habe ich jetzt alle paar Sekunden gleich zwei Einträge und das fhem Log wird förmlich zugemüllt damit. Mit weiteren Sensoren würde es die ja dann noch vervielfachen.  Kann ich das auch irgendwie (in der a-culfw?) unterdrücken?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 19 März 2016, 12:40:38
set CUN_0 verbose 0
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 20 März 2016, 01:05:14
set CUN_0 verbose 0

Super, danke! Da merke ich immer, wie sehr ich noch Anfänger bin. Danke für die Geduld :)
Titel: Antw:culfw@ARM
Beitrag von: Pythonf am 24 März 2016, 21:45:34
Ich habe einen HMUSB der mit hmland nicht mehr funktioniert habe. Ich wollte nun diese FW aufspielen, in der Hoffnung, dass ich den HMUSB wieder zum laufen bekomme. Ich hab die Jumper gesetzt und letztlich den Pull-UP Wiederstand verbunden. Im Geräte-Manager erhalte ich unter USB-Controller ein
Unbekanntes USB-Gerät (Fehler beim Anfordern einer Gerätebeschreibung.)Habt ihr eine Idee, was bzw. ob ich hier noch was machen kann?

Grüße
Fabian
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 25 März 2016, 10:57:06
Hast du die Jumper auch wieder entfernt?
Hast du den Widerstand nur in den USB Stecker geschoben, oder ihn auch gegen die Kontakte gedrückt, damit er sicher Kontakt hat?

Alternativ lässt sich der Bootloader auch über die serielle Debugschnittstelle ST1 aufspielen. Die Belegung von ST1 ist die Gleiche, wie beim Cube.
Titel: Antw:culfw@ARM
Beitrag von: Pythonf am 25 März 2016, 11:05:15
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?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 25 März 2016, 14:46:27
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.
Titel: Antw:culfw@ARM
Beitrag von: Pythonf am 25 März 2016, 22:40:05
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
Titel: Antw:culfw@ARM
Beitrag von: rainstormer am 27 März 2016, 21:43:01
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



Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 28 März 2016, 00:13:48
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.
Titel: Antw:culfw@ARM
Beitrag von: rainstormer am 28 März 2016, 09:33:33
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
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 März 2016, 11:42:42
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.
Titel: Antw:culfw@ARM
Beitrag von: stenny am 28 März 2016, 15:06:40
@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

Titel: Antw:culfw@ARM
Beitrag von: rainstormer am 28 März 2016, 16:02:06
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
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 28 März 2016, 18:44:10
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?
Titel: Antw:culfw@ARM
Beitrag von: rainstormer am 28 März 2016, 21:16:01
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 ;)
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 28 März 2016, 21:17:43
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:)
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 29 März 2016, 20:45:16
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?

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 30 März 2016, 12:06:00
Zu Frage 1:
Als Alternative zu SAM-BA gibt es unter Linux BOSSA: https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455 (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 (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.
Titel: Antw:culfw@ARM
Beitrag von: JSG am 01 April 2016, 10:57:05
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.
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 02 April 2016, 00:10:45
Zitat von: Christian1982
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?

Hallo Christian! Ja, das geht. Es ist aber ein wenig unkomfortabel, weil das CUL dazu in den RAW-Modus versetzt werden muss. Ich nutze das so problemlos. Allerdings muss man den RAW Modus jedes mal manuell nach fhem Start aktivieren. Vielleicht gibt es dafür aber auch schon eine Lösung (bin selber noch recht neu in Sachen fhem). Davon abgesehen sollte man genau aufs Modell schauen, die Lacrosse Sensoren gibt es optisch baugleich mit unterschiedlichen Datenraten und nicht alle sind geeignet. Das aber generell und nicht culfw spezifisch. Siehe  auch fhem wiki. Ich selbst nutze zwei Tx29 IT, zwei weitere DTH Varianten warten auf ihren Einsatz. Die Frage nach der Empfehlung würde ich so beantworten: hast du bereits einen Cube übrig oder willst ihn als CUN einsetzen, würde ich ihn dafür hernehmen und ansonsten einen JeeLink verwenden.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 02 April 2016, 21:38:18
Zitat
Vielleicht gibt es dafür aber auch schon eine Lösung
Ein notify auf global:INITIALIZED sollte helfen
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 03 April 2016, 18:23:13
reicht es für die sensoren den cul in raw mode (befehl?) zu setzen und die sensoren kommen per autocreate? bitte um info zu cul in raw als jeelink "ersatz"
Titel: Antw:culfw@ARM
Beitrag von: Tatsu am 05 April 2016, 22:37:03
reicht es für die sensoren den cul in raw mode (befehl?) zu setzen und die sensoren kommen per autocreate? bitte um info zu cul in raw als jeelink "ersatz"

Ja, es reicht in den RAW Mode zu setzen (z.B. 'set CUL_1 raw Nr1') und die Sensoren werden anschließend per Autocreate als HMS Geräte (vom Typ HMS100T) angelegt.  Hier kannst Du mehr darüber nachlesen: https://forum.fhem.de/index.php/topic,36565.0.html (https://forum.fhem.de/index.php/topic,36565.0.html)


PS: danke für den Tipp mit dem Notify, das klappt tatsächlich so :)
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 06 April 2016, 07:07:10
auf das thema bin ich auch gestoßen. aber so recht passt die anleitung nicht wie man in der aculf diese funktion aktiviert
EDIT: habs gefunden

board.h:
#define HAS_RFNATIVE
#define LACROSSE_HMS_EMU
Die Zeile muss weg oder wird auskommentiert:
//# define OFF_LACROSSE_HMS_EMU
In CUL.c dürfen diese Einträge nicht fehlen:
#ifdef HAS_RFNATIVE
#include "rf_native.h"
#endif

#ifdef HAS_RFNATIVE
  { 'N', native_func },
#endif

#ifdef HAS_RFNATIVE
    native_task();
#endif
Titel: Antw:culfw@ARM
Beitrag von: max333 am 08 April 2016, 11:36:26
Ich habe meinen Cube auch mit einer Lacrosse Firmware geflasht, mit set CUL raw Nr2 funktioniert auch alles einwandfrei, nur "vergisst" der Cube die Nr2 Einstellung in unregelmäßigen Abständen, mal empfängt er nur 30 Sekunden mal gehts 10 Minuten. Im Log ist aber auch nicht auffälliges.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 08 April 2016, 18:53:45
das liegt daran das er neu initialisiert. danach muss man raw Nr2 neu setzen. das fest per attribut zu setzen wäre natürlich geiler (wie zb den rfMode).
workaroung wäre ein notify auf [cul]:Initialized oder cul:CONNECTED

Zitat
2016-04-08 18:56:56 CUL nanoCUL868 DISCONNECTED
2016-04-08 18:57:04 CUL nanoCUL868 Initialized
2016-04-08 18:57:04 CUL nanoCUL868 CONNECTED
ich werde das setzen des raw-modes automatisch mal wünschen https://forum.fhem.de/index.php/topic,51946.0.html
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 08 April 2016, 19:03:58
Ich habe meinen Cube auch mit einer Lacrosse Firmware geflasht, mit set CUL raw Nr2 funktioniert auch alles einwandfrei, nur "vergisst" der Cube die Nr2 Einstellung in unregelmäßigen Abständen, mal empfängt er nur 30 Sekunden mal gehts 10 Minuten. Im Log ist aber auch nicht auffälliges.

könnt mir vorstellen das die lan-verbindung mal verloren geht und fhem dann die verbindung neu aufbaut.
per
define nft_culrestart notify [culname]:Initialized set nanoCUL868 raw Nr2
sollte er nach neustart sowie ab und anstecken / ein und ausschalten immer wieder raw Nr2 setzen

Titel: Antw:culfw@ARM
Beitrag von: max333 am 08 April 2016, 20:49:05
Den gleichen Fehler habe ich auch, wenn ich den Cube über USB anschließe. Ich vermute, das es ein Empfangsproblem ist und sich dann das RF-Modul aufhängt und mit Nr2 wieder neu initialisiert werden muss. Denn ich habe auch Daten dabei, die nicht decodiert werden.
Titel: Antw:culfw@ARM
Beitrag von: Fhemschorsch am 10 April 2016, 07:37:05
Da ich über die Suche nichts gefunden habe: Funktioniert das Umflashen zum CUN auch mit dem Cube von mobilcom-debitel? Der ist ja nochmal 5€ günstiger...
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 10 April 2016, 11:02:16
Da ich über die Suche nichts gefunden habe: Funktioniert das Umflashen zum CUN auch mit dem Cube von mobilcom-debitel? Der ist ja nochmal 5€ günstiger...

Ich habe diese Woche zwei umgeflasht, es stand folgendes auf der Unterseite: TRX868-TI
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 10 April 2016, 11:36:43
Da ich über die Suche nichts gefunden habe: Funktioniert das Umflashen zum CUN auch mit dem Cube von mobilcom-debitel? Der ist ja nochmal 5€ günstiger...

es gibt nur den maxcube, der rest ist alles auch nur der cube unter anderem namen. meiner war auch kein max! gelabelter.

beim cube habe ich eigentlich noch nie gehört das was andres drauf steht außer TRX868-TI. das betraf meines wissens nur den hm-cfg-usb mit den 2 varianten
Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 10 April 2016, 12:38:19
So alles Wunderbar bis jetzt am Laufen.. auch mit Zicken (Batterietausch schafte soweit abhilfe beim Anlernen). oder auch mehrmaliges Reset der Thermostaten von Max. Wobei dann auch die Credits zu neige gehen.

Positiv ist aber das ich ohne Max Software egal welche Fimware 1.0/1.3/1.5 alle Firmware der Aktoren die Korrekte Temperatur wiedergeben, was mit der Max Software nicht der fall ist. Da musset man ja Korregieren von 0.5 bis 1 Grad, Gemessen mit einen Infrarotthermometer.

Gruß 8)
Pop, Rock, s
Titel: Antw:culfw@ARM
Beitrag von: Fhemschorsch am 10 April 2016, 12:45:44
es gibt nur den maxcube, der rest ist alles auch nur der cube unter anderem namen. meiner war auch kein max! gelabelter.

beim cube habe ich eigentlich noch nie gehört das was andres drauf steht außer TRX868-TI. das betraf meines wissens nur den hm-cfg-usb mit den 2 varianten

Danke, ich hab soeben einen bestellt und werde berichten!
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 10 April 2016, 20:05:51
Wo kann man den einzeln von debitel bestellen ?
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 10 April 2016, 21:05:42
In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul.

Es gibt wohl mehrere Typen vom Cube, ich kenne jedoch nur den TRX868-TI mit CC1101 Funkmodul
Titel: Antw:culfw@ARM
Beitrag von: Fhemschorsch am 10 April 2016, 21:20:46
Wo kann man den einzeln von debitel bestellen ?

Amazon Marketplace, 34,90€ incl Versand
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 11 April 2016, 06:17:59
Es gibt wohl mehrere Typen vom Cube, ich kenne jedoch nur den TRX868-TI mit CC1101 Funkmodul

wie kommst du dann drauf das es mehrere gibt wenn du auch nur einen kennst  ;) hiere im forum wurd nie ein anderer erwähnt und im netz findet man auch nicht zu anderst gekennzeichneten
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 11 April 2016, 10:42:46
Weil der Entwickler (Telekatz) es geschrieben hat.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 April 2016, 11:48:48
Ich habe sicherheitshalber auf die Möglichkeit hingewiesen, dass es vielleicht Geräte mit anderen Funkmodulen geben könnte, weil es beim MAX Fensterkontakt irgendwann mal geändert wurde und weil diverse Homematic Geräte ein anderes Funkmodul haben.
Trotzdem wurde hier noch nie ein Cube mit anderen Funkmodul gemeldet. Scheint es also doch nicht zu geben.
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 11 April 2016, 19:42:18
Dann hätten wir das ja auch geklärt :-)

Hier mal ein interessanter Artikel zum Cube
https://www.insinuator.net/2016/04/discover-the-unknown-analyzing-an-iot-device/
Titel: Antw:culfw@ARM
Beitrag von: Fhemschorsch am 14 April 2016, 17:27:14
Eine kurze Rückmeldung: mein Mobilcom-Cube war dank der guten Anleitung problemlos zum CUL umgebaut.
Das mit dem Netzwerk will noch nicht (IP wird per Ping gefunden, aber Telnet über Port 2323 wehrt sich standhaft (Connection Refused), aber über USB geht es schonmal einsame Spitze!
Titel: Antw:culfw@ARM
Beitrag von: noice am 14 April 2016, 18:17:12
Bei mir auch perfekt geklappt und hängt schon im netzwerk ..
War auch eine Mobilcom Cube..

Wenn ich mir das so ansehe wäre bestimmt auch eine Anbindung per esp-01 und somit per wlan möglich ... nur so als Gedankenanstross

Mobil erstellt daher kurz gehalten

Titel: Antw:culfw@ARM
Beitrag von: Wzut am 15 April 2016, 16:27:40
Wenn ich mir das so ansehe wäre bestimmt auch eine Anbindung per esp-01 und somit per wlan möglich ... nur so als Gedankenanstross
den Gedanke hatte ich auch im Dezember :) Nachdem Telekatz seit einiger Zeit die Daten auch auf ST1 bereit stellt, steht dem direkten Anschluss eines ESP8266 mit transparenter Bridge nichts mehr im Wege. 
Titel: Antw:culfw@ARM
Beitrag von: Floca am 20 April 2016, 18:20:19
Hallo zusammen,
kompliment an die mitwirkenden.

Hab meinen geschossenen neuen Cube heute mal etwas gequält und umgeflasht  :D
Das ganze läuft auch in Fhem erstmal testweise, echt Prima.

Kann mir noch jemand was zu den LED's erklären und was die bewirken? Ich meine Internet ist mir noch relativ einleuchtend, aber warum blinkt Power dauerhaft im langsamen Rhytmus und Battery dauerhaft? Kann man das konfigurieren? Möchte so wenig licht wie Möglich vom Cube, oder wenn, dann Sinnvoll. Da wo er steht sieht man es eh nicht, ausser wenn man explizit nachschaut. Ich meine LED's brauchen ja auch nur unnötig Strom :)

gruß
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 20 April 2016, 22:29:53
Die Power LED funktioniert wie die LED beim CUL. Mit "set myCUL raw l00" kann die LED ausgeschaltet werden.

Die Internet LED leuchtet, wen eine LAN Verbindung vorhanden ist, die Battery LED wenn der Cube über USB Verbunden ist. Um die zu deaktivieren musst du das im Sourcecode auskommentieren (main.c und network.c).
Titel: Antw:culfw@ARM
Beitrag von: JayP am 30 April 2016, 14:15:55
Hallo zusammen,

ich habe meinen Cube geflashed und an meinen Testsystem "Raspi mit Raspian" läuft auch alles.
An meinen Produktivsystem "Odroid mit Ubuntu" wird der Cube nicht erkannt.

Ich nehme an dies ist eher ein Linux Problem.
Ich wußte aber nicht wohin damit.

dmesg
[ 3320.347816] usb 1-1.2: new full-speed USB device number 9 using dwc_otg
[ 3320.455654] ERROR::handle_hc_nak_intr:1307: Can not read device info from hub.We take it error

[ 3320.462313] ERROR::handle_hc_nak_intr:1307: Can not read device info from hub.We take it error

[ 3320.464027] usb 1-1.2: unable to read config index 0 descriptor/start: -71
[ 3320.465283] usb 1-1.2: can't read configurations, error -71
[ 3321.327856] hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 3322.187839] hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 3323.047817] hub 1-1:1.0: Cannot enable port 2.  Maybe the USB cable is bad?
[ 3323.049533] hub 1-1:1.0: unable to enumerate USB device on port 2

Danke und Gruß
Jay

Edit: Halte ich die Taste unter dem Cube beim verbinden gedrückt. Wird der Cube erkannt. (Bootloader)

Edit2: Wenn ich den Cube per IP anbinde klappt es. Hat jemand eine Idee? Es scheint ja am Ubuntu zu liegen. Kerneltreiber? Ich bin leide rnicht der Linux Experte.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 01 Mai 2016, 11:15:26
Das es ein Treiberproblem ist halte ich für unwahrscheinlich. Der Bootloader wird ja erkannt. Die a-culfw und der Bootloader verwenden den gleichen USB Sourcecode und benötigen dadurch den selben Treiber.

USB Kabel schon getauscht? Eventuell ein Wackelkontakt.
Titel: Antw:culfw@ARM
Beitrag von: gso am 01 Mai 2016, 11:34:35
Hallo zusammen,

könnte ich den Max Cube mit culfw auch unter Homematic mit CUxD über LAN anschließen und als Signalverstärkung für HM verwenden.
Falls ja gerne mit Beispiel.
VG
GSO
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 14 Mai 2016, 22:55:26
Die Power LED funktioniert wie die LED beim CUL. Mit "set myCUL raw l00" kann die LED ausgeschaltet werden.

Die Internet LED leuchtet, wen eine LAN Verbindung vorhanden ist, die Battery LED wenn der Cube über USB Verbunden ist. Um die zu deaktivieren musst du das im Sourcecode auskommentieren (main.c und network.c).

wie wird die led (Power) dann dauerhaft eingeschaltet?

Gruß!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 15 Mai 2016, 13:53:04
So wie beim CUL:
http://culfw.de/commandref.html#cmd_l (http://culfw.de/commandref.html#cmd_l)
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 15 Mai 2016, 20:11:12
Super, vielen Dank!

Jetzt kann der CUNX zum Elektroschrott. Selbst mit dieser popeligen Antenne, hat der CUBE bis zu 15 dBm bessere RSSI Werte im Vergleich zum CUNX.
Titel: Antw:culfw@ARM
Beitrag von: noice am 18 Mai 2016, 22:07:02
Super, vielen Dank!

Jetzt kann der CUNX zum Elektroschrott. Selbst mit dieser popeligen Antenne, hat der CUBE bis zu 15 dBm bessere RSSI Werte im Vergleich zum CUNX.

Ich glaube der CUNX findet hier im schwarzen Brett sicher noch einen Abnehmer  ::)
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 20 Mai 2016, 08:00:24
Ich glaube der CUNX findet hier im schwarzen Brett sicher noch einen Abnehmer  ::)

nach erster Euphorie über den CUBE musste ich feststellen dass auch dieser sich für 6 Stunden pro Tag schlafen legt. Der CUL direkt am USB scheint da doch die bessere Variante, nur bekomme ich damit leider keine 4 Etagen abgedeckt.

Gruß!
Titel: Antw:culfw@ARM
Beitrag von: max333 am 20 Mai 2016, 11:25:51
Mein Cube läuft seit mehreren Wochen stabil im Netzwerk über 3 Etagen mit fast 40 Geräten, allerdings reichten die vorgegebenen Credits niemals.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 21 Mai 2016, 08:32:39
dito, läuft stabil am netzwerk 24/7 (und das über meine alten bescheidenen powerlan-adapter). würde ehr den fehler im netzwerk suchen (sofern dein fhem aktuell ist).

Zitat
feststellen dass auch dieser sich für 6 Stunden pro Tag schlafen legt
bei dem fehlerbild würde ich den cube als quelle vernachlässigen. fhem versucht bei verbindungsverlust doch ständig den cube neu zu connecten und das schafft es nicht wenn zb der cul nicht verfügbar ist.
richte mal ein presence per lanping auf den cul ein um zu schauen ob er wirklich "aus dem lan verschwindet" oder nur die verbindung zu fhem verliert
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 21 Mai 2016, 10:00:35
Ich hab mit dem Cube dasselbe Problem - nach 6h regelmäßig disconnected, erst durch Steckerziehen am Cube behebbar. Gabs aber hier schon öfter - möglicherweise unterschiedliche Stände.
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 21 Mai 2016, 19:25:38
habe
VERSION V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
Titel: Antw:culfw@ARM
Beitrag von: max333 am 21 Mai 2016, 20:42:59
bei mir läuft:
VERSION V 1.20.06 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 22 Mai 2016, 16:14:20
dito, läuft stabil am netzwerk 24/7 (und das über meine alten bescheidenen powerlan-adapter). würde ehr den fehler im netzwerk suchen (sofern dein fhem aktuell ist).
bei dem fehlerbild würde ich den cube als quelle vernachlässigen. fhem versucht bei verbindungsverlust doch ständig den cube neu zu connecten und das schafft es nicht wenn zb der cul nicht verfügbar ist.
richte mal ein presence per lanping auf den cul ein um zu schauen ob er wirklich "aus dem lan verschwindet" oder nur die verbindung zu fhem verliert

das mache ich jetzt auch und musste feststellen, das seitdem ich den CUBE über presence abfrage ich keine Aussetzer mehr hatte.

Gruß!
Titel: Antw:culfw@ARM
Beitrag von: Markus M. am 26 Mai 2016, 12:39:34
Mein HM-CFG-USB-2 ist nach jedem Reboot des Rechners nicht mehr verfügbar.
Die LED blinkt, der CUL steht auf opened und ist nicht erreichbar bis ich die USB Verbindung trenne.

Ausserdem schaltet l00 die LED an statt aus.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 26 Mai 2016, 14:29:36
In den neuen Releases ist beim Cube nur noch der Bootloader vorhanden, Mit welcher Hex Datei wird er denn dann geflashed ?
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 26 Mai 2016, 14:56:16
Die Hex ist eine .bin.....

Also zwei bin Dateien im Cube Verzeichnis.....


Gesendet von iPad mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 26 Mai 2016, 15:20:32
Im Cubeverzeichnis ist nur eine bin Cube_BL
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 26 Mai 2016, 15:29:26
Dann schau in die 1.20.08 rein, die hatte ich auch genommen und ist bisher ohne Auffälligkeiten bei mir am Rennen.

Dein Cube hatte doch schon den Bootloader, zumindestens habe ich das so verstanden, dann brauchst du auch nur die
Software selber


Gesendet von iPad mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 Mai 2016, 19:23:44
bootloader_CUBE.bin ist der Bootloader.
CUBE_BL.bin ist die Firmware Datei, die mit dem Bootloader geschrieben wird.
Daneben kann man noch die Datei CUBE.bin erstellen, die ohne den Bootloader auf den Cube geschrieben wird.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 27 Mai 2016, 11:58:25
Hallo,

wie wird die Cube.bin erstellt ?

Ich habe Probleme auch mit minicom den Cube zu flashen. Laut Compare von Samba ist der Bootloader richtig geschrieben. Wenn ich den Cube dann an den Raspberry anschliessend blinkt für ca 30 sek die D1 danach leuchtet sie ständig.
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 27 Mai 2016, 12:12:09
Hallo,

wie wird die Cube.bin erstellt ?

Ich habe Probleme auch mit minicom den Cube zu flashen. Laut Compare von Samba ist der Bootloader richtig geschrieben. Wenn ich den Cube dann an den Raspberry anschliessend blinkt für ca 30 sek die D1 danach leuchtet sie ständig.

Hallo,

ich habe anstelle von minicom cutecom benutzt, wichtig nur dass man das Tool als sudo startet.

Gruß!

$ sudo cutecom
-> device auf mittlerweile ttyACM2 eingestellt
-> Open device
-> Send file… XModem
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 27 Mai 2016, 12:25:20
Die LED müsste doch aber blinken solange noch keine Firmware übertragen ist ???????

Kann jemand die neueste Cube.bin zur Verfügung stellen ?

Danke
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 27 Mai 2016, 12:30:04
das sollte dann die  220_master unter https://www.mediafire.com/folder/tf16radvztfd9/a-culfw sein
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 27 Mai 2016, 12:58:20
Da ist aber keine Cube.bin im Archiv
Titel: Antw:culfw@ARM
Beitrag von: DerFrickler am 27 Mai 2016, 13:55:32
im Download finde ich im Verzeichnis CUBe die Dateien CUBE_BL.bin und dann ein weiteres Verzeichnis mit dem Namen bootloader und dem File bootloader_CUBE.bin
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 27 Mai 2016, 13:58:25
Die kombinierte Datei heisst aber Cube.bin. Siehe alte Version auf Seite 3
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 Mai 2016, 21:02:04
Anbei eine aktuelle CUBE.bin.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 27 Mai 2016, 21:10:15
Danke !!!!

Kannst Du mir bitte auch sagen wie ich die eventuell selbst erstellen kann ?

Danke
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 29 Mai 2016, 11:31:49
- Toolchain aus dem ersten Beitrag herunterladen und installieren
- Sourcecode aus dem ersten Beitrag herunterladen
- Eventuell make installieren
- Optional IDE (z.B. Eclipse) installieren
- Im Verzeichnis ...\culfw\Devices\CUBe "make CUBE" ausführen
Titel: Antw:culfw@ARM
Beitrag von: mveltrup am 29 Mai 2016, 20:35:19
Könnte mir jemand bitte mal jemand eine Firmware mit lacrosse Unterstützung kompiliert hochladen?

Bekomme den toolchain nicht installiert und kenn mich nicht so aus.
Titel: Antw:culfw@ARM
Beitrag von: max333 am 01 Juni 2016, 07:36:16
Ich kann nur davon abraten den Cube mit LaCrosse zu betreiben. Er verliert im LaCrosse-Modus laufend die Verbindung. Viel zuverlässiger läuft der LaCrosseGateway.
Titel: Antw:culfw@ARM
Beitrag von: mveltrup am 01 Juni 2016, 14:49:02
Danke. Hab ich auch bemerkt und jetzt einen Jeelink angeschlossen.
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 25 Juni 2016, 21:23:52
Hallo Zusammen
Zunächst mal meine Hochachtung den Beteiligten zu diesem Projekt und der Portierung.

Ich betreibe mein FHEM mit zwei Selbstbau nanoCUL (433MHz & 868MHz). Lange habe ich nach einem Vorschlag für Netzwerksanbindung über einen CUN gesucht (für einen abgelegenen Raum) und bin nicht fündig geworden. Da bin ich auf das Projekt gestoßen, habe einen MAX! Cube beschafft und geflasht.
Hat im Prinzip gut geklappt (nur den Bootloader musste ich unter Linux flashen, die ATMEL Windows Version hat bei mir gezickt).

Nun zu meinen Fragen:
1)
Mit der CulFW (CUBE_BL.bin) läuft der Cube auf 868MHz, kann aber 433MHz Intertechno Kommandos absetzen wie alle CUL's.
Ich habe irgendwo mal einen Beitrag gelesen (finde ihn nicht wieder), dass beim Umschalten intern jedesmal das EEPROM umprogrammiert wird und die Anzahl der Schreibvorgänge ist ja "endlich".
Hat jemand Erfahrung damit und kann das bestätigen? Oder ist das Quatsch und lediglich Register des CC1101 werden temporär umgesetzt ohne das EEPROM zu beschreiben?

2)
Würde es für einen 433MHz-Betrieb reichen einfach per "set freq" aus FHEM die Frequenz auf 433MHz zu setzen. Mit dem hoffentlich positiven Nebeneffekt, dass auch auf dieser Frequenz empfangen wird.

3)
Beim nanoCUL kann in der "board.h" über ein "define" bestimmt werden, dass beim make statt 868MHz eine 433MHz CUL kompiliert wird.
(beide nanoCUL Varianten sind in den kompilierten BIN https://www.mediafire.com/folder/tf16radvztfd9/a-culfw enthalten)
   /* if you are using a CC1101 module for 868MHz disable the next line */
   /* #define HAS_CC1100_433 */

Für den Cube ist das in der "board.h" nicht vorgesehen. Gibt es die Variable?


Vermutlich würde ich es allerdings nicht schaffen mit der Toolchain die Variante auch zu kompilieren.
Ist es möglilch für den Cube beide Varianten in den BIN's anzubieten?

viele Grüße Ralf
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 Juni 2016, 10:42:35
1. Das EEPROM wird nur beschrieben, wenn die Frequenz dauerhaft mit "set freq" umgestellt wird. Beim temporären Umschalten für Intertechno wird das EEPROM nicht geändert.

2. Es kann dann zwar 433MHz empfangen werden, aber nicht besonders gut.

3. Die zwei verschiedenen Varianten gibt es, weil der nanoCUL zu wenig Speicher hat um alle Protokolle unterstützen zu können. Es werden jeweils nur die Protokolle hineinkompiliert, für die der Empfänger auch geeignet ist. Da der Cube mehr Speicher hat sind dort alle Protokolle enthalten.
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 26 Juni 2016, 22:11:06
Danke für die Antwort

Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 01 Juli 2016, 21:43:04
Kurzer Nachtrag zur Reichweite des 868er Cubes bei 433 Mhz.
Es reicht zumindest um im Raum bzw. im Geschoß die IT-Schaltsteckdosen anzusprechen.
Damit konnte ich mein Ziel erreichen einen abgelegenen per LAN erreicharen Raum zu steuern .

Titel: Antw:culfw@ARM
Beitrag von: Aladin222 am 02 Juli 2016, 06:29:47
Hi @all ,

auch ich habe meinen Cube zum Cuno geflasht :

list

Internals:
   CFGFN      /opt/fhem/FHEM/02_CulMaxCube.cfg
   CMDS       BbCFiAZNEkGMKLUYRTVWXefltxz
   CUL_HM_Cube_MSGCNT 1
   CUL_HM_Cube_TIME 2016-07-02 06:04:10
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        192.168.178.56:2323 1234
   DeviceName 192.168.178.56:2323
   FD         15
   FHTID      1234
   NAME       CUL_HM_Cube
   NR         93
   PARTIAL
   RAWMSG     A0FCA861022E2610000000AB0FE0F0058DB
   RSSI       -92.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
   initString X21
Ar
   owner_CCU  VCCU
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-04-25 21:55:30   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2016-07-02 06:02:58   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f l t x z
     2016-06-18 23:28:40   credit10ms      900
     2016-04-25 21:55:44   fhtbuf          AE
     2016-07-02 06:04:10   state           Initialized
     2016-06-18 04:16:40   uptime          No answer
     2016-06-18 04:07:49   version         V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
Attributes:
   hmId       1AA777
   icon       cul_cul
   model      CUL
   rfmode     HomeMatic
   room       CUL_HM

Im Logfile kommen immer wieder mal folgende Einträge : ( ca alle 2 Stunden )

2016.07.02 03:07:24 1: 192.168.178.56:2323 disconnected, waiting to reappear (CUL_HM_Cube)
2016.07.02 03:07:24 3: CUL_HM_Cube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.02 03:07:24 1: 192.168.178.56:2323 reappeared (CUL_HM_Cube)


muss ich mir da Sorgen machen ? Wenn ich das richtig verstehe ,ist der CUNO öfter offline , oder ?
Titel: Antw:culfw@ARM
Beitrag von: janvonnebenan am 02 Juli 2016, 15:08:39
Vielen Dank für die tolle Arbeit!

Den Fehler bei der Netzwerkanbindung des MaxCubes kann ich allerdings bestätigen. Im Logfile:
2016.07.02 12:05:34 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:38 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:43 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:48 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:53 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:58 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:03 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:08 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:13 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:18 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:23 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:28 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:33 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:38 3: MaxCube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.02 12:06:38 2: Setting CUL fhtid from 1034 to 0000
2016.07.02 12:06:38 1: 192.168.178.59:2323 reappeared (MaxCube)
2016.07.02 12:06:49 1: 192.168.178.59:2323 disconnected, waiting to reappear (MaxCube)
2016.07.02 12:06:49 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:51 3: MaxCube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.02 12:06:51 1: 192.168.178.59:2323 reappeared (MaxCube)

Verbinde ich mich mit Telnet, ohne dass fhem mit dem MaxCube verbunden ist, fällt auf, dass er immer wieder den Versionsstring ausgibt:
root@myserver ~ # telnet 192.168.178.59 2323
Trying 192.168.178.59...
Connected to 192.168.178.59.
Escape character is '^]'.
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)

Ich denke, dies ist das Problem. Der MaxCube startet nicht neu, aber der Netzwerkstack glaubt ein "V" empfangen zu haben, wahrscheinlich ist er in dieser Situation auch nicht ansprechbar, was zu "MaxCube did not answer request for current credits." führt.

Ich habe den MaxCube jetzt über USB angeschlossen und alles ist gut.

Herzliche Grüße
Jan
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 02 Juli 2016, 18:26:23
@Aladin222 & janvonnebenan
Ich setze den Cube seit ca. 10 Tagen ein. Ich habe keine LOG Einträge hinsichtlich LAN Verbindung.
Version :     V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 868MHz)

@Telekatz
Nochmal zu einem Teil meiner Frage 2 vom 25.6
Ich kann prima schalten bei 433Mhz (im Raum) aber trotz setzen der Frequenz auf 433 Mhz (freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB) empfange ich vom Handsender keine Signale - egal welcher Abstand. Der Event Monitor loggt nichts.
Mache ich einen Denkfehler?

Gruß Ralf
Titel: Antw:culfw@ARM
Beitrag von: Aladin222 am 02 Juli 2016, 19:04:10
@janvonnebenan ,

Ok , das heißt schonmal ich war nicht zu doof :-)
Allerdings macht es das ganze nun nicht wirklich besser für mich ,da ich gerade die LAN-Anbindung haben wollte :-(

Titel: Antw:culfw@ARM
Beitrag von: janvonnebenan am 02 Juli 2016, 19:09:41
Vielleicht ist es ja ein Problem von Version 1.21.00. Ich werde mal die ältere Version (1.20.08) testen.
Titel: Antw:culfw@ARM
Beitrag von: Aladin222 am 02 Juli 2016, 19:13:19
Hab gerade nochmal nachgesehen :

Bei mir
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)

Vielleicht bringt das ja was .... puhhh müsste ich mich wieder einlesen wie das ging *snief
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 02 Juli 2016, 19:13:51
Ich hab das Problem kaum noch, seit ich für den Cube ein Presence gesetzt hab - offebar mögen manche davon regelmäßig angepingt werden. :)
Titel: Antw:culfw@ARM
Beitrag von: Aladin222 am 02 Juli 2016, 19:16:53
@rubbertail, könntest du das bitte nochmal etwas genauer beschreiben ?
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 02 Juli 2016, 19:39:06
PRESENCE-Modul in Betrieb nehmen, IP des Cube auf presence testen. Für PRESENCE nach commandref vorgehen ;)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Juli 2016, 11:30:46
@Telekatz
Nochmal zu einem Teil meiner Frage 2 vom 25.6
Ich kann prima schalten bei 433Mhz (im Raum) aber trotz setzen der Frequenz auf 433 Mhz (freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB) empfange ich vom Handsender keine Signale - egal welcher Abstand. Der Event Monitor loggt nichts.
Mache ich einen Denkfehler?
Sollte eigentlich funktionieren. Setz mal alles mir "raw e" alles zurück und und stell die Frequenz nochmal ein.
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 03 Juli 2016, 19:32:11
Hallo, danke für die Idee  (Update 40 Minuten später)

Zitat
Sollte eigentlich funktionieren. Setz mal alles mir "raw e" alles zurück und und stell die Frequenz nochmal ein.

Gesagt getan, set freq 433 MHz, meinen nanoCUL ausgesteckt, Handsender benutzt
Per Autcreate werden keine neuen Devices angelegt - wäre zu erwarten gewesen. Mit Verbose 5 wird folgendes ins FHEM-Log geschrieben:

....
2016.07.03 18:43:23 3: nanoCUL1: Unknown code i11155f, help me!
2016.07.03 18:46:57 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:46:57 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:27 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:27 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:57 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:57 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:27 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:27 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:57 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:57 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:28 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:28 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:58 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:58 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:59 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00F4TK-if00-port0 disconnected, waiting to reappear (nanoCUL1)
2016.07.03 18:50:28 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
....
Update
2016.07.03 19:22:43 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:22:43 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:22:57 5: SW: C0D
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C0D = 10 / 16
2016.07.03 19:22:57 5: SW: C0E
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C0E = A7 / 167
2016.07.03 19:22:57 5: SW: C0F
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C0F = 62 / 98
2016.07.03 19:22:57 5: SW: C10
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C10 = 57 / 87
2016.07.03 19:22:57 5: SW: C1B
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C1B = 07 /  7
2016.07.03 19:22:57 5: SW: C1D
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C1D = 90 / 144
2016.07.03 19:23:22 5: SW: V
2016.07.03 19:23:22 5: CUL/RAW (ReadAnswer): V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:23:52 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:23:52 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)

Das scheint mir auf Empfang hinzudeuten aber nicht korrekt dekodiert zu werden, oder?
Update: die Meldungen kommen permanent alle 30 sec, die Werte 19:22 einmalig

Hier die Details vom Cube
Internals
CMDS    BbCFiAZNEkGMKLUYRTVWXefltxz
Clients  :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY::STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF      cube.fritz.box:2323 0000
DeviceName  cube.fritz.box:2323
FD        12
FHTID   0000
NAME   cubeCUL1
NR       29
PARTIAL
STATE   Initialized
TYPE    CUL
VERSION   V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 868MHz)
initString   X21

Readings
ccconf    freq:433.000MHz bWidth:325KHz rAmpl:42dB sens:4dB      2016-07-03 19:22:57
cmds     B b C F i A Z N E k G M K L U Y R T V W X e f l t x z                 2016-07-03 18:34:54
raw       is0F0F0FFF0FF0                                                                     2016-07-03 01:00:03
state    Initialized                                                                               2016-07-03 18:34:54
uptime 0 19:57:12                                                                             2016-07-02 17:58:53
version  V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 03 Juli 2016, 21:25:55
Hallo Telekatz
Ich wollte jetzt nicht nochmal die Antwort oben editieren.

Ich denke der Cube hat aufgrund von Funktelegrammen nichts geschickt.
Die Meldungen scheinen der Beobachtung von janvonnebenan mit Telnet zu entsprechen.
Ich konnte das ebenfalls per tcpdump bei aktiver Einbindung in FHEM nachvollziehen. Alle 30 sec schickt der Cube die Meldung raus.

Gruß Ralf
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Juli 2016, 22:47:10
Die Versionsmeldungen alle 30 Sekunden sind sind normal und beabsichtigt:
https://forum.fhem.de/index.php/topic,36529.msg289490.html#msg289490 (https://forum.fhem.de/index.php/topic,36529.msg289490.html#msg289490)
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 04 Juli 2016, 20:45:25
Zitat
Die Versionsmeldungen alle 30 Sekunden sind sind normal und beabsichtigt:
Gut zu wissen  :) - beantwortet damit auch die Telneterfahrung von janvonnebenan

Ich habe gerade an meinem Test-Raspi den Cube per USB angeschlossen und auf 433MHz gestellt. Macht keinen Unterschied zur LAN-Anbindung - es kommt nichts.
Zusätzlich habe ich per RAW Message statt X21 mal X67 (commanref sagt debugging für den CUL) gesetzt. Ich bekomme einfach keine Meldungen.

Bei meinem nanoCUL sieht es mit X67 dann so aus:
...
2016.07.04 20:40:26 5: CUL/RAW: /p 7
2016.07.04 20:40:26 5: CUL/RAW: p 7/  224 1008  912  352  1
2016.07.04 20:40:26 5: CUL/RAW: p 7  224 1008  912  352  1/  3 0 0F 110554
2016.07.04 20:40:26 4: CUL_Parse: nanoCUL1 p 7  224 1008  912  352  1  3 0 0F 110554
2016.07.04 20:40:26 2: nanoCUL1: unknown message p 7  224 1008  912  352  1  3 0 0F 110554
...

Mal sehen ob ich irgendwo einen FS20 Sender leihen kann. Will mal sehen ob wenigsten bei 868MHz empfangen wird.
Titel: Antw:culfw@ARM
Beitrag von: janvonnebenan am 07 Juli 2016, 15:47:05
So ich habe jetzt mal einiges getestet.
1. Es hat nichts mit der Firmwareversion zu tun.
2. Die Keepalive-Funktion steht mit dem Fehler auch nicht im Zusammenhang. Ich habe sie deaktiviert und mir eine eigene Firmware erstellt.
3. Ein regelmäßiger Ping hilft auch nicht.

Ich habe mal des Verbose vom CUL und CUL_MAX auf 5 gesetzt.
2016.07.07 14:47:41 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:42 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:42 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:43 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:43 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:44 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:44 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:44 5: CUL_MAX_SendQueueHandler: Retry 0868fe for 0f5b04031234560868fe0010070e6fe9 count: 3
2016.07.07 14:47:47 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:47 5: SW: X
2016.07.07 14:47:50 1: 192.168.178.59:2323 disconnected, waiting to reappear (MaxCube)
2016.07.07 14:47:50 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.07 14:47:53 5: SW: V
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): V 1.21.01 a-culfw Build: Jans private build (2.7.2016) CUBe (F-Band: 868MHz)^M

2016.07.07 14:47:53 5: SW: ?
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l t x z^M

2016.07.07 14:47:53 3: MaxCube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.07 14:47:53 5: SW: X21
2016.07.07 14:47:53 5: SW: Zr
2016.07.07 14:47:53 5: SW: Za123456
2016.07.07 14:47:53 5: SW: Zw111111
2016.07.07 14:47:53 5: SW: T01
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): 0000^M

2016.07.07 14:47:53 5: GOT CUL fhtid: 0000
2016.07.07 14:47:53 1: 192.168.178.59:2323 reappeared (MaxCube)
2016.07.07 14:47:53 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:53 5: SW: X
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): 21 1807^M

und einen tcpdump gemacht. Auffällig ist, dass der letzte Befehl bevor das "X" gesendet wird zwei TCP-Retransmits auslöst. Anbei mal das tcpdumpfile für Wireshark. Vielleicht kann da ja jemand etwas zu sagen. Möglich aber, dass das Problem nur bei einigen Max-Installationen auftritt. Ich habe zum Beispiel 29 Max-Geräte.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 12 Juli 2016, 16:24:07
Hallo,

nochmal eine Frage:

Beim Flashen mit minicom muss welches Protokoll ausgewählt werden ?

Danke
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 Juli 2016, 18:36:35
Es wird das XModem Protokoll verwendet.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 25 Juli 2016, 01:23:49
Was mir bei der 21er Version aufgefallen ist und was ich mit den 20er Versionen nicht hatte, das nach einer Zeit meist 3 bis 4 Tagen anstatt Initialisiert in der Fhem Software dort Open bei CUNO(Cube) steht. Ab da ist der Cube auch nicht mehr erreichbar. Das hab ich auch nicht nur einmal gehabt sondern immer wieder in Regelmässigen abständen. Wenn ich Fhem dann neu starte ist wieder alles in Butter. Und was mir vorkommt, das die Sendeleistung  wodurch auch immer nicht so Stark ist wie bei den 20er Versionen .. evtl. einbildung , aber vorher musste ich den Cube nicht auf dem schreibtisch verstellen um die Funksteckdosen in gelegenden Ecken zu erreichen. Ich werde wieder auf die letzte 20er Version wechseln.

Gruß
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 25 Juli 2016, 20:42:55
Verwendest du den Cube für slowRF auf 433MHz? Und wie hast du den Cube angeschlossen? Über USB oder Netzwerk?

Es gibt zwar in der Version 1.21.00 eine Änderung im IT Empfangsteil, der beim Cube nicht so ganz passt, aber das sollte keine Auswirkung auf die Stabilität haben. Und an der Sendeleistung wurde nichts geändert.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 29 Juli 2016, 00:03:38
Hallo Telekatz,
Ich benutze den Cube im rfmode MAX, nur zum Senden von Intertechno schalte ich kurz auf 433 Mhz Slow RF.
Angeschlossen ist der Cube über Netzwerk an einer Fritzbox 7490 woran wieder ein Rasberry 2 hängt.

Und heute wieder nach 3 Tagen steht wieder Open als Status beim Cuno (Cube). Dort muss ja Initialized stehen.
Gruß
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 29 Juli 2016, 20:05:11
Mal sehen ob ich irgendwo einen FS20 Sender leihen kann. Will mal sehen ob wenigsten bei 868MHz empfangen wird.

Das hat zwar ne Weile gedauert aber ich habe nen FS20 Handsender.
Verbose 5 - es kommt nichts. ALso  nicht nur bei 433MHz sondern auch nicht bei 868 MHz im SlowRF.
Senden sprich schalten bei 433 läuft....

Ich setze mich nachher nochmal mit der CUL Command Referenz auseinander (hinsichtlich wie schalte ich Empfangsbetrieb ein).
Und mach das gleiche mal mit dem zweiten Cube.

Gruß Ralf
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 29 Juli 2016, 22:41:04
Na da hätte ich auch früher drau f kommen können.


Da sieht sehr nach Defekt im Empfangsteil aus. Testhalber flash ich ihn nochmal.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 01 August 2016, 22:02:04
Hallo Telekatz, werd jetzt auf die 20er Version wechseln, das Problem ist definitiv abhängig von der 21er Version. ca 48 Stunden steht dort Open statt Initalized.
Gruß
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 August 2016, 10:13:16
Welche der 20er Versionen verwendest du dann?
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 03 August 2016, 22:39:06
Definitiv ist die Emfpangsrichtung defekt.
Das RF Modul ist händisch aufgelötet und scheint den gängigen 868MHz Chinamodulen zu entsprechen. Könnte man mal versuchsweise ersetzen... aber ich brauch ja nicht empfangen.
@Telekatz ist einer der GD-Pins ein Interrupt für die Empfangsrichtung. Der ganze HF-Teil muss ja in Ordnung sein.

Info:
Seit 30.7 läuft besagter Cube über LAN und ist initialized. Steuert auch jeden Abend brav die Terasse (Intertechno).
VERSION: V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
state: Initialized  2016-07-30 13:54:30
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 August 2016, 11:05:59
Bei slowRF wird über GDO2 das demodulierte Signal ausgegeben und über einen Pin change Interrupt ausgewertet. Ansonsten wird über GDO2 der Empfang eines neuen Pakets signalisiert.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 12 August 2016, 22:35:12
Habe jetzt mal beim Cuno (CUBE) get raw und get credits angecklickt was vorher rot in den Readings stand ohne angaben. Seit dem scheint der Open effeckt weg zu sein. Werde weiter ein Auge drauf haben.
Titel: Antw:culfw@ARM
Beitrag von: raspklaus am 02 September 2016, 08:57:39
Ich versuche gerade einen neuen Cube ohne Bootloader mit minicom zu flashen. ttyACM0 wird erkannt, aber mit xmodem kommt es beim flashen nur zu timeouts.

Wie bekomme ich den Cube trotzdem ans Laufen ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 September 2016, 11:44:03
Du musst erst den Bootloader mit SAM-BA oder BOSSA flashen. Über xmodem funktioniert es nur, wenn der Bootloader schon drauf ist.
Titel: Antw:culfw@ARM
Beitrag von: hietzi am 20 September 2016, 14:32:39
Ich verzweifle gerade.
Habe den Cube erfolgreich geflasht... läufft auch alles nur ich komm mit den Credits einfach nieeee aus
Kann mir einer erklären wie ich die firmware unter linux am besten selbst neu erstellen kann ?

Log
Bei 7 Thermostaten und einem Zwischenschalter
2016.09.20 14:22:03 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:22:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:23:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:23:52 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:24:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:25:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:25:42 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:26:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:27:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:27:31 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:28:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:29:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:29:22 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds.
2016.09.20 14:30:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:31:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:31:10 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:32:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:33:00 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:33:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no

thx und lg

Titel: Antw:culfw@ARM
Beitrag von: hietzi am 20 September 2016, 21:18:32
Kann es sein das der geflashte Cube Credits verbratet wo er das nicht sollte.

Ich habe folgendes Script am lauffen

#############Kontrolle der Gastherme ueber MAX-Schaltkontakt Beginn##################
#### Heizung: Winterbetrieb Sommerbetrieb
define HA_Heizung_Modus dummy
attr HA_Heizung_Modus alias Betriebsmodus
attr HA_Heizung_Modus fp_Heizung 36,220,7,
attr HA_Heizung_Modus group Betriebsmodus
attr HA_Heizung_Modus room Haus
attr HA_Heizung_Modus setList state:Winter,Sommer
attr HA_Heizung_Modus userReadings HCS_TEMP { if (ReadingsVal("HA_Heizung_Modus","state","Unbekannt") eq "Winter"){return 0} else {return 30};;}
attr HA_Heizung_Modus webCmd state
#Versuch mit HCS-Modul
define HCS_System HCS HA_Heizung_Schalter
attr HCS_System alias Heizungssteuerung
attr HCS_System deviceCmdOff desiredTemperature on
attr HCS_System deviceCmdOn desiredTemperature off
attr HCS_System event-on-change-reading state,devicestate,eco,overdrive
attr HCS_System exclude HA_Heizung_Schalter
attr HCS_System idleperiod 5
attr HCS_System interval 1
attr HCS_System loglevel 3
attr HCS_System mode valve
attr HCS_System room System
attr HCS_System sensor HA_Heizung_Modus
attr HCS_System sensorReading HCS_TEMP
attr HCS_System sensorThresholdOff 20
attr HCS_System sensorThresholdOn -1
attr HCS_System thermostatThresholdOff 0.5
attr HCS_System thermostatThresholdOn 0.5
attr HCS_System valveThresholdOff 10
attr HCS_System valveThresholdOn 40
#############Kontrolle der Gastherme ueber MAX-Schaltkontakt Ende####################

Mit dem nicht geflashten Cube fragte das Script zwar auch immer die valve Position jede Minute ab es ginge aber keine Credits flöten.
Mit dem geflashten Cube sobald ich das Script aktiviere und dieses die Thermostate abfragt dauter es keine 2 Minuten und die Credits sind weg.

Jemand ne Idee woran das liegen könnte?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 September 2016, 18:37:28
Schon mal das hier ausprobiert:
https://forum.fhem.de/index.php/topic,37980.0.html (https://forum.fhem.de/index.php/topic,37980.0.html)

Ansonsten würde ich mal im entsprechenden Unterforum für MAX oder HCS nachfragen. Mit der a-culfw Firmware hat das nicht direkt was zu tun.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 03 Oktober 2016, 06:12:22
Noch mal das Problem mit der Intitialsieung des Cube (Cuno) in Status Meldung.

Also mir scheint das der Taster den ich vorher eine Zeitlang nicht gebraucht habe, womit ich jetzt das Licht einschlalte für die Beleuchtung der Arbeitsplatte in der Küche das Open manchmal erzeugt. Den habe normal eingebunden ohne irgendwelche extras. Seit dem vermute ich wenn ich denn zwei bis dreimal drücke erscheint dann das Open bei als letzer Status beim Cube (Cuno) was sonst bei den Heizkörperthermostaten nicht Passsiert oder bei sonstigen Funksteckdosen. Mit dem Max Taster Steuere ich die Beleuchtung einer Funksteckdose. Diese machen in der Regel mit der Intertechno Fernbedienung oder gesteuert von Der Fhemsoftware keine Probleme. Werde mal Versuchen die Tage ein Log mit zu Schneiden.

Noch mal zur Erinnerung , wenn dort ein Open steht , geht garnix mehr. Dann muss ich die Fhemsoftware neustarten, dann gehst wieder. Damit der Status wieder auf Initialized steht.

Gruß
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 03 Oktober 2016, 15:17:52
Wenn du den Cube mit

attr <cubename> verbose 5

dazu bringst, alles, was er so tut, ins Log zu schreiben, und dann diesen Taster wiederholt drückst, so dass das Fehlerbild passiert - was findest du dann im Log?
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 07 Oktober 2016, 07:10:18
Sorry hatte zu tun, werde berichten.

Gruß
Titel: Antw:culfw@ARM
Beitrag von: JayP am 10 Oktober 2016, 22:52:43
Bei mir taucht leider auch ständig diese Meldung auf. :-(

2016.10.10 22:50:16 1: 192.168.178.23:2323 disconnected, waiting to reappear (Cube433)
2016.10.10 22:50:17 1: 192.168.178.23:2323 reappeared (Cube433)

Der Cube ist zwischendurch einfach weg.

Antwort von 192.168.178.23: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=4ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.23: Bytes=32 Zeit=8ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=4ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=17ms TTL=128

EDIT: Hat sich erledigt. Die Stromversorgung des Cube war nicht ausreichend. Mit einem anderen Netzteil habe ich keine Probleme mehr.
Titel: Antw:culfw@ARM
Beitrag von: Haui74 am 18 Oktober 2016, 16:06:41
Könnte bitte jemand eine Schritt-für-Schritt Anleitung für die Installation der Toolchain auf einen Pi posten?! Ich bekomm das irgendwie nicht auf die Reihe. :o :-[

Danke!!  :)

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 18 Oktober 2016, 17:29:20
Wieso willst du die Toolchain auf einen Pi Installieren? Die Firmware auf einem Pi zu erstellen ist doch total unkommod. Da nimmt man doch einen PC.

Desweiteren readme der Toolchain befolgen:
https://launchpadlibrarian.net/186123405/readme.txt (https://launchpadlibrarian.net/186123405/readme.txt)
Titel: Antw:culfw@ARM
Beitrag von: Haui74 am 18 Oktober 2016, 18:23:30
Habs aufm PC installiert, da bekomme ich immer die Fehlermeldung: "Das System kann den angegebenen Pfad nicht finden.". Muss man da noch was anpassen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 18 Oktober 2016, 19:54:04
Ja, der Pfad zum .../4.8/bin Verzeichniss der Toolchain muss zur PATH Systemvariable hinzugefügt werden.

Alternativ kann der Pfad im Makefile eingetragen werden (ARMBASE und ARMPATH):
###############################################################
#####
##### PATHS (default installation)
#####
##### You can put your path-config into Makefile.local
##### to override these defaults
#####
###############################################################

ARMBASE = F:/GNU_Tools_ARM_Embedded/4.8
INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-
OPENOCDPATH = F:\Tools\OpenOCD
OPENOCD = $(OPENOCDPATH)\openocd.exe -f $(OPENOCDPATH)\target\sam7x256.cfg -f $(OPENOCDPATH)\interface\uniprog.cfg

GENDEPFLAGS = -MMD -MP -MF .dep/$(@F).d
Titel: Antw:culfw@ARM
Beitrag von: Haui74 am 19 Oktober 2016, 13:32:17
Ich kapituliere... :'( Habe jetzt alles durch,hab es sogar mit der 5.4 versucht, aber ich bekomme immer eine Fehlermeldung >:(
C:\culfw\a-culfw-master\culfw\Devices\CUBe>make CUBE
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
make OUTPUT=CUBE target
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
make[1]: Entering directory `C:/culfw/a-culfw-master/culfw/Devices/CUBe'
C:/GNUTools/5.4/bin/arm-none-eabi-gcc -mcpu=arm7tdmi-s -Wall -Wno-strict-aliasing -Wno-unused-but-set-variable -mlong-calls -ffunction-sections -std=c99 -Dflash -DCUBE -DTRACE_LEVEL=4 -DDBGU_UNIT_IN -g -MMD -MP -MF .dep/main.o.d -Os -I. -I../.. -I../../at91lib -I../../at91lib/usb -I../../clib -I../../at91lib/avr -I../../avr-uip/uip -I../../avr-uip -IC:/GNUTools/5.4/arm-none-eabi/include  -c -o main.o main.c
main.c:471:1: fatal error: opening dependency file .dep/main.o.d: No such file or directory
 }
 ^
compilation terminated.
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `C:/culfw/a-culfw-master/culfw/Devices/CUBe'
make: *** [CUBE] Error 2

Edit: Wert der "PATH": C:\GNUTools\5.4\bin\;C:\GnuWin32\bin
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 19 Oktober 2016, 14:25:57
Versuch mal den Ordner .dep im Verzeichnis C:\culfw\a-culfw-master\culfw\Devices\CUBe manuell anzulegen.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 19 Oktober 2016, 14:38:18
Ich hab die Firmware zwar noch nie unter Windows kompiliert, aber auf dem Pi ist es auch kein Problem.

Hier mal mein Post vom letzten Jahr:

P.S.: Zum Kompilieren habe ich folgendes Makefile.local erstellt:
###############################################################

INCLUDEPATH = /usr/lib/arm-none-eabi/include
LIBPATH = /usr/lib/arm-none-eabi/lib
#ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-

######################## EOF ##################################

Dazu habe auf dem Pi noch binutils-arm-none-eabi und gcc-arm-none-eabi installiert.
Titel: Antw:culfw@ARM
Beitrag von: Haui74 am 19 Oktober 2016, 15:04:50
Hat funktioniert! ;D Es war der fehlende .dep Ordner und es geht nur mit der 4.8!

Danke für die Hilfe Telekatz! :)
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 21 Oktober 2016, 17:36:57
Hallo in die Runde,
habe gerade versucht meinen Cube  zu flshen, ohne Erfolg.
Der im 1. Post beschriebene Link zu SAM-BA kann ich nach dem download nicht starten.
Es kommt kurz die Commandline, schwarzes Fenster dann war es.
Nach einigen google versuchen fand ich SAM-BA v2.8.
Nach dem Start com und AT91SAM7S256-EK ausgewählt, kommt die Fehlermeldung:no valid Prozessor id found
Auf dem Cube nachgesehen und ein AT91SAM7S512-AU drauf >:(
Den kann ich leider nicht im Menü auswählen.
Nun zu meiner Frage, hat schon einer von euch einen solchen Prozessor gehabt? Wenn ja mit welchen Programm unter windows.
Ist doch eigentlich nur ein gröserer speicher drauf?
Wäre schön eine Hilfe zu bekommen....
Danke Heiko
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 22 Oktober 2016, 12:32:38
Ich denke nicht, dass du einen AT91SAM7S512-AU hast. Diese Serie hat kein Ethernet. Du hast einen AT91SAM7X512-AU . Dafür wählt man at91sam7x512-ek in SAM-BA aus.
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 22 Oktober 2016, 16:54:55

Hallo,
Zunächst einmal vielen Dank für deine Arbeit. Mein Respekt,super.
sorry ist ein x512. Andere Lupe genommen.
Welche SAM-BA Version nutzt du? Habe die 3.1.4 versucht.
Die ging nicht bei mir. Habe Win7 64Bit
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 22 Oktober 2016, 17:21:40
Ich verwende v2.15. Und gestartet werden muss SAM-BA mit Administratorrechten.
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 22 Oktober 2016, 17:59:36
Ich meine, Sam-ba 3.x ist ein reines CLI-Tool.
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 23 Oktober 2016, 11:36:25
Jas das mit Adminrechten ist schon klar, habe ich auch gemacht.
Scheinbar habe ich eine Version, die nicht richtig geht. Kann die v2.15 leider nirgends finden.
Vielleicht kann sie mir jemand per Mail senden, oder einen Link.
Heiko
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 23 Oktober 2016, 11:58:46
Probier doch mal V2.16:
http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx (http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx)
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 24 Oktober 2016, 17:16:27
so Bootloader ist drauf, led Blinkt ;)
mit der 2.16 ging es....
Sorry bitte nicht schlagen, geht das mit Tera Term per Netzwerk oder usb?
Was genau muss ich bei Tera Term einstellen?
Danke
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Oktober 2016, 17:44:35
Es geht nur über USB. Einstellen muss man nur den richtigen Port.
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 24 Oktober 2016, 17:55:23
ah ja ok, welchen usb treiber muss ich installieren?
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 24 Oktober 2016, 18:38:48
Windows halt, habe mall alle Treiber gelöscht und Rechner neu gebootet, und schon ging es.
Vielen Dank für eure Hilfe
Heiko
Titel: Antw:culfw@ARM
Beitrag von: somebuddy am 27 Oktober 2016, 01:20:33
komme leider auch nicht weiter.. :(

Bootloader lässt sich flashen.. verify sagt auch das alles in Ordnung ist.
Allerdings blinkt keine LED und das Gerät wird unter Windows auch nach dem flashen des Bootloaders nicht mehr erkannt.

System:

Windows 10
Sam-ba V 2.12
ATMEL AT91SAM7X256

bin für jede Hilfe dankbar !
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 27 Oktober 2016, 08:36:22
Damit es dann weitergeht, brauchts einen Neustart - und wenn schon ne FW drauf ist nen Druck auf den Taster unter dem Cube.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 Oktober 2016, 09:27:26
Welche Datei hast du genommen? Poste mal das SAM-BA Log.
Titel: Antw:culfw@ARM
Beitrag von: somebuddy am 27 Oktober 2016, 12:35:04
Dateiname:  /a-culfw_v1.21.00_build_71/CUBe/CUBE_BL.bin

Samba Log:

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/denni/Downloads/a-culfw_v1.21.00_build_71/CUBe/CUBE_BL.bin" 0x100000 0
-I- Send File C:/Users/denni/Downloads/a-culfw_v1.21.00_build_71/CUBe/CUBE_BL.bin at address 0x100000
 first_sector 0 last_sector 5
-I- Writing: 0xD400 bytes at 0x0 (buffer addr : 0x202A24)
-I- 0xD400 bytes written by applet
-I- Writing: 0x98C8 bytes at 0xD400 (buffer addr : 0x202A24)
-I- 0x98C8 bytes written by applet
Do not lock
(sam-ba_2.16) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.16) 1 %


Edit:

Ich Dussel.. das ist ja direkt die Firmware und nicht der Bootloader.. -.-
Aber wo finde ich denn den Bootloader in dem Paket :(

Edit2:

Der Bootloader fehlt scheinbar im letzten Paket. Hab das vorletze runtergeladen, dort ist er vorhanden!
Sorry !
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 27 Oktober 2016, 18:25:03
Hallo,
Habe auch den bootloader aus dem vorletzten Paket genommen ;)
bekomme immer komisches loggs.

2016.10.27 18:17:51 2: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update.
2016.10.27 18:18:22 2: maxcube: unknown message V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)

Habe aber die 71 auf dem Cube??
Gibt es da abhilfe?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 Oktober 2016, 20:16:31
Mach mal ein Update von deinem FHEM. Du verwendest eine alte Version von 00_CUL.pm und 14_CUL_MAX.pm.
Titel: Antw:culfw@ARM
Beitrag von: Kopterframe am 27 Oktober 2016, 21:49:31
Ok danke das war es
Titel: Antw:culfw@ARM
Beitrag von: defdanny am 02 November 2016, 15:46:46
Tja, ich komme nicht weiter:
Ich habe einen bereits mit Bootloader und a-culfw V 1.20.01 versehenen MAX!Cube gebraucht gekauft, diesen möchte ich auf die aktuelle a-culfw flashen.
Der Cube ist im LAN erreichbar und auch in FHEM eingebunden.

Was muss ich tun, um mittels TeraTerm über meinen Windows PC dem Cube die aktuelle FW beizubringen?

Ich habe
1. die a-culfw 1.21 herunter geladen und entpackt.
2. Das Tool "TeraTerm" auf meinem Windows PC installiert
3. Den Cube durch Drücken des Reset-Tasters in den Bootloader-Mode versetzt
4 ?

Und nun?
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 02 November 2016, 16:20:44
Das klappt nur, wenn du den Cube via USB an deinen Windows-Rechner hängst und die COM-Schnittstelle verwendest, die beim Tastendruck virtuell erzeugt wird...
Titel: Antw:culfw@ARM
Beitrag von: defdanny am 02 November 2016, 20:46:52
4. MAX!Cube per USB mit PC bei gedrückter Reset-Taste an den Windows-PC angeschlossen. Power-LED des Cube blinkt schnell.
5. Das Gerät wird als "AT91 USB to Serial Converter" an COM3 erkannt.
6. Unter Windows das Programm "Tera Term" gestartet, über "Datei --> Neue Verbindung --> Seriell" das Gerät an "COM3" ausgewählt.
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Datei senden" die aktuelle a-culfw für den Cube auswählen:
Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
8. Im Konsolenfenster von Tera Term erscheint mehrmals die Zeile "CUBELOADER V1.01" - ist das ein gutes Zeichen?
9 ...


Titel: Antw:culfw@ARM
Beitrag von: defdanny am 02 November 2016, 20:52:23
9. TeraTeam beendet, MAXCube vom Windows PC getrennt und wieder ins LAN gehängt, in FHEM wird immer noch die alte Firmware-Version "V 1.20.01 a-culfw" angezeigt. :(

Jemand eine Idee, bei welchem Schritt ich falsch "abgebogen" bin?
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 02 November 2016, 21:03:31
Xmodem als Dateiübertragungsprotokoll gewählt?

Beim Cube reichts, wenn du nachm Anschließen aufs Knöpfke drückst - muss nicht gedrückt angehängt werden.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 November 2016, 21:07:57
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Datei senden" die aktuelle a-culfw für den Cube auswählen:
Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
Datei -> Transfer -> XMODEM -> Senden

Xmodem als Dateiübertragungsprotokoll gewählt?

Beim Cube reichts, wenn du nachm Anschließen aufs Knöpfke drückst - muss nicht gedrückt angehängt werden.
Muss man schon, wenn schon eine Firmware drauf ist.
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 02 November 2016, 21:15:38
Oh - mea culpa - ich dachte, ich hätt das immer nachträglich... aber gut dann. Sorry.
Titel: Antw:culfw@ARM
Beitrag von: MAC66666 am 03 November 2016, 13:06:51
von 3 meiner Cubes wechselt immer einer die IP... interessanterweise zwischen 2 hin und her... sehr merkwürdig. Ich habe hier irgendwo gelesen, wie man eine feste IP vergeben kann, leider finde ich es nicht mehr...
Titel: Antw:culfw@ARM
Beitrag von: defdanny am 03 November 2016, 21:32:00
So, hier also das "Kochrezept" zum Flashen einer neuen Version der alternativen CUL-Firmware (a-culfw) auf den MAX!Cube.

Voraussetzungen:
- Bootloader ist bereits auf dem MAX!Cube installiert (siehe Anfang des Threads)
- Das Firmware-Update der a-culfw erfolgt bei dieser Methode über einen Windows-PC und das Windows-Tool "TeraTerm" (Download unter https://ttssh2.osdn.jp/index.html.en (https://ttssh2.osdn.jp/index.html.en))


1. Die a-culfw x.xx herunterladen und entpacken (Download unter https://github.com/heliflieger/a-culfw (https://github.com/heliflieger/a-culfw))
2. Das Tool "TeraTerm" auf Windows PC installieren
3. Der MAX!Cube per USB-Kabel an den Windows PC anschließen, dabei den "RESET"-Knopf an der Unterseite gedrückt halten. Der CUBE wird dadurch in den Bootloader-Modus versetzt (Die Power-LED blinkt schnell).
5. Das Gerät wird als "AT91 USB to Serial Converter" an COM3 (oder anderer COM-Schnittstelle) erkannt.
6. Unter Windows das Programm "Tera Term" starten, über "Datei --> Neue Verbindung --> Seriell" das Gerät an "COM3" auswählen.
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Transfer --> XMODEM --> Senden" die aktuelle a-culfw für den Cube auswählen:
bspw. Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
8. Die Dateiübertragung beginnt, nach wenigen Sekunden ist diese abgeschlossen.
9. Der CUBE startet neu wechselt wieder in den Betriebsmodus ("Power"-LED blinkt langsam). Die USB-Verbindung zum Windows-PC kann nun getrennt werden.
10. Done

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 November 2016, 22:28:01
von 3 meiner Cubes wechselt immer einer die IP... interessanterweise zwischen 2 hin und her... sehr merkwürdig. Ich habe hier irgendwo gelesen, wie man eine feste IP vergeben kann, leider finde ich es nicht mehr...
Im wiki http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten), oder auch in der commandref zur culfw http://culfw.de/commandref.html#cuno_setup (http://culfw.de/commandref.html#cuno_setup).
Titel: Antw:culfw@ARM
Beitrag von: bjoernh am 04 November 2016, 09:18:27
So, hier also das "Kochrezept" zum Flashen einer neuen Version der alternativen CUL-Firmware (a-culfw) auf den MAX!Cube.

Voraussetzungen:
- Bootloader ist bereits auf dem MAX!Cube installiert (siehe Anfang des Threads)
- Das Firmware-Update der a-culfw erfolgt bei dieser Methode über einen Windows-PC und das Windows-Tool "TeraTerm" (Download unter https://ttssh2.osdn.jp/index.html.en (https://ttssh2.osdn.jp/index.html.en))


1. Die a-culfw x.xx herunterladen und entpacken (Download unter https://github.com/heliflieger/a-culfw (https://github.com/heliflieger/a-culfw))
2. Das Tool "TeraTerm" auf Windows PC installieren
3. Der MAX!Cube per USB-Kabel an den Windows PC anschließen, dabei den "RESET"-Knopf an der Unterseite gedrückt halten. Der CUBE wird dadurch in den Bootloader-Modus versetzt (Die Power-LED blinkt schnell).
5. Das Gerät wird als "AT91 USB to Serial Converter" an COM3 (oder anderer COM-Schnittstelle) erkannt.
6. Unter Windows das Programm "Tera Term" starten, über "Datei --> Neue Verbindung --> Seriell" das Gerät an "COM3" auswählen.
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Transfer --> XMODEM --> Senden" die aktuelle a-culfw für den Cube auswählen:
bspw. Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
8. Die Dateiübertragung beginnt, nach wenigen Sekunden ist diese abgeschlossen.
9. Der CUBE startet neu wechselt wieder in den Betriebsmodus ("Power"-LED blinkt langsam). Die USB-Verbindung zum Windows-PC kann nun getrennt werden.
10. Done

@Telekatz Macht es vielleicht Sinn, so eine Anleitung als Readme zu den Quellen zu legen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 November 2016, 10:18:12
Ich werde es mal für das nächste Update ins Auge fassen.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 05 November 2016, 22:06:07
So kann mittlerweile seit heute sagen das der Opend Status willkürlich von verschieden Hardware Komponenten ausgelöst werden kann. Dachte erst es liegt am Wandschalter von Max . Diesmal wars der Türkontakt von Max.

OK, hab eh gesehen das es einen Neue Firmeware gibt. Werde diese mal draufschmeissen und mal abwarten.

Das steht bei mir im Log mit Verbose 3 eigentlich nix brauchbares.
Bevor wieder das Opend dort steht wo eigentlich Intialized stehen sollte,

2016.11.05 16:00:35 1: 192.168.178.37:2323 reappeared (CUNO)
2016.11.05 16:09:36 2: CUNO IT_set: Balkon off
2016.11.05 17:03:32 2: CUNO IT_set: Garten on
2016.11.05 17:09:36 2: CUNO IT_set: Balkon off
2016.11.05 18:09:36 2: CUNO IT_set: Balkon off
2016.11.05 18:53:37 2: CUNO IT_set: Kueche on
2016.11.05 18:53:51 2: CUNO IT_set: Kueche off
2016.11.05 18:54:35 2: CUNO IT_set: Kueche on
2016.11.05 19:09:36 2: CUNO IT_set: Balkon off
2016.11.05 19:28:13 2: CUNO IT_set: Balkon on
2016.11.05 19:28:22 2: CUNO IT_set: Balkon off
2016.11.05 19:39:47 2: CUNO IT_set: Balkon on

Ab hier dürfte dann in Global das Opend stehten.....


2016.11.05 19:39:50 1: 192.168.178.37:2323 disconnected, waiting to reappear (CUNO)
2016.11.05 19:39:50 2: IT IODev device didn't answer is command correctly:   raw => No answer
2016.11.05 19:40:02 3: CUNO: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.11.05 19:40:05 1: Cannot init 192.168.178.37:2323, ignoring it (CUNO)
2016.11.05 20:00:25 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:30 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:35 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:40 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:45 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:50 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:55 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:01:00 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.


Und das geht dann endlos weiter..............................

Das mt dem Balkon sind die Raucher ;) Klar irgendwann sind die Credits weg.

Wie gesagt ist auch nicht nachvollziehbar , läuft 2 Wochen oder auch weniger und auf einmal steht dort Opend, klar um so weniger gebrauch der Funksignale um so länger gehts gut.

Küche ist ein Wandschalter von Max der eine Intetek Funksteckdose schaltet. Balkon ist ein Max Türkontakt der eine Intertek Unterputzdose schaltet. Und Garten ist ein Dämmerungsscript für eine Intertek Funksteckdose der ein Gartenlicht einschaltet.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 November 2016, 22:40:20
Hast du deine Cube an einem Netzteil angeschlossen oder an einem funktionierenden USB Anschluss?
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 05 November 2016, 22:49:53
Ist am Orginalen Netzteil angeschlossen. Also auch währen der ganzen Opend Zeit Phasen ist der Cube am Leuchten soweit ich das beurteilen kann. Erst ein Neustart von Fhem verschafft abhilfe. Kann natürlich sein, das es garnicht dein Problem ist, sondern eher ein Problem des Entwicklers von Fhem. Aber da er davon nichst weiß und wir ein Querschiene fahren schwer zu vermitteln :)
Gruß
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 November 2016, 22:57:38
Leuchtet dabei auch die Battery LED?
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 05 November 2016, 23:04:17
Nein, Es blinkt wie gewonnt Power und Internet Leuchtet dauerhaft, aber ich werde das nochmal genau beobachten. An sich aber kann ich aber Blink und Leuchtverhalten keinen Unterschied feststellen.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 November 2016, 23:09:06
Wenn er das nächste mal disconnected schau mal mit "get uptime" nach, ob sich die Zeit dabei zurückstellt. Das würde auf ein Auslösen des Watchdogs hindeuten.
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 05 November 2016, 23:11:00
OK, mache ich , danke erstmal für deine Unterstützung. Find es ja schon merkwürdig das ich der einzige bin der davon betroffen sein soll. :)
Titel: Antw:culfw@ARM
Beitrag von: tmuecksch am 08 November 2016, 19:15:54
Unter dem Link für die Firmware im Haupt-thread gibt es leider keine Dateien zum herunterladen


https://www.mediafire.com/folder/tf16radvztfd9/a-culfw
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 November 2016, 19:02:41
Bei mir funktioniert der Link und es kommen die Dateien zum herunterladen.

Ansonsten hier der Direktlink zur aktuellen Version:
http://www.mediafire.com/file/c1xvkv19cz6kok2/a-culfw_1.21.01_build_77.zip (http://www.mediafire.com/file/c1xvkv19cz6kok2/a-culfw_1.21.01_build_77.zip)

Und weil in der aktuellen Version der Bootloader fehlt, die letzte mit Bootloader:
http://www.mediafire.com/file/viytrdbpwd3iibf/a-culfw_1.20.08_build_220_master.zip (http://www.mediafire.com/file/viytrdbpwd3iibf/a-culfw_1.20.08_build_220_master.zip)
Titel: Antw:culfw@ARM
Beitrag von: tmuecksch am 10 November 2016, 00:08:00
Vielen Dank für den Direktlink. Vermutlich ist es ein Problem mit dem Safari. Probiere es später mal mit FF oder Chrome.
Titel: Antw:culfw@ARM
Beitrag von: Kroegi am 20 November 2016, 11:26:04
Hab da grade auch so ein Phänomen mit dem Schätzchen.
Er lief jetzt von Anfang an ohne Probleme.
Nun stand da plötzlich "disconnectet", zum Glück habe ich zwei davon in Betrieb.
Also den ausgefallenen mal resettet, neu geflasht und aktuelle Firmeware drauf.
Er reagiert auch augenscheinlich ganz normal, hat ohne Fehler alles aufgenommen und Leuchtet / Blinkt wie eh und je.
Ich sehe ihn auch bei den Geräten in der Fritzbox, hat seine IP Adresse bekommen.
Nur in FHEM taucht er nicht mehr auf.
Was kann ich da noch grossartig machen?
Titel: Antw:culfw@ARM
Beitrag von: fireball2k am 20 November 2016, 16:35:50
Hallo zusammen,

zuerstmal: danke @Telekatz für die großartige Arbeit!

Ich hätte da jetzt aktuell ein kleines Problem. Mein erster Cube funktioniert hervorragend, flashen hat ohne Probleme geklappt, funktioniert bestens im Netzwerk.

Ich habe hier jetzt einen weiteren Cube liegen, der sich allerdings wehrt - gebraucht gekauft, hat aber wohl bisher funktioniert.

Zunächst mal Randdaten:
BC-LGW-O-TW
TRX868

Flashen mit dem aktuellen Binary und Bootloader aus der 1.20 lief problemlos, der Cube ist auch ansprechbar über die USB Schnittstelle, aber das Netzwerk will leider nicht.

Probiert hab ich schon Wechsel von Stromversorgung und Netzwerkkabel, DHCP und fixe IP... Über DHCP kommt an meinem DHCP Server leider nichtmal ein Request an. Ich hab den Thread hier jetzt schon kompltt durchgeackert, aber Lösung nicht wirklich gefunden... Hat da zufällig jemand ne Idee dazu, ausser dass das Netzwerkinterface Schrott sein könnte? Die "Internet"-LED kommt seitens des Cube allerdings...

Grüße
Marcus

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 20 November 2016, 17:40:04
Du könntest mal über ein serielles Terminal an der Debugschnittstelle ST2 schauen, ob er über DHCP eine Konfiguration bekommt. Die Belegung von ST2 gibt es hier: https://forum.fhem.de/index.php/topic,38404.msg332264.html#msg332264 (https://forum.fhem.de/index.php/topic,38404.msg332264.html#msg332264)

Hab da grade auch so ein Phänomen mit dem Schätzchen.
Er lief jetzt von Anfang an ohne Probleme.
Nun stand da plötzlich "disconnectet", zum Glück habe ich zwei davon in Betrieb.
Also den ausgefallenen mal resettet, neu geflasht und aktuelle Firmeware drauf.
Er reagiert auch augenscheinlich ganz normal, hat ohne Fehler alles aufgenommen und Leuchtet / Blinkt wie eh und je.
Ich sehe ihn auch bei den Geräten in der Fritzbox, hat seine IP Adresse bekommen.
Nur in FHEM taucht er nicht mehr auf.
Was kann ich da noch grossartig machen?
Schon mal probiert, ihm eine feste IP Adresse zuzuweisen?
Titel: Antw:culfw@ARM
Beitrag von: fireball2k am 20 November 2016, 19:18:37
Du könntest mal über ein serielles Terminal an der Debugschnittstelle ST2 schauen, ob er über DHCP eine Konfiguration bekommt. Die Belegung von ST2 gibt es hier:

Falls das mir galt: probier ich aus - muss nur erstmal meinen Adapter im Wust finden. An meinem Netz kanns nicht liegen an sich, geht ja mit dem anderen Cube... Aber wird getestet.

Ne andere Frage noch, ist es möglich, beim Cube den native mode zu nutzen? Aktuell rebootet das Teil, wenn ich "Nr1" übergebe. Wenn ich den Define im Source der board.h aktiviere, hagelt es Compilerfehler... ;)

(Hintergrund: ich wollte mal bissele mit LaCrosse Sensoren rumspielen...)
Titel: Antw:culfw@ARM
Beitrag von: Kroegi am 20 November 2016, 20:58:06
Zitat von: Telekatz

Schon mal probiert, ihm eine feste IP Adresse zuzuweisen?

Ja, innerhalb der Fritzbox schon. Auch schon einen andern LAN Port an der FB probiert. Er bleibt weiterhin für fhem unsichtbar.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 20 November 2016, 21:31:00
Ne andere Frage noch, ist es möglich, beim Cube den native mode zu nutzen? Aktuell rebootet das Teil, wenn ich "Nr1" übergebe. Wenn ich den Define im Source der board.h aktiviere, hagelt es Compilerfehler... ;)

(Hintergrund: ich wollte mal bissele mit LaCrosse Sensoren rumspielen...)
Der native Mode ist doch schon lange aktiv. Seit V1.20.01.

Ja, innerhalb der Fritzbox schon. Auch schon einen andern LAN Port an der FB probiert. Er bleibt weiterhin für fhem unsichtbar.
Die feste Adresse wird nicht in der Fritzbox eingestellt.
http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten)
Titel: Antw:culfw@ARM
Beitrag von: Kroegi am 20 November 2016, 21:52:59
Das probiere ich mal. Ich hab in der Tat vorgestern die Fritzbox LAN Anschlüsse auf Gigabit umgestellt. Den Betroffenen wo der störrische CUBe dran hängt kann ich aber nicht auf 100MBit zurück stellen weil da noch mehr dran hängt das die volle Geschwindigkeit haben sollte. Die Fritzbox hat dem CUBe eine IP Adresse zugewiesen, und zwar die gleiche wie vorher. Diese werd ich ihm dann händisch zuweisen. Hat der CUBe die Adresse dann nicht verinnerlicht oder wieso zickt er? Der 2. CUBe hängt auch am Gigabit, wurde aber seit dem umstellen nicht neu gestartet.
Titel: Antw:culfw@ARM
Beitrag von: Kroegi am 21 November 2016, 06:59:17
Hurra, das war wohl genau der richtige Tipp.
Hab beide CULs nun mit ihrer schon vorher vergebenen IP festgesetzt.
Nun sind beide wieder initialisiert und erreichbar.
DANKE!
Titel: Antw:culfw@ARM
Beitrag von: fireball2k am 21 November 2016, 09:15:34
Der native Mode ist doch schon lange aktiv. Seit V1.20.01.

Ups? Woran kanns dann liegen dass ich keine Telegramme von meinen Temperatursensoren bekomme? Ich bin ja auf 1.21.x...

Sorry... alles noch etwas neu für mich... :D
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 November 2016, 19:08:03
Zur Info für diejenigen, die die Firmware selbst compilieren:

Mit der letzten Version kam die Unterstützung für STM32 Controller hinzu. Dabei habe ich auch auf eine aktuelle Version der ARM Toolchain umgestellt. Aktuell sollte diese Version verwendet werden: https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update).
Titel: Antw:culfw@ARM
Beitrag von: fow0ryl am 28 November 2016, 18:23:27
Hallo,

bin neu hier und schon am verzweifeln :(
Wollte meinen CUBE zu einem CUN umflashen. Komme aber irgendwie nicht weiter.

Nachdem ich mir den Bootloader "bootloader_CUBE.bin" aus der Version 1.20.08 besorgt habe, habe ich ihn von meinem Notebook aus mit bossa auf den CUBE geschrieben.
Nach dem Einstecken des USB Kabels bilnkt die Power LED schnell.

Allerdings sehen die Meldungen im dmesg anders aus, als beschrieben.
Nov 28 18:15:17 HP8560p-HR kernel: usb 4-1.1: new full-speed USB device number 8 using ehci-pci
Nov 28 18:15:18 HP8560p-HR kernel: cdc_acm 4-1.1:1.0: ttyACM3: USB ACM device

Von "CUBELOADER" finde ich da nichts.

Wenn ich bossa neu starte findet er an den seriellen Schnittstellen auch kein passendes Device.

Ist der neue Bootloader nun drauf, oder nicht?

Mit der Beschreibung von minicom komme ich dann auch nicht weiter :(
bei CRTL-A Z passiert einfach nichts ....
Gibts da keinen passenden Befehl für die Kommandozeile?

Gruß
Henning

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 November 2016, 22:06:10
Ist der neue Bootloader nun drauf, oder nicht?
Wenn er schnell blinkt ist der Bootloader drauf.
Titel: Antw:culfw@ARM
Beitrag von: Lupo am 02 Dezember 2016, 18:14:45
Wir sind jetzt gerade etwas am Verzweifeln: der Max Cube wurde per Jumper gelöscht.
Beim Bootloader fingen dann die Probleme an, bis wir die Kiste ganz zerlegt hatten und gesehen haben daß dort ein 512KB Chip drin steckt.
Also damit geflasht, dann die Firmware. Alles lief ohne Fehlermeldung durch.

Also wieder per USB mit Power versorgt, ans LAN gehängt, Power blinkt, "Internet" leuchtet dauerhaft, aber der Würfel wird von der FB nicht gefunden.
Bzw. wir haben ein unbekanntes Gerät drin auf .103, bekommmen aber keine Verbindung von fhem aus.

Mit "define ml MAXLAN 192.168.2.103" versucht anzumelden, "disconnected". Mit "define max_LAN CUL 192.168.2.103:2323 1034" passiert das selbe.

Und per USB am RasPi hängend haben wir es mit:

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

probiert, es kommt auch keine Verbindung zustande.

Wo liegt der Fehler? Oder wo KÖNNTE er liegen?
Titel: Antw:culfw@ARM
Beitrag von: fow0ryl am 02 Dezember 2016, 18:54:32
Hallo,

mühsam ernährt sich das Eichhörnchen ...

Ich habe die Firmware inzwischen auf den Cube flashen können.

Laut Telekatz war schnelles blinken der Power LED ein eindeutiges Kennzeichen dafür, das der Bootloader drauf war.

Mit Minicom bin ich allerdings nicht weiter gekommen. CTRL-Z hat einfach zu Null Reaktionen geführt. Egal ob dirket auf der Konsole, im Xterm oder im QTerminal.
Und die Parameter für die Kommandozeile habe ich nicht wirklich verstanden.

Daher habe ich dann mit einem Windows 10 Notebook weitergemacht. Zunächst mal SAM-BA installiert. Sofort wurde ein neues USB Gerät AT91 erkannt.
Ein Versuch den Bootloader mit SAM-BA neu zu schreiben wurde sinngemäß mit der Meldung "Inkompatibles Device" quittiert.
Dann einfach mit TeraTerm wie in der Anleitung die Firmware geflasht.

Nach dem Neustart des Cube (USB Kabel ziehen und wieder anstöpseln)  blinkt die Power LED langsam und die BATTERY LED leuchtet permanent.
Ganz anders unter Linux. Dort blinkt die POWER LED. Ansonsten passiert nichts...
Merkwürdiges Verhalten. :-\

Na ja. Hatte dann erst mal im FHEM Server die Definitionen wie in diesem Thread beschrieben eingetragen. Als IP Adresse habe die Adresse verwendet, die der Cube vorher hatte. (Im Router bzw. der dnsmaq config war die MAC der IP ja fest zugeordnet)
define CULCuBE_1 CUL 192.168.1.40:2323 0000
attr CULCuBE_1 rfmode MAX
attr CULCuBE_1 room CUL
define culmax_1 CUL_MAX 654321
attr culmax_1 IODev CULCuBE_1

Und es passierte .... Richtig. Nichts.
Nach einer Weile habe ich dann bemerkt das sich ein neues unbekanntes Gerät per DHCP eine IP Adresse geholt hat. Hm. Wie das?
Angepingt, Kabel gezogen. Siehe da. Der Cube hatte einen andere MAC als zuvor. Unschöner Nebeneffekt aber lösbar. Man muss nur wissen wonach man suchen muss :(

Nächster Schritt wird das Anlernen von Thermostaten sein. Mal sehen über was ich da noch stolpere.
Für einen Anfänger jedenfalls nur mit Durchhaltewillen zu bewerkstelligen.

Das Thema Linux verliere ich noch nicht aus den Augen. Ich möchte meinen zweiten Cube ja auch noch umflashen...

Gruß
Henning
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 Dezember 2016, 19:34:22
Und per USB am RasPi hängend haben wir es mit:

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

probiert, es kommt auch keine Verbindung zustande.

Wo liegt der Fehler? Oder wo KÖNNTE er liegen?
Rechte korrekt vergeben?
http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt (http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt)
Titel: Antw:culfw@ARM
Beitrag von: Lupo am 02 Dezember 2016, 19:52:02
Rechte korrekt vergeben?
http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt (http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt)
DANKE, das wars!!!
Titel: Antw:culfw@ARM
Beitrag von: rotfisch am 06 Dezember 2016, 13:09:49
Hallo
Super Projekt. Danke an Telekatz und alle anderen. Ich konnte meinen MAXCube in einen CUL umflashen.
Hier aber noch ein paar Anmerkungen, damit andere Neulinge nicht dieselben Fehler wie ich machen:

Viele Grüße,
rotfisch
Titel: Antw:culfw@ARM
Beitrag von: cs1711 am 07 Dezember 2016, 20:35:46
Als erstes auch von mir ein großes Lob: Super Projekt!

Bei mir hat folgendes soweit funktioniert, dass der MAX!CUBE eine IP Adresse bekommt, in FHEM eingebunden werden kann und zumindest schon mal ein Gerät (Hoermann Garagentor) automatisch erkannt hat.

Vorbereitung und Flashen

Anschließend Netzwerkkabel angeschlossen und Verbindung mit verbundenem USB Kabel mittels Tera Term wieder aufgebaut. Zum Testen ein paar Befehle abgesetzt (einfach eingetippt):
Befehl: V (also nur V eintippen)
Ausgabe: V 1.23.02 a-culfw Build: 119 (2016-12-04_20-46-20) CUBe (F-Band: 868MHz)
Befehl: Rid
Ausgabe: 01
Befehl: Rim
Ausgabe: XX:XX:XX:XX:XX:XX
Befehl: Ria
Ausgabe: 10.10.10.10

Wurde natürlich eine vernünftige MAC Adresse ausgegeben. Funktion soweit gegeben. Tipp für weniger Erfahrene: Wenn beim Flashen mal was schief geht, einfach wieder  J1 verbinden und alles von vorn.

Als nächstes USB Kabel entfernt und per Telnet verbunden:
telnet 10.10.10.10 2323Verbindung funktioniert.

Dann den Cube in die fhem.cfg eingetragen. Zum Testen aktiviere ich autocreate.
define autocreate autocreate
attr autocreate autosave 1
attr autocreate filelog ./log/auto-%NAME-%Y.log

Dann der Cube (rfmode SlowRF ist nur zum Testen):
define CULCuBE_1 CUL 10.10.10.10:2323 0000
attr CULCuBE_1 icon cul_868
attr CULCuBE_1 rfmode SlowRF

Konfiguration von fhem neu geladen, Cube war da. Jetzt wird es spannender. Da meine HOMEMATIC-Aktoren noch nicht da sind, habe ich Testweise mal die Fernbedienung meines Hoermann-Garagentoröffners bedient und siehe da, wurde erkannt. Ergebnis:
define CUL_HOERMANN_91B4E26F86 CUL_HOERMANN 91B4E26F86
attr CUL_HOERMANN_91B4E26F86 IODev CULCuBE_1
attr CUL_HOERMANN_91B4E26F86 room CUL_HOERMANN
define FileLog_CUL_HOERMANN_91B4E26F86 FileLog ./log/auto-CUL_HOERMANN_91B4E26F86-%Y.log CUL_HOERMANN_91B4E26F86
attr FileLog_CUL_HOERMANN_91B4E26F86 logtype text
attr FileLog_CUL_HOERMANN_91B4E26F86 room CUL_HOERMANN

Nun aber noch zu meinem Problem. Setze ich den Toggle-Befehl für CUL_HOERMANN ab, kommt im Telnet-Fenster nur folgendes:
? (hn91B4E26F86 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l t x zund nichts weiter passiert. Hat jemand eine Idee, was da schief geht?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 07 Dezember 2016, 22:21:45
Nun aber noch zu meinem Problem. Setze ich den Toggle-Befehl für CUL_HOERMANN ab, kommt im Telnet-Fenster nur folgendes:
? (hn91B4E26F86 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l t x zund nichts weiter passiert. Hat jemand eine Idee, was da schief geht?
HOERMANN_SEND war für den Cube nicht aktiviert. Kommt mit der nächsten Version.
Titel: Antw:culfw@ARM
Beitrag von: cs1711 am 10 Dezember 2016, 21:57:53
Jetzt muss ich noch mal was fragen.

Der Cube läuft. Jetzt wollte ich ihn im Homematic-Modus laufen lassen und mit einem Homematic IP Heizkörperthermostat pairen. Meine Config sieht wie folgt aus:
define CULCuBE_1 CUL 192.168.10.67:2323 0000
attr CULCuBE_1 icon cul_868
attr CULCuBE_1 rfmode HomeMatic
attr CULCuBE_1 hmId CED68B
attr CULCuBE_1 verbose 5

Über die Kommandozeile versetze ich - so hoffe ich - den Cube in den Pairing-Modus:
set CULCuBE_1 hmPairForSec 600
Dann drücke ich die Pairing-Taste auf dem Thermostat und es passiert... nichts... LED blinkt langsam gelb vor sich hin, das war's... hat jemand eine Idee, wo das Problem liegen könnte?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 Dezember 2016, 22:19:46
Homematic IP funktioniert nicht mit einem CUL.
Titel: Antw:culfw@ARM
Beitrag von: cs1711 am 11 Dezember 2016, 09:21:52
Ah, ok, danke für die Info, irgendwie habe ich das schon befürchtet bzw. meine es irgendwo gelesen zu haben (konnte es aber nicht wiederfinden).
Titel: Antw:culfw@ARM
Beitrag von: cs1711 am 12 Dezember 2016, 10:17:47
Liebe Experten,

ich schon wieder... ich hoffe, ich habe nicht wieder irgendwo etwas überlesen...

Cube war erfolgreich geflasht, soweit, so gut. Cube läuft jetzt im Homematic Modus, allerdings will das Pairing scheinbar nicht funktionieren (Details siehe Post https://forum.fhem.de/index.php/topic,62373.0.html). Der HM-LC-SW1-FM ist ja ein Homematic Aktor, daher müsste es doch eigentlich funktionieren...

Woran kann es liegen? Frage stelle ich hier (zusätzlich), weil es ja irgendwas mit der a-culfw zu tun haben könnte...

Viele Grüße
Christian

Nachtrag: Problem gelöst, siehe https://forum.fhem.de/index.php/topic,62373.0.html.
Titel: Antw:culfw@ARM
Beitrag von: micky0867 am 13 Dezember 2016, 19:53:50
Habe gerade ebenfalls einen Max!Cube (TRX868-TI) erfolgreich unter Linux mit bossa und minicom geflasht.  8)

Danke an Telekatz für die SW.
Danke auch an Christian (cs1711) für die übersichtliche Zusammenfassung.

Das mit den vertauschten Readmes in CUBe und MapleCUL hat mich allerdings auch verwirrt.  ???

Micky
Titel: Antw:culfw@ARM
Beitrag von: Lupo am 16 Dezember 2016, 19:14:17
Noch ein Hinweis zur Hardware des HM-CFG-USB-2 und des MAX! Cube. Mir aufgefallen, dass bei diversen MAX und Homematic Geräten Funkmodule mit einem Si4431 anstelle eines CC1101 Chips verwendet werden. In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul. Die beiden HM-CFG-USB-2 Adapter die ich habe, haben einen CC1101 verbaut. Allerdings könnte es auch welche geben, die einen SI4431 haben. Bitte dies vor dem löschen der Originalfirmware kontrollieren.
Auf meinem Cube steht hingegen nur TRX868. Den habe ich allerdings auch schon seit 2012. Könnte hier bitte mal jemand der sich kürzlich einen Cube gekauft hat nachsehen, ob der Typ des Funkmoduls jetzt auch genauer angegeben ist?
Woran sieht man jetzt welchen Chip man drauf hat? Ich finde keiner der beiden Bezeichnungen auf der Platine vom Cube.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 Dezember 2016, 19:19:59
Auf der Unterseite des Gehäuses.
Titel: Antw:culfw@ARM
Beitrag von: Lupo am 16 Dezember 2016, 19:23:33
Da steht nur TRX868.
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 18 Dezember 2016, 12:47:27
Hi all.
Sorry for posting in English.

I am trying to learn how to compile the firmware for the Cube on the raspberry pi.

I have downloaded the latest version of the source code 1.23.04.
I have downloaded the toolchainGNU ARM Embedded Toolchain 5-2016-q3-update.
I have updated my path temporarily in the Pi to add path to the toolchain (PATH=$PATH:/home/pi/t2/gcc-arm-none-eabi-5_4-2016q3/bin)
I then navigated to the Devices directory in the CUL source code on the pi.
Then I typed make but received error before it had got very far that avr-gcc not found.

So installed the various tools with command
sudo apt-get install gcc-avr binutils-avr avr-libc

and tried again, this time it ran through compiling for all devices but errors when getting to the CUBe it does the clean bit, then starts but gives this error.

make -C CUBe
make[1]: Entering directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
make OUTPUT=CUBE_BL target
make[2]: Entering directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
arm-none-eabi-gcc -g -Os -fno-isolate-erroneous-paths-dereference -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S
/home/pi/t2/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: 1: /home/pi/t2/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")")
Makefile:121: recipe for target '../../at91lib/board_cstartup.o' failed
make[2]: *** [../../at91lib/board_cstartup.o] Error 2
make[2]: Leaving directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
Makefile:96: recipe for target 'CUBE_BL' failed
make[1]: *** [CUBE_BL] Error 2
make[1]: Leaving directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 2

 I have tried with an earlier version 1.20.00 and get same error.
Anyone suggest what I might be doing wrong?
Many thanks
Regards

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 18 Dezember 2016, 14:40:14
Did you build the toolchain on the raspberry from the sources, or did you use the precompiled package (which i think is only for x86)?
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 18 Dezember 2016, 14:49:11
Thanks for the prompt response.

I followed the link on the first posting for the toolchain used.
(https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update))
On the link was a Linux installation tarball which I downloaded and extracted to the pi.
(gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2)


Am I more likely to have success doing this from windows which I am more familiar with?

Thanks

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 18 Dezember 2016, 14:55:14
Yes, try it with windows.
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 22 Dezember 2016, 16:42:03
OK for anyone else who wants to try, this is what worked for me.

Download the GNU ARM Embedded Toolchain from the below link and install on your windows pc.
https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update)

Dwonload GNU ARM Eclipse Windows Build Tools and extract
https://github.com/gnuarmeclipse/windows-build-tools/releases (https://github.com/gnuarmeclipse/windows-build-tools/releases)

Download and extract your source files.

Find the gccvar.bat file in the GNU ARM Embedded Toolchain and edit the set path statement to include the bin file from the build tools directory so that when it is run the path will include the bin directory to both the embedded tool chain and the bin directory from build tools. My files were installed to short directory names so teh edited set path line looked like
set PATH=%TL_PATH%;C:\z1\bt\bin;%PATH% where C:\z1\bt\bin; was the bit for the build tools directory.

Navigate to the directory for the Device you wish to compile in the command prompt and execute the gccvar.bat directory directly from there.

Type make clean and press enter to ensure all old compiled stuff has been removed.
Type make enter and it should compile the file.

The last bit of the output from the make command was a listing of the files it created like below.
e  93640    1312   24340  119292   1d1fc CUBE_BL.elf
arm-none-eabi-objcopy -O binary CUBE_BL.elf CUBE_BL.bin
arm-none-eabi-size CUBE_BL.elf
   text    data     bss     dec     hex filename
  93640    1312   24340  119292   1d1fc CUBE_BL.elf
make[1]: Leaving directory 'C:/z1/a-culfw-1.23.02/culfw/Devices/CUBe'

For those of you who use the cube and get frustrated with credits I have a version which I think returns credits based on the led light setting off = std, ON = X2 return of credits, FLASHING = X3 return of credits

https://forum.fhem.de/index.php/topic,59968.msg544950.html#msg544950 (https://forum.fhem.de/index.php/topic,59968.msg544950.html#msg544950)
Titel: Antw:culfw@ARM
Beitrag von: iceweasel3000 am 27 Dezember 2016, 20:07:43
Hallo Telekatz,

habe den Maxcube erfolgreich umgeflasht und wollte LaCross Temperatursensoren auslesen.

Flashen und das Verbinden mit Cube funktioniert über Netzwerk und USB.

Wenn ich den Native Mode auf 2 (Nr2) stelle, startet der CUBE neu?

Es werden auch keine Meldungen angezeigt. Nur bei X2F werden Flanken erkannt.

Ich habe zum Testen leider noch keine anderen Geräte, ausser einen TX48WD-IT.

Unterstützt die Firmware LaCrosse oder geht das nur mit einen CUL von Busware ?

Edit: a-culfw_1.23.04 geflasht
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 28 Dezember 2016, 12:19:28
Seitdem ich wieder von Testung auf Jessie umgestiegen bin lässt sich a-culfw nicht mehr kompilieren auf dem Pi:
make: Entering directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
make OUTPUT=CUBE_BL target
make[1]: Entering directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
arm-none-eabi-gcc -g -Os -fno-isolate-erroneous-paths-dereference -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S
arm-none-eabi-gcc: error: unrecognized command line option '-fno-isolate-erroneous-paths-dereference'
Makefile:121: recipe for target '../../at91lib/board_cstartup.o' failed
make[1]: *** [../../at91lib/board_cstartup.o] Error 1
make[1]: Leaving directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
Makefile:96: recipe for target 'CUBE_BL' failed
make: *** [CUBE_BL] Error 2
make: Leaving directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'

arm-none-eabi-gcc ist Version 4.8.4. Benötige ich eine andere Version? Ich konnte zu '-fno-isolate-erroneous-paths-dereference' nichts im Netz finden.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Dezember 2016, 12:33:48
Zur Info für diejenigen, die die Firmware selbst compilieren:

Mit der letzten Version kam die Unterstützung für STM32 Controller hinzu. Dabei habe ich auch auf eine aktuelle Version der ARM Toolchain umgestellt. Aktuell sollte diese Version verwendet werden: https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update).

Die Option '-fno-isolate-erroneous-paths-dereference' kam mit 4.9 hinzu.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 28 Dezember 2016, 13:43:22
Danke! Das erklärt auch, warum es unter Testing noch funktioniert hat. Da ist ein 4.9er GCC dabei.
Titel: Antw:culfw@ARM
Beitrag von: iceweasel3000 am 29 Dezember 2016, 11:22:30
Danke Telekatz

Mit der neusten Firmware (a-culfw_1.23.05_build_132 )funktioniert der Nativ Mode wieder.

2016.12.29 11:20:27 5: SW: Nr1
2016.12.29 11:20:27 5: CUL/RAW: /01

2016.12.29 11:20:27 4: CUL_Parse: CUL868 01
2016.12.29 11:20:27 2: CUL868: unknown message 01
2016.12.29 11:20:31 5: CUL/RAW: /N0196A6332D9CAAAA0000321479
Titel: Antw:culfw@ARM
Beitrag von: Edi77 am 30 Dezember 2016, 00:37:35
Hallo,

Ich hätte zu dem Thema mal eine Frage.
Ich habe jetzt 5x MAX Heizkörperthermostat Basic.
Wenn die den MAX CUBE zum CUL umflashe ist er ja eigentlich wie ein CUL/CUNO.
Unterstützt er dann nur das MAX System, oder kann ich ihn auch auf andere Systeme wie Homematic, FS20 usw. konfigurieren?
Wenn ich mich richtig erinnere kann ich pro CUL/CUNO nur 1 System konfigurieren?

Eine andere Idee war das ich einen alten RPI1 + COC  konfigurieren und mit FHEM2FHEM verknüpfe.
Aber dann kann ich vom Master Fhem Server (Ubuntu) nicht via FHEM2FHEM über den RPI 1 Daten senden?
Oder sit hier eine Lösung mit ser2net besser und stabiler?

Titel: Antw:culfw@ARM
Beitrag von: alangward am 01 Januar 2017, 12:22:23
Hi,
I'm sorry, but I don't speak German.
I hope somebody has the patience to answer in English!

I have just reflashed my CUBE with the CUL firmware (latest version).
It works - I can give it commands over the USB connection using Tera Term and it replies with the correct version information.

I had hoped that I could connect it using Ethernet, but that doesn't seem to work.
Looking at the board.h file the Ethernet options are commented out.

Am I right in assuming that Ethernet is not supported?
If so, are there any plans to support it?
Are there any fundamental problems that prevent Ethernet being supported?

Thanks,
Alan
Titel: Antw:culfw@ARM
Beitrag von: alangward am 01 Januar 2017, 12:23:50
Hi,
I'm sorry, but I don't speak German.
I hope somebody has the patience to answer in English!

I have just reflashed my CUBE with the CUL firmware (latest version).
It works - I can give it commands over the USB connection using Tera Term and it replies with the correct version information.

I had hoped that I could connect it using Ethernet, but that doesn't seem to work.
Looking at the board.h file the Ethernet options are commented out.

Am I right in assuming that Ethernet is not supported?
If so, are there any plans to support it?
Are there any fundamental problems that prevent Ethernet being supported?

Thanks,
Alan
Titel: Antw:culfw@ARM
Beitrag von: alangward am 01 Januar 2017, 12:44:51
Hi,
Ignore my question.
I have now got it connected over Ethernet.
It just needed re-booting.

Thanks,
Alan
Titel: Antw:culfw@ARM
Beitrag von: malc_b am 02 Januar 2017, 11:11:17
Hi,
(sorry this is in english)

I'm trying to build a-culfw from source but I can't get it to work, perhaps someone could point out where I'm going wrong.

I tried running in win7 but that seemed to have so many issues I gave up on that and tried on my raspberry pi.  apt-get only installs gcc-arm tool 4.8 so I've had to install 5_2-2015q4 from the tar.  I put that in a ~/tools directory rather than clutter /usr etc..  I've edited the makefile in CUBe directory but when I run make from that directory (as root) I get this:

make OUTPUT=CUBE_BL target
make[1]: Entering directory '/root/a-culfw-master/culfw/Devices/CUBe'
~/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc -mcpu=arm7tdmi-s -Wall -Wno-strict-aliasing -Wno-unused-but-set-variable -mlong-calls -ffunction-sections -std=c99 -Dflash -DCUBE_BL -DTRACE_LEVEL=4 -DDBGU_UNIT_IN -g -MMD -MP -MF .dep/main.o.d -Os -fno-isolate-erroneous-paths-dereference -I. -I../.. -I../../at91lib -I../../at91lib/usb -I../../clib -I../../at91lib/avr -I../../avr-uip/uip -I../../avr-uip -I~/tools/gcc-arm-none-eabi-5_2-2015q4/arm-none-eabi/include  -c -o main.o main.c
/root/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc: 1: /root/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")")
Makefile:124: recipe for target 'main.o' failed
make[1]: *** [main.o] Error 2
make[1]: Leaving directory '/root/a-culfw-master/culfw/Devices/CUBe'
Makefile:96: recipe for target 'CUBE_BL' failed

the makefile changes are

ARMBASE = D:/a-culfw-master/gcc-arm-none-eabi-win32

INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = /arm-none-eabi-
#OPENOCDPATH = F:\Tools\OpenOCD
#OPENOCD = $(OPENOCDPATH)\openocd.exe -f $(OPENOCDPATH)\target\sam7x256.cfg -f $(OPENOCDPATH)\interface\uniprog.cfg


TIA
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 Januar 2017, 11:29:52
I asssume, that the binaries in the tar are compiled for x86 and doesn't run on a pi.

If you want to compile the Firmware wit 4.8, you have to remove the -fno-isolate-erroneous-paths-dereference parameter in the OPTFLAGS.
Titel: Antw:culfw@ARM
Beitrag von: malc_b am 02 Januar 2017, 11:41:29
DOH!  Of course.  I was just looking at the linux and not the processor (which isn't mentioned otherwise I might have realized that).  I'll try 4.8
Titel: Antw:culfw@ARM
Beitrag von: chapelhill am 02 Januar 2017, 12:10:02
This was my post on how I managed to get to compile with Windows.

https://forum.fhem.de/index.php/topic,38404.msg544992.html#msg544992 (https://forum.fhem.de/index.php/topic,38404.msg544992.html#msg544992)

I was struggling to get the pi to compile with my lack of experience.
Titel: Antw:culfw@ARM
Beitrag von: SaDa am 03 Januar 2017, 02:24:43
Hallo zusammen,

Zunächst mal allen hier ein gesundes und erfolgreiches 2017!

Ich bin neu hier und habe erfolgreich die alternative FW von Telekatz installiert. Vielen Dank an dieser Stelle für die geleistete Arbeit!!!

Da ich nicht regelmäßig nach neuen Versionen schauen kann und will, habe ich mir ein kleines Helferchen gebaut, das einmal pro Tag nach Updates sucht.

Die fhem.cfg habe ich wie folgt erweitert:

define CULFW_Version dummy
define aCULFW_Version dummy
define versionInfo readingsGroup <%cul_cul>,<aktuelle Version>,<neueste Version> \
CULFW_Version:current,latest \
aCULFW_Version:current,latest
attr versionInfo valueStyle {if($READING eq "latest"){my $t=$VALUE;;my $d=ReadingsVal($DEVICE,'current',0);;if($t ne $d){'style="color:rgb(251,63,11);;"'}}}
attr versionInfo group Versionsinfos

Die 99_myUtils.pm wurde um den nachfolgenden Code ergänzt:

sub checkCulFwVersions($) {
my ($hash) = @_;
####################################################################
# standard CUL firmware version
####################################################################
my $changeLogUrl = "http://culfw.de/CHANGED";
my $response = get( $changeLogUrl );
if (defined $response) {
my $latestCulFirmwareVersion = ( split /\n/, $response )[0];
$latestCulFirmwareVersion =~ /Version\s+(.*?)\s+\(.*?\)/;
$latestCulFirmwareVersion = $1;
fhem("setreading CULFW_Version latest $latestCulFirmwareVersion");
}
####################################################################
# MAX!Cube CUL alternative firmware version (@see http://bit.ly/2i3NE81)
####################################################################
my $aculfw_url = "http://bit.ly/2iCgKyH";
my $aculfw_response = get( $aculfw_url );
if (defined $aculfw_response) {
my $aculfw_list = JSON->new->ascii->decode($aculfw_response);
my $list = $aculfw_list->{'response'}->{'folder_content'}->{'files'};
my $aculfw_entrycount = scalar(@{ $list });
if ($aculfw_entrycount > 0) {
my $aculfw_entry = $list->[-1];
my $aCulFwVersion = $aculfw_entry->{'filename'};
$aCulFwVersion =~ /a-culfw_(.*?).zip/;
$aCulFwVersion = $1;
$aCulFwVersion =~ tr/_/ /;
fhem("setreading aCULFW_Version latest $aCulFwVersion");
}
}
RemoveInternalTimer( $hash );
my $interval = 60*60*24;
InternalTimer(gettimeofday() + $interval, "checkCulFwVersions", $hash, 1 );
}

Das Ergebnis kann man hier (http://bit.ly/2j2bIvS) betrachten.

Vielleicht hilft's ja dem ein oder anderen...

Viele Grüße
Daniel
Titel: Antw:culfw@ARM
Beitrag von: Bennemannc am 04 Januar 2017, 16:40:54
Hallo,

nach dem ich es geschafft habe, den CUBe zu flashen, läuft er über USB mit /dev/ttyACM0@38400 0000 sofort. Was muss ich machen, um dem ins Netzwerk einzubinden - die IP habe ich, aber welche Port ? Oder brauche ich keinen?
Wäre nett, wenn mir mal jemand auf die Sprünge helfen könnte.

Gruß Christoph
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 Januar 2017, 16:47:36
https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten (https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten)
Titel: Antw:culfw@ARM
Beitrag von: kFieLd am 05 Januar 2017, 22:37:21
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?
define MaxCubeLAN CUL 192.168.0.55:2323 0000
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Januar 2017, 23:18:09
Wenn deine IP Adresse 192.168.0.55 ist, ja.
Titel: Antw:culfw@ARM
Beitrag von: Bennemannc am 06 Januar 2017, 04:15:58
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
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2017, 09:22:35
Die Leute, die damit neu anfangen, können und sollten sich auch die Dokumentation in der commandref ansehen. Da steht es auch drin.

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.
Titel: Antw:culfw@ARM
Beitrag von: dbeu am 06 Januar 2017, 12:45:52
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
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2017, 14:11:30
Schau mal nach, ob der Taster an der Unterseite hängt.
Titel: Antw:culfw@ARM
Beitrag von: dbeu am 06 Januar 2017, 15:21:52
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?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2017, 18:09:09
Nein, aber das ist der einzige Grund, warum er trotz geladener Firmware immer wieder in den Bootloader springen würde.
Titel: Antw:culfw@ARM
Beitrag von: freetz am 10 Januar 2017, 20:34:51
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.
Titel: Antw:culfw@ARM
Beitrag von: Oern am 10 Januar 2017, 20:44:14
Mehrfach überlesen  ;) Habe auch lange gesucht.

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

Gesendet von meinem HTC One_M8 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: freetz am 10 Januar 2017, 23:17:13
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.
Titel: Antw:culfw@ARM
Beitrag von: freetz am 11 Januar 2017, 09:42:17
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.
Titel: Antw:culfw@ARM
Beitrag von: freetz am 11 Januar 2017, 14:29:55
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.
Titel: Antw:culfw@ARM
Beitrag von: tca am 11 Januar 2017, 20:26:04
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
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 Januar 2017, 21:11:35
Probier mal, ob es mit der angehängten Version funktioniert.
Titel: Antw:culfw@ARM
Beitrag von: tca am 11 Januar 2017, 21:43:50
:-) geht ... alles super  ;) !!
Titel: Antw:culfw@ARM
Beitrag von: freetz am 11 Januar 2017, 22:56:50
Eine Frage hätte ich noch, wobei ich nicht weiß, ob ich die hier oder woanders stellen sollte:
In den Changelogs der a-culfw steht schon für Version 1.20.05
- Code upgrade from culfw Version 1.66 (2015-11-29)
Wenn ich aber nach dem Einspielen einer selbstkompilierten a-culfw 1.23.05 in den FHEM-Logs nach der Initialisierung des Cubes nachschaue, steht dort
CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
Liegt das ggf. daran, dass für das CUBe-Device eine ältere culfw zur Grundlage genommen wird? Oder liegt der Grund doch in der a-culfw als Gesamtpaket?

Ich hatte bisher einen Busware Stick mit FW 1.66 am Laufen und jetzt eben noch den Cube und frage mich, welches Gerät ich nun an FHEM laufen lasse - der Cube wäre wegen Netzwerk eigentlich praktischer, aber wenn kein Update auf aktuellere FW-Versionen möglich sein sollte, dann würde ich noch mal genauer nach den (für mich relevanten) Unterschieden zwischen den Firmwareversionen suchen...

Danke und Gruß,

F.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 Januar 2017, 23:25:44
CUL_MAX prüft nur, ob die Firmware des CUL mindestens Version 154 ist, weil es vor dieser Version Bugs mit MAX gibt. Wird die a-culfw von CUL_MAX erkannt, wird immer 154 als Version angenommen, unabhängig davon welche Version die a-culfw hat.
Titel: Antw:culfw@ARM
Beitrag von: freetz am 11 Januar 2017, 23:27:07
Danke für die schnelle Antwort, dann ist ja alles fein :)!
Titel: Antw:culfw@ARM
Beitrag von: phoenix am 12 Januar 2017, 19:29:39
Hallo zusammen,

ich habe mir gestern einen Max Cube bestellt und wollte gerade das Teil flashen, aber ich fürchte da ist was in die Hose gegangen. Wie beschrieben habe ich J1 verbunden, USB eingesteckt und wieder abgezogen, die Verbindung entfernt und wieder an den USB Port angesteckt aber es passiert leider nix. Beim einstecken blitzen auf dem Board D1 D2 D3 einmal kurz auf und mehr passiert nicht. Da der Cube auch unter seiner standart IP Adresse nicht mehr erreichbar ist vermute ich mal, der ist hinüber? Dummerweise habe ich ihn vorher nicht gestest, kann somit nicht ausschließen dass der Cube von Anfang an defekt war. Retten lässt sich da vermutlich nix mehr oder?
Titel: Antw:culfw@ARM
Beitrag von: freetz am 12 Januar 2017, 19:32:24
Nach dem Reset über J1 ist das normal. Du musst jetzt erst einmal wie in Post #1 beschrieben, den Bootloader flashen. Erst wenn der drauf ist, blinkt LED D1 dauernd und ist bereit für das Flashen der Firmware.
Titel: Antw:culfw@ARM
Beitrag von: phoenix am 12 Januar 2017, 19:39:16
Danke für die schnelle Antwort, aber der Cube wird garnicht erkannt, also auch kein neuer Com-Port wie es da steht. Deshalb kam ich darauf dass der hinüber sein könnte
Titel: Antw:culfw@ARM
Beitrag von: phoenix am 12 Januar 2017, 19:41:57
Hmmmm nääää. Schon gut. Habs jetzt mal mit dem original USB Kabel probiert welches beim Cube beiliegt und siehe da ein neuer Comport. Mit meinem USB Kabel womit ich andere Geräte betreibe gehts nicht. Da muss auch einer drauf kommen .Dankööö
Titel: Antw:culfw@ARM
Beitrag von: Bennemannc am 13 Januar 2017, 05:06:43
Hallo,

das liegt daran, das in dem USB Stecker am Cube 5 Pole sind. V+,GND,D+,D- und mit dem 5ten machen manche Hersteller was besonderes - offen, auf Masse - keine Ahnung was noch und lassen ihr Gerät darauf prüfen. Zur reinen Stromversorgung kann man jedes Kabel nehmen - das ist ja Norm, aber für andere Sachen, kann das schon mal scheitern.

Gruß Christoph
Titel: Antw:culfw@ARM
Beitrag von: phoenix am 13 Januar 2017, 07:52:09
Ich würde doch noch mal im Hilfe bitten wollen. Denn Sam-ba macht irgendwie probleme. Der Cube ist jetzt leer und wird auch als Comport erkannt, in Sam-ba wähle ich den Port dann aus und wähle das Board wie in Post 1 ausführlich erklärt. Eigentlich ja total simpel, aber nach dem connect passiert nichts mehr. Eigentlich müsste sich dann ja ein neues Fenster öffnen wo man den Bootloader auswählen kann aber das kommt nicht. Der Prozess sam-ba läuft aber weiterhin. Wenn jemand eine Idee hätte wäre das super. Ich habs gerade mal hier auf der Arbeit am PC getestet allerdings wird der Cube hier nicht korrekt erkannt, daher heute abend zu Hause weiter probieren.
Manchmal scheint echt der Wurm drin zu sein
Titel: Antw:culfw@ARM
Beitrag von: Bennemannc am 13 Januar 2017, 08:22:20
Hallo,

ich musste mal eben meine Grauen Zellen aktivieren - hatte ich unter Windoof 7 auch. Habe das dann mit einem alten XP Rechner gemacht, da kam das Fenster zur Bootloaderauswahl. Versuche es mal mit Kompatibilitäts Gedöne. XP SP3 oder älter.

Gruß Christoph
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 13 Januar 2017, 10:00:12
Unter Windows 10 hatte ich SAM-BA auch nicht zum Laufen bekommen. Deswegen hab ich den Bootloader dann unter Linux mit bossa geflasht. Ist glaub ich auch im ersten Post verlinkt.
Titel: Antw:culfw@ARM
Beitrag von: malc_b am 13 Januar 2017, 11:01:55
I had some problems flashing the cube.  One issue was downloading sam-ba v3 when what I need is 2.16.  V2.16 comes with an install so that went in on win7 ok (v3 was just a zip AFAIR).  I also had a problem with my win7 assigning bossa driver to the new com port which I had to remove , deleting driver, before I could follow the 2.16 instructions to get a AT91 com port.  I've used sam-ba to install bootloader and then teraterm to send over aculfw which worked.

UPDATE: when I run translate (german to english) on the page this messes up my point about I found that I must have the COM DRIVER = AT91.  It might be that english to german is also messing this up.
Titel: Antw:culfw@ARM
Beitrag von: phoenix am 14 Januar 2017, 10:09:41
Bossa gibts auch mittlerweile für Windows, hilft ggf. dem einen oder anderen, bei mir funzt Bossa (unter Win7) leider auch nicht, erkennt den Cube nicht.  Ich steige auf das Lan Gateway um oder einen Cul. Aber trotzdem ein schönes Tut, danke dafür, es war einen Versuch wert
Titel: Antw:culfw@ARM
Beitrag von: Bennemannc am 14 Januar 2017, 20:10:35
Hallo,

ich hab einen fertige abzugeben ;-) oder tauschen ? Dann mache ich mir den fertig und verkaude den. So kann man mit dem Teil ja sonst nichts machen.

Gruß Christoph
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 15 Januar 2017, 15:48:00
Hallo, ich habe schon seit ca. 1 Jahr eine MAX Cube am laufen, das funktioniert soweit auch ganz gut.
Um Strom zu sparen läuft jedoch mein komplettes Heim Rechenzentrum mit KVM virtualisiert auf einem Intel NUC auf (inkl. Firewalls und vSwitch).

Da das durchreichen der USB-Ports nicht so richtig funktioniert hat, verwende ich auf dem Hypervisor (Ubuntu) das Programm ser2net um den CUBE und den JeeLink an die VM über TCP/IP durchzureichen.

    #Hypervisor mit ser2net
           #JeeLink
           2000:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03DB4I-if00-port0:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE

           #CUL
           2001:raw:0:/dev/serial/by-id/usb-03eb_AT91USBSerial1-if00:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE

   # VM mit FHEM

    define JeeLink_1 JeeLink 10.10.10.20:2000
    define CUL_1 CUL 10.10.10.20:2001 0000

Beim Neustart von FHEM oder beim Neustart der VM mit FHEM verbinden sich FHEM auch gleich wieder mit den per ser2net bereitgestellten USB-Geräten auf dem Hypervisor. Ich habe jedoch ein Problem wenn ich den Hypervisors (mit allen VMs) komplett Neustarte. Der Jeelink verbindet sich gleich wieder, der CUBE bleibt jedoch im Status "opened" stehen, dann muss ich immer den CUBE vom USB-Kabel trennen und im FHEM ein "reopen" durchführen.

Im Syslog des Hypervisor steht immer
daemon.err: Jan 15 15:34:01 Hypervisor ser2net[1126]: Could not turn off break for device /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00 port 2001: Broken pipe

Hat jemand eine Idee warum sich der CUBE nach einem Neustart des Hypervisors nicht automatisch verbindet?

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 Januar 2017, 11:50:53
Ich hab zwar keine Idee, warum das nicht funktioniert, aber warum verbindest du den Cube nicht direkt über das Netzwerk mit FHEM?
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 16 Januar 2017, 13:33:20
Ich hatte mal ein ähnliches Problem mit dem Vebinden bei einem virtuellen Rechner.
Habe in die /etc/init.d/fhem ein sleep 10 vor den Start eingesetzt - seit dem klappte es immer.


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: mrbit1968 am 21 Januar 2017, 07:48:58
@phoenix

Bei mir läuft Sam-Ba in der Version 2.16 für XP auf Windows 7 64 Bit.
Sollte bei dir auch laufen.

Und immer ruhig bleiben .9 bei Dritten anlauf gings dann auch bei mir. Kannst ja an sich alles wieder auf ausgangspositon stellen.

Gruß
Titel: Antw:culfw@ARM
Beitrag von: tca am 26 Januar 2017, 22:26:08
@Telekatz
Gibt es eine bestimmten/besonderen Grund, weshalb in board.h (CUBe) TTY_BUFSIZE=128 gesetzt ist?

Hintergrund: Ich habe einige Fehlermeldung im Log von 36_WMBUS.pm [https://forum.fhem.de/index.php/topic,42232.msg570006.html#msg570006]; evtl. liegt es am zu kleinen Puffer;
kann man TTY_BUFSIZE=512 bzw. TTY_BUFSIZE=1024 setzen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 Januar 2017, 22:44:00
Ich hab das so vom CUL übernommen.

In der angefügten Version hab ich es mal auf 512 erhöht.
Titel: Antw:culfw@ARM
Beitrag von: tca am 26 Januar 2017, 22:53:41
Danke!
Bin gerade unterwegs, werde es sobald wie möglich testen. Ehm, flashen geht nur per USB nicht über Netzwerk, oder?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 Januar 2017, 23:21:20
Nur über USB.
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 28 Januar 2017, 19:51:21
Hallo,

könnte mir das einer bitte erklären

Die Pins J1 auf dem Cube verbinden und die USB Verbindung kurz ein- und wieder ausstecken um die vorhandene Firmware zu löschen und den Flashspeicher zu entsperren

Vielen Dank im voraus

Grüße Timo
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 28 Januar 2017, 20:11:32
Timo - die J1-Pins sind innen im Cube... und groß dort so durch Aufdruck auf der Platine so bezeichnet. Oder was gibts da sonst noch zu erklären?
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 28 Januar 2017, 20:13:54
Wobei die Pins keine Pins sondern Löcher sind. Die sitzen mittig am Ende der Platine vom LAN-Port aus gesehen.
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 28 Januar 2017, 20:30:19
Ok danke für die schnelle Antwort.
Dann muss ich die zwei Pins miteinander verlöten?

sry für die dummen Fragen!
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 28 Januar 2017, 20:32:39
Nein, nur überbrücken! Nach dem Ein- und Ausstecken des USB-Kabels kannst Du die Verbindung wieder lösen.
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 28 Januar 2017, 20:34:15
Ok vielen dank...werde es die nächsten Tage angehen
Titel: Antw:culfw@ARM
Beitrag von: chris1284 am 30 Januar 2017, 06:55:21
zum überbrücken reicht zb ein breiter schraubendreher oder ne büroklammer , löten muss man nicht ;)
Titel: Antw:culfw@ARM
Beitrag von: malc_b am 30 Januar 2017, 09:43:59
I found that a screwdriver had problems in making contact.  What worked for me was a pair of long nose pliers that would go into the holes.  I think the sharp corner on the pliers made good contact where the flat blade didn't.
Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 30 Januar 2017, 22:22:53
Try it with a small tweezer, and a little pice of solder. ;)

@topic

hm, was muss ich anstellen damit ich mit meinem HM-CFG-USB-2 (Hab nen 2 weitere für alles andere) einen Hörman Promatic (BiSecur) ansprechen kann ?
denn so wie es ausschaut ist ja zumindest dem source nach Hörman aktiv, leider kann ich es ned anwählen. bzw. bekomme es erst garnicht ins autocreate.
kann es sein das in der compilierten image das evtl doch aus ist ?
wenn ja muss ich mal schauen wie ich den source compilen kann. ist ja was anderes wie adurinos.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 Februar 2017, 11:38:18
Ich denke nicht, dass mit dem Hörman Protokoll BiSecure sondern ein älteres Protokoll gemeint ist. Aktiv ist Hörman seit Version 1.23.04.
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 13:40:42
Hallo,

jetzt hab ich es endlich mal versucht den Cube zu flashen.
Hat auch alles geklappt bis zur Firmware draufspielen.
Ich ändere bei minicom die Datei in /dev/ttyACM und gehe mit exit zurück.
Danach kommt der Fehler

minicom: cannot open /dev/ttyACM: No such file or directory


Vielleicht kann mir ja jemand helfen , bin leider ein totaler Anfänger >:(

Vielen Dank
Grüße T1mo
Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 08 Februar 2017, 13:44:48
In /dev/xxxxxx   ändert auch keiner was da diese nur virtuell angelegt werden.  Damit das System auf die diversen Geräte zugreifen kann.

Jedoch nach Anleitung sollte des funktionieren.  Denke mal das du was falsch gelesen hast. Ich selbst nuze 2 hm-usb und nen cul v3.  Beim cube wird das denke ich mal auch passen.

Gesendet von meinem E6853 mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 13:48:56
im folgenden menü geht ihr in die Einstellungen zur Seriellen Verbindung, drückt a, und gebt den Namen (z.B. ttyACM) anstelle der voreinstellung ein (meist auch ttyIRGENDWAS) nur das letzte mus geändert werden, nicht der ganze Pfad. zB: aus /dev/ttyBLUB macht ihr /dev/ttyACM

Wie muss ich das dann verstehen?

Vielen Dank für deine schnelle Antwort
Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 08 Februar 2017, 13:51:09
Siehst du,  da steht Einstellung für,  nicht in das Gerät.

Gesendet von meinem E6853 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 08 Februar 2017, 13:52:56
Jedoch wo die Einstellung dafür ist kann ich dir ned sagen.  Beim raspberry ist das in einer der Dateien für die Kernel einstellung.

Gesendet von meinem E6853 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 13:59:01
ok sry , ich hatte mich falsch ausgedrückt .
Ich hab es in den Einstellungen geändert und danach kommt der Fehler.
Titel: Antw:culfw@ARM
Beitrag von: BlackStone am 08 Februar 2017, 14:01:52
Dann ist entweder beim Flashen schiefgelaufen, oder der hat den nicht erkannt. Oft ist nach dem Flash ein reboot notwendig.

Gesendet von meinem E6853 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: mahowi am 08 Februar 2017, 14:05:21
minicom: cannot open /dev/ttyACM: No such file or directoryWie die Fehlermeldung schon sagt, /dev/ttyACM gibt es nicht. Meines Wissens nach gibt es das eigentlich nie, sondern immer /dev/ttyACM0, ttyACM1 usw. Jetzt solltest Du noch herausfinden, welches Device Dein Cube ist.

Wenn der Bootloader drauf ist, solltest Du ein Device in /dev/serial/by-id mit sowas wie CUBELOADER o.ä. im Namen haben. Dann kannst Du entweder das nehmen, oder das entsprechende ttyACMx, auf das hiervon verlinkt wird.
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 14:16:07
@danke mahowi 

pi@raspberrypi:~ $ dmesg | grep tty
[    0.000000] Kernel command line: 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa22082 bcm2709.serial=0x79b4aa35 smsc95xx.macaddr=B8:27:EB:B4:AA:35 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[    0.000500] console [tty1] enabled
[    0.832415] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
[164856.590936] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[165831.810464] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device
[166308.529753] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[167099.936875] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[168833.284906] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[171088.185946] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device



Und was sollte ich jetzt nehmen:-)
Ich hoffe ich bin kein hoffnungsloser Fall :'(
Titel: Antw:culfw@ARM
Beitrag von: Weisswurstverkäufer am 08 Februar 2017, 14:20:15
was sagt denn

ls -la /dev/serial/by-id/
?
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 14:31:31
pi@raspberrypi:~ $ ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb  8 14:30 .
drwxr-xr-x 4 root root 80 Feb  8 14:30 ..
lrwxrwxrwx 1 root root 13 Feb  8 14:30 usb-03eb_CUBELOADER-if00 -> ../../ttyACM0
Titel: Antw:culfw@ARM
Beitrag von: Weisswurstverkäufer am 08 Februar 2017, 14:33:21
dann musst Du /dev/ttyACM0 nehmen (das hinten ist eine Null)
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 14:42:45
@vielen Dank Weisswurstverkäufer :)

Jetzt finde ich die Firmware nicht in der Directory.....mach jetzt erstmal Pause und ärgere mich über meine Blödheit.
Vielleicht kommt ja eine Eingebung beim Gassi gehen.
Vielen Dank an euch allen
Titel: Antw:culfw@ARM
Beitrag von: Weisswurstverkäufer am 08 Februar 2017, 14:45:50
Wenn Du minicom mit "sudo" gestartet hast befindest Du dich im Ordner "/root". Wenn Du die Firmware da rein legst solltest Du die Datei sofort sehen können
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 16:51:33
ok bin wieder ein Stück weiter gekommen ....aber jetzt geht die Firmware nicht drauf.
Beim ersten Mal wurde was gesendet und ist einer Fehler gekommen und jetzt passiert gar nichts.
Ich hatte nochmal alles von vorne gemacht
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 08 Februar 2017, 18:00:26
Zeig nochmal die Ausgabe von ls -al /dev/serial/by-id/
Wahrscheinlich ist die Firmware schon drauf. Die Fehlermeldung beim Flashen ist normal. minicom wartet noch auf eine Antwort, das alles gesendet wurde, während der Cube aber schon neu startet. Im Normalfall hat das Flashen aber funktioniert.
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 08 Februar 2017, 21:38:18
Ok morgen mittag wenn ich wieder am  Rechner sitze.
Danke dir
Titel: Antw:culfw@ARM
Beitrag von: T1mo am 09 Februar 2017, 14:53:15
pi@raspberrypi:~ $ ls -al /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb  9 14:39 .
drwxr-xr-x 4 root root 80 Feb  9 14:39 ..
lrwxrwxrwx 1 root root 13 Feb  9 14:39 usb-03eb_AT91USBSerial1-if00 -> ../../tty                     ACM0


Die Meldung kommt ,dann müsste alles passen?
Ich hatte den Cube gestern nicht im Lan gefunden , da ich ihn nicht direkt mit Strom versorgt hatte.
Kann man eigentlich eine neue Firmware einfach überspielen?

Vielen Dank für eure super Hilfe
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 09 Februar 2017, 14:57:06
Ja, paßt so.  ;)

Wenn Du neue Firmware aufspielen willst, mußt Du den Cube vom USB trennen und mit gedrücktem "Reset"-Knopf wieder anstecken. Dann bootet er wieder in den Bootloader und ist als /dev/serial/by-id/usb-03eb_CUBELOADER-if00 erreichbar.
Titel: Antw:culfw@ARM
Beitrag von: ripperle am 11 Februar 2017, 11:06:59
Hallo,

ich scheitere leider schon beim flashen des bootloaders (auf dem MAX! Cube). Nach der Verbindung via USB erscheint es unter COM10 und kann dann auch im SAM-BA (v2.16) ausgewählt werden (SAM-BA wurde als Admin gestartet).

Nachdem ich connect drücke verschwindet das Fenster und das wars. Der Prozess ist noch aktiv (im Taskmanager nachgeschaut) aber keine GUI mehr da...

Bitte um Hilfe
Andreas Veit
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 Februar 2017, 11:37:46
Schau mal nach, ob der COM Port in der Auswahlliste zweimal drin ist. Einmal als COM10 und einmal als \USBserial\COM10. Wenn ja, nimm den anderen.
Titel: Antw:culfw@ARM
Beitrag von: ripperle am 11 Februar 2017, 11:51:01
Nein nur einmal als \USBserial\COM10 ...

Gerade auf einem anderen PC installiert und bekomme das gleiche Ergebnis...

Es gibt neben dem Installer "SAM-BA 2.16 for Windows (XP, Vista, Seven editions)" auch noch ein ZIP Archiv "SAM-BA 3.1.4 for Windows (XP, Vista, Win7, Win8)"... Dieses beinhaltet allerdings nur eine cmd line .exe....  ???
Titel: Antw:culfw@ARM
Beitrag von: ripperle am 11 Februar 2017, 12:22:28
Windows...

Gerade mein PC unter Linux gestartet und schon funktioniert SAM-BA... Habe den Bootloader erfolgreich geflasht (LED D1 blinkt)

Wenn ich die FW mittels minicom (siehe https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429) flashen möchte muss man nach "Datei senden" folgedes auswählen:
- zmodem
- ymodem
- xmodem
- kermit
- ascii

Was wähle ich denn da?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 Februar 2017, 12:28:06
xmodem
Titel: Antw:culfw@ARM
Beitrag von: ripperle am 11 Februar 2017, 13:08:41
mhh kommt leider failed...

EDIT:
Wenn ich den Cube (ohne Gehäuse ist es ja eher ein Quader  ;D ) wieder unter windows anschließe taucht er im device manager als "CUBELOADER" unter andere Geräte auf... Welche Treiber muss ich dem jetzt zuweisen (sollte ja wieder als COM Port auftauchen um mittels TeraTerm die FW zu flashen)?

EDIT2:
Ich habe übrigens den bootloader aus dem ersten ZIP (V1.10.00 build163) genommen, da in der neuestem ZIP (V1.23.09 build195) keine bootloader_CUBE.bin mehr im Ordner CUBe drin ist...

EDIT3:
Ok habe (unter Windows) im device manager dem Gerät den Atmel Serivell Driver aufgezwungen. Danach wurde er als COM erkannt. Dann wie beschrieben mittels TeraTerm die CUL FW drauf geflasht... Jetzt blinkt er im sekundentakt und D3 leuchtet konstant...

EDIT4:
MAXCube aka CUL an den Raspy angeschlossen und wie im wiki beschrieben angelegt und mit Thermostat gepaired... Sofort funktioniert! Klasse!
Titel: Antw:culfw@ARM
Beitrag von: Christian1982 am 12 Februar 2017, 19:07:27
Ich habe leider immer noch ein Problem mit der Erreichbarkeit des CULs (MAX CUBe) nach einen Neustart des Intel NUCs (mit Ubuntu Server 16.10).
Nach einem Neustart muss ich den CUB (nur mit USB Verbunden) immer manuell vom USB-Kabel trennen und neu verbinden, erst danach kann ich mich wieder verbinden.
Dann funktioniert auch der Befehl "V" (gibt die Version aus) auf der Konsole und mit "echo "B00." > /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00" kann ich den CUL auch reseten.
Mit einem "set CUL_1 reopen" kann ich den CUL dann auch wieder von FHEM aus ansprechen.
Nach den Neustart des Computers ist der CUL zunächst jedoch nicht mehr ansprechbar, weder "V" noch "B00." funktionieren, erst ein trennen des USB-Kabels hilft. 

Jemand eine Lösung?
Titel: Antw:culfw@ARM
Beitrag von: Bond246 am 13 Februar 2017, 00:20:18
Hallo zusammen,

ich möchte in meiner neuen Wohnung die Heizungssteuerung mit dem MAX-System machen. Dazu ist geplant bei ELV die Bausätze der Thermostate zu kaufen.
Außerdem finde ich die Möglichkeit gut, den MAX-Cube einfach umzuflashen, um die üblichen Funktionen eines CUL zu haben. Vorteil ist, dass man Netzwerk hat statt USB. Außerdem ließe sich der Cube noch relativ gut in die Wohnung integrieren. So ein USB-Stick ist da schon "hässlicher". Und der Cube als Bausatz ist natürlich sehr günstig im Vergleich zum CUL von busware.

Würdet ihr das empfehlen oder lieber gleich einen CUL USB-Stick kaufen?

Zugegeben, ich hab nicht alle 50 Seiten des Thread gelesen. Anfangs gab es wohl die Einschränkung, dass man die Temperatur der Thermostate nicht richtig auslesen konnte. Gibt es noch Einschränkungen, in Bezug auf den Cube in Verbindung mit FHEM oder ist das mehr oder weniger uneingeschränkt zu empfehlen?

Für Später plane ich, unter Umständen ein Thermometer eines anderen Hersteller zu nutzen, das die gleiche Frequenz des Cube nutzt. Wäre das kompatibel zueinander oder führt da kein Weg hin?

Ich hoffe ich habe damit nicht zu viele Fragen, die vermutlich so ähnlich schon gefragt wurden, gestellt.

Schöne Grüße,
Bond
Titel: Antw:culfw@ARM
Beitrag von: Weisswurstverkäufer am 13 Februar 2017, 07:39:56
Wenn Du sowieso einen Cube für MAX kaufst kannst Du ihn auch direkt ungeflasht nutzen. Der Cube mit der originalen Firmware wird ja auch von fhem unterstützt.

Mehrere Protokolle auf einem CUL geht nicht - Du musst immer einen Modus wählen (z. B. Homematic, MAX).
Titel: Antw:culfw@ARM
Beitrag von: Code006 am 13 Februar 2017, 22:58:47
Hi Telekatz,

vielen Dank für deine super Arbeit :) Ich habe meinen ersten Cube als Homematic CUNx laufen. Hat alles nach Anleitung funtioniert!

Jetzt überlege ich, auch Z-Wave mit einem 2. Cube einzusetzen. Wenn ich mir das a-culfw Changelog ansehe, müsste seit Version 1.20.05 Z-Wave unterstützt werden. Geht das auch mit dem Cube?

Vielen Dank
Code006
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 Februar 2017, 23:21:30
Die Z-Wave Unterstützung ist wohl mehr experimentell und nicht wirklich produktiv einsetzbar, siehe auch diese Aussage: https://forum.fhem.de/index.php/topic,59292.msg507394.html#msg507394 (https://forum.fhem.de/index.php/topic,59292.msg507394.html#msg507394)
Titel: Antw:culfw@ARM
Beitrag von: Code006 am 15 Februar 2017, 06:44:40
Die Z-Wave Unterstützung ist wohl mehr experimentell und nicht wirklich produktiv einsetzbar, siehe auch diese Aussage: https://forum.fhem.de/index.php/topic,59292.msg507394.html#msg507394 (https://forum.fhem.de/index.php/topic,59292.msg507394.html#msg507394)

Danke für die schnelle Info, auch wenn sie nicht so ist, wie ich sie gerne hätte...
Titel: Antw:culfw@ARM
Beitrag von: stenny73 am 15 Februar 2017, 19:25:54
Ich habe leider immer noch ein Problem mit der Erreichbarkeit des CULs (MAX CUBe) nach einen Neustart des Intel NUCs (mit Ubuntu Server 16.10).
Nach einem Neustart muss ich den CUB (nur mit USB Verbunden) immer manuell vom USB-Kabel trennen und neu verbinden, erst danach kann ich mich wieder verbinden.
Dann funktioniert auch der Befehl "V" (gibt die Version aus) auf der Konsole und mit "echo "B00." > /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00" kann ich den CUL auch reseten.
Mit einem "set CUL_1 reopen" kann ich den CUL dann auch wieder von FHEM aus ansprechen.
Nach den Neustart des Computers ist der CUL zunächst jedoch nicht mehr ansprechbar, weder "V" noch "B00." funktionieren, erst ein trennen des USB-Kabels hilft. 

Jemand eine Lösung?


Ich hatte ein ähnliches Problem bei der USB Anbindung.
Ich habe es in der /etc/init.d/fhem habe ich beim Start einen sleep 20 eingetragen danach klappte es bei mir immer

stenny


Gesendet von iPad mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: fabi29891 am 25 Februar 2017, 15:18:06
Hallo,
habe gerade versucht den Max Cube als CUL zu flashen. Wenn ich nun Sam-ba( Version 2.16) als Administrator starte, den neu erschienenen COM Port (COM-Port ist erst erschienen nachdem ich den Treiber manuell eingebunden hab.) auswähle erscheint die Meldung im Anhang.Hat jemand eine Idee? Bei Bossa für Windows erscheint die Meldung Could not connect to device on COM4.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 04 März 2017, 06:47:10
Ich habe gerade die Sourcen von github aktualisiert. Wofür ist denn das neue Build-Target "CUBEx4"? Im Changelog konnte ich dazu leider nichts finden.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 März 2017, 12:35:13
Das ist ein Cube mit 4 Transceivermodulen. Wie auch der MapleCUNx4.
Titel: Antw:culfw@ARM
Beitrag von: A.Harrenberg am 05 März 2017, 11:13:16
Hi,
Danke für die schnelle Info, auch wenn sie nicht so ist, wie ich sie gerne hätte...
ich bin einer der drei erwähnten Nutzer eines ZWave-CUL in dem verlinkten Beitrag von Telekatz...  ;D

Zur Zeit wird ein 4fach CUL/CUN auf Basis von einem Maple-Mini gebaut, ich plane diese Platine mit drei 868Mhz-Empfänger zu bestücken und dadurch den Empfang / das Senden auf allen drei möglichen Frequenzen zu unterstützen. Hauptsächlich soll dies als "Sniffer" dienen, aber vielleicht gelingt es uns ja auch doch noch einen Frequenzwechsel "on-the-fly" zu ermöglichen um das Ganze dann mit nur einem Empfänger zu realisieren. Es wird sicherlich noch eine Weile dauern, aber es wird in der Richtung weitergehen.

Gruß,
 Andreas.
Titel: Antw:culfw@ARM
Beitrag von: KölnSolar am 16 März 2017, 09:11:37
Hallo Telekatz,
ich bin per Zufall auf die Betty-FB aufmerksam geworden. Wenn ich es richtig interpretiere, hat Du auch mal so ein Ding besessen und es war möglicherweise sogar der Anlass die culf@ARM zu entwickeln.

Ich wollte jetzt hier https://forum.fhem.de/index.php/topic,69112.msg605937.html#msg605937 das Betty-Thema aufgreifen. Wäre nett, wenn Du dort ein paar warme Worte zu Deinen Betty-Erfahrungen und dem Einsatz der culf@ARM auf diesem Gerät verlieren könntest.

Grüße Markus
Titel: Antw:culfw@ARM
Beitrag von: Kroegi am 20 März 2017, 19:02:26
Hab da grade auch so ein Phänomen mit dem Schätzchen.
Er lief jetzt von Anfang an ohne Probleme.
Nun stand da plötzlich "disconnectet", zum Glück habe ich zwei davon in Betrieb.
Also den ausgefallenen mal resettet, neu geflasht und aktuelle Firmeware drauf.
Er reagiert auch augenscheinlich ganz normal, hat ohne Fehler alles aufgenommen und Leuchtet / Blinkt wie eh und je.
Ich sehe ihn auch bei den Geräten in der Fritzbox, hat seine IP Adresse bekommen.
Nur in FHEM taucht er nicht mehr auf.
Was kann ich da noch grossartig machen?

Moin. Hab erneut dieses Problem, allerdings mit dem anderen Cube.
Hab dieses ebenfalls resettet, neu geflasht, feste IP vergeben und was sonst alles dazugehört.
Er bleibt trotzdem in fhem unsichtbar.
Auf der Fritzbox taucht er mit seiner üblichen IP Adresse auf.
Habe ihn aus fhem als device gelöscht, er sollte doch nach reboot unter Everything wieder auftauchen?
Oder bin ich grad einfach mal wieder zu doof??
Titel: Antw:culfw@ARM
Beitrag von: Johnnyflash am 21 März 2017, 09:54:44
Hallo zusammen,
hatte bei mir bisher zwei HM-CFG-USB-2 mit der a-culfw (V 1.24.01 a-culfw Build: 204) im Einsatz, da ich Homematic und Max im Mischbetrieb hatte. Da ich jetzt nur noch Max einsetze, habe ich einen HM-CFG-USB-2 übrig. Mit dem wollte ich jetzt gerne ein paar Intertechno kompatible Geräte einbinden, schalten klappt auch soweit, aber empfangen von Hand- /Wandsendern geht leider bisher nicht. Habe lediglich die Frequenz über ein "set freq 433.92" umgestellt. Muss ich für den Empfang von IT Komponenten noch was anderes tun?

Grüße
Philipp
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 März 2017, 11:35:39
Moin. Hab erneut dieses Problem, allerdings mit dem anderen Cube.
Hab dieses ebenfalls resettet, neu geflasht, feste IP vergeben und was sonst alles dazugehört.
Er bleibt trotzdem in fhem unsichtbar.
Auf der Fritzbox taucht er mit seiner üblichen IP Adresse auf.
Habe ihn aus fhem als device gelöscht, er sollte doch nach reboot unter Everything wieder auftauchen?
Oder bin ich grad einfach mal wieder zu doof??
Wenn du ihn aus FHEM gelöscht hast, musst du ihn neu anlegen. Von alleine wird er nicht angelegt.

Hallo zusammen,
hatte bei mir bisher zwei HM-CFG-USB-2 mit der a-culfw (V 1.24.01 a-culfw Build: 204) im Einsatz, da ich Homematic und Max im Mischbetrieb hatte. Da ich jetzt nur noch Max einsetze, habe ich einen HM-CFG-USB-2 übrig. Mit dem wollte ich jetzt gerne ein paar Intertechno kompatible Geräte einbinden, schalten klappt auch soweit, aber empfangen von Hand- /Wandsendern geht leider bisher nicht. Habe lediglich die Frequenz über ein "set freq 433.92" umgestellt. Muss ich für den Empfang von IT Komponenten noch was anderes tun?

Grüße
Philipp
Für den Empfang von 433MHz Geräten nimmt man eine Empfänger, der für 433MHz angepasst ist. Der HM-CFG-USB-2 empfängt mit seinem 868MHz Empfänger nur im Nahbereich 433MHz Signale.
Titel: Antw:culfw@ARM
Beitrag von: Kroegi am 21 März 2017, 11:57:21
Wenn du ihn aus FHEM gelöscht hast, musst du ihn neu anlegen. Von alleine wird er nicht angelegt.

Schon klar, sollte er denn nicht selbstständig in der Everything Liste auftauchen? Mir was so als wenn das bisher so funktioniert hat und er sich als neuer CUL gezeigt hat.
Hab ihn dann nur dem passenden Raum zugeordnet und ihm einen anderen Namen gegeben.
Ist alles schon länger her, daher sorry für die Anfängerfrage.

Guss
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 März 2017, 12:03:54
Der Cube wird nicht per autocreate angelegt. Von alleine taucht er in keiner Liste auf.
Titel: Antw:culfw@ARM
Beitrag von: tca am 26 März 2017, 22:19:50
Hi,

ich verwende einen CUBe mit kompilierter Firmware ([boards.h] #define TTY_BUFSIZE 1024).

Jetzt verwende ich seit kurzem einen WMBUS-Wasserzähler, der zum Testen mit einem CUL/COC fehlerfrei empfangen werden kann, aber mit einem CUBe diesen Fehler erzeugt:

WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6

Der Log-Auszug dazu:
2017.03.26 21:58:40 5: CUL/RAW: /b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857
2017.03.26 21:58:41 5: CUL/RAW: b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857/b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009

2017.03.26 21:58:41 4: CUL_Parse: cube b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 5: cube: dispatch b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 5: WMBUS raw msg b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 2: WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
2017.03.26 21:58:41 5: CUL/RAW: /b32446850325746926980896FA0119F213112A0277F061C0D601149806C6601AC9067816F360000295D2A3C29306892AF607F6988988E849990C5BE84EB

Ich würde vermuten, dass es evtl. an einer Buffer-Einstellung der '/a-culfw' Firmware liegt und weniger am 36_WMBUS.pm -Modul? Kann jemand helfen?

Tom
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 März 2017, 22:38:10
Wie sieht denn die RAW message des CUL/COC aus? Und zum Vergleich die RAW Message, die der Cube gleichzeitig empfängt.
Titel: Antw:culfw@ARM
Beitrag von: tca am 27 März 2017, 12:47:24
Hier die Log-Einträge zum Vergleich:

WMBus-Device [COC]
COC_RAWMSG
b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61

WMBus-Device [CUBe]
cube_RAWMSG
b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC

Logfile [COC]
2017.03.27 12:24:09 5: CUL/RAW: /b3244685
2017.03.27 12:24:09 5: CUL/RAW: b3244685/07931809
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809/269804F5FA0119F2
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F2/1CD05B02
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B02/74B02F706F806003
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003/B03B8008
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008/CEEB1DE856500000
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE856500000/00000000
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE85650000000000000/00001F4480A3F1A0
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A0/01772386
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A001772386/84D8A148004

2017.03.27 12:24:09 4: CUL_Parse: COC b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A148004 -72
2017.03.27 12:24:09 5: COC: dispatch b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A1480::-72
2017.03.27 12:24:10 5: CUL/RAW: /b7644210
2017.03.27 12:24:10 5: CUL/RAW: b7644210/42003377
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377/025071C5F7220033
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033/77021042
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F722003377021042/5078900600535236
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236/D8D2AD8C
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C/58E160B147829F89
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89/FB0D470A
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470A/F36B931358D43DE2
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE2/2F82A2CB
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB/730141AEF3C3805B
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805B/CA7EFCDF
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF/268BE9FE8A2DF21C
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C/02FDA68B55207554
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B55207554/51A63D77
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D77/3D11F14510761CEE
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEE/FE589948
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE589948/4DB92055044476C0
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C0/72FB4402
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402/CE3AF8DF06F3A6C3
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3/B56E9737
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737/C096B4AB8CA7B704
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704/043A7A28
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A28/01A

2017.03.27 12:24:10 4: CUL_Parse: COC b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A2801A -61
2017.03.27 12:24:10 5: COC: dispatch b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61
2017.03.27 12:24:10 5: WMBUS raw msg b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61

Logfile [CUBe]
2017.03.27 12:19:11 5: CUL/RAW: b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565E/b2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC

2017.03.27 12:19:11 4: CUL_Parse: cube b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 5: cube: dispatch b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 5: WMBUS raw msg b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 2: WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
2017.03.27 12:19:12 5: CUL/RAW: /b324468506642819269803B29A0119F216304B0271F02DC0AC30D214089D40069704C5C2E250500010100000000023D7A0C26143B5D4F1D86B6FAB880F1
b324468506074469269808A9CA0119F210F02B027AD005B072A0700005C2F000000000000000E0000000000000000A9A407280E091C4E4C9C692CD08303

Mit dem COC/CUL wird alles fehlerfrei empfangen, mit dem CUBe klappt es leider nicht.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 März 2017, 13:28:50
Kannst du mal beide gleichzeitig auf Empfang stellen, um zu sehen, wie die Ausgabe der selben Nachricht ist.
Titel: Antw:culfw@ARM
Beitrag von: tca am 27 März 2017, 14:04:23
ok, hatte auf Anhieb nicht gleich geklappt ... jetzt aber:

COC
2017.03.27 13:59:20 5: CUL/RAW: /b7644210
2017.03.27 13:59:20 5: CUL/RAW: b7644210/42003377025071C5
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5/F7220033
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033/770210425079C006
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006/005ECDC2
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC2/8270FFAB10BF558B
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558B/E451C2707BEA2992
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992/500A4984
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984/CC46AD9CE8F82305
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305/D08C28BD52AFFB40
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40/A096763B
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763B/E7484FEFBEBF821C
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C/5B3A2BBC59C8438F
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438F/C462CEEE
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE/2075F3E45285FCDD
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDD/FD5CE19620343B7D
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7D/C704C47F
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F/446143F654C162DC
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC/92B0AE7D01CF08E7
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7/CF25A019
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019/E378B9CB0842CAF8
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF8/01A

2017.03.27 13:59:20 4: CUL_Parse: COC b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF801A -61
2017.03.27 13:59:20 5: COC: dispatch b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF80::-61
2017.03.27 13:59:20 5: WMBUS raw msg b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF80::-61
2017.03.27 13:59:21 5: CUL/RAW: /b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF

CUBe
2017.03.27 13:59:22 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF/b3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C

2017.03.27 13:59:22 4: CUL_Parse: cube b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFb3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 5: cube: dispatch b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFb3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 5: WMBUS raw msg b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFb3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 2: WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 März 2017, 22:00:15
Wie hast du den Cube angeschlossen? Über USB oder Netzwerk? Und hast du beides schon mal ausprobiert?
Titel: Antw:culfw@ARM
Beitrag von: tca am 27 März 2017, 22:58:15
Der Cube ist über Netzwerk angeschlossen.

Beim COC werden offenbar einzelne Blöcken in das Log geschrieben: bis zur Position/Block "...92B0AE7D01CF08E7" stimmt COC und CUBe überein, dann wird beim CUBe eine weitere Message -von einem Techem HKV- mit reingenommen.

Beim COC kommt der Block "CF25A019". Beim CUBe wir die Zeichenfolge aber mit "CF/b3244685061508292698087ADA011..." fortgesetzt. "CF" stimmt also auch noch, dann kommt aber direkt eine andere/neue Message, die mit "/b324468506150829..." beginnt.

Kann es sein, dass "25A0" etwas auslöst bzw. etwas überläuft?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 März 2017, 23:12:36
Ich denke, es liegt am Netzwerk Stack. Der läuft nach 250 Bytes voll. Teste mal über USB.
Titel: Antw:culfw@ARM
Beitrag von: tca am 28 März 2017, 00:14:25
Ja, über USB geht es.
Wo/wie kann man den Netzwerk-Stack höher einstellen? Im ringbuffer.h, CUBe/board.h, ...?

Ich hatte TTY_BUFSIZE auf 1024 gestellt. -> der CUBe hat doch >1024*4 RAM?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 März 2017, 22:32:55
Teste mal die angefügte Version.
Titel: Antw:culfw@ARM
Beitrag von: tca am 28 März 2017, 23:53:12
Ja, damit geht es :-) :-)

Könntest Du das bitte auf github 'einchecken' ... ich würde noch gerne für mich den 'rAmpl' von 33dB auf 40dB hochstellen ;-)

Vielen Dank!!!
Titel: Antw:culfw@ARM
Beitrag von: bigmo am 14 April 2017, 22:07:04
Man kann den Cube ja auch mit der originalen Firmware also die von max in Fhem einbinden und betreiben. Welche Vorteile habe ich denn wenn ich sie culfw flashe?
Titel: Antw:culfw@ARM
Beitrag von: noice am 14 April 2017, 22:46:59
Man kann den Cube ja auch mit der originalen Firmware also die von max in Fhem einbinden und betreiben. Welche Vorteile habe ich denn wenn ich sie culfw flashe?
Das du ihn nicht nur für max! verwenden kannst sondern mit allen Protokollen die der cul 868 nutzt betreiben kannst. Und das im netzwerk.



Gesendet von meinem SM-T325 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: bigmo am 15 April 2017, 11:24:52
Ok das leuchtet ein. ABer wenn ich nur MAX komponenten verwende, welche Vorteile habe ich dann??
Oder anders gefragt, welche Option ist für eine reine MAX Umgebung mit FHEM die beste Wahl:

-Cul Stick
-Max Cube geflasht
-Max Cube original
Titel: culfw@ARM
Beitrag von: RaspiLED am 15 April 2017, 11:40:09
Hi,
Die dritte weil am wenigsten Arbeit. Und nach zwei Monaten will man mehr und flasht den Cube. Und dann holt man sich einen Cul in der anderen Frequenz ;-) Ganz ehrlich wir haben alle klein angefangen und dann kommt der Spieltrieb und der Zoo an Gateways!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 15 April 2017, 13:24:39
Welche Vorteile habe ich denn wenn ich sie culfw flashe?
Der entscheidene Vorteil liegt IMHO darin das FHEM seine einmal definierten Geräte und Parameter nicht mehr vergisst, ganz im Gegensatz zur Original MAX Alzheimer Software auf dem Cube !
Titel: Antw:culfw@ARM
Beitrag von: audimax am 20 April 2017, 14:31:51
Hallo zusammen,

zuerst danke für das tolle Projekt.
Vielleicht hat jemand einen Tipp für mich, aber ich hänge an einem Problem.
Meinem MAX! Cube (BC-LGW-O-TW-Ha xavax gelabeld) habe ich den alternativen Bootloader verpasst und a-culfw aus dem ersten Post.
Versionen habe ich einige durch im Moment ist es Build 209 (neuste Datei).

Auf der seriellen Schnittstelle nach Eingabe V kommt: V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)

Nun zum Problem:
Der Cube erhält keine IP vom dhcp Server. Auch wenn ich manuell eine IP einstelle bekomme ich keine Verbindung weder per telnet noch fhem.
Die Netzwerkdiagnose über die Konsole E... liefert keine Ausgabe.

Gibt es dazu irgendwelche Tipps oder Erkenntnisse?

Danke
gruß max
Titel: Antw:culfw@ARM
Beitrag von: pejonp am 20 April 2017, 17:02:30
@audimax
Den Cube per USB nur mit Strom versorgen und nicht als USB-Geräte anschliessen. So fährt dieser in den nezwerkmodus. Ist zumindest bei meinem so. Version 1.20...

Pejonp
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 20 April 2017, 17:42:33
Ja, steht auch irgendwo in den Anfängen dieses Threads. Wenn er gleichzeitig auch als USB-Gerät angeschlossen wird, ist er nicht übers Netzwerk erreichbar.
Titel: Antw:culfw@ARM
Beitrag von: audimax am 20 April 2017, 17:49:04
@pejonp
Danke für die schnelle Antwort.
Leider finde ich die Box so auch nicht im LAN. Weder mit dhcp vergabe noch per fixer IP.
Allerdings leuchtet so die Battery LED nicht. Nur Internet leuchtet und Power blinkt.
nmap findet auf der fixen IP auch nichts

max
Titel: Antw:culfw@ARM
Beitrag von: audimax am 28 April 2017, 18:31:12
Hat noch jemand einen Tipp für mich?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 April 2017, 18:47:51
Du könntest mal die Debugausgaben loggen https://forum.fhem.de/index.php/topic,38404.msg524928.html#msg524928 (https://forum.fhem.de/index.php/topic,38404.msg524928.html#msg524928).
Titel: Antw:culfw@ARM
Beitrag von: palatin8 am 30 April 2017, 03:04:28
@audimax
Ja, vielleicht ein Tipp - klingt etwas verrückt und ich hab das so noch nicht erlebt: probiere es an einem anderen Switch, der 10/100/1000 Mbit unterstützt!

Ich hab wohl die gleiche Prozedur durch wie du. 53 Forenseiten gelesen, den CUBe x-Mal neu geflashed mit a-culfw in verschiedenen Versionen, mit Bootloader und ohne als CUBE.bin. Jedes Mal USB-Verbindung okay, aber an zwei verschiedenen Routern mit 10/100-Switches keine LAN-Verbindung, nicht per DHCP und nicht mit fester IP (dabei war das LAN-Interface der Grund für fie Anschaffung des CUBE). Dann den CUBeCUL mal versuchsweise an einen Router mit Gigabit-Ports angeschlossen, und siehe da, er erhält seine IP per DHCP! Zurück geflashed auf den letzten Bootloader und das aktuelle CUBE_BL.bin, feste IP und Gateway vergeben, und es läuft am 10/100/1000-Port, aber nicht am 10/100-Port.

Kann das sein, dass so ein simples Stück Hardware einen Gigabit-LAN-Port voraussetzt?
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 02 Mai 2017, 14:29:31
Kann das sein, dass so ein simples Stück Hardware einen Gigabit-LAN-Port voraussetzt?
Nein, ich habe zwei von den Würfeln am laufen und habe KEINEN Gigabit Switch !
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 07 Juni 2017, 20:52:49
Hallo!

Habe folgendes Problem: hatte eine ältere FW auf dem Cube (übrigens: großen DANK für die tolle Arbeit!) (irgendwas 1.20), da ich da ein 433er-Gerät nicht richtig erkennen konnte, wollte ich mal zur Sicherheit auf die aktuelle Version gehen (V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05)). Hat auch ohne Probleme funktioniert. MAX-Modus geht auch weiterhin ohne Probleme, allerdings kann ich jetzt mit freq 433.92 gar nichts empfangen (davor hatte ich wenigstens "unknown codes" empfangen. Allerdings bin ich nicht sicher, ob ich den Cube jetzt richtig umschalten kann, da:

wenn ich attr Cube rfmode SlowRF mache bekomme ich folgendes im Log (verbose ist auf 5):

2017.06.07 20:49:42 5: SW: Ax
2017.06.07 20:49:42 5: SW: Zx
2017.06.07 20:49:42 5: SW: brx
2017.06.07 20:49:42 5: SW: X21
2017.06.07 20:49:42 2: Switched Cube rfmode to SlowRF
2017.06.07 20:49:42 5: CUL/RAW: /OFF

2017.06.07 20:49:42 4: CUL_Parse: Cube OFF
2017.06.07 20:49:42 5: Cube: dispatch OFF
2017.06.07 20:49:43 3: Cube: Unknown code OFF, help me!


Mache ich irgendwas falsch oder habe ich was überlesen? Habe diesen Thread jetzt schon mindestens 2x durch... :(

Vor dem Flashen der aktuellen FW konnte ich mit rfmode SlowRF, freq 433.92 und raw X25 alles sehen, jetzt wie gesagt nichts mehr....?

Mir gehen die Ideen aus...

Andy
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 07 Juni 2017, 21:31:17
Hi,
Was sagt denn
get <sev> cmds
Ist Intertechno überhaupt mit in der Firmware drin?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 07 Juni 2017, 21:32:27
Setz mal mit "raw e" den EEPROM zurück und probier es nochmal.
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 07 Juni 2017, 22:45:59
Hallo!

Cube cmds =>  B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z

Wenn ich set Cube raw e mache, setzt er sich zwar zurück (laut Log ist die Verbindung kurz weg und kommt dann wieder), aber helfen tut's nicht.

Einmal habe ich's hinbekommen auf SlowRF umzuschalten ohne Fehler nachdem ich ihn stromlos gemacht habe, das lässt sich aber leider nicht reproduzieren... (also wenn ich ihn nochmal stromlos mache, geht's trotzdem nicht)...

Irgendwo ist da der Hund drinnen, aber ich hab - wie gesagt - keine Idee wo oder wo/wie ich das suchen könnte...
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 07 Juni 2017, 22:47:34
Das internal "Clients" sagt folgendes, demnach müsste zB IT drinnen sein:

:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 07 Juni 2017, 23:10:55
Mach mal ein "list" vom Cube.
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 07 Juni 2017, 23:28:32
Hier Ausgabe von list Cube:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   Cube_MSGCNT 14
   Cube_TIME  2017-06-07 23:06:24
   DEF        /dev/ttyACM0@9600 1234
   DeviceName /dev/ttyACM0@9600
   FD         40
   FHTID      1234
   NAME       Cube
   NR         107
   PARTIAL
   RAWMSG     27  900
   RSSI       -57.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-07 23:25:06   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2017-06-07 23:25:03   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2017-06-07 22:50:50   credit10ms      394
     2017-06-07 19:31:02   fhtbuf          AE
     2017-06-07 23:15:35   raw             No answer
     2017-06-07 23:25:03   state           Initialized
     2017-06-07 20:40:01   uptime          0 00:16:00
     2017-06-07 19:30:37   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Attributes:
   icon       cul_cul
   rfmode     MAX
   room       System
   verbose    5
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 07 Juni 2017, 23:48:32
Im Normalbetrieb ist der Cube dazu da, um mit MAX-Komponenten zu sprechen. Scheinbar ist es jetzt so, dass das nicht mehr funktioniert, sobald man eine der genannten Einstellungen ändert (welche genau das auslöst, konnte ich noch nicht eingrenzen), bis man das Ding dann wieder stromlos macht (auch ein set Cube raw e hilft nix)... :(

Kann etwas beim Flashen so schief gegangen sein, dass dieses dubiose Verhalten erklärbar macht, oder was könnte da sein?

Was mir noch aufgefallen ist: nachdem ich den Cube jetzt wieder mal stromlos gemacht habe, ist mir ein Unterschied aufgefallen zu gerade eben - siehe list Cube jetzt:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   Cube_MSGCNT 33
   Cube_TIME  2017-06-07 23:46:15
   DEF        /dev/ttyACM0@9600 1234
   DeviceName /dev/ttyACM0@9600
   FD         40
   FHTID      1234
   NAME       Cube
   NR         107
   PARTIAL
   RAWMSG     Z0B140630102642123456005028
   RSSI       -54
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   initString X21
Zr
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-07 23:44:59   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-06-07 23:44:54   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2017-06-07 23:43:31   credit10ms      553
     2017-06-07 19:31:02   fhtbuf          AE
     2017-06-07 23:39:13   raw             25  768
     2017-06-07 23:46:15   state           Initialized
     2017-06-07 23:29:39   uptime          0 00:04:50
     2017-06-07 23:29:43   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Attributes:
   icon       cul_cul
   rfmode     MAX
   room       System
   verbose    5

Was bei Clients steht, dürfte ja vom rfmode abhängig sein, also irgendwie passt da was nicht zusammen, oder ich sehe schon den Wald vor lauter Bäumen nicht...

???
Titel: Antw:culfw@ARM
Beitrag von: Ranseyer am 08 Juni 2017, 07:46:12


Zitat

Kann das sein, dass so ein simples Stück Hardware einen Gigabit-LAN-Port voraussetzt?

Klar, wenn z.B. die LAN Verkabelung fehlerhaft ist oder ein Crossover Kabel verwendet wird. Bei Gigabit LAN werden  manche solcher Probleme ausgeglichen.


Gesendet von meinem HTC One_M8 mit Tapatalk

Titel: culfw@ARM
Beitrag von: RaspiLED am 08 Juni 2017, 08:12:43
Hi,
wie kommt es zu den Änderungen an den ccconf Zeilen? Und warum hast Du die jeweils so eingestellt?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 08 Juni 2017, 11:11:56
Ok, damit nichts verfälscht ist oder so, jetzt nochmal der Reihe nach:

Cube List nach einem Reset (sollte das gleiche wie oben sein):
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   Cube_MSGCNT 25
   Cube_TIME  2017-06-08 10:37:24
   DEF        /dev/ttyACM0@9600 1234
   DeviceName /dev/ttyACM0@9600
   FD         18
   FHTID      1234
   NAME       Cube
   NR         107
   NR_CMD_LAST_H 6
   PARTIAL
   RAWMSG     Z0B5E0630118956100F7C0010F5
   RSSI       -79.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za123456
Zw111111
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-07 23:44:59   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-06-08 08:03:13   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2017-06-08 10:04:17   credit10ms      364
     2017-06-07 19:31:02   fhtbuf          AE
     2017-06-07 23:39:13   raw             25  768
     2017-06-08 10:37:24   state           Initialized
     2017-06-07 23:29:39   uptime          0 00:04:50
     2017-06-07 23:29:43   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1496909031.64916
     1496909038.17139
     1496909039.68619
     1496909045.70287
     1496909051.71928
     1496909057.73275
Attributes:
   icon       cul_cul
   rfmode     MAX
   room       System
   verbose    5

Jetzt setze ich das Attribut rfmode auf SlowRF, was mir im Log folgende Einträge bringt:
2017.06.08 10:42:21 5: SW: Ax
2017.06.08 10:42:21 5: SW: Zx
2017.06.08 10:42:21 5: SW: brx
2017.06.08 10:42:21 5: SW: X21
2017.06.08 10:42:21 2: Switched Cube rfmode to SlowRF
2017.06.08 10:42:21 5: CUL/RAW: /OFF

2017.06.08 10:42:21 4: CUL_Parse: Cube OFF
2017.06.08 10:42:21 5: Cube: dispatch OFF
2017.06.08 10:42:21 3: Cube: Unknown code OFF, help me!

Cube List sieht jetzt so aus:
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   Cube_MSGCNT 26
   Cube_TIME  2017-06-08 10:42:21
   DEF        /dev/ttyACM0@9600 1234
   DeviceName /dev/ttyACM0@9600
   FD         18
   FHTID      1234
   NAME       Cube
   NR         107
   NR_CMD_LAST_H 6
   PARTIAL
   RAWMSG     OFF
   RSSI       -79.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-07 23:44:59   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-06-08 08:03:13   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2017-06-08 10:04:17   credit10ms      364
     2017-06-07 19:31:02   fhtbuf          AE
     2017-06-07 23:39:13   raw             25  768
     2017-06-08 10:42:21   state           Initialized
     2017-06-07 23:29:39   uptime          0 00:04:50
     2017-06-07 23:29:43   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1496909031.64916
     1496909038.17139
     1496909039.68619
     1496909045.70287
     1496909051.71928
     1496909057.73275
Attributes:
   icon       cul_cul
   rfmode     SlowRF
   room       System
   verbose    5

Jetzt noch die Frequenz auf 433.92, hier den entsprechenden Logs:
2017.06.08 10:43:57 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.06.08 10:43:57 5: SW: W0F10
2017.06.08 10:43:57 5: SW: W10b0
2017.06.08 10:43:57 5: SW: W1171
2017.06.08 10:43:57 5: SW: X21

dann sieht list Cube so aus:
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   Cube_MSGCNT 26
   Cube_TIME  2017-06-08 10:42:21
   DEF        /dev/ttyACM0@9600 1234
   DeviceName /dev/ttyACM0@9600
   FD         18
   FHTID      1234
   NAME       Cube
   NR         107
   NR_CMD_LAST_H 6
   PARTIAL
   RAWMSG     OFF
   RSSI       -79.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   initString X21
   Matchlist:
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04....(1|5|9).a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-07 23:44:59   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-06-08 08:03:13   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2017-06-08 10:04:17   credit10ms      364
     2017-06-07 19:31:02   fhtbuf          AE
     2017-06-07 23:39:13   raw             25  768
     2017-06-08 10:42:21   state           Initialized
     2017-06-07 23:29:39   uptime          0 00:04:50
     2017-06-07 23:29:43   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1496909031.64916
     1496909038.17139
     1496909039.68619
     1496909045.70287
     1496909051.71928
     1496909057.73275
Attributes:
   icon       cul_cul
   rfmode     SlowRF
   room       System
   verbose    5

ein get Cube ccconf bringt jetzt folgendes:
Cube ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
(wird scheinbar nicht automatisch ohne extra get upgedated)

will ich jetzt ein set Cube raw X25 (um auch unbekannte Sequenzen zu empfangen, steht im Log:

2017.06.08 10:47:51 3: set Cube raw X25
2017.06.08 10:47:51 5: SW: X25

Bis auf die Fehlermeldung beim Setzen des rfmode würde es ja ok ausschauen. Wenn ich die Doku richtig verstanden habe, kann man SlowRF auf mit set Cube raw fx aktivieren, oder?

2017.06.08 10:50:59 3: set Cube raw fx
2017.06.08 10:50:59 5: SW: fx

Trotz allem empfange ich so aber genau nix...

Und wenn ich jetzt wieder zurück zum eigentlichen MAX-Mode will, hätte ich folgendes gemacht:

Attribut rfmode auf MAX

2017.06.08 10:52:16 5: SW: Ax
2017.06.08 10:52:16 5: SW: X21
2017.06.08 10:52:16 5: SW: Zr
2017.06.08 10:52:16 2: Switched Cube rfmode to MAX

dann ein set Cube raw e:

2017.06.08 10:52:46 3: set Cube raw e
2017.06.08 10:52:46 5: SW: e
2017.06.08 10:52:47 1: /dev/ttyACM0 disconnected, waiting to reappear (Cube)
2017.06.08 10:52:51 3: Setting Cube serial parameters to 9600,8,N,1
2017.06.08 10:52:51 5: SW: V
2017.06.08 10:52:51 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)

2017.06.08 10:52:51 5: SW: ?
2017.06.08 10:52:51 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z

2017.06.08 10:52:52 3: Cube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2017.06.08 10:52:52 5: SW: X21
2017.06.08 10:52:52 5: SW: Zr
2017.06.08 10:52:52 5: SW: T01
2017.06.08 10:52:52 5: CUL/RAW (ReadAnswer): 1234

2017.06.08 10:52:52 5: GOT CUL fhtid: 1234
2017.06.08 10:52:52 1: /dev/ttyACM0 reappeared (Cube)

Ein get Cube ccconf bringt dann wieder die korrekten Werte:Cube ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
list Cube schaut dann so aus:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   Cube_MSGCNT 27
   Cube_TIME  2017-06-08 10:47:34
   DEF        /dev/ttyACM0@9600 1234
   DeviceName /dev/ttyACM0@9600
   FD         18
   FHTID      1234
   NAME       Cube
   NR         107
   PARTIAL
   RAWMSG     ? (25 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
   RSSI       -79.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
   initString X21
Zr
   Matchlist:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   Readings:
     2017-06-08 10:53:14   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-06-08 10:52:51   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
     2017-06-08 10:04:17   credit10ms      364
     2017-06-07 19:31:02   fhtbuf          AE
     2017-06-07 23:39:13   raw             25  768
     2017-06-08 10:52:52   state           Initialized
     2017-06-07 23:29:39   uptime          0 00:04:50
     2017-06-07 23:29:43   version         V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Attributes:
   icon       cul_cul
   rfmode     MAX
   room       System
   verbose    5


Dann dauert es aber einige Minuten (wenn man nicht gerade den Cube stromlos macht) bis der wieder normal seine Arbeit verrichtet...

Also die Frage wäre jetzt, ob der Fehler vorm Bildschirm sitzt oder im Cube oder irgendwo dazwischen ;)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 Juni 2017, 11:47:50
Mit set Cube raw fx wird der fastrf Modus deaktiviert. Der war aber bei dir nie an. Aber trotzdem wird dabei der Empfang komplett deaktiviert.

Grundsätzlich musst du, wenn du zwischen MAX und SlowRF Modus mit dem Attribut rfmode wechselst, keine raw Kommandos ausführen. Das macht FHEM automatisch und aktiviert den entsprechenden Modus selbstständig.

Ich denke, der Fehler sitzt vor dem Bildschirm.
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 08 Juni 2017, 14:22:36
Na, das mit dem raw-Kommando für den SlowRF-Modus war ja nur zusätzlich gemeint - wie du oben sehen hättest können, habe ich es davor ja so wie gedacht per fhem - Attribut gesetzt, das bringt mir aber diese eigenartige Fehlermeldung - wenn ich also diesbezüglich einen Fehler gemacht habe, dann bitte um Info, wo...

Das eigentliche Problem ist aber, dass ich mit der alten FW (habe nochmal nachgeschaut, war 1.21.00) auf SlowRF und Frequenz 433.92 umschalten konnte, ohne eine Fehlermeldung zu erhalten und dann auch noch etwas empfangen habe. Leider waren die empfangenen Daten aber nicht richtig interpretierbar, weshalb mal als ersten Versuch die aktuellste FW helfen sollte.

Jetzt kann ich aber gar nichts mehr empfangen, wegen der Fehlermeldung beim Aktivieren des SlowRF stelle ich mir aber die Frage, ob er überhaupt korrekt umschaltet...

Bisher habe ich die Erfahrung gemacht, dass das Flashen selbst entweder geht oder nicht, aber das es nur so halb geht oder so hatte ich noch nie und da hier auch kein Fehler gemeldet wurde, gehe ich mal davon aus, dass das passt.

Bin mir auch nicht bewusst hier irgendwas falsch zu bedienen oder so - aber ich kann natürlich nicht ausschließen, dass ich sozusagen "den Wald vor lauten Bäumen nicht mehr sehe", weshalb ich für Hilfe dankbar wäre...
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 08 Juni 2017, 14:39:40
Ok. Ich denke ich weiß jetzt, woher dieses CUL/RAW OFF, usw. kommt:

Das raw-Kommando brx, welches beim Umstalten auf slowRF gesetzt wird, gibt auch was zurück:
b<cmd><data>
Wireless M-Bus:
r<mode>
start receiving messages. <mode> bust be either s or t for desired mode
s<data>
send data (tbd)
returns always the actual receiving mode

Habe daher mal folgendes versucht "get Cube raw brx" und erhalte dann:
 2017.06.08 14:31:18 5: SW: brx
2017.06.08 14:31:18 5: CUL/RAW (ReadAnswer): OFF

Ein "get Cube raw C35" liefert:

2017.06.08 14:31:12 5: SW: C35
2017.06.08 14:31:12 5: CUL/RAW (ReadAnswer): C35 = 0D / 13

Somit sollte ja der Empfangsmodus aktiv sein, oder?

Um das ganze abzukürzen:
-) wie kann ich feststellen, ob der Cube auf "Empfangsmodus" ist oder nicht?
-) wie sind die genauen Schritte um von 868/MAX auf 433/SlowRF umzuschalten (um auch zu empfangen, am besten alles - nicht nur bekanntes)?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 Juni 2017, 15:15:59
Das raw Kommando brx deaktiviert den MBus mode und das OFF ist die Rückantwort, dass MBus deaktiviert ist. Wenn danach X21 gesendet wird, wird der SlowRF Mode aktiviert. Die Fehlermeldung im LOG kannst du ignorieren.


-) wie kann ich feststellen, ob der Cube auf "Empfangsmodus" ist oder nicht?
Mit raw X. Wenn X21 zurück kommt ist er im Empfangsmodus. Alternativ an der Debugschnittstelle am Cube mitloggen.

-) wie sind die genauen Schritte um von 868/MAX auf 433/SlowRF umzuschalten (um auch zu empfangen, am besten alles - nicht nur bekanntes)?
Einfach das attribut entsprechend umstellen. Und einmalig im SlowRF mode die Frequenz richtig setzen. Im MAX mode wird diese Frequenzeinstellung ignorierert und automatisch die richtige Frequenz eingestellt.
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 08 Juni 2017, 15:44:13
Ok. Danke für die Infos, somit weiß ich jetzt, dass ich nicht daneben war. Stimmt es auch, dass man mit X25 den Empfang so umstellen kann, dass auch unbekannte Signale geloggt werden?

Jetzt wäre das ganze drumherum geklärt, aber mein Problem ist ja, dass ich vor dem Update der FW von einem bestimmten Gerät auf Frequenz 433 was empfangen habe und dazwischen auch immer wieder andere Signale (wohl "Grundrauschen" bzw. Nachbarn?), jetzt mit der neuen FW aber genau nichts in den Logs auftaucht...

Mit der alten FW hatte ich es sogar so weit gehabt, dass er mir ein Gerät automatisch angelegt hatte, nur waren da die Codes (noch?) nicht korrekt...

Woran könnte das liegen? Ist es eine Einstellungssache oder kam irgendein "Feature" dazu, wodurch der Cube jetzt anders reagiert?

Als Gegentest könnte ich auch wieder die alte FW draufspielen, oder gibt es irgendeine, die zu bevorzugen wäre?

Mir ist auch aufgefallen, dass es schon mal vorkommt, dass sich der Cube kurz "verabschiedet" (also im Log kommen disconnected / reappeared Meldungen) wenn man zB get Cube raw C35 oder get Cube raw X absetzt, ab halt nur manchmal - das wäre mir mit der alten Version so nicht aufgefallen...

Danke
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 08 Juni 2017, 18:16:02
Lag wohl doch an der Firmware. Mit der angefügen Version funktioniert 433MHz wieder.
Titel: Antw:culfw@ARM
Beitrag von: Andy77H am 08 Juni 2017, 21:46:29
Wahnsinn, Super, Danke!  ;D ;D ;D

Neue Firmware geflashed, auf SlowRF und Frequenz 433.92 umgeschalten, ein paar mal auf die Fernbedienung
-> Output im Log!
-> neues IT-Device
-> kurz die on/off - Kommandos angepasst und die Motorleinwand fährt schon rauf und runter :D

Also kann nur nochmal sagen: DANKE!  8)
Titel: Antw:culfw@ARM
Beitrag von: Thomas Vandahl am 27 Juni 2017, 21:17:29
Lag wohl doch an der Firmware. Mit der angefügen Version funktioniert 433MHz wieder.

Hallo ich bin neu hier.
Habe einen Cube geflasht, weil meine FHZ das Empfangen eingestellt hat. Zunächst mit der Build 208/209-Version, da gingen FS20-Schalter, aber die HMS-Sensoren nicht (kein Empfang!). Jetzt habe ich die FW aus dem Anhang genommen, da ist es umgekehrt. Der aktuellste Build von gestern (232) ist irgendwie nur 28k groß, da fehlt wohl einiges. Welche Version ist für HMS und FS20 zu empfehlen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Juni 2017, 22:00:06
Der aktuelle Build ist jetzt wieder vollständig.
Bezüglich HMS und FS20 sollte es eigentlich keinen Unterschied in den Versionen geben.
Titel: Antw:culfw@ARM
Beitrag von: Thomas Vandahl am 02 Juli 2017, 10:33:59
Danke für die Aktualisierung. Ich probiers mal aus. Was ist der Unterschied zwischen CUBE_BL.bin und CUBEx4_BL.bin?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 Juli 2017, 14:03:15
Bei CUBEx4_BL ist Hardware Autodetection aktiviert und man könnte zusätzliche Transceiver oder 1-Wire nachrüsten.
Titel: Antw:culfw@ARM
Beitrag von: HansDampfHH am 08 Juli 2017, 10:23:03
Edit:
Ich war selber schuld. Die Angabe des IoDev passte nicht mehr, weil ich es später umbenannt hatte.
Nachdem ich das korrigiert habe, konnte ich alle Thermostate pairen // DAU


Ich habe meinen Max Cube erfolgreich auf culfw geflashed.
War meinen vergesslichen Maxcube leid.

Ich bekomme allerdings ein Thermostat nicht gepaired. Ich habe das Thermostat resetet (3 Tasten) und wollte es über pairMode anlernen.
Da zählt aber nur der Countdown runter, mehr nicht. Also habe ich das Device aus FHEM gelöscht und erneut versuch, leider ohne Erfolg.
Hat jemand einen Hinweis für mich, was ich noch machen kann?

Seither habe ich auch folgende Logeinträge:
2017.07.08 10:15:37 1: readingsUpdate(,weekprofile-4-Wed-temp,17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C) missed to call readingsBeginUpdate first.
2017.07.08 10:15:37 1: stacktrace:
2017.07.08 10:15:37 1:     main::readingsBulkUpdate            called by ./FHEM/10_MAX.pm (236)
2017.07.08 10:15:37 1:     main::MAX_ParseWeekProfile          called by ./FHEM/10_MAX.pm (794)
2017.07.08 10:15:37 1:     main::MAX_Parse                     called by fhem.pl (3608)
2017.07.08 10:15:37 1:     main::Dispatch                      called by ./FHEM/14_CUL_MAX.pm (374)
2017.07.08 10:15:37 1:     main::CUL_MAX_Parse                 called by fhem.pl (3608)
2017.07.08 10:15:37 1:     main::Dispatch                      called by ./FHEM/00_CUL.pm (947)
2017.07.08 10:15:37 1:     main::CUL_Parse                     called by ./FHEM/00_CUL.pm (831)
2017.07.08 10:15:37 1:     main::CUL_Read                      called by fhem.pl (3412)
2017.07.08 10:15:37 1:     main::CallFn                        called by fhem.pl (686)

Hier mal ein List vom Max Cube:

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 0000
   DeviceName /dev/ttyACM0@9600
   FD         20
   FHTID      0000
   NAME       CUL0
   NR         890
   NR_CMD_LAST_H 2
   PARTIAL
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za123456
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-07-10 11:30:01   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-07-10 20:26:14   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2017-07-10 20:25:55   credit10ms      8
     2017-07-10 20:26:14   state           Initialized
     2017-07-10 20:00:44   uptime          0 01:41:25
     2017-07-10 20:00:37   version         V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1499711174.39125
     1499711174.69191
Attributes:
   icon       cul_wlan
   rfmode     MAX
   room       Steuerung

...und von einem anderen Thermostat, welches funktioniert:
Internals:
   CULMax_MSGCNT 5
   CULMax_TIME 2017-07-07 09:01:56
   DEF        HeatingThermostat 14a679
   IODev      CULMax
   LASTInputDev CULMax
   MSGCNT     5
   NAME       Max.HZ.6
   NR         535
   RSSI       -73.5
   STATE      17.0 °C
   TYPE       MAX
   addr       14a679
   dstsetting 1
   mode       0
   rferror    0
   serial     MEQ1812774
   type       HeatingThermostat
   Readings:
     2017-07-07 09:01:56   RSSI            -73.5
     2017-07-06 21:44:54   TimeInformationHour 2
     2017-07-07 09:00:23   battery         ok
     2017-07-07 09:01:56   boostDuration   25
     2017-07-07 09:01:56   boostValveposition 80
     2017-07-07 09:01:56   comfortTemperature 21.0
     2017-07-07 09:01:56   decalcification Sat 12:00
     2017-07-07 09:00:23   desiredTemperature 17.0
     2017-07-07 09:01:56   ecoTemperature  17.0
     2017-07-07 09:01:56   firmware        1.0
     2017-07-07 09:01:56   groupid         0
     2017-07-07 09:01:56   maxValveSetting 100
     2017-07-07 09:01:56   maximumTemperature on
     2017-07-07 09:01:56   measurementOffset 0.0
     2017-07-07 09:01:56   minimumTemperature off
     2017-07-07 09:00:23   mode            auto
     2017-07-08 04:45:05   msgcnt          8
     2017-07-07 09:01:56   state           17.0 °C
     2017-07-07 09:00:23   temperature     22.5
     2017-07-07 09:01:56   testresult      161
     2017-07-07 09:01:56   valveOffset     0
     2017-07-07 09:00:23   valveposition   0
     2017-07-07 09:01:56   weekprofile-0-Sat-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-0-Sat-time 00:00-06:00  /  06:00-22:00  /  22:00-00:00
     2017-07-07 09:01:56   weekprofile-1-Sun-temp 17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-1-Sun-time 00:00-06:00  /  06:00-22:00  /  22:00-00:00
     2017-07-07 09:01:56   weekprofile-2-Mon-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-2-Mon-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2017-07-07 09:01:56   weekprofile-3-Tue-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-3-Tue-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2017-07-07 09:01:56   weekprofile-4-Wed-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-4-Wed-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2017-07-07 09:01:56   weekprofile-5-Thu-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-5-Thu-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2017-07-07 09:01:56   weekprofile-6-Fri-temp 17.0 °C  /  21.0 °C  /  17.0 °C  /  21.0 °C  /  17.0 °C
     2017-07-07 09:01:56   weekprofile-6-Fri-time 00:00-06:00  /  06:00-09:00  /  09:00-17:00  /  17:00-23:00  /  23:00-00:00
     2017-07-07 09:01:56   windowOpenDuration 15
     2017-07-07 09:01:56   windowOpenTemperature 12.0
   Internals:
     interfaces thermostat;battery;temperature
Attributes:
   IODev      CULMax
   alias      Küche
   icon       hc_wht_regler
   room       Küche
Titel: Antw:culfw@ARM
Beitrag von: eckonator am 17 Juli 2017, 23:29:02
Hi, ich habe mir nun eben einen Max Cube bei Kleinanzeigen geschossen und will den zu CUL flashen. Dazu zwei Fragen:

Wo finde ich die aktuellste Version?
Funktioniert der Cube danach auch via LAN?

Linux Kenntnisse sind vorhanden. Aber mit CUL und die Einbindung dessen in FHEM bisher keine Erfahrung.
Kann mir jemand für Daus erklären, wie ich am besten zum Flashen vorgehe?

Danke euch!
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 18 Juli 2017, 13:06:18
https://forum.fhem.de/index.php/topic,38404.0.html

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: eckonator am 19 Juli 2017, 21:20:18
Ich scheine was das Flashing angeht, nicht die hellste Leuchte zu sein  :'(

Ich habe a-culfw_1.25.01_build_258.zip von mediafire runtergeladen und entpackt. Check
Im Verzeichnis "CUBe" habe ich die Datei "CUBE_BL.bin" gefunden. Check
Die SAM-BA Software habe ich runter geladen und installiert. Check

Wo befindet sich die Datei "bootloader_CUBE.bin"? Im ZIP scheint diese zu fehlen.

Sorry, sollte ich mich doof anstellen. Ich denke nur, dass ich den MAX! Cube nach einem falschen Flash-Versuch in die Tonne kloppen kann?
Das wäre natürlich schade, daher würde ich mich über ein wenig Hilfe für Anfänger freuen.

Danke euch vorab.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 19 Juli 2017, 21:40:51
Lade die Version a-culfw_1.20.08_build_220_master.zip herunter. Da ist der Bootloader noch drin.
Titel: Antw:culfw@ARM
Beitrag von: eckonator am 19 Juli 2017, 21:53:01
Lade die Version a-culfw_1.20.08_build_220_master.zip herunter. Da ist der Bootloader noch drin.

Hi Telekatz,
danke für den Tipp, die "CUBE_BL.bin" nehme ich aber weiterhin von der aktuellsten Version, oder dann auch die Version von der "a-culfw_1.20.08_build_220_master.zip"?

Der Cube kommt morgen. Sehe ich es richtig, dass ich dann unten die 4 Gummifüße weg machen muss und sich darunter wohl 4 Schrauben befinden?
Diese löse ich, um den J1-Conntecor zu überbrücken, um so den Flash-Speicher für die neue Firmware freizugeben?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 19 Juli 2017, 22:46:33
Die CUBE_BL.bin nimmst du aus der aktuellen Version.

Das Gehäuse ist nicht verschraubt. Der obere Teil des Gehäuses ist nur draufgesteckt und rastet mit 4 Rastnasen ein.
Titel: Antw:culfw@ARM
Beitrag von: eckonator am 22 Juli 2017, 15:01:09
Der Cube ist geflasht  ;D Wie muss ich ihn nun in FHEM definieren? Ich möchte ihn via Netzwerk/IP einbinden.

Ok, ich bin ein Stück weiter - so scheint der Cube bei mir in FHEM erstmal ein Lebenszeichen zu zeigen:

define cul868 CUL 192.168.178.64:2323 0000
attr cul868 model CUL

Via get cul868 versin spuckt fhem folgendes aus:
cul868 version => V 1.25.01 a-culfw Build: 257 (2017-07-14_17-38-58) CUBe (F-Band: 868MHz)

Die nächste Baustelle ist nun für mich, wie bekomme ich ein MAX! EcoTaster mit dem CUL ans laufen? Freue mich über Hilfe.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 22 Juli 2017, 19:49:16
Die nächste Baustelle ist nun für mich, wie bekomme ich ein MAX! EcoTaster mit dem CUL ans laufen? Freue mich über Hilfe.
Die Frage ist hier OT , dafür gibt es das MAX Unterforum und im Wiki steht alles nötige -> https://wiki.fhem.de/wiki/MAX
Titel: Antw:culfw@ARM
Beitrag von: RalfPit am 03 September 2017, 19:25:16
# Telekatz, vielen Dank für die ausführliche Hilfe.

Jetzt habe ich auch meinen zeiten Cube problemlos geflasht.
Dieser bekommt jedoch die gleiche Serial-ID [usb-03eb_AT91USBSerial1-if00].

Gibt es eine Möglichkeit in den Voreinstellungen diese zu ändern ?

DANKE Ralf
Titel: Antw:culfw@ARM
Beitrag von: hollyghost am 03 September 2017, 19:55:08
Eine kurze Frage an die Spezialisten hier: Wo finde ich nen Schaltplan bzw. eine kurze Beschreibung, wie die zusätzlichen Transceiver beim MAXCube (x4) anzuschließen sind?
Danke & Gruß
Holger
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 03 September 2017, 20:31:26
Dieser bekommt jedoch die gleiche Serial-ID [usb-03eb_AT91USBSerial1-if00].

Gibt es eine Möglichkeit in den Voreinstellungen diese zu ändern ?

Dazu musst Du die a-culfw selbst kompilieren und für jeden Cube in default.h den Wert in der Zeile #define USB_DESCRIPTOR_SN       '1' ändern, z.B. auf 0. Damit heißen die Devices dann ...USBSerial0... usw.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 September 2017, 21:52:05
Eine kurze Frage an die Spezialisten hier: Wo finde ich nen Schaltplan bzw. eine kurze Beschreibung, wie die zusätzlichen Transceiver beim MAXCube (x4) anzuschließen sind?
Danke & Gruß
Holger
Da bin ich bis jetzt noch nicht dazu gekommen, das zu beschreiben. Die entsprechenden Signale muss man an diversen Punkten auf der Platine abgreifen. Die Belegung kann man aus der board.h entnehmen.
Titel: Antw:culfw@ARM
Beitrag von: hollyghost am 03 September 2017, 22:09:36
Da bin ich bis jetzt noch nicht dazu gekommen, das zu beschreiben. Die entsprechenden Signale muss man an diversen Punkten auf der Platine abgreifen. Die Belegung kann man aus der board.h entnehmen.
Super - das hilft mir schon mal weiter!
Danke


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: RalfPit am 04 September 2017, 16:36:54
Dazu musst Du die a-culfw selbst kompilieren und für jeden Cube in default.h den Wert in der Zeile #define USB_DESCRIPTOR_SN       '1' ändern, z.B. auf 0. Damit heißen die Devices dann ...USBSerial0... usw.

@mahowi
Danke für die schnelle Lösung. Selbst kompilieren ist jedoch für einen alten Mann wie mich ohne eine einfache Anleitung wie z.B. von Telekatz zu schwierig. Außerdem erkennt mein PI von meinem 8-Port USB-Hub nur 4.
Habe jetzt entsprechend der Vorgabe von Telekatz beide Cubes über LAN angebunden ... geht auch.
Nochmals Danke Ralf
Titel: Antw:culfw@ARM
Beitrag von: Holzlenkrad am 06 September 2017, 12:09:53
Hallo, ich bin neu hier im Forum, weil ich eine Frage zur Verwendung des Max Cube als CUL bzw. CUNO haben :)

Ich hatte Gelegenheit diesen günstig in einem Bundle bei Medion zu kaufen, weil diese wohl einen Ausverkauf gemacht haben.

Dachte zwar, dass ich mit 20€ ein Schnäppchen für den Einstieg mit FHEM in Homematic gemacht habe, aber dann habe ich gestern den HM-MOD-RPI-PCB entdeckt... Naja andere Geschichte.

Also, meine FHEM Installation läuft schon auf einem Raspberry PI 1. Also die älteste Generation, aber die mit viel RAM.
Nun frage ich mich, wie die beste Verwendung des Max Cube ist?

Man kann ihn ja wohl über LAN als auch direkt per USB an den Raspberry Pi anschließen.
Bei LAN soll es ja zu Timing Problemen mit dem Funk kommen, ließt man im Wiki mehrfach.
Auf der anderen Seite soll der USB Stack des Raspberry PIs auch nicht optimal sein, sodass es hier ebenfalls zu Timing Problemen kommen kann.

Welche Variante würdet ihr denn empfehlen, und wieso?
Schon einmal vielen Dank!


TL;DR: Max Cube per LAN als CUN oder USB als CUL mit einem alten Raspberry Pi verbinden?
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 06 September 2017, 13:07:17
Welche Variante würdet ihr denn empfehlen, und wieso?
naja mit dem empfehlen ist das so eine Sache da bei jedem die baulichen Gegebenheit anders sind. Ich bin gestartet mit einem HM-MOD-RPI-PCB im 1.OG an meinem FHEM Server. Das nächste war ein Cube via LAN im Keller, damit hatte ich volle Abdeckung im Haus. Als nächstes kam ein zweiter LAN Cube in die Garage und damit waren dann sowohl Hof als auch Garten erschlagen. Ich kann nichts Negatives zu den Cubes sagen, im Gegenteil ich bin immer wieder überrascht über die guten RSSI Werte einzelner HM Geräte. 
Titel: Antw:culfw@ARM
Beitrag von: E-J-D am 07 September 2017, 21:23:53
Hallo Leute,

das ist echt der Hammer. Da will ich die über den Sommer für schmales Geld geschossenen Max! Thermostate am Cube in Betrieb nehmen und worüber stolpere ich?!? Diesen Hammer Beitrag :-). Vielen Dank für eure Arbeit. Habe meinen Cube (5 Jahre alt) mit Win10 geflasht und per Telnet im eine fixe IP verpasst und in FHEM angelegt. Soweit hat alles 100% funktioniert. Die nächsten Tage sind dann die 10 Thermostate dran.

Viele Grüße
Titel: Antw:culfw@ARM
Beitrag von: nanocosmos am 09 September 2017, 16:45:49
Vielen Dank für die Firmware, um meinen Max Cube umzuflashen!
Bin gerade dabei die Software Seite fertig zu machen.
Leider spielt die Atmel Homepage bei der Beschaffung von SAM-BA nicht so mit. Ich bekomme einfach keinen Link zum Download zugeschickt.
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 12 September 2017, 19:02:58
Da bin ich bis jetzt noch nicht dazu gekommen, das zu beschreiben. Die entsprechenden Signale muss man an diversen Punkten auf der Platine abgreifen. Die Belegung kann man aus der board.h entnehmen.

Das Bild zeigt neben den SPI Anschlüssen noch:

In der board.h sind aber noch die OUT-Pins/IRQ-Pins angegeben:

Ich wäre für eine Hilfestellung dankbar!

Alex

PS: Grandiose Arbeit!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 September 2017, 21:08:19
Die OUT Pins waren dann der Punkt, an dem der Nachbau kompliziert wurde. Die muss man nämlich direkt am µC abgreifen. Deshalb habe ich dann erstmal mit dem MapleCUN ein einfacher nachbaubares Interface entworfen, anstatt die Cube Erweiterung weiter zu verfolgen. 

Benötigt werden die OUT Pins aber auch nur für SlowRF.


Wäre für jeden Tipp dankbar.
Stell die Frage im richtigen Unterforum (MAX und SlowRF). Das hat mit dem Thema hier direkt nichts zu tun.
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 13 September 2017, 10:57:29
Die OUT Pins waren dann der Punkt, an dem der Nachbau kompliziert wurde. Die muss man nämlich direkt am µC abgreifen. Deshalb habe ich dann erstmal mit dem MapleCUN ein einfacher nachbaubares Interface entworfen, anstatt die Cube Erweiterung weiter zu verfolgen. 

Benötigt werden die OUT Pins aber auch nur für SlowRF.

Danke für die schnelle Antwort!

Wenn man nur zwei weitere Sensoren verwenden wollte, könnte man dann die PA9, PB20, PB28 weglassen und stattdessen die board.h auf die anderen freien Pins anpassen? Oder sind PA9, PB20, PB28 spezielle Interrupt Leitungen?
Titel: Antw:culfw@ARM
Beitrag von: pc1246 am 13 September 2017, 12:04:39
Moin
Ich wollte mich hier noch mal ganz herzlich bedanken. Gestern meinen Cube erhalten, umgeflasht und alles chick.
Zwei Schwierigkeiten gab es zu umschiffen, da zum einen die Bootloader Datei nicht zu finden war, und zum anderen der Port zur Definition des CUL(N) nicht klar war. Ich habe mich dann mutig durch den thread gewuehlt, und die Infos gefunden. Bootloader ist in aculfw 1.20 V22068 oder so? Und der Port ist 2323. Eventuell koennte Telekatz das im ersten Post noch ergaenzen.
Ansonsten aber top. Danke nochmals
Gruss Christoph

P.S.: Man koennte ja fast einen Wiki-Beitrag erstellen, da muss ich mal sehen, wie es mit meiner Zeit aussieht.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 September 2017, 18:24:56
Danke für die schnelle Antwort!

Wenn man nur zwei weitere Sensoren verwenden wollte, könnte man dann die PA9, PB20, PB28 weglassen und stattdessen die board.h auf die anderen freien Pins anpassen? Oder sind PA9, PB20, PB28 spezielle Interrupt Leitungen?
Die OUT Pins brauchen keinen Interrupt. Deshalb ist es egal, welchen Pin man dafür nimmt.
Titel: Antw:culfw@ARM
Beitrag von: nanocosmos am 14 September 2017, 17:15:35
Auf der Homepage von Atmel finde ich zwei Software Versionen: 2.16 als Installer ubd 3.1.4 als Zip Archiv.
Beide Versionen funktionieren bei mir nicht.
Beim 2.16 Installer öffnet sich nur ein Mini Fenster und man kann nichts auswählen.
Die 3.1.4 Software scheint ein Kommandozeilen-Tool zu sein. Es liest sich in der Anleitung aber nach einem normalen Windows Programm.
Vielleicht könnte mir jemand bitte weiterhelfen.

Grüße Daniel
Titel: Antw:culfw@ARM
Beitrag von: pc1246 am 14 September 2017, 23:06:25
Moin
Ich habe auch beides runtergeladen. Die 3er Version ist irgendwie seltsam. Mit der 2er lief es problemlos. Installiert, als Admin gestartet, und nach Anleitung vorgegangen!
Gruss Christoph
Titel: Antw:culfw@ARM
Beitrag von: nanocosmos am 15 September 2017, 12:11:56
Danke!
Habe es jetzt mit einem anderen Rechner probiert und da läuft es.
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 15 September 2017, 16:49:08
Da bin ich bis jetzt noch nicht dazu gekommen, das zu beschreiben. Die entsprechenden Signale muss man an diversen Punkten auf der Platine abgreifen. Die Belegung kann man aus der board.h entnehmen.

Sorry, ich muss nochmal "dumm" fragen...
Die SPI Kontakte auf der Platinenunterseite des CUBe sollten doch die des CC1101 Moduls sein, oder?
Das würde bedeuten (auf dem Bild von oben gezählt):

Die board.h habe ich so umgebaut, dass ich die komplizierten PA9,PB20,PB28 auf das 4. Interface gelegt habe und stattdessen mit PB25 und PB24 als Out-Leitung für Port1 und Port2 eingetragen.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 15 September 2017, 18:04:24
Sorry, ich muss nochmal "dumm" fragen...
Die SPI Kontakte auf der Platinenunterseite des CUBe sollten doch die des CC1101 Moduls sein, oder?
Das würde bedeuten (auf dem Bild von oben gezählt):
  • VCC
  • GND
  • MOSI
  • SCLK
  • MISO
  • GDO2
  • GDO0
  • CS
Das ist die Belegung der China Briefmarken Module.

Die ELV Module haben eine andere Belegung:
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 15 September 2017, 19:31:03
unter https://wiki.fhem.de/wiki/HomeMatic_Asksin_Library gibt es Bilder & Zeichnungen der e3Q CC1101 Module
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 16 September 2017, 14:50:32
Kurze Erfolgsmeldung!

Sorry für die Konfusion... die Bilder, die Telekatz in Antwort #823 zur Verfügung gestellt hat, sind absolut korrekt  ;)

Offensichtlich bezieht sich die Einschränkung im Wiki (https://wiki.fhem.de/wiki/MapleCUN#Firmware_.2F_Flashen) bzgl. SlowRF nur an Port 1 und 2 auf die Verdrahtung des "OUT" Pins. Weiter oben unter "Bestückung der Module" ist es besser erklärt.

Dankeschön an die Entwickler!

OT: was macht ihr mit so vielen Transceivern? (Ich benutze MAX und Intertechno). Welche Hardware kann man denn noch anschließen? Ich habe etwas von 1-Wire gelesen!? Im CUBE Gehäuse ist ja noch viel Platz  :D
Titel: Antw:culfw@ARM
Beitrag von: shorty1409 am 16 September 2017, 17:36:15
Hallo Telekatz,

es gibt leider einen kleinen Fehler mit den culfw Versionen > a-culfw_1.24.02_build_209 die auf einen Max!Cube geflasht werden.
Es wirkt sich so aus, dass FS20 Steckdosen nicht mehr angelernt werden können.

Szenario:
Ich habe einen Max!Cube wie im 1. Beitrag beschrieben mit bootloader (aus dem Package "a-culfw_1.20.08_build_220_master") und der aktuellen culfw "a-culfw_1.26.00_build_268" geflasht und in FHEM wie folgt eingebunden:

define CULSlowRF CUL 192.168.XXX.XXX:2323 0000
attr CULSlowRF model CUN
attr CULSlowRF rfmode SlowRF
attr CULSlowRF room Gateways


anschließend einen FS20 Dimmer angelegt:

define Terra.Compact60 FS20 12121212 1111
attr Terra.Compact60 IODev CULSlowRF
attr Terra.Compact60 model fs20di
attr Terra.Compact60 room Terrarium

und dann den Dimmer in den Anlernmodus versetzt. Über FHEM folgendes ausgeführt:

set Terra.Compact60 off
set Terra.Compact60 on

Leider hat sich der Dimmer nicht geregt.

Nach einigen Tests und dem Austausch in diesem Artikel (https://forum.fhem.de/index.php/topic,76582.0.html (https://forum.fhem.de/index.php/topic,76582.0.html)) wurden verschiedene culfw ausprobiert.

Test's:

Somit liegt es nahe das der Fehler in den culfw > a-culfw_1.24.02_build_209 auftritt.

Ich möchte an der Stelle trotzdem vielen Dank für die gute Arbeit und den tollen Support sagen! ;)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 September 2017, 22:46:36
Ist in der nächsten Version (1.26.01) korrigiert.
Titel: Antw:culfw@ARM
Beitrag von: Tedious am 21 September 2017, 13:15:54
Auch von mir ein Hinweis - wollte gestern die 1.26.01 auf den MapleCUN flashen. Anschließend waren alle 4 (866x3 und 433) tot und nicht mehr ansprechbar. Mehrfaches ne flashen brachte keine Änderung. Ein flashen der 1.26.00 funktionierte hingegen problemlos. Da steckt irgendwo ein Fehlerchen drin.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 September 2017, 20:10:40
Habe gerade die 1.26.01 Versionen aus dem Archiv ausprobiert. Es haben beide funktioniert.

Blinkt der MapleCUN? Über LAN oder USB angeschlossen?
Titel: culfw@ARM
Beitrag von: Tedious am 21 September 2017, 21:11:47
Per USB, er blinkte auch. Wie gesagt, die andere Version ist anstandslos durchgelaufen.


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 September 2017, 22:03:35
Was liefert "get <namedesCULs> version" zurück?
Titel: Antw:culfw@ARM
Beitrag von: Tedious am 21 September 2017, 22:29:45
Hi,

   
V 1.26.00 a-culfw Build: 267 (2017-08-25_08-49-09) MapleCUNx4_0F (F-Band: 868MHz)

Also wie geflasht


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 September 2017, 22:35:50
Und was kommt bei der 1.26.01?
Titel: Antw:culfw@ARM
Beitrag von: Tedious am 21 September 2017, 22:37:08
Nichts.. da lässt er sich nicht ansprechen - bzw keiner. Lsusb liefert aber auch nur Müll, insofern zu erwarten.


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 September 2017, 22:42:10
Welche der 1.26.01 Dateien hast du verwedet?
Titel: Antw:culfw@ARM
Beitrag von: Tedious am 21 September 2017, 22:44:39
Ein Script von Ranseyer

#! /bin/sh
while (true); do

sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
#sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
#sudo dfu-util -d 1eaf:0003 -a 1 -D ~/src/IRMP_STM32/bootloader/map.bin
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 September 2017, 22:51:22
Teste mal die angefügte Version.
Titel: Antw:culfw@ARM
Beitrag von: Tedious am 22 September 2017, 09:09:26
Hi,

besten Dank, teste ich heute Abend mal aus.

Grüße

Sascha
Titel: Antw:culfw@ARM
Beitrag von: persching am 30 September 2017, 16:17:50
Ich hab heute einen Cube bekommen und würde ihn gerne umflashen, aber es scheitert an sam-ba. Ich habe es als guest probiert, ging nicht weil ich keinen downloadlink per mail bekomme. Ich hab mich dann registriert, aber ich bleibe dort nicht eingeloggt und somit kann ich auch nichts runterladen. Gibt es da einen Trick??
Titel: Antw:culfw@ARM
Beitrag von: shorty1409 am 30 September 2017, 16:22:22
Versuch es mal über diesen Link: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=Atmel%20SAM-BA%20In-system%20Programmer (http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=Atmel%20SAM-BA%20In-system%20Programmer)
Titel: Antw:culfw@ARM
Beitrag von: persching am 30 September 2017, 16:35:31
Der Link funktioniert! Super... warum nicht gleich so! Danke!!!
Titel: Antw:culfw@ARM
Beitrag von: pantau am 30 September 2017, 21:11:25
Laut dem Atmel Datenblatt vom AT91SAM7x256 ist PA9=Pin 14, PB20=Pin 65 und PB28=Pin 10.
Pin 10 und Pin 65 kann ich in dem angehängten Bild aus Beitrag #831 erkennen. (Vorausgesetzt Pin 1 ist unten rechts im Bild).
Aber PA9 (Pin 14) ist in dem Bild nicht angeschlossen, vielmehr sieht es nach PIN67 (PB22) aus?
Stimmt das Bild? Oder passt es nicht zur aktuellen board.h?

Danke!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 30 September 2017, 23:01:55
Da passt die board.h nicht zu meinem Cube. Pin 14 (PA9) ist etwas schwer anzulöten, da Pin 13 und 15 belegt sind. Viel einfacher ist es, den Draht zwischen zwei unbelegten Pins zu löten. Pin 67 = PB22 ist dann der richtige Pin für PORT 2.
Titel: Antw:culfw@ARM
Beitrag von: mfischer-ffb am 05 Oktober 2017, 19:36:53
Hallo,
ich versuche gerade die a-culfw mit gänderten out Pin´s zu compilieren. (möchte nur 2 zusätzliche cc1101 betreiben)
leider kommen da folgende Fehlermeldungen und nach dem übertragen der firmware auf den cube  ist er per lan nicht erreichbar, per USB kann ich zumindest die Version abfragen dort steht dann private build


../../clib/fband.c: In function 'readEEpromValue':
../../clib/fband.c:24:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   d = erb((uint8_t *)addr);
           ^

../../clib/fncollection.c: In function 'read_eeprom':
../../clib/fncollection.c:154:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     d = erb((uint8_t *)addr);
             ^
../../clib/fncollection.c: In function 'write_eeprom':
../../clib/fncollection.c:218:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
     ewb((uint8_t*)addr, hb[d-1]);
         ^
../../clib/fncollection.c:228:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
       ewb((uint8_t*)++addr, hb[0]);

^

vielleicht mache aber auch ich einen Fehler.
Ich habe debian 8 und hole mir per git clone https://github.com/heliflieger/a-culfw die daten
anschliessend gehe ich in das CUBe verzeichnis und starte mit make all den compiler

in board.h kann ich ja dann die out pins ändern aber wenns so schon nicht fehlerfrei durchläuft lass ich das erstmal.

muss ich in einer Datei noch diverse einstellungen vor dem make machen ?

vielleicht hat jemand einen Tip für mich..

Vielen Dank
Gruß
Markus
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Oktober 2017, 20:45:01
Das ist keine Fehlermeldung, sondern nur eine Warnung. Funktioniert aber trotzdem.
Titel: Antw:culfw@ARM
Beitrag von: mfischer-ffb am 05 Oktober 2017, 22:47:08
@Telekatz vielen Dank hat funktioniert hab für den ersten externen TRX den Out auf PB24 gelegt  IT senden geht jetzt über das 433Mhz modul nur wenn ich den PB25 für den OUT des 2 externen TRX mit 9 tausche geht LAN nicht mehr.
irgendwo hab ich hier was übersehen.....
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Oktober 2017, 23:58:56
PA9 oder PB9? An PB9 ist der Ethernet PHY angeschlossen, PA9 ist frei.
Titel: Antw:culfw@ARM
Beitrag von: mfischer-ffb am 06 Oktober 2017, 18:57:00
Super vielen Dank für den schnellen Denkanstoß !! ich hatte nicht auf A und B geachtet  :-[
Jetzt schauts gut aus ...
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 12 Oktober 2017, 08:55:34
Weil es sich um eine Frage bzgl Multi-CUL handelt, frage ich mal hier (gehört sonst evtl. in den a-culfw Bereich).

Ich habe die Anpassung bezüglich der Credit-Rückgewinnung gemacht, weil ich auch der Meinung bin, man sollte sich auf 1% pro Stunde beziehen und nicht auf 0,25 Stunden (würde wahrscheinlich auch viele Supportanfragen erschlagen, die wegen fehelender Credits entstehen).

--- a-culfw/culfw/clib/rf_send.h.orig   2017-09-12 17:41:13.068210110 +0200
+++ a-culfw/culfw/clib/rf_send.h        2017-09-12 17:33:48.454073931 +0200
@@ -15,8 +15,8 @@
 void addParityAndSendData(uint8_t *hb, uint8_t hblen,
                         uint8_t startcs, uint8_t repeat);


 extern uint16_t credit_10ms;
-#define MAX_CREDIT 900       // max 9 seconds burst / 25% of the hourly budget
+#define MAX_CREDIT 3600       // max 9 seconds burst / 25% of the hourly budget

 #endif

Nun zur eigentlichen Frage, als zweiten Receiver habe ich einen 433MHz für alle meine günstigen Steckdosen und Schalter.
Insbesondere wenn ich Lichtscenen mit vielen Lampen schalte bleiben meine Credits immer erhalten (vermindern sich nicht durch's Schalten)...

1.) Verbrauchen Intertechno Befehle auch Credits?
2.) Hat jeder der bis zu vier Tranceiver eigentlich ein eigenes Credit Budget?

Danke,
Alex
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 12 Oktober 2017, 18:46:20
1.) Verbrauchen Intertechno Befehle auch Credits?
Da Intertechno auf 433MHz sendet gibt es hier keine 1% Regel. Es werden keine Credits verbraucht.

2.) Hat jeder der bis zu vier Tranceiver eigentlich ein eigenes Credit Budget?
Alle Transceiver teilen sich ein gemeinsames Credit Budget.

Titel: Antw:culfw@ARM
Beitrag von: adn77 am 12 Oktober 2017, 23:46:44
Vielen Dank für die prompte Antwort!

Gut zu wissen, dass es bei 433MHz keine Belegungsbeschränkung gibt.
Titel: Antw:culfw@ARM
Beitrag von: wendeling am 24 Oktober 2017, 10:57:40
Hallo,
Ich habe jetzt so gut wie alles durchgelesen, aber dennoch stehe ich auf dem Schlauch.
Ich möchte mein Max Cube flashen .
Was habe ich bisher gemacht :
- Brücke eingebaut
- firmware durch ein und ausstecken gelöscht
- Brücke wieder entfernt
- Software Sam Ba 2.17 for Windows auf ein 10 Rechner installiert und neu gebootet
- beim Einstecken des cube an usb sehe ich einen neuen Com Board
- Software als admin gestartet
- neuen com Board ausgewählt
- Datei .... 7x.256 ausgewählt
-und dann Connect
- Fenster verschwindet
- warten

Aber es passiert nichts !

Was mach ich falsch ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Oktober 2017, 11:45:15
- neuen com Board ausgewählt
- Datei .... 7x.256 ausgewählt
-und dann Connect
- Fenster verschwindet
Da muss man kein neues com Board oder eine Datei auswählen. In der Liste steht schon das passende Board "at91sam7x256-ek".
Es gibt auch Cubes mit einem at91sam7x512. Da wählt man dann als Board "at91sam7x512-ek" aus.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 24 Oktober 2017, 11:48:59
Ich hatte damals auch Probleme mit Sam-Ba unter Windows, daher hab ich den Cube an den Raspi angeschlossen und geflasht. (Antwort #263 (https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455) hier im Thread)
Titel: Antw:culfw@ARM
Beitrag von: wendeling am 24 Oktober 2017, 17:09:35
Hallo,
ok, bin jetzt doch mit Windows einen schritt weiter!
jetzt blinkt die LED  und die LED 3 leuchtet.
Habe mir jetzt "a-culfw_1.26.01_build_272" gezogen
welche Datei muss ich nun nehmen ?

CUL/CUL_V2_MAX_868MHZ.hex ?

wenn ich Max geräte ansteuern will !

 
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Oktober 2017, 21:08:14
Welche Datei genommen werden muss steht im ersten Beitrag.
Titel: Antw:culfw@ARM
Beitrag von: wendeling am 25 Oktober 2017, 12:21:39
Hallo,
ich glaub ich hab es geschafft!
Jetzt blinkt die Power LED in Sekunden Takt und wenn ich ein Netzwerkkabel anstecke leuchtet auch die Internet LED.
Soweit ok?

wie kann ich die Adresse ändern ?
wie lerne ich nun den Cube an?
und wie kann ich dann MaxThermostate anlernen ?

sorry für die einfachen und blöden Fragen?

Titel: Antw:culfw@ARM
Beitrag von: Wzut am 25 Oktober 2017, 13:21:32
a => https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten
b + c =>  https://wiki.fhem.de/wiki/MAX
Titel: Antw:culfw@ARM
Beitrag von: Holzlenkrad am 19 November 2017, 00:46:33
Nachdem ich den MaxCube jetzt schon ein paar Wochen als IO Device für Homematic Geräte im Einsatz habe, wollte ich mal fragen, ob man das Blinken der Power LED irgendwie abschalten kann (Batterie leuchtet dauerhaft).

Zu Anfang dachte ich ja noch, das gibt sich wenn die ersten Geräte angelernt worden sind. Fehlanzeige.

Leider nervt das Blinken doch ein bisschen, außerdem sind blinkende LEDs ja eigentlich immer ein Fehlerindikator...
Titel: Antw:culfw@ARM
Beitrag von: scooty am 19 November 2017, 15:00:45
set Name_Deines_MaxCubes led 00
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 10 Dezember 2017, 13:30:23
Ich habe einen MaxCube um einen 433MHz Transceiver ergänzt und hoffe alles richtig gelötet und geflasht zu haben. Ich möchte mit dem eingebauten Transceiver meine MAX Komponenten abfragen, und mit dem external 433 MHz Transceiver auf Port1 meine Intertechno Steckdosen schalten.
Bisher habe ich es nicht geschafft, auf meinem CUBEx4 den external 433 MHz Transceiver auf Port1 in Betrieb zu nehmen.
Fragen:Wenn ich den weiteren Transceiver über "STACKABLE_CC" definiere, #++++++++++++++ CUL00 ++++++++++++++++++++++++++++++++++++++
#
define CUL00 CUL culfw.fritz.box:2323 0000
attr CUL00 icon cul_868
attr CUL00 model CUL
attr CUL00 rfmode MAX
attr CUL00 room Gateways
#
define CUL01 STACKABLE_CC CUL00
attr CUL01 room Gateways
attr CUL01 icon cul_cul
verschwindet der Cube aus FHEM, um nach wenigen Sekunden wieder aufzutauchen:
2017.12.08 22:15:59 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:15:59 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:15:59 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:09 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:09 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:09 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:09 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:16 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:17 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:17 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:17 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:45 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:45 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:45 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:45 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:59 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:59 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:59 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:59 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
Wenn ich den weiteren Transceiver über "STACKABLE" definiere, funktioniert der Zugriff auf das Device FHEM:DEVIO:CubeCul433Stack:9600 0000 nicht. #
define CUL00 CUL culfw.fritz.box:2323 0000
attr CUL00 icon cul_868
attr CUL00 model CUL
attr CUL00 rfmode MAX
attr CUL00 room Gateways
#
define CubeCul433Stack STACKABLE CUL00
attr CubeCul433Stack room Gateways
attr CubeCul433Stack verbose 5
define CubeCul433 CUL FHEM:DEVIO:CubeCul433Stack:9600 0000
attr CubeCul433 room Gateways
erzeugt die folgende Fehlermeldung im Logfile: 2017.12.10 12:48:03 3: Opening CUL00 device culfw.fritz.box:2323
2017.12.10 12:48:03 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.10 12:48:03 3: CUL00 device opened
2017.12.10 12:48:03 2: Switched CUL00 rfmode to MAX
2017.12.10 12:48:03 3: Opening CubeCul433 device FHEM:DEVIO:CubeCul433Stack:9600
2017.12.10 12:48:03 5: CubeCul433Stack read: *V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)

2017.12.10 12:48:03 5: CubeCul433Stack read: *? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z

2017.12.10 12:48:03 3: CubeCul433: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.10 12:48:06 1: Cannot init FHEM:DEVIO:CubeCul433Stack:9600, ignoring it (CubeCul433)
2017.12.10 12:48:06 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
Hat jemand eine Idee, wo ich suchen muss?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 Dezember 2017, 14:39:30
  • Wie kann ich kontrollieren, ob die Hardware Erweiterung richtig funktioniert? An vielen Stellen sind die möglichen Befehle beschrieben, die culfw versteht (B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *), aber ich habe bisher noch nicht herausgefunden, wie man die einzelnen Transmitter anspricht.
Um zu testen, ob die Hardware funktioniert würde ich den Cube über USB an einen Rechner hängen und ihn erstmal mit einem Terminalprogramm testen. Die einzelnen Transceiver werden dabei über ein vorangestellten * vor dem Befehl angesprochen.
Gib im Terminal folgende Befehle ein:
V
*V
X21
Zr
*X21
C99
*C99
Die Ausgabe vom Cube sollte ungefähr so aussehen:
V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
*V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 433MHz)
072E4607C626FF0C
450000060021656A
C8930322F834073F
28166C434091876B
F85610AC0B3C1141
00597F8E81350B00
*0D2E2D07D3913D04
*320000060010B071
*57C43023B9000700
*18146C070090876B
*F85611EF0C3D1F41
*00597F1788310B00
Er sollte jetzt auch MAX und Intertechno empfangen können, z.B.:
Z0B2406300FEF7412345600524E
Z0B2506300FEF74123456001050
*s2C6FEE6013;  464: 9536
*i00115103
*i00115404

  • Es gibt einige Beschreibungen, wie man in FHEM mit Transceiver erweiterte (MapleCUN) oder gestackte CULs (SCC) definiert, aber keine Beschreibung für einen erweiterten CUBE. Ich habe versucht, die vorhandenen Bescheibungen auf meinen CUBEx4_BL zu übertragen, laufe aber auf Probleme
Ein erweiterter Cube wird genauso eingebunden wie ein MapleCUN. Entweder mit STACKABLE oder mit STACKABLE_CC. Meine Konfiguration für eine Cube sieht z.B. so aus (2x SlowRF, 1x HM):
define CUBe_0 CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1235
attr CUBe_0 rfmode SlowRF
attr CUBe_0 room System

define CUBe_0_SCC STACKABLE CUBe_0
attr CUBe_0_SCC room System

define CUBe_1 CUL FHEM:DEVIO:CUBe_0_SCC:42 2345
attr CUBe_1 room System

define CUBe_1_SCC STACKABLE CUBe_1
attr CUBe_1_SCC room System

define CUBe_2 CUL FHEM:DEVIO:CUBe_1_SCC:42 3412
attr CUBe_2 hmId F11135
attr CUBe_2 rfmode HomeMatic
attr CUBe_2 room System

Wenn ich den weiteren Transceiver über "STACKABLE" definiere, funktioniert der Zugriff auf das Device FHEM:DEVIO:CubeCul433Stack:9600 0000 nicht.
Die Module STACKABLE und STACKABLE_CC funktionieren nicht gleichzeitig. Wenn du STACKABLE benutzt solltest du erst einmal alle STACKABLE_CC löschen und FHEM neu starten. Und unter Windows habe ich STACKABLE auch nicht zum laufen gebracht.
Titel: Antw:culfw@ARM
Beitrag von: BHef am 10 Dezember 2017, 18:09:00
Wenn die Antwort auf einer der vorhergehenden 59 Seiten steht, bitte ich zu entschuldigen, dass ich nicht alles gelesen habe. Ich habe zwei Fragen:
a) Welchen Vorteil bietet mir das umflashen?
b) wenn das schiefgeht, kann ich mit Fhem und den Max Komponenten OHNE den Cube arbeiten?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 Dezember 2017, 19:11:06
Wenn die Antwort auf einer der vorhergehenden 59 Seiten steht, bitte ich zu entschuldigen, dass ich nicht alles gelesen habe. Ich habe zwei Fragen:
a) Welchen Vorteil bietet mir das umflashen?
Das wurde erst kürzlich hier diskutiert:
https://forum.fhem.de/index.php/topic,77590.0.html (https://forum.fhem.de/index.php/topic,77590.0.html)

b) wenn das schiefgeht, kann ich mit Fhem und den Max Komponenten OHNE den Cube arbeiten?
Ohne ein Funk Interface geht es nicht. Entweder ein original Cube oder ein CUL bzw. ein umgeflshter Cube.
Titel: Antw:culfw@ARM
Beitrag von: BHef am 10 Dezember 2017, 19:18:51
Super, vielen Dank!
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 11 Dezember 2017, 12:45:17
Vielen Dank für die schnelle Antwort. Die einzelnen Transceiver werden dabei über ein vorangestellten * vor dem Befehl angesprochen.Das war der entscheidende Hinweis für meine weitere Fehlersuche. Leider ist das vorangestellte * nirgendwo beschrieben. Es wäre schön, wenn es in die http://culfw.de/commandref.html (http://culfw.de/commandref.html) aufgenommen würde.
Um zu testen, ob die Hardware funktioniert würde ich den Cube über USB an einen Rechner hängen und ihn erstmal mit einem Terminalprogramm testen. Der Cube hat sich an der USB Schnittstelle so verabschiedet wir unter FHEM genau in dem Augenblick, wo der nachgerüstete Transceiver das erste mal angesprochen wird. Deshalb gehe ich von einem Löt- oder Hardware Fehler aus.
Als 433MHz Transceiver habe ich einen AS07-M1101S V3.1 eingesetzt. Die Bezeichnung der AS07 Anschlußpins ist nicht genau deckungsgleich mit den Beschreibungen. Ich habe die Belegung schon mehrfach verglichen und kann keinen Fehler finden (oder ich sehe den Wald vor lauter Bäumen nicht). Hier ist meine Belegung (vergl. https://www.devicemart.co.kr/1323011 (https://www.devicemart.co.kr/1323011)):
CubeAS07-M1101SPinPin directionPin uses
VCCVCC1Power supply, must be in the range 1.9-3.6V
OUT (PB25)GOD02Module information output pin
CS (PA6)CSN3InputModule chip select pin, used to start a SPC communication
SCKSCK4InputSPI bus clock
MOSIMOSI5InputModule SPI data input pin
MOSI/GD?? was ist das ??
MISOGOD1 (O1)6??Input??Input module SPI data output pin
IN (PA5)GOD27OutputOutput module information output pin
GNDGND8OutputExpress, connected to the power supply ground reference.
Die culfw habe ich nach Anleitung und mit dem Patch von Loetzimmer gebaut.

In der Zwischenzeit habe ich einen zweiten Cube mit einem 868MHz Transceiver ausgerüstet. Der arbeitet wie beabsichtigt. Für die Einbindung in FHEM habe ich die "STACKABLE" Variante gewählt.
Die Module STACKABLE und STACKABLE_CC funktionieren nicht gleichzeitig. Das habe ich schon geahnt, da nach einem Wechsel von STACKABLE_CC nach STACKABLE folgendes in der Logdatei aufgetaucht ist:2017.12.08 22:25:19 2: Switched CUL00 rfmode to MAX
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOOpenFn redefined at ./FHEM/16_STACKABLE.pm line 114, <$fh> line 107.
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOReadFn redefined at ./FHEM/16_STACKABLE.pm line 124, <$fh> line 107.
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOWriteFn redefined at ./FHEM/16_STACKABLE.pm line 154, <$fh> line 107.
2017.12.08 22:25:19 3: Opening CUL01 device FHEM:DEVIO:CUL01Stack:9600
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 Dezember 2017, 21:32:21
Der Cube hat sich an der USB Schnittstelle so verabschiedet wir unter FHEM genau in dem Augenblick, wo der nachgerüstete Transceiver das erste mal angesprochen wird. Deshalb gehe ich von einem Löt- oder Hardware Fehler aus.
Wann genau stürzt er ab? Bei *X21 oder erst bei *Zr? Hast du auch schon mal die Debugausgabe auf ST2 mitgeloggt?
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 11 Dezember 2017, 22:07:53
Hallo Telekatz,
Wann genau stürzt er ab? Bei *X21 oder erst bei *Zr? Hast du auch schon mal die Debugausgabe auf ST2 mitgeloggt?
Der internal Transceiver arbeitet ganz normal (Zr), und beliebig lange. Der Absturz erfolgt bei *X21


Beim Einschalten des Cubes wird am Debug Port (Speed = 115200 Baud) folgendes angezeigt:-I- Getting new Started Project --
-I- CUBEx4
-I- Compiled: Dec  6 2017 21:20:20 --
-I- init Flash
-I- Initializing the SPI and AT45 drivers
-I- At45 enabled
-I- SPI interrupt enabled
-I- Waiting for a dataflash to be connected ...
-I- AT45DB041D detected
-I- Device identifier: 0x0000241F
-I- EE Magic: 1 26 Start 792
-I- Flash Serial: cb9bf4e2
-I- init Timer
-I- init EEprom
-I-  - MAC 0:80:41:9b:f4:e2
-I- ** Valid PHY Found: 1
-I-  DM9161_ResetPhy
-I- Detected CC0: PN 0x00  VER 0x03
-I- Detected CC1: PN 0x00  VER 0x14
-I- Not detected CC2: PN 0xff  VER 0xff
-I- Not detected CC3: PN 0xff  VER 0xff
-I- Not detected onewire
-I- init USB
-I- CDCDSerialDriver_Initialize
USBD_Init
-I- init Complete
Res EoBRes CfgEpt0 NewReq Std gDesc Dev EoBRes CfgEpt0 NewReq Std sAddr SetAddr(25) NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Str0 NewReq Std gDesc Str1 NewReq Std gDesc Qua -W- Sta 0x888A8 [0] -W- _ NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std sCfg SetCfg(1) CfgEpt3 CfgEpt1 CfgEpt2 ConfigurationChanged NewReq gLineCoding NewReq sControlLineState(0, 0) NewReq sLineCoding NewReq gLineCoding
Jetzt gebe ich die von Dir zum Test angegebenen Kommandos ein:V
*V
X21
Zr
Am Debug Port erscheint:
0:Set RF mode to 1
0:Set RF mode to 3
Der interne Transceiver arbeitet jetzt ganz normal und protokolliert die MAX Telegramme.
Der Absturz / der Neustart erfolgt nach dem Kommando *X21. Das USB Terminal meldet PUTTY fatal Error - Error reading from serial device. Die Ausgabe am Debug Port ist
-I- Getting new Started Project --
-I- CUBEx4 . . . und weiter mit dem ganzen Rest, den wir oben beim Einschalten sehen . . .
Ich kann mir das nur mit vertauschten Anschlüssen oder einer kaputten Briefmarke erklären. Hast Du eine Idee?
Gruß Werner
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 Dezember 2017, 16:42:57
-I- Detected CC1: PN 0x00  VER 0x14Da der zweite Transceiver erkannt wurde funktioniert die SPI Verbindung korrekt.

Das bereits X21 einen Absturz verursacht ist ungewöhnlich. Bei diesem Kommando fällt es nicht mal auf, wenn kein Transceiver verbunden ist. Bei einem nicht verbundenen Transceiver startet ein CUL erst beim aktivieren eines der anderen Protokolle neu. Dann wird darauf gewartet, dass der Transceiver einen bestimmten Zustand einnimmt und da das nicht passiert wird der Watchdog ausgelöst.

Löte mal GDO0 und GDO2 ab und schau, was dann passiert.
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 16 Dezember 2017, 22:59:53
Das bereits X21 einen Absturz verursacht ist ungewöhnlich.Um exakt zu sein, bei X21 erfolgt noch nicht der Absturz, erst bei *X21.
Aus lauter Verzweiflung hatte ich alles abgelötet und wieder angelötet, dabei aber einen Fehler gemacht und GOD0 nicht verbunden: => kein Absturz, aber auch keine Funktion des 433MHz Transceivers.
Ich habe neue Briefmarken bestellt und will sehen, ob damit der Fehler wieder auftritt.
Titel: Antw:culfw@ARM
Beitrag von: Allodo am 28 Dezember 2017, 14:09:27
Hallo,

ich habe seit gestern auch einen Max!Cube aus einem Medion-Starterset. Da ich mir gleich 2 Sets zugelegt habe, wollte ich den einen umflashen.
Ich habe es mit Sam-ba v2.17 und v2.18 unter Win10 als Admin "versucht". Jedes Mal wurde der COM-Port richtig eingetragen.

Jedoch kommt nach Send-File nur 1% und nach Execute ebenfalls nur 1% und es tut sich nix mehr (ist das normal?).
Anschließend habe ich mit TeraTerm die die Firmware geflasht und jetzt blinkt eine LED im Sekundentakt (scheint wohl richtig geflasht zu sein?).

Den Cube habe ich an einem RPi2 angesteckt, mit einer frischen FHEM-Installation von gestern Abend.

Sollte der Cube nun als CUL automatisch erkannt werden oder bedarf es noch irgendwelcher Schritte? Mir wurde nämlich gesagt, er solle automatisch erkannt werden.
Und ich weiß jetzt nicht ob das flashen richtig funktioniert hat, oder nicht :(

Den anderen MaxCube mit Original-Firmware habe ich in FHEM eingebunden und er läuft einwandfrei. Wobei ich absoluter FHEM-Neuling bin. Deshalb bitte ich um Nachsicht ;)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 Dezember 2017, 20:31:35
Sollte der Cube nun als CUL automatisch erkannt werden oder bedarf es noch irgendwelcher Schritte? Mir wurde nämlich gesagt, er solle automatisch erkannt werden.
Und ich weiß jetzt nicht ob das flashen richtig funktioniert hat, oder nicht :(

Der Cube wird nicht automatisch erkannt. Den muss man manuell definieren:
define Cube CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1234
Titel: Antw:culfw@ARM
Beitrag von: Allodo am 29 Dezember 2017, 07:31:24
@Telekatz
Danke, jetzt wurde er sofort gefunden :)

Jetzt werde ich mich erst einmal in FHEM einlesen müssen ;)

EDIT:
Ich musste FHEM noch einmal neu installieren und bei der Installation wurde der CUL_MAX sofort integriert, sprich er musste nicht extra definiert werden :)

Ich werde zukünftig wohl auch Rollladenaktoren von Homematic einsetzen, da ich bei diesen meine Mertenblenden verwenden kann (günstigere Variante als Vorschlag wird gerne angenommen). Nur stellt sich bei mir nach einigem lesen doch konfusion ein.
Die Threads sind von Beginn diesen Jahres und dort wird erwähnt man soll eine spezielle Homematic-Firmware auf den CUL aufspielen, während andere sagen der CCU2 wäre für den Einsatz mit Homematic viel besser.

Ich wollte jetzt eigentlich meinen CUL_MAX dafür einsetzen. Dort kann ich ja per rfpm Homematic auswählen. Heißt das jetzt dieser spezielle Teil ist involviert?
Wenn ich jetzt FHEM einsetzen will auf einem RPi2 oder 3 mit dem CUL_MAX, wäre dann immernoch der CCU2 die bessere Wahl?

Weiterer EDIT:
Habe mittlerweile Homematic Schalt- und Rollladenaktoren verbaut. Und diese laufen perfekt mit dem Max!Cube/CUL :)
Titel: Antw:culfw@ARM
Beitrag von: caligo23 am 05 Januar 2018, 19:48:21
@telekatz

Hallo, da ich nun endlich auch einen MAX!Cube hier habe, stellt sich die Frage : Wie schließe ich einen zusätzlichen CC1101 (433MHz) an.
Welche PINs werden mit welchen Signalen beschaltet. Aus der board.h werde ich nicht so ganz schlau und die Bilder vom blog.loetzimmer.de sind auch nicht wirklich hilfreich.
MOSI, MISO und SCK werden mit den Signalen am TRX1 verschaltet, aber wo gehen GDO0, GDO2 und CSN hin?
Leider habe ich bisher keine Antwort finden können.
Für Hilfe wäre ich dankbar.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2018, 18:06:49
GDO0 ist der OUT_PIN, GDO2 ist der IN_PIN und CSN ist der CS_PIN.

Wenn du nur einen oder zwei Transceiver nachrüsten möchtest, solltest du die Zuordnung in der board.h so ändern, dass du nur die verfügbaren Pins auf der Oberseite der Platine brauchst.
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606 (https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606)

Für Homematic oder MAX kann der OUT_PIN auch unangeschlossen bleiben.
Titel: Antw:culfw@ARM
Beitrag von: OtisWright am 06 Januar 2018, 19:30:25
Guten Abend zusammen,
ich versuche seit ein paar Tagen meinen Cube mit einem zusätzlichen CC1101 433 MHz Modul zum laufen zu bringen. Leider ohne wirklichen Erfolg.

Ich habe die Board.h nicht verändert und habe das in Beitrag #1 verlinkte Bin-File über XModem auf den Cube geladen. Dann habe ich die Pins wie folgt verbunden (siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)

Cube -> CC1101
VCC -> VCC
GND -> GND
PA5 -> GDO2
PA6 -> CSN
PA28 -> GDO0 (ST2 Pin2, laut Schaltplan)

TRX1 -> TRX2
Pin 1: MOSI -> MOSI
Pin 2: SCK -> SCK
Pin 3: MISO -> MISO

Kann jemand bestätigen, dass dies so korrekt ist?
Danke im Voraus.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2018, 20:01:40
Ich habe die Board.h nicht verändert und habe das in Beitrag #1 verlinkte Bin-File über XModem auf den Cube geladen. Dann habe ich die Pins wie folgt verbunden (siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)
Hast du auch die Datei CUBEx4_BL.bin verwendet?

PA28 -> GDO0 (ST2 Pin2, laut Schaltplan)
In board.h ist PB28 für CC1100_1_OUT definiert.
Titel: Antw:culfw@ARM
Beitrag von: OtisWright am 06 Januar 2018, 20:11:02
Genau, ich habe die CUBE_x4_BL.bin verwendet.

stimmt, ich hatte jetzt nur auf internal und external transceivers geachtet.Pin 5 und 6 sind wohl ebenfalls für cc1100 definiert. was heißt das jetzt für mich? sorry, aber steh gerade auf dem schlauch

Edit:
Mir zeigt FHEM die folgenden Infos an:

VERSION
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
ccconf
freq:5913.464MHz bWidth:232KHz rAmpl:24dB sens:16dB

und wenn ich dann auf get ccconf klicke kommt:
Timeout reading answer for get C0D
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2018, 20:19:45

VERSION
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
Erkannt worden ist der zweite Transceiver.

Mach mal mit raw e einen Reset der Einstellungen.
Titel: Antw:culfw@ARM
Beitrag von: OtisWright am 06 Januar 2018, 20:26:11
Das hab ich gerade probiert. allerdings gibts dadurch keine Besserung. ein blick ins logfile und siehe da - das hier passiert seit 30 minuten durchgehend:

2018.01.06 20:22:59 3: CUBe_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2018.01.06 20:22:59 1: 192.168.xxx.xxx:2323 reappeared (CUBe_0)
2018.01.06 20:22:59 3: CUBe_1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2018.01.06 20:23:25 1: 192.168.xxx.xxx:2323 disconnected, waiting to reappear (CUBe_0)

Woran kann das liegen?
Titel: Antw:culfw@ARM
Beitrag von: caligo23 am 06 Januar 2018, 20:28:18
Vielen Dank für die schnelle Antwort, mit den Infos sollte es funktionieren!
Ihr seid einfach Klasse!
Grüßle
Titel: Antw:culfw@ARM
Beitrag von: OtisWright am 06 Januar 2018, 20:34:35
In board.h ist PB28 für CC1100_1_OUT definiert.

ups. ich hab das B übersehen. stimmt. hier habe ich was durcheinander gebracht. habe PA28 jetzt wieder entfern, ist ohnehin nicht erforderlich, richtig? Sollen nur IT-Steckdosen geschaltet werden. Ich hoffe nur, ich hab durch diesen fauxpas nichts zerschossen :(
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 06 Januar 2018, 20:55:05
Das hab ich gerade probiert. allerdings gibts dadurch keine Besserung. ein blick ins logfile und siehe da - das hier passiert seit 30 minuten durchgehend:

2018.01.06 20:22:59 3: CUBe_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2018.01.06 20:22:59 1: 192.168.xxx.xxx:2323 reappeared (CUBe_0)
2018.01.06 20:22:59 3: CUBe_1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2018.01.06 20:23:25 1: 192.168.xxx.xxx:2323 disconnected, waiting to reappear (CUBe_0)

Woran kann das liegen?
Teste mal, ob es über USB funktioniert.

ups. ich hab das B übersehen. stimmt. hier habe ich was durcheinander gebracht. habe PA28 jetzt wieder entfern, ist ohnehin nicht erforderlich, richtig? Sollen nur IT-Steckdosen geschaltet werden. Ich hoffe nur, ich hab durch diesen fauxpas nichts zerschossen :(
Zum schalten von IT-Steckdosen wird der OUT_PIN benötigt. Ohne OUT_PIN geht nur der Empfang.
Titel: Antw:culfw@ARM
Beitrag von: OtisWright am 06 Januar 2018, 21:14:49
also ich glaube das ganze hängt mit meinem CC1101 Modul zusammen. ich hab das jetzt mal abgesteckt (Habe Jumper-Kabel an den Cube gelötet um das schnell tauschen zu können) und sowohl über USB als auch über LAN geht der Cube jetzt wieder.
Das heißt wohl, dass ich ohne neues CC1101 Modul und ändern der Board.h Datei nicht um das Vergnügen mit dem Cube herumkomme.

Danke sehr für die tolle Hilfe am Samstag Abend!
Titel: Antw:culfw@ARM
Beitrag von: freetz am 17 Januar 2018, 00:42:49
Hallo zusammen,

ich hatte vor gut einem Jahr schon einmal hier mein Problem beschrieben, das ich beim Flashen der Firmware meines Max Cubes hatte und konnte es damals irgendwie lösen:
https://forum.fhem.de/index.php/topic,38404.msg558765.html#msg558765

Nun wollte ich eine neuere Firmware aufspielen, hatte zu Anfang die gleichen Probleme mit dem Mac (bis ich auf meinen Post hier stieß ;) ) und habe es jetzt wieder unter Ubuntu probiert. Das Aufspielen eines neuen Bootloaders klappt auch, aber wenn dann die LED blinkt und ich die Firmware hochladen will, bleibt die LED nach dem (anscheinend erfolgreichen) Update aus. dmesg sagt mir "unable to enumerate USB device", aber wenn ich dann mit RESET gedrückt den Cube einstecke, bekomme ich brav ein "Product: CUBELOADER" und kann das Spiel erneut (wenn auch ohne Erfolg durchführen.
Weitere Fehlermeldungen sind u.a.
"cdc_acm 2-1:1.0: failed to set dtr/rts"
"device descriptor read/64, error -71"
"device not accepting address 11, error -71"
Wie gesagt nur, nach dem Upload der Firmware, nicht, wenn ich im Bootloader Modus bin.

Ich bin mir ziemlich sicher, dass ich damals die CUL_V3_868MHZ.hex verwendet hatte, es war auf jeden Fall die Version 1.23.05. Aber um sicher zu gehen: Wie kann ich herausfinden, ob ich V2, V3 oder V4 einsetzen muss?

Freue mich über jede Hilfe, da ansonsten die Heizung hier sonst nur über die Außentemperatur gesteuert werden kann :(...

Gruß,

F.
Titel: Antw:culfw@ARM
Beitrag von: freetz am 17 Januar 2018, 07:41:44
Ich habe nun zum Testen den neuen Cube (der für meine Eltern sein soll) auch versucht zu flashen, aber da komme ich trotz Überbrückens von J1 noch nicht einmal zum Löschen des Bootloaders. Der Cube blinkt am Anfang immer kurz und leuchtet dann dauerhaft. Gibt es da Erkenntnisse, ob neuere Cubes da einen Löschschutz haben?
Titel: Antw:culfw@ARM
Beitrag von: blueicechip am 17 Januar 2018, 08:28:54
Hallo freetz,

die CUL V 2/3/4 kenne ich nur für die Atmels für den Cube gibt es die a-cul CUBe Firmware.

Mit dem Bootloader Flashen hatte ich bisher keine Probleme, allerdings hatten ich auch grosse Probleme die Firmware per xmodem zu über tragen - lag aber an meinen Rechnern, mit einem ginges dann. Hatte aber auch nicht weiter nachgeforscht warum die anderen Rechner nicht korrekt per xmodem verbinden / übertragen wollten.
Titel: Antw:culfw@ARM
Beitrag von: freetz am 17 Januar 2018, 08:43:08
Wow. You made my day :)!
Ich Hirsch hatte vor dem Cube einen CUL-Stick im Einsatz (über ein Jahr her), den ich damals mit der CUL-Firmware geflasht hatte und dann bei der Suche nach den Files diese zuerst gefunden - und dachte irgendwie, dass die Files in CUBe nur für den Bootloader wären.
Nun tut's, diesmal sogar mit BOSSA und Tera Term aus der Virtual Machine von Parallels auf meinem Mac heraus :). Der Upload hing am Ende dann zwar bei 100%, aber nach dem An- und Abstecken bootete der Cube wie er sollte.

Das Löschen des Bootloaders ging (im Gegensatz zum anderen Cube) nicht, wenn man die Kontakte nur an der Oberfläche verbunden hat, ich musste richtig mit einer Büroklammer in die Löcher gehen, dann ging's aber sofort.

Vielen Dank noch mal für die schnelle Hilfe im entscheidenden Punkt!
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 23 Januar 2018, 17:46:06
Das bereits X21 einen Absturz verursacht ist ungewöhnlich.Um exakt zu sein, bei X21 erfolgt noch nicht der Absturz, erst bei *X21.
Aus lauter Verzweiflung hatte ich alles abgelötet und wieder angelötet, dabei aber einen Fehler gemacht und GOD0 nicht verbunden: => kein Absturz, aber auch keine Funktion des 433MHz Transceivers.
Ich habe neue Briefmarken bestellt und will sehen, ob damit der Fehler wieder auftritt.
Es hat lange gedauert bis die neuen Transceiver geliefert worden sind. Da der Fehler mit den neuen Transceivern in gleicher Weise auftaucht, habe ich mir die beiden Max!Cubes genauer angesehen:

Mit diesem Cube funktioniert es:
eQ-3  BC-LGW-O-TW
TRX868 / 868.3 MHz
Prozessor AT91SAM7x256
Das fest eingebaute Transceiver Modul hat ein QR-Code Label mit "12686872". Das Modul habe ich nicht geöffnet, um nachzuschauen welches Transceiver Chip verbaut ist.

Dieser Cube (etwas älter) hat die oben beschriebenen eigenartigen Neustarts in dem Augenblick, wenn der zweite Transceiver das erste Mal angesprochen wird (Befehl  *X21):
eQ-3  BC-LGW-O-TW-MD
TRX868-TI / 868.3 MHz
Prozessor AT91SAM7x512
eingebautes Transceiver Chip CC1100

Obwohl lt. TI der CC1100 etwas weniger Funktionen hat als der CC1101 funktioniert der CC1100 mit der Culfw Firmware.

Gibt es zu den beiden Cubes Erfahrungen was geht und was nicht?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 23 Januar 2018, 18:14:39
Dieser Cube (etwas älter) hat die oben beschriebenen eigenartigen Neustarts in dem Augenblick, wenn der zweite Transceiver das erste Mal angesprochen wird (Befehl  *X21):
Das erste mal wird der zweite Transceiver bereits bei der Hardware Autodetection angesprochen und da wird er auch gefunden. Stürzt der Cube auch bei den Befehlen *C99 oder *Zr ab?
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 24 Januar 2018, 08:35:03
Das erste mal wird der zweite Transceiver bereits bei der Hardware Autodetection angesprochen und da wird er auch gefunden. Stürzt der Cube auch bei den Befehlen *C99 oder *Zr ab?
Vielen Dank für die Geduld. Jetzt funktioniert es.
Ich habe mit dem Befehl e den Cube zurück gesetzt. Und oh Wunder keine Abstürze mehr.

PS: Wer pflegt die Seite http://culfw.de/commandref.html (http://culfw.de/commandref.html) ? Es wäre schön, wenn das Prefix * (** und ***) zur Ansprache des zweiten bis vierten Transceivers mit aufgenommen werden könnte.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 24 Januar 2018, 10:37:02
Ich hätte da gerne mal ein Problem :
Ich betreibe nun schon recht lange ohne Probleme zwei CUBEs ( V 1.10.02 a-culfw & V 1.21.00 a-culfw ) via Lan im HM Mode. Stromversorgung ist bei beiden irgend so ein USB Steckernetzteil.
Ich habe angefangen bei meinem Hardware Zoo etwas Ordnung zu machen und kam dabei auf die Idee den einen CUL statt mit dem Netzteil mit Strom zu versorgen einfach an einen freien Raspi USB Port zustecken. ( auf diesem läuft nicht FHEM ! )
Als Folge leuchtet am Cube die BATTERY LED und ca. alle zwei Minuten ist er von FHEM via Netzwerk nicht erreichbar ( disconnect -> connect), konnte ich mir nicht erklären also wieder zurück zum Netzteil. Am WE das gleiche Spiel am anderen CUBE , Netzteil weg und USB Port einer Fritzbox benutzt. Wieder BATTERY LED und die ständigen disconnects.
Was läuft da schief wenn die Firmware merkt das am USB Port eine echte serielle Schnittstelle hängt ?
Wenn es keine Möglichkeit gibt das via Software fixen zu können werde ich mir halt USB Kabel machen müssen die nur zwei Drähte aufgelegt haben statt vier.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 Januar 2018, 11:44:37
Möglicherweise öffnet irgend ein Prozess die USB Verbindung kurz. Das merkt der Cube und will daraufhin alle Nachrichten auch über USB ausgeben. Wenn die USB Verbindung dann wieder geschlossen wird, wird der USB Buffer nicht mehr geleert, der Buffer läuft voll, der Cube bleibt auf die Leerung wartend in einer Endlosschleife hängen und der Watchdog löst aus.
Titel: Antw:culfw@ARM
Beitrag von: uelpenich am 24 Januar 2018, 11:50:59
Ich hätte da gerne mal ein Problem :
Ich betreibe nun schon recht lange ohne Probleme zwei CUBEs ( V 1.10.02 a-culfw & V 1.21.00 a-culfw ) via Lan im HM Mode. Stromversorgung ist bei beiden irgend so ein USB Steckernetzteil.
Ich habe angefangen bei meinem Hardware Zoo etwas Ordnung zu machen und kam dabei auf die Idee den einen CUL statt mit dem Netzteil mit Strom zu versorgen einfach an einen freien Raspi USB Port zustecken. ( auf diesem läuft nicht FHEM ! )
Als Folge leuchtet am Cube die BATTERY LED und ca. alle zwei Minuten ist er von FHEM via Netzwerk nicht erreichbar ( disconnect -> connect), konnte ich mir nicht erklären also wieder zurück zum Netzteil. Am WE das gleiche Spiel am anderen CUBE , Netzteil weg und USB Port einer Fritzbox benutzt. Wieder BATTERY LED und die ständigen disconnects.
Was läuft da schief wenn die Firmware merkt das am USB Port eine echte serielle Schnittstelle hängt ?
Wenn es keine Möglichkeit gibt das via Software fixen zu können werde ich mir halt USB Kabel machen müssen die nur zwei Drähte aufgelegt haben statt vier.
Es gibt zwei Arten von USB Kabeln: mit und ohne Brücke zwischen Pin 4 und Pin 5 (die Masse Verbindung). Diese Brücke entscheidet im angeschlossenen Gerät, ob das Kabel nur der Stromversorgung dient oder ob es für Stromversorgung plus Datenverkehr genutzt wird. Diese Unterscheidung wird von Navis und Mobiltelefonen gemacht. Ob das für den Cube mit culfw eine Rolle spielt ist einen Versuch wert.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 24 Januar 2018, 13:14:37
Wenn die USB Verbindung dann wieder geschlossen wird, wird der USB Buffer nicht mehr geleert, der Buffer läuft voll, der Cube bleibt auf die Leerung wartend in einer Endlosschleife hängen und der Watchdog löst aus.
OK, wenn es nur darum geht den Bufferinhalt abzuholen und nach /dev/nul weiterzuleiten werde ich das mal als Softwarelösung testen bevor ich die Kabel zerschneide.
Titel: Antw:culfw@ARM
Beitrag von: toxic-tonic am 26 Januar 2018, 15:31:28
Moin,

habe nach langem hin und her nun endlich meinen cube(x4) um ein 434MHz-Modul ergänzen können. Sieht auch ganz gut aus, außer, dass er es als 868MHz-Modul erkennt:

...
-I- ** Valid PHY Found: 1
-I-  DM9161_ResetPhy
-I- Detected CC0: PN 0x00  VER 0x03
-I- Detected CC1: PN 0x00  VER 0x14
-I- Not detected CC2: PN 0xff  VER 0xff
-I- Not detected CC3: PN 0xff  VER 0xff
-I- Not detected onewire
-I- init USB
-I- CDCDSerialDriver_Initialize
USBD_Init
-I- init Complete
V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
*V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)

Muss ich die Frequenz in der Firmware anpassen, über einen Befehl oder soll ich in FHEM das einfach als Attribut übergeben?

Danke und Gruß

Tobias
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 Januar 2018, 16:11:26
Mach mal mit "raw e" einen Reset der Einstellungen.
Titel: Antw:culfw@ARM
Beitrag von: toxic-tonic am 26 Januar 2018, 16:19:21
Bingo! DANKE!! :)
Titel: Antw:culfw@ARM
Beitrag von: toxic-tonic am 29 Januar 2018, 12:07:54
Hi,

da ich ziemlich viel Stress hatte das zusätzliche Interface an den Cube zu bekommen hier mal die Schaltung für einen E07-M1101D-TH:

Pin  - CC   -  Cube
1    -  GND  -  GND
2    -  VCC  -  VCC
3    -  GDO0 -  PB25
4    -  CSN  -  PA6
5    -  SCK  -  SCK
6    -  MOSI -  MOSI
7    -  MISO -  MISO
8    -  GDO2 -  PA5

Voraussetzung ist dieser Patch: https://loetzimmer.de//patches/cube.patch um die PINs richtig zuzuordnen!

Gruß

Tobias
Titel: Antw:culfw@ARM
Beitrag von: toxic-tonic am 02 Februar 2018, 07:45:41
Moin,

Eine Frage: kann es sein, dass das zusätzliche Modul (CubeX4)  keine Signale empfangen kann? Ich habe den Cube als cul_max konfiguriert und benutze das zweite Modul als Intertechno-Sender. Mit dem alten Cul habe ich auch Schalter von Intertechno empfangen, jetzt kommt nichts mehr an.

Generell ein Problem des cubex4 oder kann ich da was dran machen?

Danke und Gruß

Tobias
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 Februar 2018, 17:10:31
Beim CUBEx4 funktioniert SlowRF ohne Einschränkungen auch beim zweiten Transceiver.
Titel: Antw:culfw@ARM
Beitrag von: toxic-tonic am 05 Februar 2018, 08:52:15
Moin,

habe es jetzt noch mal näher eruiert. Denke das Problem ist die Konfiguration als MAX-Device. meine config sieht so aus:

define cun01 CUL x.x.x.x:2323 xxxx
attr cun01 rfmode MAX
attr cun01 room Z_-_System
define cun01_max CUL_MAX xxxxxx
attr cun01_max IODev cun01
attr cun01_max room Z_-_System

define cun02 STACKABLE_CC cun01
attr cun02 room Z_-_System

Wenn ich den MAX-Teil rausnehme kann ich die IT-Sachen empfangen. Wahrscheinlich wird durch diese Konfiguration das erste Interface auf "lauschend" gestellt und das zweite kommt dann nicht mehr zum Zug? Oder mach die Konfiguration als "Stackable" vielleicht noch einen unterschied?

Danke und Gruß

Tobias
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Februar 2018, 18:46:36
An der a-culfw sollte es nicht liegen, die kann gleichzeitig MAX und IT empfangen:

Z170000000FEF74123456001004024C4551303739343539324D
*i001151F9
*i00155FFB
Z0B0106300FEF7412345600103D
Z170000000FEF74123456001004024C45513037393435393237
Z0B0106300FEF7412345600123D
Z0B0106300FEF74123456001229
*s52800660F9;  464: 9520
*i00145101
*i00155F03
Z0B0106300FEF7412345600124E
Z0B0206300FEF74123456001038
Z0B0206300FEF7412345600102F
Z0B0206300FEF74123456001016
*s52800660FE;  480: 9520
Z0B0206300FEF74123456001018
Z0B0206300FEF7412345600502C
*s52800660FD;  464: 9552

Versuch mal den zweiten Transceiver räumlich etwas anders anzuordnen. Ich hatte mal das Problem, das mehrere nur auf Empfang geschaltete Transceiver sich trotzdem gestört hatten.
Titel: Antw:culfw@ARM
Beitrag von: toxic-tonic am 07 Februar 2018, 19:16:12
Hi,

Habs auch rausbekommen, musste noch den SlowRF als rfmode setzen:

define cun02 STACKABLE_CC cun01
attr cun02 rfmode SlowRF
attr cun02 room Z_-_System

Danke und Gruß

Tobias
Titel: Antw:culfw@ARM
Beitrag von: DJNoXD am 19 März 2018, 09:16:08
Hallo

Erst einmal Danke für diese tolle Firmware. :-)


Wir ihr euch schon denken könnt, habe ich eine Frage, bei der ich eure Unterstützung benötige.

Folgendes (aus meiner Sicht seltsames) Verhalten tritt bei mir auf.

Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.
Nach meiner Recherche handelt es sich um ein echtes 86MHz Modul. (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649))
Mein Problem ist, dass der neue CC mit 433 MHz erkannt wird.
Ich ändere die Konfiguration dann auf 868MHz und alles funktioniert einwandfrei mit guten Empfang.

Nach einer gewissen Zeit "vergisst" das Modul dann leider die Konfiguration und es funktioniert erst dann wieder, wenn sie wieder angepasst habe.

Hier meine Konfiguration aus der fhem.cfg:
define CUL0 CUL 192.168.0.94:2323 0000
attr CUL0 icon cul_868
attr CUL0 rfmode MAX
attr CUL0 room System,RF
attr CUL0 verbose 0

define CUL1 STACKABLE_CC CUL0
attr CUL1 connectCommand Nr1
attr CUL1 icon cul_868
attr CUL1 rfmode SlowRF
attr CUL1 room System,RF
attr CUL1 verbose 0

define CULMAX0 CUL_MAX 123456
attr CULMAX0 IODev CUL0
attr CULMAX0 room System,RF

Auszug aus dem Log des CUBEs, wenn er erpfängt:
*N0195C3723701AAAA0000943243
H431780280055FF
*N0191D8167D03DE716B676BD0D9
H434701160400FF

Hier die Ausgaben der Module:
CUL0 (orginal Cube Modul):
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz*
CUL0_MSGCNT 1728
CUL0_TIME 2018-03-19 08:55:01
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.0.94:2323 0000
DeviceName 192.168.0.94:2323
FD 10
FHTID 0000
NAME CUL0
NR 52
PARTIAL
RAWMSG H432C00790142FF
RSSI -74.5
STACKED CUL1
STATE Initialized
TYPE CUL
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21 Zr Za123456 Zw111111

Readings:
ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB 2018-03-19 08:58:44
cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z * 2018-03-19 08:58:47
credit10ms 3106 2018-03-19 08:59:02
fhtbuf AE 2018-03-19 08:59:00
raw No answer 2018-03-17 00:39:27
state Initialized 2018-03-19 08:58:41
uptime 0 00:21:36 2018-03-19 08:58:52
version V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz) 2018-03-19 08:58:55

CUL1 (ergännztes Modul):
Internals:
CMDS bCFiAZNEGMKLUYRTVWXfz
CUL1_MSGCNT 1123
CUL1_TIME 2018-03-19 09:03:00
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF CUL0
IODev CUL0
NAME CUL1
NOTIFYDEV CUL0
NR 54
NTFY_ORDER 50-CUL1
PARTIAL
RAWMSG N0191D8427D676408B23AFFA89A
RSSI -74.5
STATE Initialized
StackLevel 1
TYPE STACKABLE_CC
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21

Readings:
ccconf freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB 2018-03-19 09:05:24
cmds b C F i A Z N E G M K L U Y R T V W X f z 2018-03-19 09:05:29
credit10ms 3496 2018-03-19 09:05:32
fhtbuf AE 2018-03-19 09:05:35
raw ? ( is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z 2018-03-17 21:18:53
state Initialized 2018-03-19 09:05:42
uptime No answer 2018-03-19 09:05:45
version V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz) 2018-03-19 09:05:45

Die Firmware habe ich selbst kompiliert, da ich das die Konfiguration der Pins angepasst habe und die LaCross Unterstützung aktiviert habe.
Meine Änderungen könnt ihr hier sehen:
https://github.com/DJNoXD/a-culfw/commits/master (https://github.com/DJNoXD/a-culfw/commits/master)


Wie kann ich herausbekommen, woher der Fehler kommt?
Ist mein Module evtl. defekt?

Vielen Dank für eure Hilfe.
Randolf
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 19 März 2018, 13:52:14
Hi,
Probiere mal ein Werksreset
set CUL0 raw e
Ist dann der CUL1 wieder auf 433?
Ich schätze irgendwie wird der resetet.

Du könntest entweder in Deiner Firmware beim init die Freq/Mode setzen oder Du machst ein regelmäßiges get CUL1 config und setzt dann mit DoIf/ Notify die Werte...

Gruß Arnd
 


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 19 März 2018, 21:37:32
Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.
Nach meiner Recherche handelt es sich um ein echtes 86MHz Modul. (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649))
Mein Problem ist, dass der neue CC mit 433 MHz erkannt wird.
Der Cube kann gar nicht erkennen, ob ein 433MHz oder ein 868MHz Modul angeschlossen ist. Für den zweiten Port ist 433 der Standardwert, der nach einem Reset des Dataflash geladen wird.

Nimm einfach den CUL0 für SlowRF und CUL1 für MAX. Der MAX Mode stellt automatisch die richtige Frequenz ein, unabhängig von Standardwert.
Titel: Antw:culfw@ARM
Beitrag von: DJNoXD am 19 März 2018, 22:44:05
Danke für eure Hilfe.

Ich habe die Reihenfolge geändert.
CUL0 = SlowRF
CUL1 = MAX

Ich melde mich wieder, sobald ich etwas sagen kann.
Titel: Antw:culfw@ARM
Beitrag von: DJNoXD am 20 März 2018, 09:29:37
Aktuell sieht es gut aus.
Beide CULs können senden und empfangen.

Danke :-)


Evtl. habt ihr noch einen weiteren Tipp für mich.
Aktuell habe ich einen CUBe mit der eq3 Firmware laufen und einen CUBe als CUL.
Ein Thermostat habe ich mit dem CUL gepaired und kann es steuern.
Seltsam ist (für mich) das folgende Verhalten:
Ich setzte den gewünschten Temperatur Wert auf z.B. 21°C.
Der Wert wird erfolgreich an das Thermostat übertragen (durch ablesen am Thermostat überprüft).
Nach einer bestimmten Zeit wird der Wert, ohne das ich etwas gemacht habe, auf ON gesetzt.

Was könnte der Grund hierfür sein?
Liegt das evtl. am Dual-Betrieb?
Titel: Antw:culfw@ARM
Beitrag von: daredevil.2k am 21 März 2018, 08:54:43
Hallo!

Ich habe meinen Cube entsprechend der Anleitung geflashed (aktuell auf dem Stand 1.26.02 Build 276) und habe für ein paar Tage erfolgreich damit arbeiten können. Nun ist der Cube nach einiger Zeit nicht mehr erreichbar und verliert seine Konfigurationsparameter für IP, Netzmask, Gateway usw. Hat jemand selbiges beobachtet oder eine Idee, was da vor sich geht?
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 16 April 2018, 00:29:55
Hallo daredevil.2k

Bisher habe ich die kompilierte Firmware von mediafire.com (by Bjoern Hempel) benutzt.

Mein Cube mit V1.21.00a war alle paar Monate mal nicht erreichbar. Es war immer etwas schwierg ihn wieder an LAN zu bekommen. Einfach die Spannungsversorung aus/an hat oft nicht gereicht. Mehrfaches wiederholen oder auch mal LAN ziehen brachte irgendwann den Erfolg.

Hatte dann letzte Woche die Idee auf V1.26.02abuild_276 zu gehen und hoffte auf Besserung. Das war irgendwie instabil. Inbesondere nach SET/GET Kommandos konnte ich keine IT Geräte mehr schalten. Das lief erst nach set <Cube-device> reopen wieder.

Bin daher ohne weitere Untersuchung auf die V1.24.02a_build_209. Das lief zufriedenstellend.

Habe nun meinen Cube mit einem weiteren Sender ausgestattet. Musste daher wieder auf V1.26.02abuild_276 CUBEx4_BL.bin

Die Einrichtung soweit abgeschlossen. Morgen gehe ich produktiv und werde mal zum LAN Thema berichten.
Siehe auch nächter Beitrag
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 16 April 2018, 01:13:52
Hallo in die Runde

Setze den Cube ein um abgsetzt per LAN noch Intertechno Steckdosen erreichen zu können. Nun brauchte ich die Erweiterung um noch ein HM Device abgesetzt zu erreichen.

Ich habe meinen Cube daher um einen 433MHZ CC1100 erweitert. Danke also schon mal an Euch für die tolle Arbeit, dass das möglich ist.
Als letzte Sichterheit zum "Löten" war der Hinweis #915 von toxic-tonic für die Zuordnung der In-/Out-Pins CC110 - Cube super wichtig.
https://forum.fhem.de/index.php/topic,38404.msg757526.html#msg757526 (https://forum.fhem.de/index.php/topic,38404.msg757526.html#msg757526)
CC1100 - Cube (mit board.h Patch)
GND    - GND
VCC    - VCC
GDO0   - PB25
CSN    - PA6
SCK    - SCK
MOSI   - MOSI
MISO   - MISO
GDO2   - PA5

Ich habe um die kompilierte FW verwenden zu können mit den Originalzuordnungen gearbeitet, also PB28 auf GD00.

Daher ein Vorschlag zum leichten Nachbau hinsichtlich der Zuordnung:
- wie in der Original FW in der board.h für die Out-/ In-Pins einen Kommentar auf GD00 (=PB28) und GD02 (=PA5) einfügen
- die anderen PINs sind ja durch ihre Bezeichnung bzw. das Foto klar (Antwort #823)

Abschließen noch eine Frage. Hat es eine "Beudeutung", dass die kompilierte FW vom mediafire.com Build 276
a-culfw_1.26.02_build_276.zip heisst
aber die Versionsabfrage liefert Build 275:
- 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) CUBEx4_83 (F-Band: 868MHz) oder
- 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) CUBEx4_83 (F-Band: 433MHz)

Gruß Ralf
Titel: Antw:culfw@ARM
Beitrag von: phantom am 16 April 2018, 15:21:13
Hi,
ich habe meinen MAX!Cube mit einem 1-Wire Transceiver DS2482S-100 erweitert. Den kann man per I2C direkt am CUBe anschließen (TWI/TWCK).
Um den 1-wire Bus via OWX anzusprechen musste ich noch einen kleinen Patch in 00_OWX.pm einfügen.

in Zeile 193 der aktuellen Version 16437 von  pah  https://forum.fhem.de/index.php/topic,85924.msg783211.html#msg783211 (https://forum.fhem.de/index.php/topic,85924.msg783211.html#msg783211)  ist noch zusätzlich CUBE als weiteres zulässiges Device eingetragen:
}elsif( $defs{$dev} && $defs{$dev}->{VERSION}  && $defs{$dev}->{VERSION} =~ m/CSM|CUNO|CUBE|MapleCUN...(4|5|6|7|C|D|E|F)/ ){
Man könnte auch CUBEx4 eintragen, da dies ohnehin nur bei einem erweiterten CUBe relevant ist (hier mein aktueller Version-String dazu):
VERSION      V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_C3 (F-Band: 868MHz)

Evtl. könnte dies jemand kurz prüfen.
Unklar ist mir noch was dazu in den Folgemodulen wie 11_OWX_CCC etc. zu ändern ist ...

Gruß Phantom
Titel: Antw:culfw@ARM
Beitrag von: phantom am 17 April 2018, 22:08:54
Hi,  zur Info

das o.g. Problem mit dem 1-Wire DS2482 am MAX!CUBe konnte in diesen Thread gelöst werden:
https://forum.fhem.de/index.php/topic,78693.msg794897.html#msg794897 (https://forum.fhem.de/index.php/topic,78693.msg794897.html#msg794897)  ff.

Gruß Phantom
Titel: Antw:culfw@ARM
Beitrag von: RalfRog am 21 April 2018, 18:20:39
Hallo daredevil.2k

Hallo daredevil.2k
.....
Die Einrichtung soweit abgeschlossen. Morgen gehe ich produktiv und werde mal zum LAN Thema berichten.
......

Habe in einer knappen Woche keine Probleme. Der Cube verliert seine Konfiguration nicht und war immer erreichbar.
Habe auch das merkwürdige Verhalten wie mit der "CUBE_BL.bin" nach set <device> version/uptime/cconfig nicht mehr.
Entweder liegt's daran, dass es ein anderer MAXCube ist oder die "CUBE_BL.bin" "CUBEx4_BL.bin" unterscheiden sich da.
Werde mal mit dem alten Cune ein wenig spielen.
Titel: Antw:culfw@ARM
Beitrag von: nussknacker4711 am 24 April 2018, 16:44:52
Hallo zusammen,

mein erstes Post in diesem Forum. Das Wichtigste zuerst: Einen großen Dank für diese phantastische Stück Software!

Mittlerweile habe ich drei Cubes (auf jeder Etage einer) und steuere meine alten FS20-Module. Einen Cube habe ich um einen zweiten Transmitter für MAX erweitert, klappt auch.

Nun möchte ich einen Cube an einen Raspberry zur Stromversorgung anschließen anstatt über das separate Netzteil (Dieser Raspi ist nicht der FHEM-Raspi).

Es leuchet die Battery-LED. Heißt das, dass die USB-Verbindung wird erkannt oder heißt das, dass da nicht genug Strom kommt "schwache Batterie"?

Senden/Empfangen klappt soweit - und dann Bumm: Alle LED gehen kurz aus, FHEM loggt "disconnected, waiting to reappear" und dann kommt der Cube wieder. Mit dem Netztteil passiert das nicht, da klappt alles.

Kann ich die USB-Schnittstelle irgendwie lahmlegen und nur als Stromversorgung verwenden? (Ich hatte schon die Idee, dass da etwas in der Ausgabe steht, aber von dem Raspi nicht abgeholt wird)

Beste Grüße

Michael




Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 24 April 2018, 18:40:31
Hi Nussknacker,
1) der erste Post ist am schwersten ;-)
2) dabei machen die meisten Fehler
3) Du auch: Offtopic!
Daher mach doch bitte einen neuen Thread unter Anfängerfragen auf!
Warum?
1) Dein Thema ist ein Cube/Raspi frage, die bei näherem Hinsehen eine einfache Stromversorgungsfrage ist. Dafür haben wir keinen extra Forenbereich ;-)
2) Es gibt USB Kabel, die keine Daten, sondern nur Ladekabel sind. (Z.B. typischerweise dicke Kabel bei Powerbanks) oder Du schneidest von den vier Pins die mittleren beiden raus bzw. trennst deren Drähte an einem Stecker. (Vgl. z.B. https://www.androidpit.de/forum/552408/samsung-galaxy-note-10-1-geloest-pinbelegung-ladekabel)
3) Falls Dein Cube dennoch beim senden zu viel Strom braucht, bleiben aus meiner Sicht folgende Lösungen:
a) Raspberry /boot/config.txt  Parameter max_usb_current=1 für USB Stromversorgung setzen,
b) einen dicken Pufferelko in der Nähe des Cube zwischen die beiden verbleibenden USB Einzaladern hängen
c) Alternative Stromzufuhr mit Relais am RaspiGPIOs steuern,
d) ... (darum neuen Thread bitte!)

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 24 April 2018, 19:25:22
Ich hatte auch immer Stabilitätsprobleme wenn ich den CUBE per USB an einem Raspi oder an einer Fritzbox zu betreiben versucht habe.

Evtl. reichen die max. 500mA am USB Port nicht aus. Gibt es qualifizierte Erkenntnisse bzgl. der Leistungsaufnahme?
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 28 April 2018, 19:45:37
Senden/Empfangen klappt soweit - und dann Bumm: Alle LED gehen kurz aus, FHEM loggt "disconnected, waiting to reappear" und dann kommt der Cube wieder. Mit dem Netztteil passiert das nicht, da klappt alles.
In die Falle bin ich auch getappt ... siehe https://forum.fhem.de/index.php/topic,38404.msg754806.html#msg754806 und die Antwort von Telekatz. ( Antwort 908 &  909) 
Lösung : USB Kabel "dumm" machen , d.h die beiden Datenleitungen kappen so das nur noch VCC und GND übrig bleiben.
Titel: Antw:culfw@ARM
Beitrag von: Hallmackenreuther am 10 Juni 2018, 22:43:07
Hallöle!

Mein Ziel, TX29-IT Sensoren mit einem MAX!Cube mitzulesen, scheint noch nicht auf Sichtweite. Aktueller Stand nach Einlesen an diversen Stellen:
Zitat
Als root im root-Verzeichnis:
mkdir a-culfw
cd a-culfw
wget https://github.com/heliflieger/a-culfw/archive/master.zip
unzip master.zip
cd ~/a-culfw/a-culfw-master/culfw/Devices/CUBe
nano board.h
#define LACROSSE_HMS_EMU unter #define HAS_RFNATIVE eingefügt, dafür #define HAS_SOMFY_RTS und #define HAS_MAICO mit // auskommentiert, um ggf. Platzprobleme zu vermeiden.
make

Das wurde am Ende so quittiert:
Zitat
../../clib/rf_native.o: In function `native_task':
/root/a-culfw/a-culfw-master/culfw/Devices/CUBe/../../clib/rf_native.c:239: undefined reference to `dec2hms_lacrosse'
collect2: error: ld returned 1 exit status
Makefile:125: die Regel für Ziel „CUBE_BL.elf“ scheiterte
make[1]: *** [CUBE_BL.elf] Fehler 1
make[1]: Verzeichnis „/root/a-culfw/a-culfw-master/culfw/Devices/CUBe“ wird verlassen
Makefile:97: die Regel für Ziel „CUBE_BL“ scheiterte
make: *** [CUBE_BL] Fehler 2

In Zeile (96) 97 in der Makefile steht
CUBE_BL:
        make OUTPUT=CUBE_BL LINK=CUBE_BL target

Zeile 125:
        $(LD)  -L$(LIBPATH) $(OPTFLAGS) -o $@  $^ $(LIBS) $(LDFLAGS)

Ich habe auch in anderen Versuchen https://forum.fhem.de/index.php/topic,36565.msg345912.html#msg345912 soweit mir verständlich beachtet, aber ich weiß nicht wo genau im Makefile ich den angegebenen Code einfügen müsste und mangels CUL.c im CUBe-Ordner gehe ich davon aus, dass die main.c das Äqivalent ist, in dem sich die beschriebenen Einträge aber alle schon befinden.

Mit vorkompiliertern .bins empfange ich die "Unknown code" Nachrichten fleißig, aber es gibt eben kein Autocreate - zur Not würde es mir auch reichen, die Sensoren manuell einzubinden, aber dazu habe ich bisher erst recht nichts gefunden.
Titel: Antw:culfw@ARM
Beitrag von: Hallmackenreuther am 16 Juni 2018, 15:26:30
Okay, ich habe mit Hilfe eines alten Pinguin-Haudegen herausgefunden, dass das, was nach meiner Lesart in die Makefile gemusst hätte, wohl in die Make.conf ging... seuuuufz.

Damit anderen MAX!Cube-Nutzern mein Leid erspart wird, hier eine CUBE_BL.bin mit LaCrosse, erfolgreich getestet mit fünf TX29-IT
V 1.26.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Titel: Antw:culfw@ARM
Beitrag von: hulzer am 03 Juli 2018, 23:24:32
Damit anderen MAX!Cube-Nutzern mein Leid erspart wird, hier eine CUBE_BL.bin mit LaCrosse, erfolgreich getestet mit fünf TX29-IT
Hallo,
verstehe ich es richtig, für MAX! und LaCrosse benötigt man zwei Cubes?
Danke.
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 04 Juli 2018, 19:53:36
Nö,
Man benötigt mindestens zwei CC1101.
Das geht mit zwei cubes im Original (Hardware) Zustand oder mit einem Cube mit zweitem eingelötetem CC1101  https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html?m=1 (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html?m=1)oder mit zwei NanoCULs oder ...
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: hulzer am 04 Juli 2018, 20:57:31
Danke für die Info.
Der Lötkolben glüht schon...
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 29 September 2018, 14:54:35
Damit anderen MAX!Cube-Nutzern mein Leid erspart wird, hier eine CUBE_BL.bin mit LaCrosse
das ist nett von dir behandelt aber leider das Symptom statt der Ursache ....
@Telekatz : bitte in die Make.conf noch mit aufnehmen (bzw. aufnehmen lassen) :
SRCS += ../../clib/lacrosse.c
Titel: Antw:culfw@ARM
Beitrag von: Mihca am 03 Oktober 2018, 16:29:06
Also erst mal ein großes Danke an alle, die daran mitgearbeitet haben, insbesondere an Telekatz.

Ich habe einen MOBILCOM-DEBITEL MAX! Cube erfolgreich mit V 1.26.03 a-culfw Build: 300 geflasht, über Netzwerk (define CUL_1 CUL 192.168.0.94:2323 0000) eingebunden und auf WMBUS-T eingestellt, um einen Stromzähler (EnergyCam) auszulesen. Das funktioniert auch im Prinzip prima. Allerdings setzt sich der MAX! nach einiger Zeit auf ein erneutes "state: initialized" in den Readings. Im log sieht man nicht, dass er neu initialized wurde, sondern nur im Reading des Devices. Danach empfängt er keine Signale mehr. Nach einem restart von fhem funktioniert es dann wieder.

Auch wenn man die Stromzufuhr des MAX! aus- und einschaltet, schaltet er nicht auf WMBUS-T um. Dann steht im log folgendes:

2018.10.02 18:36:43 3: CUL_1: Possible commands: BbCFiAZNEkGMKLUYRTVWXOefhltxz
2018.10.02 18:36:43 2: Setting CUL_1 fhtid from TMODE to 0000
2018.10.02 18:36:43 1: 192.168.0.94:2323 reappeared (CUL_1)
2018.10.02 18:37:14 3: CUL_1: Unknown code 0000, help me!

Wenn man im Falle, dass er nichts empfängt "get ccconf" ausführt, kommt als Antwort "empty" während im Reading noch die richtigen Werte "freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB" stehen. Wenn er empfängt gibt "get ccconf" auch die richtigen Paramter aus.

Ich habe den Eindruck, dass der MAX! nach einem "initialized" und Unterbrechung der Spannungsversorgung vergisst, das WMBUS-T-Protokoll wieder einzustellen.



Hat da jemand eine Lösung?

Vielen Dank Vorab
Achim
Titel: Antw:culfw@ARM
Beitrag von: berndEEE am 05 Oktober 2018, 12:42:22
Hi Zusammen,

erstmal Danke für die Arbeit die Ihr hier reingesteckt habt.
Meinen Cube habe ich anhand der Anleitung geflasht (a-culfw_1.26.04_build_307), da er immer wieder alles vergessen hat.
Insofern habe ich große Hoffnung, dass vieles Dank Eurer Arbeit besser läuft.

Nun zum aktuellen Problem:
leider bekomme ich keine Geräte (Max Thermostat + Fensterkontakt) angebunden.

Was ich getan habe:
- Flashen auf a-culfw_1.26.04_build_307
- MaxCube ist auch Netzwerk sichtbar
- fhem update
- in Fhem über die GUI:
define maxcul CUL <IP>:2323 0000
attr maxcul rfmode MAX
define cm CUL_MAX 123456
set cm pairmode 45

Dann am Max-Fensterkontakt (vorher Reset, Batterien raus) den Knopf gedrückt.

Nix passiert.
Das LogFile schweigt sich aus.

Habt Ihr Ideen, woran das liegen könnte?
Was kann ich ggf. noch testen oder probieren?

Danke sehr.
Bernd
===

internals
CMDS: BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
STATE: Initialized
TYPE: CUL
VERSION:
V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
initString:
X21
Zr
Za123456
Zw111111

Readings
cmds: B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
state: Initialized
   
====
Infos vom cm (nach Drücken der Taste am Fensterkontakt)

maxcul_MSGCNT: 1
maxcul_RAWMSG: Z1700000008B07A0000000014040F4B455130363539343536
maxcul_RSSI: -58

und beim max_cul:

RAWMSG: Z1700000008B07A0000000014040F4B45513036353934353620
RSSI: -58


Nochmaliges Drücken am Fensterkontakt zeigt kein Änderung mehr.
Titel: culfw@ARM
Beitrag von: RaspiLED am 05 Oktober 2018, 14:58:10
Hi,
Das sieht doch schon ganz gut aus,
Mach mal ein
attr max_cul verbose 5
Und schau im Eventmonitor/Log was da tatsächlich passiert beim drücken.

Evtl ist der Fensterkontakt zu nah? 5m Abstand?

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: pc1246 am 05 Oktober 2018, 16:14:08
Moin
Und gib uns mal ein list cm, und bitte in codetags (ueber den smilies der "#")!
Und von Arnd muesste es heissen attr cm verbose 5!
Gruss Christoph
Titel: Antw:culfw@ARM
Beitrag von: pejonp am 05 Oktober 2018, 16:22:23
Ich würde dem patiniert auf 120 oder 240 stellen. Je nachdem was im 868 band los ist dauert es eine weile.
Falls die Geräte schon einmal angelernt waren erst ein reset machen .
set cm pairmode 120 oder 240

Schau mal in die Doku ob 0000 als id geht. Ich trage dort z.B. 3453 ein.

CUL_1 CUL 192.168.0.94:2323 3453
.
Pejonp
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 05 Oktober 2018, 16:47:22
Schau mal in die Doku ob 0000 als id geht. Ich trage dort z.B. 3453 ein.
np, ich nutze seit Jahren auch die 0000 - IMHO viel wichtiger wäre : was steht im FHEM Log und ist autocreate an ?
Titel: Antw:culfw@ARM
Beitrag von: berndEEE am 05 Oktober 2018, 16:50:06
Danke sehr an Alle.

verbose gesetzt, autocreate ist an, 0000 durch 1234 ersetzt. :-)


Dann folgende Erkenntnisse - welche mich etwas verwirren :-(

nach dem Restart von fhem UND des MaxCubes konnte ich einmalig kurz pairen.
Dann habe ich versucht den Thermostat zu pairen.
Ging erst nicht.

Dann - nach einigen Minuten fhem restarted und direkt kam die PairMsg an.

Ca. alle 30 Sekunden kommt im Log:
2018.10.05 16:32:16 4: CUL_Parse: maxcul V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
2018.10.05 16:32:46 5: CUL/RAW: /V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)

Vermute mal um die Connection offen zu halten.
Das hört dann nach etlichen Minuten (ca. 1h, mal nur 5min) auf. Keine der o.g. Logmeldungen mehr.

Nun versuchte ich noch ein Pairing:
Fensterkontakt reset, set cm pairmode 240, Batterien rein - nix etliche Minuten lang - außer o.g. Meldung.

Dann FHEM mal restarted. Wieder nix. Und nur einmalig die o.g. Meldung.
Dann mal set maxcul reopen - und siehe da - die PairMsg von vor etlichen Minuten war da - und Gerät angelegt.
Hier und da kommt im Log auch mal nach dem Pairing:
Device MAX_0da8ea answered with: Invalid command/argument

Dann wollte ich den Fensterkontakt und das Thermostat verlinken:
2018.10.05 16:47:08 5: CUL_MAX_SendQueueHandler: 1 items in queue
2018.10.05 16:47:08 2: There is a packet for ShutterContact MAX_054cae in queue. Please trigger a window action (open or close the window) to wake up the respective ShutterContact and let it receive the packet.
...
(da kommt nun schon sehr lange - obwohl mehrfach Fenster auf/zu)


Hab das Gefühl der Cube ist immer mal weg - zumindest nicht übers Netz erreichbar bzw. nicht reagiert.

Sollte ich ggf. mal einen älteren Build der a-culfw flashen? Empfehlung willkommen.

Blöde Frage: kann ich den auch via USB an Raspi anschließen? (Sorry - mit CUL & Co hatte ich noch nix zu tun) :-)


Danke schön.
Bernd
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 05 Oktober 2018, 19:16:30
(da kommt nun schon sehr lange - obwohl mehrfach Fenster auf/zu)
Typischer Anfängerfehler, Wiki lesen  und MAX! Forum hier lesen hätte geholfen...
Mit Knopf drücken ist der Anlernknopf gemeint , nur Fenster auf/zu nützt da nix.
Titel: Antw:culfw@ARM
Beitrag von: berndEEE am 05 Oktober 2018, 19:55:49
Naja. Den Anlernknopf kenn ich schon :-)
Habe es ja ständig angelernt.

Das mit Fenster auf/zu bezog sicht auf die Logmeldung:
There is a packet for ShutterContact MAX_054cae in queue. Please trigger a window action (open or close the window) to wake up the respective ShutterContact and let it receive the packet.

Und die kommt noch immer.
Titel: Antw:culfw@ARM
Beitrag von: berndEEE am 06 Oktober 2018, 12:13:55
Hi Zusammen,

ich glaube ich hab das Problem eingegrenzt: Netzwerk - entweder mein "Infrastruktur" oder ein Problem am Cube mit dem Netzwerk.

Habe den Cube via USB angeklemmt.
Und siehe da -> Pairing, Verknüpfung von Fensterkontakt zum Thermostat - alles direkt beim ersten Versuch ok.

Werde es mal weiterbeoachten.

Auf jeden Fall nochmal Danke an Alle!!

Bernd
Titel: Antw:culfw@ARM
Beitrag von: Mihca am 07 Oktober 2018, 16:23:24
Hallo zusammen,
ich komme noch einmal auf mein in Antwort 942 beschriebenes WMBUS-Problem zurück. Ich habe inzwischen versucht den Cube über USB anzubinden. Das Ergebnis ist dasselbe. Nach einiger Zeit empfängt er keine Daten mehr. Ich nutze nun wieder ein Busware CUL über USB für den WMBUS. Das funktioniert einwandfrei. Ich hatte dieses USB CUL auch schon über einen Raspberry per ser2net über LAN eingebunden. Das funktionierte auch. Aber das leidige Thema SD-Karten-Defekt macht diese Lösung wenig betriebssicher, so dass ich das wieder eingestellt habe. Ich dachte der Cube wäre da die Lösung.

Ich nutze den Cube über LAN nun für FS20 und CUL_EM. Das funktioniert auch nach einigen Tagen immer noch perfekt.

Es wäre natürlich prima, wenn auch WMBUS richtig funktionieren würde.

Viele Grüße
Achim
Titel: Antw:culfw@ARM
Beitrag von: Andreas29 am 19 Oktober 2018, 07:00:55
Guten Morgen,

kann man einen geflashten MAX!Cube auch ohne FHEM dazu bringen sich mit anderen MAX!-Komponenten zu pairen?
Wenn ja, wie?

Danke und Grüße

Andreas
Titel: Antw:culfw@ARM
Beitrag von: Andreas29 am 20 Oktober 2018, 16:08:25
Hi,

ich habe jetzt einen älteren Cube lt. Anleitung geflasht. Hat soweit funktioniert, allerdings musste ich „at91sam7x512-ek“ auswählen, damit es funktionierte.
Aber Bootloader und CUBE_BL.bin konnten ansonsten wie in der Anleitung beschrieben aufgespielt werden.
Der Cube startet und D1 blinkt im Sekundentakt, bei Netzwerkverbindung leuchtet auch D2 dauerhaft.

Ich habe nun mit putty eine Telnetverbindung zu der IP-Adresse des Cubes (von mir im router festgelegt) geöffnet (Port2323).
Soweit so gut.
Es erscheint wiederkehrend folgende Anzeige: V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)

Aber wenn ich in putty z.B. V eingebe und dann die Entertaste drücke dann kommt: ? ( is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
Egal welche der Befehle ich übermittle es kommt immer diese Meldung.

Gleiches Spiel in TeraTerm, dort habe ich es auch schon versucht.

Über einen COM-Port habe ich keine Verbindung zustande bekommen (aber ich habe auch noch keinen virtuellen COM-Treiber).

Irgendwie bekomme ich derzeit noch keine Befehle an den Cube übermittelt. Ich gehe davon aus dass die command.ref der culf.w auch hier Gültigkeit hat?

Tipps?

Danke und Grüße

Andreas




 
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 20 Oktober 2018, 16:33:46
Hi,
Eigentlich machst Du alles richtig und auf V sollte die Version angezeigt werden und bei ? Halt der Commands Text.
Wenn aber die Firmware nicht ganz geflasht wurde, kann es auch zu solchen Fehlern kommen. Nachdem Motto: Ich weiss meine Standardantwort, aber den Befehl V habe ich noch nicht gelernt.
Evtl. Hast Du aber auch die Return Taste falsch belegt (Windows: CR und LF, statt Linux: nur LF, oder Mac
Classic: nur CR)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: Andreas29 am 20 Oktober 2018, 16:44:39
Hi,

ich habe gerade noch den Telnet-Client von Windoof installiert. Nun klappts. Befehle werden erkannt und geben entsprechende Rückmeldungen  :)

Mit dem richtigen Programm klappts  ::)

Danke soweit.

Noch eine Frage: Wie schalte ich den geflashten Cube in den MAX-Modus? Oder ist er automatisch in eben diesem?

Danke und Grüße

Andreas
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 20 Oktober 2018, 17:16:39
attr CubeCUL rfmode MAX

https://wiki.fhem.de/wiki/Rfmode



Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: Andreas29 am 21 Oktober 2018, 17:35:31
Hi,

danke. Mißverständnis, ich meinte den Cube ohne fhem also direkt aus einem Terminalprogramm in den piaringmodus versetzten. Gibt´s da einen Befehl oder Tastenfolge für?

Danke und Grüße

Andreas
Titel: Antw:culfw@ARM
Beitrag von: pc1246 am 22 Oktober 2018, 07:51:13
Hi,

danke. Mißverständnis, ich meinte den Cube ohne fhem also direkt aus einem Terminalprogramm in den piaringmodus versetzten. Gibt´s da einen Befehl oder Tastenfolge für?

Danke und Grüße

Andreas
Moin
Da wirst Du Dich wohl ein wenig in den CUL einlesen muessen. Grundsaetzlich habe ich es so verstanden, dass die RAW-Befehle das Equivalent zu Deinen Eingaben im Terminal sind. Wie Du allerdings ein "Set" implementierst hat sich mir auf die Schnelle nicht erschlossen! Vielleicht solltest Du hier im CUL Bereich noch etwas stoebern, und einen neuen Thread aufmachen!
Gruss Christoph
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 22 Oktober 2018, 07:53:14
Hi,
Ist es nicht einfacher ein temporäres FHEM zu nutzen (vielleicht mittels ser2net auf einem entfernten Rechner)!?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Beta-User am 22 Oktober 2018, 10:17:55
Der Initialisierungs-Code für den MAX-mode sollte außer in der cr der culfw auch im CULMAX-Modul stehen (wenn es ums Mithören geht).
Titel: Antw:culfw@ARM
Beitrag von: Andreas29 am 24 Oktober 2018, 07:51:49
Hi,

meine Frage hat sich erledigt, das Problem lag an der Auswertung der Funktelegramme.

Danke und Grüße

Andreas
Titel: Antw:culfw@ARM
Beitrag von: EinfachFhem am 28 Oktober 2018, 20:38:25
Hallo Zusammen,

Erst einmal Danke an Telekatz und allen andere für Ihre Arbeit / Beiträge hier.

Habe heute Morgen meinen Max Würfel (TRX868) nach der Anleitung von Seite 1 neu geflasht.
Der Grund war das wiederholte vergessen der Einstellungen.
Nach dem flashen will ich weiterhin meine MAX Geräte damit betreiben.
Dies hat auch direkt funktioniert. Habe Ihn dann in FHEM, das auf einem Raspi Pi3 läuft, als neue Device gesehen.
Wie ich dann ebenfalls hier nachgelesen haben auch die Möglichkeit gefunden wie ich meine Geräte anlerne.

Hier meine Einstellungen aus der FHEM.cfg:
define MAXLAN CUL /dev/ttyACM0@9600 3453
attr MAXLAN alias MAX Würfel
attr MAXLAN group MaxLan
attr MAXLAN icon cul
attr MAXLAN model CUL
attr MAXLAN rfmode MAX
attr MAXLAN room Root
attr MAXLAN verbose 5
So und jetzt zu meinem Problem:
Ich kann alle meine Geräte (Wandthermostat, Heizungsthermostat und Fensterkontakte) anlernen und miteinander verknüpfen.
Alles funktioniert auch, aber nur bis zur Restart von FHEM.
Restart aus der Fhem heraus, von Terminal des Raspi heraus hat immer das gleiche Ergebnis.
Alles weg, der Würfel vergisst erneut alles.
Habe Ihn schon per USB, LAN, USB und LAN verbunden, alles mit gleichem Effekt.

Habe hier noch alle Seiten durchgelesen und scheine mit meinem Problem der einzige zu sein >:(.

Bin jetzt auch mit meinem Latein am Ende und hoffe auf neue Ideen.

Danke und noch einen schönen Abend  :)
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 28 Oktober 2018, 21:27:46
Hi,
Du hast wahrscheinlich eine falsche Reihenfolge der Geräte in Deiner Config.
Erst alle Geräte und dann erst den Max als CUL wäre mein Tipp.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: pc1246 am 29 Oktober 2018, 08:25:30
Hallo Zusammen,

Erst einmal Danke an Telekatz und allen andere für Ihre Arbeit / Beiträge hier.

Habe heute Morgen meinen Max Würfel (TRX868) nach der Anleitung von Seite 1 neu geflasht.
Der Grund war das wiederholte vergessen der Einstellungen.
Nach dem flashen will ich weiterhin meine MAX Geräte damit betreiben.
Dies hat auch direkt funktioniert. Habe Ihn dann in FHEM, das auf einem Raspi Pi3 läuft, als neue Device gesehen.
Wie ich dann ebenfalls hier nachgelesen haben auch die Möglichkeit gefunden wie ich meine Geräte anlerne.

Hier meine Einstellungen aus der FHEM.cfg:
define MAXLAN CUL /dev/ttyACM0@9600 3453
attr MAXLAN alias MAX Würfel
attr MAXLAN group MaxLan
attr MAXLAN icon cul
attr MAXLAN model CUL
attr MAXLAN rfmode MAX
attr MAXLAN room Root
attr MAXLAN verbose 5

So und jetzt zu meinem Problem:
Ich kann alle meine Geräte (Wandthermostat, Heizungsthermostat und Fensterkontakte) anlernen und miteinander verknüpfen.
Alles funktioniert auch, aber nur bis zur Restart von FHEM.
Restart aus der Fhem heraus, von Terminal des Raspi heraus hat immer das gleiche Ergebnis.
Alles weg, der Würfel vergisst erneut alles.
Habe Ihn schon per USB, LAN, USB und LAN verbunden, alles mit gleichem Effekt.

Habe hier noch alle Seiten durchgelesen und scheine mit meinem Problem der einzige zu sein >:(.

Bin jetzt auch mit meinem Latein am Ende und hoffe auf neue Ideen.

Danke und noch einen schönen Abend  :)
Moin
Anstelle Ausschnitte Deiner cfg zu posten, die nebenbei auch in Codetags gehoeren, solltest du lieber mal ein "list MAXLAN" eingeben, und das Ergebnis in Codetags posten!
Dann habe ich noch weitere Fragen:
-Ein save hast du gemacht?
-Wie waren Deine anderen Definitionen?
Der "Wuerfel" kann nichts mehr vergessen, da jetzt fhem das Gedaechtnis ist!
Gruss Christoph
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 29 Oktober 2018, 09:27:58
Der "Wuerfel" kann nichts mehr vergessen, da jetzt fhem das Gedaechtnis ist!
Das ist richtig, aber FHEM schon wenn beim Start die MAX! Geräte kein gültiges IO Device haben.
Ich tippe daher in die gleiche Richtung wie RaspiLED : Die MAX! Geräte stehen schon länger in der config und der "neue" Cube bzw das CUL_MAX Device jetzt darunter. War bei mir damals bei meinem Wechsel von MAXLAN auf CUL_MAX auch so. Und genau das ist so einer der wirklich wenigen Fälle wo Handarbeit in der fhem.cfg angesagt ist um den neuen define Abschnitt möglichst weit nach oben zu bringen.
Andere harte Alternative wäre alle MAX Geräte zu löschen und nach und nach neu anlegen um damit sicher zustellen das sie in der config nach dem CUBE & CUL_MAX stehen. 
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 29 Oktober 2018, 12:19:39
Oder dblog ;-) Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: EinfachFhem am 29 Oktober 2018, 12:32:14
Danke allen erst mal für ihre Hilfe.
Werden nach der Arbeit die Vorschläge umsetzten und berichten.

Fhem.cfg alt: Definition Max vor den Geräte definitionen (Diese sind in einer separaten CFG aufgeführt).
Fhem.cfg aktuell: Definition Max nach den Geräte definitionen.

Vor dem Reboot immer ein save.
Nach dem Reboot oder speichern der fhem.cfg auf der Fhem Web - Oberfläche sind alle IO Daten weg.
Im Anhang bzw.als die LIST MAXLAN vor und nach den Rebooten.
Vor dem Reboot

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 3453
   DeviceName /dev/ttyACM0@9600
   FD         15
   FHTID      3453
   MAXLAN_MSGCNT 3
   MAXLAN_TIME 2018-10-29 16:57:06
   NAME       MAXLAN
   NR         89
   NR_CMD_LAST_H 3
   PARTIAL   
   RAWMSG     Z0E3B0202033BC8654321000118002829
   RSSI       -53.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za654321
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-10-28 18:09:02   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-10-29 16:53:22   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2018-10-29 16:57:05   credit10ms      1942
     2018-10-28 18:09:18   fhtbuf          AE
     2018-10-28 19:56:46   raw             No answer
     2018-10-29 16:57:06   state           Initialized
     2018-10-28 18:09:26   uptime          0 00:09:34
     2018-10-28 18:09:31   version         V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1540828402.69049
     1540828402.99128
     1540828625.12838
Attributes:
   alias      MAX Würfel
   group      MaxLan
   icon       cul
   model      CUL
   rfmode     MAX
   room       Root
   verbose    1

und nach dem Reboot
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 3453
   DeviceName /dev/ttyACM0@9600
   FD         15
   FHTID      3453
   MAXLAN_MSGCNT 1
   MAXLAN_TIME 2018-10-29 16:47:34
   NAME       MAXLAN
   NR         89
   NR_CMD_LAST_H 2
   PARTIAL   
   RAWMSG     Z0C3A044216BA83031EF70029C910
   RSSI       -66
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za654321
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-10-28 18:09:02   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2018-10-29 16:46:35   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2018-10-29 16:29:00   credit10ms      509
     2018-10-28 18:09:18   fhtbuf          AE
     2018-10-28 19:56:46   raw             No answer
     2018-10-29 16:47:34   state           Initialized
     2018-10-28 18:09:26   uptime          0 00:09:34
     2018-10-28 18:09:31   version         V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1540827995.90671
     1540827996.20754
Attributes:
   alias      MAX Würfel
   group      MaxLan
   icon       cul
   model      CUL
   rfmode     MAX
   room       Root
   verbose    1

Kann selbst leider nicht viel mit den Infos anfangen

Werde jetzt mal bei 0 Anfangen.

Update:
So Lösung durch Zufall gefunden  ;D ;D.
Habe bei o Angefangen und gesehen festgestellt das hier die Änderung ist.
Attributes IODev geändert.

Alt, Bezug auf den Max original Würfel
att Gerät IODev MAXLAN

Neu, Bezug auf den CUL_MAX
att Gerät IODev cmax

Danach Funktioniert alles wie es soll auch nach dem Reboot.
Definition des Würfels ist vor seinen Geräte, dies noch zu Info.

Nochmals Danke :)

Gruß Thorsten
Titel: Antw:culfw@ARM
Beitrag von: VolkerGBenner am 03 November 2018, 23:59:47
Hallo,
Ich habe gerade einen meiner Cubes(alter TRX868) auf CUL (aktuelle Version) geflasht. Es scheint soweit alles geklappt zu haben, zumindest leuchtet die mittlere LED und die POWER LED blinkt. Das soll doch so sein, oder? Leider finde ich im Router keinen Netzwerkeintrag, der mir die IP verrät und ohne kann ich ihn ja nicht definieren.

Woran kann es liegen?
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 04 November 2018, 05:46:33
Hi,
ich vermute weil er nicht auf Netzwerkmodus geht. Hast Du ein Daten-USB-Kabel an dem Cube und versorgst ihn noch mit dem Rechner mit dem Du geflasht hast? Nimm mal ein Standalone Netzteil oder eben ein Power-Only-Kabel.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: VolkerGBenner am 04 November 2018, 13:18:18
Habe unter gefühten 100 Kabel kein einziges ohne die mittleren Kontakte gefunden. Aber auch an einem reinen Steckernetzteil ändert sich nix. Hab ihn jetzt erstmal über USB am Pi angeschlosse, um zu testen, ob er überhaupt sinnvolle Signale von sich gibt.
Es lebt und antwortet schonmalVERSION  V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)Wie bekomme ich ihn jetzt dazu auch über Netzwerk zu funken?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 November 2018, 14:34:23
Stell über USB eine statische IP Adresse ein. Und der Netzwerkmodus funktioniert auch dann, wenn eine USB Verbindung besteht.
Titel: Antw:culfw@ARM
Beitrag von: VolkerGBenner am 04 November 2018, 17:09:46
Aha, er war schon online über Netzwerk, nur hat die doofe FritzBox ihn weder in der Geräteliste noch als aktive Verbindung, sondern nur als Ungenutzte Verbindung gelistet. Nachdem ich über screen die MAC-Adresse und IP ausgelesen habe (völliges Neuland für mich, Aaaaabenteuer) hab ich ihn dann in der FrtizBox gefunden. Nachdem ich die DEF auf IP umgestellt habe, war der FlashCube dann auch in der FriBox ordentlich gelistet.

Aber irgendwie hat mir der kurzzeitige Parallelbetrieb von HM-MOD-UART und FlashCube das HM-Setup durcheinander gewürfelt. Hab auf einmal ein unbekanntes HM-Device in der Übersicht.
aber das ist hier wohl oftopic.

Danke auf jeden Fall für die Hilfe.
Titel: Antw:culfw@ARM
Beitrag von: VolkerGBenner am 09 November 2018, 17:42:18
SO,
nachdem sich Cube Nr2 nun auch mal wieder resetet hat, hab ich ihn auch umgeflasht. Diesmal hat alles auf Anhieb funktioniert.

Lieber Telekatz, vielen Dank für die tolle Arbeit.
Titel: Antw:culfw@ARM
Beitrag von: Bond246 am 19 November 2018, 11:54:17
Hallo zusammen,

wenn ich den Cube umflashe, arbeitet er dann eigentlich noch als LAN-Device oder nur noch per USB?

Grüße
Titel: Antw:culfw@ARM
Beitrag von: EinfachFhem am 19 November 2018, 12:10:04
Funktioniert sowohl als auch. Wenn bei LAN Einbindung sollte man eine USB Verbindung nur zu Stromversorgung herstellen.

Gesendet von meinem Note3 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: Bond246 am 19 November 2018, 12:11:14
Ich habs gerade gefunden. Und es steht eigentlich auch auf den ersten Seiten in dem Thread.
Danke für die Antwort :)
Titel: Antw:culfw@ARM
Beitrag von: Bond246 am 19 November 2018, 14:54:11
Irgendwas läuft bei mir nicht.
Ich hab den CUBE eigentlich deswegen umgeflasht, weil er zuvor alle paar Wochen nicht mehr richtig funktionierte.

Ich hab heute die neueste Firmware geflasht und dann in FHEM integriert
define MAXcube CUL 192.168.171.4:2323 0000Per attribut hab ich ihn zu einem "MAX" gemacht. Das autocreate des CUL_MAX hat nicht funktioniert, deswegen hab ich das manuell gemacht:
define MAXcul CUL_MAX 654321
Jetzt würde ich gerne meine bestehenden Thermostate (3 Stück), wieder anlernen. Dazu hab ich sie zurückgesetzt (Batterie raus, 3 Tasten beim einlegen gedrückt, res erscheint).
Jetzt versetze ich mein Geräte "MAXcul" in den pairmode. Das wird nicht bestätigt, der State bleibt bei "Defined" stehen. Wenn ich ein Thermostat ebenfalls in den pairmode versetze, wird es im Log erkannt und erstellt.
Wenn ich nun das CUL_MAX device erneut in den pairmode setze, passiert nichts mehr. Keine Log-Einträge, der State bleibt weiterhin bei defined usw...

Ich hab alle Device gelöscht, Server und Raspberry neu gestartet usw... Ich kann immer 1 Device anlegen und dann geht nichts mehr, egal welchen Reboot ich danach mache. Beim erkennen des ersten Geräts werden folgende Logs erzeug:
2018.11.19 14:13:23 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2018.11.19 14:13:39 3: CUL_MAX_Parse: Re-Pairing device 153b17 of type HeatingThermostat with serial NEQ0932759
2018.11.19 14:13:39 1: PERL WARNING: Use of uninitialized value $it in concatenation (.) or string at ./FHEM/98_autocreate.pm line 135.
2018.11.19 14:13:39 2: autocreate: define MAX_153b17 MAX HeatingThermostat 153b17
2018.11.19 14:13:39 2: autocreate: define FileLog_MAX_153b17 FileLog ./log/MAX_153b17-%Y.log MAX_153b17
2018.11.19 14:13:48 1: 192.168.171.4:2323 disconnected, waiting to reappear (MAXcube)
2018.11.19 14:13:48 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:13:52 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:13:57 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:02 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:07 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:12 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:17 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:22 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:27 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:32 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:37 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:42 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:47 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:52 3: MAXcube: Possible commands: BbCFiAZNEkGMKLUYRTVWXOefhltxz
2018.11.19 14:14:52 1: 192.168.171.4:2323 reappeared (MAXcube)
2018.11.19 14:14:54 1: Device MAX_153b17 answered with: Invalid command/argument

Weiß jemand weiter?

Hier noch ein paar Internals:
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.171.4:2323 0000
   DeviceName 192.168.171.4:2323
   FD         10
   FHTID      0000
   MAXcube_MSGCNT 1
   MAXcube_TIME 2018-11-19 14:29:11
   NAME       MAXcube
   NR         64
   NR_CMD_LAST_H 3
   PARTIAL   
   RAWMSG     Z0E030202153B1765432100011900291B
   RSSI       -60.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za654321
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-11-19 14:26:49   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2018-11-19 14:29:10   credit10ms      2167
     2018-11-19 14:29:11   state           Initialized
   XMIT_TIME:
     1542634009.78685
     1542634010.08743
     1542634150.10673
Attributes:
   DbLogExclude .*
   rfmode     MAX
Internals:
   DEF        654321
   IODev      MAXcube
   LASTInputDev MAXcube
   MAXcube_MSGCNT 1
   MAXcube_RAWMSG Z0E030202153B176543210001190029
   MAXcube_RSSI -60.5
   MAXcube_TIME 2018-11-19 14:29:11
   MSGCNT     1
   NAME       MAXcul
   NR         66
   STATE      Defined
   TYPE       CUL_MAX
   addr       654321
   cnt        0
   pairmode   0
   retryCount 0
   sendQueue:
Attributes:
   DbLogExclude .*
   IODev      MAXcube
Titel: Antw:culfw@ARM
Beitrag von: gloob am 19 November 2018, 15:19:50
Falls noch jemand einen Cube sucht. Bei Amazon gibt es ihn gerade für 25€.

https://www.amazon.de/MAX-Cube-LAN-Gateway-99004/dp/B004W1Q2BO
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 19 November 2018, 15:53:41
@Bond246, dein Problem wäre im MAX! Forum vermutlich besser aufgehoben als hier,
aber nachdem du vorher schon nach USB / Lan gefragt hattest :
Ich vermute jetzt mal du versorgst den Cube von irgend einem Gerät via USB Port mit Strom und nicht von einem dummen Netzteil ? Wenn ja : Netzteil verwenden oder USB Kabel bearbeiten das es nur noch 2 Adern hat
(In die Falle bin ich mal getappt, siehe etliche Seiten weiter vorne) 
Titel: Antw:culfw@ARM
Beitrag von: Bond246 am 19 November 2018, 16:23:23
Beste Danke!!!

Offenbar war es genau das. Und ich dachte noch, "nicht dass da am Ende einfach nur die Stromversorgung zu schlecht ist".

Bisher kam der Strom per USB aus der Fritzbox, die gleich daneben steht.

Grüße
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 19 November 2018, 21:04:22
der Strom ist nicht zu schlecht , es die USB Datenverbindung die besteht aber nicht genutzt wird !
Darum mein Tipp in dem USB Kabel die beiden Drähte kappen und nur + & - ( i.d.R. schwarz und rot) übrig lassen.
Titel: Antw:culfw@ARM
Beitrag von: tcj am 23 November 2018, 15:35:50
Moin,

ich weiß, das ich hier im FHEM Forum bin und meine Frage bezüglich Homegear daher eigentlich OT ist, aber hier bin ich am nächsten am Entwickler dran und vielleicht mag und kann mir ja dennoch jemand helfen.

Ich möchte meinen Cube mit a-culfw flashen und dabei gleich die Möglichkeit nutzen, ein 433MHz CC1101 mit einzubauen für die Intertechno Funk-Steckdosen, so wie hier schon der eine oder andere es getan hat.
Löten, compilieren und flashen sind für mich kein Problem.

ABER: Wie konfiguriere ich das in Homegear, wenn ich den Cube dann als CUL oder CUN verwende?
Wahrscheinlich werde ich ihn als CUL nutzen, weil er sowieso nahe dem Raspberry steht und von dort bisher alles erreicht wird.
D.h. was muss ich in MAX.conf und intertechno.conf angeben, um das jeweilige Modul anzusprechen?
Einfach stackPosition = 0 bzw. 1  in den CUL/CUNX Abschnitt ergänzen?

Ich möchte das gerne vor dem Umbau wissen - kann da jemand helfen?

Danke
Titel: Antw:culfw@ARM
Beitrag von: tcj am 24 November 2018, 17:03:17
Mittlerweile habe ich einen Cube als Single-CUL/N geflasht und einen weiteren, den ich per Kleinanzeigen günstig schiessen konnte als 4fach CUL - bzw. 2fach, weil nur ein weiteres 433MHz CC1101 drin ist.
Der Einzel Cube CUN funktioniert einwandfrei.
Das 433MHz CC1101 auch, wenn ich es als Selbstbau CUL verwende - ich habe derzeit nur das eine.

Den 4fach Cube aber bekomme ich nicht wie gewünscht mit Homegear zum laufen.
Technisch ist alles ok - V und *V melden auch die beiden Module.

Welche Optionen habe ich denn, um die einzelnen Module per USB oder Netz anzusprechen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 24 November 2018, 17:58:46
Das zusätzliche Modul kann nur über * angesprochen werden. Es gibt keinen separaten Port für das zusätzliche Modul.
Titel: Antw:culfw@ARM
Beitrag von: tcj am 24 November 2018, 18:28:27
hm - Schade
Dann wird das wohl nix mit Homegear
Jedenfalls nicht mit meinem Wissen und das, was ich im Netz so finde - bzw. nicht finde.
Titel: Antw:culfw@ARM
Beitrag von: tcj am 26 November 2018, 10:00:15
Es gibt keinen separaten Port für das zusätzliche Modul.
Wäre das denn machbar?
D.h. könnte man/du es so programmieren?
Ich kann es leider nicht, aber meine dass es von allgemeinem Nutzen wäre für andere Smarthome-Software neben FHEM.
Als CUN die Ansprache der Module über Netzwerk-Ports (2323 - 2326?) oder CUL mehrere virtuelle serielle Schnittstellen fände ich als Nutzer sehr praktisch.

Wie gesagt, ich habe keine Ahnung, ob das überhaupt geht und wie hoch der Aufwand wäre.

Ich habe jetzt zwar eine funktionierende Lösung mit einem CUL/CUN-Cube für MAX! und nanoCUL für Intertechno, aber beides in einem Würfel wäre aufgeräumter und erhöht den WAF ;-)
Titel: Antw:culfw@ARM
Beitrag von: Beta-User am 26 November 2018, 10:06:09
Ich habe jetzt zwar eine funktionierende Lösung mit einem CUL/CUN-Cube für MAX! und nanoCUL für Intertechno, aber beides in einem Würfel wäre aufgeräumter und erhöht den WAF ;-)
Zusätzliche Funkmodule sind doch in der Regel über STACKABLE bzw. STACKABLE_CC ansprechbar. Ist das bei dem Cube nicht der Fall?
Titel: Antw:culfw@ARM
Beitrag von: gloob am 26 November 2018, 10:10:04
Zusätzliche Funkmodule sind doch in der Regel über STACKABLE bzw. STACKABLE_CC ansprechbar. Ist das bei dem Cube nicht der Fall?

Das funktioniert nur, wenn man FHEM nutzt. Stackable gibt es in IoBroker, OpenHab, Homegear, ... nicht.
Titel: Antw:culfw@ARM
Beitrag von: Beta-User am 26 November 2018, 10:15:04
Das funktioniert nur, wenn man FHEM nutzt. Stackable gibt es in IoBroker, OpenHab, Homegear, ... nicht.
Danke, hatte nicht weit genug nach oben gelesen um zu bemerken, dass es speziell darum ging, das Teil mit einer anderen HA-Software zu nutzen.
Wäre es dann im Ergebnis nicht einfacher, ein Plugin (analog STACKABLE.*) für die andere HA-Lösung zu bauen, als die firmware umzubauen?
Titel: Antw:culfw@ARM
Beitrag von: tcj am 26 November 2018, 10:47:12
Wäre es dann im Ergebnis nicht einfacher, ein Plugin (analog STACKABLE.*) für die andere HA-Lösung zu bauen, als die firmware umzubauen?
Aber dann müsste man ja die jeweiligen Module der unterschiedlichen HA-Lösungen umbauen, eventuell auch noch mehrfach (MAX!, IT, FS20, ...)
- Oder aber einmal die firmware.

Titel: Antw:culfw@ARM
Beitrag von: gloob am 26 November 2018, 10:49:31
Wie willst du aber 4 "CULs" über 3 Hardware Schnittstellen (USB) bekommen?
Über Netzwerk wäre es vielleicht noch machbar.
Titel: Antw:culfw@ARM
Beitrag von: tcj am 26 November 2018, 10:57:33
Wie willst du aber 4 "CULs" über 3 Hardware Schnittstellen (USB) bekommen?
Über Netzwerk wäre es vielleicht noch machbar.
Wie ich schon schrieb - ich weiß ja nicht, ob, was und wie das geht.
Netzwerkports wären ein Anfang und würden mir persönlich ja schon reichen.
Alles über USB  - oder vielleicht auch nur die ersten drei - spart ggf. ein Kabel und einen Port am Switch ;-)
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 26 November 2018, 12:10:24
Homegear unterstützt doch anscheinend den SCC. Auch mehrere gestapelte. Damit sollte auch der MapleCUL/CUBe mit mehreren Transceivern gehen. 
Titel: Antw:culfw@ARM
Beitrag von: Starbug am 06 Dezember 2018, 21:26:43
Hallo zusammen,
auch ich habe meinen Cube, der zuvor einige Jahre als MAXLAN in Gebrauch war, auf CUL_MAX umgeflasht. Meine Hauptgründe dafür waren, dass sich der Cube alle paar Wochen aufgehangen hat und ich ihn manuell reseten musste. Zudem hat mir das Polling nicht gefallen. Das Inbetriebnehmen des CUL_MAX hat auch problemlos funktioniert und läuft nun seit einigen Wochen.
Mein Problem sind fehlende Zustandsänderungen und damit dann auch fehlende Events.
Hintergrund: Ich nutze den Cube für die Überwachung von 19 Max-Fensterkontakten. Um Empfangsprobleme handelt es sich höchstwahrscheinlich nicht. In seinen Jahren als MAXLAN gab es meines Wissen nach nicht einen einzigen Verlust einer Nachricht. Der Standort hat sich nicht verändert. Heute konnte ich zudem beobachten, dass der Kontakt an der Haustür beim Öffnen und Schließen jeweils nur einmal geblinkt hat, d.h. die Übertragung zum Cube wurde erfolgreich quittiert. Der Cube hängt per USB an einem kleinen USB-Hub, der wiederum an einem Raspi hängt.

Hat jemand eine Idee, warum der CUL_MAX Nachrichten bzw. Zustandsänderungen verschluckt?

Viele Grüße
Starbug

Ein Beispiel von heute:
2018-12-06_17:54:00 Haustuer opened
2018-12-06_17:54:12 Haustuer closed
2018-12-06_18:31:21 Haustuer opened
2018-12-06_18:41:51 Haustuer opened
2018-12-06_19:24:38 Haustuer opened
2018-12-06_19:35:14 Haustuer opened

Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXOefhltxz
   CUL2_MSGCNT 11304
   CUL2_TIME  2018-12-06 20:57:11
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM3@9600 0000
   DeviceName /dev/ttyACM3@9600
   FD         4
   FHTID      0000
   NAME       CUL2
   NEXT_OPEN  1543428183
   NR         73
   NR_CMD_LAST_H 4
   PARTIAL   
   RAWMSG     Z0B5D0030054E53000000000011
   RSSI       -65.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
   initString X21
Zr
Za123456
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-11-15 21:40:13   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2018-11-28 19:02:03   cmds             B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
     2018-12-06 20:49:34   credit10ms      3282
     2018-11-15 21:54:22   raw             Z00D8
     2018-12-06 20:57:11   state           Initialized
     2018-11-15 22:05:10   version         V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
   XMIT_TIME:
     1544125755.45259
     1544125761.96311
     1544125768.47328
     1544125774.98859
Attributes:
   rfmode     MAX

Im Log steht dann mit Verbose 5:
2018.12.08 20:41:29 5: cm: dispatch MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:41:29 5: MAX_Parse MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:41:29 5: ShutterContact isopen 1, rferror 0, battery 0, unkbits 0
2018.12.08 20:42:24 5: cm: dispatch MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:42:24 5: MAX_Parse MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:42:24 5: ShutterContact isopen 1, rferror 0, battery 0, unkbits 0
Hier wurde der Fensterkontakt geöffnet, geschlossen und wieder geöffnet.
Der RSSI-Wert schwankt zwischen -70 und -80.

PS: Vielen Dank für das Modul!

Ergänzung am 16.12.2018:

Was ich bisher probiert habe:

Bisher keine Besserung. Der Effekt, dass Zustandsänderungen sporadisch verloren gehen, tritt bei allen Fensterkontakten weiterhin auf.

Hat noch jemand eine Idee?
Wie kann ich die Kommunikation zwischen Cube und FHEM (besser) loggen?
Titel: Antw:culfw@ARM
Beitrag von: Clyde am 31 Dezember 2018, 17:48:07
Bitte um einen Stubs in die richtige Richtung. Mein CUBE will nicht senden. :(

Mein ca. 5 Jahre alter MAXCUBE wurde auf V 1.26.03 a-culfw geflasht und um ein Modul für IT erweitert.
Da das Compilieren unter jessie bei mir nicht klappte, hab ich das fertige CUBEx4_BL
vom blog.loetzimmer.de verwendet. Hat soweit auch geklappt.

Nun das Problem:
1)
Die 5 MAX-Thermostate (Firmware 1.0) lassen sich nicht anlernen?
Sie werden zwar per autocreate gefunden und zugeordnet,
es scheint aber so, als würde nur mitgelesen.
Ich kann keine Temperatur setzen.
An ihnen blinkt auch das Antennensymbol nach dem Versuch sie neu anzulernen.
Batterien raus, Werksreset, neu anlernen führen nicht zum Erfolg.
Wie kann ich da anders vorgehen?

2)
Der CUBE (Stromversorgung über USB_Steckernetzteil 2A) lässt sich ansprechen.
LED auf 01 schaltet die LED ein, sie geht aber nach wenigen Sekunden wieder aus.
Ist das richtig?

3)
Welches IODev bekommen die Thermostate?
Der CUL_MAX wird per autocreate eingetragen.
Muss ich den auf den CUL ändern? Der ist ja schließlich per rfmode auf MAX gestellt.

Meine Konfiguration 1xCube per Netzwerk 5x Thermostat 5x FK:
1x Cube mit rfmode MAX
1x CC1101 mit rfmode SlowRF für die IT Steckdosen

Der CUBE
Internals:
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltxz*
   CUL_CUBe_MSGCNT 165
   CUL_CUBe_TIME 2018-12-31 17:37:45
   Clients    :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        192.168.1.57:2323 0000
   DeviceName 192.168.1.57:2323
   FD         25
   FHTID      0000
   NAME       CUL_CUBe
   NR         765
   NR_CMD_LAST_H 33
   PARTIAL   
   RAWMSG     *i500015F1
   RSSI       -59
   STACKED    CUL_CUBe_IT
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
   initString X21
Zr
Za123456
Zw111111
   MatchList:
     1:CUL_MAX  ^Z........................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-12-31 17:07:39   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
     2018-12-31 17:37:52   credit10ms      8
     2018-12-31 17:37:45   state           Initialized
     2018-12-31 16:44:25   version         V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
   XMIT_TIME:
     1546273362.5362
     1546273369.07126
     1546273375.59825
     1546273382.12472
     1546273385.67114
     1546273392.20128
     1546273398.25276
     1546273404.77885
     1546273408.33951
     1546273414.87449
     1546273421.43948
     1546273427.92978
     1546273431.46164
     1546273437.49959
     1546273444.05191
     1546273450.13371
     1546273453.22362
     1546273459.76035
     1546273466.29082
     1546273472.82956
     1546273476.3599
     1546273482.89335
     1546273489.44597
     1546273495.95125
     1546273499.46991
     1546273506.0224
     1546273608.53421
     1546273718.06567
     1546273827.62427
     1546273937.15168
     1546274046.6824
     1546274156.20553
     1546274265.91405
Attributes:
   icon       cul
   rfmode     MAX
   room       Gateways

CUL_MAX


 Internals:
   CUL_CUBe_MSGCNT 118
   CUL_CUBe_RAWMSG Z0AF30A0305D80F0504C700
   CUL_CUBe_RSSI -59
   CUL_CUBe_TIME 2018-12-31 17:33:41
   DEF        123456
   IODev      CUL_CUBe
   LASTInputDev CUL_CUBe
   MSGCNT     118
   NAME       CUL_CUBe_MAX
   NR         766
   STATE      Defined
   TYPE       CUL_MAX
   addr       123456
   cnt        0
   pairmode   0
   retryCount 0
   READINGS:
     2018-12-31 17:35:59   packetsLost     95
   sendQueue:
     HASH(0xbb316110)
Attributes:
   IODev      CUL_CUBe
   icon       cul
   room       Gateways

CUL_IT


 Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   CUL_CUBe_IT_MSGCNT 47
   CUL_CUBe_IT_TIME 2018-12-31 17:37:45
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        CUL_CUBe
   IODev      CUL_CUBe
   NAME       CUL_CUBe_IT
   NOTIFYDEV  CUL_CUBe
   NR         769
   NTFY_ORDER 50-CUL_CUBe_IT
   PARTIAL   
   RAWMSG     i500015F1
   RSSI       -81.5
   STATE      Initialized
   StackLevel 1
   TYPE       STACKABLE_CC
   VERSION    V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 433MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2018-12-31 17:07:39   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2018-12-31 17:37:44   raw             is0000F0000FFF
     2018-12-31 17:37:45   state           Initialized
Attributes:
   icon       cul
   rfmode     SlowRF
   room       Gateways
Titel: Antw:culfw@ARM
Beitrag von: pejonp am 31 Dezember 2018, 18:13:44
@clyde,

schau mal hier https://forum.fhem.de/index.php/topic,60458.msg879305.html#msg879305. Da ist meine config. MAX!-CUBE mit 3x CC1101 (2 zusätzliche). Alle Leitungen verbunden GDO0 und GDO2 (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html).

pejonp
Titel: Antw:culfw@ARM
Beitrag von: Clyde am 01 Januar 2019, 10:54:45
Ich habe mir deine Konfiguration angesehen. Hast du kein CUL_MAX Device?
Meine Befürchtung momentan ist, das die alte Firmware 1.0 in den Thermostaten bei mir nicht mitspielt.

Werden MAX Thermostate mit 1.0 Firmware überhaupt unterstützt?
Titel: Antw:culfw@ARM
Beitrag von: pejonp am 01 Januar 2019, 11:23:04
@clyde

Der erste cui ist für MAX!
defmod CUL_1 CUL 192.168.x.xxx:2323 3034
attr CUL_1 model CUN
attr CUL_1 rfmode MAX
attr CUL_1 room TRX

Pejonp
Titel: Antw:culfw@ARM
Beitrag von: Clyde am 01 Januar 2019, 12:14:05
Ja, das habe ich auch. Sieht so aus:

defmod CUL_CUBe CUL 192.168.1.57:2323 0000
attr CUL_CUBe rfmode MAX

defmod CUL_CUBe_IT STACKABLE_CC CUL_CUBe
attr CUL_CUBe_IT rfmode SlowRF


Zusätzlich habe ich allerdings noch ein CUL_MAX mit dem ich in den pairmode gehen kann.

defmod CUL_CUBe_MAX CUL_MAX 123456
attr CUL_CUBe_MAX IODev CUL_CUBe



set CUL_CUBe_MAX pairmode

Wie hast du mit deinem CUL_1 die MAX Komponenten angelernt?

Titel: Antw:culfw@ARM
Beitrag von: pejonp am 03 Januar 2019, 02:05:42
@clyde

defmod CULMAX0 CUL_MAX 123456
attr CULMAX0 IODev CUL_2
attr CULMAX0 room CUL_MAX
attr CULMAX0 verbose 2

pejonp
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 03 Januar 2019, 07:15:29
set CUL_CUBe_MAX pairmode
dir ist aber schon klar das da noch die Zeit in Sekunden fehlt ?
set CUL_CUBe_MAX pairmode 120 ?
Titel: Antw:culfw@ARM
Beitrag von: Clyde am 03 Januar 2019, 12:03:19
Auch mit Zeitangabe bekomme ich das Blinken des Antennensymbols im MAX-Thermostat-Display nicht weg. Es findet vermutlich kein Pairing statt.

Die Thermostate tauchen aber nach einer gewissen Zeit (autocreate) in der Konfiguration auf:

defmod MAX_05d80f MAX HeatingThermostat 05d80f
attr MAX_05d80f IODev CUL_CUBe_MAX

Allerdings lassen sie sich nicht ansprechen (Temparatur ändern).

Hat jemand mit Thermostaten Firmwarestand 1.0 Erfolg?
Ich vermute das diese sich nicht erfolgreich pairen lassen.
Titel: Antw:culfw@ARM
Beitrag von: siradlib am 03 Januar 2019, 13:34:58
Auch mit Zeitangabe bekomme ich das Blinken des Antennensymbols im MAX-Thermostat-Display nicht weg. Es findet vermutlich kein Pairing statt.

Die Thermostate tauchen aber nach einer gewissen Zeit (autocreate) in der Konfiguration auf:

defmod MAX_05d80f MAX HeatingThermostat 05d80f
attr MAX_05d80f IODev CUL_CUBe_MAX

Allerdings lassen sie sich nicht ansprechen (Temparatur ändern).

Hat jemand mit Thermostaten Firmwarestand 1.0 Erfolg?
Ich vermute das diese sich nicht erfolgreich pairen lassen.

Achtung, es gibt auch unterschiedliche Typen von MAX-Thermostaten:
https://www.elv.de/topic/alte-firmware-ausgeliefert.html
Das Gemeine ist, dass eq-3 bei der neuen Hardwareversion der Thermostate die (angepasste) Firmware auch wieder 1.0 genannt hat.
1.0 alt ist aber eine andere Firmware als 1.0 neu. (Hardware ist auch anders.)
Das nur als Hinweis.

Gesendet von meinem XT1650 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: Clyde am 03 Januar 2019, 14:23:09
Das ist ja raffiniert von dieser Firma. Da meine Thermostate >5 Jahre sind, hab ich sicher die alte Version 1.0.
Ein Update zu machen scheint ja nicht möglich zu sein.

Fragt sich, ob es Versionen gibt, die nicht kompatibel sind oder gehen tatsächlich alle Versionen?
Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 10 Januar 2019, 04:40:37
Hallo zusammen, was meint ihr,
ist es auch möglich einen hm-mod-rpi-pcb direkt anzuschließen bzw zu löten?


Gesendet von meinem HTC U11 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: pc1246 am 10 Januar 2019, 08:29:02
Hallo zusammen, was meint ihr,
ist es auch möglich einen hm-mod-rpi-pcb direkt anzuschließen bzw zu löten?


Gesendet von meinem HTC U11 mit Tapatalk
Moin
Wozu soll das gut sein? Es ist doch quasi einer im Cube verbaut!?
Gruss Christoph
Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 10 Januar 2019, 10:50:21
Hallo Christoph, anstelle von einem CC1101 bei Umbau auf cube x3
Der eingebaute wird für max! verwendet, ein weiterer 433 für it und dann ein CC1101 oder Hm mod für Homematic inkl Hm ip
Grüße zurück
PS vollzitat ist glaube ich nicht notwendig gewesen



Gesendet von meinem HTC U11 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 10 Januar 2019, 11:34:39
Hi, die a-culfw kann vier cc1101 auf dem CUBE. Beim MapleCUL werden zusätzlich zwei Serielle Schnittstellen auf zwei weiteren Ports über Ethernet bereitgestellt.
Wenn Du also wirklich vor hast, einen HM-MOD-UART am CUBE zu betreiben, dann müsstest Du:
a) klären ob der eine serielle frei hat
b) die Firmware analog zum Maple erweitern, um die serielle auf einen Port 2324 zu legen
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 11 Januar 2019, 10:54:34
Der Max!cube hat laut @telekatz einen seriellen debug Port und einen uart0.
Analog zu diesem Post könnte da doch was möglich sein?
https://forum.fhem.de/index.php/topic,60458.msg541584.html#msg541584

Leider fehlt mir das Wissen, ob dies möglich ist und wenn ja wie umgesetzt werden kann.

Gesendet von meinem HTC U11 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 Januar 2019, 13:33:28
Um das zu machen müsste man die USB Lib auf dual CDC umbauen. Ist prinzipiell möglich, war aber schon beim Maple einiges an Arbeit.
Titel: Antw:culfw@ARM
Beitrag von: Clyde am 12 Januar 2019, 16:37:25
Problem meinerseits ist gelöst. Auch alte Max!Thermostate mit Firmwarestand 1.0 lassen sich anlernen. Ich hatte beim Reset/Ablernen nicht lange genug die Tasten gehalten.  ::)

Ich bekomme nun alle Thermostate angelernt.

Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 12 Januar 2019, 22:43:47
Um das zu machen müsste man die USB Lib auf dual CDC umbauen. Ist prinzipiell möglich, war aber schon beim Maple einiges an Arbeit.
Danke für deine Einschätzung, schade, aber nicht schlimm. Dann kommt ein CC1101 mehr rein.

Gesendet von meinem HTC U11 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 12 Januar 2019, 22:46:14
Es gibt's den cube gerade im Angebot für 21,90 bei Amazon und für 22.90 bei ebay
Sucht nach:
MOBILCOM-DEBITEL MAX! Cube LAN-Gateway

Gesendet von meinem HTC U11 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 13 Januar 2019, 12:17:50
Hi,
1) Offtopic
2) Nur mit Vertrag -> also nein ;-)
3) Ich habe nich einen gebrauchten, wenn jemand einen will *lol*

Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: gloob am 13 Januar 2019, 12:48:01
Wieso mit Vertrag? Amazon Prime reicht.
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 13 Januar 2019, 13:04:06
Ist doch auch ein Vertrag ;-) Aber Danke! Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: d0np3p3 am 13 Januar 2019, 23:19:35
Ebay ist ohne vertrag, oder?
Ich würde mich freuen über den cube, was willst du denn für den cube?

Gesendet von meinem HTC U11 mit Tapatalk

Titel: Antw:culfw@ARM
Beitrag von: ra-ma am 14 Januar 2019, 21:18:42
Hallo, erst mal vielen Dank für die tolle Anleitung. Habe in meinen Cube noch ein 868 und ein 433 MHz Modul eingebaut. Es funktioniert der "Cube 0", also der alte Teil mit MAX und das Modul 1 mit SlowRF in 868MHz. Modul 2 (433MHz) funktioniert leider nicht richtig.

Wenn ich im Terminal prüfe, erhalte ich Folgendes:

V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
*V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
**V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)

0D2E2D07D3913D04
320000060021656A
57C43023B9000700
18146C070090876B
F85611EF2C191F41
00597F3F88310B00
*292E3F07D391FF04
*4500000F001EC4EC
*8C220222F8470730
*04766C034091876B
*F85610A90A200D41
*00597F3F88310B00
**292E3F07D391FF04
**4500000F001EC4EC
**8C220222F8470730
**04766C034091876B
**F85610A90A200D41
**00597F3F88310B00

Das zweite zusätzliche Modul hat hier denselben Inhalt wie das erste. Ist das korrekt? Wo kann ich nach dem Fehler suchen?
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 15 Januar 2019, 07:49:04
Hi, hast du die Frequenz umgestellt?
set <device2> freq 433.920
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: ra-ma am 15 Januar 2019, 18:33:08
Danke. Das habe ich versucht. Folgenden Fehler finde ich dann im Logfile:
2019.01.15 18:29:41 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2019.01.15 18:29:41 3: Cube_2: Unknown code ? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.01.15 18:29:41 3: Cube_2: Unknown code ? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.01.15 18:29:41 3: Cube_2: Unknown code ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z, help me!

Die Frequenz bleibt auf 868 MHz. Das Verstellen funktioniert bei den ersten beiden Modulen, bei dem dritten nicht. Folgende Fehlermeldung bekomme ich regelmäßig:

2019.01.14 21:53:32 2: Setting Cube_2 fhtid from ? (T01 is unknown) Use one of b C A Z N E L Y V X f z to 3412
Titel: culfw@ARM
Beitrag von: RaspiLED am 15 Januar 2019, 18:37:28
Zeig mal alle list,
Wie ist der CC1101 angeschlossen?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: ra-ma am 15 Januar 2019, 18:52:38
Hallo,

Modul 1 (welches funktioniert auf SlowRF mit 868MHz):
Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz*
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   Cube_1_MSGCNT 2123
   Cube_1_TIME 2019-01-15 18:50:03
   DEF        FHEM:DEVIO:Cube_0_SCC:42 2345
   DeviceName FHEM:DEVIO:Cube_0_SCC:42
   FD         17
   FHTID      2345
   IODev      Cube_0_SCC
   IODevPort  42
   IODevRxBuffer
   IOReadFn   STACKABLE_IOReadFn
   NAME       Cube_1
   NR         44
   PARTIAL   
   RAWMSG     T255F00A6001B
   RSSI       -60.5
   STACKED    Cube_1_SCC
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-01-15 18:23:54   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2019-01-14 21:53:32   cmds             b C F i A Z N E G M K L U Y R T V W X f z *
     2019-01-15 18:50:03   state           Initialized
   SOFTBUFFER:
Attributes:
   alias      FHT
   rfmode     SlowRF
   room       CUL

Modul 2, welches nicht richtig funktioniert (433MHz Modul):
Internals:
   CMDS       bCAZNELYVXfz
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   Cube_2_MSGCNT 9
   Cube_2_TIME 2019-01-15 18:30:00
   DEF        FHEM:DEVIO:Cube_1_SCC:42 3412
   DeviceName FHEM:DEVIO:Cube_1_SCC:42
   FD         17
   FHTID      3412
   IODev      Cube_1_SCC
   IODevPort  42
   IODevRxBuffer
   IOReadFn   STACKABLE_IOReadFn
   NAME       Cube_2
   NR         46
   PARTIAL   
   RAWMSG     ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-01-14 20:53:42   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2019-01-14 21:53:32   cmds             b C A Z N E L Y V X f z
     2019-01-15 18:39:37   raw             C35 = 01 /  1
     2019-01-15 18:30:00   state           Initialized
     2019-01-14 19:58:27   uptime          No answer
     2019-01-13 23:38:38   version         V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
Attributes:
   alias      433
   rfmode     SlowRF
   room       CUL
Titel: culfw@ARM
Beitrag von: RaspiLED am 15 Januar 2019, 18:56:55
Stell mal versuchsweise an Modul 1 433.920 ein, bitte
Wieso hat Modul 2 kein W im cmds?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 15 Januar 2019, 20:56:57
Der Cube kann nur an den ersten beiden Modulen SlowRF. Du solltest das dritte Modul für MAX verwenden.
Titel: Antw:culfw@ARM
Beitrag von: ra-ma am 15 Januar 2019, 22:09:36
Hallo Telekatz, das war's tatsächlich. Habe jetzt durch Anpassung der Üinbelegung board.h auf die ersten beiden Module SlowRF gelegt und auf den dritten Max und alles klappt inkl. der Einstellung auf 433Mhz, vielen Dank!
Titel: Antw:culfw@ARM
Beitrag von: skycrack am 19 Januar 2019, 22:08:54
Hallo,
ich habe heute einen meiner beiden MaxCubes umgeflasht und um 2 weitere CC1101 Module erweitert.
Im TeraTerm kann ich die 3 mit V, *V,**V nach der Version abfragen.
Jetzt wollte ich diese Fhem bekannt machen, und bekomme den 3. nicht per STACKABLE dazu.
Der Cube ist mit
define MAXCUN CUL 192.168.90.42:2323 0000
attr MAXCUN icon mqtt_device
attr MAXCUN rfmode MAX
der 2. dann mit
define MAXCUN_1 STACKABLE_CC MAXCUN
attr MAXCUN_1 connectCommand Nr1
attr MAXCUN_1 rfmode SlowRF

eingebunden, wenn ich den dritten mit
define MAXCUN_2 STACKABLE_CC MAXCUN
bekanntmachen möchte kommt:
MAXCUN has alread a stacked device: MAXCUN_1

Hab ich da den falschen Syntax ? Würde mich über eine Info freuen,
Gruß Rene

Danke an die Macher, für diese wirklich schöne Möglichkeit den Cube so zu verwenden.
Titel: Antw:culfw@ARM
Beitrag von: skycrack am 19 Januar 2019, 22:23:11
Habs mit
define MAXCUN_2 STACKABLE_CC MAXCUN_1gings dann.
Vieleicht hilft es ja nochmal jemanden.
Gruß
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 19 Januar 2019, 22:56:57
Hi,
Halt so wie es im Wiki für den MapleCUN aufgeschrieben ist ;-)
Vielleicht sollten wir das allgemeiner bei Stackable platzieren.
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:culfw@ARM
Beitrag von: pejonp am 20 Januar 2019, 23:31:54
@skycrack

als Anlage der bootlader_CUBe und die Firmeware 1.26.05. Habe ich auf meinem CUBe und dort ist auch LaCross mit drin. ES werden aber nur 2 von 10 erkannt. Mit JeeLink/LaCrossGateway geht es besser.

pejonp
Titel: Antw:culfw@ARM
Beitrag von: skycrack am 21 Januar 2019, 23:37:04
@pejonp

Super Sache, vielen Dank. Hab eine compilierte Version am laufen, Lacrosse und Autocreate des HMS Devices klappt.
Besten Dank
Rene
Titel: Antw:culfw@ARM
Beitrag von: Mondeo20 am 27 Januar 2019, 16:21:09
Kurze Frage,

habe mir auch den MAX Cube umgeflasht (Bootloader und Firmware). Ist alles ohne Probleme durchgelaufen (Es blinkt die Power Lampe). Wenn ich das Teil jetzt an das Lan hänge, passiert nix, sprich der Port kommt gar nicht hoch (Lampe bleibt aus am Switch) und dementsprechend sehe ich den Würfel auch nicht im Lan. 
Frage, muss ich da noch was machen vorher (per USB anschließen und irgendwas aktivieren)?

Gruss

Helge
Titel: Antw:culfw@ARM
Beitrag von: rubbertail am 27 Januar 2019, 16:37:44
Vielleicht ne blöde Frage, aber nichz böse gemeint und klassischer IT-Support: Ist der Cube denn über den USB-Port mit Strom versorgt?
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 27 Januar 2019, 17:04:57
Und die Antwort: wenn der Datenleitungen hat macht die a-culfw alles über usb und nicht über lan! Ist mir auch passiert! Also ab an ein Steckernetzteil oder ein nur Power Kabel (z.B. Von Powerbank) am RasPi ;-)

Passiert übrigens seit a-culfw 1.26.02 auch beim MapleCUN bei Betrieb mit ESP-01 über Debug Schnittstelle ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 27 Januar 2019, 17:42:47
Und die Antwort: wenn der Datenleitungen hat macht die a-culfw alles über usb und nicht über lan! Ist mir auch passiert! Also ab an ein Steckernetzteil oder ein nur Power Kabel (z.B. Von Powerbank) am RasPi ;-)
Das ist so nicht richtig. Grundsätzlich funktioniert beides gleichzeitig. Ein Problem gibt es nur dann, wenn eine USB Verbindung hergestellt und wieder geschlossen wird. Dann kann es zu einem Neustart des Cubes kommen.

Kurze Frage,

habe mir auch den MAX Cube umgeflasht (Bootloader und Firmware). Ist alles ohne Probleme durchgelaufen (Es blinkt die Power Lampe). Wenn ich das Teil jetzt an das Lan hänge, passiert nix, sprich der Port kommt gar nicht hoch (Lampe bleibt aus am Switch) und dementsprechend sehe ich den Würfel auch nicht im Lan. 
Frage, muss ich da noch was machen vorher (per USB anschließen und irgendwas aktivieren)?

Gruss

Helge
Ich würde empfehlen, den Cube über USB anzuschließen und ihm eine feste IP Adresse zu geben.
Titel: Antw:culfw@ARM
Beitrag von: Mondeo20 am 27 Januar 2019, 21:28:10
Mmmh, ich habe das original Netzteil verwendet, sprich ich habe noch einen mit originaler Firmware, der im Moment die Max Thermostate versorgt und habe einfach umgesteckt (Lan Kabel und Netzteil).
Titel: Antw:culfw@ARM
Beitrag von: skycrack am 03 Februar 2019, 14:04:53
Der Cube kann nur an den ersten beiden Modulen SlowRF. Du solltest das dritte Modul für MAX verwenden.

Hallo,
ist das eine Firmeware oder Hardware Einschränkung? Ließe sich das ändern? Der 3. CC1101 ist vollständig verdrahtet.
Gruß
Rene
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Februar 2019, 14:39:59
Beides. Pro SlowRF braucht man einen Real-time Timer, wovon der AT91SAM7 drei hat. Zwei davon werden für SlowRF verwendet, einer für Systemaufgaben. Den für die Systemaufgaben könnte man eventuell durch den Periodic Interval Timer ersetzen, dann währen drei SlowRF receiver möglich.
Titel: Antw:culfw@ARM
Beitrag von: Rudibarani am 12 Februar 2019, 19:22:32
Firmware flashen :
Die kompilierten Bin Dateien findet Ihr unter https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw (https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw). Die Firmware besteht aus zwei Teilen. Einem Bootloader (bootloader_CUBE.bin bzw. bootloader_HM_CFG.bin) und der eigentlichen culfw (CUBE_BL.bin bzw. HM_CFG_BL.bin).
Hallo @Telekatz,
ich wollte gerade Deiner Anleitung folgen meinen ersten Cube flashen. Dabei habe ich gemerkt, dass unter dem Link keine Dateien mehr zu finden sind. Gibt es einen neuen Link oder hättest Du einen Tipp für mich, wo ich die notwendigen Dateien finden kann?
Vielen Dank!
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 12 Februar 2019, 20:14:05
Source:
https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUBe

Binaries:
https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw

Konkret:
http://download37.mediafire.com/g8o6kdkgahvg/hk0y134b339mw11/a-culfw_1.26.05_build_312.zip

Der letzte Link ist zeitlich begrenzt ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Rudibarani am 12 Februar 2019, 20:25:01
Lieber Arnd,

herzlichen Dank für die schnelle Antwort! Der Mediafire-Link sieht bei mir zwar weiterhin so aus, als lägen da keine Dateien - aber der direkte Link funktioniert  ;D

Viele Grüße
Phillip

PS: Es liegt an Safari. Mit Chrome geht der Link. Sorry - war also mein Fehler.
Titel: Antw:culfw@ARM
Beitrag von: Barnie1989 am 25 Februar 2019, 09:54:11

Hat jemand mit Thermostaten Firmwarestand 1.0 Erfolg?
Ich vermute das diese sich nicht erfolgreich pairen lassen.


Ich habe auch einige uralte Thermostate (1.0) im Einsatz. Sie zicken beim Pairern immer wieder mal. Nach mehrmaligen Reset und dann ohne Batterien liegen lassen, habe ich bisher alle einbinden können. Bei den alten Fensterkontakten ist das auch so. Auch das assoziieren mit den Themostaten geht nicht immer auf Anhieb. Dann wieder alles von vorne. Reset und neu probieren. :(
Titel: Antw:culfw@ARM
Beitrag von: Mihca am 11 April 2019, 09:57:34
Ich habe die neue Firmware Build a-culfw_1.26.06_build_316.zip auf einen MAX!Cube geflasht, der vorher mit der der Firmware vom Dezember 2018  a-culfw_1.26.05_build_312.zip einwandfrei im Rfmodus funktionierte. Ich hatte den Flash gemacht, da ich hoffte dass er dann auch Wmbus ohne Probleme empfangen würde. (Siehe auch: https://forum.fhem.de/index.php/topic,96268.0.html)

Beim flashen der neuen Firmware blieb TeraTerm (Windows) hängen. Danach ging nichts mehr mit dem Cube, alle Led's aus. Ich habe dann versucht mit SAM-BA 2.18 (Windows) den Bootloader neu zu installieren. Funktionierte nicht. Dann habe ich mit BOSSA (Windows) den Bootloader neu geflash, was funtionierte. Ich habe dann mit TeraTerm nochmals die neue Firmware geflasht, mit demselben Ergebnis: TeraTerm hängt nach ca 75% und nach Neustart des Cube ging nichts mehr. Dann habe ich über BOSSA und TeraTerm die Firmware vom Dezember zurückgespielt. Nun geht fast alles wieder, ausser dass ich keine feste mehr IP zuweisen kann. Es geht nur DHCP.

Vielleich gibt es ja eine Lösung dafür. Vielen Dank vorab.

Grüße Achim
Titel: Antw:culfw@ARM
Beitrag von: RaspiLED am 11 April 2019, 15:51:28
Hi,
wie groß sind die Files?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: Mihca am 11 April 2019, 17:44:36
das File, das funktioniert hat 110kB, das File, das nicht funtioniert 111kB.

Gruß Achim
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 11 April 2019, 22:11:32
Nimm mal die CUBEx4_BL.bin. Bei einem gescheiterten Flashversuch muss man übrigens den Bootloader nicht neu installieren. Einfach den Cube ausstecken, die Taste unten am Cube gedrückt halten und dann USB wieder einstecken.
Titel: Antw:culfw@ARM
Beitrag von: bigmo am 27 April 2019, 11:21:01
Hi Leute,

ich habe neuerdings ein Problem mit meinem geflashten Cube. Er vergisst immer wieder seine Netzwerkeistellungen (feste IP) und stellt sich auf DHCP zurück.
Ich habe schon neu geflasht und Eprom gelöscht aber das Phänomen bleibt.

Hatte das schon mal jemand?
Titel: Antw:culfw@ARM
Beitrag von: Edi77 am 28 April 2019, 19:55:50
Hallo,

Habe meinen MAX! Cube laut Anleitung geflasht, und wenn ich ihn an ein USB Netzteil anschließe und Netzwerk passiert nichts. Leine LED geht an, kein Netzwerk, wie Tod.

Am PC kommt kein COM Port und "USB-Gerät wurde nicht erkannt"

Mache ich über den J1 eine Reset und machen den Bootloader wieder drauf, gleiches Problem.

Wie kann ich ihn komplett löschen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 28 April 2019, 20:27:24
Wieso will jeder immer gleich den Bootloader platt machen? Probier mal das:
Nimm mal die CUBEx4_BL.bin. Bei einem gescheiterten Flashversuch muss man übrigens den Bootloader nicht neu installieren. Einfach den Cube ausstecken, die Taste unten am Cube gedrückt halten und dann USB wieder einstecken.
Titel: Antw:culfw@ARM
Beitrag von: bigmo am 01 Mai 2019, 17:40:33
Hi Leute,

ich habe neuerdings ein Problem mit meinem geflashten Cube. Er vergisst immer wieder seine Netzwerkeistellungen (feste IP) und stellt sich auf DHCP zurück.
Ich habe schon neu geflasht und Eprom gelöscht aber das Phänomen bleibt.

Hatte das schon mal jemand?

Niemand eine Idee? Das macht mich noch verrückt. Dagegen war die amnesie des original Cube ja ein Segen...
Titel: Antw:culfw@ARM
Beitrag von: Kharim am 01 Mai 2019, 17:58:56
Welche Firmwareversion nutzt du?
Ich hatte/"habe" das Problem, dass meine Einstellung auf 433Mhz ständig verloren ging.
Dadurch neuen Cube gekauft und eine inzwischen aktuellere Firmware geflasht - bisher Ruhe.
Ich kann also leider nicht sagen, ob das anscheinende Rücksetzen der Einstellungen ein FW oder HW Problem war.

-> Firmware auf das aktuellste Build patchen
-> zu deinem Problem: MAC Adress-Reservierung am Router und Cube auf DHCP belassen....

Kahrim
Titel: Antw:culfw@ARM
Beitrag von: kotaro am 13 Mai 2019, 15:24:57
irgendwie komme ich nicht mehr an den ATMELSAM-Bain-SYSTEMPROGRAMMER ... Der Link fürht sofort auf die Hauptseite der Webseite.. somit kommt man da irgenwie nicht ran....

könnt ihr mir helfen?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 13 Mai 2019, 17:03:33
Bei Microchip suchen, oder einfach Google fragen:
https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/Atmel%20SAM-BA%20In-system%20Programmer (https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/Atmel%20SAM-BA%20In-system%20Programmer)
Titel: Antw:culfw@ARM
Beitrag von: kotaro am 13 Mai 2019, 18:35:46
Danke dir
Titel: Antw:culfw@ARM
Beitrag von: adn77 am 04 Juni 2019, 22:05:19
Habe ich riichtig verstanden, dass man an den MAX Cube auch 1wire Komponenten anschließen könnte, die mit der a-culfw abgefragt werden können?

Ich überlege, so zu einem günstgen Helligkeitssensor zu kommen...

Wahrscheinlich braucht man einen Busmaster, aber wie und wo schließt man den an?

Danke schonmal,
Alex
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 Juni 2019, 18:09:34
Die Schaltung ist die gleiche wie für den MapleCUN:
https://wiki.fhem.de/wiki/MapleCUx_und_1-wire (https://wiki.fhem.de/wiki/MapleCUx_und_1-wire)

Angeschlossen wird das an einem freien CC1100 Port. SDA an den CS Pin und SCL an den IN Pin. Belegung siehe board.h. Mittlerweile ist es auch egal, welchen Port man dafür nimmt. Der I2C Busmaster wird an allen Ports erkannt.

Frei Pins am Cube siehe:
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606 (https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606)
Titel: Antw:culfw@ARM
Beitrag von: phantom am 16 Juni 2019, 13:29:10
Hi,

@Mihca
das fertige 1.26.06 CUBE_BL.binläuft auf dem CUBe bei mir auch nicht, booted nach Flashen nicht mehr.
Die 1.26.05 läuft aber problemlos.

@telekatz
Liegt das evtl. am 1-wire autodetect? Warum sollte dann die 1.26.06 CUBEx4_BL.bin laufen, (tut es bei mir auch nicht); habe noch kein 1-wire Modul dran (kommt aber...)

Gruß Phantom
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 Juni 2019, 19:39:18
Mit der letzten Änderung funktioniert 1-wire nur noch mit Hardware Autodetect. Das ist bei CUBEx4_BL aktiviert, nicht aber bei CUBE_BL. Da bei CUBE_BL noch 1-wire aktiviert war, lief das nicht.
Ob ein 1-wire Modul angeschlossen ist oder nicht ist bei CUBEx4_BL egal. Das Modul wird von Hardware Autodetect erkannt.
Titel: Antw:culfw@ARM
Beitrag von: Mihca am 18 Juni 2019, 13:51:19
@phantom

ich habe 1.26.06 CUBEx4_BL.bin aus Zeitgründen noch nicht ausprobiert.

mfG Mihca
Titel: Antw:culfw@ARM
Beitrag von: Holzlenkrad am 19 Juni 2019, 18:05:36
Hat eigentlich jemand eine Idee, wie ich die Battery LED abschalten kann, oder noch besser eine sinnvolle Aufgabe geben kann (wie z.B. den Batterie-Status der Homematic-Geräte anzuzeigen :O )?

Wie ich die Power LED konfiguriere habe ich schon selbst raus gefunden.
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 07 Juli 2019, 14:58:10
Angeregt durch den Beitrag mit dem MSC Bootloader (https://forum.fhem.de/index.php/topic,101610.0.html) für den MapleCUL habe ich auch den Bootloader für den Cube überarbeitet und auf MSC umgestellt. Geflasht wird der neue Bootloader genauso wie der alte.

Die Firmware Dateien sind mit beiden Bootloadern kompatibel. Man kann also auch den alten Bootloader weiter benutzen.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 09 Juli 2019, 15:25:56
Ich habe heute nochmal seit langer Zeit versucht, die a-culfw für nanoCUL und CUBe auf dem RPi zu kompilieren. Da ich mittlerweile ein neu aufgesetztes System mit Buster habe, musste ich erstmal wieder alle benötigten Pakete zusammensuchen und installieren. (binutils-arm-none-eabi, gcc-arm-none-eabi, bossa-cli, libnewlib-arm-none-eabi, libstdc++-arm-none-eabi-newlib, gcc-avr, avr-libc)

Für den nanoCUL läuft auch alles. Beim Kompilieren des Bootloader für den CUBe kommt es aber zu einem Fehler beim Linken:
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [0011ccf0,0011ccf7] overlaps section .relocate LMA [0011ccf0,0011d25f]
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:125: CUBE_BL.elf] Fehler 1

Hat das Problem sonst noch jemand, bzw. gibt es eine Lösung dafür?

P.S.: Ein make direkt im Unterverzeichnis bootloader läuft durch und erstellt mir die bootloader_CUBE.bin
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 Juli 2019, 17:16:33
Wie groß ist die bootloader_CUBE.bin Datei, die dabei herauskam?
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 09 Juli 2019, 17:32:00
dietpi@fhem:~/src/a-culfw/culfw/Devices/CUBe$ ls -l bootloader_CUBE.bin
-rwxr-xr-x 1 dietpi dietpi 15720 Jul  9 17:28 bootloader_CUBE.bin
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 Juli 2019, 18:41:34
Die Datei ist zwar etwas größer als bei mir aber immernoch klein genug.
Ich denke, es könnte daran liegen, dass du eine andere GCC Version benutzt. Für die ARM Versionen sollte die GCC Version 5.4.1 verwendet werden.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 09 Juli 2019, 18:48:58
Ich habe einfach das entsprechende Paket installiert. Die GCC Version ist 7.3.1:
dietpi@fhem:~$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

Woran könnte es denn liegen, daß die bootloader_CUBE.bin zwar erstellt wird, es beim make direkt im CUBe-Verzeichnis beim Linken von CUBE_BL.bin zum Fehler kommt?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 Juli 2019, 19:59:11
Es liegt an der GCC Version, ich habe es ausprobiert. Mit Version 6.2.1 läuft es durch und mit Version 7.3.1 habe ich auch einen Fehler.
Die bootloader_CUBE.bin wird deshalb ohne Fehler erstellt, weil dort der Teil des Codes, der den Fehler verursacht, nicht enthalten ist.

Du kannst entweder eine ältere GCC Version verwenden oder folgende Änderung im Linkerscript versuchen:
SECTIONS

    .ARM.exidx : {
      . = ALIGN(4);
        __exidx_start = .;
        *(.ARM.exidx*)
        __exidx_end = .;
    } > flash
   
    .fixed :
    {
        . = ALIGN(4);
        _sfixed = .;
        *(.text*)
        *(.rodata*)
        *(.data.__malloc_av_)
        *(.data.__malloc_trim_threshold)
        *(.data.__malloc_sbrk_base)
        *(.data.__ctype_ptr__)
        *(.data.__global_locale)
        . = ALIGN(4);
        _efixed = .;
    } >flash
der Linker läuft damit durch. Ich habe aber nicht ausprobiert, ob der Code damit auch lauffähig ist.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 09 Juli 2019, 22:08:21
Danke! Jetzt lässt sich die Firmware kompilieren. Das Aufspielen des neuen Bootloader mit bossa hat auch geklappt.

Wenn ich das richtig verstehe, wird die neue Firmware nicht mehr mit einem Terminal Emulator wie minicom übertragen, sondern soll auf das neu angelegte Laufwerk kopiert werden.

Bei aktiviertem Bootloader wird jetzt ein Laufwerk erkannt:
[Di Jul  9 21:45:07 2019] usb 1-1.5: new full-speed USB device number 60 using dwc_otg
[Di Jul  9 21:45:07 2019] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=6129, bcdDevice= 1.00
[Di Jul  9 21:45:07 2019] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Di Jul  9 21:45:07 2019] usb 1-1.5: Product: ATMEL AT91 MSD
[Di Jul  9 21:45:07 2019] usb 1-1.5: Manufacturer: ATMEL
[Di Jul  9 21:45:07 2019] usb 1-1.5: SerialNumber: 0123456789AB
[Di Jul  9 21:45:07 2019] usb-storage 1-1.5:1.0: USB Mass Storage device detected
[Di Jul  9 21:45:07 2019] scsi host0: usb-storage 1-1.5:1.0
[Di Jul  9 21:45:08 2019] scsi 0:0:0:0: Direct-Access     ATMEL    Mass Storage MSD 0.01 PQ: 0 ANSI: 6
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: Attached scsi generic sg0 type 0
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] 8000 512-byte logical blocks: (4.10 MB/3.91 MiB)
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Write Protect is off
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] No Caching mode page found
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Assuming drive cache: write through
[Di Jul  9 21:45:08 2019]  sda:
[Di Jul  9 21:45:08 2019] sd 0:0:0:0: [sda] Attached SCSI removable disk

Jetzt habe ich /dev/sda gemountet und CUBE_BL.bin darauf kopiert. Nach einem umount bekomme ich mit dmesg einen Fehler angezeigt:
[Di Jul  9 21:57:42 2019] FAT-fs (sda): FAT read failed (blocknr 1)
[Di Jul  9 21:57:42 2019] FAT-fs (sda): unable to read boot sector to mark fs as dirty

Nach erneutem Anschliessen wird der CUBe nicht mehr erkannt:
[Di Jul  9 22:03:19 2019] usb 1-1.5: new full-speed USB device number 87 using dwc_otg
[Di Jul  9 22:03:19 2019] usb 1-1.5: device descriptor read/64, error -32
[Di Jul  9 22:03:19 2019] usb 1-1.5: device descriptor read/64, error -32
[Di Jul  9 22:03:19 2019] usb 1-1-port5: attempt power cycle
[Di Jul  9 22:03:20 2019] usb 1-1.5: new full-speed USB device number 88 using dwc_otg
[Di Jul  9 22:03:21 2019] usb 1-1.5: device not accepting address 88, error -32
[Di Jul  9 22:03:21 2019] usb 1-1.5: new full-speed USB device number 89 using dwc_otg
[Di Jul  9 22:03:21 2019] usb 1-1.5: device not accepting address 89, error -32
[Di Jul  9 22:03:21 2019] usb 1-1-port5: unable to enumerate USB device

Ist meine Vorgehensweise beim Installieren der Firmware falsch oder doch die kompilierte Firmware defekt?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 Juli 2019, 22:46:31
Teste es einfach mit der fertig compilierten Firmwaredatei aus dem a-culfw Archiv.
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 09 Juli 2019, 23:18:47
Ok, so wie es aussieht muß ich wohl erst eine ältere Version der Toolchain installieren. Mal sehen, wo ich was für den Pi finde.

Die von Dir kompilierte Version lässt sich installieren. Da ich aber 2 Cubes angeschlossen habe, muß ich die Firmware selbst kompilieren mit unterschiedlichen IDs. Der selbst kompilierte Bootloader funktioniert auf jeden Fall auch mit neuerer GCC Version.

Vielen Dank für die Hilfe!
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 11 Juli 2019, 21:09:55
Zur Info: Mit der Version 6.3.1 von arm-none-eabi-gcc kommt es auch zum Linker-Fehler:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [0011cf54,0011cf5b] overlaps section .relocate LMA [0011cf54,0011d4c3]
collect2: error: ld returned 1 exit status

Leider finde ich keine Version 6.2.1 für den Pi. Für die 6.3.1 musste ich mir schon extra aus den Debian-Sourcen ein Paket bauen. Für Buster gibt es nur die 7.3.1.

Wäre es vielleicht möglich,  mir die Firmware einmal mit USB_DESCRIPTOR_SN "0" zu kompilieren, damit ich beide Cubes betreiben kann?
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 15 Juli 2019, 10:26:55
Ich weiß zwar immer noch nicht, warum das Kompilieren auf dem Pi nicht mehr funktioniert,  aber auf meinem Laptop unter Ubuntu Bionic lässt sich eine  funktionierende Firmware auch mit v6.3.1 erstellen.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 21 Juli 2019, 14:42:27
Hi,

ich wollte gerade meinem bereits geflashten Max!Cube eine aktuelle Firmware verpassen. Ich hatte den Cube vor ein paar Tagen bereits nach dieser Anleitung erfolgreich geflasht, dann aber festgestellt, dass ich eine uralte Version runtergeladen hatte. Also bin ich mit dem Cube wieder an den Rechner, habe bei gedrückter Resettaste die Verbindung hergestellt und dachte nun geht das ganz simpel weiter. Tut's aber nicht.
Im Gerätemanager erscheint ein neues Gerät wie erwartet. Nennt sich Bossa Program Port (COM8). Scheint mir ein Treiber zu sein, den SAM-BA (v2.18) gleich mit installiert. Damit hat es beim ersten mal aber auch geklappt, den Bootloader zu installieren.
Ich bin davon ausgegangen, dass ich den Cube nicht wieder löschen muss, also habe ich Tera Term gestartet. Dort wird mir der Port auch angeboten, ich kann mich aber nicht dahin verbinden weil Tera Term "Cannot open COM8. Access denied." ausgibt. Auch wenn ich Tera Term als Administrator starte.
Ich hab dann über J1 die Firmware wieder gelöscht, um von Vorne zu beginnen. Wenn ich nun SAM-BA starte kann ich zwar einen Port auswählen (seltsamerweise werden mit dort sowohl \USBserial\COM8 als auch COM8 angeboten. Bei ersterem kommt eine Verbindung zustande, SAM-BA startet danach aber nicht. Im Taskmanager sehe ich einen Prozess laufen.
Gibt es noch andere Möglichkeiten, den Bootloader zu installieren? Irgendwie muss das Teil doch wieder zum fliegen kommen.

LG petjek
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 21 Juli 2019, 23:38:40
Man kann den Bootloader entweder mit SAM-BA oder mit einem JTAG Interface flashen.
Und wenn du den Bootloader neu flashst würde ich empfehlen, den neuen MSC Bootloader aus dem letzten Release 1.26.07 zu verwenden.
Titel: Antw:culfw@ARM
Beitrag von: petjek am 22 Juli 2019, 07:28:59
Ein JTAG Interface habe ich nicht. Und SAM-BA macht eben nicht das was es soll. Um genau zu sein macht SAM-BA eben nichts mehr nach der Auswahl des COM-Ports.


Gesendet von iPhone mit Tapatalk
Titel: Antw:culfw@ARM
Beitrag von: mahowi am 22 Juli 2019, 07:34:12
Wenn Du die Möglichkeit hast, einen Linux Rechner zu nutzen, geht es mit bossa. Mit Sam-ba unter Windows hatte ich auch dasselbe Problem wie Du.
Titel: Antw:culfw@ARM
Beitrag von: Mihca am 22 Juli 2019, 12:34:44
BOSSA unter Windows 10 64 funktioniert bei mir prima. SAM-BA funktioniert bei mir ebenfalls nicht.

http://www.shumatech.com/web/products/bossa (http://www.shumatech.com/web/products/bossa)
Titel: Antw:culfw@ARM
Beitrag von: petjek am 22 Juli 2019, 13:05:03
Hab's nach einenm Neustart des Rechners hin bekommen. Danke.
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 30 Juli 2019, 09:20:40
Wie  werden mit der aktuellen FW eigentlich inzwischen die beiden Schnittstellen ST1 & ST2 genutzt ?
Ich habe hier Antworten von 2015 gefunden das dort Debug Meldungen ausgegeben werden, trifft das noch so zu  ?
Bzw. gäbe es vllt auch beim Cube eine Möglichkeit wie beim Maple eine der beiden Schnittstellen transparent auf einem TCP Port durchzureichen ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 30 Juli 2019, 12:09:08
Die eine Schnittstelle wird immer noch als Debugschnittstelle genutzt. Die andere Schnittstelle kann alternativ zum USB Anschluss für die Kommunikation genutzt werden, z.B. für eine WLAN Cube mit einem ESP.
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 04 August 2019, 16:38:48
Moin!
Ich habe den ganzen Thread durchgelesen, aber leider verstehe ich immer noch nicht, wie ich zusätzliche Funkmodule an meinen Cube anschließen muß. Ich bin da eigentlich nicht auf den Kopf gefallen, aber ich kapiere die Zuordnung der Pins gar nicht. Ich sehe irgendwie keinen Zusammenhang zwischen der Board.H sowie der Platine, auch mit Hilfe von https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html) nicht. Kann mir das mal jemand für Dummies erklären? :-) Im wesentlichen fehlt mir irgendwie ein Bild mit den Bezeichnungen der Pins auf der Platine des Cubes, scheint mir. Eigenlich will ich in meinem Cube nur ein 433MHz und ein weiteres 868MHz Modul unterbringen. Vielen Dank!!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 04 August 2019, 19:53:09
Es ist eigentlich schon alles erklärt in dem Link von dir.

Hier nochmal die Bilder mit den freien Pins am Cube:
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606 (https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606)
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 05 August 2019, 18:35:16
Oh man, sorry, ich bin zu blöd :-) Ich habe den Thread gelesen, ohne mich anzumelden, da sieht man dann nicht einmal, dass man die Bilder nicht sieht .....
Jetzt verstehe ich es, allerdings fehlen da doch noch Pinbezeichnungen?  In dem verlinkten Blog sind ja z.B noch PA10 und PA11 eingezeichnet, aber wo finde ich denn z.B. PB28 oder PB20, wie sie z.B. defaultmäßig in der board.h deklariert sind? Wobei das jetzt nicht mehr so dramatisch ist, da ich jetzt kapiert habe, wo ich die Module anschließen muss, allerdings muss ich dann ja auch die Firmware selbst kompilieren. Wie ist denn die Standardbelegung in der Cube x4 firmware? Das würde es deutlich vereinfachen  ;D
Auf alle Fälle vielen Dank schon mal und nochmal sorry!!

MfG
Volker
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 05 August 2019, 19:03:39
PB20 und PB28 findest du auf der Unterseite:
https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711 (https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711)
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 09 August 2019, 15:35:55
Hallo, ich bins wieder :-)
Ich habe nun die Firmware selbst kompiliert, mit folgender board.h :
//External Transceivers
//PORT 1
#define CC1100_1_CS_PIN><------>  6
#define CC1100_1_CS_BASE<------>  AT91C_BASE_PIOA
#define CC1100_1_OUT_PIN    25
#define CC1100_1_OUT_BASE   AT91C_BASE_PIOB
#define CC1100_1_IN_PIN     5
#define CC1100_1_IN_BASE<------>  AT91C_BASE_PIOA

//PORT 2
#define CC1100_2_CS_PIN><------>  10
#define CC1100_2_CS_BASE<------>  AT91C_BASE_PIOA
#define CC1100_2_OUT_PIN    26
#define CC1100_2_OUT_BASE   AT91C_BASE_PIOB
#define CC1100_2_IN_PIN     11
#define CC1100_2_IN_BASE<------>  AT91C_BASE_PIOA

//PORT 3
#define CC1100_3_CS_PIN><------>  24
#define CC1100_3_CS_BASE<------>  AT91C_BASE_PIOB
#define CC1100_3_OUT_PIN    20
#define CC1100_3_OUT_BASE   AT91C_BASE_PIOB
#define CC1100_3_IN_PIN     28
#define CC1100_3_IN_BASE<------>  AT91C_BASE_PIOB

Und habe an Port1 ein 433MHz Modul angeschlossen. Nun kann ich wunderbar z.B. Intertechno schalten, aber es empfängt nichts? Ich habe hier am Schreibtisch eine Revolt-Steckdose, die meine eigentliche FHEM-Installation, noch über einen Nano-CUL, zuspammt, aber auf meiner Testinstallation mit dem CUBe kommt nichts an? Wo könnte der Fehler sein?
In der fhem.cfg sieht das folgendermaßen aus :
define CUL1_868 CUL 192.168.42.99:2323 1234
setuuid CUL1_868 5d4d748a-f33f-03a3-f3b5-3817ba96a3d2a9a0
attr CUL1_868 group Gateways
attr CUL1_868 hmId 308393
attr CUL1_868 icon cul_868
attr CUL1_868 model CUN
attr CUL1_868 rfmode SlowRF
attr CUL1_868 room TRX
#define CUL1_868 CUL IP:Port=2323 FHTIDattr MAPLECUL_USB_868 group Gateways


define CUL1Stack STACKABLE CUL1_868
setuuid CUL1Stack 5d4d748a-f33f-03a3-7015-c45f16c8ab2b62b3
attr CUL1Stack room TRX

define CUL2_433 CUL FHEM:DEVIO:CUL1Stack:9600 0000
setuuid CUL2_433 5d4d748a-f33f-03a3-ec61-8933ee20cd9496a7
attr CUL2_433 group Gateways
attr CUL2_433 icon cul_cul
attr CUL2_433 model CUN
attr CUL2_433 rfmode SlowRF
attr CUL2_433 room TRX
Danke für Tipps und generel für die coole Firmware!!

MfG
Volker
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 09 August 2019, 16:00:22
was sagt denn ein get CUL2_433 ccconf ?
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 09 August 2019, 16:07:15
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dBund ein

list CUL2_433
Internals:
   CMDS       bCFiAZNEGMKLUYRTVWXfz
   CUL2_433_MSGCNT 1
   CUL2_433_TIME 2019-08-09 15:54:01
   Clients    :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
   DEF        FHEM:DEVIO:CUL1Stack:9600 0000
   DeviceName FHEM:DEVIO:CUL1Stack:9600
   FD         7
   FHTID      0000
   FUUID      5d4d748a-f33f-03a3-ec61-8933ee20cd9496a7
   IODev      CUL1Stack
   IODevPort  9600
   IOReadFn   STACKABLE_IOReadFn
   NAME       CUL2_433
   NR         24
   PARTIAL   
   RAWMSG     25 2422
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.08 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 433MHz)
   initString X21
   MatchList:
     0:FS20V    ^81..(04|0c)..0101a001......00[89a-f]...
     1:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     2:BS       ^81..(04|0c)..0101a001a5cf
     3:FS20     ^81..(04|0c)..0101a001
     4:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     5:KS300    ^810d04..4027a001
     6:CUL_WS   ^K.....
     7:CUL_EM   ^E0.................$
     8:HMS      ^810e04......a001
     9:CUL_FHTTK ^T[A-F0-9]{8}
     A:CUL_RFR  ^[0-9A-F]{4}U.
     B:CUL_HOERMANN ^R..........
     C:ESA2000  ^S................................$
     D:CUL_IR   ^I............
     E:CUL_TX   ^TX[A-F0-9]{10}
     F:Revolt   ^r......................$
     G:IT       ^i......
     H:STACKABLE_CC ^\*
     I:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     J:SOMFY    ^Y[r|t|s]:?[A-F0-9]+
     K:CUL_TCM97001 ^s[A-F0-9]+
     L:CUL_REDIRECT ^o+
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2019-08-09 16:05:10   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
     2019-08-09 16:03:08   cmds             b C F i A Z N E G M K L U Y R T V W X f z
     2019-08-09 16:03:08   state           Initialized
Attributes:
   group      Gateways
   icon       cul_cul


Und im fhem.log sieht es so aus :
2019-08-09 16:02:59 CUL CUL1_868 cmds:  B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
2019-08-09 16:02:59 CUL CUL1_868 Initialized
2019-08-09 16:02:59 CUL CUL1_868 CONNECTED
2019-08-09 16:03:08 CUL CUL2_433 cmds:  b C F i A Z N E G M K L U Y R T V W X f z
2019-08-09 16:03:08 CUL CUL2_433 Initialized
2019-08-09 16:03:08 CUL CUL2_433 CONNECTED
2019-08-09 16:03:33 Global global ATTR CUL2_433 rfmode SlowRF
2019-08-09 16:03:52 Global global ATTR CUL1_868 rfmode SlowRF
2019-08-09 16:05:03 CUL CUL1_868 ccconf: freq:868.000MHz bWidth:325KHz rAmpl:42dB sens:4dB
2019-08-09 16:05:10 CUL CUL2_433 ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
Titel: Antw:culfw@ARM
Beitrag von: Wzut am 09 August 2019, 16:24:29
und
Hast du auch ../../clib/rf_receive_revolt.c  im Makefile?
Has_Revolt alleine reicht  nicht..
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 09 August 2019, 16:32:31
ich habe sonst an den Quellen nichts verändert, in der Make.conf steht das drin :
SRCS += ../../clib/rf_receive_revolt.c
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 09 August 2019, 18:10:00
Setz mal mit "raw e" den Inhalt des EEPROM zurück.
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 09 August 2019, 19:43:05
schon probiert  :) Ich habe noch einen neuen Cube und ein paar Funkmodule, ich baue nachher nochmal einen.
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 09 August 2019, 21:41:14
So, jetzt habe ich einen zweiten Cube mit einem 433MHz Modul verbunden, leider das gleiche Problem, senden geht, Empfangen nicht. Hüüülfeeeee!!! :-)
Liegt das evtl. daran, dass ich den Cube per LAN verbunden habe?? Ich dengle mal auf einen alten Raspi ein neues FHEM drauf und hänge den per USB dran.....

edit: Nö, auch per USB empfängt der meine Revolt-Steckdose auf 433MHz nicht.....

noch ein edit:
schalte ich dein eingebauten Transceiver, der ganz brav meinen ESA2000-Stromzähler empfängt, auf 433 MHz. kommen darüber (mit erstaunlicher Reichweite) meine beiden Revolt-Stecdosen sauber an, nur über das zusätzliche nicht. Heute kommt an einen Cube noch ein weiters 868MHz-Modul, mal schauen, wie sich das verhält.
edit again:
Nr1 auf das eingebaute Modul empfängt alle meine Lacrossesensonren dafür kommt fom ESA2000 nichts mehr. Nr1 auf dem 433Mhz-Modul bringt auch nichts. Umschalten des 433Mhz-Moduls auf MAX empfängt immerhine meine MAX!-Sachen.

Fortsetzung :
Nach Anschluss eines weiteren 868MHz-Moduls funktioniert dieses wie erwartet ..... nur das 433MHz-Modul will nicht. Ich tausche noch mal die Module zwischen den Ports, außerdem habe ich noch ein anderes 433MHz-Modul, anderer Hersteller, anderes Layout. Vielleicht liegt es ja an den verwendeten Modulen.

Ist das hier eigentlich normal?
CUL1_868 UNKNOWNCODE ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
CUL2_433 UNKNOWNCODE ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
CUL3_868 UNKNOWNCODE ? (? is unknown) Use one of b C A Z N E L Y V X f z

und beim ersten CUL1_868 sthet in den Internals

RAWMSG      **? (? is unknown) Use one of b C A Z N E L Y V X f z

werden die irgendwie Rückwärts durchnummeriert? Ich steig nicht durch.

Setze ich ein raw Nr1 auf den CUL3 ab, passiert im Log folgendes :
2019.08.10 12:57:17 5 : CUL/RAW: /*N019586533241AAAA0000248D0D
2019.08.10 12:57:17 4 : CUL_Parse: CUL2_433 *N019586533241AAAA0000248D0D
2019.08.10 12:57:17 5 : CUL2_433: dispatch *N019586533241AAAA0000248D0D
2019-08-10 12:57:17 CUL CUL3_868 UNKNOWNCODE N019586533241AAAA0000248D0D
2019.08.10 12:57:17 3 : CUL3_868: Unknown code N019586533241AAAA0000248D0D, help me!
2019-08-10 12:57:17 HMS HMS100TF_4316 temperature: 25.3
2019-08-10 12:57:17 HMS HMS100TF_4316 humidity: 50
2019-08-10 12:57:17 HMS HMS100TF_4316 battery: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 batteryState: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 type: HMS100TF
2019-08-10 12:57:17 HMS HMS100TF_4316 T: 25.3  H: 50  Bat: ok

Wieso tauch hier jetzt der CUL2 auf?
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 10 August 2019, 13:27:52
Wieso kann ich die Frequenz vom 3. CUL nicht setzen?

2019-08-10 13:26:42 CUL CUL3_868 freq 433.92
2019.08.10 13:26:42 5 : CUL/RAW: /*? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:42 4 : CUL_Parse: CUL2_433 *? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:42 5 : CUL2_433: dispatch *? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019-08-10 13:26:44 CUL CUL3_868 UNKNOWNCODE ? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:44 3 : CUL3_868: Unknown code ? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.08.10 13:26:44 5 : CUL/RAW: /*? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:44 4 : CUL_Parse: CUL2_433 *? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:44 5 : CUL2_433: dispatch *? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019-08-10 13:26:45 CUL CUL3_868 UNKNOWNCODE ? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 3 : CUL3_868: Unknown code ? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.08.10 13:26:45 5 : CUL/RAW: /*? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 4 : CUL_Parse: CUL2_433 *? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 5 : CUL2_433: dispatch *? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019-08-10 13:26:45 CUL CUL3_868 UNKNOWNCODE ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 3 : CUL3_868: Unknown code ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z, help me!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 10 August 2019, 13:54:07
Ist das hier eigentlich normal?
CUL1_868 UNKNOWNCODE ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
CUL2_433 UNKNOWNCODE ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
CUL3_868 UNKNOWNCODE ? (? is unknown) Use one of b C A Z N E L Y V X f z
Ja, das ist normal.

und beim ersten CUL1_868 sthet in den Internals

RAWMSG      **? (? is unknown) Use one of b C A Z N E L Y V X f z

werden die irgendwie Rückwärts durchnummeriert? Ich steig nicht durch.

Setze ich ein raw Nr1 auf den CUL3 ab, passiert im Log folgendes :
2019.08.10 12:57:17 5 : CUL/RAW: /*N019586533241AAAA0000248D0D
2019.08.10 12:57:17 4 : CUL_Parse: CUL2_433 *N019586533241AAAA0000248D0D
2019.08.10 12:57:17 5 : CUL2_433: dispatch *N019586533241AAAA0000248D0D
2019-08-10 12:57:17 CUL CUL3_868 UNKNOWNCODE N019586533241AAAA0000248D0D
2019.08.10 12:57:17 3 : CUL3_868: Unknown code N019586533241AAAA0000248D0D, help me!
2019-08-10 12:57:17 HMS HMS100TF_4316 temperature: 25.3
2019-08-10 12:57:17 HMS HMS100TF_4316 humidity: 50
2019-08-10 12:57:17 HMS HMS100TF_4316 battery: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 batteryState: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 type: HMS100TF
2019-08-10 12:57:17 HMS HMS100TF_4316 T: 25.3  H: 50  Bat: ok

Wieso tauch hier jetzt der CUL2 auf?

Nachrichten, die mit * beginnen, werden an den nächsten CUL weitergeleitet. Deshalb taucht die Nachricht des letzten CUL im LOG der vorhergehenden CULs auch auf.

Wieso kann ich die Frequenz vom 3. CUL nicht setzen?
Weil der 3. CUL beim Cube kein SlowRF kann.
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 10 August 2019, 14:04:34
Danke! Jetzt kapiere ich es. Dann ergibt es auch keinen Sinn, zum Testen den 433MHz an die 3. Stelle zu hängen, weil Revolt un IT SlowRF benötigen,richtig? Dann nehme ich mal meinen  3.Cube, und probiere es nochmal mit dem anderen Modultyp.
Titel: Antw:culfw@ARM
Beitrag von: vklaffehn am 11 August 2019, 14:54:12
Moin!
Erfolgsmeldung! :-)
Es scheint tatsächlich an meinen 433MHz-Modulen zu liegen. Ein dritter Cube mit einem anderen Modultyp (diese Bauform : https://eckstein-shop.de/Wireless-RF-Transceiver-Module-433Mhz-CC1101-CC1100-Antenna?curr=EUR&gclid=Cj0KCQjw-b7qBRDPARIsADVbUbXDPXdv8Rw6insIcUDx8DB6YalSAFyHKFfdMi1jh4s-P41tXC4Q-TkaAo2oEALw_wcB (https://eckstein-shop.de/Wireless-RF-Transceiver-Module-433Mhz-CC1101-CC1100-Antenna?curr=EUR&gclid=Cj0KCQjw-b7qBRDPARIsADVbUbXDPXdv8Rw6insIcUDx8DB6YalSAFyHKFfdMi1jh4s-P41tXC4Q-TkaAo2oEALw_wcB)) läuft wie gewünscht! Ich hänge mal Bilder von meiner Verkabelung an.  Und für die Leute, die aus dem Blogbeitrag auf lötzimmer.de nicht schlau geworden sind : Im Wesentlichen fehlt da die Pinbelegung des verwendeten Moduls, diese habe ich hier auch mal angehängt.
Titel: Antw:culfw@ARM
Beitrag von: meldelinie am 12 September 2019, 18:38:15
Hallo,

ich will mir noch eine Wetterstation zulegen, am besten eine mit 433Mhz weil dort die Reichweite am besten ist.

Nach dem Wiki https://wiki.fhem.de/wiki/Ventus_Wetterstation_433MHz#W132 (https://wiki.fhem.de/wiki/Ventus_Wetterstation_433MHz#W132) ist das Auswertemodul "CUL_TCM97001".

In der board.h https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)

findet sich der passende Eintrag mit TCM97001

#define _433MHZ
#  if defined(_433MHZ)
#    define HAS_TCM97001
#    define HAS_IT
#    define HAS_HOMEEASY
#    define HAS_BELFOX
#    define HAS_MANCHESTER
#    define HAS_REVOLT
# endif

Ich wollte also einfach ein 433 Mhz CC1101  an Port3 anschliessen damit die Wetterstation empfangen.

Aber nach diesem Wiki https://wiki.fhem.de/wiki/SIGNALduino (https://wiki.fhem.de/wiki/SIGNALduino) funktioniert es nur mit einem Signalduino der auf ATmega basiert. Auch im Forum fand ich bei der Suche nach CUL_TCM97001 immer nur den Verweis auf den Signalduino.

Da bin ich jetzt verwirrt - kann ich die Wetterstation emfangen ?
Titel: Antw:culfw@ARM
Beitrag von: Parador am 16 September 2019, 20:10:48
Hallo Zusammen,
nachdem ich noch einen vergessenden Cube hatte habe ich mich gestern drangemacht und versucht ihn doch noch nützlich zu machen.
Ich arbeite unter Win10 und bin mit Sam-ba 2.18 nicht weitergekommen.
Als ich dann Bossa 1.9.1 benutzte konnte ich m.M. nach den Bootlader erfolgreich flashen.
Wenn ich dann den Cube wieder vom USB trenne und wieder anstecke (egal ob mit oder ohne gedrückten Reset-Button) blinkt er hektisch grün, Win10 macht auch das Geräusch eines neuen Gerätes, allerdings zeigt der Eintrag im Geräte-Manager ein tragbares Geräte mit Laufwerksbuchstaben "G:" Nach einiger Zeit scheint es einen Neustart zu geben, Win10 macht wieder das Geräusch eines neuen Gerätes, aber wieder wird nichts anderes angezeigt.
Weder Tera Term noch andere XModem fähige Terminalp. kriegen eine Verbindung.
Was mache ich falsch, bzw. was muss ich machen um die aktuelle aculfw draufzubekommen? Wer hat Ideen und kann mir hefen?
Vielen Dank im Voraus!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 16 September 2019, 20:37:54
Das ist der neue MSC Bootloader. Zum flashen muss man nur die Firmwaredatei auf das neue Laufwerk kopieren.
Titel: Antw:culfw@ARM
Beitrag von: Parador am 16 September 2019, 21:15:51
Sorry wenn ich das irgendwo überlesen habe. Jetzt leuchtet eine konstant die andere blinkt langsam.
Im Geräte Manager erscheint AT91 USB to Serial Converter
Titel: Antw:culfw@ARM
Beitrag von: f-zappa am 18 September 2019, 14:52:21
Moin, ich bin gestern auf diesen Thread gestoßen und habe daraufhin bei ebay einen Cube gekauft. Grund ist, dass ich immer wieder Probleme mit meinen Homematic-Gateways habe. Derzeit habe ich einen LAN-Konfigurationsadapter, der je nach Tagesform ständig neu startet (Kondensatoren tauschen hat nix gebracht) und einen ESP mit HM-MOD-RPI-PCB, der sich aber gelegentlich aufhängt. Jetzt will ich also mit dem geflashten Cube mein Glück versuchen.

Ich habe heute in diesem und einigen anderen Threads quergelesen und auch im Wiki gestöbert . Oft wird von CUL/CUN für Homematic abgeraten oder zumindestens eine spezielle Firmware (ts-culfw) empfohlen, aber auf dem Cube läuft ja wohl eine andere (a-culfw). Vieles, was ich gelesen habe ist aber schon einige Jahre alt und ich frage mich, inwiefern es noch aktuell ist. Meine Umgebung umfasst geschätzt 30 HM-Komponenten, einiges davon mit AES. Ist das mit culfw@arm realistisch zu betreiben oder soll ich das gleich vergessen? Wenn ich es richtig verstanden habe, kann ich den Cube sowohl über USB als auch über LAN verbinden - macht das einen Unterschied in der Zuverlässigkeit, weil fhem zB das Timing über USB besser steuern kann?



Titel: Antw:culfw@ARM
Beitrag von: f-zappa am 19 September 2019, 18:24:50
So, mein Cube ist angekommen. Direkt geflasht und integriert.
Nun erwäge ich, bei allen anderen IOdevs einfach mal den Stecker zu ziehen und zu gucken, ob der Cube das packt.
Titel: Antw:culfw@ARM
Beitrag von: f-zappa am 19 September 2019, 21:49:22
Nun erwäge ich, bei allen anderen IOdevs einfach mal den Stecker zu ziehen und zu gucken, ob der Cube das packt.

Ernüchterung und Rückbau.

Alles, was AES braucht, funktioniert mit dem Cube via LAN im Grunde nicht. Da das überall zu lesen ist, hat es mich nicht wirklich überrascht.

Via USB würde alles gut, dachte ich. Leider konnte ich den Cube via USB nicht in meinem FHEM ansprechen (läuft als VM in ESXi). Das durchgeschliffene USB-Gerät wird erkannt, beim öffnen friert FHEM allerdings ein (wenn man via screen o.ä. von Hand verbinden möchte, passiert das gleiche). Auch dieser Effekt scheint bekannt zu sein - im Forum und anderswo wird empfohlen, die VM mit einem USB 3.0 Host statt 2.0 zu konfigurieren und/oder das "neue" USB-Modul von ESXi abzuschalten (esxcli system module set -m=vmkusb -e=FALSE) - allerdings ändert das nichts.

Hat noch jemand einen Tipp?
Hab ich mir für ~20€ einen formschönen Briefbeschwerer gekauft?
Kann ich mit dem Ding irgendwas anderes nettes anfangen?
Titel: Antw:culfw@ARM
Beitrag von: softcat am 29 September 2019, 21:08:38
Ich habe eine kurze Frage zu meinem Cube.

ich habe wie im Thread weiter oben bzw. unter https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html ein weiteren CC1101 angelötet.

board.h angepasst und Firmware sowie Bootloader compiliert.

Nach kurzschließen des J1 Reset PINs den Bootloader mittels Bossa aufgespielt.

Nach Neuanschließen öffnet sich auch wie erwartet ein neues Laufwerk in Windows, in das ich die Firmwaredatei ziehe. Diese wird scheinbar auch eingespielt, D1 leuchtet direkt danach dauerhaft.

Jetzt aber:
Nach erneuten Anschließen an USB blinkt D1 direkt schnell (ohne Drücken des rückseitigen Tasters) und es öffnet sich wieder das Laufwerksfenster.

Nach einigem Probieren folgende Beobachtungen:
Gleiches Problem beim Flashen der vorkompilierten Firmware.
Gleiches Problem beim Verwenden des Prä-MSC Bootloaders. Einspielen der Firmware mittels Teraterm scheinbar erfolgreich. Nach Neuverbinden das gleiche Spiel mit Blinken von D1.


Das Gerät verhät sich so, als der Taster dauerhaft geschlossen wäre. Kurz durchgemessen: er funktioniert.

Hat jemand irgendeine Idee, woran dies liegen könnte?

Tausen Dank!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 29 September 2019, 22:04:24
Es schon mal ohne den zusätzlichen CC1101 probiert?
Titel: Antw:culfw@ARM
Beitrag von: softcat am 30 September 2019, 21:05:10
Es schon mal ohne den zusätzlichen CC1101 probiert?

Jetzt steht ich irgendwie auf dem Schlauch. Ich hab den CC1101 entfernt: gleiches Problem.

Auf dem CuBE hatte ich vor längerer zeit schon mal (vor Modifikation) eine ätere Version der CUBe Firmware erfolgreich laufen.

Vielleicht ein Hardware Defekt, obwohl eigentlich alle ehemaligen Lötstellen gut aussehen...

Kann man eigentlich irgendwelche Debug-Ausgaben beim Start des CUBe bekommen?   

Grüße!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 01 Oktober 2019, 11:47:33
Debugausgaben gibt es an ST2. Allerdings hat der Bootloader selbst keine Debugausgaben, das verbraucht nur unnötig Platz.

Für Debugausgaben musst du im Makefile TARGETSTART und TRACE_LEVEL anpassen, den Bootloader neu compilieren und auch die a-culfw mit neuer TARGETSTART Adresse erstellen.
Titel: Antw:culfw@ARM
Beitrag von: Nitaro am 01 Oktober 2019, 18:10:19
Hallo zusammen,

ich habe da ein Problem mit den hm-cc-rt-dn Thermostaten.
Ich betreibe zwei umgflashte Cubes mit V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54).
Sobald ich bei den Heizkörperthermostaten ein getConfig im Clima Channel mache (HM_XY000_Clima)
bekomme ich "RESPONSE TIMEOUT:RegisterRead". Das gleiche Problem habe ich mit der vorherigen Firmware V 1.26.06.
Andere Versionen habe ich nicht versucht.

Sobald ich die Thermostate auf den nanoCUL verbinden lasse funktioniert alles tadellos.

Gibt es Einschränkungen bei dem Cube ?
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 01 Oktober 2019, 21:16:10
Nein, da gibt es keine Einschränkungen beim Cube. Und bei meinen Thermostaten bekomme ich kein "RESPONSE TIMEOUT:RegisterRead".
Titel: Antw:culfw@ARM
Beitrag von: Nitaro am 02 Oktober 2019, 08:23:41
Ok, gut.
Wie kann ich denn mit dem Cube am besten "einfangen" wo der Fehler liegen könnte ?
fhem.log verbose 5 zeigt mir nicht den Fehler. Kann man irgendetwas einstellen wo man dann
den Fehler sehen könnte ?
Titel: Antw:culfw@ARM
Beitrag von: softcat am 02 Oktober 2019, 18:45:14
Debugausgaben gibt es an ST2. Allerdings hat der Bootloader selbst keine Debugausgaben, das verbraucht nur unnötig Platz.

Für Debugausgaben musst du im Makefile TARGETSTART und TRACE_LEVEL anpassen, den Bootloader neu compilieren und auch die a-culfw mit neuer TARGETSTART Adresse erstellen.

Tausend Dank!

Und ich habe leider noch eine kurze Frage für Doofe:

Könntest du mir ganz kurz ein Beispiel für die Werte für TARGETSTART und TRACE_LEVEL geben? (welche ich ja wahrscheinlich in  der "culfw/Devices/CUBe/bootloader/Makefile" anpasse). Voreingestellt ist ja 0x104000 für TARGETSTART und TRACE_LEVEL 0.

Und wo passe ich TARGETSTART für a-culfw an?

Sorry, ich habe keine Ahnung von Mikrocpntrollerprogrammierung...  :o
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 02 Oktober 2019, 20:52:40
Nimm für TRACE_LEVEL 5 und stell TARGETSTART auf 0x108000. Damit darf der Bootloader maximal 32K groß werden.
TARGETSTART für die a-culfw wird im Linker Script CUBE_BL_flash.lds im Abschnitt MEMORY eingestellt.
Titel: Antw:culfw@ARM
Beitrag von: softcat am 02 Oktober 2019, 23:27:21
Nimm für TRACE_LEVEL 5 und stell TARGETSTART auf 0x108000. Damit darf der Bootloader maximal 32K groß werden.
TARGETSTART für die a-culfw wird im Linker Script CUBE_BL_flash.lds im Abschnitt MEMORY eingestellt.

Danke, hat geklappt.

Log, wenn ich den geflashten CUBe an USB hänge:

CUBELOADER gestartet
-I- -- Compiled: Oct  2 2019 22:27:54 --
-I- Flash lock 00
-I- Flash memory 00108000:E59F006C
-I- RAM memory 00200000:AA
-I- TA2 off
-I- Chip ID 275B0940
-I- Chip ID Extention 00000000
-D- LUN SDRAM
-I- LUN init
-I- 1 Medias defined
-I- MSD init
MSDReset USBD_Init
Res Res EoBRes CfgEpt0 NewReq Std gDesc Dev EoBRes CfgEpt0 NewReq Std sAddr SetAddr(18) NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Str3 NewReq Std gDesc Str0 NewReq Std gDesc Str2 NewReq Std gDesc Qua -W- Sta 0x888A8 [0] -W- _ NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std gDesc Str0 NewReq Std gDesc Str0 NewReq Std gDesc Str3 NewReq Std gDesc Str3 NewReq Std sCfg SetCfg(1) CfgEpt1 CfgEpt2 MSDReset NewReq gMaxLun -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
S-W- Sta 0x8628 [2] NewReq ClrFeat Hlt Std cFeat Hlt taIN -D- Cbk -D- Cbk ReqSense -D- Cbk ReqSense -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
S-W- Sta 0x8E28 [2] NewReq ClrFeat Hlt Std cFeat Hlt taIN -D- Cbk -D- Cbk ReqSense R-D- Cbk eqSense -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23

Danach habe ich die Firmware über JP1 zurückgesetzt. Den Bootloader geflasht und die Firmware über das Netzlaufwerk eingespielt.

Wenn ich jetzt den USB Stecker ab und anstecke funktioniert der CUBe, aber nur solange er ohne Unterbrechung über ST2 mit Strom versorgt bleibt:

-I- CUBe
-I- Compiled: Oct  2 2019 22:25:55 --
-I- init Flash
-I- Initializing the SPI and AT45 drivers
-I- At45 enabled
-I- SPI interrupt enabled
-I- Waiting for a dataflash to be connected ...
-I- AT45DB041D detected
-I- Device identifier: 0x0000241F
-I- EE Magic: 1 26 Start 792
-I- Flash Serial: 3e6a0937
-I- init Timer
-I- init EEprom
-I-  - MAC 0:80:41:6a:9:37
-I- ** Valid PHY Found: 1
-I-  DM9161_ResetPhy
-I- init USB
-I- CDCDSerialDriver_Initialize
USBD_Init
-I- PMC_EnablePeripheral: clock of peripheral 6 is already enabled
-I- init Complete
Res EoBRes CfgEpt0 NewReq Std gDesc Dev EoBRes CfgEpt0 NewReq Std sAddr SetAddr(19) NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Str0 NewReq Std gDesc Str1 NewReq Std gDesc Qua -W- Sta 0x888A8 [0] -W- _ NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std sCfg SetCfg(1) CfgEpt3 CfgEpt1 CfgEpt2 ConfigurationChanged NewReq gLineCoding NewReq sControlLineState(0, 0) NewReq sLineCoding NewReq gLineCoding

Sobald ist den CUBe komplett stromlos mache blinkt D1 wieder schnell und es öffnet sich das Netzlaufwerk zum einspielen der Firmware.

Log:
-I- -- Compiled: Oct  2 2019 22:27:54 --
-I- Flash lock 00
-I- Flash memory 00108000:E59F006C
-I- RAM memory 00200000:AA
-I- TA2 off
-I- Chip ID 275B0940
-I- Chip ID Extention 00000000
-D- LUN SDRAM
-I- LUN init
-I- 1 Medias defined
-I- MSD init
MSDReset USBD_Init
Res Res EoBRes CfgEpt0 NewReq Std gDesc Dev EoBRes CfgEpt0 NewReq Std sAddr SetAddr(22) NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Str3 NewReq Std gDesc Str0 NewReq Std gDesc Str2 NewReq Std gDesc Qua -W- Sta 0x888A8 [0] -W- _ NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std gDesc Str0 NewReq Std gDesc Str0 NewReq Std gDesc Str3 NewReq Std gDesc Str3 NewReq Std sCfg SetCfg(1) CfgEpt1 CfgEpt2 MSDReset NewReq gMaxLun -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
S-W- Sta 0x8628 [2] NewReq ClrFeat Hlt Std cFeat Hlt taIN -D- Cbk -D- Cbk ReqSense R-D- Cbk eqSense -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
-W- Sta 0x8E28 [2] NewReq ClrFeat Hlt Std cFeat Hlt StaIN -D- Cbk -D- Cbk ReqSense R-D- Cbk eqSense -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
-W- Sta 0x8E28 [2] NewReq ClrFeat Hlt Std cFeat Hlt StaIN -D- Cbk -D- Cbk ReqSense R-D- Cbk eqSense -D- Cbk -D- Cbk Inquiry Sen-D- Cbk ding Inquiry Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk -W- SBC_GetCommandInformation: Page code not supported(0x1C)
ModeSense(6) -W- MSDD_ProcessCommand: Unknown command 0x1A
-W- Sta 0x8628 [2] NewReq ClrFeat Hlt Std cFeat Hlt StaIN -D- Cbk -D- Cbk ReqSense -D- Cbk ReqSense -D- Cbk -D- Cbk -W- SBC_GetCommandInformation: Page code not supported(0x08)
ModeSense(6) -W- MSDD_ProcessCommand: Unknown command 0x1A
S-W- Sta 0x8E28 [2] NewReq ClrFeat Hlt Std cFeat Hlt taIN -D- Cbk -D- Cbk ReqSense R-D- Cbk eqSense -D- Cbk -D- Cbk -W- SBC_GetCommandInformation: Page code not supported(0x08)
ModeSense(6) -W- MSDD_ProcessCommand: Unknown command 0x1A
-W- Sta 0x8E28 [2] NewReq ClrFeat Hlt Std cFeat Hlt StaIN -D- Cbk -D- Cbk ReqSense -D- Cbk ReqSense -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk Read(10) LUNRead(0) LUNRead:0 len:1
-D- Cbk Read(10) Ok Read(10) Sendi-D- Cbk ng Read(10) Sent Read(10) Next -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) -D- Cbk Sending RdCapacity(10) Sent -D- Cbk -D- Cbk Read(10) LUNRead(2) LUNRead:2 len:1
-D- Cbk Read(10) Ok Read(10) Sendi-D- Cbk ng Read(10) Sent Read(10) Next -D- Cbk -D- Cbk RdCapacity(10) -D- Cbk Sending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk Read(10) LUNRead(0) LUNRead:0 len:1
-D- Cbk Read(10) Ok Read(10) Sendi-D- Cbk ng Read(10) Sent Read(10) Next -D- Cbk -D- Cbk Read(10) LUNRead(0) LUNRead:0 len:1
-D- Cbk Read(10) Ok Read(10) Sendin-D- Cbk g Read(10) Sent Read(10) Next -D- Cbk -D- Cbk -W- MSDD_PreProcessCommand: Case 5
ModeSense(6) -D- Cbk ModeSense(6) Wait StallIn -W- Sta 0x8628 [2] NewReq ClrFeat Hlt Std cFeat Hlt -D- Cbk -D- Cbk -D- Cbk -D- Cbk RdCapacity(10) -D- Cbk Sending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk Read(10) LUNRead(0) LUNRead:0 len:1
-D- Cbk Read(10) Ok Read(10) Sendi-D- Cbk ng Read(10) Sent Read(10) Next -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk RdCapacity(10) S-D- Cbk ending RdCapacity(10) Sent -D- Cbk -D- Cbk Read(10) LUNRead(0) LUNRead:0 len:1

Hilft das weiter?

Nochmals danke für die tolle Unterstützung hier!
Titel: Antw:culfw@ARM
Beitrag von: Telekatz am 03 Oktober 2019, 11:13:34
-I- RAM memory 00200000:AADer Bootloader findet am RAM Anfang den Wert 0xAA. Dadurch wird der Bootloader gestartet. Sollte eigentlich nach dem Einstecken der Stromversorgung nicht passieren.

Teste mal, ob bei aktivierten Bootloader nach ein paar Minuten der Cube automatisch neu starten und in die Firmware springt.

Auch könntest du mal probieren, Zeile 238 in bootloader.c zu ändern:
  *ram = 0x55;
Wenn das nichts hilft, kann man die Überprüfung auf 0xAA auch deaktivieren in Zeile 164-166:
//      if(*ram != 0xaa) {
        jump_to_target();
//      }
Titel: Antw:culfw@ARM
Beitrag von: softcat am 03 Oktober 2019, 12:10:21
Teste mal, ob bei aktivierten Bootloader nach ein paar Minuten der Cube automatisch neu starten und in die Firmware springt.

Das funktioniert, nach ein paar Minuten startet die Firmware und der Cube funktioniert einwandfrei.

Auch könntest du mal probieren, Zeile 238 in bootloader.c zu ändern:
  *ram = 0x55;

Das hat keine Änderung gebracht, nur der Bootloader startet.

Wenn das nichts hilft, kann man die Überprüfung auf 0xAA auch deaktivieren in Zeile 164-166:
//      if(*ram != 0xaa) {
        jump_to_target();
//      }

Das funktionert einwandfrei, die Firmware startet direkt.

Hmm, gibt es eine Idee, warum das bei meinen Gerät angepasst werden muss? Ich kann damit gut leben aber irgendeine Ursache muss es ja dafür geben...

Vielen Dank, der CUBEe ist gerettet  :)

Titel: Antw:culfw@ARM