(Gelöst) Notify bzw. Sonos per Knopfdruck vorübergehend stilllegen

Begonnen von is2late, 01 Juli 2020, 15:20:20

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: Otto123 am 03 Juli 2020, 09:38:18
Stimmt, auch die Doku dazu liest sich genauso. Anders macht ja die Angabe einer Funktion wie sunset_abs() auch keinen Sinn. ;)
Sorry für mein zweifeln, man lernt ja eben immer wieder in solchen Diskussionen :) unbedingt probieren!
Na ja, als Rudi bei der damaligen Diskussion (mit jemand anderem, ich meine, es war eine feature-Anfrage) angemerkt hatte, das angefragte feature existiere bereits, weil man könne ja eine passende Uhrzeit zurückliefern kann, war ich auch erst irritiert, aber grade wegen dieser Irritation steht es eben jetzt auf meiner "ist ja interessant"-Liste ;D .
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

is2late

Guten Morgen,

ich als Anfänger kann gar nicht beurteilen, wie unübersichtlich eine Lösung in der Theorie ist.
Die von TomLee so konvenient angebotene und sehr gut kommentierte Lösung entsprach am ehesten meinem  bescheidenen Verständnishorizont (so war es ja auch wohl beabsichtigt, nachdem ich durch die zahlreichen angebotenen und verlinkten Varianten schon nicht mehr durchstieg) und ließ sich direkt nutzen.

Und was die Verschachtelung oä anbelangt: Ich halte immer den gesamten Lösungsweg mit allen Links fest und kann daher den Gedankengang zuverlässig nachvollziehen. Überdies nutze ich "sprechende" Namen für alle Devices, Notifys etc, was bislang gut als Erinnerungsstütze funktioniert hat.

Wenn mir jetzt noch jemand sagen kann, wie ich die Fehlermeldung wegen des immer wieder neu angelegten .....fhem "define NotifySchalterAT at +00:02:00............ wegbekomme (kann das "define MeineAT" im Code einfach weggelassen werden, wenn es einmal angelegt ist??), dann steht der Glückseligkeit nichts im Wege  ;)

Vielen Dank,
LG is2late
Pi4, Tahoma Jalousien, Hue, Echo, Sonos, Lupusec XT3, FritzBox

Beta-User

Zitat von: is2late am 03 Juli 2020, 10:02:34
Wenn mir jetzt noch jemand sagen kann, wie [...]
Sagen nicht, aber nochmal das Stichwort SCHREIBEN (in der Hoffnung, dass es gelesen wird...)
Zitat von: Beta-User am 02 Juli 2020, 17:56:38Ja. Es wird nicht angelegt oder verändert, weil es schon existiert.

Abhilfe (Stichwort für die SuFu): "defmod".
Zitat von: is2late am 03 Juli 2020, 10:02:34
Und was die Verschachtelung oä anbelangt: Ich halte immer den gesamten Lösungsweg mit allen Links fest und kann daher den Gedankengang zuverlässig nachvollziehen. Überdies nutze ich "sprechende" Namen für alle Devices, Notifys etc, was bislang gut als Erinnerungsstütze funktioniert hat.
Ich habe keine Ahnung, was mit "ich halte ..." gemeint sein könnte, aber den Verdacht, dass damit cfg-Editing umschrieben wird... (no comment!)

Jedenfalls: Es geht nicht alleine darum, dass DU weißt, was Sache ist, sondern NOTFALLS auch jemand anderes sich zurechtfindet, und der wird sich "bedanken", wenn du ständig solche Umwege gehst...

Hier wäre auch mit der "kurzen" Lösung ala binford6000 alles direkt in FHEMWEB so als verknüpft zu erkennen, dass JEDER halbwegs erfahrene FHEM-User (z.B. auch jeder eventuelle Helfer hier im Forum) auf Anhieb sieht, was Sache ist; er braucht nur zwei list oder den Blick auf dein FHEMWEB...

Aber jeder ist seines eigenen Glückes Schmied, und wer nicht will, hat eben gehabt. Ich werde jedenfalls niemanden helfen, der wider besseres Anraten auf so einem "von hinten durch die Brust ins Auge"-Weg weiterläuft, nur weil er ein kleines Problemchen beim Einstieg in die Perl-Syntax und der Adaption eines einfachen Grundgedankens an die eigenen Bedarfe hatte.

Viel Glück noch!
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

TomLee

Zitat von: TomLee l Readings darstellt.ink=topic=112595.msg1069254#msg1069254 date=1593620208
disabledForIntervals find ich aber eleganter, aber noch nicht ganz verstanden.

Aber jetzt. Das Problem war das ich mir kurzum irgendeinen Testdummy geschnappt hatte, der mit stateformat Text eines irgendwann mal definierten Readings formatiert hatte. STATE also gar nicht on sein konnte ( Value("dummy") eq "on" ) :o

Aber auch nach dem löschen von stateformat und dem auslösen des dummy auf on ist nicht direkt erkennbar das disabledForIntervals auch greift, man muss es anhand irgendeiner Aktion auch wirklich testen, das war etwas irritierend.
Hatte irgendwie erwartet dass das notify ein disable-Attribut in der Zeit bekommt ist aber nicht so und alles klappt genauso wie gleich vorgeschlagen.

Jetzt stellt sich mir die Frage wozu ein Eventmap für on-for-timer ?

Es klappt auch wie vorgesehen ohne eventMap dass das notify für die Zeit von on-for-timer disabled wird.
Folgender dummy zeigt den Zustand während eines on-for-timer, in STATE und auch state steht immer nur on bei aktivem on-for-timer

defmod dummy dummy
attr dummy devStateIcon .*:noIcon
attr dummy group Test1
attr dummy room Test
attr dummy setList on off
attr dummy useSetExtensions 1

setstate dummy on
setstate dummy 2020-07-03 15:17:39 state on





Zitat
(no comment!)

@is2late, wenn er Recht hat: aber in comment (dem Attribut ;D)

Zitatalles direkt in FHEMWEB so als verknüpft zu erkennen, dass JEDER halbwegs erfahrene FHEM-User (z.B. auch jeder eventuelle Helfer hier im Forum) auf Anhieb sieht, was Sache ist; er braucht nur zwei list oder den Blick auf dein FHEMWEB...

Na_ja, beim dummy mit Sicherheit nicht. Wenn ich mir den in FHEMWEB anschaue dann seh ich einen dummy mehr nicht, Probably associated with ist er mit keinem Device.
Und das list/Raw Defintion siehst ja oben.

Beta-User

Ja, Value(), da war doch was... (ich rate v.a. aus dem von dir genannten Grund eigentlich grundsätzlich davon ab, das überhaupt zu verwenden und habe es hier nur gemacht, weil der TE sowieso schon verwirrt genug war ::) ). Jetzt aber ausdrücklich an den TE: nimm' besser ReadingsVal() auf "state". Das ist eindeutig, selbst wenn du irgendwelche "Aufhübschungen" mit stateFormat machen solltest. (Man kann dann auch setExtensionEvent setzen, was ggf. laufende Timer in STATE visualisiert...).

Das mit der eventMap war nur ein Gedanke, falls es nur ein einziges klickbares Element geben soll und der dummy zwangsweise immer nach Zeitablauf off werden soll. Sonst würde ich eher zu "vollmanueller Bedienung" tendieren und weitere select-Buttons für unterschiedliche Dauern vorsehen ;D . (oder einen slider? *duckundweg*)



Was die Querbezüge angeht:
zumindest an dem notify könnte ausdrücklich was "associatedWith" stehen, wenn nicht, sieht man es m.e. trotzdem mit hinreichender Gewissheit im list des notify. Wer mag, kann ja das Reading "associatedWith" auch manuell setzen, dann hat man das von beiden Enden aus ;) . Und wer ggf. configDB nutzt  ;) , kann sowieso auch ein "configdb search %dummy-name%" machen, dann bekommt man auch sowas "frei Haus" raus, ganz ohne "comment" oder ausdrückliches "associatedWith"...
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