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)

Wzut

Zitat von: Rince am 18 Oktober 2015, 09:29:09
Hast du schon mal geprüft, wie es sich beim senden verhält? Z.b. neue Temperatur setzen?
Ja , kein Unterschied zum Empfang. Für mich war wichtig erst  einmal an die Grenze des aktuellen Sende/Empfangsbereich des CUL zu gehen und dann im nächsten Schritt einen Raum noch dazu zu nehmen der noch weiter entfernt liegt und der dann zu 100% vom Cube abgedeckt werden muss.
D.h. für mich in einem Mehrfamilienhaus mit drei Wohnebenen :
Cul im ersten Stock , versorgt zu 100 % das darüber liegende Dachgeschoss , zu 100% den ersten Stock und ca. 50% des EG.
Die z.Z noch fehlenden 50% Funkabdeckung im EG werden dann vom Cube im Keller durch die Decke abgewickelt - bzw. ich kann mir dann sogar vermutlich den Luxus leisten den bisher ungenutzten Heizkörper in der Waschküche (auch im Keller) an manchen Wintertagen auch noch dazu zu nehmen. ( das Basic HT ksotet ja gerde mal 20 Öre) :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wzut

Update :
Theorie ist eine Sache, Praxis eine ganz Andere ...
Nachdem ich ja meine Funkabdeckung so elegant ausgeweitet hatte habe ich das WT im Grenzbereich an einen für den Raum optimalen Platz umgezogen. Und das war leider ein Griff ins Klo :( , der USB CUL lief danach nur noch am CreditLimit bzw. das logfile war voll von Einträgen das zuwenig Credits verfügbar seien. Kein Wunder durch das Umstellen des WT ist dessen RSSI Wert auf dem CUL auf ca. -99.5 abgesackt. Das der Cube für dieses Gerät das viel bessere Funkdevice wäre davon hat das CULMAX Device natürlich keine Ahnung. Also was tun ? Definieren wir doch einfach ein zweites CULMAX Device und splitten so den Funkverkehr ? Leider nein denn CULMAX gehört z.Z. noch zu den Highlander Geräten ("es kann nur Einen geben ... ") siehe auch :   http://forum.fhem.de/index.php/topic,41103.0.html

Wenn ich wieder etwas mehr Luft habe werde ich den dort gemachten Vorschlag von
Matthias Gehre testen und die betroffenen Zeilen aus dem CUL_MAX Modul entfernen um ein zweites Gerät anzulegen.
Eine andere Idee wäre noch weiter mit nur einem CULMAX Device zu arbeiten aber intern mit Gewalt das IoDev umzuschalten, auf das Gerät von dem das letzte Telegramm empfangen wurde.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

persching

Hat sich hier in den letzten 2 Jahren etwas getan? Ich benötige auch wegen der Reichweite etwas neues. Jetzt habe ich einen CUL an meinem BananaPi und seit heute zusätzlich einen CUBE mit culfw. Ich war eigentlich der Meinung, dass ich in den letzten Tagen irgendwo gelesen habe, dass das Problemlos gehen würde. Aber jetzt weiß ich nicht so genau, ob das so alles richtig funktionieren wird....

Wzut

#18
Zitat von: persching am 30 September 2017, 17:48:31
dass ich in den letzten Tagen irgendwo gelesen habe, dass das Problemlos gehen würde.
Was genau hast du wo gelsen ? Cube mit a-culfw ? Das geht wunderbar, betreibe selbst zwei davon allerdings unter mode hm.
Oder meinst du das Thema mehrere CULs zusammen für MAX! ? Das habe ich seit meinem Post vor zwei Jahren nicht weiter verfolgt. Seit ein paar Monaten kaufe ich nur noch HM sowohl für neue Anwendungen als auch als Ersatz für alte Geräte. Bei HM klappt das mit mehr als einer Sende/Empfangstation unter dem Dach der VCCU super. In der Beziehung ist MAX! IMHO Lichtjahre von HM entfernt, obwohl sie beide aus dem gleichen Stall kommen. Fazit : MAX! ist gut und günstig für Bewohner kleiner Wohneinheiten,
ist die Hütte allerdings etwas größer und kommt ggf. sogar noch ein Aussenbereich dazu kommt man an HM fast nicht vorbei.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

persching

Ich meinte hier im Forum gelesen zu haben dass Cul_Max und Cube parallel funktionieren. Aber ich finde es nicht mehr.
Für einen Ersatz aller Geräte wäre das ziemlich viel Geld. :( Ich habe 9 Thermostate und 8 Fensterkontakte im Einsatz. Dazu einen weiteren Fensterkontakt als digitalen Eingang.

Meine Idee war dass ich die Thermostate und Fensterkontakte vom hinteren Gebäudeteil am Cube mit culfw einzulernen und die vom vorderen Teil am Cul_Max direkt an meinem BananaPi. Könnte das funktionieren? Denn es könnte ja in einem dicht besiedelten Gebiet durchaus sein dass 2 Wohnungen nebeneinander MAX Geräte verwenden. Oder ist das Problem dass ich das an einer Fhem Installation nutzen möchte?

Wzut

Wenn du zwei Inseln mit unterschiedlicher ID und getrennten IO Devices betreiben willst sollte das keine Problem sein. Entsprechend deinem Beispiel der zwei Nachbarn in einem Mehrfamilienhaus. Ich bin halt damals am Versuch der großen Wolke (alles unter einer ID) gescheitert.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

persching

Die ID ist das was ich beim define mit angebe oder? Meistens 123456.

Dann werde ich das mal so probieren. Am jetzigen Cul muss ich die ja nicht irgendwie abmelden, oder?
Ich hätte jetzt nur die Devices mit einem factory reset zurückgesetzt und dann den Cube in den pairing Modus gesetzt.

Wzut

Zitat von: persching am 01 Oktober 2017, 14:29:07
Meistens 123456.
ja, wichtig unbedingt 6 Ziffern !

Zitat von: persching am 01 Oktober 2017, 14:29:07
Ich hätte jetzt nur die Devices mit einem factory reset zurückgesetzt und dann den Cube in den pairing Modus gesetzt.
factory reset ist immer gut , aber Cube im Pairing ? Der CUL unterstützt nur hmPairForSec und das ist wie die ersten beiden Buchstaben schon andeuten HM only !
MAX! Geräte werden mittel des übergeordneten Device CUL_MAX (das mit der ID) und dem Kommando set pairmode 1 angelernt.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

persching

Ich hab das schon lange nicht mehr gemacht und ich hab beides im Einsatz. Hab das wohl durcheinander gebracht...

Ich werde berichten wie erfolgreich ich war.