Autor Thema: culfw@ARM  (Gelesen 293286 mal)

Online Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 960
Antw:culfw@ARM
« Antwort #885 am: 16 Dezember 2017, 16:42:57 »
-I- Detected CC1: PN 0x00  VER 0x14Da der zweite Transceiver erkannt wurde funktioniert die SPI Verbindung korrekt.

Das bereits X21 einen Absturz verursacht ist ungewöhnlich. Bei diesem Kommando fällt es nicht mal auf, wenn kein Transceiver verbunden ist. Bei einem nicht verbundenen Transceiver startet ein CUL erst beim aktivieren eines der anderen Protokolle neu. Dann wird darauf gewartet, dass der Transceiver einen bestimmten Zustand einnimmt und da das nicht passiert wird der Watchdog ausgelöst.

Löte mal GDO0 und GDO2 ab und schau, was dann passiert.

Offline uelpenich

  • New Member
  • *
  • Beiträge: 17
Antw:culfw@ARM
« Antwort #886 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.

Offline Allodo

  • Jr. Member
  • **
  • Beiträge: 72
Antw:culfw@ARM
« Antwort #887 am: 28 Dezember 2017, 14:09:27 »
Hallo,

ich habe seit gestern auch einen Max!Cube aus einem Medion-Starterset. Da ich mir gleich 2 Sets zugelegt habe, wollte ich den einen umflashen.
Ich habe es mit Sam-ba v2.17 und v2.18 unter Win10 als Admin "versucht". Jedes Mal wurde der COM-Port richtig eingetragen.

Jedoch kommt nach Send-File nur 1% und nach Execute ebenfalls nur 1% und es tut sich nix mehr (ist das normal?).
Anschließend habe ich mit TeraTerm die die Firmware geflasht und jetzt blinkt eine LED im Sekundentakt (scheint wohl richtig geflasht zu sein?).

Den Cube habe ich an einem RPi2 angesteckt, mit einer frischen FHEM-Installation von gestern Abend.

Sollte der Cube nun als CUL automatisch erkannt werden oder bedarf es noch irgendwelcher Schritte? Mir wurde nämlich gesagt, er solle automatisch erkannt werden.
Und ich weiß jetzt nicht ob das flashen richtig funktioniert hat, oder nicht :(

Den anderen MaxCube mit Original-Firmware habe ich in FHEM eingebunden und er läuft einwandfrei. Wobei ich absoluter FHEM-Neuling bin. Deshalb bitte ich um Nachsicht ;)

Online Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 960
Antw:culfw@ARM
« Antwort #888 am: 28 Dezember 2017, 20:31:35 »
Sollte der Cube nun als CUL automatisch erkannt werden oder bedarf es noch irgendwelcher Schritte? Mir wurde nämlich gesagt, er solle automatisch erkannt werden.
Und ich weiß jetzt nicht ob das flashen richtig funktioniert hat, oder nicht :(

Der Cube wird nicht automatisch erkannt. Den muss man manuell definieren:
define Cube CUL /dev/serial/by-id/usb-03eb_AT91USBSerial1-if00@42 1234

Offline Allodo

  • Jr. Member
  • **
  • Beiträge: 72
Antw:culfw@ARM
« Antwort #889 am: 29 Dezember 2017, 07:31:24 »
@Telekatz
Danke, jetzt wurde er sofort gefunden :)

Jetzt werde ich mich erst einmal in FHEM einlesen müssen ;)

EDIT:
Ich musste FHEM noch einmal neu installieren und bei der Installation wurde der CUL_MAX sofort integriert, sprich er musste nicht extra definiert werden :)

Ich werde zukünftig wohl auch Rollladenaktoren von Homematic einsetzen, da ich bei diesen meine Mertenblenden verwenden kann (günstigere Variante als Vorschlag wird gerne angenommen). Nur stellt sich bei mir nach einigem lesen doch konfusion ein.
Die Threads sind von Beginn diesen Jahres und dort wird erwähnt man soll eine spezielle Homematic-Firmware auf den CUL aufspielen, während andere sagen der CCU2 wäre für den Einsatz mit Homematic viel besser.

Ich wollte jetzt eigentlich meinen CUL_MAX dafür einsetzen. Dort kann ich ja per rfpm Homematic auswählen. Heißt das jetzt dieser spezielle Teil ist involviert?
Wenn ich jetzt FHEM einsetzen will auf einem RPi2 oder 3 mit dem CUL_MAX, wäre dann immernoch der CCU2 die bessere Wahl?

Weiterer EDIT:
Habe mittlerweile Homematic Schalt- und Rollladenaktoren verbaut. Und diese laufen perfekt mit dem Max!Cube/CUL :)
« Letzte Änderung: 07 Januar 2018, 21:52:50 von Allodo »

Offline caligo23

  • New Member
  • *
  • Beiträge: 13
Antw:culfw@ARM
« Antwort #890 am: 05 Januar 2018, 19:48:21 »
@telekatz

Hallo, da ich nun endlich auch einen MAX!Cube hier habe, stellt sich die Frage : Wie schließe ich einen zusätzlichen CC1101 (433MHz) an.
Welche PINs werden mit welchen Signalen beschaltet. Aus der board.h werde ich nicht so ganz schlau und die Bilder vom blog.loetzimmer.de sind auch nicht wirklich hilfreich.
MOSI, MISO und SCK werden mit den Signalen am TRX1 verschaltet, aber wo gehen GDO0, GDO2 und CSN hin?
Leider habe ich bisher keine Antwort finden können.
Für Hilfe wäre ich dankbar.
« Letzte Änderung: 05 Januar 2018, 21:40:29 von caligo23 »

Online Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 960
Antw:culfw@ARM
« Antwort #891 am: 06 Januar 2018, 18:06:49 »
GDO0 ist der OUT_PIN, GDO2 ist der IN_PIN und CSN ist der CS_PIN.

Wenn du nur einen oder zwei Transceiver nachrüsten möchtest, solltest du die Zuordnung in der board.h so ändern, dass du nur die verfügbaren Pins auf der Oberseite der Platine brauchst.
https://forum.fhem.de/index.php/topic,38404.msg680606.html#msg680606

Für Homematic oder MAX kann der OUT_PIN auch unangeschlossen bleiben.
Gefällt mir Gefällt mir x 1 Liste anzeigen

OtisWright

  • Gast
Antw:culfw@ARM
« Antwort #892 am: 06 Januar 2018, 19:30:25 »
Guten Abend zusammen,
ich versuche seit ein paar Tagen meinen Cube mit einem zusätzlichen CC1101 433 MHz Modul zum laufen zu bringen. Leider ohne wirklichen Erfolg.

Ich habe die Board.h nicht verändert und habe das in Beitrag #1 verlinkte Bin-File über XModem auf den Cube geladen. Dann habe ich die Pins wie folgt verbunden (siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)

Cube -> CC1101
VCC -> VCC
GND -> GND
PA5 -> GDO2
PA6 -> CSN
PA28 -> GDO0 (ST2 Pin2, laut Schaltplan)

TRX1 -> TRX2
Pin 1: MOSI -> MOSI
Pin 2: SCK -> SCK
Pin 3: MISO -> MISO

Kann jemand bestätigen, dass dies so korrekt ist?
Danke im Voraus.

Online Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 960
Antw:culfw@ARM
« Antwort #893 am: 06 Januar 2018, 20:01:40 »
Ich habe die Board.h nicht verändert und habe das in Beitrag #1 verlinkte Bin-File über XModem auf den Cube geladen. Dann habe ich die Pins wie folgt verbunden (siehe https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/CUBe/board.h)
Hast du auch die Datei CUBEx4_BL.bin verwendet?

PA28 -> GDO0 (ST2 Pin2, laut Schaltplan)
In board.h ist PB28 für CC1100_1_OUT definiert.

OtisWright

  • Gast
Antw:culfw@ARM
« Antwort #894 am: 06 Januar 2018, 20:11:02 »
Genau, ich habe die CUBE_x4_BL.bin verwendet.

stimmt, ich hatte jetzt nur auf internal und external transceivers geachtet.Pin 5 und 6 sind wohl ebenfalls für cc1100 definiert. was heißt das jetzt für mich? sorry, aber steh gerade auf dem schlauch

Edit:
Mir zeigt FHEM die folgenden Infos an:

VERSION
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
ccconf
freq:5913.464MHz bWidth:232KHz rAmpl:24dB sens:16dB

und wenn ich dann auf get ccconf klicke kommt:
Timeout reading answer for get C0D
« Letzte Änderung: 06 Januar 2018, 20:14:43 von OtisWright »

Online Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 960
Antw:culfw@ARM
« Antwort #895 am: 06 Januar 2018, 20:19:45 »

VERSION
V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) CUBEx4_83 (F-Band: 868MHz)
Erkannt worden ist der zweite Transceiver.

Mach mal mit raw e einen Reset der Einstellungen.

OtisWright

  • Gast
Antw:culfw@ARM
« Antwort #896 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?

Offline caligo23

  • New Member
  • *
  • Beiträge: 13
Antw:culfw@ARM
« Antwort #897 am: 06 Januar 2018, 20:28:18 »
Vielen Dank für die schnelle Antwort, mit den Infos sollte es funktionieren!
Ihr seid einfach Klasse!
Grüßle

OtisWright

  • Gast
Antw:culfw@ARM
« Antwort #898 am: 06 Januar 2018, 20:34:35 »
In board.h ist PB28 für CC1100_1_OUT definiert.

ups. ich hab das B übersehen. stimmt. hier habe ich was durcheinander gebracht. habe PA28 jetzt wieder entfern, ist ohnehin nicht erforderlich, richtig? Sollen nur IT-Steckdosen geschaltet werden. Ich hoffe nur, ich hab durch diesen fauxpas nichts zerschossen :(

Online Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 960
Antw:culfw@ARM
« Antwort #899 am: 06 Januar 2018, 20:55:05 »
Das hab ich gerade probiert. allerdings gibts dadurch keine Besserung. ein blick ins logfile und siehe da - das hier passiert seit 30 minuten durchgehend:

2018.01.06 20:22:59 3: CUBe_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefhltxz*
2018.01.06 20:22:59 1: 192.168.xxx.xxx:2323 reappeared (CUBe_0)
2018.01.06 20:22:59 3: CUBe_1: Possible commands: bCFiAZNEGMKLUYRTVWXfz
2018.01.06 20:23:25 1: 192.168.xxx.xxx:2323 disconnected, waiting to reappear (CUBe_0)

Woran kann das liegen?
Teste mal, ob es über USB funktioniert.

ups. ich hab das B übersehen. stimmt. hier habe ich was durcheinander gebracht. habe PA28 jetzt wieder entfern, ist ohnehin nicht erforderlich, richtig? Sollen nur IT-Steckdosen geschaltet werden. Ich hoffe nur, ich hab durch diesen fauxpas nichts zerschossen :(
Zum schalten von IT-Steckdosen wird der OUT_PIN benötigt. Ohne OUT_PIN geht nur der Empfang.

 

decade-submarginal