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
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
Zitat von: Damian schrieb am Di, 08 Oktober 2013 20:44Und 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:
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>
Hallo Martin,
Zitatwarum 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
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
Hallo Martin,
ich habe bereits einen Thread im Automatisationsforum dazu geöffnet.
Alles Weitere sollte dann dort geklärt werden.
Gruß
Damian