Hallo,
ich möchte euch meine Portierung der culfw für AT91SAM7-Controller vorstellen. Lauffähig ist diese Version auf dem HM-CFG-USB-2 und dem MAX! Cube.
Die beiden Geräte können dann wie ein CUL in FHEM eingebunden werden.
Quellcode:
Der Quellcode ist in der a-culfw (https://github.com/heliflieger/a-culfw) enthalten. Zum Erstellen der Firmware wurde diese Toolchain (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update) verwendet.
Firmware flashen :
Die kompilierten Bin Dateien findet Ihr unter https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw (https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw). Die Firmware besteht aus zwei Teilen. Einem Bootloader (bootloader_CUBE.bin bzw. bootloader_HM_CFG.bin) und der eigentlichen culfw (CUBE_BL.bin bzw. HM_CFG_BL.bin).
Flashanleitung MSC Bootloader (neu): https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUBe (https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUBe)
Flashanleitung XMODEM Bootloader (alt): https://github.com/heliflieger/a-culfw/tree/2f863c8576ecb5f5910509d268163bbee9da13a5/culfw/Devices/CUBe (https://github.com/heliflieger/a-culfw/tree/2f863c8576ecb5f5910509d268163bbee9da13a5/culfw/Devices/CUBe)
Update 23.01.2020:
Flashanleitung verlinkt
Gerade mit dem HM-CFG-USB-2 sehr interessant -> CUL 868 für 25€. Ich werde mir wohl direkt einen 2. bestellen müssen. Danke für das veröffentlichen. Würdest du ggf noch eine Version mit der alternativen culfw http://forum.fhem.de/index.php?topic=35064.0 bereitstellen können?
Wie sehen spätere updates der firmware aus? Hex-file vom cul und los geht denke ich nicht
Nein, die HEX Files vom CUL passen nicht, die sind für ATMega Controller. Im HM-CHG-USB-2 und im Cube steckt ein ARM drin. Das muss neu compiliert werden.
Und mit der alternativen culfw müsste ich erst mal schauen, wieweit der Code dort von der culfw abweicht. Da in der culfw kein HAL vorhanden ist, muss der gesamte Code durchforstet werden, um das auf einer anderen Plattform zum laufen zu bringen.
Danke für die ausführliche Anleitung, so kann der inzwischen durch einen CUL abgelöste Cube doch noch sinnvoll weiter verwendet werden.
Wenn ich deine Anleitung richtig verstanden habe ist es allerdings dann vorbei mit Netzwerkzugriff, da dann der Datenaustausch noch via USB läuft ?
Richtig, der Netzwerkzugrif funktioniert momentan noch nicht. Da muss ich mir erstmal den Beispielcode von Atmel ansehen, um den uIP Stack auch zu aktivieren.
Ist denn heute schon Weihnachten? ;D
Erst das hier:
http://forum.fhem.de/index.php/topic,38317.msg305426.html#msg305426
Und jetzt auch noch eine ARM-variante von CUL für den HM-CFG-USB-2.
Super!
Hat das auch schon jemand in Kombination getestet?
Zitat von: Telekatz am 23 Juni 2015, 12:00:20
Nein, die HEX Files vom CUL passen nicht, die sind für ATMega Controller. Im HM-CHG-USB-2 und im Cube steckt ein ARM drin. Das muss neu compiliert werden.
Und mit der alternativen culfw müsste ich erst mal schauen, wieweit der Code dort von der culfw abweicht. Da in der culfw kein HAL vorhanden ist, muss der gesamte Code durchforstet werden, um das auf einer anderen Plattform zum laufen zu bringen.
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.
Der Quellcode für die ARM Version ist jetzt in der a-culfw enthalten.
Noch ein Hinweis zur Hardware des HM-CFG-USB-2 und des MAX! Cube. Mir aufgefallen, dass bei diversen MAX und Homematic Geräten Funkmodule mit einem Si4431 anstelle eines CC1101 Chips verwendet werden. In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul. Die beiden HM-CFG-USB-2 Adapter die ich habe, haben einen CC1101 verbaut. Allerdings könnte es auch welche geben, die einen SI4431 haben. Bitte dies vor dem löschen der Originalfirmware kontrollieren.
Auf meinem Cube steht hingegen nur TRX868. Den habe ich allerdings auch schon seit 2012. Könnte hier bitte mal jemand der sich kürzlich einen Cube gekauft hat nachsehen, ob der Typ des Funkmoduls jetzt auch genauer angegeben ist?
Hallo Telekatz,
vielen Dank dafür. Habe es mit einem HM-CFG-USB2 ausprobiert. Funktioniert perfekt. Ich musste den 10k Widerstand einlöten. Er kann aber nach dem Flashen wieder entfernt werden.
Hallo
Bisher hatte ich zwar noch keine Probleme eines Senilen Cube.... Aber da ich eine Ersatgerät liegen habe würde ich es einfach mal
ausprobiren.....
Im Vorfeld noch zwei Frage...
- Fungiert ein Cube oder USB-CFG dann genau wie ein CUL - also man könnte den Cube auch auf HomeMatic umstellen?
- Wird der Netzwerkanschluss noch mit intregiert?
stenny
Bis auf den Firmwareupdate aus FHEM heraus ist alles möglich, was mit dem CUL auch möglich ist. Der Netzwerkanschluss vom Cube wird auch noch integriert.
Genial!!!!!!!!!!!!!!!!!
Dann wird der zweite heute umgebastellt....
Nachtrag: Und läuft..... Perfekt
Hallo Telekatz,
zuerst einmal vielen Dank für die geniale Idee und deine Umsetzung!
Ich habe gleich mal einen alten Cube geflasht, der hin- und wieder an der vielleicht bekannten Amnesie gelitten hatte (alle 2-3 Monate waren alle Daten weg --> Werksreset!). Jetzt weiß ich nicht, ob es ein Einzelfall ist, oder ob es vielleicht auch mit der Amnesie zu tun hat, aber ich musste am Debug-Port (ST2) noch einen Pull-up-Widerstand zwischen Pin1 und Pin3 einlöten.
Ohne diesen hatte ich ein paar seltsame Fehlerbilder:
- beim Verbinden mit PC oder RPi startete die Fw immer wieder neu (alle 2-3 sec. flackerten kurz die LEDs und der Cube verschwand kurz aus dem Gerätemanager).
- Falls eine stabile Verbindung mal hergestellt war, kam neben den richtigen Daten auch häufig viel Datenmüll an.
- das Flashen hatte interessanterweise auch ohne den Pull-up Widerstand fehlerfrei funktioniert...
Wird in der Firmware eigentlich ein interner Pull-up auf diesen Port gesetzt? Habe leider vor einiger Zeit den Schaltplan vom Cube entsorgt und konnte es auf die Schnelle nicht mehr in der Firmware nachvollziehen...
Mit dem Pull-up Widerstand schnurrt das Teil jetzt wie ein Kätzchen, ich freue mich schon auf die Netzwerk-Anbindung! Echt geniale Arbeit von Dir! :-)
Viele Grüße,
Martin
Zitat 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?
Auf meinem Cube (gekauft Anfang 2015) steht TRX868-TI, ähnlich dem HM-CFG-USB-2 . :)
Hallo Martin,
dein Cube empfängt wohl irgend einen Datenmüll über die serielle Schnittstelle der Debug Unit. Dort hatte ich zu Testzwecken einen einen Befehl eingebaut, mit dem sich die USB Verbindung lösen und wieder verbinden lässt. Dadurch verschwindet der Cube immer wieder aus dem Gerätemanager. Der restliche Datenmüll wird dann noch von der Debug Unit zur Konsole der USB Verbindung weitergeleitet.
Ein Pull-up für diesen Port war nicht gesetzt. Das habe ich jetzt geändert, das Problem sollte dadurch gelöst sein. Außerdem habe ich auch noch die Netzwerkunterstützung für den Cube mit in die a-culfw eingecheckt.
Zitat von: Blizzard am 22 August 2015, 21:48:18
Auf meinem Cube (gekauft Anfang 2015) steht TRX868-TI, ähnlich dem HM-CFG-USB-2 . :)
Ja, das ist das passende Funkmodul.
Zitat von: Telekatz am 23 August 2015, 20:23:15
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
Man kann ihn wie einen CUN benutzen. Ein CUNO hat zusätzlich noch 1Wire.
Hallo Telekatz,
super, da werde ich auch direkt mal meinen Cube umwidmen!
Eine Frage noch hierzu: wenn ich den Cube über USB anschließe, welche Baudrate nehme ich dann bei der Definition des CUL in Fhem? 9600, 38400, 115200 oder ganz was anderes?
Danke und Gruß.
Da ja nicht wirklich eine RS232 Verbindung existiert ist das eigentlich egal. Es funktioniert auch mit 42 Baud.
So, habe heute meinen CUBE entsprechend geflasht. Er empfängt auch die opened/closed Stati von meinen MAX! Fenstersensoren. Soweit ok.
Aber: Es kommen permanent irgendelche Daten über die Schnittstelle, was dazu führt, dass einzelne Telegramme verwurstelt werden bzw. FHEM bei einem "shutdown restart" komplett blockiert und erst weiterläuft, wenn ich den CUBE abziehe. Habe mal mit einem Verbose 5 auf den CUL geloggt, was dann so aussieht:
2015.08.26 20:38:29 3: Setting CUL_0 serial parameters to 9600,8,N,1
2015.08.26 20:38:29 1: /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00 reappeared (CUL_0)
2015.08.26 20:38:29 5: SW: V
2015.08.26 20:38:29 5: CUL/RAW (ReadAnswer): V 1.65 CUBe
2015.08.26 20:38:29 5: SW: ?
2015.08.26 20:38:29 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B C F i A Z E G M K U Y R T V W X e f l t x
2015.08.26 20:38:29 3: CUL_0: Possible commands: BCFiAZEGMKUYRTVWXefltx
2015.08.26 20:38:29 5: SW: X21
2015.08.26 20:38:29 5: SW: Zr
2015.08.26 20:38:29 5: SW: Za123456
2015.08.26 20:38:29 5: SW: Zw111111
2015.08.26 20:38:29 5: SW: T01
2015.08.26 20:38:29 5: CUL/RAW (ReadAnswer): 1034
2015.08.26 20:38:29 5: GOT CUL fhtid: 1034
2015.08.26 20:38:30 5: CUL/RAW: /
2015.08.26 20:38:30 5: CUL/RAW: /
2015.08.26 20:38:32 5: CUL/RAW: /�
2015.08.26 20:38:32 5: CUL/RAW: �/
2015.08.26 20:38:32 5: CUL/RAW: �/
2015.08.26 20:38:33 5: CUL/RAW: �/
2015.08.26 20:38:33 5: CUL/RAW: �/
2015.08.26 20:38:34 5: CUL/RAW: �/
2015.08.26 20:38:34 5: CUL/RAW: �/�
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:34 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/
2015.08.26 20:38:35 5: CUL/RAW: ��/�
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:35 5: CUL/RAW: ���/
2015.08.26 20:38:36 5: CUL/RAW: ���/�
2015.08.26 20:38:36 5: CUL/RAW: ����/
2015.08.26 20:38:36 5: CUL/RAW: ����/�
2015.08.26 20:38:36 5: CUL/RAW: �����/
2015.08.26 20:38:36 5: CUL/RAW: �����/0
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/
2015.08.26 20:38:36 5: CUL/RAW: �����0/�
2015.08.26 20:38:36 5: CUL/RAW: �����0�/
2015.08.26 20:38:36 5: CUL/RAW: �����0�/
2015.08.26 20:38:36 5: CUL/RAW: �����0�/�
2015.08.26 20:38:36 5: CUL/RAW: �����0��/`
2015.08.26 20:38:36 5: CUL/RAW: �����0��`/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`/~
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~/?
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?/�
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:36 5: CUL/RAW: �����0��`~?�/
2015.08.26 20:38:37 5: CUL/RAW: �����0��`~?�/?>>�
list CUL_0 ergibt:
Internals:
CMDS BCFiAZEGMKUYRTVWXefltx
CUL_0_MSGCNT 1
CUL_0_TIME 2015-08-26 20:39:03
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@9600 1034
DeviceName /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@9600
FHTID 1034
NAME CUL_0
NR 146
PARTIAL
RAWMSG Z0B1A06300FFDEA123456001029
RSSI -53.5
STATE disconnected
TYPE CUL
VERSION V 1.65 CUBe
initString X21
Zr
Za123456
Zw111111
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1440614349.80468
VALUE DISCONNECTED
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2015-08-26 20:23:05 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2015-08-26 20:38:29 cmds B C F i A Z E G M K U Y R T V W X e f l t x
2015-08-15 09:40:39 credit10ms 900
2015-08-13 20:05:19 fhtbuf AE
2015-08-26 20:39:09 state disconnected
2015-08-26 20:23:10 version V 1.65 CUL868
Attributes:
rfmode MAX
verbose 5
Habe auch schon versucht neu geflasht, aber irgendwie sendet der CUBE dauernd. Woran kann das liegen? :(
Danke und Gruß.
P.S. mit eine CUL 868 in der gleichen Konfiguration habe ich diese Probleme nicht.
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)
Ich habe seit gestern die neuste Version drauf.Sowohl der Datenmüll ist verschwunden (auch ohne Hardware-Pullup ;D), als auch die Netzwerk-Funktionalität funktioniert bisher fehlerfrei. 2x 100 Punkte! 8)
Ich betreibe den "Cube-CUNO" zusammen mit Homegear um ein paar Homematic-Geräte zu steuern. :)
Zitat von: Telekatz am 26 August 2015, 20:59:36
Klingt so, als ob es das gleiche Problem wie bei Blizzard (http://forum.fhem.de/index.php/topic,38404.msg325171.html#msg325171) ist. Probier mal die neueste Version, die in der a-culfw enthalten ist: https://www.mediafire.com/folder/tf16radvztfd9/a-culfw (https://www.mediafire.com/folder/tf16radvztfd9/a-culfw)
Super! Das war's! Erste Tests sehen sehr gut aus.
Vielen Dank!
EDIT: Ich hatte nach einem Neustart von FHEM plötzlich Probleme, dass mein Fensterkontakte den Status "opened (rf error)" oder "closed (rf error)" hatten. Im Log war daneben noch folgendes zu finden:
2015.08.26 22:17:08 1: PERL WARNING: Argument "04 a-culfw Build: 151 (2015-08-25_20-48-08) CUBe (F-Band..." isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 147.
2015.08.26 22:17:08 2: CUL_MAX_Check: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update
Nach Durchsicht von 14_CUL_MAX habe ich festgestellt, dass offensichtlich in Abhängigkeit von der Firmware-Version die Initialisierung anders verläuft. Nachdem ich mal versuchsweise in 14_CUL_MAX die Version hart auf 165 gesetzt habe (aktuelle Original-Firmware) läuft es nun wieder. Werde den Punkt mal im MAX-Unterforum melden.
Kann man man Cube eigentlich eine feste IP einstellen?
Zitat von: stenny73 am 28 August 2015, 20:14:02
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)
ZitatSample 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
Moin Telekatz,
danke ersteinmal für die Portierung.
für Dich und andere vielleicht interessant, mein CUBE hat einen at91sam7x512 an Board.
Jetzt zu meinem eigentlichen Problem:
Wegen des MAX-Problems:
Zitat adb76
ZitatNach 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
Hast du die Version 4.9 installiert? Die hat bei mir nicht funktioniert. Deshalb verwende ich die Version 4.8.
Danke Telekatz, guter Tipp,
es ist die Version 4.9.3.
Werde das jetzt mal mit der Version 4.8 versuchen, und mich bei Problemen nocheinmal melden.
Gruß Joachim
Edith:
So, jetzt diese Version genommen:
https://launchpad.net/gcc-arm-embedded/4.8/4.8-2013-q4-major
gcc-arm-none-eabi-4_8-2013q4-20131204-linux.tar.bz2
Makefile angepasst:
###############################################################
#####
##### Makefile for boop - OpenSource firmware for Betty
##### Created at 30.8.2007 02:26 am
#####
##### boop V0.1 by netguy - ck@mamalala.net
##### Makefile V0.1 by alterego - alteregon@gmx.net
##### Makefile v0.2 by Tobias - tobias-betty@23.gs
#####
###############################################################
###############################################################
#####
##### PATHS (default installation)
#####
##### You can put your path-config into Makefile.local
##### to override these defaults
#####
###############################################################
ARMBASE = /home/joachim/Downloads/gcc-arm-none-eabi-4_8-2013q4 <------------------------------------------
INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin/ <-------------------------------------------------------------
TOOLPREFIX = arm-none-eabi-
OPENOCDPATH = F:\Tools\OpenOCD
OPENOCD = $(OPENOCDPATH)\openocd.exe -f $(OPENOCDPATH)\target\sam7x256.cfg -f $(OPENOCDPATH)\interface\uniprog.cfg
GENDEPFLAGS = -MMD -MP -MF .dep/$(@F).d
make gestartet, und geflasht.
--> es geht!
Gruß Joachim
Thanks in advance for all the effort by everybody towards FHEM and firmwares.
Sorry for post in English, but I am struggling a little installing to Max cube.
I think I have successfully deleted previous firmware, by shorting J1, connecting USB, disconnecting short on J1, waiting for a second or so, hear usb drop and reconnect from computer notification then power off by disconnecting USB. When firmware has been deleted and you power back on light D1 is then permanently out. (Normally it should be on solid to indicate power on in normal mode with firmware loaded?)
I think I have loaded the boot loader with the SAM-BA software as D1 is now flashing approx 3 times per second when powered on, but I can't get past that stage to get the firmware loaded.
I used the instructions from the Atmel sam-ba Software to install its USB driver, which installed ok.
Started the software
Connected to the device as per instructions
Loaded the Bin file
Pressed the send
To the question about wanting to lock the involved lock regions, I say no, then
execute the script to boot from flash.
This is the log output from SAM-BA session:
loading history file ... 0 events added
SAM-BA console display active (Tcl8.5.9 / Tk8.5.9)
(sam-ba_2.15) 1 %
(sam-ba_2.15) 1 % send_file {Flash} "C:/Users/Alastair/Documents/raspberry/CULstuff/originalfw/bootloader_CUBE.bin" 0x100000 0
-I- Send File C:/Users/Alastair/Documents/raspberry/CULstuff/originalfw/bootloader_CUBE.bin at address 0x100000
first_sector 0 last_sector 0
-I- Writing: 0x3A6C bytes at 0x0 (buffer addr : 0x202A24)
-I- 0x3A6C bytes written by applet
Do not lock
(sam-ba_2.15) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.15) 1 %
Then on powering back off and back on the D1 light is now flashing approx 3 times per second, which I think indicates it has booted in boot loader mode as it has no firmware.
The USB is still detected as a AT91 USB to serial converter but to a different com port.
I then start up the teraterm software.
Connect to the port
File > Transfer > XMODEM > Send
Select the bin file from the dialogue and it start writing ok, but progress window seems to disappear before it finishes entirely (about half way), and you hear the USB disconnect and re-connect notification.
The light D1 is still flashing at about 3 times per second.
If I disconnect and re-connect the power the D1 led is still flashing at 3 times per second.
I think that means the Firmware flash has not worked.
How long does the flash process take?
Any suggestions as to what I am doing wrong.
I am also a little unclear as to which version of the firmware allows the device to function as a CUN. (IP based CUL device.)
Hopefully there are some instructions in here which might help some other users past the bit I have been able to get to.
I have attached document with screenshots to help other people if it can, and perhaps to help someone show me the error of my ways?
Regards
Chapelhill
Your procedure looks good for me. I think it is the same problem that Blizzard noticed with the missig pull up resistor on the debug port. This could lead to disconnect the USB connection before teraterm can upload the entire firmware. I fixed this problem in the a-culfw version.
You can find the a-culfw on https://github.com/heliflieger/a-culfw (https://github.com/heliflieger/a-culfw). The compiled binaries are available on https://www.mediafire.com/folder/tf16radvztfd9/a-culfw (https://www.mediafire.com/folder/tf16radvztfd9/a-culfw).
Try again with the bootloader and the firmware from Build 151.
Regards
Alex
Hi thanks for the quick response.
I have tried with build 151 and the previous build, it seems to make no difference. Are there any other builds to try, all the other builds appear to be too early for this development. I presume the problem is with the bootloader?
Which pins can I connect a resistor to, too see if I can resolve with hardware pull up resistor and approx what resistor value?
Board has
ST1
1x 2x 3x 4x
ST2
1x 2x 3x 4x
My cube was bought early this year, but has lost its settings twice, so I want to convert to using the CUL FW since I need functionality for switching heating on and off based on radiator demand. It is marked with the TRX868-TI and has AT91SAM7X256 ARM chip.
Regards
Chapelhill.
The resistor has to be connected between pin 1 and 3 on ST2. Use a 10k resistor.
Did you also try to use the bootloader from build 151?
Just to confirm.
I have retried with bootloader from build 151 and build 138 and no difference.
I did a file compare between bootloader from those two builds and it did not find any difference.
I have tried with 10k resistor between pins 1 and 3 on ST2 debug connections.
It made no difference.
Checking with a volt meter on dc voltage it showed both pin 1 and pin 3 at 3.3v without the resistor anyway.
Perhaps there is a problem with my cube?
I have tried with minicom on raspberry pi and this is the output. I think it is also aware that the connection drops before completing transfer.
Interestingly when connected to pi, the D1 led goes to constant on after 7 seconds, but returns to flashing at 3 times per second once minicom connection is established.
+-----------[xmodem upload - Press CTRL-C to quit]------------+
|Sending CUBE_BL.bin, 618 blocks: Give your local XMODEM recei|
|ve command now. |
|Xmodem sectors/kbytes sent: 618/77kRetry 0: No ACK on EOT |
| |
|Transfer incomplete |
| |
| READY: press any key to continue... |
+-------------------------------------------------------------+
Chapelhill
Zitat von: chapelhill am 10 September 2015, 19:14:04
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.
Hi I have checked the switch and that seems ok.
I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel AT91SSAM7X256 not the AT91SSAM7X512
The version number written on my circuit board is 1113596J and not 1113596H
I presume we might need some different settings in firmware for the differing Atmel chips as they have differing amount of memory and ram.
Is there any other information I can provide?
Zitat von: chapelhill am 11 September 2015, 16:50:16
Hi I have checked the switch and that seems ok.
I was searching the net for other images of the circuit board and I noticed that mine has the ARM Atmel 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?
Zitat von: chapelhill am 11 September 2015, 16:50:16
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.
Zitat 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
The firmware is intended to run on the AT91SAM7X256.
Attached you can find a version of the firmware you can flash with SAM-BA direct to the cube without the need of a bootloader. The flash procedure is the same as for bootloader_CUBE.bin.
Hi all.
I have checked MP8 and it shows 3.3 volts normally, and drops to 0 volts when the switch is pressed, returning back to 3.3v on release of the switch.
I have loaded the firmware you attached and flashed with SAM-BA and upon reboot we have D3 on continuously D2 off and D1 flashing slowly approximately once every two seconds. That is with the cube connected to usb only, no ethernet connection.
Looks like it has succesfully flashed firmware and booted normally.
I will see if I can work out how to use the device and update the thread accordingly.
Many thanks for the patience you have shown me.
Regards
Chapelhill.
Hat jemand von euch die a-culfw auf einem Cube mit der Version 1113596J installiert und kann bestätigen, dass das Flashen mit dem Bootloader normal funktioniert? Ich hab hier auch nur welche mit der Version 1113596H.
Moin Telekatz,
Ich kann Dir bestätigen, dass die a-culfw auf einem CUBE mit der Version 1113596J nicht funktioniert.
Das angepasste file von Heute um 17:30:04 funktioniert einwandfrei.
Insgesamt habe ich bisher 2 CUBE's (die älter als 3 Jahre sind erfolgreich geflasht, und den mit der Version 1113596J nur über das von Dir angehängte.
Gruß Joachim
Hallo Joachim,
Hast du den Cube mit der Version 1113596J als Bausatz gekauft und eine Anleitung mit Schaltplan dazu bekommen? Mich würde interessieren, ob der Taster TA2 bei dieser Version noch am Pin 22 (PA14) angeschlossen ist, oder ob dieser Pin jetzt auf Masse liegt. Der Bootloader verwendet ein Low Signal an diesem Pin, um den Bootloader Modus zu aktivieren. Ansonsten wird die Firmware gestartet, die im Flash nach dem Bootloader geschrieben ist.
Das File von Heute ist im Prinzip die gleiche Version wie die für den Bootloader. Der einzige Unterschied ist, das es an den Anfang des Flashs geladen wird und dann direkt startet.
Gruß
Alex
Moin Telekatz,
Ich habe den CUBE nicht als Bausatz gekauft, und damit leider auch keinen Schaltplan.
Der CUBE, mit dem das Flashen geklappt hat, ist Version 1113596I und hat einen at91sam7x512 an Board.
Ich habe hier beide geöffnet neben mir stehen. sag mir was ich suchen oder messen soll, und ich mache es.
Pin 22 (PA14) finde ich leider nicht.
Gruß Joachim
Könntest du bitte je ein Foto von beiden Platinenseiten der Version 1113596J machen, auf denen man die Leiterbahnen erkennen kann?
Bitteschön
Der Anschluss von TA2 sieht genauso aus wie bei mir. Das scheint es wohl nicht zu sein.
Du könntest mal folgendes probieren:
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-In SAM-BA die Address von 0x100000 auf 0x104000 ändern
-In SAM-BA CUBE_BL.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.
Wenn die a-culfw jetzt normal startet, liegt das Problem wohl an der Flash Funktion im Bootloader. Startet hingegen direkt der Bootloader, funktioniert anscheinend die Erkennung, ob bereits eine Firmware geladen wurde im Bootloader nicht.
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
Hallo Joachim,
könntest du mal den angefügten Bootloader ausprobieren.
Gruß
Alex
Moin Telekatz,
Der neue Bootloader funktioniert nicht.
Flogenden Ablauf habe ich gewählt:
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.
-starten von CuteCom unter Linux Mint 17
-open Device
-SendFile a-culfw_1.05.04_build_151_master/CUBe/CUBE_BL.bin
-USB trennen und Cube neu starten.
-D1 blinkt weiterhin mit ca. 3x/sec
Gruß Joachim
Hast du die Möglichkeit, mit einem Treminalprogramm den Debugoutput auf ST2 aufzuzeichnen? Ich würde dann mal einen Bootloader mit TRACE Ausgaben erstellen, um den Fehler etwas eingrenzen zu können.
Moin Telekatz,
habe ich noch nie gemacht, sollte aber machbar sein.
Ich gehe davon aus, dass Ich auf ST 2 einen Pfostenstecker einlöten muss, und dann mit einem serial 3,3 V auf USB-Konverter an einenPC gehen soll.
Die Belegung ist wie in diesem Bild?
Gruß Joachim
Ja, die Belegung ist so richtig. Die Baudrate am Debugport ist 115200.
Anbei der modifizierte Bootloader und die dazu passende a-culfw.
Moin Telekatz,
lange gesucht, um den richtigen Adapter zu finden (wer Ordnung hält...)
ich habe zwar kein Ahnung, was das Log aussagt, deshalb bekommst Du es.
Gruß Joachim
Danke für das Log. Es sagt aus, dass das Beschreiben des Flash nicht funktioniert und dass dein at91sam7x256 eine neuere Revision hat als meiner.
Ich denke, dass ich im AT91 Forum die Lösung für dieses Problem gefunden habe. Könntest du nochmal die beiden angefügten Bootolader ausprobieren?
Sieht gut aus.
Hier die beiden Log's passend zu den Bootloadern.
Dann ist es jetzt wohl gelöst?
Gruß Joachim
Hallo Joachim,
ja, passt. Problem gelöst. Danke fürs Testen.
Anbei dann auch der korrigierte Bootloader für die veröffentlichte a-culfw.
Gruß Alex
So, noch einmal schnell gegengetestet,
rennt auch mit selbst kompilierter Firmware.
Hast Du super gemacht, danke Joachim
Hallo,
danke für diese tolle Leistung! Als ich dies gelesen habe musste ich es direkt mit meinem Cube ausprobieren.
Leider hänge ich an einer Stelle.
Ich habe den Bootloader geschrieben und wie beschrieben blinkt die LED D1 schnell.
Nun habe ich aber lediglich ein device CUBELOADER unter "Andere Geräte" kann aber mit keinem Terminalprogramm (auch Tera Term) auf den Cube zugreifen. Die Schaltfläche für Serielle Verbindungen ist schlicht ausgegraut.
Habe ich etwas übersehen?
Danke und Gruß,
Thorsten
Hat Windows nach einen Treiber gefragt oder hast du schon versucht den Treiber zu aktualisieren?
Zitat von: Telekatz am 13 September 2015, 22:57:29
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.
Schonmal versucht, den Treiber zu deinstallieren und den Cube danach nochmal anzuschließen?
Zitat von: Telekatz am 13 September 2015, 23:11:46
Schonmal versucht, den Treiber zu deinstallieren und den Cube danach nochmal anzuschließen?
Ich habe nun für den CUBELOADER den selben Treiber unter Windows ausgewählt (den schon installierten, welchen er bei Treiberneuinstallation ignoriert), welcher für das Flashen des Bootloader funktioniert hatte. Ergebnis: OK.
Ich konnte das Image nun ohne Probleme übertragen.
Werde später versuchen den Cube in FHEM einzubinden.Habe ich es richtig verstanden, dass Netzwerk mittlerweile auch schon funktioniert, oder muss ich mittels USB anschließen?OK ist eingebunden...morgen kommen ein paar Geräte dran.
Aber ich muss mich für den Modus entscheiden: also ob ich den Cube für MAX, Homematic oder SlowRF benutzen möchte? Mischen ist vermutlich nicht möglich?!
Bezüglich des Modus gilt das gleiche wie für den CUL. Solange nur ein Transceiver eingebaut ist geht auch nur ein Modus gleichzeitig.
Hallo Leute,
habe heute meinen Cube geflasht. hat nach dem zweiten mal einwandfrei funktioniert.
Beim ersten mal(Windows 10) ist Samba abgestürzt.
Nutze ihn übers Netzwerk.
empfängt HM Geräte(zum testen) einwandfrei.
vielen vielen dank für diesen Port an Telekatz
Jetzt habe ich den den Cube(aus dem Marktplatz hier im Forum) für 25€ bekommen und habe nun einen CUL 868 MHZ mit dem man sogar über
Netzwerk seine Reichweite erhöhen kann.
Ich werde ihn allerdings im Slow RF Bereich nutzen um FS20 steuern zu können.
Mfg Marcel
Moin Telekatz,
nachdem meine beiden CUBE's nun super mit MAX laufen, wollte ich mal einen für Homematic verwenden.
Dank des Netzwerkanschlusses ist er dafür eigentlich wie geschaffen. Haken an der Sache ist, das es meine Fähigkeiten leider übersteigt, die angepasste
Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1 http://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466 auf den CUBE zu portieren.
Wenn Du dabei helfen könntest, wäre das genial.
Gruß Joachim
Hallo Leute,
ich habe meinen CUBE nach Anleitung geflasht. Als Firmware habe ich die 1.05.04 Build 151 drauf.
Danach habe ich den CUBE per IP in FHEM eingebunden und meine MAX Geräte neu angelernt.
Ausser das mir bei 3 +Thermostaten die valvePosition nicht gemeldet wird, funktioniert alles.
Das echte Problem ist, das der CUBE nach einer gewissen Zeit nicht mehr im Netzwerk erreichbar ist.
Nicht mal ping geht. Der Switch zeigt aber noch den Link an.
Als erstes habe ich dann DHCP deaktiviert und ihm eine statische IP verpasst.
Danach ging es natürlich erstmal wieder. Habe dann sicher knapp 4 Stunden versucht das valvePosition Problem zu lösen.
Dabei war der CUBE die ganze Zeit ansprechbar.
Heute früh war er wieder nicht erreichbar. Im Log steht:
2015.09.23 21:17:19 1: 192.168.178.247:2323 disconnected, waiting to reappear (CUL_CUBE)
Seitdem isser DOWN.
Das gab heute früh mächtig ärger, da das Bad kalt war ???
Bis zum flashen gabs mit original MAX Firmware keine Probleme.
Der CUBE ist, wie Telekatz seiner, ein TRX868, also schon was älter.
Hat dieses Problem noch einer?
Gruß Larsi
Hallo,
ich wollte den CUBe mal kompilieren, allerdings bricht der compiler mit der folgenden Meldung an:
E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe>cd E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe
E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe>make
arm-none-eabi-gcc -g -Os -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S
process_begin: CreateProcess(NULL, arm-none-eabi-gcc -g -Os -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
make: *** [../../at91lib/board_cstartup.o] Error 2
E:\Meine Dateien\Arduino\a-culfw\branches\ARM\culfw\Devices\CUBe>
Das Verzeichniss ../../at91lib/ ist mit der Datei "board_cstartup.S" ist vorhanden.
Allerdings habe ich WinAVR-20100110 installiert, liegt es daran?
Danke
Michael
Nimm die Toolchain aus dem Eröffnungspost und pass den Pfad zur Toolchain im Makefile an.
Hallo,
habe hier einen (älteren) HM-CFG-USB-2. Auf diesem steht nur TRX868-TFK / 868.3 MHz. Wie kann ich feststellen, ob hier ein CC1101 Funkmodul verbaut ist?
Auch im Innern des Stick sind keine Hinweise vorhanden.
Sry falsche info.
Nein, der falsche Chip ist es nur, wenn TRX868-SL oder TRX868-TFK-SL drauf steht. Wenn nur TRX-TFK drauf steht, ist das Funkmodul wohl produziert worden, als nur der CC1101 verwendet wurde und deshalb der Typ nicht extra gekennzeichnet wurde.
Außerdem kann man es noch an der Leiterbahnführung an der Stiftleiste des Moduls erkennen. Wenn es wie hier http://www.fhemwiki.de/wiki/Datei:Tranceiver_CutGradScaleUSM800x600_85P_IMGP8367.JPG (http://www.fhemwiki.de/wiki/Datei:Tranceiver_CutGradScaleUSM800x600_85P_IMGP8367.JPG) aussieht, ist es ein CC1101 Modul.
Es ist das Modul rechts auf dem Bild verbaut. Somit handelt es sich wahrscheinlich um ein CC1101-Modul. Werde demnächst mal einen Versuch wagen.
Gesendet von meinem SM-P600 mit Tapatalk
Habe einen Cube erfolgreich geflasht. Windows7 erkennt nun einen "cubeloader", ohne dass dazu ein Treiber gefunden wird. Nun habe ich manuell einen Com-Port Treiber zugewiesen und habe einen Com3 der nicht gestartet werden kann.
In Folge kann ich auch nicht mit Teraterm auf die Kiste zugreifren
Die erste Frage:
Beim Strom anlegen blinkt die LED einige Sekunden lang schnell... Somit gehe ich davon aus dass der Bootloader korrekt geflasht ist. (Ich habe auch das 512KB Modell der ARM-Controllers, daher diese beim Flashen mit SAM-BA ausgewählt, sonst war kein Connect möglich.)
PS: so sieht das syslog unter Linux aus wenn man das Gerät einsteckt.
ZitatSep 29 14:11:27 martin-ws kernel: [23329.513994] usb 3-5: new full-speed USB device number 42 using ohci-pci
Sep 29 14:11:27 xx-ws kernel: [23329.685226] usb 3-5: New USB device found, idVendor=03eb, idProduct=6119
Sep 29 14:11:27 xx-ws kernel: [23329.685236] usb 3-5: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Sep 29 14:11:27 xx-ws kernel: [23329.685241] usb 3-5: Product: CUBELOADER
Sep 29 14:11:27 xx-ws kernel: [23329.687501] cdc_acm 3-5:1.0: This device cannot do calls on its own. It is not a modem.
Sep 29 14:11:27 xx-ws kernel: [23329.687554] cdc_acm 3-5:1.0: ttyACM0: USB ACM device
Ich habe versucht mit CuteCom unterLinux auf das Kistchen zu kommen bekomme aber keine Verbindung zustande zu /dev/ttyACM0 (auch nicht /dev/tty/ttyACM0, vor allem mit 9600, 56- und 115K und 8N1).
Somit ist meine erste Frage natürlich ober der Bootloader passt, oder ab er angepasst werden muss auf den größeren Flash.
Der Bootloader passt. Er meldet sich ja mit seinem Namen und das schnelle Blinken zeigt auch an, dass er gestartet ist.
Hallo Leute ich weis nicht ob ich die Frage hier richtig stelle.
Ich habe mir einen Cube umgeflasht und würde nun gerne damit 433 Mhz signale empfangen.
Hab denm Cube bereits auf 433.92Mhz eingestellt und eine Passende Antenne dran.
Senden an Elro steckdosen funktioniert auch super.
Nun weis ich leider nicht weiter was ich als nächstes machen muss um signale auszuwerten bzw anzeigen zu lassen........
Danke für eure hilfe
Da der Cube ja einen 868,3MHz Empfänger hat sind die 433,92MHz Protokolle nicht enthalten. Um die Signale dennoch zu empfangen musst du in der board.h folgende Änderung am Code vornehmen und die Firmware neu erstellen:
#define _433MHZ
# if defined(_433MHZ)
# define HAS_TCM97001
# define HAS_IT
# define HAS_HOMEEASY
# define HAS_OREGON3
# define HAS_BELFOX
# define DEBUG_SYNC
# endif
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.
Zitat von: larsi am 24 September 2015, 08:58:22
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? ;-)
Zitat von: Basegate am 01 Oktober 2015, 21:02:52
Ja das hört sich gut an. Nur leider stehe ich noch sehr am anfang und bin total froh das das flashen überhaupt geklapt hat. Wäre es zu viel verlangt wenn du mir das machst? Wäre dir sehr dankbar. Ausser es braucht zu viel zeit. Danke für die schnelle antwort.
Ist jetzt enthalten in der Firmware, siehe erster Post.
Zitat von: strauch am 02 Oktober 2015, 11:05:45
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.
Also irgendwann kann ich nicht mehr über den cube senden oder empfangen, wenn ich dann ein set cube reopen mache geht es wieder. Aber er steht nicht auf disconnected.
Ich hatte den DHCP abgeschaltet. Ich werde ihn noch mal neu konfigurieren und testen. Vielleicht hab ich irgendwo murks gemacht.
Gesendet von meinem Nexus 4 mit Tapatalk
FHEM merkt es nicht sofort, wenn der Cube nicht erreichbar ist. Wenn ich durch resetten des Cube einen Verbindungsabbruch provoziere dauert es genau zwei Stunden, bis FHEM den diconnect bemerkt. Dann erfolgt aber sofort ein reopen und der Cube ist wieder erreichbar.
Danke Telekatz,
du bist echt der beste. der 433mhz empfang funktioniert super.
Nabend!
Ich hab da mal eine (wahrscheinlich doofe) Frage.
Momentan setze ich einen Cube ein um 3 Heizungsthermostate damit zu steuern. Es ist noch die originale Firmware installiert.
Wenn ich den Cube jetzt zum CUN umflashe, kann ich dann diesen ganz normal für die MAX! Geräte weiterverwenden und zusätzlich Befehle an meine Intertechno Schaltern senden (das der CUN-CUBE dann zum Zeitpunkt des sendens taub ist, ist mir bewußt)?
Gruß
Manni
Intertechno senden funktioniert neben dem MAX Mode, hat aber natürlich eine geringere Reichweite als ein auf 433MHz abgestimmter Sender.
Danke für die Antwort.
Habe schon selber herausgefunden.
Gesendet von meinem ONE A2003 mit Tapatalk
Ist das Netzwerkproblem jetzt gelöst?
Ich habe mich am WE auch mal an meinen CUBE gesetzt. Version 1113596 I BS (siehe Bild) , denke den I hatten wir bis jetzt noch nicht nur J & H ?
Bootloader mit sam-ba ist soweit kein Problem , linux legt nach dem Cube Neustart brav /dev/ttyACM0 an und ich kann mich mit einem Terminalprog und beliebiger Baudrate verbinden - Ausgabe bei Eingabe von Shift +v -> CUBELOADER V1.01
Was bei mir nicht läuft ist die a-culfw , egal welche Version ich mit XMODEM übertragen habe , das Ergebnis ist immer das gleiche :
Nach dem USB trennen und neu starten kann linux keinen USB Port zuordnen ( es leuchtet auch keine der drei LEDs )
[ 2785.144057] usb 3-2: new full speed USB device using ohci_hcd and address 27
[ 2785.552029] usb 3-2: device not accepting address 27, error -62
[ 2785.728049] usb 3-2: new full speed USB device using ohci_hcd and address 28
[ 2786.136030] usb 3-2: device not accepting address 28, error -62
[ 2786.136056] hub 3-0:1.0: unable to enumerate USB device on port 2
Versuche die a-culfw statt mit XMODEM zu übertragen sondern mit dieser Methode :
Zitat von: Telekatz am 11 September 2015, 23:34:37
-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 ?
Löte ST2 ein und schau, was an Debug rauskommt.
ok, mal schauen ob ich heute Abend dazu komme.
Kann der aktuelle Bootloader Debug Ausgaben oder soll ich die Versionen durchtesten die du auf Seite drei gepostet hast ?
Probier es erst mal mit der aktuellen Version des Bootloaders und der Firmware. Der Bootloader selbst hat keinen Debugausgaben, interessanter ist hier jedoch die Debugausgabe der Firmware.
Sollte nichts ausgegeben werden kannst du es auch noch mit der CUBE.bin von Seite drei probieren, die ohne Bootloader geladen wird.
PFFF , kaum macht man es richtig geht es auch ....
Ich hatte zuvor schon deine CUBE.bin vom 11. September probiert , allerdings zusammen mit dem Bootloader :(
Die CUBE.bin mit SAM-BA direkt und alleine auf den CUBE geschoben und das Mistding rennt :)
Vielen Dank nochmal für deine tolle Arbeit !!!
Moin!
Meine Frage nach dem Netzwerkproblem scheint untergegangen zu sein... Ist das jetzt behoben?
Ich habe an der Netzwerkfunktion nichts geändert. Und solange ich das Problem nicht reproduzieren kann, kann ich auch schlecht was dagegen unternehmen.
Dann werde ich nachher mal testen. :-)
Hm. Jetzt hab ich wohl ein Problem.
Nach dem Verbinden von J1, dem Einstecken und trennen der USB-Verbindung passiert nun mit meinem Cube (1113596 I) beim Widerherstellen der USB-Verbindung nichts mehr. Windows erkennt keinen neuen USB-Port, und irgendeine LED blinkt auch nicht.
Mit gedrücktem Taster auf der Unterseite ebenfalls kein Erfolg.
Anderen USB-Port am Laptop (WIN7) versucht, ebenfalls kein Erfolg.
Und nun?
Grüße
anfichtn
Ok, das erste Problem saß wohl vor dem PC.
Nach Tausch des USB-Kabels erscheint zumindest der COM-Port.
Aber Sam-Ba? Gestartet, Port ausgewählt, Board eingestellt, Connect geklickt. Warten... Warten.. Warten.. 5 Minuten später hat sich der Prozess beendet. WTF?
Es geht weiter....
Also bei mir erscheint der Com Port leider nicht. Sondern nur ein nicht identifiziertes Gerät. Welchen Widerstand nehme ich genau und wo muss ich diesen einlöten? Direkt an den Kontakten oder an einem USB Kabel?
Ach wenn ich hier in dem Bereich noch relativ grün hinter den Ohren bin wäre super, wenn mir jemand helfen könnte.
Viele Grüße
Gib dem nicht identifizierten Gerät mal bitte den Treiber, den du auf der atmel -seite herunter laden kannst.
Grüße
Habe ich gemacht und im Gerätemanager dann die Treiber aktualisiert. Klappt leider nicht: Die Treiber sind auf dem aktuellen Stand bekomme ich als Meldung.
Ich habe die Jumper jeweils mit einer Büroklammer überbrückt, wuste nicht wie ich es sonst machen sollte...
Alten Treiber deinstallieren, und entfernen lassen. Dann klappts auch mit dem neuen Treiber
Leider nicht ...
Zitat von: cdn am 14 Oktober 2015, 16:38:01
Also bei mir erscheint der Com Port leider nicht. Sondern nur ein nicht identifiziertes Gerät. Welchen Widerstand nehme ich genau und wo muss ich diesen einlöten? Direkt an den Kontakten oder an einem USB Kabel?
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.
Es gibt da doch auch verschiedene Widerstände von der Form/Art oder? Welchen nehme ich am besten?
Nimm den erstbesten bedrahteten 10kOhm Widerstand, der sich finden lässt und in die Kontakte des USB Steckers reinpasst.
Okay nochmal zum Verständnis: Ich werde vorne in den USB Stecker den Widerstand stecken und das Ganze dann in den USB Port am PC richtig?
Danke für die Hilfe!
Nein, hinten! Da wo der Pfeil hin zeigt.
OK. Ich dachte schon. Danke
Coool!!!!11einself
Da war ich mal ein halbes Jahr nicht im Forum aktiv und da baut Telekatz hier so was geniales zusammen! Da ich nen Cube zu viel habe, meine Heizungssteuerung mit MAX die Tage den "Release 1.1" (so ganz fertig ist man ja nie ^^) erreicht haben werden sollte, wollte ich als nächstes in Homematic einsteigen. Da trifft sich das doch wunderbar! Wieder mal ein paar Euro gespart auf dem Weg zum smart Home.
Hab zwar noch nix geflasht, dennoch schon mal: Vielen Dank an Telekatz für den Port. Du bist mein persönlicher Oktober-Held!
Hallo Telekatz!
Mit wachsender Begeisterung habe ich Deinen Beitrag hier verfolgt und habe mir nun selbst einen Cube gekauft, da ich bei mir zu Hause nun auch in die Hausautomation einsteigen möchte.
Ich hatte auch Glück, mein Modell, welches ich bekommen habe ist ein TRX868-TI und somit kompatibel zu Deinem Projekt.
Ich habe bisher erfolgreich den Bootloader geflasht und das Cube-Board wartet nun mit blinkender D1 LED auf eine Firmware...
Leider kann ich ihm keines senden, da Windows 7 für die neu entdeckte Hardware "CUBELOADER" keinen Treiber findet! Ich habe zwar auf das Verzeichnis von "Atmel" verwiesen, jedoch findet es keinen passenden Treiber... ;-(
Ich würde mich wirklich sehr freuen, wenn Du mir an der Stelle einen Tipp geben könntest! Vielen Dank im Voraus!
Ergänzung:
Ich habe den Treiber nun manuell erzwungen, indem ich bei der Treibersuche (Manuell aus Liste wählen -> COM Port -> Atmel -> AT91 USB to Serial Converter) ausgewählt habe! Hat geklappt! Nun werde ich fhem einrichten und den CUBE anschließen per LAN... ich werde berichten! Vielen Dank nochmal für dieses Projekt Telekatz!
Ergänzung2:
Ich habe erfolgreich einen MAX! Heizkörperthermostat Basic damit auslesen und steuern können! Perfekt!!! Jetzt wird das ganze Haus ausgestattet! ;-)
Ich noch mal. Nachdem ich den Bootloader wie oben beschrieben vor ein paar Tagen auf meinen CUBE geflasht hatte, habe ich jetzt die Firmware geflasht.
Hier mal eine Anleitung für die Linux Nutzer zum flashen des MAX CUBE.
Kommt sich darauf an welche Distri ihr nutzt: Installiert das Programm minicom und seid Root.
Schließt den Cube an und öffnet ein Terminal.
dann schaut nach wie das gerät heißt das ihr ansprechen wollt: dmsg | grep tty
eines wird sicher etwas mit USB im Namen haben, etwa: ttyACM diesen Namen braucht ihr.
nun geht es weiter (auf Root achten!) minicom -s im folgenden menü geht ihr in die Einstellungen zur Seriellen Verbindung, drückt a, und gebt den Namen (z.B. ttyACM) anstelle der voreinstellung ein (meist auch ttyIRGENDWAS) nur das letzte mus geändert werden, nicht der ganze Pfad. zB: aus /dev/ttyBLUB macht ihr /dev/ttyACM
nun das Menü schließen und in minicom die Tastenkombination Strg+A verwenden und dann die Taste Z drücken. Jetzt wählt ihr Datei Senden aus indem ihr den entsprechenden Buchstaben drückt (es war meine ich "S") dann noch zum Ort Navigieren an dem die zu Flashende Datei liegt und diese auswählen.
Die Datei sollte gesendet werden und wenn alles fertig ist drückt ihr die berühmte beliebige Taste.
Fertig.
So... Ich wollte doch berichten: Super! Ich habe Empfang durch drei(!) Betondecken, vom Gateway im Keller bis unter das Dach zum letzten Regler, klasse!
Der Cube ist auch zuverlässig und fleißg, vielleicht zu fleißig. Habe zwei sich häufende Einträge im Log:
Alle 30 Sekunden: CUN1: unknown message V 1.10.01 a-culfw Build: 167 (2015-10-13_18-19-02) CUBe (F-Band: 868MHz)
Unregelmäßig, aber oft: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update.
Kann mir jemand hierbei weiterhelfen?
Vielen Dank im Voraus!
Mach mal einen Update von FHEM. Für die erste Meldung gab es im April eine Änderung in 00_CUL.pm, um diese Nachrichten auszufiltern. Wegen der zweiten Meldung wurde kürzlich 14_CUL_MAX.pm geändert.
Hat geklappt! Vielen, vielen Dank! ;D
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
Zitat von: SmokeMaster am 22 Oktober 2015, 21:19:10
dmsg | grep tty
Danke für die super Beschreibung. Nur muss es dmesg heissen... (Ein Buchstabe vergessen)
Zitat von: ranseyer am 25 Oktober 2015, 09:07:18
Danke für die super Beschreibung. Nur muss es dmesg heissen... (Ein Buchstabe vergessen)
oops, war keine böse Absicht :) Habe das auf die schnelle zwischen firmware flashen und CUL(CUBE) in FHEM einrichten runtergerattert. Mir ist auch ein Fehler unterlaufen in dem Punkt:
Zitat von: SmokeMastereines 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
Zitat von: mr.os am 24 Oktober 2015, 14:18:16
Hallo,
ich will mich auch erst einmal vielmals für die Arbeit die hier drinnen steckt bedanken. Leider habe ich aber ein kleines Problem:
bei mir steigt der Cube mit der Firmware hier immer nach recht kurzer Zeit komplett aus. Es dauert so etwas zwischen 4h und 16h (hab es erst 2 - 3 mal probiert) und dann ist der Cube nicht mehr erreichbar. Weder per Telnet noch per Ping. Wenn er vorher mit FHEM verbunden war, dann kommt die folgenden Meldungen:
2015.10.21 20:20:06 1: 192.168.10.30:2323 disconnected, waiting to reappear (CUBE1)
2015.10.21 20:20:06 1: Error in CUL_MAX_SendQueueHandler: CUL CUBE1 did not answer request for current credits. Waiting 5 seconds.
Allerdings muss er vorher nicht unbedingt mit FHEM verbunden gewesen sein um nicht mehr erreichbar zu sein. Ich hatte ihn heute einfach ungefähr 4h angeschlossen ohne das sich was mit ihm verbunden hat und jetzt ist er weder per Ping noch per Telnet erreichbar.
Da ich bei dem niegelnagelneuen Cube auch noch die Fehlermeldung CUBE1: unknown message ZERR30D hatte, benutze ich gerade die Firmware von hier http://forum.fhem.de/index.php/topic,25745.msg332883.html#msg332883
Irgendwas läuft auf alle Fälle noch auf dem Cube, da die eine LED noch blinkt. Eine neue Verbindung kriege ich leider nur nach einem Power Cycle wieder hin.
Hat eventuell irgendjemand eine Idee woran das ganze liegen kann? Ich habe gerade mal im Git probiert zu schauen, ob sich etwas an den Netzwerkroutinen geändert hat aber leider habe ich da nicht wirklich was gefunden.
Ich kann auch gerne mal per JTAG hochschauen (wenn es aktiviert ist, hab im uC Forum gelesen das es eventuell deaktiviert ist) und sehen, wo es hängt. Nur bräuchte wäre ich da über einen Anhaltspunkt sehr froh :)
Mit besten Grüßen
Andreas
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!
Zitat von: mr.os am 24 Oktober 2015, 14:18:16
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.
@chris_fiesta bzw. Mr.OS, wie ist die Stromversorgung des Cube realisiert ?
Ich hatte meinen am Anfang zum testen ein paar Tage direkt an einer Fritzbox (sowohl USB als auch das LAN Kabel) , dort hat er sich auch regelmäßig verabschiedet :(
Seit ca. einer Woche steht er nun im Keller an einem Cisco Switch , Strom kommt von einem alten USB Netzteil ohne einen einzigen Disconnect :)
@Wzut:
Das mit dem Netzteil ist ein guter Hinweis. Ich habe den Cube allerdings an dem mittgelieferten Netzteil ebtrieben und glaube, dass es schon funktionieren sollte. Das hatte ja 0,5A am Ausgang. Ich habe ihn aber heute früh mal schnell an ein anderes Netzteil angeschlossen und werde heute Nachmittag/Abend sehen, ob er noch lebt.
@Telekatz:
Vielen Dank für die neue Version. Wenn es das Netzteil nicht ist (was ich glaube), dann werde ich die Version mal probieren.
Was mich ein wenig beschäftigt ist die Tatsache, dass der Cube die Telnet-Verbindung aktiv beendet. Wenn ich einfach nur den Strom von ihm abziehe merkt Fhem das ja nicht (so schnell). Sollte man eventuell finden können.
Zitat von: Telekatz am 25 Oktober 2015, 15:00:43
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 ZERR30DIm Übrigen verwende ich auch das original Netzteil, an der Stromversorgung sollte es also nicht liegen, aber danke für den Tipp.
Hallo Telekatz,
leider hat auch diese neue Firmware von Dir nicht geholfen. Der CUBE ist wieder nach ein paar Stunden reproduzierbar ausgestiegen...
Kann ich irgendetwas tun, dass Dir bei diesem Problem weiterhelfen könnte?
Ich habe egstern morgen noch schnell das Netzteil gewechselt um das sicherheitshalber auszuschließen. Es ist dann aber gegen 20:00 wieder ausgestiegen.
Seit dem läuft jetzt die neue Firmware mit dem ZERR30D Fehler.
Welche Toolchain Version hast du genutzt? Vielleicht kriege ich es ja ins Atmel Studio oder wo anders rein und kann mal den Debugger mitlaufen lassen.
Ich werde auch mal schauen, an welchen Stellen aus welchen Gründen im Code der uIP Stack gekillt wird. Es wird ja noch ordentlich die Verbindung beendet ...
Das Problem ist halt, das mein Cube ohne Probleme durchläuft. Ich kann kann den Fehler bei mir nicht reproduzieren.
Die Toolchain die ich verwende steht im ersten Beitrag. Der SAM7 wird im Atmel Studio soweit ich weiß gar nicht unterstützt. Da wirst du dir wohl Eclipse mit GDB zum Debuggen einrichten müssen.
Welche Revision hat eigentlich der SAM7 auf euren CUBEs (B oder C)?
Zitat von: Telekatz am 27 Oktober 2015, 11:51:49
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...
Mein Cube hat die Rev. B.
Grüße
anfichtn
Zitat von: anfichtn am 27 Oktober 2015, 13:48:22
Mein Cube hat die Rev. B.
Läuft bei dir die Netzwerkverbindung stabil?
Bei mir ist auch die neue uIP Version heute 13:30 ausgestiegen.
Mein SAM7 hat die Rev C
Ist ja blöd dass der SAM7 nicht mit dem Atmel Studio geht. Soweit hatte ich gar nicht gedacht. Mal schauen, ich werde nachher mal ein wenig probieren.
Grüß Dich Telekatz,
ich hatte nun Gelegenheit den Cube mal zu "zerlegen". Ich habe auch Revision C, wenn ich das "C" auf dem Chip richtig interpretiere. Zur Sicherheit habe ich Dir mal Bilder meines Boards angehängt, in der Hoffnung Du kannst mir/uns helfen!?
Ja, der SAM7 hat die Revision C. Was mich noch interessieren würde ist, ob die Netzwerkverbindung nur im MAX Modus instabil ist oder auch im SlowRF Modus.
@Wzut
Bei deinem Cube läuft die Netzwerkverbindung stabil. In welchen Modus betreibst du den Cube und hat dein SAM7 die Revision B?
Wenn ich es richtig sehe, wird der RF-Modus doch erst von FHEM konfiguriert oder?
Ich hatte den Cube nämlich einfach am Wochenende an Strom und Netzwerk gehangen ohne das sich FHEM mit ihm verbunden hatte oder eine andere Telnet Verbindung da war. Der war dann nach ungefähr 4-5h auch nicht mehr ansprechbar als ich FHEM gestartet habe. Weder per Telnet auf 2323 noch per Ping.
Ich ahbe leider gestern nicht die sonst von mir genutzte IDE (em::blocks) zum kompilieren überreden können. Ich bin aber dabei.
Hallo zusammen,
ich werde leider nicht ganz schlau, woran kann ich genau erkennen ob mein Cube geeignet ist!? Auf dem Cube selber steht "nur" TRX868.
Kann ich den Cube mit der alternativen FW flashen?
Und noch eine Frage. In der Anleitung steht die Pins J11 verbinden, heisst das ich muss die einfach nur mit nem Draht echt verbinden?
Frage nur vorsichtshalber, will meinen Cube nicht gleich zerschiessen! ???
Gruß Thommy
Zitat von: ThommyTom am 28 Oktober 2015, 11:04:12
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.
Zitat 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?
Wenn nur TRX868 drauf steht dann ist der Cube geeignet.
Zitat von: mr.os am 28 Oktober 2015, 11:03:51
Wenn ich es richtig sehe, wird der RF-Modus doch erst von FHEM konfiguriert oder?
Ich hatte den Cube nämlich einfach am Wochenende an Strom und Netzwerk gehangen ohne das sich FHEM mit ihm verbunden hatte oder eine andere Telnet Verbindung da war. Der war dann nach ungefähr 4-5h auch nicht mehr ansprechbar als ich FHEM gestartet habe. Weder per Telnet auf 2323 noch per Ping.
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.
Zitat von: Telekatz am 28 Oktober 2015, 11:51:54
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? :-[
Ich habe gerade mal ins Errata der Rev C geschaut und was sich zur Rev B getan hat ist das folgende:
EFC: Embedded Flash Access Time 2
The embedded Flash maximum access time is 20 MHz (instead of 30 MHz at zero Wait State (FWS = 0).
The maximum operating frequency with one Wait State (FWS = 1) is 48.1 MHz (instead of 55 MHz). Above 48.1 MHz and
up to 55MHz, two Wait States (FWS = 2) are required.
Problem Fix/Workaround
Set the number of Wait States (FWS) according to the frequency requirements described in this errata.
Ich habe jetzt meiner Meinung nach im Code rausgelesen, dass er FWS auf 1 stellt. Leider hab ich jetzt auf die schnelle nicht den Takt gefunden.
Eventuell prophylaktisch einfach hoch stellen?
Zitat von: chris_fiesta am 28 Oktober 2015, 11:56:39
Kann ich etwas tun, damit du leichter erkennen kannst woran genau? :-[
Ich denke nicht. Ich muss mir selber mal einen aktuellen Cube besorgen.
Zitat von: mr.os am 28 Oktober 2015, 12:09:11
Ich habe gerade mal ins Errata der Rev C geschaut und was sich zur Rev B getan hat ist das folgende:
EFC: Embedded Flash Access Time 2
The embedded Flash maximum access time is 20 MHz (instead of 30 MHz at zero Wait State (FWS = 0).
The maximum operating frequency with one Wait State (FWS = 1) is 48.1 MHz (instead of 55 MHz). Above 48.1 MHz and
up to 55MHz, two Wait States (FWS = 2) are required.
Problem Fix/Workaround
Set the number of Wait States (FWS) according to the frequency requirements described in this errata.
Ich habe jetzt meiner Meinung nach im Code rausgelesen, dass er FWS auf 1 stellt. Leider hab ich jetzt auf die schnelle nicht den Takt gefunden.
Eventuell prophylaktisch einfach hoch stellen?
Der Takt liegt bei 48MHz, FWS = 1 sollte deshalb passen. Aber man kann ja trotzdem mal ausprobieren, FWS auf 2 zu setzen.
Zitat 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?
Modus = MAX , Revision kann ich erst heute Abend checken wenn ich den Cube aufmache.
K.A. ob es eine Rolle spielt : aber ich hatte ja das Problem das ich nicht mit bootloader + xmodem flashen konnte und musste daher deine zu Anfang gepostete .bin Datei nehmen ( die hat auch noch den unknown message ZERR30D Fehler)
V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Zitat von: Wzut am 28 Oktober 2015, 16:22:36
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?
Ich habe es jetzt endlich geschafft es zu compilieren - wenn auch nicht in der IDE die ich will. Leider kann ich so nicht per JTAG drauf.
Ich habe aber mal die WaitStates geändert und das uIP logging angeschalten. Jetzt läuft das Ganze mal und ich logge die Ausgabe mit.
Ich habe nun den Cube mal per USB angeschlossen und beobachte mal so das Verhalten, was ich jetzt schon sagen kann, ist das der Fehler unknown message ZERR30D auch via USB geloggt wird... :o
Zitat von: Telekatz am 28 Oktober 2015, 12:24:09
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.
Zitat von: Telekatz am 28 Oktober 2015, 17:00:00
Lag da nicht das Problem daran, dass du versucht hast die Version für die Verwendung ohne Bootloader mit dem Bootloader zu verwenden?
das war ein Fehler von mir nachdem bootloader + a-culfw via xmodem in allen Versionen nicht ging - Letztendlich lief der Cube nur mit der Datei von dir ohne Bootloader.
Aber anway , die Schrift auf dem Atmel ist so schwach das ich es nicht schaffe ein brauchbares Foto davon zu machen.
die Beschriftung unterhalb des ATMEL Logo :
AT91SAM7X256
AU
1122 B
1PO750 ARM
Gekauft wurde der Cube als Neuware im Frühjahr 2012.
Moin!
Zitat von: Telekatz am 27 Oktober 2015, 14:26:00
Läuft bei dir die Netzwerkverbindung stabil?
Ich kann mich nicht beklagen, Ausfälle konnte ich bisher nicht feststellen, trotzdem taucht auch bei mir der eigenwillige Fehler auf.
Internals:
CMDS BCFiAZEGMKLUYRTVWXefltx
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
Cube_MSGCNT 58
Cube_TIME 2015-10-28 20:07:30
DEF 192.168.178.80:2323 4321
DeviceName 192.168.178.80:2323
FD 17
FHTID 4321
NAME Cube
NR 178
NR_CMD_LAST_H 3
PARTIAL
RAWMSG Z0EC502020E02FE0F39350001380F2D37
RSSI -46.5
STATE Initialized
TYPE CUL
VERSION V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
initString X21
Zr
Za0d9874
Zw111111
CHANGETIME:
Helper:
Dblog:
State:
Mydblog:
TIME 1446056025.98194
VALUE UNKNOWNCODE ZERR30D
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2015-10-14 22:56:41 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2015-10-28 19:13:14 cmds B C F i A Z E G M K L U Y R T V W X e f l t x
2015-10-28 19:13:44 credit10ms 900
2015-10-28 20:07:30 state Initialized
2015-10-28 20:05:25 uptime 10 22:24:12
2015-10-14 22:59:42 version V 1.05.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
XMIT_TIME:
1446055994.32879
1446055994.62965
1446056024.94958
Attributes:
rfmode MAX
room 99_System
Grüße
anfichtn
Habe auch eine B-Version und kann das Netzwerkproblem bestätigen. Einen genauen Zeitraum kann ich nicht fest machen; mal steigt der Cube nach Stunden aus, mal nach Tagen und mal nach 1-2 Wochen....
Ich verwende den Cube in Verbindung mit Homegear um Homematic-Geräte zu steuern...
Mein zweiter Cube hängt über USB direkt am Rechner und steuert die Max!-Geräte. Dieser Cube läuft seit Wochen einwandfrei, auch wenn am Tag mehrere Male die ZERR30D-Meldung geloggt wird.
Viele Grüße,
Martin
Ich glaube, ich habe schon die Ursache gefunden. Ich probiere gerade, sie zu reproduzieren.
Ich habe aber schon mal eine neue Firmware gebastelt und wer will, kann probieren. An den Wait States lag es übrigens nicht.
Edit: Die Firmware ist weiter hinten zu finden
Wenn ich es reproduzieren kann sag ich natürlich auch, woran es liegt.
Das ZERR30D sollte aber schon mal weg sein.
Ich habe gestern Abend den Cube mal per USB angeschlossen und nicht per LAN, denn ich wollte ausschließen, dass es mit etwas anderes als dem Netzwerk zu tun haben könnte, warum der Cube sich stumm stellt. Er läuft jetzt seit fast 15 Stunden ohne Ausfall, solange lief er noch nie! Es hat also definitiv etwas mit dem Netzwerk zu tun... Ich habe aber dennoch den unknown message ZERR30D Fehler.
@mr.os
Sollte der Cube heute Abend immer noch funktionieren, werde ich Deine FW mal probieren! Ich würde mich aber dennoch darüber freuen zu lesen, was Du gefunden hast?!?
Gestern Abend musste es schnell gehen, deshalb jetzt etwas mehr:
Der ZERR30D Fehler kommt durch ein sehr unglückliches Stückchen Code für den CC1100 im MAX! Teil der Firmware. Da hatte schon mal wer hier im Forum was genaueres dazu geschrieben. Siehe hier: http://forum.fhem.de/index.php/topic,25745.msg218980.html#msg218980 Da hab ich nur den Code kopiert und bei mir eingefügt. Die Firmware aus dem Thread lief bei auch ohne den ZERR30D Fehler.
Das die Netzwerkverbindung immer mal wieder zusammen bricht lag daran, dass der uIP Stack so konfiguriert ist, dass er maximal Packete mit 1500 Bytes Länge empfangen kann. Das reicht eigentlich auch. Aber zumindest bei mir im Netzwerk kamen am Cube auch welche mit 1510 Bytes an. Er hat auch ordentlich erkannt dass es zu lang ist. Normalerweise sollte er das verwerfen und auf das nächste warten. Hat er aber nicht gemacht. Er hat es einfach immer und immer wieder probiert abzurufen und das hat alles lahmgelegt.
Ich hab jetzt was eingebaut das er solche Packete verwirft und einfach weitermacht als ob nichts gewesen wäre. Gestern Abend hat er bei mir auch noch mehrere zu lange Packete empfangen und geht trotzdem noch.
Die Leute bei Atmel die den Stack auf den SAM7 adaptiert haben, haben sich echt nicht mit Ruhm beckleckert. In einer Bibliothek ein hart reincodiertes printf ...
Dein Cube wird also per USB gehen. Ich würde heute Abend auch noch mal ein diff fertig machen und es Telekatz zukommen lassen wenn es recht ist. Kann man ja vielleicht ne neue Version draus machen.
@mr.os
Vielen Dank für Deine Nachricht und Arbeit, die Du investierst! Ich werde heute Abend nach der Arbeit Deine Firmware ausprobieren! ;D
@Chris-Fiesta:
Ich kann die Aussage von Mr. OS bestätigen. Habe zwei Cubes parallel laufen; einer am Netzwerk (Homematic), einer an USB (MAX!). Der USB-Cube läuft seit Monaten störungsfrei.
@Mr. OS:
Ich habe heute morgen deine Version auf den Netzwerk-Cube aufgespielt. Bin schon ganz gespannt und werde berichten! Vielen Dank dafür! :)
Viele Grüße,
Martin
Zitat von: Telekatz am 15 Oktober 2015, 11:48:35
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 -.-
@Mr. OS , TOP JOB !! Respekt das du den Bug mit den 1500 byte gefunden hast.
Also war bei mir auch nicht unbedingt das Netzteil schuld sondern eventuell die Position im Netzwerk ...
Ich hab noch mal neu compiliert und die Wait States und einige Debug-Ausgaben wieder zurückgesetzt. Das hatte ich gestern Abend in der Eile des Gefechts nicht gemacht.
Bie mir ist der Cube seit gestern Abend bis jetzt durchgelaufen (jetzt hab ich noch mal schnell meine neue Version hochgespielt). Es ist wirklich (scheinbar) nur das eine Problem gewesen.
(Wer die andere Firmware von gestern drauf hat muss nicht unbedingt tauschen - die geht auch)
@mr.os
Danke für Deine Mühen! Ich habe Deine Firmware nun aufgespielt... Was ich bis jetzt sagen kann ist: KEINE FEHLERMELDUNGEN! Spitze!
Wenn das Dingen jetzt auch noch durchrennt, bin ich höchst zufrieden.
Hast Dich auch schön verewigt: get MAXCUBE version -> ...build by mr.os... 8)
@Mr. OS: Danke für den Patch. Ich hab ihn in den Sourcecode eingearbeitet und committed. Die Änderungen sollten dann bald in der a-culfw enthalten sein.
Zitat von: cdn am 29 Oktober 2015, 14:26:50
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?
Mit der Firmware von mr.os läufts!
Mein Cube hängt jetzt über 12 Stunden per LAN im Netz und arbeitet zuverlässig und OHNE Fehlermeldungen! Perfekt! Danke vielmals an Telekatz & mr.os! ;D ;D ;D
Zitat von: Telekatz am 29 Oktober 2015, 21:25:40
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 :)
Anbei die Version ohne Bootloder.
Hallo telekatz.
Kann ich mit dieser version auch immernoch meine homeeasy schalter 433 mhz empfangen?
Die 433 MHz Protokolle sind weiterhin im Cube enthalten.
Hallo zusammen,
wo ist denn nun die letzte aktuelle Version zu finden ?
Die aktuelle Version findest du in der a-culfw:
http://forum.fhem.de/index.php/topic,35064.0.html (http://forum.fhem.de/index.php/topic,35064.0.html)
Ich meinte die mit der ich den MAX! Cube neu flashen kann
Die ist dort auch enthalten.
Hallo,
Danke erst einmal für die tolle Arbeit und deinen Support.
Ich habe bereits meinen Cube erfolgreich geflasht und nutze ihn für meine max! Thermostate.
Nun habe ich bei ebay einen zweiten erstanden und wollte ihn auch flashen.
Ich komme bis zum Starten von Sam-ba und kann dort den com-port auswählen. Wenn ich nun auf Connect klicke, dann öffnet si h kein Fenster. Das andere verschwindet und es passiert nichts mehr.
Hat jemand einen Hinweis oder Rat für mich?
Edit:
Habe es bereits an 2 Laptops probiert(winxp und win8)
Mfg
habe nochmal das Vergrösserungsglas rausgeholt.
auf dem Chip steht
AT91SAM7X256 AU
kann mir niemand helfen?
Kommt wenigstens eine Fehlermeldung nach dem Drücken von Connect?
Welche SAM-BA Version?
Steht da bei der Auswahl des Com Ports etwas in der Art "\USBserial\COMx"?
Richtiges Board ausgewählt?
Hallo,
Danke erstmal für deine Antwort.
Ich kann das richtige Board nicht auswählen, es gibt bei der Auswahl kein at91sam7x256-Au.
Es gibt nur eins mit -ek am ende.
Wenn ich dieses auswähle kommt keine Fehlermeldung. Beim Klick auf Connect verschwindet das Fenster und dann passiert nichts mehr.
Als version benutze ich 2.15.
habe auch schon 2.8 probiert, dort bekomme ich wenigstens eine Fehlermeldung (No valid Processor ID found) oder so ähnlich.
Aber auch hier gibt es das Board mit der Endung -Au nicht.
Habe jetzt das ganze WE am Laptop verbracht und Google gequält aber nichts gefunden.
Mit freundlichen Grüßen
Das richtige Board ist at91sam7x256-ek.
Steht da bei der Auswahl des Com Ports etwas in der Art "\USBserial\COMx"?
Wenn ich das Board mit der Endung ek nehme bekomme ich obige Fehlermeldung bei v2.8 und bei v2.15 passiert nichts.
Bei der Auswahl des ComPorts steht \USBserial\COM8
Mfg
Wo hast du die Version 2.8 her? Die neueste Version, die ich auf der Atmel Seite finden konnte war V2.15.
Von der Atmel-Seite.
War ein Programm-Bundle mit Sam-Prog v2.4
AT91-ISP v1.2
Hast du evtl noch eine Tip wie ich das wieder hinbiegen kann?
Wie gesagt, beim ersten Cube hat es wunderbar geklappt.
Dieser hatte allerdings einen at91sam7x512 Chip.
Moin!
Meines Erachtens liegt dein Problem am verwendeten usb-kabel. Probier einfach mal ein anderes Kabel aus.
Mh, wenn ich ehrlich bin habe ich schon 4 verschiedene probiert.
Das vom neuen und vom alten Cube(hat beim alten Cube funktioniert) und eins von einer DigiCam und noch eins von einer USB Festplatte.
Ich würde alle SAM-BA Versionen deinstallieren, den USB Treiber deinstallieren, SAM-BA V2.15 installieren, den USB Treiber aus dem SAM-BA V2.15 Verzeichnis manuell installieren, am Cube nochmal einen Flash Erase durchführen und es nochmal probieren.
Der at91sam7x256 ist eigentlich der übliche µC für den Cube. Einen at91sam7x512 hatten glaube ich nur die frühen Versionen des Cube.
Hast du ein JTAG Interface?
Habe es sogar schon an einem jungfräulichen Rechner probiert. Hier ist es identisch zu meinem.
Nein, habe kein JTAG-Interface
So, alles noch einmal deinstalliert und Rechner neu gestartet.
Sam-ba v2.15 installiert und Treiber ebenfalls.
J1 Pink geschlossen und kurz mit usb verbunden und wieder getrennt.
J1 Brücke entfernt und wieder am usb angeschlossen.
Gleiches Ergebnis wie vorher,
Sam-ba gestartet, Com-Port vom at91usbtoSerialdriver ausgewählt und Connect gedrückt.
Das Fenster verschwindet und das wars dann.
Keine weitere Reaktion.
Schade eigentlich
Gibt's evtl. die Möglichkeit etwas mit TeraTerm zu senden?
Habe gerade mit dem "sendFile" probiert, allerdings schreibt er den Bootloader nur zu 29%, dann ist wohl der Speicher voll.
Jedenfalls klappt die Verbindung mit TeraTerm.
Meldet sich der Atmel Bootloader unter TerraTerm nach Eingabe von V# mit z.B. "v1.4 Feb 02 2005 17:55:46"?
Also mit TeraTerm kann ich keine Eingaben machen.
Kann auf der Tastatur rumhacken wie ich will, es erscheint kein Buchstabe.
Irgendwie passt das nicht zusammen. Da du eine USB Verbindung mit TerraTerm aufbauen kannst muss der Atmel Bootloader auch laufen. Dann müsste aber auch nach der Eingabe von # ein Kommandopromt ">" und nach der Eingabe von V# "v1.4 Feb 02 2005 17:55:46" erscheinen.
Wie gesagt,
Egal welche Taste ich auf der Tastatur tippe, in TeraTerm erscheint kein Zeichen.
Habe auch schon die Schriftfarbe und die Hintergrundfarbe geändert, aber es erscheint kein Buchstabe auf dem Terminal.
Fahre jetzt mal den 2.PC hoch und versuche es dort.
Evtl liegt es ja an winXP
Edit:
So, habe am Laptop meiner Tochter probiert, keine Änderung.
Auch hier ist keine Eingabe am Terminal möglich.
Ich bin ja echt ein geduldiger Mensch, aber wenn man das ganze WE mit einem so kleinen Cube verbringt, kann die Laune schon mal sinken.
Bin kurz davor das Ding einfach in den Müll zu werfen.
Am Pc kann es doch aber eigentlich nicht liegen, habe ja bereits einen Cube erfolgreich geflasht
Hallo,
mein Cube ist inzwischen auch angekommen. Nun wollte ich ihn auch neu flashen. Habe extra bei J1 Pfosten eingelötet und eine Brücke gesteckt. Dann kurz mit USB verbunden, bis zum ersten kurzen Blinken. Danach Brücke entfernt und USB wieder verbunden (mit dem mitgelieferten Kabel).
Habe den Gerätemanager offen aber es wird kein neues Gerät erkannt.
Die Powerled blinkt 10 mal kurz und leuchtet dann konstant.
Wenn ich einen Flash erase an meinem Cube mache blinkt und leuchtet danach gar nichts mehr. Wenn die Power Led immer noch blinkt und leuchtet, dann ist der Flash nicht gelöscht. Probier mal aus, ob sich über Netzwerk immernoch die MAX Firmware meldet.
Das Problem mit dem Lan ist, dass die IP 192.168.0.222 aufgedruckt ist. Also müsste ich wohl oder übel den Cube mit einem crossover Kabel anschliessen un den PC netzwerkmässig kurz in diese Range heben.
Wie kann ich dann feststellen wie sich der Cube meldet ?
Edit: ok, wahrscheinlich mit der PC Software ::)
Die Brücke war anscheinend nicht ok. Jetzt blinkt nichts mehr. Am Windowssystem wird auch ein neues Gerät erkannt und nach der Treiberinstallation als AT91 USB to Serial Converter (COM 3) angezeigt. Wenn ich nun SAM-BA 2.15 starte und den COM 3 sowie den at91sam7s128-ek eintrage und mich verbinde kommt:
Can´t connect atsam7s128-ek - Invalid chip ID
und nun :-[
Auch bei mir ist der Chip der AT91SAM7X256 AU
Falsches Board. Nimm at91sam7x256-ek.
ok, jetzt verbindet er sich. Ist die folgende Ausgabe ok ?
(sam-ba_2.15) 1 % send_file {Flash} "C:/Cube/bootloader/bootloader_CUBE.bin" 0x100000 0
-I- Send File C:/Cube/bootloader/bootloader_CUBE.bin at address 0x100000
first_sector 0 last_sector 0
-I- Writing: 0x3AC0 bytes at 0x0 (buffer addr : 0x202A24)
-I- 0x3AC0 bytes written by applet
Do not lock
(sam-ba_2.15) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.15) 1 %
Sieht nicht schlecht aus. Blinkt D1 auf dem Cube jetzt schnell?
Ja, sie blinkt schnell, aber der installierte COM3 ist aus dem Gerätemanager verschwunden. Angezeigt wird nun beim Gerätemanager nur bei andere Geräte ein Cubeloader über den ich mich mit Terra Term natürlich nicht verbinden kann.
und nun ???
Weise dem Cubeloader aus anderen Geräten manuell den Treiber aus dem SAM-BA Installationsverzeichniss zu.
Das habe ich natürlich schon probiert aber er meint, dass er die Treibersoftware für das Gerät in dem amtel drv Verzeichnis nicht finden kann
Hast du es auch wirklich auf die ganz Manuelle weise probiert, also Manuelle Auswahl, Treiber aus Liste auswählen und dann auf Datenträger den Treiber im Verzeichnis auswählen?
Natürlich, ich habe es auch über Legacy Hardware versucht. Keine der Vorgehensweisen brachte Erfolg
Dann probier mal den atm6124 USB CDC signed driver for Windows (http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx) von der Atmel Seite.
Auch der funktioniert nicht
Ich habe das jetzt unter Linux geflasht. Nun blinkt die Powerled langsam und die Batterieled konstant. Ist das korrekt so ?
minit meinte dass die Datei nicht komplett übertragen würde.
Aus den einzelnen Beiträgen entnehme ich, dass die Netzwerkfunktion wieder komplett arbeitet, richtig ?
IP wird per DHCP gezogen ?
Zitat von: raspklaus am 10 November 2015, 19:55:18
Ich habe das jetzt unter Linux geflasht. Nun blinkt die Powerled langsam und die Batterieled konstant. Ist das korrekt so ?
Das langsame blinken der Powerled signalisiert, dass die a-culfw läuft. Die Batterieled leuchtet, wenn das Netzwerk verbunden ist.
Zitat von: raspklaus am 10 November 2015, 19:55:18
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.
Zitat von: raspklaus am 10 November 2015, 19:55:18
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.
Zitat von: raspklaus am 10 November 2015, 19:55:18
IP wird per DHCP gezogen ?
Per Defaulteinstellung ist DHCP aktiviert.
So, ich wollte mich mal für die Arbeit von euch nd die gute Anleitung bedanken. Ich habe meinen Cube am Sa. innerhalb von 15 min am laufen gehabt.
Derzeit betreibe ich Ihn über einen VPN Tunnel und es läuft Top.
Ist es richtig das ich derzeit beim Mode MAX kein Pairing machen kann? Beim Versuch wird mir angezeigt das pairing im Mode Max nicht geht.
VG
Greg
Du musst auf das Subdevice z.B. CULMAX0 gehen und dort pairmode auswählen
Was bedeutet broadcastTime ?
In der Befehlsreferenz ist das nicht zu finden.
Zitat von: raspklaus am 16 November 2015, 11:30:44
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.
@Telekatz
Moin, nachdem ich ja nun massive Probleme mit dem 2.Cube hätte kann ich jetzt Erfolg melden.
Habe den 2.Cube getauscht und konnte den neuen erfolgreich flashen.
Jetzt noch eine Frage nebenbei, auch wenn ich befürchte die Antwort schon zu kennen.
Ist es evtl. möglich mit dem Cube auch Lacrosse/TFA Temperatursensoren zu empfangen?
MfG
Habe meinen Cube mit aFW auf 433 MHz und SlowRF eingestellt und bevor ich mich versah wurden (mit autocreate an) meine 433MHz Temperatursensoren verschiedener "Standard"-Wetterstationen von FHEM erkannt und angelegt (als CUL_TCM97001 (http://fhem.de/commandref.html#CUL_TCM97001)). Empfang der Daten läuft wirklich zuverlässig.
List des MAXCUBES:
Internals:
CMDS BCFiAZEGMKLUYRTVWXefltx
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF 192.168.0.155:2323 0000
DeviceName 192.168.0.155:2323
FD 14
FHTID 0000
MAXCUBE_MSGCNT 1407
MAXCUBE_TIME 2015-11-26 20:05:51
NAME MAXCUBE
NR 36
PARTIAL
RAWMSG s62F01F60D5
RSSI -80.5
STATE Initialized
TYPE CUL
VERSION V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CUBe (F-Band: 433MHz)
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
Readings:
2015-11-24 14:45:46 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
2015-11-26 09:20:34 cmds B C F i A Z E G M K L U Y R T V W X e f l t x
2015-11-06 08:44:38 credit10ms 900
2015-11-26 20:05:51 state Initialized
2015-11-16 14:21:08 uptime 0 01:37:56
2015-11-24 18:45:11 version V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CUBe (F-Band: 433MHz)
Attributes:
addvaltrigger RSSI
event-on-change-reading .*
model CUN
rfmode SlowRF
Echt tolle Sache, vielen Dank!
:) :) :)
Andreas
PS:
Perfekt wäre noch eine aFW-/CUL_TCM97001-Einbindung der in diesem Thema (http://forum.fhem.de/index.php/topic,39451.0.html) beschriebenen preislich sehr interessanten Wetterstationen WH-1080/ WS-1080 (http://www.ebay.de/itm/Ersatz-Wettermast-fur-WH1080-Pass14c-/330832213045) / CTW600 (//http://) .
Zitat von: Shadow3561 am 26 November 2015, 18:01:56
Jetzt noch eine Frage nebenbei, auch wenn ich befürchte die Antwort schon zu kennen.
Ist es evtl. möglich mit dem Cube auch Lacrosse/TFA Temperatursensoren zu empfangen?
Meinst du dieses Protokoll?
http://forum.fhem.de/index.php/topic,36565.0.html (http://forum.fhem.de/index.php/topic,36565.0.html)
hi,
falls jemand wie ich mehrer CUBEs gleichzeitig am USB Port nutzen möchte, kann man in der Datei
a-culfw/culfw/at91lib/usb/device/cdc-serial/CDCDSerialDriverDescriptors.c individuelle USB-Id vergeben
Dazu im Bereich productStringDescriptor, ganz unten in der Datei, anpassen.
Nachfolgend ein Beispiel:
Zitat
/// Product string descriptor
const unsigned char productStringDescriptor[] = {
#if defined(bootloader_CUBE) ||defined(bootloader_HM_CFG)
USBStringDescriptor_LENGTH(10),
USBGenericDescriptor_STRING,
USBStringDescriptor_UNICODE('C'),
USBStringDescriptor_UNICODE('U'),
USBStringDescriptor_UNICODE('B'),
USBStringDescriptor_UNICODE('E'),
USBStringDescriptor_UNICODE('L'),
USBStringDescriptor_UNICODE('O'),
USBStringDescriptor_UNICODE('A'),
USBStringDescriptor_UNICODE('D'),
USBStringDescriptor_UNICODE('E'),
USBStringDescriptor_UNICODE('R')
#else
USBStringDescriptor_LENGTH(15),
USBGenericDescriptor_STRING,
USBStringDescriptor_UNICODE('F'),
USBStringDescriptor_UNICODE('H'),
USBStringDescriptor_UNICODE('E'),
USBStringDescriptor_UNICODE('M'),
USBStringDescriptor_UNICODE('_'),
USBStringDescriptor_UNICODE('C'),
USBStringDescriptor_UNICODE('U'),
USBStringDescriptor_UNICODE('B'),
USBStringDescriptor_UNICODE('E'),
USBStringDescriptor_UNICODE('_'),
USBStringDescriptor_UNICODE('8'),
USBStringDescriptor_UNICODE('6'),
USBStringDescriptor_UNICODE('8'),
USBStringDescriptor_UNICODE('_'),
USBStringDescriptor_UNICODE(USB_DESCRIPTOR_SN)
#endif
};
Zitat
root@minibian:~# ls -l /dev/serial/by-id/
total 0
lrwxrwxrwx 1 root root 13 Nov 28 17:24 usb-03eb_AT91USBSerial1-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Nov 28 18:19 usb-03eb_FHEM_CUBE_888_1-if00 -> ../../ttyACM1
Danach einmal make clean && make und anschließend ganz normal flaschen
Grüße,
Stephan
hm, ich habe nun meinen 2 ten hm-usb2 umgeflascht, und bekomme auch per putty mit v eine versionsrückmeldung. nur komischerweise bekommt fhem mit der default "define CUL CUL /dev/ttyAMA0@38400 0000" keine verbindung.
Hi,
Kannst du mal die Ausgabe von ls -l /dev/ttyACM* posten?
Und vllt noch ls -l /dev/serial/by-id/
Grüße Stephan
Gesendet von meinem SM-T335 mit Tapatalk
jupp, das kann ich
root@FHEMrpi:/home/pi# ls -l /dev/ttyACM*
crw-rw---T 1 root dialout 166, 0 Nov 29 03:17 /dev/ttyACM0
root@FHEMrpi:/home/pi# ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-03eb_AT91USBSerial1-if00 -> ../../ttyACM0
der raspi, ist ein neu aufgesetzter, mit wheezy und fhem ( stand gestern). und kernel 3.18.
edit:/
FHEM hat nu selbst Ständig den eingebunden. ^^
define CUL_0 CUL /dev/ttyACM0@9600 1034
hm, warum das 1034 *kopfkratz*
List :
Internals:
CFGFN
CMDS BCFiAZEGMKLUYRTVWXefltx
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 5
FHTID 1034
NAME CUL_0
NR 47
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.10.02 a-culfw Build: 171 (2015-10-29_21-49-43) CUL-HM-CFG (F-Band: 868MHz)
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
Readings:
2015-11-29 03:17:55 cmds B C F i A Z E G M K L U Y R T V W X e f l t x
2015-11-29 03:17:55 state Initialized
Attributes
Hi,
super dann läuft es ja ;)
Nutzt du beide HM-CFG-USB an einem PI?
Die 1034 ist eine "Zufalls-ID" für FHT bzw. Homematic.
Grüße,
Stephan
ich habe den einen jetzt an einer Testumgebung, auf der Haupt Box einem raspi 2b, nutze ich eine ccd2, einen mysensor Gateway, und einen nanocul auf 433 MHz, dazu noch eine Anbindung an den Stromzähler, mit dem volkszähler.org usb-ir lese schreibkopf.
das ganze per WLAN an eine Fritz.Box gekoppelt. der HM-CFG-USB wird denke ich mal den ccd2 ersetzen, der ccd2 kommt dann in meine Testumgebung, da ich den zurzeit eh nur als Basis für die homematic nutze und den Schirm da meist aus habe.
Vielen Dank für die tolle Arbeit hier.
Zusätzlich zu meinem original Busware CUL läuft nun schon der erste MAX! Cube als CUN. Dieser Bedient den IT Bereich in 433.9 Mhz.
Der zweite Würfel liegt schon bereit und wird Wahrscheinlich im HM Modus arbeiten.
Eine Frage habe ich allerdings noch:
Gibt es einen technischen Grund warum die Würfel keinem WMBus Mode unterstützen, oder ist es nur in der Software nicht drin?
Könnte das Gut brauchen ;-)
Liebe Grüße
Zitat von: Gator99 am 06 Dezember 2015, 15:55:49
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.
:D
*jubel* *jubel* *freu* *freu*
Besten Dank, sehr nett von dir.
Wenn du in der Nähe bist, sag bescheid. Ich zahle in Bier ;-)
Gruss
Hallo Zusammen,
um mal "ganz dumm" in die Runde zu fragen....wie kann ich die Firmware selbst kompilieren?
(Vorzugsweise im Windows)
(((Ich hab seit dem Umstieg des MAX!Cubes auf CUL und Fhem aktuell massive Credit Probleme und würde gern, zumindest für den Übergang das Limit erhöhen.)))
Danke,
Kharim
Es gibt einen neue Version in der jetzt auch Mbus, ZWave, LaCrosse/IT+ und Kopp-fc aktiviert ist.
Zitat von: Kharim am 07 Dezember 2015, 22: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
Dank dir,
nach Installation des Make-Tools und Anpassung der PATH Variable ist auch das nun geschafft *gg*
Zitat von: Telekatz am 06 Juli 2015, 20:59:36
Der Quellcode für die ARM Version ist jetzt in der a-culfw enthalten.
Noch ein Hinweis zur Hardware des HM-CFG-USB-2 und des MAX! Cube. Mir aufgefallen, dass bei diversen MAX und Homematic Geräten Funkmodule mit einem Si4431 anstelle eines CC1101 Chips verwendet werden. In der Regel steht der Typ des Funkmoduls Außen auf dem Gerät. TRX868-TFK-TI für den CC1101 und TRX868-TFK-SL für den Si4431.
Die culfw funktioniert nur mit einem CC1101 Funkmodul. Die beiden HM-CFG-USB-2 Adapter die ich habe, haben einen CC1101 verbaut. Allerdings könnte es auch welche geben, die einen SI4431 haben. Bitte dies vor dem löschen der Originalfirmware kontrollieren.
Auf meinem Cube steht hingegen nur TRX868. Den habe ich allerdings auch schon seit 2012. Könnte hier bitte mal jemand der sich kürzlich einen Cube gekauft hat nachsehen, ob der Typ des Funkmoduls jetzt auch genauer angegeben ist?
Hi,
Auf meinem Cube steht auch nur TRX868.
Er ist auch schon älter. Geht es mit diesem?
Und nach Bootloader und fw (welche nehme ich genau) wie kann ich ihn zum CUN machen?
Zitat von: masterpete23 am 10 Dezember 2015, 07:20:17
Auf meinem Cube steht auch nur TRX868.
Er ist auch schon älter. Geht es mit diesem?
Ja, es geht mit dem.
Zitat von: masterpete23 am 10 Dezember 2015, 07:20:17
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.
Ok und wie wird er cun?
Gesendet von meinem Huawei Honor 7
Indem man das Netzwerkkabel ansteckt.
Hallo zusammen,
ich versuche mich auch gerade daran, meinen Cube zu flashen. Allerdings klappt das nicht so wie erwartet.
Das löschen der Original-Firmware scheint geklappt zu haben, im Gerätemaneger wurde mir ein neues unbekanntes Gerät gezeigt, das ich dann mittels des Treibers erfolgreich zu einem "AT91 USB to Serial Converter" machen konnte.
Wenn ich SAM-BA starte und COM7 sowie das Board at91sam7x256-ek wähle, schließt sich beim connecten SAM-BA ganz einfach und das war es. Wenn ich dann SAM-BA neu starte, erscheint die Meldung "Open a new SAM-BA Instance?". Anscheinend läuft das Programm also noch aber es passiert nix. Im Task-Manager finde ich keine verdächtigen Tasks.
Auf dem Cube steht TRX868-TI, nachdem was ich hier gelesen habe sollte es damit doch eigentlich klappen, oder?
LG,
petjek
Ich komm nicht weiter
habe j1 verbunden und gelöst nach neu anschließen zeigt windows
bossa program port
nun kommt die frage
Ich habe einen atmel at91sam7x512. diesen wähle ich bei Samba aus (at91sam7x512-ek)
bei flash wähle ich die adress statt 0x100000 0x104000.
Welches File muss ich nun flashen?
und welches file muss ich dann mit teraterm flashen?
im CUBe Ordner liegt CUBE_BL.bin und da im bootloader liegt bootloader_CUBE.bin beides in a-culfw_1.20.01_build_176_master
ich habe CUBE_BL.bin genommen und danach ging es schon sofort
nur weiß ich nicht wie ich dann maxmode definen muss
den cul habe ich auf port 2323 defined nur wie mache ich weiter?
In fhem auf das Device gehen. Und rfmode unten als Attribut setzen. Da kannst du kann Homematic slowrf oder max wählen.
Danke auf max und geht. Bis aufs pairen. Da error.
Gesendet von meinem Huawei Honor 7
Hat keiner eine Idee was ich falsch mache? Kann das am Treiber liegen?
Hey Petjek,
Um ganz sicher zu gehen, versuche doch mal einen kompletten Neuanfang in einer virtuellen Maschine.
Ich empfehle Linux, dort hast du erheblich weniger Ärger mit Treiber für Com und Co. Zusätzlich kannst du diese Installation bequem als Testumgebung für FHEM nutzen.
Für Anfänger ist Mint Linux gut geeignet.
Auch eine der vielen Linux Live CDs wäre vielleicht eine Möglichkeit.
Gruss
Hallo petjek,
welches SAM-BA Version hast du verwendet? Und hast du SAM-BA als Administrator gestartet?
Moin
SAM-BA 2.15 habe ich installiert. Und da ich als Administrator angemeldet war habe ich das doch auch als Administrator gestartet oder?
LG,
petjek
Hi alle,
ich hab jetzt alles zweimal durchgelesen, aber bei Klenigkeiten bin ich mir nicht 100%ig sicher:
Da ich FHEM nur in einer VM ohne USB-Ports habe: Nach dem Flashen an einem lokalen PC, ist da Ganze denn dann direkt Netzwerkfähig? Ging ja wohl am Anfang noch nicht, aber geht es inzwischen?
Ich kann dann mit FHT und FS20 kommunizieren? (Ja, mit MAX gleichzeitig geht's dann nicht mehr)...
Bin zwar blutiger FHEM Anfänger, aber für mich geht da jetzt kein Weg mer dran vorbei ;-)
@petjek
Verbinde den Cube mal mit einen Terminalprogramm und gib V# ein. Wenn der SAM-BA Bootloader läuft solle etwas in der Art "v1.4 Feb 02 2005 17:55:46" ausgegeben werden.
@MAC66666
Ja, der Cube ist Netzwerkfähig. FHT und FS20 geht damit natürlich auch.
Erstmal vielen Dank für die Firmware. :)
Nachdem ich SAM-BA unter Windows 10 nicht zum Laufen gebracht habe, habe ich den Cube direkt am RasPi mit bossa und minicom geflashed. Soweit funktioniert auch alles, an USB wird der Cube als CUL erkannt.
Aber wie bekomme ich ihn jetzt ins Netz? Er hängt jetzt wieder direkt am Lan-Port des Routers, bekommt aber keine IP-Adresse.
Ein "list CUL0" ergibt:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefltxz
CUL0_MSGCNT 21
CUL0_TIME 2015-12-15 23:10:10
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/ttyACM1@9600 0000
DeviceName /dev/ttyACM1@9600
FD 12
FHTID 0000
NAME CUL0
NR 131
NR_CMD_LAST_H 2
PARTIAL
RAWMSG Z0E80020206856102A8230001182F2822
RSSI -57
STATE Initialized
TYPE CUL
VERSION V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2015-12-15 23:01:21 cmds B b C F i A Z N E k G M K L U Y R T V W X e f l t x z
2015-12-15 23:10:10 state Initialized
2015-12-15 22:24:26 uptime 0 00:11:37
2015-12-15 22:24:32 version V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
XMIT_TIME:
1450215554.14902
1450215554.45074
Attributes:
rfmode MAX
Ich vermute entweder LAN oder usb ? Leuchtet die LED?
Gesendet von meinem Huawei Honor 7
Zitat von: masterpete23 am 15 Dezember 2015, 23:17:12
Ich vermute entweder LAN oder usb ? Leuchtet die LED?
Ich habe es auch schon ohne USB-Verbindung zum Raspi probiert, ohne Erfolg. :-\
Die LED für die Netzwerk-Verbindung leuchtet, sobald ich das LAN-Kabel anschließe.
Edit:
Nach dem ich nach dieser Anleitung (http://culfw.de/commandref.html#cuno_setup) den Cube ohne DHCP eingerichtet hatte passierte erstmal wieder nix. Nach einem Factory Reset ist er jetzt im Netz.Nachdem ich den Cube wieder vom Raspi getrennt und direkt ans Ladegerät gehängt habe verbindet er sich wieder nicht mit dem Router. :-\
So, ich habe jetzt alles probiert. Solange der Cube per USB am Pi hängt, bekommt er eine IP-Adresse und findet sich auch im Netzwerk. Ich komme mit screen direkt über USB und auch per telnet übers Netz auf Cube als CUNO. (BTW: Gibt's kein Kürzel zum Beenden der Verbindung?)
Sobald ich den Cube vom Pi trenne und nur über LAN mit dem Netz verbinde (USB-Kabel im Netzstecker) stellt er sich tot. Firmware ist die aktuellste Build 176 vom 07.12.
Mit der Originalfirmware gab es keine Netzwerkprobleme. Welchen Unterschied kann es geben zwischen USB-Kabel am Pi oder am Netzstecker?
Edit: Es läuft! ;D
Ich habe am Pi jetzt die aktuellste Firmware von Github gezogen und selbst kompiliert. Auf den Cube aufgespielt, und siehe da, er meldet sich übers Netz, ohne am Pi zu hängen.
V 1.20.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
P.S.: Zum Kompilieren habe ich folgendes Makefile.local erstellt:
###############################################################
INCLUDEPATH = /usr/lib/arm-none-eabi/include
LIBPATH = /usr/lib/arm-none-eabi/lib
#ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-
######################## EOF ##################################
Dazu habe auf dem Pi noch binutils-arm-none-eabi und gcc-arm-none-eabi installiert.
Zitat von: Telekatz am 14 Dezember 2015, 17:03:35
@petjek
Verbinde den Cube mal mit einen Terminalprogramm und gib V# ein. Wenn der SAM-BA Bootloader läuft solle etwas in der Art "v1.4 Feb 02 2005 17:55:46" ausgegeben werden.
Terminalprogramm? Dazu muss ich ihn wieder ins LAN hängen, oder? Per USB wird das nicht gehen, woll?
Muss ich dann die IP-Range des Rechners auf die des Cubes anpassen?
Zitat von: petjek am 17 Dezember 2015, 13:44:19
Terminalprogramm? Dazu muss ich ihn wieder ins LAN hängen, oder? Per USB wird das nicht gehen, woll?
Muss ich dann die IP-Range des Rechners auf die des Cubes anpassen?
Dein Problem war doch, dass SAM-BA unter Windows nicht lief. Das läuft über USB. Netzwerk geht ja erst, nachdem die Firmware geflasht wurde.
@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 :)
Nein, am ST2 kommen auch im laufenden Betrieb Debugausgaben.
Man könnte den Datenverkehr vom USB Port aber auch an ST1 duplizieren. Dort ist auch eine serielle Schnittstelle mit der selben Pinbelegung wie auf ST2 vorhanden.
Zitat von: Telekatz am 17 Dezember 2015, 14:32:49
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?
Damit die LEDs leuchten muss da erst eine passende Firmware drauf. Der SAM-BA Bootloader steuert die nicht an. Wenn du allerdings auch mit Putty keine Verbindung zu Cube bekommst, dann ist irgendwas nicht mit dem SAM-BA Bootloader nicht in Ordnung. Versuch nochmal einen Flash erase.
Woher hast du eigentlich den Treiber genommen, den du dem Unbekannten Gerät zugewiesen hast? Aus dem SAM-BA Verzeichnis?
Hab ich gemacht. Leider kein Erfolg. Keine Reaktion auf Putty oder SAM-BA.
Den Treiber hab ich aus dem Verzeichnis C:\Program Files (x86)\Atmel\sam-ba_2.15\drv
Kannst du nochmal zusammen fassen was du wie von wo genommen hast?kann ja nicht sein das so viele keine Probleme hatten. Das kriegen wir schon hin.
Gesendet von meinem Huawei Honor 7
Du meinst wie ich den Treiber installiert habe?
Ich habe mich als Administrator am Rechner angemeldet, Flash erase wie beschrieben durchgeführt und anschließend den Cube wieder verbunden. Im Gerätemanager tauchte dann ein unbekanntes Gerät auf. Dort habe ich über Rechtsklick den Treiber manuell installiert und dabei den aus dem o.g. Verzeichnis genommen.
welches OS hast du.
Ich wundere mich nur, da ich gar keine Treiber installieren mussen.
Flash per Jumper gelöscht.
Dann Kabel rann undper SAM-BA aktiv gewesen.
Alles tutti
An OSsen habe ich die Wahl zwischen MacOS, Win7, Ubuntu und einen ungenutzten Raspberry Pi hätte ich auch noch. Probiert habe ich es aber bis jetzt nur unter Win7.
Per Jumper gelöscht? Wie und wo denn?
Zitat von: petjek am 18 Dezember 2015, 13:35:55
Per Jumper gelöscht? Wie und wo denn?
wie im ersten Post beschrieben :
Zitat von: Telekatz am 22 Juni 2015, 22:42:29
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 ....
Ach so. Ja klar. So hab ich das auch gemacht. Ich habe dazu ein Stück Kupferdraht genommen, den ich schräg abgeknipst habe, damit er in die beiden kleinen Löcher passt.
Jumper klang für mich so als gäbe es da noch irgendwo Pins die ich übersehen hätte auf die man einen Jumper stecken könnte.
Ich denke schon dass der Flash erase funktioniert hat. Seitdem sind die LEDs aus. Wäre da noch die Firmware drauf würde das doch anders aussehen, oder?
Probier doch nochmal das löschen oder hast du schon?
Gesendet von meinem Huawei Honor 7
Mehrfach.
Muss man unter Win 7 nen Treiber zwingend nehmen? Welchen Chip hast du drauf?
Gesendet von meinem Huawei Honor 7
Nutzt hier noch jemand den Cube als CUN in Verbindung mit einem Speedport Hybrid der Telekom?
Nachdem der Cube jetzt 2 Tage im Netz erreichbar war ist er jetzt nach einem Neustart des Routers (und auch des Cube selbst) wieder weg. ???
Ich habe so langsam den Verdacht, daß es vielleicht am Router liegen könnte, obwohl ich mir das nicht erklären kann. Andererseits macht es auch keinen Sinn, daß er sich im Netz anmeldet, wenn er per USB am Pi hängt.
Dummerweise hab ich keinen weiteren Cube oder CUL als Backup.
Edit: Wieder zur Diagnose an den Pi gehängt, angeblich hat er eine IP aus meinem Netz. Hier die Ausgaben nach factory reset (e) von V, Rid, Ria, Rig:
V 1.20.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
01
192.168.2.101
192.168.2.1
255.255.255.0
Trotzdem ist er über die 192.168.2.101 nicht erreichbar, dabei ist er gerade sogar wieder im Router sichtbar.
So langsam weiß ich keinen Rat mehr. Ethernet-Kabel habe ich bereits getauscht, statt an den Router an einen Powerlan-Adapter gehängt. Kein Ergebnis. :-\
Ich hab es gerade mal ausprobiert. Cube mit aktueller Firmware direkt am Speedport Hybrid angeschlossen, Stromversorgung über Nertzteil, IP Adresse über DHCP vom Speedport. Nach dem Neustart des Speedport war der Cube noch unter seiner IP Adresse erreichbar. Nach dem Neustart des Cube hat dieser vom Speedport eine neue IP Adresse bezogen. Nachdem die neue IP Adresse in FHEM geändert wurde war der Cube auch wieder erreichbar.
Auf dem Speedport selbst war in der "Übersicht der Geräte im Heimnetzwerk" immernoch die alte IP Adresse vorhanden. Nach dem anklicken von "Liste aktualisieren" war dann auch im Speedport die neue IP Adresse angegeben.
Noch etwas zum Thema Treiber. Dass manche keinen Treiber installieren mussten könnte daran liegen, dass die Arduino IDE installiert war. Mit der wird auch ein kompatibler Treiber installiert. Im Gerätemanager taucht der Cube dann als "Bossa Program Port" auf.
Nein habe die IDE nicht aber vllt hat Windows 10 das dabei. Genau hieß bei mir auch Bossa...
Gesendet von meinem Huawei Honor 7
Zitat von: Telekatz am 17 Dezember 2015, 17:50:43
Nein, am ST2 kommen auch im laufenden Betrieb Debugausgaben.
Man könnte den Datenverkehr vom USB Port aber auch an ST1 duplizieren. Dort ist auch eine serielle Schnittstelle mit der selben Pinbelegung wie auf ST2 vorhanden.
hmm schade. Wie hoch schätzt du den Aufwand dafür ?
Beim ATmega328 ist das ganze Thema serielle Ausgabe mit vier Zeilen abgehandelt:
#define HAS_UART 1
#define UART_BAUD_RATE 38400
uart_init( UART_BAUD_SELECT_DOUBLE_SPEED(UART_BAUD_RATE,F_CPU) );
uart_task(); wenn ich aber sehe was du beim CUBe mit USART0, USART1 und USB da machst muss ich leider zugeben ist das ne Nummer zu groß für mich :(
Zitat von: masterpete23 am 18 Dezember 2015, 14:45:43
Muss man unter Win 7 nen Treiber zwingend nehmen? Welchen Chip hast du drauf?
Gesendet von meinem Huawei Honor 7
So ich habe es jetzt noch mal mit einer Win7-VM auf dem Mac versucht. Auch da musste ich den Treiber aus dem Programmverzeichnis manuell installieren. Leider führt das zu dem gleichen Ergebnis.
Ich würde es ja auch noch mal unter Linux probieren, wenn mir jemand sagen kann, wie das damit geht.
Der Chip ist ein AT91SAM7X256.
Versuch doch mal ne Win 10 vm
Gesendet von meinem Huawei Honor 7
Zitat von: Telekatz am 18 Dezember 2015, 16:49:17
Ich hab es gerade mal ausprobiert. Cube mit aktueller Firmware direkt am Speedport Hybrid angeschlossen, Stromversorgung über Nertzteil, IP Adresse über DHCP vom Speedport. Nach dem Neustart des Speedport war der Cube noch unter seiner IP Adresse erreichbar. Nach dem Neustart des Cube hat dieser vom Speedport eine neue IP Adresse bezogen. Nachdem die neue IP Adresse in FHEM geändert wurde war der Cube auch wieder erreichbar.
Auf dem Speedport selbst war in der "Übersicht der Geräte im Heimnetzwerk" immernoch die alte IP Adresse vorhanden. Nach dem anklicken von "Liste aktualisieren" war dann auch im Speedport die neue IP Adresse angegeben.
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":
[/list]
2015.12.22 07:42:08 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 0f1d040312345600a8f1000f1607ea05
2015.12.22 07:43:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 64, but we need 121. Waiting 57 seconds.
2015.12.22 07:44:12 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 191e001012345600a8f1000240b44cfc40004520452045204520
2015.12.22 07:44:12 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 121. Waiting 117 seconds.
2015.12.22 07:46:16 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:48:16 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:50:17 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:52:14 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 191f001012345600a8f1000340b44cfc40004520452045204520
2015.12.22 07:52:14 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 4, but we need 121. Waiting 117 seconds.
2015.12.22 07:54:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:56:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 07:58:19 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds.
2015.12.22 08:00:17 2: CUL_MAX_SendQueueHandler: Missing ack from 00a8f1 for 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.
Hi,
eine Möglichkeit zum Auslesen der Verbindung wäre traumhaft... gib es aber meines Wissens nach nciht....
Die meisten Thermostate lassen sich weder manuell noch per FHEM auf auto schalten.
Wenn Kein wochenprogramm hinterlegt ist kannst du auch nicht auf Auto schalten, weder mit FHEM noch am Thermostat
ich bekomme keine neuen Wochenprogramme auf die Thermostate. Der Versuch scheitert regelmäßig mit zu wenigen Credits und "missing ack":
Das Übertragen den Wochenprogramme frisst credits ohne ende.... mit etwas "krimineller Energie" könntest du das maximale creditlimit deines CUBe erhöhn, dazu einfach die datei rf_send.h modifizieren und anstatt 900 z.B. 3600 eintragen.
Achtung: Dadurch überschreitest du ggf. die maximale Sendezeit pro Stunde (1% Regel ...)
Danach neu compilieren und neu flashen.
Grüße,
Stephan
Missing ack deutet doch auf nicht gepairt oder?
Gesendet von meinem Huawei Honor 7
Zitat von: CaptainHook am 22 Dezember 2015, 08:44:04
Hi,
eine Möglichkeit zum Auslesen der Verbindung wäre traumhaft... gib es aber meines Wissens nach nciht....
Schade! Im Wohnzimmer habe ich z.B. 2 Thermostate, 1 Fensterkontakt und 1 Wandthermostat. Da wäre es super, wenn ich sehen könnte, ob alle associates untereinander funktioniert haben.
Zitat von: CaptainHook
Die meisten Thermostate lassen sich weder manuell noch per FHEM auf auto schalten.
Wenn Kein wochenprogramm hinterlegt ist kannst du auch nicht auf Auto schalten, weder mit FHEM noch am Thermostat
In den Readings wird mir ein Wochenprofil angezeigt, also müsste ich doch eigentlich darauf umschalten können.
Zitat von: CaptainHook
ich bekomme keine neuen Wochenprogramme auf die Thermostate. Der Versuch scheitert regelmäßig mit zu wenigen Credits und "missing ack":
Das Übertragen den Wochenprogramme frisst credits ohne ende.... mit etwas "krimineller Energie" könntest du das maximale creditlimit deines CUBe erhöhn, dazu einfach die datei rf_send.h modifizieren und anstatt 900 z.B. 3600 eintragen.
Achtung: Dadurch überschreitest du ggf. die maximale Sendezeit pro Stunde (1% Regel ...)
Danach neu compilieren und neu flashen.
Dann werde ich das mal zumindest testweise ändern, um zu sehen, ob es daran liegt. Mit der Original-Firmware vom Cube hatte ich eigentlich keine Probleme.
Zitat von: masterpete23 am 22 Dezember 2015, 08:52:58
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. :-\
Ich musste meine HT resetten dann ging es korrekt. Das mit dem woxhenplan hatte ich auch. Ich habe dann per Handy App einfach einen gesetzt und dann wurde der auch in den readings angezeigt.
Gesendet von meinem Huawei Honor 7
So, a-culfw mit creditlimit 3600 neu kompiliert und aufgespielt. Pairing ging jetzt auch bei 2 Geräten, auch ohne erneuten Reset.
Aber irgendetwas scheint hier Credits zu fressen ohne Ende:
2015.12.22 10:10:44 3: CUL_MAX_Parse: Pairing device 007fed of type HeatingThermostat with serial IEQ0195899
2015.12.22 10:11:42 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 109, but we need 110. Waiting 1 seconds.
2015.12.22 10:14:29 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 57, but we need 110. Waiting 53 seconds.
2015.12.22 10:15:28 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 110. Waiting 103 seconds.
2015.12.22 10:17:18 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 110. Waiting 103 seconds.
Zwischen dem Pairing und den "Not enough credit"-Warnungen habe ich nur versucht, an einem Thermostat per fhem die Temperatur zu ändern, um zu sehen, ob es wieder einen "missing ack" gibt.
Seit dem Aufspielen der neuen Firmware habe ich also nur an 2 Thermostaten die Temperatur geändert, nach "missing ack" die beiden gepairt und das ganze an einem dritten Thermostat versucht. Das darf doch noch nicht sämtliche Credits verbrauchen, oder?
Zitat von: mahowi am 22 Dezember 2015, 08:17:19
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.
Ich habe ne Weile gegoogelt, welche Alternativen zu Sam-Ba es gibt. Dabei bin ich auf BOSSA (http://www.shumatech.com/web/products/bossa) gestoßen. Gibt es auch als Paket für Ubuntu oder Debian bzw. Raspbian:
bossa - Atmel SAM ARM microcontroller flash programming GUI
bossa-cli - Atmel SAM ARM microcontroller flash programming utility
Die GUI habe ich nicht getestet. Ich habe im terminal einfach die BOSSA Shell (bossash) aufgerufen. Sollte dann in etwa so aussehen:
$ bossash
Press Ctrl-D or enter "exit" to end session.
Enter "help" to display a command list.
bossa>
Dann einfach mit "scan" nach dem CUBe suchen. Dabei sollte er automatisch verbunden werden. Dann mit "write bootloader_CUBE.bin" den Bootloader schreiben. Dann "bootf true" und der CUBe bootet neu in den Bootloader. Danach kannst Du mit einem Terminalprogramm (z.B. minicom) die Firmware auf den CUBe bringen.
Danke fuer die Infos.
Allerdings bekomme ich auch unter Ubuntu mit Bossa keine Verbindung zum Board. Bossa findet beim Scan kein Geraet.
Ich habe so langsam den Verdacht, dass das Board hin ist. Wodurch auch immer. :(
Hi,
Du machst das ganze in einer VM? Bist du sicher das der Port auch richtig durchgereicht wird?
Als weitere Möglichkeit könntest du ein Linux Live System von DVD booten und es damit versuchen...
Gesendet von meinem A0001 mit Tapatalk
Ich habe das an einem Windows-Laptop mit Windows 7 probiert, an einem Mac mit Windows-VM und am selben Mac mit einer Ubuntu-VM. Die Windows-VM erkennt das USB-Gerät, wenn ich es anschließe, daher vermute ich, dass es auch in der Ubuntu-VM so wäre. Wie auch immer, es ist jedes mal das gleiche Ergebnis, nämlich keines. Ich könnte es jetzt noch nativ am Mac mit Bossa probieren, da habe ich aber Probleme, die Dateien aus der .dmg nach /usr/bin zu verschieben. Keine Berechtigung.
Der Flash erase ist ja eine ziemlich einfache Sache, daher vermute ich, dass ich da nichts falsch gemacht habe. Aber allem Anschein nach habe ich jetzt hier einen kleine quadratischen Schrotthaufen produziert, wie auch immer ich das geschafft habe.
:(
Naja, ist ja Weihnachten, da kann ich mir ja noch schnell einen CUNX wünschen. ::)
Ach ja: Fröhliche Weihnachten allen hier! ;)
Hallo zusammen,
fange erst gerade mit FHEM an und der Groschen ist leider noch nicht gefallen.
Bin auch kein Entwickler und komme mit der techn. Beschreibung zu diesem Thema nicht immer ganz mit.
Habe aber einen MAX Cube von einem Freund geschenkt bekommen, allerdings ohne Aktoren und frage mich was ich am Ende mit dem Ding machen kann wenn ich ihn flashe?
Ist das dann ein Gerät (von der Funktion her) ähnlich einem Busware CUL? (CUL ist ja lokal am USB Port und CUN wäre die Netzwerkversion, soviel habe ich schon begriffen)
Welche Protokolle (Geräte) kann ich denn damit zur Zeit ansprechen ?
Unter http://www.meintechblog.de/2015/02/fhem-welches-gateway-fuer-welches-system/ (http://www.meintechblog.de/2015/02/fhem-welches-gateway-fuer-welches-system/) gibt es ja eine brauchbare Auflistung was mit einem Busware CUL alles geht.
Da ich auch schon einzelne Komponenten z.B. aus der FS 20 Serien besitze würde ich gerne den MAX flashen wenn ich ihn am Ende dafür gebrauchen kann?
433 MHz Steckdosen gehören ebenfalls schon zu meiner Sammlung, die ich zur Zeit über einen eigenen Sender über GPIO schalte.
Könnte man die MAX Aktoren nach dem flashen noch ansprechen?
Und was passiert wenn beim flashen was schiefgeht, ist der Cube dann für die Tonne?
Vielen Dank für Eure Antworten
Zitat von: Ralle am 24 Dezember 2015, 15:06:20
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.
Was passiert denn genau?
Gesendet von meinem Huawei Honor 7
Na eben nichts (mehr)!
Ich habe inzwischen gefühlte 98 mal einen Flash erase durchgeführt.
Also J1 mit einem Kupferdraht gebrückt, USB angeschlossen, 5 sek gewartet, Kabel wieder ab, Brücke raus, Kabel wieder dran. Anschließend zeigt Windows 7 ein unbekanntes Gerät, dass ich mit den Treibern aus dem SAM-BA- Programmverzeichnis versehen habe. SAM-BA macht nach Auswahl des Ports und des Chips die Biege, zumindest die GUI verschwindet einfach. Im Hintergrund scheint noch was zu laufen, da ich beim erneuten Start von SAM-BA gefragt werde, ob ich eine weitere Instanz öffnen will.
Das gleiche Verhalten habe ich unter einer Windows-VM am Mac reproduzieren können.
Unter Ubuntu (VM) hab ich's mit Bossa versucht, das findet beim Scan kein Gerät.
Unter MacOS bekomme ich Bossa nicht ans Laufen, da mangelt es einerseits an den Rechten, die erforderlichen Programme nach /usr/bin zu verschieben und mir an der Fähigkeit, dass im Terminal mit den erforderlichen Rechten auszuführen.
Alles in Allem sehr ärgerlich aber so langsam gebe ich auf.
Kannst du mir auch per Post schicken mit Rückporto dann schau ich mal oder der Ersteller des threads vllt auch?
Gesendet von meinem Huawei Honor 7
Du könntest es noch über die die Debugschnittstelle an ST2 probieren, falls du einen Seriellen Wandler mit TTL Pegel hast. Damit könnte man dann den USB Treiber als Fehlerquelle ausschließen. Oder falls vorhanden mit einem JTAG Interface.
Auf einen Raspberry hab ich es gerade mit Bossa auch noch probiert. Hat funktioniert
Zitat von: Ralle am 17 Januar 1970, 20:02:45
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.
Zitat von: Telekatz am 24 Dezember 2015, 17:38:18
Du könntest es noch über die die Debugschnittstelle an ST2 probieren, falls du einen Seriellen Wandler mit TTL Pegel hast. Damit könnte man dann den USB Treiber als Fehlerquelle ausschließen. Oder falls vorhanden mit einem JTAG Interface.
Ä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.
@petjek, wenn ich deinen Leidensweg bis jetzt richtig gelesen habe hast du entweder unter Windoof oder innerhalb einer VM gearbeitet.
Mal ganz banal : Hast du schon mal das USB Kabel gewechselt ?
Dann schreibst du mehrfach das du auch einen Rpi besitzt, hast den aber noch nie mit dem Cube verbunden und ganz primitiv versucht mit einem Term Prg anzusprechen ( putty / minicom /miniterm ) ?
Das das kleine SAM-BA Fenster beim connect verschwindet ist normal. Es bleibt verschwunden bis erfolgreich der Connect zum Cube durchgeführt wurde und kommt dann wieder als großes Fenster, dauert bei meiner alten Hardware so ca. 1 Sekunde.
Das mit dem USB Kabel ist ja nicht so einfach. Bei mir zumindest ist das ein Mini-USB Kabel und davon besitze ich genau eines. Den RPi kann ich natürlich auch noch testen.
Super Idee wzut
Gesendet von meinem Huawei Honor 7
Mensch petjek, nun sei doch mal ein bissel kreativ ... es ist Weihnachten die Geschäfte sind zwar zu aber deine Nachbarn sitzen zu Hause und warten nur darauf das du klingelst und Sie bittest dir mal kurz das Kabel auszuleihen mit dem sie ihr Smartphone laden :)
Ne cube ist doch Mini und nicht micro usb oder
Gesendet von meinem Huawei Honor 7
Ja ebent!
Zitat von: Wzut am 25 Dezember 2015, 15:05:04
@petjek, wenn ich deinen Leidensweg bis jetzt richtig gelesen habe hast du entweder unter Windoof oder innerhalb einer VM gearbeitet.
Mal ganz banal : Hast du schon mal das USB Kabel gewechselt ?
Ja, habe gerade eines gefunden. Funktioniert ebenfalls nicht.
Zitat von: Wzut am 25 Dezember 2015, 15:05:04
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.
Kannst du mal im Gerätemanager nachsehen, mit welcher VID und PID sich der Cube meldet.
Wenn ich das richtig lese ist VID 03EB und PID 6124.
Ich glaube durch meine Probiererei habe ich jetzt einiges strubbelig gemacht. Wenn ich den Cube an dem vorderen der beiden seitlichen USB-Ports anschließe wird er als AT91 USB to Serial Converter (COM7) erkannt, benutze ich den USB-Port daneben ist es ein BOSS Programm Port (COM8). So oder so sagt Bossa mir aber
Could not connect to device on COM7 //bzw. COM8//
beim Versuch zu verbinden.
Zitat von: petjek am 26 Dezember 2015, 09:59:43
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
Ich würde den Cube mal an den Pi anschließen und bossa installieren. (sudo apt-get install bossa-cli) Dann bossash starten und scan eingeben. Dann sollte der Cube gefunden werden. Eventuell mal mit dmesg anzeigen lassen, ob der Cube überhaupt erkannt wurde. Sollte an /dev/ttyACMx als Cubeloader erkannt werden. Sollte dann so aussehen:
[Di Dez 22 09:58:23 2015] usb 1-1.3: new full-speed USB device number 78 using dwc_otg
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=6119
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Di Dez 22 09:58:23 2015] usb 1-1.3: Product: CUBELOADER
[Di Dez 22 09:58:23 2015] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
Ok. Probiere ich aus wenn ich wieder in der Heimat bin. ;)
Hallo zusammen,
Bin absoluter fhem Neuling und bin beim Beschaffen der Komponenten über das culfw@arm gestolpert. Zum Glück! :-) Vielen Dank an Telekatz für die tolle Arbeit. Ich habe den Max Cube auch erfolgreich flashen können und als cul über USB eingebunden. Nach und nach möchte ich gerne drei weitere CUBEs einsetzen, u.a. für 433 MHz und FS20. Wenn ich richtig verstanden habe, muss ich bei USB selbst kompilieren wg. GeräteID. Gilt das auch für den Anschluss als CUN? Wäre es evtl. möglich im nächsten Build weitere Firmware Dateien anzuhängen für diesen Zweck? Wäre echt super, traue mich noch nicht so recht an Toolchain ran um selbst zu kompilieren :-(
Zitat 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
Zitat von: Tatsu am 28 Dezember 2015, 18:50:12
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
Zitat von: Wzut am 28 Dezember 2015, 19:20:57
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...
Mir sind jetzt auch zwei zusätzliche Cubes in die Hände gefallen und überlege jetzt einen als Cuno für 433MHz zu nutzen.
Bevor ich jetzt die Firmware lösche....
Wenn ich den kleinen Antennen Draht durch einen in der Länge von 17cm ersetze, sollte das doch gut funktionieren?
Hi,
Dadurch passt die Abstimmung trotzdem nicht... Wenn dann müsstest du das Funkmodul tauschen. Sprich das original auslöten und ein 433-Modul einlöten..
Gesendet von meinem A0001 mit Tapatalk
Ok schade, dann werde ich nur einen für Homematic nehmen und den zweiten evtl. auf Reserve.
Hallo Leute.
Ich habe momentan Dank euch 2 Cubes erfolgreich mit der neuesten aculfw geflasht und in Betrieb. 1 für. Max + IT schalten und einen für. 433mhz senden und empfangen. Nun möchte ich an den Cubes gerne eine SMA Buchse anlöten um eine anständige Antenne dran machen zu können.
Nun zu meinem Problem. Ich weiß zwar welchen Pin ich an die Buchse löten muss, nur wo soll ich die Masse(Schirm) der SMA Buchse anlöten?
Vom Mobiltelefon gesendet.
Hallo zusammen,
stehe im Moment auf den Schlauch und komme einfach nicht weiter(Newbie)
Habe mit den MAX Cube erfolgreich geflasht und er ist nun auch im Netzwerk anzupingen.
Nun muss ich ja die Konfiguration in FHEM erstellen.
Meine Ersten Versuche mit define MAX_Lan <|IP> funktionieren ja nun nicht mehr.
Wie bekomme ich den CUL der ja jetzt ein CUN ist in die Konfig eingebunden ?
Define name CUL <adresse> ist ja keine IP möglich.
Define CUN gibt es nicht ?
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
Zitat von: masterpete23 am 29 Dezember 2015, 14:09:10
define maxcube CUL 192.168.0.123:2323 0000
attr maxcube rfmode MAX
attr maxcube room CUL
define cmax CUL_MAX 654321
attr cmax IODev maxcube
Gesendet von meinem Huawei Honor 7
Danke, das ist die Info die mir gefehlt hat :)
Zitat von: mahowi am 27 Dezember 2015, 12:24:42
Ich würde den Cube mal an den Pi anschließen und bossa installieren. (sudo apt-get install bossa-cli)
So, wieder zuhause und gleich mal ausprobiert.
sudo apt-get install bossa-cli liefert folgendes Ergebnis:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden gelesen.... Fertig
E: Paket bossa-cli kann nicht gefunden werden.Muss ich da noch irgendwas an Quellen hinzufügen? Und wenn ja, wie?
Vorher sudo apt-get update
Gesendet von meinem Huawei Honor 7
Das hab ich wohl gemacht!
Zitat von: mahowi am 27 Dezember 2015, 12:24:42
Eventuell mal mit dmesg anzeigen lassen, ob der Cube überhaupt erkannt wurde. Sollte an /dev/ttyACMx als Cubeloader erkannt werden. Sollte dann so aussehen:
[Di Dez 22 09:58:23 2015] usb 1-1.3: new full-speed USB device number 78 using dwc_otg
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device found, idVendor=03eb, idProduct=6119
[Di Dez 22 09:58:23 2015] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Di Dez 22 09:58:23 2015] usb 1-1.3: Product: CUBELOADER
[Di Dez 22 09:58:23 2015] cdc_acm 1-1.3:1.0: ttyACM0: USB ACM device
So sieht es leider nicht aus sondern so:
[1233.192024] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[1233.295001] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6124
[1233.295043] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[1233.374988] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device:(
Als Cubeloader wird er erst erkannt, wenn der Bootloader aufgespielt wurde. Der SAM-BA Bootloader meldet sich so:
[ 1276.790543] usb 1-1.2: new full-speed USB device number 20 using dwc_otg
[ 1276.893472] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6124
[ 1276.893512] usb 1-1.2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1276.972259] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Bossa mit sudo apt-get install bossa-cli installieren funktioniert bei mir auch nicht. Aber man kann Bossa auch selber bauen:
cd /usr/src
sudo git clone git://git.code.sf.net/p/b-o-s-s-a/code b-o-s-s-a-code
sudo apt-get install libreadline-dev wx2.8-headers libwxgtk2.8-0 libwxgtk2.8-dev
cd b-o-s-s-a-code
sudo make bin/bossash
#Starten
/usr/src/b-o-s-s-a-code/bin/bossash
Soweit scheint das jetzt zu klappen. Bossa habe ich erfolgreich selbst gebaut und konnte mit
bossa> scan
Checking port ttyACM0...
Device found on ttyACM0
bossa> connect ttyACM0
Connected to device on ttyACM0
bossa> write /home/pi/Desktop/bootloader_CUBE.bin
Write 196 bytes to flash
[==============================] 100% (1/1 pages)
bossa> bootf true
Boot to flash flag set to true
bossa>
den Bootloader installieren. Einen reboot hat er aber nicht gemacht. Auch den connect musste ich manuell durchführen.
Also habe ich ihn vom USB angezogen und wieder angeschlossen.
Sollte dann nicht wie im ersten Beitrag geschrieben die LED D1 schnell blinken? Tut sie nicht. Auch nachdem ich den Resetbutton gedruckt habe beim Anschließen.
Zitat von: petjek am 31 Dezember 2015, 13:27:47
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 ?
Es sollten etwa 15040 Bytes sein.
bossa> scan
Checking port ttyACM0...
Device found on ttyACM0
bossa> write /home/pi/bootloader_CUBE.bin
Write 15040 bytes to flash
[==============================] 100% (59/59 pages)
bossa> bootf true
Boot to flash flag set to true
bossa>
Wie hast du das bin File besorgt? Ggf falscher download. Nochmal runterladen und dann sollte das passen
Gesendet von meinem Huawei Honor 7
Hab ich vorhin frisch gezogen von der Adresse aus dem ersten Beitrag.
Mit Windows oder wie?
Gesendet von meinem Huawei Honor 7
Am Raspi
Lade mal per Windows und kopiere dann rueber
Gesendet von meinem Huawei Honor 7
OK, das lag wahrscheinlich alles am Jahr. In 2015 sollte das wohl nicht mehr klappen. ;)
Der Fehler lag bei mir. Ich hatte die Datei noch mal neu geladen und auf meinem NAS abgelegt. Ich habe dann nicht bemerkt, dass ich die Datei nicht kopiert sondern nur einen Link abgelegt hatte. Das kann man am Raspi aber auch nur beim vermeintlichen Kopieren selbst sehen, woll? Danach sah die Datei für mich wie jede andere auch aus.
Egal, nachdem ich nun also das Wunder der Strg-Taste entdeckt habe lag die Datei mit 15040 Bytes auf dem Desktop und mit bossa habe ich sie dann auf den CUBE bekommen.
Was soll ich sagen: er blinkt! Er blinkt wirklich! Dass ich das noch erleben darf! :)
Aber - und wie könnte es anders sein? - wie geht es nun weiter?
Mein erster Versuch galt Windows 7. Da taucht das Gerät nun als CUBELOADER unter Andere Geräte im Gerätemanager auf. Unter Tera Term steht es nicht zur Auswahl. So also schon mal nicht. :(
Also ran an den Raspi, da Putty installiert und eine serielle Verbindung zu /dev/ttyACM0 aufgebaut. Das scheint irgendwie zu klappen aber ich sehe nur einen schwarzen Bildschirm... :(
Nächster Kandidat wäre nun also minicom aber da blicke ich nun gar nicht durch. Ich hab's mal mit minicom -D /dev/ttyACM0 probiert. Das heißt mich dann zwar herzlich Willkommen, danach wird es aber undurchsichtig. Was muss da nun gemacht werden?
Ahc ja, falls es von Interesse ist, hier noch das Ergebnis von dmesg:
[ 87.424648] usb 1-1.2: new full-speed USB device number 7 using dwc_otg
[ 87.529862] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6119
[ 87.529905] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 87.529926] usb 1-1.2: Product: CUBELOADER
[ 87.604905] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[ 87.609116] usbcore: registered new interface driver cdc_acm
[ 87.609193] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
Hat sich die idProduct jetzt geändert?
PS: Ein frohes neues Jahr an alle! Trotz meiner beharrlichen Nerverei. ;)
---
Nachtrag: habe gerade noch was interessantes entdeckt, als ich den CUBE am Mac angeschlossen habe.
(http://content.screencast.com/users/petjek/folders/Snagit/media/e3b9621e-6322-4cf0-86c8-0b2e3afcfbb8/2016-01-01_15-35-22.png)
Ist mein CUBE jetzt ein Telefon???
Hallo zusammen,
nach Stunden der Suche muss ich mich hier doch nochmal melden. Bei mir hatte das Flashen mit der Amtelsuite nicht funktioniert. Ich erhielt dann einen Hinweis wie ich den Maxcube unter linux flashen kann. Diesen Threat finde ich nicht mehr.
Kann mir jemand weiterhelfen wie ich diese Anleitung wieder finde ?
Danke
Zitat von: petjek am 01 Januar 2016, 12:38:50
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.
Zitat von: raspklaus am 01 Januar 2016, 17:26:11
Hallo zusammen,
nach Stunden der Suche muss ich mich hier doch nochmal melden. Bei mir hatte das Flashen mit der Amtelsuite nicht funktioniert. Ich erhielt dann einen Hinweis wie ich den Maxcube unter linux flashen kann. Diesen Threat finde ich nicht mehr.
Kann mir jemand weiterhelfen wie ich diese Anleitung wieder finde ?
Danke
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)
Danke, genau das wars
OK, jetzt bin ich mir nicht sicher ob es das war, bzw. ob ich jetzt fertig bin.
Die Treiber aus dem AMTEL-Verzeichnis wurden nicht akzeptiert, allerdings funktionierte die automatische Installation der Treiber.
Der CUBE wurde dann wieder als AT91 USB to Serial Converter (COM9) angezeigt. Die Verbindung über Tera Term kam auch zustande, die Übertragung wurde gestartet und nach ein paar USB-Disconnect und -Connect Sounds blinkt nun die Power-LED und die Battery-LED leuchtet permanent.
War's das? Hab ich es wirklich geschafft? Ich kann es noch nicht so recht glauben.
---
Nachtrag: Ich glaube es! Unfassbar! Das ich das noch erleben darf!
(http://content.screencast.com/users/petjek/folders/Snagit/media/0c96f540-1b67-4eba-9b7b-2dcb8afd2d40/2016-01-02_11-29-26.png)
Danke an Alle, die hier die Geduld gezeigt haben mir weiterzuhelfen. War ein hartes Stück Arbeit, was?
Jetzt werde ich mich mal daran begeben herauszubekommen, wie ich nun meine Thermostate und Fensterkontakte da wieder angelernt bekomme. ;)
Na endlich. Glückwunsch
Gesendet von meinem Huawei Honor 7
Danke für den Link. Hatte ich doch übersehen :-\
Aber eine Frage habe ich noch:
wenn ich den Cube neu flashen will, muss ich erst nochmal den Bootloader übertragen oder reicht es die neue Firmware per minicom zu übertragen ?
Danke Klaus
Na endlich bekomme ich die Chance mal was hilfreiches beizutragen. :)
Beim Einstecken des USB-Kabels die Reset-Taste gedrückt halten, das aktiviert den Bootloader. Dann kann die FW neu aufgespielt werden. Musste ich auch machen weil ich beim ersten Versuch nicht XMODEM ausgewählt hatte.
Hab da noch auch noch ne Frage. Wie bekomme ich den maxcube nun in den pairmodus?
Ich hab es mit
set maxcube pairmode versucht. Da bekomme ich als Antwort
Unknown argument pairmode, choose one of ITClock bWidth freq hmPairForSec hmPairSerial led patable rAmpl raw reopen sensSo also schon mal nicht.
Der hmPairForSec gilt nur für Homematic-Komponenten, richtig?
Ich habe
- im Wohnzimmer 2x Heizkörperthermostat, 1x Wandthermostat,
- im Badezimmer 1x Heizkörperthermostat+, 1x Fensterkontakt
Ich habe nun alle Komponenten einmal resetet, danach die Wohnzimmergeräte wie in der Raumlösung gepairt. (Kann ich mir das nicht eigentlich sparen?)
Inzwischen tauchen der Fensterkontakt und das Wandthermostat wieder auf, der Rest (also alle Heizkörperthermostate) glänzen noch durch Abwesenheit.
Ich habe mal das heutige Protokoll angefügt. Die Thermostate scheinen nicht erkannt zu werden, richtig? Weiterhin steht da sehr häufig...
Can't connect to socket!... was wohl eher auch nichts Gutes bedeutet, oder?
LG,
petjek
Schau mal hier http://forum.fhem.de/index.php?topic=38404.msg381162.msg#381162
Gesendet von meinem Huawei Honor 7
Öhm, der Link bringt mich zu meinem eigenen Beitrag auf Seite 20.
Oder meinst du den Hinweis, wie man den maxcube definiert? Das hat geklappt. Darum geht's grad nicht.
Mir ging es um das definieren. Wie sieht es bei dir aus?
define maxcube CUL 192.168.0.123:2323 0000
attr maxcube rfmode MAX
attr maxcube room CUL
define cmax CUL_MAX 654321
attr cmax IODev maxcube
Genau so. Bis auf die IP natürlich
Hast du hm oder max? Und das pairen muss auf cmax stattfinden nicht auf maxcube
Gesendet von meinem Huawei Honor 7
Hey Leute. Ich würde mir gerne einen sma Anschluss an den cube löten um eine richtige Antenne dran machen zu können. Hab alles da. Kann mir jemand sagen wo ich den Schirm (masse) anlöten soll??
Vom Mobiltelefon gesendet.
Hi,
Die Masse deines Antennen Steckers kannst du direkt an das Metallgeäuse des Funkmoduls löten, das sollte mit Masse verbunden sein
Grüße,
Stephan
Hab nun an meinen 433mhz cube die sma Buchse und antenne dran. Senden und empfangen ist viel besser bzw reagiert schneller. Danke für den Tipp mit der Masse.
Demnächst kommt die Antenne für meinen cube 868mhz. Werde mal die rssi Werte vorher checken und vergleichen.
(https://uploads.tapatalk-cdn.com/20160107/eefd3326046a3772ddf19732f7e591c3.jpg)
Vom Mobiltelefon gesendet.
Hi,
Hast du das Funkmodul im Cube ausgetauscht oder "einfach nur" ne Externe Antenne drangelötet?
Grüße,
Stephan
Hi.
Ist das gleiche funkmodul . Hab eine SMA Verlängerung genommen. Den Stecker abgeschnitten und den Schirm ans Gehäuse des funkmoduls gelötet und die Antenne an den antennenanschluss.
Vom Mobiltelefon gesendet.
Zitat von: Basegate am 07 Januar 2016, 11:53:02
Hab nun an meinen 433mhz cube die sma Buchse und antenne dran. Senden und empfangen ist viel besser bzw reagiert schneller. Danke für den Tipp mit der Masse.
Demnächst kommt die Antenne für meinen cube 868mhz. Werde mal die rssi Werte vorher checken und vergleichen.
(https://uploads.tapatalk-cdn.com/20160107/eefd3326046a3772ddf19732f7e591c3.jpg)
Vom Mobiltelefon gesendet.
... und die schöne Power lampe geopfert :-\
Mobil erstellt daher kurz gehalten
Na ja, die Power-LED ist meinermeinung nach "unwichtig". Sollange die Battery-LED Blinkt ist doch alles in Butter.
Kannst du bitte ein Platinen Foto Posten und eins von drinnen
Gesendet von meinem Huawei Honor 7
Mach ich beim nächsten cube (868 mhz) ok? Will den ungern wieder auseinander bauen.
Vom Mobiltelefon gesendet.
Hab mich auch hinreisen lassen :)
Alles wie gehabt durchgeführt... Hardware soweit verglichen und bei Connect kam immer Invalide Chip ID.. nach dem Versuch diverser Kabel und 2ten Rechner hab ich dann mal statt at91sam7x256-ek diesen at91sam7x512-ek genommen ??? UPS Funktioniert die Verbindung. Meiner ist aber auch schon ein altes Eisen ca 4 Jahre Alt kann auch Älter sein, lag lange im Baumarkt. Evtl. hat der wohl mehr Internen Speicher.. geh ich mal von der Zahl 512 aus. Evtl. haben sie bei den Neueren schon gespart. Bei mir steht auch nur auf dem Gehäuse (TRX868) Ohne TI oder sonst was. Das Bild zum Vergleich des Funkmoduls ist aber Identisch.
Versuche jetzt zu Flashen :)
EDIT: Scheint zu Funktionieren... Batterie Leuchtet dauernd und Power Blinkt. So mal sehen wie es weiter geht :) PUH hab das Pairen jetzt auch hinbekomen ...pfui spinne, lol ..gewusst wie.
Hab meinen zweiten cube nun fertig mit sma Anschluss. Max empfang zwischen 10 und 15 Dezibel besser. Siehe bilder
Vom Mobiltelefon gesendet.
Habe aber im Moment. Zu wenige Credit zum kompletten einrichten. Habe aber auch beim Thermostat einen RF error gehabt. Ich warte ab, da ich jetzt eh auf Arbeit bin, wie es morgen mit den Credits aussieht.
Hallo zusammen,
ich habe soeben zwei max cube (TRX868) versucht zu flashen. Dabei habe ich unter Linux mit minicom bei beiden folgende Fehlermeldung erhalten:
+-----------[xmodem upload - Press CTRL-C to quit]------------+
Press CTR|Sending fw.hex, 279 blocks: Give your local XMODEM receive command now.
|Xmodem sectors/kbytes sent: 279/34kRetry 0: No ACK on EOT
|Transfer incomplete
| READY: press any key to continue...
+-------------------------------------------------------------+
Der Bootloader ist korrekt installiert:
[ 49.614360] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[ 49.719642] usb 1-1.2: New USB device found, idVendor=03eb, idProduct=6119
[ 49.719684] usb 1-1.2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 49.719703] usb 1-1.2: Product: CUBELOADER
Ebenfalls habe ich es probiert unter Windows zu flashen, hierbei wurden keine Fehlermeldungen ausgegeben.
Wo liegt der Fehler?
Wenn ich den cube einfach per USB anschließe, dann blinkt keine LED. Nur wenn ich den Taster vor dem anschalten gedrückt halte blinkt die LED D1. Wie geschrieben bekomme ich aber keine Firmware geflasht.
Vielen Dank vorab.
Zitat von: darth am 09 Januar 2016, 00:06:46
+-----------[xmodem upload - Press CTRL-C to quit]------------+
Press CTR|Sending fw.hex, 279 blocks: Give your local XMODEM receive command now.
|Xmodem sectors/kbytes sent: 279/34kRetry 0: No ACK on EOT
|Transfer incomplete
| READY: press any key to continue...
+-------------------------------------------------------------+
Die Fehlermeldung ist normal, da der Cube schon neustartet bevor das Letzte ACK empfangen wurde. Ich denke du hast die falsche Firmware geflasht. Die Firmware ist deutlich größer als 34k und auch kein .hex File sondern eine .bin File.
So alles Wunderbar bis jetzt am Laufen.. auch mit Zicken (Batterietausch schafte soweit abhilfe beim Anlernen). oder auch mehrmaliges Reset der Thermostaten von Max. Wobei dann auch die Credits zu neige gehen.
Positiv ist aber das ich ohne Max Software egal welche Fimware 1.0/1.3/1.5 alle Firmware der Aktoren die Korrekte Temperatur wiedergeben, was mit der Max Software nicht der fall ist. Da musset man ja Korregieren von 0.5 bis 1 Grad, Gemessen mit einen Infrarotthermometer.
Gruß 8)
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?
Zitat von: mrbit1968 am 10 Januar 2016, 22:45:58
Hab jetzt auch schon geschaft meine Unitec Steckdosen zu steuern.
Wie sieht das aus mit einer Multiband Antenne? Weil die Reichweite ist eher Mager auf 433 MHz. Gibt da welche für 868 und 433 Mhz. bzw. für beides mit SMA Anschluss...evtl. schon jemand erfahrung gemacht mit diesen Antennen.
Und ist es nicht besser einen 2 Cube zu besorgen wegen der Lebensdauer beim umschalten. Da hab ich gelesen das ja dabei das Eprom neu geflasht wird?
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
Hallo zusammen,
hab folgendes Problem:
Hab einen MAx!Cube mit der aktuelle Firmware zu einem CUN geflasht. Feste IP vergeben und in FHEM bekannt gemacht. Funktioniert auch alles soweit allerdings scheint der Cube Komunikationsprobleme mit FHEM zu haben. Ich bekomme ständig folgende Fehlermeldung:
016.01.14 08:07:03 1: 192.168.1.2:2323 disconnected, waiting to reappear (MAXCUBE1)
2016.01.14 08:07:03 1: Error in CUL_MAX_SendQueueHandler: CUL MAXCUBE1 did not answer request for current credits. Waiting 5 seconds.
2016.01.14 08:07:08 1: 192.168.1.2:2323 reappeared (MAXCUBE1)
2016.01.14 08:07:08 3: MAXCUBE1: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.01.14 09:07:03 1: 192.168.1.2:2323 disconnected, waiting to reappear (MAXCUBE1)
2016.01.14 09:07:03 1: Error in CUL_MAX_SendQueueHandler: CUL MAXCUBE1 did not answer request for current credits. Waiting 5 seconds.
2016.01.14 09:07:08 1: 192.168.1.2:2323 reappeared (MAXCUBE1)
2016.01.14 09:07:08 3: MAXCUBE1: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
Das auslesen bzw. aktualisieren von Werte und schreiben von Befehlen an den Cube funktionert auch nur sehr sporadisch.
Ein get info über die FHEM Oberfläche meldet beim ersten Ausführen immer "No data" und die obige Fehlermedlung im Log. Bei zweiten Ausführen bekomme ich dann die Firmware Version zurück.
Selbes Verhalten habe ich auch wenn ich es direkt mit telnet und -V versuche.
Aber schon nach 1 min hab ich das selbe problem. Irgendwie so als wenn der Cube in eine Art Standby geht und nicht mehr antwortet. Das anpingen klappt jedoch problem los.
Hat jmd eine Idee woran es liegen könnte??? Hab ich evtl beim flashen noch etwas in der FW einstellen müssen ???
Ich hatte auch Probleme, eine stabile Verbindung über LAN zu bekommen. Letztlich habe ich den Cube dann doch als CUL per USB angeschlossen. Seitdem hab ich keine Probleme mehr.
Zitat von: daniel85 am 14 Januar 2016, 09:50:50
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.
Fhem läuft bei mir auf einem QNAP Nas. Dafür muss man erst treiber und kernel kompilieren. Jedoch steck ich da nicht so tief drinn und habe auch keine Lust/Zeit mich da einzuarbeiten.
Daher fällt Cul über USB wohl erstmal flach.
Mit der Firmware von Mr.Os sieht es auch nicht besser aus! Allerdings vestehe ich nicht was daran so schwer sein kann. Der Cube hängt an der zweiten Netzwerkschnittstelle und ist direkt verbunden, ohne Switch dazwischen !
Läuft das Ding denn bei anderen Störungsfrei ???? ich kann mir schwer vorstellen, dass es an der Netzwerkkonfiguration liegt.
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.
Zitat von: marty29ak am 15 Januar 2016, 21:57:39
Ich habe inzwischen drei Stück mit der aktuellen Firmware nach der Anleitung hier geflasht und auch über Netzwerk angebunden.
Bisher keine Probleme.
Liegt also sicher an was anderem.
Irgendwelche besonderen Einstellungen bzgl. des Cubes vorgenommen ??
Ich bekomme nächste Woche noch einen zweiten...mal schauen wie es mit dem aussieht
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.
Zitat von: marty29ak am 15 Januar 2016, 22:40:46
Nein eigentlich nicht, die IP bekommt der Cub von der Fritzbox per DHCP und in Fhem normal nach Anleitung definiert.
Mache noch nicht so viele Experimente da ich noch Anfänger mit Fhem bin und erst mal versuche die Anleitungen sicher um zu setzen.
setzte mal im Router das Häkchen, nicht das der sich ständig ne andere IP schnappt.
Ja das hab ich natürlich. :) Wie schon geschrieben, mit den Cubes habe ich keine Probleme.
Ist für mich eine wirklich zuverlässige, günstige und gut zu beschaffende Alternative zu den Cul oder Cun.
Würde es ja gerne machen. Aber den Cub vom Life-System nehmen geht nicht. In der Bucht gerade nachgeschaut. Nur einer, der günstig ist. Der Rest ... Da sind sogar Preise über 60 €...
Bei uns im Globusbaumarkt gab es die Heute noch für 40€. Glaube die sind noch bis Morgen im Angebot.
Ps.:Oder bei ELV als Bausatz (ist in 10Min zusammen) für ebenfalls 40€
Hm, ist noch viel, wenn ich daraus einen Pflasterstein mache...
Das Flashen ist ziemlich unkompliziert und in 10 Minuten erledigt.
Da würde ich mir keine großen Gedanken machen. Einfach genau nach der Anleitung auf Seite 1 gehen.
kann ich bestätigen beim cube. meiner wurde gerade vom postboten gebracht (gebraucht inkl versand 30€ als XAVAX green eco Max cube).
J1 mit schraubendreher überbrückt, tools aus post 1 genutzt < 5 min und der cubeCUL ist eingebunden.
allerdings muss ich sagen das der cube gegenüber gleich platziertem HM-CFG-LAN,HM-CFG-USB und selbstbauCUL die schlechteren rssi werte zeigt (getestet mit hm-fernbedienung aus ca 2m entfernung)
Zitat
rssi_at_HMLAN1 avg:-15.93 min:-21 max:-15 lst:-21 cnt:15
rssi_at_HMLAN_USB avg:-19.46 min:-25 max:-18 lst:-24 cnt:185
rssi_at_cubeCUL868 avg:-26.53 min:-33 max:-24 lst:-24.5 cnt:57
rssi_at_nanoCUL868 avg:-23.15 min:-23.5 max:-22.5 lst:-23.5 cnt:23
was muss man tun um den cul-cube mit lan zu nutzen? habe wie in post 1 die CUBe draufgeflashed. per usb läuft er aber steck ich ihn ans lan hat er keinen link (kein zeichen am switsch das ein lan-gerät dran hängt). muss ich ihm vorher per usb das lan aktivieren oder sowas?
LAN ist automatisch aktiv und wenn DHCP vorhanden ist, wird die Netzwerkadresse auch automatisch gesetzt. Du kannst ja mal versuchen, die Netzwerkadresse manuell zu setzen http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten (http://www.fhemwiki.de/wiki/CUN_Netzwerk_einrichten)
Dass der Cube eine Verbindung zum Netzwerk hat, sieht man auch daran, das D2 (INTERNET) am Cube leuchtet.
Zitat von: chris1284 am 16 Januar 2016, 15:24:34
per usb läuft er aber steck ich ihn ans lan hat er keinen link
das USB Kabel hast aber trotzdem zur Stromversorgung des Cubes dran gelassen ? denn PoE kann der Cube nicht :)
Zitat von: Wzut am 17 Januar 2016, 18:33:36
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....
Habe mir einen HM-CFG-USB-2 Stick gekauft und heute nach der Anleitung vorne umgeflasht. Vorher habe ich die Firmware noch selbst kompiliert, das hat auch geklappt, nachdem ich im Thread gelesen hatte, dass die 4.9er Toolchain nicht geht - und ich mich gewundert habe, warum der Stick nicht will... ^^ Mit der 4.8er ging es dann und der Stick meldet sich korrekt, kann mich per serieller Konsole mit ihm verbinden und auf das Kommando "V" nennt er mir seine Versionsnummer. Das funktioniert sowohl an meinem Windows-Rechner als auch am Linux-Host.
ZitatV 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.
Hi,
ich wollte meinen Cube auch flashen. Da ich MAC-User bin kann ich das SAM_BA tool leider nicht verwenden. Unter einer Windows VM und Linux VM konnte ich nach mehreren Versuchen nicht auf den CUBE zugreifen (liegt wohl an Virtual Box).
Nun habe ich den Cube an meinen Raspberry PI angeschlossen. Dort wird er auch erkannt. Soweit schon mal gut.
Kann ich den Bootloader und die Firmware dort auch mit einem anderen Tool flashen. AVRDUDE wäre eine möglichkeit aber AT91 werden darüber ja nicht unterstützt.
Hat jemand eine Idee? (...oder evtl. direkt über MAC).
Danke!!
Zitat von: mahowi am 22 Dezember 2015, 21:49:39
Ich habe ne Weile gegoogelt, welche Alternativen zu Sam-Ba es gibt. Dabei bin ich auf BOSSA (http://www.shumatech.com/web/products/bossa) gestoßen. Gibt es auch als Paket für Ubuntu oder Debian bzw. Raspbian:
bossa - Atmel SAM ARM microcontroller flash programming GUI
bossa-cli - Atmel SAM ARM microcontroller flash programming utility
Die GUI habe ich nicht getestet. Ich habe im terminal einfach die BOSSA Shell (bossash) aufgerufen. Sollte dann in etwa so aussehen:
$ bossash
Press Ctrl-D or enter "exit" to end session.
Enter "help" to display a command list.
bossa>
Dann einfach mit "scan" nach dem CUBe suchen. Dabei sollte er automatisch verbunden werden. Dann mit "write bootloader_CUBE.bin" den Bootloader schreiben. Dann "bootf true" und der CUBe bootet neu in den Bootloader. Danach kannst Du mit einem Terminalprogramm (z.B. minicom) die Firmware auf den CUBe bringen.
Hallo zusammen,
Ich habe ich jetzt auch mal drangegeben den Cube zu flashen. Es will aber nicht so richtig. Ich habe J1 überbrückt. Dann habe ich mit Bossa (auf dem Mac) den Cube mit der Firmware gefüttert. Habe auch eine korrekte Rückmeldung erhalten. Danach per Zterm die cubefw raufgespielt. Die Fortschrittsanzeige lief bis 100 %. Dann kam eine Fehlermeldung. Den Cube abgezogen und neu gestartet. Die LED leuchten nicht.
Die Prozedur habe ich jetzt schon einige Male wiederholt. Jedoch wird der Modemport nicht mehr erkannt.
In Bossa kann ich jedesmal die Firmware neu aufspielen mit Erfolgsmeldung. Stecke ich den Cube (auch mit gedrückter Taste unterhalb) jetzt ein, leuchten aber keine LED mehr. Zterm erkennt den Cube nicht mehr. In der MAC Netzwerkumgebung erscheint der Cube als "Cubeloader"
Also scheint er noch nicht "tot" zu sein. Wo mache ich denn da noch einen Fehler?
Gruß an alle Bastler.
Carsten
Update: Habe den "Cubeloader" Eintrag mal in der Übersicht gelöscht. Kommt jetzt beim Neueinstecken nicht wieder. Also ein alter Eintrag. Aber wie gesagt, kann ich die FW über Bossa immer neu aufspielen. Also muß der Cube ja irgendwie erreichbar sein.
Was mir an deiner Beschreibung aufgefallen ist: Du hast während dem Flashen den J1 überbrückt?
Dieser muss NUR am Anfang kurz gebrückt werden dann kurz das USB Kabel dran und wieder ab. Jetzt J1 entfernen und dann flashen.....
Ok, mißverständlich geschrieben. Ich hatte natürlich die Brücke vor dem Flashen wieder entfernt. Sorry
Ah ok, nutzt du ein 64bit Windows 7? Hatte damit auch Probleme den Bootloader zu flashen. Bin dann auf ein 32Bit Windows 7 ausgewichen und dort lief es dann perfekt.
Nein, ich flashe das ganze auf einem Mac. Das Programm heißt Bossa. Das flashen scheint ja auch zu funktionieren. Beim ersten Mal hatte ich sogar die blinkenden LED. Leider gab es ja den Fehler beim uploaden der CubefW. Dann habe ich die Prozeduren wiederholt. Jetzt blinken die LED nicht mehr. Aber der Flashvorgang läßt sich fehlerfrei durchführen.
Jetzt erscheint der Cube wieder mit der Bezeichnung USBModem 1421, aber der Upload klappt nicht und es blinkt auch nichts.
Mit einem MAC kann ich leider nicht weiter helfen.
Aber versuch doch mal den Cube direkt am PI zu flashen. Da soll dieses Bossa ja auch laufen....Wie ist ja weiter oben beschrieben.
@CarstenF, deine Fehlerbeschreibung liest sich wie meine Probleme damals mit dem Cube.
Fang mal an auf Seite 6 ab Posting #85 meinen Leidens und Lösungsweg zu lesen mit einer anderen Firmware von Telekatz die keinen extra Bootloader benötigt. ( letzte Version im Posting #156 , Seite 11)
Ne, klappt alles nicht. Bossa bekomme ich nicht auf den PI installiert. (Habe es auf zweien versucht, erhalte jedesmal eine Fehlermeldung)
Tot ist der Cube auf jeden Fall nicht. Am Mac wird er am USB Port noch als Device angezeigt. Egal. Leihe mir am Wochenende mal ne Windows Maschine und versuche es erneut. Trotzdem Danke erstmal.
Zitat von: CarstenF am 20 Januar 2016, 16:55:59
Ne, klappt alles nicht. Bossa bekomme ich nicht auf den PI installiert. (Habe es auf zweien versucht, erhalte jedesmal eine Fehlermeldung)
Welche Fehlermeldung bringt der PI?
Die Fehlermeldung kam hier im Board schon mal vor. Ich habe nur nichts gefunden wie es gefixt wurde. Auch im Netz habe ich nichts gefunden. Update des PI habe ich vorher gemacht.
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden gelesen.... Fertig
E: Paket bossa-cli kann nicht gefunden werden.
Das ganze stand aber in Englisch dort.
Hattest du vorher ein sudo apt-get update gemacht
Gesendet von meinem Huawei Honor 7
Ja, hatte ich gemacht....
Bleibt bei
Unable so locate package bossa-cli
Dann bau es doch selber:
Zitat von: Telekatz am 30 Dezember 2015, 18:32:36
Bossa mit sudo apt-get install bossa-cli installieren funktioniert bei mir auch nicht. Aber man kann Bossa auch selber bauen:
cd /usr/src
sudo git clone git://git.code.sf.net/p/b-o-s-s-a/code b-o-s-s-a-code
sudo apt-get install libreadline-dev wx2.8-headers libwxgtk2.8-0 libwxgtk2.8-dev
cd b-o-s-s-a-code
sudo make bin/bossash
#Starten
/usr/src/b-o-s-s-a-code/bin/bossash
Danke Telekatz,
Damit läuft Bossa jetzt auf dem PI. Habs gerade per VPN Tunnel von Unterwegs installiert. Morgen werde ich dann mal den Flashvorgang erneut anstupsen und berichten. Hoffe ich bekomme den Cube irgendwie ans laufen. Finde dieses Projekt wirklich Klasse!!!
Zitat von: dieda am 15 Januar 2016, 23:09:19
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.
Zitat von: mahowi am 19 Januar 2016, 08:10:40
Hallo, ich konnte jetzt den Cube vom Pi aus mit dem Bootloader beschreiben. Wenn ich den Cube jetzt booten will mit
"bootf true"
kommt
Boot to flash flag set to true. Was muß ich denn da machen?
Danke, Gruß Carsten
Da musst du nichts machen, da das die Bestätigung von "bootf true" ist und er beim nächsten mal vom Flash bootet.
Oh mann, ich seh schon, ich muß doch mal nen Linuxkurs in der Abendschule belegen.....
Danke. Dir. Jetzt werde ich mal schauen, das die Firmware draufkommt.
Zitat von: CarstenF am 21 Januar 2016, 14:43:52
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
Menno, ich konnte doch nur mit der Meldung nix anfangen...... ;D. Aber ist schon ok :)
So, erstmal vielen an die Entwickler dieses Projekts. Auch ich habe es hinbekommen. Ich konnte den Cube mit dem Bootloader versorgen über Bossa. Das ganze vom Mac Rechner. Allerdings konnte ich die Firmware weder vom Mac aus, noch über den PI hochladen. Hatte mit dann einen Windows Rechner (Windows 10) geliehen und dann per Tera Term geflasht. Das lief ohne Probleme. Danach blinkten zwei LED (Power blinkt langsam durchgängig, Internet ist die ganze Zeit an). Der Cube ist dann im Netzwerk zu finden und ich kann ihn per "define maxcube_868 CUL 192.168.1.59:2323 0000" in Fhem einbinden. Die ersten Schaltungen sind auch schon erfolgt. Also scheint alles zu laufen.
Hat mal wieder totalen Spaß gemacht, so ein Projekt umzusetzen. Dieses Board ist einfach der Hammer!!!
Danke für die SW! Ich habe sie auf einem HM-CFG-USB-2 im Einsatz, läuft seit 24 h ohne Aussetzer an FHEM auf raspi.
Zum flashen habe ich vier Anläufe gebraucht, wahrscheinlich wegen der winzigen Jumperfelder und meiner dicken Finger...
Ich habe einen 9 kOhm-Widerstand eingesetzt, der hatte dickeren Draht als der 10er, den ich gefunden habe. Hat auch funktioniert.
Läuft bei mir als Homematic.
Gruß, Bernd
Wenn ich den Cube (CUNO) mit dem Somfy Modul anspreche gehen alle LED´s aus was er ja normal nicht macht. Normal geht die Power LED ja kurz an für einen Sendecommando. ? Funktioniert bzw ist das Gerät nicht in der Firmware ?
Gruß
Zitat von: mrbit1968 am 28 Januar 2016, 16:45:19
Wenn ich den Cube (CUNO) mit dem Somfy Modul anspreche gehen alle LED´s aus was er ja normal nicht macht. Normal geht die Power LED ja kurz an für einen Sendecommando. ? Funktioniert bzw ist das Gerät nicht in der Firmware ?
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.
Zitat von: Wzut am 17 Dezember 2015, 17:28:16
@Telekatz , Joachim hat ja in Antwort #49 die Pinbelegung des ST2 gepostet, ist diese serielle Schnittstelle am ST2 nur im Debugmodus aktiv oder sind die Ein/Ausgaben im laufenden Betrieb identisch mit denen am USB Port ?
Hintergrund : die vier Pins schreien direkt danach einen ESP8266-01 aufzustecken und den Cube damit zum Wireless Cube zu machen :)
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.
Zitat von: Telekatz am 28 Januar 2016, 21:59:22
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 ?
Es wird automatisch erkannt, das der Cube an einem Host angeschlossen ist. Wenn der Cube nur an einem USB Netzteil hängt ist die Ausgabe auf ST1 aktiv.
Falls notwendig könnte man aber auch einen Befehl einbauen, dass sobald ein bestimmter Befehl über ST1 empfangen wird, die USB Verbindung manuell getrennt wird und die Ausgabe an ST1 übergeben wird.
Nabend zusammen,
meinen hm-usb habe ich wie in Post#1 beschrieben bearbeitet. Das Ergebnis aktuell ist, die LED ist an, Linux erkennt aber kein Gerät.
Ausgabe von dmesg:
[1135772.654015] usb 4-2: device descriptor read/64, error -71
[1135772.868021] usb 4-2: device descriptor read/64, error -71
[1135773.071016] usb 4-2: new full-speed USB device number 10 using uhci_hcd
[1135773.185017] usb 4-2: device descriptor read/64, error -71
[1135773.400016] usb 4-2: device descriptor read/64, error -71
[1135773.603015] usb 4-2: new full-speed USB device number 11 using uhci_hcd
[1135774.013019] usb 4-2: device not accepting address 11, error -71
[1135774.115018] usb 4-2: new full-speed USB device number 12 using uhci_hcd
[1135774.525015] usb 4-2: device not accepting address 12, error -71
[1135774.525079] usb usb4-port2: unable to enumerate USB device
Ist das Teil jetzt kaputt?
Direkt angeschlossen oder über USB Hub?
Gesendet von meinem Huawei Honor 7
Direkt angeschlossen, hatte aber auch schon das Kabel versucht.
---
Tony
Zitat von: tboston am 02 Februar 2016, 23:46:04
Nabend zusammen,
meinen hm-usb habe ich wie in Post#1 beschrieben bearbeitet. Das Ergebnis aktuell ist, die LED ist an, Linux erkennt aber kein Gerät.
Ausgabe von dmesg:
[1135772.654015] usb 4-2: device descriptor read/64, error -71
[1135772.868021] usb 4-2: device descriptor read/64, error -71
[1135773.071016] usb 4-2: new full-speed USB device number 10 using uhci_hcd
[1135773.185017] usb 4-2: device descriptor read/64, error -71
[1135773.400016] usb 4-2: device descriptor read/64, error -71
[1135773.603015] usb 4-2: new full-speed USB device number 11 using uhci_hcd
[1135774.013019] usb 4-2: device not accepting address 11, error -71
[1135774.115018] usb 4-2: new full-speed USB device number 12 using uhci_hcd
[1135774.525015] usb 4-2: device not accepting address 12, error -71
[1135774.525079] usb usb4-port2: unable to enumerate USB device
Ist das Teil jetzt kaputt?
Wie weit hat es nach Anleitung noch funktioniert? Konntest du den Bootloader noch laden?
Hi,
den Bootloader konnte ich nicht flashen. Hatte auch erst v3.0 sa-mba versucht, die erwartete aber Argumente wo ich nicht wusste welche...
Ist es eventuell wichtig, dass ich da eine andere Firmware drauf hatte vorher? Siehe hier: http://forum.fhem.de/index.php/topic,13071.0.html
Die Firmware, die vorher drauf war, ist egal. Die wird durch das setzen von J2 sowieso gelöscht.
Hast du danach mit J1 den internen SAM-BA Bootloader geladen und anschließend auch den 10k Ohm Widerstand beim erneuten Einstecken mit verbunden?
bis zu Schritt J1 überbrücken bin ich gekommen ja. Einen 10k Ohm Widerstand habe ich nicht. Der nächste schritt war ja sa-mba starten. Da passierte aber nix, da der Stick nicht gefunden wurde.
Wenn nach dem Schritt mit J1 der Stick nicht gefunden wird war der nächste Schritt den 10k Ohm Widerstand zu verwenden.
Zitat von: Telekatz am 03 Februar 2016, 17:44:23
Wenn nach dem Schritt mit J1 der Stick nicht gefunden wird war der nächste Schritt den 10k Ohm Widerstand zu verwenden.
Sowas habe ich leider nicht. Gibt noch nen anderen Weg?
---
Tony
Es kann auch ein 1k Ohm Widerstand sein. Oder jeder beliebige Wert dazwischen. Aber ein Widerstand muss da rein.
Verstehe, da ich mich mit sowas leider nicht auskenne, bleibt das Gerät nun wohl tot :(
---
Tony
Es würde auch funktionieren, wenn man die richtigen zwei Pins am µC mit einer spitzen Nadel Überbrückt. Ich hab die entsprechende Stelle mal auf dem Foto markiert. Man muss den zweiten mit dem dritten Pin an der markierten Stelle überbrücken (während des gesamten SAM-BA Flashvorgangs).
Die Chance mit dieser Methode den Stick wirklich zu töten ist hier natürlich größer als mit der Widerstandsmethode. Insbesondere für Grobmotoriker.
Danke für die Mühe, ich denke aber ich zähle zu den Grobmotorikern. Mir hat jemand aus dem Forum angeboten, den Stick zu löten. Ich denke darauf werde ich zurückkommen und dann wieder ein hmlan draus bauen. Habe mir gestern noch einen CUL868 bestellt der hoffentlich diese Woche noch kommt.
Danke euch!
Was für einen Widerstand brauche ich da genau?
z.B. so einen:
http://www.reichelt.de/1-4W-5-10-k-Ohm-91-k-Ohm/1-4W-10K/3/index.html?&ACTION=3&LA=2&ARTICLE=1338&GROUPID=3066&artnr=1%2F4W+10K (http://www.reichelt.de/1-4W-5-10-k-Ohm-91-k-Ohm/1-4W-10K/3/index.html?&ACTION=3&LA=2&ARTICLE=1338&GROUPID=3066&artnr=1%2F4W+10K)
siehe auch:
http://forum.fhem.de/index.php/topic,38404.msg344668.html#msg344668 (http://forum.fhem.de/index.php/topic,38404.msg344668.html#msg344668)
Guten Morgen,
da ich mir nun den CUL868 zugelegt habe, würde ich gerne den hmusb wieder mit der FW von hier http://forum.fhem.de/index.php/topic,13071.0.html betreiben.
Ist das noch möglich?
Weiter würde mich interessieren ob es Sinn machen würde den 10kOhm Widerstand anzulöten oder nur zum flashen jetzt dranstecken?
Grüße
das ist keine firmware sondern nur hmland welches quasi ein stück software ist welches sich mit der (bei dir wohl nun nicht mehr vorhandenen) original firmware "unterhält"
siehe post 1 den du dir vor dem flashen natürlich durchgelesen hast:
Achtung: Die original Firmware ist danach weg und kann auch nicht wiederhergestellt werden, da keine unverschlüsselte Version davon verfügbar ist!
Ja habe ich durch gelesen. Dann kommt also nur a-culfw in Frage, was ja auch Homematic kann.
---
Tony
Zitat von: tboston am 05 Februar 2016, 07:14:29
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.
Kann mir jemand sagen wie ich das andere Stück Plastik noch lösen kann?
Du musst die beiden Plastiknasen, die durch die Befestigungslöcher der Platine gehen, mit einem scharfen Messer bündig mit der Platineoberseite abschneiden.
Also, der Widerstand ist drin, Stick wird aber nicht erkannt, jedenfalls via 'dmesg'.
Wer von den Linux'ern hier kann mir sagen wie er das mit sam_ba angestellt hat?
Der Widerstand hat nicht immer zuverlässig Kontakt zu den Anschlüssen vom USB Stecker wenn er gesteckt wird. Drücke ein bisschen am Widerstand , damit seine Drähte besser gegen die die Kontakte des USB Steckers gedrückt werden.
Okay, hat scheinbar funktioniert. Ich weiß dennoch nciht was ich nun mit sam-ba tun soll :(
Sam-ba brauchst du nur, um den neuen Bootloader auf den Stick zu kriegen. Wenn das erledigt ist, brauchst du künftig nur noch eine Terminalsoftware, die Xmodem kann. Wenn der Bootloader mal drauf ist, kannst den aktivieren (wie das bei dem Stick geht, weiß ich nicht - bei nem CUL oder nem Maxcube gibts dafür dann nen Taster - den hält man gedrückt und steckt das Ding am USB-Port ein, dann meldet es sich als Serial Port am OS, auf den man dann das Terminalprogramm verbindet), dann via Xmodem die Firmware auf diesen Port geschubst - fertig.
Okay, ich weiß aber leider nicht wie ich per sam-ba den bootloader der aufschieben kann
---
Tony
Äh - um Missverständnissen vorzubeugen - soweit ich weiß, geht das mit Xmodem "nur" bei den Teilen mit dem Bootloader aus diesem Fred. :)
Habs nur unter Windows gemacht lt Anleitung am Anfang dieses Theads - unter Linux gabs aber doch auch eine?
Such mal hier im Thread nach Antworten von mir. Ich hab mit bossash den Bootloader installiert. Damit ist es ganz einfach.
Hallo zusammen,
ich wollte mir die Dateien herunterladen. Das Verzeichnis ist bei mir aber leer.
Mache ich da etwas falsch, oder muss man sich bei mediafire registrieren (was bei mir irgendwie nicht funktioniert)
"Firmware flashen :
Die kompilierten Bin Dateien findet Ihr unter https://www.mediafire.com/folder/tf16radvztfd9/a-culfw "
Der Cube liegt noch versiegelt auf dem Tisch und Sam-ba 3 wartet schon in meinem Home Verzeichnis
Soweit ich das als Anfänger alles verstanden habe, bringt die alternative Firmware mehr und läuft wohl auch stabiler als die Originale.
Media fire muss man sich nicht anmelden. Leer ist es auch nicht
Gesendet von meinem Huawei Honor 7
So siehts bei mir im Browser aus.
Win 7 - Firefox 43.0.4 - Scripte erlaubt, ABP für die Seite deaktiviert.
Unter Ubuntu das gleiche Bild.
Das Problem hatte ich komischerweise auf meinem Windows 7 Notebook (mit Chrome) auch, auf meinem Mac (mit Chrome) wurden alle Datei angezeigt.
Keine Ahnung warum.
Hallo an die Runde,
ich würde gerne nochmal das Thema "Mehrere Cubes via USB" nach vorne holen. Habe ich richtig verstanden, dass dafür die Firmware mit Toolchain und angepasster Device ID neu kompiliert werden muss? Möchte einen zweiten (vorhandenen) Max! Cube gerne für LaCrosse verwenden (Ziel: die TX Temparatursensoren auszulesen zur Steuerung eines Stellantriebs der Fußbodenheizung via Max! Zwischenstecker) und den zweiten Cube ebenfalls über USB einbinden. Würde mich sehr über Tipps freuen.
tatsu
Hi Tatsu,
wenn du zwei oder mehrere CUBEs via usb und FHEM nutzen möchtest. Muss jeder CUBE eine eindeutige USB-Id haben.
Sonst hast du das Problem, das du die CUBEs nicht eindeutig addressieren kannst.
Die nötige Änderung habe ich hier http://forum.fhem.de/index.php/topic,38404.msg366448.html#msg366448 (http://forum.fhem.de/index.php/topic,38404.msg366448.html#msg366448) beschrieben.
Solltest du Fragen haben, helfe ich gerne ;)
Grüße,
Stephan
Anstatt die CDCDSerialDriverDescriptors.c zu ändern kannst du einen unterschiedliche USB-ID auch in der board.h (zeile 31) einstellen:
#define USB_DESCRIPTOR_SN '1'
Einfach die 1 durch ein anderes Zeichen erstetzen.
Zitat von: Telekatz am 10 Februar 2016, 10:34:02
Anstatt die CDCDSerialDriverDescriptors.c zu ändern kannst du einen unterschiedliche USB-ID auch in der board.h (zeile 31) einstellen:
#define USB_DESCRIPTOR_SN '1'
Einfach die 1 durch ein anderes Zeichen erstetzen.
:o Das wäre ja zu einfach :o
Frag mal, wie lange ich nach dem anderen gesucht habe bis es bei mir lief ;)
Hi,
Habe nun schon ein paar mal diese Meldung bekommen beim Versuch upzudaten:
ZitatWillkommen 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.
Zitatccconf freq:433.920MHz bWidth:464KHz rAmpl:42dB sens:4dB
Wenn ich in das Eventlog gehe sehe meist genau einmal einen Befehl nachdem der Cube Strom bekommen hat. Egal wieviele Tasten ich auf dem Sender drücke.
Er hat mir einen neuen Raum "IT" mit genau einem Gerät angelegt. Egal wieviele Tasten von verschiedenen Geräten ich drücke.
(Steckdosen sind z.B. diese: http://www.pollin.de/shop/dt/MzMzOTQ0OTk-/Haustechnik/Funkschaltsysteme/Funksteckdosen_Set_mit_3_Steckdosen.html )
Wie schon ein paarmal hier im Thread beschrieben ist die Meldung von minicom normal. Die Übertragung ist abgeschlossen und der Arduino bootet schon neu, während minicom noch auf eine Bestätigung wartet.
Danke, das bedeutet, die Firmware ist OK. Empfang von 433 MHz Funksteckdosen Signalen & co klappt trotzdem nicht. (1 oder 10m Entfernung)
Hätte mir jemand nen Tipp ob das so passt ?
(Man sieht: Zwei Codes wurden erkannt. Vier waren mehrfach ohne andere Störsignale in der Luft in kurzem Abstand)
Zitatdefine 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
Vllt ein itclock Thema oder?
Gesendet von meinem Huawei Honor 7
Vllt ein itclock Thema oder?
Gesendet von meinem Huawei Honor 7
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.
Zitat von: ranseyer am 20 Februar 2016, 08:43:41
Hmmm. Habe einiges hin und herprobiert. Mit itclock 400 kann ich meine Steckdosen zuverlässig schalten. Empfangen tut es diese trotzdem nur extrem selten und wenn dann nur die erste Aussendung nachdem der Cube gestartet wurde.
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.
Hi, ich habe das fertige Binary genommen.
Soll ich mal selbst kompilieren ?
Hallo,
vielen Dank für den Einblick. Habe nun die 29 Seiten gelesen.
Habe noch ein paar Fragen zum Verständnis:
1.Zu den möglichen Modi
Es ist ja der Max und Homematic modus möglich.
Ist beim Max Modi die Max Software (auf dem PC) weiter nutzbar?
Oder geht die Steuerung nur über FHEM auf z.B. Rasperry Pi
Würde auch die Einbindung des Cun lediglich in meinem Handy möglich sein?
Vielen Dank
Die Max Software kann danach nicht mehr verwendet werden. Die Steuerung des Cube funktioniert dann nur noch über FHEM.
Zitat von: Snop007 am 24 Februar 2016, 13:05:26
Würde auch die Einbindung des Cun lediglich in meinem Handy möglich sein?
Nein.
Ok, vielen Dank.
hat jemand Erfhrungen mit der Synology Diskstation 213j und der Beta, was FHEM angeht?
Oder ist es grundsätzlich sinnvoller ein Rasperry Pi für FHEM zu nutzen, wo dann der "MAX-Cube/CUN" angeschlossen wird.
Nutze gerade für ein Ambilightnachbau Openelec auf einem Rasperry. Nach Recherchen habe ich jedoch nichts finden können, wie ich da dann noch FHEM drauf bekomme --> Sprich ob das geht. Weiß das Jemand, oder hat es auch in dieser Kombination im Einsatz?
Openelec ist eigentlich rein auf Kodi ausgelegt und hat kein Paketmanagement. Du müsstest also alle benötigten Programme und Libs "zu Fuß" installieren.
Einfacher wäre es dann wahrscheinlich, auf Raspbian zu setzen und Kodi darauf zu installieren.
Zitat von: Snop007 am 26 Februar 2016, 12:18:10
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
Wie bekomme ich denn den Cul-Cube über Lan Fhem verbunden...
Im Wiki habe ich nur etwas über usb gefunden.
@schmello
Ich habe meinen so angeleldet....
define CUL1_LAN CUL 192.xxx.yyy.zzz:2323 1034
Gesendet von iPad mit Tapatalk
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
Hallo zusammen,
ich bräuchte mal Eure Hilfe. Ich habe es letztendlich geschafft, meinen Cube über Bananian mit dem Bootloader zu füttern. Jetzt versuche ich vergeblich die Firmware aufzuspielen. Ente Windows habe ich keinen Erfolg, mit minicom komme ich nicht klar und bei ZTerm unter Mac OS reagiert der Cube ABER es kommt folgende Fehlermeldung:
CUBELOADER V1.01
### Error: 6 in SerGetBuf
### Send (x) CUBE_BL.bin: 93696 bytes, 1:13 elapsed, 1270 cps, 33%
Habe mal versucht den Cube anzuschließen. Zwei LEDS leuchten dauerhaft, eine blinkt...
Leider bekomme ich keine Verbindung zum Cube. Weder über die Fritzbox oder über FHEM oder sonst wie??
Hätte jemand vielleicht eine Idee was ich machen kann?
Vielen Dank an Euch!
LG Thommy
Hast du es schon mal mit Tera Term unter Windows ausprobiert?
Zitat von: Telekatz am 08 März 2016, 20:15:46
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
LAN und USB könne gleichzeitig verwendet werden. Da wird nichts bevorzugt.
Ich bin jetzt echt am verzweifeln... :-\
Ich habe die halbe Nacht damit verbracht und habe versucht Firmware auf den Cube zu bringen.
Alles wie bisher beschrieben:
Windows 7 wird der Cubeloader erkannt und nach ein wenig gefrickel habe ich da einen ComPort mit a91 to serial, dann mit TeraTerm das bin File hochgeladen. Battery und Internet leuchten durchgehend, Power blinkt. Aber ich finde den Cube nicht im Netzt. Die Fritze zeigt nur an das was in Lan2 steckt aber keine Ip oder Sonstiges...
MacOs mit ZTerm erkennt den Cubeloader, lädt die Bin hoch und spuckt am Ende nur den o.g. Fehler aus...
Jetzt habe ich Linux Mint unter Virtualbox versucht, da spuckt minicom immer nur den Fehler aus : Fehler bitte Taste drücken. Der Cubeloader wird aber ohne Probleme erkannt
Ich wäre so dankbar wenn mir einer helfen könnte? Notfalls würde ich den Cube auch jemanden zuschicken inkl. Rückporto...
LG Thoma
Zitat von: ThommyTom am 09 März 2016, 09:24:47
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)
Oh freude, oh freude!
Ich habe es geschafft den Cube über USB anzusprechen! :D :D
Danke Telekatz, ich werde jetzt mal deinen Link anschauen und es weiter versuchen!!!
lg Thommy
Zitat von: Telekatz am 10 Februar 2016, 10:34:02
Anstatt die CDCDSerialDriverDescriptors.c zu ändern kannst du einen unterschiedliche USB-ID auch in der board.h (zeile 31) einstellen:
#define USB_DESCRIPTOR_SN '1'
Einfach die 1 durch ein anderes Zeichen erstetzen.
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?
Welche Version der Toolchain? Welches make target hast du erzeugt?
Ich benutze die Toolchain gcc-arm-none-eabi-5_2-2015q4-20151219-win32.exe und will nur für den CUBe das File erzeugen, dazu habe ich make im CUBe Verzeichnis gestartet.
Nimm mal die Version 4.8 der Toolchain, die im Eröffnungspost auch verlinkt ist.
Welche der erzeugten Dateien hast du danach geflasht? CUBE.bin oder CUBE_BL.bin?
Bei mir wird nur eine CUBE_BL.bin erstellt, welche ich auch geflasht habe. Jedenfalls mit der 4.8 geht es jetzt, vielen DANK!
Zitat von: cdn am 08 März 2016, 19:09:59
Ist es auch möglich den Stick als RFR zu nutzen? Ich habe es probiert nur leider ist es nicht möglich den raw entsprechend zu ändern wie hier beschrieben:
http://fhemwiki.de/wiki/RFR_CUL
Hmm ist das vielleicht untergegangen? Oder hat keiner eine Idee?
Die RF Router Funktion habe ich mal auskommentiert, weil sie bei meinem Cube Probleme beim Betrieb mit mehreren Transceivermodulen verursacht hat. Das war einfacher, als dem Problem auf den Grund zu gehen. Aber prinzipiell müsste die Router Funktion funktionieren, wenn man sie in der board.h wieder aktiviert. Getestet hab ich die Funktion allerdings nie.
Habe jetzt den zweiten CUBE geflasht in der Hoffnung, ihn als CUN im RAW Modus für Lacrosse Sensorik verwenden zu können. Ich habe verstanden, dass ich ihn dafür in den RAW Mode mit z.B. 'SET CUN_0 RAW Nr1' versetzen muss. Siehe dazu auch https://forum.fhem.de/index.php?topic=36565 (https://forum.fhem.de/index.php?topic=36565).
Allerdings verabschiedet sich der CUBE (V 1.20.06 a-culfw Build: 199) dann kurz darauf mit folgendem Logeintrag:
2016.03.16 16:23:34 3: set CUN_0 raw Nr1
2016.03.16 16:24:00 1: 192.168.1.9:2323 disconnected, waiting to reappear (CUN_0)
2016.03.16 16:24:00 1: 192.168.1.9:2323 reappeared (CUN_0)
2016.03.16 16:24:00 3: CUN_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
Das passiert auch mit meinem zweiten CUBE (V 1.20.01 a-culfw Build: 176, via USB):
2016.03.16 16:38:28 3: set CUL_0 raw Nr2
2016.03.16 16:38:30 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.03.16 16:38:31 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.03.16 16:38:31 1: /dev/ttyACM0 reappeared (CUL_0)
Stehe ich gerade auf der Leitung bzw. hat jemand eine Idee was da schief geht? Ich hatte gehofft, dass ich dafür nicht extra einen Jeelink Stick kaufen muss.
Ich würde natürlich ggf. mit #define LACROSSE_HMS_EMU u. lacrosse.c im Makefile etc. neu kompilieren, aber mit dem SET RAW (also RFNATIVE) sollte ich doch trotzdem ein Datenpaket vom Sensor im Logfile sehen statt der Disconnects - oder sehe ich das falsch?
Danke für jeden Tipp!
Mach mal folgende Änderung in rf_native.c, dann sollte es funktionieren:
diff --git a/culfw/clib/rf_native.c b/culfw/clib/rf_native.c
index 3f973c0..9e308c2 100644
--- a/culfw/clib/rf_native.c
+++ b/culfw/clib/rf_native.c
@@ -219,13 +219,13 @@
void native_func(char *in) {
- uint8_t mode = 0;
+ uint16_t mode = 0;
if(in[1] == 'r') { // Reception on
// "Er<x>" - where <x> is mode
if (in[2])
- fromdec(in+2, &mode);
+ fromdec(in+2, (uint8_t *)&mode);
if (!mode || mode>MAX_MODES) {
DS_P(PSTR("specify valid mode number\r\n"));
Zitat von: Telekatz am 16 März 2016, 22:15:18
Mach mal folgende Änderung in rf_native.c, dann sollte es funktionieren:
Wow das ging ja fix,danke erstmal :) Habs nur kurz testen können, aber scheint geholfen zu haben. Bisher kein Disconnect mehr
und ich sehe jetzt auch die Einträge die ich erwartet hätte:
2016.03.16 22:38:19 2: CUN_0: unknown message N019C45956A1CAAAA0000975273
2016.03.16 22:38:28 2: CUN_0: unknown message N019C45956A1CAAAA0000E5A23B
2016.03.16 22:38:37 2: CUN_0: unknown message N019C45956A1CAAAA00004DAC9F
2016.03.16 22:38:45 2: CUN_0: unknown message N019C45956A1CAAAA00003D8F76
Ich würde als nächstes den LACROSSE_HMS_EMU mit reinnehmen, muss ich dabei auch etwas beachten (andere Protkolle raus wg. Speicherplatz o.ä.) ?
Danke & Gruß
Tatsu
Speicherplatz ist beim Cube noch genügend vorhanden. Da muss man nichts raus nehmen.
Hat funktioniert :) Ein Lacrosse Temperatursensor (TX29-IT) ist nach 'SET RAW Nr1' direkt mit Autocreate als HMS Device erkannt worden und liefert seitdem alle 10 Sekunden neue Werte. Also genau das, was ich mir erhofft hatte. Jetzt komme ich dem Ziel, meine Fußbodenheizung mit Max Zwischenstecker zu schalten anhand der Lacrosse Temparaturwerte wieder ein Stückchen näher.
Bei der Gelegenheit habe ich auch gleich eine andere USB ID mitkompiliert, warum ich mich ja sowieso noch mit der Toolchain beschäftigen wollte. Meine "make" Zeiten waren schon eine ganze Weile her ;-)
Danke nochmal Telekatz!
Ich versuche jetzt nur noch verzweifelt diese 'unknown message' Einträge wegzukriegen. Obwohl die Sensoren mit dem HMS Lacrosse Emulator eingebunden sind und im RAW Mode auch Readings erzeugt und protkolliert werden, bleiben die Unknown Einträge erhalten. Anfangs dachte ich mir noch nichts weiter dabei, aber seit dem zweiten Sensor habe ich jetzt alle paar Sekunden gleich zwei Einträge und das fhem Log wird förmlich zugemüllt damit. Mit weiteren Sensoren würde es die ja dann noch vervielfachen. Kann ich das auch irgendwie (in der a-culfw?) unterdrücken?
set CUN_0 verbose 0
Zitat von: Telekatz am 19 März 2016, 12:40:38
set CUN_0 verbose 0
Super, danke! Da merke ich immer, wie sehr ich noch Anfänger bin. Danke für die Geduld :)
Ich habe einen HMUSB der mit hmland nicht mehr funktioniert habe. Ich wollte nun diese FW aufspielen, in der Hoffnung, dass ich den HMUSB wieder zum laufen bekomme. Ich hab die Jumper gesetzt und letztlich den Pull-UP Wiederstand verbunden. Im Geräte-Manager erhalte ich unter USB-Controller ein
Unbekanntes USB-Gerät (Fehler beim Anfordern einer Gerätebeschreibung.)
Habt ihr eine Idee, was bzw. ob ich hier noch was machen kann?
Grüße
Fabian
Hast du die Jumper auch wieder entfernt?
Hast du den Widerstand nur in den USB Stecker geschoben, oder ihn auch gegen die Kontakte gedrückt, damit er sicher Kontakt hat?
Alternativ lässt sich der Bootloader auch über die serielle Debugschnittstelle ST1 aufspielen. Die Belegung von ST1 ist die Gleiche, wie beim Cube.
hab den widerstand sogar dran gelötet, jumper sind sicher gelöst (habs sogar nachgemessen).
Gibts es dazu eine Anleitung, wie ich die FW direkt aufspielen kann?
Du brauchst dazu einen RS232 zu TTL oder USB zu TTL Schnittstellenadapter. Dessen Ausgang wird mit ST1 verbunden (GND mit GND, TXD mit RXD und RXD mit TXD). Die Belegung von ST1 ist Pin1:3,3V, Pin2:TXD, Pin3:RXD und Pin4:GND. In SAM-BA wählst du dann den COM Port des Schnittstellenadapers aus.
Einmal konnte ich connecten, aber leider liefert er nun can't connect to at91sam7s128-ek - Das war es dann wohl - Ich hab aber sowieso die Vermutung, das irgendwas Hardware-Technisch nicht einwandfrei ist. Dennoch danke - vielleicht bekomm ich ja nochmal einen MAX Cube oder HMUSB in die Hand an dem ich das ganze erfolgreich austesten kann.
Grüße
Fabian
Hallo zusammen,
bin relativ neu in dem Thema und bräuchte etwas Hilfe. Ich habe einen Cube geflasht, jedoch weiß ich nicht so ganz ob ich alles richtig gemacht habe. Von meinem eigenen empfinden her scheint es geklappt zu haben, aber irgendwie scheinen die Settings in FHEM nicht ganz richtig zu sein. Zu sehen im Anhang.
Die Definition in FHEM ist folgende:
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456
attr cm IODev CUL0
Vielleicht kann mir ja jemand helfen.
Danke und Gruß
Chris
Zitat von: rainstormer am 27 März 2016, 21:43:01
Hallo zusammen,
bin relativ neu in dem Thema und bräuchte etwas Hilfe. Ich habe einen Cube geflasht, jedoch weiß ich nicht so ganz ob ich alles richtig gemacht habe. Von meinem eigenen empfinden her scheint es geklappt zu haben, aber irgendwie scheinen die Settings in FHEM nicht ganz richtig zu sein. Zu sehen im Anhang.
Die Definition 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.
Zitat von: Tatsu am 28 März 2016, 00:13:48
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
Zitat von: rainstormer am 28 März 2016, 09:33:33
Hey, erstmal danke für die Antwort. Bin mir nicht ganz sicher wie ich erkennen kann ob die Firmware korrekt installiert wurde.
Habe jetzt nocheinmal geflashed und das Log im SAM-BA sieht so aus:
loading history file ... 0 events added
SAM-BA console display active (Tcl8.5.9 / Tk8.5.9)
(sam-ba_2.16) 1 %
(sam-ba_2.16) 1 % send_file {Flash} "C:/Users/Chris/Desktop/bootloader_CUBE.bin" 0x100000 0
-I- Send File C:/Users/Chris/Desktop/bootloader_CUBE.bin at address 0x100000
first_sector 0 last_sector 0
-I- Writing: 0x3AC0 bytes at 0x0 (buffer addr : 0x202A24)
-I- 0x3AC0 bytes written by applet
Do not lock
(sam-ba_2.16) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.16) 1 %
Ist das soweit korrekt? Das FHEM-Log kann ich heute Abend mal nachschauen.
Sieht korrekt aus.
@rainstormer
Ist zwar schon länger her bei mir....
Hast du den manuell angelegt oder ist der automatisch angelegt worden?
Hat anfangs auch ein wenig Probleme beim anlegen.
Lösche ggf mal die Definition, abziehen und einstecken vom Stick und dann mal denn Stick über USB create hieß es glaube ich erkennen (Befehl weiß ich nicht mehr ganz genau, ü d nicht vor Ort zum nachsehen.....)
stenny
Gesendet von meinem HTC One_M8 mit Tapatalk
Ok, also das FHEM-Log sagt folgendes:
2016.03.28 15:56:28 1: Including fhem.cfg
2016.03.28 15:56:28 3: telnetPort: port 7072 opened
2016.03.28 15:56:28 3: WEB: port 8083 opened
2016.03.28 15:56:28 3: WEBphone: port 8084 opened
2016.03.28 15:56:28 3: WEBtablet: port 8085 opened
2016.03.28 15:56:28 3: Opening CUL0 device /dev/ttyACM0
2016.03.28 15:56:29 3: Setting CUL0 serial parameters to 9600,8,N,1
2016.03.28 15:56:29 3: CUL0 device opened
2016.03.28 15:56:42 1: Cannot init /dev/ttyACM0, ignoring it (CUL0)
2016.03.28 15:56:42 2: Switched CUL0 rfmode to MAX
2016.03.28 15:56:42 1: CUL_MAX_Check: No IODev has no VERSION
2016.03.28 15:56:42 3: CUL_MAX_Check: Detected firmware version 0 of the CUL-compatible IODev
2016.03.28 15:56:44 2: eventTypes: loaded 581 events from ./log/eventTypes.txt
2016.03.28 15:56:44 3: HUEDevice1: I/O device is hueBridge1
2016.03.28 15:56:44 3: HUEGroup0: I/O device is hueBridge1
2016.03.28 15:56:44 1: Including ./log/fhem.save
2016.03.28 15:56:44 0: Featurelevel: 5.7
2016.03.28 15:56:44 0: Server started with 25 defined entities (fhem.pl:11109/2016-03-21 perl:5.014002 os:linux user:fhem pid:8743)
Kann das eventuell ein Berechtigungsproblem sein? Oder liegt es vielleicht an der Version der Datei? Genommen habe ich a-culfw_1.20.06_build_208_master.zip
Gruß
Chris
Zitat von: rainstormer am 28 März 2016, 16:02:06
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?
Zitat von: Tatsu am 28 März 2016, 18:44:10
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 ;)
Zitat von: rainstormer am 28 März 2016, 21:16:01
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:)
Hallo,
ich hätte da auch mal drei Frage zu culfw@ARM.
Ich habe bereits einen Cube (nutze ich erfolgreich mit ser2net) und einen HM-CFG-USB-2 erfolgreich mit Windows geflasht, jedoch nutze ich normalweise kein Windows sondern einen MAC und diverse Linux Server.
Frage1: Ist es möglich die Firmware auch unter Linux (zur Not auch unter MAC) zu flashen, bzw. direkt aus FHEM?
Frage2: Es kommen ja immer wieder Updates der Software, sollte man dabei auch immer den Bootloader (bootloader_HM_CFG.bin, bootloader_CUBE.bin) aktualisieren oder ist es ausreichend NUR die Culfw Firmware (HM_CFG_BL.bin, CUBE_BL.bin) zu aktualisiert, weil der Bootloader nur einmal initial benötigt wird?
Frage3: für die Anbindung von TX 29 DTH Sensoren wird normal der JeeLink empfohlen, seit 1.05 kann jedoch auch culfw@ARM LaCrosse Sensoren empfangen, was würdet ihr heute empfehlen?
Zu Frage 1:
Als Alternative zu SAM-BA gibt es unter Linux BOSSA: https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455 (https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455)
Anleitung zum flashen der Firmware unter Linux: https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429 (https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429)
Zu Frage 2:
Den Bootloader muss man nur einmal flashen. Wäre ja sonst unnütz weil man dann gleich eine Version ohne Bootloader flashen könnte.
Zu Frage 3:
Kann ich nichts dazu sagen, verwende keine LaCrosse Sensoren.
Hallo,
erst mal vielen Dank an Telekatz für die Portierung der Firmware! Das Flashen verlief einwandfrei, mein CUBE werkelt nun seit einigen Tagen unter FHEM über LAN (Firmware V 1.20.06 a-culfw Build:208).
Nun zu meinem 'Problem': Ich steuere unter anderem 5 Stück FHT80b an. Setze ich nun bei allen z.B. die Temperatur auf 20.0 C°, klappt dies auch einwandfrei. Allerdings verbleiben im FHT Buffer des CUBE zumeist Telegramme von 1-2 FHTs (telnet: T02), obwohl die betreffenden FHTs die Temperaturänderung längst übernommen haben. Laut RSSI Wert in FHEM ist der Empfang von allen FHTs ausgezeichnet, auch die Batterien in allen FHTs sind neu. Die Telegramme verschwinden auch nach Stunden nicht aus dem Buffer. Es scheint dass die FHTs entweder keine Quittierung an den CUBE senden oder der CUBE diese nicht korrekt interpretiert. Komplett verwirrend ist, dass die FHTs die Änderungen ja korrekt übernehmen und nicht immer dieselben FHTs betroffen sind.
Hat jemand von Euch ein ähnliches Problem? Ich bin mit meinem Latein am Ende und überlege schon jede Nacht einfach mit 'set CUBE1 raw T011234' den FHT Buffer zu löschen oder auf die wesentlich weniger kapriziösen MAX Heizungsregler umzustellen.
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.
ZitatVielleicht gibt es dafür aber auch schon eine Lösung
Ein notify auf global:INITIALIZED sollte helfen
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"
Zitat von: chris1284 am 03 April 2016, 18:23:13
reicht es für die sensoren den cul in raw mode (befehl?) zu setzen und die sensoren kommen per autocreate? bitte um info zu cul in raw als jeelink "ersatz"
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 :)
auf das thema bin ich auch gestoßen. aber so recht passt die anleitung nicht wie man in der aculf diese funktion aktiviert
EDIT: habs gefunden
board.h:
#define HAS_RFNATIVE
#define LACROSSE_HMS_EMU
Die Zeile muss weg oder wird auskommentiert:
//# define OFF_LACROSSE_HMS_EMU
In CUL.c dürfen diese Einträge nicht fehlen:
#ifdef HAS_RFNATIVE
#include "rf_native.h"
#endif
#ifdef HAS_RFNATIVE
{ 'N', native_func },
#endif
#ifdef HAS_RFNATIVE
native_task();
#endif
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.
das liegt daran das er neu initialisiert. danach muss man raw Nr2 neu setzen. das fest per attribut zu setzen wäre natürlich geiler (wie zb den rfMode).
workaroung wäre ein notify auf [cul]:Initialized oder cul:CONNECTED
Zitat2016-04-08 18:56:56 CUL nanoCUL868 DISCONNECTED
2016-04-08 18:57:04 CUL nanoCUL868 Initialized
2016-04-08 18:57:04 CUL nanoCUL868 CONNECTED
ich werde das setzen des raw-modes automatisch mal wünschen https://forum.fhem.de/index.php/topic,51946.0.html
Zitat von: max333 am 08 April 2016, 11:36:26
Ich habe meinen Cube auch mit einer Lacrosse Firmware geflasht, mit set CUL raw Nr2 funktioniert auch alles einwandfrei, nur "vergisst" der Cube die Nr2 Einstellung in unregelmäßigen Abständen, mal empfängt er nur 30 Sekunden mal gehts 10 Minuten. Im Log ist aber auch nicht auffälliges.
könnt mir vorstellen das die lan-verbindung mal verloren geht und fhem dann die verbindung neu aufbaut.
per
define nft_culrestart notify [culname]:Initialized set nanoCUL868 raw Nr2sollte er nach neustart sowie ab und anstecken / ein und ausschalten immer wieder raw Nr2 setzen
Den gleichen Fehler habe ich auch, wenn ich den Cube über USB anschließe. Ich vermute, das es ein Empfangsproblem ist und sich dann das RF-Modul aufhängt und mit Nr2 wieder neu initialisiert werden muss. Denn ich habe auch Daten dabei, die nicht decodiert werden.
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...
Zitat von: Fhemschorsch am 10 April 2016, 07:37:05
Da ich über die Suche nichts gefunden habe: Funktioniert das Umflashen zum CUN auch mit dem Cube von mobilcom-debitel? Der ist ja nochmal 5€ günstiger...
Ich habe diese Woche zwei umgeflasht, es stand folgendes auf der Unterseite: TRX868-TI
Zitat von: Fhemschorsch am 10 April 2016, 07:37:05
Da ich über die Suche nichts gefunden habe: Funktioniert das Umflashen zum CUN auch mit dem Cube von mobilcom-debitel? Der ist ja nochmal 5€ günstiger...
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
Zitat von: mrbit1968 am 10 Januar 2016, 07:11:24
So alles Wunderbar bis jetzt am Laufen.. auch mit Zicken (Batterietausch schafte soweit abhilfe beim Anlernen). oder auch mehrmaliges Reset der Thermostaten von Max. Wobei dann auch die Credits zu neige gehen.
Positiv ist aber das ich ohne Max Software egal welche Fimware 1.0/1.3/1.5 alle Firmware der Aktoren die Korrekte Temperatur wiedergeben, was mit der Max Software nicht der fall ist. Da musset man ja Korregieren von 0.5 bis 1 Grad, Gemessen mit einen Infrarotthermometer.
Gruß 8)
Pop, Rock, s
Zitat von: chris1284 am 10 April 2016, 11:36:43
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!
Wo kann man den einzeln von debitel bestellen ?
Zitat von: Telekatz am 06 Juli 2015, 20:59:36
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
Zitat von: raspklaus am 10 April 2016, 20:05:51
Wo kann man den einzeln von debitel bestellen ?
Amazon Marketplace, 34,90€ incl Versand
Zitat von: Christian1982 am 10 April 2016, 21:05:42
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
Weil der Entwickler (Telekatz) es geschrieben hat.
Ich habe sicherheitshalber auf die Möglichkeit hingewiesen, dass es vielleicht Geräte mit anderen Funkmodulen geben könnte, weil es beim MAX Fensterkontakt irgendwann mal geändert wurde und weil diverse Homematic Geräte ein anderes Funkmodul haben.
Trotzdem wurde hier noch nie ein Cube mit anderen Funkmodul gemeldet. Scheint es also doch nicht zu geben.
Dann hätten wir das ja auch geklärt :-)
Hier mal ein interessanter Artikel zum Cube
https://www.insinuator.net/2016/04/discover-the-unknown-analyzing-an-iot-device/
Eine kurze Rückmeldung: mein Mobilcom-Cube war dank der guten Anleitung problemlos zum CUL umgebaut.
Das mit dem Netzwerk will noch nicht (IP wird per Ping gefunden, aber Telnet über Port 2323 wehrt sich standhaft (Connection Refused), aber über USB geht es schonmal einsame Spitze!
Bei mir auch perfekt geklappt und hängt schon im netzwerk ..
War auch eine Mobilcom Cube..
Wenn ich mir das so ansehe wäre bestimmt auch eine Anbindung per esp-01 und somit per wlan möglich ... nur so als Gedankenanstross
Mobil erstellt daher kurz gehalten
Zitat von: noice am 14 April 2016, 18:17:12
Wenn ich mir das so ansehe wäre bestimmt auch eine Anbindung per esp-01 und somit per wlan möglich ... nur so als Gedankenanstross
den Gedanke hatte ich auch im Dezember :) Nachdem Telekatz seit einiger Zeit die Daten auch auf ST1 bereit stellt, steht dem direkten Anschluss eines ESP8266 mit transparenter Bridge nichts mehr im Wege.
Hallo zusammen,
kompliment an die mitwirkenden.
Hab meinen geschossenen neuen Cube heute mal etwas gequält und umgeflasht :D
Das ganze läuft auch in Fhem erstmal testweise, echt Prima.
Kann mir noch jemand was zu den LED's erklären und was die bewirken? Ich meine Internet ist mir noch relativ einleuchtend, aber warum blinkt Power dauerhaft im langsamen Rhytmus und Battery dauerhaft? Kann man das konfigurieren? Möchte so wenig licht wie Möglich vom Cube, oder wenn, dann Sinnvoll. Da wo er steht sieht man es eh nicht, ausser wenn man explizit nachschaut. Ich meine LED's brauchen ja auch nur unnötig Strom :)
gruß
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).
Hallo zusammen,
ich habe meinen Cube geflashed und an meinen Testsystem "Raspi mit Raspian" läuft auch alles.
An meinen Produktivsystem "Odroid mit Ubuntu" wird der Cube nicht erkannt.
Ich nehme an dies ist eher ein Linux Problem.
Ich wußte aber nicht wohin damit.
dmesg
[ 3320.347816] usb 1-1.2: new full-speed USB device number 9 using dwc_otg
[ 3320.455654] ERROR::handle_hc_nak_intr:1307: Can not read device info from hub.We take it error
[ 3320.462313] ERROR::handle_hc_nak_intr:1307: Can not read device info from hub.We take it error
[ 3320.464027] usb 1-1.2: unable to read config index 0 descriptor/start: -71
[ 3320.465283] usb 1-1.2: can't read configurations, error -71
[ 3321.327856] hub 1-1:1.0: Cannot enable port 2. Maybe the USB cable is bad?
[ 3322.187839] hub 1-1:1.0: Cannot enable port 2. Maybe the USB cable is bad?
[ 3323.047817] hub 1-1:1.0: Cannot enable port 2. Maybe the USB cable is bad?
[ 3323.049533] hub 1-1:1.0: unable to enumerate USB device on port 2
Danke und Gruß
Jay
Edit: Halte ich die Taste unter dem Cube beim verbinden gedrückt. Wird der Cube erkannt. (Bootloader)
Edit2: Wenn ich den Cube per IP anbinde klappt es. Hat jemand eine Idee? Es scheint ja am Ubuntu zu liegen. Kerneltreiber? Ich bin leide rnicht der Linux Experte.
Das es ein Treiberproblem ist halte ich für unwahrscheinlich. Der Bootloader wird ja erkannt. Die a-culfw und der Bootloader verwenden den gleichen USB Sourcecode und benötigen dadurch den selben Treiber.
USB Kabel schon getauscht? Eventuell ein Wackelkontakt.
Hallo zusammen,
könnte ich den Max Cube mit culfw auch unter Homematic mit CUxD über LAN anschließen und als Signalverstärkung für HM verwenden.
Falls ja gerne mit Beispiel.
VG
GSO
Zitat von: Telekatz am 20 April 2016, 22:29:53
Die Power LED funktioniert wie die LED beim CUL. Mit "set myCUL raw l00" kann die LED ausgeschaltet werden.
Die Internet LED leuchtet, wen eine LAN Verbindung vorhanden ist, die Battery LED wenn der Cube über USB Verbunden ist. Um die zu deaktivieren musst du das im Sourcecode auskommentieren (main.c und network.c).
wie wird die led (Power) dann dauerhaft eingeschaltet?
Gruß!
So wie beim CUL:
http://culfw.de/commandref.html#cmd_l (http://culfw.de/commandref.html#cmd_l)
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.
Zitat von: DerFrickler am 15 Mai 2016, 20:11:12
Super, vielen Dank!
Jetzt kann der CUNX zum Elektroschrott. Selbst mit dieser popeligen Antenne, hat der CUBE bis zu 15 dBm bessere RSSI Werte im Vergleich zum CUNX.
Ich glaube der CUNX findet hier im schwarzen Brett sicher noch einen Abnehmer ::)
Zitat von: noice am 18 Mai 2016, 22:07:02
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ß!
Mein Cube läuft seit mehreren Wochen stabil im Netzwerk über 3 Etagen mit fast 40 Geräten, allerdings reichten die vorgegebenen Credits niemals.
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).
Zitatfeststellen dass auch dieser sich für 6 Stunden pro Tag schlafen legt
bei dem fehlerbild würde ich den cube als quelle vernachlässigen. fhem versucht bei verbindungsverlust doch ständig den cube neu zu connecten und das schafft es nicht wenn zb der cul nicht verfügbar ist.
richte mal ein presence per lanping auf den cul ein um zu schauen ob er wirklich "aus dem lan verschwindet" oder nur die verbindung zu fhem verliert
Ich hab mit dem Cube dasselbe Problem - nach 6h regelmäßig disconnected, erst durch Steckerziehen am Cube behebbar. Gabs aber hier schon öfter - möglicherweise unterschiedliche Stände.
habe
VERSION V 1.20.01 a-culfw Build: 176 (2015-12-07_23-24-58) CUBe (F-Band: 868MHz)
bei mir läuft:
VERSION V 1.20.06 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Zitat von: chris1284 am 21 Mai 2016, 08:32:39
dito, läuft stabil am netzwerk 24/7 (und das über meine alten bescheidenen powerlan-adapter). würde ehr den fehler im netzwerk suchen (sofern dein fhem aktuell ist).
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ß!
Mein HM-CFG-USB-2 ist nach jedem Reboot des Rechners nicht mehr verfügbar.
Die LED blinkt, der CUL steht auf opened und ist nicht erreichbar bis ich die USB Verbindung trenne.
Ausserdem schaltet l00 die LED an statt aus.
In den neuen Releases ist beim Cube nur noch der Bootloader vorhanden, Mit welcher Hex Datei wird er denn dann geflashed ?
Die Hex ist eine .bin.....
Also zwei bin Dateien im Cube Verzeichnis.....
Gesendet von iPad mit Tapatalk
Im Cubeverzeichnis ist nur eine bin Cube_BL
Dann schau in die 1.20.08 rein, die hatte ich auch genommen und ist bisher ohne Auffälligkeiten bei mir am Rennen.
Dein Cube hatte doch schon den Bootloader, zumindestens habe ich das so verstanden, dann brauchst du auch nur die
Software selber
Gesendet von iPad mit Tapatalk
bootloader_CUBE.bin ist der Bootloader.
CUBE_BL.bin ist die Firmware Datei, die mit dem Bootloader geschrieben wird.
Daneben kann man noch die Datei CUBE.bin erstellen, die ohne den Bootloader auf den Cube geschrieben wird.
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.
Zitat von: raspklaus am 27 Mai 2016, 11:58:25
Hallo,
wie wird die Cube.bin erstellt ?
Ich habe Probleme auch mit minicom den Cube zu flashen. Laut Compare von Samba ist der Bootloader richtig geschrieben. Wenn ich den Cube dann an den Raspberry anschliessend blinkt für ca 30 sek die D1 danach leuchtet sie ständig.
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
Die LED müsste doch aber blinken solange noch keine Firmware übertragen ist ???????
Kann jemand die neueste Cube.bin zur Verfügung stellen ?
Danke
das sollte dann die 220_master unter https://www.mediafire.com/folder/tf16radvztfd9/a-culfw sein
Da ist aber keine Cube.bin im Archiv
im Download finde ich im Verzeichnis CUBe die Dateien CUBE_BL.bin und dann ein weiteres Verzeichnis mit dem Namen bootloader und dem File bootloader_CUBE.bin
Die kombinierte Datei heisst aber Cube.bin. Siehe alte Version auf Seite 3
Anbei eine aktuelle CUBE.bin.
Danke !!!!
Kannst Du mir bitte auch sagen wie ich die eventuell selbst erstellen kann ?
Danke
- Toolchain aus dem ersten Beitrag herunterladen und installieren
- Sourcecode aus dem ersten Beitrag herunterladen
- Eventuell make installieren
- Optional IDE (z.B. Eclipse) installieren
- Im Verzeichnis ...\culfw\Devices\CUBe "make CUBE" ausführen
Könnte mir jemand bitte mal jemand eine Firmware mit lacrosse Unterstützung kompiliert hochladen?
Bekomme den toolchain nicht installiert und kenn mich nicht so aus.
Ich kann nur davon abraten den Cube mit LaCrosse zu betreiben. Er verliert im LaCrosse-Modus laufend die Verbindung. Viel zuverlässiger läuft der LaCrosseGateway.
Danke. Hab ich auch bemerkt und jetzt einen Jeelink angeschlossen.
Hallo Zusammen
Zunächst mal meine Hochachtung den Beteiligten zu diesem Projekt und der Portierung.
Ich betreibe mein FHEM mit zwei Selbstbau nanoCUL (433MHz & 868MHz). Lange habe ich nach einem Vorschlag für Netzwerksanbindung über einen CUN gesucht (für einen abgelegenen Raum) und bin nicht fündig geworden. Da bin ich auf das Projekt gestoßen, habe einen MAX! Cube beschafft und geflasht.
Hat im Prinzip gut geklappt (nur den Bootloader musste ich unter Linux flashen, die ATMEL Windows Version hat bei mir gezickt).
Nun zu meinen Fragen:
1)
Mit der CulFW (CUBE_BL.bin) läuft der Cube auf 868MHz, kann aber 433MHz Intertechno Kommandos absetzen wie alle CUL's.
Ich habe irgendwo mal einen Beitrag gelesen (finde ihn nicht wieder), dass beim Umschalten intern jedesmal das EEPROM umprogrammiert wird und die Anzahl der Schreibvorgänge ist ja "endlich".
Hat jemand Erfahrung damit und kann das bestätigen? Oder ist das Quatsch und lediglich Register des CC1101 werden temporär umgesetzt ohne das EEPROM zu beschreiben?
2)
Würde es für einen 433MHz-Betrieb reichen einfach per "set freq" aus FHEM die Frequenz auf 433MHz zu setzen. Mit dem hoffentlich positiven Nebeneffekt, dass auch auf dieser Frequenz empfangen wird.
3)
Beim nanoCUL kann in der "board.h" über ein "define" bestimmt werden, dass beim make statt 868MHz eine 433MHz CUL kompiliert wird.
(beide nanoCUL Varianten sind in den kompilierten BIN https://www.mediafire.com/folder/tf16radvztfd9/a-culfw enthalten)
/* if you are using a CC1101 module for 868MHz disable the next line */
/* #define HAS_CC1100_433 */
Für den Cube ist das in der "board.h" nicht vorgesehen. Gibt es die Variable?
Vermutlich würde ich es allerdings nicht schaffen mit der Toolchain die Variante auch zu kompilieren.
Ist es möglilch für den Cube beide Varianten in den BIN's anzubieten?
viele Grüße Ralf
1. Das EEPROM wird nur beschrieben, wenn die Frequenz dauerhaft mit "set freq" umgestellt wird. Beim temporären Umschalten für Intertechno wird das EEPROM nicht geändert.
2. Es kann dann zwar 433MHz empfangen werden, aber nicht besonders gut.
3. Die zwei verschiedenen Varianten gibt es, weil der nanoCUL zu wenig Speicher hat um alle Protokolle unterstützen zu können. Es werden jeweils nur die Protokolle hineinkompiliert, für die der Empfänger auch geeignet ist. Da der Cube mehr Speicher hat sind dort alle Protokolle enthalten.
Danke für die Antwort
- 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)"
Kurzer Nachtrag zur Reichweite des 868er Cubes bei 433 Mhz.
Es reicht zumindest um im Raum bzw. im Geschoß die IT-Schaltsteckdosen anzusprechen.
Damit konnte ich mein Ziel erreichen einen abgelegenen per LAN erreicharen Raum zu steuern .
Hi @all ,
auch ich habe meinen Cube zum Cuno geflasht :
list
Internals:
CFGFN /opt/fhem/FHEM/02_CulMaxCube.cfg
CMDS BbCFiAZNEkGMKLUYRTVWXefltxz
CUL_HM_Cube_MSGCNT 1
CUL_HM_Cube_TIME 2016-07-02 06:04:10
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
DEF 192.168.178.56:2323 1234
DeviceName 192.168.178.56:2323
FD 15
FHTID 1234
NAME CUL_HM_Cube
NR 93
PARTIAL
RAWMSG A0FCA861022E2610000000AB0FE0F0058DB
RSSI -92.5
STATE Initialized
TYPE CUL
VERSION V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
initString X21
Ar
owner_CCU VCCU
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2016-04-25 21:55:30 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2016-07-02 06:02:58 cmds B b C F i A Z N E k G M K L U Y R T V W X e f l t x z
2016-06-18 23:28:40 credit10ms 900
2016-04-25 21:55:44 fhtbuf AE
2016-07-02 06:04:10 state Initialized
2016-06-18 04:16:40 uptime No answer
2016-06-18 04:07:49 version V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
Attributes:
hmId 1AA777
icon cul_cul
model CUL
rfmode HomeMatic
room CUL_HM
Im Logfile kommen immer wieder mal folgende Einträge : ( ca alle 2 Stunden )
2016.07.02 03:07:24 1: 192.168.178.56:2323 disconnected, waiting to reappear (CUL_HM_Cube)
2016.07.02 03:07:24 3: CUL_HM_Cube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.02 03:07:24 1: 192.168.178.56:2323 reappeared (CUL_HM_Cube)
muss ich mir da Sorgen machen ? Wenn ich das richtig verstehe ,ist der CUNO öfter offline , oder ?
Vielen Dank für die tolle Arbeit!
Den Fehler bei der Netzwerkanbindung des MaxCubes kann ich allerdings bestätigen. Im Logfile:
2016.07.02 12:05:34 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:38 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:43 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:48 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:53 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:05:58 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:03 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:08 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:13 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:18 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:23 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:28 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:33 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:38 3: MaxCube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.02 12:06:38 2: Setting CUL fhtid from 1034 to 0000
2016.07.02 12:06:38 1: 192.168.178.59:2323 reappeared (MaxCube)
2016.07.02 12:06:49 1: 192.168.178.59:2323 disconnected, waiting to reappear (MaxCube)
2016.07.02 12:06:49 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.02 12:06:51 3: MaxCube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.02 12:06:51 1: 192.168.178.59:2323 reappeared (MaxCube)
Verbinde ich mich mit Telnet, ohne dass fhem mit dem MaxCube verbunden ist, fällt auf, dass er immer wieder den Versionsstring ausgibt:
root@myserver ~ # telnet 192.168.178.59 2323
Trying 192.168.178.59...
Connected to 192.168.178.59.
Escape character is '^]'.
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
Ich denke, dies ist das Problem. Der MaxCube startet nicht neu, aber der Netzwerkstack glaubt ein "V" empfangen zu haben, wahrscheinlich ist er in dieser Situation auch nicht ansprechbar, was zu "MaxCube did not answer request for current credits." führt.
Ich habe den MaxCube jetzt über USB angeschlossen und alles ist gut.
Herzliche Grüße
Jan
@Aladin222 & janvonnebenan
Ich setze den Cube seit ca. 10 Tagen ein. Ich habe keine LOG Einträge hinsichtlich LAN Verbindung.
Version : V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 868MHz)
@Telekatz
Nochmal zu einem Teil meiner Frage 2 vom 25.6
Ich kann prima schalten bei 433Mhz (im Raum) aber trotz setzen der Frequenz auf 433 Mhz (freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB) empfange ich vom Handsender keine Signale - egal welcher Abstand. Der Event Monitor loggt nichts.
Mache ich einen Denkfehler?
Gruß Ralf
@janvonnebenan ,
Ok , das heißt schonmal ich war nicht zu doof :-)
Allerdings macht es das ganze nun nicht wirklich besser für mich ,da ich gerade die LAN-Anbindung haben wollte :-(
Vielleicht ist es ja ein Problem von Version 1.21.00. Ich werde mal die ältere Version (1.20.08) testen.
Hab gerade nochmal nachgesehen :
Bei mir
V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
Vielleicht bringt das ja was .... puhhh müsste ich mich wieder einlesen wie das ging *snief
Ich hab das Problem kaum noch, seit ich für den Cube ein Presence gesetzt hab - offebar mögen manche davon regelmäßig angepingt werden. :)
@rubbertail, könntest du das bitte nochmal etwas genauer beschreiben ?
PRESENCE-Modul in Betrieb nehmen, IP des Cube auf presence testen. Für PRESENCE nach commandref vorgehen ;)
Zitat von: RalfRog am 02 Juli 2016, 18:26:23
@Telekatz
Nochmal zu einem Teil meiner Frage 2 vom 25.6
Ich kann prima schalten bei 433Mhz (im Raum) aber trotz setzen der Frequenz auf 433 Mhz (freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB) empfange ich vom Handsender keine Signale - egal welcher Abstand. Der Event Monitor loggt nichts.
Mache ich einen Denkfehler?
Sollte eigentlich funktionieren. Setz mal alles mir "raw e" alles zurück und und stell die Frequenz nochmal ein.
Hallo, danke für die Idee (Update 40 Minuten später)
ZitatSollte eigentlich funktionieren. Setz mal alles mir "raw e" alles zurück und und stell die Frequenz nochmal ein.
Gesagt getan, set freq 433 MHz, meinen nanoCUL ausgesteckt, Handsender benutzt
Per Autcreate werden keine neuen Devices angelegt - wäre zu erwarten gewesen. Mit Verbose 5 wird folgendes ins FHEM-Log geschrieben:
....
2016.07.03 18:43:23 3: nanoCUL1: Unknown code i11155f, help me!
2016.07.03 18:46:57 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:46:57 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:27 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:27 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:57 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:47:57 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:27 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:27 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:57 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:48:57 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:28 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:28 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:58 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:58 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 18:49:59 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00F4TK-if00-port0 disconnected, waiting to reappear (nanoCUL1)
2016.07.03 18:50:28 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
....
Update
2016.07.03 19:22:43 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:22:43 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:22:57 5: SW: C0D
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C0D = 10 / 16
2016.07.03 19:22:57 5: SW: C0E
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C0E = A7 / 167
2016.07.03 19:22:57 5: SW: C0F
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C0F = 62 / 98
2016.07.03 19:22:57 5: SW: C10
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C10 = 57 / 87
2016.07.03 19:22:57 5: SW: C1B
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C1B = 07 / 7
2016.07.03 19:22:57 5: SW: C1D
2016.07.03 19:22:57 5: CUL/RAW (ReadAnswer): C1D = 90 / 144
2016.07.03 19:23:22 5: SW: V
2016.07.03 19:23:22 5: CUL/RAW (ReadAnswer): V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:23:52 5: CUL/RAW: /V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
2016.07.03 19:23:52 4: CUL_Parse: cubeCUL1 V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
Das scheint mir auf Empfang hinzudeuten aber nicht korrekt dekodiert zu werden, oder?
Update: die Meldungen kommen permanent alle 30 sec, die Werte 19:22 einmalig
Hier die Details vom Cube
Internals
CMDS BbCFiAZNEkGMKLUYRTVWXefltxz
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY::STACKABLE_CC:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF cube.fritz.box:2323 0000
DeviceName cube.fritz.box:2323
FD 12
FHTID 0000
NAME cubeCUL1
NR 29
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 868MHz)
initString X21
Readings
ccconf freq:433.000MHz bWidth:325KHz rAmpl:42dB sens:4dB 2016-07-03 19:22:57
cmds B b C F i A Z N E k G M K L U Y R T V W X e f l t x z 2016-07-03 18:34:54
raw is0F0F0FFF0FF0 2016-07-03 01:00:03
state Initialized 2016-07-03 18:34:54
uptime 0 19:57:12 2016-07-02 17:58:53
version V 1.20.08 a-culfw Build: 220 (2016-04-11_23-12-16) CUBe (F-Band: 433MHz)
Hallo Telekatz
Ich wollte jetzt nicht nochmal die Antwort oben editieren.
Ich denke der Cube hat aufgrund von Funktelegrammen nichts geschickt.
Die Meldungen scheinen der Beobachtung von janvonnebenan mit Telnet zu entsprechen.
Ich konnte das ebenfalls per tcpdump bei aktiver Einbindung in FHEM nachvollziehen. Alle 30 sec schickt der Cube die Meldung raus.
Gruß Ralf
Die Versionsmeldungen alle 30 Sekunden sind sind normal und beabsichtigt:
https://forum.fhem.de/index.php/topic,36529.msg289490.html#msg289490 (https://forum.fhem.de/index.php/topic,36529.msg289490.html#msg289490)
ZitatDie Versionsmeldungen alle 30 Sekunden sind sind normal und beabsichtigt:
Gut zu wissen :) - beantwortet damit auch die Telneterfahrung von janvonnebenan
Ich habe gerade an meinem Test-Raspi den Cube per USB angeschlossen und auf 433MHz gestellt. Macht keinen Unterschied zur LAN-Anbindung - es kommt nichts.
Zusätzlich habe ich per RAW Message statt X21 mal X67 (commanref sagt debugging für den CUL) gesetzt. Ich bekomme einfach keine Meldungen.
Bei meinem nanoCUL sieht es mit X67 dann so aus:
...
2016.07.04 20:40:26 5: CUL/RAW: /p 7
2016.07.04 20:40:26 5: CUL/RAW: p 7/ 224 1008 912 352 1
2016.07.04 20:40:26 5: CUL/RAW: p 7 224 1008 912 352 1/ 3 0 0F 110554
2016.07.04 20:40:26 4: CUL_Parse: nanoCUL1 p 7 224 1008 912 352 1 3 0 0F 110554
2016.07.04 20:40:26 2: nanoCUL1: unknown message p 7 224 1008 912 352 1 3 0 0F 110554
...
Mal sehen ob ich irgendwo einen FS20 Sender leihen kann. Will mal sehen ob wenigsten bei 868MHz empfangen wird.
So ich habe jetzt mal einiges getestet.
1. Es hat nichts mit der Firmwareversion zu tun.
2. Die Keepalive-Funktion steht mit dem Fehler auch nicht im Zusammenhang. Ich habe sie deaktiviert und mir eine eigene Firmware erstellt.
3. Ein regelmäßiger Ping hilft auch nicht.
Ich habe mal des Verbose vom CUL und CUL_MAX auf 5 gesetzt.
2016.07.07 14:47:41 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:42 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:42 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:43 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:43 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:44 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:44 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:44 5: CUL_MAX_SendQueueHandler: Retry 0868fe for 0f5b04031234560868fe0010070e6fe9 count: 3
2016.07.07 14:47:47 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:47 5: SW: X
2016.07.07 14:47:50 1: 192.168.178.59:2323 disconnected, waiting to reappear (MaxCube)
2016.07.07 14:47:50 1: Error in CUL_MAX_SendQueueHandler: CUL MaxCube did not answer request for current credits. Waiting 5 seconds.
2016.07.07 14:47:53 5: SW: V
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): V 1.21.01 a-culfw Build: Jans private build (2.7.2016) CUBe (F-Band: 868MHz)^M
2016.07.07 14:47:53 5: SW: ?
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l t x z^M
2016.07.07 14:47:53 3: MaxCube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.07.07 14:47:53 5: SW: X21
2016.07.07 14:47:53 5: SW: Zr
2016.07.07 14:47:53 5: SW: Za123456
2016.07.07 14:47:53 5: SW: Zw111111
2016.07.07 14:47:53 5: SW: T01
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): 0000^M
2016.07.07 14:47:53 5: GOT CUL fhtid: 0000
2016.07.07 14:47:53 1: 192.168.178.59:2323 reappeared (MaxCube)
2016.07.07 14:47:53 5: CUL_MAX_SendQueueHandler: 3 items in queue
2016.07.07 14:47:53 5: SW: X
2016.07.07 14:47:53 5: CUL/RAW (ReadAnswer): 21 1807^M
und einen tcpdump gemacht. Auffällig ist, dass der letzte Befehl bevor das "X" gesendet wird zwei TCP-Retransmits auslöst. Anbei mal das tcpdumpfile für Wireshark. Vielleicht kann da ja jemand etwas zu sagen. Möglich aber, dass das Problem nur bei einigen Max-Installationen auftritt. Ich habe zum Beispiel 29 Max-Geräte.
Hallo,
nochmal eine Frage:
Beim Flashen mit minicom muss welches Protokoll ausgewählt werden ?
Danke
Es wird das XModem Protokoll verwendet.
Was mir bei der 21er Version aufgefallen ist und was ich mit den 20er Versionen nicht hatte, das nach einer Zeit meist 3 bis 4 Tagen anstatt Initialisiert in der Fhem Software dort Open bei CUNO(Cube) steht. Ab da ist der Cube auch nicht mehr erreichbar. Das hab ich auch nicht nur einmal gehabt sondern immer wieder in Regelmässigen abständen. Wenn ich Fhem dann neu starte ist wieder alles in Butter. Und was mir vorkommt, das die Sendeleistung wodurch auch immer nicht so Stark ist wie bei den 20er Versionen .. evtl. einbildung , aber vorher musste ich den Cube nicht auf dem schreibtisch verstellen um die Funksteckdosen in gelegenden Ecken zu erreichen. Ich werde wieder auf die letzte 20er Version wechseln.
Gruß
Verwendest du den Cube für slowRF auf 433MHz? Und wie hast du den Cube angeschlossen? Über USB oder Netzwerk?
Es gibt zwar in der Version 1.21.00 eine Änderung im IT Empfangsteil, der beim Cube nicht so ganz passt, aber das sollte keine Auswirkung auf die Stabilität haben. Und an der Sendeleistung wurde nichts geändert.
Hallo Telekatz,
Ich benutze den Cube im rfmode MAX, nur zum Senden von Intertechno schalte ich kurz auf 433 Mhz Slow RF.
Angeschlossen ist der Cube über Netzwerk an einer Fritzbox 7490 woran wieder ein Rasberry 2 hängt.
Und heute wieder nach 3 Tagen steht wieder Open als Status beim Cuno (Cube). Dort muss ja Initialized stehen.
Gruß
Zitat von: RalfRog am 04 Juli 2016, 20:45:25
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
Na da hätte ich auch früher drau f kommen können.
- 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.
Hallo Telekatz, werd jetzt auf die 20er Version wechseln, das Problem ist definitiv abhängig von der 21er Version. ca 48 Stunden steht dort Open statt Initalized.
Gruß
Welche der 20er Versionen verwendest du dann?
Definitiv ist die Emfpangsrichtung defekt.
Das RF Modul ist händisch aufgelötet und scheint den gängigen 868MHz Chinamodulen zu entsprechen. Könnte man mal versuchsweise ersetzen... aber ich brauch ja nicht empfangen.
@Telekatz ist einer der GD-Pins ein Interrupt für die Empfangsrichtung. Der ganze HF-Teil muss ja in Ordnung sein.
Info:
Seit 30.7 läuft besagter Cube über LAN und ist initialized. Steuert auch jeden Abend brav die Terasse (Intertechno).
VERSION: V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
state: Initialized 2016-07-30 13:54:30
Bei slowRF wird über GDO2 das demodulierte Signal ausgegeben und über einen Pin change Interrupt ausgewertet. Ansonsten wird über GDO2 der Empfang eines neuen Pakets signalisiert.
Habe jetzt mal beim Cuno (CUBE) get raw und get credits angecklickt was vorher rot in den Readings stand ohne angaben. Seit dem scheint der Open effeckt weg zu sein. Werde weiter ein Auge drauf haben.
Ich versuche gerade einen neuen Cube ohne Bootloader mit minicom zu flashen. ttyACM0 wird erkannt, aber mit xmodem kommt es beim flashen nur zu timeouts.
Wie bekomme ich den Cube trotzdem ans Laufen ?
Du musst erst den Bootloader mit SAM-BA oder BOSSA flashen. Über xmodem funktioniert es nur, wenn der Bootloader schon drauf ist.
Ich verzweifle gerade.
Habe den Cube erfolgreich geflasht... läufft auch alles nur ich komm mit den Credits einfach nieeee aus
Kann mir einer erklären wie ich die firmware unter linux am besten selbst neu erstellen kann ?
Log
Bei 7 Thermostaten und einem Zwischenschalter
2016.09.20 14:22:03 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:22:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:23:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:23:52 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:24:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:25:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:25:42 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:26:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:27:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:27:31 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:28:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:29:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:29:22 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 3, but we need 110. Waiting 107 seconds.
2016.09.20 14:30:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:31:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:31:10 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:32:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
2016.09.20 14:33:00 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 2, but we need 110. Waiting 108 seconds.
2016.09.20 14:33:07 3: HCS HCS_System Found 8 Device(s): 0 FHT, 0 HM-CC-TC, 8 MAX, demand: 0, idle: 7, ignored: 0, excluded: 1, unknown: 0, eco: no overdrive: no
thx und lg
Kann es sein das der geflashte Cube Credits verbratet wo er das nicht sollte.
Ich habe folgendes Script am lauffen
#############Kontrolle der Gastherme ueber MAX-Schaltkontakt Beginn##################
#### Heizung: Winterbetrieb Sommerbetrieb
define HA_Heizung_Modus dummy
attr HA_Heizung_Modus alias Betriebsmodus
attr HA_Heizung_Modus fp_Heizung 36,220,7,
attr HA_Heizung_Modus group Betriebsmodus
attr HA_Heizung_Modus room Haus
attr HA_Heizung_Modus setList state:Winter,Sommer
attr HA_Heizung_Modus userReadings HCS_TEMP { if (ReadingsVal("HA_Heizung_Modus","state","Unbekannt") eq "Winter"){return 0} else {return 30};;}
attr HA_Heizung_Modus webCmd state
#Versuch mit HCS-Modul
define HCS_System HCS HA_Heizung_Schalter
attr HCS_System alias Heizungssteuerung
attr HCS_System deviceCmdOff desiredTemperature on
attr HCS_System deviceCmdOn desiredTemperature off
attr HCS_System event-on-change-reading state,devicestate,eco,overdrive
attr HCS_System exclude HA_Heizung_Schalter
attr HCS_System idleperiod 5
attr HCS_System interval 1
attr HCS_System loglevel 3
attr HCS_System mode valve
attr HCS_System room System
attr HCS_System sensor HA_Heizung_Modus
attr HCS_System sensorReading HCS_TEMP
attr HCS_System sensorThresholdOff 20
attr HCS_System sensorThresholdOn -1
attr HCS_System thermostatThresholdOff 0.5
attr HCS_System thermostatThresholdOn 0.5
attr HCS_System valveThresholdOff 10
attr HCS_System valveThresholdOn 40
#############Kontrolle der Gastherme ueber MAX-Schaltkontakt Ende####################
Mit dem nicht geflashten Cube fragte das Script zwar auch immer die valve Position jede Minute ab es ginge aber keine Credits flöten.
Mit dem geflashten Cube sobald ich das Script aktiviere und dieses die Thermostate abfragt dauter es keine 2 Minuten und die Credits sind weg.
Jemand ne Idee woran das liegen könnte?
Schon mal das hier ausprobiert:
https://forum.fhem.de/index.php/topic,37980.0.html (https://forum.fhem.de/index.php/topic,37980.0.html)
Ansonsten würde ich mal im entsprechenden Unterforum für MAX oder HCS nachfragen. Mit der a-culfw Firmware hat das nicht direkt was zu tun.
Noch mal das Problem mit der Intitialsieung des Cube (Cuno) in Status Meldung.
Also mir scheint das der Taster den ich vorher eine Zeitlang nicht gebraucht habe, womit ich jetzt das Licht einschlalte für die Beleuchtung der Arbeitsplatte in der Küche das Open manchmal erzeugt. Den habe normal eingebunden ohne irgendwelche extras. Seit dem vermute ich wenn ich denn zwei bis dreimal drücke erscheint dann das Open bei als letzer Status beim Cube (Cuno) was sonst bei den Heizkörperthermostaten nicht Passsiert oder bei sonstigen Funksteckdosen. Mit dem Max Taster Steuere ich die Beleuchtung einer Funksteckdose. Diese machen in der Regel mit der Intertechno Fernbedienung oder gesteuert von Der Fhemsoftware keine Probleme. Werde mal Versuchen die Tage ein Log mit zu Schneiden.
Noch mal zur Erinnerung , wenn dort ein Open steht , geht garnix mehr. Dann muss ich die Fhemsoftware neustarten, dann gehst wieder. Damit der Status wieder auf Initialized steht.
Gruß
Wenn du den Cube mit
attr <cubename> verbose 5
dazu bringst, alles, was er so tut, ins Log zu schreiben, und dann diesen Taster wiederholt drückst, so dass das Fehlerbild passiert - was findest du dann im Log?
Sorry hatte zu tun, werde berichten.
Gruß
Bei mir taucht leider auch ständig diese Meldung auf. :-(
2016.10.10 22:50:16 1: 192.168.178.23:2323 disconnected, waiting to reappear (Cube433)
2016.10.10 22:50:17 1: 192.168.178.23:2323 reappeared (Cube433)
Der Cube ist zwischendurch einfach weg.
Antwort von 192.168.178.23: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=3ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=4ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.178.23: Bytes=32 Zeit=8ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=4ms TTL=128
Antwort von 192.168.178.23: Bytes=32 Zeit=17ms TTL=128
EDIT: Hat sich erledigt. Die Stromversorgung des Cube war nicht ausreichend. Mit einem anderen Netzteil habe ich keine Probleme mehr.
Könnte bitte jemand eine Schritt-für-Schritt Anleitung für die Installation der Toolchain auf einen Pi posten?! Ich bekomm das irgendwie nicht auf die Reihe. :o :-[
Danke!! :)
Wieso willst du die Toolchain auf einen Pi Installieren? Die Firmware auf einem Pi zu erstellen ist doch total unkommod. Da nimmt man doch einen PC.
Desweiteren readme der Toolchain befolgen:
https://launchpadlibrarian.net/186123405/readme.txt (https://launchpadlibrarian.net/186123405/readme.txt)
Habs aufm PC installiert, da bekomme ich immer die Fehlermeldung: "Das System kann den angegebenen Pfad nicht finden.". Muss man da noch was anpassen?
Ja, der Pfad zum .../4.8/bin Verzeichniss der Toolchain muss zur PATH Systemvariable hinzugefügt werden.
Alternativ kann der Pfad im Makefile eingetragen werden (ARMBASE und ARMPATH):
###############################################################
#####
##### PATHS (default installation)
#####
##### You can put your path-config into Makefile.local
##### to override these defaults
#####
###############################################################
ARMBASE = F:/GNU_Tools_ARM_Embedded/4.8
INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-
OPENOCDPATH = F:\Tools\OpenOCD
OPENOCD = $(OPENOCDPATH)\openocd.exe -f $(OPENOCDPATH)\target\sam7x256.cfg -f $(OPENOCDPATH)\interface\uniprog.cfg
GENDEPFLAGS = -MMD -MP -MF .dep/$(@F).d
Ich kapituliere... :'( Habe jetzt alles durch,hab es sogar mit der 5.4 versucht, aber ich bekomme immer eine Fehlermeldung >:(
C:\culfw\a-culfw-master\culfw\Devices\CUBe>make CUBE
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
make OUTPUT=CUBE target
Das System kann den angegebenen Pfad nicht finden.
Das System kann den angegebenen Pfad nicht finden.
make[1]: Entering directory `C:/culfw/a-culfw-master/culfw/Devices/CUBe'
C:/GNUTools/5.4/bin/arm-none-eabi-gcc -mcpu=arm7tdmi-s -Wall -Wno-strict-aliasing -Wno-unused-but-set-variable -mlong-calls -ffunction-sections -std=c99 -Dflash -DCUBE -DTRACE_LEVEL=4 -DDBGU_UNIT_IN -g -MMD -MP -MF .dep/main.o.d -Os -I. -I../.. -I../../at91lib -I../../at91lib/usb -I../../clib -I../../at91lib/avr -I../../avr-uip/uip -I../../avr-uip -IC:/GNUTools/5.4/arm-none-eabi/include -c -o main.o main.c
main.c:471:1: fatal error: opening dependency file .dep/main.o.d: No such file or directory
}
^
compilation terminated.
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `C:/culfw/a-culfw-master/culfw/Devices/CUBe'
make: *** [CUBE] Error 2
Edit: Wert der "PATH": C:\GNUTools\5.4\bin\;C:\GnuWin32\bin
Versuch mal den Ordner .dep im Verzeichnis C:\culfw\a-culfw-master\culfw\Devices\CUBe manuell anzulegen.
Ich hab die Firmware zwar noch nie unter Windows kompiliert, aber auf dem Pi ist es auch kein Problem.
Hier mal mein Post vom letzten Jahr:
Zitat von: mahowi am 16 Dezember 2015, 18:38:58
P.S.: Zum Kompilieren habe ich folgendes Makefile.local erstellt:
###############################################################
INCLUDEPATH = /usr/lib/arm-none-eabi/include
LIBPATH = /usr/lib/arm-none-eabi/lib
#ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = arm-none-eabi-
######################## EOF ##################################
Dazu habe auf dem Pi noch binutils-arm-none-eabi und gcc-arm-none-eabi installiert.
Hat funktioniert! ;D Es war der fehlende .dep Ordner und es geht nur mit der 4.8!
Danke für die Hilfe Telekatz! :)
Hallo in die Runde,
habe gerade versucht meinen Cube zu flshen, ohne Erfolg.
Der im 1. Post beschriebene Link zu SAM-BA kann ich nach dem download nicht starten.
Es kommt kurz die Commandline, schwarzes Fenster dann war es.
Nach einigen google versuchen fand ich SAM-BA v2.8.
Nach dem Start com und AT91SAM7S256-EK ausgewählt, kommt die Fehlermeldung:no valid Prozessor id found
Auf dem Cube nachgesehen und ein AT91SAM7S512-AU drauf >:(
Den kann ich leider nicht im Menü auswählen.
Nun zu meiner Frage, hat schon einer von euch einen solchen Prozessor gehabt? Wenn ja mit welchen Programm unter windows.
Ist doch eigentlich nur ein gröserer speicher drauf?
Wäre schön eine Hilfe zu bekommen....
Danke Heiko
Ich denke nicht, dass du einen AT91SAM7S512-AU hast. Diese Serie hat kein Ethernet. Du hast einen AT91SAM7X512-AU . Dafür wählt man at91sam7x512-ek in SAM-BA aus.
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
Ich verwende v2.15. Und gestartet werden muss SAM-BA mit Administratorrechten.
Ich meine, Sam-ba 3.x ist ein reines CLI-Tool.
Jas das mit Adminrechten ist schon klar, habe ich auch gemacht.
Scheinbar habe ich eine Version, die nicht richtig geht. Kann die v2.15 leider nirgends finden.
Vielleicht kann sie mir jemand per Mail senden, oder einen Link.
Heiko
Probier doch mal V2.16:
http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx (http://www.atmel.com/tools/atmelsam-bain-systemprogrammer.aspx)
so Bootloader ist drauf, led Blinkt ;)
mit der 2.16 ging es....
Sorry bitte nicht schlagen, geht das mit Tera Term per Netzwerk oder usb?
Was genau muss ich bei Tera Term einstellen?
Danke
Es geht nur über USB. Einstellen muss man nur den richtigen Port.
ah ja ok, welchen usb treiber muss ich installieren?
Windows halt, habe mall alle Treiber gelöscht und Rechner neu gebootet, und schon ging es.
Vielen Dank für eure Hilfe
Heiko
komme leider auch nicht weiter.. :(
Bootloader lässt sich flashen.. verify sagt auch das alles in Ordnung ist.
Allerdings blinkt keine LED und das Gerät wird unter Windows auch nach dem flashen des Bootloaders nicht mehr erkannt.
System:
Windows 10
Sam-ba V 2.12
ATMEL AT91SAM7X256
bin für jede Hilfe dankbar !
Damit es dann weitergeht, brauchts einen Neustart - und wenn schon ne FW drauf ist nen Druck auf den Taster unter dem Cube.
Welche Datei hast du genommen? Poste mal das SAM-BA Log.
Dateiname: /a-culfw_v1.21.00_build_71/CUBe/CUBE_BL.bin
Samba Log:
loading history file ... 0 events added
SAM-BA console display active (Tcl8.5.9 / Tk8.5.9)
(sam-ba_2.16) 1 %
(sam-ba_2.16) 1 % send_file {Flash} "C:/Users/denni/Downloads/a-culfw_v1.21.00_build_71/CUBe/CUBE_BL.bin" 0x100000 0
-I- Send File C:/Users/denni/Downloads/a-culfw_v1.21.00_build_71/CUBe/CUBE_BL.bin at address 0x100000
first_sector 0 last_sector 5
-I- Writing: 0xD400 bytes at 0x0 (buffer addr : 0x202A24)
-I- 0xD400 bytes written by applet
-I- Writing: 0x98C8 bytes at 0xD400 (buffer addr : 0x202A24)
-I- 0x98C8 bytes written by applet
Do not lock
(sam-ba_2.16) 1 % FLASH::ScriptGPNMV 4
-I- GPNVM2 set
(sam-ba_2.16) 1 %
Edit:
Ich Dussel.. das ist ja direkt die Firmware und nicht der Bootloader.. -.-
Aber wo finde ich denn den Bootloader in dem Paket :(
Edit2:
Der Bootloader fehlt scheinbar im letzten Paket. Hab das vorletze runtergeladen, dort ist er vorhanden!
Sorry !
Hallo,
Habe auch den bootloader aus dem vorletzten Paket genommen ;)
bekomme immer komisches loggs.
2016.10.27 18:17:51 2: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update.
2016.10.27 18:18:22 2: maxcube: unknown message V 1.21.00 a-culfw Build: 70 (2016-04-22_17-15-27) CUBe (F-Band: 868MHz)
Habe aber die 71 auf dem Cube??
Gibt es da abhilfe?
Mach mal ein Update von deinem FHEM. Du verwendest eine alte Version von 00_CUL.pm und 14_CUL_MAX.pm.
Ok danke das war es
Tja, ich komme nicht weiter:
Ich habe einen bereits mit Bootloader und a-culfw V 1.20.01 versehenen MAX!Cube gebraucht gekauft, diesen möchte ich auf die aktuelle a-culfw flashen.
Der Cube ist im LAN erreichbar und auch in FHEM eingebunden.
Was muss ich tun, um mittels TeraTerm über meinen Windows PC dem Cube die aktuelle FW beizubringen?
Ich habe
1. die a-culfw 1.21 herunter geladen und entpackt.
2. Das Tool "TeraTerm" auf meinem Windows PC installiert
3. Den Cube durch Drücken des Reset-Tasters in den Bootloader-Mode versetzt
4 ?
Und nun?
Das klappt nur, wenn du den Cube via USB an deinen Windows-Rechner hängst und die COM-Schnittstelle verwendest, die beim Tastendruck virtuell erzeugt wird...
4. MAX!Cube per USB mit PC bei gedrückter Reset-Taste an den Windows-PC angeschlossen. Power-LED des Cube blinkt schnell.
5. Das Gerät wird als "AT91 USB to Serial Converter" an COM3 erkannt.
6. Unter Windows das Programm "Tera Term" gestartet, über "Datei --> Neue Verbindung --> Seriell" das Gerät an "COM3" ausgewählt.
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Datei senden" die aktuelle a-culfw für den Cube auswählen:
Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
8. Im Konsolenfenster von Tera Term erscheint mehrmals die Zeile "CUBELOADER V1.01" - ist das ein gutes Zeichen?
9 ...
9. TeraTeam beendet, MAXCube vom Windows PC getrennt und wieder ins LAN gehängt, in FHEM wird immer noch die alte Firmware-Version "V 1.20.01 a-culfw" angezeigt. :(
Jemand eine Idee, bei welchem Schritt ich falsch "abgebogen" bin?
Xmodem als Dateiübertragungsprotokoll gewählt?
Beim Cube reichts, wenn du nachm Anschließen aufs Knöpfke drückst - muss nicht gedrückt angehängt werden.
Zitat von: defdanny am 02 November 2016, 20:46:52
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Datei senden" die aktuelle a-culfw für den Cube auswählen:
Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
Datei -> Transfer -> XMODEM -> Senden
Zitat von: rubbertail am 02 November 2016, 21:03:31
Xmodem als Dateiübertragungsprotokoll gewählt?
Beim Cube reichts, wenn du nachm Anschließen aufs Knöpfke drückst - muss nicht gedrückt angehängt werden.
Muss man schon, wenn schon eine Firmware drauf ist.
Oh - mea culpa - ich dachte, ich hätt das immer nachträglich... aber gut dann. Sorry.
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...
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
Zitat von: MAC66666 am 03 November 2016, 13:06:51
von 3 meiner Cubes wechselt immer einer die IP... interessanterweise zwischen 2 hin und her... sehr merkwürdig. Ich habe hier irgendwo gelesen, wie man eine feste IP vergeben kann, leider finde ich es nicht mehr...
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).
Zitat von: defdanny am 03 November 2016, 21:32:00
So, hier also das "Kochrezept" zum Flashen einer neuen Version der alternativen CUL-Firmware (a-culfw) auf den MAX!Cube.
Voraussetzungen:
- Bootloader ist bereits auf dem MAX!Cube installiert (siehe Anfang des Threads)
- Das Firmware-Update der a-culfw erfolgt bei dieser Methode über einen Windows-PC und das Windows-Tool "TeraTerm" (Download unter https://ttssh2.osdn.jp/index.html.en (https://ttssh2.osdn.jp/index.html.en))
1. Die a-culfw x.xx herunterladen und entpacken (Download unter https://github.com/heliflieger/a-culfw (https://github.com/heliflieger/a-culfw))
2. Das Tool "TeraTerm" auf Windows PC installieren
3. Der MAX!Cube per USB-Kabel an den Windows PC anschließen, dabei den "RESET"-Knopf an der Unterseite gedrückt halten. Der CUBE wird dadurch in den Bootloader-Modus versetzt (Die Power-LED blinkt schnell).
5. Das Gerät wird als "AT91 USB to Serial Converter" an COM3 (oder anderer COM-Schnittstelle) erkannt.
6. Unter Windows das Programm "Tera Term" starten, über "Datei --> Neue Verbindung --> Seriell" das Gerät an "COM3" auswählen.
7. Nun, wie am Anfang des Threads beschrieben, über "Datei --> Transfer --> XMODEM --> Senden" die aktuelle a-culfw für den Cube auswählen:
bspw. Datei "\a-culfw_v1.21.00_build_71\CUBe\CUBE_BL.bin" aus dem aktuellen a-culfw-Archiv
8. Die Dateiübertragung beginnt, nach wenigen Sekunden ist diese abgeschlossen.
9. Der CUBE startet neu wechselt wieder in den Betriebsmodus ("Power"-LED blinkt langsam). Die USB-Verbindung zum Windows-PC kann nun getrennt werden.
10. Done
@Telekatz Macht es vielleicht Sinn, so eine Anleitung als Readme zu den Quellen zu legen?
Ich werde es mal für das nächste Update ins Auge fassen.
So kann mittlerweile seit heute sagen das der Opend Status willkürlich von verschieden Hardware Komponenten ausgelöst werden kann. Dachte erst es liegt am Wandschalter von Max . Diesmal wars der Türkontakt von Max.
OK, hab eh gesehen das es einen Neue Firmeware gibt. Werde diese mal draufschmeissen und mal abwarten.
Das steht bei mir im Log mit Verbose 3 eigentlich nix brauchbares.
Bevor wieder das Opend dort steht wo eigentlich Intialized stehen sollte,
2016.11.05 16:00:35 1: 192.168.178.37:2323 reappeared (CUNO)
2016.11.05 16:09:36 2: CUNO IT_set: Balkon off
2016.11.05 17:03:32 2: CUNO IT_set: Garten on
2016.11.05 17:09:36 2: CUNO IT_set: Balkon off
2016.11.05 18:09:36 2: CUNO IT_set: Balkon off
2016.11.05 18:53:37 2: CUNO IT_set: Kueche on
2016.11.05 18:53:51 2: CUNO IT_set: Kueche off
2016.11.05 18:54:35 2: CUNO IT_set: Kueche on
2016.11.05 19:09:36 2: CUNO IT_set: Balkon off
2016.11.05 19:28:13 2: CUNO IT_set: Balkon on
2016.11.05 19:28:22 2: CUNO IT_set: Balkon off
2016.11.05 19:39:47 2: CUNO IT_set: Balkon on
Ab hier dürfte dann in Global das Opend stehten.....
2016.11.05 19:39:50 1: 192.168.178.37:2323 disconnected, waiting to reappear (CUNO)
2016.11.05 19:39:50 2: IT IODev device didn't answer is command correctly: raw => No answer
2016.11.05 19:40:02 3: CUNO: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz
2016.11.05 19:40:05 1: Cannot init 192.168.178.37:2323, ignoring it (CUNO)
2016.11.05 20:00:25 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:30 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:35 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:40 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:45 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:50 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:00:55 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
2016.11.05 20:01:00 1: Error in CUL_MAX_SendQueueHandler: CUL CUNO did not answer request for current credits. Waiting 5 seconds.
Und das geht dann endlos weiter..............................
Das mt dem Balkon sind die Raucher ;) Klar irgendwann sind die Credits weg.
Wie gesagt ist auch nicht nachvollziehbar , läuft 2 Wochen oder auch weniger und auf einmal steht dort Opend, klar um so weniger gebrauch der Funksignale um so länger gehts gut.
Küche ist ein Wandschalter von Max der eine Intetek Funksteckdose schaltet. Balkon ist ein Max Türkontakt der eine Intertek Unterputzdose schaltet. Und Garten ist ein Dämmerungsscript für eine Intertek Funksteckdose der ein Gartenlicht einschaltet.
Hast du deine Cube an einem Netzteil angeschlossen oder an einem funktionierenden USB Anschluss?
Ist am Orginalen Netzteil angeschlossen. Also auch währen der ganzen Opend Zeit Phasen ist der Cube am Leuchten soweit ich das beurteilen kann. Erst ein Neustart von Fhem verschafft abhilfe. Kann natürlich sein, das es garnicht dein Problem ist, sondern eher ein Problem des Entwicklers von Fhem. Aber da er davon nichst weiß und wir ein Querschiene fahren schwer zu vermitteln :)
Gruß
Leuchtet dabei auch die Battery LED?
Nein, Es blinkt wie gewonnt Power und Internet Leuchtet dauerhaft, aber ich werde das nochmal genau beobachten. An sich aber kann ich aber Blink und Leuchtverhalten keinen Unterschied feststellen.
Wenn er das nächste mal disconnected schau mal mit "get uptime" nach, ob sich die Zeit dabei zurückstellt. Das würde auf ein Auslösen des Watchdogs hindeuten.
OK, mache ich , danke erstmal für deine Unterstützung. Find es ja schon merkwürdig das ich der einzige bin der davon betroffen sein soll. :)
Unter dem Link für die Firmware im Haupt-thread gibt es leider keine Dateien zum herunterladen
https://www.mediafire.com/folder/tf16radvztfd9/a-culfw
Bei mir funktioniert der Link und es kommen die Dateien zum herunterladen.
Ansonsten hier der Direktlink zur aktuellen Version:
http://www.mediafire.com/file/c1xvkv19cz6kok2/a-culfw_1.21.01_build_77.zip (http://www.mediafire.com/file/c1xvkv19cz6kok2/a-culfw_1.21.01_build_77.zip)
Und weil in der aktuellen Version der Bootloader fehlt, die letzte mit Bootloader:
http://www.mediafire.com/file/viytrdbpwd3iibf/a-culfw_1.20.08_build_220_master.zip (http://www.mediafire.com/file/viytrdbpwd3iibf/a-culfw_1.20.08_build_220_master.zip)
Vielen Dank für den Direktlink. Vermutlich ist es ein Problem mit dem Safari. Probiere es später mal mit FF oder Chrome.
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?
Hallo zusammen,
zuerstmal: danke @Telekatz für die großartige Arbeit!
Ich hätte da jetzt aktuell ein kleines Problem. Mein erster Cube funktioniert hervorragend, flashen hat ohne Probleme geklappt, funktioniert bestens im Netzwerk.
Ich habe hier jetzt einen weiteren Cube liegen, der sich allerdings wehrt - gebraucht gekauft, hat aber wohl bisher funktioniert.
Zunächst mal Randdaten:
BC-LGW-O-TW
TRX868
Flashen mit dem aktuellen Binary und Bootloader aus der 1.20 lief problemlos, der Cube ist auch ansprechbar über die USB Schnittstelle, aber das Netzwerk will leider nicht.
Probiert hab ich schon Wechsel von Stromversorgung und Netzwerkkabel, DHCP und fixe IP... Über DHCP kommt an meinem DHCP Server leider nichtmal ein Request an. Ich hab den Thread hier jetzt schon kompltt durchgeackert, aber Lösung nicht wirklich gefunden... Hat da zufällig jemand ne Idee dazu, ausser dass das Netzwerkinterface Schrott sein könnte? Die "Internet"-LED kommt seitens des Cube allerdings...
Grüße
Marcus
Du könntest mal über ein serielles Terminal an der Debugschnittstelle ST2 schauen, ob er über DHCP eine Konfiguration bekommt. Die Belegung von ST2 gibt es hier: https://forum.fhem.de/index.php/topic,38404.msg332264.html#msg332264 (https://forum.fhem.de/index.php/topic,38404.msg332264.html#msg332264)
Zitat von: Kroegi am 20 November 2016, 11:26:04
Hab da grade auch so ein Phänomen mit dem Schätzchen.
Er lief jetzt von Anfang an ohne Probleme.
Nun stand da plötzlich "disconnectet", zum Glück habe ich zwei davon in Betrieb.
Also den ausgefallenen mal resettet, neu geflasht und aktuelle Firmeware drauf.
Er reagiert auch augenscheinlich ganz normal, hat ohne Fehler alles aufgenommen und Leuchtet / Blinkt wie eh und je.
Ich sehe ihn auch bei den Geräten in der Fritzbox, hat seine IP Adresse bekommen.
Nur in FHEM taucht er nicht mehr auf.
Was kann ich da noch grossartig machen?
Schon mal probiert, ihm eine feste IP Adresse zuzuweisen?
Zitat von: Telekatz am 20 November 2016, 17:40:04
Du könntest mal über ein serielles Terminal an der Debugschnittstelle ST2 schauen, ob er über DHCP eine Konfiguration bekommt. Die Belegung von ST2 gibt es hier:
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...)
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.
Zitat von: fireball2k am 20 November 2016, 19:18:37
Ne andere Frage noch, ist es möglich, beim Cube den native mode zu nutzen? Aktuell rebootet das Teil, wenn ich "Nr1" übergebe. Wenn ich den Define im Source der board.h aktiviere, hagelt es Compilerfehler... ;)
(Hintergrund: ich wollte mal bissele mit LaCrosse Sensoren rumspielen...)
Der native Mode ist doch schon lange aktiv. Seit V1.20.01.
Zitat von: Kroegi am 20 November 2016, 20:58:06
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)
Das probiere ich mal. Ich hab in der Tat vorgestern die Fritzbox LAN Anschlüsse auf Gigabit umgestellt. Den Betroffenen wo der störrische CUBe dran hängt kann ich aber nicht auf 100MBit zurück stellen weil da noch mehr dran hängt das die volle Geschwindigkeit haben sollte. Die Fritzbox hat dem CUBe eine IP Adresse zugewiesen, und zwar die gleiche wie vorher. Diese werd ich ihm dann händisch zuweisen. Hat der CUBe die Adresse dann nicht verinnerlicht oder wieso zickt er? Der 2. CUBe hängt auch am Gigabit, wurde aber seit dem umstellen nicht neu gestartet.
Hurra, das war wohl genau der richtige Tipp.
Hab beide CULs nun mit ihrer schon vorher vergebenen IP festgesetzt.
Nun sind beide wieder initialisiert und erreichbar.
DANKE!
Zitat von: Telekatz am 20 November 2016, 21:31:00
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
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).
Hallo,
bin neu hier und schon am verzweifeln :(
Wollte meinen CUBE zu einem CUN umflashen. Komme aber irgendwie nicht weiter.
Nachdem ich mir den Bootloader "bootloader_CUBE.bin" aus der Version 1.20.08 besorgt habe, habe ich ihn von meinem Notebook aus mit bossa auf den CUBE geschrieben.
Nach dem Einstecken des USB Kabels bilnkt die Power LED schnell.
Allerdings sehen die Meldungen im dmesg anders aus, als beschrieben.
Nov 28 18:15:17 HP8560p-HR kernel: usb 4-1.1: new full-speed USB device number 8 using ehci-pci
Nov 28 18:15:18 HP8560p-HR kernel: cdc_acm 4-1.1:1.0: ttyACM3: USB ACM device
Von "CUBELOADER" finde ich da nichts.
Wenn ich bossa neu starte findet er an den seriellen Schnittstellen auch kein passendes Device.
Ist der neue Bootloader nun drauf, oder nicht?
Mit der Beschreibung von minicom komme ich dann auch nicht weiter :(
bei CRTL-A Z passiert einfach nichts ....
Gibts da keinen passenden Befehl für die Kommandozeile?
Gruß
Henning
Zitat von: fow0ryl am 28 November 2016, 18:23:27
Ist der neue Bootloader nun drauf, oder nicht?
Wenn er schnell blinkt ist der Bootloader drauf.
Wir sind jetzt gerade etwas am Verzweifeln: der Max Cube wurde per Jumper gelöscht.
Beim Bootloader fingen dann die Probleme an, bis wir die Kiste ganz zerlegt hatten und gesehen haben daß dort ein 512KB Chip drin steckt.
Also damit geflasht, dann die Firmware. Alles lief ohne Fehlermeldung durch.
Also wieder per USB mit Power versorgt, ans LAN gehängt, Power blinkt, "Internet" leuchtet dauerhaft, aber der Würfel wird von der FB nicht gefunden.
Bzw. wir haben ein unbekanntes Gerät drin auf .103, bekommmen aber keine Verbindung von fhem aus.
Mit "define ml MAXLAN 192.168.2.103" versucht anzumelden, "disconnected". Mit "define max_LAN CUL 192.168.2.103:2323 1034" passiert das selbe.
Und per USB am RasPi hängend haben wir es mit:
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456
probiert, es kommt auch keine Verbindung zustande.
Wo liegt der Fehler? Oder wo KÖNNTE er liegen?
Hallo,
mühsam ernährt sich das Eichhörnchen ...
Ich habe die Firmware inzwischen auf den Cube flashen können.
Laut Telekatz war schnelles blinken der Power LED ein eindeutiges Kennzeichen dafür, das der Bootloader drauf war.
Mit Minicom bin ich allerdings nicht weiter gekommen. CTRL-Z hat einfach zu Null Reaktionen geführt. Egal ob dirket auf der Konsole, im Xterm oder im QTerminal.
Und die Parameter für die Kommandozeile habe ich nicht wirklich verstanden.
Daher habe ich dann mit einem Windows 10 Notebook weitergemacht. Zunächst mal SAM-BA installiert. Sofort wurde ein neues USB Gerät AT91 erkannt.
Ein Versuch den Bootloader mit SAM-BA neu zu schreiben wurde sinngemäß mit der Meldung "Inkompatibles Device" quittiert.
Dann einfach mit TeraTerm wie in der Anleitung die Firmware geflasht.
Nach dem Neustart des Cube (USB Kabel ziehen und wieder anstöpseln) blinkt die Power LED langsam und die BATTERY LED leuchtet permanent.
Ganz anders unter Linux. Dort blinkt die POWER LED. Ansonsten passiert nichts...
Merkwürdiges Verhalten. :-\
Na ja. Hatte dann erst mal im FHEM Server die Definitionen wie in diesem Thread beschrieben eingetragen. Als IP Adresse habe die Adresse verwendet, die der Cube vorher hatte. (Im Router bzw. der dnsmaq config war die MAC der IP ja fest zugeordnet)
define CULCuBE_1 CUL 192.168.1.40:2323 0000
attr CULCuBE_1 rfmode MAX
attr CULCuBE_1 room CUL
define culmax_1 CUL_MAX 654321
attr culmax_1 IODev CULCuBE_1
Und es passierte .... Richtig. Nichts.
Nach einer Weile habe ich dann bemerkt das sich ein neues unbekanntes Gerät per DHCP eine IP Adresse geholt hat. Hm. Wie das?
Angepingt, Kabel gezogen. Siehe da. Der Cube hatte einen andere MAC als zuvor. Unschöner Nebeneffekt aber lösbar. Man muss nur wissen wonach man suchen muss :(
Nächster Schritt wird das Anlernen von Thermostaten sein. Mal sehen über was ich da noch stolpere.
Für einen Anfänger jedenfalls nur mit Durchhaltewillen zu bewerkstelligen.
Das Thema Linux verliere ich noch nicht aus den Augen. Ich möchte meinen zweiten Cube ja auch noch umflashen...
Gruß
Henning
Zitat von: Lupo am 02 Dezember 2016, 18:14:45
Und per USB am RasPi hängend haben wir es mit:
define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456
probiert, es kommt auch keine Verbindung zustande.
Wo liegt der Fehler? Oder wo KÖNNTE er liegen?
Rechte korrekt vergeben?
http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt (http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt)
Zitat von: Telekatz am 02 Dezember 2016, 19:34:22
Rechte korrekt vergeben?
http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt (http://www.fhemwiki.de/wiki/CUL_am_Raspberry_Pi_flashen#CUL_wird_nicht_.28richtig.29_erkannt)
DANKE, das wars!!!
Hallo
Super Projekt. Danke an Telekatz und alle anderen. Ich konnte meinen MAXCube in einen CUL umflashen.
Hier aber noch ein paar Anmerkungen, damit andere Neulinge nicht dieselben Fehler wie ich machen:
- 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
Als erstes auch von mir ein großes Lob: Super Projekt!
Bei mir hat folgendes soweit funktioniert, dass der MAX!CUBE eine IP Adresse bekommt, in FHEM eingebunden werden kann und zumindest schon mal ein Gerät (Hoermann Garagentor) automatisch erkannt hat.
Vorbereitung und Flashen
- 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):
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:
telnet 10.10.10.10 2323Verbindung funktioniert.
Dann den Cube in die fhem.cfg eingetragen. Zum Testen aktiviere ich autocreate.
define autocreate autocreate
attr autocreate autosave 1
attr autocreate filelog ./log/auto-%NAME-%Y.logDann der Cube (rfmode SlowRF ist nur zum Testen):
define CULCuBE_1 CUL 10.10.10.10:2323 0000
attr CULCuBE_1 icon cul_868
attr CULCuBE_1 rfmode 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:
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:
? (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?
Zitat von: cs1711 am 07 Dezember 2016, 20:35:46
Nun aber noch zu meinem Problem. Setze ich den Toggle-Befehl für CUL_HOERMANN ab, kommt im Telnet-Fenster nur folgendes:
? (hn91B4E26F86 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f l t x z
und nichts weiter passiert. Hat jemand eine Idee, was da schief geht?
HOERMANN_SEND war für den Cube nicht aktiviert. Kommt mit der nächsten Version.
Jetzt muss ich noch mal was fragen.
Der Cube läuft. Jetzt wollte ich ihn im Homematic-Modus laufen lassen und mit einem Homematic IP Heizkörperthermostat pairen. Meine Config sieht wie folgt aus:
define CULCuBE_1 CUL 192.168.10.67:2323 0000
attr CULCuBE_1 icon cul_868
attr CULCuBE_1 rfmode HomeMatic
attr CULCuBE_1 hmId CED68B
attr CULCuBE_1 verbose 5
Über die Kommandozeile versetze ich - so hoffe ich - den Cube in den Pairing-Modus:
set CULCuBE_1 hmPairForSec 600
Dann drücke ich die Pairing-Taste auf dem Thermostat und es passiert... nichts... LED blinkt langsam gelb vor sich hin, das war's... hat jemand eine Idee, wo das Problem liegen könnte?
Homematic IP funktioniert nicht mit einem CUL.
Ah, ok, danke für die Info, irgendwie habe ich das schon befürchtet bzw. meine es irgendwo gelesen zu haben (konnte es aber nicht wiederfinden).
Liebe Experten,
ich schon wieder... ich hoffe, ich habe nicht wieder irgendwo etwas überlesen...
Cube war erfolgreich geflasht, soweit, so gut. Cube läuft jetzt im Homematic Modus, allerdings will das Pairing scheinbar nicht funktionieren (Details siehe Post https://forum.fhem.de/index.php/topic,62373.0.html). Der HM-LC-SW1-FM ist ja ein Homematic Aktor, daher müsste es doch eigentlich funktionieren...
Woran kann es liegen? Frage stelle ich hier (zusätzlich), weil es ja irgendwas mit der a-culfw zu tun haben könnte...
Viele Grüße
Christian
Nachtrag: Problem gelöst, siehe https://forum.fhem.de/index.php/topic,62373.0.html.
Habe gerade ebenfalls einen Max!Cube (TRX868-TI) erfolgreich unter Linux mit bossa und minicom geflasht. 8)
Danke an Telekatz für die SW.
Danke auch an Christian (cs1711) für die übersichtliche Zusammenfassung.
Das mit den vertauschten Readmes in CUBe und MapleCUL hat mich allerdings auch verwirrt. ???
Micky
Zitat 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?
Woran sieht man jetzt welchen Chip man drauf hat? Ich finde keiner der beiden Bezeichnungen auf der Platine vom Cube.
Auf der Unterseite des Gehäuses.
Da steht nur TRX868.
Hi all.
Sorry for posting in English.
I am trying to learn how to compile the firmware for the Cube on the raspberry pi.
I have downloaded the latest version of the source code 1.23.04.
I have downloaded the toolchainGNU ARM Embedded Toolchain 5-2016-q3-update.
I have updated my path temporarily in the Pi to add path to the toolchain (PATH=$PATH:/home/pi/t2/gcc-arm-none-eabi-5_4-2016q3/bin)
I then navigated to the Devices directory in the CUL source code on the pi.
Then I typed make but received error before it had got very far that avr-gcc not found.
So installed the various tools with command
sudo apt-get install gcc-avr binutils-avr avr-libc
and tried again, this time it ran through compiling for all devices but errors when getting to the CUBe it does the clean bit, then starts but gives this error.
make -C CUBe
make[1]: Entering directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
make OUTPUT=CUBE_BL target
make[2]: Entering directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
arm-none-eabi-gcc -g -Os -fno-isolate-erroneous-paths-dereference -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S
/home/pi/t2/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: 1: /home/pi/t2/gcc-arm-none-eabi-5_4-2016q3/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")")
Makefile:121: recipe for target '../../at91lib/board_cstartup.o' failed
make[2]: *** [../../at91lib/board_cstartup.o] Error 2
make[2]: Leaving directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
Makefile:96: recipe for target 'CUBE_BL' failed
make[1]: *** [CUBE_BL] Error 2
make[1]: Leaving directory '/home/pi/t2/culfw12304/culfw/Devices/CUBe'
Makefile:2: recipe for target 'all' failed
make: *** [all] Error 2
I have tried with an earlier version 1.20.00 and get same error.
Anyone suggest what I might be doing wrong?
Many thanks
Regards
Did you build the toolchain on the raspberry from the sources, or did you use the precompiled package (which i think is only for x86)?
Thanks for the prompt response.
I followed the link on the first posting for the toolchain used.
(https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update))
On the link was a Linux installation tarball which I downloaded and extracted to the pi.
(gcc-arm-none-eabi-5_4-2016q3-20160926-linux.tar.bz2)
Am I more likely to have success doing this from windows which I am more familiar with?
Thanks
Yes, try it with windows.
OK for anyone else who wants to try, this is what worked for me.
Download the GNU ARM Embedded Toolchain from the below link and install on your windows pc.
https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update)
Dwonload GNU ARM Eclipse Windows Build Tools and extract
https://github.com/gnuarmeclipse/windows-build-tools/releases (https://github.com/gnuarmeclipse/windows-build-tools/releases)
Download and extract your source files.
Find the gccvar.bat file in the GNU ARM Embedded Toolchain and edit the set path statement to include the bin file from the build tools directory so that when it is run the path will include the bin directory to both the embedded tool chain and the bin directory from build tools. My files were installed to short directory names so teh edited set path line looked like
set PATH=%TL_PATH%;C:\z1\bt\bin;%PATH% where C:\z1\bt\bin; was the bit for the build tools directory.
Navigate to the directory for the Device you wish to compile in the command prompt and execute the gccvar.bat directory directly from there.
Type make clean and press enter to ensure all old compiled stuff has been removed.
Type make enter and it should compile the file.
The last bit of the output from the make command was a listing of the files it created like below.
e 93640 1312 24340 119292 1d1fc CUBE_BL.elf
arm-none-eabi-objcopy -O binary CUBE_BL.elf CUBE_BL.bin
arm-none-eabi-size CUBE_BL.elf
text data bss dec hex filename
93640 1312 24340 119292 1d1fc CUBE_BL.elf
make[1]: Leaving directory 'C:/z1/a-culfw-1.23.02/culfw/Devices/CUBe'
For those of you who use the cube and get frustrated with credits I have a version which I think returns credits based on the led light setting off = std, ON = X2 return of credits, FLASHING = X3 return of credits
https://forum.fhem.de/index.php/topic,59968.msg544950.html#msg544950 (https://forum.fhem.de/index.php/topic,59968.msg544950.html#msg544950)
Hallo Telekatz,
habe den Maxcube erfolgreich umgeflasht und wollte LaCross Temperatursensoren auslesen.
Flashen und das Verbinden mit Cube funktioniert über Netzwerk und USB.
Wenn ich den Native Mode auf 2 (Nr2) stelle, startet der CUBE neu?
Es werden auch keine Meldungen angezeigt. Nur bei X2F werden Flanken erkannt.
Ich habe zum Testen leider noch keine anderen Geräte, ausser einen TX48WD-IT.
Unterstützt die Firmware LaCrosse oder geht das nur mit einen CUL von Busware ?
Edit: a-culfw_1.23.04 geflasht
Seitdem ich wieder von Testung auf Jessie umgestiegen bin lässt sich a-culfw nicht mehr kompilieren auf dem Pi:
make: Entering directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
make OUTPUT=CUBE_BL target
make[1]: Entering directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
arm-none-eabi-gcc -g -Os -fno-isolate-erroneous-paths-dereference -I. -I../../at91lib -D__ASSEMBLY__ -Dflash -c -o ../../at91lib/board_cstartup.o ../../at91lib/board_cstartup.S
arm-none-eabi-gcc: error: unrecognized command line option '-fno-isolate-erroneous-paths-dereference'
Makefile:121: recipe for target '../../at91lib/board_cstartup.o' failed
make[1]: *** [../../at91lib/board_cstartup.o] Error 1
make[1]: Leaving directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
Makefile:96: recipe for target 'CUBE_BL' failed
make: *** [CUBE_BL] Error 2
make: Leaving directory '/usr/local/src/a-culfw/culfw/Devices/CUBe'
arm-none-eabi-gcc ist Version 4.8.4. Benötige ich eine andere Version? Ich konnte zu '-fno-isolate-erroneous-paths-dereference' nichts im Netz finden.
Zitat von: Telekatz am 27 November 2016, 19:08:03
Zur Info für diejenigen, die die Firmware selbst compilieren:
Mit der letzten Version kam die Unterstützung für STM32 Controller hinzu. Dabei habe ich auch auf eine aktuelle Version der ARM Toolchain umgestellt. Aktuell sollte diese Version verwendet werden: https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update (https://launchpad.net/gcc-arm-embedded/5.0/5-2016-q3-update).
Die Option '-fno-isolate-erroneous-paths-dereference' kam mit 4.9 hinzu.
Danke! Das erklärt auch, warum es unter Testing noch funktioniert hat. Da ist ein 4.9er GCC dabei.
Danke Telekatz
Mit der neusten Firmware (a-culfw_1.23.05_build_132 )funktioniert der Nativ Mode wieder.
2016.12.29 11:20:27 5: SW: Nr1
2016.12.29 11:20:27 5: CUL/RAW: /01
2016.12.29 11:20:27 4: CUL_Parse: CUL868 01
2016.12.29 11:20:27 2: CUL868: unknown message 01
2016.12.29 11:20:31 5: CUL/RAW: /N0196A6332D9CAAAA0000321479
Hallo,
Ich hätte zu dem Thema mal eine Frage.
Ich habe jetzt 5x MAX Heizkörperthermostat Basic.
Wenn die den MAX CUBE zum CUL umflashe ist er ja eigentlich wie ein CUL/CUNO.
Unterstützt er dann nur das MAX System, oder kann ich ihn auch auf andere Systeme wie Homematic, FS20 usw. konfigurieren?
Wenn ich mich richtig erinnere kann ich pro CUL/CUNO nur 1 System konfigurieren?
Eine andere Idee war das ich einen alten RPI1 + COC konfigurieren und mit FHEM2FHEM verknüpfe.
Aber dann kann ich vom Master Fhem Server (Ubuntu) nicht via FHEM2FHEM über den RPI 1 Daten senden?
Oder sit hier eine Lösung mit ser2net besser und stabiler?
Hi,
I'm sorry, but I don't speak German.
I hope somebody has the patience to answer in English!
I have just reflashed my CUBE with the CUL firmware (latest version).
It works - I can give it commands over the USB connection using Tera Term and it replies with the correct version information.
I had hoped that I could connect it using Ethernet, but that doesn't seem to work.
Looking at the board.h file the Ethernet options are commented out.
Am I right in assuming that Ethernet is not supported?
If so, are there any plans to support it?
Are there any fundamental problems that prevent Ethernet being supported?
Thanks,
Alan
Hi,
I'm sorry, but I don't speak German.
I hope somebody has the patience to answer in English!
I have just reflashed my CUBE with the CUL firmware (latest version).
It works - I can give it commands over the USB connection using Tera Term and it replies with the correct version information.
I had hoped that I could connect it using Ethernet, but that doesn't seem to work.
Looking at the board.h file the Ethernet options are commented out.
Am I right in assuming that Ethernet is not supported?
If so, are there any plans to support it?
Are there any fundamental problems that prevent Ethernet being supported?
Thanks,
Alan
Hi,
Ignore my question.
I have now got it connected over Ethernet.
It just needed re-booting.
Thanks,
Alan
Hi,
(sorry this is in english)
I'm trying to build a-culfw from source but I can't get it to work, perhaps someone could point out where I'm going wrong.
I tried running in win7 but that seemed to have so many issues I gave up on that and tried on my raspberry pi. apt-get only installs gcc-arm tool 4.8 so I've had to install 5_2-2015q4 from the tar. I put that in a ~/tools directory rather than clutter /usr etc.. I've edited the makefile in CUBe directory but when I run make from that directory (as root) I get this:
make OUTPUT=CUBE_BL target
make[1]: Entering directory '/root/a-culfw-master/culfw/Devices/CUBe'
~/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc -mcpu=arm7tdmi-s -Wall -Wno-strict-aliasing -Wno-unused-but-set-variable -mlong-calls -ffunction-sections -std=c99 -Dflash -DCUBE_BL -DTRACE_LEVEL=4 -DDBGU_UNIT_IN -g -MMD -MP -MF .dep/main.o.d -Os -fno-isolate-erroneous-paths-dereference -I. -I../.. -I../../at91lib -I../../at91lib/usb -I../../clib -I../../at91lib/avr -I../../avr-uip/uip -I../../avr-uip -I~/tools/gcc-arm-none-eabi-5_2-2015q4/arm-none-eabi/include -c -o main.o main.c
/root/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc: 1: /root/tools/gcc-arm-none-eabi-5_2-2015q4/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")")
Makefile:124: recipe for target 'main.o' failed
make[1]: *** [main.o] Error 2
make[1]: Leaving directory '/root/a-culfw-master/culfw/Devices/CUBe'
Makefile:96: recipe for target 'CUBE_BL' failed
the makefile changes are
ARMBASE = D:/a-culfw-master/gcc-arm-none-eabi-win32
INCLUDEPATH = $(ARMBASE)/arm-none-eabi/include
LIBPATH = $(ARMBASE)/arm-none-eabi/lib
ARMPATH = $(ARMBASE)/bin
TOOLPREFIX = /arm-none-eabi-
#OPENOCDPATH = F:\Tools\OpenOCD
#OPENOCD = $(OPENOCDPATH)\openocd.exe -f $(OPENOCDPATH)\target\sam7x256.cfg -f $(OPENOCDPATH)\interface\uniprog.cfg
TIA
I asssume, that the binaries in the tar are compiled for x86 and doesn't run on a pi.
If you want to compile the Firmware wit 4.8, you have to remove the -fno-isolate-erroneous-paths-dereference parameter in the OPTFLAGS.
DOH! Of course. I was just looking at the linux and not the processor (which isn't mentioned otherwise I might have realized that). I'll try 4.8
This was my post on how I managed to get to compile with Windows.
https://forum.fhem.de/index.php/topic,38404.msg544992.html#msg544992 (https://forum.fhem.de/index.php/topic,38404.msg544992.html#msg544992)
I was struggling to get the pi to compile with my lack of experience.
Hallo zusammen,
Zunächst mal allen hier ein gesundes und erfolgreiches 2017!
Ich bin neu hier und habe erfolgreich die alternative FW von Telekatz installiert. Vielen Dank an dieser Stelle für die geleistete Arbeit!!!
Da ich nicht regelmäßig nach neuen Versionen schauen kann und will, habe ich mir ein kleines Helferchen gebaut, das einmal pro Tag nach Updates sucht.
Die fhem.cfg habe ich wie folgt erweitert:
define CULFW_Version dummy
define aCULFW_Version dummy
define versionInfo readingsGroup <%cul_cul>,<aktuelle Version>,<neueste Version> \
CULFW_Version:current,latest \
aCULFW_Version:current,latest
attr versionInfo valueStyle {if($READING eq "latest"){my $t=$VALUE;;my $d=ReadingsVal($DEVICE,'current',0);;if($t ne $d){'style="color:rgb(251,63,11);;"'}}}
attr versionInfo group Versionsinfos
Die 99_myUtils.pm wurde um den nachfolgenden Code ergänzt:
sub checkCulFwVersions($) {
my ($hash) = @_;
####################################################################
# standard CUL firmware version
####################################################################
my $changeLogUrl = "http://culfw.de/CHANGED";
my $response = get( $changeLogUrl );
if (defined $response) {
my $latestCulFirmwareVersion = ( split /\n/, $response )[0];
$latestCulFirmwareVersion =~ /Version\s+(.*?)\s+\(.*?\)/;
$latestCulFirmwareVersion = $1;
fhem("setreading CULFW_Version latest $latestCulFirmwareVersion");
}
####################################################################
# MAX!Cube CUL alternative firmware version (@see http://bit.ly/2i3NE81)
####################################################################
my $aculfw_url = "http://bit.ly/2iCgKyH";
my $aculfw_response = get( $aculfw_url );
if (defined $aculfw_response) {
my $aculfw_list = JSON->new->ascii->decode($aculfw_response);
my $list = $aculfw_list->{'response'}->{'folder_content'}->{'files'};
my $aculfw_entrycount = scalar(@{ $list });
if ($aculfw_entrycount > 0) {
my $aculfw_entry = $list->[-1];
my $aCulFwVersion = $aculfw_entry->{'filename'};
$aCulFwVersion =~ /a-culfw_(.*?).zip/;
$aCulFwVersion = $1;
$aCulFwVersion =~ tr/_/ /;
fhem("setreading aCULFW_Version latest $aCulFwVersion");
}
}
RemoveInternalTimer( $hash );
my $interval = 60*60*24;
InternalTimer(gettimeofday() + $interval, "checkCulFwVersions", $hash, 1 );
}
Das Ergebnis kann man hier (http://bit.ly/2j2bIvS) betrachten.
Vielleicht hilft's ja dem ein oder anderen...
Viele Grüße
Daniel
Hallo,
nach dem ich es geschafft habe, den CUBe zu flashen, läuft er über USB mit /dev/ttyACM0@38400 0000 sofort. Was muss ich machen, um dem ins Netzwerk einzubinden - die IP habe ich, aber welche Port ? Oder brauche ich keinen?
Wäre nett, wenn mir mal jemand auf die Sprünge helfen könnte.
Gruß Christoph
https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten (https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten)
Zitat von: Bennemannc am 04 Januar 2017, 16:40:54
Was muss ich machen, um dem ins Netzwerk einzubinden - die IP habe ich, aber welche Port ?
Meinst du vielleicht das hier, um den Cube als Netzwerk-CUL einzurichten?
define MaxCubeLAN CUL 192.168.0.55:2323 0000
Wenn deine IP Adresse 192.168.0.55 ist, ja.
Hallo,
so habe ich das auch gemacht. Die IP und der Port ist 2323. Beim CFG-LAN ist es 1000 bei ESP-Link die 23 --- sehr verwirrend. Könnte man sich - zumindest für die selbstgeschriebenen Sachen nicht auf einen Port einigen? Das wäre für Leute die damit neu anfangen einfacher.
Gruß Christoph
Die Leute, die damit neu anfangen, können und sollten sich auch die Dokumentation in der commandref ansehen. Da steht es auch drin.
Define
define <name> CUL <device> <FHTID>
USB-connected devices (CUL/CUN):
<device> specifies the serial port to communicate with the CUL. The name of the serial-device depends on your distribution, under linux the cdc_acm kernel module is responsible, and usually a /dev/ttyACM0 device will be created. If your distribution does not have a cdc_acm module, you can force usbserial to handle the CUL by the following command:
modprobe usbserial vendor=0x03eb product=0x204b In this case the device is most probably /dev/ttyUSB0.
You can also specify a baudrate if the device name contains the @ character, e.g.: /dev/ttyACM0@38400
If the baudrate is "directio" (e.g.: /dev/ttyACM0@directio), then the perl module Device::SerialPort is not needed, and FHEM opens the device with simple file io. This might work if the operating system uses sane defaults for the serial parameters, e.g. some Linux distributions and OSX.
Network-connected devices (CUN(O)):
<device> specifies the host:port of the device, e.g. 192.168.0.244:2323
If the device is called none, then no device will be opened, so you can experiment without hardware attached.
The FHTID is a 4 digit hex number, and it is used when the CUL talks to FHT devices or when CUL requests data. Set it to 0000 to avoid answering any FHT80b request by the CUL.
Ich habe leider ein Problem mit meinem auf culfw geflashten Cube.
Viele Wochen problemlos im Einsatz, wurde er auf einmal von fhem nicht mehr erkannt ("no answer").
Auf dem seriellen Interface konnte ich ihm dann nur ein "Cubeloader V1.01" entlocken, woraus ich nehme das er wohl irgentwie seine Firmware verloren hat ?
Versuche ihn neu zu flaschen (habe die Versionen 1.20.08(von dieser der Bootloader), 1.21.01 sowie die aktuelle 1.23.05 versucht) enden entweder in einem nicht vollständigen Transfer (alle Led sind aus) oder darin, das D3 permanent leuchtet und D1 etwa im sekundentakt blinkt. Jedoch erhalte ich kein serielles Interface und wenn ich den Cube neu verbinde ist er wieder im flash-Modus (D1 schnell am blinken) und ich erhalte wieder nur "Cubeloader V1.01" auf ein großes V.
Was ist zu tun?
Grüße und besten Dank
Schau mal nach, ob der Taster an der Unterseite hängt.
Nein, der scheint freigängig zu sein.
Edit:
Muss mich korrigieren, nachdem ich den Plastiktaster hochgebogen hatte und den Taster mehrfach betätigt habe scheint das Problem gelöst.
Vielen Dank, schon merkwürdig das der Schalter das auf einmal macht - hattest du so einen Fehler schon?
Nein, aber das ist der einzige Grund, warum er trotz geladener Firmware immer wieder in den Bootloader springen würde.
Hallo,
vielleicht habe ich es auf den 46 Seiten des Threads überlesen, aber zumindest in der aktuellen Version auf Mediafire gibt es im CUBe Verzeichnis keine bootloader_CUBE.bin Datei, nur die CUBE_BL.bin. Wo finde ich den Bootloader?
Danke schon mal und Gruß,
F.
Mehrfach überlesen ;) Habe auch lange gesucht.
Schau mal in den Vorgängerversionen, dort findest du sie.
Gesendet von meinem HTC One_M8 mit Tapatalk
Danke für die schnelle Rückmeldung! Nun habe ich den Bootloader geflasht (unter Mac OSX mit bossash), habe nun aber das Problem, dass beim Einstecken die D1-LED nur einmal kurz aufblinkt. Auch beim Drücken des Reset-Tasters ändert sich das nicht, nur bei jedem 10. Versuch leuchtet die LED durchgängig auf. Ich habe dann in beiden Modi immer mal wieder einen XModem-Upload probiert, und ich weiß nicht, ob es damit zusammenhängt, aber manchmal erschien dann in dem Zusammenhang im Terminal Programm die Kennung CUBELOADER V1.01. Aber auch dann startete der XModem-Upload nicht.
Von daher meine Frage, ob man den Upload im Bootloader noch irgendwie aktivieren muss (ich habe irgendwo was von Shift + V gelesen)?
Und kann/sollte ich sonst den Bootloader noch einmal neu flashen? Unter bossash wird mir nun allerdings nach einem Scan kein Gerät mehr angezeigt, das geflasht werden könnte, auch nach erneutem Schließen von JP1.
Edit: Das Schließen des Jumpers hat nun doch dazu geführt, dass ich den Bootloader neu schreiben konnte, aber jetzt mit dem Ergebnis, dass danach nun gar keine LED mehr leuchtet (außer D2 und D3 für den Bruchteil einer Sekunde beim USB-Kabel-Einstecken) und ich nurmehr über JP1 wieder zum Bootloader-Flashen zurück muss. Sehr seltsam...
Edit: Nach gefühlten Dutzend Versuchen jetzt einmal mit der Bossa GUI probiert, geschrieben, verified, zuerst nichts, dann auf Info geklickt (wo mir vorher die Chip-Infos des Cube angezeigt wurden), da kam dann eine Fehlermeldung und die LED D1 blinkt nun wieder 4x pro Sekunde. Upload klappt immer noch nicht, wenn ich dann den Cube abziehe und wieder anstecke, blinkt die LED zuerst wieder, um dann dauernd zu leuchten.
Freue mich über jeden Hinweis, vielen Dank und gute Nacht,
F.
Folgendes konnte ich jetzt reproduzieren:
- Der Flash-Speicher scheint nicht immer korrekt geschrieben zu werden. Wenn ich nach dem Schreiben das Flash auslese, sind in mehreren Fällen nur "ff" in den Speicherstellen gewesen. Manchmal (mit unterschiedlichen Kabeln getestet) hatte ich Glück und das Verify hat keine Fehler ergeben.
- Wenn das Verify erfolgreich war, hat LED D1 nach dem Wiedereinstecken ein paar Sekunden lang realtiv schnell geblinkt, dann war sie aus. Beim Wiedereinstecken leuchtet sie jetzt einmal kurz auf und ist dann aus.
- Ein Zugriff über minicom hat auch mit Shift-V nichts gebracht, obwohl zwei Devices beim Einstecken angelegt werden (cu.usbmodem1421 für das USB-Device und tty.usbmodem1421 für das serielle).
Entweder habe ich mehrere schlechte Kabel, von denen einige weniger schlecht sind als andere und dann zumindest beim Schreiben mal funktionieren oder es gibt sonst noch eine Schwachstelle, die dafür sorgt, dass die Kommunikation zum einen beim Flashen, zum anderen beim späteren Zugriff über das Terminal nicht in Ordnung ist.
Freue mich über jeden Tipp, vielen Dank schon mal,
F.
Ok, habe es nun selber lösen können, vielleicht sind meine Problemschilderungen aber für andere Mac-Besitzer von Nutzen:
Mit einem alten Ubuntu-Laptop hat das Flashen nun gleich auf anhieb geklappt (gleich auch mehrfach getestet). Allerdings hat der selbst kompilierte Bootloader den Effekt gezeigt, dass die LED D1 eben nur 1-2 Sekunden schnell geblinkt hat und dann auf Dauerleuchten gegangen ist. Ein Flashen der Firmware über ein Terminalprogramm (hier auch minicom) funktionierte hier nicht.
Ich habe dann aus der Version 1.20.08_build_220 die bootloader_CUBE.bin genommen, diese geflasht und dann blinkte D1 dauernd schnell. Nach dem Ab- und Anstecken des Cubes konnte ich dann mit minicom die Firmware hochladen. Hier funktioniert interessanterweise auch die selbst kompilierte Version (mit Toolchain 5.4.1). Nach dem Flashen konnte ich dann mit dem Terminal den Cube (bzw. jetzt CUL :) ) konfigurieren und er empfängt fleißig die Nachrichten meiner Max-Geräte :).
Was das Problem jetzt am Mac war, konnte ich nicht weiter identifizieren. Seltsam ist das schon, denn das Flashen meines Busware-Sticks hat ohne Probleme funktioniert. Im Übrigen hatte ich auch kein Glück mit Windows XP unter Parallels Desktop auf dem Mac, dort wurde zwar der resettete Cube von Windwos auch erkannt, aber Bossa hat ihn nicht als flashbares Gerät gesehen. Ich habe da dann auch nicht weiter Zeit hineingesteckt. Ein alter Laptop mit einem Linux-Derivat ist da vielleicht doch immer noch die einfachste Variante.
Gruß und Danke auf jeden Fall noch mal an Telekatz für diese tolle Arbeit!
F.
Hallo,
ich habe einen Max!Cube mit der Version a-culfw_1.23.05 geflashed und in fhem eingebunden. Jetzt möchte ich meine TechemHKV über WMBus_T empfangen, es wird aber nichts angezeigt/empfangen. Bis jetzt hat das über eine andere CUL (COC) gut funktioniert.
Sollte das auch mit a-culfw funktionierten, bzw. muss man noch etwas einstellen?
Danke im Voraus,
Tom
Probier mal, ob es mit der angehängten Version funktioniert.
:-) geht ... alles super ;) !!
Eine Frage hätte ich noch, wobei ich nicht weiß, ob ich die hier oder woanders stellen sollte:
In den Changelogs der a-culfw steht schon für Version 1.20.05
- Code upgrade from culfw Version 1.66 (2015-11-29)
Wenn ich aber nach dem Einspielen einer selbstkompilierten a-culfw 1.23.05 in den FHEM-Logs nach der Initialisierung des Cubes nachschaue, steht dort
CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
Liegt das ggf. daran, dass für das CUBe-Device eine ältere culfw zur Grundlage genommen wird? Oder liegt der Grund doch in der a-culfw als Gesamtpaket?
Ich hatte bisher einen Busware Stick mit FW 1.66 am Laufen und jetzt eben noch den Cube und frage mich, welches Gerät ich nun an FHEM laufen lasse - der Cube wäre wegen Netzwerk eigentlich praktischer, aber wenn kein Update auf aktuellere FW-Versionen möglich sein sollte, dann würde ich noch mal genauer nach den (für mich relevanten) Unterschieden zwischen den Firmwareversionen suchen...
Danke und Gruß,
F.
CUL_MAX prüft nur, ob die Firmware des CUL mindestens Version 154 ist, weil es vor dieser Version Bugs mit MAX gibt. Wird die a-culfw von CUL_MAX erkannt, wird immer 154 als Version angenommen, unabhängig davon welche Version die a-culfw hat.
Danke für die schnelle Antwort, dann ist ja alles fein :)!
Hallo zusammen,
ich habe mir gestern einen Max Cube bestellt und wollte gerade das Teil flashen, aber ich fürchte da ist was in die Hose gegangen. Wie beschrieben habe ich J1 verbunden, USB eingesteckt und wieder abgezogen, die Verbindung entfernt und wieder an den USB Port angesteckt aber es passiert leider nix. Beim einstecken blitzen auf dem Board D1 D2 D3 einmal kurz auf und mehr passiert nicht. Da der Cube auch unter seiner standart IP Adresse nicht mehr erreichbar ist vermute ich mal, der ist hinüber? Dummerweise habe ich ihn vorher nicht gestest, kann somit nicht ausschließen dass der Cube von Anfang an defekt war. Retten lässt sich da vermutlich nix mehr oder?
Nach dem Reset über J1 ist das normal. Du musst jetzt erst einmal wie in Post #1 beschrieben, den Bootloader flashen. Erst wenn der drauf ist, blinkt LED D1 dauernd und ist bereit für das Flashen der Firmware.
Danke für die schnelle Antwort, aber der Cube wird garnicht erkannt, also auch kein neuer Com-Port wie es da steht. Deshalb kam ich darauf dass der hinüber sein könnte
Hmmmm nääää. Schon gut. Habs jetzt mal mit dem original USB Kabel probiert welches beim Cube beiliegt und siehe da ein neuer Comport. Mit meinem USB Kabel womit ich andere Geräte betreibe gehts nicht. Da muss auch einer drauf kommen .Dankööö
Hallo,
das liegt daran, das in dem USB Stecker am Cube 5 Pole sind. V+,GND,D+,D- und mit dem 5ten machen manche Hersteller was besonderes - offen, auf Masse - keine Ahnung was noch und lassen ihr Gerät darauf prüfen. Zur reinen Stromversorgung kann man jedes Kabel nehmen - das ist ja Norm, aber für andere Sachen, kann das schon mal scheitern.
Gruß Christoph
Ich würde doch noch mal im Hilfe bitten wollen. Denn Sam-ba macht irgendwie probleme. Der Cube ist jetzt leer und wird auch als Comport erkannt, in Sam-ba wähle ich den Port dann aus und wähle das Board wie in Post 1 ausführlich erklärt. Eigentlich ja total simpel, aber nach dem connect passiert nichts mehr. Eigentlich müsste sich dann ja ein neues Fenster öffnen wo man den Bootloader auswählen kann aber das kommt nicht. Der Prozess sam-ba läuft aber weiterhin. Wenn jemand eine Idee hätte wäre das super. Ich habs gerade mal hier auf der Arbeit am PC getestet allerdings wird der Cube hier nicht korrekt erkannt, daher heute abend zu Hause weiter probieren.
Manchmal scheint echt der Wurm drin zu sein
Hallo,
ich musste mal eben meine Grauen Zellen aktivieren - hatte ich unter Windoof 7 auch. Habe das dann mit einem alten XP Rechner gemacht, da kam das Fenster zur Bootloaderauswahl. Versuche es mal mit Kompatibilitäts Gedöne. XP SP3 oder älter.
Gruß Christoph
Unter Windows 10 hatte ich SAM-BA auch nicht zum Laufen bekommen. Deswegen hab ich den Bootloader dann unter Linux mit bossa geflasht. Ist glaub ich auch im ersten Post verlinkt.
I had some problems flashing the cube. One issue was downloading sam-ba v3 when what I need is 2.16. V2.16 comes with an install so that went in on win7 ok (v3 was just a zip AFAIR). I also had a problem with my win7 assigning bossa driver to the new com port which I had to remove , deleting driver, before I could follow the 2.16 instructions to get a AT91 com port. I've used sam-ba to install bootloader and then teraterm to send over aculfw which worked.
UPDATE: when I run translate (german to english) on the page this messes up my point about I found that I must have the COM DRIVER = AT91. It might be that english to german is also messing this up.
Bossa gibts auch mittlerweile für Windows, hilft ggf. dem einen oder anderen, bei mir funzt Bossa (unter Win7) leider auch nicht, erkennt den Cube nicht. Ich steige auf das Lan Gateway um oder einen Cul. Aber trotzdem ein schönes Tut, danke dafür, es war einen Versuch wert
Hallo,
ich hab einen fertige abzugeben ;-) oder tauschen ? Dann mache ich mir den fertig und verkaude den. So kann man mit dem Teil ja sonst nichts machen.
Gruß Christoph
Hallo, ich habe schon seit ca. 1 Jahr eine MAX Cube am laufen, das funktioniert soweit auch ganz gut.
Um Strom zu sparen läuft jedoch mein komplettes Heim Rechenzentrum mit KVM virtualisiert auf einem Intel NUC auf (inkl. Firewalls und vSwitch).
Da das durchreichen der USB-Ports nicht so richtig funktioniert hat, verwende ich auf dem Hypervisor (Ubuntu) das Programm ser2net um den CUBE und den JeeLink an die VM über TCP/IP durchzureichen.
#Hypervisor mit ser2net
#JeeLink
2000:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AI03DB4I-if00-port0:57600 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
#CUL
2001:raw:0:/dev/serial/by-id/usb-03eb_AT91USBSerial1-if00:38400 NONE 1STOPBIT 8DATABITS HANGUP_WHEN_DONE
# VM mit FHEM
define JeeLink_1 JeeLink 10.10.10.20:2000
define CUL_1 CUL 10.10.10.20:2001 0000
Beim Neustart von FHEM oder beim Neustart der VM mit FHEM verbinden sich FHEM auch gleich wieder mit den per ser2net bereitgestellten USB-Geräten auf dem Hypervisor. Ich habe jedoch ein Problem wenn ich den Hypervisors (mit allen VMs) komplett Neustarte. Der Jeelink verbindet sich gleich wieder, der CUBE bleibt jedoch im Status "opened" stehen, dann muss ich immer den CUBE vom USB-Kabel trennen und im FHEM ein "reopen" durchführen.
Im Syslog des Hypervisor steht immer
daemon.err: Jan 15 15:34:01 Hypervisor ser2net[1126]: Could not turn off break for device /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00 port 2001: Broken pipe
Hat jemand eine Idee warum sich der CUBE nach einem Neustart des Hypervisors nicht automatisch verbindet?
Ich hab zwar keine Idee, warum das nicht funktioniert, aber warum verbindest du den Cube nicht direkt über das Netzwerk mit FHEM?
Ich hatte mal ein ähnliches Problem mit dem Vebinden bei einem virtuellen Rechner.
Habe in die /etc/init.d/fhem ein sleep 10 vor den Start eingesetzt - seit dem klappte es immer.
Gesendet von iPhone mit Tapatalk
@phoenix
Bei mir läuft Sam-Ba in der Version 2.16 für XP auf Windows 7 64 Bit.
Sollte bei dir auch laufen.
Und immer ruhig bleiben .9 bei Dritten anlauf gings dann auch bei mir. Kannst ja an sich alles wieder auf ausgangspositon stellen.
Gruß
@Telekatz
Gibt es eine bestimmten/besonderen Grund, weshalb in board.h (CUBe) TTY_BUFSIZE=128 gesetzt ist?
Hintergrund: Ich habe einige Fehlermeldung im Log von 36_WMBUS.pm [https://forum.fhem.de/index.php/topic,42232.msg570006.html#msg570006]; evtl. liegt es am zu kleinen Puffer;
kann man TTY_BUFSIZE=512 bzw. TTY_BUFSIZE=1024 setzen?
Ich hab das so vom CUL übernommen.
In der angefügten Version hab ich es mal auf 512 erhöht.
Danke!
Bin gerade unterwegs, werde es sobald wie möglich testen. Ehm, flashen geht nur per USB nicht über Netzwerk, oder?
Nur über USB.
Hallo,
könnte mir das einer bitte erklären
Die Pins J1 auf dem Cube verbinden und die USB Verbindung kurz ein- und wieder ausstecken um die vorhandene Firmware zu löschen und den Flashspeicher zu entsperren
Vielen Dank im voraus
Grüße Timo
Timo - die J1-Pins sind innen im Cube... und groß dort so durch Aufdruck auf der Platine so bezeichnet. Oder was gibts da sonst noch zu erklären?
Wobei die Pins keine Pins sondern Löcher sind. Die sitzen mittig am Ende der Platine vom LAN-Port aus gesehen.
Ok danke für die schnelle Antwort.
Dann muss ich die zwei Pins miteinander verlöten?
sry für die dummen Fragen!
Nein, nur überbrücken! Nach dem Ein- und Ausstecken des USB-Kabels kannst Du die Verbindung wieder lösen.
Ok vielen dank...werde es die nächsten Tage angehen
zum überbrücken reicht zb ein breiter schraubendreher oder ne büroklammer , löten muss man nicht ;)
I found that a screwdriver had problems in making contact. What worked for me was a pair of long nose pliers that would go into the holes. I think the sharp corner on the pliers made good contact where the flat blade didn't.
Try it with a small tweezer, and a little pice of solder. ;)
@topic
hm, was muss ich anstellen damit ich mit meinem HM-CFG-USB-2 (Hab nen 2 weitere für alles andere) einen Hörman Promatic (BiSecur) ansprechen kann ?
denn so wie es ausschaut ist ja zumindest dem source nach Hörman aktiv, leider kann ich es ned anwählen. bzw. bekomme es erst garnicht ins autocreate.
kann es sein das in der compilierten image das evtl doch aus ist ?
wenn ja muss ich mal schauen wie ich den source compilen kann. ist ja was anderes wie adurinos.
Ich denke nicht, dass mit dem Hörman Protokoll BiSecure sondern ein älteres Protokoll gemeint ist. Aktiv ist Hörman seit Version 1.23.04.
Hallo,
jetzt hab ich es endlich mal versucht den Cube zu flashen.
Hat auch alles geklappt bis zur Firmware draufspielen.
Ich ändere bei minicom die Datei in /dev/ttyACM und gehe mit exit zurück.
Danach kommt der Fehler
minicom: cannot open /dev/ttyACM: No such file or directory
Vielleicht kann mir ja jemand helfen , bin leider ein totaler Anfänger >:(
Vielen Dank
Grüße T1mo
In /dev/xxxxxx ändert auch keiner was da diese nur virtuell angelegt werden. Damit das System auf die diversen Geräte zugreifen kann.
Jedoch nach Anleitung sollte des funktionieren. Denke mal das du was falsch gelesen hast. Ich selbst nuze 2 hm-usb und nen cul v3. Beim cube wird das denke ich mal auch passen.
Gesendet von meinem E6853 mit Tapatalk
im folgenden menü geht ihr in die Einstellungen zur Seriellen Verbindung, drückt a, und gebt den Namen (z.B. ttyACM) anstelle der voreinstellung ein (meist auch ttyIRGENDWAS) nur das letzte mus geändert werden, nicht der ganze Pfad. zB: aus /dev/ttyBLUB macht ihr /dev/ttyACM
Wie muss ich das dann verstehen?
Vielen Dank für deine schnelle Antwort
Siehst du, da steht Einstellung für, nicht in das Gerät.
Gesendet von meinem E6853 mit Tapatalk
Jedoch wo die Einstellung dafür ist kann ich dir ned sagen. Beim raspberry ist das in einer der Dateien für die Kernel einstellung.
Gesendet von meinem E6853 mit Tapatalk
ok sry , ich hatte mich falsch ausgedrückt .
Ich hab es in den Einstellungen geändert und danach kommt der Fehler.
Dann ist entweder beim Flashen schiefgelaufen, oder der hat den nicht erkannt. Oft ist nach dem Flash ein reboot notwendig.
Gesendet von meinem E6853 mit Tapatalk
minicom: cannot open /dev/ttyACM: No such file or directory
Wie 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.
@danke mahowi
pi@raspberrypi:~ $ dmesg | grep tty
[ 0.000000] Kernel command line: 8250.nr_uarts=0 dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa22082 bcm2709.serial=0x79b4aa35 smsc95xx.macaddr=B8:27:EB:B4:AA:35 bcm2708_fb.fbswap=1 bcm2709.uart_clock=48000000 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles
[ 0.000500] console [tty1] enabled
[ 0.832415] 3f201000.uart: ttyAMA0 at MMIO 0x3f201000 (irq = 87, base_baud = 0) is a PL011 rev2
[164856.590936] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[165831.810464] cdc_acm 1-1.2:1.0: ttyACM1: USB ACM device
[166308.529753] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[167099.936875] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[168833.284906] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
[171088.185946] cdc_acm 1-1.2:1.0: ttyACM0: USB ACM device
Und was sollte ich jetzt nehmen:-)
Ich hoffe ich bin kein hoffnungsloser Fall :'(
was sagt denn
ls -la /dev/serial/by-id/
?
pi@raspberrypi:~ $ ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb 8 14:30 .
drwxr-xr-x 4 root root 80 Feb 8 14:30 ..
lrwxrwxrwx 1 root root 13 Feb 8 14:30 usb-03eb_CUBELOADER-if00 -> ../../ttyACM0
dann musst Du /dev/ttyACM0 nehmen (das hinten ist eine Null)
@vielen Dank Weisswurstverkäufer :)
Jetzt finde ich die Firmware nicht in der Directory.....mach jetzt erstmal Pause und ärgere mich über meine Blödheit.
Vielleicht kommt ja eine Eingebung beim Gassi gehen.
Vielen Dank an euch allen
Wenn Du minicom mit "sudo" gestartet hast befindest Du dich im Ordner "/root". Wenn Du die Firmware da rein legst solltest Du die Datei sofort sehen können
ok bin wieder ein Stück weiter gekommen ....aber jetzt geht die Firmware nicht drauf.
Beim ersten Mal wurde was gesendet und ist einer Fehler gekommen und jetzt passiert gar nichts.
Ich hatte nochmal alles von vorne gemacht
Zeig nochmal die Ausgabe von ls -al /dev/serial/by-id/
Wahrscheinlich ist die Firmware schon drauf. Die Fehlermeldung beim Flashen ist normal. minicom wartet noch auf eine Antwort, das alles gesendet wurde, während der Cube aber schon neu startet. Im Normalfall hat das Flashen aber funktioniert.
Ok morgen mittag wenn ich wieder am Rechner sitze.
Danke dir
pi@raspberrypi:~ $ ls -al /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 60 Feb 9 14:39 .
drwxr-xr-x 4 root root 80 Feb 9 14:39 ..
lrwxrwxrwx 1 root root 13 Feb 9 14:39 usb-03eb_AT91USBSerial1-if00 -> ../../tty ACM0
Die Meldung kommt ,dann müsste alles passen?
Ich hatte den Cube gestern nicht im Lan gefunden , da ich ihn nicht direkt mit Strom versorgt hatte.
Kann man eigentlich eine neue Firmware einfach überspielen?
Vielen Dank für eure super Hilfe
Ja, paßt so. ;)
Wenn Du neue Firmware aufspielen willst, mußt Du den Cube vom USB trennen und mit gedrücktem "Reset"-Knopf wieder anstecken. Dann bootet er wieder in den Bootloader und ist als /dev/serial/by-id/usb-03eb_CUBELOADER-if00 erreichbar.
Hallo,
ich scheitere leider schon beim flashen des bootloaders (auf dem MAX! Cube). Nach der Verbindung via USB erscheint es unter COM10 und kann dann auch im SAM-BA (v2.16) ausgewählt werden (SAM-BA wurde als Admin gestartet).
Nachdem ich connect drücke verschwindet das Fenster und das wars. Der Prozess ist noch aktiv (im Taskmanager nachgeschaut) aber keine GUI mehr da...
Bitte um Hilfe
Andreas Veit
Schau mal nach, ob der COM Port in der Auswahlliste zweimal drin ist. Einmal als COM10 und einmal als \USBserial\COM10. Wenn ja, nimm den anderen.
Nein nur einmal als \USBserial\COM10 ...
Gerade auf einem anderen PC installiert und bekomme das gleiche Ergebnis...
Es gibt neben dem Installer "SAM-BA 2.16 for Windows (XP, Vista, Seven editions)" auch noch ein ZIP Archiv "SAM-BA 3.1.4 for Windows (XP, Vista, Win7, Win8)"... Dieses beinhaltet allerdings nur eine cmd line .exe.... ???
Windows...
Gerade mein PC unter Linux gestartet und schon funktioniert SAM-BA... Habe den Bootloader erfolgreich geflasht (LED D1 blinkt)
Wenn ich die FW mittels minicom (siehe https://forum.fhem.de/index.php/topic,38404.msg348429.html#msg348429) flashen möchte muss man nach "Datei senden" folgedes auswählen:
- zmodem
- ymodem
- xmodem
- kermit
- ascii
Was wähle ich denn da?
xmodem
mhh kommt leider failed...
EDIT:
Wenn ich den Cube (ohne Gehäuse ist es ja eher ein Quader ;D ) wieder unter windows anschließe taucht er im device manager als "CUBELOADER" unter andere Geräte auf... Welche Treiber muss ich dem jetzt zuweisen (sollte ja wieder als COM Port auftauchen um mittels TeraTerm die FW zu flashen)?
EDIT2:
Ich habe übrigens den bootloader aus dem ersten ZIP (V1.10.00 build163) genommen, da in der neuestem ZIP (V1.23.09 build195) keine bootloader_CUBE.bin mehr im Ordner CUBe drin ist...
EDIT3:
Ok habe (unter Windows) im device manager dem Gerät den Atmel Serivell Driver aufgezwungen. Danach wurde er als COM erkannt. Dann wie beschrieben mittels TeraTerm die CUL FW drauf geflasht... Jetzt blinkt er im sekundentakt und D3 leuchtet konstant...
EDIT4:
MAXCube aka CUL an den Raspy angeschlossen und wie im wiki beschrieben angelegt und mit Thermostat gepaired... Sofort funktioniert! Klasse!
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?
Hallo zusammen,
ich möchte in meiner neuen Wohnung die Heizungssteuerung mit dem MAX-System machen. Dazu ist geplant bei ELV die Bausätze der Thermostate zu kaufen.
Außerdem finde ich die Möglichkeit gut, den MAX-Cube einfach umzuflashen, um die üblichen Funktionen eines CUL zu haben. Vorteil ist, dass man Netzwerk hat statt USB. Außerdem ließe sich der Cube noch relativ gut in die Wohnung integrieren. So ein USB-Stick ist da schon "hässlicher". Und der Cube als Bausatz ist natürlich sehr günstig im Vergleich zum CUL von busware.
Würdet ihr das empfehlen oder lieber gleich einen CUL USB-Stick kaufen?
Zugegeben, ich hab nicht alle 50 Seiten des Thread gelesen. Anfangs gab es wohl die Einschränkung, dass man die Temperatur der Thermostate nicht richtig auslesen konnte. Gibt es noch Einschränkungen, in Bezug auf den Cube in Verbindung mit FHEM oder ist das mehr oder weniger uneingeschränkt zu empfehlen?
Für Später plane ich, unter Umständen ein Thermometer eines anderen Hersteller zu nutzen, das die gleiche Frequenz des Cube nutzt. Wäre das kompatibel zueinander oder führt da kein Weg hin?
Ich hoffe ich habe damit nicht zu viele Fragen, die vermutlich so ähnlich schon gefragt wurden, gestellt.
Schöne Grüße,
Bond
Wenn Du sowieso einen Cube für MAX kaufst kannst Du ihn auch direkt ungeflasht nutzen. Der Cube mit der originalen Firmware wird ja auch von fhem unterstützt.
Mehrere Protokolle auf einem CUL geht nicht - Du musst immer einen Modus wählen (z. B. Homematic, MAX).
Hi Telekatz,
vielen Dank für deine super Arbeit :) Ich habe meinen ersten Cube als Homematic CUNx laufen. Hat alles nach Anleitung funtioniert!
Jetzt überlege ich, auch Z-Wave mit einem 2. Cube einzusetzen. Wenn ich mir das a-culfw Changelog ansehe, müsste seit Version 1.20.05 Z-Wave unterstützt werden. Geht das auch mit dem Cube?
Vielen Dank
Code006
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)
Zitat von: Telekatz am 13 Februar 2017, 23:21:30
Die Z-Wave Unterstützung ist wohl mehr experimentell und nicht wirklich produktiv einsetzbar, siehe auch diese Aussage: https://forum.fhem.de/index.php/topic,59292.msg507394.html#msg507394 (https://forum.fhem.de/index.php/topic,59292.msg507394.html#msg507394)
Danke für die schnelle Info, auch wenn sie nicht so ist, wie ich sie gerne hätte...
Zitat von: Christian1982 am 12 Februar 2017, 19:07:27
Ich habe leider immer noch ein Problem mit der Erreichbarkeit des CULs (MAX CUBe) nach einen Neustart des Intel NUCs (mit Ubuntu Server 16.10).
Nach einem Neustart muss ich den CUB (nur mit USB Verbunden) immer manuell vom USB-Kabel trennen und neu verbinden, erst danach kann ich mich wieder verbinden.
Dann funktioniert auch der Befehl "V" (gibt die Version aus) auf der Konsole und mit "echo "B00." > /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00" kann ich den CUL auch reseten.
Mit einem "set CUL_1 reopen" kann ich den CUL dann auch wieder von FHEM aus ansprechen.
Nach den Neustart des Computers ist der CUL zunächst jedoch nicht mehr ansprechbar, weder "V" noch "B00." funktionieren, erst ein trennen des USB-Kabels hilft.
Jemand eine Lösung?
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
Hallo,
habe gerade versucht den Max Cube als CUL zu flashen. Wenn ich nun Sam-ba( Version 2.16) als Administrator starte, den neu erschienenen COM Port (COM-Port ist erst erschienen nachdem ich den Treiber manuell eingebunden hab.) auswähle erscheint die Meldung im Anhang.Hat jemand eine Idee? Bei Bossa für Windows erscheint die Meldung Could not connect to device on COM4.
Ich habe gerade die Sourcen von github aktualisiert. Wofür ist denn das neue Build-Target "CUBEx4"? Im Changelog konnte ich dazu leider nichts finden.
Das ist ein Cube mit 4 Transceivermodulen. Wie auch der MapleCUNx4.
Hi,
Zitat von: Code006 am 15 Februar 2017, 06:44:40
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.
Hallo Telekatz,
ich bin per Zufall auf die Betty-FB aufmerksam geworden. Wenn ich es richtig interpretiere, hat Du auch mal so ein Ding besessen und es war möglicherweise sogar der Anlass die culf@ARM zu entwickeln.
Ich wollte jetzt hier https://forum.fhem.de/index.php/topic,69112.msg605937.html#msg605937 das Betty-Thema aufgreifen. Wäre nett, wenn Du dort ein paar warme Worte zu Deinen Betty-Erfahrungen und dem Einsatz der culf@ARM auf diesem Gerät verlieren könntest.
Grüße Markus
Zitat von: Kroegi am 20 November 2016, 11:26:04
Hab da grade auch so ein Phänomen mit dem Schätzchen.
Er lief jetzt von Anfang an ohne Probleme.
Nun stand da plötzlich "disconnectet", zum Glück habe ich zwei davon in Betrieb.
Also den ausgefallenen mal resettet, neu geflasht und aktuelle Firmeware drauf.
Er reagiert auch augenscheinlich ganz normal, hat ohne Fehler alles aufgenommen und Leuchtet / Blinkt wie eh und je.
Ich sehe ihn auch bei den Geräten in der Fritzbox, hat seine IP Adresse bekommen.
Nur in FHEM taucht er nicht mehr auf.
Was kann ich da noch grossartig machen?
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??
Hallo zusammen,
hatte bei mir bisher zwei HM-CFG-USB-2 mit der a-culfw (V 1.24.01 a-culfw Build: 204) im Einsatz, da ich Homematic und Max im Mischbetrieb hatte. Da ich jetzt nur noch Max einsetze, habe ich einen HM-CFG-USB-2 übrig. Mit dem wollte ich jetzt gerne ein paar Intertechno kompatible Geräte einbinden, schalten klappt auch soweit, aber empfangen von Hand- /Wandsendern geht leider bisher nicht. Habe lediglich die Frequenz über ein "set freq 433.92" umgestellt. Muss ich für den Empfang von IT Komponenten noch was anderes tun?
Grüße
Philipp
Zitat von: Kroegi am 20 März 2017, 19:02:26
Moin. Hab erneut dieses Problem, allerdings mit dem anderen Cube.
Hab dieses ebenfalls resettet, neu geflasht, feste IP vergeben und was sonst alles dazugehört.
Er bleibt trotzdem in fhem unsichtbar.
Auf der Fritzbox taucht er mit seiner üblichen IP Adresse auf.
Habe ihn aus fhem als device gelöscht, er sollte doch nach reboot unter Everything wieder auftauchen?
Oder bin ich grad einfach mal wieder zu doof??
Wenn du ihn aus FHEM gelöscht hast, musst du ihn neu anlegen. Von alleine wird er nicht angelegt.
Zitat von: Johnnyflash am 21 März 2017, 09:54:44
Hallo zusammen,
hatte bei mir bisher zwei HM-CFG-USB-2 mit der a-culfw (V 1.24.01 a-culfw Build: 204) im Einsatz, da ich Homematic und Max im Mischbetrieb hatte. Da ich jetzt nur noch Max einsetze, habe ich einen HM-CFG-USB-2 übrig. Mit dem wollte ich jetzt gerne ein paar Intertechno kompatible Geräte einbinden, schalten klappt auch soweit, aber empfangen von Hand- /Wandsendern geht leider bisher nicht. Habe lediglich die Frequenz über ein "set freq 433.92" umgestellt. Muss ich für den Empfang von IT Komponenten noch was anderes tun?
Grüße
Philipp
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.
Zitat von: Telekatz am 21 März 2017, 11:35:39
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
Der Cube wird nicht per autocreate angelegt. Von alleine taucht er in keiner Liste auf.
Hi,
ich verwende einen CUBe mit kompilierter Firmware ([boards.h] #define TTY_BUFSIZE 1024).
Jetzt verwende ich seit kurzem einen WMBUS-Wasserzähler, der zum Testen mit einem CUL/COC fehlerfrei empfangen werden kann, aber mit einem CUBe diesen Fehler erzeugt:
WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
Der Log-Auszug dazu:
2017.03.26 21:58:40 5: CUL/RAW: /b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857
2017.03.26 21:58:41 5: CUL/RAW: b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857/b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 4: CUL_Parse: cube b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 5: cube: dispatch b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 5: WMBUS raw msg b764421042003377025071C5F722003377021042507FC00600543501C446681CB480A12E307C961D5D05BD607E1BCB17B1606FA4EC40BCC1B3A7F301CBDAE5F73B4453D8CCA39C3C2C87C35E323624236C982447B49807917D0A1ECA40C3E6EF1C0A0305552986F101BE70EDAE9AFA28581CF21DA27A9BBDC8835C3857b32446850525081926980F8EBA0119F213A01A027EE0019082E080416DC97000B614913000000000000000000000072D40011050214171017088D588009
2017.03.26 21:58:41 2: WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
2017.03.26 21:58:41 5: CUL/RAW: /b32446850325746926980896FA0119F213112A0277F061C0D601149806C6601AC9067816F360000295D2A3C29306892AF607F6988988E849990C5BE84EB
Ich würde vermuten, dass es evtl. an einer Buffer-Einstellung der '/a-culfw' Firmware liegt und weniger am 36_WMBUS.pm -Modul? Kann jemand helfen?
Tom
Wie sieht denn die RAW message des CUL/COC aus? Und zum Vergleich die RAW Message, die der Cube gleichzeitig empfängt.
Hier die Log-Einträge zum Vergleich:
WMBus-Device [COC]
COC_RAWMSG
b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61
WMBus-Device [CUBe]
cube_RAWMSG
b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
Logfile [COC]
2017.03.27 12:24:09 5: CUL/RAW: /b3244685
2017.03.27 12:24:09 5: CUL/RAW: b3244685/07931809
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809/269804F5FA0119F2
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F2/1CD05B02
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B02/74B02F706F806003
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003/B03B8008
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008/CEEB1DE856500000
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE856500000/00000000
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE85650000000000000/00001F4480A3F1A0
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A0/01772386
2017.03.27 12:24:09 5: CUL/RAW: b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A001772386/84D8A148004
2017.03.27 12:24:09 4: CUL_Parse: COC b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A148004 -72
2017.03.27 12:24:09 5: COC: dispatch b324468507931809269804F5FA0119F21CD05B0274B02F706F806003B03B8008CEEB1DE8565000000000000000001F4480A3F1A00177238684D8A1480::-72
2017.03.27 12:24:10 5: CUL/RAW: /b7644210
2017.03.27 12:24:10 5: CUL/RAW: b7644210/42003377
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377/025071C5F7220033
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033/77021042
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F722003377021042/5078900600535236
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236/D8D2AD8C
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C/58E160B147829F89
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89/FB0D470A
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470A/F36B931358D43DE2
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE2/2F82A2CB
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB/730141AEF3C3805B
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805B/CA7EFCDF
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF/268BE9FE8A2DF21C
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C/02FDA68B55207554
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B55207554/51A63D77
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D77/3D11F14510761CEE
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEE/FE589948
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE589948/4DB92055044476C0
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C0/72FB4402
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402/CE3AF8DF06F3A6C3
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3/B56E9737
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737/C096B4AB8CA7B704
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704/043A7A28
2017.03.27 12:24:10 5: CUL/RAW: b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A28/01A
2017.03.27 12:24:10 4: CUL_Parse: COC b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A2801A -61
2017.03.27 12:24:10 5: COC: dispatch b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61
2017.03.27 12:24:10 5: WMBUS raw msg b764421042003377025071C5F7220033770210425078900600535236D8D2AD8C58E160B147829F89FB0D470AF36B931358D43DE22F82A2CB730141AEF3C3805BCA7EFCDF268BE9FE8A2DF21C02FDA68B5520755451A63D773D11F14510761CEEFE5899484DB92055044476C072FB4402CE3AF8DF06F3A6C3B56E9737C096B4AB8CA7B704043A7A280::-61
Logfile [CUBe]
2017.03.27 12:19:11 5: CUL/RAW: b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565E/b2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 4: CUL_Parse: cube b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 5: cube: dispatch b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 5: WMBUS raw msg b764421042003377025071C5F7220033770210425078800600568FEBFFDD44A035E41B54B40DA0E18E75EC19BCC33CD00055F17CA77794A1DC0BF627758450B6151F800826D3CD32437DE5AFE26587EE318B1E9C391D8651C475528662D68E311D52DBD9610AA72C3E5F0A962ABD321F9AF2797CA779A9C08C882A565Eb2E4468506924210570624D3DA0809F213801B0270E0000010202040382B60302030002000000050403010203010054CD0000020583541A88EC
2017.03.27 12:19:11 2: WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
2017.03.27 12:19:12 5: CUL/RAW: /b324468506642819269803B29A0119F216304B0271F02DC0AC30D214089D40069704C5C2E250500010100000000023D7A0C26143B5D4F1D86B6FAB880F1
b324468506074469269808A9CA0119F210F02B027AD005B072A0700005C2F000000000000000E0000000000000000A9A407280E091C4E4C9C692CD08303
Mit dem COC/CUL wird alles fehlerfrei empfangen, mit dem CUBe klappt es leider nicht.
Kannst du mal beide gleichzeitig auf Empfang stellen, um zu sehen, wie die Ausgabe der selben Nachricht ist.
ok, hatte auf Anhieb nicht gleich geklappt ... jetzt aber:
COC
2017.03.27 13:59:20 5: CUL/RAW: /b7644210
2017.03.27 13:59:20 5: CUL/RAW: b7644210/42003377025071C5
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5/F7220033
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033/770210425079C006
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006/005ECDC2
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC2/8270FFAB10BF558B
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558B/E451C2707BEA2992
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992/500A4984
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984/CC46AD9CE8F82305
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305/D08C28BD52AFFB40
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40/A096763B
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763B/E7484FEFBEBF821C
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C/5B3A2BBC59C8438F
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438F/C462CEEE
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE/2075F3E45285FCDD
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDD/FD5CE19620343B7D
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7D/C704C47F
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F/446143F654C162DC
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC/92B0AE7D01CF08E7
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7/CF25A019
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019/E378B9CB0842CAF8
2017.03.27 13:59:20 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF8/01A
2017.03.27 13:59:20 4: CUL_Parse: COC b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF801A -61
2017.03.27 13:59:20 5: COC: dispatch b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF80::-61
2017.03.27 13:59:20 5: WMBUS raw msg b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF25A019E378B9CB0842CAF80::-61
2017.03.27 13:59:21 5: CUL/RAW: /b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF
CUBe
2017.03.27 13:59:22 5: CUL/RAW: b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CF/b3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 4: CUL_Parse: cube b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFb3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 5: cube: dispatch b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFb3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 5: WMBUS raw msg b764421042003377025071C5F7220033770210425079C006005ECDC28270FFAB10BF558BE451C2707BEA2992500A4984CC46AD9CE8F82305D08C28BD52AFFB40A096763BE7484FEFBEBF821C5B3A2BBC59C8438FC462CEEE2075F3E45285FCDDFD5CE19620343B7DC704C47F446143F654C162DC92B0AE7D01CF08E7CFb3244685061508292698087ADA0119F21EB0AB0273D05690A8B0C3B5AC31A01959176791617000000000000000000B86807432B3B7C747A99817C77810C
2017.03.27 13:59:22 2: WMBUS WMBUS_AAA_70370320_37_7 Error during ApplicationLayer parse:crc check failed for block 6
Wie hast du den Cube angeschlossen? Über USB oder Netzwerk? Und hast du beides schon mal ausprobiert?
Der Cube ist über Netzwerk angeschlossen.
Beim COC werden offenbar einzelne Blöcken in das Log geschrieben: bis zur Position/Block "...92B0AE7D01CF08E7" stimmt COC und CUBe überein, dann wird beim CUBe eine weitere Message -von einem Techem HKV- mit reingenommen.
Beim COC kommt der Block "CF25A019". Beim CUBe wir die Zeichenfolge aber mit "CF/b3244685061508292698087ADA011..." fortgesetzt. "CF" stimmt also auch noch, dann kommt aber direkt eine andere/neue Message, die mit "/b324468506150829..." beginnt.
Kann es sein, dass "25A0" etwas auslöst bzw. etwas überläuft?
Ich denke, es liegt am Netzwerk Stack. Der läuft nach 250 Bytes voll. Teste mal über USB.
Ja, über USB geht es.
Wo/wie kann man den Netzwerk-Stack höher einstellen? Im ringbuffer.h, CUBe/board.h, ...?
Ich hatte TTY_BUFSIZE auf 1024 gestellt. -> der CUBe hat doch >1024*4 RAM?
Teste mal die angefügte Version.
Ja, damit geht es :-) :-)
Könntest Du das bitte auf github 'einchecken' ... ich würde noch gerne für mich den 'rAmpl' von 33dB auf 40dB hochstellen ;-)
Vielen Dank!!!
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?
Zitat von: bigmo am 14 April 2017, 22:07:04
Man kann den Cube ja auch mit der originalen Firmware also die von max in Fhem einbinden und betreiben. Welche Vorteile habe ich denn wenn ich sie culfw flashe?
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
Ok das leuchtet ein. ABer wenn ich nur MAX komponenten verwende, welche Vorteile habe ich dann??
Oder anders gefragt, welche Option ist für eine reine MAX Umgebung mit FHEM die beste Wahl:
-Cul Stick
-Max Cube geflasht
-Max Cube original
Hi,
Die dritte weil am wenigsten Arbeit. Und nach zwei Monaten will man mehr und flasht den Cube. Und dann holt man sich einen Cul in der anderen Frequenz ;-) Ganz ehrlich wir haben alle klein angefangen und dann kommt der Spieltrieb und der Zoo an Gateways!
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: bigmo am 14 April 2017, 22:07:04
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 !
Hallo zusammen,
zuerst danke für das tolle Projekt.
Vielleicht hat jemand einen Tipp für mich, aber ich hänge an einem Problem.
Meinem MAX! Cube (BC-LGW-O-TW-Ha xavax gelabeld) habe ich den alternativen Bootloader verpasst und a-culfw aus dem ersten Post.
Versionen habe ich einige durch im Moment ist es Build 209 (neuste Datei).
Auf der seriellen Schnittstelle nach Eingabe V kommt: V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Nun zum Problem:
Der Cube erhält keine IP vom dhcp Server. Auch wenn ich manuell eine IP einstelle bekomme ich keine Verbindung weder per telnet noch fhem.
Die Netzwerkdiagnose über die Konsole E... liefert keine Ausgabe.
Gibt es dazu irgendwelche Tipps oder Erkenntnisse?
Danke
gruß max
@audimax
Den Cube per USB nur mit Strom versorgen und nicht als USB-Geräte anschliessen. So fährt dieser in den nezwerkmodus. Ist zumindest bei meinem so. Version 1.20...
Pejonp
Ja, steht auch irgendwo in den Anfängen dieses Threads. Wenn er gleichzeitig auch als USB-Gerät angeschlossen wird, ist er nicht übers Netzwerk erreichbar.
@pejonp
Danke für die schnelle Antwort.
Leider finde ich die Box so auch nicht im LAN. Weder mit dhcp vergabe noch per fixer IP.
Allerdings leuchtet so die Battery LED nicht. Nur Internet leuchtet und Power blinkt.
nmap findet auf der fixen IP auch nichts
max
Hat noch jemand einen Tipp für mich?
Du könntest mal die Debugausgaben loggen https://forum.fhem.de/index.php/topic,38404.msg524928.html#msg524928 (https://forum.fhem.de/index.php/topic,38404.msg524928.html#msg524928).
@audimax
Ja, vielleicht ein Tipp - klingt etwas verrückt und ich hab das so noch nicht erlebt: probiere es an einem anderen Switch, der 10/100/1000 Mbit unterstützt!
Ich hab wohl die gleiche Prozedur durch wie du. 53 Forenseiten gelesen, den CUBe x-Mal neu geflashed mit a-culfw in verschiedenen Versionen, mit Bootloader und ohne als CUBE.bin. Jedes Mal USB-Verbindung okay, aber an zwei verschiedenen Routern mit 10/100-Switches keine LAN-Verbindung, nicht per DHCP und nicht mit fester IP (dabei war das LAN-Interface der Grund für fie Anschaffung des CUBE). Dann den CUBeCUL mal versuchsweise an einen Router mit Gigabit-Ports angeschlossen, und siehe da, er erhält seine IP per DHCP! Zurück geflashed auf den letzten Bootloader und das aktuelle CUBE_BL.bin, feste IP und Gateway vergeben, und es läuft am 10/100/1000-Port, aber nicht am 10/100-Port.
Kann das sein, dass so ein simples Stück Hardware einen Gigabit-LAN-Port voraussetzt?
Zitat von: palatin8 am 30 April 2017, 03:04:28
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 !
Hallo!
Habe folgendes Problem: hatte eine ältere FW auf dem Cube (übrigens: großen DANK für die tolle Arbeit!) (irgendwas 1.20), da ich da ein 433er-Gerät nicht richtig erkennen konnte, wollte ich mal zur Sicherheit auf die aktuelle Version gehen (V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05)). Hat auch ohne Probleme funktioniert. MAX-Modus geht auch weiterhin ohne Probleme, allerdings kann ich jetzt mit freq 433.92 gar nichts empfangen (davor hatte ich wenigstens "unknown codes" empfangen. Allerdings bin ich nicht sicher, ob ich den Cube jetzt richtig umschalten kann, da:
wenn ich attr Cube rfmode SlowRF mache bekomme ich folgendes im Log (verbose ist auf 5):
2017.06.07 20:49:42 5: SW: Ax
2017.06.07 20:49:42 5: SW: Zx
2017.06.07 20:49:42 5: SW: brx
2017.06.07 20:49:42 5: SW: X21
2017.06.07 20:49:42 2: Switched Cube rfmode to SlowRF
2017.06.07 20:49:42 5: CUL/RAW: /OFF
2017.06.07 20:49:42 4: CUL_Parse: Cube OFF
2017.06.07 20:49:42 5: Cube: dispatch OFF
2017.06.07 20:49:43 3: Cube: Unknown code OFF, help me!
Mache ich irgendwas falsch oder habe ich was überlesen? Habe diesen Thread jetzt schon mindestens 2x durch... :(
Vor dem Flashen der aktuellen FW konnte ich mit rfmode SlowRF, freq 433.92 und raw X25 alles sehen, jetzt wie gesagt nichts mehr....?
Mir gehen die Ideen aus...
Andy
Hi,
Was sagt denn
get <sev> cmds
Ist Intertechno überhaupt mit in der Firmware drin?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Setz mal mit "raw e" den EEPROM zurück und probier es nochmal.
Hallo!
Cube cmds => B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
Wenn ich set Cube raw e mache, setzt er sich zwar zurück (laut Log ist die Verbindung kurz weg und kommt dann wieder), aber helfen tut's nicht.
Einmal habe ich's hinbekommen auf SlowRF umzuschalten ohne Fehler nachdem ich ihn stromlos gemacht habe, das lässt sich aber leider nicht reproduzieren... (also wenn ich ihn nochmal stromlos mache, geht's trotzdem nicht)...
Irgendwo ist da der Hund drinnen, aber ich hab - wie gesagt - keine Idee wo oder wo/wie ich das suchen könnte...
Das internal "Clients" sagt folgendes, demnach müsste zB IT drinnen sein:
:FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Mach mal ein "list" vom Cube.
Hier Ausgabe von list Cube:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Cube_MSGCNT 14
Cube_TIME 2017-06-07 23:06:24
DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
FD 40
FHTID 1234
NAME Cube
NR 107
PARTIAL
RAWMSG 27 900
RSSI -57.5
STATE Initialized
TYPE CUL
VERSION V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-06-07 23:25:06 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2017-06-07 23:25:03 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017-06-07 22:50:50 credit10ms 394
2017-06-07 19:31:02 fhtbuf AE
2017-06-07 23:15:35 raw No answer
2017-06-07 23:25:03 state Initialized
2017-06-07 20:40:01 uptime 0 00:16:00
2017-06-07 19:30:37 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Attributes:
icon cul_cul
rfmode MAX
room System
verbose 5
Im Normalbetrieb ist der Cube dazu da, um mit MAX-Komponenten zu sprechen. Scheinbar ist es jetzt so, dass das nicht mehr funktioniert, sobald man eine der genannten Einstellungen ändert (welche genau das auslöst, konnte ich noch nicht eingrenzen), bis man das Ding dann wieder stromlos macht (auch ein set Cube raw e hilft nix)... :(
Kann etwas beim Flashen so schief gegangen sein, dass dieses dubiose Verhalten erklärbar macht, oder was könnte da sein?
Was mir noch aufgefallen ist: nachdem ich den Cube jetzt wieder mal stromlos gemacht habe, ist mir ein Unterschied aufgefallen zu gerade eben - siehe list Cube jetzt:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
Cube_MSGCNT 33
Cube_TIME 2017-06-07 23:46:15
DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
FD 40
FHTID 1234
NAME Cube
NR 107
PARTIAL
RAWMSG Z0B140630102642123456005028
RSSI -54
STATE Initialized
TYPE CUL
VERSION V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
initString X21
Zr
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-06-07 23:44:59 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2017-06-07 23:44:54 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017-06-07 23:43:31 credit10ms 553
2017-06-07 19:31:02 fhtbuf AE
2017-06-07 23:39:13 raw 25 768
2017-06-07 23:46:15 state Initialized
2017-06-07 23:29:39 uptime 0 00:04:50
2017-06-07 23:29:43 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Attributes:
icon cul_cul
rfmode MAX
room System
verbose 5
Was bei Clients steht, dürfte ja vom rfmode abhängig sein, also irgendwie passt da was nicht zusammen, oder ich sehe schon den Wald vor lauter Bäumen nicht...
???
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
Hi,
wie kommt es zu den Änderungen an den ccconf Zeilen? Und warum hast Du die jeweils so eingestellt?
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ok, damit nichts verfälscht ist oder so, jetzt nochmal der Reihe nach:
Cube List nach einem Reset (sollte das gleiche wie oben sein):
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
Cube_MSGCNT 25
Cube_TIME 2017-06-08 10:37:24
DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
FD 18
FHTID 1234
NAME Cube
NR 107
NR_CMD_LAST_H 6
PARTIAL
RAWMSG Z0B5E0630118956100F7C0010F5
RSSI -79.5
STATE Initialized
TYPE CUL
VERSION V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-06-07 23:44:59 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2017-06-08 08:03:13 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017-06-08 10:04:17 credit10ms 364
2017-06-07 19:31:02 fhtbuf AE
2017-06-07 23:39:13 raw 25 768
2017-06-08 10:37:24 state Initialized
2017-06-07 23:29:39 uptime 0 00:04:50
2017-06-07 23:29:43 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
XMIT_TIME:
1496909031.64916
1496909038.17139
1496909039.68619
1496909045.70287
1496909051.71928
1496909057.73275
Attributes:
icon cul_cul
rfmode MAX
room System
verbose 5
Jetzt setze ich das Attribut rfmode auf SlowRF, was mir im Log folgende Einträge bringt:
2017.06.08 10:42:21 5: SW: Ax
2017.06.08 10:42:21 5: SW: Zx
2017.06.08 10:42:21 5: SW: brx
2017.06.08 10:42:21 5: SW: X21
2017.06.08 10:42:21 2: Switched Cube rfmode to SlowRF
2017.06.08 10:42:21 5: CUL/RAW: /OFF
2017.06.08 10:42:21 4: CUL_Parse: Cube OFF
2017.06.08 10:42:21 5: Cube: dispatch OFF
2017.06.08 10:42:21 3: Cube: Unknown code OFF, help me!
Cube List sieht jetzt so aus:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Cube_MSGCNT 26
Cube_TIME 2017-06-08 10:42:21
DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
FD 18
FHTID 1234
NAME Cube
NR 107
NR_CMD_LAST_H 6
PARTIAL
RAWMSG OFF
RSSI -79.5
STATE Initialized
TYPE CUL
VERSION V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-06-07 23:44:59 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2017-06-08 08:03:13 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017-06-08 10:04:17 credit10ms 364
2017-06-07 19:31:02 fhtbuf AE
2017-06-07 23:39:13 raw 25 768
2017-06-08 10:42:21 state Initialized
2017-06-07 23:29:39 uptime 0 00:04:50
2017-06-07 23:29:43 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
XMIT_TIME:
1496909031.64916
1496909038.17139
1496909039.68619
1496909045.70287
1496909051.71928
1496909057.73275
Attributes:
icon cul_cul
rfmode SlowRF
room System
verbose 5
Jetzt noch die Frequenz auf 433.92, hier den entsprechenden Logs:
2017.06.08 10:43:57 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2017.06.08 10:43:57 5: SW: W0F10
2017.06.08 10:43:57 5: SW: W10b0
2017.06.08 10:43:57 5: SW: W1171
2017.06.08 10:43:57 5: SW: X21
dann sieht list Cube so aus:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Cube_MSGCNT 26
Cube_TIME 2017-06-08 10:42:21
DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
FD 18
FHTID 1234
NAME Cube
NR 107
NR_CMD_LAST_H 6
PARTIAL
RAWMSG OFF
RSSI -79.5
STATE Initialized
TYPE CUL
VERSION V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
initString X21
Matchlist:
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04....(1|5|9).a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-06-07 23:44:59 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2017-06-08 08:03:13 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017-06-08 10:04:17 credit10ms 364
2017-06-07 19:31:02 fhtbuf AE
2017-06-07 23:39:13 raw 25 768
2017-06-08 10:42:21 state Initialized
2017-06-07 23:29:39 uptime 0 00:04:50
2017-06-07 23:29:43 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
XMIT_TIME:
1496909031.64916
1496909038.17139
1496909039.68619
1496909045.70287
1496909051.71928
1496909057.73275
Attributes:
icon cul_cul
rfmode SlowRF
room System
verbose 5
ein get Cube ccconf bringt jetzt folgendes:
Cube ccconf => freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
(wird scheinbar nicht automatisch ohne extra get upgedated)
will ich jetzt ein set Cube raw X25 (um auch unbekannte Sequenzen zu empfangen, steht im Log:
2017.06.08 10:47:51 3: set Cube raw X25
2017.06.08 10:47:51 5: SW: X25
Bis auf die Fehlermeldung beim Setzen des rfmode würde es ja ok ausschauen. Wenn ich die Doku richtig verstanden habe, kann man SlowRF auf mit set Cube raw fx aktivieren, oder?
2017.06.08 10:50:59 3: set Cube raw fx
2017.06.08 10:50:59 5: SW: fx
Trotz allem empfange ich so aber genau nix...
Und wenn ich jetzt wieder zurück zum eigentlichen MAX-Mode will, hätte ich folgendes gemacht:
Attribut rfmode auf MAX
2017.06.08 10:52:16 5: SW: Ax
2017.06.08 10:52:16 5: SW: X21
2017.06.08 10:52:16 5: SW: Zr
2017.06.08 10:52:16 2: Switched Cube rfmode to MAX
dann ein set Cube raw e:
2017.06.08 10:52:46 3: set Cube raw e
2017.06.08 10:52:46 5: SW: e
2017.06.08 10:52:47 1: /dev/ttyACM0 disconnected, waiting to reappear (Cube)
2017.06.08 10:52:51 3: Setting Cube serial parameters to 9600,8,N,1
2017.06.08 10:52:51 5: SW: V
2017.06.08 10:52:51 5: CUL/RAW (ReadAnswer): V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
2017.06.08 10:52:51 5: SW: ?
2017.06.08 10:52:51 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017.06.08 10:52:52 3: Cube: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2017.06.08 10:52:52 5: SW: X21
2017.06.08 10:52:52 5: SW: Zr
2017.06.08 10:52:52 5: SW: T01
2017.06.08 10:52:52 5: CUL/RAW (ReadAnswer): 1234
2017.06.08 10:52:52 5: GOT CUL fhtid: 1234
2017.06.08 10:52:52 1: /dev/ttyACM0 reappeared (Cube)
Ein get Cube ccconf bringt dann wieder die korrekten Werte:Cube ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
list Cube schaut dann so aus:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
Cube_MSGCNT 27
Cube_TIME 2017-06-08 10:47:34
DEF /dev/ttyACM0@9600 1234
DeviceName /dev/ttyACM0@9600
FD 18
FHTID 1234
NAME Cube
NR 107
PARTIAL
RAWMSG ? (25 is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
RSSI -79.5
STATE Initialized
TYPE CUL
VERSION V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
initString X21
Zr
Matchlist:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
Readings:
2017-06-08 10:53:14 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2017-06-08 10:52:51 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z
2017-06-08 10:04:17 credit10ms 364
2017-06-07 19:31:02 fhtbuf AE
2017-06-07 23:39:13 raw 25 768
2017-06-08 10:52:52 state Initialized
2017-06-07 23:29:39 uptime 0 00:04:50
2017-06-07 23:29:43 version V 1.24.02 a-culfw Build: 208 (2017-03-30_16-08-05) CUBe (F-Band: 868MHz)
Attributes:
icon cul_cul
rfmode MAX
room System
verbose 5
Dann dauert es aber einige Minuten (wenn man nicht gerade den Cube stromlos macht) bis der wieder normal seine Arbeit verrichtet...
Also die Frage wäre jetzt, ob der Fehler vorm Bildschirm sitzt oder im Cube oder irgendwo dazwischen ;)
Mit set Cube raw fx wird der fastrf Modus deaktiviert. Der war aber bei dir nie an. Aber trotzdem wird dabei der Empfang komplett deaktiviert.
Grundsätzlich musst du, wenn du zwischen MAX und SlowRF Modus mit dem Attribut rfmode wechselst, keine raw Kommandos ausführen. Das macht FHEM automatisch und aktiviert den entsprechenden Modus selbstständig.
Ich denke, der Fehler sitzt vor dem Bildschirm.
Na, das mit dem raw-Kommando für den SlowRF-Modus war ja nur zusätzlich gemeint - wie du oben sehen hättest können, habe ich es davor ja so wie gedacht per fhem - Attribut gesetzt, das bringt mir aber diese eigenartige Fehlermeldung - wenn ich also diesbezüglich einen Fehler gemacht habe, dann bitte um Info, wo...
Das eigentliche Problem ist aber, dass ich mit der alten FW (habe nochmal nachgeschaut, war 1.21.00) auf SlowRF und Frequenz 433.92 umschalten konnte, ohne eine Fehlermeldung zu erhalten und dann auch noch etwas empfangen habe. Leider waren die empfangenen Daten aber nicht richtig interpretierbar, weshalb mal als ersten Versuch die aktuellste FW helfen sollte.
Jetzt kann ich aber gar nichts mehr empfangen, wegen der Fehlermeldung beim Aktivieren des SlowRF stelle ich mir aber die Frage, ob er überhaupt korrekt umschaltet...
Bisher habe ich die Erfahrung gemacht, dass das Flashen selbst entweder geht oder nicht, aber das es nur so halb geht oder so hatte ich noch nie und da hier auch kein Fehler gemeldet wurde, gehe ich mal davon aus, dass das passt.
Bin mir auch nicht bewusst hier irgendwas falsch zu bedienen oder so - aber ich kann natürlich nicht ausschließen, dass ich sozusagen "den Wald vor lauten Bäumen nicht mehr sehe", weshalb ich für Hilfe dankbar wäre...
Ok. Ich denke ich weiß jetzt, woher dieses CUL/RAW OFF, usw. kommt:
Das raw-Kommando brx, welches beim Umstalten auf slowRF gesetzt wird, gibt auch was zurück:
b<cmd><data>
Wireless M-Bus:
r<mode>
start receiving messages. <mode> bust be either s or t for desired mode
s<data>
send data (tbd)
returns always the actual receiving mode
Habe daher mal folgendes versucht "get Cube raw brx" und erhalte dann:
2017.06.08 14:31:18 5: SW: brx
2017.06.08 14:31:18 5: CUL/RAW (ReadAnswer): OFF
Ein "get Cube raw C35" liefert:
2017.06.08 14:31:12 5: SW: C35
2017.06.08 14:31:12 5: CUL/RAW (ReadAnswer): C35 = 0D / 13
Somit sollte ja der Empfangsmodus aktiv sein, oder?
Um das ganze abzukürzen:
-) wie kann ich feststellen, ob der Cube auf "Empfangsmodus" ist oder nicht?
-) wie sind die genauen Schritte um von 868/MAX auf 433/SlowRF umzuschalten (um auch zu empfangen, am besten alles - nicht nur bekanntes)?
Das raw Kommando brx deaktiviert den MBus mode und das OFF ist die Rückantwort, dass MBus deaktiviert ist. Wenn danach X21 gesendet wird, wird der SlowRF Mode aktiviert. Die Fehlermeldung im LOG kannst du ignorieren.
Zitat von: Andy77H am 08 Juni 2017, 14:39:40
-) 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.
Zitat von: Andy77H am 08 Juni 2017, 14:39:40
-) 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.
Ok. Danke für die Infos, somit weiß ich jetzt, dass ich nicht daneben war. Stimmt es auch, dass man mit X25 den Empfang so umstellen kann, dass auch unbekannte Signale geloggt werden?
Jetzt wäre das ganze drumherum geklärt, aber mein Problem ist ja, dass ich vor dem Update der FW von einem bestimmten Gerät auf Frequenz 433 was empfangen habe und dazwischen auch immer wieder andere Signale (wohl "Grundrauschen" bzw. Nachbarn?), jetzt mit der neuen FW aber genau nichts in den Logs auftaucht...
Mit der alten FW hatte ich es sogar so weit gehabt, dass er mir ein Gerät automatisch angelegt hatte, nur waren da die Codes (noch?) nicht korrekt...
Woran könnte das liegen? Ist es eine Einstellungssache oder kam irgendein "Feature" dazu, wodurch der Cube jetzt anders reagiert?
Als Gegentest könnte ich auch wieder die alte FW draufspielen, oder gibt es irgendeine, die zu bevorzugen wäre?
Mir ist auch aufgefallen, dass es schon mal vorkommt, dass sich der Cube kurz "verabschiedet" (also im Log kommen disconnected / reappeared Meldungen) wenn man zB get Cube raw C35 oder get Cube raw X absetzt, ab halt nur manchmal - das wäre mir mit der alten Version so nicht aufgefallen...
Danke
Lag wohl doch an der Firmware. Mit der angefügen Version funktioniert 433MHz wieder.
Wahnsinn, Super, Danke! ;D ;D ;D
Neue Firmware geflashed, auf SlowRF und Frequenz 433.92 umgeschalten, ein paar mal auf die Fernbedienung
-> Output im Log!
-> neues IT-Device
-> kurz die on/off - Kommandos angepasst und die Motorleinwand fährt schon rauf und runter :D
Also kann nur nochmal sagen: DANKE! 8)
Zitat von: Telekatz am 08 Juni 2017, 18:16:02
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?
Der aktuelle Build ist jetzt wieder vollständig.
Bezüglich HMS und FS20 sollte es eigentlich keinen Unterschied in den Versionen geben.
Danke für die Aktualisierung. Ich probiers mal aus. Was ist der Unterschied zwischen CUBE_BL.bin und CUBEx4_BL.bin?
Bei CUBEx4_BL ist Hardware Autodetection aktiviert und man könnte zusätzliche Transceiver oder 1-Wire nachrüsten.
Edit:
Ich war selber schuld. Die Angabe des IoDev passte nicht mehr, weil ich es später umbenannt hatte.
Nachdem ich das korrigiert habe, konnte ich alle Thermostate pairen // DAU
Ich habe meinen Max Cube erfolgreich auf culfw geflashed.
War meinen vergesslichen Maxcube leid.
Ich bekomme allerdings ein Thermostat nicht gepaired. Ich habe das Thermostat resetet (3 Tasten) und wollte es über pairMode anlernen.
Da zählt aber nur der Countdown runter, mehr nicht. Also habe ich das Device aus FHEM gelöscht und erneut versuch, leider ohne Erfolg.
Hat jemand einen Hinweis für mich, was ich noch machen kann?
Seither habe ich auch folgende Logeinträge:
2017.07.08 10:15:37 1: readingsUpdate(,weekprofile-4-Wed-temp,17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C) missed to call readingsBeginUpdate first.
2017.07.08 10:15:37 1: stacktrace:
2017.07.08 10:15:37 1: main::readingsBulkUpdate called by ./FHEM/10_MAX.pm (236)
2017.07.08 10:15:37 1: main::MAX_ParseWeekProfile called by ./FHEM/10_MAX.pm (794)
2017.07.08 10:15:37 1: main::MAX_Parse called by fhem.pl (3608)
2017.07.08 10:15:37 1: main::Dispatch called by ./FHEM/14_CUL_MAX.pm (374)
2017.07.08 10:15:37 1: main::CUL_MAX_Parse called by fhem.pl (3608)
2017.07.08 10:15:37 1: main::Dispatch called by ./FHEM/00_CUL.pm (947)
2017.07.08 10:15:37 1: main::CUL_Parse called by ./FHEM/00_CUL.pm (831)
2017.07.08 10:15:37 1: main::CUL_Read called by fhem.pl (3412)
2017.07.08 10:15:37 1: main::CallFn called by fhem.pl (686)
Hier mal ein List vom Max Cube:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyACM0@9600 0000
DeviceName /dev/ttyACM0@9600
FD 20
FHTID 0000
NAME CUL0
NR 890
NR_CMD_LAST_H 2
PARTIAL
STATE Initialized
TYPE CUL
VERSION V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) CUBe (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2017-07-10 11:30:01 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2017-07-10 20:26:14 cmds B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
2017-07-10 20:25:55 credit10ms 8
2017-07-10 20:26:14 state Initialized
2017-07-10 20:00:44 uptime 0 01:41:25
2017-07-10 20:00:37 version V 1.25.00 a-culfw Build: 253 (2017-06-28_20-40-30) CUBe (F-Band: 868MHz)
XMIT_TIME:
1499711174.39125
1499711174.69191
Attributes:
icon cul_wlan
rfmode MAX
room Steuerung
...und von einem anderen Thermostat, welches funktioniert:
Internals:
CULMax_MSGCNT 5
CULMax_TIME 2017-07-07 09:01:56
DEF HeatingThermostat 14a679
IODev CULMax
LASTInputDev CULMax
MSGCNT 5
NAME Max.HZ.6
NR 535
RSSI -73.5
STATE 17.0 °C
TYPE MAX
addr 14a679
dstsetting 1
mode 0
rferror 0
serial MEQ1812774
type HeatingThermostat
Readings:
2017-07-07 09:01:56 RSSI -73.5
2017-07-06 21:44:54 TimeInformationHour 2
2017-07-07 09:00:23 battery ok
2017-07-07 09:01:56 boostDuration 25
2017-07-07 09:01:56 boostValveposition 80
2017-07-07 09:01:56 comfortTemperature 21.0
2017-07-07 09:01:56 decalcification Sat 12:00
2017-07-07 09:00:23 desiredTemperature 17.0
2017-07-07 09:01:56 ecoTemperature 17.0
2017-07-07 09:01:56 firmware 1.0
2017-07-07 09:01:56 groupid 0
2017-07-07 09:01:56 maxValveSetting 100
2017-07-07 09:01:56 maximumTemperature on
2017-07-07 09:01:56 measurementOffset 0.0
2017-07-07 09:01:56 minimumTemperature off
2017-07-07 09:00:23 mode auto
2017-07-08 04:45:05 msgcnt 8
2017-07-07 09:01:56 state 17.0 °C
2017-07-07 09:00:23 temperature 22.5
2017-07-07 09:01:56 testresult 161
2017-07-07 09:01:56 valveOffset 0
2017-07-07 09:00:23 valveposition 0
2017-07-07 09:01:56 weekprofile-0-Sat-temp 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-0-Sat-time 00:00-06:00 / 06:00-22:00 / 22:00-00:00
2017-07-07 09:01:56 weekprofile-1-Sun-temp 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-1-Sun-time 00:00-06:00 / 06:00-22:00 / 22:00-00:00
2017-07-07 09:01:56 weekprofile-2-Mon-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-2-Mon-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2017-07-07 09:01:56 weekprofile-3-Tue-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-3-Tue-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2017-07-07 09:01:56 weekprofile-4-Wed-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-4-Wed-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2017-07-07 09:01:56 weekprofile-5-Thu-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-5-Thu-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2017-07-07 09:01:56 weekprofile-6-Fri-temp 17.0 °C / 21.0 °C / 17.0 °C / 21.0 °C / 17.0 °C
2017-07-07 09:01:56 weekprofile-6-Fri-time 00:00-06:00 / 06:00-09:00 / 09:00-17:00 / 17:00-23:00 / 23:00-00:00
2017-07-07 09:01:56 windowOpenDuration 15
2017-07-07 09:01:56 windowOpenTemperature 12.0
Internals:
interfaces thermostat;battery;temperature
Attributes:
IODev CULMax
alias Küche
icon hc_wht_regler
room Küche
Hi, ich habe mir nun eben einen Max Cube bei Kleinanzeigen geschossen und will den zu CUL flashen. Dazu zwei Fragen:
Wo finde ich die aktuellste Version?
Funktioniert der Cube danach auch via LAN?
Linux Kenntnisse sind vorhanden. Aber mit CUL und die Einbindung dessen in FHEM bisher keine Erfahrung.
Kann mir jemand für Daus erklären, wie ich am besten zum Flashen vorgehe?
Danke euch!
https://forum.fhem.de/index.php/topic,38404.0.html
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich scheine was das Flashing angeht, nicht die hellste Leuchte zu sein :'(
Ich habe a-culfw_1.25.01_build_258.zip von mediafire runtergeladen und entpackt. Check
Im Verzeichnis "CUBe" habe ich die Datei "CUBE_BL.bin" gefunden. Check
Die SAM-BA Software habe ich runter geladen und installiert. Check
Wo befindet sich die Datei "bootloader_CUBE.bin"? Im ZIP scheint diese zu fehlen.
Sorry, sollte ich mich doof anstellen. Ich denke nur, dass ich den MAX! Cube nach einem falschen Flash-Versuch in die Tonne kloppen kann?
Das wäre natürlich schade, daher würde ich mich über ein wenig Hilfe für Anfänger freuen.
Danke euch vorab.
Lade die Version a-culfw_1.20.08_build_220_master.zip herunter. Da ist der Bootloader noch drin.
Zitat von: Telekatz am 19 Juli 2017, 21:40:51
Lade die Version a-culfw_1.20.08_build_220_master.zip herunter. Da ist der Bootloader noch drin.
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?
Die CUBE_BL.bin nimmst du aus der aktuellen Version.
Das Gehäuse ist nicht verschraubt. Der obere Teil des Gehäuses ist nur draufgesteckt und rastet mit 4 Rastnasen ein.
Der Cube ist geflasht ;D Wie muss ich ihn nun in FHEM definieren? Ich möchte ihn via Netzwerk/IP einbinden.
Ok, ich bin ein Stück weiter - so scheint der Cube bei mir in FHEM erstmal ein Lebenszeichen zu zeigen:
define cul868 CUL 192.168.178.64:2323 0000
attr cul868 model CUL
Via get cul868 versin spuckt fhem folgendes aus:
cul868 version => V 1.25.01 a-culfw Build: 257 (2017-07-14_17-38-58) CUBe (F-Band: 868MHz)
Die nächste Baustelle ist nun für mich, wie bekomme ich ein MAX! EcoTaster mit dem CUL ans laufen? Freue mich über Hilfe.
Zitat von: eckonator am 22 Juli 2017, 15:01:09
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
# Telekatz, vielen Dank für die ausführliche Hilfe.
Jetzt habe ich auch meinen zeiten Cube problemlos geflasht.
Dieser bekommt jedoch die gleiche Serial-ID [usb-03eb_AT91USBSerial1-if00].
Gibt es eine Möglichkeit in den Voreinstellungen diese zu ändern ?
DANKE Ralf
Eine kurze Frage an die Spezialisten hier: Wo finde ich nen Schaltplan bzw. eine kurze Beschreibung, wie die zusätzlichen Transceiver beim MAXCube (x4) anzuschließen sind?
Danke & Gruß
Holger
Zitat von: RalfPit am 03 September 2017, 19:25:16
Dieser bekommt jedoch die gleiche Serial-ID [usb-03eb_AT91USBSerial1-if00].
Gibt es eine Möglichkeit in den Voreinstellungen diese zu ändern ?
Dazu musst Du die a-culfw selbst kompilieren und für jeden Cube in
default.h den Wert in der Zeile
#define USB_DESCRIPTOR_SN '1' ändern, z.B. auf 0. Damit heißen die Devices dann ...USBSerial0... usw.
Zitat von: hollyghost am 03 September 2017, 19:55:08
Eine kurze Frage an die Spezialisten hier: Wo finde ich nen Schaltplan bzw. eine kurze Beschreibung, wie die zusätzlichen Transceiver beim MAXCube (x4) anzuschließen sind?
Danke & Gruß
Holger
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.
Zitat von: Telekatz am 03 September 2017, 21:52:05
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 [emoji106]
Gesendet von iPhone mit Tapatalk
Zitat von: mahowi am 03 September 2017, 20:31:26
Dazu musst Du die a-culfw selbst kompilieren und für jeden Cube in default.h den Wert in der Zeile #define USB_DESCRIPTOR_SN '1' ändern, z.B. auf 0. Damit heißen die Devices dann ...USBSerial0... usw.
@mahowi
Danke für die schnelle Lösung. Selbst kompilieren ist jedoch für einen alten Mann wie mich ohne eine einfache Anleitung wie z.B. von Telekatz zu schwierig. Außerdem erkennt mein PI von meinem 8-Port USB-Hub nur 4.
Habe jetzt entsprechend der Vorgabe von Telekatz beide Cubes über LAN angebunden ... geht auch.
Nochmals Danke Ralf
Hallo, ich bin neu hier im Forum, weil ich eine Frage zur Verwendung des Max Cube als CUL bzw. CUNO haben :)
Ich hatte Gelegenheit diesen günstig in einem Bundle bei Medion zu kaufen, weil diese wohl einen Ausverkauf gemacht haben.
Dachte zwar, dass ich mit 20€ ein Schnäppchen für den Einstieg mit FHEM in Homematic gemacht habe, aber dann habe ich gestern den HM-MOD-RPI-PCB entdeckt... Naja andere Geschichte.
Also, meine FHEM Installation läuft schon auf einem Raspberry PI 1. Also die älteste Generation, aber die mit viel RAM.
Nun frage ich mich, wie die beste Verwendung des Max Cube ist?
Man kann ihn ja wohl über LAN als auch direkt per USB an den Raspberry Pi anschließen.
Bei LAN soll es ja zu Timing Problemen mit dem Funk kommen, ließt man im Wiki mehrfach.
Auf der anderen Seite soll der USB Stack des Raspberry PIs auch nicht optimal sein, sodass es hier ebenfalls zu Timing Problemen kommen kann.
Welche Variante würdet ihr denn empfehlen, und wieso?
Schon einmal vielen Dank!
TL;DR: Max Cube per LAN als CUN oder USB als CUL mit einem alten Raspberry Pi verbinden?
Zitat von: Holzlenkrad am 06 September 2017, 12:09:53
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.
Hallo Leute,
das ist echt der Hammer. Da will ich die über den Sommer für schmales Geld geschossenen Max! Thermostate am Cube in Betrieb nehmen und worüber stolpere ich?!? Diesen Hammer Beitrag :-). Vielen Dank für eure Arbeit. Habe meinen Cube (5 Jahre alt) mit Win10 geflasht und per Telnet im eine fixe IP verpasst und in FHEM angelegt. Soweit hat alles 100% funktioniert. Die nächsten Tage sind dann die 10 Thermostate dran.
Viele Grüße
Vielen Dank für die Firmware, um meinen Max Cube umzuflashen!
Bin gerade dabei die Software Seite fertig zu machen.
Leider spielt die Atmel Homepage bei der Beschaffung von SAM-BA nicht so mit. Ich bekomme einfach keinen Link zum Download zugeschickt. [emoji58]
Zitat von: Telekatz am 03 September 2017, 21:52:05
Da bin ich bis jetzt noch nicht dazu gekommen, das zu beschreiben. Die entsprechenden Signale muss man an diversen Punkten auf der Platine abgreifen. Die Belegung kann man aus der board.h entnehmen.
Das Bild zeigt neben den SPI Anschlüssen noch:
In der board.h sind aber noch die OUT-Pins/IRQ-Pins angegeben:
Ich wäre für eine Hilfestellung dankbar!
Alex
PS: Grandiose Arbeit!
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.
Zitat von: sash5000 am 12 September 2017, 11:09:09
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.
Zitat von: Telekatz am 12 September 2017, 21:08:19
Die OUT Pins waren dann der Punkt, an dem der Nachbau kompliziert wurde. Die muss man nämlich direkt am µC abgreifen. Deshalb habe ich dann erstmal mit dem MapleCUN ein einfacher nachbaubares Interface entworfen, anstatt die Cube Erweiterung weiter zu verfolgen.
Benötigt werden die OUT Pins aber auch nur für SlowRF.
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?
Moin
Ich wollte mich hier noch mal ganz herzlich bedanken. Gestern meinen Cube erhalten, umgeflasht und alles chick.
Zwei Schwierigkeiten gab es zu umschiffen, da zum einen die Bootloader Datei nicht zu finden war, und zum anderen der Port zur Definition des CUL(N) nicht klar war. Ich habe mich dann mutig durch den thread gewuehlt, und die Infos gefunden. Bootloader ist in aculfw 1.20 V22068 oder so? Und der Port ist 2323. Eventuell koennte Telekatz das im ersten Post noch ergaenzen.
Ansonsten aber top. Danke nochmals
Gruss Christoph
P.S.: Man koennte ja fast einen Wiki-Beitrag erstellen, da muss ich mal sehen, wie es mit meiner Zeit aussieht.
Zitat von: adn77 am 13 September 2017, 10:57:29
Danke für die schnelle Antwort!
Wenn man nur zwei weitere Sensoren verwenden wollte, könnte man dann die PA9, PB20, PB28 weglassen und stattdessen die board.h auf die anderen freien Pins anpassen? Oder sind PA9, PB20, PB28 spezielle Interrupt Leitungen?
Die OUT Pins brauchen keinen Interrupt. Deshalb ist es egal, welchen Pin man dafür nimmt.
Auf der Homepage von Atmel finde ich zwei Software Versionen: 2.16 als Installer ubd 3.1.4 als Zip Archiv.
Beide Versionen funktionieren bei mir nicht.
Beim 2.16 Installer öffnet sich nur ein Mini Fenster und man kann nichts auswählen.
Die 3.1.4 Software scheint ein Kommandozeilen-Tool zu sein. Es liest sich in der Anleitung aber nach einem normalen Windows Programm.
Vielleicht könnte mir jemand bitte weiterhelfen.
Grüße Daniel
Moin
Ich habe auch beides runtergeladen. Die 3er Version ist irgendwie seltsam. Mit der 2er lief es problemlos. Installiert, als Admin gestartet, und nach Anleitung vorgegangen!
Gruss Christoph
Danke!
Habe es jetzt mit einem anderen Rechner probiert und da läuft es.
Zitat von: Telekatz am 03 September 2017, 21:52:05
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.
Zitat von: adn77 am 15 September 2017, 16:49:08
Sorry, ich muss nochmal "dumm" fragen...
Die SPI Kontakte auf der Platinenunterseite des CUBe sollten doch die des CC1101 Moduls sein, oder?
Das würde bedeuten (auf dem Bild von oben gezählt):
- VCC
- GND
- MOSI
- SCLK
- MISO
- GDO2
- GDO0
- CS
Das ist die Belegung der China Briefmarken Module.
Die ELV Module haben eine andere Belegung:
- MOSI
- SCK
- MISO
- GDO2
- GDO0
- CS
- GND
- VCC
unter https://wiki.fhem.de/wiki/HomeMatic_Asksin_Library gibt es Bilder & Zeichnungen der e3Q CC1101 Module
Kurze
Erfolgsmeldung!
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
Hallo Telekatz,
es gibt leider einen kleinen Fehler mit den culfw Versionen >
a-culfw_1.24.02_build_209 die auf einen Max!Cube geflasht werden.
Es wirkt sich so aus, dass FS20 Steckdosen nicht mehr angelernt werden können.
Szenario:
Ich habe einen Max!Cube wie im 1. Beitrag beschrieben mit bootloader (aus dem Package "a-culfw_1.20.08_build_220_master") und der aktuellen culfw "a-culfw_1.26.00_build_268" geflasht und in FHEM wie folgt eingebunden:
define CULSlowRF CUL 192.168.XXX.XXX:2323 0000
attr CULSlowRF model CUN
attr CULSlowRF rfmode SlowRF
attr CULSlowRF room Gateways
anschließend einen FS20 Dimmer angelegt:
define Terra.Compact60 FS20 12121212 1111
attr Terra.Compact60 IODev CULSlowRF
attr Terra.Compact60 model fs20di
attr Terra.Compact60 room Terrarium
und dann den Dimmer in den Anlernmodus versetzt. Über FHEM folgendes ausgeführt:
set Terra.Compact60 off
set Terra.Compact60 on
Leider hat sich der Dimmer nicht geregt.
Nach einigen Tests und dem Austausch in diesem Artikel (https://forum.fhem.de/index.php/topic,76582.0.html (https://forum.fhem.de/index.php/topic,76582.0.html)) wurden verschiedene culfw ausprobiert.
Test's:
- 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! ;)
Ist in der nächsten Version (1.26.01) korrigiert.
Auch von mir ein Hinweis - wollte gestern die 1.26.01 auf den MapleCUN flashen. Anschließend waren alle 4 (866x3 und 433) tot und nicht mehr ansprechbar. Mehrfaches ne flashen brachte keine Änderung. Ein flashen der 1.26.00 funktionierte hingegen problemlos. Da steckt irgendwo ein Fehlerchen drin.
Habe gerade die 1.26.01 Versionen aus dem Archiv ausprobiert. Es haben beide funktioniert.
Blinkt der MapleCUN? Über LAN oder USB angeschlossen?
Per USB, er blinkte auch. Wie gesagt, die andere Version ist anstandslos durchgelaufen.
Gesendet von iPhone mit Tapatalk
Was liefert "get <namedesCULs> version" zurück?
Hi,
V 1.26.00 a-culfw Build: 267 (2017-08-25_08-49-09) MapleCUNx4_0F (F-Band: 868MHz)
Also wie geflasht
Gesendet von iPhone mit Tapatalk
Und was kommt bei der 1.26.01?
Nichts.. da lässt er sich nicht ansprechen - bzw keiner. Lsusb liefert aber auch nur Müll, insofern zu erwarten.
Gesendet von iPhone mit Tapatalk
Welche der 1.26.01 Dateien hast du verwedet?
Ein Script von Ranseyer
#! /bin/sh
while (true); do
sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5500_BL.bin
#sudo dfu-util --verbose --device 1eaf:0003 --cfg 1 --alt 2 --download MapleCUNx4_W5100_BL.bin
#sudo dfu-util -d 1eaf:0003 -a 1 -D ~/src/IRMP_STM32/bootloader/map.bin
if [ $? -eq 0 ]
then break
fi
sleep 1
done
exit
Gesendet von iPhone mit Tapatalk
Teste mal die angefügte Version.
Hi,
besten Dank, teste ich heute Abend mal aus.
Grüße
Sascha
Ich hab heute einen Cube bekommen und würde ihn gerne umflashen, aber es scheitert an sam-ba. Ich habe es als guest probiert, ging nicht weil ich keinen downloadlink per mail bekomme. Ich hab mich dann registriert, aber ich bleibe dort nicht eingeloggt und somit kann ich auch nichts runterladen. Gibt es da einen Trick??
Versuch es mal über diesen Link: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=Atmel%20SAM-BA%20In-system%20Programmer (http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=Atmel%20SAM-BA%20In-system%20Programmer)
Der Link funktioniert! Super... warum nicht gleich so! Danke!!!
Laut dem Atmel Datenblatt vom AT91SAM7x256 ist PA9=Pin 14, PB20=Pin 65 und PB28=Pin 10.
Pin 10 und Pin 65 kann ich in dem angehängten Bild aus Beitrag #831 erkennen. (Vorausgesetzt Pin 1 ist unten rechts im Bild).
Aber PA9 (Pin 14) ist in dem Bild nicht angeschlossen, vielmehr sieht es nach PIN67 (PB22) aus?
Stimmt das Bild? Oder passt es nicht zur aktuellen board.h?
Danke!
Da passt die board.h nicht zu meinem Cube. Pin 14 (PA9) ist etwas schwer anzulöten, da Pin 13 und 15 belegt sind. Viel einfacher ist es, den Draht zwischen zwei unbelegten Pins zu löten. Pin 67 = PB22 ist dann der richtige Pin für PORT 2.
Hallo,
ich versuche gerade die a-culfw mit gänderten out Pin´s zu compilieren. (möchte nur 2 zusätzliche cc1101 betreiben)
leider kommen da folgende Fehlermeldungen und nach dem übertragen der firmware auf den cube ist er per lan nicht erreichbar, per USB kann ich zumindest die Version abfragen dort steht dann private build
../../clib/fband.c: In function 'readEEpromValue':
../../clib/fband.c:24:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
d = erb((uint8_t *)addr);
^
../../clib/fncollection.c: In function 'read_eeprom':
../../clib/fncollection.c:154:13: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
d = erb((uint8_t *)addr);
^
../../clib/fncollection.c: In function 'write_eeprom':
../../clib/fncollection.c:218:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
ewb((uint8_t*)addr, hb[d-1]);
^
../../clib/fncollection.c:228:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
ewb((uint8_t*)++addr, hb[0]);
^
vielleicht mache aber auch ich einen Fehler.
Ich habe debian 8 und hole mir per git clone https://github.com/heliflieger/a-culfw die daten
anschliessend gehe ich in das CUBe verzeichnis und starte mit make all den compiler
in board.h kann ich ja dann die out pins ändern aber wenns so schon nicht fehlerfrei durchläuft lass ich das erstmal.
muss ich in einer Datei noch diverse einstellungen vor dem make machen ?
vielleicht hat jemand einen Tip für mich..
Vielen Dank
Gruß
Markus
Das ist keine Fehlermeldung, sondern nur eine Warnung. Funktioniert aber trotzdem.
@Telekatz vielen Dank hat funktioniert hab für den ersten externen TRX den Out auf PB24 gelegt IT senden geht jetzt über das 433Mhz modul nur wenn ich den PB25 für den OUT des 2 externen TRX mit 9 tausche geht LAN nicht mehr.
irgendwo hab ich hier was übersehen.....
PA9 oder PB9? An PB9 ist der Ethernet PHY angeschlossen, PA9 ist frei.
Super vielen Dank für den schnellen Denkanstoß !! ich hatte nicht auf A und B geachtet :-[
Jetzt schauts gut aus ...
Weil es sich um eine Frage bzgl Multi-CUL handelt, frage ich mal hier (gehört sonst evtl. in den a-culfw Bereich).
Ich habe die Anpassung bezüglich der Credit-Rückgewinnung gemacht, weil ich auch der Meinung bin, man sollte sich auf 1% pro Stunde beziehen und nicht auf 0,25 Stunden (würde wahrscheinlich auch viele Supportanfragen erschlagen, die wegen fehelender Credits entstehen).
--- a-culfw/culfw/clib/rf_send.h.orig 2017-09-12 17:41:13.068210110 +0200
+++ a-culfw/culfw/clib/rf_send.h 2017-09-12 17:33:48.454073931 +0200
@@ -15,8 +15,8 @@
void addParityAndSendData(uint8_t *hb, uint8_t hblen,
uint8_t startcs, uint8_t repeat);
extern uint16_t credit_10ms;
-#define MAX_CREDIT 900 // max 9 seconds burst / 25% of the hourly budget
+#define MAX_CREDIT 3600 // max 9 seconds burst / 25% of the hourly budget
#endif
Nun zur eigentlichen Frage, als zweiten Receiver habe ich einen 433MHz für alle meine günstigen Steckdosen und Schalter.
Insbesondere wenn ich Lichtscenen mit vielen Lampen schalte bleiben meine Credits immer erhalten (vermindern sich nicht durch's Schalten)...
1.) Verbrauchen Intertechno Befehle auch Credits?
2.) Hat jeder der bis zu vier Tranceiver eigentlich ein eigenes Credit Budget?
Danke,
Alex
Zitat von: adn77 am 12 Oktober 2017, 08:55:34
1.) Verbrauchen Intertechno Befehle auch Credits?
Da Intertechno auf 433MHz sendet gibt es hier keine 1% Regel. Es werden keine Credits verbraucht.
Zitat von: adn77 am 12 Oktober 2017, 08:55:34
2.) Hat jeder der bis zu vier Tranceiver eigentlich ein eigenes Credit Budget?
Alle Transceiver teilen sich ein gemeinsames Credit Budget.
Vielen Dank für die prompte Antwort!
Gut zu wissen, dass es bei 433MHz keine Belegungsbeschränkung gibt.
Hallo,
Ich habe jetzt so gut wie alles durchgelesen, aber dennoch stehe ich auf dem Schlauch.
Ich möchte mein Max Cube flashen .
Was habe ich bisher gemacht :
- Brücke eingebaut
- firmware durch ein und ausstecken gelöscht
- Brücke wieder entfernt
- Software Sam Ba 2.17 for Windows auf ein 10 Rechner installiert und neu gebootet
- beim Einstecken des cube an usb sehe ich einen neuen Com Board
- Software als admin gestartet
- neuen com Board ausgewählt
- Datei .... 7x.256 ausgewählt
-und dann Connect
- Fenster verschwindet
- warten
Aber es passiert nichts !
Was mach ich falsch ?
Zitat von: wendeling am 24 Oktober 2017, 10:57:40
- neuen com Board ausgewählt
- Datei .... 7x.256 ausgewählt
-und dann Connect
- Fenster verschwindet
Da muss man kein neues com Board oder eine Datei auswählen. In der Liste steht schon das passende Board "at91sam7x256-ek".
Es gibt auch Cubes mit einem at91sam7x512. Da wählt man dann als Board "at91sam7x512-ek" aus.
Ich hatte damals auch Probleme mit Sam-Ba unter Windows, daher hab ich den Cube an den Raspi angeschlossen und geflasht. (Antwort #263 (https://forum.fhem.de/index.php/topic,38404.msg378455.html#msg378455) hier im Thread)
Hallo,
ok, bin jetzt doch mit Windows einen schritt weiter!
jetzt blinkt die LED und die LED 3 leuchtet.
Habe mir jetzt "a-culfw_1.26.01_build_272" gezogen
welche Datei muss ich nun nehmen ?
CUL/CUL_V2_MAX_868MHZ.hex ?
wenn ich Max geräte ansteuern will !
Welche Datei genommen werden muss steht im ersten Beitrag.
Hallo,
ich glaub ich hab es geschafft!
Jetzt blinkt die Power LED in Sekunden Takt und wenn ich ein Netzwerkkabel anstecke leuchtet auch die Internet LED.
Soweit ok?
wie kann ich die Adresse ändern ?
wie lerne ich nun den Cube an?
und wie kann ich dann MaxThermostate anlernen ?
sorry für die einfachen und blöden Fragen?
a => https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten
b + c => https://wiki.fhem.de/wiki/MAX
Nachdem ich den MaxCube jetzt schon ein paar Wochen als IO Device für Homematic Geräte im Einsatz habe, wollte ich mal fragen, ob man das Blinken der Power LED irgendwie abschalten kann (Batterie leuchtet dauerhaft).
Zu Anfang dachte ich ja noch, das gibt sich wenn die ersten Geräte angelernt worden sind. Fehlanzeige.
Leider nervt das Blinken doch ein bisschen, außerdem sind blinkende LEDs ja eigentlich immer ein Fehlerindikator...
set Name_Deines_MaxCubes led 00
Ich habe einen MaxCube um einen 433MHz Transceiver ergänzt und hoffe alles richtig gelötet und geflasht zu haben. Ich möchte mit dem eingebauten Transceiver meine MAX Komponenten abfragen, und mit dem external 433 MHz Transceiver auf Port1 meine Intertechno Steckdosen schalten.
Bisher habe ich es nicht geschafft, auf meinem CUBEx4 den external 433 MHz Transceiver auf Port1 in Betrieb zu nehmen.
Fragen:
- 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
Wenn ich den weiteren Transceiver über "STACKABLE_CC" definiere,
#++++++++++++++ CUL00 ++++++++++++++++++++++++++++++++++++++
#
define CUL00 CUL culfw.fritz.box:2323 0000
attr CUL00 icon cul_868
attr CUL00 model CUL
attr CUL00 rfmode MAX
attr CUL00 room Gateways
#
define CUL01 STACKABLE_CC CUL00
attr CUL01 room Gateways
attr CUL01 icon cul_cul
verschwindet der Cube aus FHEM, um nach wenigen Sekunden wieder aufzutauchen:
2017.12.08 22:15:59 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:15:59 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:15:59 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:09 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:09 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:09 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:09 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:16 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:17 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:17 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:17 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:45 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:45 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:45 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:45 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.08 22:16:59 1: culfw.fritz.box:2323 disconnected, waiting to reappear (CUL00)
2017.12.08 22:16:59 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.08 22:16:59 1: culfw.fritz.box:2323 reappeared (CUL00)
2017.12.08 22:16:59 3: CUL01: Possible commands: bCFiAZNEGMKLUYRTVWXfz
Wenn ich den weiteren Transceiver über "STACKABLE" definiere, funktioniert der Zugriff auf das Device
FHEM:DEVIO:CubeCul433Stack:9600 0000 nicht.
#
define CUL00 CUL culfw.fritz.box:2323 0000
attr CUL00 icon cul_868
attr CUL00 model CUL
attr CUL00 rfmode MAX
attr CUL00 room Gateways
#
define CubeCul433Stack STACKABLE CUL00
attr CubeCul433Stack room Gateways
attr CubeCul433Stack verbose 5
define CubeCul433 CUL FHEM:DEVIO:CubeCul433Stack:9600 0000
attr CubeCul433 room Gateways
erzeugt die folgende Fehlermeldung im Logfile:
2017.12.10 12:48:03 3: Opening CUL00 device culfw.fritz.box:2323
2017.12.10 12:48:03 3: CUL00: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2017.12.10 12:48:03 3: CUL00 device opened
2017.12.10 12:48:03 2: Switched CUL00 rfmode to MAX
2017.12.10 12:48:03 3: Opening CubeCul433 device FHEM:DEVIO:CubeCul433Stack:9600
2017.12.10 12:48:03 5: CubeCul433Stack read: *V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
2017.12.10 12:48:03 5: CubeCul433Stack read: *? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z
2017.12.10 12:48:03 3: CubeCul433: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2017.12.10 12:48:06 1: Cannot init FHEM:DEVIO:CubeCul433Stack:9600, ignoring it (CubeCul433)
2017.12.10 12:48:06 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
Hat jemand eine Idee, wo ich suchen muss?
- bei meinen Lötkünsten?
- bei der Definition in FHEM?
- fehlt in FHEM noch die CUBEx4 Erweiterung?
Zitat von: uelpenich am 10 Dezember 2017, 13:30:23
- Wie kann ich kontrollieren, ob die Hardware Erweiterung richtig funktioniert? An vielen Stellen sind die möglichen Befehle beschrieben, die culfw versteht (B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *), aber ich habe bisher noch nicht herausgefunden, wie man die einzelnen Transmitter anspricht.
Um zu testen, ob die Hardware funktioniert würde ich den Cube über USB an einen Rechner hängen und ihn erstmal mit einem Terminalprogramm testen. Die einzelnen Transceiver werden dabei über ein vorangestellten * vor dem Befehl angesprochen.
Gib im Terminal folgende Befehle ein:
V
*V
X21
Zr
*X21
C99
*C99
Die Ausgabe vom Cube sollte ungefähr so aussehen:
V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
*V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 433MHz)
072E4607C626FF0C
450000060021656A
C8930322F834073F
28166C434091876B
F85610AC0B3C1141
00597F8E81350B00
*0D2E2D07D3913D04
*320000060010B071
*57C43023B9000700
*18146C070090876B
*F85611EF0C3D1F41
*00597F1788310B00
Er sollte jetzt auch MAX und Intertechno empfangen können, z.B.:
Z0B2406300FEF7412345600524E
Z0B2506300FEF74123456001050
*s2C6FEE6013; 464: 9536
*i00115103
*i00115404
Zitat von: uelpenich am 10 Dezember 2017, 13:30:23
- Es gibt einige Beschreibungen, wie man in FHEM mit Transceiver erweiterte (MapleCUN) oder gestackte CULs (SCC) definiert, aber keine Beschreibung für einen erweiterten CUBE. Ich habe versucht, die vorhandenen Bescheibungen auf meinen CUBEx4_BL zu übertragen, laufe aber auf Probleme
Ein erweiterter Cube wird genauso eingebunden wie ein MapleCUN. Entweder mit STACKABLE oder mit STACKABLE_CC. Meine Konfiguration für eine Cube sieht z.B. so aus (2x SlowRF, 1x HM):
define CUBe_0 CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1235
attr CUBe_0 rfmode SlowRF
attr CUBe_0 room System
define CUBe_0_SCC STACKABLE CUBe_0
attr CUBe_0_SCC room System
define CUBe_1 CUL FHEM:DEVIO:CUBe_0_SCC:42 2345
attr CUBe_1 room System
define CUBe_1_SCC STACKABLE CUBe_1
attr CUBe_1_SCC room System
define CUBe_2 CUL FHEM:DEVIO:CUBe_1_SCC:42 3412
attr CUBe_2 hmId F11135
attr CUBe_2 rfmode HomeMatic
attr CUBe_2 room SystemZitat von: uelpenich am 10 Dezember 2017, 13:30:23
Wenn ich den weiteren Transceiver über "STACKABLE" definiere, funktioniert der Zugriff auf das Device FHEM:DEVIO:CubeCul433Stack:9600 0000 nicht.
Die Module STACKABLE und STACKABLE_CC funktionieren nicht gleichzeitig. Wenn du STACKABLE benutzt solltest du erst einmal alle STACKABLE_CC löschen und FHEM neu starten. Und unter Windows habe ich STACKABLE auch nicht zum laufen gebracht.
Wenn die Antwort auf einer der vorhergehenden 59 Seiten steht, bitte ich zu entschuldigen, dass ich nicht alles gelesen habe. Ich habe zwei Fragen:
a) Welchen Vorteil bietet mir das umflashen?
b) wenn das schiefgeht, kann ich mit Fhem und den Max Komponenten OHNE den Cube arbeiten?
Zitat von: BHef am 10 Dezember 2017, 18:09:00
Wenn die Antwort auf einer der vorhergehenden 59 Seiten steht, bitte ich zu entschuldigen, dass ich nicht alles gelesen habe. Ich habe zwei Fragen:
a) Welchen Vorteil bietet mir das umflashen?
Das wurde erst kürzlich hier diskutiert:
https://forum.fhem.de/index.php/topic,77590.0.html (https://forum.fhem.de/index.php/topic,77590.0.html)
Zitat von: BHef am 10 Dezember 2017, 18:09:00
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.
Super, vielen Dank!
Zitat von: Telekatz am 10 Dezember 2017, 14:39:30
Vielen Dank für die schnelle Antwort.
Die einzelnen Transceiver werden dabei über ein vorangestellten * vor dem Befehl angesprochen.Das war der entscheidende Hinweis für meine weitere Fehlersuche. Leider ist das vorangestellte * nirgendwo beschrieben. Es wäre schön, wenn es in die http://culfw.de/commandref.html (http://culfw.de/commandref.html) aufgenommen würde.
Um zu testen, ob die Hardware funktioniert würde ich den Cube über USB an einen Rechner hängen und ihn erstmal mit einem Terminalprogramm testen. Der Cube hat sich an der USB Schnittstelle so verabschiedet wir unter FHEM genau in dem Augenblick, wo der nachgerüstete Transceiver das erste mal angesprochen wird. Deshalb gehe ich von einem Löt- oder Hardware Fehler aus.
Als 433MHz Transceiver habe ich einen AS07-M1101S V3.1 eingesetzt. Die Bezeichnung der AS07 Anschlußpins ist nicht genau deckungsgleich mit den Beschreibungen. Ich habe die Belegung schon mehrfach verglichen und kann keinen Fehler finden (oder ich sehe den Wald vor lauter Bäumen nicht). Hier ist meine Belegung (vergl. https://www.devicemart.co.kr/1323011 (https://www.devicemart.co.kr/1323011)):
| 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. |
Die culfw habe ich nach Anleitung und mit dem Patch von Loetzimmer gebaut.
In der Zwischenzeit habe ich einen zweiten Cube mit einem 868MHz Transceiver ausgerüstet. Der arbeitet wie beabsichtigt. Für die Einbindung in FHEM habe ich die "STACKABLE" Variante gewählt.
Die Module STACKABLE und STACKABLE_CC funktionieren nicht gleichzeitig. Das habe ich schon geahnt, da nach einem Wechsel von STACKABLE_CC nach STACKABLE folgendes in der Logdatei aufgetaucht ist:
2017.12.08 22:25:19 2: Switched CUL00 rfmode to MAX
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOOpenFn redefined at ./FHEM/16_STACKABLE.pm line 114, <$fh> line 107.
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOReadFn redefined at ./FHEM/16_STACKABLE.pm line 124, <$fh> line 107.
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOWriteFn redefined at ./FHEM/16_STACKABLE.pm line 154, <$fh> line 107.
2017.12.08 22:25:19 3: Opening CUL01 device FHEM:DEVIO:CUL01Stack:9600
Zitat von: uelpenich am 11 Dezember 2017, 12:45:17
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?
Hallo Telekatz,
Zitat von: Telekatz am 11 Dezember 2017, 21:32:21
Wann genau stürzt er ab? Bei *X21 oder erst bei *Zr? Hast du auch schon mal die Debugausgabe auf ST2 mitgeloggt?
Der internal Transceiver arbeitet ganz normal (Zr), und beliebig lange. Der Absturz erfolgt bei *X21
Beim Einschalten des Cubes wird am Debug Port (Speed = 115200 Baud) folgendes angezeigt:
-I- Getting new Started Project --
-I- CUBEx4
-I- Compiled: Dec 6 2017 21:20:20 --
-I- init Flash
-I- Initializing the SPI and AT45 drivers
-I- At45 enabled
-I- SPI interrupt enabled
-I- Waiting for a dataflash to be connected ...
-I- AT45DB041D detected
-I- Device identifier: 0x0000241F
-I- EE Magic: 1 26 Start 792
-I- Flash Serial: cb9bf4e2
-I- init Timer
-I- init EEprom
-I- - MAC 0:80:41:9b:f4:e2
-I- ** Valid PHY Found: 1
-I- DM9161_ResetPhy
-I- Detected CC0: PN 0x00 VER 0x03
-I- Detected CC1: PN 0x00 VER 0x14
-I- Not detected CC2: PN 0xff VER 0xff
-I- Not detected CC3: PN 0xff VER 0xff
-I- Not detected onewire
-I- init USB
-I- CDCDSerialDriver_Initialize
USBD_Init
-I- init Complete
Res EoBRes CfgEpt0 NewReq Std gDesc Dev EoBRes CfgEpt0 NewReq Std sAddr SetAddr(25) NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Str0 NewReq Std gDesc Str1 NewReq Std gDesc Qua -W- Sta 0x888A8 [0] -W- _ NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std sCfg SetCfg(1) CfgEpt3 CfgEpt1 CfgEpt2 ConfigurationChanged NewReq gLineCoding NewReq sControlLineState(0, 0) NewReq sLineCoding NewReq gLineCoding
Jetzt gebe ich die von Dir zum Test angegebenen Kommandos ein:
V
*V
X21
ZrAm Debug Port erscheint:
0:Set RF mode to 1
0:Set RF mode to 3
Der interne Transceiver arbeitet jetzt ganz normal und protokolliert die MAX Telegramme.
Der Absturz / der Neustart erfolgt nach dem Kommando
*X21. Das USB Terminal meldet
PUTTY fatal Error - Error reading from serial device. Die Ausgabe am Debug Port ist
-I- Getting new Started Project --
-I- CUBEx4 . . . und weiter mit dem ganzen Rest, den wir oben beim Einschalten sehen . . .
Ich kann mir das nur mit vertauschten Anschlüssen oder einer kaputten Briefmarke erklären. Hast Du eine Idee?
Gruß Werner
-I- Detected CC1: PN 0x00 VER 0x14
Da 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.
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.
Hallo,
ich habe seit gestern auch einen Max!Cube aus einem Medion-Starterset. Da ich mir gleich 2 Sets zugelegt habe, wollte ich den einen umflashen.
Ich habe es mit Sam-ba v2.17 und v2.18 unter Win10 als Admin "versucht". Jedes Mal wurde der COM-Port richtig eingetragen.
Jedoch kommt nach Send-File nur 1% und nach Execute ebenfalls nur 1% und es tut sich nix mehr (ist das normal?).
Anschließend habe ich mit TeraTerm die die Firmware geflasht und jetzt blinkt eine LED im Sekundentakt (scheint wohl richtig geflasht zu sein?).
Den Cube habe ich an einem RPi2 angesteckt, mit einer frischen FHEM-Installation von gestern Abend.
Sollte der Cube nun als CUL automatisch erkannt werden oder bedarf es noch irgendwelcher Schritte? Mir wurde nämlich gesagt, er solle automatisch erkannt werden.
Und ich weiß jetzt nicht ob das flashen richtig funktioniert hat, oder nicht :(
Den anderen MaxCube mit Original-Firmware habe ich in FHEM eingebunden und er läuft einwandfrei. Wobei ich absoluter FHEM-Neuling bin. Deshalb bitte ich um Nachsicht ;)
Zitat von: Allodo am 28 Dezember 2017, 14:09:27
Sollte der Cube nun als CUL automatisch erkannt werden oder bedarf es noch irgendwelcher Schritte? Mir wurde nämlich gesagt, er solle automatisch erkannt werden.
Und ich weiß jetzt nicht ob das flashen richtig funktioniert hat, oder nicht :(
Der Cube wird nicht automatisch erkannt. Den muss man manuell definieren:
define Cube CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1234
@Telekatz
Danke, jetzt wurde er sofort gefunden :)
Jetzt werde ich mich erst einmal in FHEM einlesen müssen ;)
EDIT:
Ich musste FHEM noch einmal neu installieren und bei der Installation wurde der CUL_MAX sofort integriert, sprich er musste nicht extra definiert werden :)
Ich werde zukünftig wohl auch Rollladenaktoren von Homematic einsetzen, da ich bei diesen meine Mertenblenden verwenden kann (günstigere Variante als Vorschlag wird gerne angenommen). Nur stellt sich bei mir nach einigem lesen doch konfusion ein.
Die Threads sind von Beginn diesen Jahres und dort wird erwähnt man soll eine spezielle Homematic-Firmware auf den CUL aufspielen, während andere sagen der CCU2 wäre für den Einsatz mit Homematic viel besser.
Ich wollte jetzt eigentlich meinen CUL_MAX dafür einsetzen. Dort kann ich ja per rfpm Homematic auswählen. Heißt das jetzt dieser spezielle Teil ist involviert?
Wenn ich jetzt FHEM einsetzen will auf einem RPi2 oder 3 mit dem CUL_MAX, wäre dann immernoch der CCU2 die bessere Wahl?
Weiterer EDIT:
Habe mittlerweile Homematic Schalt- und Rollladenaktoren verbaut. Und diese laufen perfekt mit dem Max!Cube/CUL :)
@telekatz
Hallo, da ich nun endlich auch einen MAX!Cube hier habe, stellt sich die Frage : Wie schließe ich einen zusätzlichen CC1101 (433MHz) an.
Welche PINs werden mit welchen Signalen beschaltet. Aus der board.h werde ich nicht so ganz schlau und die Bilder vom blog.loetzimmer.de sind auch nicht wirklich hilfreich.
MOSI, MISO und SCK werden mit den Signalen am TRX1 verschaltet, aber wo gehen GDO0, GDO2 und CSN hin?
Leider habe ich bisher keine Antwort finden können.
Für Hilfe wäre ich dankbar.
GDO0 ist der OUT_PIN, GDO2 ist der IN_PIN und CSN ist der CS_PIN.
Wenn du nur einen oder zwei Transceiver nachrüsten möchtest, solltest du die Zuordnung in der board.h so ändern, dass du nur die verfügbaren Pins auf der Oberseite der Platine brauchst.
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606 (https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606)
Für Homematic oder MAX kann der OUT_PIN auch unangeschlossen bleiben.
Guten Abend zusammen,
ich versuche seit ein paar Tagen meinen Cube mit einem zusätzlichen CC1101 433 MHz Modul zum laufen zu bringen. Leider ohne wirklichen Erfolg.
Ich habe die Board.h nicht verändert und habe das in Beitrag #1 verlinkte Bin-File über XModem auf den Cube geladen. Dann habe ich die Pins wie folgt verbunden (siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)
Cube -> CC1101
VCC -> VCC
GND -> GND
PA5 -> GDO2
PA6 -> CSN
PA28 -> GDO0 (ST2 Pin2, laut Schaltplan)
TRX1 -> TRX2
Pin 1: MOSI -> MOSI
Pin 2: SCK -> SCK
Pin 3: MISO -> MISO
Kann jemand bestätigen, dass dies so korrekt ist?
Danke im Voraus.
Zitat von: OtisWright am 06 Januar 2018, 19:30:25
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?
Zitat von: OtisWright am 06 Januar 2018, 19:30:25
PA28 -> GDO0 (ST2 Pin2, laut Schaltplan)
In board.h ist PB28 für CC1100_1_OUT definiert.
Genau, ich habe die CUBE_x4_BL.bin verwendet.
stimmt, ich hatte jetzt nur auf internal und external transceivers geachtet.Pin 5 und 6 sind wohl ebenfalls für cc1100 definiert. was heißt das jetzt für mich? sorry, aber steh gerade auf dem schlauch
Edit:
Mir zeigt FHEM die folgenden Infos an:
VERSION
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
ccconf
freq:5913.464MHz bWidth:232KHz rAmpl:24dB sens:16dB
und wenn ich dann auf get ccconf klicke kommt:
Timeout reading answer for get C0D
Zitat von: OtisWright am 06 Januar 2018, 20:11:02
VERSION
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
Erkannt worden ist der zweite Transceiver.
Mach mal mit raw e einen Reset der Einstellungen.
Das hab ich gerade probiert. allerdings gibts dadurch keine Besserung. ein blick ins logfile und siehe da - das hier passiert seit 30 minuten durchgehend:
2018.01.06 20:22:59 3: CUBe_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2018.01.06 20:22:59 1: 192.168.xxx.xxx:2323 reappeared (CUBe_0)
2018.01.06 20:22:59 3: CUBe_1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2018.01.06 20:23:25 1: 192.168.xxx.xxx:2323 disconnected, waiting to reappear (CUBe_0)
Woran kann das liegen?
Vielen Dank für die schnelle Antwort, mit den Infos sollte es funktionieren!
Ihr seid einfach Klasse!
Grüßle
Zitat von: Telekatz am 06 Januar 2018, 20:01:40
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 :(
Zitat von: OtisWright am 06 Januar 2018, 20:26:11
Das hab ich gerade probiert. allerdings gibts dadurch keine Besserung. ein blick ins logfile und siehe da - das hier passiert seit 30 minuten durchgehend:
2018.01.06 20:22:59 3: CUBe_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2018.01.06 20:22:59 1: 192.168.xxx.xxx:2323 reappeared (CUBe_0)
2018.01.06 20:22:59 3: CUBe_1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2018.01.06 20:23:25 1: 192.168.xxx.xxx:2323 disconnected, waiting to reappear (CUBe_0)
Woran kann das liegen?
Teste mal, ob es über USB funktioniert.
Zitat von: OtisWright am 06 Januar 2018, 20:34:35
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.
also ich glaube das ganze hängt mit meinem CC1101 Modul zusammen. ich hab das jetzt mal abgesteckt (Habe Jumper-Kabel an den Cube gelötet um das schnell tauschen zu können) und sowohl über USB als auch über LAN geht der Cube jetzt wieder.
Das heißt wohl, dass ich ohne neues CC1101 Modul und ändern der Board.h Datei nicht um das Vergnügen mit dem Cube herumkomme.
Danke sehr für die tolle Hilfe am Samstag Abend!
Hallo zusammen,
ich hatte vor gut einem Jahr schon einmal hier mein Problem beschrieben, das ich beim Flashen der Firmware meines Max Cubes hatte und konnte es damals irgendwie lösen:
https://forum.fhem.de/index.php/topic,38404.msg558765.html#msg558765
Nun wollte ich eine neuere Firmware aufspielen, hatte zu Anfang die gleichen Probleme mit dem Mac (bis ich auf meinen Post hier stieß ;) ) und habe es jetzt wieder unter Ubuntu probiert. Das Aufspielen eines neuen Bootloaders klappt auch, aber wenn dann die LED blinkt und ich die Firmware hochladen will, bleibt die LED nach dem (anscheinend erfolgreichen) Update aus. dmesg sagt mir "unable to enumerate USB device", aber wenn ich dann mit RESET gedrückt den Cube einstecke, bekomme ich brav ein "Product: CUBELOADER" und kann das Spiel erneut (wenn auch ohne Erfolg durchführen.
Weitere Fehlermeldungen sind u.a.
"cdc_acm 2-1:1.0: failed to set dtr/rts"
"device descriptor read/64, error -71"
"device not accepting address 11, error -71"
Wie gesagt nur, nach dem Upload der Firmware, nicht, wenn ich im Bootloader Modus bin.
Ich bin mir ziemlich sicher, dass ich damals die CUL_V3_868MHZ.hex verwendet hatte, es war auf jeden Fall die Version 1.23.05. Aber um sicher zu gehen: Wie kann ich herausfinden, ob ich V2, V3 oder V4 einsetzen muss?
Freue mich über jede Hilfe, da ansonsten die Heizung hier sonst nur über die Außentemperatur gesteuert werden kann :(...
Gruß,
F.
Ich habe nun zum Testen den neuen Cube (der für meine Eltern sein soll) auch versucht zu flashen, aber da komme ich trotz Überbrückens von J1 noch nicht einmal zum Löschen des Bootloaders. Der Cube blinkt am Anfang immer kurz und leuchtet dann dauerhaft. Gibt es da Erkenntnisse, ob neuere Cubes da einen Löschschutz haben?
Hallo freetz,
die CUL V 2/3/4 kenne ich nur für die Atmels für den Cube gibt es die a-cul CUBe Firmware.
Mit dem Bootloader Flashen hatte ich bisher keine Probleme, allerdings hatten ich auch grosse Probleme die Firmware per xmodem zu über tragen - lag aber an meinen Rechnern, mit einem ginges dann. Hatte aber auch nicht weiter nachgeforscht warum die anderen Rechner nicht korrekt per xmodem verbinden / übertragen wollten.
Wow. You made my day :)!
Ich Hirsch hatte vor dem Cube einen CUL-Stick im Einsatz (über ein Jahr her), den ich damals mit der CUL-Firmware geflasht hatte und dann bei der Suche nach den Files diese zuerst gefunden - und dachte irgendwie, dass die Files in CUBe nur für den Bootloader wären.
Nun tut's, diesmal sogar mit BOSSA und Tera Term aus der Virtual Machine von Parallels auf meinem Mac heraus :). Der Upload hing am Ende dann zwar bei 100%, aber nach dem An- und Abstecken bootete der Cube wie er sollte.
Das Löschen des Bootloaders ging (im Gegensatz zum anderen Cube) nicht, wenn man die Kontakte nur an der Oberfläche verbunden hat, ich musste richtig mit einer Büroklammer in die Löcher gehen, dann ging's aber sofort.
Vielen Dank noch mal für die schnelle Hilfe im entscheidenden Punkt!
Zitat von: uelpenich am 16 Dezember 2017, 22:59:53
Das bereits X21 einen Absturz verursacht ist ungewöhnlich.Um exakt zu sein, bei X21 erfolgt noch nicht der Absturz, erst bei *X21.
Aus lauter Verzweiflung hatte ich alles abgelötet und wieder angelötet, dabei aber einen Fehler gemacht und GOD0 nicht verbunden: => kein Absturz, aber auch keine Funktion des 433MHz Transceivers.
Ich habe neue Briefmarken bestellt und will sehen, ob damit der Fehler wieder auftritt.
Es hat lange gedauert bis die neuen Transceiver geliefert worden sind. Da der Fehler mit den neuen Transceivern in gleicher Weise auftaucht, habe ich mir die beiden Max!Cubes genauer angesehen:
Mit diesem Cube funktioniert es:
eQ-3 BC-LGW-O-TW
TRX868 / 868.3 MHz
Prozessor AT91SAM7x256
Das fest eingebaute Transceiver Modul hat ein QR-Code Label mit "12686872". Das Modul habe ich nicht geöffnet, um nachzuschauen welches Transceiver Chip verbaut ist.
Dieser Cube (etwas älter) hat die oben beschriebenen eigenartigen Neustarts in dem Augenblick, wenn der zweite Transceiver das erste Mal angesprochen wird (Befehl
*X21):
eQ-3 BC-LGW-O-TW-MD
TRX868-TI / 868.3 MHz
Prozessor AT91SAM7x512
eingebautes Transceiver Chip CC1100
Obwohl lt. TI der CC1100 etwas weniger Funktionen hat als der CC1101 funktioniert der CC1100 mit der Culfw Firmware.
Gibt es zu den beiden Cubes Erfahrungen was geht und was nicht?
Zitat von: uelpenich am 23 Januar 2018, 17:46:06
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?
Zitat von: Telekatz am 23 Januar 2018, 18:14:39
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.
Ich hätte da gerne mal ein Problem :
Ich betreibe nun schon recht lange ohne Probleme zwei CUBEs ( V 1.10.02 a-culfw & V 1.21.00 a-culfw ) via Lan im HM Mode. Stromversorgung ist bei beiden irgend so ein USB Steckernetzteil.
Ich habe angefangen bei meinem Hardware Zoo etwas Ordnung zu machen und kam dabei auf die Idee den einen CUL statt mit dem Netzteil mit Strom zu versorgen einfach an einen freien Raspi USB Port zustecken. ( auf diesem läuft nicht FHEM ! )
Als Folge leuchtet am Cube die BATTERY LED und ca. alle zwei Minuten ist er von FHEM via Netzwerk nicht erreichbar ( disconnect -> connect), konnte ich mir nicht erklären also wieder zurück zum Netzteil. Am WE das gleiche Spiel am anderen CUBE , Netzteil weg und USB Port einer Fritzbox benutzt. Wieder BATTERY LED und die ständigen disconnects.
Was läuft da schief wenn die Firmware merkt das am USB Port eine echte serielle Schnittstelle hängt ?
Wenn es keine Möglichkeit gibt das via Software fixen zu können werde ich mir halt USB Kabel machen müssen die nur zwei Drähte aufgelegt haben statt vier.
Möglicherweise öffnet irgend ein Prozess die USB Verbindung kurz. Das merkt der Cube und will daraufhin alle Nachrichten auch über USB ausgeben. Wenn die USB Verbindung dann wieder geschlossen wird, wird der USB Buffer nicht mehr geleert, der Buffer läuft voll, der Cube bleibt auf die Leerung wartend in einer Endlosschleife hängen und der Watchdog löst aus.
Zitat von: Wzut am 24 Januar 2018, 10:37:02
Ich hätte da gerne mal ein Problem :
Ich betreibe nun schon recht lange ohne Probleme zwei CUBEs ( V 1.10.02 a-culfw & V 1.21.00 a-culfw ) via Lan im HM Mode. Stromversorgung ist bei beiden irgend so ein USB Steckernetzteil.
Ich habe angefangen bei meinem Hardware Zoo etwas Ordnung zu machen und kam dabei auf die Idee den einen CUL statt mit dem Netzteil mit Strom zu versorgen einfach an einen freien Raspi USB Port zustecken. ( auf diesem läuft nicht FHEM ! )
Als Folge leuchtet am Cube die BATTERY LED und ca. alle zwei Minuten ist er von FHEM via Netzwerk nicht erreichbar ( disconnect -> connect), konnte ich mir nicht erklären also wieder zurück zum Netzteil. Am WE das gleiche Spiel am anderen CUBE , Netzteil weg und USB Port einer Fritzbox benutzt. Wieder BATTERY LED und die ständigen disconnects.
Was läuft da schief wenn die Firmware merkt das am USB Port eine echte serielle Schnittstelle hängt ?
Wenn es keine Möglichkeit gibt das via Software fixen zu können werde ich mir halt USB Kabel machen müssen die nur zwei Drähte aufgelegt haben statt vier.
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.
Zitat von: Telekatz am 24 Januar 2018, 11:44: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.
Moin,
habe nach langem hin und her nun endlich meinen cube(x4) um ein 434MHz-Modul ergänzen können. Sieht auch ganz gut aus, außer, dass er es als 868MHz-Modul erkennt:
...
-I- ** Valid PHY Found: 1
-I- DM9161_ResetPhy
-I- Detected CC0: PN 0x00 VER 0x03
-I- Detected CC1: PN 0x00 VER 0x14
-I- Not detected CC2: PN 0xff VER 0xff
-I- Not detected CC3: PN 0xff VER 0xff
-I- Not detected onewire
-I- init USB
-I- CDCDSerialDriver_Initialize
USBD_Init
-I- init Complete
V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
*V 1.26.01 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
Muss ich die Frequenz in der Firmware anpassen, über einen Befehl oder soll ich in FHEM das einfach als Attribut übergeben?
Danke und Gruß
Tobias
Mach mal mit "raw e" einen Reset der Einstellungen.
Bingo! DANKE!! :)
Hi,
da ich ziemlich viel Stress hatte das zusätzliche Interface an den Cube zu bekommen hier mal die Schaltung für einen E07-M1101D-TH:
Pin - CC - Cube
1 - GND - GND
2 - VCC - VCC
3 - GDO0 - PB25
4 - CSN - PA6
5 - SCK - SCK
6 - MOSI - MOSI
7 - MISO - MISO
8 - GDO2 - PA5
Voraussetzung ist dieser Patch: https://loetzimmer.de//patches/cube.patch um die PINs richtig zuzuordnen!
Gruß
Tobias
Moin,
Eine Frage: kann es sein, dass das zusätzliche Modul (CubeX4) keine Signale empfangen kann? Ich habe den Cube als cul_max konfiguriert und benutze das zweite Modul als Intertechno-Sender. Mit dem alten Cul habe ich auch Schalter von Intertechno empfangen, jetzt kommt nichts mehr an.
Generell ein Problem des cubex4 oder kann ich da was dran machen?
Danke und Gruß
Tobias
Beim CUBEx4 funktioniert SlowRF ohne Einschränkungen auch beim zweiten Transceiver.
Moin,
habe es jetzt noch mal näher eruiert. Denke das Problem ist die Konfiguration als MAX-Device. meine config sieht so aus:
define cun01 CUL x.x.x.x:2323 xxxx
attr cun01 rfmode MAX
attr cun01 room Z_-_System
define cun01_max CUL_MAX xxxxxx
attr cun01_max IODev cun01
attr cun01_max room Z_-_System
define cun02 STACKABLE_CC cun01
attr cun02 room Z_-_System
Wenn ich den MAX-Teil rausnehme kann ich die IT-Sachen empfangen. Wahrscheinlich wird durch diese Konfiguration das erste Interface auf "lauschend" gestellt und das zweite kommt dann nicht mehr zum Zug? Oder mach die Konfiguration als "Stackable" vielleicht noch einen unterschied?
Danke und Gruß
Tobias
An der a-culfw sollte es nicht liegen, die kann gleichzeitig MAX und IT empfangen:
Z170000000FEF74123456001004024C4551303739343539324D
*i001151F9
*i00155FFB
Z0B0106300FEF7412345600103D
Z170000000FEF74123456001004024C45513037393435393237
Z0B0106300FEF7412345600123D
Z0B0106300FEF74123456001229
*s52800660F9; 464: 9520
*i00145101
*i00155F03
Z0B0106300FEF7412345600124E
Z0B0206300FEF74123456001038
Z0B0206300FEF7412345600102F
Z0B0206300FEF74123456001016
*s52800660FE; 480: 9520
Z0B0206300FEF74123456001018
Z0B0206300FEF7412345600502C
*s52800660FD; 464: 9552
Versuch mal den zweiten Transceiver räumlich etwas anders anzuordnen. Ich hatte mal das Problem, das mehrere nur auf Empfang geschaltete Transceiver sich trotzdem gestört hatten.
Hi,
Habs auch rausbekommen, musste noch den SlowRF als rfmode setzen:
define cun02 STACKABLE_CC cun01
attr cun02 rfmode SlowRF
attr cun02 room Z_-_System
Danke und Gruß
Tobias
Hallo
Erst einmal Danke für diese tolle Firmware. :-)
Wir ihr euch schon denken könnt, habe ich eine Frage, bei der ich eure Unterstützung benötige.
Folgendes (aus meiner Sicht seltsames) Verhalten tritt bei mir auf.
Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.
Nach meiner Recherche handelt es sich um ein echtes 86MHz Modul. (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649))
Mein Problem ist, dass der neue CC mit 433 MHz erkannt wird.
Ich ändere die Konfiguration dann auf 868MHz und alles funktioniert einwandfrei mit guten Empfang.
Nach einer gewissen Zeit "vergisst" das Modul dann leider die Konfiguration und es funktioniert erst dann wieder, wenn sie wieder angepasst habe.
Hier meine Konfiguration aus der fhem.cfg:
define CUL0 CUL 192.168.0.94:2323 0000
attr CUL0 icon cul_868
attr CUL0 rfmode MAX
attr CUL0 room System,RF
attr CUL0 verbose 0
define CUL1 STACKABLE_CC CUL0
attr CUL1 connectCommand Nr1
attr CUL1 icon cul_868
attr CUL1 rfmode SlowRF
attr CUL1 room System,RF
attr CUL1 verbose 0
define CULMAX0 CUL_MAX 123456
attr CULMAX0 IODev CUL0
attr CULMAX0 room System,RF
Auszug aus dem Log des CUBEs, wenn er erpfängt:
*N0195C3723701AAAA0000943243
H431780280055FF
*N0191D8167D03DE716B676BD0D9
H434701160400FF
Hier die Ausgaben der Module:
CUL0 (orginal Cube Modul):
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz*
CUL0_MSGCNT 1728
CUL0_TIME 2018-03-19 08:55:01
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.0.94:2323 0000
DeviceName 192.168.0.94:2323
FD 10
FHTID 0000
NAME CUL0
NR 52
PARTIAL
RAWMSG H432C00790142FF
RSSI -74.5
STACKED CUL1
STATE Initialized
TYPE CUL
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21 Zr Za123456 Zw111111
Readings:
ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB 2018-03-19 08:58:44
cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z * 2018-03-19 08:58:47
credit10ms 3106 2018-03-19 08:59:02
fhtbuf AE 2018-03-19 08:59:00
raw No answer 2018-03-17 00:39:27
state Initialized 2018-03-19 08:58:41
uptime 0 00:21:36 2018-03-19 08:58:52
version V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz) 2018-03-19 08:58:55
CUL1 (ergännztes Modul):
Internals:
CMDS bCFiAZNEGMKLUYRTVWXfz
CUL1_MSGCNT 1123
CUL1_TIME 2018-03-19 09:03:00
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF CUL0
IODev CUL0
NAME CUL1
NOTIFYDEV CUL0
NR 54
NTFY_ORDER 50-CUL1
PARTIAL
RAWMSG N0191D8427D676408B23AFFA89A
RSSI -74.5
STATE Initialized
StackLevel 1
TYPE STACKABLE_CC
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21
Readings:
ccconf freq:868.300MHz bWidth:203KHz rAmpl:33dB sens:8dB 2018-03-19 09:05:24
cmds b C F i A Z N E G M K L U Y R T V W X f z 2018-03-19 09:05:29
credit10ms 3496 2018-03-19 09:05:32
fhtbuf AE 2018-03-19 09:05:35
raw ? ( is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z 2018-03-17 21:18:53
state Initialized 2018-03-19 09:05:42
uptime No answer 2018-03-19 09:05:45
version V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz) 2018-03-19 09:05:45
Die Firmware habe ich selbst kompiliert, da ich das die Konfiguration der Pins angepasst habe und die LaCross Unterstützung aktiviert habe.
Meine Änderungen könnt ihr hier sehen:
https://github.com/DJNoXD/a-culfw/commits/master (https://github.com/DJNoXD/a-culfw/commits/master)
Wie kann ich herausbekommen, woher der Fehler kommt?
Ist mein Module evtl. defekt?
Vielen Dank für eure Hilfe.
Randolf
Hi,
Probiere mal ein Werksreset
set CUL0 raw e
Ist dann der CUL1 wieder auf 433?
Ich schätze irgendwie wird der resetet.
Du könntest entweder in Deiner Firmware beim init die Freq/Mode setzen oder Du machst ein regelmäßiges get CUL1 config und setzt dann mit DoIf/ Notify die Werte...
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Zitat von: DJNoXD am 19 März 2018, 09:16:08
Ich habe meinen Cube um einen CC1101 erweitert (868MHz), welcher auch funktioniert.
Nach meiner Recherche handelt es sich um ein echtes 86MHz Modul. (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 (https://www.ebay.de/itm/CC1101-868-MHz-Modul-FHEM-CUL-Transciever-Wireless-Funk-Arduino-Raspberry-Pi/183119455997?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649))
Mein Problem ist, dass der neue CC mit 433 MHz erkannt wird.
Der Cube kann gar nicht erkennen, ob ein 433MHz oder ein 868MHz Modul angeschlossen ist. Für den zweiten Port ist 433 der Standardwert, der nach einem Reset des Dataflash geladen wird.
Nimm einfach den CUL0 für SlowRF und CUL1 für MAX. Der MAX Mode stellt automatisch die richtige Frequenz ein, unabhängig von Standardwert.
Danke für eure Hilfe.
Ich habe die Reihenfolge geändert.
CUL0 = SlowRF
CUL1 = MAX
Ich melde mich wieder, sobald ich etwas sagen kann.
Aktuell sieht es gut aus.
Beide CULs können senden und empfangen.
Danke :-)
Evtl. habt ihr noch einen weiteren Tipp für mich.
Aktuell habe ich einen CUBe mit der eq3 Firmware laufen und einen CUBe als CUL.
Ein Thermostat habe ich mit dem CUL gepaired und kann es steuern.
Seltsam ist (für mich) das folgende Verhalten:
Ich setzte den gewünschten Temperatur Wert auf z.B. 21°C.
Der Wert wird erfolgreich an das Thermostat übertragen (durch ablesen am Thermostat überprüft).
Nach einer bestimmten Zeit wird der Wert, ohne das ich etwas gemacht habe, auf ON gesetzt.
Was könnte der Grund hierfür sein?
Liegt das evtl. am Dual-Betrieb?
Hallo!
Ich habe meinen Cube entsprechend der Anleitung geflashed (aktuell auf dem Stand 1.26.02 Build 276) und habe für ein paar Tage erfolgreich damit arbeiten können. Nun ist der Cube nach einiger Zeit nicht mehr erreichbar und verliert seine Konfigurationsparameter für IP, Netzmask, Gateway usw. Hat jemand selbiges beobachtet oder eine Idee, was da vor sich geht?
Hallo daredevil.2k
Bisher habe ich die kompilierte Firmware von mediafire.com (by Bjoern Hempel) benutzt.
Mein Cube mit V1.21.00a war alle paar Monate mal nicht erreichbar. Es war immer etwas schwierg ihn wieder an LAN zu bekommen. Einfach die Spannungsversorung aus/an hat oft nicht gereicht. Mehrfaches wiederholen oder auch mal LAN ziehen brachte irgendwann den Erfolg.
Hatte dann letzte Woche die Idee auf V1.26.02abuild_276 zu gehen und hoffte auf Besserung. Das war irgendwie instabil. Inbesondere nach SET/GET Kommandos konnte ich keine IT Geräte mehr schalten. Das lief erst nach set <Cube-device> reopen wieder.
Bin daher ohne weitere Untersuchung auf die V1.24.02a_build_209. Das lief zufriedenstellend.
Habe nun meinen Cube mit einem weiteren Sender ausgestattet. Musste daher wieder auf V1.26.02abuild_276 CUBEx4_BL.bin
Die Einrichtung soweit abgeschlossen. Morgen gehe ich produktiv und werde mal zum LAN Thema berichten.
Siehe auch nächter Beitrag
Hallo in die Runde
Setze den Cube ein um abgsetzt per LAN noch Intertechno Steckdosen erreichen zu können. Nun brauchte ich die Erweiterung um noch ein HM Device abgesetzt zu erreichen.
Ich habe meinen Cube daher um einen 433MHZ CC1100 erweitert. Danke also schon mal an Euch für die tolle Arbeit, dass das möglich ist.
Als letzte Sichterheit zum "Löten" war der Hinweis #915 von toxic-tonic für die Zuordnung der In-/Out-Pins CC110 - Cube super wichtig.
https://forum.fhem.de/index.php/topic,38404.msg757526.html#msg757526 (https://forum.fhem.de/index.php/topic,38404.msg757526.html#msg757526)
CC1100 - Cube (mit board.h Patch)
GND - GND
VCC - VCC
GDO0 - PB25
CSN - PA6
SCK - SCK
MOSI - MOSI
MISO - MISO
GDO2 - PA5
Ich habe um die kompilierte FW verwenden zu können mit den Originalzuordnungen gearbeitet, also PB28 auf GD00.
Daher ein Vorschlag zum leichten Nachbau hinsichtlich der Zuordnung:
- wie in der Original FW in der board.h für die Out-/ In-Pins einen Kommentar auf GD00 (=PB28) und GD02 (=PA5) einfügen
- die anderen PINs sind ja durch ihre Bezeichnung bzw. das Foto klar (Antwort #823)
Abschließen noch eine Frage. Hat es eine "Beudeutung", dass die kompilierte FW vom mediafire.com Build 276
- a-culfw_1.26.02_build_276.zip heisst
aber die Versionsabfrage liefert Build 275:
- 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) CUBEx4_83 (F-Band: 868MHz) oder
- 1.26.02 a-culfw Build: 275 (2018-02-07_20-27-53) CUBEx4_83 (F-Band: 433MHz)
Gruß Ralf
Hi,
ich habe meinen MAX!Cube mit einem 1-Wire Transceiver DS2482S-100 erweitert. Den kann man per I2C direkt am CUBe anschließen (TWI/TWCK).
Um den 1-wire Bus via OWX anzusprechen musste ich noch einen kleinen Patch in 00_OWX.pm einfügen.
in Zeile 193 der aktuellen Version 16437 von pah https://forum.fhem.de/index.php/topic,85924.msg783211.html#msg783211 (https://forum.fhem.de/index.php/topic,85924.msg783211.html#msg783211) ist noch zusätzlich CUBE als weiteres zulässiges Device eingetragen:
}elsif( $defs{$dev} && $defs{$dev}->{VERSION} && $defs{$dev}->{VERSION} =~ m/CSM|CUNO|CUBE|MapleCUN...(4|5|6|7|C|D|E|F)/ ){
Man könnte auch CUBEx4 eintragen, da dies ohnehin nur bei einem erweiterten CUBe relevant ist (hier mein aktueller Version-String dazu):
VERSION V 1.26.02 a-culfw Build: private build (unknown) CUBEx4_C3 (F-Band: 868MHz)
Evtl. könnte dies jemand kurz prüfen.
Unklar ist mir noch was dazu in den Folgemodulen wie 11_OWX_CCC etc. zu ändern ist ...
Gruß Phantom
Hi, zur Info
das o.g. Problem mit dem 1-Wire DS2482 am MAX!CUBe konnte in diesen Thread gelöst werden:
https://forum.fhem.de/index.php/topic,78693.msg794897.html#msg794897 (https://forum.fhem.de/index.php/topic,78693.msg794897.html#msg794897) ff.
Gruß Phantom
Hallo daredevil.2k
Zitat von: RalfRog am 16 April 2018, 00:29:55
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.
Hallo zusammen,
mein erstes Post in diesem Forum. Das Wichtigste zuerst: Einen großen Dank für diese phantastische Stück Software!
Mittlerweile habe ich drei Cubes (auf jeder Etage einer) und steuere meine alten FS20-Module. Einen Cube habe ich um einen zweiten Transmitter für MAX erweitert, klappt auch.
Nun möchte ich einen Cube an einen Raspberry zur Stromversorgung anschließen anstatt über das separate Netzteil (Dieser Raspi ist nicht der FHEM-Raspi).
Es leuchet die Battery-LED. Heißt das, dass die USB-Verbindung wird erkannt oder heißt das, dass da nicht genug Strom kommt "schwache Batterie"?
Senden/Empfangen klappt soweit - und dann Bumm: Alle LED gehen kurz aus, FHEM loggt "disconnected, waiting to reappear" und dann kommt der Cube wieder. Mit dem Netztteil passiert das nicht, da klappt alles.
Kann ich die USB-Schnittstelle irgendwie lahmlegen und nur als Stromversorgung verwenden? (Ich hatte schon die Idee, dass da etwas in der Ausgabe steht, aber von dem Raspi nicht abgeholt wird)
Beste Grüße
Michael
Hi Nussknacker,
1) der erste Post ist am schwersten ;-)
2) dabei machen die meisten Fehler
3) Du auch: Offtopic!
Daher mach doch bitte einen neuen Thread unter Anfängerfragen auf!
Warum?
1) Dein Thema ist ein Cube/Raspi frage, die bei näherem Hinsehen eine einfache Stromversorgungsfrage ist. Dafür haben wir keinen extra Forenbereich ;-)
2) Es gibt USB Kabel, die keine Daten, sondern nur Ladekabel sind. (Z.B. typischerweise dicke Kabel bei Powerbanks) oder Du schneidest von den vier Pins die mittleren beiden raus bzw. trennst deren Drähte an einem Stecker. (Vgl. z.B. https://www.androidpit.de/forum/552408/samsung-galaxy-note-10-1-geloest-pinbelegung-ladekabel)
3) Falls Dein Cube dennoch beim senden zu viel Strom braucht, bleiben aus meiner Sicht folgende Lösungen:
a) Raspberry /boot/config.txt Parameter max_usb_current=1 für USB Stromversorgung setzen,
b) einen dicken Pufferelko in der Nähe des Cube zwischen die beiden verbleibenden USB Einzaladern hängen
c) Alternative Stromzufuhr mit Relais am RaspiGPIOs steuern,
d) ... (darum neuen Thread bitte!)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Ich hatte auch immer Stabilitätsprobleme wenn ich den CUBE per USB an einem Raspi oder an einer Fritzbox zu betreiben versucht habe.
Evtl. reichen die max. 500mA am USB Port nicht aus. Gibt es qualifizierte Erkenntnisse bzgl. der Leistungsaufnahme?
Zitat von: nussknacker4711 am 24 April 2018, 16:44:52
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.
Hallöle!
Mein Ziel, TX29-IT Sensoren mit einem MAX!Cube mitzulesen, scheint noch nicht auf Sichtweite. Aktueller Stand nach Einlesen an diversen Stellen:
ZitatAls 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.
Okay, ich habe mit Hilfe eines alten Pinguin-Haudegen herausgefunden, dass das, was nach meiner Lesart in die Makefile gemusst hätte, wohl in die Make.conf ging... seuuuufz.
Damit anderen MAX!Cube-Nutzern mein Leid erspart wird, hier eine CUBE_BL.bin mit LaCrosse, erfolgreich getestet mit fünf TX29-IT
V 1.26.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
Zitat 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
Hallo,
verstehe ich es richtig, für MAX! und LaCrosse benötigt man zwei Cubes?
Danke.
Nö,
Man benötigt mindestens zwei CC1101.
Das geht mit zwei cubes im Original (Hardware) Zustand oder mit einem Cube mit zweitem eingelötetem CC1101 https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html?m=1 (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html?m=1)oder mit zwei NanoCULs oder ...
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Danke für die Info.
Der Lötkolben glüht schon...
Zitat 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
das ist nett von dir behandelt aber leider das Symptom statt der Ursache ....
@Telekatz : bitte in die Make.conf noch mit aufnehmen (bzw. aufnehmen lassen) :
SRCS += ../../clib/lacrosse.c
Also erst mal ein großes Danke an alle, die daran mitgearbeitet haben, insbesondere an Telekatz.
Ich habe einen MOBILCOM-DEBITEL MAX! Cube erfolgreich mit V 1.26.03 a-culfw Build: 300 geflasht, über Netzwerk (define CUL_1 CUL 192.168.0.94:2323 0000) eingebunden und auf WMBUS-T eingestellt, um einen Stromzähler (EnergyCam) auszulesen. Das funktioniert auch im Prinzip prima. Allerdings setzt sich der MAX! nach einiger Zeit auf ein erneutes "state: initialized" in den Readings. Im log sieht man nicht, dass er neu initialized wurde, sondern nur im Reading des Devices. Danach empfängt er keine Signale mehr. Nach einem restart von fhem funktioniert es dann wieder.
Auch wenn man die Stromzufuhr des MAX! aus- und einschaltet, schaltet er nicht auf WMBUS-T um. Dann steht im log folgendes:
2018.10.02 18:36:43 3: CUL_1: Possible commands: BbCFiAZNEkGMKLUYRTVWXOefhltxz
2018.10.02 18:36:43 2: Setting CUL_1 fhtid from TMODE to 0000
2018.10.02 18:36:43 1: 192.168.0.94:2323 reappeared (CUL_1)
2018.10.02 18:37:14 3: CUL_1: Unknown code 0000, help me!
Wenn man im Falle, dass er nichts empfängt "get ccconf" ausführt, kommt als Antwort "empty" während im Reading noch die richtigen Werte "freq:868.950MHz bWidth:325KHz rAmpl:33dB sens:8dB" stehen. Wenn er empfängt gibt "get ccconf" auch die richtigen Paramter aus.
Ich habe den Eindruck, dass der MAX! nach einem "initialized" und Unterbrechung der Spannungsversorgung vergisst, das WMBUS-T-Protokoll wieder einzustellen.
Hat da jemand eine Lösung?
Vielen Dank Vorab
Achim
Hi Zusammen,
erstmal Danke für die Arbeit die Ihr hier reingesteckt habt.
Meinen Cube habe ich anhand der Anleitung geflasht (a-culfw_1.26.04_build_307), da er immer wieder alles vergessen hat.
Insofern habe ich große Hoffnung, dass vieles Dank Eurer Arbeit besser läuft.
Nun zum aktuellen Problem:
leider bekomme ich keine Geräte (Max Thermostat + Fensterkontakt) angebunden.
Was ich getan habe:
- Flashen auf a-culfw_1.26.04_build_307
- MaxCube ist auch Netzwerk sichtbar
- fhem update
- in Fhem über die GUI:
define maxcul CUL <IP>:2323 0000
attr maxcul rfmode MAX
define cm CUL_MAX 123456
set cm pairmode 45
Dann am Max-Fensterkontakt (vorher Reset, Batterien raus) den Knopf gedrückt.
Nix passiert.
Das LogFile schweigt sich aus.
Habt Ihr Ideen, woran das liegen könnte?
Was kann ich ggf. noch testen oder probieren?
Danke sehr.
Bernd
===
internals
CMDS: BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
STATE: Initialized
TYPE: CUL
VERSION:
V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
initString:
X21
Zr
Za123456
Zw111111
Readings
cmds: B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
state: Initialized
====
Infos vom cm (nach Drücken der Taste am Fensterkontakt)
maxcul_MSGCNT: 1
maxcul_RAWMSG: Z1700000008B07A0000000014040F4B455130363539343536
maxcul_RSSI: -58
und beim max_cul:
RAWMSG: Z1700000008B07A0000000014040F4B45513036353934353620
RSSI: -58
Nochmaliges Drücken am Fensterkontakt zeigt kein Änderung mehr.
Hi,
Das sieht doch schon ganz gut aus,
Mach mal ein
attr max_cul verbose 5
Und schau im Eventmonitor/Log was da tatsächlich passiert beim drücken.
Evtl ist der Fensterkontakt zu nah? 5m Abstand?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Moin
Und gib uns mal ein list cm, und bitte in codetags (ueber den smilies der "#")!
Und von Arnd muesste es heissen attr cm verbose 5!
Gruss Christoph
Ich würde dem patiniert auf 120 oder 240 stellen. Je nachdem was im 868 band los ist dauert es eine weile.
Falls die Geräte schon einmal angelernt waren erst ein reset machen .
set cm pairmode 120 oder 240
Schau mal in die Doku ob 0000 als id geht. Ich trage dort z.B. 3453 ein.
CUL_1 CUL 192.168.0.94:2323 3453
.
Pejonp
Zitat von: pejonp am 05 Oktober 2018, 16:22:23
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 ?
Danke sehr an Alle.
verbose gesetzt, autocreate ist an, 0000 durch 1234 ersetzt. :-)
Dann folgende Erkenntnisse - welche mich etwas verwirren :-(
nach dem Restart von fhem UND des MaxCubes konnte ich einmalig kurz pairen.
Dann habe ich versucht den Thermostat zu pairen.
Ging erst nicht.
Dann - nach einigen Minuten fhem restarted und direkt kam die PairMsg an.
Ca. alle 30 Sekunden kommt im Log:
2018.10.05 16:32:16 4: CUL_Parse: maxcul V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
2018.10.05 16:32:46 5: CUL/RAW: /V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
Vermute mal um die Connection offen zu halten.
Das hört dann nach etlichen Minuten (ca. 1h, mal nur 5min) auf. Keine der o.g. Logmeldungen mehr.
Nun versuchte ich noch ein Pairing:
Fensterkontakt reset, set cm pairmode 240, Batterien rein - nix etliche Minuten lang - außer o.g. Meldung.
Dann FHEM mal restarted. Wieder nix. Und nur einmalig die o.g. Meldung.
Dann mal set maxcul reopen - und siehe da - die PairMsg von vor etlichen Minuten war da - und Gerät angelegt.
Hier und da kommt im Log auch mal nach dem Pairing:
Device MAX_0da8ea answered with: Invalid command/argument
Dann wollte ich den Fensterkontakt und das Thermostat verlinken:
2018.10.05 16:47:08 5: CUL_MAX_SendQueueHandler: 1 items in queue
2018.10.05 16:47:08 2: There is a packet for ShutterContact MAX_054cae in queue. Please trigger a window action (open or close the window) to wake up the respective ShutterContact and let it receive the packet.
...
(da kommt nun schon sehr lange - obwohl mehrfach Fenster auf/zu)
Hab das Gefühl der Cube ist immer mal weg - zumindest nicht übers Netz erreichbar bzw. nicht reagiert.
Sollte ich ggf. mal einen älteren Build der a-culfw flashen? Empfehlung willkommen.
Blöde Frage: kann ich den auch via USB an Raspi anschließen? (Sorry - mit CUL & Co hatte ich noch nix zu tun) :-)
Danke schön.
Bernd
Zitat von: berndEEE am 05 Oktober 2018, 16:50:06
(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.
Naja. Den Anlernknopf kenn ich schon :-)
Habe es ja ständig angelernt.
Das mit Fenster auf/zu bezog sicht auf die Logmeldung:
There is a packet for ShutterContact MAX_054cae in queue. Please trigger a window action (open or close the window) to wake up the respective ShutterContact and let it receive the packet.
Und die kommt noch immer.
Hi Zusammen,
ich glaube ich hab das Problem eingegrenzt: Netzwerk - entweder mein "Infrastruktur" oder ein Problem am Cube mit dem Netzwerk.
Habe den Cube via USB angeklemmt.
Und siehe da -> Pairing, Verknüpfung von Fensterkontakt zum Thermostat - alles direkt beim ersten Versuch ok.
Werde es mal weiterbeoachten.
Auf jeden Fall nochmal Danke an Alle!!
Bernd
Hallo zusammen,
ich komme noch einmal auf mein in Antwort 942 beschriebenes WMBUS-Problem zurück. Ich habe inzwischen versucht den Cube über USB anzubinden. Das Ergebnis ist dasselbe. Nach einiger Zeit empfängt er keine Daten mehr. Ich nutze nun wieder ein Busware CUL über USB für den WMBUS. Das funktioniert einwandfrei. Ich hatte dieses USB CUL auch schon über einen Raspberry per ser2net über LAN eingebunden. Das funktionierte auch. Aber das leidige Thema SD-Karten-Defekt macht diese Lösung wenig betriebssicher, so dass ich das wieder eingestellt habe. Ich dachte der Cube wäre da die Lösung.
Ich nutze den Cube über LAN nun für FS20 und CUL_EM. Das funktioniert auch nach einigen Tagen immer noch perfekt.
Es wäre natürlich prima, wenn auch WMBUS richtig funktionieren würde.
Viele Grüße
Achim
Guten Morgen,
kann man einen geflashten MAX!Cube auch ohne FHEM dazu bringen sich mit anderen MAX!-Komponenten zu pairen?
Wenn ja, wie?
Danke und Grüße
Andreas
Hi,
ich habe jetzt einen älteren Cube lt. Anleitung geflasht. Hat soweit funktioniert, allerdings musste ich ,,at91sam7x512-ek" auswählen, damit es funktionierte.
Aber Bootloader und CUBE_BL.bin konnten ansonsten wie in der Anleitung beschrieben aufgespielt werden.
Der Cube startet und D1 blinkt im Sekundentakt, bei Netzwerkverbindung leuchtet auch D2 dauerhaft.
Ich habe nun mit putty eine Telnetverbindung zu der IP-Adresse des Cubes (von mir im router festgelegt) geöffnet (Port2323).
Soweit so gut.
Es erscheint wiederkehrend folgende Anzeige: V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
Aber wenn ich in putty z.B. V eingebe und dann die Entertaste drücke dann kommt: ? ( is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
Egal welche der Befehle ich übermittle es kommt immer diese Meldung.
Gleiches Spiel in TeraTerm, dort habe ich es auch schon versucht.
Über einen COM-Port habe ich keine Verbindung zustande bekommen (aber ich habe auch noch keinen virtuellen COM-Treiber).
Irgendwie bekomme ich derzeit noch keine Befehle an den Cube übermittelt. Ich gehe davon aus dass die command.ref der culf.w auch hier Gültigkeit hat?
Tipps?
Danke und Grüße
Andreas
Hi,
Eigentlich machst Du alles richtig und auf V sollte die Version angezeigt werden und bei ? Halt der Commands Text.
Wenn aber die Firmware nicht ganz geflasht wurde, kann es auch zu solchen Fehlern kommen. Nachdem Motto: Ich weiss meine Standardantwort, aber den Befehl V habe ich noch nicht gelernt.
Evtl. Hast Du aber auch die Return Taste falsch belegt (Windows: CR und LF, statt Linux: nur LF, oder Mac
Classic: nur CR)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hi,
ich habe gerade noch den Telnet-Client von Windoof installiert. Nun klappts. Befehle werden erkannt und geben entsprechende Rückmeldungen :)
Mit dem richtigen Programm klappts ::)
Danke soweit.
Noch eine Frage: Wie schalte ich den geflashten Cube in den MAX-Modus? Oder ist er automatisch in eben diesem?
Danke und Grüße
Andreas
attr CubeCUL rfmode MAX
https://wiki.fhem.de/wiki/Rfmode
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Hi,
danke. Mißverständnis, ich meinte den Cube ohne fhem also direkt aus einem Terminalprogramm in den piaringmodus versetzten. Gibt´s da einen Befehl oder Tastenfolge für?
Danke und Grüße
Andreas
Zitat von: Andreas29 am 21 Oktober 2018, 17:35:31
Hi,
danke. Mißverständnis, ich meinte den Cube ohne fhem also direkt aus einem Terminalprogramm in den piaringmodus versetzten. Gibt´s da einen Befehl oder Tastenfolge für?
Danke und Grüße
Andreas
Moin
Da wirst Du Dich wohl ein wenig in den CUL einlesen muessen. Grundsaetzlich habe ich es so verstanden, dass die RAW-Befehle das Equivalent zu Deinen Eingaben im Terminal sind. Wie Du allerdings ein "Set" implementierst hat sich mir auf die Schnelle nicht erschlossen! Vielleicht solltest Du hier im CUL Bereich noch etwas stoebern, und einen neuen Thread aufmachen!
Gruss Christoph
Hi,
Ist es nicht einfacher ein temporäres FHEM zu nutzen (vielleicht mittels ser2net auf einem entfernten Rechner)!?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Der Initialisierungs-Code für den MAX-mode sollte außer in der cr der culfw auch im CULMAX-Modul stehen (wenn es ums Mithören geht).
Hi,
meine Frage hat sich erledigt, das Problem lag an der Auswertung der Funktelegramme.
Danke und Grüße
Andreas
Hallo Zusammen,
Erst einmal Danke an Telekatz und allen andere für Ihre Arbeit / Beiträge hier.
Habe heute Morgen meinen Max Würfel (TRX868) nach der Anleitung von Seite 1 neu geflasht.
Der Grund war das wiederholte vergessen der Einstellungen.
Nach dem flashen will ich weiterhin meine MAX Geräte damit betreiben.
Dies hat auch direkt funktioniert. Habe Ihn dann in FHEM, das auf einem Raspi Pi3 läuft, als neue Device gesehen.
Wie ich dann ebenfalls hier nachgelesen haben auch die Möglichkeit gefunden wie ich meine Geräte anlerne.
Hier meine Einstellungen aus der FHEM.cfg:
define MAXLAN CUL /dev/ttyACM0@9600 3453
attr MAXLAN alias MAX Würfel
attr MAXLAN group MaxLan
attr MAXLAN icon cul
attr MAXLAN model CUL
attr MAXLAN rfmode MAX
attr MAXLAN room Root
attr MAXLAN verbose 5
So und jetzt zu meinem Problem:
Ich kann alle meine Geräte (Wandthermostat, Heizungsthermostat und Fensterkontakte) anlernen und miteinander verknüpfen.
Alles funktioniert auch, aber nur bis zur Restart von FHEM.
Restart aus der Fhem heraus, von Terminal des Raspi heraus hat immer das gleiche Ergebnis.
Alles weg, der Würfel vergisst erneut alles.
Habe Ihn schon per USB, LAN, USB und LAN verbunden, alles mit gleichem Effekt.
Habe hier noch alle Seiten durchgelesen und scheine mit meinem Problem der einzige zu sein >:(.
Bin jetzt auch mit meinem Latein am Ende und hoffe auf neue Ideen.
Danke und noch einen schönen Abend :)
Hi,
Du hast wahrscheinlich eine falsche Reihenfolge der Geräte in Deiner Config.
Erst alle Geräte und dann erst den Max als CUL wäre mein Tipp.
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: EinfachFhem am 28 Oktober 2018, 20:38:25
Hallo Zusammen,
Erst einmal Danke an Telekatz und allen andere für Ihre Arbeit / Beiträge hier.
Habe heute Morgen meinen Max Würfel (TRX868) nach der Anleitung von Seite 1 neu geflasht.
Der Grund war das wiederholte vergessen der Einstellungen.
Nach dem flashen will ich weiterhin meine MAX Geräte damit betreiben.
Dies hat auch direkt funktioniert. Habe Ihn dann in FHEM, das auf einem Raspi Pi3 läuft, als neue Device gesehen.
Wie ich dann ebenfalls hier nachgelesen haben auch die Möglichkeit gefunden wie ich meine Geräte anlerne.
Hier meine Einstellungen aus der FHEM.cfg:
define MAXLAN CUL /dev/ttyACM0@9600 3453
attr MAXLAN alias MAX Würfel
attr MAXLAN group MaxLan
attr MAXLAN icon cul
attr MAXLAN model CUL
attr MAXLAN rfmode MAX
attr MAXLAN room Root
attr MAXLAN verbose 5
So und jetzt zu meinem Problem:
Ich kann alle meine Geräte (Wandthermostat, Heizungsthermostat und Fensterkontakte) anlernen und miteinander verknüpfen.
Alles funktioniert auch, aber nur bis zur Restart von FHEM.
Restart aus der Fhem heraus, von Terminal des Raspi heraus hat immer das gleiche Ergebnis.
Alles weg, der Würfel vergisst erneut alles.
Habe Ihn schon per USB, LAN, USB und LAN verbunden, alles mit gleichem Effekt.
Habe hier noch alle Seiten durchgelesen und scheine mit meinem Problem der einzige zu sein >:(.
Bin jetzt auch mit meinem Latein am Ende und hoffe auf neue Ideen.
Danke und noch einen schönen Abend :)
Moin
Anstelle Ausschnitte Deiner cfg zu posten, die nebenbei auch in Codetags gehoeren, solltest du lieber mal ein "list MAXLAN" eingeben, und das Ergebnis in Codetags posten!
Dann habe ich noch weitere Fragen:
-Ein save hast du gemacht?
-Wie waren Deine anderen Definitionen?
Der "Wuerfel" kann nichts mehr vergessen, da jetzt fhem das Gedaechtnis ist!
Gruss Christoph
Zitat von: pc1246 am 29 Oktober 2018, 08:25:30
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.
Oder dblog ;-) Gruß Arnd
Gesendet von iPhone mit Tapatalk
Danke allen erst mal für ihre Hilfe.
Werden nach der Arbeit die Vorschläge umsetzten und berichten.
Fhem.cfg alt: Definition Max vor den Geräte definitionen (Diese sind in einer separaten CFG aufgeführt).
Fhem.cfg aktuell: Definition Max nach den Geräte definitionen.
Vor dem Reboot immer ein save.
Nach dem Reboot oder speichern der fhem.cfg auf der Fhem Web - Oberfläche sind alle IO Daten weg.
Im Anhang bzw.als die LIST MAXLAN vor und nach den Rebooten.
Vor dem Reboot
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyACM0@9600 3453
DeviceName /dev/ttyACM0@9600
FD 15
FHTID 3453
MAXLAN_MSGCNT 3
MAXLAN_TIME 2018-10-29 16:57:06
NAME MAXLAN
NR 89
NR_CMD_LAST_H 3
PARTIAL
RAWMSG Z0E3B0202033BC8654321000118002829
RSSI -53.5
STATE Initialized
TYPE CUL
VERSION V 1.26.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
initString X21
Zr
Za654321
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-10-28 18:09:02 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2018-10-29 16:53:22 cmds B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
2018-10-29 16:57:05 credit10ms 1942
2018-10-28 18:09:18 fhtbuf AE
2018-10-28 19:56:46 raw No answer
2018-10-29 16:57:06 state Initialized
2018-10-28 18:09:26 uptime 0 00:09:34
2018-10-28 18:09:31 version V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
XMIT_TIME:
1540828402.69049
1540828402.99128
1540828625.12838
Attributes:
alias MAX Würfel
group MaxLan
icon cul
model CUL
rfmode MAX
room Root
verbose 1
und nach dem Reboot
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyACM0@9600 3453
DeviceName /dev/ttyACM0@9600
FD 15
FHTID 3453
MAXLAN_MSGCNT 1
MAXLAN_TIME 2018-10-29 16:47:34
NAME MAXLAN
NR 89
NR_CMD_LAST_H 2
PARTIAL
RAWMSG Z0C3A044216BA83031EF70029C910
RSSI -66
STATE Initialized
TYPE CUL
VERSION V 1.26.03 a-culfw Build: private build (unknown) CUBe (F-Band: 868MHz)
initString X21
Zr
Za654321
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-10-28 18:09:02 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2018-10-29 16:46:35 cmds B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
2018-10-29 16:29:00 credit10ms 509
2018-10-28 18:09:18 fhtbuf AE
2018-10-28 19:56:46 raw No answer
2018-10-29 16:47:34 state Initialized
2018-10-28 18:09:26 uptime 0 00:09:34
2018-10-28 18:09:31 version V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
XMIT_TIME:
1540827995.90671
1540827996.20754
Attributes:
alias MAX Würfel
group MaxLan
icon cul
model CUL
rfmode MAX
room Root
verbose 1
Kann selbst leider nicht viel mit den Infos anfangen
Werde jetzt mal bei 0 Anfangen.
Update:
So Lösung durch Zufall gefunden ;D ;D.
Habe bei o Angefangen und gesehen festgestellt das hier die Änderung ist.
Attributes IODev geändert.
Alt, Bezug auf den Max original Würfel
att Gerät IODev MAXLAN
Neu, Bezug auf den CUL_MAX
att Gerät IODev cmax
Danach Funktioniert alles wie es soll auch nach dem Reboot.
Definition des Würfels ist vor seinen Geräte, dies noch zu Info.
Nochmals Danke :)
Gruß Thorsten
Hallo,
Ich habe gerade einen meiner Cubes(alter TRX868) auf CUL (aktuelle Version) geflasht. Es scheint soweit alles geklappt zu haben, zumindest leuchtet die mittlere LED und die POWER LED blinkt. Das soll doch so sein, oder? Leider finde ich im Router keinen Netzwerkeintrag, der mir die IP verrät und ohne kann ich ihn ja nicht definieren.
Woran kann es liegen?
Hi,
ich vermute weil er nicht auf Netzwerkmodus geht. Hast Du ein Daten-USB-Kabel an dem Cube und versorgst ihn noch mit dem Rechner mit dem Du geflasht hast? Nimm mal ein Standalone Netzteil oder eben ein Power-Only-Kabel.
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Habe unter gefühten 100 Kabel kein einziges ohne die mittleren Kontakte gefunden. Aber auch an einem reinen Steckernetzteil ändert sich nix. Hab ihn jetzt erstmal über USB am Pi angeschlosse, um zu testen, ob er überhaupt sinnvolle Signale von sich gibt.
Es lebt und antwortet schonmalVERSION V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)Wie bekomme ich ihn jetzt dazu auch über Netzwerk zu funken?
Stell über USB eine statische IP Adresse ein. Und der Netzwerkmodus funktioniert auch dann, wenn eine USB Verbindung besteht.
Aha, er war schon online über Netzwerk, nur hat die doofe FritzBox ihn weder in der Geräteliste noch als aktive Verbindung, sondern nur als Ungenutzte Verbindung gelistet. Nachdem ich über screen die MAC-Adresse und IP ausgelesen habe (völliges Neuland für mich, Aaaaabenteuer) hab ich ihn dann in der FrtizBox gefunden. Nachdem ich die DEF auf IP umgestellt habe, war der FlashCube dann auch in der FriBox ordentlich gelistet.
Aber irgendwie hat mir der kurzzeitige Parallelbetrieb von HM-MOD-UART und FlashCube das HM-Setup durcheinander gewürfelt. Hab auf einmal ein unbekanntes HM-Device in der Übersicht.
aber das ist hier wohl oftopic.
Danke auf jeden Fall für die Hilfe.
SO,
nachdem sich Cube Nr2 nun auch mal wieder resetet hat, hab ich ihn auch umgeflasht. Diesmal hat alles auf Anhieb funktioniert.
Lieber Telekatz, vielen Dank für die tolle Arbeit.
Hallo zusammen,
wenn ich den Cube umflashe, arbeitet er dann eigentlich noch als LAN-Device oder nur noch per USB?
Grüße
Funktioniert sowohl als auch. Wenn bei LAN Einbindung sollte man eine USB Verbindung nur zu Stromversorgung herstellen.
Gesendet von meinem Note3 mit Tapatalk
Ich habs gerade gefunden. Und es steht eigentlich auch auf den ersten Seiten in dem Thread.
Danke für die Antwort :)
Irgendwas läuft bei mir nicht.
Ich hab den CUBE eigentlich deswegen umgeflasht, weil er zuvor alle paar Wochen nicht mehr richtig funktionierte.
Ich hab heute die neueste Firmware geflasht und dann in FHEM integriert
define MAXcube CUL 192.168.171.4:2323 0000
Per attribut hab ich ihn zu einem "MAX" gemacht. Das autocreate des CUL_MAX hat nicht funktioniert, deswegen hab ich das manuell gemacht:
define MAXcul CUL_MAX 654321
Jetzt würde ich gerne meine bestehenden Thermostate (3 Stück), wieder anlernen. Dazu hab ich sie zurückgesetzt (Batterie raus, 3 Tasten beim einlegen gedrückt, res erscheint).
Jetzt versetze ich mein Geräte "MAXcul" in den pairmode. Das wird nicht bestätigt, der State bleibt bei "Defined" stehen. Wenn ich ein Thermostat ebenfalls in den pairmode versetze, wird es im Log erkannt und erstellt.
Wenn ich nun das CUL_MAX device erneut in den pairmode setze, passiert nichts mehr. Keine Log-Einträge, der State bleibt weiterhin bei defined usw...
Ich hab alle Device gelöscht, Server und Raspberry neu gestartet usw... Ich kann immer 1 Device anlegen und dann geht nichts mehr, egal welchen Reboot ich danach mache. Beim erkennen des ersten Geräts werden folgende Logs erzeug:
2018.11.19 14:13:23 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2018.11.19 14:13:39 3: CUL_MAX_Parse: Re-Pairing device 153b17 of type HeatingThermostat with serial NEQ0932759
2018.11.19 14:13:39 1: PERL WARNING: Use of uninitialized value $it in concatenation (.) or string at ./FHEM/98_autocreate.pm line 135.
2018.11.19 14:13:39 2: autocreate: define MAX_153b17 MAX HeatingThermostat 153b17
2018.11.19 14:13:39 2: autocreate: define FileLog_MAX_153b17 FileLog ./log/MAX_153b17-%Y.log MAX_153b17
2018.11.19 14:13:48 1: 192.168.171.4:2323 disconnected, waiting to reappear (MAXcube)
2018.11.19 14:13:48 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:13:52 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:13:57 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:02 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:07 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:12 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:17 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:22 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:27 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:32 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:37 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:42 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:47 1: Error in CUL_MAX_SendQueueHandler: CUL MAXcube did not answer request for current credits. Waiting 5 seconds.
2018.11.19 14:14:52 3: MAXcube: Possible commands: BbCFiAZNEkGMKLUYRTVWXOefhltxz
2018.11.19 14:14:52 1: 192.168.171.4:2323 reappeared (MAXcube)
2018.11.19 14:14:54 1: Device MAX_153b17 answered with: Invalid command/argument
Weiß jemand weiter?
Hier noch ein paar Internals:
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXOefhltxz
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.171.4:2323 0000
DeviceName 192.168.171.4:2323
FD 10
FHTID 0000
MAXcube_MSGCNT 1
MAXcube_TIME 2018-11-19 14:29:11
NAME MAXcube
NR 64
NR_CMD_LAST_H 3
PARTIAL
RAWMSG Z0E030202153B1765432100011900291B
RSSI -60.5
STATE Initialized
TYPE CUL
VERSION V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
initString X21
Zr
Za654321
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-11-19 14:26:49 cmds B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
2018-11-19 14:29:10 credit10ms 2167
2018-11-19 14:29:11 state Initialized
XMIT_TIME:
1542634009.78685
1542634010.08743
1542634150.10673
Attributes:
DbLogExclude .*
rfmode MAX
Internals:
DEF 654321
IODev MAXcube
LASTInputDev MAXcube
MAXcube_MSGCNT 1
MAXcube_RAWMSG Z0E030202153B176543210001190029
MAXcube_RSSI -60.5
MAXcube_TIME 2018-11-19 14:29:11
MSGCNT 1
NAME MAXcul
NR 66
STATE Defined
TYPE CUL_MAX
addr 654321
cnt 0
pairmode 0
retryCount 0
sendQueue:
Attributes:
DbLogExclude .*
IODev MAXcube
Falls noch jemand einen Cube sucht. Bei Amazon gibt es ihn gerade für 25€.
https://www.amazon.de/MAX-Cube-LAN-Gateway-99004/dp/B004W1Q2BO
@Bond246, dein Problem wäre im MAX! Forum vermutlich besser aufgehoben als hier,
aber nachdem du vorher schon nach USB / Lan gefragt hattest :
Ich vermute jetzt mal du versorgst den Cube von irgend einem Gerät via USB Port mit Strom und nicht von einem dummen Netzteil ? Wenn ja : Netzteil verwenden oder USB Kabel bearbeiten das es nur noch 2 Adern hat
(In die Falle bin ich mal getappt, siehe etliche Seiten weiter vorne)
Beste Danke!!!
Offenbar war es genau das. Und ich dachte noch, "nicht dass da am Ende einfach nur die Stromversorgung zu schlecht ist".
Bisher kam der Strom per USB aus der Fritzbox, die gleich daneben steht.
Grüße
der Strom ist nicht zu schlecht , es die USB Datenverbindung die besteht aber nicht genutzt wird !
Darum mein Tipp in dem USB Kabel die beiden Drähte kappen und nur + & - ( i.d.R. schwarz und rot) übrig lassen.
Moin,
ich weiß, das ich hier im FHEM Forum bin und meine Frage bezüglich Homegear daher eigentlich OT ist, aber hier bin ich am nächsten am Entwickler dran und vielleicht mag und kann mir ja dennoch jemand helfen.
Ich möchte meinen Cube mit a-culfw flashen und dabei gleich die Möglichkeit nutzen, ein 433MHz CC1101 mit einzubauen für die Intertechno Funk-Steckdosen, so wie hier schon der eine oder andere es getan hat.
Löten, compilieren und flashen sind für mich kein Problem.
ABER: Wie konfiguriere ich das in Homegear, wenn ich den Cube dann als CUL oder CUN verwende?
Wahrscheinlich werde ich ihn als CUL nutzen, weil er sowieso nahe dem Raspberry steht und von dort bisher alles erreicht wird.
D.h. was muss ich in MAX.conf und intertechno.conf angeben, um das jeweilige Modul anzusprechen?
Einfach stackPosition = 0 bzw. 1 in den CUL/CUNX Abschnitt ergänzen?
Ich möchte das gerne vor dem Umbau wissen - kann da jemand helfen?
Danke
Mittlerweile habe ich einen Cube als Single-CUL/N geflasht und einen weiteren, den ich per Kleinanzeigen günstig schiessen konnte als 4fach CUL - bzw. 2fach, weil nur ein weiteres 433MHz CC1101 drin ist.
Der Einzel Cube CUN funktioniert einwandfrei.
Das 433MHz CC1101 auch, wenn ich es als Selbstbau CUL verwende - ich habe derzeit nur das eine.
Den 4fach Cube aber bekomme ich nicht wie gewünscht mit Homegear zum laufen.
Technisch ist alles ok - V und *V melden auch die beiden Module.
Welche Optionen habe ich denn, um die einzelnen Module per USB oder Netz anzusprechen?
Das zusätzliche Modul kann nur über * angesprochen werden. Es gibt keinen separaten Port für das zusätzliche Modul.
hm - Schade
Dann wird das wohl nix mit Homegear
Jedenfalls nicht mit meinem Wissen und das, was ich im Netz so finde - bzw. nicht finde.
Zitat von: Telekatz am 24 November 2018, 17:58:46Es 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 ;-)
Zitat von: tcj am 26 November 2018, 10:00:15
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?
Zitat von: Beta-User am 26 November 2018, 10:06:09
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.
Zitat von: gloob am 26 November 2018, 10:10: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?
Zitat von: Beta-User am 26 November 2018, 10:15:04
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.
Wie willst du aber 4 "CULs" über 3 Hardware Schnittstellen (USB) bekommen?
Über Netzwerk wäre es vielleicht noch machbar.
Zitat von: gloob am 26 November 2018, 10:49:31
Wie willst du aber 4 "CULs" über 3 Hardware Schnittstellen (USB) bekommen?
Über Netzwerk wäre es vielleicht noch machbar.
Wie ich schon schrieb - ich weiß ja nicht, ob, was und wie das geht.
Netzwerkports wären ein Anfang und würden mir persönlich ja schon reichen.
Alles über USB - oder vielleicht auch nur die ersten drei - spart ggf. ein Kabel und einen Port am Switch ;-)
Homegear unterstützt doch anscheinend den SCC. Auch mehrere gestapelte. Damit sollte auch der MapleCUL/CUBe mit mehreren Transceivern gehen.
Hallo zusammen,
auch ich habe meinen Cube, der zuvor einige Jahre als MAXLAN in Gebrauch war, auf CUL_MAX umgeflasht. Meine Hauptgründe dafür waren, dass sich der Cube alle paar Wochen aufgehangen hat und ich ihn manuell reseten musste. Zudem hat mir das Polling nicht gefallen. Das Inbetriebnehmen des CUL_MAX hat auch problemlos funktioniert und läuft nun seit einigen Wochen.
Mein Problem sind fehlende Zustandsänderungen und damit dann auch fehlende Events.
Hintergrund: Ich nutze den Cube für die Überwachung von 19 Max-Fensterkontakten. Um Empfangsprobleme handelt es sich höchstwahrscheinlich nicht. In seinen Jahren als MAXLAN gab es meines Wissen nach nicht einen einzigen Verlust einer Nachricht. Der Standort hat sich nicht verändert. Heute konnte ich zudem beobachten, dass der Kontakt an der Haustür beim Öffnen und Schließen jeweils nur einmal geblinkt hat, d.h. die Übertragung zum Cube wurde erfolgreich quittiert. Der Cube hängt per USB an einem kleinen USB-Hub, der wiederum an einem Raspi hängt.
Hat jemand eine Idee, warum der CUL_MAX Nachrichten bzw. Zustandsänderungen verschluckt?
Viele Grüße
Starbug
Ein Beispiel von heute:
2018-12-06_17:54:00 Haustuer opened
2018-12-06_17:54:12 Haustuer closed
2018-12-06_18:31:21 Haustuer opened
2018-12-06_18:41:51 Haustuer opened
2018-12-06_19:24:38 Haustuer opened
2018-12-06_19:35:14 Haustuer opened
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXOefhltxz
CUL2_MSGCNT 11304
CUL2_TIME 2018-12-06 20:57:11
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF /dev/ttyACM3@9600 0000
DeviceName /dev/ttyACM3@9600
FD 4
FHTID 0000
NAME CUL2
NEXT_OPEN 1543428183
NR 73
NR_CMD_LAST_H 4
PARTIAL
RAWMSG Z0B5D0030054E53000000000011
RSSI -65.5
STATE Initialized
TYPE CUL
VERSION V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-11-15 21:40:13 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2018-11-28 19:02:03 cmds B b C F i A Z N E k G M K L U Y R T V W X O e f h l t x z
2018-12-06 20:49:34 credit10ms 3282
2018-11-15 21:54:22 raw Z00D8
2018-12-06 20:57:11 state Initialized
2018-11-15 22:05:10 version V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) CUBe (F-Band: 868MHz)
XMIT_TIME:
1544125755.45259
1544125761.96311
1544125768.47328
1544125774.98859
Attributes:
rfmode MAX
Im Log steht dann mit Verbose 5:
2018.12.08 20:41:29 5: cm: dispatch MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:41:29 5: MAX_Parse MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:41:29 5: ShutterContact isopen 1, rferror 0, battery 0, unkbits 0
2018.12.08 20:42:24 5: cm: dispatch MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:42:24 5: MAX_Parse MAX,0,ShutterContactState,0554cd,02
2018.12.08 20:42:24 5: ShutterContact isopen 1, rferror 0, battery 0, unkbits 0
Hier wurde der Fensterkontakt geöffnet, geschlossen und wieder geöffnet.
Der RSSI-Wert schwankt zwischen -70 und -80.
PS: Vielen Dank für das Modul!
Ergänzung am 16.12.2018:
Was ich bisher probiert habe:
- 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?
Bitte um einen Stubs in die richtige Richtung. Mein CUBE will nicht senden. :(
Mein ca. 5 Jahre alter MAXCUBE wurde auf V 1.26.03 a-culfw geflasht und um ein Modul für IT erweitert.
Da das Compilieren unter jessie bei mir nicht klappte, hab ich das fertige CUBEx4_BL
vom blog.loetzimmer.de verwendet. Hat soweit auch geklappt.
Nun das Problem:
1)
Die 5 MAX-Thermostate (Firmware 1.0) lassen sich nicht anlernen?
Sie werden zwar per autocreate gefunden und zugeordnet,
es scheint aber so, als würde nur mitgelesen.
Ich kann keine Temperatur setzen.
An ihnen blinkt auch das Antennensymbol nach dem Versuch sie neu anzulernen.
Batterien raus, Werksreset, neu anlernen führen nicht zum Erfolg.
Wie kann ich da anders vorgehen?
2)
Der CUBE (Stromversorgung über USB_Steckernetzteil 2A) lässt sich ansprechen.
LED auf 01 schaltet die LED ein, sie geht aber nach wenigen Sekunden wieder aus.
Ist das richtig?
3)
Welches IODev bekommen die Thermostate?
Der CUL_MAX wird per autocreate eingetragen.
Muss ich den auf den CUL ändern? Der ist ja schließlich per rfmode auf MAX gestellt.
Meine Konfiguration 1xCube per Netzwerk 5x Thermostat 5x FK:
1x Cube mit rfmode MAX
1x CC1101 mit rfmode SlowRF für die IT Steckdosen
Der CUBE
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz*
CUL_CUBe_MSGCNT 165
CUL_CUBe_TIME 2018-12-31 17:37:45
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.1.57:2323 0000
DeviceName 192.168.1.57:2323
FD 25
FHTID 0000
NAME CUL_CUBe
NR 765
NR_CMD_LAST_H 33
PARTIAL
RAWMSG *i500015F1
RSSI -59
STACKED CUL_CUBe_IT
STATE Initialized
TYPE CUL
VERSION V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
initString X21
Zr
Za123456
Zw111111
MatchList:
1:CUL_MAX ^Z........................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-12-31 17:07:39 cmds B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
2018-12-31 17:37:52 credit10ms 8
2018-12-31 17:37:45 state Initialized
2018-12-31 16:44:25 version V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 868MHz)
XMIT_TIME:
1546273362.5362
1546273369.07126
1546273375.59825
1546273382.12472
1546273385.67114
1546273392.20128
1546273398.25276
1546273404.77885
1546273408.33951
1546273414.87449
1546273421.43948
1546273427.92978
1546273431.46164
1546273437.49959
1546273444.05191
1546273450.13371
1546273453.22362
1546273459.76035
1546273466.29082
1546273472.82956
1546273476.3599
1546273482.89335
1546273489.44597
1546273495.95125
1546273499.46991
1546273506.0224
1546273608.53421
1546273718.06567
1546273827.62427
1546273937.15168
1546274046.6824
1546274156.20553
1546274265.91405
Attributes:
icon cul
rfmode MAX
room Gateways
CUL_MAX
Internals:
CUL_CUBe_MSGCNT 118
CUL_CUBe_RAWMSG Z0AF30A0305D80F0504C700
CUL_CUBe_RSSI -59
CUL_CUBe_TIME 2018-12-31 17:33:41
DEF 123456
IODev CUL_CUBe
LASTInputDev CUL_CUBe
MSGCNT 118
NAME CUL_CUBe_MAX
NR 766
STATE Defined
TYPE CUL_MAX
addr 123456
cnt 0
pairmode 0
retryCount 0
READINGS:
2018-12-31 17:35:59 packetsLost 95
sendQueue:
HASH(0xbb316110)
Attributes:
IODev CUL_CUBe
icon cul
room Gateways
CUL_IT
Internals:
CMDS bCFiAZNEGMKLUYRTVWXfz
CUL_CUBe_IT_MSGCNT 47
CUL_CUBe_IT_TIME 2018-12-31 17:37:45
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF CUL_CUBe
IODev CUL_CUBe
NAME CUL_CUBe_IT
NOTIFYDEV CUL_CUBe
NR 769
NTFY_ORDER 50-CUL_CUBe_IT
PARTIAL
RAWMSG i500015F1
RSSI -81.5
STATE Initialized
StackLevel 1
TYPE STACKABLE_CC
VERSION V 1.26.03 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 433MHz)
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2018-12-31 17:07:39 cmds b C F i A Z N E G M K L U Y R T V W X f z
2018-12-31 17:37:44 raw is0000F0000FFF
2018-12-31 17:37:45 state Initialized
Attributes:
icon cul
rfmode SlowRF
room Gateways
@clyde,
schau mal hier https://forum.fhem.de/index.php/topic,60458.msg879305.html#msg879305. Da ist meine config. MAX!-CUBE mit 3x CC1101 (2 zusätzliche). Alle Leitungen verbunden GDO0 und GDO2 (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html).
pejonp
Ich habe mir deine Konfiguration angesehen. Hast du kein CUL_MAX Device?
Meine Befürchtung momentan ist, das die alte Firmware 1.0 in den Thermostaten bei mir nicht mitspielt.
Werden MAX Thermostate mit 1.0 Firmware überhaupt unterstützt?
@clyde
Der erste cui ist für MAX!
defmod CUL_1 CUL 192.168.x.xxx:2323 3034
attr CUL_1 model CUN
attr CUL_1 rfmode MAX
attr CUL_1 room TRX
Pejonp
Ja, das habe ich auch. Sieht so aus:
defmod CUL_CUBe CUL 192.168.1.57:2323 0000
attr CUL_CUBe rfmode MAX
defmod CUL_CUBe_IT STACKABLE_CC CUL_CUBe
attr CUL_CUBe_IT rfmode SlowRF
Zusätzlich habe ich allerdings noch ein CUL_MAX mit dem ich in den pairmode gehen kann.
defmod CUL_CUBe_MAX CUL_MAX 123456
attr CUL_CUBe_MAX IODev CUL_CUBe
set CUL_CUBe_MAX pairmode
Wie hast du mit deinem CUL_1 die MAX Komponenten angelernt?
@clyde
defmod CULMAX0 CUL_MAX 123456
attr CULMAX0 IODev CUL_2
attr CULMAX0 room CUL_MAX
attr CULMAX0 verbose 2
pejonp
Zitat von: Clyde am 01 Januar 2019, 12:14:05
set CUL_CUBe_MAX pairmode
dir ist aber schon klar das da noch die Zeit in Sekunden fehlt ?
set CUL_CUBe_MAX pairmode 120 ?
Auch mit Zeitangabe bekomme ich das Blinken des Antennensymbols im MAX-Thermostat-Display nicht weg. Es findet vermutlich kein Pairing statt.
Die Thermostate tauchen aber nach einer gewissen Zeit (autocreate) in der Konfiguration auf:
defmod MAX_05d80f MAX HeatingThermostat 05d80f
attr MAX_05d80f IODev CUL_CUBe_MAX
Allerdings lassen sie sich nicht ansprechen (Temparatur ändern).
Hat jemand mit Thermostaten Firmwarestand 1.0 Erfolg?
Ich vermute das diese sich nicht erfolgreich pairen lassen.
Zitat von: Clyde am 03 Januar 2019, 12:03:19
Auch mit Zeitangabe bekomme ich das Blinken des Antennensymbols im MAX-Thermostat-Display nicht weg. Es findet vermutlich kein Pairing statt.
Die Thermostate tauchen aber nach einer gewissen Zeit (autocreate) in der Konfiguration auf:
defmod MAX_05d80f MAX HeatingThermostat 05d80f
attr MAX_05d80f IODev CUL_CUBe_MAX
Allerdings lassen sie sich nicht ansprechen (Temparatur ändern).
Hat jemand mit Thermostaten Firmwarestand 1.0 Erfolg?
Ich vermute das diese sich nicht erfolgreich pairen lassen.
Achtung, es gibt auch unterschiedliche Typen von MAX-Thermostaten:
https://www.elv.de/topic/alte-firmware-ausgeliefert.html
Das Gemeine ist, dass eq-3 bei der neuen Hardwareversion der Thermostate die (angepasste) Firmware auch wieder 1.0 genannt hat.
1.0 alt ist aber eine andere Firmware als 1.0 neu. (Hardware ist auch anders.)
Das nur als Hinweis.
Gesendet von meinem XT1650 mit Tapatalk
Das ist ja raffiniert von dieser Firma. Da meine Thermostate >5 Jahre sind, hab ich sicher die alte Version 1.0.
Ein Update zu machen scheint ja nicht möglich zu sein.
Fragt sich, ob es Versionen gibt, die nicht kompatibel sind oder gehen tatsächlich alle Versionen?
Hallo zusammen, was meint ihr,
ist es auch möglich einen hm-mod-rpi-pcb direkt anzuschließen bzw zu löten?
Gesendet von meinem HTC U11 mit Tapatalk
Zitat von: d0np3p3 am 10 Januar 2019, 04:40:37
Hallo zusammen, was meint ihr,
ist es auch möglich einen hm-mod-rpi-pcb direkt anzuschließen bzw zu löten?
Gesendet von meinem HTC U11 mit Tapatalk
Moin
Wozu soll das gut sein? Es ist doch quasi einer im Cube verbaut!?
Gruss Christoph
Hallo Christoph, anstelle von einem CC1101 bei Umbau auf cube x3
Der eingebaute wird für max! verwendet, ein weiterer 433 für it und dann ein CC1101 oder Hm mod für Homematic inkl Hm ip
Grüße zurück
PS vollzitat ist glaube ich nicht notwendig gewesen
Gesendet von meinem HTC U11 mit Tapatalk
Hi, die a-culfw kann vier cc1101 auf dem CUBE. Beim MapleCUL werden zusätzlich zwei Serielle Schnittstellen auf zwei weiteren Ports über Ethernet bereitgestellt.
Wenn Du also wirklich vor hast, einen HM-MOD-UART am CUBE zu betreiben, dann müsstest Du:
a) klären ob der eine serielle frei hat
b) die Firmware analog zum Maple erweitern, um die serielle auf einen Port 2324 zu legen
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Der Max!cube hat laut @telekatz einen seriellen debug Port und einen uart0.
Analog zu diesem Post könnte da doch was möglich sein?
https://forum.fhem.de/index.php/topic,60458.msg541584.html#msg541584
Leider fehlt mir das Wissen, ob dies möglich ist und wenn ja wie umgesetzt werden kann.
Gesendet von meinem HTC U11 mit Tapatalk
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.
Problem meinerseits ist gelöst. Auch alte Max!Thermostate mit Firmwarestand 1.0 lassen sich anlernen. Ich hatte beim Reset/Ablernen nicht lange genug die Tasten gehalten. ::)
Ich bekomme nun alle Thermostate angelernt.
Zitat von: Telekatz am 11 Januar 2019, 13:33:28
Um das zu machen müsste man die USB Lib auf dual CDC umbauen. Ist prinzipiell möglich, war aber schon beim Maple einiges an Arbeit.
Danke für deine Einschätzung, schade, aber nicht schlimm. Dann kommt ein CC1101 mehr rein.
Gesendet von meinem HTC U11 mit Tapatalk
Es gibt's den cube gerade im Angebot für 21,90 bei Amazon und für 22.90 bei ebay
Sucht nach:
MOBILCOM-DEBITEL MAX! Cube LAN-Gateway
Gesendet von meinem HTC U11 mit Tapatalk
Hi,
1) Offtopic
2) Nur mit Vertrag -> also nein ;-)
3) Ich habe nich einen gebrauchten, wenn jemand einen will *lol*
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Wieso mit Vertrag? Amazon Prime reicht.
Ist doch auch ein Vertrag ;-) Aber Danke! Gruß Arnd
Gesendet von iPhone mit Tapatalk
Ebay ist ohne vertrag, oder?
Ich würde mich freuen über den cube, was willst du denn für den cube? [emoji848]
Gesendet von meinem HTC U11 mit Tapatalk
Hallo, erst mal vielen Dank für die tolle Anleitung. Habe in meinen Cube noch ein 868 und ein 433 MHz Modul eingebaut. Es funktioniert der "Cube 0", also der alte Teil mit MAX und das Modul 1 mit SlowRF in 868MHz. Modul 2 (433MHz) funktioniert leider nicht richtig.
Wenn ich im Terminal prüfe, erhalte ich Folgendes:
V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
*V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
**V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
0D2E2D07D3913D04
320000060021656A
57C43023B9000700
18146C070090876B
F85611EF2C191F41
00597F3F88310B00
*292E3F07D391FF04
*4500000F001EC4EC
*8C220222F8470730
*04766C034091876B
*F85610A90A200D41
*00597F3F88310B00
**292E3F07D391FF04
**4500000F001EC4EC
**8C220222F8470730
**04766C034091876B
**F85610A90A200D41
**00597F3F88310B00
Das zweite zusätzliche Modul hat hier denselben Inhalt wie das erste. Ist das korrekt? Wo kann ich nach dem Fehler suchen?
Hi, hast du die Frequenz umgestellt?
set <device2> freq 433.920
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Danke. Das habe ich versucht. Folgenden Fehler finde ich dann im Logfile:
2019.01.15 18:29:41 3: Setting FREQ2..0 (0D,0E,0F) to 10 b0 71 = 433.920 MHz
2019.01.15 18:29:41 3: Cube_2: Unknown code ? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.01.15 18:29:41 3: Cube_2: Unknown code ? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.01.15 18:29:41 3: Cube_2: Unknown code ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z, help me!
Die Frequenz bleibt auf 868 MHz. Das Verstellen funktioniert bei den ersten beiden Modulen, bei dem dritten nicht. Folgende Fehlermeldung bekomme ich regelmäßig:
2019.01.14 21:53:32 2: Setting Cube_2 fhtid from ? (T01 is unknown) Use one of b C A Z N E L Y V X f z to 3412
Zeig mal alle list,
Wie ist der CC1101 angeschlossen?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Hallo,
Modul 1 (welches funktioniert auf SlowRF mit 868MHz):
Internals:
CMDS bCFiAZNEGMKLUYRTVWXfz*
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Cube_1_MSGCNT 2123
Cube_1_TIME 2019-01-15 18:50:03
DEF FHEM:DEVIO:Cube_0_SCC:42 2345
DeviceName FHEM:DEVIO:Cube_0_SCC:42
FD 17
FHTID 2345
IODev Cube_0_SCC
IODevPort 42
IODevRxBuffer
IOReadFn STACKABLE_IOReadFn
NAME Cube_1
NR 44
PARTIAL
RAWMSG T255F00A6001B
RSSI -60.5
STACKED Cube_1_SCC
STATE Initialized
TYPE CUL
VERSION V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-01-15 18:23:54 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2019-01-14 21:53:32 cmds b C F i A Z N E G M K L U Y R T V W X f z *
2019-01-15 18:50:03 state Initialized
SOFTBUFFER:
Attributes:
alias FHT
rfmode SlowRF
room CUL
Modul 2, welches nicht richtig funktioniert (433MHz Modul):
Internals:
CMDS bCAZNELYVXfz
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
Cube_2_MSGCNT 9
Cube_2_TIME 2019-01-15 18:30:00
DEF FHEM:DEVIO:Cube_1_SCC:42 3412
DeviceName FHEM:DEVIO:Cube_1_SCC:42
FD 17
FHTID 3412
IODev Cube_1_SCC
IODevPort 42
IODevRxBuffer
IOReadFn STACKABLE_IOReadFn
NAME Cube_2
NR 46
PARTIAL
RAWMSG ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
STATE Initialized
TYPE CUL
VERSION V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-01-14 20:53:42 ccconf freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
2019-01-14 21:53:32 cmds b C A Z N E L Y V X f z
2019-01-15 18:39:37 raw C35 = 01 / 1
2019-01-15 18:30:00 state Initialized
2019-01-14 19:58:27 uptime No answer
2019-01-13 23:38:38 version V 1.26.05 a-culfw Build: private build (unknown) CUBEx4_87 (F-Band: 868MHz)
Attributes:
alias 433
rfmode SlowRF
room CUL
Stell mal versuchsweise an Modul 1 433.920 ein, bitte
Wieso hat Modul 2 kein W im cmds?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Der Cube kann nur an den ersten beiden Modulen SlowRF. Du solltest das dritte Modul für MAX verwenden.
Hallo Telekatz, das war's tatsächlich. Habe jetzt durch Anpassung der Üinbelegung board.h auf die ersten beiden Module SlowRF gelegt und auf den dritten Max und alles klappt inkl. der Einstellung auf 433Mhz, vielen Dank!
Hallo,
ich habe heute einen meiner beiden MaxCubes umgeflasht und um 2 weitere CC1101 Module erweitert.
Im TeraTerm kann ich die 3 mit V, *V,**V nach der Version abfragen.
Jetzt wollte ich diese Fhem bekannt machen, und bekomme den 3. nicht per STACKABLE dazu.
Der Cube ist mit
define MAXCUN CUL 192.168.90.42:2323 0000
attr MAXCUN icon mqtt_device
attr MAXCUN rfmode MAX
der 2. dann mit
define MAXCUN_1 STACKABLE_CC MAXCUN
attr MAXCUN_1 connectCommand Nr1
attr MAXCUN_1 rfmode SlowRF
eingebunden, wenn ich den dritten mit
define MAXCUN_2 STACKABLE_CC MAXCUN
bekanntmachen möchte kommt:
MAXCUN has alread a stacked device: MAXCUN_1
Hab ich da den falschen Syntax ? Würde mich über eine Info freuen,
Gruß Rene
Danke an die Macher, für diese wirklich schöne Möglichkeit den Cube so zu verwenden.
Habs mit
define MAXCUN_2 STACKABLE_CC MAXCUN_1
gings dann.
Vieleicht hilft es ja nochmal jemanden.
Gruß
Hi,
Halt so wie es im Wiki für den MapleCUN aufgeschrieben ist ;-)
Vielleicht sollten wir das allgemeiner bei Stackable platzieren.
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
@skycrack
als Anlage der bootlader_CUBe und die Firmeware 1.26.05. Habe ich auf meinem CUBe und dort ist auch LaCross mit drin. ES werden aber nur 2 von 10 erkannt. Mit JeeLink/LaCrossGateway geht es besser.
pejonp
@pejonp
Super Sache, vielen Dank. Hab eine compilierte Version am laufen, Lacrosse und Autocreate des HMS Devices klappt.
Besten Dank
Rene
Kurze Frage,
habe mir auch den MAX Cube umgeflasht (Bootloader und Firmware). Ist alles ohne Probleme durchgelaufen (Es blinkt die Power Lampe). Wenn ich das Teil jetzt an das Lan hänge, passiert nix, sprich der Port kommt gar nicht hoch (Lampe bleibt aus am Switch) und dementsprechend sehe ich den Würfel auch nicht im Lan.
Frage, muss ich da noch was machen vorher (per USB anschließen und irgendwas aktivieren)?
Gruss
Helge
Vielleicht ne blöde Frage, aber nichz böse gemeint und klassischer IT-Support: Ist der Cube denn über den USB-Port mit Strom versorgt?
Und die Antwort: wenn der Datenleitungen hat macht die a-culfw alles über usb und nicht über lan! Ist mir auch passiert! Also ab an ein Steckernetzteil oder ein nur Power Kabel (z.B. Von Powerbank) am RasPi ;-)
Passiert übrigens seit a-culfw 1.26.02 auch beim MapleCUN bei Betrieb mit ESP-01 über Debug Schnittstelle ;-)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: RaspiLED am 27 Januar 2019, 17:04:57
Und die Antwort: wenn der Datenleitungen hat macht die a-culfw alles über usb und nicht über lan! Ist mir auch passiert! Also ab an ein Steckernetzteil oder ein nur Power Kabel (z.B. Von Powerbank) am RasPi ;-)
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.
Zitat von: Mondeo20 am 27 Januar 2019, 16:21:09
Kurze Frage,
habe mir auch den MAX Cube umgeflasht (Bootloader und Firmware). Ist alles ohne Probleme durchgelaufen (Es blinkt die Power Lampe). Wenn ich das Teil jetzt an das Lan hänge, passiert nix, sprich der Port kommt gar nicht hoch (Lampe bleibt aus am Switch) und dementsprechend sehe ich den Würfel auch nicht im Lan.
Frage, muss ich da noch was machen vorher (per USB anschließen und irgendwas aktivieren)?
Gruss
Helge
Ich würde empfehlen, den Cube über USB anzuschließen und ihm eine feste IP Adresse zu geben.
Mmmh, ich habe das original Netzteil verwendet, sprich ich habe noch einen mit originaler Firmware, der im Moment die Max Thermostate versorgt und habe einfach umgesteckt (Lan Kabel und Netzteil).
Zitat von: Telekatz am 15 Januar 2019, 20:56:57
Der Cube kann nur an den ersten beiden Modulen SlowRF. Du solltest das dritte Modul für MAX verwenden.
Hallo,
ist das eine Firmeware oder Hardware Einschränkung? Ließe sich das ändern? Der 3. CC1101 ist vollständig verdrahtet.
Gruß
Rene
Beides. Pro SlowRF braucht man einen Real-time Timer, wovon der AT91SAM7 drei hat. Zwei davon werden für SlowRF verwendet, einer für Systemaufgaben. Den für die Systemaufgaben könnte man eventuell durch den Periodic Interval Timer ersetzen, dann währen drei SlowRF receiver möglich.
Zitat von: Telekatz am 22 Juni 2015, 22:42:29
Firmware flashen :
Die kompilierten Bin Dateien findet Ihr unter https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw (https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw). Die Firmware besteht aus zwei Teilen. Einem Bootloader (bootloader_CUBE.bin bzw. bootloader_HM_CFG.bin) und der eigentlichen culfw (CUBE_BL.bin bzw. HM_CFG_BL.bin).
Hallo @Telekatz,
ich wollte gerade Deiner Anleitung folgen meinen ersten Cube flashen. Dabei habe ich gemerkt, dass unter dem Link keine Dateien mehr zu finden sind. Gibt es einen neuen Link oder hättest Du einen Tipp für mich, wo ich die notwendigen Dateien finden kann?
Vielen Dank!
Source:
https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices/CUBe
Binaries:
https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw
Konkret:
http://download37.mediafire.com/g8o6kdkgahvg/hk0y134b339mw11/a-culfw_1.26.05_build_312.zip
Der letzte Link ist zeitlich begrenzt ;-)
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Lieber Arnd,
herzlichen Dank für die schnelle Antwort! Der Mediafire-Link sieht bei mir zwar weiterhin so aus, als lägen da keine Dateien - aber der direkte Link funktioniert ;D
Viele Grüße
Phillip
PS: Es liegt an Safari. Mit Chrome geht der Link. Sorry - war also mein Fehler.
Zitat von: Clyde am 03 Januar 2019, 12:03:19
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. :(
Ich habe die neue Firmware Build a-culfw_1.26.06_build_316.zip auf einen MAX!Cube geflasht, der vorher mit der der Firmware vom Dezember 2018 a-culfw_1.26.05_build_312.zip einwandfrei im Rfmodus funktionierte. Ich hatte den Flash gemacht, da ich hoffte dass er dann auch Wmbus ohne Probleme empfangen würde. (Siehe auch: https://forum.fhem.de/index.php/topic,96268.0.html)
Beim flashen der neuen Firmware blieb TeraTerm (Windows) hängen. Danach ging nichts mehr mit dem Cube, alle Led's aus. Ich habe dann versucht mit SAM-BA 2.18 (Windows) den Bootloader neu zu installieren. Funktionierte nicht. Dann habe ich mit BOSSA (Windows) den Bootloader neu geflash, was funtionierte. Ich habe dann mit TeraTerm nochmals die neue Firmware geflasht, mit demselben Ergebnis: TeraTerm hängt nach ca 75% und nach Neustart des Cube ging nichts mehr. Dann habe ich über BOSSA und TeraTerm die Firmware vom Dezember zurückgespielt. Nun geht fast alles wieder, ausser dass ich keine feste mehr IP zuweisen kann. Es geht nur DHCP.
Vielleich gibt es ja eine Lösung dafür. Vielen Dank vorab.
Grüße Achim
Hi,
wie groß sind die Files?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
das File, das funktioniert hat 110kB, das File, das nicht funtioniert 111kB.
Gruß Achim
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.
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?
Hallo,
Habe meinen MAX! Cube laut Anleitung geflasht, und wenn ich ihn an ein USB Netzteil anschließe und Netzwerk passiert nichts. Leine LED geht an, kein Netzwerk, wie Tod.
Am PC kommt kein COM Port und "USB-Gerät wurde nicht erkannt"
Mache ich über den J1 eine Reset und machen den Bootloader wieder drauf, gleiches Problem.
Wie kann ich ihn komplett löschen?
Wieso will jeder immer gleich den Bootloader platt machen? Probier mal das:
Zitat von: Telekatz am 11 April 2019, 22:11:32
Nimm mal die CUBEx4_BL.bin. Bei einem gescheiterten Flashversuch muss man übrigens den Bootloader nicht neu installieren. Einfach den Cube ausstecken, die Taste unten am Cube gedrückt halten und dann USB wieder einstecken.
Zitat von: bigmo am 27 April 2019, 11:21:01
Hi Leute,
ich habe neuerdings ein Problem mit meinem geflashten Cube. Er vergisst immer wieder seine Netzwerkeistellungen (feste IP) und stellt sich auf DHCP zurück.
Ich habe schon neu geflasht und Eprom gelöscht aber das Phänomen bleibt.
Hatte das schon mal jemand?
Niemand eine Idee? Das macht mich noch verrückt. Dagegen war die amnesie des original Cube ja ein Segen...
Welche Firmwareversion nutzt du?
Ich hatte/"habe" das Problem, dass meine Einstellung auf 433Mhz ständig verloren ging.
Dadurch neuen Cube gekauft und eine inzwischen aktuellere Firmware geflasht - bisher Ruhe.
Ich kann also leider nicht sagen, ob das anscheinende Rücksetzen der Einstellungen ein FW oder HW Problem war.
-> Firmware auf das aktuellste Build patchen
-> zu deinem Problem: MAC Adress-Reservierung am Router und Cube auf DHCP belassen....
Kahrim
irgendwie komme ich nicht mehr an den ATMELSAM-Bain-SYSTEMPROGRAMMER ... Der Link fürht sofort auf die Hauptseite der Webseite.. somit kommt man da irgenwie nicht ran....
könnt ihr mir helfen?
Bei Microchip suchen, oder einfach Google fragen:
https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/Atmel%20SAM-BA%20In-system%20Programmer (https://www.microchip.com/DevelopmentTools/ProductDetails/PartNO/Atmel%20SAM-BA%20In-system%20Programmer)
Danke dir
Habe ich riichtig verstanden, dass man an den MAX Cube auch 1wire Komponenten anschließen könnte, die mit der a-culfw abgefragt werden können?
Ich überlege, so zu einem günstgen Helligkeitssensor zu kommen...
Wahrscheinlich braucht man einen Busmaster, aber wie und wo schließt man den an?
Danke schonmal,
Alex
Die Schaltung ist die gleiche wie für den MapleCUN:
https://wiki.fhem.de/wiki/MapleCUx_und_1-wire (https://wiki.fhem.de/wiki/MapleCUx_und_1-wire)
Angeschlossen wird das an einem freien CC1100 Port. SDA an den CS Pin und SCL an den IN Pin. Belegung siehe board.h. Mittlerweile ist es auch egal, welchen Port man dafür nimmt. Der I2C Busmaster wird an allen Ports erkannt.
Frei Pins am Cube siehe:
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606 (https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606)
Hi,
@Mihca
das fertige 1.26.06 CUBE_BL.binläuft auf dem CUBe bei mir auch nicht, booted nach Flashen nicht mehr.
Die 1.26.05 läuft aber problemlos.
@telekatz
Liegt das evtl. am 1-wire autodetect? Warum sollte dann die 1.26.06 CUBEx4_BL.bin laufen, (tut es bei mir auch nicht); habe noch kein 1-wire Modul dran (kommt aber...)
Gruß Phantom
Mit der letzten Änderung funktioniert 1-wire nur noch mit Hardware Autodetect. Das ist bei CUBEx4_BL aktiviert, nicht aber bei CUBE_BL. Da bei CUBE_BL noch 1-wire aktiviert war, lief das nicht.
Ob ein 1-wire Modul angeschlossen ist oder nicht ist bei CUBEx4_BL egal. Das Modul wird von Hardware Autodetect erkannt.
@phantom
ich habe 1.26.06 CUBEx4_BL.bin aus Zeitgründen noch nicht ausprobiert.
mfG Mihca
Hat eigentlich jemand eine Idee, wie ich die Battery LED abschalten kann, oder noch besser eine sinnvolle Aufgabe geben kann (wie z.B. den Batterie-Status der Homematic-Geräte anzuzeigen :O )?
Wie ich die Power LED konfiguriere habe ich schon selbst raus gefunden.
Angeregt durch den Beitrag mit dem MSC Bootloader (https://forum.fhem.de/index.php/topic,101610.0.html) für den MapleCUL habe ich auch den Bootloader für den Cube überarbeitet und auf MSC umgestellt. Geflasht wird der neue Bootloader genauso wie der alte.
Die Firmware Dateien sind mit beiden Bootloadern kompatibel. Man kann also auch den alten Bootloader weiter benutzen.
Ich habe heute nochmal seit langer Zeit versucht, die a-culfw für nanoCUL und CUBe auf dem RPi zu kompilieren. Da ich mittlerweile ein neu aufgesetztes System mit Buster habe, musste ich erstmal wieder alle benötigten Pakete zusammensuchen und installieren. (binutils-arm-none-eabi, gcc-arm-none-eabi, bossa-cli, libnewlib-arm-none-eabi, libstdc++-arm-none-eabi-newlib, gcc-avr, avr-libc)
Für den nanoCUL läuft auch alles. Beim Kompilieren des Bootloader für den CUBe kommt es aber zu einem Fehler beim Linken:
/usr/lib/gcc/arm-none-eabi/7.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [0011ccf0,0011ccf7] overlaps section .relocate LMA [0011ccf0,0011d25f]
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:125: CUBE_BL.elf] Fehler 1
Hat das Problem sonst noch jemand, bzw. gibt es eine Lösung dafür?
P.S.: Ein make direkt im Unterverzeichnis bootloader läuft durch und erstellt mir die bootloader_CUBE.bin
Wie groß ist die bootloader_CUBE.bin Datei, die dabei herauskam?
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
Die Datei ist zwar etwas größer als bei mir aber immernoch klein genug.
Ich denke, es könnte daran liegen, dass du eine andere GCC Version benutzt. Für die ARM Versionen sollte die GCC Version 5.4.1 verwendet werden.
Ich habe einfach das entsprechende Paket installiert. Die GCC Version ist 7.3.1:
dietpi@fhem:~$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:7-2018-q2-6) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Woran könnte es denn liegen, daß die bootloader_CUBE.bin zwar erstellt wird, es beim make direkt im CUBe-Verzeichnis beim Linken von CUBE_BL.bin zum Fehler kommt?
Es liegt an der GCC Version, ich habe es ausprobiert. Mit Version 6.2.1 läuft es durch und mit Version 7.3.1 habe ich auch einen Fehler.
Die bootloader_CUBE.bin wird deshalb ohne Fehler erstellt, weil dort der Teil des Codes, der den Fehler verursacht, nicht enthalten ist.
Du kannst entweder eine ältere GCC Version verwenden oder folgende Änderung im Linkerscript versuchen:
SECTIONS
{
.ARM.exidx : {
. = ALIGN(4);
__exidx_start = .;
*(.ARM.exidx*)
__exidx_end = .;
} > flash
.fixed :
{
. = ALIGN(4);
_sfixed = .;
*(.text*)
*(.rodata*)
*(.data.__malloc_av_)
*(.data.__malloc_trim_threshold)
*(.data.__malloc_sbrk_base)
*(.data.__ctype_ptr__)
*(.data.__global_locale)
. = ALIGN(4);
_efixed = .;
} >flash
Danke! Jetzt lässt sich die Firmware kompilieren. Das Aufspielen des neuen Bootloader mit bossa hat auch geklappt.
Wenn ich das richtig verstehe, wird die neue Firmware nicht mehr mit einem Terminal Emulator wie minicom übertragen, sondern soll auf das neu angelegte Laufwerk kopiert werden.
Bei aktiviertem Bootloader wird jetzt ein Laufwerk erkannt:
[Di Jul 9 21:45:07 2019] usb 1-1.5: new full-speed USB device number 60 using dwc_otg
[Di Jul 9 21:45:07 2019] usb 1-1.5: New USB device found, idVendor=03eb, idProduct=6129, bcdDevice= 1.00
[Di Jul 9 21:45:07 2019] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Di Jul 9 21:45:07 2019] usb 1-1.5: Product: ATMEL AT91 MSD
[Di Jul 9 21:45:07 2019] usb 1-1.5: Manufacturer: ATMEL
[Di Jul 9 21:45:07 2019] usb 1-1.5: SerialNumber: 0123456789AB
[Di Jul 9 21:45:07 2019] usb-storage 1-1.5:1.0: USB Mass Storage device detected
[Di Jul 9 21:45:07 2019] scsi host0: usb-storage 1-1.5:1.0
[Di Jul 9 21:45:08 2019] scsi 0:0:0:0: Direct-Access ATMEL Mass Storage MSD 0.01 PQ: 0 ANSI: 6
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: Attached scsi generic sg0 type 0
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: [sda] 8000 512-byte logical blocks: (4.10 MB/3.91 MiB)
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: [sda] Write Protect is off
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: [sda] Mode Sense: 03 00 00 00
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: [sda] No Caching mode page found
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: [sda] Assuming drive cache: write through
[Di Jul 9 21:45:08 2019] sda:
[Di Jul 9 21:45:08 2019] sd 0:0:0:0: [sda] Attached SCSI removable disk
Jetzt habe ich /dev/sda gemountet und CUBE_BL.bin darauf kopiert. Nach einem umount bekomme ich mit dmesg einen Fehler angezeigt:
[Di Jul 9 21:57:42 2019] FAT-fs (sda): FAT read failed (blocknr 1)
[Di Jul 9 21:57:42 2019] FAT-fs (sda): unable to read boot sector to mark fs as dirty
Nach erneutem Anschliessen wird der CUBe nicht mehr erkannt:
[Di Jul 9 22:03:19 2019] usb 1-1.5: new full-speed USB device number 87 using dwc_otg
[Di Jul 9 22:03:19 2019] usb 1-1.5: device descriptor read/64, error -32
[Di Jul 9 22:03:19 2019] usb 1-1.5: device descriptor read/64, error -32
[Di Jul 9 22:03:19 2019] usb 1-1-port5: attempt power cycle
[Di Jul 9 22:03:20 2019] usb 1-1.5: new full-speed USB device number 88 using dwc_otg
[Di Jul 9 22:03:21 2019] usb 1-1.5: device not accepting address 88, error -32
[Di Jul 9 22:03:21 2019] usb 1-1.5: new full-speed USB device number 89 using dwc_otg
[Di Jul 9 22:03:21 2019] usb 1-1.5: device not accepting address 89, error -32
[Di Jul 9 22:03:21 2019] usb 1-1-port5: unable to enumerate USB device
Ist meine Vorgehensweise beim Installieren der Firmware falsch oder doch die kompilierte Firmware defekt?
Teste es einfach mit der fertig compilierten Firmwaredatei aus dem a-culfw Archiv.
Ok, so wie es aussieht muß ich wohl erst eine ältere Version der Toolchain installieren. Mal sehen, wo ich was für den Pi finde.
Die von Dir kompilierte Version lässt sich installieren. Da ich aber 2 Cubes angeschlossen habe, muß ich die Firmware selbst kompilieren mit unterschiedlichen IDs. Der selbst kompilierte Bootloader funktioniert auf jeden Fall auch mit neuerer GCC Version.
Vielen Dank für die Hilfe!
Zur Info: Mit der Version 6.3.1 von arm-none-eabi-gcc kommt es auch zum Linker-Fehler:
/usr/lib/gcc/arm-none-eabi/6.3.1/../../../arm-none-eabi/bin/ld: section .ARM.exidx LMA [0011cf54,0011cf5b] overlaps section .relocate LMA [0011cf54,0011d4c3]
collect2: error: ld returned 1 exit status
Leider finde ich keine Version 6.2.1 für den Pi. Für die 6.3.1 musste ich mir schon extra aus den Debian-Sourcen ein Paket bauen. Für Buster gibt es nur die 7.3.1.
Wäre es vielleicht möglich, mir die Firmware einmal mit USB_DESCRIPTOR_SN "0" zu kompilieren, damit ich beide Cubes betreiben kann?
Ich weiß zwar immer noch nicht, warum das Kompilieren auf dem Pi nicht mehr funktioniert, aber auf meinem Laptop unter Ubuntu Bionic lässt sich eine funktionierende Firmware auch mit v6.3.1 erstellen.
Hi,
ich wollte gerade meinem bereits geflashten Max!Cube eine aktuelle Firmware verpassen. Ich hatte den Cube vor ein paar Tagen bereits nach dieser Anleitung erfolgreich geflasht, dann aber festgestellt, dass ich eine uralte Version runtergeladen hatte. Also bin ich mit dem Cube wieder an den Rechner, habe bei gedrückter Resettaste die Verbindung hergestellt und dachte nun geht das ganz simpel weiter. Tut's aber nicht.
Im Gerätemanager erscheint ein neues Gerät wie erwartet. Nennt sich Bossa Program Port (COM8). Scheint mir ein Treiber zu sein, den SAM-BA (v2.18) gleich mit installiert. Damit hat es beim ersten mal aber auch geklappt, den Bootloader zu installieren.
Ich bin davon ausgegangen, dass ich den Cube nicht wieder löschen muss, also habe ich Tera Term gestartet. Dort wird mir der Port auch angeboten, ich kann mich aber nicht dahin verbinden weil Tera Term "Cannot open COM8. Access denied." ausgibt. Auch wenn ich Tera Term als Administrator starte.
Ich hab dann über J1 die Firmware wieder gelöscht, um von Vorne zu beginnen. Wenn ich nun SAM-BA starte kann ich zwar einen Port auswählen (seltsamerweise werden mit dort sowohl \USBserial\COM8 als auch COM8 angeboten. Bei ersterem kommt eine Verbindung zustande, SAM-BA startet danach aber nicht. Im Taskmanager sehe ich einen Prozess laufen.
Gibt es noch andere Möglichkeiten, den Bootloader zu installieren? Irgendwie muss das Teil doch wieder zum fliegen kommen.
LG petjek
Man kann den Bootloader entweder mit SAM-BA oder mit einem JTAG Interface flashen.
Und wenn du den Bootloader neu flashst würde ich empfehlen, den neuen MSC Bootloader aus dem letzten Release 1.26.07 zu verwenden.
Ein JTAG Interface habe ich nicht. Und SAM-BA macht eben nicht das was es soll. Um genau zu sein macht SAM-BA eben nichts mehr nach der Auswahl des COM-Ports.
Gesendet von iPhone mit Tapatalk
Wenn Du die Möglichkeit hast, einen Linux Rechner zu nutzen, geht es mit bossa. Mit Sam-ba unter Windows hatte ich auch dasselbe Problem wie Du.
BOSSA unter Windows 10 64 funktioniert bei mir prima. SAM-BA funktioniert bei mir ebenfalls nicht.
http://www.shumatech.com/web/products/bossa (http://www.shumatech.com/web/products/bossa)
Hab's nach einenm Neustart des Rechners hin bekommen. Danke.
Wie werden mit der aktuellen FW eigentlich inzwischen die beiden Schnittstellen ST1 & ST2 genutzt ?
Ich habe hier Antworten von 2015 gefunden das dort Debug Meldungen ausgegeben werden, trifft das noch so zu ?
Bzw. gäbe es vllt auch beim Cube eine Möglichkeit wie beim Maple eine der beiden Schnittstellen transparent auf einem TCP Port durchzureichen ?
Die eine Schnittstelle wird immer noch als Debugschnittstelle genutzt. Die andere Schnittstelle kann alternativ zum USB Anschluss für die Kommunikation genutzt werden, z.B. für eine WLAN Cube mit einem ESP.
Moin!
Ich habe den ganzen Thread durchgelesen, aber leider verstehe ich immer noch nicht, wie ich zusätzliche Funkmodule an meinen Cube anschließen muß. Ich bin da eigentlich nicht auf den Kopf gefallen, aber ich kapiere die Zuordnung der Pins gar nicht. Ich sehe irgendwie keinen Zusammenhang zwischen der Board.H sowie der Platine, auch mit Hilfe von https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html) nicht. Kann mir das mal jemand für Dummies erklären? :-) Im wesentlichen fehlt mir irgendwie ein Bild mit den Bezeichnungen der Pins auf der Platine des Cubes, scheint mir. Eigenlich will ich in meinem Cube nur ein 433MHz und ein weiteres 868MHz Modul unterbringen. Vielen Dank!!
Es ist eigentlich schon alles erklärt in dem Link von dir.
Hier nochmal die Bilder mit den freien Pins am Cube:
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606 (https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606)
Oh man, sorry, ich bin zu blöd :-) Ich habe den Thread gelesen, ohne mich anzumelden, da sieht man dann nicht einmal, dass man die Bilder nicht sieht .....
Jetzt verstehe ich es, allerdings fehlen da doch noch Pinbezeichnungen? In dem verlinkten Blog sind ja z.B noch PA10 und PA11 eingezeichnet, aber wo finde ich denn z.B. PB28 oder PB20, wie sie z.B. defaultmäßig in der board.h deklariert sind? Wobei das jetzt nicht mehr so dramatisch ist, da ich jetzt kapiert habe, wo ich die Module anschließen muss, allerdings muss ich dann ja auch die Firmware selbst kompilieren. Wie ist denn die Standardbelegung in der Cube x4 firmware? Das würde es deutlich vereinfachen ;D
Auf alle Fälle vielen Dank schon mal und nochmal sorry!!
MfG
Volker
PB20 und PB28 findest du auf der Unterseite:
https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711 (https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711)
Hallo, ich bins wieder :-)
Ich habe nun die Firmware selbst kompiliert, mit folgender board.h :
//External Transceivers
//PORT 1
#define CC1100_1_CS_PIN><------> 6
#define CC1100_1_CS_BASE<------> AT91C_BASE_PIOA
#define CC1100_1_OUT_PIN 25
#define CC1100_1_OUT_BASE AT91C_BASE_PIOB
#define CC1100_1_IN_PIN 5
#define CC1100_1_IN_BASE<------> AT91C_BASE_PIOA
//PORT 2
#define CC1100_2_CS_PIN><------> 10
#define CC1100_2_CS_BASE<------> AT91C_BASE_PIOA
#define CC1100_2_OUT_PIN 26
#define CC1100_2_OUT_BASE AT91C_BASE_PIOB
#define CC1100_2_IN_PIN 11
#define CC1100_2_IN_BASE<------> AT91C_BASE_PIOA
//PORT 3
#define CC1100_3_CS_PIN><------> 24
#define CC1100_3_CS_BASE<------> AT91C_BASE_PIOB
#define CC1100_3_OUT_PIN 20
#define CC1100_3_OUT_BASE AT91C_BASE_PIOB
#define CC1100_3_IN_PIN 28
#define CC1100_3_IN_BASE<------> AT91C_BASE_PIOB
Und habe an Port1 ein 433MHz Modul angeschlossen. Nun kann ich wunderbar z.B. Intertechno schalten, aber es empfängt nichts? Ich habe hier am Schreibtisch eine Revolt-Steckdose, die meine eigentliche FHEM-Installation, noch über einen Nano-CUL, zuspammt, aber auf meiner Testinstallation mit dem CUBe kommt nichts an? Wo könnte der Fehler sein?
In der fhem.cfg sieht das folgendermaßen aus :
define CUL1_868 CUL 192.168.42.99:2323 1234
setuuid CUL1_868 5d4d748a-f33f-03a3-f3b5-3817ba96a3d2a9a0
attr CUL1_868 group Gateways
attr CUL1_868 hmId 308393
attr CUL1_868 icon cul_868
attr CUL1_868 model CUN
attr CUL1_868 rfmode SlowRF
attr CUL1_868 room TRX
#define CUL1_868 CUL IP:Port=2323 FHTIDattr MAPLECUL_USB_868 group Gateways
define CUL1Stack STACKABLE CUL1_868
setuuid CUL1Stack 5d4d748a-f33f-03a3-7015-c45f16c8ab2b62b3
attr CUL1Stack room TRX
define CUL2_433 CUL FHEM:DEVIO:CUL1Stack:9600 0000
setuuid CUL2_433 5d4d748a-f33f-03a3-ec61-8933ee20cd9496a7
attr CUL2_433 group Gateways
attr CUL2_433 icon cul_cul
attr CUL2_433 model CUN
attr CUL2_433 rfmode SlowRF
attr CUL2_433 room TRX
Danke für Tipps und generel für die coole Firmware!!
MfG
Volker
was sagt denn ein get CUL2_433 ccconf ?
freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
und ein
list CUL2_433
Internals:
CMDS bCFiAZNEGMKLUYRTVWXfz
CUL2_433_MSGCNT 1
CUL2_433_TIME 2019-08-09 15:54:01
Clients :FS20:FHT.*:KS300:USF1000:BS:HMS:FS20V: :CUL_EM:CUL_WS:CUL_FHTTK:CUL_HOERMANN: :ESA2000:CUL_IR:CUL_TX:Revolt:IT:UNIRoll:SOMFY: :STACKABLE_CC:TSSTACKED:STACKABLE:CUL_RFR::CUL_TCM97001:CUL_REDIRECT:
DEF FHEM:DEVIO:CUL1Stack:9600 0000
DeviceName FHEM:DEVIO:CUL1Stack:9600
FD 7
FHTID 0000
FUUID 5d4d748a-f33f-03a3-ec61-8933ee20cd9496a7
IODev CUL1Stack
IODevPort 9600
IOReadFn STACKABLE_IOReadFn
NAME CUL2_433
NR 24
PARTIAL
RAWMSG 25 2422
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: private build (unknown) CUBEx4_83 (F-Band: 433MHz)
initString X21
MatchList:
0:FS20V ^81..(04|0c)..0101a001......00[89a-f]...
1:USF1000 ^81..(04|0c)..0101a001a5ceaa00....
2:BS ^81..(04|0c)..0101a001a5cf
3:FS20 ^81..(04|0c)..0101a001
4:FHT ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
5:KS300 ^810d04..4027a001
6:CUL_WS ^K.....
7:CUL_EM ^E0.................$
8:HMS ^810e04......a001
9:CUL_FHTTK ^T[A-F0-9]{8}
A:CUL_RFR ^[0-9A-F]{4}U.
B:CUL_HOERMANN ^R..........
C:ESA2000 ^S................................$
D:CUL_IR ^I............
E:CUL_TX ^TX[A-F0-9]{10}
F:Revolt ^r......................$
G:IT ^i......
H:STACKABLE_CC ^\*
I:UNIRoll ^[0-9A-F]{5}(B|D|E)
J:SOMFY ^Y[r|t|s]:?[A-F0-9]+
K:CUL_TCM97001 ^s[A-F0-9]+
L:CUL_REDIRECT ^o+
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2019-08-09 16:05:10 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
2019-08-09 16:03:08 cmds b C F i A Z N E G M K L U Y R T V W X f z
2019-08-09 16:03:08 state Initialized
Attributes:
group Gateways
icon cul_cul
Und im fhem.log sieht es so aus :
2019-08-09 16:02:59 CUL CUL1_868 cmds: B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
2019-08-09 16:02:59 CUL CUL1_868 Initialized
2019-08-09 16:02:59 CUL CUL1_868 CONNECTED
2019-08-09 16:03:08 CUL CUL2_433 cmds: b C F i A Z N E G M K L U Y R T V W X f z
2019-08-09 16:03:08 CUL CUL2_433 Initialized
2019-08-09 16:03:08 CUL CUL2_433 CONNECTED
2019-08-09 16:03:33 Global global ATTR CUL2_433 rfmode SlowRF
2019-08-09 16:03:52 Global global ATTR CUL1_868 rfmode SlowRF
2019-08-09 16:05:03 CUL CUL1_868 ccconf: freq:868.000MHz bWidth:325KHz rAmpl:42dB sens:4dB
2019-08-09 16:05:10 CUL CUL2_433 ccconf: freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:8dB
und
Zitat von: CaptainHook am 27 Dezember 2015, 22:29:03
Hast du auch ../../clib/rf_receive_revolt.c im Makefile?
Has_Revolt alleine reicht nicht..
ich habe sonst an den Quellen nichts verändert, in der Make.conf steht das drin :
SRCS += ../../clib/rf_receive_revolt.c
Setz mal mit "raw e" den Inhalt des EEPROM zurück.
schon probiert :) Ich habe noch einen neuen Cube und ein paar Funkmodule, ich baue nachher nochmal einen.
So, jetzt habe ich einen zweiten Cube mit einem 433MHz Modul verbunden, leider das gleiche Problem, senden geht, Empfangen nicht. Hüüülfeeeee!!! :-)
Liegt das evtl. daran, dass ich den Cube per LAN verbunden habe?? Ich dengle mal auf einen alten Raspi ein neues FHEM drauf und hänge den per USB dran.....
edit: Nö, auch per USB empfängt der meine Revolt-Steckdose auf 433MHz nicht.....
noch ein edit:
schalte ich dein eingebauten Transceiver, der ganz brav meinen ESA2000-Stromzähler empfängt, auf 433 MHz. kommen darüber (mit erstaunlicher Reichweite) meine beiden Revolt-Stecdosen sauber an, nur über das zusätzliche nicht. Heute kommt an einen Cube noch ein weiters 868MHz-Modul, mal schauen, wie sich das verhält.
edit again:
Nr1 auf das eingebaute Modul empfängt alle meine Lacrossesensonren dafür kommt fom ESA2000 nichts mehr. Nr1 auf dem 433Mhz-Modul bringt auch nichts. Umschalten des 433Mhz-Moduls auf MAX empfängt immerhine meine MAX!-Sachen.
Fortsetzung :
Nach Anschluss eines weiteren 868MHz-Moduls funktioniert dieses wie erwartet ..... nur das 433MHz-Modul will nicht. Ich tausche noch mal die Module zwischen den Ports, außerdem habe ich noch ein anderes 433MHz-Modul, anderer Hersteller, anderes Layout. Vielleicht liegt es ja an den verwendeten Modulen.
Ist das hier eigentlich normal?
CUL1_868 UNKNOWNCODE ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
CUL2_433 UNKNOWNCODE ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
CUL3_868 UNKNOWNCODE ? (? is unknown) Use one of b C A Z N E L Y V X f z
und beim ersten CUL1_868 sthet in den Internals
RAWMSG **? (? is unknown) Use one of b C A Z N E L Y V X f z
werden die irgendwie Rückwärts durchnummeriert? Ich steig nicht durch.
Setze ich ein raw Nr1 auf den CUL3 ab, passiert im Log folgendes :
2019.08.10 12:57:17 5 : CUL/RAW: /*N019586533241AAAA0000248D0D
2019.08.10 12:57:17 4 : CUL_Parse: CUL2_433 *N019586533241AAAA0000248D0D
2019.08.10 12:57:17 5 : CUL2_433: dispatch *N019586533241AAAA0000248D0D
2019-08-10 12:57:17 CUL CUL3_868 UNKNOWNCODE N019586533241AAAA0000248D0D
2019.08.10 12:57:17 3 : CUL3_868: Unknown code N019586533241AAAA0000248D0D, help me!
2019-08-10 12:57:17 HMS HMS100TF_4316 temperature: 25.3
2019-08-10 12:57:17 HMS HMS100TF_4316 humidity: 50
2019-08-10 12:57:17 HMS HMS100TF_4316 battery: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 batteryState: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 type: HMS100TF
2019-08-10 12:57:17 HMS HMS100TF_4316 T: 25.3 H: 50 Bat: ok
Wieso tauch hier jetzt der CUL2 auf?
Wieso kann ich die Frequenz vom 3. CUL nicht setzen?
2019-08-10 13:26:42 CUL CUL3_868 freq 433.92
2019.08.10 13:26:42 5 : CUL/RAW: /*? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:42 4 : CUL_Parse: CUL2_433 *? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:42 5 : CUL2_433: dispatch *? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019-08-10 13:26:44 CUL CUL3_868 UNKNOWNCODE ? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:44 3 : CUL3_868: Unknown code ? (W0F10 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.08.10 13:26:44 5 : CUL/RAW: /*? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:44 4 : CUL_Parse: CUL2_433 *? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:44 5 : CUL2_433: dispatch *? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019-08-10 13:26:45 CUL CUL3_868 UNKNOWNCODE ? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 3 : CUL3_868: Unknown code ? (W10b0 is unknown) Use one of b C A Z N E L Y V X f z, help me!
2019.08.10 13:26:45 5 : CUL/RAW: /*? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 4 : CUL_Parse: CUL2_433 *? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 5 : CUL2_433: dispatch *? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019-08-10 13:26:45 CUL CUL3_868 UNKNOWNCODE ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z
2019.08.10 13:26:45 3 : CUL3_868: Unknown code ? (W1171 is unknown) Use one of b C A Z N E L Y V X f z, help me!
Zitat von: vklaffehn am 09 August 2019, 21:41:14
Ist das hier eigentlich normal?
CUL1_868 UNKNOWNCODE ? (? is unknown) Use one of B b C F i A Z N E k G M K L U Y R T V W X e f h l t x z *
CUL2_433 UNKNOWNCODE ? (? is unknown) Use one of b C F i A Z N E G M K L U Y R T V W X f z *
CUL3_868 UNKNOWNCODE ? (? is unknown) Use one of b C A Z N E L Y V X f z
Ja, das ist normal.
Zitat von: vklaffehn am 09 August 2019, 21:41:14
und beim ersten CUL1_868 sthet in den Internals
RAWMSG **? (? is unknown) Use one of b C A Z N E L Y V X f z
werden die irgendwie Rückwärts durchnummeriert? Ich steig nicht durch.
Setze ich ein raw Nr1 auf den CUL3 ab, passiert im Log folgendes :
2019.08.10 12:57:17 5 : CUL/RAW: /*N019586533241AAAA0000248D0D
2019.08.10 12:57:17 4 : CUL_Parse: CUL2_433 *N019586533241AAAA0000248D0D
2019.08.10 12:57:17 5 : CUL2_433: dispatch *N019586533241AAAA0000248D0D
2019-08-10 12:57:17 CUL CUL3_868 UNKNOWNCODE N019586533241AAAA0000248D0D
2019.08.10 12:57:17 3 : CUL3_868: Unknown code N019586533241AAAA0000248D0D, help me!
2019-08-10 12:57:17 HMS HMS100TF_4316 temperature: 25.3
2019-08-10 12:57:17 HMS HMS100TF_4316 humidity: 50
2019-08-10 12:57:17 HMS HMS100TF_4316 battery: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 batteryState: ok
2019-08-10 12:57:17 HMS HMS100TF_4316 type: HMS100TF
2019-08-10 12:57:17 HMS HMS100TF_4316 T: 25.3 H: 50 Bat: ok
Wieso tauch hier jetzt der CUL2 auf?
Nachrichten, die mit * beginnen, werden an den nächsten CUL weitergeleitet. Deshalb taucht die Nachricht des letzten CUL im LOG der vorhergehenden CULs auch auf.
Zitat von: vklaffehn am 10 August 2019, 13:27:52
Wieso kann ich die Frequenz vom 3. CUL nicht setzen?
Weil der 3. CUL beim Cube kein SlowRF kann.
Danke! Jetzt kapiere ich es. Dann ergibt es auch keinen Sinn, zum Testen den 433MHz an die 3. Stelle zu hängen, weil Revolt un IT SlowRF benötigen,richtig? Dann nehme ich mal meinen 3.Cube, und probiere es nochmal mit dem anderen Modultyp.
Moin!
Erfolgsmeldung! :-)
Es scheint tatsächlich an meinen 433MHz-Modulen zu liegen. Ein dritter Cube mit einem anderen Modultyp (diese Bauform : https://eckstein-shop.de/Wireless-RF-Transceiver-Module-433Mhz-CC1101-CC1100-Antenna?curr=EUR&gclid=Cj0KCQjw-b7qBRDPARIsADVbUbXDPXdv8Rw6insIcUDx8DB6YalSAFyHKFfdMi1jh4s-P41tXC4Q-TkaAo2oEALw_wcB (https://eckstein-shop.de/Wireless-RF-Transceiver-Module-433Mhz-CC1101-CC1100-Antenna?curr=EUR&gclid=Cj0KCQjw-b7qBRDPARIsADVbUbXDPXdv8Rw6insIcUDx8DB6YalSAFyHKFfdMi1jh4s-P41tXC4Q-TkaAo2oEALw_wcB)) läuft wie gewünscht! Ich hänge mal Bilder von meiner Verkabelung an. Und für die Leute, die aus dem Blogbeitrag auf lötzimmer.de nicht schlau geworden sind : Im Wesentlichen fehlt da die Pinbelegung des verwendeten Moduls, diese habe ich hier auch mal angehängt.
Hallo,
ich will mir noch eine Wetterstation zulegen, am besten eine mit 433Mhz weil dort die Reichweite am besten ist.
Nach dem Wiki https://wiki.fhem.de/wiki/Ventus_Wetterstation_433MHz#W132 (https://wiki.fhem.de/wiki/Ventus_Wetterstation_433MHz#W132) ist das Auswertemodul "CUL_TCM97001".
In der board.h https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h (https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)
findet sich der passende Eintrag mit TCM97001
#define _433MHZ
# if defined(_433MHZ)
# define HAS_TCM97001
# define HAS_IT
# define HAS_HOMEEASY
# define HAS_BELFOX
# define HAS_MANCHESTER
# define HAS_REVOLT
# endif
Ich wollte also einfach ein 433 Mhz CC1101 an Port3 anschliessen damit die Wetterstation empfangen.
Aber nach diesem Wiki https://wiki.fhem.de/wiki/SIGNALduino (https://wiki.fhem.de/wiki/SIGNALduino) funktioniert es nur mit einem Signalduino der auf ATmega basiert. Auch im Forum fand ich bei der Suche nach CUL_TCM97001 immer nur den Verweis auf den Signalduino.
Da bin ich jetzt verwirrt - kann ich die Wetterstation emfangen ?
Hallo Zusammen,
nachdem ich noch einen vergessenden Cube hatte habe ich mich gestern drangemacht und versucht ihn doch noch nützlich zu machen.
Ich arbeite unter Win10 und bin mit Sam-ba 2.18 nicht weitergekommen.
Als ich dann Bossa 1.9.1 benutzte konnte ich m.M. nach den Bootlader erfolgreich flashen.
Wenn ich dann den Cube wieder vom USB trenne und wieder anstecke (egal ob mit oder ohne gedrückten Reset-Button) blinkt er hektisch grün, Win10 macht auch das Geräusch eines neuen Gerätes, allerdings zeigt der Eintrag im Geräte-Manager ein tragbares Geräte mit Laufwerksbuchstaben "G:" Nach einiger Zeit scheint es einen Neustart zu geben, Win10 macht wieder das Geräusch eines neuen Gerätes, aber wieder wird nichts anderes angezeigt.
Weder Tera Term noch andere XModem fähige Terminalp. kriegen eine Verbindung.
Was mache ich falsch, bzw. was muss ich machen um die aktuelle aculfw draufzubekommen? Wer hat Ideen und kann mir hefen?
Vielen Dank im Voraus!
Das ist der neue MSC Bootloader. Zum flashen muss man nur die Firmwaredatei auf das neue Laufwerk kopieren.
Sorry wenn ich das irgendwo überlesen habe. Jetzt leuchtet eine konstant die andere blinkt langsam.
Im Geräte Manager erscheint AT91 USB to Serial Converter
Moin, ich bin gestern auf diesen Thread gestoßen und habe daraufhin bei ebay einen Cube gekauft. Grund ist, dass ich immer wieder Probleme mit meinen Homematic-Gateways habe. Derzeit habe ich einen LAN-Konfigurationsadapter, der je nach Tagesform ständig neu startet (Kondensatoren tauschen hat nix gebracht) und einen ESP mit HM-MOD-RPI-PCB, der sich aber gelegentlich aufhängt. Jetzt will ich also mit dem geflashten Cube mein Glück versuchen.
Ich habe heute in diesem und einigen anderen Threads quergelesen und auch im Wiki gestöbert . Oft wird von CUL/CUN für Homematic abgeraten oder zumindestens eine spezielle Firmware (ts-culfw) empfohlen, aber auf dem Cube läuft ja wohl eine andere (a-culfw). Vieles, was ich gelesen habe ist aber schon einige Jahre alt und ich frage mich, inwiefern es noch aktuell ist. Meine Umgebung umfasst geschätzt 30 HM-Komponenten, einiges davon mit AES. Ist das mit culfw@arm realistisch zu betreiben oder soll ich das gleich vergessen? Wenn ich es richtig verstanden habe, kann ich den Cube sowohl über USB als auch über LAN verbinden - macht das einen Unterschied in der Zuverlässigkeit, weil fhem zB das Timing über USB besser steuern kann?
So, mein Cube ist angekommen. Direkt geflasht und integriert.
Nun erwäge ich, bei allen anderen IOdevs einfach mal den Stecker zu ziehen und zu gucken, ob der Cube das packt.
Zitat 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.
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?
Ich habe eine kurze Frage zu meinem Cube.
ich habe wie im Thread weiter oben bzw. unter https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html ein weiteren CC1101 angelötet.
board.h angepasst und Firmware sowie Bootloader compiliert.
Nach kurzschließen des J1 Reset PINs den Bootloader mittels Bossa aufgespielt.
Nach Neuanschließen öffnet sich auch wie erwartet ein neues Laufwerk in Windows, in das ich die Firmwaredatei ziehe. Diese wird scheinbar auch eingespielt, D1 leuchtet direkt danach dauerhaft.
Jetzt aber:
Nach erneuten Anschließen an USB blinkt D1 direkt schnell (ohne Drücken des rückseitigen Tasters) und es öffnet sich wieder das Laufwerksfenster.
Nach einigem Probieren folgende Beobachtungen:
Gleiches Problem beim Flashen der vorkompilierten Firmware.
Gleiches Problem beim Verwenden des Prä-MSC Bootloaders. Einspielen der Firmware mittels Teraterm scheinbar erfolgreich. Nach Neuverbinden das gleiche Spiel mit Blinken von D1.
Das Gerät verhät sich so, als der Taster dauerhaft geschlossen wäre. Kurz durchgemessen: er funktioniert.
Hat jemand irgendeine Idee, woran dies liegen könnte?
Tausen Dank!
Es schon mal ohne den zusätzlichen CC1101 probiert?
Zitat von: Telekatz am 29 September 2019, 22:04:24
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!
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.
Hallo zusammen,
ich habe da ein Problem mit den hm-cc-rt-dn Thermostaten.
Ich betreibe zwei umgflashte Cubes mit V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54).
Sobald ich bei den Heizkörperthermostaten ein getConfig im Clima Channel mache (HM_XY000_Clima)
bekomme ich "RESPONSE TIMEOUT:RegisterRead". Das gleiche Problem habe ich mit der vorherigen Firmware V 1.26.06.
Andere Versionen habe ich nicht versucht.
Sobald ich die Thermostate auf den nanoCUL verbinden lasse funktioniert alles tadellos.
Gibt es Einschränkungen bei dem Cube ?
Nein, da gibt es keine Einschränkungen beim Cube. Und bei meinen Thermostaten bekomme ich kein "RESPONSE TIMEOUT:RegisterRead".
Ok, gut.
Wie kann ich denn mit dem Cube am besten "einfangen" wo der Fehler liegen könnte ?
fhem.log verbose 5 zeigt mir nicht den Fehler. Kann man irgendetwas einstellen wo man dann
den Fehler sehen könnte ?
Zitat von: Telekatz am 01 Oktober 2019, 11:47:33
Debugausgaben gibt es an ST2. Allerdings hat der Bootloader selbst keine Debugausgaben, das verbraucht nur unnötig Platz.
Für Debugausgaben musst du im Makefile TARGETSTART und TRACE_LEVEL anpassen, den Bootloader neu compilieren und auch die a-culfw mit neuer TARGETSTART Adresse erstellen.
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
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.
Zitat von: Telekatz am 02 Oktober 2019, 20:52:40
Nimm für TRACE_LEVEL 5 und stell TARGETSTART auf 0x108000. Damit darf der Bootloader maximal 32K groß werden.
TARGETSTART für die a-culfw wird im Linker Script CUBE_BL_flash.lds im Abschnitt MEMORY eingestellt.
Danke, hat geklappt.
Log, wenn ich den geflashten CUBe an USB hänge:
CUBELOADER gestartet
-I- -- Compiled: Oct 2 2019 22:27:54 --
-I- Flash lock 00
-I- Flash memory 00108000:E59F006C
-I- RAM memory 00200000:AA
-I- TA2 off
-I- Chip ID 275B0940
-I- Chip ID Extention 00000000
-D- LUN SDRAM
-I- LUN init
-I- 1 Medias defined
-I- MSD init
MSDReset USBD_Init
Res Res EoBRes CfgEpt0 NewReq Std gDesc Dev EoBRes CfgEpt0 NewReq Std sAddr SetAddr(18) NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Str3 NewReq Std gDesc Str0 NewReq Std gDesc Str2 NewReq Std gDesc Qua -W- Sta 0x888A8 [0] -W- _ NewReq Std gDesc Dev NewReq Std gDesc Cfg NewReq Std gDesc Cfg NewReq Std gDesc Str0 NewReq Std gDesc Str0 NewReq Std gDesc Str3 NewReq Std gDesc Str3 NewReq Std sCfg SetCfg(1) CfgEpt1 CfgEpt2 MSDReset NewReq gMaxLun -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk Inquiry S-D- Cbk ending Inquiry Sent -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
S-W- Sta 0x8628 [2] NewReq ClrFeat Hlt Std cFeat Hlt taIN -D- Cbk -D- Cbk ReqSense -D- Cbk ReqSense -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 0x23
S-W- Sta 0x8E28 [2] NewReq ClrFeat Hlt Std cFeat Hlt taIN -D- Cbk -D- Cbk ReqSense R-D- Cbk eqSense -D- Cbk -D- Cbk -W- MSDD_ProcessCommand: Unknown command 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:
-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:
-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!
-I- RAM memory 00200000:AA
Der Bootloader findet am RAM Anfang den Wert 0xAA. Dadurch wird der Bootloader gestartet. Sollte eigentlich nach dem Einstecken der Stromversorgung nicht passieren.
Teste mal, ob bei aktivierten Bootloader nach ein paar Minuten der Cube automatisch neu starten und in die Firmware springt.
Auch könntest du mal probieren, Zeile 238 in bootloader.c zu ändern:
*ram = 0x55;
Wenn das nichts hilft, kann man die Überprüfung auf 0xAA auch deaktivieren in Zeile 164-166:
// if(*ram != 0xaa) {
jump_to_target();
// }
Zitat von: Telekatz am 03 Oktober 2019, 11:13:34
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.
Zitat von: Telekatz am 03 Oktober 2019, 11:13:34
Auch könntest du mal probieren, Zeile 238 in bootloader.c zu ändern:
*ram = 0x55;
Das hat keine Änderung gebracht, nur der Bootloader startet.
Zitat von: Telekatz am 03 Oktober 2019, 11:13:34
Wenn das nichts hilft, kann man die Überprüfung auf 0xAA auch deaktivieren in Zeile 164-166:
// if(*ram != 0xaa) {
jump_to_target();
// }
Das funktionert einwandfrei, die Firmware startet direkt.
Hmm, gibt es eine Idee, warum das bei meinen Gerät angepasst werden muss? Ich kann damit gut leben aber irgendeine Ursache muss es ja dafür geben...
Vielen Dank, der CUBEe ist gerettet :)
Habe meinen eingestaubten CUBE wieder aktiviert und auf 1.26.08 geflasht. Ziel ist es ista Wasser- / Wärmezähler (vermutl. mit Wireless M-Bus) zu empfangen. Wireless M-Bus wäre hier im Status ein bißchen wie "Jugend forscht".
Ist das Protokoll grundsätzlich in der culfw@ARM mit eingebaut / aktiviert worden?
Auf "brs", bzw. "brt" im telnet client kommen jedenfalls "SMODE" / "TMODE" als Responses.
Besten Dank schon mal!
Hallo zusammen,
ich habe schon seit ein paar Jahren einen MAX!Cube mit der Firmware von Telekatz geflasht und das Teil arbeitet ohne Mucken, vielen Dank noch mal für die tolle Arbeit hier!
Ich habe nun von Conrad im Rahmen einer Weihnachtsaktion die Wetterstation Eurochron ETFH-800 gratis mit dazu bekommen, und die ist schon ganz nett, aber ich würde sie gerne in FHEM einbinden, und habe die Hoffnung, da es sich um ein 433MHz-System handelt, dass das vielleicht sogar möglich ist?
Im Forum findet man zu anderen Eurochron-Wetterstationen Hinweise, aber ich bin mir nicht sicher, wie ich eine Einbindung angehen sollte und ob das überhaupt mit diesem Modell out-of-the-box geht. Falls nicht, dann hat vielleicht trotzdem jemand Hinweise, wie ich da vorgehen könnte?
Neben dem geflashten Cube (der momentan im Moritz-Modus die Max!-Heizkörper- und Wandthermostate abfragt) hätte ich auch noch einen CC1101-USB-Lite 868MHz Stick hier herumliegen, falls es damit besser/überhaupt nur gehen sollte.
Freue mich über jeden Hinweis, danke dafür schon im Voraus,
F.
EDIT: Foto von Platine angehängt.
Hi,
ich habe vor ein paar Monaten meinen MaxCube erfolgreich mit einem zusätzlichen 433er CC1101 versehen,
mit a-CulFW V 1.26.08 geflasht und in meinem Testsystem im FHEM via Netzwerk zur Steuerung meiner IT-Komponenten eingebunden.
Das hat soweit alles funktioniert (Senden & Empfangen). (Soweit ich mich erinnern kann ;-) )
Jetzt hat's leider die MemCard meines Test-Raspis gerissen.
Auf meinem Prod-System sicherere ich regelmässig nach Änderungen. Leider nicht auf dem Testsystem.
Ich kann mich nicht mehr erinnern, wie ich den MaxCul eingebunden habe und die Suche hat auch nichts nützliches ergeben.
Könnte mir da bitte einer weiterhelfen und die Konfiguration eines funktionierenden Setups (MaxCube mit V 1.26.08 und zusätzlichen 433 CC1101, Netzwerkanschluss, für IT-Steuerung)
angeben?
gruss
jones
Zitat von: JonesFXR am 23 Dezember 2019, 11:46:56
die Suche hat auch nichts nützliches ergeben.
Tipp : Suchbegriffe STACKABLE und STACKABLE_CC
oder wie im Wiki für Maple ab Punkt 8 -> https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_.28alt.29
STACKABLE bzw. CC, da kam ich nicht drauf.
Danke!!!
Mein Cube wird nach dem ersten Teil dem Flashen des Bootloaders als USB Laufwerk erkannt, ich kann ihn seriell nicht verbiden?
Hat jemand eine Idee?
Version a-culfw_1.26.08_build_324, hab aber auch die zwei vorhergehenden probiert, derselbe Fehler.
Danke schonmal ....
genau das ist ja der riesen Vorteil des neuen Bootloaders , ein Laufwerk und da schiebst du einfach die FW hin :)
Zitat von: Wzut am 04 Januar 2020, 19:25:32
genau das ist ja der riesen Vorteil des neuen Bootloaders , ein Laufwerk und da schiebst du einfach die FW hin :)
1000x Dank, ich hab es nach der "alten" Anleitung versucht.
Noch eine Frage, gibt es da eine WEB Oberfläche?
beim CUL ? nein wozu ?
Hallo, Ich habe ein Problem mit meinem MAX-Cube..
ich habe versucht nach der Anleitung vom Anfang dieses Themas zu flashen, also
1. J1 verbinden und kurz strom setzen
2. USB mit SAM-BA den bootloader übertragen..
3. mit gedrückter resettaste starten, D1 blinkt schnell - und hier hat es begonnen, denn win10 erkennt das ding dann als USB-Laufwerk und nicht als COM oder so (habe ich vielleicht eine andere Hardware?? - siehe Fotos)...
daher habe ich von seite 3
Zitat
Der Anschluss von TA2 sieht genauso aus wie bei mir. Das scheint es wohl nicht zu sein.
Du könntest mal folgendes probieren:
-Flash erase mit J1 durchführen.
-In SAM-BA bootloader_CUBE.bin auswählen und auf Send File klicken.
-In SAM-BA die Address von 0x100000 auf 0x104000 ändern
-In SAM-BA CUBE_BL.bin auswählen und auf Send File klicken.
-Script Boot from Flash ausführen.
-USB trennen und Cube neu starten.
ausprobiert.. dann habe ich auch die CUBE_BL.bin übertragen können..
4. Cube getrennt und neu gestartet, D1 blinkt 1x/sek, D3 läuchtet durch...
ich bekomme auch ein Ping auf die per DHCP zugewiesene IP (nicht dauernd, immer wieder mit unterbrechungen)
in FHEM einbinden funktioniert nicht, da immer disconnectet (muß hier noch irgendwas aus FHEM geflasht werden wie beim Signalduino?)
eingebunden in FHEM habe ich es mit
define cuno CUL 10.66.1.234:2323 0000
setuuid cuno 5e29445e-f33f-2c3b-2243-14690970eef34fc8
attr cuno room 031_MAX!
habe ich irgendwo was übersehen, vergessen oder falsch gemacht?
hat jemand von euch tips?
danke für eure hilfe
Nachtrag:
Mit Putty komme ich, wenn per usb direkt angesteckt ist, mit SErial-verbindung auf den CunO. bei V erhalte ich folgende INfos:
V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
du bist zuerst in die Bootloader Falle getappt :)
Der neue Bootloader erzeugt ein USB Laufwerk wo man zum flashen einfach nur die Datei hinschieben muß :)
Das ist relativ versteckt hier im Thread ( da er erst sehr viel später kam ) und ich bin da auch mal reingefallen.
@Telekatz vllt solltest du da mal im ersten Post eine Anmerkung hinterlassen.
Dein Disconnect :
Auch das wurde hier schon behandelt - wenn du die Cube Stromversorgung via USB machst ist es ein Unterschied ob du einen echten USB Port verwendest oder ein Netzteil. Beim Netzteil sollte alles gut sein, verwendest du aber den USB Port so will der Cube Daten loswerden. Schafft er das nicht macht er einen Reboot. D.h. wenn der USB Port nur Stromversorgung ist aber der Zugriff exklusiv via LAN erfolgen soll benötigst du ein "dummes" USB Kabel das entweder keine oder gekappte Datenleitungen hat.
Hallo Wzut
danke für die INfo, klar dass ich wieder mal irgendwo reintappe.... immer so...
Zitatdu bist zuerst in die Bootloader Falle getappt :)
das mit dem Disconnect ist auch ein guter tip, ich hatte es tatsächlich per usb an einer Qnap angeschlosse, habe diese nun durch ein entsprechendes Netzteil ersetzt, ABER ich habe immer noch diverse disconnects
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.234: Bytes=32 Zeit=2029ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=15ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=17ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=16ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=16ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=16ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=18ms TTL=255
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 10.66.1.234: Bytes=32 Zeit=23ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=30ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=15ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=22ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=21ms TTL=255
Zeitüberschreitung der Anforderung.
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.111: Zielhost nicht erreichbar.
Antwort von 10.66.1.234: Bytes=32 Zeit=2011ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=18ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=26ms TTL=255
Antwort von 10.66.1.234: Bytes=32 Zeit=16ms TTL=255
Übrigens habe ich den kompletten reset (inkl. neuen bootloader und Firmware aufs USB-LAufwerk geschoben) durchgeführt, erkennt bei SErial direkt per usb am pc die Version...
ABER per FHEM ist das teil noch immer nicht erreichbar...
woher weiß ich dass der port 2323 der richtige ist?
muss ich da noch irgendwas draufpacken ausser die beschriebenen Bootloader und Firmware?
was mach ich falsch????? :'(
also dein define cuno CUL 10.66.1.234:2323 0000 ist schon so ok, wenn der Cube wirklich die IP 10.66.1.234 hat
Der Port 2323 ist so in der FW vorgegeben, stimmt also
K.A. warum es immer wieder vom LAN abmeldet , rebootet er dabei auch wieder ?
Du kannst aber mal seine Funktion als reines USB Device testen ohne LAN ob der dabei stabil ist oder auch Probleme macht.
Hab den mal direkt per usb angeschlossen,fhem erkennt das, wurden auch schon Devices angelegt, aber per lan geht nix, rebooten tut das teil glaub ich nicht, wären zu kurze Abstände weil 5-6x pingt dann 2-4x kein ping und ich glaub nicht dass das teil binnen rsek rebootet hat oder?
Hast du schon probiert, DHCP beim Cube abzuschalten und manuell eine IP Adresse zu setzen:
https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten (https://wiki.fhem.de/wiki/CUN_Netzwerk_einrichten)
@Wzut: Hab den ersten Post angepasst und auf die Flashanleitungen im Git verlinkt.
@Telekatz: habe den DHCP nach deiner anleitung abgeschaltet...
die Verbindung per lan ist wesentlich stabiler, keine Ping-Aussetzer mehr.... danke hierfür...
ABER FHEM verbindet sich dennoch nicht, ich kann den CUL anlegen, bekommt aber immer wieder Timeout...
2020.01.23 12:39:08 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:39:11 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:50:27 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:50:30 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:50:58 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:51:01 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:54:25 3: Opening cuno device 10.66.1.234:2323
2020.01.23 12:54:28 1: cuno: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:55:23 2: Switched cuno rfmode to MAX
dann und wann lässt sich das teil verbinden, dann bekomme ich diese Log:
2020.01.23 12:39:08 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:39:11 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:39:58 1: PERL WARNING: Found = in conditional, should be == at (eval 41584) line 1, <DATA> line 2.
2020.01.23 12:39:58 3: eval: di_WW: warning in condition c04
2020.01.23 12:44:59 1: PERL WARNING: Found = in conditional, should be == at (eval 41849) line 1, <DATA> line 2.
2020.01.23 12:44:59 3: eval: di_WW: warning in condition c04
2020.01.23 12:50:27 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:50:30 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:50:58 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:51:01 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:54:25 3: Opening cuno device 10.66.1.234:2323
2020.01.23 12:54:28 1: cuno: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:55:23 2: Switched cuno rfmode to MAX
2020.01.23 12:59:58 5: SW: V
2020.01.23 12:59:58 5: CUL/RAW (ReadAnswer): V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 12:59:58 5: SW: ?
2020.01.23 12:59:58 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
2020.01.23 12:59:58 3: cuno: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2020.01.23 12:59:58 5: SW: X21
2020.01.23 12:59:58 5: SW: Zr
2020.01.23 12:59:58 5: SW: T01
2020.01.23 12:59:58 5: CUL/RAW (ReadAnswer): 0000
2020.01.23 12:59:58 5: GOT CUL fhtid: 0000
2020.01.23 12:59:58 1: 10.66.1.234:2323 reappeared (cuno)
2020.01.23 13:00:04 5: SW: C0D
2020.01.23 13:00:04 1: 10.66.1.234:2323 disconnected, waiting to reappear (cuno)
2020.01.23 13:00:12 5: SW: V
2020.01.23 13:00:12 5: CUL/RAW (ReadAnswer): V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 13:00:12 5: SW: ?
2020.01.23 13:00:12 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
2020.01.23 13:00:12 3: cuno: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2020.01.23 13:00:12 5: SW: X21
2020.01.23 13:00:12 5: SW: Zr
2020.01.23 13:00:12 5: SW: T01
2020.01.23 13:00:12 5: CUL/RAW (ReadAnswer): 0000
2020.01.23 13:00:12 5: GOT CUL fhtid: 0000
2020.01.23 13:00:12 1: 10.66.1.234:2323 reappeared (cuno)
2020.01.23 13:00:21 5: CUL/RAW: /Z0F0C0460093D8A00000000581D2E00E7F8
2020.01.23 13:00:21 4: CUL_Parse: cuno Z0F0C0460093D8A00000000581D2E00E7F8 -78
2020.01.23 13:00:21 5: cuno: dispatch Z0F0C0460093D8A00000000581D2E00E7
2020.01.23 13:00:21 2: No CUL_MAX defined
2020.01.23 13:00:35 5: CUL/RAW: /Z0F0004601A1C2E0000000018122A00D71A
2020.01.23 13:00:35 4: CUL_Parse: cuno Z0F0004601A1C2E0000000018122A00D71A -61
2020.01.23 13:00:35 5: cuno: dispatch Z0F0004601A1C2E0000000018122A00D7
2020.01.23 13:00:35 2: No CUL_MAX defined
2020.01.23 13:01:18 5: CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 13:01:18 4: CUL_Parse: cuno V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 13:01:18 1: 10.66.1.234:2323 disconnected, waiting to reappear (cuno)
2020.01.23 13:03:21 5: SW: V
2020.01.23 13:03:21 5: CUL/RAW (ReadAnswer): V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 13:03:21 5: SW: ?
2020.01.23 13:03:21 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
2020.01.23 13:03:21 3: cuno: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2020.01.23 13:03:21 5: SW: X21
2020.01.23 13:03:21 5: SW: Zr
2020.01.23 13:03:21 5: SW: T01
2020.01.23 13:03:21 5: CUL/RAW (ReadAnswer): 0000
2020.01.23 13:03:21 5: GOT CUL fhtid: 0000
2020.01.23 13:03:21 1: 10.66.1.234:2323 reappeared (cuno)
2020.01.23 13:03:51 5: CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 13:03:51 4: CUL_Parse: cuno V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.01.23 13:03:51 1: 10.66.1.234:2323 disconnected, waiting to reappear (cuno)
2020.01.23 13:06:24 5: SW: C0D
hat zwar nichts mit deinen disconnects zu tun , aber wenn du schon den CUL im rfmode MAX betreibst solltest du auch ein entsprechendes CUL_MAX Device anlegen :)
das habe ich noch nicht weil ja keine verbindung zu stande kam... auf meiner anderen fhem instanz hab ich den angelegt, weil dort bin ich direkt per usb verbunden..
Zitat von: Michael Berger am 23 Januar 2020, 13:13:12
2020.01.23 12:39:08 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:39:11 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:50:27 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:50:30 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:50:58 3: Opening MaxCube device 10.66.1.234:2323
2020.01.23 12:51:01 1: MaxCube: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:54:25 3: Opening cuno device 10.66.1.234:2323
2020.01.23 12:54:28 1: cuno: Can't connect to 10.66.1.234:2323: Connection timed out
2020.01.23 12:55:23 2: Switched cuno rfmode to MAX
Kann es sein, dass du den Cube doppelt definiert hast? Einmal als cuno und einmal als MAXCube.
hallo, ja hatte ich zum testen...
aber jetzt nur mehr als cul..
kann mir wer sagen was der logeintrag bedeutet?
2020.01.24 08:38:06 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 7, but we need 121. Waiting 114 seconds. Currently 18 messages are waiting to be sen
habe euch viele zeilen mit
2020.01.24 08:23:43 2: There is a packet for ShutterContact MAX_0fe47a 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 mir kommt die übertragung ziemlich verzögert vor...
kann man den cube etwas beschleunigen? welche Baud-Rate sollte man verwenden bei der Definition???
@Michael Berger, jetzt wirst du hier aber eindeutig OT.
Beide Meldung sind reine MAX Themen, die sich durch lesen der MAX Doku bzw. Wiki oder MAX Unterforum leicht lösen/erklären lassen.
alles klar, dann werd ich mal recherchieren... danke
Hallo Michael,
das Problem, dass nach dem Bootloader-Flashen ein lokaler Datenträger angezeigt wurde, hatte ich auch. Nimm den Bootloader der Vorgängerversion, flashe danach aber die neueste a-culfw-version, das klappt prima und alles läuft.
Gruß Stephan
Zitat von: Stephan68 am 24 Februar 2020, 13:41:35
das Problem, dass nach dem Bootloader-Flashen ein lokaler Datenträger angezeigt wurde, hatte ich auch. Nimm den Bootloader der Vorgängerversion, flashe danach aber die neueste a-culfw-version, das klappt prima und alles läuft.
Ich sehe das eigentlich nicht als Problem. Ich finde, das erleichtert das Flashen, da die Firmware nur noch auf das neu angelegte Laufwerk kopiert werden muß.
Hallo!
Ich lese schon ein paar Tage in diesem Forum mit und habe 2 Stockwerke mit MAX Geräten. Da die Entwicklung der MAX Geräte leider hinter meiner persönlichen Erwartung geblieben ist, habe ich mich umgesehen was man mit den Produkten noch so machen kann.
FHEM hat mich überzeugt, auch wenn ich von all den Infos noch keine so richtig zuordnen kann und mich etwas erschlagen fühle. Ich wollte nun die ersten Schritte machen und meinen Reserve Cube von Max als erstes flashen. Gesagt getan, der Flashanleitung gefolgt - den Bootloader installiert, auf das USB Medium die Cube_BL.bin kopiert. Nach dem kopieren schließt sich alles, der Cube startet neu und blinkt nun nichtmehr 4x sondern nur mehr 1x pro Sekunde. Soweit so gut.
Also Cube mit LAN und Strom versorgt und hier stehe ich nun und weiß nicht weiter. Lt. meiner Fritzbox hat er per DHCP einen IP Adresse bekommen. Ich kann sie anpingen. Ich komme weder über das Webif (ip:2323/fhem bzw. ip:2323) hinein (timeout) noch über telnet oder ssh.
Ich habe die Prozedur von Anfang an wiederholt, dies hat jedoch nichts geändert. Daher meine Frage: Habe ich etwas übersehen / falsch gemacht? Hat jemand Infos für mich?
lG
Es gibt kein webif und kein ssh Zugriff. Nur 00_CUL "spricht" mit dem CUBE.
Poste mal ein list von deinem CUL Device.
OK. Danke für die Gegenfrage, ich bin offensichtlich einem Trugschluss aufgesessen. Ich dachte dass mit der Firmware gleichzeitig auch fhem installiert wird.
Ich vermute aufgrund deiner Frage daher, dass i h eine fhem Installation auf einem rasp oder einem Nas oder ähnlichem brauche und diesen anschließend erst mit dem nun geflashten Cube verbinden muss. Er ersetzt daher eigentlich einen USB Stick welcher am rasp oder Nas laufen würde. Korrekt? In der Wiki und im quick Start habe ich nur immer einen USB cul gelesen, daher dachte ich dass hier alles in einem wäre.
Mein Beitrag wäre dann hier aber eigentlich falsch. Sorry dafür. Es handelt sich eher um ein Problem dass sich 60 cm vom Bildschirm entfernt befindet 😀
Zitat von: Backdraft am 13 April 2020, 23:22:55
Er ersetzt daher eigentlich einen USB Stick welcher am rasp oder Nas laufen würde. Korrekt?
Richtig, der Vortel ist nun das du ihn aber via LAN oder USB nutzen kannst. Da du aber schreibst das es dein Reserve CUBE war, würde ich an deiner Stelle ersteinmal ganz entspannt beginnen. D.h. installiere dir FHEM auf einem Raspi oder anderem System und verwende zuerst deinen CUBE mit der original Firmware.
Siehe dazu das Wiki Stichwort MAXLAN -> https://wiki.fhem.de/wiki/MAX
Wenn du deine MAX Welt in FHEM abgebildet hast meldest dich nochmal im MAX Unterforum und du machst dann den Wechsel auf den anderen Cube.
Fhem habe ich heute bereits auf dem synoglogy Nas installiert - läuft.
Nun wollte ich mich deinem Rat folgen und habe mich direkt in den ersten Max Cube (mit der Originalsoftware) eingeloggt und siehe da: Alle Daten weg. Warum auch immer und seit wann auch immer, es ist nur eine weitere Bestätigung von dieser Software wegzukommen.
Meine Idee ist nun, dass ich gleich in FHEM beginne und jeden Raum einzeln neu anlerne. Oder denkst du ist es besser den Originalcube nochmal mit allen Geräten erneut zu füttern?
Danke jedenfalls für deine Hilfe
TIPP : geh den leichten Weg (wie von mir beschrieben) , aber frage bitte im richtigen Unterforum :) hier ist das OT
Hallo Gemeinde
Ich habe jetzt 1 woche versucht meinen Max Cube zu flashen(a-culfw_1.26.08_build_324), einen CC1101 433MHz anzulöten, und die Ganze Geschichte in Fhem einzubinden.
Ich finde auch beide CUL, sowohl bei der Konfiguration mit USB, als auch über LAN.
Allerdings empfange ich keine Signale. kann mir da jemand helfen????
angelötet ist so
CUBE oben CC1101
PA 5 = blau GD02
PA 6 = braun CSN
PB25 = orange GD00
GND = transparent Gnd
VCC = rosa Vcc
Cube unten
MOSI = gelb Mosi
SCK = grau Sck
MISO = schwarz Miso
Vermutlich hab ich da Probleme mit der Board.H wie bekomme ich die ins System???
//Internal Transceiver
#define CC1100_0_CS_PIN 12
#define CC1100_0_CS_BASE AT91C_BASE_PIOA
#define CC1100_0_OUT_PIN 30
#define CC1100_0_OUT_BASE AT91C_BASE_PIOA
#define CC1100_0_IN_PIN 25
#define CC1100_0_IN_BASE AT91C_BASE_PIOA
//External Transceivers
//PORT 1
#define CC1100_1_CS_PIN 6
#define CC1100_1_CS_BASE AT91C_BASE_PIOA
#define CC1100_1_OUT_PIN 25 #hier habe ich aus 28 25 gemacht
#define CC1100_1_OUT_BASE AT91C_BASE_PIOB
#define CC1100_1_IN_PIN 5
#define CC1100_1_IN_BASE AT91C_BASE_PIOA
Die Board.h habe ich in den Ordner auf den CUBE geschoben, danach die CUBEx4_BL.bin.
der CUBE ist neu gestartet, und wurde nach dem Anschuss, an den Pi, und Neustart erkannt.
So sieht es nach einen Neustart aus!
2020.04.19 16:36:39 1: Including fhem.cfg
2020.04.19 16:36:40 3: WEB: port 8083 opened
2020.04.19 16:36:40 3: WEBtablet: port 8085 opened
2020.04.19 16:36:40 2: eventTypes: loaded 493 events from ./log/eventTypes.txt
2020.04.19 16:36:40 3: Opening CUL_0 device /dev/ttyACM0
2020.04.19 16:36:40 3: Setting CUL_0 serial parameters to 9600,8,N,1
2020.04.19 16:36:40 3: CUL_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2020.04.19 16:36:40 3: CUL_0 device opened
2020.04.19 16:36:40 2: Switched CUL_0 rfmode to MAX
2020.04.19 16:36:40 3: CUL_MAX_Check: Detected firmware version 154 of the CUL-compatible IODev
2020.04.19 16:36:40 3: Opening CUL433 device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2020.04.19 16:36:40 3: Setting CUL433 serial parameters to 38400,8,N,1
2020.04.19 16:36:43 3: CUL433: Possible commands: ABCEeFfGiKLlMmRTtUuVWXxY
2020.04.19 16:36:43 3: CUL433 device opened
2020.04.19 16:36:43 3: Opening CUBe_1 device /dev/ttyACM1
2020.04.19 16:36:43 3: Setting CUBe_1 serial parameters to 9600,8,N,1
2020.04.19 16:36:44 3: CUBe_1: Possible commands: ABbCeFGhiKkLlMmNRTtUuVWXxYZ
2020.04.19 16:36:44 3: CUBe_1 device opened
2020.04.19 16:36:44 2: Switched CUBe_1 rfmode to MAX
2020.04.19 16:36:53 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2020.04.19 16:36:53 3: Registering HTTPSRV TABLETUI for URL /ftui and assigned link ftui/ ...
2020.04.19 16:36:53 1: Including ./log/fhem.save
2020.04.19 16:36:58 2: AttrTemplates: got 155 entries
So sieht di fhem.cfg aus!
#######################################################################
########_MAXCUBe_Umbau_USB_##########
########_F-Band: 868MHz_##########
define CUBe_1 CUL /dev/ttyACM1@9600 1134
setuuid CUBe_1 5e993dfc-f33f-9f68-ba4c-dc50599dae0ac4e1
attr CUBe_1 rfmode MAX
attr CUBe_1 room System
########_CUBe_433MHz_##########
define CUBe_2 STACKABLE_CC CUBe_1
setuuid CUBe_2 5e9b18b1-f33f-9f68-0fc3-e3125d6ddd7aee79
attr CUBe_2 room System
#######################################################################
##########_MAXCUBe an Lan_######
########_F-Band: 868MHz_##########
#define CUBe_LAN CUL 192.168.2.117:2323 1234
#setuuid CUBe_LAN 5e996c37-f33f-9f68-6721-5af4d1fc17b8e0df
#attr CUBe_LAN rfmode MAX
#attr CUBe_LAN room System
########_CUBe_433MHz_##########
#define CUBe_LAN_2 STACKABLE_CC CUBe_LAN
#setuuid CUBe_LAN_2 5e9991de-f33f-9f68-249d-e5795d537c3c1cc7
#attr CUBe_LAN_2 room System
#######################################################################
Kann mir einer sagen wo mein Fehler liegt.
Gruß Arno
Hi,
die board.h wird beim kompilieren verwendet!
Die muss nicht auf das IsB Laufwerk kopiert werden, sondern ist quasi in der BIN schon verarbeitet. Also wenn Du etwas in det Board.h ändern willst, dann musst Du danach neu kompilieren.
Bist Du sicher, dass dies überhaupt nötig ist?
Versuche dich erstmal ein fertiges Image von mediafire:
http://www.mediafire.com/file/cfqrqde91k7shsp/a-culfw_1.26.08_build_324.zip/file
Und dann halt die bin aus dem Ordner des CUBE.
Gruß Arnd
Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Da der OUT_PIN nur zum Senden gebraucht wird, liegt das Problem beim Empfangen nicht an einer geänderten board.h.
Was kommt bei "get CUBe_2 ccconf" zurück?
Hallo Telekatz
Timeout reading answer for get C0D
Gruß Arno
Hallo Telekatz
komicherweise springt die Version Des CUBe_1 auf
CUL
VERSION
V 1.67 CUL868
Wenn ich den Pi neu starte bekommt der CUBe_1
VERSION
V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBEx4_83 (F-Band: 868MHz)
und der CUBe_2
VERSIOn
V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBEx4_83 (F-Band: 433MHz)
get CUBe_2 ccconf erhät die Antwort : CUBe_2 ccconf => freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
Setze mal mit "set CUBe_1 raw e" den Speicher zurück.
Scheint alles zu funktionieren :D :D
Super Danke!!!
Dann werde ich das morgen mal via LAN versuchen.
ZitatDa der OUT_PIN nur zum Senden gebraucht wird, liegt das Problem beim Empfangen nicht an einer geänderten board.h.
Wenn du mir noch sagen könntest, wo auf der Platiene ich den OUT_PIN anschließen kann, wäre ich dir dankbar ;) ;)
Gruß Arno
Den habe ich direkt am Controller angeschlossen: https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711 (https://forum.fhem.de/index.php/topic,38404.msg684711.html#msg684711)
Ich habs befürchtet.
son feinen Lötkolben hab ich nicht. :-[
@ahtdf wenn du nur einen weiteren Transceiver anschließen möchtest, dann solltest du noch ausreichend Pins vom 3. und 4. Modul übrig haben.
Du musst die board.h nur entsprechend umbauen, z.B. so
//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 24
#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 22
#define CC1100_3_CS_BASE AT91C_BASE_PIOB
#define CC1100_3_OUT_PIN 20
#define CC1100_3_OUT_BASE AT91C_BASE_PIOB
#define CC1100_3_IN_PIN 28
#define CC1100_3_IN_BASE AT91C_BASE_PIOB
@adn77 wenn das so einfach wäre :-\
Ich suche noch einen der mir die CUBexxxx.bin genau so kompiliert. ;D ;D
Ist es möglich zwei Verbindungen über Lan an den Cube aufzubauen?
Bräuchte es einmal für FHEM und CuxD
Hallo zusammen.
Ich versuche nun schon seit einigen Stunden die a-culfw für meinen CUBe zu kompilieren.
RaspberryPi 3 B
Raspbian Buster
apt-get update & upgrade durchgeführt
Habe mich anfangs an diese Anleitung (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html) gehalten, der Kompiler bricht aber immer wieder mit folgendem Fehler ab:
/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[1]: *** [Makefile:125: CUBE_BL.elf] Error 1
make[1]: Leaving directory '/home/pi/a-culfw/culfw/Devices/CUBe'
make: *** [Makefile:97: CUBE_BL] Error 2
Hat jemand eine Ahnung, wie ich das beheben kann?
Nachdem der Fehler auftrat, habe ich die unveränderte culfw geladen, um zuerst das Original zu kompilieren. Auch hier tritt der Fehler auf.
Auch ohne die Makefile.local bleibt der Fehler bestehen.
Ich habe des öfterern von "-funwind-tables" gelesen, um diesen Konflikt zu lösen. Komme hier aber nicht weiter.
Nimm eine ältere GCC Version. Die letzte funktionierende Version ist 6.2.1.
Danke für deine Schnelle Antwort.
Das GCC Release 6.2.0 aus 2016 konnte ich leider noch nicht finden. Aber trotz Deinstallation der aktuellen Version von gcc tritt der Fehler noch auf. Wird in diesem Fall nicht "arm-none-eabi-gcc" genutzt?
#edit arm-none-eabi-gcc 6.2.1 habe ich nun auch gefunden. laufen tut es noch nicht.
Gruß
Jörn
Hast du vor dem erstellen mit 6.2.1 ein make clean gemacht? Ansonsten schauen, ob du eine noch ältere Version findest, z.B 5.4.
Nabend.
Ja, habe jedes mal vorher ein make clean ausgeführt.
Aktuell habe ich arm-none-eabi-gcc in Version 5.3.1, 5.4.2 und 5.4.3 in /usr/lib/arm-none-eabi/ liegen, die a-culfw liegt in /usr/lib/a-culfw/culfw/
Er bricht mit folgender Fehlermeldung ab:
make OUTPUT=CUBE_BL LINK=CUBE_BL target
make[1]: Entering directory '/usr/lib/a-culfw/culfw/Devices/CUBe'
/usr/lib/arm-none-eabi/5.4.3/bin/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
/usr/lib/arm-none-eabi/5.4.3/bin/arm-none-eabi-gcc: 1: /usr/lib/arm-none-eabi/5.4.3/bin/arm-none-eabi-gcc: Syntax error: word unexpected (expecting ")")
make[1]: *** [Makefile:129: ../../at91lib/board_cstartup.o] Error 2
make[1]: Leaving directory '/usr/lib/a-culfw/culfw/Devices/CUBe'
make: *** [Makefile:97: CUBE_BL] Error 2
Im Makefile.local steht folgendes:
ARMBASE = /usr/lib/arm-none-eabi/5.4.3
INCLUDEPATH = $(ARMBASE)/include
LIBPATH = $(ARMBASE)/lib
TOOLPREFIX = arm-none-eabi-
ARMPATH = $(ARMBASE)/bin/
Bis hierher bin ich mit google gekommen, nun verlässt mich mein gefährliches Halbwissen langsam.
Die a-culfw ist unverändert von github.
#edit:
Die besagten compiler habe ich HIER (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads) heruntergeladen.
Probierst du es immer noch auf dem RaspberryPi?
Ja.
Nimm einen PC. Zu deiner Fehlermeldung finde ich Beiträge, die darauf hindeuten, dass dein GCC nicht auf dem RaspberryPi lauffähig ist.
Ok, vielen Dank für den Hinweis.
Also noch einmal von vorne. ::) Dummy Frage: Besser Ubuntu VM aufsetzen, oder unter Windows? Unter Linux habe ich immerhin mittlerweile eine leichte Ahnung, wie es geht.
Wenn auf deinem PC Windows läuft, dann würde ich auch eine Windows GCC Version nehmen. Wozu der Umweg über eine VM?
Hallo Forum,
ich versuche gerade einen Cube zu flashen. Leider scheitert es schon am Anfang. Nach dem löschen wird von Windows10 kein neues USB Gerät erkannt.
Ich habe noch nicht alle Post's in diesem Thread durch. Kann mir jemand helfen? Muss ich einen Treiber installieren?
Gruß
Thomas
EDIT: sorry, nach neustart wurde es erkannt...
Zitat von: Telekatz am 02 Oktober 2020, 17:22:32
Wenn auf deinem PC Windows läuft, dann würde ich auch eine Windows GCC Version nehmen. Wozu der Umweg über eine VM?
Umweg über VM, weil ich mir gerade alles angelesen habe um es auf dem PI hinzubekommen. Unter win10 bin ich wieder gescheitert, alleine schon daran die Fehlermeldungen zu entziffern...
Habe kurz VMBox geladen, eine Ubuntu light VM aufgesetzt, die Abhängigkeiten installiert und siehe da, es scheint zu funktionieren. Mit aktuellem gcc-none-eabi... konnte ich ohne weiteres kompilieren. Läuft nun schon ein paar Tage auf meinem Cube.
Vielen Dank für deine Tips, ich würde wohl noch immer an meinem RasPi verzweifeln.
Hallo zusammen,
ich habe meinen Max Cube gestern erfolgreich mit der culfw geflasht und über LAN in FHEM (wie einen CUN) eingebunden. Ich wollte ihn als zusätzliches IO Device neben meinen HM-CFG-LAN und einem CUL-USB in meine VCCU einbinden.
Obwohl es in der IOList der VCCU eingetragen ist, schreibt mir das neue Device jetzt allerdings mein log mit "Unknown code A06739703900BAA, help me!" Nachrichten und etlichen anderen Device-IDs voll. Das sind die HM-Devices von meinem Nachbarn, die aber eigentlich alle bereits in der VVCU als unknown bekannt sind.
Kann mir jemand einen Tipp geben wo das Problem liegen könnte? Kann der geflashte Max Cube überhaupt als IO Device in die VCCU eingebunden werden? Ist es normal, dass das Device nur den state "Initialized" hat und nicht wie z.B. ein HM-CFG-LAN den state "opened"?
Hier ein list des Max Cube CUL...
Internals:
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
CUN1_MSGCNT 2127
CUN1_TIME 2020-11-10 15:39:07
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 192.168.1.36:2323 5468
DeviceName 192.168.1.36:2323
FD 78
FHTID 5468
FUUID 5fa9abda-f33f-799c-2f7a-3f8bff1e432536be
NAME CUN1
NR 1267
NR_CMD_LAST_H 20
PARTIAL
RAWMSG A0FBC861063910D0000000A88EA10000044
RSSI -40
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) 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 ^\*
M:TSSTACKED ^\*
N:STACKABLE ^\*
READINGS:
2020-11-09 21:54:05 ccconf freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
2020-11-10 13:43: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
2020-11-10 15:39:07 state Initialized
2020-11-09 21:53:51 version V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
XMIT_TIME:
1605016176.49944
1605016493.21963
1605016504.59396
1605016636.66399
1605016670.58769
1605017047.196
1605017072.34441
1605017179.67339
1605017222.48891
1605017263.80427
1605017381.83501
1605017423.52219
1605017502.67909
1605017626.19909
1605017662.08871
1605017868.32209
1605017904.11819
1605018099.39355
1605018100.31245
1605018788.70074
helper:
25F0CE:
QUEUE:
490C8B:
QUEUE:
529089:
QUEUE:
52C319:
QUEUE:
550FF6:
QUEUE:
582097:
QUEUE:
5CFF2E:
QUEUE:
5CFF62:
QUEUE:
5F5BB2:
QUEUE:
5F917E:
QUEUE:
68D3FB:
QUEUE:
Attributes:
group Gateways
hmId 37A111
rfmode HomeMatic
room Server
...und eines der VCCU:
nternals:
CUN1_MSGCNT 708
CUN1_RAWMSG A12120083900BAAF00001000543BF37FE28F24D::-64:CUN1
CUN1_RSSI -64
CUN1_TIME 2020-11-10 15:39:48
DEF 37A111
FUUID 5c5ee43e-f33f-799c-a1f6-f3ed5a8775f08a34
HMLAN1_MSGCNT 429
HMLAN1_RAWMSG E900BAA,0000,AD38D910,FF,FFBC,120083900BAAF00001000543BF37FE28F24D
HMLAN1_RSSI -68
HMLAN1_TIME 2020-11-10 15:39:48
HMLAN2_MSGCNT 455
HMLAN2_RAWMSG E900BAA,0000,0A7D1837,FF,FFAD,120083900BAAF00001000543BF37FE28F24D
HMLAN2_RSSI -83
HMLAN2_TIME 2020-11-10 15:39:48
IODev HMLAN1
LASTInputDev CUN1
MSGCNT 1592
NAME VCCU
NOTIFYDEV global
NR 35
NTFY_ORDER 50-VCCU
STATE HMLAN1:ok,HMLAN2:ok,CUL_USB:disconnected,CUN1:ok
TYPE CUL_HM
assignedIOs CUL_USB,CUN1,HMLAN1,HMLAN2
chanNo 01
lastMsg No:DC - t:02 s:37A111 d:5D011C 00
protLastRcv 2020-11-10 15:37:50
protRcv 228 last_at:2020-11-10 15:37:50
protRcvB 1 last_at:2020-11-10 13:45:03
rssi_at_CUN1 cnt:184 min:-95.5 max:-36.5 avg:-58.25 lst:-37
rssi_at_HMLAN1 cnt:70 min:-84 max:-66 avg:-72.45 lst:-75
rssi_at_HMLAN2 cnt:129 min:-77 max:-41 avg:-70.44 lst:-42
READINGS:
2020-11-10 15:37:50 CommandAccepted yes
2020-11-10 13:44:02 IOopen 3
2020-11-09 21:56:05 cfgState ok
2020-11-10 15:21:39 recentStateType ack
2020-11-10 13:44:02 state HMLAN1:ok,HMLAN2:ok,CUL_USB:disconnected,CUN1:ok
2020-03-23 19:12:02 unknown_00137A received
2020-02-15 17:08:39 unknown_00257B received
2019-06-26 10:26:25 unknown_052992 received
2020-02-17 09:10:13 unknown_08380A received
2019-09-22 16:59:55 unknown_0D117E received
[gekürzt -> insgesamt ca. 70 Zeilen/Devices]
2020-02-15 10:47:44 unknown_F4C861 received
2020-06-16 11:01:16 unknown_F7BE4F received
2020-02-15 07:07:33 unknown_F7E861 received
helper:
HM_CMDNR 220
PONtest 1
peerFriend peerSD,peerSens,peerAct
peerOpt -:virtual
regLst 0
rxType 1
supp_Pair_Rep 0
ack:
cmds:
TmplKey :no:1605012239.89592
TmplTs 1605012239.89592
cmdKey 1:1:1::VCCU::01:
cmdLst:
assignHmKey noArg
assignIO -IO- [({set}|unset)]
clear [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
defIgnUnknown noArg
deviceRename -newName-
fwUpdate -filename- [-bootTime-]
getDevInfo noArg
hmPairForSec [-sec-]
hmPairSerial -serial-
peerChan -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
peerSmart -peerOpt-
postEvent -condition-
press [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
pressL [(-peer-|{all})]
pressS [(-peer-|{all})]
raw -data- [...]
reset noArg
tplSet_0 -tplChan-
unpair noArg
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt [gekürzt -> alle meine HM-Devices werden gelistet]
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
listDevice noArg
param -param-
expert:
def 1
det 0
raw 0
tpl 0
io:
nextSend 1605019070.30245
prefIO
vccu VCCU
ioList:
HMLAN1
HMLAN2
CUL_USB
CUN1
mRssi:
mNo DC
io:
CUN1:
-37
-37
HMLAN1:
HMLAN2:
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
vrt 1
rssi:
at_CUN1:
avg -58.2554347826087
cnt 184
lst -37
max -36.5
min -95.5
at_HMLAN1:
avg -72.4571428571428
cnt 70
lst -75
max -66
min -84
at_HMLAN2:
avg -70.4418604651163
cnt 129
lst -42
max -41
min -77
tmpl:
Attributes:
IODev HMLAN1
IOList HMLAN1,HMLAN2,CUL_USB,CUN1
IOgrp VCCU
group Gateways
model CCU-FHEM
room Server
subType virtual
webCmd virtual:update
Viele Grüße
Slanesh
P.S. Der CUL_USB steckt gerade nicht, dürfte für dieses Problem aber keine Rolle spielen.
Zitat von: Slanesh am 10 November 2020, 15:52:27
Kann der geflashte Max Cube überhaupt als IO Device in die VCCU eingebunden werden?
Ist es normal, dass das Device nur den state "Initialized" hat und nicht wie z.B. ein HM-CFG-LAN den state "opened"?
ja & ja
Hallo zusammen,
ich habe einen MAX Cube geflashed auf MAX_CUL zusammen mit 13 Thermostaten und 2 Wandthermostaten im Einsatz. MAX Scanner läuft mit 30 Min Intervall. Bis vor einigen Tagen hat alles gut funktioniert.
Leider passiert es nun ständig, dass Nachrichten vom MAX_CUL nicht mehr von den Thermostaten quittiert werden. Die Nachrichten kommen aber an und die die Einstellungen werden übernommen. Der MAX_CUL versucht aber immer wieder die Nachricht neu zu versenden und verbraucht dazu Credits.
Wenn ich Verbindung zum MAX CUL mit "reopen" unterbreche und neu öffne, dann werden kurzeitig wieder Nachrichten quittiert und von den Thermostaten empfangen. Nach kurzer Zeit allerdings tritt wieder der gleiche Fehler auf:
2020.11.11 00:19:16 4: CUL_Parse: MAXCUL V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.11 00:19:21 5: SW: X
2020.11.11 00:19:21 5: CUL/RAW (ReadAnswer): 21 3600
2020.11.11 00:19:21 3: get MAXCUL credit10ms : MAXCUL credit10ms => 3600
2020.11.11 00:19:51 5: CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.11 00:19:51 4: CUL_Parse: MAXCUL V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.11 00:20:02 3: get HwcSum HwcSum : HwcSum 669360149
2020.11.11 00:20:03 3: get HwcCount HwcCount : HwcCount 1242732
2020.11.11 00:20:03 3: get HcSum HcSum : HcSum 220377100
2020.11.11 00:20:03 3: get HcCount HcCount : HcCount 1015460
2020.11.11 00:20:21 5: CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.11 00:20:21 4: CUL_Parse: MAXCUL V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.11 00:20:40 5: CUL_MAX_BroadcastTime: payload 140b0094e8
2020.11.11 00:20:40 5: Broadcast time to 13ff01
2020.11.11 00:20:40 5: CUL_MAX_Send: enqueuing 0f31040312345613ff0100140b0094e8
2020.11.11 00:20:40 5: CUL_MAX_SendQueueHandler: 1 items in queue
2020.11.11 00:20:40 5: SW: X
2020.11.11 00:20:40 5: CUL/RAW (ReadAnswer): 21 3600
2020.11.11 00:20:40 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 3600
2020.11.11 00:20:40 5: Updating TimeInformation payload
2020.11.11 00:20:40 5: MAXCUL sending Zs0f31040312345613ff0100140b0094e8
2020.11.11 00:20:40 5: SW: Zs0f31040312345613ff0100140b0094e8
2020.11.11 00:20:40 5: Broadcast time to 1408a3
2020.11.11 00:20:40 5: CUL_MAX_Send: enqueuing 0f9504031234561408a300140b0094e8
2020.11.11 00:20:40 5: Broadcast time to 1863e1
2020.11.11 00:20:40 5: CUL_MAX_Send: enqueuing 0f0304031234561863e100140b0094e8
2020.11.11 00:20:41 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:41 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:42 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:42 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:43 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:43 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:44 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:44 5: CUL_MAX_SendQueueHandler: Retry 13ff01 for 0f31040312345613ff0100140b0094e8 count: 3
2020.11.11 00:20:47 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:47 5: SW: X
2020.11.11 00:20:47 5: CUL/RAW (ReadAnswer): 21 3494
2020.11.11 00:20:47 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 3494
2020.11.11 00:20:47 5: Updating TimeInformation payload
2020.11.11 00:20:47 5: MAXCUL sending Zs0f31040312345613ff0100140b0094ef
2020.11.11 00:20:47 5: SW: Zs0f31040312345613ff0100140b0094ef
2020.11.11 00:20:47 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:48 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:48 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:49 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:49 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:50 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:50 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:50 5: CUL_MAX_SendQueueHandler: Retry 13ff01 for 0f31040312345613ff0100140b0094ef count: 2
2020.11.11 00:20:53 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:53 5: SW: X
2020.11.11 00:20:53 5: CUL/RAW (ReadAnswer): 21 3388
2020.11.11 00:20:53 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 3388
2020.11.11 00:20:53 5: Updating TimeInformation payload
2020.11.11 00:20:53 5: MAXCUL sending Zs0f31040312345613ff0100140b0094f5
2020.11.11 00:20:53 5: SW: Zs0f31040312345613ff0100140b0094f5
2020.11.11 00:20:54 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:54 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:55 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:55 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:56 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:56 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:56 5: CUL_MAX_SendQueueHandler: Retry 13ff01 for 0f31040312345613ff0100140b0094f5 count: 1
2020.11.11 00:20:57 5: SW: X
2020.11.11 00:20:57 5: CUL/RAW (ReadAnswer): 21 3279
2020.11.11 00:20:57 3: get MAXCUL credit10ms : MAXCUL credit10ms => 3279
2020.11.11 00:20:59 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:20:59 5: SW: X
2020.11.11 00:20:59 5: CUL/RAW (ReadAnswer): 21 3281
2020.11.11 00:21:00 5: needPreamble: 1, necessaryCredit: 113, credit10ms: 3281
2020.11.11 00:21:00 5: Updating TimeInformation payload
2020.11.11 00:21:00 5: MAXCUL sending Zs0f31040312345613ff0100140b0095c0
2020.11.11 00:21:00 5: SW: Zs0f31040312345613ff0100140b0095c0
2020.11.11 00:21:00 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:21:00 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:21:01 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:21:01 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:21:02 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:21:03 5: CUL_MAX_SendQueueHandler: 3 items in queue
2020.11.11 00:21:03 2: CUL_MAX_SendQueueHandler: Missing ack from 13ff01 for 0f31040312345613ff0100140b0095c0
2020.11.11 00:21:04 5: SW: V
Zusätzlich habe ich noch ein Problem mit dem Cube. Er stürzt regelmäßig ab:
2020.11.12 22:29:10 4 : CUL_Parse: MAXCUL V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:29:10 5 : CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:29:17 4 : CUL_Parse: MAXCUL Z0C1C04421863E11A28C80022C63A -45
2020.11.12 22:29:17 5 : MAXCUL: dispatch Z0C1C04421863E11A28C80022C6
2020.11.12 22:29:17 5 : MAX, IODev MAXCUL, len 12, msgcnt 1C, msgflag 04, msgType WallThermostatControl, src 1863e1, dst 1a28c8, group 0, payload 22C6, rssi -45
2020.11.12 22:29:17 5 : MAX: dispatch MAX,0,WallThermostatControl,1863e1,22C6
2020.11.12 22:29:17 5 : MAX_Parse, MAX,0,WallThermostatControl,1863e1,22C6
2020.11.12 22:29:17 5 : WT_Kueche, desiredTemperature : 17, temperature : 19.8
2020.11.12 22:29:17 4 : CUL_Parse: MAXCUL Z0E1C02021A28C81863E1000118002211 -65.5
2020.11.12 22:29:17 5 : MAXCUL: dispatch Z0E1C02021A28C81863E10001180022
2020.11.12 22:29:17 5 : MAX, IODev MAXCUL, len 14, msgcnt 1C, msgflag 02, msgType Ack, src 1a28c8, dst 1863e1, group 0, payload 01180022, rssi -65.5
2020.11.12 22:29:17 4 : MAX, ACK from HZ_Kueche to WT_Kueche
2020.11.12 22:29:17 5 : MAX: dispatch MAX,0,Ack,1a28c8,01180022
2020.11.12 22:29:17 5 : MAX_Parse, MAX,0,Ack,1a28c8,01180022
2020.11.12 22:29:17 5 : MAX_Parse, MAX2,0,ThermostatState,1a28c8,180022
2020.11.12 22:29:17 5 : CUL/RAW: /Z0C1C04421863E11A28C80022C63A Z0E1C02021A28C81863E1000118002211 </div>2020-11-12 22:29:17 CUL_MAX MAX MAXCUL:ok
2020-11-12 22:29:17 MAX HZ_Kueche RSSI: -65.5
2020-11-12 22:29:17 CUL_MAX MAX MAXCUL:ok
2020.11.12 22:29:43 4 : CUL_Parse: MAXCUL Z0F0004601408A30000000018082A00D403 -72.5
2020.11.12 22:29:43 5 : MAXCUL: dispatch Z0F0004601408A30000000018082A00D4
2020.11.12 22:29:43 5 : MAX, IODev MAXCUL, len 15, msgcnt 00, msgflag 04, msgType ThermostatState, src 1408a3, dst 000000, group 0, payload 18082A00D4, rssi -72.5
2020.11.12 22:29:43 5 : MAX: dispatch MAX,0,ThermostatState,1408a3,18082A00D4
2020.11.12 22:29:43 5 : MAX_Parse, MAX,0,ThermostatState,1408a3,18082A00D4
2020.11.12 22:29:43 5 : CUL/RAW: /Z0F0004601408A30000000018082A00D403 </div>2020-11-12 22:29:43 MAX HZ_Gabriele temperature: 21.2
2020-11-12 22:29:43 MAX HZ_Gabriele deviation: 0.2
2020-11-12 22:29:43 MAX HZ_Gabriele RSSI: -72.5
2020-11-12 22:29:43 CUL_MAX MAX MAXCUL:ok
2020.11.12 22:30:07 5 : SW: X
2020.11.12 22:30:07 4 : CUL_Parse: MAXCUL ? (? (? (? (ђ���r҇���}O U�Y R T V W X e f h l t x z����X 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
2020.11.12 22:30:07 5 : MAXCUL: dispatch ? (? (? (? (\021ђ���r\032҇���}O U�Y R T V W X e f h l t x z����X 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
2020.11.12 22:30:07 3 : MAXCUL: Unknown code ? (? (? (? (ђ���r҇���}O U�Y R T V W X e f h l t x z����X 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, help me!
2020.11.12 22:30:10 1 : 192.168.178.39:2323 disconnected, waiting to reappear (MAXCUL)
2020.11.12 22:30:10 3 : get MAXCUL credit10ms : MAXCUL credit10ms => No answer
2020.11.12 22:30:07 5 : CUL/RAW (ReadAnswer): ? (? (? (? (ђ���r҇���}O U�Y R T V W X e f h l t x z����X 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 </div>2020-11-12 22:30:07 CUL MAXCUL UNKNOWNCODE ? (? (? (? (ђ���r҇���}O U�Y R T V W X e f h l t x z����X 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
2020-11-12 22:30:10 CUL MAXCUL DISCONNECTED
2020-11-12 22:30:10 dummy MAX_dutycycle 100
2020-11-12 22:30:10 CUL_MAX MAX dutycycle: 100
2020-11-12 22:30:10 dummy Jahreszeit MAXUmstellenSO: 0
2020-11-12 22:30:10 dummy Jahreszeit MAXUmstellenUG: 0
2020-11-12 22:30:10 dummy Jahreszeit MAXUmstellenWI: 0
2020-11-12 22:30:10 dummy Jahreszeit MAXUmstellenWK: 0
2020-11-12 22:30:10 dummy Jahreszeit MAXUmstellenUG: 100
2020-11-12 22:30:10 CUL MAXCUL credit10ms: No answer
2020-11-12 22:30:10 at MAXGetCredit Next: 22:31:43
2020.11.12 22:30:10 5 : SW: V
2020.11.12 22:30:10 5 : SW: ?
2020.11.12 22:30:10 3 : MAXCUL: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz
2020.11.12 22:30:10 5 : SW: X21
2020.11.12 22:30:10 5 : SW: Zr
2020.11.12 22:30:10 5 : SW: Za123456
2020.11.12 22:30:10 5 : SW: Zw111111
2020.11.12 22:30:10 5 : SW: T01
2020.11.12 22:30:10 5 : GOT CUL fhtid: 1234
2020.11.12 22:30:10 1 : 192.168.178.39:2323 reappeared (MAXCUL)
2020.11.12 22:30:10 5 : CUL/RAW (ReadAnswer): V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:30:10 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 </div>2020-11-12 22:30:10 CUL MAXCUL 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
2020.11.12 22:30:10 5 : CUL/RAW (ReadAnswer): 1234 </div>2020-11-12 22:30:10 CUL MAXCUL Initialized
2020-11-12 22:30:10 CUL MAXCUL CONNECTED
2020.11.12 22:30:41 4 : CUL_Parse: MAXCUL V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:30:41 5 : CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:31:11 4 : CUL_Parse: MAXCUL V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:31:11 5 : CUL/RAW: /V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
2020.11.12 22:31:36 4 : CUL_Parse: MAXCUL Z0CE804421C07991408A3002AD429 -53.5
2020.11.12 22:31:36 5 : MAXCUL: dispatch Z0CE804421C07991408A3002AD4
2020.11.12 22:31:36 5 : MAX, IODev MAXCUL, len 12, msgcnt E8, msgflag 04, msgType WallThermostatControl, src 1c0799, dst 1408a3, group 0, payload 2AD4, rssi -53.5
2020.11.12 22:31:36 5 : MAX: dispatch MAX,0,WallThermostatControl,1c0799,2AD4
2020.11.12 22:31:36 5 : MAX_Parse, MAX,0,WallThermostatControl,1c0799,2AD4
2020.11.12 22:31:36 5 : WT_Gabriele, desiredTemperature : 21, temperature : 21.2
2020.11.12 22:31:36 4 : CUL_Parse: MAXCUL Z0EE802021408A31C0799000118002A04 -72
2020.11.12 22:31:36 5 : MAXCUL: dispatch Z0EE802021408A31C0799000118002A
2020.11.12 22:31:36 5 : MAX, IODev MAXCUL, len 14, msgcnt E8, msgflag 02, msgType Ack, src 1408a3, dst 1c0799, group 0, payload 0118002A, rssi -72
2020.11.12 22:31:36 4 : MAX, ACK from HZ_Gabriele to WT_Gabriele
2020.11.12 22:31:36 5 : MAX: dispatch MAX,0,Ack,1408a3,0118002A
2020.11.12 22:31:36 5 : MAX_Parse, MAX,0,Ack,1408a3,0118002A
2020.11.12 22:31:36 5 : MAX_Parse, MAX2,0,ThermostatState,1408a3,18002A
2020.11.12 22:31:36 5 : CUL/RAW: /Z0CE804421C07991408A3002AD429 Z0EE802021408A31C0799000118002A04 </div>2020-11-12 22:31:36 MAX WT_Gabriele RSSI: -53.5
2020-11-12 22:31:36 CUL_MAX MAX MAXCUL:ok
2020-11-12 22:31:36 MAX HZ_Gabriele valveposition: 0
2020-11-12 22:31:36 MAX HZ_Gabriele RSSI: -72
2020-11-12 22:31:36 CUL_MAX MAX MAXCUL:ok
2020.11.12 22:31:43 5 : SW: X
2020.11.12 22:31:43 5 : CUL/RAW (ReadAnswer): ? (? (r*Z:jZb*2Bb���5 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��Ii�TV W X e f h l t x z 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 ��aX is unknown) Use one of B b C F i A Z N E k G
2020.11.12 22:31:43 4 : CUL_Parse: MAXCUL ? (? (r*Z:jZb*2Bb���5 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��Ii�TV W X e f h l t x z 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 ��aX 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
2020.11.12 22:31:43 5 : MAXCUL: dispatch ? (? (\005r*Z:jZb\005\005\005\005\005\005\005*2Bb���5 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��Ii�TV W X e f h l t x z 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 ��aX 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
2020.11.12 22:31:43 3 : MAXCUL: Unknown code ? (? (r*Z:jZb*2Bb���5 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��Ii�TV W X e f h l t x z 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 ��aX 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, help me!
2020.11.12 22:31:46 1 : 192.168.178.39:2323 disconnected, waiting to reappear (MAXCUL)
2020.11.12 22:31:46 3 : get MAXCUL credit10ms : MAXCUL credit10ms => No answer
2020.11.12 22:31:43 5 : CUL/RAW (ReadAnswer): M K L U Y R T V W X e f h l t x z </div>2020-11-12 22:31:43 CUL MAXCUL UNKNOWNCODE ? (? (r*Z:jZb*2Bb���5 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��Ii�TV W X e f h l t x z 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 ��aX 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
2020-11-12 22:31:46 CUL MAXCUL DISCONNECTED
Kann mir hier jemand weiterhelfen? Ist die eventuell die Hardware des Cube defekt? Ich habe noch einen zweiten Cube mit MAX Software drauf. Ich werde den mal flashen und testen.
Grüße, Stefan
Ich habe jetzt den Cube getauscht. Das Problem ist seitdem nicht mehr aufgetreten. :)
Hi zusammen,
ich bekomme einfach keine IP.
Hab den Cube geflasht und nun blinkt die Power LED jede Sekunde.
Stecke ich das Lan Kabel in die Fritzbox leuchtet INTERNET.
Aber in der Fritzbox sehe ich kein Gerät das an LAN angeschlossen ist.
Hab schon sämtliche Kabel probiert und den Cube schon etliche male neu geflasht.
Hat noch jemand nen Tipp ?
Gruß
N3M3SIS
Moin
@N3m3sis
Ich mag mich erinnern, dass man LAN irgendwie freischalten musste! Weiss es aber nicht mehr genau. Sollte ich hier auch mal geschrieben haben, da es bei mir auch nicht ging!
Gruss Christoph
Edith:
Gefunden: https://forum.fhem.de/index.php/topic,38404.msg684904.html#msg684904
Hallo miteinander,
ich habe einen MAX!Cube mit einem Atmel AT91SAM7X256. Diesen wollte ich mit der letzten Version a-culfw_1.26.08_build_324 umflashen. Nach dem Flashen des Bootloaders mit dem SAM-BA v2.18 for Windows konnte ich die Image-Datei CUBE_BL.bin so wie beschrieben auf den Cube kopieren. Nach dem Neustart des Cubes scheint erstmal alles in Ordnung zu sein, die Battery-LED leuchtet dauerhaft, die Power-LED blinkt etwa im Sekundentakt und er wird unter Windows 10 als serielle Schnittstelle erkannt.
Jetzt kommt das Problem: Über die RS232 wollte ich die Netzwerkeinstellungen anpassen, allerdings reagiert er darauf nicht. Wenn ich mit HTerm mit 9600 Baud ein "V" sende erhalte ich keine Antwort. Auch wenn ich den Cube ans LAN anschließe (Stromversorgung dabei über das Original-USB-Netzteil), wird er mir im Router (mit DHCP) nicht angezeigt.
Mit der älteren Version a-culfw_1.26.07_build_320 habe ich genau das gleiche Problem.
Mit der noch älteren Version a-culfw_1.25.01_build_258 und dem alten Bootloader bekomme ich nach dem Flashen des Bootloaders keine stabile USB-Verbindung zustande...
Schon mal vielen Dank im voraus.
Michi
Zitat von: michaelsaller am 01 Juni 2021, 13:40:00
Über die RS232 wollte ich die Netzwerkeinstellungen anpassen
Hast du den Cube wirklich über RS232 angeschlossen, oder meinst du damit den USB Port?
Zitat von: michaelsaller am 01 Juni 2021, 13:40:00
Wenn ich mit HTerm mit 9600 Baud ein "V" sende erhalte ich keine Antwort.
Nur "V" oder "V" und Return?
Hi Telekatz,
Zitat von: Telekatz am 01 Juni 2021, 19:57:05
Hast du den Cube wirklich über RS232 angeschlossen, oder meinst du damit den USB Port?
ja ich meine schon den USB-Port, der als serielle Schnittstelle installiert wird.
Zitat von: Telekatz am 01 Juni 2021, 19:57:05
Nur "V" oder "V" und Return?
Achso, muss nach dem "V" Zeichen noch ein CR-Zeichen gesendet werden?
Nachtrag: Ich habe gerade nochmal in der culfw reference nachgelesen, dass mit dem "cr/nl as a message terminator" habe ich übersehen. Ich probiers heute abend gleich nochmal aus...
Hallo Telekatz,
ja, es lag am fehlenden CR-Zeichen. Vielen vielen Dank für die schnelle Antwort!!!
Hallo zusammen,
ich habe meinen Max!Cube gestern umgeflasht und auf Homematic umgestellt.
Soweit funktioniert alles wunderbar - vielen Dank hier an Telekatz und alle die an der Firmware gearbeitet haben!
Ich würde den Cube jetzt gerne um ein 433 MHz-Modul erweitern.
Was mir nicht klar ist, ist wie ich das neue Modul dann über das Netzwerk adressiere vom FHEM aus?
Der CUNO ist ja per IP-Adresse und Portnummer erreichbar mit seinem 868 MHz-Modul.
Wie würde das neue Modul angesprochen?
Danke und Gruß,
Frank
Zitat von: FrankFHEM am 21 Oktober 2021, 15:56:09
.....
Der CUNO ist ja per IP-Adresse und Portnummer erreichbar mit seinem 868 MHz-Modul.
Wie würde das neue Modul angesprochen?
Schon gelöst?
Es funktioniert wie beim MapleCUN mit STACKABLE bzw. STACKABLE_CC und ist im Wiki (https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_.28alt.29) beschrieben.
Zitat von: Telekatz am 15 Dezember 2021, 18:05:39
Es funktioniert wie beim MapleCUN mit STACKABLE bzw. STACKABLE_CC und ist im Wiki (https://wiki.fhem.de/wiki/MapleCUN#Einrichtung_in_FHEM_.28alt.29) beschrieben.
Jau... passt :)
Bei meinem Cube (1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)) ist mir aufgefallen, als ich mal mit X67 (set raw) ein paar Daten im Eventmonitor lesen wollte, dass der Cube "neu startet" wenn ich etwas Anderes als X21 zum Cube schicke.
Ist das korrekt?
Edit: habe den Cube mal an den PC gehängt und mit puTTY direkt auf den COM-Port geschrieben.
- B00 (Error Reading from serial) Uptime fängt wieder vorne an => ist natürlich ok, wollte die Reaktion sehen
- X00, X01, X02, X04, X21, X67 lassen sich eingeben Uptime läuft hoch
aber
- X01, gefolgt von X02 oder X21 gefolgt von X67 führt zum Reboot.
- X21 gefolgt X00 geht
aber
- X21 gefolgt X00 gefolgt von X21 führt zum Reboot.
Fazit die meisten (alle?) zweifachen Umschaltungen des Reporting führen zum Reboot.
Hallo Allerseits =)
ich habe jetzt erfolgreich meinen MAX!Cube mit der a-CULFW (CUBe) umgeflasht mit dieser Anleitung (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html). Er läuft über LAN, also als CUN, und es ist ein zweites CC1101-Modul angelötet für den 433MHz-Bereich. Der integrierte Transceiver ist für meine MAX!-Heizung zuständig, der zusätzliche Transceiver schaltet Intertechno-Steckdosen, bzw empfängt meine SmartWares-Wandschalter und es läuft alles wie gewünscht ;D
Mich würde aber interessieren, ob man dort auch eine IRLed verbauen kann, um einen zusätzlichen CUL_IR betreiben zu können. In der engl. Commandref steht, das es mit einem CUN/CUNO geht, allerdings ist mein MAX!Cube ja kein klassischer CUN.
Hat das evtl. schon jemand versucht?
LG
Eric
Hallo zusammen,
ich habe am Wochenende auch endlich mal Zeit gefunden einen zweiten Transceiver in meinen schon mit der a-culFw geflashten Cube einzubauen.
Nun scheitere ich an der geänderten Pinbelegung.
Ich habe nach diese Anleitung gelötet: https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html
Die CUBEx4_BL.bin Datei hat aber scheinbar den CC1100_1_OUT_PIN auf 28 gesetzt und ich brauche den auf 25.
Nun habe ich den Source Code runtergeladen und die board.h entsprechend geändert, aber ich bekomme es zu verrecken nicht compiliert.
Auf meinem Raspberry habe ich das nicht hinbekommen. Ich müßte wohl extra einen Linux System aufsetzen um die Umgebung zu schaffen.
Hat hier nicht irgendjemand das schon gemacht und kann mir und sicher auch anderen die des compilens nicht mächtig sind imens aushelfen und die Datei zu Verfügung stellen ?
Wäre klasse...
Das Problem hatte ich auch :) setz ein Ubuntu 16.04 auf einer virtuellen Maschine (zb VMPlayer o.ä.) auf, dann klappt das kompilieren. Muss aber ein älteres Linux sein, da auf den neuen eine neuere Version von GCC benutzt wird, damit klappt das nicht.
Tja, nun habe ich mir extra ein Ubuntu Notebook aufgesetzt und mir die Bin Datei erfolgreich mit geänderter Pin Zuordnung in der board.h kompiliert.
Dann den Cube mit gerückter Reset Taste an meinen Rechner gehängt und die Datei in das USB device kopiert. Cube startet neu und das Device des internen Tranceivers ist in Fhem initialisiert wie vorher. Miene Max Fernsterkontake funktionieren auch wie gehabt.
Nur der zusätzlich Tranceiver will nun gar nicht mehr.
Internals:
CFGFN
CMDS
CUL1_MSGCNT 9
CUL1_TIME 2022-03-20 15:05:07
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 CUN868
FUUID 623600ce-f33f-98db-99a2-451622e0c41ebabe
IODev CUN868
NAME CUL1
NOTIFYDEV CUN868
NR 48257
NTFY_ORDER 50-CUL1
PARTIAL
RAWMSG (*V 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
STATE disconnected
StackLevel 1
TYPE STACKABLE_CC
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:
2022-03-20 15:05:07 state disconnected
Attributes:
rfmode SlowRF
Vorher mit der fertigen CUBEx4_BL.bin konnte ich wenigstens mit dem zusätzlichem Transceiver empfangen, nur eben nicht senden.
Nun ist aber der state disconnected. Also das Ergebnis mit meiner angepassten .bin ist leider schlechter.
Was kann denn da noch schief gelaufen sein ?
Hat jemand noch einen Tipp ?
Wie sieht deine aktuelle board.h aus? Hast du zuerst versucht, die Sourcen ohne Änderung zu kompilieren, um zu sehen, ob die erstellte .bin wie die fertige .bin läuft?
So, hab endlich mal Zeit gefunden dem nachzugehen.
Also um es kurz zu machen: Es funktioniert nun !!!
Ich habe aber leider keine Ahnung woran es lag.
Ich habe zuerst die board.h wieder zurück geändert, also Pin 25 wieder mit 28 getauscht (bei Port 3 natürlich auch)
Dann kompiliert und auf den Cube übertragen. Ins LAN gehängt und in Fhem waren beide Tranceiver Initialized.
Empfangen geht, senden nicht.
Dann die board.h wieder geändert und Pin 25 bei Port 1eingetragen und 28 bei Port 3. Kompiliert, und auf das Cube Laufwerk kopiert. Power Cycle und in Lan, und beide Transceiver senden und empfangen !!! ;-)
Ob es daran lag das ich nun aus Faulheit den Cube an das Ubuntu Notebook gehängt habe um die .bin auf das UAS Laufwerk des Cube zu übertragen, und letztes mal war es der Windows Rechner ???
Egal. ich freue mich das es nun funktioniert und ich nun einen zweiten Sender im Haus habe.
Nun noch die Frage wie ich den schlau einsetzte. Muß ich bei jedem IT Device angeben mit welchem IODev es kommunizieren soll ? Oder kann man das Attribut auch löschen und es geht immer über den Empfangsstärksten ?
Hallo,
läuft bei euch der Cube stabil? Sobald ich was größeres Senden möchte (weekprofile, mehrere Befehle,...) verschwindet er erstmal und taucht dann wieder auf. Gelegentlich läuft er auch amok ("message $rmsg len mismatch" / "unhandled message"), was jedes Mal meine gesamte FHEM Installation runter zieht. Hat meine HW evtl. nen Schuss? Bootet ihr regelmäßig (raw B)?
Falls jemand immernoch das nervice Problem mit dem Compilieren hat wo am Ende das Linken in die Binsen geht: es gibt einen Fix für das Linker Script.
https://github.com/heliflieger/a-culfw/pull/35 (https://github.com/heliflieger/a-culfw/pull/35)
Ich habe 2 zusätzliche CC1100 Module entsprechend den Anleitungen im Netz angelötet. Jetzt benötige ich noch etwas Unterstützung bei der Modifizierung der Firmware für den geflashten CUBE.
Wer von euch hat eine fertig kompilierte Version mit einer wie folgt angepassten board.h und würde diese mir zu Verfügung stellen. PORT3 wird von mir nicht genutzt. Ich denke daher sind nur die Änderungen von PORT 1 und 2 wichtig.
Vielen Dank für eure Hilfe
PS. Ja, ich habe versucht den Compiler zu installieren, bin aber gescheitert
//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 24
#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 22
#define CC1100_3_CS_BASE AT91C_BASE_PIOB
#define CC1100_3_OUT_PIN 20
#define CC1100_3_OUT_BASE AT91C_BASE_PIOB
#define CC1100_3_IN_PIN 28
#define CC1100_3_IN_BASE AT91C_BASE_PIOB
Nutzt jemand den Cube Max for wmbus, evtl sogar mit wmbusmeters? Flash und Co soweit erfolgreich, jedoch weiß ich nicht ob die Firmware wmbus bereits drin hat und ob ich noch etwas zusätzlich aktivieren / konfigurieren muss?
Hallo Zusammen,
Habe das gleiche Probleme beim Kompilieren wie oben schon mehrfach beschrieben.
Kann jemand, dem es gelungen ist, für die beschriebene (https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html) Konfiguration, die fertig kompilierte Firmware für den CUbe bereitstellen?
Oh Mann...
meiner läuft schon über drei Jahre (oder 6??). Da muss ich mal kräftig im Gedächtnis kramen.
Wenn ist es eine Version für einen 433er und einen 866er Sender.
Wenn keiner spontan antworten kann. Nach Ostern kann ich schauen.
Gruß Ralf
Hallo Zusammen,
Mit der gefixten Source von https://github.com/Scyten/a-culfw/tree/bugfix-Fix-linker-script-for-CUBe-device konnte ich die Frimware unter Debian Bullseye compilieren. :)
Wollte nun einmal RFmode für MAX und einmal für RFmode für WMBUS unter FHEM aktivieren.... geht so ja mal nicht. :(
Wie spreche ich die Transceiver überhaupt unter FHEM an?
Spontanes Stichwort dazu :
Stacked Cul
Du hast dann 2 CULs
Ja Prima - Danke!
ein
defmod CUL_Cube_Keller_0 CUL 192.168.178.18:2323 0000
defmod CUL_Cube_Keller_1 STACKABLE_CC CUL_Cube_Keller_0
hat es gebracht.
Was ist eigentlich der Unterschied zwischen "STACKABLE_CC" und "STACKABLE"?
Ehrlich:
k. A. zu lange her. Evtl. wg. dem Chip CC1100.
Ich habe meinen MAX! Cube nun mit der Firmware-culfw_1.26.08_build_324 geflashed.
Nach dem Flashen der bootloader_CUBE.bin habe ich die CUBE_BL.bin in das bereit gestellte USB Laufwerk kopiert. Ich hoffe das war die richtige Datei?
Auch habe ich einen CUN mit rfmode = MAX definiert. Aber jetzt weiss ich nicht mehr weiter
Ich denke nun müsste man den CUL_ MAX definieren, gem. commandref
define <name> CUL_MAX <addr>Aber woher weiss ich die addr?
Im Logfile erscheint unzählige male
CM_Parse, no matching CUL_MAX device found
Im Prinzip ja,
wegen der CUBE_BL.bin/CUBEx4_BL.bin kannst du in dem Bereich mal lesen https://forum.fhem.de/index.php?topic=38404.msg655022#msg655022
Einen CUN habe ich ebenfalls wegen der LAN-Anbindung definiert.
Ich nutze die beiden Sender für "Homematic rfmode=HomeMatic" und "433Mhz Steckdosen rfmode=SlowRF".
Wenn ich das auf den MAX! übertrage müsstest du den 866er Sender auf rfmode = MAX stellen und dann wie ein MAX!-IO handeln. Dazu weiss ich aber nichts.
Ein "define <name> CUL_MAX <addr>" würde ja nur einen neuen separaten MAX-Cul erzeugen.
Der Cun ist nach dem flashen wie folgt definiert
Internals:
CFGFN
CMDS BbCFiAZNEkGMKLUYRTVWXefhltxz
CULmax_MSGCNT 32
CULmax_RAWMSG Z0E5D02020D065A11EB4A0001190026
CULmax_RSSI -53.5
CULmax_TIME 2023-05-01 22:42:51
Clients :CUL_MAX:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
DEF 10.10.10.16:2323 0000
DeviceName 10.10.10.16:2323
FD 88
FHTID 0000
FUUID 64502378-f33f-f4b3-4c5b-fa141588ecfb6dc2
LASTInputDev CULmax
MSGCNT 16
NAME CULmax
NR 1674
PARTIAL
RAWMSG Z0E5D02020D065A11EB4A000119002629
RSSI -53.5
STATE Initialized
TYPE CUL
VERSION V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) CUBe (F-Band: 868MHz)
devioNoSTATE 1
eventCount 3
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:
2023-05-01 22:39: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 h l t x z
2023-05-01 22:42:51 state Initialized
Attributes:
rfmode MAX
room CUL
das verursacht dann
...................
2023.05.01 22:44:56 2: CM_Parse, no matching CUL_MAX device found
2023.05.01 22:44:56 2: CM_Parse, no matching CUL_MAX device found
2023.05.01 22:44:59 2: CM_Parse, no matching CUL_MAX device found
...................
Hast du autocreate aktiviert?
Ja eigentlich schon,
Jetzt scheint der autocreate funktioniert zu haben, nach etwa dem 10. Mal definieren, löschen, neu definieren usw...
Na ja, man kann nicht immer alles verstehen.
Hoffentlich liest hier noch jemand ab und zu mit.
Ich habe versucht, eine angepasste Version auf einem Pi3 mit Debian buster zu kompilieren.
Das ist auch nach einigem hin und her ohne Fehlermeldung und Abbruch gelungen, aber wenn ich die erzeugte CUBE_BL.bin auf den Cube kopiere, funktioniert er nicht mehr.
Nachdem ich die "alte" CUBE_BL.bin wieder drauf kopiere, ist alles wieder OK.
Funktioniert der compile-Prozess auf dem Pi3 Debian nicht richtig?
Hat sich erledigt, es gibt eine angepasste Version: a-culfw-bugfix-Fix-linker-script-for-CUBe-device
Hallo.
Nachdem FHEM das Neustarten meiner gelflashten Maxcubes mit a-culfw nicht mitbekam, habe ich dafür ein AT gemacht erstellt, welches die Zeit des internen Readings prüft und ein REOPEN macht, wenn sich das Reading nicht verändert hat.
Vielleicht hilft das ja einigen.
https://forum.fhem.de/index.php?topic=129073.msg1313338#msg1313338
Gruss Armin