Probleme mit mehreren MAX Geräten / TempScanner

Begonnen von willyk, 30 Dezember 2014, 23:38:42

Vorheriges Thema - Nächstes Thema

willyk

Zitat von: John am 01 Januar 2015, 13:19:28
Verwendest du die Cube-Software für die Raumeinteilung (Gruppeneinteilung) ?

Ja, Hat das Auswirkungen auf die GroupId?

Zitat von: John am 01 Januar 2015, 13:19:28
Ich schlage vor , daß du UG_Hobby_H komplett löschst, neu definierst und anlernst.
Die GroupID sollt dann 0 sein.

Habe ich gemacht. Die ID ist 0. Es ändert aber nichts am Verhalten; wenn ich über fhem die Temperatur an UG_Hobby ändere, ändert sich das OG_Schlafzi mit.

Zitat von: John am 01 Januar 2015, 13:19:28
Wenn das nicht hilft, würde ich bei allen beteiligten Komponenten einen Factory Reset durchführen, aus FHEM löschen, neu definieren und neu anlernen.

Habe ich versucht. Allerdings habe ich damit den Cube verärgert  :(

Dummerweise habe ich zuerst WT und HT zurückgesetzt, und dann die Geräte aus dem Cube löschen wollen.

Nun kann ich die Geräte nicht mehr löschen - es kommt dann immer die Meldung "Es ist ein Fehler aufgetreten: Bei der Datenübertragung ist ein Fehler aufgetreten. Die Konfiguration wurde nicht übermittelt."

Neu anlernen kann ich die Geräte auch nicht - dann kommt die Meldung "Kommunikation zum Cube gestört".

Werde noch ein wenig rumspielen, aber wahrscheinlich muss ich den Cube (nun zum 3ten Mal) zurücksetzen und alles neu anlernen. Grmpfl. Oder hat jemand eine Idee wie ich den Cube wieder ans laufen kriege?

Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Harald

#16
Guten Morgen willyk,

vermutlich wird Dir wohl nichts anderes übrig bleiben, als das MAX!-System neu aufzusetzen.

Wenn Du in Zukunft Komponenten hinzufügen, entfernen oder ändern möchtest, solltest Du das immer erst in der MAX!-Software durchführen. Der Cube ist der Master, der mit den übrigen MAX!-Geräten kommuniziert. Das ist so ein autarkes System. FHEM ist da nur überlagert und holt und sendet die Infos vom/zum Cube über LAN und nicht von/zu den Thermostaten usw. über Funk direkt.
Wenn ich die Zuordnung (Gruppierung) der div. Komponenten zu den Räumen definiere, Wochenprogramme oder Temperaturen ändere, nutze ich immer die MAX!-Software und mache das nicht von FHEM aus.

Anders sieht es aus, wenn man keinen Cube nutzt und die Geräte über einen CUL mittels "attr CUL rfmode MAX" steuert.

Aber ich denke, das weißt Du auch ohne meine Ausführungen. Jedenfalls viel Erfolg beim neu Aufsetzen.

VIele Grüße

Harald

PS: Ich habe gerade nochmal in der Commandref unter MAX nachgelesen: Die "groupid" der Thermostate können in einem Raum gleich aber > 0 sein.
Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

Harald

#17
Hallo willyk,

ich habe mir nochmal den Auszug Deines Logs angesehen. Kann es sein, dass Du Deine MAX!-Geräte einmal am Cube und ein zweites Mal am CUL angemeldet hast? 
2014.12.31 14:33:18 3: Opening maxcl device 192.168.0.50:2323
2014.12.31 14:33:18 3: maxcl device opened
2014.12.31 14:33:18 3: maxcl: Possible commands: mBCFZiAGMRTVWXOefltuHxEcq
2014.12.31 14:33:18 2: Switched maxcl rfmode to MAX

Was ist den "maxcl" für ein Gerät? Nach den beiden letzten Zeilen oben vermute ich einen CUL, oder? Dort hast Du den rfmode MAX gewählt. Dann versucht maxcl darüber Kontakt zu den MAX-Geräten herzustellen.

Weiter unten wird maxcube geöffnet
2014.12.31 14:33:19 3: Opening maxcube device 192.168.0.120:62910
2014.12.31 14:33:19 3: maxcube device opened

Das bedeutet doch, dass FHEM über LAN mit der Adresse 192.168.0.120, also den Cube auch Daten austauscht, oder liege ich da falsch?

Meldest Du die MAX-Geräte am CUL an und nutzt den "rfmode MAX" benötigst Du den Cube nicht und musst die gesamte Heizungssteuerung über den CUL abwickeln. Willst Du aber das System über den Cube autark betreiben und FHEM nur zum Auslesen der Daten und einigen Steuerungsaufgaben, wie z.B. Johns Scanner u.a. nutzen, darfst Du "attr CUL rfmode MAX" nicht verwenden. In dem Falle werden die Daten und Befehle von FHEM über den Cube, also über LAN und nicht vom CUL über Funk übermittelt. Wenn beides läuft, wissen die MAX-Geräte ja nicht, welchem Chef sie gehorchen sollen ;)

Harald


Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

willyk

Zitat von: Harald am 03 Januar 2015, 11:54:18
Meldest Du die MAX-Geräte am CUL an und nutzt den "rfmode MAX" benötigst Du den Cube nicht und musst die gesamte Heizungssteuerung über den CUL abwickeln. Willst Du aber das System über den Cube autark betreiben und FHEM nur zum Auslesen der Daten und einigen Steuerungsaufgaben, wie z.B. Johns Scanner u.a. nutzen, darfst Du "attr CUL rfmode MAX" nicht verwenden. In dem Falle werden die Daten und Befehle von FHEM über den Cube, also über LAN und nicht vom CUL über Funk übermittelt. Wenn beides läuft, wissen die MAX-Geräte ja nicht, welchem Chef sie gehorchen sollen ;)

Auf die Gefahr hin mich zu blamieren:   ich hatte das bisher anders verstanden.

Alle Geräte sind am Cube angemeldet und werden über diesen konfiguriert und gesteuert. Da mir der Cube zu eingeschränkt ist, möchte ich (bald) auf CUL umstellen. Laut wiki http://www.fhemwiki.de/wiki/MAX wird ein Kombimodus unterstützt; der CUL "hört" nur zu. Dafür braucht es aber das "rfmode MAX", sonst läuft er auf einem andernen Protokoll.

Über welchen Chef die Geräte gesteuert werden, steht im attr IODev.
Eigentlich funktioniert das auch:

Internals:
   DEF        HeatingThermostat 0cea3e
   IODev      maxcube
   LASTInputDev cm
   MSGCNT     297
   NAME       EG_Eingang_H
   NR         33
   RSSI       -61
   STATE      20.5 °C
   TYPE       MAX
   addr       0cea3e
   backend    maxcube
   cm_MSGCNT  61
   cm_TIME    2015-01-03 13:10:05
   dstsetting 1
   maxcube_MSGCNT 236
   maxcube_TIME 2015-01-03 13:09:01
   mode       0
   rferror    0
   serial     KEQ0698053
   type       HeatingThermostat



So sollte es auch möglich sein, Geräte sowohl durch Cube wie auch durch CUL zu steuern - natürlich nicht gleichzeitig.

Oder liege ich da falsch?

Danke für Deine Mühe + Gruss
willyk
NUC mit Ubuntu, MAX!Cube, CUNO, 6 MAX WT, 16 MAX HT, 2 MAX Fensterkontakt, MaxScanner

Harald

#19
Hallo willyk,

also, blamieren wird sich hier keiner ;) Jeder hat Mal angefangen und auch ich bin Anfänger, wenn auch schon etwas länger dabei.

Vielleicht sehe ich das ja auch falsch. Ich vermute aber, wie schon beschrieben, Probleme, Befehle über den CUL und attr CUL rfmode MAX UND über LAN via MAXLAN zu senden. Ob devIO das verhindert, kann ich nicht beurteilen, da ich das noch nicht probiert habe.
Evtl. kann da jemand dazu etwas sagen, der tiefer in der Materie steckt.
Meine oben beschriebene Lösung funktioniert jedenfalls schon lange problemlos.
Du kannst ja Mal versuchen, rfmode MAX zu deaktivieren und sehen, ob sich an Deinem Problemen etwas ändert.

Ich wünsche Dir viel Erfolg und einen schönen Abend noch

Harald

Router:AVM7590 1&1 FW:FRITZ!OS 07.56 Anbindung:1&1 50/10 Mb/s, WLAN-Repeater 300E
ELV MAX!Cube, 7xThermostat, ECO, RasPi 4B mit bullseye auf Festplatte,
CUL V 1.67, JeeLink v3_10.1c, nanoCUL, 1xS300TH, 4xHMS100T, 4xELRO, 1xTFA, 2xMAX_FK
ELV MAX!1.4.5, FHEM 5.7 auf RasPi, Kostal PIKO plus

Sebastian_

Hallo,

ich hatte vermutlich auch dieses Problem. Wie ich hier (http://forum.fhem.de/index.php/topic,11624.msg229906.html#msg229906) beschrieben hatte, wurden bei Benutzung des Scanners auch die Temperaturen einer WT/HT Kombination geändert, bei der definitiv kein "scantemp" in der FHEM.CFG bei den entsprechenden Geräten angegeben war. Nach langem Hin- und Her ohne Lösung hatte ich mich dann dazu entschlossen, den Cube zu resetten und auch die FHEM-Konfiguration zu löschen. Danach habe ich dann das Pairing aller Geräte (WT, HT und FK) und die Zuordnung zu den jeweiligen Räumen mit der ELV/EQ3-Software vorgenommen. Anschließend dann noch FHEM neu konfiguriert. Seit diesem "Reset" läuft auch der Scanner wie er soll.
Was da nun bei Benutzung des Scanners im Zusammenhang mit dem Cube falsch lief kann ich nicht sagen, aber auch ich hatte im Vorfeld mal den Effekt, dass der Cube die Konfiguration verloren hatte.

Gruß
Sebastian

Rince

Zitat von: WikiDas Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können  an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

So wie ich das lese, kannst du an den Cube angelernte Geräte nicht mit einem Cul steuern. Weder gleichzeitig noch mit einem Zeitversatz.

Das Wort "angemeldet" ist wohl ungünstig. Ich denke, es bedeutet nicht "Anlernen".



Auf der anderen Seite:
Wenn du eh vom Cube auf den Cul umsteigen willst, warum machst das nicht gleich jetzt?

Setze ein sinnvolles Wochenprogramm in den Thermostatventilen. Dann fahren die auch vernünftig wenn fhem mal nicht gehen sollte...
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)