Knoten im Hirn: Frage zu "[?..." resp. Automatik/Manuell - Betrieb

Begonnen von M_I_B, 10 Januar 2018, 08:55:44

Vorheriges Thema - Nächstes Thema

M_I_B

Moin Kinnaz,

ich habe da mal wieder ein Beißholz, was ich nicht klein bekomme ^^

Folgende Situation:
Deckenventilator am (modifiziert; induktive Last) HM Dimmer (HM-LC-DIM2L-SM), Tasten zur manuellen Steuerung (HM-PB-6-WM55), DOIF mit diversen Bedingungen, wie z.B. Ventilator an wenn Öffnung Thermostatventile (HM-CC-RT-DN) größer 10% oder wenn Kamin an (Erkennung durch HM-WDS30-OT2-SM). der ganze Trum sieht dann im Moment (Snapshot) so aus:

## Ventilator anschmeißen bei Heizung und/oder Ofen
define set_311_vt DOIF ([HM2TH1_12:temperature] < 10 and [HM6TH01_4:ValvePosition] > 20 and [HM6TH01_4:ValvePosition] < 50) (set HM2DI1_2 50) \
DOELSEIF ([HM2TH1_12:temperature] < 10 and [HM6TH01_4:ValvePosition] > 50) (set HM2DI1_2 100) \
DOELSEIF ([HM2TH1_12:temperature] > 50) (set HM2DI1_2 100) \
DOELSE (set HM2DI1_2 0)
attr set_311_vt do always

# WZ Ventilator (HM-LC-DIM2L-SM, Kanal 2)
define set_311v_ta DOIF ([HM6TA2_4:?Short.*]) (set HM2DI1_2 100) DOELSEIF ([HM6TA2_3:?Short.*]) (set HM2DI1_2 0) \
DOELSEIF ([HM6TA2_4:?Long.*]) (set HM2DI1_2 up) DOELSEIF ([HM6TA2_3:?Long.*]) (set HM2DI1_2 down)
attr set_311v_ta do always


Anm: Devicebezeichnungen bei mir sind ...
2 Buchstaben Typ + 1 Ziffer Anzahl Kanäle + zwei Buchstaben Art des Devices + Index + _Kanal. Im Beispiel also HM2DI1_2 = "HM"- Device, "2" Kanäle, "DI"mmer Nummer "1", Kanal _"2"



Bei der ganzen Nummer habe ich aber ein Problem, welches sich dahingehend äußert, das eine manuelle Änderung über die Taster alsbald überschrieben wird, sobald ein Event von z.B. dem Thermostatventil aufschlägt. Das wollte ich nun dadurch beseitigen, das ich bei einige Abfragen den Event durch ein vorangestelltes "?" unterdrücke, also nur abfrage. Aber genau da beißt sich die Katze in'n Schwanz, da dann die Automatik wirkungslos wird...
Mit anderen Worten: Wenn ich das o.g. z.B. durch einen Dummy erweitere, der das Betätigen einer Taste zum Einleiten des manuellen Modus speichert und in dem Fall die Automatik ausser Betrieb setzt, muss ich ja irgendwie irgendwann man wieder auf den automatischen Modus zurück kommen... Und dieses Problem habe ich nicht nur beim VentiLenti, sondern überall dort, wo automatisch UND manuell auf ein Device zugegriffen werden soll, wie z.B. alle Leuchtmittel...

Ich benötige also ein paar Denkanstöße resp. Hinweise, wie Ihr solch eine Sache gelöst habt

Beta-User

Du könntest in der Ventilator-Automatik abfragen, ob innerhalb einer Zeit x eine der beiden Tasten gedrückt wurde. Ginge jeweils mit einer ReadingsAge-Abfrage.

Dann ist mir nicht so recht klar, warum du den Dimmer-Aktor nicht direkt mit dem Tasterpaar peerst. Würde auch dann funktionieren, wenn FHEM mal versehentlich nicht läuft und außerdem vermutlich die Reaktionszeit zwischen den Dimm-Befehlen und der Drehzahländerung drastisch verkürzen ;) .

Viel Erfolg, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

M_I_B

... das mit dem direkten Peeren hatte ich noch gelassen, weil an vielen Stellen noch nicht klar ist, ob das so bleibt oder sich was an der Hardware ändert. Aber Du hast natürlich recht bezgl. Latenz und Redundanz. Bei dem Monster von VentiLenti fällt das auf Grund der Trägheit nicht auf, aber bei ähnlich gebauten Lichtsteuerungen merkt man das schon...

ReadingAge? Is mir noch nicht unter gekommen. Wie muss ich das verstehen? Ist das Ergebnis einer entsprechenden Abfrage ein Sekundenwert, wann das betreffende Reading letztmalig geändert wurde und ist das ein fortlaufender Zähler (nebst Überlauf auf 0) oder an der Realzeit festgemacht?

Beta-User

ReadingsAge findet sich in der Commandref bei den Perl-Specials:
ZitatReadingsAge(<devicename>,<reading>,<defaultvalue>)
gibt das Alter des Readings in Sekunden zurück.
Ergo: Es muß etwas perl-Code in das DOIF rein...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

M_I_B

... ja, schon gefunden. Aber es ist leider nicht dargelegt, wie die Zeit berechnet wird, also auf Basis eines Zählers (mit ggf. Überlauf nach x Sekunden) oder auf Basis der Realzeit. Das dürfte m.E. eine entscheidende Rolle bei Tageswechseln o.ä. spielen ...

Beta-User

Soweit erkennbar, gibt es keinen Überauf oä..
Dürfte aber leicht rauszufinden sein: einfach ein Reading suchen, das schon länger (einige Tage) unverändert ist, den entsprechenden Perl-Code in geschweiften Klammern in die Eingabezeile tippen und nachsehen, was als Ergebnis angezeigt wird ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

M_I_B

... Feldforschung ;D Mache ich mal heute Abend. Mal sehen, ob ich damit meine Sorgen lösen kann ...

Per


Damian

zyklisch sendende Sensoren und do always verbietet sich eigentlich von selbst.
Man kann neuerdings auch diesen Spagat mit Hilfe von DOIF_Readings meistern, wie das geht steht hier: https://fhem.de/commandref_DE.html#DOIF_Readings
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

M_I_B

... sagst Du so einfach ;) Ohne DoAlways hat das irgendwie nicht wollen. Aber da ich sowieso gerade am Umstricken bin, werde ich mir das zu Herzen nehmen und darauf achten; bin ja lernfähig ;)

BTW: Irgendwie konnte man doch auf den Trigger mehrerer Devices gleichzeitig reagieren? Ich komme grade nicht drauf, weiß aber, das es geht...

Im Bedingungsteil möchte ich ...
([ECO02:?opened] or [ECO03:?opened] or [ECO04:?opened])
... irgendwie zusammenfassen ala ...
([ECO0[2|3|4]:?opened])
Dat geit aBär so net; das war irgendwie anders... (scheiß Alzheimer ^^) War da irgendwie RegEx im Spiel?

Damian

Zunächst solltest du auf die aktuelle Syntax deine Definitionen umstellen. ? ist nicht mehr aktuell für Regex-Abfragen.

Wahrscheinlich meinst du so etwas:

["^ECO0(2|3|4):opened"]
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

M_I_B

... ja genau, das war's !  ::) Danke Dir!

Was meinst Du mit aktueller Syntax? Z.B. das "?" vor "opened"?

Damian

Zitat von: M_I_B am 10 Januar 2018, 21:04:25
... ja genau, das war's !  ::) Danke Dir!

Was meinst Du mit aktueller Syntax? Z.B. das "?" vor "opened"?

Noch das Gleiche, wie in Anführungszeichen: [<device>:?<Regex>] entspricht noch [<device>:"<Regex>"]

Irgendwann fliegt die alte Syntax raus, weil es mit [?<device>...] nicht konform ist. Dieses Fragezeichen hat ganz andere Bedeutung, das weißt du aber bestimmt schon.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

M_I_B

... ah ok, das kann ich nachvollziehen. Wie viel Zeit habe ich denn, das alles zu korrigieren? Das steckt nämlich überall mit drin...

Damian

Zitat von: M_I_B am 10 Januar 2018, 21:16:56
... ah ok, das kann ich nachvollziehen. Wie viel Zeit habe ich denn, das alles zu korrigieren? Das steckt nämlich überall mit drin...

Dass man es nicht mehr nutzen sollte, steht schon ziemlich lange in der Commandref. Noch bleibt es drin, du solltest aber zumindest die neuen Definitionen schon mit der aktuellen Syntax definieren.
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF