Hallo zusammen,
Ich habe seit Kurzem Homematic Wandthermostaten (HM-TC-IT-WM-W-EU) und Radiatorköpfe (HM-CC-RT-DN). Alle sind mit FHEM gekoppelt, und einige Radiatorköpfe sind mit Thermostaten gepeered (einige stehen auch für sich selber). Nun möchte ich gemäss https://wiki.fhem.de/wiki/HomeMatic_HMInfo_TempList/Weekplan Wochenpläne erstellen... irgendwie schnalle ich das Prinzip aber nicht. Ich habe auch versucht zu googeln und im Forum zu suchen, aber erfolglos.
Ich habe zuerst mit attr hm configDir setup, attr hm configTempFile original.cfg, set hm tempList save ein Original aller Standardlisten erstellt. Wenn ich da reinschaue, fällt mir zuerst einmal auf, dass die Thermostaten mehrere Listen zu haben scheinen:
entities:WZ_Thermostat_Climate
R_P1_0_tempListSat>06:00 17.0 22:00 21.0 24:00 17.0
R_P1_1_tempListSun>06:00 17.0 22:00 21.0 24:00 17.0
R_P1_2_tempListMon>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_3_tempListTue>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_4_tempListWed>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_5_tempListThu>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P1_6_tempListFri>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_P2_0_tempListSat>24:00 17.0
R_P2_1_tempListSun>24:00 17.0
R_P2_2_tempListMon>24:00 17.0
R_P2_3_tempListTue>24:00 17.0
R_P2_4_tempListWed>24:00 17.0
R_P2_5_tempListThu>24:00 17.0
R_P2_6_tempListFri>24:00 17.0
R_P3_0_tempListSat>24:00 17.0
R_P3_1_tempListSun>24:00 17.0
R_P3_2_tempListMon>24:00 17.0
R_P3_3_tempListTue>24:00 17.0
R_P3_4_tempListWed>24:00 17.0
R_P3_5_tempListThu>24:00 17.0
R_P3_6_tempListFri>24:00 17.0
Da steht zwar was davon: "...Für jedes Device wird ein Wochenplan (bei einigen Devices können es sogar mehrere sein)..." - was die zwei Dummylisten sollen, wird daraus aber nicht klar. Mir stellt sich da als Erstes die Frage, ob ich diesen Ballast fortführen muss, wenn ich den Plan ändern will? Ich habe mir also eine Datei winterWork.cfg (in Anlehnung an die Seite) angelegt, mit
entities: THWohnzimmer
R_P1_0_tempListSat>06:00 17.0 22:00 21.0 24:00 17.0
R_P1_1_tempListSun>06:00 17.0 22:00 21.0 24:00 17.0
R_P1_2_tempListMon>06:00 17.0 08:00 21.0 16:30 17.0 22:00 21.0 24:00 17.0
R_P1_3_tempListTue>06:00 17.0 08:00 21.0 16:30 17.0 22:00 21.0 24:00 17.0
R_P1_4_tempListWed>06:00 17.0 08:00 21.0 16:30 17.0 22:00 21.0 24:00 17.0
R_P1_5_tempListThu>06:00 17.0 08:00 21.0 16:30 17.0 22:00 21.0 24:00 17.0
R_P1_6_tempListFri>06:00 17.0 08:00 21.0 12:00 17.0 22:00 21.0 24:00 17.0
R_P2_0_tempListSat>24:00 17.0
R_P2_1_tempListSun>24:00 17.0
R_P2_2_tempListMon>24:00 17.0
R_P2_3_tempListTue>24:00 17.0
R_P2_4_tempListWed>24:00 17.0
R_P2_5_tempListThu>24:00 17.0
R_P2_6_tempListFri>24:00 17.0
R_P3_0_tempListSat>24:00 17.0
R_P3_1_tempListSun>24:00 17.0
R_P3_2_tempListMon>24:00 17.0
R_P3_3_tempListTue>24:00 17.0
R_P3_4_tempListWed>24:00 17.0
R_P3_5_tempListThu>24:00 17.0
R_P3_6_tempListFri>24:00 17.0
Eine zweite Frage stellt sich mir, weil dieser Thermostat ja einen Radiatorkopf steuert, der selber im original.cfg auch einen Eintrag hat:
entities:WZ_Radiator_Clima
R_0_tempListSat>06:00 17.0 22:00 21.0 24:00 17.0
R_1_tempListSun>06:00 17.0 22:00 21.0 24:00 17.0
R_2_tempListMon>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_3_tempListTue>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_4_tempListWed>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_5_tempListThu>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
R_6_tempListFri>06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0
Hier mit nur einem Wochenplan... eigentlich scheint es mir überflüssig zu sein, an dem etwas zu drehen, da der Thermostat das ja schon hat. Trotzdem: muss man beide Wochenpläne ändern, oder nur einen, und wenn ja, welchen? Die Dinger sind gepeered mit "set WZ_Thermostat_Weather peerChan 0 WZ_Radiator_Weather single set" und "set WZ_Thermostat_Climate peerChan 0 WZ_Radiator_Climate single set".
OK ich bin auf Nummer sicher gegangen, und habe beides geändert.
Dann habe ich ein
attr hm configTempFile winterWork.cfg,winterHome.cfg,winterAway.cfg,summer.cfg
eingegeben, das soll offenbar die winterWork.cfg Templates nutzen. Ich habe dort die bestehenden durch neue entities ersetzt, z.B.
entities: THArbeitszimmer
R_P1_0_tempListSat>08:00 15.0 24:00 18.0
R_P1_1_tempListSun>08:00 15.0 24:00 18.0
...
Ich kann auch noch die Entities setzen:
attr AZ_Thermostat_Climate tempListTmpl THArbeitszimmer
attr WZ_Thermostat_Climate tempListTmpl THWohnzimmer
attr EZ_Thermostat_Climate tempListTmpl THWohnzimmer
attr GA_Thermostat_Climate tempListTmpl THGang
attr SZ_Thermostat_Climate tempListTmpl THSchlafzimmer
attr DU_Radiator_Clima tempListTmpl RTBad
attr BZ_Radiator_Clima tempListTmpl RTBad
attr KU_Radiator_Clima tempListTmpl RTKueche
Auch ein "set hm tempListG restore" klappt:
passed : ././setup/winterWork.cfg:EZ_Radiator_Clima for EZ_Radiator_Clima
passed : ././setup/winterWork.cfg:GA_Radiator_Clima for GA_Radiator_Clima
passed : ././setup/winterWork.cfg:SZ_Radiator_Clima for SZ_Radiator_Clima
passed : ././setup/winterWork.cfg:WZ_Radiator_Clima for WZ_Radiator_Clima
restore: ././setup/winterWork.cfg:RTBad for BZ_Radiator_Clima
restore: ././setup/winterWork.cfg:RTBad for DU_Radiator_Clima
restore: ././setup/winterWork.cfg:RTKueche for KU_Radiator_Clima
restore: ././setup/winterWork.cfg:THArbeitszimmer for AZ_Thermostat_Climate
restore: ././setup/winterWork.cfg:THGang for GA_Thermostat_Climate
restore: ././setup/winterWork.cfg:THSchlafzimmer for SZ_Thermostat_Climate
restore: ././setup/winterWork.cfg:THWohnzimmer for EZ_Thermostat_Climate
restore: ././setup/winterWork.cfg:THWohnzimmer for WZ_Thermostat_Climate
Wenn ich danach aber ein "set hm templistG verify" eingab, kam ein Berg von Fehlermeldungen:
fail : ././setup/winterWork.cfg:RTBad for BZ_Radiator_Clima: failed Entries:
BZ_Radiator_Clima :R_0_tempListSat mismatch 06:00 17.0 09:00 23.0 23:00 22.0 24:00 20.0 ne incomplete ##
BZ_Radiator_Clima :R_1_tempListSun mismatch 07:00 17.0 10:00 23.0 23:00 22.0 24:00 20.0 ne incomplete ##
BZ_Radiator_Clima :R_2_tempListMon mismatch 05:00 17.0 08:00 23.0 17:00 17.0 23:00 22.0 24:00 20.0 ne incomplete ##
...
Nur die unveränderten Radiatortemplates waren fehlerfrei, aber nur, weil ich dir alten Templates nicht gelöscht habe. Etwas darauf versuchte ich dann nich einmal ein "set hm tempListG restore", weil ich dachte, dass der Update vielleicht länger braucht, oder etwas schief ging. Seither hängt fhem aber, weder webseite noch Telent port reagiert (das System selber läuft aber noch). Ich bin mir nicht sicher, ob ich den Prozess abschiessen soll, oder noch warten.
Auf jeden Fall würde ich gerne wissen, ob und was ich falsch gemacht habe... Wäre froh, wenn ihr mir nen Tipp habt.
lg, klaymen
[EDIT]: Habe es nach Killen des Prozesses (mit kill -9 !) nochmals probiert, sieht nicht viel besser aus... micht beunruhigt die Ausgabe unter CUL_HM unten etwas:
AZ_Thermostat CMDs_processing... getConfig clear msgEvents
BZ_Radiator IOerr getConfig clear msgEvents burstXmit
DU_Radiator IOerr getConfig clear msgEvents burstXmit
EZ_Radiator CMDs_done getConfig clear msgEvents burstXmit
EZ_Thermostat CMDs_processing... getConfig clear msgEvents
GA_Radiator CMDs_done getConfig clear msgEvents burstXmit
GA_Thermostat CMDs_processing... getConfig clear msgEvents
KU_Radiator IOerr getConfig clear msgEvents burstXmit
SZ_Radiator CMDs_done getConfig clear msgEvents burstXmit
SZ_Thermostat CMDs_processing... getConfig clear msgEvents
WZ_Radiator CMDs_done getConfig clear msgEvent burstXmit
WZ_Thermostat CMDs_processing... getConfig clear msgEvents
Im Einzelnen funktioneren die Teile aber alle, hier hats aber noch einige Fehlermeldungen. Kann es sein, dass zuviel gefunkt wird und das Teil überlastet ist?
PPS: Ich habe auch Verständnisprobleme beim Unterschied zwischen "attr xxx tempListTmpl yyy" und "set xxx tempListTempl yyy". Ich habe oben das Erste benutzt. Wenn ich "set AZ_Thermostat_Climate tempListTmpl THArbeitszimmer" eingebe, kommt
failed Entries:
AZ_Thermostat_Climate :R_P1_0_tempListSat mismatch 08:00 15.0 24:00 18.0 ne 06:00 17.0 22:00 21.0 24:00 17.0 ##
AZ_Thermostat_Climate :R_P1_1_tempListSun mismatch 08:00 15.0 24:00 18.0 ne 06:00 17.0 22:00 21.0 24:00 17.0 ##
AZ_Thermostat_Climate :R_P1_2_tempListMon mismatch 17:00 15.0 24:00 18.0 ne 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ##
AZ_Thermostat_Climate :R_P1_3_tempListTue mismatch 17:00 15.0 24:00 18.0 ne 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ##
AZ_Thermostat_Climate :R_P1_4_tempListWed mismatch 17:00 15.0 24:00 18.0 ne 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ##
AZ_Thermostat_Climate :R_P1_5_tempListThu mismatch 17:00 15.0 24:00 18.0 ne 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ##
AZ_Thermostat_Climate :R_P1_6_tempListFri mismatch 12:00 15.0 24:00 18.0 ne 06:00 17.0 09:00 21.0 17:00 17.0 22:00 21.0 24:00 17.0 ##
Er stellt also lediglich fest, dass meine gewünschten neuen Zeitpläne nicht identisch zu den tatsächlich gesetzten sind.... irgendwie alles sehr intransparent.
[EDIT2]: Ich bin mir noch nicht sicher, aber wenn ich statt "set hm tempListG restore" inidividuelle "set WZ_Thermostat_Climate tempListTmpl restore" etc benutze, dann scheint es zu klappen... muss es aber noch verifizieren. Ist das ein bekanntes Problem?
Kleiner Update: mit den individuellen Updates ("set WZ_Thermostat_Climate tempListTmpl restore" etc) statt dem globalen "set hm tempListG restore" hat es offenbar geklappt, wobei nach jedem Update eines Teils wartete, bis die Liste korrekt angezeigt wurde, und das verify auch klappte. Natürlich kann ihc nicht ausschliessen, dass das Globale auch geklappt hätte, wenn ich länger gewartet hätte (aber ich glaube nciht daran). Das ist zwar ok, aber bei späteren wechseln etwas mühsam... man müste das ggf scripten, entweder mit langen Wartezeiten von ein paar minuten nach jedem Teil, oder automatisierten verifies. Gibt es da ncihts Eleganteres?
Das klappt offenbar jetzt auch bei den Teilen, wo Radiatoren mit Thermostaten gepeered sind - es scheint zu reichen, die Thermostaten mit Listen zu versorgen, die Ventilköpfe brauchen keine Eigenen (war zu erwarten, aber sicher war ich nicht). Offen ist, wie ich am besten mit den so überflüssigen Heizlisten in den Ventilköpfen umgehe? Momentan haben die Standardwerte, und in den Clima "attr tempListTmpl xyz" individuelle Einträge mit jeweils der Standardliste drin, die aus dem initialen save stammen, udn die ich im cfg belassen habe (ich nehme an, ich kann diese noch in eine einzige entity mit mehreren Namen zusamenfassen, das ist aber wohl eher zur besseren Übersichtilichkeit im File). . Optional könnte man aber auch "attr tempListTmpl" dieser Devices auf "none" setzen udn die Einträhe im Fiel entfernen? Würde das so klappen? Macht es auf die Menge des Funkverkehrs einen Unterschied?
Unklar ist mir weiterhin die Sache mit den 3 Wochenplänen in den Thermostaten... keine Ahnung, wozu die beiden anderen dienen. Im Wiki wird zwar erklärt, wie man sie setzen kann ("Das HM-TC-IT-WM-W-EU Funk-Wandthermostat AP verfügt über weitere Wochenprogramme, P2 und P3. Um das Wochenprogramm "P2" eines HM-TC-IT-WM-W-EU zu setzen, wird der Temperaturliste "p2" vorangestellt. Beispiel: set <HM-TC-IT-WM-W-EU>_Climate tempListSat p2 07:30 16.0 17:00 20.0 19:00 21.0 24:00 16.0") - wahrscheinlich geht das auch über die cfg Files - aber nicht, wozu und wie man diese Zusatzlisten nutzen kann. Ich verscuhe nochmals, das im Forum hier irgendwie ausfindig zu machen - momentan sieht das für mich nach Dekoration resp. Dokumentation aus. Elegant wäre es natürlich, wenn man wirklich 3 Varianten hinterlegen, und mit einem einzigen Funkkommando eine davon aktivieren könnte - dann würden sie Sinn machen. Aber wie?
lg Andy
Zitat von: klaymen am 23 Dezember 2016, 08:55:33
Unklar ist mir weiterhin die Sache mit den 3 Wochenplänen in den Thermostaten...
Stell Dir vor, dass Du Schichtarbeiter bist und in der einen Woche die Morgenschicht und in der nächsten Woche die Nachtschicht hast. Dann macht es Sinn, dass es mehrere Heizpläne gibt. In der einen Woche aktivierst Du Wochenprogramm 1 und in der anderen Woche Plan 2 und im Urlaub, den Du zu Hause verbringst Plan 3.
Und ja, so lange das Ventil von einem Thermostaten gesteuert wird, kann man dessen eigene Pläne ignorieren.
Danke, das mit den 3 Wochenplänen macht schon Sinn, dann würde auch das Umschalten schneller gehen (wie ich oben ja schon vermutet habe).
Aber leider finde ich keinen Weg, mit welchem Befehl konkret man zwischen den 3 Plänen umschaltet? Müsste über eines der Register gehen oder so?
lg Andy
Hallo nochmals (schon wieder ich :-)
Das mit dem Umschalten habe ich mittlerweile herausgefunden (der Vollständigkeit halber, falls jemand bei ner Suche hier landet):
set xyz_Climate regSet weekPrgSel prog2
Klappt gut, und nach etwas Warten wird die Wunschtemperatur korrigiert (dauert aber eine Minute oder so).
Das Problem, was bleibt ist das nicht funktionierende "set hm tempListG restore". Wenn ich z.B. die Wochenlisten im File anpasse (für alle Thermostaten) und dann "set hm tempListG restore" eingebe, erhalte ich zwar eine korrekte Bestätigung über passed (unveränderte Elemente) und restore (wa szu updaten ist), danach hängt FHEM aber. In fhem-2016-12.log sehe ich massenweise Einträge
2016.12.25 16:30:54 1: HMUARTLGW myHmUART: queue is full, dropping packet
2016.12.25 16:30:55 1: HMUARTLGW myHmUART: queue is full, dropping packet
2016.12.25 16:30:55 1: HMUARTLGW myHmUART: queue is full, dropping packet
676986 solche Einträge, und das in 15 Minuten. Ich musste danach den fhem Prozess killen (und zwar mit -9).
Individuelle "set xyz_Climate tempListTmpl restore" klappen aber. Immerhin kann ich danach reliativ schnell die Wochenprogramm ewechseln. Trotzdem eigenartig...?
lg Klaymen
Hallöchen,
wenn die tempList an die HM-CC-RT... oder auch HM-TC-IT... gesendet wird, erzeugt das sehr viel funk-last. daher gehen die IO's gerne mal in den Overload - oder nehmen halt keine Befehle mehr an, weil die queue (warteschlange) voll ist.
Das ganze Prozedere einmal anstoßen und dann sollte man warten!! ruhig 15 - 30 Minuten oder auch länger, je nach dem wie viele Thermostate man hat. Wenn nach 30 Sekunden nix passiert ist und man dann noch mal tempList restore macht, treibt man die IO's auf jeden Fall in den overload.
einen Erfolg oder halt nicht, kann man mit hmInfo überprüfen
Wie viele Thermostate hast du denn?
Zitat von: automatisierer am 25 Dezember 2016, 17:14:42
Wie viele Thermostate hast du denn?
5 Wandthermostaten (je mit einem Radiator gekoppelt), zusätzlich 3 Radiatoren ohne zusätzliche Wandthermostaten. Ja, ich habe mir etwas in der Art gedacht, wusste aber nicht, wie lange die Queue ist, und ob eventuell ein Hardwareproblem bei meinem Raspberry Modul vorliegt.
Bei den Wandthermostaten ist das nicht so tragisch - da sie ja 3 Listen unterstützen, brauche ich - wenn sie mal geladen sind - nur das eine Register umsetzen, um zwischen den Modi zu wechseln, das erzeugt dann nicht mehr viel Last. Bei den separaten Radiatoren gibt es nur eine Liste, da muss ich jeweils eine Neue senden.
Was ist denn da empfehlenswert: 3 separate "set DU_Radiator_Clima tempListTmpl restore" an die Radiatoren, oder ein einziger "set hm tempListG restore"? Und wenn das Erste, sollte man da zwischen den einzelnen Restores im Skript jeweils ein paar Minuten warten, oder gar irgendwie das Ende den erfolgreichen Abschluss testen?
Oder würde es etwas bringen, das Ganze manuell zu machen, und die Befehle, wie sie im Log file geloggt werden, direkt ausführen mit einem einzigen exec am Ende für alle Radiatoren (falls das überhaupt deviceübergreifend zulässig ist), also z.B.
2016.12.26 00:28:02 3: CUL_HM set DU_Radiator_Clima tempListSat prep 06:00 ...
...
2016.12.26 00:28:02 3: CUL_HM set DU_Radiator_Clima tempListFri prep 06:00 ...
2016.12.26 00:29:43 3: CUL_HM set BZ_Radiator_Clima tempListSat prep 06:00 ...
...
2016.12.26 00:29:43 3: CUL_HM set BZ_Radiator_Clima tempListFri exec 06:00 ...
Mir fällt übrigens im Log auf, dass der letzte Tag einer Seire (Fri) immer doppelt geschickt wird, einmal mit prep und einmal mit exec... ist das normal?
2016.12.26 00:28:02 3: CUL_HM set DU_Radiator_Clima tempListSat prep 06:00 ...
...
2016.12.26 00:28:02 3: CUL_HM set DU_Radiator_Clima tempListFri prep 06:00 ...
2016.12.26 00:28:02 3: CUL_HM set DU_Radiator_Clima tempListFri exec 06:00 ...
Leider habe ich noch immer Probleme mit dem Teil. Hier zuerst mal mein Original-Notify:
define WochenProgrammeTest notify WochenProgramme:test {
my $trg = "prog2";
foreach my $name (("WZ_Thermostat_Climate",
"EZ_Thermostat_Climate",
"GA_Thermostat_Climate",
"SZ_Thermostat_Climate",
"AZ_Thermostat_Climate"))
{
if (ReadingsVal($name,"R-weekPrgSel",99) ne $trg)
{
fhem("set $name regSet weekPrgSel $trg");
}
}
}
Wenn ich das triggere, sehe ich im Log:
2017.01.07 13:43:27 3: CUL_HM set WZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:43:27 3: CUL_HM set EZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:43:27 3: CUL_HM set GA_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:43:27 3: CUL_HM set SZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:43:27 3: CUL_HM set AZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:43:49 1: HMUARTLGW myHmUART: queue is full, dropping packet
2017.01.07 13:43:49 1: HMUARTLGW myHmUART: queue is full, dropping packet
2017.01.07 13:43:50 1: HMUARTLGW myHmUART: queue is full, dropping packet
2017.01.07 13:43:50 1: HMUARTLGW myHmUART: queue is full, dropping packet
Etwa nach 22 Sekunden (manchmal sind es auch 43 Sekunden) kommen die Queue Fehler rein, anfangs 2-3 pro Sekunde, aber innert einer Minuten schaukelt sich das auf ca. 500 pro Sekunde auf. es hilft nur Reboot oder kill -9.
Ich habe auch versucht, nach jedem regSet einen Sleep von ein paar Sekunden einzufügen, aber gleiches Ergebnis. Nach einem Rboot sehe ich, dass einige der Einträge auf "set_prog2" gingen (aber nicht alle), aber nach kurzer Zeit stehen sie wieder auf prog1.
Wenn ich nur 4 wähle, scheint es zu gehen:
2017.01.07 13:49:12 3: CUL_HM set WZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:49:12 3: CUL_HM set GA_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:49:13 3: CUL_HM set SZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:49:13 3: CUL_HM set AZ_Thermostat_Climate regSet weekPrgSel prog2
2017.01.07 13:49:21 3: CUL_HM set AZ_Thermostat_Climate getConfig
2017.01.07 13:49:37 3: CUL_HM set GA_Thermostat_Climate getConfig
2017.01.07 13:49:49 3: CUL_HM set SZ_Thermostat_Climate getConfig
2017.01.07 13:50:05 3: CUL_HM set WZ_Thermostat_Climate getConfig
Oder auch nicht (hier mit 4 Anderen):
2017.01.07 13:53:19 3: CUL_HM set WZ_Thermostat_Climate regSet weekPrgSel prog3
2017.01.07 13:53:19 3: CUL_HM set EZ_Thermostat_Climate regSet weekPrgSel prog3
2017.01.07 13:53:19 3: CUL_HM set SZ_Thermostat_Climate regSet weekPrgSel prog3
2017.01.07 13:53:19 3: CUL_HM set AZ_Thermostat_Climate regSet weekPrgSel prog3
2017.01.07 13:53:47 1: HMUARTLGW myHmUART: queue is full, dropping packet
...
Immerhin wurden hier nach einem Reboot die ersten drei gesetzt, AZ_Thermostat_Climate aber nicht.
Ich steure übrigens auch Lichtgruppen via Homematic (4 total), die kannn ich aber recht schnell ein- und ausschalten:
2017.01.07 14:01:27 3: CUL_HM set DL_Bar on
2017.01.07 14:01:27 3: CUL_HM set DL_Kueche on
2017.01.07 14:01:27 3: CUL_HM set DL_Gang on
2017.01.07 14:01:27 3: CUL_HM set DL_Halle on
2017.01.07 14:01:29 3: CUL_HM set DL_Bar off
2017.01.07 14:01:29 3: CUL_HM set DL_Kueche off
2017.01.07 14:01:29 3: CUL_HM set DL_Gang off
2017.01.07 14:01:29 3: CUL_HM set DL_Halle off
Das sind immerhin 8 Telegramme in 2 Sekunden. Ein generelles Problem schient es also nicht zu sein, oder?
Ich habe auch versucht, jedes einzelne Schalten zu bestätugen, mit folgendem Code:
WochenProgramme:test {
my $trg = "prog2";
foreach my $name (("WZ_Thermostat_Climate",
#"EZ_Thermostat_Climate",
"GA_Thermostat_Climate",
"SZ_Thermostat_Climate",
"AZ_Thermostat_Climate"))
{
if (ReadingsVal($name,"R-weekPrgSel",99) ne $trg)
{
fhem("set $name regSet weekPrgSel $trg");
while (ReadingsVal($name,"R-weekPrgSel",99) ne $trg)
{
printf ("sleep: %s\n",ReadingsVal($name,"R-weekPrgSel",99));
sleep(1);
}
}
}
}
Das blockiert aber nach dem ersten Teil schon:
2017.01.07 14:09:35 3: CUL_HM set WZ_Thermostat_Climate regSet weekPrgSel prog2
sleep: set_prog2
sleep: set_prog2
sleep: set_prog2
...
Ich nehme an, weil FHEM single-threaded ist, und mein Code FHEM blockiert, das Reading also gar nicht geupdated werden kann.
Wie gehe ich da am besten vor? Mir kommt im Moment höchstens in den Sinn, die einzelnen Settings in einem Abstand von ein paar Minuten timergesteuert durchführen zu lassen. Und - ist dieses Verhalten normal? Wo kann das Problem liegen? Die Thermostaten und FHEM sind übrigens nicht weit auseinander, maximal 5 Meter, ohne viel Wände, nur AZ ist im unteren Stock, aber dort praktisch an derselben Stelle wie FHEM.
Danke im Voraus.
Andreas
Hallo Andreas,
attr qLen 60 hast Du gesetzt?
Und Du bist sicher hier im richtigen Unterforum zu sein? Homematic fände ich sinnvoller...
Gruß Otto
Hallo Otto,
Nein, qLen habe ich nie angerührt, höre ich zum ersten Mal... mein hmUART hat kein qLen Attribut, habe es mal gesetzt und werde testen. Wo ist das denn dokumentiert? Meine Suche im Wiki brachte da nichts, und im Forum auch nur in einem Fall als Fehlerbehebung...
Hast recht, ist wohl HomeMatic spezifisch, aber anfangs - Temperaturlisten - fand ich, es passt hier besser. Das Problem hat sich wohl verschoben, und so wäre die Frage besser im HM Forum - ist anfangs manchmal schwierig, zu entscheiden, wo eine Frage hingehört...
Danke, Andreas
[EDIT]: Löst das Problem leider nicht.... ich habe eine Lösung mittels at gebastelt, das klappt immerhin, aber ist mir trotzdem schleierhaft.
Ja dokumentiert ... :-[
Ich werde das als Hinweis mal mit ins Wiki schreiben. Ich hatte einmal diesen Fehler und bin über diesen Hinweis "gestolpert"
Schade das es nichts bringt.
Gruß otto
Zitat von: Otto123 am 07 Januar 2017, 15:25:45
Ja dokumentiert ... :-[
Wo denn? Ich habe als Hardware in Raspberry übrigens das https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi - eventuell ist das anders als das Teil via USB.
[EDIT] Ich meine damit, dass ich nicht das LAN Gateway benutze. Spielt für das Problem wahrscheinlich keine Rolle, aber ich wollte vollständig sein.
Falls es von Bedeutung ist, ich habe die Sache momentan über einen 5-minütlichen at gelöst:
+*00:05:00 {
my $trg = Value("HeizungsZielProgramm");
foreach my $name (("WZ_Thermostat_Climate",
"EZ_Thermostat_Climate",
"GA_Thermostat_Climate",
"SZ_Thermostat_Climate",
"AZ_Thermostat_Climate"))
{
my $oldProg = ReadingsVal($name,"R-weekPrgSel",99);
# Update falls in set_... Zustand
if (substr($oldProg, 0, 4) eq "set_")
{
fhem("set $name getConfig");
last; # Max 1 pro Durchgang (Overloads)
}
# Setzen, falls in einem "progx", aber im Falschen
if (substr($oldProg, 0, 4) eq "prog" &&
$oldProg ne $trg)
{
fhem("set $name regSet weekPrgSel $trg");
last; # Max 1 pro Durchgang (Overloads)
}
}
}Das setzt jeweils maximal einen Thermostaten auf das globale Wunschprogramm (im Dummy HeizungsZielProgramm), dabei werden nur solche beachtet, die nicht gerade ein "set_..." haben (also auf eine Bestätigung warten). Das dauert so natürlich, aber für das Umschalten der Wochenprogramme ist das für mich so ok. In den Notifies muss ich jetzt nur noch den Dummy setzen.
lg Andreas
PS: Sorry wenn ich das hier im Thread im falschen Forum anfüge, eventuell sollte man den ganzen Thread ins Homematic Forum schieben - einen neuen zu beginnen fand ich überflüssig.
ich meinte damit: es ist sicher nicht dokumentiert ;)
Wie kommst Du plötzlich auf USB?
Den Thread kannst Du verschieben ;)
Gruß Otto