Hauptmenü

Max_CUL und Cube

Begonnen von boke, 05 Oktober 2015, 22:47:53

Vorheriges Thema - Nächstes Thema

boke

Hallo, ich habe in einem Wiki Eintrag gelesen, das man beides gleichzeitig betreiben kann.
Ich hatte erst nur den Cube in Fhem integriert, hier hat mich aber die lange zeit bis zur nächsten Aktualisierung gestört (Fensterkontakte). Deshalb hab ich eine MAX_CUL dazu geschaltet.
Jetzt stelle ich mir die Frage, soll ich den Cube weiter hin benutzen und wenn ja für was.
Viele Grüße!
Dennis

chris1284

du kannst auf den cube die cul-firmware spielen und ihn wie einen cul benutzen http://forum.fhem.de/index.php?topic=38404.0 somit stehen dir dann alle cul-möglichkeiten offen (max, homematic, SlowRF usw)

willyk

Ich habe den cube und einen cul parallel in Betrieb. Ein Teil der Geräte läuft über den Cube, einanderer über den Cul. So habe ich (insgesamt) mehr credits zur Verfügung.
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Rince

ZitatSo habe ich (insgesamt) mehr credits zur Verfügung.

Ich halte es ja für ziemlich unlegal, aber:
Es gibt da für den CUL eine Firmware, die von Haus aus einfach mehr Credits zur Verfügung stellt.
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

willyk

Richtig.
Die Kombination von beiden gibt sogar noch mehr credits ....    8)
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Rince

Ich sag nix mehr  :P
Wie viele Devices hast du im Einsatz???
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

willyk

Steht in meinem Footer ....

MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakte
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Rince

Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Rince

ZitatIch habe den cube und einen cul parallel in Betrieb. Ein Teil der Geräte läuft über den Cube, einanderer über den Cul. So habe ich (insgesamt) mehr credits zur Verfügung.

Holla,
du hast da offenbar ein Problem gelöst, welches ich seit 1 Jahr vor mir her schiebe :)


Mehrere Empfänger für Max. Ich brauche es weniger wegen der Credits, sondern eher wegen der Funkabdeckung.

Wie hast du bitte das konfiguriert?
Hast du verschiedene Devices an verschiedene IO Devices gepaired?
Und was passiert, wenn ein Telegramm (z.B. Windows Open) von verschiedenen Empfängern empfangen wird???
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

willyk

Folgendes kann ich empfehlen:

http://www.fhemwiki.de/wiki/MAX

Zitat:  ....  Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Rince

Ach das.
Ne, das ist unspannend.

Praktisch benutzt du so nur den Cube zum senden, den Cul zum (zusätzlichen) empfangen.
Große Vorteile hat das imho nicht. Du darfst weiter brav alles mit der eq3 Frikkelware steuern, nur dass fhem es sofort bemerkt. Der Cube müßte ja gepollt werden...
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Wzut

Zitat von: Rince am 15 Oktober 2015, 11:37:36
Und was passiert, wenn ein Telegramm (z.B. Windows Open) von verschiedenen Empfängern empfangen wird???
in dem Punkt ist die commandref "für mich" eigentlich eindeutig :
Zitat von: commandrefEs ist möglich mehr als ein Gerät zu verwenden, um einen besseren Empfang zu erhalten, FHEM filtert doppelte Funktelegramme aus.
Ich habe vor ein paar Tagen meinem Cube die a-culfw verpasst und betreibe ihn nun im Tandem mit dem USB CUL. Auch hier war IMHO die commandref des CUL eindeutig :
Zitat von: commandrefsendpool
Wenn mehr als ein CUL verwendet wird, um einen größeren Bereich abzudecken, können diese sich gegenseitig beeinflussen. Dieses Phänomen wird auch Palm-Beach-Resort Effekt genannt. Wenn man diese zu einen gemeinsamen Sende"pool" zusammenschließt, wird das Senden der einzelnen Telegramme seriell (d.h. hintereinander) durchgeführt. Wenn z.B. drei CUN's zur Verfügung stehen, werden folgende Attribute gesetzt:
attr CUN1 sendpool CUN1,CUN2,CUN3
attr CUN2 sendpool CUN1,CUN2,CUN3
attr CUN3 sendpool CUN1,CUN2,CUN3
oder unterliege ich da jetzt einem Denkfehler ?
Z.Z. steht der Cube noch nicht allzuweit vom CUL weg, das werde ich am WE ändern.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Rince

Ne, das klingt gut :)

Ich hatte immer den Repeater Modus für SlowRF im Hinterkopf, welches keine doppelten Pakete filtert.

Wenn das mit CUL und CUNO (bzw. umgeflaschten Cube) auch so funzt, wäre es eine sehr lohnende Sache :)


Danke sehr :)

D.h. du hast den Max Modus auf beiden CULs auch identisch konfiguriert?
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

Wzut

#13
Zitat von: Rince am 16 Oktober 2015, 12:13:58
D.h. du hast den Max Modus auf beiden CULs auch identisch konfiguriert?
Ja, und gestern habe ich den CUBE in den am weitesten vom CUL entfernten Bereich umgezogen.
Der anghängte Screenshot zeigt nun schön die aktuelle Situation :
die meisten Telegramme werden nach wie vor vom USB CUL bearbeitet, allerdings mit den schlechten RSSI Werten zwischen -70 & -85
an den Stellen wo die "Nadeln" auf Werte um die -40 hoch gehen hat vermutlich der Cube die Sache abgewickelt.
( ist meine Vermutung, da ich die RSSI Werte schon länger aufzeichne und bis gestern nie solche Effekte hatte )

Einziger Nachteil : den Versionsstring des Cube mit der a-culfw mag das CUL_MAX Modul nicht :
2015.10.16 20:17:08 1: PERL WARNING: Argument "03 a-culfw Build: private build (unknown) CUBe (F-Band:" isn't numeric in addition (+) at ./FHEM/14_CUL_MAX.pm line 147.
2015.10.16 20:17:08 2: CUL_MAX_Check: You are using an old version of the CUL firmware, which has known bugs with respect to MAX! support. Please update.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Rince

Danke für die Rückmeldung :)
Ich schätze es liegt daran, dass der CUL seine Daten schneller an fhem weitermeldet als der Cube. Da hängt ja noch das Netzwerk dazwischen drin.

Ist also nicht so elegant wie die VCCU, aber immerhin wrsentlich besser als nix.


Hast du schon mal geprüft, wie es sich beim senden verhält? Z.b. neue Temperatur setzen?
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)