MAX über FHEM steuern ohne erneutes Pairing?

[akstrike]

Moin zusammen,

bin seit 1 Woche mit FHEM zugange und habe eine Verständnisfrage:
Umgebung: diverse MAX HT, FK, ECO, Max Steckdosen am MAXLAN, RasPI, CUL 868, HUE

Vorab: Es läuft alles bisher gut.
Habe alles vor einiger Zeit (4 Wochen) über den Max Cube eingestellt (Zeiten, Räume, HTs+FK) und dann letzte Woche FHEM auf dem PI installiert, den CUL geflasht (nicht über FHEM) und mit define ml MAXLAN 192.168.1.175 in FHEM eingebunden. Er hat auch alle Komponenten brav gefunden. Mehr habe ich bisher nicht gemacht.

Ich habe nun gelesen, dass der CUL/FHEM jetzt quasi nur mithört was der Cube macht, man aber keine Einstellungen vornehmen kann, dafür muss man die MAX Komponenten direkt mit dem CUL pairen. Ich kann aber sehr wohl über FHEM die Temperaturen an den HTs verändern und das auch fast in Echtzeit (3-7 sec. Verzögerung idR).

Meine Frage: Habe ich da irgendetwas falsch verstanden oder wozu muss man dann alles komplett resetten und ein neues Pairing am CUL durchführe, wenn es auch so geht?

Gruß aus dem Norden
Till

[Harald]

Hallo akstrike,
so wie Du habe ich mein System auch aufgesetzt. Genau so funktioniert das bei mir auch. Allerdings ist hier

Ich habe nun gelesen, dass der CUL/FHEM jetzt quasi nur mithört was der Cube macht, man aber keine Einstellungen vornehmen kann, dafür muss man die MAX Komponenten direkt mit dem CUL pairen. Ich kann aber sehr wohl über FHEM die Temperaturen an den HTs verändern und das auch fast in Echtzeit (3-7 sec. Verzögerung idR).

denke ich, ein kleiner Gedankenfehler.

FHEM holt sich m.W. mittels der MAX-Module über MAXLAN via Polling die Infos vom Cube und verarbeitet sie. Das Pollingintervall (hier 180 sek) wird bei der Definition von MAXLAN (define MAXLAN MAXLAN 192.168.0.222 180 ondemand) mit angegeben . Umgekehrt läuft das ähnlich. Soll ein Befehl z.B. an einen Thermostaten geschickt werden, spricht FHEM MAXLAN an. Von dort wird er über LAN an den Cube gegeben. Dieser schickt ihn weiter an das Ventil.
Der CUL wird dabei nicht gebraucht. Ich vermute, wenn man MAX-Geräte parallel zum Cube auch noch am CUL incl. "attr rfmode MAX" anmeldet, dass es dann zu Problemen führen könnte. Ich denke, dann weiß das Gerät nicht, wer der Chef ist und wessen Befehl es gehorchen soll.
Ich kann mich aber irren, da ich so etwas noch nie ausprobiert habe. Bei mir klappt ja alles ohne CUL-Anmeldung. Den nutze ich nur für andere Komponenten.

Falls ich hier Unsinn geschrieben habe, möge das jemand korrigieren, der tiefer in der Materie steckt. Würde mich freuen, wenn ich weiter dazu lernen könnte.

Viele Grüße

Harald

[akstrike]

Hallo Harald,

danke für die Info. Das würde es erklären! D.h. dann, dass man, je nach dem ondemand-Wert (den ich bisher noch nicht gesetzt hatte) nur eine entsprechende Verzögerung hätte. Damit kann ich leben und den CUL auch für andere Komponenten nutzen  .

Gruß
Till

[willyk]

Hallo, ich habe das gleiche Setup. Die Steuerung erfolgt über den Cube. Der CUL (bei rfmode MAX) "hört mit". fhem zeigt das auch:

Internals:
   DEF        WallMountedThermostat 0a0793
   IODev      maxcube
   LASTInputDev cm
   

Das IODEV ist der cube, das LASTInputDev ist der CUL.

Der ondemand-Wert hat was mit dem Pollen (Abfragen) der Werte durch fhem zu tun. Eine Verzögerung tritt für den EMpfang von Werten auf, aber nicht beim Senden von Kommandos. Das kannst Du sehen, wenn der ondemand Parameter gesetzt wird, da dann die Verbindung auf- und wieder abgebaut wird, z.B.:

2015.01.14 07:17:42 3: Opening maxcube device 192.168.0.120:62910
2015.01.14 07:17:42 3: maxcube device opened


Gruss
willyk

[Harald]

@ willyk,

Du hast ja grundsätzlich Recht damit, dass der Cube die Steuerung übernimmt. Aber auch das Auslesen der Werte der MAX!-Geräte wird vom Cube über MAXLAN bewerkstelligt und somit stehen sie in FHEM zur Verfügung. Du schreibst selbst, dass das "I(n)O(ut)Dev(ice)" maxcube ist. Also funktioniert das in beiden Richtungen.
Ich verstehe dashalb nicht, warum Du unbedingt mittels des CUL und rfmode MAX die Daten nochmal mitlesen möchtest. Ob das zu Kollisionen führt, kann ich nicht beurteilen, aber m.M.n. kann man sich den CUL sparen bzw. für andere Zwecke nutzen.
Hat man nämlich das Attribut rfmode MAX gesetzt, kann, so viel ich weiß, der CUL nur MAX-Signale interpretieren. Sonst müsste man ständig hin und her schalten mit dem Nachteil, dass dann, wenn z.B. rfmode SlowRF aktiv ist, die MAX-Signale nicht empfangen werden können und umgekehrt.
Als ich mit MAX! und FHEM angefangen habe, gab es auch Probleme mit diesem Umschalten. Das klappte nicht immer einwandfrei wenn ich mich richtig erinnere. Ob das heute bereinigt ist, kann ich nicht beurteilen. Da könnte vielleicht Matthias etwas dazu sagen?

Wie schon geschrieben, setze ich keinen CUL zum Mitlesen der MAX-Signale ein und das System arbeitet zu meiner vollsten Zufriedenheit.

@ akstrike,

in der Commandref ist unter MAXLAN beschrieben, wie man das nutzen kann. Da findest Du auch was ondemand und weitere Parameter bewirken.

Viele Grüße

Harald

[akstrike]

Hi Harald,

danke für die Info. Habe das ondemand jetzt auch auf 180 gesetzt und siehe da, jetzt kann ich auch wieder ohne Probleme auf die Max Software zugreifen (ohne den FHEM Server zu killen). Für das ändern der Wochenprogramme ist das irgendwie etwas einfacher.
Und es funktioniert top. Kann alles bedienen/ändern und auslesen ohne den Cul. Für meine Zwecke reicht das. Ich habe lediglich 2 Floorplans erstellt und dort alle Heizungen, Fenster und Steckdosen eingetragen, funzt prächtig.

@ willyk / Harald
Welchen tatsächlichen Vorteil würde es bringen, wenn man nur den CUL nutzen würde? Weitere Optionen? Performance? Und zweitens: Ich habe das kleine Problem dass ich 16 Räume definiert habe/hatte und das gab Verbindungsprobleme. Mit 12 gehts aber 4 Ventile habe ich ablernen müssen und betreibe sie ohne den Cube. Könnte man diese über den CUL dann zusätzlich wieder mit einbinden?

Gruß
Till

[Harald]

Uii, das sind eine Menge Räume! Ich habe nur 5 mit 7 Ventilen und einem ECO-Taster. Wieviele MAX!-Geräte hast Du denn am Cube angemeldet? Nach ELV kann der Cube ca. 50 Geräte verwalten.
Hast Du evtl. John's Temperaturscanner im Betrieb? Der kommoniziert recht häufig mit dem Cube und benötigt dazu eine entsprechende Anzahl von DutyCycles. Wenn die aufgebraucht sind, wird der Datenaustausch gestoppt, bis wieder genügend DC zur Verfügung stehen.

Ach ja, zum Einsatz eines CUL für die Verwaltung von MAX!-Geräten kann ich Dir nicht viel sagen, da ich da keine Erfahrung habe. Mein Konzept basiert darauf, dass die Heizungssteuerung autark über den Cube laufen soll, damit das auch klappt, wenn FHEM mal ausfällt. FHEM überwacht das MAX!-System und greift nur zum Optimieren ein. So läuft z.B. John's Temperaturscanner, der dafür sorgt, dass die Temperaturkurven der Ventile zyklisch aktualisiert werden.

Viele Grüße und schönes Wochenende

Harald

[willyk]

@ willyk,

Du hast ja grundsätzlich Recht damit, dass der Cube die Steuerung übernimmt. Aber auch das Auslesen der Werte der MAX!-Geräte wird vom Cube über MAXLAN bewerkstelligt und somit stehen sie in FHEM zur Verfügung.

Das ist richtig. Allerdings werden die Werte des Cube nur in dem angegebenen ondemand-Interval aktualisiert, oder wenn die Verbindung zum Cube aktiviert wird. Das bedeutet die Werte werden ungenau, speziell wenn man die Ist-Temperaturen aufzeichnen möchte.

Wenn der CUL im rfmode max arbeitet, wird eine Antwort sowohl vom CUL wie auch vom cube empfangen; fhem bekommt das dann über den CUL einfach nur früher mit. Das muss man nicht getrennt konfigurieren, das geht völlig automatisch.

@akstrike:
In meiner Installation habe ich 14 Räume definiert; davon sind 8 beim cube und 6 mit dem CUL gepaired. Der Vorteil ist natürlich, dass die credits des CUL bzw. duty-cycles des cube nicht so schnell zur Neige gehen.

Gruss
willyk

[Rince]

Ich hab 13 Thermostatventile an einem CUL.

Im großen und ganzen läuft es gut.

Habe mir aber in der 99_myUtils eine Funktion eingebaut, um den Scanner an allen Thermostaten de/aktivieren zu können.
Braucht man dann, wenn man das Wochenprofil dauerhaft außer Kraft setzen will, z.B. wenn man wg. längerer Abwesenheit Eco setzen möchte.


So 2-3 mal pro Tag sagt das Logfile, dass die Credits ausgegangen sind. Aktuell habe ich 597

Ich möchte bei Gelegenheit mal die Credits in ein Logfile schreiben lassen um zu sehen, wie es sich damit so verhält.

[Harald]

Hallo Rince,

ich schreibe mir die DutyCycles des MAXLAN (habe einen Cube) in eine Datei und von dort aus in ein Diagramm. Dann kann ich besser erkennen, was da passiert. Ist schon ganz interessant.

Viele Grüße und schönes Wochenende

Harald

[Rince]

Magst du mir kurz das DEF posten bitte?

[Harald]

Hmm, ich weiß jetzt nicht, was Du meinst.
Ich lasse DutyCycle in das Log von MAXLAN schreiben

Code Auswählen Erweitern

define FileLog_MAXLAN FileLog ./log/MAXLAN-%m-%U.log MAXLAN:(dutycycle).*
Diese Werte hole ich mir und lasse sie in meinem Diagramm "Heizung" mit darstellen

Code Auswählen Erweitern

define FileLog_Heizung FileLog ./log/Heizung-%m-%U.log (Vorlauf|Ruecklauf|Wetter|GasZaehler|MAXLAN).(T:|onoff:|cntPerDay:|RSSI:|dutycycle:).*
Vielleicht hilft Dir das weiter. Sonst sage mir bitte genauer, was Du benötigst.

Viele Grüße

Harald

[Rince]

Danke. Den FileLog Teil hab ich auch. Nur wird leider beim Cul kein Event getriggert, wenn ich die Credits prüfe. Daher bleibt das Logfile leer.
Aber ich schätze, hier wird es etwas OT

[Harald]

Bei mir gibt ein Readings "credit10ms" beim CUL. Vielleicht kannst Du damit etwas anfangen?

Viele Grüße

Harald

[Rince]

Selbiges nutze ich theoretisch.

Damit das aktualisiert braucht es ein get CUL0 credits10ms

./log/CUL0-%m-%U.log CUL0:(credit10ms).*