Da ich Probleme mit meinen Templists habe wurde mir empfohlen Fehler in meiner Config zu fixen. Das Ganze läuft seit ca 5 Jahren, es kann also sein, dass manches einfach nicht mehr State of the Art ist. Da manch einer vielleicht die gleichen Probleme hat wie ich stehen hier auch die Probleme, die ich mittlerweile gefixt habe (eigene Antworten)
configCheck done:
missing register list
WT_KiZi: RegL_00.
WT_KiZi_Climate: RegL_01.,RegL_07.,RegL_08.,RegL_09.
WT_KiZi_SwitchTr: RegL_01.
WT_KiZi_Weather: RegL_01.
WT_KiZi_WindowRec: RegL_01.
WT_KiZi_remote: RegL_01.
incomplete register list
WT_WoZi_Climate: RegL_07.
peer not verified. Check that peer is set on both sides
HK_Bad_Climate: p:WT_Bad_Climate
HK_Bad_Weather: p:WT_Bad_Weather
HK_KiZi2_Weather: p:WT_KiZi_Weather
HK_KiZi_Climate: p:WT_KiZi_Climate
HK_KiZi_Weather: p:WT_KiZi_Weather
HK_WoZi_1_Climate: p:WT_WoZi_Climate
HK_WoZi_1_Weather: p:WT_WoZi_Weather
HK_WoZi_2_Climate: p:WT_WoZi_Climate
HK_WoZi_2_Weather: p:WT_WoZi_Weather
boost or template differ in team
WT_KiZi_Climate: team:HK_KiZi2_Clima boost differ Value not captured:WT_KiZi_Climate - boostPeriod / 5
WT_KiZi_Climate: team:HK_KiZi2_Clima tempListTmpl differ Kinderzimmer / none
templist mismatch
HK_Ku_Clima: HK_Ku_Clima not found in file ./FHEM/Winter.cfg
HK_SchlaZi_Clima:
HK_SchlaZi_Clima: tempList 1 not verified
WT_Bad_Climate:
WT_Bad_Climate: unprogrammed prog 2
WT_Bad_Climate: unprogrammed prog 3
WT_KiZi_Climate:
WT_KiZi_Climate: unprogrammed prog 2
WT_KiZi_Climate: tempList 1 not verified
WT_KiZi_Climate: unprogrammed prog 3
WT_WoZi_Climate:
WT_WoZi_Climate: unprogrammed prog 3
WT_WoZi_Climate: tempList 1 not verified
WT_WoZi_Climate: unprogrammed prog 2
Nach getconfig für WT_WoZi_Climate verbleiben nur noch die missing register lists (was heißt denn das?)
configCheck done:
missing register list
WT_KiZi: RegL_00.
WT_KiZi_Climate: RegL_01.,RegL_07.,RegL_08.,RegL_09.
WT_KiZi_SwitchTr: RegL_01.
WT_KiZi_Weather: RegL_01.
WT_KiZi_WindowRec: RegL_01.
WT_KiZi_remote: RegL_01.
incomplete register list
WT_WoZi_Climate: RegL_07.
peer not verified. Check that peer is set on both sides
HK_Bad_Climate: p:WT_Bad_Climate
HK_Bad_Weather: p:WT_Bad_Weather
HK_KiZi2_Weather: p:WT_KiZi_Weather
HK_KiZi_Climate: p:WT_KiZi_Climate
HK_KiZi_Weather: p:WT_KiZi_Weather
HK_WoZi_1_Climate: p:WT_WoZi_Climate
HK_WoZi_1_Weather: p:WT_WoZi_Weather
HK_WoZi_2_Climate: p:WT_WoZi_Climate
HK_WoZi_2_Weather: p:WT_WoZi_Weather
boost or template differ in team
WT_KiZi_Climate: team:HK_KiZi2_Clima boost differ Value not captured:WT_KiZi_Climate - boostPeriod / 5
WT_KiZi_Climate: team:HK_KiZi2_Clima tempListTmpl differ Kinderzimmer / none
templist mismatch
HK_Ku_Clima: HK_Ku_Clima not found in file ./FHEM/Winter.cfg
HK_SchlaZi_Clima:
HK_SchlaZi_Clima: tempList 1 not verified
WT_Bad_Climate:
WT_Bad_Climate: unprogrammed prog 2
WT_Bad_Climate: unprogrammed prog 3
WT_KiZi_Climate:
WT_KiZi_Climate: unprogrammed prog 2
WT_KiZi_Climate: tempList 1 not verified
WT_KiZi_Climate: unprogrammed prog 3
WT_WoZi_Climate:
WT_WoZi_Climate: unprogrammed prog 3
WT_WoZi_Climate: tempList 1 not verified
WT_WoZi_Climate: unprogrammed prog 2
Missing regList heißt, dass von diesem Gerät noch nicht alle Register (Konfig-Einträge des Flash im Gerät) gelesen wurden: getConfig
Das Gerät was jetzt (noch) angemerkt wird ist ja KiZi und nicht WoZi ;)
Also auch dafür ein getConfig usw.
Peer not verified: entweder konnte das nicht geprüft werden, weil eben noch nicht alle Einträge gelesen wurden (getConfig) oder die tatsächlich nicht eingetragen sind (erneut Peeren)...
EDIT: und warten bis getConfig auch abgearbeitet ist, also keine cmdsPending mehr sind... Evtl. vor einem getConfig noch clearMsg
EDIT: CUL_HM / fhem ist aktuell?!
EDIT: irgendwelche TimeOutRegisterRead?
Und: wieder Anfängerfragen ;)
Du kannst das verschieben 8)
Gruß, Joachim
Danke, das mit dem KiZi hatte ich nur für mitleser gemacht. Aber Du hast Recht ich habe was anderes geschrieben als gemacht.
Anfängerfragen=> War Absicht, denn ich dachte das sei allgemein FHEM weilConfig und nicht Homematic spezifisch
Update => Heute 10:30 alles aktuell
TimeOutRegisterRead => noch nicht
Zitat von: Louis Cypher am 26 November 2022, 11:28:21
Anfängerfragen=> War Absicht, denn ich dachte das sei allgemein FHEM weilConfig und nicht Homematic spezifisch
Tja ;)
Hier geht es um eine Homematic-interne Prüfung.
Ja ist evtl. nicht gleich zu erkennen ;)
Drum ja im anderen Thread bewusst der Hinweis die configCheck-Sachen im Homematic Unterforum zu posten oder sogar erst dort zu suchen, weil das kommt immer wieder, dass da "aufgeräumt" werden sollte...
Aber: du kannst immer noch verschieben ;)
Zitat von: Louis Cypher am 26 November 2022, 11:28:21
Update => Heute 10:30 alles aktuell
TimeOutRegisterRead => noch nicht
Gut.
Welches Funkmodul hast du?
Wenn kein CUL, dann sollte dich das auch eher selten/gar nicht treffen.
Wenn du einen CUL (also kein "Original HM-Funkmodul") hast, dann kann das zusätzlich Probleme machen...
Aber erst mal eins nach dem andern 8)
Gruß, Joachim
Ich habe den tollen HM-USB Dongle.
So, die Register sachen sind gelöst. Beim Peering habe ich noch Probleme und ein wenig die Hosen voll, denn ich hab in Erinnerung, dass das nicht so wirklich gut funktioniert hat. In welche Richtung fehlt hier der Link? Zurück von z.B: WT_Bad_Climate zu HK_Bad_Climate (das Konzept, dass ein Peering beidseitig gesetzt sein muss ist mir etwas "fremd"; Wenn ein Link da ist ist er da hätte ich gedacht):
configCheck done:
peer not verified. Check that peer is set on both sides
HK_Bad_Climate: p:WT_Bad_Climate
HK_Bad_Weather: p:WT_Bad_Weather
HK_KiZi2_Weather: p:WT_KiZi_Weather
HK_KiZi_Climate: p:WT_KiZi_Climate
HK_WoZi_1_Climate: p:WT_WoZi_Climate
HK_WoZi_1_Weather: p:WT_WoZi_Weather
HK_WoZi_2_Climate: p:WT_WoZi_Climate
HK_WoZi_2_Weather: p:WT_WoZi_Weather
WT_KiZi_Weather: p:HK_KiZi_chn-23
WT_KiZi_Weather: p:HK_KiZi_chn-6C
WT_WoZi_Climate: p:HK_Ku_Climate
WT_WoZi_Weather: p:HK_Ku_Weather
boost or template differ in team
WT_KiZi_Climate: team:HK_KiZi2_Clima tempListTmpl differ Kinderzimmer / none
WT_WoZi_Climate: team:HK_Ku_Clima tempListTmpl differ Wohnzimmer / --
templist mismatch
HK_ArZi_Clima: failed Entries:
HK_ArZi_Clima: R_0_tempListSat mismatch 09:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_ArZi_Clima: R_1_tempListSun mismatch 09:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_ArZi_Clima: R_2_tempListMon mismatch 08:00 15.0 19:00 21.0 24:00 15.0 ne 24:00 10.0 ##
HK_ArZi_Clima: R_3_tempListTue mismatch 08:00 15.0 19:00 21.0 24:00 15.0 ne 24:00 10.0 ##
HK_ArZi_Clima: R_4_tempListWed mismatch 08:00 15.0 19:00 21.0 24:00 15.0 ne 24:00 10.0 ##
HK_ArZi_Clima: R_5_tempListThu mismatch 08:00 15.0 19:00 21.0 24:00 15.0 ne 24:00 10.0 ##
HK_ArZi_Clima: R_6_tempListFri mismatch 08:00 15.0 19:00 21.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: failed Entries:
HK_GaeTo_Clima: R_0_tempListSat mismatch 09:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: R_1_tempListSun mismatch 09:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: R_2_tempListMon mismatch 08:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: R_3_tempListTue mismatch 08:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: R_4_tempListWed mismatch 08:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: R_5_tempListThu mismatch 08:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_GaeTo_Clima: R_6_tempListFri mismatch 08:00 15.0 19:00 18.0 24:00 15.0 ne 24:00 10.0 ##
HK_Ku_Clima: HK_Ku_Clima not found in file ./FHEM/Winter.cfg
HK_SchlaZi_Clima: failed Entries:
HK_SchlaZi_Clima: R_0_tempListSat mismatch 07:00 17.0 09:30 20.0 22:00 15.0 24:00 17.0 ne 24:00 10.0 ##
HK_SchlaZi_Clima: R_1_tempListSun mismatch 07:00 17.0 09:30 20.0 22:00 15.0 24:00 17.0 ne 24:00 10.0 ##
HK_SchlaZi_Clima: R_2_tempListMon mismatch 07:00 17.0 21:00 15.0 24:00 17.0 ne 24:00 10.0 ##
HK_SchlaZi_Clima: R_3_tempListTue mismatch 07:00 17.0 21:00 15.0 24:00 17.0 ne 24:00 10.0 ##
HK_SchlaZi_Clima: R_4_tempListWed mismatch 07:00 17.0 21:00 15.0 24:00 17.0 ne 24:00 10.0 ##
HK_SchlaZi_Clima: R_5_tempListThu mismatch 07:00 17.0 21:00 15.0 24:00 17.0 ne 24:00 10.0 ##
HK_SchlaZi_Clima: R_6_tempListFri mismatch 07:00 17.0 21:00 15.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: failed Entries:
WT_Bad_Climate: R_P1_0_tempListSat mismatch 06:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: R_P1_1_tempListSun mismatch 06:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: R_P1_2_tempListMon mismatch 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: R_P1_3_tempListTue mismatch 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: R_P1_4_tempListWed mismatch 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: R_P1_5_tempListThu mismatch 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: R_P1_6_tempListFri mismatch 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ne 24:00 10.0 ##
WT_Bad_Climate: unprogrammed prog 2
WT_Bad_Climate: unprogrammed prog 3
WT_KiZi_Climate: failed Entries:
WT_KiZi_Climate: R_P1_0_tempListSat mismatch 09:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_1_tempListSun mismatch 09:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_2_tempListMon mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_3_tempListTue mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_4_tempListWed mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_5_tempListThu mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_6_tempListFri mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: unprogrammed prog 3
WT_KiZi_Climate: unprogrammed prog 2
WT_WoZi_Climate: failed Entries:
WT_WoZi_Climate: R_P1_0_tempListSat mismatch 07:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: R_P1_1_tempListSun mismatch 07:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: R_P1_2_tempListMon mismatch 07:00 15.0 09:00 19.0 11:00 17.0 13:00 19 17:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: R_P1_3_tempListTue mismatch 07:00 15.0 09:00 19.0 11:00 17.0 13:00 20.0 17:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: R_P1_4_tempListWed mismatch 07:00 15.0 09:00 19.0 11:00 17.0 13:00 20.0 17:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: R_P1_5_tempListThu mismatch 07:00 15.0 09:00 19.0 11:00 17.0 13:00 20.0 17:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: R_P1_6_tempListFri mismatch 07:00 15.0 09:00 19.0 11:00 17.0 13:00 20.0 17:00 15.0 23:00 20.0 24:00 15.0 ne 24:00 10.0 ##
WT_WoZi_Climate: unprogrammed prog 2
WT_WoZi_Climate: unprogrammed prog 3
Gesetzt wird er in beiden Geräten, also Sensor und Aktor:
Der Sensor muss ja wissen wohin er senden soll und wo er dann auf Quittung warten soll/muss...
...ebenso muss nat. der Aktor wissen, dass er auf das Telegramm reagieren soll und eine Quittung zurückschicken soll/muss...
Also in BEIDEN Geräten wird das ins Flash geschrieben mit EINEM Befehl von fhem (oder allgemein: der Zentrale).
Dann kann es sein, dass z.B. ein Gerät das nicht mitgekriegt hat -> es steht dann nicht im Flash...
Oder es wurde nicht zurückgelesen, dann weiß fhem davon nichts...
Also einfach noch mal den (am besten notierten ;) Stichwort: Attribut comment / dort lege ich solche Sachen ab) Peering-Befehl absetzen...
Oder Peer-Smart nutzen: https://forum.fhem.de/index.php?topic=98054.0
(hab ich aber noch nie genutzt, kann daher dabei auch nicht weiterhelfen)
Gruß, Joachim
Einfach ist gut ;-). Ich habe gerade nachgesehen. Das Pairing der meisten Devices sollte 2012 - 2013 gewesen sein :o
Ich warte jetzt erstmal bis alle getConfigs abgearbeitet sind. Und dann werd ich dem Löwen wohl mal in den stinkenden Atem schauen müssen
Viel Erfolg!
Gruß, Joachim
So bis auf das Peering und die Temperaturen ist alles gelöst außer die Boost Geschichte. Was hat es damit auf sich? Kann ich das zurücksetzen?
GetConfig mit ClearMessages davor hat den Rest gelöst (und ein paar neue Batterien für einen WT)
configCheck done:
peer not verified. Check that peer is set on both sides
HK_Bad_Climate: p:WT_Bad_Climate
HK_Bad_Weather: p:WT_Bad_Weather
HK_KiZi2_Weather: p:WT_KiZi_Weather
HK_KiZi_Climate: p:WT_KiZi_Climate
HK_WoZi_1_Climate: p:WT_WoZi_Climate
HK_WoZi_1_Weather: p:WT_WoZi_Weather
HK_WoZi_2_Climate: p:WT_WoZi_Climate
HK_WoZi_2_Weather: p:WT_WoZi_Weather
WT_KiZi_Weather: p:HK_KiZi_chn-23
WT_KiZi_Weather: p:HK_KiZi_chn-6C
WT_WoZi_Climate: p:HK_Ku_Climate
WT_WoZi_Weather: p:HK_Ku_Weather
boost or template differ in team
WT_KiZi_Climate: team:HK_KiZi2_Clima tempListTmpl differ Kinderzimmer / none
WT_WoZi_Climate: team:HK_Ku_Clima tempListTmpl differ Wohnzimmer / --
templist mismatch
HK_Ku_Clima: HK_Ku_Clima not found in file ./FHEM/Winter.cfg
WT_Bad_Climate:
WT_Bad_Climate: unprogrammed prog 3
WT_Bad_Climate: unprogrammed prog 2
WT_KiZi_Climate: failed Entries:
WT_KiZi_Climate: R_P1_0_tempListSat mismatch 09:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_1_tempListSun mismatch 09:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_2_tempListMon mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_3_tempListTue mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_4_tempListWed mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_5_tempListThu mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: R_P1_6_tempListFri mismatch 17:00 15.0 24:00 15.0 ne 07:00 15.0 23:00 19.0 24:00 17.0 ##
WT_KiZi_Climate: unprogrammed prog 2
WT_KiZi_Climate: unprogrammed prog 3
WT_WoZi_Climate: failed Entries:
WT_WoZi_Climate: R_P1_2_tempListMon mismatch 07:00 15.0 09:00 19.0 11:00 17.0 13:00 19 17:00 15.0 23:00 20.0 24:00 15.0 ne 07:00 15.0 09:00 19.0 11:00 17.0 13:00 19.0 17:00 15.0 23:00 20.0 24:00 15.0 ##
WT_WoZi_Climate: unprogrammed prog 3
WT_WoZi_Climate: unprogrammed prog 2
Da bin ich leider raus :-\
Hast du HKTs im Team/Gruppen laufen?
Klingt so als hättest du Teams/Gruppen und damit ja den Wunsch diese gleich laufen zu lassen aber Unterschiede in den Templisten -> widerspricht ja dem Gedanken...
Aber mehr Idee hab ich dazu auch nicht...
Gruß, Joachim
Ich bin mir nicht sicher, dass ich Dich komplett verstanden habe. Ich habe sowohl die HK als auch die zugehörigen WT in Homematic gepairt. Ich bin davon ausgegangen, dass FHEM weiß dass der WT der Master, der HK der Slave ist. Sonst macht ja der WT keinen Sinn. (Sorry für das unkorrekte Wording; mir gefällt gerade nicht ein wie das heute heißt; irgendwas mit Avatar)
Liebe Grüße
Wichtig:
Pairen: verbinden/anlernen eines Gerätes an eine Zentrale
PEEREN: "verbinden" von einem Sensor mit einem Aktor
fhem/die Zentrale kann das auslesen und anzeigen...
...ABER: die Geräte "regeln" das untereinander.
(das ist ja das schöne: selbst wenn fhem mal nicht läuft, dann funktioniert alles was eingestellt ist und auf den Geräten liegt/Flash weiterhin)
Also fhem ist es egal, wer "Master" ist ;)
fhem macht nur was du sagst ;)
Also Temperaturen weitergeben oder gemessene anzeigen, Templisten übertragen (auf Anweisung) usw.
Regeln usw. tun dann die Geräte laut ihrer Config/Flash
Wenn du mehrere HKTs verbunden hast oder WDTs (geht das überhaupt), dann verhalten sich diese als Team/Gruppe.
Also du drehst an einem HKT und es wird an den "verbundenen" ebenso "gedreht".
EDIT: damit sollten nat. bei den als "Team" verbundenen HKT-Wochenprogramme auch "synchron" sein, sonst ist ja da bzgl. Team/Gleichverhalten ein Problem: welcher HKT stimmt nun?
Das hat nichts mit fhem zu tun (außer, dass es u.U. mittels fhem mal so eingerichtet wurde / geht aber auch ohne fhem/Zentrale, wenn man es macht BEVOR man die Geräte an eine Zentrale/fhem anlernt / steht aber ja in der BD der HKT, WDT, ... und hat nichts mit fhem zu tun, das ist ganz "normal" Homematic)...
EDIT: und ja, wenn du den WDT mit dem HKT peerst (vorher ohne Zentrale/fhem oder nach Anlernen über die Zentrale/fhem), dann regelt der HKT nach der gemessenen Temp des WDT und nimmt auch von dem die "Wunschtemperatur" entgegen (bei auto aus dem Wochenprogramm bei manu eben wie er gerade eingestellt ist). Da aber ja mal Telegramme verloren gehen können, halte ich eben WDT und HKT Programme "synchron"...
EDIT: wenn du nur den WDT anpassen willst (Wochenprogramme) und den HKT gepeert hast und es dich nicht stört, dass der HKT bei Telegrammverlust "irgendwas" macht (z.B. Dauer-17Grad), dann musst du auch keine HKT-Wochenprogramme "pflegen", bekommst allerdings von HMinfo eben die Meldung, dass die Einträge fehlen. Ist ja nicht schlimm, ist ja nur ein Hinweis. Wenn du das so willst, dann kannst du diese Meldungen auch ignorieren. Was du halt nicht brauchen kannst sind falsch/fehlerhaft befüllte templisten, die können ja nicht übertragen werden...
Gruß, Joachim
Ok, Danke. Ja, dann habe ich Gruppen
Z.B. WT_Wozi_Clima regelt 2 Heizkörper HK_WoZi... im Wohnzimmer. Deswegen möchte ich auch nur dem WT die Temperatur zuweisen, damit der das an die HK weitergibt. Wenn FHEM egal ist wer wer ist kann das natürlich Mumpitz sein es sei denn es wird einfach die letzte Änderung an alle weitergeleitet. Ich habe allerdings leider vergessen wo ich die Entity zugeordnet habe. Aber der Teil gehört dann eigentlich in den anderen Thread, richtig?
Liebe Grüße,
P.S.: Die Listen greifen wieder trotz der Fehlermeldungen. Ich friere zumindest nicht mehr ;-)
Noch mal:
fhem "verwaltet" nur die Templisten und spielt sie auf Wunsch per hminfo zurück auf die Geräte.
(fhem zeigt noch die aktuellen Temps an und übergibt auch Temps an einzelne Geräte, wenn du das auslöst aber das ist genauso als würdest du "am Rad drehen")
Die Geräte machen SELBSTÄNDIG nach Einstellung (auto/manu) was in ihren Registern/Flsh steht (Wochenprogramm etc.).
Da ist fhem (komplett) raus.
Du kannst auch nur die WDT mit Templisten versorgen...
(Wenn du dann die Einträge für HKT rauslöschst, dann bekommst du eben "Fehlermeldungen" bzw. wird dir mitgeteilt, dass keine Einträge für HKT gefunden wurden)
ABER: wenn mal Funk gestört ist o.ä. dann regelt halt der HKT aufgrund SEINES Wochenprogrammes und wenn das nicht "synchron" mit dem WDT ist, dann regelt er halt "anders".
Daher halte ICH die "synchron"...
Aber: das musst du für dich entscheiden...
Gruß, Joachim
Guten Morgen,
Habe mich an die Peering Fehler gemacht. Ich verstehe die Anleitungen zum peeren nicht (jetzt erinnere ich mich warum mir das Thema unsympathisch war; das was ich eintippen musste passte für mein Gehirn nicht zur Anleitung).
Wenn ich einen Sensorkanal (sagen wir WT_Wozi_Climate) mit einem Aktorkanal (sagen wir HK_Wozi_Clima) gepeert habe ist frage ich mich wie das eine unidirektionale Verbindung sein kann. Am Wandthermostat gibt es ja gar nichts was ein Aktor sein könnte. Ist hier mit Aktor und Sensor eigentlich Sender und Empfänger gemeint?
Hieße das es muss nach
set WT_Wozi_Climate peerChan 0 HK_Wozi_Clima single set
noch ein
set HK_Wozi_Clima peerChan 0 WT_Wozi_Climate single set
kommen?
Warum die 0 da stehen muss habe ich in der Doku auch nicht gefunden
Dazu kommt, dass die Fehler eigentich zu Kanälen gemeldet werden, die ich gar nicht nutze und meiner Ansicht nach nie gepeert habe. Ich habe nur die Clima Kanäle (Kanal 4) der Heizkörper mit dem Climate Kanal (Kanal 2) des WT gepeert.
Wie wäre es sich auf einen Thread zu konzentrieren!!?
Weil genau das habe ich in DIESEM Thread weiter vorne GENAU (so ich konnte) erklärt.
UND: nun zusätzlich im anderen Thread noch mal (mit Verweis auf "hier" wo ich es bereits erläutert hatte)...
Im Wiki sollte es doch ganz gut beschrieben sein?
Schon mal durchgelesen/durchgewühlt?
Zu Homematic, Pairen, Peeren, usw. steht so einiges im Wiki...
https://wiki.fhem.de/wiki/HomeMatic
https://wiki.fhem.de/wiki/HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat
https://fhemwiki.de/wiki/HomeMatic_Peering_Beispiele
https://wiki.fhem.de/wiki/HomeMatic_Devices_pairen
Gruß, Joachim
Hab mit Absicht in diesen Thread gecopy pasted, denn hier geht es ja um Config Fehler. Die Templists funktionieren ja.
Ja die Dinger habe ich gelesen. Mein Problem mit vielen Wiki einträgen ist, dass die Erklärungen von FHEM Profis geschrieben sind und nah am Maximum in Sachen Fachbegriffe sind (meiner Ansicht nach auch dort wo das nicht nötig ist).
Zu dem was Du oben geschrieben hast. Ja jab ich verstanden, wollte mich aber rückversichern
Und hier das Besipiel wo ich an der Doku verzweifle:
set HK_Wozi_Clima peerChan 0 WT_Wozi_Climate single setDokumentiert ist Aktor Channel, Sensorchannel.... Kein Wort zu dem Parameter, der hier eine 0 ist obwohl er nicht zwangsläufig eine Null sein muss, wenn ich Dich richtig verstehe. Da sollte doch ein <Channel> und nicht eine 0 in der Doku stehen, oder?
Frage Nummer zwei: Da steht
Zitatset <sensChan> peerChan 0 <actChan> [single|dual] [set|unset]
Ich verbinde also zum Beispiel <sensChan> Kanal 4 des Sensors mit <actChan> Kanal4 des Aktors. Was ist denn dann der Peerchannel? Das ist doch eindeutig. Finde ich aber nicht in der Doku ::)
set HK_Wozi_Clima peerChan 0 WT_Wozi_Climate single set
GENAU ANDERSRUM!!
Habe ich doch geschrieben und steht (mMn) auch im Wiki und den Peering-Beispielen...
Wenn du bereits das Kommando AM CHANNEL (also 4) ausführst, dann 0 (weil du hast ja bereits im Namen beim Ausführen des Befehls den Channel also implizit 4 angegeben).
Wenn du den Befehl am Hauptdevice ausführen würdest, dann musst du nat. mitteilen welchen Kanal: 4
Warum nicht einfach die Beispiele (die ja beim WDT im Wiki und beim HKT im Wiki stehen) nehmen, mit deinen Namen ersetzen/anpassen und gut?
Ich habe (seither) nie darüber nachgedacht, sondern einfach so lange/oft den Befehl inkl. getConfig abgesetzt, bis configCheck io war fertig.
Gruß, Joachim
Zu ANDERSRUM: Sorry, nmy bad. Das hatte ich nur aus meinem Text copy pasted um zu erklären wo ich das Problem mit der Doku gesehen habe. Ich habe schlichtweg die falsche Zeile aus meinem Post gecopy pasted :-\ Ich hab das schon so gemacht wie Du geschrieben hast.
Ich kann der Doku nicht entnehmen, dass man auch das ganze Device peeren kann. Da steht ganz eindeutig *Channel*. Und genau deswegen macht für mich in dem Fall der Parameter peerChannel keinen Sinn mehr. Stünde da eine Erklärung könnte ich das nachvollziehen, ansonsten Frage ich mich warum ich drei Mal Channel angebe
Da mögen wir unterschiedlicher Meinung sein, aber aus meiner Sicht ist das nicht gut beschrieben.
Zum Thema Beispiel: Wie gesagt mein Kram läuft seit fast 10 Jahren. Und das ganze Setup ist genau mit Hilfe der Besipiele zusammengebastelt. Leider habe ich aber auf einmal Issues. Deswegen versuche ich zu verstehen statt abzutippen. Leider ist das für die, die einem helfen (dafür mal ganz explicit herzlichen Dank!) etwas mühsamer
Man kann auch nicht das ganze Device peeren (nur pairen ;) ).
Sondern nur Kanäle.
Aber wenn du den Peering-Befehl eh schon am Kanal-Device abgibst, dann brauchst du das ja nicht extra angeben...
(Kanal 0 -> "self" wenn man so will / der Befehl versteht/braucht halt eine Kanalnummer und die ist bei "self" halt 0)
Wenn du den Befehl z.B. am Hautpdevice abgibst, dann musst du angeben welcher Kanal denn gepeert werden soll und dann ist es nicht mehr 0 sondern eben z.B. 4 (oder was immer die entsprechende Kanalnummer ist).
Aber ich habe es auch hinbekommen und mich hat das noch nie interessiert und die Peering-Beispiele sind halt bereits am Kanal und daher eben die 0
Wenn dir das zu kompliziert ist: peerSmart...
Da kannst du (so ich das im Kopf habe) per Klick auswählen was mit was gepeert werden soll und fetig.
Gruß, Joachim
wenn ich den cmd peerchan auf der detailseite auswähle, wird mehr als genug doku eingeblendet.
gepeert wird immer nur ein sender chn mit einem receiver chn. eigentlich ganz einfach.
problematisch ist auch immer wieder die erwartungshaltung.