Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[fastfoot]

@psims Probiere mal so, Änderungen in den Zeilen 3, 13 und 16

var Text_Hilf;
 
on({id: "telegram.0.communicate.request"}, async function (){
    var command = getState("telegram.0.communicate.request").val;
    var user = command.substring(1, command.indexOf("]"));
    var AusgabeAenderung;
 
    command = command.substring(command.indexOf("]") + 1, command.length);
    
    if ((command == 'Schutz aktivieren') || (command =='Schutz deaktivieren')) {
        
        if (command == 'Schutz aktivieren'){
            await setStateAsync('0_userdata.0.Alarmanlage.Alarm_Zustand', true);
            AusgabeAenderung = 'ALARMANLAGE <b>AKTIVIERT</b>\n\n';
        } else {
            await setStateAsync('0_userdata.0.Alarmanlage.Alarm_Zustand', false);
            AusgabeAenderung = 'ALARMANLAGE <b>DEAKTIVIERT</b>\n\n';
        }
 
        sendTo('telegram', {
            user: user,
            text:   AusgabeAenderung +
                    '<b>Aktuelle Statusübersicht</b>\n' +
                    '------------------------------------------\n' +
                    'Alarmstatus: ' + TextAlarm(getState("0_userdata.0.Alarmanlage.Alarm_Zustand").val) + '\n' +
                    'Auslösung: ' + TextAlarm(getState("0_userdata.0.Alarmanlage.Alarm_Aktiv").val) + '\n' +
                    '------------------------------------------',
            parse_mode: 'HTML',
    });
    };   
});
 
function TextAlarm(zustandAlarm){
    Text_Hilf = 'nicht aktiv';
    if (zustandAlarm==true){
        Text_Hilf = 'aktiv';
    }
    return Text_Hilf
}

[AlCalzone]

Der korrekte Weg wären lokale Variablen für den Schutzzustand, die dann nur in den State gespeichert werden. Das getState kann man sich dann sparen und direkt die Variable verwenden.

setState gefolgt von getState missbraucht eine Datenbank als Variable. Das sorgt erstens für mehr Systemlast, und zweitens zu Verzögerung durch den Umweg über die Datenbank.

[fastfoot]

@alcalzone sagte in Problem mit getState():

Der korrekte Weg wären lokale Variablen für den Schutzzustand, die dann nur in den State gespeichert werden. Das getState kann man sich dann sparen und direkt die Variable verwenden.

setState gefolgt von getState missbraucht eine Datenbank als Variable. Das sorgt erstens für mehr Systemlast, und zweitens zu Verzögerung durch den Umweg über die Datenbank.

Eigentlich wollte ich das auch vorschlagen, dann kam mir aber der Gedanke, dass man mit der Variablen eigentlich nur den Zustand beschreibt, der nach dem setState() herrschen sollte, genau weiss man es nur nach getState(). Diesen 'Konflikt' konnte ich gerade nicht auflösen, also hatte ich es so belassen in meiner Lösung :-)

[ticaki]

Hab zwar noch nicht mit setStateAsync() rumgespielt, wenn die Nachricht jedoch den tatsächlichen Zustand widerspiegeln soll muß man auf Änderungen der beiden States reagieren.

Wenn innerhalb von setStateAsync() ein setState() aufgerufen wird, dass den wert auf "false" setzt, wird man es auf diesem Weg wohl nicht mitbekommen.

[AlCalzone]

@fastfoot sagte in Problem mit getState():

dass man mit der Variablen eigentlich nur den Zustand beschreibt, der nach dem setState() herrschen sollte

Hä? setState (und setStateAsync) schreibt den Wert, den du übergibst in die Datenbank. Wenn direkt danach mit dem Wert was gemacht werden soll, brauchst du ihn doch nicht wieder aus der Datenbank lesen. Du weißt den Wert doch schon.
Das ist wie als würde ich mir nen Notizzettel schreiben und selbst per Post schicken, um zu schauen was auf dem Notizzettel steht.

[fastfoot]

@alcalzone sagte in Problem mit getState():

Das ist wie als würde ich mir nen Notizzettel schreiben und selbst per Post schicken, um zu schauen was auf dem Notizzettel steht.

Es ist in der Analogie wohl eher so, als wenn ich einen Anderen bitte, etwas auf den Zettel zu schreiben und dann lese, ob der das auch richtig geschrieben hat :-)

[AlCalzone]

@fastfoot Ne, wenn dann bittest du den anderen, es vorzulesen. Ist aber auch egal, da du sicher davon ausgehen kannst, dass er es richtig macht, wenn das Skript nicht mit Fehler abstürzt.

Dennoch bleibe ich dabei: Es spricht nichts dagegen die Daten rausspeichern, um beim nächsten Skript-Start darauf zuzugreifen, oder von wo anders darauf zu reagieren.
Eine Datenbank als Variable zu missbrauchen ist Unsinn.

[ticaki]

@alcalzone

EDIT: Ups war garnicht an mich gerichtet... sry :)

Ich habe dir nicht widersprochen, sondern den Gedanken des Vorpostens weitergeführt.
Die Bestätigung das die Alarmanlage tatsächlich scharf geschaltet wurde ist durch ein "setStateAsync()" nicht zu verwirklichen. Dazu muß man auf Änderungen von '0_userdata.0.Alarmanlage.Alarm_Zustand' mit einem Delay reagieren um nicht doppelte Meldungen zu erhalten.

Das ist für den Fall nötig dass das Alarmsystem im Fehlerfall die Variable wieder auf false setzt. Ansonsten ist nach setzten des States dessen auslesen überflüssig.

@fastfoot
Das die Datenbank es richtig macht muß man einfach annehmen* und alle anderen "Fehler" findest du auf diese Art nicht. :)
*Wenn nicht wird viel viel mehr nicht funktionieren als nur das Skript g

[AlCalzone]

@ticaki Okay, für den Fall dass irgendwas als Reaktion auf das setStateAsync von außen den State wieder zurück setzt, kann es tatsächlich Sinn machen. Alarm_Aktiv auszulesen, kannst du in dem Beispiel nicht vermeiden, Alarm_Zustand hingegen schon.

Aber es ist dennoch nicht garantiert, dass bis zum Auslesen für die Nachricht die Reaktion schon erfolgt ist. Da Skripte parallel laufen, ist folgendes denkbar

• Skript A setzt State 1 auf true
• Skript B reagiert auf State 1 (macht was, kann ein paar ms dauern)
• Skript A liest State 1 wieder aus (true)
• Skript B ist fertig mit Reaktion und setzt State 1 auf false (zu spät)
• Skript A liest State 2 aus (true)
• Skript B setzt State 2 auf false (zu spät)
• Skript A versendet Meldung mit true, true, obwohl beide States false sind

In dem Fall wäre es vielleicht sinnvoller, Skript B reagieren zu lassen und die Meldung selbst zu senden (mit garantiert richtigen und aktuellen Daten)

[ticaki]

@alcalzone
Deshalb habe ich geschrieben auf Änderungen zu reagieren, also .on() zu verwenden. Ich widerspreche dir noch immer nicht, sondern bin deiner Meinung. :)

[PSims]

Hallo an euch und vielen Dank für die vielen Informationen.

@fastfoot
Deine vorgeschlagene Variante mit den verschiedenen Asynch-Parametern/ -Funktionen hatte ich auch ausprobiert. Jedoch hat sich der Zustand des Datenpunktes gar nicht mehr geändert, wenn ich diesen beschreiben wollte. Deshalb bin ich dann auf die Variante mit den lokalen Variablen umgeswitcht.

Somit wird nun am Anfang des Skriptes der aktuelle Zustand der Datenpunkte in eine lokale Variable geschrieben. Die ich dann im Skript weiter verwende. Das einzig "doofe" ist halt, dass ich diese dann im laufenden Skript mit verändern muss, da ich den aktuellen Zustand des Datenpunktes im laufenden Skript ja auch weiter benötige und über getState (aufgrund des Asynch-Problems) nicht nutzen kann.

Also hier ein Beispiel:

Hier werden die Werte am Anfang des Skriptes aus der Datenbank geholt bzw. in eine lokale Variable geschrieben:

    // Einlesen der Zustände der Alarmanlage
    STATE_ALARM_ZUSTAND = getState('0_userdata.0.Alarmanlage.Alarm_Zustand').val;
    STATE_ALARM_AKTIV = getState('0_userdata.0.Alarmanlage.Alarm_Aktiv').val;

Wenn jetzt innerhalb des Skriptes der Zustand des Datenpunktes geändert wird, ändere ich im Anschluss auch die lokale Variable, da ich diese ja im Nachhinein auch weiter nutze bzw. abfrage:

    // Setze Alarmzustand aktiv
    setState('0_userdata.0.Alarmanlage.Alarm_Zustand', true);
    STATE_ALARM_ZUSTAND = true;

Und hier wird die Variable dann nochmals genutzt bzw. abgefragt, bevor sie dann per Telegram verschickt wird:

    sendTo('telegram', {
        text:      '<b>Aktuelle Statusübersicht</b>\n' +
                    '------------------------------------------\n' +
                    'Alarmstatus: ' + TextAlarm(STATE_ALARM_ZUSTAND) + '\n' +
                    'Auslösung: ' + TextAlarm(STATE_ALARM_AKTIV) + '\n' +
                    '------------------------------------------',
        parse_mode: 'HTML',
    })

function TextAlarm(zustandAlarm){
    Text_Hilf = 'nicht aktiv';
    if (zustandAlarm==true){
        Text_Hilf = 'aktiv';
    }
    return Text_Hilf
}

Aus eurer Sicht wäre das nun die optimale und gleichzeitig auch ressourcenschonende Variante?

[ticaki]

@psims
Ich würde, um Fehler in Zukunft auszuschließen(späteres editieren), folgende Variante bevorzugen:

// Setze Alarmzustand aktiv
    STATE_ALARM_ZUSTAND = true;
    setState('0_userdata.0.Alarmanlage.Alarm_Zustand', STATE_ALARM_ZUSTAND);

Desweiteren würde ich innerhalb des If Blocks nur die Variable verändern und hinter diesem den State setzten.