HmIP-eTRV-2 Bediensperre

[gnatolf]

Hallo,

Nachdem ich es schaffe, per Skript/automatisiert die Bediensperre auf meinen Thermostaten zu setzen ( viewtopic.php?f=77&t=68486 ), wunderte ich mich heute, dass sich diese offenbar 'lösen' kann.

Da alle Thermostate in Wochenprogrammen programmiert sind, folgende Fragen:

Ich hatte es bisher so verstanden, dass die Wochenprogramme auch bei Bediensperre ablaufen - die Sperre nur die manuelle Manipulation am Gerät verhindert. Ist das richtig so?

Wenn der reset nach einer festen Zeit erfolgt, wäre es einfach, dies mit brute force direkt wieder zurück zu setzen. Elegant ist das allerdings nicht... Gibt es da eine Möglichkeit?

Verstehe ich es richtig, dass die Bediensperre ja 'lokal' im Gerät gesetzt/gespeichert wird, oder gibt es eine Systemvariable auf der CCU, die exakt den Status hält?

Oder, offener kann man es kaum fragen, was kann den Reset der Bediensperre triggern?

Vielen Dank für eure Hilfe.

[cloudman88]

Was dazu führt, dass der Lock verschwindet weiß ich nicht.

Hier mein Hack um den Status zu lesen. Ob das die optimale Methode weiß ich auch nicht.
Nach etwas trial und error hat das hier für mich funktioniert

Code: Alles auswählen

object dev=devices.Get("WohnzimmerTerasse");
!- WriteLine(dev);
!- WriteLine(dev.Address());
!- WriteLine(dev.Interface());

boolean locked = false ; 
var master = xmlrpc.GetParamset(dev.Interface(), dev.Address() # ":0", "MASTER");
!- WriteLine(master);
var token='<member><name>GLOBAL_BUTTON_LOCK</name><value><boolean>';
var idx= master.Find(token) ; 
if (idx != -1) {
  var w = master.Substr(idx + token.Length(),1 );
  locked =  (w == '1') ;
}

WriteLine( locked);

[gnatolf]

Das heißt du hast auch mit verschwundenen Sperren zu kämpfen?

Den Status abzufragen, bin ich auch schon auf die Idee gekommen. Da kann ich aber ja auch einfach den Lock-Befehl nochmal schicken, oder nicht?

[Baxxy]

was kann den Reset der Bediensperre triggern?

Gute Frage, habe ich bisher so noch nicht gehört.
Was sagt der Gegentest mit händisch gesetztem Haken in den Geräteeinstellungen? Springt der auch irgendwann raus?

[gnatolf]

Ja, der springt auch wieder raus.

[Xel66]

Dann würde ich mal behaupten, dass die Ursache in der Aktorfirmware zu suchen ist, denn dort wird dieser Zustand ja gespeichert. Die CCU liest das nur aus und zeigt es an.

Gruß Xel66

[cloudman88]

Das heißt du hast auch mit verschwundenen Sperren zu kämpfen?

Den Status abzufragen, bin ich auch schon auf die Idee gekommen. Da kann ich aber ja auch einfach den Lock-Befehl nochmal schicken, oder nicht?

Nein habe ich nicht - dein Post hat mich nur neugierig gemacht wie man den Status abfragen kann
Ich wusste nicht so genau ob Teil deiner Frage war wie man den Status abfragt.

Zum Testen habe ich die Sperre gestern gesetzt - zumindest heute morgen ist sie noch da.
Wie lange dauert es denn so im Durchschnitt?

Klar kann du den lock Befehl neu senden - ich würde nur nicht zu oft den Status abfragen - bin mir nicht sicher ob es auf den DC Einfluss hat

[gnatolf]

Ja genau, der Verschleiß ist es, der mich davon abhält, es mit brute force zu "lösen". Wie lange es dauert ist schwer zu sagen, aber über Nacht ist es recht zuverlässig weg, wenn ich meine Erfahrungen so richtig erinnere.

Eine weitere (theoretische, vage Theorie!) Möglichkeit könnte noch sein, dass das node red Dashboard in irgendwelchen Tabs auf verschiedenen Endgeräten 'immer mal wieder' geladen wird, und beim refresh der Zustand der sich dort befindlichen Schalter 'falsch' aktualisiert. Der Default ist bei allen glaube ich offen, dann könnte ich die Logik mal umdrehen und das überprüfen. Insbesondere wenn zB aggressives Speichermanagement von mobilen Geräten die Tabs aus dem RAM kickt.

Es sind meiner Meinung nach 7 Geräte betroffen, glaube nicht, dass es sich bei allen dann um Firmware-Probleme handelt, die noch kein anderer User entdeckt hat. Obwohl ich mich schon bei der Frage nach dem 'remote' schalten der Sperre ohne Homematic WebUI gewundert habe, dass offenbar nicht viele diese Funktion benutzen.

[Black]

das der Haken auch in der WebUI wieder rausi st spricht eigentlich gegen ein Firmwareproblem. Parameter werden, wenn ein Aktor an einer CCU angelernt ist, immer von der CCU in den Aktor übertragen. Wenn die CCU also weiss (oder glaubt) dass der Haken raus ist, so ging dies über den Schnittstellenprozess der CCU. Dies muss nicht unbedingt die CCU gemacht haben, auch Middlewares setzen auf den Schnittstellenprozessen auf und können dadrüber auch Ändrungen ausführen. Nodered benutzt für den Gerätezugriff auf den XMLrpc Prozess, wäre also denkbar, das die Ursache daher kommt.

Es ist ohne Probleme möglich, in der WebUI die Sperre zu setzen, dann über z.b. IObroker über ein SendTo Auf den RPC Adapter dieser weider zu entfernen und beim nächsten öfnen der WebUI,- richtig, ist diese Sperre weg.

Ich hab das mal seit 2 Tagen testweise an einem eTRV-2 probiert, der brauchte bishe rnoch kein Voltax

Black

[gnatolf]

das der Haken auch in der WebUI wieder rausi st spricht eigentlich gegen ein Firmwareproblem.
....
Nodered benutzt für den Gerätezugriff auf den XMLrpc Prozess, wäre also denkbar, das die Ursache daher kommt.

Ja, siehe oben, denke ich auch. Der Haken in der WebUI ist völlig analog und korrekt wie am Gerät, hier sehe ich überhaupt nicht das Problem, muss 'natürlich' wenn dann von der Middleware kommen.

Ich hab das mal seit 2 Tagen testweise an einem eTRV-2 probiert, der brauchte bishe rnoch kein Voltax

Ich werde zeitnah versuchen, die Verbindung mit dem Node Red Dashboard zu kappen, wie gesagt, halte das eigentlich für den fast einzigen möglichen Auslöser.