UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[haus-automatisierung]

@skorpil sagte in XML-RPC fault - Fehler abfangen?:

geht das auch außerhalb von blocky mit einem normalen Java Skript?

Klar, da Blockly einfach nur JavaScript generiert :)

https://github.com/ioBroker/ioBroker.javascript/blob/master/docs/en/javascript.md#onlog

[skorpil]

@haus-automatisierung ich werde mich daran mal versuchen und meine Lösung hier zeigen

[skorpil]

mit Hilfe von KI habe ich folgendes Script zum erneuten Senden des Schaltbefehls (max. 3 mal, jeweils nach 5 sec) erstellt, wenn ein Kommunikationsfehler auftritt. Jetzt muß ich abwarten und sehen, wie es reagiert

// Warteschlange zur Speicherung der Schaltbefehl-Meldungen
let setValueQueue = [];

// Verwenden der onLog-Anweisung, um Logmeldungen zu überwachen
onLog('error', function (obj) {
    const logMessage = obj.message;
    const source = obj.from;

    // Überprüfen, ob die Quelle 'hm-rpc.1' ist
    if (source === 'hm-rpc.1') {

        // Prüfen, ob die Logmeldung ein Schaltbefehl ist
        if (logMessage.includes('xmlrpc -> setValue')) {
            // Schaltbefehl in die Warteschlange speichern
            setValueQueue.push({ message: logMessage });
        }

        // Prüfen, ob die Logmeldung ein Kommunikationsfehler ist
        if (logMessage.includes('Cannot call setValue: XML-RPC fault: Generic error (TIMEOUT)')) {
            // Prüfen, ob es einen gespeicherten Schaltbefehl gibt, der zu diesem Fehler passt
            if (setValueQueue.length > 0) {
                // Die älteste Schaltbefehl-Meldung aus der Warteschlange holen
                const lastSetValueLogEntry = setValueQueue.shift();

                // Extrahiere die Gerätedaten aus dem Schaltbefehl
                const match = lastSetValueLogEntry.message.match(/xmlrpc -> setValue \["(.+?):(\d+)","(.+?)",(true|false)\] BOOL/);

                if (match) {
                    const deviceAddress = match[1]; // Adresse des Geräts
                    const channel = match[2]; // Kanal des Geräts
                    const stateName = match[3]; // Zustandsname (z.B. "STATE")
                    const value = match[4] === 'true'; // Wert, den der Zustand annehmen soll

                    // Befehl mit Verzögerung und Wiederholungslogik senden
                    sendCommandWithRetry(deviceAddress, channel, stateName, value, 3);
                }
            } else {
                log('Kein zugehöriger Schaltbefehl für den Kommunikationsfehler gefunden.', 'warn');
            }
        }
    }
});

// Funktion, um den Schaltbefehl mit Wiederholungslogik zu senden
function sendCommandWithRetry(deviceAddress, channel, stateName, value, retries) {
    const stateId = `hm-rpc.1.${deviceAddress}:${channel}.${stateName}`;

    const attemptToSendCommand = (remainingRetries) => {
        // Befehl senden
        setState(stateId, value, false, (err) => {
            if (err) {
                log(`Fehler beim Senden des Befehls für ${stateId}: ${err}`, 'error');

                if (remainingRetries > 0) {
                    log(`Wiederhole den Befehl in 5 Sekunden (${remainingRetries} Versuche verbleibend).`);
                    // Erneut versuchen, nachdem eine Verzögerung von 5 Sekunden abgewartet wurde
                    setTimeout(() => attemptToSendCommand(remainingRetries - 1), 5000); // 5000 ms = 5 Sekunden
                } else {
                    log(`Maximale Anzahl an Wiederholungen erreicht für ${stateId}. Befehl wird nicht erneut gesendet.`, 'error');
                }
            } else {
                log(`Befehl erfolgreich gesendet für ${stateId}`);
            }
        });
    };

    // Erste Ausführung des Befehls
    attemptToSendCommand(retries);
}

[paul53]

@skorpil sagte: kann ich den Fehler gegebenenfalls mit einem Skript abfangen?

Ich gehe mal davon aus, dass es immer wieder die gleichen Aktoren betrifft und der Adapter bei Kommunikationsstörung den betreffenden Wert nicht bestätigt (ack = false). Dann kann man bei nicht bestätigter Änderung eine Wiederholung anstoßen, die bei Bestätigung des Wertes abgebrochen wird.
Skript für einen Aktor mit Wiederholung nach 1 s und 5 s:

const idAktor = 'hm-rpc.1.00021D89A1B3E0.3.STATE';

var soll = getState(idAktor).val;
var timer1 = null;
var timer5 = null;

on({id: idAktor}, function(dp) {
    if(dp.state.ack) {
        if(dp.state.val == soll) {
            clearTimeout(timer1);
            clearTimeout(timer5);
        }
    } else if(dp.state.val != soll) {
        soll = dp.state.val;
        timer1 = setTimeout(function() {setState(idAktor, soll);}, 1000);
        timer5 = setTimeout(function() {setState(idAktor, soll);}, 5000);
    }
});

[skorpil]

@paul53 ja, es sind immer wieder meine homematic IP Geräte. Keine Ahnung, warum! Das ist ein guter Vorschlag, ich werde auch diese Variante prüfen. Dankeschön.

[skorpil]

@paul53 ich würde Dein Script gerne "generalisieren". Hier mal mein Versuch:

// Funktion, um relevante STATE-IDs im hm-rpc.1-Adapter zu ermitteln
function getRelevantDeviceIds() {
    const ids = [];
    const states = $('state[id=hm-rpc.1.*.STATE]'); // Verwenden von Selektoren, um alle STATE-IDs zu finden

    states.each(function (id, i) {
        // Prüfen, ob die STATE-ID den Kanal 3 oder 4 betrifft
        const parts = id.split('.');
        const channel = parts[parts.length - 2];  // Extrahiere die Kanalnummer
        if (channel === '3' || channel === '4') {
            ids.push(id);
        }
    });

    return ids;
}

// Hauptfunktion, um für alle relevanten Geräte-IDs das Skript zu implementieren
function setupListeners() {
    const deviceIds = getRelevantDeviceIds();

    // Einmalige Auflistung der relevanten STATE-IDs beim Start des Skripts
    log('Relevante STATE-IDs im Adapter hm-rpc.1:', 'info');
    deviceIds.forEach(id => log(id, 'info'));

    log('Anzahl der überwachten Geräte: ' + deviceIds.length, 'info');  // Log für die Anzahl der Geräte

    deviceIds.forEach(idAktor => {
        var soll = getState(idAktor).val;
        log('Initialer Soll-Wert für ' + idAktor + ': ' + soll, 'debug');  // Debug-Log für den initialen Soll-Wert

        var timer1 = null;
        var timer5 = null;

        // Ereignislistener für Zustandsänderungen des Gerätes
        on({id: idAktor}, function(dp) {
            log('Zustandsänderung bei ' + idAktor + ': ' + dp.state.val, 'debug');  // Debug-Log für Zustandsänderungen

            if (dp.state.ack) {
                if (dp.state.val == soll) {
                    log('Zustand bestätigt und entspricht dem Soll-Wert bei ' + idAktor, 'debug');  // Debug-Log bei bestätigtem Zustand
                    clearTimeout(timer1);
                    clearTimeout(timer5);
                }
            } else if (dp.state.val != soll) {
                log('Neuer Soll-Wert für ' + idAktor + ': ' + dp.state.val, 'debug');  // Debug-Log für neuen Soll-Wert
                soll = dp.state.val;
                timer1 = setTimeout(function() { 
                    setState(idAktor, soll); 
                    log('Soll-Wert nach 1 Sekunde gesetzt bei ' + idAktor + ': ' + soll, 'debug');  // Debug-Log nach 1 Sekunde
                }, 1000);
                timer5 = setTimeout(function() { 
                    setState(idAktor, soll); 
                    log('Soll-Wert nach 5 Sekunden gesetzt bei ' + idAktor + ': ' + soll, 'debug');  // Debug-Log nach 5 Sekunden
                }, 5000);
            }
        });
    });
}

// Skriptausführung starten
setupListeners();

Ich habe allerdings festgestellt, daß sich bei HMIP Zwischensteckern der relevante State im Kanal 3 findet, bei den HMIP Lichtschaltern im Kanal 4. Fällt Dir irgendeine Möglichkeit ein, im IObroker die für die Schaltung relevanten Kanäle zu ermitteln? Dummerweise gibt es auch in anderen Kanälen "States".Z.B. beim Zwischenstecker in Kanal 4. So dass "States" nicht trennscharf sind.

Der Einfachheit halber kann man natürlich alle States in Kanal 3 und 4 überwachen. Aber bei HMIP Lichtschaltern ist das ja nicht relevant, obwohl es eben da einen state gibt.

Ideal wäre es, nur die States zu überwachen, die wirklich relevant sind.

[Homoran]

@skorpil HmIP arbeitet mit virtuellen Kanälen!
der jeweils erste in dem der State vorkommt dient nur der Anzeige des Gesamtergebnisses der Verknüpfungen der anderen virtuellen Kanäle.
nur diese lassen sich auch steuern

[skorpil]

@homoran Dankeschön. Und welchen muss ich dann steuern? (denn ich vermute, dass mein Problem mit den Fehlermeldungen vielleicht damit zusammen hängt, dass ich den falschen Kanal steuere?)

[Homoran]

@skorpil sagte in XML-RPC fault - Fehler abfangen?:

Und welchen muss ich dann steuern?

kommt auf deine Konfiguration an.
so kannst du beim Dimmer z.b. an einem Kanal normal dimmen, am anderen Kanal einen "Faktor" einstellen, so dass es nachts nicht gar so hell wird.

[peterfido]

@skorpil Was hast Du als HMIP Zentrale, und wie ist das Netzwerk dahin aufgebaut?

Der oben genannte Workaround mit dem Prüfen nach einer Sekunde kann helfen, wäre dann aber nicht die Beseitigung der Ursache.

Wenn das instabil läuft, könntest Du alle Sollwerte unter 0_userdata nochmal abbilden und per Skript regelmäßig schauen, ob Ist=Soll und wenn nicht, dann nochmal den Wert setzen. Bleibt allerdings eine Krücke.

[skorpil]

@peterfido Dankeschön. Ich habe als Zentrale eine Raspberrymatic. Und unter rpc.1 läuft hmip. Unter nicht reproduzierbaren Umständen, in unregelmäßigen Abständen habe ich dann immer wieder Kommunikationsfehler. Der iobroker läuft unter Debian in VirtualDub (hervorragend!)

Mir ist bewusst, dass das alles Workarounds sind und die Ursache nicht beseitigt wird. Aber dazu müsste ich ja erst mal die Ursache erkennen.