Also aus irgendeinem Grund kann ich meinen vorigen Beitrag weder ergänzen noch beantworten, deswegen hier die Ergänzung als neuer Eintrag. Vielleicht kann man die ja später zusammenführen ?
Ich habe in der Zwischenzeit ein brandaktuelles update von Heute durchgeführt. Dann habe ich FHEM mit jungfräulicher fhem.cfg aus einer Telnet-Sitzung heraus gestartet.
Alle Einträge für CULs wurden von FHEM generiert, CUL_0 wurde von mir auf "attr CUL_0 rfmode MAX" gesetzt. Den Thermostat habe ich auf Auslieferzustand zurückgesetzt "rES". Nach der Eingabe von Datum und Uhrzeit wurde schon ein "CULMAX0" angelegt, ohne daß ich die Kopplung veranlasst hätte. Anschließend "CULMAX0" auf "Paaren" gesetzt und die Kopplung mit "BOOST" initiiert.
Ergebnis: Der Thermostat wird zwar erkannt, aber nicht eingerichtet.
fhem.cfg, FileLog und Fehlermeldungen der Shell hänge ich unten an. Vielleicht schaut mal jemand rein ?
Danke.
Mir fällt auf, daß "HT pairt nicht mit fhem [Beitrag #66670]" eine ganz ähnliche Problematik beschreibt, vielleicht kann/sollte man die Beiträge verknüpfen ? Man muß allerdings auch erst mal drauf kommen, was der Schreiber mit "HT" meint.
Hallo,
da ich neu hier bin, möchte ich mich erst mal bedanken für dieses wunderbare open source Produkt und auch, dass Dieses weitergepflegt wird und supported.
Trotzdem habe auch ich Probleme und bekomme die Thermostate (HT) nicht "gepaired"
Ich habe zwei dieser Thermostate bei Conrad gekauft (Comfort "$") Mit dem Fensterkontakt lassen diese sich pairen.
Ich habe FHEM auf einem Raspberry mit COC von busware laufen. FS20 Komponenten liefen auf Anhieb. Mit den MAX Teilen mache ich nun seit Tagen rum aber ohne Erfolg.
Habe u.a. schon folgendes ausprobiert:
-Fhem hoch und runter gepachted/geupdated
-so ziemlich alle Firmwarstände ausprobiert
-fhem conf hoch und runter geändert
-fhem Forum abgegrast und die Beiträge nachgestellt, ausprobiert (Rechte, 00_CUL.pm ändern, fhem.cfg usw.)
-HT Auslieferungszustand usw.
Bin momentan mit meinem Latein am Ende.
Hbe das Loglevel erhöht. Der COC sendet auch irgendwas aber wenn ich den pair Befehl im FHEM absetze, wird das im Log bestätigt (also das initiieren des Selbigen) aber sonst passiert weiter nichts. Die Howtos gehen halt auch nur auf das Minimalste ein.
Habt Ihr noch ne Idee für mich, was ich prüfen müsste? Schicke auch gerne heute Abend das logfile und die fhem.cfg wenn gewünscht.
Moin mato,
definiere genauer:
>Ich habe zwei dieser Thermostate bei Conrad gekauft (Comfort "$")
ist das dieser?
eQ-3 MAX! Heizkörperthermostat Weiß Best.-Nr.: 560897 - 62
gruß Joachim
Hi Joachim,
nein sind die Best.-Nr.: 616100 - 62. Kann das sein, dass diese vielleicht überhaupt nicht gehen?
so isses,
die gehen nicht, ist ein anderes System.
Gruß Joachim
Hi Joachim,
peinlich aber naja ...Mut zur Lücke;) Danke jedenfalls für die schnelle Hilfe!
Das ist schon ganz anderen passiert.
EQ3 betreibt da auch massive Kundenverwirrung.
Gruß Joachim
Der Conrad Heizkörperthermostat Bestell-Nummer 560307 - 62 http://www.produktinfo.conrad.com/datenblaetter/550000-574999/560307-an-01-ml-ENERGIESPAR_REGLER_MK_de_en_fr_nl.pdf heißt bei eQ-3 "CC-RT-B-CyK-W".
Meiner von ELV heißt "MAX! Elektronischer Heizkörper-Thermostat+" und hat die Artikel-Nummer 68-10 59 36. http://www.elv-downloads.de/Assets/Produkte/10/1059/105936/Downloads/105936_thermostat1.1._um.pdf
Bei eQ3 heißt das Teil "BC-RT-TRX-CyG-2", ist der zu FHEM kompatibel ?
Ja, der ist kompatibel.
Danke für die Rückmeldung, Joachim.
Zitat von: housekeeper schrieb am Do, 14 März 2013 11:26Ergebnis: Der Thermostat wird zwar erkannt, aber nicht eingerichtet.
Also, nach ein wenig Probieren und Grübeln jetzt folgender Stand:
Nachdem das Gerät beim Paaren erkannt, aber nicht eingerichtet wird, habe ich versucht das Teil von Hand zu definieren:
define SZ MAX ThermostatPlus 05da08Die Hex-Adresse habe ich aus den Log-Einträgen geraten. Jetzt erklärt mir FHEM:
MAX_Define: Device with addr 05da08 is already defined Aber weder in .save noch in .cfg ein Hinweis auf diese Adresse. Also alle Einträge mit MAX-Relevanz gelöscht, CUL Attribut rfmode MAX gelöscht. Anschließend
shutdown restartJetzt als erstes den Heizkörperthermostaten manuell definiert:
define SZ MAX ThermostatPlus 05da08Anschließend das Attribut rfmode für den CUL wieder auf MAX gesetzt. Jetzt den Heizkörperthermostat auf Fabrikeinstellung zurückgesetzt, nach Eingabe der Uhrzeit erfolgt automatische Einrichtung eines CULMAX. CULMAX auf Paaren gestellt und am Heizkörperthemostat BOOST für 3 Sekunden betätigt.
Oh Wunder, jetzt ist der Eintrag für den Heizkörperthermostat aktiviert und sagt "waiting for data".
Ein wenig umständlich und nicht ganz wie in der Befehlsreferenz oder WIKI beschrieben, aber immerhin...
Es bleibt spannend.
Auffällig ist die letzte Zeile:
2013.03.14 11:02:05 5: CUL_MAX_Parse: Got PairPing (dst 000000, pairmode 1), unk1 16, type 2, unk2 0, serial JEQ0613485
2013.03.14 11:02:05 3: CUL_MAX_Parse: Pairing device 05da08 of type HeatingThermostatPlus with serial JEQ0613485
2013.03.14 11:02:05 5: CUL_MAX_Send: enqueuing 0b01000112345605da080000
2013.03.14 11:02:05 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.14 11:02:05 5: SW: X
2013.03.14 11:02:05 5: CUL/RAW (ReadAnswer): 21 900
2013.03.14 11:02:05 5: needPreamble: 1, necessaryCredit: 110, credit10ms: 900
2013.03.14 11:02:05 5: CUL_0 sending Zs0b01000112345605da080000
2013.03.14 11:02:05 5: SW: Zs0b01000112345605da080000
2013.03.14 11:02:05 5: CULMAX0 dispatch MAX,0,define,05da08,HeatingThermostatPlus,JEQ0613485,0,0
2013.03.14 11:02:05 5: Loading ./usr/share/fhem/FHEM/10_MAX.pm
2013.03.14 11:02:05 5: Calling MAX_Initialize
2013.03.14 11:02:05 5: MAX_Parse MAX,0,define,05da08,HeatingThermostatPlus,JEQ0613485,0,0
2013.03.14 11:02:05 1: Device changed type from to HeatingThermostatPlus
Anscheinend existierte schon ein Device mit der Adresse und leerem Typ? Ich frage mich,
wo das herkommt.
Edit: Das Problem scheint es nur mit HeatingThermostatPlus zu geben, oder hat jemand mit einem "normalen" HeatingThermostat das gleiche Problem?
Kann sein, dass das für HeatingThermostatPlus noch nie funktioniert hat...
Zitat von: Matthias Gehre schrieb am Fr, 15 März 2013 15:26Anscheinend existierte schon ein Device mit der Adresse und leerem Typ? Ich frage mich,
wo das herkommt.
Also ich vermute mal ganz wild:
Wenn noch kein MAX Gerät definiert ist, und der CUL auf rfmode MAX gesetzt wird, versucht das Modul beim ersten Empfang einer MAX-Nachricht sowohl das CULMAX als auch das eigentliche Heizkörperthermostat über autocreate zu generieren. Der CULMAX kommt durch, der Heizkörperthermostat bleibt irgendwo stecken, damit ist seine Hex-Adresse bekannt und das Modul läßt keine weitere Paarung für diese Adresse zu. Ist der Heizkörperthermostat mit der Hex-Adresse vorkonfiguriert, werden ihm alle erforderlichen Daten zugeordnet.
Mein Tipp:
Use of uninitialized value in string ne at ./usr/share/fhem/FHEM/10_MAX.pm line 567.(aus dem Protokoll der Telnet-Sitzung, siehe Anhang der ersten Nachricht)
Probier mal, ob es geht, wenn du die beiden Zeilen
CUL_MAX_Send($shash, "PairPong", $src, "00");
Dispatch($shash, "MAX,$isToMe,define,$src,$device_types{$type},$serial,0,0", {RAWMSG => $rmsg});
in CUL_MAX_Parse (Zeile 299) vertauscht.
Sieht gut aus! Was habe ich gemacht ?
1. Die beiden Zeilen in 14_CUL_MAX.pm vertauscht, wie vorgeschlagen.
2. Alles was mit MAX! zu tun hat löschen, rfmode MAX ebenfalls.
3. Shutdown Restart
4. CUL rfmode auf MAX
5. Heizkörperthermostat in Fabrikzustand zurückversetzen
6. Datum und Uhrzeit eingeben, nach Eingabe der Minuten taucht CULMAX0 in FHEM auf.
7. CULMAX0 auf "pairmode" setzen
8. BOOST 3+ Sekunden drücken, anschließend ist " MAX_05da08" vorhanden, mit FileLog und allem drum und dran. Mein "handgestrickter" sah irgendwie sparsamer aus.
Super Teamwork, Gruppenumarmung!
housekeeper
Nach update von gerade eben auf $Id: 14_CUL_MAX.pm 2959 2013-03-21 15:12:52Z mgehre $ ist das Problem erledigt, Danke Matthias.