Autor Thema: culfw@ARM  (Gelesen 176901 mal)

Offline phantom

  • New Member
  • *
  • Beiträge: 42
Antw:culfw@ARM
« Antwort #930 am: 17 April 2018, 22:08:54 »
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  ff.

Gruß Phantom

Offline RalfRog

  • New Member
  • *
  • Beiträge: 35
Antw:culfw@ARM
« Antwort #931 am: 21 April 2018, 18:20:39 »
Hallo daredevil.2k

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.

Offline nussknacker4711

  • Newbie
  • Beiträge: 1
Antw:culfw@ARM
« Antwort #932 am: 24 April 2018, 16:44:52 »
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





Offline RaspiLED

  • Hero Member
  • *****
  • Beiträge: 1639
  • Es begann alles so klein ;-)
Antw:culfw@ARM
« Antwort #933 am: 24 April 2018, 18:40:31 »
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, ...
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Offline adn77

  • Jr. Member
  • **
  • Beiträge: 65
Antw:culfw@ARM
« Antwort #934 am: 24 April 2018, 19:25:22 »
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?

Offline Wzut

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1905
Antw:culfw@ARM
« Antwort #935 am: 28 April 2018, 19:45:37 »
Senden/Empfangen klappt soweit - und dann Bumm: Alle LED gehen kurz aus, FHEM loggt "disconnected, waiting to reappear" und dann kommt der Cube wieder. Mit dem Netztteil passiert das nicht, da klappt alles.
In die Falle bin ich auch getappt ... siehe https://forum.fhem.de/index.php/topic,38404.msg754806.html#msg754806 und die Antwort von Telekatz. ( Antwort 908 &  909) 
Lösung : USB Kabel "dumm" machen , d.h die beiden Datenleitungen kappen so das nur noch VCC und GND übrig bleiben.
Maintainer der Module: MPD, UbiquitiMP, UbiquitiOut, SIP

Offline Hallmackenreuther

  • New Member
  • *
  • Beiträge: 11
Antw:culfw@ARM
« Antwort #936 am: 10 Juni 2018, 22:43:07 »
Hallöle!

Mein Ziel, TX29-IT Sensoren mit einem MAX!Cube mitzulesen, scheint noch nicht auf Sichtweite. Aktueller Stand nach Einlesen an diversen Stellen:
Zitat
Als root im root-Verzeichnis:
mkdir a-culfw
cd a-culfw
wget https://github.com/heliflieger/a-culfw/archive/master.zip
unzip master.zip
cd ~/a-culfw/a-culfw-master/culfw/Devices/CUBe
nano board.h
#define LACROSSE_HMS_EMU unter #define HAS_RFNATIVE eingefügt, dafür #define HAS_SOMFY_RTS und #define HAS_MAICO mit // auskommentiert, um ggf. Platzprobleme zu vermeiden.
make

Das wurde am Ende so quittiert:
Zitat
../../clib/rf_native.o: In function `native_task':
/root/a-culfw/a-culfw-master/culfw/Devices/CUBe/../../clib/rf_native.c:239: undefined reference to `dec2hms_lacrosse'
collect2: error: ld returned 1 exit status
Makefile:125: die Regel für Ziel „CUBE_BL.elf“ scheiterte
make[1]: *** [CUBE_BL.elf] Fehler 1
make[1]: Verzeichnis „/root/a-culfw/a-culfw-master/culfw/Devices/CUBe“ wird verlassen
Makefile:97: die Regel für Ziel „CUBE_BL“ scheiterte
make: *** [CUBE_BL] Fehler 2

In Zeile (96) 97 in der Makefile steht
CUBE_BL:
        make OUTPUT=CUBE_BL LINK=CUBE_BL target

Zeile 125:
        $(LD)  -L$(LIBPATH) $(OPTFLAGS) -o $@  $^ $(LIBS) $(LDFLAGS)

Ich habe auch in anderen Versuchen https://forum.fhem.de/index.php/topic,36565.msg345912.html#msg345912 soweit mir verständlich beachtet, aber ich weiß nicht wo genau im Makefile ich den angegebenen Code einfügen müsste und mangels CUL.c im CUBe-Ordner gehe ich davon aus, dass die main.c das Äqivalent ist, in dem sich die beschriebenen Einträge aber alle schon befinden.

Mit vorkompiliertern .bins empfange ich die "Unknown code" Nachrichten fleißig, aber es gibt eben kein Autocreate - zur Not würde es mir auch reichen, die Sensoren manuell einzubinden, aber dazu habe ich bisher erst recht nichts gefunden.
FHEM 5.8 auf Raspi 3, Raspbian 9 | MAX! Cube a-culfw MAX: Heizkörperthermostate,  Fensterkontakte, Wandthermostat, Zwischenstecker BC-TS-Sw-Pl |2. MAX! Cube a-culfw HM: Rollos HM-LC-BI1PBU-FM, Licht HM-LC-Sw2PBU-FM | 3. MAX! Cube a-culfw SlowRF: Thermometer TX29-IT

Offline Hallmackenreuther

  • New Member
  • *
  • Beiträge: 11
Antw:culfw@ARM
« Antwort #937 am: 16 Juni 2018, 15:26:30 »
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)
« Letzte Änderung: 16 Juni 2018, 15:44:08 von Hallmackenreuther »
FHEM 5.8 auf Raspi 3, Raspbian 9 | MAX! Cube a-culfw MAX: Heizkörperthermostate,  Fensterkontakte, Wandthermostat, Zwischenstecker BC-TS-Sw-Pl |2. MAX! Cube a-culfw HM: Rollos HM-LC-BI1PBU-FM, Licht HM-LC-Sw2PBU-FM | 3. MAX! Cube a-culfw SlowRF: Thermometer TX29-IT
Hilfreich Hilfreich x 1 Liste anzeigen

Offline hulzer

  • Jr. Member
  • **
  • Beiträge: 50
Antw:culfw@ARM
« Antwort #938 am: 03 Juli 2018, 23:24:32 »
Damit anderen MAX!Cube-Nutzern mein Leid erspart wird, hier eine CUBE_BL.bin mit LaCrosse, erfolgreich getestet mit fünf TX29-IT
Hallo,
verstehe ich es richtig, für MAX! und LaCrosse benötigt man zwei Cubes?
Danke.

Offline RaspiLED

  • Hero Member
  • *****
  • Beiträge: 1639
  • Es begann alles so klein ;-)
Antw:culfw@ARM
« Antwort #939 am: 04 Juli 2018, 19:53:36 »
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=1oder mit zwei NanoCULs oder ...
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

Offline hulzer

  • Jr. Member
  • **
  • Beiträge: 50
Antw:culfw@ARM
« Antwort #940 am: 04 Juli 2018, 20:57:31 »
Danke für die Info.
Der Lötkolben glüht schon...

 

decade-submarginal