btnLock für Thermostate mit FILTER...

Morgennebel · 23 Juli 2017, 18:58:19

Moin Moin,

ich versuche, im gesamten Haus in der Sommerpause die Bedienelemente der Heizungsthermostaten und der Wandthermostaten zu sperren.
Leider funktionieren weder

Code Auswählen

set TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=DEF=...... regSet btnLock on
set TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=DEF=...... regSet btnLock on

noch

Code Auswählen

set TYPE=CUL_HM:FILTER=model=HM-CC-RT-DN:FILTER=ChanNo=00 regSet btnLock on
set TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=ChanNo=00 regSet btnLock on

der Befehl wird angenommen aber ohne Resultat: es gibt in den beteiligte Thermostaten keine PendingCommands, ein getConfig zeigt denselben Status wie zuvor und R-btnLock bleibt auf off...

Was mache ich falsch?

Danke, -MN

Otto123 · 23 Juli 2017, 21:17:42

Hi,

habe gerade getestet:

Code Auswählen

list TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=DEF=...... funktioniert bei mir. Und ein

Code Auswählen

set <Einer der gefunden Thermostate> regSet btnLock on auch.
Da wird fleißig übertragen und dann ist das Schloß zu im Display

Und ein

Code Auswählen

set TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=DEF=123456 regSet btnLock on funktioniert auch.

Allerdings gab es vorher ein R-btnLock das ist verschwunden. Über regTable wird es aber angezeigt.

Gruß Otto

Morgennebel · 23 Juli 2017, 23:33:47

Danke, Otto,

ich möchte mit dem set & TYPE/FILTER-Kombination alle Thermostaten auf einmal erwischen. Mit einem bekannten (DEF-ID oder Namen) funktioniert es.

Warum aber nicht mit TYPE/FILTER?

Danke, -MN

Otto123 · 23 Juli 2017, 23:46:45

Hi,

ich sehe nicht warum es nicht funktioniert. Ich hatte keine Lust alle meine Thermostate zu setzen, du meinst genau das geht nicht? Mehrere auf einmal?
Also für ein Gerät ging es bei mir mit TYPE/FILTER
Ich habe es jetzt probiert genau so wie Du wolltest mit ...... geht astrein, meine 3 Thermostate werden gelockt.

Am Befehl liegt es nicht, Du hast ein anderes Problem, welchen IO hast Du?

Geht der in Overload? Es sind pro Thermostat 14 CMDs ...

Gruß Otto

Morgennebel · 24 Juli 2017, 14:37:46

Hi Otto,

die Heizungsthermostate sind alle gesperrt, jedoch die Wandthermostate nicht. Die stehen allerdings alle momentan im Manuellen Modus auf "off".

Mein IO ist eine VCCU mit 2 x HMLAN. Davon geht einer recht schnell in den Overload-Modus, wenn ich

Code Auswählen

set TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=DEF=...... regSet btnLock on

verwende (14 Wandthermostate werden gefunden). Interessanterweise klappt es mit

Code Auswählen

TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=chanNo=00 regSet btnLock on

jedoch nicht...

Hmmm..

Ciao, -MN

Otto123 · 24 Juli 2017, 14:51:33

Hi,

ja da stimmt der Filter nicht, kurz probiert und

Code Auswählen

list TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=chanNo=00gibt nichts zurück.
Gibt es denn einen Channel 00?
Mit 01 funktioniert der Filter!

Code Auswählen

list TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=chanNo=01
list TYPE=CUL_HM:FILTER=model=HM-TC-IT-WM-W-EU:FILTER=DEF=......01

Ich glaube das mit der Massenabfertigung mit 14 Thermostaten führt zum Chaos. Bei mir lief gestern mit drei Thermostaten der HmUART schon in eine 5 minütige Endlos Schleife mit 100% CPU aus der ich ihn nur mit reboot befreien konnte.

Code Auswählen

2017.07.23 23:48:10 1: HMUARTLGW HMUART1: queue is full, dropping packet
2017.07.23 23:48:10 1: HMUARTLGW HMUART1: queue is full, dropping packet
2017.07.23 23:48:10 1: HMUARTLGW HMUART1: queue is full, dropping packet
2017.07.23 23:48:11 1: HMUARTLGW HMUART1 IO in overload!
2017.07.23 23:48:12 1: HMUARTLGW HMUART1 IO in overload!
2017.07.23 23:48:15 1: HMUARTLGW HMUART1 IO in overload!

Ich glaube, da musst Du besser was in Perl bauen mit einer schönen Pause dazwischen.

Gruß Otto

Morgennebel · 25 Juli 2017, 12:21:17

Hi Otto,

ich habe eine VCCU mit 2 x HMLAN. Davon ist bei 14 Wandthermostaten einer in Overload gegangen.

Bei etwa der Hälfte der Wandthermostaten bleibt es bei btnLock im Status "set_on" und ein getConfig zeigt dann den Ausgangswert "off".

Mein Ansatz wäre, die Wandthermostaten zu gruppieren (EG, OG, Nord, Süd), d.h. EG-Nord, EG-Süd, usw. und dann den FILTER zu ergänzen - und zwischen den Filtern eine Wartezeit zu definieren...

Danke für die Hilfe,

Ciao, -MN

frank · 26 Juli 2017, 11:12:06

das problem mit overload ist sicherlich das automatische getconfig nach dem setzen des registers auf das hauptdevice. denn hier werden dann vermutlich alle daten sämtlicher channel angefordert, beim tc bis zu 7 chn, inkl. peers.

allerdings hätte ich gedacht, dass ein overload durch den batchlevel beim hmlan, verhindert werden würde.

haben die hmlan aktuelle firmware?
hast du die tc über prefered io auf die hmlan gerecht verteilt?
mit welcher load starten die hmlan den vorgang?
wie ist die einstellung von autoreadreg?

Otto123 · 26 Juli 2017, 11:29:57

Zitat von: frank am 26 Juli 2017, 11:12:06
das problem mit overload ist sicherlich das automatische getconfig nach dem setzen des registers auf das hauptdevice. denn hier werden dann vermutlich alle daten sämtlicher channel angefordert, beim tc bis zu 7 chn, inkl. peers.

So scheint es, ich habe das nicht exakt beobachtet, es gab aber glaube ich sogar noch einen dritten "Durchgang" . Ich habe nur den Geräte in der Oberfläche beobachtet und nur beim Wand-Thermostaten.

Ich kann das gern nochmal getrennt probieren mit HMLAN und HMUART. Vielleicht kann man ja sogar beim HMUART noch was nacharbeiten, weil der hat bei mir echt geschleudert, bei drei Wand Thermostaten! Das könnte nur Michael sagen

Gruß Otto

Morgennebel · 26 Juli 2017, 12:34:59

Zitat von: frank am 26 Juli 2017, 11:12:06
haben die hmlan aktuelle firmware?
hast du die tc über prefered io auf die hmlan gerecht verteilt?
mit welcher load starten die hmlan den vorgang?
wie ist die einstellung von autoreadreg?

HMLAN Firmware = 0.964 auf beiden
Bei allen TCs steht VCCU als IODev (die stehen räumlich verteilt, weil die Reichweite eines HMLAN nicht ausreicht)

Ich habe den set-Befehl mit 14 TCs gerade nochmal aufgerufen. Beide starteten mit low-Last. HMLAN1 ging nach wenigen Sekunden in Disconnect-Modus (der hängt an einem 100MBit-Hub). Die Befehle laufen aber nicht durch, durch den Disconnect von HMLAN1 bleibt es bei einem set_on in einigen TCs.

Der Wert autoReadReg steht auf 4_reqStatus.

Ciao, -MN

Otto123 · 26 Juli 2017, 13:44:14

Hi MN,
die letzte Weisheit war 0.965 für den HMLAN. Die sollte wohl vor allem diffuse Probleme mit Nachbarn beheben die HM IP Pakete in die Luft pusten.

Läuft bei mir unauffällig gut, kann ich als update empfehlen.

Gruß Otto

frank · 26 Juli 2017, 13:52:29

firmware würde ich aktualisieren => 0.965. könnte verbesserung mit disconnects bringen.

ZitatBei allen TCs steht VCCU als IODev (die stehen räumlich verteilt, weil die Reichweite eines HMLAN nicht ausreicht)

hoffentlich meinst du IOgrp.
da würde ich auf jeden fall ein prefered io festlegen, zb "VCCU:HMLAN1" (eigentlich bei allen stationären devices). natürlich immer den mit den besten rssi.

ZitatDie Befehle laufen aber nicht durch, durch den Disconnect von HMLAN1 bleibt es bei einem set_on in einigen TCs.

das setzen könnte ja trotzdem funktioniert haben, schau am tc nach. mit autoreadreg=5_missing sollte/könnte später das getconfig nachgeholt werden. allerdings wahrscheinlich erst, wenn der batchlevel beim hmlan wieder erreicht ist. kann dann also wahrscheinlich sehr lange dauern.

vielleicht abeitet ein "set regBulk" mit weniger messages.

oder erst bei allen tc autoreadreg=0 zum setzen der register wählen, in der hoffnung, dass kein automatisches getconfig kommt. nach dem setzen dann wieder auf 5_missing. vielleicht werden dann nach und nach die getconfig nachgeholt.

hm..., ich frage mich gerade, ob die vccu auch ein io nutzt, welches gar keine chance hat ein device zu erreichen. das würde ja nur unnötig load erzeugen. eigentlich müsste/sollte man bei jedem device auch io's ausschliessen können.

Otto123 · 26 Juli 2017, 18:34:37

Hi,

ich unterstreiche mal noch meine Idee von #5 und habe mit Halbwissen von Perl mal per Klau & Paste was für die 99_myUtils.pm zusammengeführt und getestet.
Du erkennst die Möglichkeit mit dem Filter (TYPE=dummy:FILTER=state=on), Du erkennst die Möglichkeit der Pause (sleep 10;) und Du erkennst sicher den Befehl (set $d off).
So wie es ist, kann man beliebig viele dummy's die "on" sind im 10 Sekunden Takt "off" setzen. Die gefundenen Dummy's werden als String zurückgegeben.

Code Auswählen

sub Test() {
 my $ret = '';
 my @array = '';
 my $cmd;
 
 @array = devspec2array("TYPE=dummy:FILTER=state=on");
 foreach my $d (@array) 
 {
 	$cmd .= "sleep 10;" if ($cmd);
    $cmd .= "set $d off;";
	$ret .= "$d"."|";
}
fhem $cmd;

return $ret;
}

Gruß Otto