HM-CC-TC mit CMDs_pending bei set desired-temp

[mirQ]

Hallo zusammen,

ich benutze FHEM schon seit längerem, hatte bis letzte Woche auch keine Probleme. Bisher hatte ich eine Version von Mitte 2013 und habe es gewagt ein Update zu machen. Hat im Prinzip auch funktioniert, allerdings ließ sich die Temperatur der Thermostate nicht mehr ändern. Also sie ließ sich ändern, kam aber nie bei den Thermostaten an.
Zunächst dachte ich, dass es möglicherweise an der "alten" Config lag und habe (das wollte ich eh mal machen um meine Testereien aus der alten Config mal sauber aufzuräumen) mit einer neuen Config angefangen. Geräte über den HMLAN gepairt. Alles super. Aber: Temperatur setzen geht immer noch nicht.
Nach ein wenig recherche ist mir aufgefallen, dass nach einer Änderung der Temperatur und dem Abarbeiten der CMD-Queue der Status weiterhin auf CMDs_pending bleibt. Das ist wohl eindeutig ein Fehler. Allerdings bin ich etwas verunsichert, ob er auf meiner Seite zu suchen ist, oder ob das ein Bug in der aktuellen Version ist?

Ich habe vorsichtshalber mal ein paar Logs erstellt und angehängt wo ich für den TC (wz_Thermostat) eine Temperaturänderung auf 16°C durchführe. Anschließend bleibt der Status bei CMDs_pending hängen.

Danke schonmal und viele Grüße
Mirko

[martinp876]

Das Device wacht auf, FHEM sendet ein "warte mal", TC sagt "ok". dann sendet fhem die temp, aber der TC antwortet nicht darauf.

Möglich wäre, dass das setzen zu schnell zum TC kommt. Bekannt ist mir das nicht, bei RTs u.ä. klappt das alles genau so.

Wie ist es bei anderen Kommandos?

[mirQ]

Hallo Martin,

danke für die Antwort. Ich habe es mal bei meinem einzigen RT getestet, da funktioniert alles prima. Temperatur lässt sich ohne Probleme setzen. Nur die TCs machen Ärger.
Ich habe jetzt nochmal eine blanke Config genommen, nur den TC aus dem Wohnzimmer gepairt und testweise den controlMode auf auto setzen lassen. Da sind dann zunächst 4, anschließend 6 CMDs in der Queue, die bleiben aber drinnen und mit jedem Duty Cycle steigt Resnd um eins.
Hab das mal geloggt.

Viele Grüße
Mirko

[martinp876]

Das Verfahren sieht wie beim RT aus.
klappt die Übertragung, wenn du config am TC auslöst?

[mirQ]

Hallo Martin,

ich nehme mal an, dass du mit Config auslösen das 5 Sek. OK drücken -> KON meinst, oder?
Habe das mal geloggt: Temperatur bei fhem geändert, die Änderung war 2x im Duty Cycle nicht erfolgreich, Status blieb auf "pending", dann hab ich KON ausgelöst und voila, Temperatur wird gesetzt.

Was mir aber gerade auch aufgefallen ist: wenn die Temperatur dann erfolgreich gesetzt ist, wird die Anzeige am TC nicht aktualisiert. Erst wenn ich einmal kurz auf OK drücke wird die Anzeige aktualisiert und die Sonne verschwindet bzw. erscheint, je nach Temperatur.

Viele Grüße
Mirko

[Newbie]

Hallo Mirko, Hallo Martin,

ich klinke mich mal hier ein. Ich habe seit ca 2 Wochen die gleichen Symptome bei meinen beiden TC, meine 7 DN funktionieren tadellos.

Abhilfe bisher

Code Auswählen Erweitern

attr burstAccess 1_auto

bei den TC, aber wenn ich dich Martin richtig verstanden habe, geht das ja zu Lasten der Funklast.

mfg Jens

[martinp876]

Nicht nur beim TC.

[Billy]

Hallo Martin,
habe hier zufällig mal mitgelesen und muss feststellen, dass meine TC's nun auch kein set desired temp mehr ausführen und im "protState CMDs_pending"
hängen bleiben. 
Das ist natürlich unbefriedigend.
das fiel mir bisher nicht auf, da meine TC's über die Templist laufen und ich normalerweise nicht über FHEM an der desired temp drehe.

Welche Module von dir muss ich nun restoren, damit ich feststellen kann seit wann der BUG auftritt?
d.h. 00_HMLAN.pm und 10_CUL_HM.pm oder nur einer von beiden?
Muß ich dabei mit Auswirkungen auf andere Module rechnen?

Gruß Billy

[DecaTec]

Ich habe ähnliche Probleme beim Setzen eines Registers:

Code Auswählen Erweitern

fhem("set wz.Thermostat_Climate regSet weekPrgSel prog1");

Wird in einer Funktion in den MyUtils aufgerufen. Das ganze gleich für mehrere TCs.

Fhem liefert dann für das Register weekPrgSel "set_prog1". Das bleibt dann aber auch so und schaltet erst nach einem manuellen getConfig auf "prog1" um.
Bei allen TCs steht autoReadReg auf 5. ist es hier nicht so, dass Fhem automatisch ein getConfig aufrufen sollte (evtl. mit etwas Zeitverzögerung), wenn Commands pending sind, oder irgendwelche Register auf set_xxx stehen?

[ext23]

Code Auswählen Erweitern

attr burstAccess 1_auto

Das habe ich gestern auch gemacht weil ich gemerkt habe, dass die Heizung nicht mehr warm wird...

[Billy]

Das habe ich gestern auch gemacht weil ich gemerkt habe, dass die Heizung nicht mehr warm wird...

Ich glaube nicht dass das die gewollte Lösung ist.
Bin gespannt was Martin dazu sagt, nachdem die HM-CC-TC bisher über 2 Jahre problemlos liefen.
Irgendwo muß da was geändert worden sein.

Billy

[DecaTec]

Habe gerade gemerkt, dass das pairen wohl auch nicht mehr funktioniert.

Habe ein unpait auf ein Device gemacht und dann neu über die VCCU pairen wollen. Register pairCentral bleibt dann auf set_xxxxxx hängen und ein manuelles getConfig führt nur zu weiteren cmd_pending. Das Pairen klappt erst, wenn man das Device ein zweites mal in den Anlern-Modus bringt.

Das hat vor ein paar Tagen noch einwandfrei funktioniert.

[martinp876]

Nachdem ich kein testgeraet mehr habe...
Bitte ein log mit der alten und der neuen version

[Billy]

Nachdem ich kein testgeraet mehr habe...
Bitte ein log mit der alten und der neuen version

Kann dir gerne ein testgerät zukommen lassen. --> HM-CC-TC

Mit welchen Modulen muß ich zurück? reicht 00_HMLAN.pm und 10_CUL_HM.pm oder
nur eines von beiden?
Billy

[Billy]

Um das ganze zu beschleunigen habe ich mal mein restore vom 2015-09-29 eingespielt.
# $Id: 00_HMLAN.pm 9103 2015-08-22 05:23:08Z martinp876 $
# $Id: 10_CUL_HM.pm 9201 2015-09-04 21:28:56Z martinp876 $

Damit geht alles einwandfrei!
Werde mich morgen mal nach vorne tasten.

Welche Logs mit welchem Loglevel brauchst du.
Billy