E-Mail Adresse für Protokolle in Item festlegen ?

[TorstenE]

Hallo Mitstreiter,

ich lasse mir z.B. in Rules Werte oder Statusmeldungen z.B. welcher IF-Zweig
gerade ausgeführt wird per E-Mail zusenden. Das ist einfacher als in den
Logs immer zu suchen.
Jetzt möchte ich diese E-Mail Adresse aber nicht im Quellcode der Rules
hinterlegen, sondern z.B. in einem Item. Damit kann ich die E-Mail
Adresse global verwalten.

Meine Frage:
Wo können solche Werte in OH hinterlegt werden. Bei einem "normalen"
String-Item habe ich keinen Default-Werte, den ich hinterlegen kann ?

Danke

Torsten

[udo1toni]

Der Default Wert aller Items ist immer NULL. Du kannst diesen Wert beim Starten von openHAB z.B. durch eine Persistence mit dem letzten bekannten Wert ersetzen lassen (restoreOnStartup), oder Du nutzt eine Rule, welche beim Starten des Systems einen festen Wert setzt.

[TorstenE]

Das bedeutet so eine Art Init-Rule setzt diese Werte beim Start, das reicht mir auch.

Danke

Torsten

[udo1toni]

Tipp an der Stelle:

Der Trigger System started wird auch bei Änderungen an der Datei ausgelöst (also für den Fall, dass die Rule in einer rules-Datei gespeichert ist). Es ist also (naja, eigentlich eh immer) sinnvoll, zu prüfen, ob das Item tatsächlich noch den Status NULL hat.

[TorstenE]

Hallo Udo,

nachfolgende Regel sollte also bei Systemstart UND beim Ändern dieser Datei ausgeführt werden.
Das tut sie aber nicht, bzw. der Wert kommt im Item nicht an.

Code: Alles auswählen

rule "E-Mail Adresse für Log-Mails"
    when
        System started
    then

        if (EmailServer_RulesMailEmpfaenger.state === NULL) {
            val success = EmailServer_RulesMailEmpfaenger.postUpdate("MeinEmailAdresse@schonwieder.du");
        }

    end

[Mclupo]

Das sollte etwa so aussehen

[TorstenE]

Hey Mclupo,

yes, so funktioniert es.
Wurde in OH 3 umgestellt.

https://www.openhab.org/docs/configurat ... d-triggers

Danke

Torsten

[udo1toni]

Nein, da hat sich für die normalen rein textbasierten DSL Rules gar nichts geändert.
Was allerdings komplett falsch ist, ist die Abfrage auf === NULL.

Die korrekte Rule in Textform:

Code: Alles auswählen

rule "E-Mail Adresse für Log-Mails"
when
    System started
then
    if(EmailServer_RulesMailEmpfaenger.state == NULL) {
        EmailServer_RulesMailEmpfaenger.postUpdate("MeinEmailAdresse@schonwieder.du")
    }
end

Die "bessere" Variante (ist natürlich Geschmackssache):

Code: Alles auswählen

rule "E-Mail Adresse für Log-Mails"
when
    System started
then
    if(EmailServer_RulesMailEmpfaenger.state != NULL)
        return;

    EmailServer_RulesMailEmpfaenger.postUpdate("MeinEmailAdresse@schonwieder.du")
end

So oder so wird aber nicht auf Identität geprüft (===), sondern auf Gleichheit.
Das Gegenbeispiel:

Code: Alles auswählen

if(myVar === null)

Hier ist der Vergleich auf Identität korrekt (und es gäbe auch eine Meldung darüber, dass == im Vergleich mit null ersetzt werden sollte).

NULL ist etwas anderes als null, === ist etwas anderes als ==.

[TorstenE]

Hallo Udo,

der VS Code hat mir "null" blau angezeigt wie "String", "Number", "var" ....
und "NULL" eben weiss. Deshalb hat es mich verwirrt, aber es funktioniert in der Zwischenzeit.

Danke

Torsten

[udo1toni]

Also:

Auf der einen Seite haben wir es mit Variablen zu tun. Das hat nichts mit openHAB zu tun (also zwingend...). Eine Variable kann uninitialisiert sein. Dann hat sie den Wert null. Das Problem dabei: wie soll man das darstellen, ohne einen möglichen Wert zu verlieren? Der Trick: die Variable ist eigentlich nur ein Zeiger auf eine bestimmte Speicherzelle, in der der Wert der Variablen gehalten wird. Der Zeiger wird dann "einfach" auf eine ganz bestimmte Adresse im Speicher verstellt. Der Vergleich mit === prüft nun nicht den in der Variablen gespeicherten Wert, sondern dieser Vergleich prüft, ob dieser Zeiger auf die Adresse verweist, welche per Definition die null ist.

Auf der anderen Seite haben wir Items. Ein Item hat immer einen Status. Wenn openHAB startet, hat jedes Item den Status NULL. Das ist aber ein anderes NULL und hat nichts mit dem null der Variablen zu tun. Ein weiterer mögliche Wert ist auch noch UNDEV. Und ganz wichtig (nehmen wir mal ein String Item): NULL ist nicht nur etwas anderes als null, NULL ist auch etwas anderes als "NULL".

Code: Alles auswählen

meinStringItem.postUpdate(NULL)   // Item hat keinen gültigen Zustand, es ist also "leer" (aber eben nicht "")
meinStringItem.postUpdate("NULL") // Item hält den Text "NULL"
meinStringItem.postUpdate(null)   // Nö, dat geht nich

Die Farbgebung in VSCode richtet sich nach ein paar "seltsamen" Regeln, aber gerade das mit blau und weiß ist einfach nur von der Großschreibung abhängig und erst mal kein Hinweis auf einen Fehler.