Autor Thema: culfw@ARM  (Gelesen 232386 mal)

Offline vklaffehn

  • New Member
  • *
  • Beiträge: 13
Antw:culfw@ARM
« Antwort #1095 am: 10 August 2019, 14:04:34 »
Danke! Jetzt kapiere ich es. Dann ergibt es auch keinen Sinn, zum Testen den 433MHz an die 3. Stelle zu hängen, weil Revolt un IT SlowRF benötigen,richtig? Dann nehme ich mal meinen  3.Cube, und probiere es nochmal mit dem anderen Modultyp.

Offline vklaffehn

  • New Member
  • *
  • Beiträge: 13
Antw:culfw@ARM
« Antwort #1096 am: 11 August 2019, 14:54:12 »
Moin!
Erfolgsmeldung! :-)
Es scheint tatsächlich an meinen 433MHz-Modulen zu liegen. Ein dritter Cube mit einem anderen Modultyp (diese Bauform : https://eckstein-shop.de/Wireless-RF-Transceiver-Module-433Mhz-CC1101-CC1100-Antenna?curr=EUR&gclid=Cj0KCQjw-b7qBRDPARIsADVbUbXDPXdv8Rw6insIcUDx8DB6YalSAFyHKFfdMi1jh4s-P41tXC4Q-TkaAo2oEALw_wcB) 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.

Offline meldelinie

  • New Member
  • *
  • Beiträge: 13
Antw:culfw@ARM
« Antwort #1097 am: 12 September 2019, 18:38:15 »
Hallo,

ich will mir noch eine Wetterstation zulegen, am besten eine mit 433Mhz weil dort die Reichweite am besten ist.

Nach dem Wiki https://wiki.fhem.de/wiki/Ventus_Wetterstation_433MHz#W132 ist das Auswertemodul "CUL_TCM97001".

In der 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 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 ?
« Letzte Änderung: 12 September 2019, 18:40:09 von meldelinie »

Offline Parador

  • Full Member
  • ***
  • Beiträge: 124
Antw:culfw@ARM
« Antwort #1098 am: 16 September 2019, 20:10:48 »
Hallo Zusammen,
nachdem ich noch einen vergessenden Cube hatte habe ich mich gestern drangemacht und versucht ihn doch noch nützlich zu machen.
Ich arbeite unter Win10 und bin mit Sam-ba 2.18 nicht weitergekommen.
Als ich dann Bossa 1.9.1 benutzte konnte ich m.M. nach den Bootlader erfolgreich flashen.
Wenn ich dann den Cube wieder vom USB trenne und wieder anstecke (egal ob mit oder ohne gedrückten Reset-Button) blinkt er hektisch grün, Win10 macht auch das Geräusch eines neuen Gerätes, allerdings zeigt der Eintrag im Geräte-Manager ein tragbares Geräte mit Laufwerksbuchstaben "G:" Nach einiger Zeit scheint es einen Neustart zu geben, Win10 macht wieder das Geräusch eines neuen Gerätes, aber wieder wird nichts anderes angezeigt.
Weder Tera Term noch andere XModem fähige Terminalp. kriegen eine Verbindung.
Was mache ich falsch, bzw. was muss ich machen um die aktuelle aculfw draufzubekommen? Wer hat Ideen und kann mir hefen?
Vielen Dank im Voraus!
« Letzte Änderung: 16 September 2019, 20:13:35 von Parador »

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 860
Antw:culfw@ARM
« Antwort #1099 am: 16 September 2019, 20:37:54 »
Das ist der neue MSC Bootloader. Zum flashen muss man nur die Firmwaredatei auf das neue Laufwerk kopieren.

Offline Parador

  • Full Member
  • ***
  • Beiträge: 124
Antw:culfw@ARM
« Antwort #1100 am: 16 September 2019, 21:15:51 »
Sorry wenn ich das irgendwo überlesen habe. Jetzt leuchtet eine konstant die andere blinkt langsam.
Im Geräte Manager erscheint AT91 USB to Serial Converter

Offline f-zappa

  • Full Member
  • ***
  • Beiträge: 103
Antw:culfw@ARM
« Antwort #1101 am: 18 September 2019, 14:52:21 »
Moin, ich bin gestern auf diesen Thread gestoßen und habe daraufhin bei ebay einen Cube gekauft. Grund ist, dass ich immer wieder Probleme mit meinen Homematic-Gateways habe. Derzeit habe ich einen LAN-Konfigurationsadapter, der je nach Tagesform ständig neu startet (Kondensatoren tauschen hat nix gebracht) und einen ESP mit HM-MOD-RPI-PCB, der sich aber gelegentlich aufhängt. Jetzt will ich also mit dem geflashten Cube mein Glück versuchen.

Ich habe heute in diesem und einigen anderen Threads quergelesen und auch im Wiki gestöbert . Oft wird von CUL/CUN für Homematic abgeraten oder zumindestens eine spezielle Firmware (ts-culfw) empfohlen, aber auf dem Cube läuft ja wohl eine andere (a-culfw). Vieles, was ich gelesen habe ist aber schon einige Jahre alt und ich frage mich, inwiefern es noch aktuell ist. Meine Umgebung umfasst geschätzt 30 HM-Komponenten, einiges davon mit AES. Ist das mit culfw@arm realistisch zu betreiben oder soll ich das gleich vergessen? Wenn ich es richtig verstanden habe, kann ich den Cube sowohl über USB als auch über LAN verbinden - macht das einen Unterschied in der Zuverlässigkeit, weil fhem zB das Timing über USB besser steuern kann?




Offline f-zappa

  • Full Member
  • ***
  • Beiträge: 103
Antw:culfw@ARM
« Antwort #1102 am: 19 September 2019, 18:24:50 »
So, mein Cube ist angekommen. Direkt geflasht und integriert.
Nun erwäge ich, bei allen anderen IOdevs einfach mal den Stecker zu ziehen und zu gucken, ob der Cube das packt.

Offline f-zappa

  • Full Member
  • ***
  • Beiträge: 103
Antw:culfw@ARM
« Antwort #1103 am: 19 September 2019, 21:49:22 »
Nun erwäge ich, bei allen anderen IOdevs einfach mal den Stecker zu ziehen und zu gucken, ob der Cube das packt.

Ernüchterung und Rückbau.

Alles, was AES braucht, funktioniert mit dem Cube via LAN im Grunde nicht. Da das überall zu lesen ist, hat es mich nicht wirklich überrascht.

Via USB würde alles gut, dachte ich. Leider konnte ich den Cube via USB nicht in meinem FHEM ansprechen (läuft als VM in ESXi). Das durchgeschliffene USB-Gerät wird erkannt, beim öffnen friert FHEM allerdings ein (wenn man via screen o.ä. von Hand verbinden möchte, passiert das gleiche). Auch dieser Effekt scheint bekannt zu sein - im Forum und anderswo wird empfohlen, die VM mit einem USB 3.0 Host statt 2.0 zu konfigurieren und/oder das "neue" USB-Modul von ESXi abzuschalten (esxcli system module set -m=vmkusb -e=FALSE) - allerdings ändert das nichts.

Hat noch jemand einen Tipp?
Hab ich mir für ~20€ einen formschönen Briefbeschwerer gekauft?
Kann ich mit dem Ding irgendwas anderes nettes anfangen?

Offline softcat

  • New Member
  • *
  • Beiträge: 5
Antw:culfw@ARM
« Antwort #1104 am: 29 September 2019, 21:08:38 »
Ich habe eine kurze Frage zu meinem Cube.

ich habe wie im Thread weiter oben bzw. unter https://blog.loetzimmer.de/2017/10/max-cube-umbau-zu-4-fach-netzwerk-cul.html ein weiteren CC1101 angelötet.

board.h angepasst und Firmware sowie Bootloader compiliert.

Nach kurzschließen des J1 Reset PINs den Bootloader mittels Bossa aufgespielt.

Nach Neuanschließen öffnet sich auch wie erwartet ein neues Laufwerk in Windows, in das ich die Firmwaredatei ziehe. Diese wird scheinbar auch eingespielt, D1 leuchtet direkt danach dauerhaft.

Jetzt aber:
Nach erneuten Anschließen an USB blinkt D1 direkt schnell (ohne Drücken des rückseitigen Tasters) und es öffnet sich wieder das Laufwerksfenster.

Nach einigem Probieren folgende Beobachtungen:
Gleiches Problem beim Flashen der vorkompilierten Firmware.
Gleiches Problem beim Verwenden des Prä-MSC Bootloaders. Einspielen der Firmware mittels Teraterm scheinbar erfolgreich. Nach Neuverbinden das gleiche Spiel mit Blinken von D1.


Das Gerät verhät sich so, als der Taster dauerhaft geschlossen wäre. Kurz durchgemessen: er funktioniert.

Hat jemand irgendeine Idee, woran dies liegen könnte?

Tausen Dank!

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 860
Antw:culfw@ARM
« Antwort #1105 am: 29 September 2019, 22:04:24 »
Es schon mal ohne den zusätzlichen CC1101 probiert?

Offline softcat

  • New Member
  • *
  • Beiträge: 5
Antw:culfw@ARM
« Antwort #1106 am: 30 September 2019, 21:05:10 »
Es schon mal ohne den zusätzlichen CC1101 probiert?

Jetzt steht ich irgendwie auf dem Schlauch. Ich hab den CC1101 entfernt: gleiches Problem.

Auf dem CuBE hatte ich vor längerer zeit schon mal (vor Modifikation) eine ätere Version der CUBe Firmware erfolgreich laufen.

Vielleicht ein Hardware Defekt, obwohl eigentlich alle ehemaligen Lötstellen gut aussehen...

Kann man eigentlich irgendwelche Debug-Ausgaben beim Start des CUBe bekommen?   

Grüße!

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 860
Antw:culfw@ARM
« Antwort #1107 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.

Offline Nitaro

  • New Member
  • *
  • Beiträge: 49
Antw:culfw@ARM
« Antwort #1108 am: 01 Oktober 2019, 18:10:19 »
Hallo zusammen,

ich habe da ein Problem mit den hm-cc-rt-dn Thermostaten.
Ich betreibe zwei umgflashte Cubes mit V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54).
Sobald ich bei den Heizkörperthermostaten ein getConfig im Clima Channel mache (HM_XY000_Clima)
bekomme ich "RESPONSE TIMEOUT:RegisterRead". Das gleiche Problem habe ich mit der vorherigen Firmware V 1.26.06.
Andere Versionen habe ich nicht versucht.

Sobald ich die Thermostate auf den nanoCUL verbinden lasse funktioniert alles tadellos.

Gibt es Einschränkungen bei dem Cube ?

Offline Telekatz

  • Developer
  • Sr. Member
  • ****
  • Beiträge: 860
Antw:culfw@ARM
« Antwort #1109 am: 01 Oktober 2019, 21:16:10 »
Nein, da gibt es keine Einschränkungen beim Cube. Und bei meinen Thermostaten bekomme ich kein "RESPONSE TIMEOUT:RegisterRead".

 

decade-submarginal