[suche Idee] devStateIcon für notify active/disabled

Begonnen von betateilchen, 24 Februar 2015, 20:54:19

Vorheriges Thema - Nächstes Thema

betateilchen

Hat jemand eine Idee, wie man einem notify ein devStateIcon zuweisen kann, um optisch darzustellen, ob ein notify enabled/disbled ist?

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

wenn dir langoll updates erst mal egal sind geht das z.b. so:attr n devStateIcon disabled:off .*:on   

oder
attr <n> devStateIcon {return ".*:off" if( AttrVal($name,"disable",0) == 1); return ".*:on"}

bzw. entsprechend über IsDisabled statt AttrVal wenn du disabledForIntervalls auch auswerten willst.

wenn du wert auf longpollUpdates legst würde es vermutlich über den umweg eines zweiten notify auf die attribut änderung das über Trigger ein gefaktes event für das nicht vorhandene state reading erzeugt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

Zitat von: justme1968 am 24 Februar 2015, 21:14:14
wenn dir langoll updates erst mal egal sind geht das z.b. so:

da wird mir genau gar nichts angezeigt - egal in welchem Zustand das Attribut ist.

Zitat von: justme1968 am 24 Februar 2015, 21:14:14
wenn du wert auf longpollUpdates legst würde es vermutlich über den umweg

Es geht um longpoll und ich wollte einen Umweg vermeiden. Es wäre schon schön, wenn ein notify auch ein auswertbares "state" hätte.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

#3
da muss etwas angezeigt werden. ich habe beide versionen mit safari, chrome und firefox probiert.

was bedeutet gar nichts? auch nicht der text für STATE?


mit dem angehängten patch und der ersten variante:attr n devStateIcon disabled:off .*:ongeht es (beim mir :) )auch per longpoll. keine ahnung ob rudi die umstellung von STATE auf state einchecken würde.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

Der Text bei STATE ist vorhanden, aber ich sehe nirgends ein Icon.

Den Patch werde ich testen, aber erst morgen. Bis dahin erstmal danke für die Hilfe.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

#5
mit dem Patch funktioniert es
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zu früh gefreut. Das funktioniert nur solange, bis das notify zum ersten Mal getriggert wurde.

Irgendwas stimmt da mit "showtime" noch nicht, denn irgendwann steht nur noch ein Timestamp in der Anzeige - egal, ob showtime auf 0 oder auf 1 steht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

es gibt für showtime eine sonderbehandlung in 01_FHEMWEB.pm. sobald das attribut bei einem device gesetzt ist wird devStateIcon komplett ignoriert und immer der timestamp des state reading angezeigt.

wenn das attribut showTime im notify komplett gelöscht ist dann geht es. sobald es gesetzt ist (egal ob auf 0 oder 1) greift die sonderbehandlung.

ich denke diese sonderbehandlung sollte eigentlich entfernt werden. oder zumindest die prüfung sollte nicht auf defined sondern auf attribut = 1 gehen:--- 01_FHEMWEB.pm (revision 8085)
+++ 01_FHEMWEB.pm (working copy)
@@ -2420,7 +2420,7 @@
   my $txt = $state;
   my $dsi = ($attr{$d} && ($attr{$d}{stateFormat} || $attr{$d}{devStateIcon}));

-  if(defined(AttrVal($d, "showtime", undef))) {
+  if(AttrVal($d, "showtime", undef) == 1) {
     my $v = $defs{$d}{READINGS}{state}{TIME};
     $txt = $v if(defined($v));

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Die showtime Zeile in FHEMWEB habe ich angepasst.

Mit dem notfy-patch hadere ich noch:
- ich will nicht, dass ein notify events generiert, das wird mir zu bunt.
- showtime sollte mAn in FHEMWEB und nicht im Geraet ausgewertet werden.
- die disabled/active Anzeige in notify funktioniert nur fuer disabled, disabledForIntervals wird nicht behandelt.
- ich meine das, was jetzt funktioniert, muesste fuer die ueblichen Faelle reichen.

betateilchen

Zitat von: rudolfkoenig am 25 Februar 2015, 07:26:31
- ich meine das, was jetzt funktioniert, muesste fuer die ueblichen Faelle reichen.

Ist es ein sehr unüblicher Fall, im Frontend sehen zu wollen, ob ein notify active oder disabled ist, wenn man es per Button/Link im Frontend einfach toggeln kann?

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Wenn du per button toggelst, dann kannst du ja auch den button beobachten.

justme1968

es wäre schön dafür direkt das Icon des notify zu verwenden. ohne zusätzlichen dummy. und für at genau so.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

betateilchen

Zitat von: justme1968 am 25 Februar 2015, 09:35:00
es wäre schön dafür direkt das Icon des notify zu verwenden.

Genau darum geht es. Den Button in meinem Frontend kann ich nicht beobachten, da fhem diesen Button gar nicht kennt, sondern nur das Icon des notify.

Zitat von: rudolfkoenig am 25 Februar 2015, 07:26:31
Mit dem notfy-patch hadere ich noch:
- ich will nicht, dass ein notify events generiert, das wird mir zu bunt.

Dieses Anliegen verstehe ich durchaus. Könnte man das Erzeugen eines events nicht irgendwie mit dem ohnehin schon verbundenen Attribut "addStateEvent" verknüpfen, sodaß ein event nur dann erzeugt wird, wenn dieses Attribut auf 1 gesetzt ist? Das Attribut wurde zwar zu einem anderen Zweck eingeführt (das ist mir schon klar) aber es passt zum einen wunderbar von seinem Namen her und zum anderen würde diese Verknüpfung nirgends "wehtun".

Nach dem gleichen Ansinnen beim at zu fragen, hatte ich mich noch gar nicht getraut, zumal mir die Sache bei den notify wichtiger ist. Aber es ist schön, dass das nun auch schon angesprochen wurde 8)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

justme1968

das addStateEvent attribut bezieht sich auf die auswertung der events des vom notify überwachten device, nicht auf das notify selber. von daher passt eine verknüpfung nicht wirklich.

ich glaube nicht das die zusätzlichen events wirklich ins gewicht fallen. wenn man direkt im notify modul schon prüft und das reading schreibt wenn es sich geändert hat wird für den fall das showtime nicht gesetzt ist nur beim umschalten von disable ein einziges event erzeugt.

um das icon auch bei disabledForIntervalls aktuell zu halten habe ich noch keine gute idee. es wäre aber auch schön.

natürlich sollte es dann auch für at eingebaut werden :). je weniger ausnahmen es gibt um so besser. der einbau von modifyTimeSpec geht ja auch in die richtung eine bedienung ohne zusätzliche dummys zu ermöglichen.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Habe fuer at/notify die gewuenschten Events eingebaut, allerdings generiert notify kein Event, falls es getriggert wird.
D.h. fuer "attr X disable" wird ein Event generiert, aber auch fuer at, nach der Ausfuehrung.

betateilchen

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Irgendwer/-was überschreibt mir immer noch den STATE in einem notify mit einem Timestamp, was dazu führt, dass das devStateIcon nicht funktioniert.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Ich konkretisiere das Problem: Nach einem fhem Neustart zeigt das notify kein devStateIcon an, obwohl während des Startens ein "attr <device> disable 0" gesetzt wird.

Temporär habe ich dadurch Abhilfe geschaffen, dass ich per notify auf global:INITIALIZED das Attribut einfach nochmal setze - dann stimmt plötzlich das Icon. Aber schön ist dieser Workaround nicht.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Du musst es noch mehr konkretisieren (== define + alle attr + Vorgang), da bei mir folgendes ein restart ueberlebt:

define n notify a { Log 1, "$NAME $EVENT" }
attr n devStateIcon active:dog_silhouette disabled:scene_sleeping
attr n disable 1

betateilchen

Es ist ein showTime Problem.

Ich verstehe einfach die Logik nicht, dass ich in JEDEM Device (in einer Liste von devices, die ein notify auslösen können) das Attribut setzen muss, anstatt einfach im notify selbst die Möglichkeit zu haben, die Timestamp Anzeige abzuschalten. Wenn ich in einem notify KEINEN Timestamp sehen möchte, dann bezieht sich das definitiv auf das notify selbst und hat für mich nichts damit zu tun, welches Device auch immer das notify auslöst.

Wehe, man vergisst, das Attribut auch nur bei einem einzigen Device zu setzen...

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Da ich keine andere Möglichkeit gefunden habe, das Problem in den Griff zu bekommen, habe ich jetzt die 91_notify.pm geändert:


      $ntfy->{STATE} =
        AttrVal($ln,'showtime',0) ? $dev->{NTFY_TRIGGERTIME} : 'active';


In AttrVal() den default auf 0 gesetzt anstatt wie bisher auf 1 - und schon ist Ruhe. Damit umgehe ich den Zwang, ein Attribut gesetzt haben zu müssen - und das dann auch noch auf 0.


-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

ZitatIch verstehe einfach die Logik nicht, dass ich in JEDEM Device (in einer Liste von devices, die ein notify auslösen können) das Attribut setzen muss

Das sollte nicht der Fall sein, und ich kann das auch nicht nachvollziehen.
Kannst du mir bitte zeigen, wie man das Problem reproduziert?

betateilchen

Zitat von: rudolfkoenig am 11 März 2015, 07:07:38
Das sollte nicht der Fall sein, und ich kann das auch nicht nachvollziehen.

Nachvollziehen läßt sich das doch ganz einfach im Coding von 91_notify.pm, dort steht im Original:

$ntfy->{STATE} =
        AttrVal($ln,'showtime',1) ? $dev->{NTFY_TRIGGERTIME} : 'active';


Daraus ergibt sich doch zwangsläufig, dass ein Timestamp immer dann in den STATE von notify geschrieben wenn


  • das attribut showtime im auslösenden device auf 1 steht
  • das attribut showtime im auslösenden device überhaupt nicht vorhanden ist

Und genau der zweite Punkt ist das Problem: Ein Timestamp wird nämlich nur dann nicht nach STATE geschrieben, wenn ein auslösendes device das attribut showtime besitzt UND dieses attribut auf 0 steht. Dieses Problem verschärft sich mit der Anzahl der devices, die ein bestimmtes notify triggern können.

Durch meine Änderung, den default-Wert in AttrVal() auf 0 statt auf 1 zu setzen, habe ich für mich das Problem nun zuverlässig gelöst.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitatdas attribut showtime im auslösenden device auf 1 steht

Das ist natuerlich falsch interpretiert. $ln ist nicht das ausloesende device, sondern das notify selbst.

betateilchen

Also muss das Attribut doch im notify selbst gesetzt werden?
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Ja, das finde ich auch intuitiv. Und wieso "doch"?

betateilchen

Zitat von: rudolfkoenig am 11 März 2015, 11:38:40
Und wieso "doch"?

Weil ich irgendwie im Rahmen einer bereits neulich geführten Diskussion zu showtime im Hinterkopf behalten habe, dass showtime vom auslösenden Device (dessen Triggertime ja wohl auch verwendet wird) gesteuert würde.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!