[gelöst] Gelegentlich Fehler bei Homematic

[Rene55]

@paul53 Ah, Ok, krieg ich hin. Hab nur ein Problem mit 'soll' und 'ist'. Der Sollwert steht ja im Datenpunkt des Aktors drin, allerdings rot (also nicht bestätigt). Das ist ja der, den du als 'ist' nimmst. Da hab ich noch nen Knoten im Script (Kopf).

[paul53]

@rene55 sagte: Der Sollwert steht ja im Datenpunkt des Aktors drin,

Erst einmal nicht, sondern es gibt irgendwelche Bedingungen, die zum Schalten führen sollen: Das Ergebnis dieser Bedingungen ist der Sollzustand in einer Variablen.

@rene55 sagte in Gelegentlich Fehler bei Homematic:

Das ist ja der, den du als 'ist' nimmst.

"ist" ist der Zustand, der als "bestätigt" vom Aktor gesendet wird.

EDIT: Bei mir ist der Sollzustand in einem virtuellen Datenpunkt vorhanden.

const idSoll = '0_userdata.0.xyz'; 

var soll = getState(idSoll).val;

// und unten
on(idSoll, function(dp) {
   soll = dp.state.val;
   Schalten();
});

[grrfield]

@rene55 Ich habe dasselbe Problem und mir dafür eine Funktion setHMStateSec() geschrieben, die in einem globalen Skript gespeichert ist und von überall aufgerufen werden kann. Die Funktion setzt den entsprechenden State und überprüft, dann, ob er ausgeführt wurde. War das nicht erfolgreich, wird einige Zeit immer wieder versucht, die Homematic-Komponente anzusprechen:

/**
 * Setzt sicher einen State und überprüft die Ausführung.
 * Überprüft nach _HMAckWait (2000 ms), ob der Befehl erfolgreich war. 
 * Bei Mißerfolg wird der Befehl mit setState() jeweils nach _HMAckWait und  
 * einem zufälligen Anteil so oft wiederholt, bis er ausgeführt wurde
 * oder bis die Zeit HM_reptime (10000 ms) abgelaufen ist.
 * @param   {string}            HM_id           ID der Homematic-Komponente
 * @param   {boolean|number}    HM_value        zu schreibender Wert
 * @param   {number}            [HM_reptime]    optional: maximale Zeit für die Versuche [ms]
 * @param   {number}            [HM_ackwait]    optional: Verzögerung zwischen den Versuchen [ms]
 * @returns {Object}            acksiID         setInterval ID - löschen mit clearInterval()
 */
function setHMStateSec(HM_id, HM_value, HM_reptime, HM_ackwait)
{
    // maximale Default-Zeit für Versuche [ms] (kann mit Parameter überschrieben werden)
    let _HMreptime=10000;      //10000
    // Default-Verzögerung zwischen den Versuchen [ms] (kann mit Parameter überschrieben werden)
    let _HMackwait=2000;       //2000

    let _HMacksiID;

    setState(HM_id, HM_value);

    if(HM_reptime !== undefined && typeof(HM_reptime) == 'number') {
        _HMreptime=HM_reptime;
        if(HM_ackwait !== undefined && typeof(HM_ackwait) == 'number') _HMackwait=HM_ackwait;
    }
    let i=1;
    _HMacksiID=setInterval(function() {
        i++;
        if(getState(HM_id).val == HM_value && getState(HM_id).ack === true) {
            log('setHMStateSec '+HM_id+' Success.');
            clearInterval(_HMacksiID);
        } else if(i*_HMackwait > _HMreptime) {
            log('setHMStateSec '+HM_id+' no success after trial '+(--i), 'error');
            clearInterval(_HMacksiID);
        } else {
            log('setHMStateSec '+HM_id+' trial '+i, 'warn');
            setStateDelayed(HM_id, HM_value, Math.floor(Math.random()*10)*_HMackwait/100);            
        }
    }, _HMackwait);
    return _HMacksiID;
}

Der Aufruf erfolgt wie bei setState():

setHMStateSec('hm-rpc.0.xxxxxxxx.1.STATE', true);

Optional kann noch die Wartezeit zwischen dem erneuten Ausführen (hier 5 s) und die Zeitspanne, in der versucht wird, neu zu senden (hier 20 s), angegeben werden; ansonsten werden die Defaultwerte (2 s und 10 s) verwendet:

setHMStateSec('hm-rpc.0.xxxxxxxx.1.STATE', true, 20000, 5000);

HM_reptime muß größer sein als HM_ackwait, sonst finden keine erneuten Versuche statt.
Ich verwende die Funktion nur für kritische Schaltvorgänge, die in jedem Fall ausgeführt werden müssen.
Einige Homematic-Komponentne brauchen recht lange, bis der Funkbefehl bestätigt wird (z. B. Heizungsgruppe mit Thermostat ca. 30 s) - dann muß HM_ackwait größer als diese Zeit gewählt werden, damit es nicht zu Konflikten kommt.

[Rene55]

@grrfield sagte in Gelegentlich Fehler bei Homematic Funktion setHMStateSec():
Sauber. Das sieht auch gut aus. Ich hab mir das Script 'mal geklaut' und unter global gespeichert. Ich gehe davon aus, dass ich dann in meinem (Rollladen)Script den Aufruf ans HM-Device durch den Aufruf dieses Scriptes ersetzen muss. Und dann natürlich hoffen, dass der Gelegentlich-Fall bald wieder eintritt und das Script entsprechend reagiert. Zunächst mal Danke für die Idee.

[Homoran]

@rene55 sagte in Gelegentlich Fehler bei Homematic:

unter global gespeichert.

du weisst wofür global ist?

[Rene55]

@homoran Ich geh damit sehr vorsichtig um . Ich habs erstmal so übernommen, ums zu testen. In 5 Minuten gehen die ersten Rollläden zu - dann weiß ich mehr. Wenn ichs verstanden habe, werde ich das in mein Rollladenscript einbauen, so dass es nicht mehr global liegen muss.

[Rene55]

@paul53 sagte in Gelegentlich Fehler bei Homematic:

virtuellen Datenpunkt

Danke, damit wirds für mich klarer. Hab diesen Ansatz auch noch im Hinterkopf.

[Rene55]

@grrfield Erster Versuch ist gestartet:

19:57:39.036	error	script.js.common.Rollladen.RollControl: setHMStateSec hm-rpc.0.LEQ1439759.1.LEVEL no success after trial 5
javascript.2	2022-03-26 19:57:37.036	warn	script.js.common.Rollladen.RollControl: setHMStateSec hm-rpc.0.LEQ1439759.1.LEVEL trial 5
javascript.2	2022-03-26 19:57:35.036	warn	script.js.common.Rollladen.RollControl: setHMStateSec hm-rpc.0.LEQ1439759.1.LEVEL trial 4
javascript.2	2022-03-26 19:57:33.035	warn	script.js.common.Rollladen.RollControl: setHMStateSec hm-rpc.0.LEQ1439759.1.LEVEL trial 3
javascript.2	2022-03-26 19:57:31.035	warn	script.js.common.Rollladen.RollControl: setHMStateSec hm-rpc.0.LEQ1439759.1.LEVEL trial 2
javascript.2	2022-03-26 19:57:29.025	warn	script.js.common.Rollladen.RollControl: (f) setScheduler (6) wurde gesetzt auf (29 57 19 * * *)

Muss noch die Zeiten anpassen

[Rene55]

@grrfield Die Änderung mit deinem Script hat nichts verschlimmbessert. Wenn ich die Funktionsweise des Scripts richtig verstanden habe, wird das setState grundsätzlich verzögert ans Device gegeben. Somit wird der Logeintrag aus " 'setHMStateSec '+HM_id+' Success.' " wohl nie zu sehen sein.
BTW: Da dieser Fehler überwiegend bei meinen Rollladen auftritt und es da besonders ärgerlich ist, habe ich die Funktion in mein Rollladenscript eingebaut so dass es (@Homoran) nicht im global liegen muss. Ich werd dann weiter beobachten, ob es noch Seiteneffekte gibt, wenn mehrere Rollladen zeitlich recht zusammenliegend gefahren werden (i, _HMacksiID) .

[grrfield]

@homoran Ja das paßt - wenn Du die Funktion unter global speicherst, kannst Du sie aus jedem Skript heraus aufrufen und damit kritische HM-Devices ansteuern. Genau dafür ist global ja da - Funktionen, die ich in jedem Skript benötige, zu speichern.

[grrfield]

@rene55 Nein, der State wird in Zeile 22 sofort gesetzt. Dann wird in der setInterval-Schleife mit Verzögerung nachgeschaut, ob es geklappt hat. Wenn ja, wird 'Success.' ausgegeben, wenn nein, wird es wieder versucht. Du solltest also das 'Success' zu sehen bekommen. Vielleicht erstmal mit einem normalen Schalter versuchen.
Bei den Rolläden hast Du das gleich Problem wie bei der Heizungssteuerung. Die Rollos melden während der Fahrt mehrmals ihren Status - HM_ackwait muß daher größer gewählt werden als die Rollolaufzeit.

[Rene55]

@grrfield Tatsache, hatte ich übersehen. Klar, die Rollladen brauchen eine Weile, bis die ihre Position erreicht haben. Frage an den Fachmann: gibt es hier Beeinflussung, wenn zwei Rollläden gleichzeitig gefahren werden bezüglich i und _HMacksiID?

[grrfield]

@rene55 Da sollte es keine Beeinflussung geben, da die Variablen ja nur innerhalb der aktuellen Funktion gelten. Zwei Rollos gleichzeitig zu fahren ist aber problematisch, da die beiden sich gegenseitig stören, wenn sie ihre Position ständig übermitteln. Besser ist es da, eine Direktverknüpfung mit einem virtuellen CCU-Kanal anzulegen und diesen anzusprechen:

Das funktioniert eigentlich recht zuverlässig.

[Rene55]

@grrfield Ah, ok. Dass dann der Funkkanal stark belegt ist, ist schon klar. Kommt auch eigentlich nicht vor, da ich alle Rollladenaktoren etwas zeitversetzt fahre (außer bei einer morgens - hier ist ein großes Fenster mit geteilten Rollladen). Zu dem Hinweis mit den Direktverknüpfungen - davon habe ich gar keine Ahnung. Ich hab mich darauf versteift, alles im ioBroker zu machen. Somit hab ich die RaspberryMatic eigentlich nur zum funken. Ich schau es mir trotzdem mal näher an.

[grrfield]

@rene55 Der Vorteil ist auch, daß alle Rollos wirklich gleichzeitig und nicht nacheinander hoch- und runtergehen - sieht einfach besser aus!

[Rene55]

@grrfield Meinst Du grundsätzlich oder speziell bei einem Fenster? Ich persönlich finde es natürlicher, wenn in den verschiedenen Zimmern die Rollläden zu verschiedenen Zeiten rauf und runter gehen. Sieht dann nach außen auch nicht so vollautomatisiert aus. Dein Script läuft jetzt zur Probe und ich warte auf den nächsten "Gelegentlich-Fall". Daher erstmal als gelöst markiert.

[grrfield]

@rene55 Ich meinte alle Rollos, die in der Direktverknüpfung sind. Ich persönlich finde es schöner, wenn alle (zumindest in einem Raum) geleichzeitig arbeiten - ist aber Geschmackssache.