Hallo zusammen,
ich wollte heute meine HM-TC-IT-WM-W-EU mit den Wochenprofilen über die tempList.cfg versorgen.
Versorgt werden sollen 6 Wandthermostate mit 2 Temperaturlisten
Beispiel für ein Thermostat
entities:Hz.Thermostat_DG_Studio_Climate
R_P1_0_tempListSat> 11:00 15.0 22:30 20.0 24:00 15.0
R_P1_1_tempListSun> 11:00 15.0 22:30 20.0 24:00 15.0
R_P1_2_tempListMon> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_3_tempListTue> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_4_tempListWed> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_5_tempListThu> 19:30 15.0 22:30 20.0 24:00 15.0
R_P1_6_tempListFri> 15:00 15.0 22:30 20.0 24:00 15.0
R_P2_0_tempListSat> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_1_tempListSun> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_2_tempListMon> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_3_tempListTue> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_4_tempListWed> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_5_tempListThu> 11:00 15.0 23:00 20.0 24:00 15.0
R_P2_6_tempListFri> 11:00 15.0 23:00 20.0 24:00 15.0
Ein vorheriges verify sagt mir auch, dass die Config zur derzeitigen mehrere mismatches aufweist.
Wenn ich nun ein "set hm tempList restore" mache sehe ich dass die Thermostate zuerst auf CMDs Pending gehen und danach geht nichts mehr.
Im TOP sehe ich dann dass die CPU auf 100% Last geht, dann hilft nur noch der Reboot des Systems.
Was kann ich tun ?
Update wurde vorhin durchgeführt um auszuschliessen, dass ich eine alte Version einsetze.
Gruß
Bodo
hm - hatte ich noch nie.
die CPU oder das OS sollte das können.
was sagt TOP? Vermutlich nur FHEM? oder zeigt es ein IO device?
was macht apptime?
Top sagt dass Fhem alles von einem CPU Core des Cubietrucks verbraucht.
Apptime suche ich später mal raus.
Wenn ich die Templisten versuche über Funktionen aus meiner MyUtils zu setzen kann ich auch nur ein Thermostat auf einmal machen, sonst rauscht mir der HMLAN sofort in den Overload.
Wenn ich die 6 Thermostate über den Zeitraum von 30 Minuten mache geht es....
Ich denke daher nicht, dass das Problem beim tempList restore sondern eher am HMLAN liegt.
Im vergangenen Winter habe ich die RT's direkt über FHEM betankt (über die MyUtils), da gab es kein Problem bei 9 RTs gleichzeitig.
Gruß
Bodo
Das Problem mit der CPULoad hat sich erledigt ich habe keine Ahnung warum....
Allerdings kann ich die Listen nicht setzen, da mir der HMLAN immer in den Overload rennt.
Die Listen scheinen bei manchen Devices anzukommen allerdings stehen diese dann auf "set" und nicht auf "verified".
Ich werde nun erstmal suchen wo der richtige Ansatzpunkt ist.
Du solltest darauf achten burst nicht im attribut gesetzt zu haben. Schau dir das device dazu an.
Ggf. Schicke rohmessages.
Falls burst genutzt wird belastet das sehr. I h empfehle, burst nur manuell zu senden, wenn notwendig
,
Hallo Martin,
ich gehe davon aus, dass du das Register "burstRx" meinst oder ?
Readings:
2014-10-28 10:09:30 Activity alive
2014-10-27 23:04:20 CommandAccepted yes
2014-08-17 21:23:00 D-firmware 1.1
2014-08-17 21:23:00 D-serialNr LEQ0418064
2014-10-25 20:27:47 PairedTo 0x25756B
2014-10-25 20:27:47 R-btnLock off
2014-10-25 20:27:47 R-burstRx on
2014-10-25 20:27:47 R-cyclicInfoMsg on
2014-10-25 20:27:47 R-cyclicInfoMsgDis 0
2014-10-25 20:27:47 R-globalBtnLock off
2014-10-25 20:27:47 R-localResDis off
2014-08-17 21:23:08 R-lowBatLimitRT 2.2 V
2014-10-25 20:27:47 R-modusBtnLock off
2014-10-25 20:27:47 R-pairCentral 0x25756B
2014-10-25 20:27:47 RegL_00: 01:01 02:01 09:01 0A:25 0B:75 0C:6B 0F:00 11:00 12:16 16:00 18:00 19:00 1A:00 00:00
2014-10-28 20:24:48 batteryLevel 2.8
2014-10-28 20:24:48 desired-temp 22.0
2014-10-28 20:24:48 measured-temp 21.0
2014-10-28 19:09:17 state CMDs_done
2014-10-28 19:09:17 time-request -
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 0_off
expert 2_full
firmware 1.1
model HM-TC-IT-WM-W-EU
msgRepeat 1
room CUL_HM
serialNr LEQ0418064
subType thermostat
webCmd getConfig:clear msgEvents
Dann würde ich das mal bei allen rausnehmen.
Bei den RTs kann ich es ja eigentlich drinlassen, da ich an denen eigentlich nichts einstelle.
Hier habe ich die Climate und Weather Channels entpsrechend mit denen des TC-ITs gepeert.
Gruß
Bodo
das register schaltet "aufwachen bei burst" am Device ein. Es ermöglicht das device zu wecken, wann man will. Mehr: Bei einem burst (egal von wem) wachen alle burst-sensitive devices auf und verbrauchen Batterie.
das Register würde ich immer einschalten, weil mir die Batterie hier "egal" ist.
Der Zentrale kostet dies erst einmal keine performance auf der Funkstrecke
Nun kann die Zentrale Kommandos per burst senden - das kostet dann schon. Insbesondere wenn der Empfänger nicht antwortet und der burst wiederholt wird.
Mit attr burstAccess kannst du einschalten, dass alle Kommandos sofort durch burst gesendet werden. Das solltest du ausschalten, das kostst ggf wirklich viel
mit kommando burstXmit kannst du das versenden wartender Kommandos sofort starten. das macht sinn - sollte aber nur gezielt eingesetzt werden.
schau einmal nach dem Attribut.
Hallo Martin,
Burst habe ich nun auf "0_off" gestellt bei allen.
Zum Test habe ich vorhin bei allen meinen RT-DN die Templisten mit einer Dummy Liste überschrieben (15.0 Grad den ganzen Tag).
Das hat soweit beim restore auch Funktioniert.
Wenn ich nun versuche die Listen für die TC-IT zu setzen verabschiedet sich der HMLAN quasi sofort.
Nachdem Fhem nicht mehr reagiert (100%) anbei ein tail des Fhem Logs.
2014.11.03 21:52:52 1: HMLAN_Parse: HMLAN1 new condition init
2014.11.03 21:53:06 1: HMLAN_Parse: HMLAN1 new condition ok
2014.11.03 21:53:58 1: 192.168.200.7:1000 disconnected, waiting to reappear (HMLAN1)
2014.11.03 21:53:58 1: HMLAN_Parse: HMLAN1 new condition disconnected
2014.11.03 21:53:58 1: 192.168.200.7:1000 reappeared (HMLAN1)
2014.11.03 21:53:58 1: HMLAN_Parse: HMLAN1 new condition init
2014.11.03 21:57:30 1: FBDECT: unknown message type 00
2014.11.03 21:57:30 1: FBDECT: unknown message type 00
2014.11.03 21:57:30 1: FBAHA: resetting buffer as we are out of sync (0)
2014.11.03 22:02:24 1: FBAHA: resetting buffer as we are out of sync (0)
2014.11.03 22:12:11 1: HMLAN_Parse: HMLAN1 new condition ok
2014.11.03 22:12:11 1: FBAHA: resetting buffer as we are out of sync (0)
Was kann ich noch tun ? Es wäre ja kein Problem wenn die Listen nur langsam gesetzt werden...
Gruß
Bodo
ist das wirklich das log der rohmessages?
es kommt ein init ohne dass etwas anderes vorher gekommen ist?
kannst du das verifizieren?
Loglevel ist einfach das normale FHEM Log mit Verbose 3.
Rawmessages suche ich mal wie ich die anfertigen kann. Ein einfaches global verbose 5, bringt hier zuviel von den anderen sachen mit rein....
Edit: Anleitung gefunden... Rawmessages mache ich später noch und hänge sie an.
Schau in wiki hm sniffen
Hallo Martin,
ich habe heute ein tempList restore angestossen und die Messages aufgezeichnet.
Auffällig sind die vielen Delay Meldungen.
Die Deives dahinter sind die Wandthermostate
2B317D Hz.Thermostat_OG_Gaestezimmer
2B3180 Hz.Thermostat_EG_Wohnzimmer
2B3156 Hz.Thermostat_OG_Bad
286A2B Hz.Thermostat_DG_Studio
286CD3 Hz.Thermostat_UG_Keller_Flur
2B317B Hz.Thermostat_OG_Schlafzimmer
286CDB Hz.Thermostat_EG_Flur
286C99 Hz.Thermostat_UG_Keller_2
2B3195 Hz.Thermostat_UG_Keller_1
Irgendwas scheine ich bei der Einrichtung gehörig verbockt zu haben ....
Gruß
Bodo
stelle am HMLAN
attr xxx hmLanQlen 1_min
ein - passeirt es immer noch?
War bereits so gesetzt.
Entweder ist es der Default Wert beim Define oder ich hatte damals anhand eines Wiki/Forum Artikels es gleich so gemacht.
Was mir noch eingefallen ist, über das Jahr sind ein paar HM Devices dazu gekommen.
Könnte hier die allgemeine Menge ein Problem sein ?
Derzeit sind im Einsatz:
2x Außentemp Sensoren
11x RT-DN
9x TC-IT
4x HM-ES-PMSw1-Pl
4x Fensterkontakte (1x SC2, 3x SCO)
1x Feuchtigkeitsmelder
1x HM-SCI-3-FM
Verteilt über 4 Etagen mit einem HMLAN
Gruß
Bodo
Hallo, an der Anzahl der devices liegt es mit Sicherheit nicht. Ich habe auf meiner Hauptinstanz 143 devices laufen und über 2 F2F sind noch zwei fhem Instanzen mit der Hauptinstanz verbunden, dass läuft völlig problemlos.
VG
Frank
Hallo Frank,
danke.. wollte es nur ausschliessen.
Sind ja auch nur die HM Devices, den rest habe ich nicht aufgezählt.... aber 143 sind es nicht :D
Hallo, funktioniert das Ganze wenn du das über die "althergebrachte" myUtils mit prep und dann exec machst? Ich schreibe mit dieser Methode öfters (Ferien, WE, Arbeitstag u.a.) die Temperaturlisten für 9 RT´s neu, ohne Probleme. Die Listen werden übertragen und nach kurzer Zeit zeigen alle RT´s cmd done.
VG
Frank
Du hast in deinen Rohmessages jede Menge "no Ack". Aber die Rohmessages zu interpretieren ist Martins Kenntnissbereich, da blicke ich nicht so ganz durch ;)
Auf jeden Fall bekommt fhem keine Antwort von deinen RT´s.
VG
Frank
da läuft schon etwas schief. Es schaukelt sich auf
zuerst einmal wird nach Burst für 286A2B das Senden der Messages zu spät gestartet (so etwa 300ms fehlen).
Grund... hm .. könnte das lesen des tempfiles sein (geraten). Kann ich einmal untersuchen.
Danach kollabiert es. Die Antworten kommen nicht mehr ...
was aber vermeidbar ist, sind die vielen Bursts. Die würde ich nicht starten.
Schalte in den Devices einmal überall attr burstAccess ab - das erzeugt sehr viel (zu viel) Last.
Dann dauert das Setzen der Listen eben 4min (bis jeder RT einmal aufgewacht ist).
Der generelle Ablauf ist dennoch interessant - werde einmal suchen.
Werde ich bei den RT's deaktivieren (oder diese einfach aus dem tempList file entfernen - sollen ja über den TC gesteuert werden).
Was mich allerdings wundert, dass an den 286A2B ein Burst gesendet wird. Das Device ist ein TC-IT und hat als Attribut am Device "burstAccess 0_off", oder muss ich den burstAccess im Climate Channel statt am Device auf off setzen ?
beim TC-IT braucht man burst. der macht kein wakeup und man kann es daher nicht abschalten.