habe heute auf configDB migriert, seitdem wird auf meine HM-TC-IT-WM-W-EU im 5-Minutentank ein getConfig gefeuert bis die HMLAN's im Overload sind:
2015.07.10 17:16:41.736 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:15:51.593 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:15:01.273 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 17:12:31.976 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 17:11:52.790 1: HMLAN_Parse: HMLAN2 new condition ERROR-Overload
2015.07.10 17:11:41.829 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:10:51.685 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:10:08.610 1: HMLAN_Parse: HMLAN2 new condition Warning-HighLoad
2015.07.10 17:10:01.534 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 17:07:32.206 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 17:06:42.060 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:05:51.917 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:05:01.769 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 17:02:32.489 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 17:01:42.346 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 17:00:52.202 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 17:00:02.054 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:57:31.765 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:56:41.622 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:55:51.469 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:55:01.325 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:52:32.040 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:51:41.899 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:50:51.759 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:50:01.605 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:47:32.321 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:46:42.180 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:45:52.040 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:45:01.895 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:42:32.566 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:41:42.416 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:40:52.275 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:40:02.111 3: CUL_HM set og_sz_wandthermostat getConfig
2015.07.10 16:37:31.730 3: CUL_HM set dg_wz_wandthermostat getConfig
2015.07.10 16:36:41.595 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.10 16:35:51.453 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.10 16:35:01.309 3: CUL_HM set og_sz_wandthermostat getConfig
protoEvents gibt eine queue length von 0 aus, auch keine CMDs pending.
Habe schon autoReadReg bei allen Devices auf 0 gesetzt, wird allerdings nicht besser.
Kann einer helfen oder hat eine Idee?
Außer der migration auf configDB hat sich eigentlich nichts an der config geändert...
ConfigDb nutze ich nicht. Was sendet das ? Welche trigger und kommandos loest es aus ?
das erschreckende - nichts/garkeine...
die configDB ersetzt nur die fhem.cfg, es wird also lediglich beim Start aus der DB statt aus dem Config-File gelesen.
Während des Fhem Betriebs ist das Modul nicht weiter tätig (bis ein Save oder rereadcfg ausgeführt wird).
Der einzige evtl. gravierende Unterschied könnte sein, dass ich zuvor die Devices geordnet in verschiedenen Konfig-Files included hatte, jetzt übernimmt die configDB die Reihenfolge und die könnte jetzt eine andere sein als zuvor?
Allerdings alle anderen definitions und Geräte funktionieren wie gehabt, nur die Wandthermostate musste ich seitdem auf 'ignore' setzen.
Das komische ist ja wirklich dass es genau im 5 Minuten takt passiert:
2015.07.11 07:55:51.322 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.11 08:00:52.013 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.11 08:05:51.735 3: CUL_HM set og_ez_wandthermostat getConfig
2015.07.11 08:10:51.462 3: CUL_HM set og_ez_wandthermostat getConfig
Irgen ein anderesEvent wird zu dieser Zeit nicht getriggert:
2015-07-11 08:09:44.134 HMLAN HMLAN3 loadLvl: low
2015-07-11 08:09:55.472 PRESENCE TV_Esszimmer present
2015-07-11 08:09:55.472 PRESENCE TV_Esszimmer presence: present
2015-07-11 08:10:00.825 CUL_HM og_ez_wandthermostat_Climate humidity: 38
2015-07-11 08:10:09.133 HMLAN HMLAN3 loadLvl: low
2015-07-11 08:10:25.521 PRESENCE TV_Esszimmer present
2015-07-11 08:10:25.521 PRESENCE TV_Esszimmer presence: present
2015-07-11 08:10:34.135 HMLAN HMLAN3 loadLvl: low
2015-07-11 08:10:34.767 ROOMMATE rr_Claudiu durTimerAbsence_cr: 73456
2015-07-11 08:10:34.767 ROOMMATE rr_Claudiu durTimerAbsence: 1224:16:14
2015-07-11 08:10:51.461 CUL_HM og_ez_wandthermostat CMDs_pending
Ein at oder ähnliches ist hier auch nicht aktiv...
das 1. getConfig wird ziemlich zeitnah nach dem Fhem-Start ausgeführt (dauert keine 5 Min), ebenso wenn ich das 'ignore' Attr vom device entferne.
Kann ich irgendwas kontrollieren, oder irgendwelche Infos liefern, um dem auf die Spur zu kommen?
ZitatDer einzige evtl. gravierende Unterschied könnte sein, dass ich zuvor die Devices geordnet in verschiedenen Konfig-Files included hatte, jetzt übernimmt die configDB die Reihenfolge und die könnte jetzt eine andere sein als zuvor?
wenn das die ursache ist, müsste doch delete <device> und ein erneutes definieren/anlernen (am besten über autocreate) das drama beenden. zum testen erst mal eins. ;)
vorher kannst du das register setting und das peering sichern (saveConfig).
Die 5min sind, meine ich, der automatischen abfrage geschulder. Die macht so etwas.
Es sollten aber die messages gesendet werden. Die abfrage autoreadreg stellt fest, dass daten fehlen und versucht diese zu holen. Eine pruefung dass nicht gesendet wurde isr nicht drin da davon ausgegangen wird, dass nach5min das vorige erledigt ist - erfolgreich oder nicht.
Das problem waere also, dass nicht gesendet wird. Kannst du dies klaeren oder ein list schicken ?
@frank: ein delete und neu definieren war mit eins was ich als erstes ausprobiert hatte, neu angelernt habe ich nicht - ob dies einen unterschied zu einem 'clear all; getconfig' macht?
@martin:
Habe versucht es zu klären, bin aber etwas unsicher ;-)
Hier erstmal das 'list og_ez_wandthermostat':
Internals:
.triggerUsed 1
CFGFN
DEF 31FE90
HMLAN1_MSGCNT 924
HMLAN1_RAWMSG E31FE90,0000,0497A5C2,FF,FFA2,D8865A31FE90000000310B26
HMLAN1_RSSI -94
HMLAN1_TIME 2015-07-11 13:52:02
HMLAN2_MSGCNT 944
HMLAN2_RAWMSG E31FE90,0000,046A257F,FF,FFC0,0B801031FE903765140300
HMLAN2_RSSI -64
HMLAN2_TIME 2015-07-11 13:51:10
HMLAN3_MSGCNT 143
HMLAN3_RAWMSG E31FE90,0000,3EF81408,FF,FF98,D7847031FE90000000010B26
HMLAN3_RSSI -104
HMLAN3_TIME 2015-07-11 13:49:30
IODev HMLAN2
LASTInputDev HMLAN1
MSGCNT 2011
NAME og_ez_wandthermostat
NR 222
NTFY_ORDER 50-og_ez_wandthermostat
STATE CMDs_done
TYPE CUL_HM
channel_01 og_ez_wandthermostat_Weather
channel_02 og_ez_wandthermostat_Climate
channel_03 og_ez_wandthermostat_WindowRec
channel_06 og_ez_wandthermostat_remote
channel_07 og_ez_wandthermostat_SwitchTr
lastMsg No:D8 - t:5A s:31FE90 d:000000 310B26
protCmdDel 14
protLastRcv 2015-07-11 13:52:02
protResnd 2 last_at:2015-07-11 13:51:05
protResndFail 2 last_at:2015-07-11 13:51:09
protSnd 194 last_at:2015-07-11 13:51:10
protState CMDs_done
rssi_at_HMLAN1 avg:-93.65 lst:-94 cnt:200 min:-99 max:-87
rssi_at_HMLAN2 max:-64 cnt:216 min:-64 lst:-64 avg:-64
rssi_at_HMLAN3 max:-102 cnt:6 min:-105 lst:-104 avg:-103.83
CHANGETIME:
Helper:
Dblog:
Activity:
Dblog:
TIME 1436615360.89594
VALUE alive
R-btnlock:
Dblog:
TIME 1436615086.90964
VALUE off
R-burstrx:
Dblog:
TIME 1436615086.90964
VALUE on
R-cyclicinfomsg:
Dblog:
TIME 1436615086.90964
VALUE on
R-cyclicinfomsgdis:
Dblog:
TIME 1436615086.90964
VALUE 0
R-globalbtnlock:
Dblog:
TIME 1436615086.90964
VALUE off
R-localresdis:
Dblog:
TIME 1436615086.90964
VALUE off
R-lowbatlimitrt:
Dblog:
TIME 1436615086.90964
VALUE 2.2 V
R-modusbtnlock:
Dblog:
TIME 1436615086.90964
VALUE off
R-paircentral:
Dblog:
TIME 1436615086.90964
VALUE 0x376514
Batterylevel:
Dblog:
TIME 1436615238.52211
VALUE 2.7
Desired-temp:
Dblog:
TIME 1436615238.52211
VALUE 6.0
Measured-temp:
Dblog:
TIME 1436615238.52211
VALUE 26.7
State:
Dblog:
TIME 1436615469.39064
VALUE CMDs_done
Readings:
2015-07-11 13:52:02 .protLastRcv 2015-07-11 13:52:02
2015-07-11 13:49:20 Activity alive
2015-07-11 13:50:52 CommandAccepted yes
2015-07-11 13:50:52 PairedTo 0x376514
2015-07-11 13:44:46 R-btnLock off
2015-07-11 13:44:46 R-burstRx on
2015-07-11 13:44:46 R-cyclicInfoMsg on
2015-07-11 13:44:46 R-cyclicInfoMsgDis 0
2015-07-11 13:44:46 R-globalBtnLock off
2015-07-11 13:44:46 R-localResDis off
2015-07-11 13:44:46 R-lowBatLimitRT 2.2 V
2015-07-11 13:44:46 R-modusBtnLock off
2015-07-11 13:44:46 R-pairCentral 0x376514
2015-07-11 13:50:52 RegL_00: 01:01 02:01 09:01 0A:37 0B:65 0C:14 0F:00 11:00 12:16 16:00 18:00 19:00 1A:00 00:00
2015-07-11 13:47:18 batteryLevel 2.7
2015-07-11 13:47:18 desired-temp 6.0
2015-07-11 13:47:18 measured-temp 26.7
2015-07-11 13:51:10 state CMDs_done
Regl_07::
VAL
Helper:
HM_CMDNR 216
cSnd 0137651431FE9002040000000008,0137651431FE9002040000000009
mId 00AD
rxType 6
Io:
newChn +31FE90,00,01,00
nextSend 1436615522.6115
rxt 0
vccu vccu
p:
31FE90
00
01
00
prefIO:
HMLAN2
Mrssi:
mNo D8
Io:
HMLAN1 -94
HMLAN2 -62
Prt:
awake 0
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat
Role:
dev 1
Rssi:
At_hmlan1:
avg -93.65
cnt 200
lst -94
max -87
min -99
At_hmlan2:
avg -64
cnt 216
lst -64
max -64
min -64
At_hmlan3:
avg -103.833333333333
cnt 6
lst -104
max -102
min -105
Shregw:
07 02
Shadowreg:
Attributes:
IODev HMLAN2
IOgrp vccu:HMLAN2
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
event-on-change-reading .*
expert 2_full
firmware 1.1
group WAND-THERMOSTATE
ignore 0
model HM-TC-IT-WM-W-EU
msgRepeat 1
room Devices
serialNr LEQ0998921
subType thermostat
webCmd getConfig:clear msgEvents
Was ich probiert habe (siehe anhängendes Logfile, achtung reverseLog):
- habe das 'ignore' attr am devices og_ez_wandthermostat deleted
- habe auf allen 3 HMLAN's 'logIDs sys,og_ez_wandthermostat' gesetzt und global verbose 1
- habe ein notify erstellt welchen zusätzlich alle Events des Devices logt
- Habe um 13:44:30 ein 'set og_ez_wandthermostat clear all' gemacht
- Habe um 13:44:45 manuell ein 'getConfig' angestoßen
- Um 13:45:03 hat mein notify: 'CMDs_done' geloggt, einen Fehler konnte ich nicht erkennen.
- Um 13:45:51 ist das 1. mal automatisch das getConfig wieder angesprungen
- Um 13:46:10 hat mein noitfy: 'CMDs_done_Errors:1' gemeldet, heute vormittag ist mir das ohne das ntfy noch nicht aufgefallen...
- Um 13:50:51 ist das 2. mal automatisch das getConfig angesprungen
- Um 13:51:09 hat mein notify wieder 'CMDs_done_Errors:1' gemeldet, ist hier ein Muster zu erkennen?
- Habe ein list erstellt und dieses Beitrag geschrieben ;D
Hoffe du kannst aus dem Logfile was erkennen, viel sonstiger Müll sollte nicht drin sein, sind allerdings trotzdem einige Zeilen geworden...
Danke schonmal :-)
Edit:
- in dem list ist autoreadreg 4 drin, habe aber auch schon mit 0, und reboot, redefine usw. rumgetestet, hat aber nicht geholfen.
Habe heute nochmal probiert, heute laufen die getConfigs allerdings ohne Errors druch, die wiederholung von 5 Min bleibt aber:
2015.07.13 17:46:42.395 1: ntfy_test_WT:CMDs_pending
2015.07.13 17:46:42.398 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.13 17:46:59.978 1: ntfy_test_WT:CMDs_done
2015.07.13 17:51:42.069 1: ntfy_test_WT:CMDs_pending
2015.07.13 17:51:42.072 3: CUL_HM set og_bz_wandthermostat getConfig
2015.07.13 17:51:59.856 1: ntfy_test_WT:CMDs_done
Gibt es noch irgendwas was ich tun/versuchen kann?
so wie es aussieht, bist du wohl der einzige mit diesem problem. ansonsten hätten schon mehrere über overload berichtet. demnach kann es eigentlich nicht an cul_hm liegen.
nochmal zu delete. du hast alle channel und das device mit delete <device> gelöscht? dann save gemacht? danach am besten shutdown restart. dann musst du wohl nur das device in den anlernmodus bringen und getconfig manuell starten.
oder versuche das in der db vorhandene device (plus alle channel) über edit DEF eine willkürliche hmid=111111 zu geben und auf ignore setzen. dann das reale device neu definieren. vielleicht kann man so die db überlisten. denn wer weiss, ob sie nach delete wirklich alles entfernt.
zu hminfo configcheck hast du dich nicht geäussert. was wird da berichtet?
zu deinem list vom device. ich habe auch kein dblog, deswegen ein paar "dumme" fragen:
sollten unter helper->dblog eigentlich alle readings auftauchen? wenn du mit den readings vergleichst, fehlen einige. besonders auffällig: pairedTo und RegL_00. wie sieht das bei deinen anderen, funktionierenden devices aus?
dann, im reading von RegL_00: gibt es zwischen "11:00" und "12:00" 2 leerzeichen. seltsam.
unter dem reading state gibt es eine zeile mit "Regl_07::". müsste hier das reading der liste erscheinen? ich habe auch kein tc-it. ;)
ansonsten macht das verhalten ja den eindruck, dass cul_hm irgend etwas vermisst. das getconfig wird mit cmds_done erfolgreich vermeldet, aber die daten gehen wohl verloren. machst du nach einem erfolgreichen getconfig auch save? danach vielleicht mal einen restart.
anstatt auf ignore zu setzen, würde ich vielleicht attr dummy probieren, dann kannst du eventuell die devices noch ein wenig nutzen/beobachten ohne overload gefahr.
zum schluss könntest du noch versuchen die vccu für dieses device zu canceln. also attr IOgrp löschen. dann sollte attr IODev wirken.
gruss frank
Hi Frank,
danke erstmal für deine Tipps!
Zitat von: frank am 13 Juli 2015, 19:24:30
zu hminfo configcheck hast du dich nicht geäussert. was wird da berichtet?
ConfigCheck läuft sauber durch.
Zitat von: frank am 13 Juli 2015, 19:24:30
zu deinem list vom device. ich habe auch kein dblog, deswegen ein paar "dumme" fragen:
sollten unter helper->dblog eigentlich alle readings auftauchen? wenn du mit den readings vergleichst, fehlen einige. besonders auffällig: pairedTo und RegL_00. wie sieht das bei deinen anderen, funktionierenden devices aus?
dann, im reading von RegL_00: gibt es zwischen "11:00" und "12:00" 2 leerzeichen. seltsam.
unter dem reading state gibt es eine zeile mit "Regl_07::". müsste hier das reading der liste erscheinen? ich habe auch kein tc-it. ;)
Das mit DbLog ist eine gute Frage, das Problem mit den TC-IT's trat allerdings schon vor der Nutzung von DbLog auf, also dürfte es damit nichts zutun haben.
Das Regl_07 leer ist, ist mir auch schon aufgefallen, das scheint glaube ich allerdings normal zu sein?
Zitat von: frank am 13 Juli 2015, 19:24:30
ansonsten macht das verhalten ja den eindruck, dass cul_hm irgend etwas vermisst. das getconfig wird mit cmds_done erfolgreich vermeldet, aber die daten gehen wohl verloren. machst du nach einem erfolgreichen getconfig auch save? danach vielleicht mal einen restart.
Save ganz klar, das ist in Fleisch und Blut übergegangen nach einer Konfigänderung :-)
Restarts nach jedem einzelnen Schritt hatte ich auch probiert.
Zitat von: frank am 13 Juli 2015, 19:24:30
anstatt auf ignore zu setzen, würde ich vielleicht attr dummy probieren, dann kannst du eventuell die devices noch ein wenig nutzen/beobachten ohne overload gefahr.
Danke für den Tipp!
JETZT ABER MAL ZUM FAZIT:Zitat von: frank am 13 Juli 2015, 19:24:30
nochmal zu delete. du hast alle channel und das device mit delete <device> gelöscht? dann save gemacht? danach am besten shutdown restart. dann musst du wohl nur das device in den anlernmodus bringen und getconfig manuell starten.
zum schluss könntest du noch versuchen die vccu für dieses device zu canceln. also attr IOgrp löschen. dann sollte attr IODev wirken.
Habe ich grad nochmal genau nach deinem beschriebenen Vorgehen gemacht.
Nachdem das Gerät von autocreate mit dem
default Namen und
ohne Attr IOgrp angelegt wurde,
scheint es jetzt wieder zu funktionieren, kein getConfig nach dem fhem-start, kein sich wiederholendes getConfig, manuelles getConfig allerdings problemlos.
Als ich das delete das erste mal probierte, habe ich es nach einem restart manuell wieder angelegt, und dies nicht von autocreate erledigen lassen, dadurch habe ich auch alle Attribute wieder mitgenommen.
Werde jetzt erstmal das Device wieder richtig renamen, meine Attribute sowie vccu setzen, und beobachten ob sich das Verhalten nach irgend einer dieser Konfig-Änderungen wiederholt oder ein Unterschied zwischen dem neuen & alten list erkennbar ist.
Gebe anschließend nochmals bescheid.
Bis dahin schonmal vielen Dank an Dich und Martin :-)
Gruß
Hallo Zusammen,
so, Problem erkannt, Problem gebannt?
Das komische getConfig-Verhalten wird durch den Device u./o. Channel-Namen hervorgerufen.
Folgende Namen lösen ein sich wiederholendes getConfig aus:
device dg_wz_wandthermostat
channel_01 dg_wz_wandthermostat_Weather
channel_02 dg_wz_wandthermostat_Climate
channel_03 dg_wz_wandthermostat_WindowRec
channel_06 dg_wz_wandthermostat_remote
channel_07 dg_wz_wandthermostat_SwitchTr
Mit diesen Namen ist nun kein Problem mehr vorhanden:
device dg_wz_wt
channel_01 dg_wz_wt_Weather
channel_02 dg_wz_wt_Climate
channel_03 dg_wz_wt_WindowRec
channel_06 dg_wz_wt_remote
channel_07 dg_wz_wt_SwitchTr
Jetzt ist natürlich die Frage warum das ganze so ist, und wo hier nach einem Fehler gesucht werden muss...
Den Fehler kann ich jetzt natürlich für mich erstmal durch Anpassung der Namen umgehen.
Danke und Gruß
Claudiu
jaaaaa, da war doch etwas wegen zu langer Namen , glaube länger als 32 Zeichen? ,
ich sag weiter nichts dazu :)
Ja diese standardmäßige Begrenzung beim anlegen von configDB und DbLog auf 32 Zeichen ist einfach nur Katastrophal, keine Ahnung wie man sich darauf versteifen konnte.
Allerdings denke ich wird dies hier nicht das Problem sein, weil:
1. der längste Bezeichner ist hier 'dg_wz_wandthermostat_WindowRec" mit 31 Zeichen
2. Habe ich meine SQL-Table manuell angelegt ohne jegliche Begrenzungen
3. Würde die verwendete SQLite DB so oder so keine Begrenzung kennen,
4. (Hat hier zwar nichts damit zutun) Habe die Angabe welche DbLog für das substr() verwendet ebenfalls erhöht.
5. Andere HM-devices (auch mit noch längerem Namen, z.B. 'og_schlieserschnittstelle_haustuer' mit 35 Zeichen) funktionieren???
die namen, die nicht funktionieren, sind doch von anfang an die selben. oder nicht? vielleicht gibt es so etwas wie einen cache und es wird immer die alte version benutzt. wenn du auch configdb nutzt, da gibt es doch eine versions historie.
gruss frank
ja, Versionierung der Konfig gibts, nur von einem Cache wüsste ich nichts.
Habe zwar 100 Versionen bei mir konfiguriert, es ist(sollte) zumindest ja immer nur Version 0 der Konfig aktiv sein.
Auf jedenfall verdammt komischer Fehler, hätte nicht erwartet dass es am Namen liegt...
Gruß Claudiu