Die MAX Module heute und die Aussichten für 2020

[Wzut]

Viele werden es nicht mitbekommen haben, ich habe Ende November den Support für alle MAX Module übernommen.
Dank Hardware Spenden einiger netter User im Marktplatz konnte ich neben meinem aktiven MAX System noch eine Testinsel aufbauen mit einem Cube ( original ELV Firmware). Die ersten beiden Wochen habe ich extrem viel Funktelegramme zwischen dem Cube und den Geräten bzw. der Geräte untereinander gelogt und analysiert.
Ziel war es ein besseres Verständnis der Arbeitsweise der MAX Module zu bekommen. Einige kleine Fehler konnte ich schon fixen und das Logging ist auch stark erweitert.
Das erweiterte Logging bringt Euch im Normalbetrieb nichts, für mich war es aber sehr hilfreich um bestimmte Zusammenhänge besser zu verstehen und Ihr werdet daraus Nutzen ziehen können wenn vllt. mal etwas nicht so ganz rund läuft und es darum geht die Ursache zu finden.

Ich habe schon öfters geschrieben das in meinen Augen das größte Manko von 14_CUL_MAX die Tatsache ist das es nicht mit mehr als einem CUL klar kommt.
In der Beziehung kann man nur neidisch zu HM rüber schielen wo das mit der VCCU in meinen Augen einfach perfekt umgesetzt ist

Aber am Freitag Abend gab es einen kleinen Durchbruch : Ich habe bis jetzt recht erfolgreich zwei CULs und zwei CUL_MAX Devices auf meinem Testsystem gleichzeitig laufen. So wird es vermutlich ab Januar 2020 möglich sein ein ganzes Haus mit einer FHEM Zentrale und mehreren IOs (USB/Lan) abzudecken !
Das können dann entweder mehrere kleine MAX Inseln mit jeweils einer eignen ID sein oder alles unter dem Dach einer Einzigen. Der Unterschied zur HM VCCU ist allerdings das es bis jetzt noch nicht so schön automatisch läuft was das Senden betrifft, aber beim reinen Empfang arbeiten alle CULs gut zusammen. FHEM hat die Eigenschaft doppelte Telegramme zu erkennen ( Stichwort attr global dupTimeout ) so das man sich als Entwickler darum schon mal nicht selbst kümmern muß, allerdings "gewinnt" das erste Telegramm das ankommt. Dieses muss aber nicht unbedingt auch den besten RSSI Wert haben.
Beim senden bestimmt z.Z. noch der User via dem IODev bzw. CULdev Attribut über welchen CUL sein Endgerät angesprochen wird, aber vllt. kann man ja bei der VCCU noch die eine oder andere Idee klauen.
     

[Plextor]

Hallo Wzut,

ich möchte mein erstes öffentliches Posting im FHEM-Forum dazu nutzen, um dir ein herzliches Dankschön für die Weiterentwicklung im MAX-Bereich zu übermitteln.

Wegen Reichweitenproblemen habe ich seit einiger Zeit zwei zu CUL's umgeflashte MAX-Cubes im Einsatz, was ja bekanntermaßen einige Probleme bereitet. Nun habe ich deine Beta-Module einige Tage getestet und bin richtig begeistert. Endlich kann ich bestimmen, welche MAX-Komponenten mit welchem CUL kommunizieren und habe kaum noch Paketverluste und dadurch auch ein viel besseres Credit-Management.

Also noch einmal ein großes Danke, damit deine Motivation hoffentlich noch längere Zeit erhalten bleibt.

[Wzut]

Ich danke dir ebenfalls für das erste Feedback eines Multi IO Users
Bitte bedenke aber : Auch wenn das jetzt schon recht gut für dich persönlich läuft ist es noch nicht wirklich fertig.
Z.Z. bastele ich :
a. an der Unterstützung für mehr als eine MAX Wolke auf einem FHEM
b. und daran das IO Handling zu verbessern, in dem der User entweder eine Vorauswahl treffen kann (HT Wohnzimmer über CUL1 ) oder automatisch an Hand der besseren RSSI Werte.

So richtig knifflig wird es wenn man a und b zusammen betrachtet ....

[Plextor]

Das hört sich spannend und vielversprechend an.

Ich bleibe am Ball und werde die weitere Entwicklung auf jeden Fall verfolgen und eifrig mittesten...

[Maui]

Wow, das ist Mal ein Weihnachtsgeschenk. 
Ich warte noch die aktuelle Heizperiode ab und dann werde ich intensiv testen und Rückmeldung geben.
So kann ich mindestens eine (virtuelle) fhem instanz loswerden.

[Wzut]

Es ist vollbracht ! Mann kann nun mehr als eine MAX Wolke unter FHEM betreiben und jede Wolke darf auch wieder mehere IOs (CUL) haben.
Ich habe eben die Beta Versionen ausgetauscht.

Seit ein paar Tagen hat 00_CUL ein neues Attribut maxid, bitte einmal update 00_CUL ausführen um diese Version zu erhalten.

Kurzanleitung für zwei MAX Wolken/Inseln : ACHTUNG erfordert mindestens auch zwei CULs (einen pro ID !!!)
1. bei jedem CUL Device das Attribut maxid auf die ID der MAX Wolke setzen die dieser CUL versorgen soll (beim senden)
2. im CULMAX Device das attribut IOgrp setzen , z.b. CUL1,CUL2 darauf achten das die Namen wirklich zu Punkt 1 passen.
3. bei jedem MAX Device das Attribut CULdev auf den Namen des zuständigen CULs setzen, auf keinen Fall leer lassen !
Dieser Punkt ist extrem wichtig, wenn ihr hier den falschen CUL eintragt wird das Senden an das Gerät in jedem Fall scheitern und sehr schnell hat der CUL dann alle seine Credits verbraten !!!

4. FHEM neu starten
 

[Maui]

Schön. Ich hätte ein paar Fragen.
-Hast du einen groben Zeitplan, wann du aus der Beta raus willst? Vielleicht spring ich doch noch auf den Beta-Zug und teste mit. Du scheinst ja einiges geändert zu haben, und das Modul wird mit Sicherheit besser geworden sein. Wurde ja ewig kaum gepflegt.
-maxid finde ich gleich doppelt nicht so schön vom Naming, da a) alles klein, und b) man bei maxid erstmal andere Erwartungen hat. Nur als Info
-Wolken ist für dich ein Satz an MAX-Geräten, welche alle mit einer ID per CULMAX zusammenarbeiten, richtig? Ich sehe keinen Mehrwert, wenn ich eh mehrere CULs pro CULMAX definieren und nutzen kann. Höchstens den historischen, ich muss meine bereits bestehenden Wolken nicht neu pairen und könnte sie so fortführen.

Gruß und Danke, du motivierst mich, dass ich meine MAX-HW doch noch nicht bald entsorgen muss

[Plextor]

Noch einmal danke für deinen Einsatz für die immer kleiner werdende MAX-Gemeinde.

Genau wie Maui habe ich allerdings den praktischen Mehrwert von mehreren Wolken/Inseln noch nicht verstanden. Kannst du uns den Unterschied zwischen 2 CUL's in einer Wolke und jeweils einem CUL in zwei Wolken erklären? Hat die eine Lösung Vorteile gegenüber der anderen?

Irgendwie stehe ich gerade auf der Leitung...

[Wzut]

-maxid finde ich gleich doppelt nicht so schön vom Naming, da a) alles klein, und b) man bei maxid erstmal andere Erwartungen hat.

Ich habe mich da 00_CUL angepasst , da gab es für Homematic schon das Attribut hmid und für mich war es logisch da weiter zu machen mit maxid 
Aber anyway , diese maxid ist nur wirklich wichtig wenn wer unbedingt diese zwei/drei Wolken/Inseln unter einer FHEM Instanz haben will.
Ich geb dir und Plextor völlig Recht, ich würde es bei mir auch nicht machen sondern immer den Weg gehen viele IOs aber nur eine ID.

Zeitplan : Das 10_MAX könnte ich eigentlich sofort einchecken, möchte aber damit nochmal zurück auf den Original Cube zusammen mit MAXLAN
um ganz sicher zu sein da keine negativen Auswirkungen zu haben.
Das 14_CUL_MAX könnte ich auch raushauen, wäre aber schön doch noch etwas mehr Feedback über Multi IO zu haben.

Fertig sind beide Module noch nicht , zumindest ich kenne da noch Schwachstellen die mir nicht gefallen :
a. Das Pairing und Peering von Fensterkontakten ist höflich gesagt suboptimal.
b. ich träume auch noch davon das Multi IO Handling etwas dynamischer wie bei HM zu machen statt wie jetzt starr

[Maui]

Das pairing von FK empfinde ich jetzt auch schon als lästig. Die HTs zicken da nicht so. Von den FKs bekommt man häufig einen rf error zurück und nicht immer ist mir ersichtlich warum. Bzw. Nach dem Wechsel eines CUL mit gleicher culmax id laufen die HTs super und die FKs muss ich resetten und neu pairen wenn ich keine rf errors will.

Gruss

[Wzut]

Ja da man WTs und HTs jederzeit direkt ansprechen kann ist das alles kein Problem. Die FKs schlafen halt die meiste Zeit und wachen nur auf wenn der Reedkontakt betätigt wurde oder der Config Button gedrückt wurde oder eben auch x mal am Tag um ihren Status los zu werden wenn sie mit einer Zentrale gepaired sind.
Die Orginal ELV Software mit dem Cube macht das viel eleganter als heute CUL_MAX und da würde ich gerne hin.

rf errors lassen sich aber inzwischen recht gut finden, die neuen debug Attribute sowie ein verbose 5 Log helfen (mir) sehr gut weiter
Ich verlange gar nicht das jeder fit im Log lesen ist, aber erstellen und posten kann jeder, ich helfe dann als Klugscheisser schon weiter .....

[Wzut]

kleines Update :
ich habe die Version im Beta Thread ausgetauscht , neues Get Kommando showSendQueue , Beispiel im Thread

[Wzut]

und das nächste Update  :
10_MAX
neue Set Funktion deviceRename
Vllt. wird so der eine oder andere User doch noch ermutigt seinen MAX Geräten einen anderen Namen als den von autocreate erzeugtem MAX_112233 Namen zu geben. Im Unterschied zum FHEM rename Konsole Kommando werden hier eventuell betroffene FileLogs gleich mit geändert.

neues Attribut externalSensor (device:reading)
Wenn in einem Raum kein Wandthermostat vorhanden ist aber die Raumtemperatur zusätlich mit einem externen Sensor in FHEM erfasst wird (z.B. LaCrosse)
kann dessen aktueller Temperatur Wert zur Berechnung des Readings deviation benutzt werden statt des eigenen Readings temperature

neue Readings peerList und peerIDs  (Name analog zur HomeMatic Welt)
Schon oft im Forum angefragt : Wie lese ich aus einem MAX Device die anderen Geräte aus die mit diesem assoziiert sind (peers) ?
Einfache Antwort : gar nicht , bzw. bis heute ist kein Befehl bekannt der irgend etwas von einem MAX Gerät auslesen kann.
Die jetzt eingebaute einfache Lösung überwacht den Datenaustausch zwischen zwei Geräten und sammelt diese Daten in den beiden Readings.
So kann man z.B. recht leicht herausfinden ob ein Fensterkontakt wirklich mit seinem HT / WT assoziiert ist oder ob er seinen Status lediglich als Broadcast Nachricht verschickt.

Für diese neuen Funktionen wird unbedingt auch die neue Version von CUL_MAX benötigt und auch ein FHEM Neustart ist dringend empfohlen.
Die 10_MAX arbeitet auch mit MAXLAN oder älternen CUL_MAX Versionen zusammen, allerdings stehen dann die hier beschriebenen Neuerungen teilweise oder gar nicht nicht zur Verfügung.

[Maui]

Moin. Ich bin jetzt gestern auch auf den Beta-zug aufgesprungen. Bisher sieht alles gut aus aber multi-CUL kann ich erst testen meine Teile aus china alle da sind.
Bzgl deviation? Wird damit auch aktiv was getan am HT, also mit der Temperatur gearbeitet?
Im Moment nutze ich die max Thermos als Aktor und mit PID20 und ext Sensor wird geregelt. Über maxValve dann eingestellt

[Wzut]

Z.Z. wird deviation (Abweichung) bei jeder aktualisierung berechnet ( IST - SOLL ) durch den externen Sensor wird lediglich für IST statt des Readings temperatur der aktuelle Wert des externen Sensors genommen. Ziel ist es aber das später noch weiter auszubauen (Stichwort fakeWT).