Problem mit set_off bzw set_on im state

[Damian]

Hallo Martin,

hat es eine besondere Bewandtnis, dass bei HM_Aktoren zunächst set_on bzw. set_off gesetzt wird, bevor der eigentliche Zustand on bzw. off nach dem acknowledge kommt?

Es hat nämlich z. B. in Kombination mit structure erhebliche Nebeneffekte, denn dort führt jede Zustandsänderung zu weiteren Ereignissen. Filtern nach bestimmten Zuständen ist nicht vorgesehen. Das hat zur Folge, dass immer für paar Millisekunden sich der Zustand ändert, bis der eigentliche dann tatsächlich gesetzt wird. Und wenn man darüber z. B. eine Heizung steuert, die für paar Millisekunden an und aus geht, dann kann das auf die Dauer nicht gut sein. Das Attribut event-on-update-reading hilft da natürlich nicht weiter, weil die kurzfristige Zustandsänderung von z. B. set_on auf on damit nicht abgefangen werden kann.

Gibt es evtl. bereits eine Möglichkeit das Setzen des Zwischenzustands: set_on bzw. set_off abzustellen?

Gruß

Damian

[martinp876]

Hallo Damian,

das set_ hat schon eine Bewandtnis. wenn man HM nutzt  (nicht jeder aber einige) dann will man "etwas mehr sicherheit" der Werte haben. damit meine ich , dass HM im gegensatz zu anderen Familien Rückmeldungen über den aktuellen Zustand liefert.
wenn du nun ein Kommando absendest glaubst/erwartest du, dass der switch seinen Zustand ändert. Wissen kannst du es aber erst, wenn der Switch es bestätigt.
Sollte der Switch nicht antworten dann ist nicht klar ob er geschaltet hat oder nicht.

set_ ist also IMMER ein zustand gleichzusetzen mit ??? - nur eben mit einer Tendenz.

nein, abschalten kann man das nicht - das set_ ist an mehrere Stellen eingebaut - beim lichtschalter nur einmal, klar aber auch bei register ,...

Ich würde liegen sehen, wenn sich structure darum kümmert  - und den Zustand als "uncertain" einstuft.

warum du es bei einer heizungssteuerung nicht abfangen kannst verstehe ich nicht. Kannst du nicht alle set_ ignorieren wenn sie dich nicht interessieren?

Gruss Martin

[fritz]

Und wenn man darüber z. B. eine Heizung steuert, die für paar Millisekunden an und aus geht, dann kann das auf die Dauer nicht gut sein.

In meiner Heizungssteuerung findet sich deshalb:

Code Auswählen Erweitern

   if ($status ne $next && $status ne "set_$next") {
        Log 4, "controlHeizung($self): set $actor $next";
        fhem ("set $actor $next");
    }Codebeispiel (muss ich erläutern, welche Werte auf welchen Variablen stehen?)

Als Anregung (und bitte die set_-Zustände behalten, das ist korrekt so)

<F>

[Damian]

Hallo Martin,

warum du es bei einer heizungssteuerung nicht abfangen kannst verstehe ich nicht. Kannst du nicht alle set_ ignorieren wenn sie dich nicht interessieren?

Es ist die falsche Frage, es müsste eher heißen warum es structure nicht kann;)

Hier nochmal die Konstellation zum Verständnis:

Definiert wurde die structure mit dem Namen H_Switches (H_Bad, H_Dachgeschoss ... sind HM-Switche)

define H_Switches structure CUL_HM H_Bad H_Dachgeschoss H_Kueche H_Keller H_Kinderzimmer_o H_Kinderzimmer_w H_Kinderzimmer_o H_Wohnzimmer

attr H_Switches clientstate_behavior relative
attr H_Switches clientstate_priority on off

bedeutet: sobald ein Schalter auf on geht, soll die structure auf on gehen und wenn alle Schalter auf off sind, ist die structure off

Dann gibt es ein notify zum Schalten der Therme

define Heizung_trigger notify H_Switches:o.* set Therme %


So nun wird H_Bad auf on geschaltet:

hier die dazugehörigen Events:

Events:
2013-10-09 15:55:39.721 FS20 Therme off
2013-10-09 15:55:39.740 structure H_Switches LastDevice: H_Bad
2013-10-09 15:55:39.740 structure H_Switches LastDevice_Abs: H_Bad
2013-10-09 15:55:39.740 structure H_Switches off
2013-10-09 15:55:39.749 CUL_HM H_Bad set_on
2013-10-09 15:55:40.163 FS20 Therme on
2013-10-09 15:55:40.180 structure H_Switches LastDevice: H_Bad
2013-10-09 15:55:40.180 structure H_Switches LastDevice_Abs: H_Bad
2013-10-09 15:55:40.180 structure H_Switches on
2013-10-09 15:55:40.191 CUL_HM H_Bad level: 100 %
2013-10-09 15:55:40.191 CUL_HM H_Bad deviceMsg: on (to HMLAN)
2013-10-09 15:55:40.191 CUL_HM H_Bad on

hier überholen sich die Nachrichten offenbar wegen unterschiedlicher Verarbeitungsgeschwindigheiten.

Tatsache ist, dass aufgrund von H_Bad set_on  H_Switches kurz auf off geht und dann bei H_Bad on erst auf on und damit geht die Therme erst einmal für ca. eine halbe Sekunde auf off und dann erst auf on.

An diese Stelle helfen auch keine gutgemeinten Vorschläge zum Filtern oder irgendwelchen If-Abfragen, weil der Anwender hier nicht dazwischen kommt.

Wenn also auf der HM-Seite keine Änderung erfolgt, müsste zwangsläufig structure angepasst werden, damit sie sinnvoll mit HM-Komponenten umgehen kann.

Ich werde die Problematik nochmal im Automatisationsforum posten. Mal schauen was die Anderen dazu sagen.

Gruß

Damian

[martinp876]

Hallo Damian,

das lese ich wie einen klaren Fehler in Structure


clientstate_priority
If clientstate_behavior is set to relative, then you have to set the attribute "clientstate_priority" with all states of the defined devices to this structure in descending order. Each group is delemited by space. Each entry of one group is delimited by "pipe". The status represented by the structure is the first entry of each group. Example:

    attr kitchen clientstate_behavior relative
    attr kitchen clientstate_priority An|On|on Aus|Off|off
    attr house clientstate_priority Any_On|An All_Off|Aus

ich würde erwarten, dass structur ungültige werte verwirft (set_on  und set_off). lese ich das falsch? Das solltest du bei Structure einklagen.

Alternativ - wie ist es mit
attr H_Switches clientstate_priority set_on|on set_off|off

sollte das  nicht auch gehen?

sorry, muss mir structure erst genauer ansehen - vielleicht verstehe ich etwas falsch.

Gruss Martin

[Damian]

Hallo Martin,

ich habe bereits einen Thread im Automatisationsforum dazu geöffnet.

Alles Weitere sollte dann dort geklärt werden.

Gruß

Damian