Beitrag von: Telekatz am 22 Juni 2015, 22:42:29
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):
- 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.
- SAM-BA als Administrator ausführen. COM Port auswählen und „at91sam7x256-ek“ als Board auswählen und auf Connect Drücken.
- Auf der Registerkarte Flash bei „Send File Name“ die Datei bootloader_CUBE.bin auswählen und auf Send File drücken. Die folgende Frage, ob das Flash gelockt werden soll, mit nein beantworten.
- Im Feld Scripts „Boot from Flash (GPNVM2)“ auswählen und auf Execute drücken.
- SAM-BA schließen und USB Kabel lösen.
Bootloader (HM-CFG-USB-2):
- Jumper J2 auf dem Stick verbinden und den Stick kurz ein- und wiederausstecken 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! - Jumper J2 lösen und Jumper J1 verbinden. Den Stick für etwa 10s einstecken um den internen Bootloader zu aktivieren. Stick ausstecken und Jumper J1 lösen.
- Stick wieder einstecken. Falls jetzt kein neuer COM Port im Gerätemanager erscheint muss ein 10kOhm Widerstand zwischen +5V und Data+ am USB Stecker verbunden werden.
- SAM-BA als Administrator ausführen. COM Port auswählen und „at91sam7s128-ek“ als Board auswählen und auf Connect Drücken.
- Auf der Registerkarte Flash bei „Send File Name“ die Datei bootloader_HM_CFG.bin auswählen und auf Send File drücken. Die folgende Frage, ob das Flash gelockt werden soll, mit nein beantworten.
- SAM-BA schließen und Stick entfernen.
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)
Beitrag von: chris1284 am 23 Juni 2015, 07:35:48
Wie sehen spätere updates der firmware aus? Hex-file vom cul und los geht denke ich nicht
Beitrag von: Telekatz am 23 Juni 2015, 12:00:20
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.
Beitrag von: Wzut am 24 Juni 2015, 16:40:14
Wenn ich deine Anleitung richtig verstanden habe ist es allerdings dann vorbei mit Netzwerkzugriff, da dann der Datenaustausch noch via USB läuft ?
Beitrag von: Telekatz am 24 Juni 2015, 20:07:49
Beitrag von: ccier am 29 Juni 2015, 14:44:52
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?
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.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.
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.
Beitrag von: Telekatz am 06 Juli 2015, 20:59:36
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?
Beitrag von: Loctotex am 13 Juli 2015, 22:31:06
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.
Beitrag von: stenny73 am 12 August 2015, 12:55:32
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
Beitrag von: Telekatz am 12 August 2015, 15:57:09
Beitrag von: stenny73 am 12 August 2015, 16:02:00
Dann wird der zweite heute umgebastellt....
Nachtrag: Und läuft..... Perfekt
Beitrag von: Blizzard am 22 August 2015, 21:14:17
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
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 . :)
Beitrag von: Telekatz am 23 August 2015, 20:23:15
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.
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
Beitrag von: Telekatz am 23 August 2015, 21:01:44
Beitrag von: adb76 am 25 August 2015, 22:43:21
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ß.
Beitrag von: Telekatz am 25 August 2015, 23:07:28
Beitrag von: adb76 am 26 August 2015, 20:46:17
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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.
Beitrag von: Telekatz am 26 August 2015, 20:59:36
Beitrag von: Blizzard am 26 August 2015, 21:07:43
Ich betreibe den "Cube-CUNO" zusammen mit Homegear um ein paar Homematic-Geräte zu steuern. :)
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:
Code: [Auswählen]
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.
Beitrag von: stenny73 am 28 August 2015, 20:14:02
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
Beitrag von: Joachim am 29 August 2015, 16:18:14
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
Beitrag von: Telekatz am 29 August 2015, 16:41:46
Beitrag von: Joachim am 29 August 2015, 17:14:47
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:
Code: [Auswählen]
###############################################################
#####
##### 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).dmake gestartet, und geflasht.--> es geht!
Gruß Joachim
Beitrag von: chapelhill am 10 September 2015, 19:14:04
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
Beitrag von: Telekatz am 10 September 2015, 23:09:03
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
Beitrag von: chapelhill am 11 September 2015, 08:36:50
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.
Beitrag von: Telekatz am 11 September 2015, 10:03:14
Did you also try to use the bootloader from build 151?
Beitrag von: chapelhill am 11 September 2015, 11:06:54
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
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.
Beitrag von: chapelhill am 11 September 2015, 16:50:16
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?
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?
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 AT91SSAM7X512The firmware is intended to run on the AT91SAM7X256.
The version number written on my circuit board is 1113596J and not 1113596H
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.
Beitrag von: chapelhill am 11 September 2015, 17:57:09
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.
Beitrag von: Telekatz am 11 September 2015, 19:16:02
Beitrag von: Joachim am 11 September 2015, 19:56:37
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
Beitrag von: Telekatz am 11 September 2015, 20:31:03
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
Beitrag von: Joachim am 11 September 2015, 21:02:35
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
Beitrag von: Telekatz am 11 September 2015, 21:55:28
Beitrag von: Joachim am 11 September 2015, 22:31:55
Beitrag von: Telekatz am 11 September 2015, 23:34:37
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.
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
Beitrag von: Telekatz am 12 September 2015, 13:12:16
könntest du mal den angefügten Bootloader ausprobieren.
Gruß
Alex
Beitrag von: Joachim am 12 September 2015, 14:04:12
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
Beitrag von: Telekatz am 12 September 2015, 19:39:59
Beitrag von: Joachim am 13 September 2015, 11:55:08
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
Beitrag von: Telekatz am 13 September 2015, 13:23:37
Anbei der modifizierte Bootloader und die dazu passende a-culfw.
Beitrag von: Joachim am 13 September 2015, 19:10:47
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
Beitrag von: Telekatz am 13 September 2015, 20:50:13
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?
Beitrag von: Joachim am 13 September 2015, 21:05:45
Hier die beiden Log's passend zu den Bootloadern.
Dann ist es jetzt wohl gelöst?
Gruß Joachim
Beitrag von: Telekatz am 13 September 2015, 21:42:29
ja, passt. Problem gelöst. Danke fürs Testen.
Anbei dann auch der korrigierte Bootloader für die veröffentlichte a-culfw.
Gruß Alex
Beitrag von: Joachim am 13 September 2015, 21:58:37
rennt auch mit selbst kompilierter Firmware.
Hast Du super gemacht, danke Joachim
Beitrag von: Bujakka am 13 September 2015, 22:19:20
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
Beitrag von: Telekatz am 13 September 2015, 22:57:29
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.
Beitrag von: Telekatz am 13 September 2015, 23:11:46
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.
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?!
Beitrag von: Telekatz am 14 September 2015, 11:46:20
Beitrag von: Basegate am 18 September 2015, 22:15:10
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
Beitrag von: Joachim am 21 September 2015, 10:10:29
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
Beitrag von: larsi am 24 September 2015, 08:58:22
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:
Code: [Auswählen]
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
Beitrag von: Funsailor am 24 September 2015, 17:02:59
ich wollte den CUBe mal kompilieren, allerdings bricht der compiler mit der folgenden Meldung an:
Code: [Auswählen]
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
Beitrag von: Telekatz am 24 September 2015, 21:06:53
Beitrag von: neckartown am 27 September 2015, 15:56:51
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.
Beitrag von: Basegate am 27 September 2015, 20:59:06
Beitrag von: Telekatz am 27 September 2015, 21:28:22
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.
Beitrag von: neckartown am 27 September 2015, 21:56:48
Gesendet von meinem SM-P600 mit Tapatalk
Beitrag von: Ranseyer am 29 September 2015, 14:18:28
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-pciIch 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).
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
Somit ist meine erste Frage natürlich ober der Bootloader passt, oder ab er angepasst werden muss auf den größeren Flash.
Beitrag von: Telekatz am 29 September 2015, 15:50:56
Beitrag von: Basegate am 01 Oktober 2015, 19:45:52
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
Beitrag von: Telekatz am 01 Oktober 2015, 20:50:15
Code: [Auswählen]
#define _433MHZ
# if defined(_433MHZ)
# define HAS_TCM97001
# define HAS_IT
# define HAS_HOMEEASY
# define HAS_OREGON3
# define HAS_BELFOX
# define DEBUG_SYNC
# endif
Beitrag von: Basegate am 01 Oktober 2015, 21:02:52
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? ;-)
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.
Beitrag von: strauch am 03 Oktober 2015, 09:46:19
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
Beitrag von: Telekatz am 03 Oktober 2015, 10:00:06
Beitrag von: Basegate am 03 Oktober 2015, 13:16:16
du bist echt der beste. der 433mhz empfang funktioniert super.
Beitrag von: mannil am 07 Oktober 2015, 21:18:56
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
Beitrag von: Telekatz am 08 Oktober 2015, 20:21:29
Beitrag von: mannil am 08 Oktober 2015, 21:12:34
Habe schon selber herausgefunden.
Gesendet von meinem ONE A2003 mit Tapatalk
Beitrag von: anfichtn am 12 Oktober 2015, 18:10:06
Beitrag von: Wzut am 12 Oktober 2015, 19:53:42
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 )
Code: [Auswählen]
[ 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 ?
Beitrag von: Telekatz am 12 Oktober 2015, 21:00:04
Beitrag von: Wzut am 13 Oktober 2015, 07:54:14
Kann der aktuelle Bootloader Debug Ausgaben oder soll ich die Versionen durchtesten die du auf Seite drei gepostet hast ?
Beitrag von: Telekatz am 13 Oktober 2015, 12:23:31
Sollte nichts ausgegeben werden kannst du es auch noch mit der CUBE.bin von Seite drei probieren, die ohne Bootloader geladen wird.
Beitrag von: Wzut am 13 Oktober 2015, 17:48:02
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 !!!
Beitrag von: anfichtn am 13 Oktober 2015, 18:30:14
Meine Frage nach dem Netzwerkproblem scheint untergegangen zu sein... Ist das jetzt behoben?
Beitrag von: Telekatz am 13 Oktober 2015, 19:37:32
Beitrag von: anfichtn am 13 Oktober 2015, 19:48:11
Beitrag von: anfichtn am 13 Oktober 2015, 21:08:28
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
Beitrag von: anfichtn am 13 Oktober 2015, 21:56:51
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....
Beitrag von: cdn am 14 Oktober 2015, 16:38:01
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
Beitrag von: anfichtn am 14 Oktober 2015, 17:46:37
Grüße
Beitrag von: cdn am 15 Oktober 2015, 09:56:49
Ich habe die Jumper jeweils mit einer Büroklammer überbrückt, wuste nicht wie ich es sonst machen sollte...
Beitrag von: anfichtn am 15 Oktober 2015, 11:04:54
Beitrag von: cdn am 15 Oktober 2015, 11:22:52
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.
Beitrag von: cdn am 15 Oktober 2015, 11:59:39
Beitrag von: Telekatz am 15 Oktober 2015, 12:32:13
Beitrag von: cdn am 15 Oktober 2015, 12:51:38
Danke für die Hilfe!
Beitrag von: Telekatz am 15 Oktober 2015, 13:01:22
Beitrag von: cdn am 15 Oktober 2015, 13:04:25
Beitrag von: SmokeMaster am 17 Oktober 2015, 12:10:48
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!
Beitrag von: chris_fiesta am 21 Oktober 2015, 12:56:12
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! ;-)
Beitrag von: SmokeMaster am 22 Oktober 2015, 21:19:10
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:
Code: [Auswählen]
dmsg | grep ttyeines wird sicher etwas mit USB im Namen haben, etwa: ttyACM diesen Namen braucht ihr.nun geht es weiter (auf Root achten!)
Code: [Auswählen]
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/ttyACMnun 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.
Beitrag von: chris_fiesta am 23 Oktober 2015, 14:07:44
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!
Beitrag von: Telekatz am 23 Oktober 2015, 14:28:57
Beitrag von: chris_fiesta am 23 Oktober 2015, 15:16:44
Beitrag von: mr.os am 24 Oktober 2015, 14:18:16
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
Beitrag von: Ranseyer am 25 Oktober 2015, 09:07:18
Code: [Auswählen]dmsg | grep tty
Danke für die super Beschreibung. Nur muss es dmesg heissen... (Ein Buchstabe vergessen)
Beitrag von: SmokeMaster am 25 Oktober 2015, 11:33:35
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:
Danke für die super Beschreibung. Nur muss es dmesg heissen... (Ein Buchstabe vergessen)
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
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!
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.
Beitrag von: Wzut am 25 Oktober 2015, 19:26:10
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 :)
Beitrag von: mr.os am 26 Oktober 2015, 07:59:12
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.
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.
Beitrag von: chris_fiesta am 27 Oktober 2015, 10:46:02
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?
Beitrag von: mr.os am 27 Oktober 2015, 11:10:06
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 ...
Beitrag von: Telekatz am 27 Oktober 2015, 11:51:49
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)?
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...
Beitrag von: anfichtn am 27 Oktober 2015, 13:48:22
Grüße
anfichtn
Beitrag von: Telekatz am 27 Oktober 2015, 14:26:00
Mein Cube hat die Rev. B.
Läuft bei dir die Netzwerkverbindung stabil?
Beitrag von: mr.os am 27 Oktober 2015, 17:44:02
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.
Beitrag von: chris_fiesta am 28 Oktober 2015, 09:14:31
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!?
Beitrag von: Telekatz am 28 Oktober 2015, 10:53:27
@Wzut
Bei deinem Cube läuft die Netzwerkverbindung stabil. In welchen Modus betreibst du den Cube und hat dein SAM7 die Revision B?
Beitrag von: mr.os am 28 Oktober 2015, 11:03:51
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.
Beitrag von: ThommyTom am 28 Oktober 2015, 11:04:12
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
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.
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.Wenn nur TRX868 drauf steht dann ist der Cube geeignet.
Kann ich den Cube mit der alternativen FW flashen?
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.
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? :-[
Beitrag von: mr.os am 28 Oktober 2015, 12:09:11
Code: [Auswählen]
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?
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:Der Takt liegt bei 48MHz, FWS = 1 sollte deshalb passen. Aber man kann ja trotzdem mal ausprobieren, FWS auf 2 zu setzen.Code: [Auswählen]EFC: Embedded Flash Access Time 2Ich 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.
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.
Eventuell prophylaktisch einfach hoch stellen?
Beitrag von: Wzut am 28 Oktober 2015, 16:22:36
@WzutModus = MAX , Revision kann ich erst heute Abend checken wenn ich den Cube aufmache.
Bei deinem Cube läuft die Netzwerkverbindung stabil. In welchen Modus betreibst du den Cube und hat dein SAM7 die Revision B?
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)
Code: [Auswählen]
V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
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?
Beitrag von: mr.os am 28 Oktober 2015, 18:55:29
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.
Beitrag von: chris_fiesta am 28 Oktober 2015, 19:40:17
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.
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 :
Code: [Auswählen]
AT91SAM7X256
AU
1122 B
1PO750 ARM
Gekauft wurde der Cube als Neuware im Frühjahr 2012.
Beitrag von: anfichtn am 28 Oktober 2015, 20:12:41
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.
Code: [Auswählen]
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
Beitrag von: Blizzard am 28 Oktober 2015, 20:12:56
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
Beitrag von: mr.os am 28 Oktober 2015, 20:42:55
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.
Beitrag von: chris_fiesta am 29 Oktober 2015, 10:08:38
@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?!?
Beitrag von: mr.os am 29 Oktober 2015, 10:52:53
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.
Beitrag von: chris_fiesta am 29 Oktober 2015, 12:17:05
Vielen Dank für Deine Nachricht und Arbeit, die Du investierst! Ich werde heute Abend nach der Arbeit Deine Firmware ausprobieren! ;D
Beitrag von: Blizzard am 29 Oktober 2015, 12:27:49
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
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 -.-
Beitrag von: Wzut am 29 Oktober 2015, 17:32:07
Also war bei mir auch nicht unbedingt das Netzteil schuld sondern eventuell die Position im Netzwerk ...
Beitrag von: mr.os am 29 Oktober 2015, 18:25:27
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)
Beitrag von: chris_fiesta am 29 Oktober 2015, 20:06:47
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)
Beitrag von: Telekatz am 29 Oktober 2015, 21:25:40
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?
Beitrag von: chris_fiesta am 30 Oktober 2015, 08:06:43
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
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 :)
Beitrag von: Telekatz am 30 Oktober 2015, 17:40:12
Beitrag von: Basegate am 31 Oktober 2015, 12:31:58
Kann ich mit dieser version auch immernoch meine homeeasy schalter 433 mhz empfangen?
Beitrag von: Telekatz am 31 Oktober 2015, 18:23:06
Beitrag von: raspklaus am 04 November 2015, 10:52:45
wo ist denn nun die letzte aktuelle Version zu finden ?
Beitrag von: Telekatz am 04 November 2015, 11:42:58
http://forum.fhem.de/index.php/topic,35064.0.html (http://forum.fhem.de/index.php/topic,35064.0.html)
Beitrag von: raspklaus am 04 November 2015, 14:12:04
Beitrag von: Telekatz am 04 November 2015, 14:22:20
Beitrag von: Shadow3561 am 06 November 2015, 20:34:34
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
Beitrag von: Shadow3561 am 08 November 2015, 12:19:06
auf dem Chip steht
AT91SAM7X256 AU
kann mir niemand helfen?
Beitrag von: Telekatz am 08 November 2015, 13:36:58
Welche SAM-BA Version?
Steht da bei der Auswahl des Com Ports etwas in der Art "\USBserial\COMx"?
Richtiges Board ausgewählt?
Beitrag von: Shadow3561 am 08 November 2015, 14:25:22
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
Beitrag von: Telekatz am 08 November 2015, 14:48:14
Steht da bei der Auswahl des Com Ports etwas in der Art "\USBserial\COMx"?
Beitrag von: Shadow3561 am 08 November 2015, 14:51:21
Bei der Auswahl des ComPorts steht \USBserial\COM8
Mfg
Beitrag von: Telekatz am 08 November 2015, 15:09:42
Beitrag von: Shadow3561 am 08 November 2015, 15:16:10
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.
Beitrag von: anfichtn am 08 November 2015, 15:32:44
Meines Erachtens liegt dein Problem am verwendeten usb-kabel. Probier einfach mal ein anderes Kabel aus.
Beitrag von: Shadow3561 am 08 November 2015, 15:35:25
Das vom neuen und vom alten Cube(hat beim alten Cube funktioniert) und eins von einer DigiCam und noch eins von einer USB Festplatte.
Beitrag von: Telekatz am 08 November 2015, 15:36:39
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?
Beitrag von: Shadow3561 am 08 November 2015, 15:42:20
Nein, habe kein JTAG-Interface
Beitrag von: Shadow3561 am 08 November 2015, 15:51:42
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.
Beitrag von: Telekatz am 08 November 2015, 16:09:57
Beitrag von: Shadow3561 am 08 November 2015, 16:20:44
Kann auf der Tastatur rumhacken wie ich will, es erscheint kein Buchstabe.
Beitrag von: Telekatz am 08 November 2015, 16:58:25
Beitrag von: Shadow3561 am 08 November 2015, 17:03:37
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
Beitrag von: raspklaus am 09 November 2015, 11:07:32
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.
Beitrag von: Telekatz am 09 November 2015, 12:24:09
Beitrag von: raspklaus am 09 November 2015, 12:42:00
Wie kann ich dann feststellen wie sich der Cube meldet ?
Edit: ok, wahrscheinlich mit der PC Software ::)
Beitrag von: raspklaus am 10 November 2015, 09:34:44
Can´t connect atsam7s128-ek - Invalid chip ID
und nun :-[
Auch bei mir ist der Chip der AT91SAM7X256 AU
Beitrag von: Telekatz am 10 November 2015, 10:14:47
Beitrag von: raspklaus am 10 November 2015, 11:17:46
Code: [Auswählen]
(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 % Beitrag von: Telekatz am 10 November 2015, 11:34:19
Beitrag von: raspklaus am 10 November 2015, 11:44:04
und nun ???
Beitrag von: Telekatz am 10 November 2015, 11:57:30
Beitrag von: raspklaus am 10 November 2015, 12:02:12
Beitrag von: Telekatz am 10 November 2015, 12:09:09
Beitrag von: raspklaus am 10 November 2015, 12:28:42
Beitrag von: Telekatz am 10 November 2015, 12:52:18
Beitrag von: raspklaus am 10 November 2015, 13:12:18
Beitrag von: raspklaus am 10 November 2015, 19:55:18
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 ?
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.
Beitrag von: GregPac am 16 November 2015, 10:41:17
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
Beitrag von: raspklaus am 16 November 2015, 11:30:44
Beitrag von: raspklaus am 16 November 2015, 11:45:00
In der Befehlsreferenz ist das nicht zu finden.
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.
Beitrag von: Shadow3561 am 26 November 2015, 18:01:56
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
Beitrag von: scooty am 26 November 2015, 20:15:50
List des MAXCUBES:
Code: [Auswählen]
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://) .
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.Meinst du dieses Protokoll?
Ist es evtl. möglich mit dem Cube auch Lacrosse/TFA Temperatursensoren zu empfangen?
http://forum.fhem.de/index.php/topic,36565.0.html (http://forum.fhem.de/index.php/topic,36565.0.html)
Beitrag von: CaptainHook am 28 November 2015, 20:10:19
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
Beitrag von: BlackStone am 29 November 2015, 03:48:56
Beitrag von: CaptainHook am 29 November 2015, 08:15:33
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
Beitrag von: BlackStone am 29 November 2015, 11:41:14
Code: [Auswählen]
root@FHEMrpi:/home/pi# ls -l /dev/ttyACM*
crw-rw---T 1 root dialout 166, 0 Nov 29 03:17 /dev/ttyACM0
Code: [Auswählen]
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. ^^
Code: [Auswählen]
define CUL_0 CUL /dev/ttyACM0@9600 1034
hm, warum das 1034 *kopfkratz*
List :
Code: [Auswählen]
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
Beitrag von: CaptainHook am 29 November 2015, 12:08:56
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
Beitrag von: BlackStone am 29 November 2015, 12:35:37
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.
Beitrag von: Gator99 am 06 Dezember 2015, 15:55:49
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
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.
Beitrag von: Gator99 am 07 Dezember 2015, 11:45:43
*jubel* *jubel* *freu* *freu*
Besten Dank, sehr nett von dir.
Wenn du in der Nähe bist, sag bescheid. Ich zahle in Bier ;-)
Gruss
Beitrag von: Kharim am 07 Dezember 2015, 22:16:05
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
Beitrag von: Telekatz am 08 Dezember 2015, 18:16:05
....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
Beitrag von: Kharim am 09 Dezember 2015, 08:19:35
nach Installation des Make-Tools und Anpassung der PATH Variable ist auch das nun geschafft *gg*
Beitrag von: masterpete23 am 10 Dezember 2015, 07:20:17
Der Quellcode für die ARM Version ist jetzt in der a-culfw enthalten.Hi,
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 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?
Beitrag von: Telekatz am 10 Dezember 2015, 17:20:19
Auf meinem Cube steht auch nur TRX868.Ja, es geht mit dem.
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?Du nimmst Bootloader und Firmware aus dem verlinkten Archiv im ersten Beitrag.
Beitrag von: masterpete23 am 10 Dezember 2015, 17:43:16
Gesendet von meinem Huawei Honor 7
Beitrag von: Telekatz am 10 Dezember 2015, 18:12:52
Beitrag von: petjek am 12 Dezember 2015, 13:21:10
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
Beitrag von: masterpete23 am 12 Dezember 2015, 14:31:47
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
Beitrag von: masterpete23 am 12 Dezember 2015, 15:24:58
nur weiß ich nicht wie ich dann maxmode definen muss
den cul habe ich auf port 2323 defined nur wie mache ich weiter?
Beitrag von: Basegate am 12 Dezember 2015, 17:36:20
Beitrag von: masterpete23 am 12 Dezember 2015, 17:45:25
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 13 Dezember 2015, 12:28:55
Beitrag von: Gator99 am 13 Dezember 2015, 13:37:10
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
Beitrag von: Telekatz am 13 Dezember 2015, 20:18:12
welches SAM-BA Version hast du verwendet? Und hast du SAM-BA als Administrator gestartet?
Beitrag von: petjek am 14 Dezember 2015, 07:40:32
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
Beitrag von: MAC66666 am 14 Dezember 2015, 11:15:22
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 ;-)
Beitrag von: Telekatz am 14 Dezember 2015, 17:03:35
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.
Beitrag von: mahowi am 15 Dezember 2015, 23:13:34
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:
Code: [Auswählen]
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
Beitrag von: masterpete23 am 15 Dezember 2015, 23:17:12
Gesendet von meinem Huawei Honor 7
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:
Nachdem ich den Cube wieder vom Raspi getrennt und direkt ans Ladegerät gehängt habe verbindet er sich wieder nicht mit dem Router. :-\
Beitrag von: mahowi am 16 Dezember 2015, 18:38:58
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.
Code: [Auswählen]
V 1.20.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)P.S.: Zum Kompilieren habe ich folgendes Makefile.local erstellt:
Code: [Auswählen]
###############################################################
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.
Beitrag von: petjek am 17 Dezember 2015, 13:44:19
@petjekTerminalprogramm? Dazu muss ich ihn wieder ins LAN hängen, oder? Per USB wird das nicht gehen, woll?
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.
Muss ich dann die IP-Range des Rechners auf die des Cubes anpassen?
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?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.
Muss ich dann die IP-Range des Rechners auf die des Cubes anpassen?
Beitrag von: Wzut am 17 Dezember 2015, 17:28:16
Hintergrund : die vier Pins schreien direkt danach einen ESP8266-01 aufzustecken und den Cube damit zum Wireless Cube zu machen :)
Beitrag von: Telekatz am 17 Dezember 2015, 17:50:43
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.
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?
Beitrag von: Telekatz am 17 Dezember 2015, 18:12:56
Woher hast du eigentlich den Treiber genommen, den du dem Unbekannten Gerät zugewiesen hast? Aus dem SAM-BA Verzeichnis?
Beitrag von: petjek am 18 Dezember 2015, 12:30:52
Den Treiber hab ich aus dem Verzeichnis C:\Program Files (x86)\Atmel\sam-ba_2.15\drv
Beitrag von: masterpete23 am 18 Dezember 2015, 12:51:29
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 18 Dezember 2015, 13:06:46
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.
Beitrag von: masterpete23 am 18 Dezember 2015, 13:11:50
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
Beitrag von: petjek am 18 Dezember 2015, 13:35:55
Per Jumper gelöscht? Wie und wo denn?
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 ....
Beitrag von: petjek am 18 Dezember 2015, 14:02:44
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?
Beitrag von: masterpete23 am 18 Dezember 2015, 14:27:43
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 18 Dezember 2015, 14:43:31
Beitrag von: masterpete23 am 18 Dezember 2015, 14:45:43
Gesendet von meinem Huawei Honor 7
Beitrag von: mahowi am 18 Dezember 2015, 15:13:10
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:
Code: [Auswählen]
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.0Trotzdem 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. :-\
Beitrag von: Telekatz am 18 Dezember 2015, 16:49:17
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.
Beitrag von: masterpete23 am 18 Dezember 2015, 19:22:46
Gesendet von meinem Huawei Honor 7
Beitrag von: Wzut am 18 Dezember 2015, 19:28:52
Nein, am ST2 kommen auch im laufenden Betrieb Debugausgaben.hmm schade. Wie hoch schätzt du den Aufwand dafür ?
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.
Beim ATmega328 ist das ganze Thema serielle Ausgabe mit vier Zeilen abgehandelt:
Code: [Auswählen]
#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 :(
Beitrag von: petjek am 20 Dezember 2015, 14:18:14
Muss man unter Win 7 nen Treiber zwingend nehmen? Welchen Chip hast du drauf?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.
Gesendet von meinem Huawei Honor 7
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.
Beitrag von: masterpete23 am 20 Dezember 2015, 22:42:01
Gesendet von meinem Huawei Honor 7
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. :(
- "associate" zwischen Fensterkontakt und Thermostat scheint nicht zu funktionieren. Gibt es hier die Möglichkeit, die verschiedenen Verbindung zwischen den Geräten auszulesen?
- Die meisten Thermostate lassen sich weder manuell noch per FHEM auf auto schalten.
- ich bekomme keine neuen Wochenprogramme auf die Thermostate. Der Versuch scheitert regelmäßig mit zu wenigen Credits und "missing ack":
Code: [Auswählen]
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 1920001012345600a8f1000440b44cfc40004520452045204520Erneutes 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.
Beitrag von: CaptainHook am 22 Dezember 2015, 08:44:04
eine Möglichkeit zum Auslesen der Verbindung wäre traumhaft... gib es aber meines Wissens nach nciht....
Code: [Auswählen]
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 ThermostatCode: [Auswählen]
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
Beitrag von: masterpete23 am 22 Dezember 2015, 08:52:58
Gesendet von meinem Huawei Honor 7
Beitrag von: mahowi am 22 Dezember 2015, 09:23:34
Hi,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.
eine Möglichkeit zum Auslesen der Verbindung wäre traumhaft... gib es aber meines Wissens nach nciht....
Zitat von: CaptainHook
In den Readings wird mir ein Wochenprofil angezeigt, also müsste ich doch eigentlich darauf umschalten können.Code: [Auswählen]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
Zitat von: CaptainHook
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.Code: [Auswählen]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.
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. :-\
Beitrag von: masterpete23 am 22 Dezember 2015, 09:30:54
Gesendet von meinem Huawei Honor 7
Beitrag von: mahowi am 22 Dezember 2015, 10:22:38
Aber irgendetwas scheint hier Credits zu fressen ohne Ende:
Code: [Auswählen]
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?
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.
Beitrag von: mahowi am 22 Dezember 2015, 21:49:39
Code: [Auswählen]
bossa - Atmel SAM ARM microcontroller flash programming GUI
bossa-cli - Atmel SAM ARM microcontroller flash programming utilityDie GUI habe ich nicht getestet. Ich habe im terminal einfach die BOSSA Shell (bossash) aufgerufen. Sollte dann in etwa so aussehen:Code: [Auswählen]
$ 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.
Beitrag von: petjek am 24 Dezember 2015, 07:32:24
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. :(
Beitrag von: CaptainHook am 24 Dezember 2015, 08:25:55
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
Beitrag von: petjek am 24 Dezember 2015, 12:15:41
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! ;)
Beitrag von: Ralle am 24 Dezember 2015, 15:06:20
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
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.
Beitrag von: masterpete23 am 24 Dezember 2015, 16:31:55
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 24 Dezember 2015, 16:46:19
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.
Beitrag von: masterpete23 am 24 Dezember 2015, 17:33:14
Gesendet von meinem Huawei Honor 7
Beitrag von: Telekatz am 24 Dezember 2015, 17:38:18
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.
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.
Beitrag von: Wzut am 25 Dezember 2015, 15:05:04
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.
Beitrag von: petjek am 25 Dezember 2015, 15:27:39
Beitrag von: masterpete23 am 25 Dezember 2015, 16:46:54
Gesendet von meinem Huawei Honor 7
Beitrag von: Wzut am 25 Dezember 2015, 17:36:04
Beitrag von: masterpete23 am 25 Dezember 2015, 17:43:19
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 25 Dezember 2015, 18:04:00
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.Ja, habe gerade eines gefunden. Funktioniert ebenfalls nicht.
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 ) ?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.
Beitrag von: Telekatz am 26 Dezember 2015, 10:45:33
Beitrag von: petjek am 26 Dezember 2015, 11:35:41
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
Code: [Auswählen]
Could not connect to device on COM7 //bzw. COM8//beim Versuch zu verbinden.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
Beitrag von: mahowi am 27 Dezember 2015, 12:24:42
Code: [Auswählen]
[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
Beitrag von: petjek am 27 Dezember 2015, 14:46:52
Beitrag von: Tatsu am 28 Dezember 2015, 18:50:12
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
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
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...
Beitrag von: marty29ak am 28 Dezember 2015, 22:30:24
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?
Beitrag von: CaptainHook am 28 Dezember 2015, 22:36:45
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
Beitrag von: marty29ak am 28 Dezember 2015, 22:40:05
Beitrag von: Basegate am 29 Dezember 2015, 08:36:24
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.
Beitrag von: Ralle am 29 Dezember 2015, 13:52:55
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 ?
Beitrag von: masterpete23 am 29 Dezember 2015, 14:09:10
attr maxcube rfmode MAX
attr maxcube room CUL
define cmax CUL_MAX 654321
attr cmax IODev maxcube
Gesendet von meinem Huawei Honor 7
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 :)
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:
Code: [Auswählen]
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?
Beitrag von: masterpete23 am 30 Dezember 2015, 16:23:10
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 30 Dezember 2015, 16:24:44
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:Code: [Auswählen][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:
Code: [Auswählen]
[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 :(
Beitrag von: Telekatz am 30 Dezember 2015, 18:32:36
Code: [Auswählen]
[ 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 deviceBossa mit sudo apt-get install bossa-cli installieren funktioniert bei mir auch nicht. Aber man kann Bossa auch selber bauen:
Code: [Auswählen]
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
Beitrag von: petjek am 31 Dezember 2015, 13:27:47
Code: [Auswählen]
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.
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 ?
Beitrag von: Telekatz am 31 Dezember 2015, 15:52:57
Code: [Auswählen]
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>
Beitrag von: masterpete23 am 31 Dezember 2015, 16:23:36
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 31 Dezember 2015, 19:50:54
Beitrag von: masterpete23 am 31 Dezember 2015, 20:01:34
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 31 Dezember 2015, 20:02:19
Beitrag von: masterpete23 am 31 Dezember 2015, 20:17:40
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 01 Januar 2016, 12:38:50
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:
Code: [Auswählen]
[ 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???
Beitrag von: raspklaus am 01 Januar 2016, 17:26:11
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
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,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)
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
Beitrag von: raspklaus am 02 Januar 2016, 10:06:43
Beitrag von: petjek am 02 Januar 2016, 11:11:32
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. ;)
Beitrag von: masterpete23 am 02 Januar 2016, 22:33:52
Gesendet von meinem Huawei Honor 7
Beitrag von: raspklaus am 03 Januar 2016, 10:38:04
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
Beitrag von: petjek am 03 Januar 2016, 12:00:44
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.
Beitrag von: petjek am 03 Januar 2016, 13:13:52
Ich hab es mit
Code: [Auswählen]
set maxcube pairmode versucht. Da bekomme ich als AntwortCode: [Auswählen]
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
- im Wohnzimmer 2x Heizkörperthermostat, 1x Wandthermostat,
- im Badezimmer 1x Heizkörperthermostat+, 1x Fensterkontakt
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...
Code: [Auswählen]
Can't connect to socket!... was wohl eher auch nichts Gutes bedeutet, oder?LG,
petjek
Beitrag von: masterpete23 am 03 Januar 2016, 13:47:43
Gesendet von meinem Huawei Honor 7
Beitrag von: petjek am 03 Januar 2016, 13:58:50
Oder meinst du den Hinweis, wie man den maxcube definiert? Das hat geklappt. Darum geht's grad nicht.
Beitrag von: masterpete23 am 03 Januar 2016, 14:26:42
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
Beitrag von: petjek am 03 Januar 2016, 15:06:32
Beitrag von: masterpete23 am 03 Januar 2016, 15:08:29
Gesendet von meinem Huawei Honor 7
Beitrag von: Basegate am 07 Januar 2016, 03:10:39
Vom Mobiltelefon gesendet.
Beitrag von: CaptainHook am 07 Januar 2016, 08:15:31
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
Beitrag von: Basegate am 07 Januar 2016, 11:53:02
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.
Beitrag von: CaptainHook am 07 Januar 2016, 12:23:09
Hast du das Funkmodul im Cube ausgetauscht oder "einfach nur" ne Externe Antenne drangelötet?
Grüße,
Stephan
Beitrag von: Basegate am 07 Januar 2016, 12:26:56
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.
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.... und die schöne Power lampe geopfert :-\
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.
Mobil erstellt daher kurz gehalten
Beitrag von: CaptainHook am 07 Januar 2016, 12:42:55
Beitrag von: masterpete23 am 07 Januar 2016, 14:03:10
Gesendet von meinem Huawei Honor 7
Beitrag von: Basegate am 08 Januar 2016, 01:43:07
Vom Mobiltelefon gesendet.
Beitrag von: mrbit1968 am 08 Januar 2016, 16:43:41
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.
Beitrag von: Basegate am 08 Januar 2016, 18:34:09
Vom Mobiltelefon gesendet.
Beitrag von: mrbit1968 am 08 Januar 2016, 22:26:02
Beitrag von: darth am 09 Januar 2016, 00:06:46
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.
Beitrag von: Telekatz am 09 Januar 2016, 12:05:06
+-----------[xmodem upload - Press CTRL-C to quit]------------+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.
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...
+-------------------------------------------------------------+
Beitrag von: mrbit1968 am 10 Januar 2016, 07:11:24
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)
Beitrag von: mrbit1968 am 10 Januar 2016, 22:45:58
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?
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
Beitrag von: daniel85 am 14 Januar 2016, 09:50:50
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 ???
Beitrag von: mahowi am 14 Januar 2016, 09:59:58
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.
Beitrag von: daniel85 am 15 Januar 2016, 21:52:50
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.
Beitrag von: marty29ak am 15 Januar 2016, 21:57:39
Bisher keine Probleme.
Liegt also sicher an was anderem.
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
Beitrag von: marty29ak am 15 Januar 2016, 22:40:46
Mache noch nicht so viele Experimente da ich noch Anfänger mit Fhem bin und erst mal versuche die Anleitungen sicher um zu setzen.
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.
Beitrag von: marty29ak am 15 Januar 2016, 23:12:40
Ist für mich eine wirklich zuverlässige, günstige und gut zu beschaffende Alternative zu den Cul oder Cun.
Beitrag von: dieda am 15 Januar 2016, 23:17:20
Beitrag von: marty29ak am 15 Januar 2016, 23:25:08
Ps.:Oder bei ELV als Bausatz (ist in 10Min zusammen) für ebenfalls 40€
Beitrag von: dieda am 16 Januar 2016, 13:31:07
Beitrag von: marty29ak am 16 Januar 2016, 14:18:39
Da würde ich mir keine großen Gedanken machen. Einfach genau nach der Anleitung auf Seite 1 gehen.
Beitrag von: chris1284 am 16 Januar 2016, 14:59:26
J1 mit schraubendreher überbrückt, tools aus post 1 genutzt < 5 min und der cubeCUL ist eingebunden.
Beitrag von: chris1284 am 16 Januar 2016, 15:09:44
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
Beitrag von: chris1284 am 16 Januar 2016, 15:24:34
Beitrag von: Telekatz am 16 Januar 2016, 15:47:57
Dass der Cube eine Verbindung zum Netzwerk hat, sieht man auch daran, das D2 (INTERNET) am Cube leuchtet.
Beitrag von: Wzut am 17 Januar 2016, 18:33:36
per usb läuft er aber steck ich ihn ans lan hat er keinen linkdas USB Kabel hast aber trotzdem zur Stromversorgung des Cubes dran gelassen ? denn PoE kann der Cube nicht :)
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....
Beitrag von: tobby am 19 Januar 2016, 02:31:50
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.
Beitrag von: tucka am 19 Januar 2016, 02:40:33
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!!
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:Code: [Auswählen]bossa - Atmel SAM ARM microcontroller flash programming GUIDie GUI habe ich nicht getestet. Ich habe im terminal einfach die BOSSA Shell (bossash) aufgerufen. Sollte dann in etwa so aussehen:
bossa-cli - Atmel SAM ARM microcontroller flash programming utilityCode: [Auswählen]$ bossashDann 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.
Press Ctrl-D or enter "exit" to end session.
Enter "help" to display a command list.
bossa>
Beitrag von: CarstenF am 20 Januar 2016, 13:15:52
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.
Beitrag von: marty29ak am 20 Januar 2016, 13:32:24
Dieser muss NUR am Anfang kurz gebrückt werden dann kurz das USB Kabel dran und wieder ab. Jetzt J1 entfernen und dann flashen.....
Beitrag von: CarstenF am 20 Januar 2016, 13:34:58
Beitrag von: marty29ak am 20 Januar 2016, 13:38:10
Beitrag von: CarstenF am 20 Januar 2016, 13:42:41
Jetzt erscheint der Cube wieder mit der Bezeichnung USBModem 1421, aber der Upload klappt nicht und es blinkt auch nichts.
Beitrag von: marty29ak am 20 Januar 2016, 13:49:06
Aber versuch doch mal den Cube direkt am PI zu flashen. Da soll dieses Bossa ja auch laufen....Wie ist ja weiter oben beschrieben.
Beitrag von: Wzut am 20 Januar 2016, 14:19:41
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)
Beitrag von: CarstenF am 20 Januar 2016, 16:55:59
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.
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?
Beitrag von: CarstenF am 20 Januar 2016, 21:00:21
Code: [Auswählen]
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.
Beitrag von: masterpete23 am 20 Januar 2016, 21:05:11
Gesendet von meinem Huawei Honor 7
Beitrag von: CarstenF am 20 Januar 2016, 21:09:38
Bleibt bei
Unable so locate package bossa-cli
Beitrag von: Telekatz am 20 Januar 2016, 21:55:32
Bossa mit sudo apt-get install bossa-cli installieren funktioniert bei mir auch nicht. Aber man kann Bossa auch selber bauen:Code: [Auswählen]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
Beitrag von: CarstenF am 20 Januar 2016, 22:16:39
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!!!
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.
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
Code: [Auswählen]
Boot to flash flag set to true. Was muß ich denn da machen?Danke, Gruß Carsten
Beitrag von: Telekatz am 21 Januar 2016, 14:18:28
Beitrag von: CarstenF am 21 Januar 2016, 14:43:52
Danke. Dir. Jetzt werde ich mal schauen, das die Firmware draufkommt.
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
Beitrag von: CarstenF am 21 Januar 2016, 20:46:33
Beitrag von: CarstenF am 24 Januar 2016, 14:54:07
Hat mal wieder totalen Spaß gemacht, so ein Projekt umzusetzen. Dieses Board ist einfach der Hammer!!!
Beitrag von: bernd_zwo am 27 Januar 2016, 17:04:18
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
Beitrag von: mrbit1968 am 28 Januar 2016, 16:45:19
Gruß
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.
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 ?
Beitrag von: Telekatz am 29 Januar 2016, 10:42:25
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.
Beitrag von: tboston am 02 Februar 2016, 23:46:04
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:
Code: [Auswählen]
[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 deviceIst das Teil jetzt kaputt?
Beitrag von: masterpete23 am 02 Februar 2016, 23:50:57
Gesendet von meinem Huawei Honor 7
Beitrag von: tboston am 02 Februar 2016, 23:56:51
---
Tony
Beitrag von: Telekatz am 03 Februar 2016, 08:47:09
Nabend zusammen,Wie weit hat es nach Anleitung noch funktioniert? Konntest du den Bootloader noch laden?
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:Code: [Auswählen][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?
Beitrag von: tboston am 03 Februar 2016, 09:04:39
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
Beitrag von: Telekatz am 03 Februar 2016, 17:28:10
Hast du danach mit J1 den internen SAM-BA Bootloader geladen und anschließend auch den 10k Ohm Widerstand beim erneuten Einstecken mit verbunden?
Beitrag von: tboston am 03 Februar 2016, 17:30:57
Beitrag von: Telekatz am 03 Februar 2016, 17:44:23
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
Beitrag von: Telekatz am 03 Februar 2016, 18:04:40
Beitrag von: tboston am 03 Februar 2016, 18:09:46
---
Tony
Beitrag von: Telekatz am 03 Februar 2016, 19:04:37
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.
Beitrag von: tboston am 03 Februar 2016, 19:10:17
Danke euch!
Beitrag von: tboston am 04 Februar 2016, 11:36:13
Beitrag von: Telekatz am 04 Februar 2016, 11:51:20
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)
Beitrag von: tboston am 05 Februar 2016, 07:14:29
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
Beitrag von: chris1284 am 05 Februar 2016, 07:43:54
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!
Beitrag von: tboston am 05 Februar 2016, 07:47:49
---
Tony
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.
Beitrag von: tboston am 05 Februar 2016, 08:40:23
Beitrag von: Telekatz am 05 Februar 2016, 13:30:08
Beitrag von: tboston am 05 Februar 2016, 20:01:30
Wer von den Linux'ern hier kann mir sagen wie er das mit sam_ba angestellt hat?
Beitrag von: Telekatz am 06 Februar 2016, 10:49:07
Beitrag von: tboston am 06 Februar 2016, 10:55:51
Beitrag von: rubbertail am 06 Februar 2016, 12:42:15
Beitrag von: tboston am 06 Februar 2016, 12:44:27
---
Tony
Beitrag von: rubbertail am 06 Februar 2016, 12:46:04
Beitrag von: rubbertail am 06 Februar 2016, 12:47:19
Beitrag von: mahowi am 06 Februar 2016, 12:50:02
Beitrag von: pneuman1 am 06 Februar 2016, 21:23:33
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.
Beitrag von: masterpete23 am 06 Februar 2016, 21:26:27
Gesendet von meinem Huawei Honor 7
Beitrag von: pneuman1 am 06 Februar 2016, 22:51:43
Win 7 - Firefox 43.0.4 - Scripte erlaubt, ABP für die Seite deaktiviert.
Unter Ubuntu das gleiche Bild.
Beitrag von: Christian1982 am 07 Februar 2016, 10:31:23
Keine Ahnung warum.
Beitrag von: Tatsu am 10 Februar 2016, 00:18:01
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
Beitrag von: CaptainHook am 10 Februar 2016, 08:12:42
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
Beitrag von: Telekatz am 10 Februar 2016, 10:34:02
Code: [Auswählen]
#define USB_DESCRIPTOR_SN '1'Einfach die 1 durch ein anderes Zeichen erstetzen.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:Code: [Auswählen]#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 ;)
Beitrag von: Ranseyer am 13 Februar 2016, 11:55:48
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:4dBWenn 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 )
Beitrag von: mahowi am 13 Februar 2016, 14:01:35
Beitrag von: Ranseyer am 14 Februar 2016, 16:57:15
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
Beitrag von: masterpete23 am 14 Februar 2016, 17:25:33
Gesendet von meinem Huawei Honor 7
Beitrag von: masterpete23 am 14 Februar 2016, 17:25:51
Gesendet von meinem Huawei Honor 7
Beitrag von: Ranseyer am 20 Februar 2016, 08:43:41
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.
Beitrag von: Ranseyer am 21 Februar 2016, 09:50:12
Soll ich mal selbst kompilieren ?
Beitrag von: Snop007 am 24 Februar 2016, 13:05:26
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
Beitrag von: Telekatz am 24 Februar 2016, 22:45:12
Würde auch die Einbindung des Cun lediglich in meinem Handy möglich sein?Nein.
Beitrag von: Snop007 am 26 Februar 2016, 12:18:10
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?
Beitrag von: mahowi am 26 Februar 2016, 12:23:27
Einfacher wäre es dann wahrscheinlich, auf Raspbian zu setzen und Kodi darauf zu installieren.
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
Beitrag von: schmello am 03 März 2016, 17:48:29
Im Wiki habe ich nur etwas über usb gefunden.
Beitrag von: stenny73 am 03 März 2016, 17:52:04
Ich habe meinen so angeleldet....
define CUL1_LAN CUL 192.xxx.yyy.zzz:2323 1034
Gesendet von iPad mit Tapatalk
Beitrag von: cdn am 08 März 2016, 19:09:59
http://fhemwiki.de/wiki/RFR_CUL
Beitrag von: ThommyTom am 08 März 2016, 19:55:23
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
Beitrag von: Telekatz am 08 März 2016, 20:15:46
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
Beitrag von: Telekatz am 08 März 2016, 21:43:57
Beitrag von: ThommyTom am 09 März 2016, 09:24:47
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
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)
Beitrag von: ThommyTom am 09 März 2016, 09:51:14
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
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:Code: [Auswählen]#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?
Beitrag von: Telekatz am 11 März 2016, 11:36:01
Beitrag von: max333 am 11 März 2016, 12:06:10
Beitrag von: Telekatz am 11 März 2016, 12:16:24
Welche der erzeugten Dateien hast du danach geflasht? CUBE.bin oder CUBE_BL.bin?
Beitrag von: max333 am 11 März 2016, 12:49:15
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?
Beitrag von: Telekatz am 11 März 2016, 19:00:39
Beitrag von: Tatsu am 16 März 2016, 16:48:29
Allerdings verabschiedet sich der CUBE (V 1.20.06 a-culfw Build: 199) dann kurz darauf mit folgendem Logeintrag:
Code: [Auswählen]
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: BbCFiAZNEkGMKLUYRTVWXefltxzDas passiert auch mit meinem zweiten CUBE (V 1.20.01 a-culfw Build: 176, via USB):
Code: [Auswählen]
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!
Beitrag von: Telekatz am 16 März 2016, 22:15:18
Code: [Auswählen]
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"));
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:
Code: [Auswählen]
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
Beitrag von: Telekatz am 16 März 2016, 22:48:03
Beitrag von: Tatsu am 17 März 2016, 01:46:39
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!
Beitrag von: Tatsu am 19 März 2016, 11:14:57
Beitrag von: Telekatz am 19 März 2016, 12:40:38
Code: [Auswählen]
set CUN_0 verbose 0
Beitrag von: Tatsu am 20 März 2016, 01:05:14
Code: [Auswählen]set CUN_0 verbose 0
Super, danke! Da merke ich immer, wie sehr ich noch Anfänger bin. Danke für die Geduld :)
Beitrag von: Pythonf am 24 März 2016, 21:45:34
Code: [Auswählen]
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
Beitrag von: Telekatz am 25 März 2016, 10:57:06
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.
Beitrag von: Pythonf am 25 März 2016, 11:05:15
Gibts es dazu eine Anleitung, wie ich die FW direkt aufspielen kann?
Beitrag von: Telekatz am 25 März 2016, 14:46:27
Beitrag von: Pythonf am 25 März 2016, 22:40:05
Grüße
Fabian
Beitrag von: rainstormer am 27 März 2016, 21:43:01
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
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.
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
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.Sieht korrekt aus.
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.
Beitrag von: stenny am 28 März 2016, 15:06:40
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
Beitrag von: rainstormer am 28 März 2016, 16:02:06
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
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?
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 ;)
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:)
Beitrag von: Christian1982 am 29 März 2016, 20:45:16
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?
Beitrag von: Telekatz am 30 März 2016, 12:06:00
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.
Beitrag von: JSG am 01 April 2016, 10:57:05
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.
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.
Beitrag von: chris1284 am 02 April 2016, 21:38:18
Zitat
Vielleicht gibt es dafür aber auch schon eine LösungEin notify auf global:INITIALIZED sollte helfen
Beitrag von: chris1284 am 03 April 2016, 18:23:13
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 :)
Beitrag von: chris1284 am 06 April 2016, 07:07:10
EDIT: habs gefunden
board.h:
Code: [Auswählen]
#define HAS_RFNATIVE
#define LACROSSE_HMS_EMUDie Zeile muss weg oder wird auskommentiert:Code: [Auswählen]
//# define OFF_LACROSSE_HMS_EMUIn CUL.c dürfen diese Einträge nicht fehlen:
Code: [Auswählen]
#ifdef HAS_RFNATIVE
#include "rf_native.h"
#endif
#ifdef HAS_RFNATIVE
{ 'N', native_func },
#endif
#ifdef HAS_RFNATIVE
native_task();
#endif
Beitrag von: max333 am 08 April 2016, 11:36:26
Beitrag von: chris1284 am 08 April 2016, 18:53:45
workaroung wäre ein notify auf [cul]:Initialized oder cul:CONNECTED
Zitat
2016-04-08 18:56:56 CUL nanoCUL868 DISCONNECTEDich werde das setzen des raw-modes automatisch mal wünschen https://forum.fhem.de/index.php/topic,51946.0.html
2016-04-08 18:57:04 CUL nanoCUL868 Initialized
2016-04-08 18:57:04 CUL nanoCUL868 CONNECTED
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
Code: [Auswählen]
define nft_culrestart notify [culname]:Initialized set nanoCUL868 raw Nr2sollte er nach neustart sowie ab und anstecken / ein und ausschalten immer wieder raw Nr2 setzen
Beitrag von: max333 am 08 April 2016, 20:49:05
Beitrag von: Fhemschorsch am 10 April 2016, 07:37:05
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
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
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.Pop, Rock, s
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)
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!
Beitrag von: raspklaus am 10 April 2016, 20:05:51
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
Beitrag von: Fhemschorsch am 10 April 2016, 21:20:46
Wo kann man den einzeln von debitel bestellen ?
Amazon Marketplace, 34,90€ incl Versand
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
Beitrag von: Christian1982 am 11 April 2016, 10:42:46
Beitrag von: Telekatz am 11 April 2016, 11:48:48
Trotzdem wurde hier noch nie ein Cube mit anderen Funkmodul gemeldet. Scheint es also doch nicht zu geben.
Beitrag von: Christian1982 am 11 April 2016, 19:42:18
Hier mal ein interessanter Artikel zum Cube
https://www.insinuator.net/2016/04/discover-the-unknown-analyzing-an-iot-device/
Beitrag von: Fhemschorsch am 14 April 2016, 17:27:14
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!
Beitrag von: noice am 14 April 2016, 18:17:12
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
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 Gedankenanstrossden 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.
Beitrag von: Floca am 20 April 2016, 18:20:19
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ß
Beitrag von: Telekatz am 20 April 2016, 22:29:53
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).
Beitrag von: JayP am 30 April 2016, 14:15:55
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
Code: [Auswählen]
[ 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.
Beitrag von: Telekatz am 01 Mai 2016, 11:15:26
USB Kabel schon getauscht? Eventuell ein Wackelkontakt.
Beitrag von: gso am 01 Mai 2016, 11:34:35
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
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ß!
Beitrag von: Telekatz am 15 Mai 2016, 13:53:04
http://culfw.de/commandref.html#cmd_l (http://culfw.de/commandref.html#cmd_l)
Beitrag von: DerFrickler am 15 Mai 2016, 20:11:12
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.
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 ::)
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ß!
Beitrag von: max333 am 20 Mai 2016, 11:25:51
Beitrag von: chris1284 am 21 Mai 2016, 08:32:39
Zitat
feststellen dass auch dieser sich für 6 Stunden pro Tag schlafen legtbei 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
Beitrag von: rubbertail am 21 Mai 2016, 10:00:35
Beitrag von: chris1284 am 21 Mai 2016, 19:25:38
Code: [Auswählen]
VERSION V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
Beitrag von: max333 am 21 Mai 2016, 20:42:59
Code: [Auswählen]
VERSION V 1.20.06 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
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ß!
Beitrag von: Markus M. am 26 Mai 2016, 12:39:34
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.
Beitrag von: raspklaus am 26 Mai 2016, 14:29:36
Beitrag von: stenny73 am 26 Mai 2016, 14:56:16
Also zwei bin Dateien im Cube Verzeichnis.....
Gesendet von iPad mit Tapatalk
Beitrag von: raspklaus am 26 Mai 2016, 15:20:32
Beitrag von: stenny73 am 26 Mai 2016, 15:29:26
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
Beitrag von: Telekatz am 26 Mai 2016, 19:23:44
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.
Beitrag von: raspklaus am 27 Mai 2016, 11:58:25
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.
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
Beitrag von: raspklaus am 27 Mai 2016, 12:25:20
Kann jemand die neueste Cube.bin zur Verfügung stellen ?
Danke
Beitrag von: DerFrickler am 27 Mai 2016, 12:30:04
Beitrag von: raspklaus am 27 Mai 2016, 12:58:20
Beitrag von: DerFrickler am 27 Mai 2016, 13:55:32
Beitrag von: raspklaus am 27 Mai 2016, 13:58:25
Beitrag von: Telekatz am 27 Mai 2016, 21:02:04
Beitrag von: raspklaus am 27 Mai 2016, 21:10:15
Kannst Du mir bitte auch sagen wie ich die eventuell selbst erstellen kann ?
Danke
Beitrag von: Telekatz am 29 Mai 2016, 11:31:49
- Sourcecode aus dem ersten Beitrag herunterladen
- Eventuell make installieren
- Optional IDE (z.B. Eclipse) installieren
- Im Verzeichnis ...\culfw\Devices\CUBe "make CUBE" ausführen
Beitrag von: mveltrup am 29 Mai 2016, 20:35:19
Bekomme den toolchain nicht installiert und kenn mich nicht so aus.
Beitrag von: max333 am 01 Juni 2016, 07:36:16
Beitrag von: mveltrup am 01 Juni 2016, 14:49:02
Beitrag von: RalfRog am 25 Juni 2016, 21:23:52
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
Beitrag von: Telekatz am 26 Juni 2016, 10:42:35
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.
Beitrag von: RalfRog am 26 Juni 2016, 22:11:06
- Dann braucht man sich ja keine Gedanken zu machen :)
- Ok das ist klar, dass die Eigenschaften mit der RF-Fehlanpassung nicht so gut sind. Aber als Behelf für eine per LAN erreichbare Stelle mit Funkloch im Haus gehts. Zumindest das Schalten klappt (getestet) . Wenn es dann für das Horchen bei 433 MHz reicht "set freq 433" zu setzen ist es ok.
Ich werde die Reichweite mal austesten und mit dem 433er nanoCUL vergleichen. - Da steckte die Idee dahinter den Cube direkt(schlecht angepasst) bei 433 MHz laufen zu haben.
mit passendem String - "V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)"
Beitrag von: RalfRog am 01 Juli 2016, 21:43:04
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 .
Beitrag von: Aladin222 am 02 Juli 2016, 06:29:47
auch ich habe meinen Cube zum Cuno geflasht :
list
Code: [Auswählen]
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 )
Code: [Auswählen]
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 ?
Beitrag von: janvonnebenan am 02 Juli 2016, 15:08:39
Den Fehler bei der Netzwerkanbindung des MaxCubes kann ich allerdings bestätigen. Im Logfile:
Code: [Auswählen]
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:
Code: [Auswählen]
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
Beitrag von: RalfRog am 02 Juli 2016, 18:26:23
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
Beitrag von: Aladin222 am 02 Juli 2016, 19:04:10
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 :-(
Beitrag von: janvonnebenan am 02 Juli 2016, 19:09:41
Beitrag von: Aladin222 am 02 Juli 2016, 19:13:19
Bei mir
Code: [Auswählen]
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
Beitrag von: rubbertail am 02 Juli 2016, 19:13:51
Beitrag von: Aladin222 am 02 Juli 2016, 19:16:53
Beitrag von: rubbertail am 02 Juli 2016, 19:39:06
Beitrag von: Telekatz am 03 Juli 2016, 11:30:46
@TelekatzSollte eigentlich funktionieren. Setz mal alles mir "raw e" alles zurück und und stell die Frequenz nochmal ein.
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?
Beitrag von: RalfRog am 03 Juli 2016, 19:32:11
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:
Code: [Auswählen]
....
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
Code: [Auswählen]
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)
Beitrag von: RalfRog am 03 Juli 2016, 21:25:55
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
Beitrag von: Telekatz am 03 Juli 2016, 22:47:10
https://forum.fhem.de/index.php/topic,36529.msg289490.html#msg289490 (https://forum.fhem.de/index.php/topic,36529.msg289490.html#msg289490)
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:
Code: [Auswählen]
...
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.
Beitrag von: janvonnebenan am 07 Juli 2016, 15:47:05
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.
Code: [Auswählen]
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.
Beitrag von: raspklaus am 12 Juli 2016, 16:24:07
nochmal eine Frage:
Beim Flashen mit minicom muss welches Protokoll ausgewählt werden ?
Danke
Beitrag von: Telekatz am 12 Juli 2016, 18:36:35
Beitrag von: mrbit1968 am 25 Juli 2016, 01:23:49
Gruß
Beitrag von: Telekatz am 25 Juli 2016, 20:42:55
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.
Beitrag von: mrbit1968 am 29 Juli 2016, 00:03:38
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ß
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
Beitrag von: RalfRog am 29 Juli 2016, 22:41:04
- mein 2ter Cube (USB) vom HM-Mode zu SlowRF umgeschaltet --> FS20 wird emfpangen
FS20-Remote funktioniert also grundsätzlich schon mal - meinen 1ten Cube vom LAN an den USB Anschluss und im HM-Mode probiert
und siehe da schalten geht, aber der ACK fehlt
Da sieht sehr nach Defekt im Empfangsteil aus. Testhalber flash ich ihn nochmal.
Beitrag von: mrbit1968 am 01 August 2016, 22:02:04
Gruß
Beitrag von: Telekatz am 02 August 2016, 10:13:16
Beitrag von: RalfRog am 03 August 2016, 22:39:06
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
Beitrag von: Telekatz am 04 August 2016, 11:05:59
Beitrag von: mrbit1968 am 12 August 2016, 22:35:12
Beitrag von: raspklaus am 02 September 2016, 08:57:39
Wie bekomme ich den Cube trotzdem ans Laufen ?
Beitrag von: Telekatz am 02 September 2016, 11:44:03
Beitrag von: hietzi am 20 September 2016, 14:32:39
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
Code: [Auswählen]
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
Beitrag von: hietzi am 20 September 2016, 21:18:32
Ich habe folgendes Script am lauffen
Code: [Auswählen]
#############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?
Beitrag von: Telekatz am 21 September 2016, 18:37:28
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.
Beitrag von: mrbit1968 am 03 Oktober 2016, 06:12:22
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ß
Beitrag von: rubbertail am 03 Oktober 2016, 15:17:52
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?
Beitrag von: mrbit1968 am 07 Oktober 2016, 07:10:18
Gruß
Beitrag von: JayP am 10 Oktober 2016, 22:52:43
Code: [Auswählen]
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.
Code: [Auswählen]
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=128EDIT: Hat sich erledigt. Die Stromversorgung des Cube war nicht ausreichend. Mit einem anderen Netzteil habe ich keine Probleme mehr.
Beitrag von: Haui74 am 18 Oktober 2016, 16:06:41
Danke!! :)
Beitrag von: Telekatz am 18 Oktober 2016, 17:29:20
Desweiteren readme der Toolchain befolgen:
https://launchpadlibrarian.net/186123405/readme.txt (https://launchpadlibrarian.net/186123405/readme.txt)
Beitrag von: Haui74 am 18 Oktober 2016, 18:23:30
Beitrag von: Telekatz am 18 Oktober 2016, 19:54:04
Alternativ kann der Pfad im Makefile eingetragen werden (ARMBASE und ARMPATH):
Code: [Auswählen]
###############################################################
#####
##### 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
Beitrag von: Haui74 am 19 Oktober 2016, 13:32:17
Code: [Auswählen]
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 2Edit: Wert der "PATH": C:\GNUTools\5.4\bin\;C:\GnuWin32\bin
Beitrag von: Telekatz am 19 Oktober 2016, 14:25:57
Beitrag von: mahowi am 19 Oktober 2016, 14:38:18
Hier mal mein Post vom letzten Jahr:
P.S.: Zum Kompilieren habe ich folgendes Makefile.local erstellt:Code: [Auswählen]###############################################################
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.
Beitrag von: Haui74 am 19 Oktober 2016, 15:04:50
Danke für die Hilfe Telekatz! :)
Beitrag von: Kopterframe am 21 Oktober 2016, 17:36:57
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
Beitrag von: Telekatz am 22 Oktober 2016, 12:32:38
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
Beitrag von: Telekatz am 22 Oktober 2016, 17:21:40
Beitrag von: rubbertail am 22 Oktober 2016, 17:59:36
Beitrag von: Kopterframe am 23 Oktober 2016, 11:36:25
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
Beitrag von: Telekatz am 23 Oktober 2016, 11:58:46
http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx (http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx)
Beitrag von: Kopterframe am 24 Oktober 2016, 17:16:27
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
Beitrag von: Telekatz am 24 Oktober 2016, 17:44:35
Beitrag von: Kopterframe am 24 Oktober 2016, 17:55:23
Beitrag von: Kopterframe am 24 Oktober 2016, 18:38:48
Vielen Dank für eure Hilfe
Heiko
Beitrag von: somebuddy am 27 Oktober 2016, 01:20:33
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 !
Beitrag von: rubbertail am 27 Oktober 2016, 08:36:22
Beitrag von: Telekatz am 27 Oktober 2016, 09:27:26
Beitrag von: somebuddy am 27 Oktober 2016, 12:35:04
Samba Log:
Code: [Auswählen]
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 !
Beitrag von: Kopterframe am 27 Oktober 2016, 18:25:03
Habe auch den bootloader aus dem vorletzten Paket genommen ;)
bekomme immer komisches loggs.
Code: [Auswählen]
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?
Beitrag von: Telekatz am 27 Oktober 2016, 20:16:31
Beitrag von: Kopterframe am 27 Oktober 2016, 21:49:31
Beitrag von: defdanny am 02 November 2016, 15:46:46
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?
Beitrag von: rubbertail am 02 November 2016, 16:20:44
Beitrag von: defdanny am 02 November 2016, 20:46:52
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 ...
Beitrag von: defdanny am 02 November 2016, 20:52:23
Jemand eine Idee, bei welchem Schritt ich falsch "abgebogen" bin?
Beitrag von: rubbertail am 02 November 2016, 21:03:31
Beim Cube reichts, wenn du nachm Anschließen aufs Knöpfke drückst - muss nicht gedrückt angehängt werden.
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 -> Transfer -> XMODEM -> Senden
Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
Xmodem als Dateiübertragungsprotokoll gewählt?Muss man schon, wenn schon eine Firmware drauf ist.
Beim Cube reichts, wenn du nachm Anschließen aufs Knöpfke drückst - muss nicht gedrückt angehängt werden.
Beitrag von: rubbertail am 02 November 2016, 21:15:38
Beitrag von: MAC66666 am 03 November 2016, 13:06:51
Beitrag von: defdanny am 03 November 2016, 21:32:00
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
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).
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?
Beitrag von: Telekatz am 04 November 2016, 10:18:12
Beitrag von: mrbit1968 am 05 November 2016, 22:06:07
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.
Beitrag von: Telekatz am 05 November 2016, 22:40:20
Beitrag von: mrbit1968 am 05 November 2016, 22:49:53
Gruß
Beitrag von: Telekatz am 05 November 2016, 22:57:38
Beitrag von: mrbit1968 am 05 November 2016, 23:04:17
Beitrag von: Telekatz am 05 November 2016, 23:09:06
Beitrag von: mrbit1968 am 05 November 2016, 23:11:00
Beitrag von: tmuecksch am 08 November 2016, 19:15:54
https://www.mediafire.com/folder/tf16radvztfd9/a-culfw
Beitrag von: Telekatz am 09 November 2016, 19:02:41
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)
Beitrag von: tmuecksch am 10 November 2016, 00:08:00
Beitrag von: Kroegi am 20 November 2016, 11:26:04
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?
Beitrag von: fireball2k am 20 November 2016, 16:35:50
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
Beitrag von: Telekatz am 20 November 2016, 17:40:04
Hab da grade auch so ein Phänomen mit dem Schätzchen.Schon mal probiert, ihm eine feste IP Adresse zuzuweisen?
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?
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...)
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.
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... ;)Der native Mode ist doch schon lange aktiv. Seit V1.20.01.
(Hintergrund: ich wollte mal bissele mit LaCrosse Sensoren rumspielen...)
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)
Beitrag von: Kroegi am 20 November 2016, 21:52:59
Beitrag von: Kroegi am 21 November 2016, 06:59:17
Hab beide CULs nun mit ihrer schon vorher vergebenen IP festgesetzt.
Nun sind beide wieder initialisiert und erreichbar.
DANKE!
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
Beitrag von: Telekatz am 27 November 2016, 19:08:03
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).
Beitrag von: fow0ryl am 28 November 2016, 18:23:27
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.
Code: [Auswählen]
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 deviceVon "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
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.
Beitrag von: Lupo am 02 Dezember 2016, 18:14:45
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:
Code: [Auswählen]
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456probiert, es kommt auch keine Verbindung zustande.
Wo liegt der Fehler? Oder wo KÖNNTE er liegen?
Beitrag von: fow0ryl am 02 Dezember 2016, 18:54:32
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)
Code: [Auswählen]
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_1Und 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
Beitrag von: Telekatz am 02 Dezember 2016, 19:34:22
Und per USB am RasPi hängend haben wir es mit:Rechte korrekt vergeben?Code: [Auswählen]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?
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)
Beitrag von: Lupo am 02 Dezember 2016, 19:52:02
Rechte korrekt vergeben?DANKE, das wars!!!
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)
Beitrag von: rotfisch am 06 Dezember 2016, 13:09:49
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:
- Der Mediafire link im ersten Posting führt nur zu einem leeren Mediafire Folder. Der richtige Link ist der aus dem "Alternative culfw" thread:
https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw - Der bootloader für den MAXCube scheint nicht mehr in den aktuellen binary releases enthalten zu sein. Letzte Version, die sie enthält war "a-culfw_1.20.08_build_220_master.zip"
- Readme.md von MapleCUL und CUBe sind vertauscht
- Programmieren des culfw über minicom hat bei mir nicht funktioniert (mit xmode ist Übertragung fehlgeschlagen, ascii schien zu funktionieren, aber danach immer noch nur im bootloader gelandet). Mit TeraTerm hat es auf Anhieb funktionert.
- Nach dem umflashen des Cube müssen alle bereits gepairten Geräte mit einem Werksreset zurückgesetzt werden, bevor man sie mit dem CUL wieder pairen kann
Viele Grüße,
rotfisch
Beitrag von: cs1711 am 07 Dezember 2016, 20:35:46
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
- http://www.mediafire.com/file/viytrdbpwd3iibf/a-culfw_1.20.08_build_220_master.zip heruntergeladen, denn dort ist der Bootloader drin
- http://www.mediafire.com/file/5lt0x9pnkhtsbkf/a-culfw_1.23.02_build_120.zip heruntergeladen, enthält neueste CULFW
- http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx -> SAM-BA 2.16 heruntergeladen und unter Win10 installiert
- http://ttssh2.osdn.jp/index.html.en -> Tera Term heruntergeladen und unter Win10 installiert
- a-culfw_1.20.08_build_220_master.zip und a-culfw_1.23.02_build_120.zip entpackt.
- Jetzt kommt vielleicht der verwirrende Teil. Die Anleitung für das Flashen des MAX!Cube liegt als README.md im Ordner MapleCUL.
- Also Schritt für Schritt wie in der README.md, allerdings die bootloader_CUBE.bin aus a-culfw_1.20.08_build_220_master.zip verwendet. Liegt dort unter CUBe\bootloader.
Anschließend Netzwerkkabel angeschlossen und Verbindung mit verbundenem USB Kabel mittels Tera Term wieder aufgebaut. Zum Testen ein paar Befehle abgesetzt (einfach eingetippt):
Code: [Auswählen]
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.10Wurde 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:
Code: [Auswählen]
telnet 10.10.10.10 2323Verbindung funktioniert.Dann den Cube in die fhem.cfg eingetragen. Zum Testen aktiviere ich autocreate.
Code: [Auswählen]
define autocreate autocreate
attr autocreate autosave 1
attr autocreate filelog ./log/auto-%NAME-%Y.logDann der Cube (rfmode SlowRF ist nur zum Testen):
Code: [Auswählen]
define CULCuBE_1 CUL 10.10.10.10:2323 0000
attr CULCuBE_1 icon cul_868
attr CULCuBE_1 rfmode SlowRFKonfiguration 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:
Code: [Auswählen]
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_HOERMANNNun aber noch zu meinem Problem. Setze ich den Toggle-Befehl für CUL_HOERMANN ab, kommt im Telnet-Fenster nur folgendes:
Code: [Auswählen]
? (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?
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:HOERMANN_SEND war für den Cube nicht aktiviert. Kommt mit der nächsten Version.Code: [Auswählen]? (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?
Beitrag von: cs1711 am 10 Dezember 2016, 21:57:53
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:
Code: [Auswählen]
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:
Code: [Auswählen]
set CULCuBE_1 hmPairForSec 600Dann 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?
Beitrag von: Telekatz am 10 Dezember 2016, 22:19:46
Beitrag von: cs1711 am 11 Dezember 2016, 09:21:52
Beitrag von: cs1711 am 12 Dezember 2016, 10:17:47
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.
Beitrag von: micky0867 am 13 Dezember 2016, 19:53:50
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
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.Woran sieht man jetzt welchen Chip man drauf hat? Ich finde keiner der beiden Bezeichnungen auf der Platine vom Cube.
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?
Beitrag von: Telekatz am 16 Dezember 2016, 19:19:59
Beitrag von: Lupo am 16 Dezember 2016, 19:23:33
Beitrag von: chapelhill am 18 Dezember 2016, 12:47:27
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.
Code: [Auswählen]
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
Beitrag von: Telekatz am 18 Dezember 2016, 14:40:14
Beitrag von: chapelhill am 18 Dezember 2016, 14:49:11
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
Beitrag von: Telekatz am 18 Dezember 2016, 14:55:14
Beitrag von: chapelhill am 22 Dezember 2016, 16:42:03
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
Code: [Auswählen]
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)
Beitrag von: iceweasel3000 am 27 Dezember 2016, 20:07:43
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
Beitrag von: mahowi am 28 Dezember 2016, 12:19:28
Code: [Auswählen]
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.
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.
Beitrag von: mahowi am 28 Dezember 2016, 13:43:22
Beitrag von: iceweasel3000 am 29 Dezember 2016, 11:22:30
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
Beitrag von: Edi77 am 30 Dezember 2016, 00:37:35
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?
Beitrag von: alangward am 01 Januar 2017, 12:22:23
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
Beitrag von: alangward am 01 Januar 2017, 12:23:50
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
Beitrag von: alangward am 01 Januar 2017, 12:44:51
Ignore my question.
I have now got it connected over Ethernet.
It just needed re-booting.
Thanks,
Alan
Beitrag von: malc_b am 02 Januar 2017, 11:11:17
(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:
Code: [Auswählen]
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
Code: [Auswählen]
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
Beitrag von: Telekatz am 02 Januar 2017, 11:29:52
If you want to compile the Firmware wit 4.8, you have to remove the -fno-isolate-erroneous-paths-dereference parameter in the OPTFLAGS.
Beitrag von: malc_b am 02 Januar 2017, 11:41:29
Beitrag von: chapelhill am 02 Januar 2017, 12:10:02
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.
Beitrag von: SaDa am 03 Januar 2017, 02:24:43
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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
Beitrag von: Bennemannc am 04 Januar 2017, 16:40:54
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
Beitrag von: Telekatz am 04 Januar 2017, 16:47:36
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?
Code: [Auswählen]
define MaxCubeLAN CUL 192.168.0.55:2323 0000
Beitrag von: Telekatz am 05 Januar 2017, 23:18:09
Beitrag von: Bennemannc am 06 Januar 2017, 04:15:58
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
Beitrag von: Telekatz am 06 Januar 2017, 09:22:35
Code: [Auswählen]
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.
Beitrag von: dbeu am 06 Januar 2017, 12:45:52
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
Beitrag von: Telekatz am 06 Januar 2017, 14:11:30
Beitrag von: dbeu am 06 Januar 2017, 15:21:52
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?
Beitrag von: Telekatz am 06 Januar 2017, 18:09:09
Beitrag von: freetz am 10 Januar 2017, 20:34:51
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.
Beitrag von: Oern am 10 Januar 2017, 20:44:14
Schau mal in den Vorgängerversionen, dort findest du sie.
Gesendet von meinem HTC One_M8 mit Tapatalk
Beitrag von: freetz am 10 Januar 2017, 23:17:13
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.
Beitrag von: freetz am 11 Januar 2017, 09:42:17
- 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.
Beitrag von: freetz am 11 Januar 2017, 14:29:55
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.
Beitrag von: tca am 11 Januar 2017, 20:26:04
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
Beitrag von: Telekatz am 11 Januar 2017, 21:11:35
Beitrag von: tca am 11 Januar 2017, 21:43:50
Beitrag von: freetz am 11 Januar 2017, 22:56:50
In den Changelogs der a-culfw steht schon für Version 1.20.05
Code: [Auswählen]
- 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
Code: [Auswählen]
CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODevLiegt 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.
Beitrag von: Telekatz am 11 Januar 2017, 23:25:44
Beitrag von: freetz am 11 Januar 2017, 23:27:07
Beitrag von: phoenix am 12 Januar 2017, 19:29:39
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?
Beitrag von: freetz am 12 Januar 2017, 19:32:24
Beitrag von: phoenix am 12 Januar 2017, 19:39:16
Beitrag von: phoenix am 12 Januar 2017, 19:41:57
Beitrag von: Bennemannc am 13 Januar 2017, 05:06:43
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
Beitrag von: phoenix am 13 Januar 2017, 07:52:09
Manchmal scheint echt der Wurm drin zu sein
Beitrag von: Bennemannc am 13 Januar 2017, 08:22:20
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
Beitrag von: mahowi am 13 Januar 2017, 10:00:12
Beitrag von: malc_b am 13 Januar 2017, 11:01:55
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.
Beitrag von: phoenix am 14 Januar 2017, 10:09:41
Beitrag von: Bennemannc am 14 Januar 2017, 20:10:35
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
Beitrag von: Christian1982 am 15 Januar 2017, 15:48:00
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?
Beitrag von: Telekatz am 16 Januar 2017, 11:50:53
Beitrag von: stenny73 am 16 Januar 2017, 13:33:20
Habe in die /etc/init.d/fhem ein sleep 10 vor den Start eingesetzt - seit dem klappte es immer.
Gesendet von iPhone mit Tapatalk
Beitrag von: mrbit1968 am 21 Januar 2017, 07:48:58
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ß
Beitrag von: tca am 26 Januar 2017, 22:26:08
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?
Beitrag von: Telekatz am 26 Januar 2017, 22:44:00
In der angefügten Version hab ich es mal auf 512 erhöht.
Beitrag von: tca am 26 Januar 2017, 22:53:41
Bin gerade unterwegs, werde es sobald wie möglich testen. Ehm, flashen geht nur per USB nicht über Netzwerk, oder?
Beitrag von: Telekatz am 26 Januar 2017, 23:21:20
Beitrag von: T1mo am 28 Januar 2017, 19:51:21
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
Beitrag von: rubbertail am 28 Januar 2017, 20:11:32
Beitrag von: mahowi am 28 Januar 2017, 20:13:54
Beitrag von: T1mo am 28 Januar 2017, 20:30:19
Dann muss ich die zwei Pins miteinander verlöten?
sry für die dummen Fragen!
Beitrag von: mahowi am 28 Januar 2017, 20:32:39
Beitrag von: T1mo am 28 Januar 2017, 20:34:15
Beitrag von: chris1284 am 30 Januar 2017, 06:55:21
Beitrag von: malc_b am 30 Januar 2017, 09:43:59
Beitrag von: BlackStone am 30 Januar 2017, 22:22:53
@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.
Beitrag von: Telekatz am 02 Februar 2017, 11:38:18
Beitrag von: T1mo am 08 Februar 2017, 13:40:42
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
Beitrag von: BlackStone am 08 Februar 2017, 13:44:48
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
Beitrag von: T1mo am 08 Februar 2017, 13:48:56
Wie muss ich das dann verstehen?
Vielen Dank für deine schnelle Antwort
Beitrag von: BlackStone am 08 Februar 2017, 13:51:09
Gesendet von meinem E6853 mit Tapatalk
Beitrag von: BlackStone am 08 Februar 2017, 13:52:56
Gesendet von meinem E6853 mit Tapatalk
Beitrag von: T1mo am 08 Februar 2017, 13:59:01
Ich hab es in den Einstellungen geändert und danach kommt der Fehler.
Beitrag von: BlackStone am 08 Februar 2017, 14:01:52
Gesendet von meinem E6853 mit Tapatalk
Beitrag von: mahowi am 08 Februar 2017, 14:05:21
Code: [Auswählen]
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.
Beitrag von: T1mo am 08 Februar 2017, 14:16:07
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 :'(
Beitrag von: Weisswurstverkäufer am 08 Februar 2017, 14:20:15
Code: [Auswählen]
ls -la /dev/serial/by-id/?
Beitrag von: T1mo am 08 Februar 2017, 14:31:31
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
Beitrag von: Weisswurstverkäufer am 08 Februar 2017, 14:33:21
Code: [Auswählen]
/dev/ttyACM0 nehmen (das hinten ist eine Null)
Beitrag von: T1mo am 08 Februar 2017, 14:42:45
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
Beitrag von: Weisswurstverkäufer am 08 Februar 2017, 14:45:50
Beitrag von: T1mo am 08 Februar 2017, 16:51:33
Beim ersten Mal wurde was gesendet und ist einer Fehler gekommen und jetzt passiert gar nichts.
Ich hatte nochmal alles von vorne gemacht
Beitrag von: mahowi am 08 Februar 2017, 18:00:26
Code: [Auswählen]
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.
Beitrag von: T1mo am 08 Februar 2017, 21:38:18
Danke dir
Beitrag von: T1mo am 09 Februar 2017, 14:53:15
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
Beitrag von: mahowi am 09 Februar 2017, 14:57:06
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.
Beitrag von: ripperle am 11 Februar 2017, 11:06:59
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
Beitrag von: Telekatz am 11 Februar 2017, 11:37:46
Beitrag von: ripperle am 11 Februar 2017, 11:51:01
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.... ???
Beitrag von: ripperle am 11 Februar 2017, 12:22:28
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?
Beitrag von: Telekatz am 11 Februar 2017, 12:28:06
Beitrag von: ripperle am 11 Februar 2017, 13:08:41
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!
Beitrag von: Christian1982 am 12 Februar 2017, 19:07:27
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?
Beitrag von: Bond246 am 13 Februar 2017, 00:20:18
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
Beitrag von: Weisswurstverkäufer am 13 Februar 2017, 07:39:56
Mehrere Protokolle auf einem CUL geht nicht - Du musst immer einen Modus wählen (z. B. Homematic, MAX).
Beitrag von: Code006 am 13 Februar 2017, 22:58:47
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
Beitrag von: Telekatz am 13 Februar 2017, 23:21:30
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...
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
Beitrag von: fabi29891 am 25 Februar 2017, 15:18:06
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.
Beitrag von: mahowi am 04 März 2017, 06:47:10
Beitrag von: Telekatz am 04 März 2017, 12:35:13
Beitrag von: A.Harrenberg am 05 März 2017, 11:13:16
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.
Beitrag von: KölnSolar am 16 März 2017, 09:11:37
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
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??
Beitrag von: Johnnyflash am 21 März 2017, 09:54:44
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
Beitrag von: Telekatz am 21 März 2017, 11:35:39
Moin. Hab erneut dieses Problem, allerdings mit dem anderen Cube.Wenn du ihn aus FHEM gelöscht hast, musst du ihn neu anlegen. Von alleine wird er nicht angelegt.
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??
Hallo zusammen,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.
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
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
Beitrag von: Telekatz am 21 März 2017, 12:03:54
Beitrag von: tca am 26 März 2017, 22:19:50
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:
Code: [Auswählen]
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
Beitrag von: Telekatz am 26 März 2017, 22:38:10
Beitrag von: tca am 27 März 2017, 12:47:24
WMBus-Device [COC]
Code: [Auswählen]
COC_RAWMSG
b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61
WMBus-Device [CUBe]
Code: [Auswählen]
cube_RAWMSG
b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
Logfile [COC]
Code: [Auswählen]
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]
Code: [Auswählen]
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.
Beitrag von: Telekatz am 27 März 2017, 13:28:50
Beitrag von: tca am 27 März 2017, 14:04:23
COC
Code: [Auswählen]
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: /b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFCUBe
Code: [Auswählen]
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
Beitrag von: Telekatz am 27 März 2017, 22:00:15
Beitrag von: tca am 27 März 2017, 22:58:15
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?
Beitrag von: Telekatz am 27 März 2017, 23:12:36
Beitrag von: tca am 28 März 2017, 00:14:25
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?
Beitrag von: Telekatz am 28 März 2017, 22:32:55
Beitrag von: tca am 28 März 2017, 23:53:12
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!!!
Beitrag von: bigmo am 14 April 2017, 22:07:04
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
Beitrag von: bigmo am 15 April 2017, 11:24:52
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
Beitrag von: RaspiLED am 15 April 2017, 11:40:09
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, ...
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 !
Beitrag von: audimax am 20 April 2017, 14:31:51
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
Beitrag von: pejonp am 20 April 2017, 17:02:30
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
Beitrag von: mahowi am 20 April 2017, 17:42:33
Beitrag von: audimax am 20 April 2017, 17:49:04
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
Beitrag von: audimax am 28 April 2017, 18:31:12
Beitrag von: Telekatz am 28 April 2017, 18:47:51
Beitrag von: palatin8 am 30 April 2017, 03:04:28
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?
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 !
Beitrag von: Andy77H am 07 Juni 2017, 20:52:49
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
Beitrag von: RaspiLED am 07 Juni 2017, 21:31:17
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, ...
Beitrag von: Telekatz am 07 Juni 2017, 21:32:27
Beitrag von: Andy77H am 07 Juni 2017, 22:45:59
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...
Beitrag von: Andy77H am 07 Juni 2017, 22:47:34
: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:
Beitrag von: Telekatz am 07 Juni 2017, 23:10:55
Beitrag von: Andy77H am 07 Juni 2017, 23:28:32
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
Beitrag von: Andy77H am 07 Juni 2017, 23:48:32
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...
???
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
Beitrag von: RaspiLED am 08 Juni 2017, 08:12:43
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, ...
Beitrag von: Andy77H am 08 Juni 2017, 11:11:56
Cube List nach einem Reset (sollte das gleiche wie oben sein):
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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?
Code: [Auswählen]
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
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
Cube ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dBlist Cube schaut dann so aus:
Code: [Auswählen]
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 ;)
Beitrag von: Telekatz am 08 Juni 2017, 11:47:50
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.
Beitrag von: Andy77H am 08 Juni 2017, 14:22:36
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...
Beitrag von: Andy77H am 08 Juni 2017, 14:39:40
Das raw-Kommando brx, welches beim Umstalten auf slowRF gesetzt wird, gibt auch was zurück:
Code: [Auswählen]
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 modeHabe daher mal folgendes versucht "get Cube raw brx" und erhalte dann:
Code: [Auswählen]
2017.06.08 14:31:18 5: SW: brx
2017.06.08 14:31:18 5: CUL/RAW (ReadAnswer): OFFEin "get Cube raw C35" liefert:
Code: [Auswählen]
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)?
Beitrag von: Telekatz am 08 Juni 2017, 15:15:59
-) 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.
Beitrag von: Andy77H am 08 Juni 2017, 15:44:13
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
Beitrag von: Telekatz am 08 Juni 2017, 18:16:02
Beitrag von: Andy77H am 08 Juni 2017, 21:46:29
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)
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?
Beitrag von: Telekatz am 28 Juni 2017, 22:00:06
Bezüglich HMS und FS20 sollte es eigentlich keinen Unterschied in den Versionen geben.
Beitrag von: Thomas Vandahl am 02 Juli 2017, 10:33:59
Beitrag von: Telekatz am 02 Juli 2017, 14:03:15
Beitrag von: HansDampfHH am 08 Juli 2017, 10:23:03
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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
Beitrag von: eckonator am 17 Juli 2017, 23:29:02
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!
Beitrag von: RaspiLED am 18 Juli 2017, 13:06:18
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Beitrag von: eckonator am 19 Juli 2017, 21:20:18
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.
Beitrag von: Telekatz am 19 Juli 2017, 21:40:51
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?
Beitrag von: Telekatz am 19 Juli 2017, 22:46:33
Das Gehäuse ist nicht verschraubt. Der obere Teil des Gehäuses ist nur draufgesteckt und rastet mit 4 Rastnasen ein.
Beitrag von: eckonator am 22 Juli 2017, 15:01:09
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.
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
Beitrag von: RalfPit am 03 September 2017, 19:25:16
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
Beitrag von: hollyghost am 03 September 2017, 19:55:08
Danke & Gruß
Holger
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
Code: [Auswählen]
#define USB_DESCRIPTOR_SN '1' ändern, z.B. auf 0. Damit heißen die Devices dann ...USBSerial0... usw.
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?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.
Danke & Gruß
Holger
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
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 ZeileCode: [Auswählen]#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
Beitrag von: Holzlenkrad am 06 September 2017, 12:09:53
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?
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.
Beitrag von: E-J-D am 07 September 2017, 21:23:53
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
Beitrag von: nanocosmos am 09 September 2017, 16:45:49
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.
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:
- PA5
- PA6
- PA10
- PA11
- PB24
- PB25
In der board.h sind aber noch die OUT-Pins/IRQ-Pins angegeben:
- PA9
- PB20
- PB28
Ich wäre für eine Hilfestellung dankbar!
Alex
PS: Grandiose Arbeit!
Beitrag von: Telekatz am 12 September 2017, 21:08:19
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.
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?
Beitrag von: pc1246 am 13 September 2017, 12:04:39
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 V220
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.
Beitrag von: Telekatz am 13 September 2017, 18:24:56
Danke für die schnelle Antwort!Die OUT Pins brauchen keinen Interrupt. Deshalb ist es egal, welchen Pin man dafür nimmt.
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?
Beitrag von: nanocosmos am 14 September 2017, 17:15:35
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
Beitrag von: pc1246 am 14 September 2017, 23:06:25
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
Beitrag von: nanocosmos am 15 September 2017, 12:11:56
Habe es jetzt mit einem anderen Rechner probiert und da läuft es.
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):
- VCC
- GND
- MOSI
- SCLK
- MISO
- GDO2
- GDO0
- CS
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.
Beitrag von: Telekatz am 15 September 2017, 18:04:24
Sorry, ich muss nochmal "dumm" fragen...Das ist die Belegung der China Briefmarken Module.
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
Die ELV Module haben eine andere Belegung:
- MOSI
- SCK
- MISO
- GDO2
- GDO0
- CS
- GND
- VCC
Beitrag von: Wzut am 15 September 2017, 19:31:03
Beitrag von: adn77 am 16 September 2017, 14:50:32
Sorry für die Konfusion... die Bilder, die Telekatz in Antwort #823 zur Verfügung gestellt hat, sind absolut korrekt ;)
- Ich habe am CUBE zwei weitere CC1101 angeschlossen (433 und 868MHz).
- Anstelle der "komplizierten" PA9,PB20,PB28 habe ich die PB24 und PB25 als "OUT" Pins benutzt und die board.h entsprechend angepasst
- Kompiliert habe ich das Ganze auf einem RPi unter Stretch (9.1) mit "gcc-arm-none-eabi" (v4.9.3)
- Den Ur-Bootloader habe ich aus der 1.20.08_build_220_master.zip
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
Beitrag von: shorty1409 am 16 September 2017, 17:36:15
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
- Test mit culfw "a-culfw_1.25.01_build_258" --> nicht erfolgreich!
- Test mit culfw "a-culfw_1.23.09_build_195" --> Erfolg! Die FS20 lassen sich anlernen!
- Test mit culfw "a-culfw_1.24.02_build_209" --> Erfolg! Die FS20 lassen sich anlernen!
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! ;)
Beitrag von: Telekatz am 16 September 2017, 22:46:36
Beitrag von: Tedious am 21 September 2017, 13:15:54
Beitrag von: Telekatz am 21 September 2017, 20:10:40
Blinkt der MapleCUN? Über LAN oder USB angeschlossen?
Beitrag von: Tedious am 21 September 2017, 21:11:47
Gesendet von iPhone mit Tapatalk
Beitrag von: Telekatz am 21 September 2017, 22:03:35
Beitrag von: Tedious am 21 September 2017, 22:29:45
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
Beitrag von: Telekatz am 21 September 2017, 22:35:50
Beitrag von: Tedious am 21 September 2017, 22:37:08
Gesendet von iPhone mit Tapatalk
Beitrag von: Telekatz am 21 September 2017, 22:42:10
Beitrag von: Tedious am 21 September 2017, 22:44:39
#! /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
Beitrag von: Telekatz am 21 September 2017, 22:51:22
Beitrag von: Tedious am 22 September 2017, 09:09:26
besten Dank, teste ich heute Abend mal aus.
Grüße
Sascha
Beitrag von: persching am 30 September 2017, 16:17:50
Beitrag von: shorty1409 am 30 September 2017, 16:22:22
Beitrag von: persching am 30 September 2017, 16:35:31
Beitrag von: pantau am 30 September 2017, 21:11:25
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!
Beitrag von: Telekatz am 30 September 2017, 23:01:55
Beitrag von: mfischer-ffb am 05 Oktober 2017, 19:36:53
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
Beitrag von: Telekatz am 05 Oktober 2017, 20:45:01
Beitrag von: mfischer-ffb am 05 Oktober 2017, 22:47:08
irgendwo hab ich hier was übersehen.....
Beitrag von: Telekatz am 05 Oktober 2017, 23:58:56
Beitrag von: mfischer-ffb am 06 Oktober 2017, 18:57:00
Jetzt schauts gut aus ...
Beitrag von: adn77 am 12 Oktober 2017, 08:55:34
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).
Code: [Auswählen]
--- 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
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.
Beitrag von: adn77 am 12 Oktober 2017, 23:46:44
Gut zu wissen, dass es bei 433MHz keine Belegungsbeschränkung gibt.
Beitrag von: wendeling am 24 Oktober 2017, 10:57:40
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 ?
Beitrag von: Telekatz am 24 Oktober 2017, 11:45:15
- neuen com Board ausgewähltDa muss man kein neues com Board oder eine Datei auswählen. In der Liste steht schon das passende Board "at91sam7x256-ek".
- Datei .... 7x.256 ausgewählt
-und dann Connect
- Fenster verschwindet
Es gibt auch Cubes mit einem at91sam7x512. Da wählt man dann als Board "at91sam7x512-ek" aus.
Beitrag von: mahowi am 24 Oktober 2017, 11:48:59
Beitrag von: wendeling am 24 Oktober 2017, 17:09:35
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 !
Beitrag von: Telekatz am 24 Oktober 2017, 21:08:14
Beitrag von: wendeling am 25 Oktober 2017, 12:21:39
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?
Beitrag von: Wzut am 25 Oktober 2017, 13:21:32
b + c => https://wiki.fhem.de/wiki/MAX
Beitrag von: Holzlenkrad am 19 November 2017, 00:46:33
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...
Beitrag von: scooty am 19 November 2017, 15:00:45
Code: [Auswählen]
set Name_Deines_MaxCubes led 00
Beitrag von: uelpenich am 10 Dezember 2017, 13:30:23
Bisher habe ich es nicht geschafft, auf meinem CUBEx4 den external 433 MHz Transceiver auf Port1 in Betrieb zu nehmen.
Fragen:
- 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.
- 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
Code: [Auswählen]
#++++++++++++++ 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: Code: [Auswählen]
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. Code: [Auswählen]
#
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: Code: [Auswählen]
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?- bei meinen Lötkünsten?
- bei der Definition in FHEM?
- fehlt in FHEM noch die CUBEx4 Erweiterung?
Beitrag von: Telekatz am 10 Dezember 2017, 14:39:30
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.
- 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.
Gib im Terminal folgende Befehle ein:
Code: [Auswählen]
V
*V
X21
Zr
*X21
C99
*C99
Die Ausgabe vom Cube sollte ungefähr so aussehen:Code: [Auswählen]
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.:Code: [Auswählen]
Z0B2406300FEF7412345600524E
Z0B2506300FEF74123456001050
*s2C6FEE6013; 464: 9536
*i00115103
*i00115404
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):
- 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
Code: [Auswählen]
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 SystemWenn 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.
Beitrag von: BHef am 10 Dezember 2017, 18:09:00
a) Welchen Vorteil bietet mir das umflashen?
b) wenn das schiefgeht, kann ich mit Fhem und den Max Komponenten OHNE den Cube arbeiten?
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:Das wurde erst kürzlich hier diskutiert:
a) Welchen Vorteil bietet mir das umflashen?
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.
Beitrag von: BHef am 10 Dezember 2017, 19:18:51
Beitrag von: uelpenich am 11 Dezember 2017, 12:45:17
Code: [Auswählen]
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. Code: [Auswählen]
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)):
| Cube | AS07-M1101S | Pin | Pin direction | Pin uses |
| VCC | VCC | 1 | Power supply, must be in the range 1.9-3.6V | |
| OUT (PB25) | GOD0 | 2 | Module information output pin | |
| CS (PA6) | CSN | 3 | Input | Module chip select pin, used to start a SPC communication |
| SCK | SCK | 4 | Input | SPI bus clock |
| MOSI | MOSI | 5 | Input | Module SPI data input pin |
| MOSI/GD | ?? was ist das ?? | |||
| MISO | GOD1 (O1) | 6 | ??Input?? | Input module SPI data output pin |
| IN (PA5) | GOD2 | 7 | Output | Output module information output pin |
| GND | GND | 8 | Output | Express, connected to the power supply ground reference. |
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.
Code: [Auswählen]
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:Code: [Auswählen]
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
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?
Beitrag von: uelpenich am 11 Dezember 2017, 22:07:53
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:
Code: [Auswählen]
-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:Code: [Auswählen]
V
*V
X21
ZrAm Debug Port erscheint:Code: [Auswählen]
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
Code: [Auswählen]
-I- Getting new Started Project --
-I- CUBEx4 . . . und weiter mit dem ganzen Rest, den wir oben beim Einschalten sehen . . .
Gruß Werner
Beitrag von: Telekatz am 16 Dezember 2017, 16:42:57
Code: [Auswählen]
-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.
Beitrag von: uelpenich am 16 Dezember 2017, 22:59:53
Code: [Auswählen]
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.
Beitrag von: Allodo am 28 Dezember 2017, 14:09:27
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 ;)
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:
Code: [Auswählen]
define Cube CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1234
Beitrag von: Allodo am 29 Dezember 2017, 07:31:24
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 :)
Beitrag von: caligo23 am 05 Januar 2018, 19:48:21
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.
Beitrag von: Telekatz am 06 Januar 2018, 18:06:49
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.
Beitrag von: OtisWright am 06 Januar 2018, 19:30:25
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.
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.
Beitrag von: OtisWright am 06 Januar 2018, 20:11:02
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
Beitrag von: Telekatz am 06 Januar 2018, 20:19:45
VERSIONErkannt worden ist der zweite Transceiver.
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
Mach mal mit raw e einen Reset der Einstellungen.
Beitrag von: OtisWright am 06 Januar 2018, 20:26:11
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?
Beitrag von: caligo23 am 06 Januar 2018, 20:28:18
Ihr seid einfach Klasse!
Grüßle
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 :(
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:Teste mal, ob es über USB funktioniert.
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?
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.
Beitrag von: OtisWright am 06 Januar 2018, 21:14:49
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!
Beitrag von: freetz am 17 Januar 2018, 00:42:49
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.
Beitrag von: freetz am 17 Januar 2018, 07:41:44
Beitrag von: blueicechip am 17 Januar 2018, 08:28:54
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.
Beitrag von: freetz am 17 Januar 2018, 08:43:08
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!
Beitrag von: uelpenich am 23 Januar 2018, 17:46:06
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:Code: [Auswählen]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.
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?
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?
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.
Beitrag von: Wzut am 24 Januar 2018, 10:37:02
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.
Beitrag von: Telekatz am 24 Januar 2018, 11:44:37
Beitrag von: uelpenich am 24 Januar 2018, 11:50:59
Ich hätte da gerne mal ein Problem :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.
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.
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.
Beitrag von: toxic-tonic am 26 Januar 2018, 15:31:28
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:
Code: [Auswählen]
...
-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
Beitrag von: Telekatz am 26 Januar 2018, 16:11:26
Beitrag von: toxic-tonic am 26 Januar 2018, 16:19:21
Beitrag von: toxic-tonic am 29 Januar 2018, 12:07:54
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:
Code: [Auswählen]
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 - PA5Voraussetzung ist dieser Patch: https://loetzimmer.de//patches/cube.patch um die PINs richtig zuzuordnen!
Gruß
Tobias
Beitrag von: toxic-tonic am 02 Februar 2018, 07:45:41
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
Beitrag von: Telekatz am 02 Februar 2018, 17:10:31
Beitrag von: toxic-tonic am 05 Februar 2018, 08:52:15
habe es jetzt noch mal näher eruiert. Denke das Problem ist die Konfiguration als MAX-Device. meine config sieht so aus:
Code: [Auswählen]
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
Beitrag von: Telekatz am 05 Februar 2018, 18:46:36
Code: [Auswählen]
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.
Beitrag von: toxic-tonic am 07 Februar 2018, 19:16:12
Habs auch rausbekommen, musste noch den SlowRF als rfmode setzen:
Code: [Auswählen]
define cun02 STACKABLE_CC cun01
attr cun02 rfmode SlowRF
attr cun02 room Z_-_System
Danke und Gruß
Tobias
Beitrag von: DJNoXD am 19 März 2018, 09:16:08
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:
Code: [Auswählen]
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:
Code: [Auswählen]
*N0195C3723701AAAA0000943243
H431780280055FF
*N0191D8167D03DE716B676BD0D9
H434701160400FF
Hier die Ausgaben der Module:
CUL0 (orginal Cube Modul):
Internals:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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:
Code: [Auswählen]
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
Beitrag von: RaspiLED am 19 März 2018, 13:52:14
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, ...
Beitrag von: Telekatz am 19 März 2018, 21:37:32
Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.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.
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.
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.
Beitrag von: DJNoXD am 19 März 2018, 22:44:05
Ich habe die Reihenfolge geändert.
CUL0 = SlowRF
CUL1 = MAX
Ich melde mich wieder, sobald ich etwas sagen kann.
Beitrag von: DJNoXD am 20 März 2018, 09:29:37
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?
Beitrag von: daredevil.2k am 21 März 2018, 08:54:43
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?
Beitrag von: RalfRog am 16 April 2018, 00:29:55
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
Beitrag von: RalfRog am 16 April 2018, 01:13:52
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)
Code: [Auswählen]
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
Beitrag von: phantom am 16 April 2018, 15:21:13
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:
Code: [Auswählen]
}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
Beitrag von: phantom am 17 April 2018, 22:08:54
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
Beitrag von: RalfRog am 21 April 2018, 18:20:39
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.
Beitrag von: nussknacker4711 am 24 April 2018, 16:44:52
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
Beitrag von: RaspiLED am 24 April 2018, 18:40:31
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, ...
Beitrag von: adn77 am 24 April 2018, 19:25:22
Evtl. reichen die max. 500mA am USB Port nicht aus. Gibt es qualifizierte Erkenntnisse bzgl. der Leistungsaufnahme?
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.
Beitrag von: Hallmackenreuther am 10 Juni 2018, 22:43:07
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.
Beitrag von: Hallmackenreuther am 16 Juni 2018, 15:26:30
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)
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-ITHallo,
verstehe ich es richtig, für MAX! und LaCrosse benötigt man zwei Cubes?
Danke.
Beitrag von: RaspiLED am 04 Juli 2018, 19:53:36
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
Beitrag von: hulzer am 04 Juli 2018, 20:57:31
Der Lötkolben glüht schon...
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 LaCrossedas ist nett von dir behandelt aber leider das Symptom statt der Ursache ....
@Telekatz : bitte in die Make.conf noch mit aufnehmen (bzw. aufnehmen lassen) :
Code: [Auswählen]
SRCS += ../../clib/lacrosse.c
Beitrag von: Mihca am 03 Oktober 2018, 16:29:06
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:
Code: [Auswählen]
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
Beitrag von: berndEEE am 05 Oktober 2018, 12:42:22
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.
Beitrag von: RaspiLED am 05 Oktober 2018, 14:58:10
Das sieht doch schon ganz gut aus,
Mach mal ein
Code: [Auswählen]
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
Beitrag von: pc1246 am 05 Oktober 2018, 16:14:08
Und gib uns mal ein
Code: [Auswählen]
list cm, und bitte in codetags (ueber den smilies der "#")!Und von Arnd muesste es heissen
Code: [Auswählen]
attr cm verbose 5!Gruss Christoph
Beitrag von: pejonp am 05 Oktober 2018, 16:22:23
Falls die Geräte schon einmal angelernt waren erst ein reset machen .
Code: [Auswählen]
set cm pairmode 120 oder 240
Schau mal in die Doku ob 0000 als id geht. Ich trage dort z.B. 3453 ein.
Code: [Auswählen]
CUL_1 CUL 192.168.0.94:2323 3453
. Pejonp
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 ?
Beitrag von: berndEEE am 05 Oktober 2018, 16:50:06
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
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.
Beitrag von: berndEEE am 05 Oktober 2018, 19:55:49
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.
Beitrag von: berndEEE am 06 Oktober 2018, 12:13:55
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
Beitrag von: Mihca am 07 Oktober 2018, 16:23:24
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
Beitrag von: Andreas29 am 19 Oktober 2018, 07:00:55
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
Beitrag von: Andreas29 am 20 Oktober 2018, 16:08:25
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
Beitrag von: RaspiLED am 20 Oktober 2018, 16:33:46
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, ...
Beitrag von: Andreas29 am 20 Oktober 2018, 16:44:39
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
Beitrag von: RaspiLED am 20 Oktober 2018, 17:16:39
https://wiki.fhem.de/wiki/Rfmode
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Beitrag von: Andreas29 am 21 Oktober 2018, 17:35:31
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
Beitrag von: pc1246 am 22 Oktober 2018, 07:51:13
Hi,Moin
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
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
Beitrag von: RaspiLED am 22 Oktober 2018, 07:53:14
Ist es nicht einfacher ein temporäres FHEM zu nutzen (vielleicht mittels ser2net auf einem entfernten Rechner)!?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Beitrag von: Beta-User am 22 Oktober 2018, 10:17:55
Beitrag von: Andreas29 am 24 Oktober 2018, 07:51:49
meine Frage hat sich erledigt, das Problem lag an der Auswertung der Funktelegramme.
Danke und Grüße
Andreas
Beitrag von: EinfachFhem am 28 Oktober 2018, 20:38:25
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:
Code: [Auswählen]
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 :)
Beitrag von: RaspiLED am 28 Oktober 2018, 21:27:46
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
Beitrag von: pc1246 am 29 Oktober 2018, 08:25:30
Hallo Zusammen,Moin
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 :)
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
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.
Beitrag von: RaspiLED am 29 Oktober 2018, 12:19:39
Gesendet von iPhone mit Tapatalk
Beitrag von: EinfachFhem am 29 Oktober 2018, 12:32:14
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
Code: [Auswählen]
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 1und nach dem Reboot
Code: [Auswählen]
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 1Kann 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
Code: [Auswählen]
att Gerät IODev MAXLAN
Neu, Bezug auf den CUL_MAX
Code: [Auswählen]
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
Beitrag von: VolkerGBenner am 03 November 2018, 23:59:47
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?
Beitrag von: RaspiLED am 04 November 2018, 05:46:33
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
Beitrag von: VolkerGBenner am 04 November 2018, 13:18:18
Es lebt und antwortet schonmal
Code: [Auswählen]
VERSION 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?Beitrag von: Telekatz am 04 November 2018, 14:34:23
Beitrag von: VolkerGBenner am 04 November 2018, 17:09:46
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.
Beitrag von: VolkerGBenner am 09 November 2018, 17:42:18
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.
Beitrag von: Bond246 am 19 November 2018, 11:54:17
wenn ich den Cube umflashe, arbeitet er dann eigentlich noch als LAN-Device oder nur noch per USB?
Grüße
Beitrag von: EinfachFhem am 19 November 2018, 12:10:04
Gesendet von meinem Note3 mit Tapatalk
Beitrag von: Bond246 am 19 November 2018, 12:11:14
Danke für die Antwort :)
Beitrag von: Bond246 am 19 November 2018, 14:54:11
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
Code: [Auswählen]
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:Code: [Auswählen]
define MAXcul CUL_MAX 654321Jetzt 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:
Code: [Auswählen]
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/argumentWeiß jemand weiter?
Hier noch ein paar Internals:
Code: [Auswählen]
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 MAXCode: [Auswählen]
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
Beitrag von: gloob am 19 November 2018, 15:19:50
https://www.amazon.de/MAX-Cube-LAN-Gateway-99004/dp/B004W1Q2BO
Beitrag von: Wzut am 19 November 2018, 15:53:41
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)
Beitrag von: Bond246 am 19 November 2018, 16:23:23
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
Beitrag von: Wzut am 19 November 2018, 21:04:22
Darum mein Tipp in dem USB Kabel die beiden Drähte kappen und nur + & - ( i.d.R. schwarz und rot) übrig lassen.
Beitrag von: tcj am 23 November 2018, 15:35:50
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
Beitrag von: tcj am 24 November 2018, 17:03:17
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?
Beitrag von: Telekatz am 24 November 2018, 17:58:46
Beitrag von: tcj am 24 November 2018, 18:28:27
Dann wird das wohl nix mit Homegear
Jedenfalls nicht mit meinem Wissen und das, was ich im Netz so finde - bzw. nicht finde.
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 ;-)
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?
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.
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?
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.
Beitrag von: gloob am 26 November 2018, 10:49:31
Über Netzwerk wäre es vielleicht noch machbar.
Beitrag von: tcj am 26 November 2018, 10:57:33
Wie willst du aber 4 "CULs" über 3 Hardware Schnittstellen (USB) bekommen?Wie ich schon schrieb - ich weiß ja nicht, ob, was und wie das geht.
Über Netzwerk wäre es vielleicht noch machbar.
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 ;-)
Beitrag von: Telekatz am 26 November 2018, 12:10:24
Beitrag von: Starbug am 06 Dezember 2018, 21:26:43
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:
Code: [Auswählen]
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 openedCode: [Auswählen]
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:
Code: [Auswählen]
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:
- USB-Kabel direkt an den Raspi ohne Hub
- anderes USB-Kabel (direkt an den Raspi)
- Cube als CUNO an den Router angeschlossen; Stromversorgung über separates Netzteil
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?
Beitrag von: Clyde am 31 Dezember 2018, 17:48:07
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
Code: [Auswählen]
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
Code: [Auswählen]
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
Code: [Auswählen]
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
Beitrag von: pejonp am 31 Dezember 2018, 18:13:44
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
Beitrag von: Clyde am 01 Januar 2019, 10:54:45
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?
Beitrag von: pejonp am 01 Januar 2019, 11:23:04
Der erste cui ist für MAX!
Code: [Auswählen]
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
Beitrag von: Clyde am 01 Januar 2019, 12:14:05
Code: [Auswählen]
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.
Code: [Auswählen]
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?
Beitrag von: pejonp am 03 Januar 2019, 02:05:42
Code: [Auswählen]
defmod CULMAX0 CUL_MAX 123456
attr CULMAX0 IODev CUL_2
attr CULMAX0 room CUL_MAX
attr CULMAX0 verbose 2
pejonp
Beitrag von: Wzut am 03 Januar 2019, 07:15:29
set CUL_CUBe_MAX pairmodedir ist aber schon klar das da noch die Zeit in Sekunden fehlt ?
set CUL_CUBe_MAX pairmode 120 ?
Beitrag von: Clyde am 03 Januar 2019, 12:03:19
Die Thermostate tauchen aber nach einer gewissen Zeit (autocreate) in der Konfiguration auf:
Code: [Auswählen]
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.
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.Achtung, es gibt auch unterschiedliche Typen von MAX-Thermostaten:
Die Thermostate tauchen aber nach einer gewissen Zeit (autocreate) in der Konfiguration auf:Code: [Auswählen]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.
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
Beitrag von: Clyde am 03 Januar 2019, 14:23:09
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?
Beitrag von: d0np3p3 am 10 Januar 2019, 04:40:37
ist es auch möglich einen hm-mod-rpi-pcb direkt anzuschließen bzw zu löten?
Gesendet von meinem HTC U11 mit Tapatalk
Beitrag von: pc1246 am 10 Januar 2019, 08:29:02
Hallo zusammen, was meint ihr,Moin
ist es auch möglich einen hm-mod-rpi-pcb direkt anzuschließen bzw zu löten?
Gesendet von meinem HTC U11 mit Tapatalk
Wozu soll das gut sein? Es ist doch quasi einer im Cube verbaut!?
Gruss Christoph
Beitrag von: d0np3p3 am 10 Januar 2019, 10:50:21
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
Beitrag von: RaspiLED am 10 Januar 2019, 11:34:39
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, ...
Beitrag von: d0np3p3 am 11 Januar 2019, 10:54:34
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
Beitrag von: Telekatz am 11 Januar 2019, 13:33:28
Beitrag von: Clyde am 12 Januar 2019, 16:37:25
Ich bekomme nun alle Thermostate angelernt.
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
Beitrag von: d0np3p3 am 12 Januar 2019, 22:46:14
Sucht nach:
MOBILCOM-DEBITEL MAX! Cube LAN-Gateway
Gesendet von meinem HTC U11 mit Tapatalk
Beitrag von: RaspiLED am 13 Januar 2019, 12:17:50
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, ...
Beitrag von: gloob am 13 Januar 2019, 12:48:01
Beitrag von: RaspiLED am 13 Januar 2019, 13:04:06
Gesendet von iPhone mit Tapatalk
Beitrag von: d0np3p3 am 13 Januar 2019, 23:19:35
Ich würde mich freuen über den cube, was willst du denn für den cube?
Gesendet von meinem HTC U11 mit Tapatalk
Beitrag von: ra-ma am 14 Januar 2019, 21:18:42
Wenn ich im Terminal prüfe, erhalte ich Folgendes:
Code: [Auswählen]
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
**00597F3F88310B00Das zweite zusätzliche Modul hat hier denselben Inhalt wie das erste. Ist das korrekt? Wo kann ich nach dem Fehler suchen?
Beitrag von: RaspiLED am 15 Januar 2019, 07:49:04
Code: [Auswählen]
set <device2> freq 433.920
Gruß Arnd Gesendet von iPhone mit Tapatalk
Beitrag von: ra-ma am 15 Januar 2019, 18:33:08
Code: [Auswählen]
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:
Code: [Auswählen]
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
Beitrag von: RaspiLED am 15 Januar 2019, 18:37:28
Wie ist der CC1101 angeschlossen?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Beitrag von: ra-ma am 15 Januar 2019, 18:52:38
Modul 1 (welches funktioniert auf SlowRF mit 868MHz):
Code: [Auswählen]
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 CULModul 2, welches nicht richtig funktioniert (433MHz Modul):
Code: [Auswählen]
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
Beitrag von: RaspiLED am 15 Januar 2019, 18:56:55
Wieso hat Modul 2 kein W im cmds?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Beitrag von: Telekatz am 15 Januar 2019, 20:56:57
Beitrag von: ra-ma am 15 Januar 2019, 22:09:36
Beitrag von: skycrack am 19 Januar 2019, 22:08:54
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
Code: [Auswählen]
define MAXCUN CUL 192.168.90.42:2323 0000
attr MAXCUN icon mqtt_device
attr MAXCUN rfmode MAXder 2. dann mit Code: [Auswählen]
define MAXCUN_1 STACKABLE_CC MAXCUN
attr MAXCUN_1 connectCommand Nr1
attr MAXCUN_1 rfmode SlowRFeingebunden, 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.
Beitrag von: skycrack am 19 Januar 2019, 22:23:11
Code: [Auswählen]
define MAXCUN_2 STACKABLE_CC MAXCUN_1gings dann.Vieleicht hilft es ja nochmal jemanden.
Gruß
Beitrag von: RaspiLED am 19 Januar 2019, 22:56:57
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, ...
Beitrag von: pejonp am 20 Januar 2019, 23:31:54
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
Beitrag von: skycrack am 21 Januar 2019, 23:37:04
Super Sache, vielen Dank. Hab eine compilierte Version am laufen, Lacrosse und Autocreate des HMS Devices klappt.
Besten Dank
Rene
Beitrag von: Mondeo20 am 27 Januar 2019, 16:21:09
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
Beitrag von: rubbertail am 27 Januar 2019, 16:37:44
Beitrag von: RaspiLED am 27 Januar 2019, 17:04:57
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
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,Ich würde empfehlen, den Cube über USB anzuschließen und ihm eine feste IP Adresse zu geben.
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
Beitrag von: Mondeo20 am 27 Januar 2019, 21:28:10
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
Beitrag von: Telekatz am 03 Februar 2019, 14:39:59
Beitrag von: Rudibarani am 12 Februar 2019, 19:22:32
Firmware flashen :Hallo @Telekatz,
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).
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!
Beitrag von: RaspiLED am 12 Februar 2019, 20:14:05
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
Beitrag von: Rudibarani am 12 Februar 2019, 20:25:01
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.
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. :(
Beitrag von: Mihca am 11 April 2019, 09:57:34
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
Beitrag von: RaspiLED am 11 April 2019, 15:51:28
wie groß sind die Files?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Beitrag von: Mihca am 11 April 2019, 17:44:36
Gruß Achim
Beitrag von: Telekatz am 11 April 2019, 22:11:32
Beitrag von: bigmo am 27 April 2019, 11:21:01
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?
Beitrag von: Edi77 am 28 April 2019, 19:55:50
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?
Beitrag von: Telekatz am 28 April 2019, 20:27:24
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.
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...
Beitrag von: Kharim am 01 Mai 2019, 17:58:56
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
Beitrag von: kotaro am 13 Mai 2019, 15:24:57
könnt ihr mir helfen?
Beitrag von: Telekatz am 13 Mai 2019, 17:03:33
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)
Beitrag von: kotaro am 13 Mai 2019, 18:35:46
Beitrag von: adn77 am 04 Juni 2019, 22:05:19
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
Beitrag von: Telekatz am 05 Juni 2019, 18:09:34
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)
Beitrag von: phantom am 16 Juni 2019, 13:29:10
@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
Beitrag von: Telekatz am 16 Juni 2019, 19:39:18
Ob ein 1-wire Modul angeschlossen ist oder nicht ist bei CUBEx4_BL egal. Das Modul wird von Hardware Autodetect erkannt.
Beitrag von: Mihca am 18 Juni 2019, 13:51:19
ich habe 1.26.06 CUBEx4_BL.bin aus Zeitgründen noch nicht ausprobiert.
mfG Mihca
Beitrag von: Holzlenkrad am 19 Juni 2019, 18:05:36
Wie ich die Power LED konfiguriere habe ich schon selbst raus gefunden.
Beitrag von: Telekatz am 07 Juli 2019, 14:58:10
Die Firmware Dateien sind mit beiden Bootloadern kompatibel. Man kann also auch den alten Bootloader weiter benutzen.
Beitrag von: mahowi am 09 Juli 2019, 15:25:56
Für den nanoCUL läuft auch alles. Beim Kompilieren des Bootloader für den CUBe kommt es aber zu einem Fehler beim Linken:
Code: [Auswählen]
/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 1Hat 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
Beitrag von: Telekatz am 09 Juli 2019, 17:16:33
Beitrag von: mahowi am 09 Juli 2019, 17:32:00
Code: [Auswählen]
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
Beitrag von: Telekatz am 09 Juli 2019, 18:41:34
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.
Beitrag von: mahowi am 09 Juli 2019, 18:48:58
Code: [Auswählen]
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?
Beitrag von: Telekatz am 09 Juli 2019, 19:59:11
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:
Code: [Auswählen]
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.
Beitrag von: mahowi am 09 Juli 2019, 22:08:21
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:
Code: [Auswählen]
[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 diskJetzt habe ich /dev/sda gemountet und CUBE_BL.bin darauf kopiert. Nach einem umount bekomme ich mit dmesg einen Fehler angezeigt:
Code: [Auswählen]
[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 dirtyNach erneutem Anschliessen wird der CUBe nicht mehr erkannt:
Code: [Auswählen]
[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 deviceIst meine Vorgehensweise beim Installieren der Firmware falsch oder doch die kompilierte Firmware defekt?
Beitrag von: Telekatz am 09 Juli 2019, 22:46:31
Beitrag von: mahowi am 09 Juli 2019, 23:18:47
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!
Beitrag von: mahowi am 11 Juli 2019, 21:09:55
Code: [Auswählen]
/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 statusLeider 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?
Beitrag von: mahowi am 15 Juli 2019, 10:26:55
Beitrag von: petjek am 21 Juli 2019, 14:42:27
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
Beitrag von: Telekatz am 21 Juli 2019, 23:38:40
Und wenn du den Bootloader neu flashst würde ich empfehlen, den neuen MSC Bootloader aus dem letzten Release 1.26.07 zu verwenden.
Beitrag von: petjek am 22 Juli 2019, 07:28:59
Gesendet von iPhone mit Tapatalk
Beitrag von: mahowi am 22 Juli 2019, 07:34:12
Beitrag von: Mihca am 22 Juli 2019, 12:34:44
http://www.shumatech.com/web/products/bossa (http://www.shumatech.com/web/products/bossa)
Beitrag von: petjek am 22 Juli 2019, 13:05:03
Beitrag von: Wzut am 30 Juli 2019, 09:20:40
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 ?
Beitrag von: Telekatz am 30 Juli 2019, 12:09:08
Beitrag von: vklaffehn am 04 August 2019, 16:38:48
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!!
Beitrag von: Telekatz am 04 August 2019, 19:53:09
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)
Beitrag von: vklaffehn am 05 August 2019, 18:35:16
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
Beitrag von: Telekatz am 05 August 2019, 19:03:39
https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711 (https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711)
Beitrag von: vklaffehn am 09 August 2019, 15:35:55
Ich habe nun die Firmware selbst kompiliert, mit folgender board.h :
Code: [Auswählen]
//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_PIOBUnd 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 :
Code: [Auswählen]
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 TRXDanke für Tipps und generel für die coole Firmware!!MfG
Volker
Beitrag von: Wzut am 09 August 2019, 16:00:22
Beitrag von: vklaffehn am 09 August 2019, 16:07:15
Code: [Auswählen]
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dBund ein list CUL2_433
Code: [Auswählen]
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_culUnd im fhem.log sieht es so aus :
Code: [Auswählen]
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
Beitrag von: Wzut am 09 August 2019, 16:24:29
Hast du auch ../../clib/rf_receive_revolt.c im Makefile?
Has_Revolt alleine reicht nicht..
Beitrag von: vklaffehn am 09 August 2019, 16:32:31
Code: [Auswählen]
SRCS += ../../clib/rf_receive_revolt.c
Beitrag von: Telekatz am 09 August 2019, 18:10:00
Beitrag von: vklaffehn am 09 August 2019, 19:43:05
Beitrag von: vklaffehn am 09 August 2019, 21:41:14
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?
Beitrag von: vklaffehn am 10 August 2019, 13:27:52
Code: [Auswählen]
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!
Beitrag von: Telekatz am 10 August 2019, 13:54:07
Ist das hier eigentlich normal?Ja, das ist 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 InternalsNachrichten, die mit * beginnen, werden an den nächsten CUL weitergeleitet. Deshalb taucht die Nachricht des letzten CUL im LOG der vorhergehenden CULs auch auf.
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?
Wieso kann ich die Frequenz vom 3. CUL nicht setzen?Weil der 3. CUL beim Cube kein SlowRF kann.
Beitrag von: vklaffehn am 10 August 2019, 14:04:34
Beitrag von: vklaffehn am 11 August 2019, 14:54:12
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.
Beitrag von: meldelinie am 12 September 2019, 18:38:15
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
Code: [Auswählen]
#define _433MHZ
# if defined(_433MHZ)
# define HAS_TCM97001
# define HAS_IT
# define HAS_HOMEEASY
# define HAS_BELFOX
# define HAS_MANCHESTER
# define HAS_REVOLT
# endifIch 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 ?
Beitrag von: Parador am 16 September 2019, 20:10:48
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!
Beitrag von: Telekatz am 16 September 2019, 20:37:54
Beitrag von: Parador am 16 September 2019, 21:15:51
Im Geräte Manager erscheint AT91 USB to Serial Converter
Beitrag von: f-zappa am 18 September 2019, 14:52:21
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?
Beitrag von: f-zappa am 19 September 2019, 18:24:50
Nun erwäge ich, bei allen anderen IOdevs einfach mal den Stecker zu ziehen und zu gucken, ob der Cube das packt.
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?
Beitrag von: softcat am 29 September 2019, 21:08:38
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!
Beitrag von: Telekatz am 29 September 2019, 22:04:24
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!
Beitrag von: Telekatz am 01 Oktober 2019, 11:47:33
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.
Beitrag von: Nitaro am 01 Oktober 2019, 18:10:19
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 ?
Beitrag von: Telekatz am 01 Oktober 2019, 21:16:10
Beitrag von: Nitaro am 02 Oktober 2019, 08:23:41
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 ?
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
Beitrag von: Telekatz am 02 Oktober 2019, 20:52:40
TARGETSTART für die a-culfw wird im Linker Script CUBE_BL_flash.lds im Abschnitt MEMORY eingestellt.
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:
Code: [Auswählen]
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 0x23Danach 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:
Code: [Auswählen]
-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 gLineCodingSobald ist den CUBe komplett stromlos mache blinkt D1 wieder schnell und es öffnet sich das Netzlaufwerk zum einspielen der Firmware.
Log:
Code: [Auswählen]
-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:1Hilft das weiter?
Nochmals danke für die tolle Unterstützung hier!
Beitrag von: Telekatz am 03 Oktober 2019, 11:13:34
Code: [Auswählen]
-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:
Code: [Auswählen]
*ram = 0x55;Wenn das nichts hilft, kann man die Überprüfung auf 0xAA auch deaktivieren in Zeile 164-166:
Code: [Auswählen]
// if(*ram != 0xaa) {
jump_to_target();
// }
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:Code: [Auswählen]*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:Code: [Auswählen]// 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 :)