Hallo Zusammen,
ich verwende FHEM mit Homematic Komponenten u.a. zur Steuerung der Heizung - genauer gesagt der Heizkörper.
Mir ist heute aufgefallen, das Peers zwischen dem Weather-Kanal eines HM-TC-IT-WM-W-EU und den Weather-Kanälen zweiter HM-CC-RT-DN nicht mehr korrekt sind. Ich weiß aber, das diese vor ein paar Tagen noch korrekt waren.
Ein HMInfo configCheck liefert die Meldung "peer not verified. Check that peer is set on both sides".
Zum Stellantrieb (Name = Wz.Heizung_Front) enthalten peerList und peerIDs die richtigen Werte.
Zum Thermostats (Wz.Thermostat) enthalten peerLists und peerIDs jedoch Werte die in meinem System nicht existieren.
Also dachte ich, ich löschen den Peer zwischen beiden Weather Kanälen und erstelle ihn neu.
Der Befehl "set Wz.Thermostat_Weather peerChan 0 Wz.Heizung_Front_Weather single unset" scheint jedoch nicht zu funktionieren, oder besser nicht anzukommen.
Das Gerät "Wz.Thermostat" zeigt nach kurzer Zeit immer "Nack" an. Daran ändert sich auch nichts, wenn ich das Thermostat in den Raum lege in dem der HM USB Adapter liegt. Wenn ich dann ein getConfig absetzte wird diese erfolgreich ausgeführt. Nur die Daten des Weather-Kanals zeigen das der Peer immer noch besteht.
Laut Anzeige sind die RSSI Werte mit -64 zwar nicht perfekt aber im Zielbereich.
Mach ich etwas falsch, oder gibt es einen anderen / besseren Weg das Problem bzw. das Peering zu lösen.
Nachtrag:
Nachdem ich es noch ein wenig weiter probiert habe, ist es jetzt so, das im Stellantrieb-Kanal Wz.Heizung_Front_Weather keine Peer-Informationen mehr angezeigt werden. Dieser also scheinbar nicht mehr gepeert ist. Im Thermostat-Kanal Wz.Thermostat_Weather werden jedoch immer noch unbekannte Peer-IDs in peerIDs sowie Namen in peerList angezeigt.
Grüße
Holger
zum loeschen eines peers musst du quasi den selben befehl nutzen, wie beim anlegen des peers, aber eben mit unset.
peerchan erwartet immer vorne den sensor und hinten den aktor. daher ist dein befehl falsch.
Die folgenden Zeile stammt aus dem FHEM Wiki:
set <HM-TC-IT-WM-W-EU-Gerät>_Weather peerChan 0 <HM-CC-RT-DN-Gerät>_Weather single set
Da das bei mir Wz.Thermostat genannten Gerät der Wandthermostat vom Typ HM-TC-IT-WM-W-EU ist, und der Gerät Wz.Heizung_Front vom Typ HM-CC-RT-DN würde ich sagen, der von mir verwendete Befehl war/ist korrekt.
Ich bin mittlerweile auch etwas weiter gekommen.
Insgesamt geht es um ein Wandthermostat (HM-TC-IT-WM-W-EU) der 2 Heizköroerantriebe (HM-CC-RT-DN) steuern soll. Die beiden heißen Wz.Heizung_Front und Wz.Heizung_Dach.
Der aktuelle "Zustand" der 3 Weather-Kanäle ist:
Wz.Heizung_Dach_Weather (ID = 3177AC01)
- nicht gepeert (keine peerIDs und oder peerList)
Wz.Heizung_Front_Weather (ID = 3177A201)
- erfolgreich gepeert mit Wz.Thermostat_Weather (35A48201)
Wz.Thermostat_Weather (ID = 35A48201)
- erfolgreich gepeert mit Wz.Heizung_Front_Weather (3177A201)
- zeigt weiterhin Peerings mit Wz.Heizung_Dach_chn:31 (3177AC31) und Wz.Heizung_Dach_chn:77 (3177AC77) an
Somit ist einer der beiden Heizkörperantriebe wieder korrekt gepeert. Der andere hingegen noch garnicht.
Auffällig finde ich, das der Thermostat glaubt mit den Kanälen 31 und 77 des Wz.Heizung_Dach gepeert zu sein. Allerdings hat das Device keine Kanäle mit dem Nummern.
Mit Hilfe von Backups meiner fhem.cfg Datei konnte ich ermitteln, das das Peering vorgestern noch in Ordnung war.
Einzige mir gekannte Aktion seit dem war ein Firmware Update des HM-TC-IT-WM-W-EU von 1.2 auf 1.3.
Allerdings hat das Firmware Update bei 3 weiteren Geräten des Typs zu keinem Problem geführt. Die sind jedoch auch nur mit jeweils einem Heizungsaktor verknüpft.
mit diesen seltsamen peerings wuerde ich ein werksreset machen.
Die zahlen sind hex. Die Nummer ist also deutlich höher. Mehr als 63 unterstützt hm nicht, ich denke bei 50 ist Schluss. Bei diesem Kanal sicher deutlich eher.
Beim wetterkanal hatte ich schon Probleme mit dem löschen.... Das ging nicht, egal was ich gemacht habe.
Hallo,
habe die Probleme auch bei einem Thermostat, der zwei RTs bedient.
Das passiert nach einem Reboot, ist evtl. in Firmware 1.3 gefixed, wenn man da einen Factory-Reset macht und neu peered (zumindest interpretiere ich das Changelog so).
Zitat von: holgerschlegel am 27 September 2015, 14:14:58
- zeigt weiterhin Peerings mit Wz.Heizung_Dach_chn:31 (3177AC31) und Wz.Heizung_Dach_chn:77 (3177AC77) an
Das Ding speichert das Peering einfach intern kaputt im EEprom ab. Die komischen Kanalnummern sind nochmal Teil der HMID, deswegen passen sie auch nicht ins Schema.
Nachdem die Wetterdaten eh per Broadcast versendet werden, habe ich meinen Thermostat jetzt nicht nochmal resettet, das hatte ich zuletzt bei FW 1.2 versucht.
Viele Gruesse
Michael
Dann werde ich es wohl morgen Abend mal mit einem Werksreset versuchen.
Leider heißt das, das ich danach auch die 2 Fensterkontakte (Drehgriffkontakte) neu peeren muss. Zu denen ist der Funkkontakt ziemlich bescheiden. Beim ersten mal hab ich jeweils locker 5-6 Versuche gebraucht.
Danke für die Hilfe.
Holger
du musst nur den wandthermostat neu peeren. set fk peerChan 0 tc_windowRec single set actor.
Hab' jetzt mal alle Peer und den Pair mit FHEM gelöscht, dann ein Werksreset direkt am Gerät ausgeführt und Pair und Peers wieder hergestellt.
Mal davon ab, das der ganze Spaß fast 'ne Stunde gedauert hat, werden jetzt alle Peers im Thermostat und den Stellantrieben wieder korrekt angezeigt.
Einzig die Fensterkontakte (Drehgriff) zeigen den Peer zum Thermostat nicht an. Im Thermostat stehen die Peers zu den Fensterkontakten aber drin.
Wenn ich den Drehgriff verwende, wird der passenden "Fenster-offen" Zustand sowohl im Thermostat als auch im FHEM korrekt dargstellt.
Kommischerweise sind die beiden Drehgriffkontakte scheinbar untereinander gepeert. Beide enthalten in peerIDs den ID des jeweils anderen.
Ist das normal, oder habe ich bei meinen Versuchen war verbockt?
Grüße
Holger
ZitatIst das normal,
nein. :)