Probleme beim Pairen von HM-CC-TC

[mschulte63]

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

[martinp876]

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

[mschulte63]

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

[mschulte63]

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

[martinp876]

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

[mschulte63]

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

[mschulte63]

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

[martinp876]

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

[mschulte63]

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

[martinp876]

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

[mschulte63]

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

[martinp876]

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

[mschulte63]

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

[martinp876]

Hallo Michael,

Fü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

[mschulte63]

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