Moin Moin,
mein hminfo wirft bei dem Befehl checkConfig viele interessante Fehlermeldungen. Leider kann ich nicht alle verstehen bzw. weiß nicht, was ich tun kann:
configCheck done:
missing register list
EG.Flur.EingangsAWAYDisplay: RegL_00.
EG.Kuche.Licht_Sw_Esstisch: RegL_01.
EG.Kueche.Licht: RegL_00.
EG.Kueche.Licht_Sw_Arbeitsbereich: RegL_01.
HM_4656DC_Dis_01: RegL_01.
HM_4656DC_Dis_02: RegL_01.
HM_4656DC_Dis_03: RegL_01.
[...]
peer list incomplete. Use getConfig to read it.
incomplete: HM_4656DC_Dis_02:
incomplete: HM_4656DC_Dis_05:
[...]
peer not defined
HM_EG.ESSZMMR_Wandthermostat_Weather id:3B38F001
HM_OG.SCHLAFZ_Wandthermostat_Weather id:8338E511
HM_OG.WOHNZMR_DmSchlafzimmer_Dim id:280A7B01
HM_OG.WOHNZMR_DmSchlafzimmer_Dim id:280A7B02
[...]
peer not verified. Check that peer is set on both sides
HM_EG.ATELIER_SwDeckenlicht p:HM_EG.ATELIER_SwRemoteDeckenlicht_Btn_01
HM_EG.ATELIER_SwDeckenlicht p:HM_EG.ATELIER_SwRemoteDeckenlicht_Btn_02
HM_EG.ESSZMMR_HeizungMitte_Weather p:HM_EG.ESSZMMR_Wandthermostat_Weather
HM_EG.ESSZMMR_Wandthermostat_Weather p:HM_EG.ESSZMMR_HeizungLinks_chn-38
[...]
peering strange - likely not suitable
HM_EG.WINTERG_Heizung_Climate pID: Model HM-TC-IT-WM-W-EU should be HM-TC-IT-WM-W-EU Climate Channel
boost or template differ in team
HM_EG.ARBEITZ_Wandthermostat_Climate team:HM_EG.ARBEITZ_HeizungLinks_Clima tempListTmpl differ tempList.cfg:EG.Arbeitszimmer.Wandthermostat_Climate / tempList.cfg:EG.Arbeitszimmer.HeizungLinks_Clima
HM_EG.ESSZMMR_Wandthermostat_Climate team:HM_EG.ESSZMMR_HeizungLinks_Clima tempListTmpl differ tempList.cfg:EG.Esszimmer.Wandthermostat_Climate / tempList.cfg:EG.Esszimmer.HeizungLinks_Clima
[...]
peerNeedsBurst not set
HM_OG.SCHLAFZ_FensterRechts:HM_OG.SCHLAFZ_HeizungRechts_WindowRec
PairedTo missing/unknown
EG.Flur.EingangsAWAYDisplay
EG.Kueche.Licht
HM_EG.ATELIER_SwRemoteDeckenlicht
HM_EG.FLUR_NachtStrom
HM_EG.KUECHE_FBLichtArbeitSchranke
HM_OG.LENNART_FBLichtEingang
templist mismatch
HM_EG.ATELIER_Wandthermostat_Climate: failed Entries:
HM_EG.ATELIER_Wandthermostat_Climate :R_P1_0_tempListSat mismatch 08:00 16.0 20:00 20.0 24:00 16.0 ne 08:00 16.0 21:00 20.0 24:00 16.0 ##
[...]
bei einigen kann ich vermuten, was zu tun ist - getConfig, templist neu schreiben - aber was ist PairedTo missing, peering strange, peer not defined usw.?
Danke, -MN
Moin,
was zu tun ist:
- Erst mal bei allen Devices das pairing sauber abschließen (siehe wiki) (welche: PairedTo missing/unknown)
- dann sehen, dass die getConfigs sauber durchlaufen (benötigt bei Batterie-Geräten ggf. mehrere Durchläufe - anstoßen mit Auslösen bzw. Config-Taste drücken
Dabei die 1%-Regel beachten (Geduld...).
Am Ende nochmal checkConfig und dann die peerings (wieder: wiki) durchgehen, da wurde mangels pairing manches wohl nicht sauber übertragen. Das muß ggf. wiederholt werden.
Ach so: solange cmd pending sind, kann das schwierig werden, diese müssen ggf. mit "clear" beseitigt werden.
Gruß, Beta-User
Ich muss diesen Thread noch mal aufleben lassen.
Die infoHm zeigt bei configCheck eine recht umfangreiche Liste, die ich schon deutlich rduzieren konnte. Jetzt arbeite ich die umfangreichsten Bereiche der Reihe nach ab. Allerdings komme ich bei nachfolgendem Bereich nicht weiter:
Da ich alle Fehlerquellen beseitigen will, versuche ich die Fehlerliste aus HMInfo abzuarbeiten.
Problem:
boost or template differ in team
Th_Bad_Climate team:Hzg_Bad_Clima tempListTmpl differ Th_Bad_Climate / Hzg_Bad_Clima
Th_Bu_Climate team:Hzg_Bu1_Clima tempListTmpl differ Th_Bu_Climate / Hzg_Bu1_Clima
Th_Bu_Climate team:Hzg_Bu2_Clima tempListTmpl differ Th_Bu_Climate / Hzg_Bu2_Clima
Th_GzB_Climate team:Hzg_GzB_Clima tempListTmpl differ Th_GzB_Climate / Hzg_GzB_Clima
Th_GzR_Climate team:Hzg_GzR_Clima tempListTmpl differ Th_GzR_Climate / Hzg_GzR_Clima
Th_Ku_Climate team:Hzg_Ku_Clima tempListTmpl differ Th_Ku_Climate / Hzg_Ku_Clima
Th_Sz_Climate team:Hzg_Sz_Clima tempListTmpl differ Th_Sz_Climate / Hzg_Sz_Clima
Th_Wz_Ez_Climate team:Hzg_Wz1_Clima tempListTmpl differ Th_Wz_Ez_Climate / Hzg_Wz1_Clima
Th_Wz_Ez_Climate team:Hzg_Wz2_Clima tempListTmpl differ Th_Wz_Ez_Climate / Hzg_Wz2_Clima
Th_Wz_Ez_Climate team:Hzg_Wz3_Clima tempListTmpl differ Th_Wz_Ez_Climate / Hzg_Wz3_Clima
Ich habe die zentrale tempListTmpl als Wochenplan.cfg abgelegt und alle Thermostate und Ventile erfolgreich restored. das set infoHM tempList verify zeigt alles mit "passed" an
Damit die im Climateam arbeitenden Geräte auch wirklich mit den gleichen Inhalten arbeiten; habe ich sie im Template durch Komma getrennt aufgeführt:
entities:Th_Bad_Climate,Hzg_Bad_Clima
R_0_tempListSat>07:00 17.0 09:00 21.0 22:00 17.0 23:00 21.0 24:00 17.0
u.s.w.
Ich weiß nun nicht mehr wie ich diese Fhlermeldungen beseitigen kann.
Viele grüße
Eberhard
Meiner Meinung nach kannst Du keine TempListen eines Wandthermostaten in einen Heizungsregler packen, da der eine 3 und der andere nur 1 Profil kennt...
Ciao, -MN
Ich habe in der tempList (bei mir Wochenplan.cfg) die entities für Hzg_Bad_Clima und Th_Bad_Climate getrennt, mit dem Ergebnis, dass es daran nicht lag.
(einen Tag später)
Der Fehler lag in der Definition des attributes tempListTmpl. Arbeiten ein HKT und ein WT im Climateam zusammen, muss offensichtlich das attr tempListTmpl der HKT immer auf das entity des WT zeigen.
Bei mir arbeiten drei HKT mit einem WT im ClimaTeam. Also:
attr Hzg_Wz1_Clima tempListTmpl Th_Wz_Ez_Climate
attr Hzg_Wz2_Clima tempListTmpl Th_Wz_Ez_Climate
attr Hzg_Wz3_Clima tempListTmpl Th_Wz_Ez_Climate
Dabei ist es unerheblich ob HKT und WT eine TempList benutzen und nur durch Komma getrennt werden.
Andererseits bedeutet das auch, dass ich für die HKT keine eigenen Einträge in der Wochenplan.cfg benötige, wenn HKT und WT im Team arbeiten. Richtig?
Gruß
Eberhard
Die meldung sagt doch, dass der Wochenplan der device IM TEAM unterschiedlich ist. Wenn du ein team hast sollten diese immer die gleiche temperatur eingestellt bekommen. Damit sollte auch der wochenplan identisch sein.
Scheinbar ist die meldung nicht eindeutig. Oder wurde nicht gelesen.
Ich würde sagen, dass dem Inhalt der Nachricht nicht die entsprechende Bedeutung zugemessen wurde. :D
Jetzt sind alle Fehler beseitigt - also Danke an alle Beteiligten!
Gruß Eberhard
Ich habe auch noch einen Fehler, welchen ich seit der Einrichtung nicht beseitigt bekomme. Die Besonderheit könnte darin bestehen, dass die beiden bemängelten optischen Fenstersensoren jeweils mit zwei Heizungs-Thermostaten gepeert sind. Eventuell hat ja jemand eine Idee was das sein könnte:
trigger sent to unpeered device
triggerUnpeered: ku_fe:000000
triggerUnpeered: kz_fe_links:000000
und das ensprechende list von einem der betroffenen optischen Fenstersensoren:
Internals:
CFGFN cfg/11_kueche.cfg
CHANGED
DEF 5CF5C9
FUUID 5c54bff3-f33f-2f37-8c3e-c68f34e825cce707
IODev hmusb
LASTInputDev hmusb
MSGCNT 3
NAME ku_fe
NOTIFYDEV global
NR 405
NTFY_ORDER 50-ku_fe
STATE closed
TYPE CUL_HM
hmusb_MSGCNT 3
hmusb_RAWMSG E5CF5C9,0000,009654E7,FF,FFBA,3CA6105CF5C912345606010000
hmusb_RSSI -70
hmusb_TIME 2019-02-07 20:03:32
peerList ku_hz_WindowRec,fl_hz_WindowRec,
protState Info_Cleared
rssi_at_hmusb cnt:3 min:-70 max:-67 avg:-68.33 lst:-70
READINGS:
2019-02-07 17:20:05 Activity alive
2018-09-09 19:47:42 CommandAccepted yes
2018-09-09 19:48:19 D-firmware 1.0
2018-09-09 19:48:19 D-serialNr YYYxxxxxxx
2018-09-09 19:48:21 PairedTo 0x123456
2018-09-09 18:55:33 R-cyclicInfoMsg on
2018-09-09 18:55:34 R-eventDlyTime 0 s
2018-09-09 19:02:37 R-fl_hz_WindowRec-expectAES off
2018-09-09 19:02:37 R-fl_hz_WindowRec-peerNeedsBurst on
2018-09-09 19:02:37 R-ku_hz_WindowRec-expectAES off
2018-09-09 19:02:37 R-ku_hz_WindowRec-peerNeedsBurst on
2018-09-09 19:48:19 R-pairCentral 0x123456
2018-09-09 18:55:33 R-sabotageMsg on
2018-09-09 18:55:34 R-sign on
2018-09-09 19:48:21 RegL_00. 02:01 09:01 0A:34 0B:F2 0C:14 10:01 14:06 00:00
2018-09-09 19:48:21 RegL_01. 08:01 20:9C 21:00 30:06 00:00
2018-09-09 19:48:23 RegL_04.fl_hz_WindowRec 01:01 00:00
2018-09-09 19:48:22 RegL_04.ku_hz_WindowRec 01:01 00:00
2018-09-09 19:47:42 aesCommToDev ok
2018-09-09 19:47:42 aesKeyNbr 00
2019-02-07 20:03:32 alive yes
2019-02-07 20:03:32 battery ok
2019-02-07 20:03:32 contact closed (to vccu)
2019-02-07 17:20:05 peerList ku_hz_WindowRec,fl_hz_WindowRec,
2019-02-07 20:03:32 recentStateType info
2019-02-07 20:03:32 sabotageError off
2019-02-07 20:03:32 state closed
2018-09-09 18:54:39 trigDst_broadcast noConfig
2019-01-20 13:35:06 trigger_cnt 58
helper:
HM_CMDNR 60
mId 00C7
regLst ,0,1,4p
rxType 28
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +5CF5C9,00,01,00
nextSend 1549566212.84846
rxt 2
vccu vccu
p:
5CF5C9
00
01
00
prefIO:
hmusb
mRssi:
mNo 3C
io:
hmusb:
-68
-68
prt:
bErr 0
sProc 0
sleeping 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO hmusb
flg A
ts 1549566212.7857
ack:
HASH(0x3a3a120)
3C80021234565CF5C900
rssi:
at_hmusb:
avg -68.3333333333333
cnt 3
lst -70
max -67
min -70
shadowReg:
tmpl:
Attributes:
DbLogInclude state
IODev hmusb
IOgrp vccu:hmusb
actCycle 001:05
actStatus alive
autoReadReg 4_reqStatus
devStateIcon open:fts_window_1w_open@red closed:fts_window_1w_open@lightgreen
event-on-change-reading state,battery,sabotageError
expert 2_raw
firmware 1.0
group Schalter
icon fts_window_1w
model HM-SEC-SCo
peerIDs 00000000,AAAAAA03,BBBBBB03,
room Küche
serialNr YYYxxxxxxx
subType threeStateSensor
Vorab: ich sehe keine triggerTo readings. Hast du diese gelöscht? Der kanal ist gepeert und sollte an die peers senden, nicht an broadcast.
Das reading triggertobroadcast ist uralt. ich denke es wird bei cleartrigger nicht gelöscht.
=> Lösche das reading.
=> Das problem sollte behoben sein. Auch nach einen neuen trigger ( bitte testen)
=> Das mit cleartrigger ist dann ein bug. Werde ich untersuchen
Danke martinp876.
Das löschen dieses Readings behebt diese Meldung und der configCheck ist leer! Bischen peinlich das ich diesen kleinen Unterschied zwischen den Sensoren nicht bemerkt habe!
Besten Dank
Sollte der Fehler nicht im Löschen der entsprechenden "cleartrigger"Methode zu finden sein hier noch einmal eine weitere Erläuterung:
Ich hatte soeben gesehen, dass ich am 16.12.2017 die Fenster eingerichtet hatte. Mit Gewissheit kann ich auch sagen, dass ich kz_fe_links(betroffen von dem Problem) und kz_fe_rechts(nicht betroffen) am selben Tag eingerichtet hatte. Leider kann ich die Softwareversion zum dortigen Zeitpunkt nicht mehr ausfindig machen.
Die Version zur Einrichtung des Sensor fe_ku(betroffen von dem Problem) kann ich noch einschränken weil dieser später eingerichtet wurde und war >= 10_CUL_HM.pm 16940 2018-07-03
98_HMinfo.pm 17467 2018-10-06
Die Befehle welche ich eingegeben habe in genau dieser Reihenfolge waren mit hoher Wahrscheinlichkeit:
set vccu hmPairForSec 10
rename etc.
set fe_sensor assignHmKey
attr fe_sensor event-on-change-reading state,battery,sabotageError
attr fe_sensor actCycle 001:05
set fe_sensor peerChan 0 Heizkörperthermostat_WindowRec single set
set fe_sensor regSet peerNeedsBurst on Heizkörperthermostat_WindowRec
Eventuell helfen die Informationen weiter.
Kein Problem. Der trigger geht an broadcast wenn nicht gepeert ist. Also vor einrichten