ELV Max! Funk-Heizungsregler-System - ich habe begonnen ein Modul zu schreiben

[bigcpb]

Hallo,

ich habe den wesentlichen Teil des Max!-Protokoll unter "http://http://www.domoticaforum.eu/viewtopic.php?f=66&t=6654" gefunden und habe begonnen die Analyse der Max!-Cube Daten unter Perl zu implementieren. Hat irgendjemand von Euch Interesse, Zeit, Lust daran mitzuwirken, oder ist da bereits jemand dran und wir können unsere Arbeit koordinieren?

BigCPB

[elanter]

Hi,
ja, ich hätte Interesse daran. Habe einen kompletten Satz Cube, Thermostat, Aktoren, zum Testen zur Verfügung. Noch im Karton, nicht ausgepackt.

Gruß
Elmar
 

[Topos]

Interessantes System. Verstehe ich die Ausführung bei ELV richtig, das der Max! Fenster-Kontakt jede Statusänderung ohne Verzögerung sendet? Der FHT80TF-2 braucht ja immer 1 Minute ehe er sendet.

 

Allerdings scheint der Sender keine Möglichkeit zu haben, externe Kontakte anzuschließen. Kann man da evt. auch improvisieren und direkt auf die Platine löten?

 

Gruß

 

Topos

[Alexander Petrovic]

Es sei aber dazugesagt, dass das beschrieben Protokoll nicht über die
Funkschnittstelle kommuniziert sondern reine TCP/IP (Json)
Kommunikation mit dem LAN-Cube ist.



2012/5/7 Topos <webm...@genesisnet.info>:

> --
> To unsubscribe from this group, send email to
> fhem-users+...@googlegroups.com

[bigcpb]

Hallo,

es ist viel Zeit vergangen seit meinem ersten Posting. Zwischenzeitlich habe ich ein Modul entwickelt, dass die Daten aus den Heizkörperventilen ausließt. Aber es gibt noch offene ToDo's. In dem jetzigen Status ist es nur für die wenigsten brauchbar.
Die Ergebnisse müssen noch in FHEM dargestellt werden und die Aktoren kann ich zur Zeit auch noch nicht steuern.., z.B. die Temperatureinstellung zu verändern.


Gibt es in der "Gemeinde" jemanden, der
   a) bei der Entschlüsselung der Kommandosequenzen behilflich sein will
   b) der sich gut mit den GUI auskennt und mir hift das Ganze im FHEM darzustellen (im Moment analysiere ich das FLOORPLAN-Modul)
Weitere Frage: wenn ich soweit bin es komplett zur Verfügung zu stellen, soll ich es einfach per Git "hochladen"? Oder wie ist hier die übliche Vorgehensweise?

Es gab auch Fragen und Anmerkungen zu meinem ersten Posting, die ich versuche zu beantworten:
1) ja, ich arbeite mit der Netzwerkschnittstelle und nicht mit der Funkschnittstelle, das das für mich einfacher zu analysierne ist.
2) die MAX!Aktoren übertragen ziemlich zeitnah Verändernungen der Aktoren an den MAX!Cube. Im Moment pollt das Modul alle 10 Sekunden die relevanten Daten vom MAX!Cube.

MfG

bigCPB

 

[tobias.faust]

Bzgl Darstellung sollte natürlich auch alles im pgm2 sichtbar sein. Schau dir mal das 67_ECMDDevice Modul an. Das ist relativ übersichtlich.
Bzgl Auswertung kann man das ganze dann mit einem Standard-Plot grafisch aufbreiten

[Stobor]

Hallo,

 

ich selber bin kein Programierer, aber habe eine interessante Website gefunden: www.maxbuddy.de

Vielleicht kann der Entwickler ja helfen.

 

VG

[hgw]

Hi,

hier wäre noch jemand der Interesse hätte mitzuhelfen. Ich bin aktiver Perl Entwickler, kenne mich recht gut mit WebUI Programierung (jQuery, Ajax etc.) aus und haben hier Zuhaus eine komplette Max! Installation (4Regler, 2FensterSensoren plus den Cube). Das was ich noch nicht habe ist eine FHEM Installation. Da ich FHEM jedoch gerne für zukünftige Hausautomations-projekte verwenden möchte und meine bestehende Max! Installation gerne auch in Kombination mit meinen FS20 Schaltern über FHEM betreiben würde wäre ich sehr Interessiert :-)

Viele Grüße HG. 

[Dirk Tostmann]

Am 03.08.2012 um 10:12 schrieb hgw:

> Gibt es in der "Gemeinde" jemanden, der
> a) bei der Entschlüsselung der Kommandosequenzen behilflich sein will

Ich glaube die Zeiten sind vorbei in denen man sich aus Ermangelung an
Hausautomationsalternativen ans entschlüsseln gemacht hat. ELV und all
die Anderen wären besser beraten eine offizielle API zur Verfügung zu
stellen wenn Sie an systemübergreifender Integration Ihrer Lösungen
interessiert wären.

ETH ist schon wieder am verschwinden - Max wird folgen ...

[muellthos]

Warum sollten die Hersteller an einer "systemübergreifenden Integration ihrer Losungen" interessiert sein ??? Das Zeug verkauft sich doch so viel besser. Außerdem würden dann ja ihre Programm und Designfehler sofort offensichtlich. Und so groß ist der Marktanteil von den Leuten, die was systemübergreifendes - oder wenigstens die Möglichkeit dazu- haben wollen, nun auch nicht.  

gruß muellthos

[wollet42]

Hi,
gibt es hier was neues bzw. kann man das Modul schon verwenden?
Ich hab gerade den Max!Cube in Betrieb genommen und würde gerne ein paar Werte in fhem darstellen können.
Gruss,
Wolle

[joachim herold]

Würde mich auch interessieren,

bin auch gerade dabei den Max mit einem Cube in Betrieb zu nehmen.
würde gerne mittesten und forschen, auch gerne mit einem Modul im früh alpha-Stadium.
Perlkenntnisse sind zwar gering, aber ich bin lernfähig.

Gruß Joachim

[Chris]

Würde auch testen hab auch MAX! System am laufen.

Am Sonntag, 6. Mai 2012 16:27:30 UTC+2 schrieb bigcpb:

[Hausautomat]

Ist die Frage, was ihr wollt. Cube via LAN anbinden? Oder die Elemente
direkt via Luftschnittstelle anbinden?

Ich selbst interessiere mich nur für letzteres. Der Cube wird hier so
schnell wie möglich wieder abgeschaltet. Status? Noch keiner -
pre-pre-Alpha, sozusagen. Lediglich für den 00_CUL.pm hatte ich eine
Erweiterung eingebracht, um mit aktuellen CU* überhaupt MAX sprechen zu
können. Kann man zum lesen auch einschalten (s. commandref). Schreiben
muss ich mir noch anschauen, ist derzeit nicht aktiviert (kann auch
gerne wer anders schauen ;-) ).
Und dann kommt erst ein Modul, dass die Nachrichten auswertet.
Fensterkontakte scheinen recht simple, aber so einfach ist's dann doch
wieder nicht. Melde mich hier erst mit Code, wenn's einigermaßen
funktioniert.

Gruß
Hausautomat.

[Alexander Petrovic]

Danke für das Update. Ich befürchte viele unterschätzen den Aufwand ein Protokoll on culw und die Steuerung über fhem zu implementieren.

Um funklast etc zu sparen sind die Protokolle oft etwas verschachtelt und schwer zu interpretieren.

Mit einem einfachen mitschneiden der rf payload ist es ja noch lange nicht getan.

Aber es ist jeder aufgerufen hier mitzuarbeiten

--
To unsubscribe from this group, send email to

fhem-users+unsubscribe@googlegroups.com

[Hausautomat]

Am 04.11.2012 19:19, schrieb Alexander Petrovic:
>
> Danke für das Update. Ich befürchte viele unterschätzen den Aufwand
> ein Protokoll on culw und die Steuerung über fhem zu implementieren.
>

Hör mir auf - sonst hör ich auf ;-)

>
> Um funklast etc zu sparen sind die Protokolle oft etwas verschachtelt
> und schwer zu interpretieren.
>

Etwas ist gut... Ein paar grundlegende Definitionen zu haben, wäre gut.
Damit meine ich nicht das, was hier in HomeMatic schon analysiert wurde.
Hilfreich, aber eben nicht die Lösung des MAX-Protokolls und dessen
Definitionen. Und auch die LAN-Analyse auf domotica ist für die
Luftschnittstelle weitgehend irrelevant.

>
> Mit einem einfachen mitschneiden der rf payload ist es ja noch lange
> nicht getan.
>
> Aber es ist jeder aufgerufen hier mitzuarbeiten
>

So ist es. Fertig analysierte Sequenzen von Pairing, Command-Transmit,
Datenwertanalyse - immer gern willkommen....

Gruß
Hausautomat.

[Chris]

Hmm und was ist mit dem anderen weg über Maxbuddy ?? JSON-Schnittstelle des Onyx-Servers von maxbuddy benutzen ?

Naja da ich den Lan Cube eh habe, könnte ich beide Wege Testen falls es mal etwas zum Testen gibt.

[Hausautomat]

Am 04.11.2012 20:32, schrieb Chris:
> Hmm und was ist mit dem anderen weg über Maxbuddy
> ?? JSON-Schnittstelle des Onyx-Servers von maxbuddy benutzen ?
>

Nix. Denn Maxbuddy braucht Libraries mit MAX-spezifischen Code, die
werden nachgeladen und sind Windows-only. Portabilität = Null. Also Mist.

Gruß
Hausautomat

[drdownload]

Für die User, die Fragen wann es bei MAX etwas zu testen gibt empfehle ich einen Blick in diesen Thread: https://groups.google.com/forum/#!topic/cul-fans/49zs2_vS0M0 und hier geht es nur um rf und noch nicht um die Module in FHEM ;)

[Andy Fuchs]

Am 04.11.2012 um 20:39 schrieb Hausautomat <hausa...@googlemail.com>:

> Nix. Denn Maxbuddy braucht Libraries mit MAX-spezifischen Code, die
> werden nachgeladen und sind Windows-only. Portabilität = Null. Also Mist.

Läuft bei mir auf dem Mac einwandfrei.

andy

[Chris]

es ist ja auch nur eine art Notlösung bis es ein eigenes Modul gibt.

Onyx-Servers mit Maxbuddy läuft auf fast jedem System. Libraries werden automatisch Importiert.

Für jemand der sich mit Fhem auskennt ist so eine Maxbuddy Installation auch kein ding. Von daher wäre dies doch eine gute Notlösung.

[Hausautomat]

>
>> Nix. Denn Maxbuddy braucht Libraries mit MAX-spezifischen Code, die
>> werden nachgeladen und sind Windows-only. Portabilität = Null. Also Mist.
> Läuft bei mir auf dem Mac einwandfrei.
>

Klar, sicher auf auf einem vollwertigen Linux.

Nur eben nicht auf den primären Zielplatformen von fhem. Und closed
source hat mich bisher immer nur vom Schlechten daran überzeugt.

Gruß
Hausautomat

[joachim herold]

@ Hausautomat,

diese Diskussion kenns Du?
--> http://www.mikrocontroller.net/topic/244432#new

MfG
Joachim

[Hausautomat]

Am 05.11.2012 20:11, schrieb joachim herold:
> @ Hausautomat,
>
> diese Diskussion kenns Du?
> --> http://www.mikrocontroller.net/topic/244432#new
>

Jetzt ja.

Das Problem ist doch, dass die FW nicht frei verfügbar ist und
vermutlich nie sein wird.

Dankenswerterweise ist eine culfw verfügbar, mit der wir MAX-Nachrichten
empfangen können,
00_CUL kann die aufnehmen/anzeigen.

Mir persönlich sind die Fensterkontakte via Airschnittstelle am
wichtigsten, die versuche ich einzubinden. Wenn's klappt, gut, wenn
nicht, war's eben ein Versuch. Wenn das klappt, ist der erste Schritt
getan und ich werde das Modul online stellen.

Gruß
Jens

[Andy Fuchs]

Am 05.11.2012 um 19:52 schrieb Hausautomat <hausa...@googlemail.com>:

> Klar, sicher auf auf einem vollwertigen Linux.
>
> Nur eben nicht auf den primären Zielplatformen von fhem. Und closed source hat mich bisher immer nur vom Schlechten daran überzeugt.

versteh' ich jetzt nicht: Zählst Du OS X nicht zu einer 'primären Zielplatform von fhem'? Dafür läuft's ziemlich gut da drauf ;-) (nativ, versteht sich)

andy

[joachim herold]

Moin Jens,

Bei den Fensterkontakten ist mir der Funk-Fenster-Drehgriffkontakt HM-Sec-RHS deutlich lieber, da vielfaeltiger zu verwenden (Rolladen stoppen, wenn Terrassentuer offen, Alarmanlage fuettern, Heizung herabregeln, wenn Fenster offen, uva)
von daher ist die Einbindung des Max über die Luftschnittstelle fuer mich kein muss.
Da nach meinem bisherigem Kenntnisstand durch ein unterschiedliches SyncWord keine gemischte Nutzung von Homematic und Max moeglich ist, wuerde das bedeuten, dass man 2 Cul benoetigt (1x Homematic und 1x Max).
Dann kann man auch gleich die Lanschnittstelle des Cube nutzen. der als LAN-Geraet im Haus auch noch besser zu Positionieren ist, und wo das Protokoll schon ziemlich bekannt ist.
--> http://www.domoticaforum.eu/viewtopic.php?f=66&t=6654&hilit=max               ELV MAX! protocol description
--> http://www.domoticaforum.eu/viewtopic.php?f=66&t=7015                              ELV Max! Radio Signal Protocol 868.3MH

leider habe ich im Moment diverse andere offene Baustellen, die ich ersteinmal bearbeiten muss.

MfG
Joachim

[Hausautomat]

Am 05.11.2012 21:52, schrieb joachim herold:

Moin Jens,

Bei den Fensterkontakten ist mir der Funk-Fenster-Drehgriffkontakt HM-Sec-RHS deutlich lieber, da vielfaeltiger zu verwenden (Rolladen stoppen, wenn Terrassentuer offen, Alarmanlage fuettern, Heizung herabregeln, wenn Fenster offen, uva)von daher ist die Einbindung des Max über die Luftschnittstelle fuer mich kein muss.

Da nach meinem bisherigem Kenntnisstand durch ein unterschiedliches SyncWord keine gemischte Nutzung von Homematic und Max moeglich ist, wuerde das bedeuten, dass man 2 Cul benoetigt (1x Homematic und 1x Max).
Dann kann man auch gleich die Lanschnittstelle des Cube nutzen. der als LAN-Geraet im Haus auch noch besser zu Positionieren ist, und wo das Protokoll schon ziemlich bekannt ist.
--> http://www.domoticaforum.eu/viewtopic.php?f=66&t=6654&hilit=max               ELV MAX! protocol description
--> http://www.domoticaforum.eu/viewtopic.php?f=66&t=7015                              ELV Max! Radio Signal Protocol 868.3MH

Der HM-Griff passt bei mir leider überhaupt nicht (WAF=negativ), so dass ich nach Alternativen gesucht habe und der MAX-Griff scheint eine handelbare Alternative zu sein.

Der CUBE fliegt hier auf Sicht wieder raus, weil so ein intransparentes "Calling Home"-Device (Daten zu ELV) mag ich überhaupt nicht. Bin gerne Herr meiner Daten und weiss, was da passiert. Zumindest rudimentär.

Wenn ich nicht viele Mails schreibe, kann ich in der wenigen Zeit auch mal ein paar Testreihen für mein MAX-Modul machen.
Und nein, das Modul ist nicht annähern reif für eine Veröffentlichung. :-)

Gruß
 Jens

[Hausautomat]

Hallo Andy,

sorry, wenn ich etwas harsch rüberkam. Mir geht's dabei (auch) um dieses
closed-source gehabe von ELV. Und in der Tat ist eine Fritzbox oder
Diskstation (small footprint) eine "primäre Zielplatform". Die wenigsten
leisten sich einen vollwertigen Server daheim (egal welches BS), um
solche Aufgaben zu erledigen.

OSX, Linux oder WHS sind - soweit ich es wahrnehme - sekundäre
Zielplatformen. Nicht umsonst ist alles in Perl, portabel auf alle
(relevanten) Platformen ohne wenn und aber.

Aber die Diskussion driftet ab. Ich arbeite, zunächst für mich, an einem
MAX-Modul (Fensterkontakte). Was da mal draus wird, hey, keine Ahnung :-)

Gruß
Jens

[joachim herold]

Jens,
ich will Dich auch garnicht drängen, da mir die Cube-Variante mangels Cul im Moment sowiso besser gefaellt,
und da hatte bigCPB als Treadstarter ja schon begonnen, nur leider keine weitere Rueckmeldung mehr abgegeben.

Ich werde einfach mal abwarten, was denn da kommt, oder mich irgendwann selber dran setzen.

Mfg Joachim

[Andy Fuchs]

Am 05.11.2012 um 22:08 schrieb Hausautomat <hausa...@googlemail.com>:

> sorry, wenn ich etwas harsch rüberkam. Mir geht's dabei (auch) um dieses closed-source gehabe von ELV.

Null problemo...

> Und in der Tat ist eine Fritzbox oder Diskstation (small footprint) eine "primäre Zielplatform".

Hm... ich glaube, da haben wir einfach unterschiedliche Auffassungen. Die Fritzbox ist für mich ein DSL-Modem mit -Router; nicht mehr - und nicht weniger. *Für mich* macht es überhaupt keinen Sinn, da irgendwas ausser der Standard-Funktionalität drauf laufen zu lassen. Für das ganze andere Zeugs bräuchte ich ja dann doch wieder einen Server.

> Die wenigsten leisten sich einen vollwertigen Server daheim (egal welches BS), um solche Aufgaben zu erledigen.

fhem ganz wunderbar auf einem 'stinknormalen' MacMini (auch ohne Server), oder beispielsweise einem kleinen Synology-NAS - und wenn ich das hier richtig verfolgt habe, auch auf einem Raspberry Pi.

> OSX, Linux oder WHS sind - soweit ich es wahrnehme - sekundäre Zielplatformen. Nicht umsonst ist alles in Perl, portabel auf alle (relevanten) Platformen ohne wenn und aber.

Tja - ich hätte das irgendwie genau andersrum gesehen. Auf dem Mac muss ich nichtmal Perl nach-installieren, um fhem laufen zu lassen.

> Aber die Diskussion driftet ab. Ich arbeite, zunächst für mich, an einem MAX-Modul (Fensterkontakte). Was da mal draus wird, hey, keine Ahnung :-)

Aber Du hast recht... es driftet ab; ich wollte es dennoch etwas gerade ziehen, nicht dass hier Leute verschreckt werden. ;-)

Viel Spaß jedenfalls - und immer schön portabel halten :-))

andy

[Hausautomat]

Am 05.11.2012 22:23, schrieb Andy Fuchs:
>> Und in der Tat ist eine Fritzbox oder Diskstation (small footprint) eine "primäre Zielplatform".
> Hm... ich glaube, da haben wir einfach unterschiedliche Auffassungen. Die Fritzbox ist für mich ein DSL-Modem mit -Router; nicht mehr - und nicht weniger. *Für mich* macht es überhaupt keinen Sinn, da irgendwas ausser der Standard-Funktionalität drauf laufen zu lassen. Für das ganze andere Zeugs bräuchte ich ja dann doch wieder einen Server.

Ich selbst nutze ja auch einen richtigen Computer als Server, auch für
Hausautomation. ;-)

> Aber Du hast recht... es driftet ab; ich wollte es dennoch etwas
> gerade ziehen, nicht dass hier Leute verschreckt werden. ;-) Viel Spaß
> jedenfalls - und immer schön portabel halten :-)) andy

Da arbeiten wir alle dran, oder? Und Spass dabei ist in der Tat wichtig.
Am Ende ist und bleibt es ein Hobby und Erwachsenenspielzeug, oder? ;-)

Gruß
Jens

[Andy Fuchs]

Andy

Am 05.11.2012 um 22:52 schrieb Hausautomat <hausa...@googlemail.com>

> Ich selbst nutze ja auch einen richtigen Computer als Server, auch für Hausautomation. ;-)

Wozu quälst Du Dich dann mit der Fritzbox ab? ;-)

> Da arbeiten wir alle dran, oder? Und Spass dabei ist in der Tat wichtig. Am Ende ist und bleibt es ein Hobby und Erwachsenenspielzeug, oder? ;-)

Kommt drauf an :-))

Andy

[Willi]

Je länger ich über MAX! nachdenke, desto besser gefällt es mir. Ich wollte so und so meine FHT80b ablösen (machen mehr und mehr Zicken) und HM ist doch recht teuer (1 x zum Test mit HMLAN im Einsatz).

Gibt es eigentlich bis auf die Tatsache, dass der MAX!-Cube eine Black-Box ist, einen Vorteil für eine CUL-Lösung? Preislich scheint ja kaum ein Unterschied, da man einen eigenen CUL braucht (49,95 EUR Cube gegenüber CULv4 mit 44 EUR).

Ich habe verstanden, dass das Funkprotokoll des MAX! kompliziert ist und daher vermutlich eine Realisierung für FHEM mit CUL sehr lange dauern kann, wenn überhaupt.

Dagegen ist man beim zitierten Domoticaforum schon sehr weit, was das Analysieren der Netzwerkkommunikation des MAX!-Cube angeht.

Oder habe ich da etwas übersehen?

MfG Willi

[Rudolf Koenig]

> Ich habe verstanden, dass das Funkprotokoll des MAX! kompliziert ist und

> daher vermutlich eine Realisierung f�r FHEM mit CUL sehr lange dauern kann,
> wenn �berhaupt.

Ohne es selbst geprueft zu haben: nach den ersten Dumps von Dirk (siehe auch
cul-fans) schien das Funk-Protokoll eher einfach zu sein, er hat mWn auch
etliche Werte entschluesselt (eingestellte Temperatur, Ventilstellung), und
Temperatur Setzen konnte er auch, mit einem "geborgten" id.

Vmtl. braucht man fuer ein ordentliches Fhem-Modul, der vom CUL gespeist wird,
auch ein Cube, damit man die verschiedenen Operationen mitlauschen kann.
Interessant waere also die CUL Loesung nur dann, falls der Cube Buggy ist, oder
irgendwelche Werte nicht weitergibt. Oder wenn man prinzipiell nicht auf
closed-source setzen moechte, und das dem Herrstellern indirekt unter die Nase
reiben will :)

[Willi]

Ohne es selbst geprueft zu haben: nach den  ersten Dumps von Dirk (siehe auch
cul-fans) schien das Funk-Protokoll eher einfach zu sein, er hat mWn auch
etliche Werte entschluesselt (eingestellte Temperatur, Ventilstellung), und
Temperatur Setzen konnte er auch, mit einem "geborgten" id.

Ok. 

Zwei Vorteile beim Einsatz von CUL sind mir noch eingefallen:

- Redundanz für das Hausautomatisierungssystem läßt sich relativ günstig erreichen. Einen CUL braucht man so und so als Ersatz, wenn man schon CUL einsetzt und bei HW-Defekt nicht im Dunkeln stehen will. Den kann man dann bei Ausfall des MAX-CUL auch verwenden.

- Vermutlich wesentlich geringerer Stromverbrauch (Ethernet-Chip und stromhungriger Prozessor fällt weg)

[Hausautomat]

>> Ich habe verstanden, dass das Funkprotokoll des MAX! kompliziert ist und

>> daher vermutlich eine Realisierung für FHEM mit CUL sehr lange dauern kann,
>> wenn überhaupt.

> Ohne es selbst geprueft zu haben: nach den ersten Dumps von Dirk (siehe auch
> cul-fans) schien das Funk-Protokoll eher einfach zu sein, er hat mWn auch
> etliche Werte entschluesselt (eingestellte Temperatur, Ventilstellung), und
> Temperatur Setzen konnte er auch, mit einem "geborgten" id.

Na, so ganz einfach ist es dann doch nicht. Gut, nicht für mich ;-)

Ich habe in 00_CUL.pm jetzt eine Option zugefügt "maxPairForSeconds" -
Basisarbeit für den Max (inkl. Doku). Das 10_CUL_MAX.pm ist noch lange
nicht so weit, dass man es auch nur annähernd als Alpha betrachten
könnte. Pairing mit dem Fensterkontakt klappt noch nicht, an den
Thermostat denke ich also noch garnicht.

> Vmtl. braucht man fuer ein ordentliches Fhem-Modul, der vom CUL gespeist wird,
> auch ein Cube, damit man die verschiedenen Operationen mitlauschen kann.

Um dann erstmal zu verstehen, was der da eigentlich macht. Allein, dazu
braucht's schon was mehr Zeit.

[Dirk Tostmann]

Am 06.11.2012 um 18:25 schrieb Willi:

Zwei Vorteile beim Einsatz von CUL sind mir noch eingefallen:

Ein grosser Kritikpunkt für Max!-Cube war/ist auch die nicht-Erweiterbarkeit des Funkradius. Heisst: Wenn der Cube nicht in der Mitte des Hauses steht, also alle Aktoren erreichen kann - klappts nicht mit der Steuerung … So mal implementiert ist mit CUL oder gar CUNO eine großflächigere also auch funktechnisch sicherere Lösung aufbaubar, als mit einem einzelnen Cube.

[Andy Fuchs]

On 09.11.2012, at 06:49, Dirk Tostmann <tost...@gmail.com> wrote:

> Ein grosser Kritikpunkt für Max!-Cube war/ist auch die nicht-Erweiterbarkeit des Funkradius. Heisst: Wenn der Cube nicht in der Mitte des Hauses steht, also alle Aktoren erreichen kann - klappts nicht mit der Steuerung … So mal implementiert ist mit CUL oder gar CUNO eine großflächigere also auch funktechnisch sicherere Lösung aufbaubar, als mit einem einzelnen Cube.

Man darf allerdings auch nicht vergessen, dass ein zweiter Cube weniger kostet als z.B. ein Fritzbox-Repeater, was diesen Kritikpunkt einigermaßen entschärft...

Ich, als bekennender CUNO-Fan, wäre allerdings auch der erste, der den Cube zugunsten eines CUNOv3 aussortieren würde :-)

andy

[bigcpb]

Hallo FanGemeinde, ich hatte jetzt länger keinen Zugriff auf das Internet und kann mich erste jetzt melden. Aus beruflichen und gesundheitlichen Gründen konnte ich das Modul nicht weiterentwickeln. G. der sich erst anbot die grafische Oberfläche zu schreiben hat seine MAX Module verkauft und somit kein Interesse hieran weiter zu arbeiten.
Ich selbst muss mich mehr um meine Gesundheit und auf meine Arbeit konzentrieren.... In diesem Jahr werde ich mich vermutlich nicht mehr der Perl-Programmierung widmen können.
Falls einer von Euch das MAX-Modul mit dem Cube finalsieren möchte, bitte melden. Eventuell ist das ja so geschrieben,dass ein Perl-Programmierer damit etwas anfangen kann?? Die Ausleseroutinen sind fertig und MAX lauft bei mir im Hintergrund - ohne Ausgaben und die Möglichkeit von außen einzuwirken fehlt auch noch. Wenn man das Modul 01_FHEDMWEB.pm einwenig erweitert, dann erhält man auch alle Informationen aus den MAX!-Termostaten angezeigt.

BigCPB

Am Sonntag, 6. Mai 2012 16:27:30 UTC+2 schrieb bigcpb:

Hallo,

ich habe den wesentlichen Teil des Max!-Protokoll unter "http://http://www.domoticaforum.eu/viewtopic.php?f=66&t=6654" gefunden und habe begonnen die Analyse der Max!-Cube Daten unter Perl zu implementieren. Hat irgendjemand von Euch Interesse, Zeit, Lust daran mitzuwirken, oder ist da bereits jemand dran und wir können unsere Arbeit koordinieren?

BigCPB

[Polytheus]

Hi,

Wo finde ich deinen Code? Ist der für MAX mit CUL oder für den MAX Cube über LAN?
Ich hab unter
https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/pdFUO0Gus_8
meinen Code für den MAX Cube per LAN veröffentlicht.

Viele Grüße,
Matthias

--

To unsubscribe from this group, send email to

fhem-users+...@googlegroups.com