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
Hallo akstrike,
so wie Du habe ich mein System auch aufgesetzt. Genau so funktioniert das bei mir auch. Allerdings ist hier
ZitatIch 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
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
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
@ 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
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
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
Zitat von: Harald am 16 Januar 2015, 14:22:38
@ 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
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.
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
Magst du mir kurz das DEF posten bitte?
Hmm, ich weiß jetzt nicht, was Du meinst.
Ich lasse DutyCycle in das Log von MAXLAN schreibendefine FileLog_MAXLAN FileLog ./log/MAXLAN-%m-%U.log MAXLAN:(dutycycle).*
Diese Werte hole ich mir und lasse sie in meinem Diagramm "Heizung" mit darstellendefine 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
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 ;)
Bei mir gibt ein Readings "credit10ms" beim CUL. Vielleicht kannst Du damit etwas anfangen?
Viele Grüße
Harald
Selbiges nutze ich theoretisch.
Damit das aktualisiert braucht es ein get CUL0 credits10ms
Zitat von: DEF_FileLog./log/CUL0-%m-%U.log CUL0:(credit10ms).*
Klar, der Wert muss natürlich im Log abrufbar sein. Aber das hast Du ja.
Viele Grüße
Harald
Dachte ich auch. Nur bleibt das Logfile quasi jungfräulich :(
Hast Du überhaupt dieses Readings? Bei mir sieht das so aus
Readings
cmds B b C F i A Z E G M K U Y R T V W X e f m l t u x 2015-01-26 11:13:11
credit10ms 900 2014-11-09 22:40:14
fhtbuf AE 2014-11-09 10:27:46
raw is0FF00F0FFFF0 2015-01-26 08:17:46
state Initialized 2015-01-26 11:13:11
version V 1.61 CUL868 2014-11-09 10:27:05
Wie Du siehst, ist der Zeitstempel uralt. Bei mir macht das keine Probleme, da ich dieses Readings nicht benutze. Warum das so ist, muss man evtl. in einem anderen Forenbereich versuchen zu erfahren .
Viele Grüße und viel Erfolg
Harald
ZitatHast Du überhaupt dieses Readings?
Logisch.
Wenn du mal ein get
CUL0 (oder wie du ihn genannt hast) credits10ms eingibst, ist das Reading auch brav aktualisiert :)
Stimmt, klappt. Jetzt muss man das nur noch automatisieren.
Das kann ja ein DOIF übernehmen.
Zitat von: DOIFRelative Zeitangaben
Zeitangaben, die mit Pluszeichen beginnen, werden relativ behandelt, d. h. die angegebene Zeit wird zum aktuellen Zeitpunkt hinzuaddiert.
Anwendungsbeispiel: Automatisches Speichern der Konfiguration im Stundentakt:
define di_save DOIF ([+01:00]) (save)
attr di_save do always
Halt alle 10-60 Sekunden. Müsste man mal ausprobieren was schlau ist.
Nur hilft es nix, wenn im LogFile nix landet ;)
Hm, wenn die Variable in den Readings steht und im Eventmonitor erscheint, sollte sie auch ins Log geschrieben werden, wenn Filelog richtig definiert (Tippfehler?) ist. Sonst habe ich auch keine Erklärung mehr.
Im Eventmonitor taucht sie auch nicht auf.
Puh, dann weiß ich auch nichts mehr. Versuch doch Mal im Bereich Anfänger oder so zu fragen. Vielleicht weiß Rudi oder andere "Wissende" etwas.
Hallo Rince,
ich habe mal eine paar Fragen:
Du arbeitest ja mit MAX-Thermostaten und einem CUL. Welches Modul liest den die Thermostate aus, verwaltet diese und stellt die Readings usw. in FHEM zur Verfügung?
Stehen in den Readings auch die Wochenprogramme und werden die Ventile auch danach gesteuert?
Wenn das so ist, dann arbeitet doch das Modul so wie der Cube, oder?
Der Cube verwaltet ja gesamten Funktionen der MAX!-Komponenten autark und liefert die Ergebnisse via MAXLAN an FHEM.
Viele Grüße
Harald
Ich glaube, ich hab's. Das Modul heißt 14_CUL_MAX.pm. Aber ob es die gleichen Funktionen bietet wie MAXLAN, habe ich nicht gefunden.