Falsche Zustandsanzeige nach Neustart

[Heavy-Dee]

Hallo zusammen,

Ich betreibe mein OH2 System auf einer Synology DiskStation und habe div Sonoff u. Shelly Switches implementiert. Soweit funktioniert auch alles.
Jetzt ist mir aufgefallen das nach einem Neustart der OH2 Anwendung oder bei einer Änderung der aktuelle Zustand der Icons nicht richtig angezeigt wird.

Status.PNG

Zwar sind die Schaltestellungen korrekt aber die entsprechenden Icons nicht.

Die items sind wie folgt aufgesetzt:

Code: Alles auswählen

// Sonoff
Switch Sonoff_810E6E "Stehlampe [(Wohnzimmer)]"     <light>         (grpHomeNet,grpHaus,grpEG,grpWohnzimmer,grpLicht)       {mqtt=">[broker:cmnd/Sonoff_810E6E/POWER:command:*:default], <[broker:stat/Sonoff_810E6E/POWER:state:default]" }    //Stehlampe, Wohnzimmer 
Switch Sonoff_00750A "Schrankwand [(Wohnzimmer)]"   <light>         (grpHomeNet,grpHaus,grpEG,grpWohnzimmer,grpLicht)       {mqtt=">[broker:cmnd/Sonoff_00750A/POWER:command:*:default], <[broker:stat/Sonoff_00750A/POWER:state:default]" }    //Schrank, Wohnzimmer 
Switch Sonoff_A80CC5 "Sideboard [(Esszimmer)]"      <light>         (grpHomeNet,grpHaus,grpEG,grpEsszimmer,grpLicht)        {mqtt=">[broker:cmnd/Sonoff_A80CC5/POWER:command:*:default], <[broker:stat/Sonoff_A80CC5/POWER:state:default]" }    //Sideboard, Esszimmer 

// Shelly
Switch Shelly1_2C68B6 "Esstisch [(Esszimmer)]"      <light>         (grpHomeNet,grpHaus,grpEG,grpEsszimmer,grpLicht)        {mqtt=">[broker:cmnd/Shelly1_2C68B6/POWER:command:*:default], <[broker:stat/Shelly1_2C68B6/POWER:state:default]" }  //Esstisch, Esszimmer 
Switch Shelly1_259ED4 "Arbeitsplatte [(Küche)]"     <light>         (grpHomeNet,grpHaus,grpEG,grpKueche,grpLicht)           {mqtt=">[broker:cmnd/Shelly1_259ED4/POWER:command:*:default], <[broker:stat/Shelly1_259ED4/POWER:state:default]" }  //Arbeitsplatte, Küche 

und in der sitemap:

Code: Alles auswählen

    Frame label="Lichtschalter"
    {
        // Stehlampe (Wohnzimmer)
        Switch item=Sonoff_810E6E
        // Schrank (Wohnzimmer)
        Switch item=Sonoff_00750A   
        // Essisch(Esszimmer)
        Switch item=Shelly1_2C68B6 
        // Sideboard (Esszimmer) 
        Switch item=Sonoff_A80CC5
        // Arbeitsplatte, (Küche)          
        Switch item=Shelly1_259ED4 
    }

wäre nett wenn mir jemand nen Tipp geben könnte.
DANKE

[seppy]

Hi,
wie schnell nach einem Neustart schaust Du denn? Bei mir braucht das System einen Schaltvorgang und dann passt alles.
Grüße,
Seppy

[udo1toni]

Der Status wird über das Topic stat/%topic%/POWER nur beim Schaltvorgang gemeldet. Man kann bei Einsatz von mqtt1 zusätzlich noch tele/%topic%/STATE verwenden (das ist ein JSON Objekt, muss also noch entsprechend verarbeitet werden). Dieses Topic wird dann zumindest alle x Minuten automatisch gesendet und entsprechend von openHAB empfangen.
Man könnte auch eine Art Startup Script anlegen, welches die Status aller MQTT Channel beim Initialisieren abruft, jedenfalls tut openHAB das nicht selbsttätig.

[peter-pan]

Das gleiche Phänomen habe(hatte) ich auch beim Neustart von OH. Deshalb habe ich mir alle meine Sonoff-Switches(nur das Switch-item) in eine Gruppe gepackt und in der mapDB ein Persist für die Switches angelegt.

Code: Alles auswählen

  gSonoff*                    : strategy = everyChange, restoreOnStartup

Das soll man ja eigentlich für "echte" Items nicht machen, weil die Daten ja aus dem Channel kommen. Aber das dauert ja etwas (Standard ist glaube ich 300 Sek.), wie @udo1toni beschrieben hat. Das könnte halt evtl. kritisch werden z. B. bei einem Stromausfall und dein Switch dann OFF bleiben soll, der letzte Zustand aber ON war.

Das kann man ja aber nach dem Test, wenn das System läuft, wieder auskommentieren.

[Heavy-Dee]

Danke euch !
Ich habe gedacht es gäbe eine einfache Möglichkeit beim öffnen einer Sitemap den Status aller Items abzufragen um den ISTzustand angezeigt zu bekommen.
Ich glaube ich werde mal versuchen das StartupScript umzusetzen.

[udo1toni]

Ich habe gedacht es gäbe eine einfache Möglichkeit beim öffnen einer Sitemap den Status aller Items abzufragen um den ISTzustand angezeigt zu bekommen.

Das hat nichts mit der Sitemap zu tun.
Der Status eines jeden Items wird intern in openHAB gehalten.
Jede Änderung eines Items wird dabei von openHAB gespeichert.
Damit der Zustand nach dem Start des Systems auch den Tatsachen entspricht, muss jedes Binding aktiv alle Status auf dem zugehörigen Bus abfragen.
Z.B. in knx kann man das auhc so konfigurieren, andere Bindings machen das automatisch.
Bei MQTT ist ein entsprechender Mechanismus nicht implementiert, man muss also aktiv für jeden Channel den Status erfragen (das geht über ein entsprechendes Topic, wie alle anderen Befehle auch).
Um das in openHAB zu automatisieren, braucht es eine Rule, die auf System started triggert. In der Rule verwendet man entweder die mqtt action oder man legt entsprechende Items an, über die man jedem Item den Befehl zum Senden des Status schicken kann, z.B. so:

Code: Alles auswählen

Switch Sonoff1SendStatus { mqtt="broker:cmnd/Sonoff1/POWER:*:NULL" }

Wobei ich gerade nicht sicher bin, ob die Angabe NULL für "nix" stimmt. Jedenfalls sollte openHAB dann mit

Code: Alles auswählen

stat/Sonoff1/POWER ON/OFF

antworten.

[Heavy-Dee]

...das werde ich mir heute Abend mal genauer ansehen.
Ich melde mic wieder.
Besten DANK

[peter-pan]

Hallo zusammen,
und Danke dir @udo1toni für die Hinweise wie man es richtig machen soll. Ich bin ja ein grosser "Fan" deiner Beiträge, sowohl hier, als auch im internationalen Forum und habe mir da schon einiges abgeschaut. Leider bin ich halt kein IT-Informatiker oder Programmierer und hab aber sowas von überhaupt keiner Ahnung von Java oder den Script-Sprachen, deshalb geht bei mir das meiste über "Schnipselklau" und Trial and Error.

Ich hab mich mal hingesetzt und versucht das ganze in eine Rule zu packen. Das hat dann bei mir aber eine ganze Weile gedauert (aber als Rentner hab ich ja Zeit) und das ist dabei rausgekommen:

Code: Alles auswählen

var Timer sonoffState = null
//val sonoff_device_ids = newArrayList(
//    "basic_03"
//)

val sonoff_device_ids = newArrayList("sonoffs")

rule "Sonoff Status Request"
when
    Item Dummy4 changed to ON or  // Test
    System started
then
    logInfo("sonoff-state.rules", "Sonoff State Request previousState: " + previousState)  // Test
    logInfo("sonoff-state.rules", "Sonoff State triggeringItem: " + triggeringItem )  // Test
//    logInfo("sonoff-state.rules", "Sonoff State receivedEvent: " + receivedEvent)  // Test -> funktioniert nicht
    logInfo("sonoff-state.rules", "Sonoff State sonoffState: " + sonoffState)  // Test
    sonoffState?.cancel
    sonoffState = createTimer(now.plusSeconds(60), [|
      for (String device_id : sonoff_device_ids) {
          publish("peter", "cmnd/" + device_id + "/POWER", "?")
          logInfo("sonoff-state.rules", "Status : " + device_id + "Timer Status: " + sonoffState)  // Test
      }
   ])
end

... natürlich auch abgekupfert , von dir (sonoffState?.cancel) und von einem Beitrag von ThomDietrich.

Ich habe den Persist in der mapDB herausgenommen und in die Rule das GroupTopic "sonoffs" genommen. Anstelle von NULL als Payload(?) habe ich das Fragezeichen eingesetzt, ich meine, das mal irgendwo gelesen zu haben.

Ich weiss auch nicht genau ob " sonoffState?.cancel" so richtig ist. Das ist doch so etwas Ähnliches wie ein "if" mit "return;" Die ganzen logInfos und der Test-Schalter müssen natürlich nicht sein.

Was meinst du dazu ? Kann man das so benutzen oder gibt es da noch das ein oder andere zu verbessern ?

Gruss - Peter

EDIT: Die Regel benutzt MQTT 1.x

[udo1toni]

Code: Alles auswählen

sonoffState?.cancel

und

Code: Alles auswählen

if (sonoffState !== null) sonoffState.cancel

sind gleichbedeutend. Hier geht es darum, den Timer zu canceln, falls er existiert.
Der Timer schiebt den Vorgang um eine Minute in die Zukunft, das ist nur für den Fall, dass die Items noch nicht fertig initialisiert sind (da ist eine Minute schon reichlich, egal welche Plattform)

Code: Alles auswählen

for (String device_id : sonoff_device_ids) {

diese For-Schleife durchläuft alle in der Liste sonoff_device_ids eingetragenen Strings. Das Problem ist, Du hast das Array oben auskommentiert. Ebenfalls nicht so schön ist, dass man, um das ganze zu nutzen, für jedes Item einen Eintrag im Array anlegen muss, womit die Konfiguration an zwei verschiedenen Stellen geschieht. Falls man die Items nach dem Schema *_deviceId_* vornimmt, könnte man alle Items, die getriggert werden sollen, in eine Gruppe packen, also z.B. so:

Code: Alles auswählen

Group mqttTrigger
Switch mqtt_basic01_power "Basic 01 [%s]" (mqttTrigger) { mqtt=">[broker:cmnd/basic01/POWER:comand:*:default], <[broker:stat/basic01/POWER:state:default]" }
Switch mqtt_basic02_power "Basic 02 [%s]" (mqttTrigger) { mqtt=">[broker:cmnd/basic02/POWER:comand:*:default], <[broker:stat/basic02/POWER:state:default]" }
Switch mqtt_myswitchab_power "My Switch AB [%s]" (mqttTrigger) { mqtt=">[broker:cmnd/myswitchab/POWER:comand:*:default], <[broker:stat/myswitchab/POWER:state:default]" }

Rule:

Code: Alles auswählen

var Timer tMqttState = null

rule "initial mqtt state"
when
    System started
then
    tMqttState?.cancel
    logInfo("initialState","Initializing Timer")
    tMqttState = createTimer(now.plusSeconds(20),[|
        logInfo("initialState","Timer ended. Initializing Items")
        mqttTrigger.members.filter[m|m.state == NULL].forEach[i|
            logInfo("initialState","Initializing {}",i.name)
            publish("peter", "cmnd/" + i.name.split("_").get(1) + "/POWER", "?")
        ]
    ])
end

Die Rule wird beim Trigger System started getriggert und erstellt einen Timer, der nach 20 Sekunden abläuft.
Läuft der Timer ab, durchläuft der Code alle Member der Gruppe mqttTrigger, die nicht initialisiert sind. Für jeden dieser Items wird aus dem Namen der Teil zwischne ersten und zweiten Unterstrich als Teil des Topics gesetzt und das Kommando verschickt, welches das Statusupdate erzwingt.

publish ist eine mqtt Action, das muss getrennt vom eigentlichen mqtt Binding installiert werden.

PS: Ob das ? an dieser Stelle das Richtige ist, weiß ich aber auch nicht.

[peter-pan]

Hallo @udo1toni,

Danke für die Erläuterungen zu

von udo1toni » 30. Jan 2019 19:12

sonoffState?.cancel
und
if (sonoffState !== null) sonoffState.cancel

sind gleichbedeutend. Hier geht es darum, den Timer zu canceln, falls er existiert.
Der Timer schiebt den Vorgang um eine Minute in die Zukunft, das ist nur für den Fall, dass die Items noch nicht fertig initialisiert sind (da ist eine Minute schon reichlich, egal welche Plattform)

Deine Rule hab' ich auch schon ausprobiert. Hat auf Anhieb geklappt. Leider hat hat sie nicht alle meine Sonoffs gefunden. Das liegt aber daran, dass ich beim Anlegen meiner Items (Namen) und meiner Tasmota-Topics nicht ganz so strukturiert vorgegangen bin. Das muss ich für solche Zwecke noch nachbessern. Aber hier wird schön gezeigt, wie man mit der Group-Item Methode arbeiten kann.

Noch eine Frage zu split und get: Sind das auch Methoden/Funktionen zu einem Objekt ?
Hast du vielleicht auch noch einen Link, wo man das vielleicht auch noch (für den Laien verständlich) nachlesen kann ? (Bitte nicht xtend,xtext, das ist mir noch etwas zu abstrakt).

Danke auf jeden Fall für deine Unterstützung.

Gruss - Peter

P.S. zum "?" habe ich noch eine kleine Randnotiz von Theo Arends gefunden:

Code: Alles auswählen

Side Note: For many commands, an empty payload is a query. 
If you are using mosquitto_pub, you can issue an empty payload using the -n command line option. 
If your MQTT client cannot issue an empty payload, you can use the single character "?" instead.

https://github.com/arendst/Sonoff-Tasmo ... management