Probleme mit HM_CC-TC nach Update auf FHEM 5.3 (Fritzbox)

[Uli70]

Hallo, ich bin noch blutiger FHEM-Anfänger und habe bisher meine 6 HM-CC-TC's über die Fritzbox 7390 mit FHEM 5.2  verwaltet. Gestern habe ich dann von FHEM 5.2 => 5.3 ge-update-t und festgestellt, dass sich einige Dinge nicht so verhalten wie in der FHEMwiki beschrieben und desweiteren Fehler in den Logfiles zu finden sind. Meine beiden mich quälrenden Hauptpunkte, für die ich bisher keine Antwort finden konnte lauten wie folgt:

a) In FHEMwiki ist beschrieben, dass unter Version 5.3 bei einem erneuten Pairen mit dem HM-Lan-Adapter neben dem Hauptgerät auch Defines für die Kanäle Weather, Climate und WindowRec via autocreate erstellt werden. Bei mir ist das jedoch nicht der Fall, sondern es wird nur ein Define-Block erstellt (siehe unten am Beispiel BAD) - liegt hier ein Missverständnis meinerseits vor oder läuft hier was bei meinem Komponenten schief?

Übrigens, beim Thema Pairen verhält es sich zudem so (war aber auch unter 5.2 schon so), dass die HM-CC-TC`s nach dem aktivieren des Anlernmodus bereits im FHEM erscheinen, auch ohne, dass ich den HM-Lan-Adampter in den Anlernmodus versetzt habe. - Ist das normal? Wahrscheinlich eher nicht oder?

#***********************************
#************** BAD ****************
#***********************************
define CUL_HM_thermostat_1BF837 CUL_HM 1BF837
attr CUL_HM_thermostat_1BF837 actCycle 000:10
attr CUL_HM_thermostat_1BF837 actStatus dead
attr CUL_HM_thermostat_1BF837 devInfo 00FFFF
attr CUL_HM_thermostat_1BF837 firmware 2.1
attr CUL_HM_thermostat_1BF837 hmClass receiver
attr CUL_HM_thermostat_1BF837 model HM-CC-TC
attr CUL_HM_thermostat_1BF837 protCmdPend 3 CMDs pending
attr CUL_HM_thermostat_1BF837 protLastRcv 2013-02-09 21:12:18
attr CUL_HM_thermostat_1BF837 room CUL_HM
attr CUL_HM_thermostat_1BF837 serialNr JEQ0457101
attr CUL_HM_thermostat_1BF837 subType thermostat
define FileLog_CUL_HM_thermostat_1BF837 FileLog ./log/CUL_HM_thermostat_1BF837-%Y.log CUL_HM_thermostat_1BF837
attr FileLog_CUL_HM_thermostat_1BF837 logtype temp4hum6:Temp/Hum,text
attr FileLog_CUL_HM_thermostat_1BF837 room CUL_HM
*********************************************************************************


b) Der zweite Punkt bezieht sich auf die Logfiles der HM-CC-TS's:
Hier tritt nach dem Update 5.3 der Fehler auf, dass die Ventilstellung nicht mehr geloggt wird und hier anstelle dessen die Meldung "... noReceiver: src:1BF837 (A258) 00B3" erscheint:

2013-02-10_14:06:19 CUL_HM_thermostat_1BF837 T: 18.9 H: 61
2013-02-10_14:06:19 CUL_HM_thermostat_1BF837 measured-temp: 18.9
2013-02-10_14:06:19 CUL_HM_thermostat_1BF837 humidity: 61
2013-02-10_14:06:39 CUL_HM_thermostat_1BF837 noReceiver: src:1BF837 (A258) 00B3

Ich habe zwar andren Beiträgen entnommen(z.B. Link), dass der Fehler nicht unbekannt ist, aber mir ist nicht klar, wie man ihn beheben kann. In dem bisherigen Beiträgen war ja nur eine Update fällig, aber ich habe ja das aktuelle gerade durchgeführt (denke ich jeden falls).

Es wäre klasse, wenn mir jemand zu den oben genannten Fragen Antworten liefern kann - ich wäre Euch überaus dankbar, da meine Recherche bereits Stunden gekostet hat und die Frau schon nörgelt ;o) - Antworten aber bitte für einen FHEM-Anfänger gestalten.  

Vielen Dank + Grüße
  Uli

[martinp876]

oder läuft hier was bei meinem Komponenten schief?

Besitzstandswahrung: es werden keine Kanaele definiert  solange du nichts machst.
Sobald du anlernen drückst werden die Kanaele erstellt  ( je device) . also einfach einmal ok fuer 20 sec.

 

Ist das normal? Wahrscheinlich eher nicht oder?

doch, ist ok so. Der Adapter wird meines wissens nicht angelernt sondern der TC.

evtl loest ich danach auch dein Problem mit der unknown message

Gruss
Martin

[Uli70]

Super - vielen Dank Martin - bin wieder ein Stück schlauer => bin also noch mal auf den Config-Stand nach dem Update gegangen und habe an allen HM-CC-TC's auf OK gedrückt - jetzt sieht das Beispiel von oben wie folgt aus:

#***********************************
#************** BAD ****************
#***********************************
define Bad_Thermostat CUL_HM 1BF837
attr Bad_Thermostat alias Bad-Thermostat
attr Bad_Thermostat channel_01 Bad_Thermostat_Weather
attr Bad_Thermostat channel_02 Bad_Thermostat_Climate
attr Bad_Thermostat channel_03 Bad_Thermostat_WindowRec
attr Bad_Thermostat devInfo 00FFFF
attr Bad_Thermostat firmware 2.1
attr Bad_Thermostat hmClass receiver
attr Bad_Thermostat model HM-CC-TC
attr Bad_Thermostat protLastRcv 2013-02-10 21:39:35
attr Bad_Thermostat room Bad
attr Bad_Thermostat serialNr JEQ0457101
attr Bad_Thermostat subType thermostat
define FileLog_Bad_Thermostat FileLog ./log/CUL_HM_HM_CC_TC_1BF837-%Y.log Bad_Thermostat
attr FileLog_Bad_Thermostat logtype fht_Bad:Plot,text
attr FileLog_Bad_Thermostat room Bad

define Bad_Thermostat_Weather CUL_HM 1BF83701
attr Bad_Thermostat_Weather chanNo 01
attr Bad_Thermostat_Weather device Bad_Thermostat
attr Bad_Thermostat_Weather model HM-CC-TC
attr Bad_Thermostat_Weather room CUL_HM
define FileLog_Bad_Thermostat_Weather FileLog ./log/Bad_Thermostat_Weather-%Y.log Bad_Thermostat_Weather
attr FileLog_Bad_Thermostat_Weather logtype text
attr FileLog_Bad_Thermostat_Weather room CUL_HM

define Bad_Thermostat_Climate CUL_HM 1BF83702
attr Bad_Thermostat_Climate chanNo 02
attr Bad_Thermostat_Climate device Bad_Thermostat
attr Bad_Thermostat_Climate model HM-CC-TC
attr Bad_Thermostat_Climate room CUL_HM
define FileLog_Bad_Thermostat_Climate FileLog ./log/Bad_Thermostat_Climate-%Y.log Bad_Thermostat_Climate
attr FileLog_Bad_Thermostat_Climate logtype text
attr FileLog_Bad_Thermostat_Climate room CUL_HM

define Bad_Thermostat_WindowRec CUL_HM 1BF83703
attr Bad_Thermostat_WindowRec chanNo 03
attr Bad_Thermostat_WindowRec device Bad_Thermostat
attr Bad_Thermostat_WindowRec model HM-CC-TC
attr Bad_Thermostat_WindowRec room CUL_HM
define FileLog_Bad_Thermostat_WindowRec FileLog ./log/Bad_Thermostat_WindowRec-%Y.log Bad_Thermostat_WindowRec
attr FileLog_Bad_Thermostat_WindowRec logtype text
attr FileLog_Bad_Thermostat_WindowRec room CUL_HM

***************************************************************************************

Sind die Einträge o.k.? Oder müsste ich zumindest unter Climate die peerID des HM-CC-VD sehen (so stehts zumindest FHEMwiki)?

Das Problem mit dem fehlenden Stellventil-Wert ist damit zumindest leider immer noch nicht gelöst. Bei allen 6 HM-CC-TC das Gleiche :o((

Wie kann ich das Problem einkreisen?

Dank + Gruß
Uli

[martinp876]

Hallo Uli,

die Eintraege sind ok.

ja, die peers fehlen. Es koennten im Window-receiver Fensterkontakte eingetragen sein - aber in jeden Fall die VDs in den climate channels.

So jetzt vorsicht: Es macht keinen Sinn, diese Eintraegen in FHEM zu "machen" - FHEM muss sie aus dem Device lesen! Die Peers muessen im Device stehen und koennen ggf mit devicepair eingetragen werden.

Also erstens "Lesen"
- du kannst die Daten aus dem TC mit "set getConfig" lesen
- du kannst das lesen nach reboot automatisieren mit dem Attribut "autoReadReg" Nach reboot wird dann - zeitlich entzerrt plus wartezeit auf den TC - die Info gelesen. Kann also mehrere Minuten dauern (3min fuer TC - plus zeitstaffel)

==> jetzt sollte die Liste gefuellt sein - jedenfalls hast du jetzt den Stand der Info aus dem TC.
Sollte immer noch kein peer vorhanden sein (attribut peerIDs und readigns peerList) musst du peeren. Siehe "devicepair"

Gruss
Martin

[Uli70]

Hallo Martin,

ein set <TC> getconfig wird leider immer nur mit einem MISSING ACK im Logfile quitiert. Hast Du noch einen Tip für mich? Ich weiss gar nicht wo ich da ansetzten muss :o(

Gruß
  Uli

[Billy]

Hallo Martin,

ein set <TC> getconfig wird leider immer nur mit einem MISSING ACK im Logfile quitiert.

Muss das nicht mit grossem C ein "set <TC> getConfig" sein? Oder war das nur ein Schreibfehler?

Gruss Billy

[Uli70]

Danke. Ist hier nur eine Nachlässigkeit vom mir gewesen. Den Befehl habe ich in FHEM übers Pull-Down-Menü gesetzt, da stimmt es ja dann.
 Gruß Uli

[Rohan]

Hi Uli,

setz den Befehl ruhig noch ein- oder zweimal ab. Der HM-CC-TC ist ein wenig störrisch, hat aber meist nach mehrmaliger Wiederholung den Befehl trotzdem geschluckt.

Nach ca. 5 - 10 Min. mache mal bitte ein

Code Auswählen Erweitern

list Bad_Thermostat

ein

Code Auswählen Erweitern

list Bad_Thermostat_Climate

und poste bitte die Rückgaben.

Gruß
Thomas

[martinp876]

Hi,

etwas problematisch koennte es sein, wenn der TC noch keinen VD zu steuern hat. Bin nicht sicher, dass er sich dann regelmaessig meldet.

Was immer geht ist
- kommando absetzen
- ok 20sek drücken
=> TC sollte (muss) jetzt die Sequenz abarbeiten.
das spart wartezeit, wenn man testen will

Gruss
Martin

[Uli70]

Hallo Thomas, hallo Martin,

ich habe versucht Eure Hilfen umzusetzen (set Bad_Thermostat getConfig => OK-Taste am TC gedrückt => list Bad_Thermostat / list Bad_Thermostat_Climate).

Ergebnisse siehe angehängte Txt-Datei.

Ich hoffe, Ihr könnt was Hilfreiches draus ablesen.

Dank + Gruß
  Uli

P.S.: ...ich glaube, ich hatte auch ein Problem mit der HMid. Die FHEM HMid war eine andere als die durch den Windows-Konfigurator gesetzt ID. Das habe ich geradegezogen und noch einmal mit dem HM-Lan über FHEM neu gepaired. Ich hoffe, das war richtig!? In jedem Fall, sah danach die jeweilige "List" deutlich umfangreicher aus, wie im Anhang zu sehen. Das eigentliche Problem "die fehlende Ventilstellung" ist aber unverändert.

[Rohan]

Hallo Uli,

sorry, ich hatte diesen Thread aus den Augen verloren.

Es fehlt nach wie vor die Peer-Info zum / vom VD. Da ich ein Peering mittels FHEM-Befehlen noch nie gemacht habe, kann ich hier nur den HomeMatic-Weg beschreiben:

* TC auf Werkseinstellung (danach erst mal nur Datum und Zeit setzen)
* VD auf Werkseinstellung
* VD initialisieren lassen
* jetzt den TC über => Menü => Add VD setzen (noch nicht ok drücken)
* VD in den Anlernmodus versetzen
* am TC OK drücken, er fängt an von 20 rückwärts zu zählen, anlernen sollte aber schnell erledigt sein, es erscheint "ok" (ansonsten "nok" (so meine Erinnerung) )
* VD-Display sollte (jetzt erst!) Antennensymbol anzeigen
* Im TC-Menü gibt es die Option, sich die max. 4 VDs anzeigen zu lassen (siehe HM-Handbuch), siehst du einen?

erst wenn das soweit ist, in FHEM set hmPairForSec 600 machen und den TC in den Anlernmodus versetzen, autoReadReg 1 setzen, warten und im _Climate-Channel des TC nach dem VD-Peer-Eintrag schauen.

Hat bei mir zigmal so geklappt, warum nicht auch bei dir?

Gruß
Thomas

[Uli70]

Hallo Thomas,

vielen Dank für Deine Antwort.

Da ich ohnehin heute ein weiteres jungfräuliches HM-CC-TC + VD Set installieren wollte, bin ich genau nach Deiner Anleitung vorgegangen (die ja im Prinzip dem normalen Vorgehen entspricht).

Leider habe ich jedoch als Ergebnis wieder keine Eintrage für peerList und peerID. Dafür aber Angaben zu "PairedTo" und "R-pairCentral" (siehe Anhang). Hast Du diese Parameter auch? Sehen die "normal" aus?

Wie Du jedoch auch siehst, bekomme ich aber trotz fehlender peerID etc. den Actuator-Wert des Stellantriebes!? Kannst Du mir das erklären?

Ich habe übrigens mal im anfänglichen Übereifer den Sicherheitsschlüssel des HM-LAN_Adampters geändert (ich weiss, hätte ich nicht machen sollen). Frage ist, ob hier evtl. auch der Hund begraben ist? Weisst Du hier was?

Dank + Grüsse
Uli

[Rohan]

Hallo Uli,

bin ich genau nach Deiner Anleitung vorgegangen (die ja im Prinzip dem normalen Vorgehen entspricht).

Ja.

Leider habe ich jedoch als Ergebnis wieder keine Eintrage für peerList und peerID.

Die VD-Peers tauchen im Kanal <TC-Name>_Climate auf. Schau mal da nach. Und siehst du den VD im HM-CC-TC?? Bitte Handbuch Seite 24
* Menü-Taste für 4 Sek. drücken
* Mit Stellrad Menüpunkt "VST" wählen
* VST mit "OK" bestätigen => Info-Anzeige zum 1. VD (bei mehr als einem VD kann mit dem Stellrad zwischen diesen gewechselt werden.
Wenn der / die VD dort auftaucht, dann ist alles gepeert.

Verpasse bitte dem TC noch das "attr <TC-Name> autoReadReg 1", starte FHEM neu und nach 5 Minuten bitte ein "list <TC-Name>" machen. Alternative ein "set <HM-CC-TC-Name> getConfig".

Dafür aber Angaben zu "PairedTo" und "R-pairCentral" (siehe Anhang). Hast Du diese Parameter auch? Sehen die "normal" aus?

Ja und Ja.

Wie Du jedoch auch siehst, bekomme ich aber trotz fehlender peerID etc. den Actuator-Wert des Stellantriebes!? Kannst Du mir das erklären?

Nein, evtl. Martin876.

Ich habe übrigens mal im anfänglichen Übereifer den Sicherheitsschlüssel des HM-LAN_Adampters geändert (ich weiss, hätte ich nicht machen sollen). Frage ist, ob hier evtl. auch der Hund begraben ist? Weisst Du hier was?

Sorry, nichts wirklich und dann sage ich besser nix ;)

Gruß
Thomas

[martinp876]

Wie Du jedoch auch siehst, bekomme ich aber trotz fehlender peerID etc. den Actuator-Wert des Stellantriebes!? Kannst Du mir das erklären?

Die peerIDs werden aus dem TC gelesen (sollen gelesen werden). Wichtig ist also erst einmal, dass der Wert IM TC steht. Ob das attribut peerIDs gefuellt ist oder nicht hat operationell erst einmal keinen Einfluss.
Das gilt fuer alle Einstellungen IM Device: Die Werte, die in FHEM angezeigt werden (allen Andren sind in readings angesiedelt) sind zur Kontrolle. Ausgefuehrt wird immer was im Device steht.

Du kannst das Attribut peerIDs jederzeit loeschen oder es nie gelesen haben... deshalb funktioniert es immer noch.

Korrekt waere, wenn du ein getConfig auf den TC machst. Dann sollten die peers aller Channels gelesen werden - und das Attribut peerIDs wird gefuellt. VDs stehen im climate channel.
Wenn du nicht speicherst ist das Attribut nach restart wieder verschwunden - klar.

Was du machen koenntest (so mache ich es) ist das attribut autoReadReg auf 1 zu setzen, dann wird das entsprechende Device automatisch nach jeden reboot gelesen.
Beschreibung beachten: autoReadReg besser nur im device setzen, in den Channels ist dies nicht notwendig, die kommen automatisch mit.

Noch eine Anmerkung: Fuer devices die ich nicht automatisch auslesen kann (remotes,...) achte ich darauf, dass ich die peerIDs sauber abspeichere. Hier macht das Attribut autoReadReg keinen Sinn, auch klar hoffe ich. Hier also "manuell" lesen und einen save machen. Auch hier noch einmal: Wenn man die peerIDs nicht im attribut hat funktioniert es immer noch.

Und noch eine Anmerkung (wir sind schon weit weg vom TC..) Bei virtuellen devices sind die peerIDs natuerlich wieder wichtig. Diese Arbeiten mit diesen Einstellungen - da ist ja kein physikalisches device, das Daten haelt....

Aber das steht alles im commandref

Gruss
Martin

[Uli70]

Hallo Thomas, hallo Martin,

abermals vielen Dank für all die wertvollen Informationen.

Den Eintrag attr autoReadReg 1 habe ich vorgenommen, damit wird auch eine Menge aus dem TC ausgelesen, aber die peerID bleibt leer.

Ich habe zwar verstanden, dass dies für die Funktion des TC keinen Einfluss hat, dennoch würde ich gerne wissen, warum dieser Wert bei meinen TC`s nicht gefüllt bzw. ausgelesen werden kann!?

Habt Ihr noch eine letzte Idee?

Ich habe die List <TC> nach ausführen des autoReadReg Attributes angehängt.

Dank + Grüße
  Uli