Hallo,
ich habe folgendes Problem mit dem HM-CC-TC :
Folgende Gerätekombination habe ich :
HM-CC-TC Version 2.0
HM-CC-VD Version 1.8
fhem wird regelmäßig aktualisiert
Vor einiger Zeit habe ich meine Konfiguration des HM-CC-TC geändert. Und zwar habe ich den HM-CC-VD mit FHEM gepairt und mit dem TC dann über fhem gepeert. Funktionierte augenscheinlich auch problemlos.
War anhand der Infos aus dem WIki eigentlich recht einfach und unproblematisch.
Danach habe ich aber anhand eines Plots in fhem festgestellt, daß das Verhalten etwas merkwürdig war. Trotz zeitlicher Vorgaben für die desired-temp blieb die Temperatur permanent auf einem hohen Level und der Actuator war ständig offen.
Auch habe ich bemerkt, daß die eingetragene PeerID ständig gelöscht wurde.
Es hat sich aber auch mit der Zeit kein vergleichbares Verhalten eingestellt, so wie ich es kannte.
Darum habe ich vor ein paar Tagen den HM-CC-TC aus der bestehenden Konfiguration gelöscht und mit Hilfe von hmPairFor Sec 300 und entsprechender Betätigung versucht neu zu pairen.
In der Konfiguration von fhem sieht man auch die Informationen zu dem HM-CC-TC.
Aber bei dem Thermostat scheint dieser Punkt noch nicht angekommen zu sein.
So wie es aussieht kommt die Verbindung nicht zu Stande.
Deshalb meine Frage, was ich hier falsch gemacht habe und wie ich das Problem wieder in den Griff bekomme.
Es ist zwar momentan nicht allzu kalt. Aber es sollte kurzfristig doch wieder möglich sein, über den HM-CC-TC uind über fhem die Temperatur regeln zu können.
Schon mal Danke für die Hilfe.
Viele Grüße
Michael
Hallo Michael,
kann ich auch nur raten.
peerIDs werden gelöscht und neu gesetzt, wenn FHEM das device ausliest. Wen das lesen schief geht könnte die liste leer sein.
- steht wenigstens 00000000 drin?
Sollte das nicht der Fall sein ist es möglich, dass der Empfang den Device (VD, TC oder beide?) nicht stabil ist.
- wie sehen RSSI aus? Sind die Batterien ok?
Die peer liste wird, falls autoReadReg aktiv ist, nach einem Neustart gelesen (oder es wird versucht). Danach sollte nichts mehr passieren. Geschrieben wird automtisch nichts.
Zum operationalen Betrieb - FHEM spielt da nicht mit - nur das was du sendest. Das sollte laufen wie bisher.
Wenn nichts mehr hilft, batterien wechseln.
Dass das pairen geklappt hat, hast du schon geprüft?
Gruss Martin
Hallo Martin,
viele Infos auf einmal und alles etwas verwirrend :(
Damit ich einen definierten Zustand habe, werde ich heute abend mal die Batterien erneuern und dann schauen, was passiert.
Der VD scheint aber korrekt im FHEM gepaired zu sein.
Der TC hingegen nicht.
Deshalb wäre es primär sinnvoll, wenn ich dieses Problem erst einmal hinbekomme.
Danach können wir die Peers angehen.
Ich habe alle Probleme in das Posting gepackt, damit klar ist, welche Punkte bei mir schief laufen.
Michael
Hallo Michael,
wenn ich es beurteilen soll brauch ich die Daten.
ein List des TC und des TC_Climate
ggf ein log des lesens der Config des TC - roh-messages nach
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
Gruss Martin
Hallo Martin,
ich habe gestern abend erst einmal die Batterien im TC und VD ausgetauscht.
Auf den ersten Blick hatte sich aber nichts geändert.
Dann habe ich versucht die Geräte mit fhem zu pairen.
Dies scheint aktuell nicht zu funktionieren.
Beim TC läuft der Zähler von 20 runter auf 0 und dann wird im Display NOK angezeigt -> Pairen hat nicht geklappt. Der Vorgang ist reproduzierbar
Es läßt sich am Gerät auch der Central-Mode nicht einstellen
Anbei die Ausgaben von list für TC und TC_Climate
Internals:
CFGFN
DEF 166AEF
EVENTS 2
HMLAN1_MSGCNT 152
HMLAN1_RAWMSG E166AEF,0000,00140BB3,FF,FFD0,598670166AEF00000000CB36
HMLAN1_RSSI -48
HMLAN1_TIME 2013-12-18 08:29:44
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 152
NAME CUL_HM_HM_CC_TC_166AEF
NR 806
STATE T: 20.3 H: 54
TYPE CUL_HM
channel_01 CUL_HM_HM_CC_TC_166AEF_Weather
channel_02 CUL_HM_HM_CC_TC_166AEF_Climate
channel_03 CUL_HM_HM_CC_TC_166AEF_WindowRec
hmPairSerial IEQ0068104
lastMsg No:59 - t:70 s:166AEF d:000000 00CB36
protCmdDel 65
protIOerr 8 last_at:2013-12-18 08:29:08
protLastRcv 2013-12-18 08:29:44
protState CMDs_done_Errors:1
rssi_at_HMLAN1 avg:-65.09 min:-82 max:-39 lst:-48 cnt:152
Readings:
2013-12-18 08:28:08 Activity alive
2013-12-17 18:34:44 R-pairCentral set_0xBEB4B3
2013-12-18 08:29:44 humidity 54
2013-12-18 08:29:44 measured-temp 20.3
2013-12-18 08:29:44 state T: 20.3 H: 54
Helper:
mId 0039
rxType 140
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -65.0921052631579
cnt 152
lst -48
max -39
min -82
Shadowreg:
RegL_00: 02:01 0A:BE 0B:B4 0C:B3
Attributes:
actCycle 000:10
actStatus alive
autoReadReg 1_restart
expert 2_full
firmware 2.0
model HM-CC-TC
peerIDs
room CUL_HM
serialNr IEQ0068104
subType thermostat
Internals:
CFGFN
DEF 166AEF02
NAME CUL_HM_HM_CC_TC_166AEF_Climate
NR 810
STATE set_desired-temp 21.5
TYPE CUL_HM
chanNo 02
device CUL_HM_HM_CC_TC_166AEF
Readings:
2013-12-17 19:43:31 state set_desired-temp 21.5
Helper:
getCfgListNo
Role:
chn 1
Attributes:
expert 2_full
model HM-CC-TC
peerIDs 167096
room CUL_HM
Beim VD passiert im Grunde genommen genau das selbe.
Im fhem wird aber ein ioerr angezeigt.
Hier dann die Ausgabe vom list :
Internals:
CFGFN
DEF 167096
EVENTS 1
HMLAN1_MSGCNT 4
HMLAN1_RAWMSG E167096,0000,2E59E87C,FF,FFBA,04840016709600000018003A4945513030363938353858010100
HMLAN1_RSSI -70
HMLAN1_TIME 2013-12-17 18:41:18
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 4
NAME CUL_HM_HM_CC_VD_167096
NR 861
STATE IOerr
TYPE CUL_HM
hmPairSerial IEQ0069858
lastMsg No:04 - t:00 s:167096 d:000000 18003A4945513030363938353858010100
protCmdDel 14
protCmdPend 13 CMDs_pending
protIOerr 2 last_at:2013-12-17 18:42:18
protLastRcv 2013-12-17 18:41:18
protState CMDs_pending
rssi_at_HMLAN1 avg:-69.75 min:-74 max:-67 lst:-70 cnt:4
Readings:
2013-12-17 18:41:18 Activity alive
2013-12-17 20:09:28 R-pairCentral set_0x0
2013-12-17 18:42:18 state IOerr
cmdStack:
++A001BEB4B316709600040000000000
++A001BEB4B31670960103
++A001BEB4B316709601040000000005
++A001BEB4B316709600040000000000
++A001BEB4B31670960103
++A001BEB4B316709601040000000005
++A001BEB4B316709600040000000000
++A001BEB4B31670960103
++A001BEB4B316709601040000000005
++A401BEB4B3000000010A49455130303639383538
++A001BEB4B316709600050000000000
++A001BEB4B3167096000802010A000B000C00
++A001BEB4B31670960006
Helper:
getCfgListNo
mId 003A
oldDes 0
rxType 12
Prt:
bErr 0
sProc 2
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan1:
avg -69.75
cnt 4
lst -70
max -67
min -74
Shadowreg:
RegL_00: 02:01 0A:00 0B:00 0C:00
Attributes:
actCycle 028:00
actStatus alive
autoReadReg 1_restart
expert 2_full
firmware 1.8
model HM-CC-VD
peerIDs
room CUL_HM
serialNr IEQ0069858
subType thermostat
webCmd getConfig
Welche log-Datei möchtest Du haben ? Kann momentan mit der Info ein log des lesens der Config des TC nicht viel anfangen.
Danke schon einmal und viele Grüße
Michael
Hallo Michael,
probiere ein
set CUL_HM_HM_CC_VD_167096 clear msgEvents
set HMLAN1 hmPairForSec 300
=> anlernen drücken
wenn es nicht klappt (oder preventiv) schalte die logs ein und sende sie, wenn es nicht geklappt hat.
attr global verbose 1
attr global mseclog 1
attr HMLAN1 logIDs all,sys
Gruss Martin
Hallo Martin,
erst einmal ein frohes neues Jahr.
Anbei die log-Dateien für den VD und den HMLAN.
Ich habe gestern erneut versucht, den VD zu pairen.
Aber das Ergebnis hat sich nicht geändert.
Immer noch wird mir der IOErr angezeigt.
Danke und viele Grüße
Michael
Hallo Michael,
wenn das IO device ein Problem hat ist das erst einmal zu lösen. Pairen oder sonst etwas kann bei disconnected nicht funktionieren.
Ich will (fast) immer die roh-messages
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
tritt das disconnect nur beim pairen auf oder eigentlich immer?
zeigen die roh-messages - und schaue einmal im IO-device nach. Da sollten readings anzeigen wie das keep-alive funktioniert
In jedem Fall die messages mitschneiden
was läuft sonst noch in deinem System? Irgend ein langweiler?
Gruss Martin
Hi Martin,
hier noch die aktuelle fhem.log
Viele Grüße
Michael
Hallo Michael,
ich denke, du hast mittlerweile einen update gemacht - zumindest 98HMInfo war nicht mehr kompatibel.....
Nach dem update kann ich nirgendwo erkennen, dass du anlernen irgendwo drückst. Kein TC, kein VD.
der TC und der VD scheinen auch nicht gepeert zu sein - der TC sendet nichts dergleichen
also zum pairen:
set <hmlan> hmPairForSec 300
##!!! anlernen drücken
-> vd: der button sol lange bis "20" erscheint
-> beim TC "ok" bis die LED sich ändert
steht in manual deiner Bausteine.
Dann sollte auch eine message imlog kommen.
Gruss Martin
Hallo Martin,
vielleicht können wir deine letzte Mail mal ordnen :
1. Ich will (fast) immer die roh-messages
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
Die Einstellungen in meinem System sind schon seit längerer Zeit genau, wie in dem Posting beschrieben.
Vielleicht kannst Du mir eine Info senden, welche log-Datei Du haben möchtest und was ich noch machen kann, damit raw-Messages drin sind !!
Warum keine raw-Messages drin stehen ist für mich nicht nachvollziehbar.
2. tritt das disconnect nur beim pairen auf oder eigentlich immer?
zeigen die roh-messages - und schaue einmal im IO-device nach. Da sollten readings anzeigen wie das keep-alive funktioniert
In jedem Fall die messages mitschneiden.
Könntest Du das bitte etwas genauer erläutern oder eine Quelle angeben, wo es nachvollziehbar erläutert ist !!
3. HM-mäßig ist nur der TC und der VD drin
Es gibt aber noch einige FS20 Komponenten (Schalter für Dielen- und Badlicht, Steckdosenschalter, etc.), die eher unproblematisch laufen.
Im HM-Bereich ist das ganze System eher noch als Testsystem zu sehen, da ich erst einmal nur die Temperaturregelung so hinbekommen möchte,
wie ich mir das vorstelle (wenn es überhaupt geht -> da benötige ich von Dir noch weiterführende Infos).
Schon einmal Danke und viele Grüße
Michael
Hallo Martin,
den VD habe ich gestern versucht zu pairen, so wie Du es beschrieben hast.
Das hat nicht funktioniert. Der Zustand war vergleichbar zu dem Zustand wie vorher.
Und bezüglich TC hatte ich auch schon vor einiger Zeit geschrieben, daß das wohl nicht mehr funbktioniert !!
Aber ich werde es noch einmal probieren. Gehe aber davoin aus, daß es nicht klappt.
Wenn ich beide Geräte versucht habe zu pairen, dann schick ich Dir noch einmal die Log-Dateien für den HMLAN, den VD, den TC und fhem.log
Wenn Du aber raw-MEssages haben möchtest, benötige ich noch eine Info von Dir, wie ich diese in der log-Datei ablege !!
Danke und viele Grüße
Michael
ZitatIch will (fast) immer die roh-messages
http://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848
hat er dir doch schon geschrieben ;)
Hi,
Das pairen war bislang 2mal notwendig, jedenfalls musste erst das Device in FHEM angeledt werden (1-mal anlernen drücken) und dann ein hmPairForSec, noch einmal anlernen.
es soll mit der Version von heute (per update morgen) in einem zug funktionieren
Gruss Martin
Hallo fhem-hm-knecht,
ich habe aber auch geschrieben, daß ich diese Einstellung bereits seit einiger Zeit in meiner Konfig drin habe und trotzdem keine raw-messages bekomme.
Aber trotztdem Danke für die Info, die mich nicht weiterbringt !!
Im Grunde genommen geht es doch primär darum raw-messages von den betroffenen Geräten HMLAN, TC und VD zu erhalten.
Dies ist aber wohl auf meiner Installation nicht möglich, da ich in allen log-Dateien nur Text-Messages habe.
Da ich alle Informationsquellen mehrfach durchfrorstet habe, benötige ich jetzt weitergehende Informationen, wie ich an raw-messages dran komme.
Das wäre dann schon einmal hilfreich, um das eigentliche Problem zu lösen !!
Danke und viele Grüße
Michael
Hallo Martin,
lass uns bitte folgende Punkte der Reihe nach klären :
1. Warum bekomme ich keine Raw-Messages von den HM-Geräten
Eventuell ist der HMLAN nicht korrekt eingebunden !!!
Es könnte ja sein, daß das eine Problem (Gerät nicht korrekt eingebunden) das zweite Problem begünstigt (keine Raw-Messages).
2. HMLAN korrekt einbinden, falls dies nicht bereits unter Punkt 1 geschehen ist
3. TC und VD korrekt pairen und peeren.
4. Infos zu
Nutzung und Bedeutung der Kanäle Weather und Climate
Was kann ich aus fhem heraus verändern ?
(eventuell Offline)
Ich glaube, daß es Sinn macht, diese Reihenfolge abzuarbeiten. Damit sollte man auf jeden Fall zu Lösungen der einzelnen Probleme kommen.
Danke und viele Grüße
Michael
Hallo Michael,
1) a) falls HMLAN nich tkorrekt eingebunden ist probieren einen update force.
b) rohmessages sollen (müssen) im zentralen Logfile erscheinen, wenn du im HMLAN das attribut logIDs setzt. Am besten erst einmal auf
attr <HMLAN> logIDs sys,all
2)
nach dem einbinden sollte FHEM automatisch alle 25sec ein keepalive senden. Der State muss opened sein.
3)bis vor kurzem hat das pairen nur funktioniert, wenn schon ein Eintrag in FHEM vorhanden war - ist jetzt geändert. Also
set <hmlan> hmPairForSec 100
#anlernen drücken
---> evtl noch einmal wiederholen oder nächstes Device
---> falls das device existiert kann man auch ein set <device> clear msgEvents vor dem anlernen drücken einbauen
---> falls es nicht klappt einmal loggen (rohmessage sollten jetzt klappen)
4)
get <tc_Weather> regList
get <tc_Climate> regList
...
Ja, die Reihenfolge macht sinn ;)
Gruss Martin
Hallo Martin,
anbei die fhem.log (ich gehe mal davon aus, daß diese Datei die zentrale Log-Dateien ist) vom heutigen Tag.
Ich hoffe, daß jetzt die gewünschten raw-Messages vorhanden sind.
Meine Vorstellung bezüglich der Reihenfolge ist aber auch, daß jeweils nur ein Problem betrachtet wird und die anderen dann erst, wenn das aktuelle gelöst ist. Also aktuell erst einmal das Thema raw-Messages in den Griff bekommen und dann HMLAN.
Die beiden Geräte dann pairen und peeren ist aktuell zweitrangig und werden ich erst angehen, wenn der HMLAN korrekt funktioniert.
Danke und viele Grüße
Michael
Hallo Martin,
anbei die fhem.log nachdem ich noch einmal versucht habe den TC zu pairen.
Das Ergebnis ist unverändert.
Zusätzlich habe ich noch ein list vom HMLAN hinzugefügt.
Soweit ich erkennen kann, ist das Gerät korrekt eingebunden.
Jetzt ist nur zu klären, warum der TC sich nicht pairen läßt !!
Ich gehe mal davon aus, daß die restlichen Aktionen (peeren, etc.) unproblematisch eingerichtet werden, wenn dieses Problem gelöst ist !!
Danke und viele Grüße
Michael
hm seltsam.
das Anlernen wird empfangen - aber es wird nichts gesendet.
das list des HMLAN ist leider leer. Kannst du auch das List des TC dazu schicken?
Hast du das Log auf den TC eingeschränkt? Der ist der einzige, der sendet
Gruss Martin
Hallo Martin,
anbei die Ausgabe von list TC.
Ich habe aktuell nur mit dem TC versucht das Pairing durchzuführen.
Deshalb siehst Du auch nur den TC.
Aus ca. 30 jähriger Erfahrung macht es Sinn kleine Schritte zu machen.
Ich gehe davon aus, wenn das Problem mit dem TC gelöst ist, dann läßt sich der VD entsprechend pairen.
Und der Rest geht dann von alleine
Viele Grüße
Michael
Hallo Martin,
habe eben gesehen, daß die Datei mit der Ausgabe von list für den HMLAN leer war.
Anbei eine aktuelle Ausgabe von list für den HMLAN.
Viele Grüße
Michael
Hi Michael,
sicher korrekt.
Der TC hat noch kommandos gespeichert, das ist ein getConfig .
Es sollte beim pairen automatisch gelöscht werden, aber du kannst es ja auch manuell machen
set CUL_HM_HM_CC_TC_166AEF clear msgEvents
was auffällig ist, dass zwar das Anlernen/Config empfangen wird, aber FHEM nicht versucht zu senden.
du hast
set HMLAN1 hmPairForSec 200
ausgeführt? das sollte im HMLAN1 'Internals' auch sehen können mit 'hmPair 1'
Dann innerhalb der 200sec anlernen.
Das HMLAN1 ist operationell? Keine Alarme?
Gruss Martin
Hallo Martin,
Du brauchst mir nicht permanent zu erklären, wie man ein pairing ausführt.
Ich glaube aufgrund meines E-Technik Studiums (Ist zwar schon länger her, aber ich habe in der Zeit auch selber Hardware gebaut und programmiert) habe ich schon verstanden, wie das Pairen von Geräte durchgeführt wird. Und seit über 20 Jahren bin ich in der EDV tätig.
Ich habe aber das Gefühl, daß wir nicht weiterkommen. So wirklich sehe ich keinen Ansatz für eine Lösung des Problems.
Es muß doch ersichtlich sein, warum FHEM nicht sendet.
Ich habe momentan das Problem, daß ich überhaupt nicht verstehe, daß aktuell mit dem TC und dem VD soviele Probleme auftreten.
Bis vor einiger Zeit hatte ich keinerlei Probleme. Aber bis dann hing der VD eben nur am TC und nicht am HMLAN.
Nachdem ich das Pairing deinen Empfehlungen angepasst habe, traten erst die Probleme auf !!
Vielleicht sollte man noch einmal Grundsätzliches checken.
FHEM ist auf einer Fritz!Box 7390 mit Fritz!OS 6.0 installiert.
Anbei die Konfig. Falls die Includes noch interessant sind, dann kann ich dir die auch schicken.
Da aber HM nur in der fhem.cfg enthalten ist (Include ist auskommentiert), müßte das eigentlich ausreichen.
Den HMLAN-Adapter habe ich direkt an der Fritz!Box angeschlossen.
AES habe ich ausgeschaltet.
Für FS20 habe ich eine FHZ1350, die an einem USB-Port der Fritz!Box hängt.
Ich bin der Meinung, daß die Konstellation nichts Besonderes beinhaltet.
Speziell da aktuell nur der HMLAN und der TC betrachtet werden. Es gibt keine weiteren HM-Geräte, die in der Konfiguration auftauchen.
Es muß doch eigentlich Informationen geben, die mir anzeigen, warum fhem nicht antwortet.
Kann ich dafür noch etwas einstellen, z.B. log-Parameter ?
Ich kann mich noch daran erinnern, daß man eine Flut von Infos bei diversen Microcontrollern bekommen kann, wenn man entsprechende Flags gesetzt hat.
Da stand so viel drin, daß jegliches Bit eigentlich kommentiert wurde.
Danke und viele Grüße
Michael
sorry, wollte dir nicht zunahe traten mit dem pairen
lösche einmal die Zeile
attr HMLAN1 eventMap closed:Fehler opened:OK
der Zustand des HMLAN wird intern auch genutzt, wenn du den umbenennst ist er nicht mehr opened.... und dann senden wir auch nichts mehr, as muss ein fehler vorliegen...
Nicht alles, was user-sichtbar ist wird noch einmal intern roh verwaltet.....
Gruss Martin
Hallo Martin,
Du bist mir nicht zu nahe getreten !!
Ich bin nur der Meinung, daß wir uns mit der Thematik pairen nicht beschäftigen sollten, da klar ist, wie das geht.
Es reicht, wenn notwenig nur der Hinweis, daß gepairt werden soll.
Ok. Ich nehm die Zeile mal raus. Ich gehe aber davon aus, daß das Problem nicht daran liegt !!
Ich verstehe nämlich nicht, warum ich die Zeile löschen soll.
Es hat doch bis jetzt geklappt. Erst als ich den VD pairen wollte traten die Probleme auf.
Und beim TC traten die PRobleme auf, nachdem ich die Batterien gewechselt habe.
Und an der HMLAN-Konfiguration und an der Hardware habe ich nichts geändert.
Wir werden sehen, was dabei passiert.
Viele Grüße
Michael
Hi Michael,
ich versuche ausführlich zu antworten. Ich bin leider nicht in der Lage zu erkennen, wo ich einen user abholen muss. Ich merke mir noch nicht einmal über mehrere Antworten hinweg, was ich schon alles empfohlen habe - sorry. Meine Antworten sollen eher ausführlich sein, als dass ich den User auf halbem Weg stehen lasse.
CUL_HM prüft, ob das IO device sendebereit ist (open). Du änderst "open" nach "ok" - das ist dann nicht mehr open. Mit deinem von dir beschriebenen Hintergrund sollten dir die Konsequenzen klar sein - no open, no send. Oder kein send bei OK.
Würde mich wundern, wenn irgendwas gesendet werden kann. Bei mir verhält es sich korrekt - wenn ich es einbaue, kein send.
Vergiss nicht einen neustart des HMLAN nach dem Delete! sonst bleibt OK im state und es geht immer noch nichts.
Du solltest auch sehen, dass protokoll IOerrors gemeldet werden. Das ist wichtig dort einen Blick drauf zu haben.
HMInfo
set hm protoEvents short
Gruss Martin
Hallo Martin,
mir ist schon klar, daß in dem Umfeld des Forums Support nicht in der Form erfolgen kann, wie bei einem profesionellen Support.
Die Unterstützung wird von Dir ja in Deiner Freizeit erledigt und da ist es schon ok, wenn ab und zu mehr Infos, wie nötig kommen.
Mir ist schon klar, daß wenn intern anstelle open ok stehen würde, daß gegebenenfalls Probleme entstehen könnten.
Für mich war evetnMap bisher so etwas, wie eine Alias-Ersetzung für den ursprünglichen Wert !!
Scheint aber wohl nicht so zu sein.
Was ich aber nicht verstehe, ist die Tatsache, daß es bis zu Umstellung ging.
Die einzige Möglichkeit besteht darin, daß ich den TC mit fhem gepairt habe und dann den Status vom HMLAN geändert habe.
Aktuell habe ich folgende Schritte durchgeführt :
1. eventMap auskommentiert
2. HMLAN neu gestartet
3. TC gepairt -> scheint zu funktionieren
der TC hat sich dabei aber aufgehgängt : Am Gerät läßt sich keine Einstellung mehr machen.
4. VD gepairt -> scheint zu funktionieren
Bekomme in fhem aber keinen state zurück geliefert.
Also Pairen geht nun.
Aber es gibt nun andere Probleme !!! :(
Anbei sende ich Dir noch einmal meine fhem.log.
Vielleicht sieht man darin etwas mehr.
Danke und viele Grüße
Michael
Hallo Michael,
ZitatFür mich war evetnMap bisher so etwas, wie eine Alias-Ersetzung
ist es auch. Da es aber sehr pauschal genutzt wird und mit regexp arbeitet gibt es damit immer wieder Probleme. Die einfachheit hat eben Vor und Nachteile.
In deinem Fall hat es das gemacht was du wolltest - aber als nebeneffekt auch das Senden blockiert. Könnte ich vermeiden, wenn ich eine 2. Ebene einziehen würde: User-display und operationale Daten.
Je nachdem wie alt deine alte Version war- ja früher wurde das nicht geprüft. Da hat CUL_HM messages in (auch temporär)geschlossene IOs gepumpt, die wurden verworfen. Jetzt prüft CLU_HM ob senden möglich ist. Wenn der Status 'ok' ist, ist das nicht der Fall - es wird gewartet. Der User bekommt das auch signalisiert - es werden IOerrors gezählt => das IO device ist Grund für die Probleme.
zum VD:
der state des VD ist der Level des Ventils. Der wird an den "einstellen" gesendet, alle 2,5min. Der "einsteller" ist normal der TC - und da der nicht funktioniert kommt auch kein Level.
Dem VD solltest du die Register entlocken können. Ein getConfig sollte schon gelaufen sein, so du es nicht weggeklemmt hast. Ansonsten kannst du es manuell starten - dann musst du noch einmal anlernen drücken, da der VD ja aktuell nicht aufwacht weil kein TC vorhanden ist. Wenn der TC->VD läuft kann man mit dem VD alle 2,5min "reden".
Dass der TC nichts mehr macht ist das eingetliche Problem. So es gepairt ist sollte jetzt der Mode "cent" zu verfügung stehen. Batterie raus hast du sicher schon einmal probiert. auch noch einmal config/anlernen drücken. Passiert da irgend etwas? Kommt diese message?
Gruss Martin
Hallo Martin,
ich mal wieder mit dem Problem HM-CC-TC und HM-CC-VD.
Hatte seit dem letzten Posting keine Zeit mich wirklich um die Thematik zu kümmern.
Aktuell sind aber einige Probleme aufgetaucht, die ziemlich extrem sind.
HM-CC-TC
Es wird eine aktuelle Temperatur angezeigt, die überhaupt nicht nachvollziehbar ist.
Und zwar ein Wert von z.B. 75,7 Grad Celsius !!
Also ein Wert für die aktuelle Temperatur in der Regel über 50 Grad
Und ich habe jetzt mehrfach das Gerät neu anlernen lassen.
Jedesmal das selbe Ergebnis !!
Bei mir kommt langsam der Verdacht auf, daß der TC hardwaremäßig defekt ist.
Oder ist das ein Softwareproblem.
Firmware ist Version 2.0. Gibt es da eventuell eine neuere Version.
Ist Dir das Problem bekannt.
Wäre ziemlich blöd, wenn ich das Projekt einstampfen müßte, da der Thermostat defekt ist.
Wollte eigentlich die ganze Thematik ausbauen, da es einige Räume bei uns im Haus gibt, bei denen die Heizung zentraler gesteuert werden müßte.
Und das Thema VD kommt erst wieder zum Tragen, wenn das Thema TC gelöst ist.
Macht sonst keinen Sinn !!
Schon einmal Danke und viele Grüße
Michael
Zitatz.B. 75,7 Grad Celsius !!
...
Bei mir kommt langsam der Verdacht auf, daß der TC hardwaremäßig defekt ist.
könnte sein, dass FHEM etwas falsch dekodiert, oder eben das Gerät ist defekt.
Im ersteren Fall müsste ich etwas tun, um 2. du.
Wie oft kommt der falsche Wert? Kannst du die rohmessages logen?
Gruss Martin
Hallo MArtin,
anbei die log-Datei mit den raw-Messages
Ich gehe aber davon aus, daß der TC defekt ist.
Ich habe aufgrund der aktuellen Temperaturen unsere Heizung abgestellt und den TC auf Manuell umgestellt.
In der Anzeige wird jetzt keine Temperatur angezeigt, sondern nur noch Striche -- -- --.
Wenn in den raw-Messages kein Hinweis zu finden ist, dann muß ich davon ausgehen, daß der TC defekt ist.
Mal sehen, ob ich noch Ersatz bekomme oder das Teil reparieren lassen kann.
Schon einmal vielen Dank und viele Grüße
Michael
Hallo MArtin,
mein Rechner hatte heute früh einige Probleme, da die Systemplatte voll gelaufen ist und sich erst jetzt gemeldet hat !!
Anbei die log-Datei !!
Viele Grüße
Michael
Aktuell sehe ich im fhem folgende Werte :
Temperatur : 106,8 °C
Luftfeuchtigkeit : 99
Ich glaube das wäre sehr fatal, wenn die Werte stimmen würden.
hm - ist schon seltsam.
Die Temp ist definiert mit von -40 bis 80 Grad. Der Wertebereich in der Message geht über +-1638.3 Grad.
Die Werte kommen in der Höhe - das ist ausserhalb des Bereichs. Ich sehe aber nicht, wo ich abschneiden sollte. Allein die Sprünge in den Werten sind nicht ok
12:00:21.663 m:B4 8670 166AEF 000000 8419
12:03:11.921 m:B5 8670 166AEF 000000 83EE
12:05:47.676 m:B6 8670 166AEF 000000 8419
das sind 4,3 Grad runter und dann wieder hoch...
Ich denke, das Teil ist defekt
Hallo Martin,
was Du da schreibst ist nicht realistisch.
Ich gehe auch davon aus, daß der TC defekt ist.
Werde das Teil mal an den Reparaturservice von ELV schicken.
Vielleicht kann man es ja noch reparieren !! ;)
Sonst muß ich Ersatz besorgen.
Vielleicht klappt dann auch das Peering mit dem VD.
Schon einmal Danke für Deine Bemühungen.
Viele Grüße
Michael
P.S. Ich werde mir mal im LAufe der nächsten Tage Gedanken machen, ob ich etwas tiefer in das Thema einsteige und mich dann bei DIr melden.
Hallo,
nachdem der TC zurück ist und ich mittlerweile die Heizung wieder angestellt habe, wollte ich die Heizungssteuerung mit HM-CC-TC und HM-CC-VD wieder in Betrieb nehmen und habe beide Geräte mit fhem gepairt.
Es sieht im fhem auch alles plausibel aus. Aber die Heizung bleibt trotzdem kalt !!
Es kann nicht am Ventil oder der Heizung liegen, da ich im Laufe der letzten Tage mehrfach das Ventil mit Hilfe des Notantriebs des VC bedienen mußte (Entlüftung der Heizung, etc.) Und dabei funktionierte eigentlich alles, wie erwartet.
Ich habe anbei mal die aktuelle fhem.log angehängt. Vielleicht erkennt man dort etwas mehr.
So langsam wird meine Frau nämlich ungeduldig, da der VD im Wohnzimmer installiert ist und es recht kühl geworden ist.
Vielen Dank schon einmal im Vorfeld.
Viele Grüße
Michael
das nächste mal bitte rohmessage (siehe wiki/nachrichten sniffen)
der TC sendet nicht an den VD. Nach dem pairen mit fhem solltest du beide noch peeren.
set tc_Climate peerChan 0 vd single set
config drücken