culfw@ARM

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

Gruß Phantom

[RalfRog]

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.

[nussknacker4711]

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

[RaspiLED]

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

[adn77]

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?

[Wzut]

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.

[Hallmackenreuther]

Hallöle!

Mein Ziel, TX29-IT Sensoren mit einem MAX!Cube mitzulesen, scheint noch nicht auf Sichtweite. Aktueller Stand nach Einlesen an diversen Stellen:

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:

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

[Hallmackenreuther]

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)

[hulzer]

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.

[RaspiLED]

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

[hulzer]

Danke für die Info.
Der Lötkolben glüht schon...

[Wzut]

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) :

Code: [Auswählen]

SRCS += ../../clib/lacrosse.c

[Mihca]

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:

Code: [Auswählen]

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

[berndEEE]

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.

[RaspiLED]

Hi,
Das sieht doch schon ganz gut aus,
Mach mal ein

Code: [Auswählen]

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