Hauptmenü

culfw@ARM

Begonnen von Telekatz, 22 Juni 2015, 22:42:29

Vorheriges Thema - Nächstes Thema

mahowi

Ich hatte damals auch Probleme mit Sam-Ba unter Windows, daher hab ich den Cube an den Raspi angeschlossen und geflasht. (Antwort #263 hier im Thread)
CUBe (MAX): HT, FK | CUBe (SlowRF): ESA2000WZ
JeeLink: LaCrosse | nanoCUL433: Smartwares SHS-51001-EU, EM1000GZ
ZME_UZB1: GreenWave PowerNode, Popp Thermostat | SIGNALDuino: HE877, X10 MS14A, Revolt NC-5462,  IT Steckdosen + PIR
tado° | Milight | HUE, Lightify | SmarterCoffee

wendeling

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 !



Telekatz

Welche Datei genommen werden muss steht im ersten Beitrag.

wendeling

#873
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?


Wzut

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Holzlenkrad

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...

scooty

set Name_Deines_MaxCubes led 00
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

uelpenich

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?

Telekatz

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 System


Zitat 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.

BHef

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?

Telekatz

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

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.

BHef

Super, vielen Dank!

uelpenich

#882
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 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):
CubeAS07-M1101SPinPin directionPin uses
VCCVCC1Power supply, must be in the range 1.9-3.6V
OUT (PB25)GOD02Module information output pin
CS (PA6)CSN3InputModule chip select pin, used to start a SPC communication
SCKSCK4InputSPI bus clock
MOSIMOSI5InputModule SPI data input pin
MOSI/GD?? was ist das ??
MISOGOD1 (O1)6??Input??Input module SPI data output pin
IN (PA5)GOD27OutputOutput module information output pin
GNDGND8OutputExpress, connected to the power supply ground reference.
Die culfw habe ich nach Anleitung und mit dem Patch von Loetzimmer gebaut.

In der Zwischenzeit habe ich einen zweiten Cube mit einem 868MHz Transceiver ausgerüstet. Der arbeitet wie beabsichtigt. Für die Einbindung in FHEM habe ich die "STACKABLE" Variante gewählt.
Die Module STACKABLE und STACKABLE_CC funktionieren nicht gleichzeitig. Das habe ich schon geahnt, da nach einem Wechsel von STACKABLE_CC nach STACKABLE folgendes in der Logdatei aufgetaucht ist:2017.12.08 22:25:19 2: Switched CUL00 rfmode to MAX
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOOpenFn redefined at ./FHEM/16_STACKABLE.pm line 114, <$fh> line 107.
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOReadFn redefined at ./FHEM/16_STACKABLE.pm line 124, <$fh> line 107.
2017.12.08 22:25:19 1: PERL WARNING: Subroutine STACKABLE_IOWriteFn redefined at ./FHEM/16_STACKABLE.pm line 154, <$fh> line 107.
2017.12.08 22:25:19 3: Opening CUL01 device FHEM:DEVIO:CUL01Stack:9600

Telekatz

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?

uelpenich

#884
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
Zr
Am Debug Port erscheint:
0:Set RF mode to 1
0:Set RF mode to 3
Der interne Transceiver arbeitet jetzt ganz normal und protokolliert die MAX Telegramme.
Der Absturz / der Neustart erfolgt nach dem Kommando *X21. Das USB Terminal meldet PUTTY fatal Error - Error reading from serial device. Die Ausgabe am Debug Port ist

-I- Getting new Started Project --
-I- CUBEx4 . . . und weiter mit dem ganzen Rest, den wir oben beim Einschalten sehen . . .
Ich kann mir das nur mit vertauschten Anschlüssen oder einer kaputten Briefmarke erklären. Hast Du eine Idee?
Gruß Werner