DOIF ([device:reading] exists)??

roman1528 · 11 November 2015, 11:42:51

Moin.
Mein GDS wird mit

define at_gds_rereadcfg at +*01:00:00 get gds rereadcfg
aktualisiert und mit

define notify_gds_readalerts notify gds get gds alerts 103241000
werden die alerts für meine Region geholt.

Desweiteren wird mit

Code Auswählen

define doif_gds_alert DOIF ([gds:a_count] >= 1) (set gds_alert_dummy yes) DOELSE (set gds_alert_dummy no)
ein Dummy für die Alarmierung in FTUI gesetzt.

Nun ist es ja so, dass nicht immer alerst für meine Region vorhanden sind und DOIF gibt

Code Auswählen

2015.11.11 11:30:12 2: doif_gds_alert: reading does not exist: [gds:a_count]
aus.

Kann ich mit DOIF erst abfragen ob das Reading existiert?

Code Auswählen

define doif_gds_alert DOIF ([gds:a_count] [exists] and [gds:a_count] >= 1) (set gds_alert_dummy yes)........

Oder wie kann ich das am besten lösen?

Loredo · 24 November 2015, 15:38:57

Würde mich auch interessieren wie man die Fehlermeldungen ignorieren kann, dass ein bestimmtes Reading (gerade) nicht vorhanden ist...
Besser wäre natürlich, wenn das GDS Modul zumindest die Readings a_valid und a_count immer bereitstellen würde... vielleicht kann man sich mit einem userreading behelfen?

Wuppi68 · 24 November 2015, 15:59:12

mache doch nach dem define vom gds ein setreading(gds, a_count, "0")

dann gibt es das reading ja auch wirklich

Loredo · 24 November 2015, 16:19:59

bringt halt nix, wenn das gds Modul das Reading beim nächsten alert-Lauf wieder löscht.

frank · 24 November 2015, 16:35:57

bei einem anscheinend "langweiligen" notify gäbe es die situation erst gar nicht. kein reading => kein event => keine aktion.
aber doif wäre nicht doif, wenn das nicht mit doif funktioniert.

vermutlich ein paar fragezeichen (event-handling) spendieren.

Damian · 24 November 2015, 17:32:26

Zitat von: frank am 24 November 2015, 16:35:57
bei einem anscheinend "langweiligen" notify gäbe es die situation erst gar nicht. kein reading => kein event => keine aktion.
aber doif wäre nicht doif, wenn das nicht mit doif funktioniert.
vermutlich ein paar fragezeichen (event-handling) spendieren.

sollte so funktionieren:

Code Auswählen

define doif_gds_alert DOIF ([gds:?a_count] and [?gds:a_count] >= 1) (set gds_alert_dummy yes)........

Gruß

Damian

Loredo · 27 November 2015, 19:30:44

Danke, Damian.

Das funktioniert allerdings aus mehreren Gründen nicht:

1. Das GDS Modul scheint für jedes neu erstellte Reading ein eigenes Event zu erstellen (Single-Update). Zu der Zeit, wo a_valid ein Event erzeugt, gibt es a_count noch nicht.
Das führt dann leider dazu, dass ein DOIF erstmal auf "on" gesetzt wird und direkt danach wieder auf "off" (siehe mein Beispiel weiter unten).
--> das GDS Modul muss eigentlich ein Bulk-Update für alle Readings zusammen machen. Und natürlich wäre es klug die Readings a_count und a_valid nie zu löschen, sondern nur zu aktualisieren.
@betateilchen

2. Ich habe noch immer das Problem, dass [abc:?reading] bei mir nicht direkt mit einer Auswertung funktioniert und ich es immer mit einem "and [?abc:reading] eq "123"" kombinieren muss. Da funktionieren bei mir ne Menge Automationen seit einigen Wochen schon nicht mehr, weil ich es noch nicht geschafft habe alle ~50 (ineinander verschachtelten) DOIF daraufhin zu prüfen... als ich sie mal erstellt hatte gingen die alle wie vorgesehen (ich nutze DOIF auch extensiv dafür über cmdState Status-Dummys zu erstellen).

Hier ist der Anfang eines DOIF, welches ich erstellt habe, um später Nachrichten zu versenden und gleichzeitig eine Anzeige für Oberflächen zu haben.

Code Auswählen


define di_gds_alerts DOIF 
(
   [gds:?a_valid] == 1
)

DOELSEIF
(
   [gds:?a_valid] == 0 and
   [?gds:a_count] != 0
)

DOELSE


attr di_gds_alerts cmdState on|standby|off

Es funktioniert so allerdings nicht, weil eben die Events nicht alle zusammen kommen.
So wiederum funktioniert es einigermaßen, bringt aber natürlich die Fehler mit dem temporär fehlenden a_* Readings (oder eben dauerhaft, wenn mal gar keine Warnung vorliegt).

Code Auswählen


define di_gds_alerts DOIF 
(
   [gds:a_valid] == 1
)

DOELSEIF
(
   [gds:a_valid] == 0 and
   [gds:a_count] != 0
)

DOELSE


attr di_gds_alerts cmdState on|standby|off

EDIT:
Auch ne aktuelle Lösung ist nur auf a_count zu triggern - da gibt es a_valid schon:

Code Auswählen


define di_gds_alerts DOIF 
(
   [?gds:a_valid] == 1
   [gds:?a_count] != 0
)

DOELSEIF
(
   [?gds:a_valid] == 0 and
   [gds:?a_count] != 0
)

DOELSE


attr di_gds_alerts cmdState on|standby|off

In meiner Kopflogik würde ich aber zuerst auf a_valid prüfen und danach bei a_count schauen - naja

Loredo · 27 November 2015, 19:34:13

Zitat von: frank am 24 November 2015, 16:35:57
bei einem anscheinend "langweiligen" notify gäbe es die situation erst gar nicht. kein reading => kein event => keine aktion.

Notify ist dafür halt nur bedingt geeignet, weil a_valid auch 0 sein kann und a_count trotzdem >=1. Nämlich in dem Fall wenn es eine Vorabinfo gibt. Man möchte also immer beide Werte zusammen betrachten und für sowas ist DOIF dann eben gleich viel besser geeignet (siehe mein Beispiel oben

)

Loredo · 27 November 2015, 19:45:42

Zusatz:
Man muss derzeit auch noch ein "attr di_gds_alerts wait 2:2:2" setzen.
Ansonsten springt das DOIF kurz auf "off", weil das Löschen des a_count Readings offenbar ebenfalls ein Event auslöst und somit das DOIF triggert.

Damian · 27 November 2015, 19:48:47

Wenn ein Reading nicht vorhanden ist, dann wird kein Befehl ausgeführt, die Abarbeitung wird abgebrochen und es ändert sich kein Zustand des Moduls, alles andere halte ich nicht für sinnvoll.

Das einzige Problem, was ich sehe ist, dass diese Trigger als Fehler geloggt werden. Man könnte in diesem Fall einfach nur das Error-Reading zur Information für die Nachvollziehbarkeit füllen, aber keinen Log-Eintrag erzeugen.

Im Übrigen, da die Auswertung der Bedingung im DOIF-Modul vom Perl-Interpreter vorgenommen wird, wird bei AND-Verknüpfung der weitere Teil einer Bedingung nicht mehr überprüft, sobald der erste nicht wahr ist.

Gruß

Damian

Loredo · 27 November 2015, 19:50:37

Zitat von: Damian am 27 November 2015, 19:48:47
Wenn ein Reading nicht vorhanden ist, dann wird kein Befehl ausgeführt, die Abarbeitung wird abgebrochen und es ändert sich kein Zustand des Moduls, alles andere halte ich nicht für sinnvoll.

Nope, da gibts dann sowas im Log:

Code Auswählen



2015.11.27 19:13:11 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30097) line 1.
2015.11.27 19:13:23 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30176) line 1.
2015.11.27 19:13:45 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30242) line 1.
2015.11.27 19:14:23 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30389) line 1.
2015.11.27 19:15:33 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at (eval 30633) line 1.

Damian · 27 November 2015, 19:58:13

Zitat von: Loredo am 27 November 2015, 19:50:37

Nope, da gibts dann sowas im Log:

Code Auswählen Erweitern
2015.11.27 19:13:11 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30097) line 1. 2015.11.27 19:13:23 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30176) line 1. 2015.11.27 19:13:45 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30242) line 1. 2015.11.27 19:14:23 1: PERL WARNING: Argument "" isn't numeric in numeric ge (>=) at (eval 30389) line 1. 2015.11.27 19:15:33 1: PERL WARNING: Argument "" isn't numeric in numeric ne (!=) at (eval 30633) line 1.

Bei mir führt

Code Auswählen

DOIF ([bladevice:bla]>20 and [Trigger])(...)

zu einer Fehlermeldung

Zitatreading does not exist: [bladevice:bla]

und keiner Ausführung, wenn Trigger triggert.

Gruß

Damian

CoolTux · 27 November 2015, 20:14:13

Code Auswählen


userReadings alerts { ReadingsVal( "dwdWetterdienst", "a_valid", "0" ); }, alertsCount { ReadingsVal( "dwdWetterdienst", "a_count", "0",); }

So mach ich das.

Grüße

RidcuIIy · 11 Dezember 2015, 19:16:23

Hi,

ich möchte nochmal den Threadgrund aufgreifen:

ZitatDamian:Wenn ein Reading nicht vorhanden ist, dann wird kein Befehl ausgeführt, die Abarbeitung wird abgebrochen und es ändert sich kein Zustand des Moduls, alles andere halte ich nicht für sinnvoll.

Das kommt darauf an was man machen möchte. Ich fände es auch gut wenn ein Fehlen eines readings über DOIF abgefragt werden kann, das ist in diesem Fall absichtlich. Ich triggere einen Hauptschalter auf Presence lan-ping was eher schlecht funktioniert und möchte anstelle dessen über Modul FRITZBOX auslesen ob die Geräte eingeloggt sind. Hier wird ein Reading FritzBox:MacAdresse ausgegeben.
FRITZBOX löscht jedoch dieses Reading wenn die Endgeräte nicht mehr angemeldet sind.
Die Lösung per PRESENCE via Script über 99_myutils.pm kenne ich und würde diese im Notfall auch nutzen, fände jedoch eine Möglichkeit, DOIF auch zu triggern wenn ein Reading nicht vorhanden ist, in dieser und auch ein paar anderen Konstellationen nützlich da ich mir ein paar Zwischenschritte spare. DOIF wäre hier viel eleganter und würde meine Codeentropie senken

Gibt es da keine Lösung?

Laffer72 · 12 Dezember 2015, 12:51:42

Hallo,

ich gehe auch über die das Reading mit der MAC-Adresse mit dem FRITZBOX-Modul. Die Anwesenheit habe ich mit einem DOIF im Residents -Modul gesetzt, aber auch das Problem des fehlenden Readings bei Abwesenheit.
Ich habe das über ReadingProxy-Modul gelöst.

Code Auswählen

define HandyAnwesend readingsProxy Fritzbox:mac_xx_xx_xx_xx_xx_xx

Ist das Reading nicht vorhanden habe ich im state "inactive" stehen. Das DOIF frägt jetzt "HandyAnwesend" ab.

Hab ich jetzt schon länger im Gebrauch und funktioniert tadellos.

Hoffe ich konnt ein bisserl helfen

Reinhard