Zutrittssteuerung - Wiegand to FHEM

Begonnen von nugat1, 15 September 2015, 22:43:27

Vorheriges Thema - Nächstes Thema

FrankieSOC

Hey Benni,

mit Hilfe deines Schaltplanes habe ich diesen RFID Reader https://www.i-keys.de/de/zutrittskontrollsysteme/leser-fuer-controller/mifare/a58m-mini.html aufgebaut und mit ESPEasy bekomme ich die Tags in Fhem angezeigt. Danke!

Leider weiß ich nun nicht weiter, wie ich mit den Daten intern arbeiten kann. Ziel ist es:
RFID bekannt -> Keymatic aufschließen
RFID unbekannt -> nichts

Das Abschließen habe ich über eine Anwesenheitskontrolle gemacht. Ich niemand mehr im Umkreis X Meter, wird nach 5 Min abgeschlossen.

Hast du einen Tipp für mich, wie du das mit deinen Fingerabdrücken in FHEM handhabst?

Viele Grüße
Frank

Benni

Leider bin ich bisher noch nicht dazu gekommen, das hier mal noch zu veröffentlichen.  :-[

Ich werde schauen, dass ich meine Lösung mal noch dieses WE zusammenschreibe und hier poste.

FrankieSOC

das wäre toll  :D

Mein doif will nicht so richtig klappen...
([ESPEasy_Eingang_Wiegand] eq "Tag: XXXX") (set HM_535E4E open)

Es funktioniert immer nur einmal, erst nachdem ich einen falschen Code benutzt habe, klappt es wieder.

Viele Grüße  ;)

HeikoE



Zitat von: FrankieSOC am 13 Oktober 2017, 17:41:06
das wäre toll  :D

Mein doif will nicht so richtig klappen...
([ESPEasy_Eingang_Wiegand] eq "Tag: XXXX") (set HM_535E4E open)

Es funktioniert immer nur einmal, erst nachdem ich einen falschen Code benutzt habe, klappt es wieder.

Viele Grüße  ;)

Hallo FrankieSOC,
BEI DOIF gibt's ein Attribut 'do always'. Bin kein DOIF Experte, aber vielleicht hilft das.
Gruß Heiko

Benni


FrankieSOC

Benni, da bin ich drauf gespannt.  8)

Das mit dem do always werde ich trotzdem mal testen.

Benni

#36
Also, trotz des herrlichen sommerlichen Wetters am vergangenen Wochenende, hatte ich doch die Zeit, meine Schlüsselverwaltung für die Präsentation hier zusammenzuschreiben:

Ein paar Dummies, ein (!) notify (und kein DOIF ;D), etwas Perl-Code mehr ist nicht nötig!

Zutrittsteuerung - Tag (Schlüssel) -  Behandlung in FHEM

Wie weiter oben beschrieben ist meine Wiegand-Zuttrittsteuerung so eingerichtet, dass ich für jeden Finger (erst mal egal von welcher Person) einen separaten Tag erhalte.
Dazu ist in meinen Sebury F2-2 jeder Finger (oder auch RFID-Tag) quasi als eigene Person hinterlegt. Hintergrund ist, dass ich mit jedem Finger prinzipiell unterschiedliche aktionen durführen können möchte.
Weiterhin ist es so, dass ich nicht nur einen F2-2 im Einsatz habe, sondern derzeit 2 Stück, nämlich einen an der Haupteingangstür und einen an der Kellereingangstür. Demnächst kommt vllt. sogar noch ein 3. am Garagentor dazu.

Um eine Zuordnung für mögliche Einfache Abschaltungen einzelner Schlüssel, bzw. Zuordnung von Aktionen zu haben, habe ich mir über Dummies (ich weiß "Wieso so viele Dummies ;) ) einige logische Devices, bzw. Device-Gruppen eingerichtet.
Diese Device-Gruppen beschreibe ich im folgenden:

Schlüssel/Tag-Devices (Tag):

Für jeden Tag (egal ob RFID oder Fingerprint) habe ich mir ein entsprechendes logisches Tag-Device angelegt:

Beispieldefinition Tag:


define tagBenni.LZF dummy
attr tagBenni.LZF userattr tagid tagowner tagmapping:textField-long
attr tagBenni.LZF devStateIcon on:ios-on-green off:ios-off
attr tagBenni.LZF group Key
attr tagBenni.LZF icon access_keypad_1
attr tagBenni.LZF room Zutritt
attr tagBenni.LZF setList on off
attr tagBenni.LZF tagid 1234
attr tagBenni.LZF tagmapping espdHaustuer:OpenHaustuer
espdKellertuer:ToggleKellertuer
attr tagBenni.LZF tagowner ownBenni
attr tagBenni.LZF webCmd :


Das Tag-Device bekommt, wie man oben sieht folgende user-Attribute (userattr):

   - tagid         = die Tag-ID, die auch vom ESPEasy-Device geliefert wird.
   - tagowner      = Name des zugeordneten Schlüsselbesitzers (s.u.)
   - tagmapping   = Aktionszuordnung (Erklärung folgt ganz unten)

Innerhalb dieses Tag-Devices wird angegeben, welchem Owner er zugeordnet ist (tagowner) und welche Aktion für welche Türstation ausgeführt werden soll, wenn der Tag (tagid) genutzt wird (tagmapping).
Die anderen tag-Attribute sind eher von informativem als funktionalem Charakter und sind denke ich selbsterklärend, bzw. wird deren Verwendung ggf. später im Code noch ersichtlich.

Der Status des Device bestimmt dann ob der Schlüssel aktiv (on) oder inaktiv (off) ist.

Schlüssel-Besitzer-Devices (KeyOwner):

Ein Schlüssel (Key=Tag) muss bei mir immer genau einem Schlüsselbesitzer zugeordnet sein.
Dafür gibt es diese Device-Klasse.

Beispieldefinition KeyOwner:


define ownBenni dummy
attr ownBenni userattr ownerName
attr ownBenni devStateIcon on:ios-on-green .*:ios-off
attr ownBenni group KeyOwner
attr ownBenni icon user_unknown
attr ownBenni ownerName Benni
attr ownBenni room Zutritt
attr ownBenni setList on off
attr ownBenni webCmd :


Das Schlüsselbesitzer-Device bekommte folgendes User-Attribut (userattr):

   - ownerName = Ein (beliebiger) Name für den Schlüsselbesitzer

Der state (on/off) bestimmt dann, ob der Schlüsselbesitzer aktiv (on) oder inaktiv (off) ist.
Wichtig, damit der Schlüsselbesitzer als solcher auch erkannt wird ist eben, dass das Attribut ownerName auch mit einem Wert belegt ist (Der Wert selbst ist dabei grundsätzlich unerheblich).

Was erreiche ich damit:

    - Übersichtlickeit über die einzelnen definierten Schlüssel, deren Besitzer
    - Übesichtlichkeit über den Zustand der einzelnen Schlüssel (aktiv/inaktiv)

    Ich kann nun also bspw. jeden Schlüssel einzeln aktivieren oder deaktiviern.
    Ebenso kann eich einen Schlüsselbesitzer aktivieren oder deaktivieren, damit sind dann
    auch gleichzeitig alle, ihm zugeordneten Schlüssel entsprechend aktiv oder inaktiv.
    Und ich kann je nach dem an welcher Türstation welcher Schlüssel eingesetzt wird, unterschiedlich auf diesen reagieren.

   Ich kann auch relativ Bequem eine zeitliche Steuerung für die einzelnen Schlüssel oder Schlüsselbesitzer einrichten (einfaches at).
   So kann ich bspw. die Fingerabdrücke für meine Urlaubs-Blumenversorger genau für den Zeitraum des Urlaubs aktivieren.
   Oder ich mache die Wirksamkeit von Schlüsseln von der Anwesenheit abhängig, oder, oder, oder ....

Man könnte sich noch überlegen, ob man auch logische Devices für die einzelnen Türstationen einrichten will.
Ich habe mir das aber gespart. Ich kann bei mir direkt die Stromversorgung zu den einzelnen F2-2 physikalisch schalten und somit bei Bedarf einzelne oder alle Türstationen deaktivieren.

Wie das ganze nun im Detail funktioniert im Folgenden:

Ich habe für jeden meiner Sebury F2-2 einen eigenen ESP der über ESPEasy angebunden ist (s. Beschreibung im Post weiter oben).
Wird nun ein Tag gesendet, so wird von diesen Device u.a. ein Event für das Reading tag erzeugt (so ist das in der ESP-Konfiguration benannt. siehe im Post weiter oben)
Dieses Event wird von einem Notify aufgefangen:

Meine ESPEasy-Devices sind dazu, wie bereits in der Tag-Definition im tagmapping zu sehen, wie folgt benannt:

    - espdHaustuer
    - espdKellertuer

Somit komme ich für beide mit einem einzigen notify aus, das wie folgt definiert ist:


define nyEspDoors notify esp.*tuer.tag.* {\
tagAction($EVTPART1,$NAME);;\
}
attr nyEspDoors devStateIcon inactive:ios-off:active .*:ios-on-blue:inactive
attr nyEspDoors room Zutritt


(Evtl. könnte/sollte man die regex  genau (!) auf die beiden Devices einschränken)

Dieses notify wiederum ruft nun die eigentliche Kern-Funktion tagAction, die entscheidet, ob und was nun passieren soll.
Dieser Funktion wird der tag (also nur die isolierte tag-Id, die vom F2-2 gesendet wird) und der Name des ESPEasy-Device (also der regeistrierenden Türstation) übergeben.
Letztendlich splittet sich das Ganze in mehrere Unterfunktionen auf, deshalb habe ich wegen der Übersichtlichkeit dafür eine eigene 99_MySimpleTagUtils.pm angelegt, man kann die aber natürlich auch alle in der 99_myUtils.pm ablegen.

Im folgenden nun also die 99_MySimpleTagUtils.pm mit vielen Kommentaren :)


##############################################
# $Id: 99_MySimpleTagUtils.pm 7570 2017-10-15 17:00:00Z Benni $
#

package main;

use strict;
use warnings;
use POSIX;

sub MySimpleTagUtils_Initialize($$) {
  my ($hash) = @_;
}

sub tagGetTags($;$) {
#Mit dieser Funktion kann ein Array abgerufen werden, das die Namen
#aller Schlüsseldevices mit bestimmten IDs (regex) und einem bestimmten
#Status (on/off) haben

#Übergeben wird die regEx für die tagID(s) und den tag-Status.
#Beides wird in entsprechende Variablen gepackt.
my ($tagId,$tagState)=@_;

#Wurde für die regex der tagID nichts angegeben, wird undef an die aufrufende
#Funktion zurückgeliefett und die Verarbeitung ist hier zu Ende
return undef if(!defined $tagId);

#Es sollen keine leeren tagIDs berücksichtigt werden, daher wird die regex
#im Falle von .* so angepasst, dass auf jeden Fall Devices mit belegtem (.+)
#tagid-Attribut gefiltert wird
$tagId='.+' if($tagId eq '.*');

#Wird für tagstate nichts angegeben, so soll nach beliebigem Status
#gefiltert werden (egal ob on oder off)
$tagState='(on|off)' if(!defined($tagState));

#Nun wird das devspec anhand der bis hierher zusammengestellten
#Filter zusammengesetzt und ausgeführt.
my $devspec="tagid=$tagId:FILTER=state=$tagState";
my @tags=devspec2array($devspec);

#Jetzt sollte als Ergebnis ein Array mit den gefundenen Devicenamen
#vorliegen....
my $tags=@tags;
if(int($tags)==1) {
#... falls nicht, wird undef zurückt gegeben
return undef if(!$defs{$tags[0]});
}
return @tags;
}

sub tagGetTagById($) {
#Es wird das Tag-Device zur übergebenen tagID ermittelt

#Übergeben wird die tagID (nicht als regex!), die packen wir in eine Variable
my ($tagid)=@_;

#Wir nutzen die Funktion tagGetTags und lassen uns alle tagDevices zurückgeben
#und zwar unabhängig vom aktiv-Zustand
my @tags=tagGetTags('.+');

#Das zurückgelieferte Array durchsuchen wir nach der übergebenen tagID
foreach my $tagdev (@tags) {
#Ist die tagID im aktuell durchsuchten tagDevice eingetragen, so
#haben wir das Device gefunden und geben den Namen zurück.
#Weiter müssen wir auch nicht suchen und die Verarbeitung
#endet hier.
return $tagdev if(AttrVal($tagdev,'tagid',undef) eq $tagid);
}

#wurden alle möglichen tag-Deveices abgeklappert und die gesuchte tagID
#nicht gefunden, dann laden wir hier und wir geben undef zurück, weil
#wir nichts gefunden haben.
return undef;
}

sub tagIsValidTag($) {
    #Überprüfen, ob der übergebene Schlüssel (tag/tagID) gültig ist.
    #0=ungültig / 1=gültig

   
#Die tagID wird übergeben, diese packen wir in eine Variable
    my ($tagid)=@_;

    #Wurde evtl. gar keine tagID übergeben, so kann diese auch nicht gültig
    #sein und damit sind wir hier schon fertig und geben 0 (=ungültig)
    #an die aufrufende Funktion zurück.
return 0 if(!$tagid);

    #über die Funktion tagGetTags lassen wir uns alle Tags mit der angegebenen
    #tagID die den Status 'on' (=aktiv) haben ermitteln
    #(Diese Funktion behandelt die tagID eigentlich als regex)
my @tags=tagGetTags($tagid,'on');

    #Konnte nicht genau eine tagID gefunden werden (also keine, oder mehr als eine),
    #so ist die tagID ebenfalls nicht gültig und wir sind hier fertig und geben 0
    #an die aufrufende Funktion zurück.
my $tagcount=@tags;
return 0 if($tagcount!=1);

    #Zur tagID, die an sich, wie wir wissen nun soweit gültig ist
    #(-> sie existiert und ist aktiv)
    #Das von tagGetTags zurügckgebene Array enthält somit genau 1 Element und
    #das ist der Name des Tag-Device und aus diesem ....
my $tagdev=$tags[0];
    # ... holen wir uns nun den Namen zugeordnete KeyOwner-Device
my $owner=AttrVal($tagdev,'tagowner',undef);

    #Abschließend muss nun noch geprüft werden, ob der Schlüsselbesitzer
    #auch gültig ist. Das Ergebnis dieser Prüfung bestimmt dann letztendlich die
    #Gesamtgültigkeit des Schlüssels (tag)
return tagIsValidOwner($owner);
}

sub tagIsValidOwner($) {
#Es wird überprüft, ob ein Owner-Device existiert und aktiv (on) ist.
#Ist das der Fall, so wird 1 an die aufrufende Funktion zurückgeliefert,
#ansonsten 0.

#Es wird der Name des gesuchten KeyOwner-Devices übergeben, der wird
#in eine entsprechende Variable gepackt.
my ($owner)=@_;

#Existiert kein KeyOwnerDevice mit angegebenem Namen, so kann dies
#auch nicht gültig sein und es wird 0 an die aufrüfende Funktion zurück
#geliefert und die Verarbeitung ist hier zu Ende
return 0 if(!$defs{$owner});

#Hier wird geprüft, ob es sich überhaupt um ein KeyOwnder-Device
#handelt, dazu wird das Attribut für den KeyOwner-Namen abgefragt
#Ist dies nicht gesetzt, so ist das Device kein gültiges KeyOwner-Device
#Die Verarbeitung Endet in diesem Fall hier und  es wird 0 an die
#aufrufende Funktion zurückgeliefert.
return 0 if(!AttrVal($owner,'ownerName',undef));

#Bis hierher waren alle Überprüfungen erfolgreich, also muss
#noch der Status (state) des Device geprüft werden. Steht dieser
#auf 'on', so ist das KeyOwner-Device gültig und es kann 1
#zurück geliefert werden.
return 1 if(ReadingsVal($owner,'state','off') eq 'on');

#Sollte die Verarbeitung bis hier kommen (stat ist nicht 'on'),
#so liegt letztendlich kein gültiges KeyOwner-Device vor und es wir
#0 an die aufrufende Funktion zurückgeliefert.
return 0;
}

sub tagAction($$) {
#Übergeben werden die tagID und die Quelle (=Name der Türstation)
#diese Informationen packen wir zunächst mal in eigene Variablen
my ($tagid,$source)=@_;

#Jetzt wird durch die Funktion tagIsValidTag geprüft, ob der übergebene Tag
#gültig ist. Die Definition der Gültigkeit -> siehe tagIsValidTag
my $tagvalid=tagIsValidTag($tagid);

#Im Log soll auf jeden Fall der Tag und die ermittelte Gültigkeit eingetragen werden:
my $validtxt='invalid';
$validtxt='valid' if($tagvalid);
Log3 'tagAction',3,"Source: $source - Tag: $tagid -> $validtxt";

#Wenn der Tag gültig ist, muss als nächstes Ermittelt werden, was denn nun ausgeführt werden soll
if($tagvalid) {

#Dazu holen wir uns anhand des übermittelten Tags (tagid) das entsprechende logische Tag-/Schlüssel-Device
my $tagdev=tagGetTagById($tagid);

#Dann lassen wir uns die eigentliche Aktion aus dem Device geben (siehe tagGetAction)
my $action=tagGetAction($tagdev,$source);

#Das Ergebnis für die ermittelte Aktion tragen wir auch ins Log ein
Log3 'tagAction',3,"Tag-Device: $tagdev -> Action: $action";

#Und wenn tatsächlich eine Aktion ermittelt werden konnte, so wird versucht, diese auszuführen.
#Auch das Ergebnis des Ausführungsversuchs wird ins Log eintegtagen.
if($action) {
Log3 'tagAction',3,'Trying to execute action...';
eval($action);
Log3 'tagAction',3,$@ if($@);
}

}
return undef;
}

sub tagGetAction($$) {
    #Es wird aus dem Übergebenen tag-Device und der Quelle (Türstation)
    #die entsprechende Aktion aus dem Reading tagmapping des tag-device
    #extrahiert

    #Der Name des tag-Device und die Quelle werden übergeben und in entsprechende
    #Variablen gepackt
my ($tag,$source)=@_;

my $actions=AttrVal($tag,'tagmapping',undef);

return undef if(!$actions);

    #Jetzt haben wir alle Zeilen aus tagmapping und die Zeilen werden nun
    #einzeln darauf überprüft, ob sie für die Quelle einen Eintrag haben
my @actionmap=split(/\n/,$actions);

foreach my $action (@actionmap) {
my($actsrc,$action)=split(/:/,$action,2);
        #Es wurde ein Eintrag für die gesuchte Quelle gefunden.
        #Damit sind wir fertig und geben diesen an die aufrufende FUnktion
        #zurück
return $action if($actsrc eq $source);
}

    #Es konnte keine Aktion zur Quelle gefunden werden
return undef;
}

1;


So, damit hätten wir nun alles an Code zusammen.

Was fehlt jetzt noch?
Genau! Bisher haben wir noch keine Aktionen definiert. Wir haben zwar im Beispiel-KeyDevice ein
entsprechendes Mapping eingetragen, allerdings haben wir noch keine Umsetzung.

Das Mapping (tagmapping) im o.g. Tag-/Key-Device ist im Beispiel mit folgendem Inhalt belegt:


espdHaustuer:OpenHaustuer
espdKellertuer:ToggleKellertuer


Jede Zeile im angegebenen Attribut definiert eine Aktion und zwar immer in Zuordnung zur Quelle (Türstation)
Also wird für den Tag, wenn er von Türstation (ESPEasy-Device) 'espdHaustuer' kommt die Aktion 'OpenHaustuer' ausgeführt.
Kommt der Tag jedoch von der Türstation 'espdKellertuer', so wird die Aktion 'ToggleKellertuer' ausgeführt.
'OpenHaustuer' und 'ToggleKellertuer' sind einfach 2 Funktionen in der 99_myUtils.pm, die bei mir entsprechenden Aktionen, an den jeweiligen KeyMatics ausführt.

Beide als Beispiel mal im Folgenden, die müssen natürlich auf die jeweilige Umgebung angepasst werden.


sub OpenHaustuer() {
#Wenn der aktuelle Status KeyMatic der Haustür 'entriegelt' ist,
#wird der Aktor für den Türöffner (Summer) kurz aktiviert
fhem('set aktTueroeffner on-for-timer 0.5') if(Value('KeyMatic_Haustuer') =~/unlock/);
}



sub ToggleKellertuer() {
#Die Kellertuer kann von innen und außen per Klinke geöffnet werden,
#daher wird hier einfach die KeyMatic zwischen den zuständen verriegelt und entriegelt getoggelt

#Es wird erst noch geprüft, ob die Tür an sich geschlossen ist. Dazu wird der ebenfalls
#vorhandene Tür-/Fenster-Kontakt geprüft
if(Value('tkKellertuer') eq 'closed') {
if(Value('KeyMatic_Kellertuere') eq 'locked') {
fhem('set KeyMatic_Kellertuere unlock');
} else {
fhem('set KeyMatic_Kellertuere lock');
}
}
}


Man kann das sicher auch noch kompakter aufbauen, v.a. was die "vielen" zusätzlichen Dummies anbelangt, aber ich finde so ist die Verwaltund der einzelnen Schlüssel deutlich übersichtlicher.
Eventuell habe ich irgendwann noch mal die nötige Zeit und Lust, dann packe ich das Ganze mal noch ein ein separates Modul mit dem dann die komplette Verwaltung zusammengefasst werden kann (ähnl. pahs Alarmanlage) und mit dem dann auch die Dummies wegfallen würden.
Im Moment funktioniert das für mich aber ganz gut und mir gefällt auch, dass das quasi mit elementaren FHEM-Bausteinen umgesetzt ist.

Viel Spaß damit!

gb#

Update 17.10.2017 19:00:

Im Code von 99_MySimpleTagUtils.pm war noch ein kleiner Bug in der sub tagGetTags. Dort muss die Zeile

$tagState="('on'|'off')" if(!defined($tagState));


durch


$tagState='(on|off)' if(!defined($tagState));


ersetzt werden (im Listing oben ist das inzwischen korrigiert)


FrankieSOC

Hallo Benni,

damit hatte ich nicht gerechnet, gefällt mir gut, vielen Dank.
Leider merke ich, wie schnell ich an meine "grenzen" komme.

Ich habe mit einem "tag" und einem "owner" zum Testen gestartet.
Internals:
   NAME       tagFrank.LZF
   NR         211
   STATE      on
   TYPE       dummy
   READINGS:
     2017-10-16 12:38:25   state           on
Attributes:
   devStateIcon on:ios-on-green off:ios-off
   group      Key
   icon       access_keypad_1
   room       Zutritt
   setList    on off
   tagid      1419114678
   tagmapping espdHaustuer:OpenHaustuer
   tagowner   ownFrank
   userattr   tagid tagowner tagmapping:textField-long
   webCmd     :


Das notify musste ich anpassen.
espdHaustuer {\
tagAction($EVTPART1,$NAME);;\
}


Der Perl-Code "MySimpleTagUtils" und "sub OpenHaustuer" ist eingetragen und angepasst.
sub OpenHaustuer() {
fhem('set HM_535E4E open')


Wenn ich jetzt den in der "tagid" definierten Code scanne, wird der "tag" in fhem beim "espdHaustuer" angezeigt, aber nichts passiert.

Im Logfile finde ich folgende Einträge.
Source: espdHaustuer - Tag: 1419114678 -> valid
Tag-Device:  -> Action:

Wenn ich einen falschen Code scanne.
Source: espdHaustuer - Tag: 2479659275 -> invalid

Wenn der ESP nach ein paar Minuten in absent geht, bekomme ich folgende Meldung.
Source: espdHaustuer - Tag: absent -> invalid
ERROR evaluating my $NAME='espdHaustuer';my $EVENT='absent';my $EVTPART0='absent';my $TYPE='ESPEasy';my $SELF='nyEspDoors';{ tagAction($EVTPART1,$NAME);; }: Global symbol "$EVTPART1" requires explicit package name at (eval 94413) line 1.
nyEspDoors return value: Global symbol "$EVTPART1" requires explicit package name at (eval 94413) line 1
.


Wo muss ich suchen?

Viele Grüße
Frank


Benni

#38
Zitat von: FrankieSOC am 17 Oktober 2017, 12:56:28
Wo muss ich suchen?

Ich glaube, da ist noch ein kleiner Bug drin. :-\
Ich bin dran  ;) ....


So, der Bug ist raus und im Listing im Post oben korrigiert und dort auch als Update beschrieben:

Zitat von: Benni am 16 Oktober 2017, 07:55:59
Update 17.10.2017 19:00:

Im Code von 99_MySimpleTagUtils.pm war noch ein kleiner Bug in der sub tagGetTags. Dort muss die Zeile

$tagState="('on'|'off')" if(!defined($tagState));


durch


$tagState='(on|off)' if(!defined($tagState));


ersetzt werden (im Listing oben ist das inzwischen korrigiert)



Das zweite, davon unabhängige Problem:

Zitat von: FrankieSOC am 17 Oktober 2017, 12:56:28
Wenn der ESP nach ein paar Minuten in absent geht, bekomme ich folgende Meldung.

das ist eine Folge davon:

Zitat von: FrankieSOC am 17 Oktober 2017, 12:56:28
Das notify musste ich anpassen.
espdHaustuer {\
tagAction($EVTPART1,$NAME);;\
}


Dein notify ist zu großzügig und greift alle (!) events ab, die von espdHaustuer erzeugt werden. Das sollte aber bei dir auch funktionieren:

espdHaustuer.tag.* {\
tagAction($EVTPART1,$NAME);;\
}


Ich gehe dabei davon aus, dass das Reading und der Event der in espdHaustuer erzeugt werden 'tag' heißt.




FrankieSOC

Mit der Anleitung kann man gut arbeiten.  :)

Diesen Fehler hätte ich nie gefunden...  :o
vielen Dank für suche, es hat direkt nach der Änderung geklappt.

Das "notify" hab ich nach deinem Hinweis angepasst, nun sind keine Fehlermeldung im logfile.

Eine Sache klappt noch nicht wie es soll.
Wenn ich den richtigen "tag" scanne, wird der Befehl nach 1 1/2 Minuten noch ein zweites mal gestarte.
2017.10.17 21:46:30.461 3: Source: espdHaustuer - Tag: 1419114678 -> valid
2017.10.17 21:46:30.461 3: Tag-Device: tagFrank.LZF -> Action: OpenHaustuer
2017.10.17 21:46:30.461 3: Trying to execute action...
2017.10.17 21:46:30.462 3: CUL_HM set HM_535E4E open
2017.10.17 21:46:30.465 3: Source: espdHaustuer - Tag: 1419114678 -> valid
2017.10.17 21:46:30.465 3: Tag-Device: tagFrank.LZF -> Action: OpenHaustuer
2017.10.17 21:46:30.465 3: Trying to execute action...
2017.10.17 21:46:30.466 3: CUL_HM set HM_535E4E open
2017.10.17 21:48:53.093 3: Source: espdHaustuer - Tag: 1419114678 -> valid
2017.10.17 21:48:53.094 3: Tag-Device: tagFrank.LZF -> Action: OpenHaustuer
2017.10.17 21:48:53.094 3: Trying to execute action...
2017.10.17 21:48:53.094 3: CUL_HM set HM_535E4E open


Im readings vom espdHaustuer, sieht man das der code 21:46 gescannt wurde und dann im 21:48 durch den Änderung "present" der Vorgang ein zweites mal gestartet wurde.
READINGS
Presence present 2017-10-17 21:48:53
State tag: 1419114678 2017-10-17 21:48:53
Tag 1419114678 2017-10-17 21:46:30


Hast du diese Phänomen auch schon beobachtet?

schöne Abend und Grüße
Frank

Benni

Stimmt!
Das hatte ich anfangs auch.

Ich habe am ESPEasy-Device das Attribut presenceCheck auf 0 gesetzt. Damit hatte sich das dann glaube ich erledigt.

FrankieSOC

#41
cool  8) Danke Benni, klappt.

hat doch nicht geklappt. "presenceCheck 0"

Nun sind es aber 5 Minuten  ???

state
tag: 1419114678 2017-10-18 15:09:32
tag  1419114678 2017-10-18 15:04:31

diese Attributes sind gesetzt.

   IODev      espBridge
   Interval   300
   group      ESPEasy Device
   presenceCheck 0
   readingSwitchText 1
   room       ESPEasy,Zutritt
   setState   3

Zeig mal deine? ;D

Benni

Zitat von: FrankieSOC am 18 Oktober 2017, 10:02:36
Zeig mal deine? ;D

Bitteschön:


Attributes:
   DbLogExclude .*
   IODev      espBridge
   Interval   0
   event-min-interval tag:10
   event-on-change-reading tag
   event-on-update-reading tag
   group      ESPEasy Device
   presenceCheck 0
   readingSwitchText 1
   room       ESPEasy
   setState   3


Dann wird's wohl Interval sein.
Selber experimentieren ist übrigens immer noch elaubt ;)

zentis666

Hallo!
Ich hab die von  Benni vorgestellte Lösung nachgebaut und mein altes SBoard Steuergerät ersetzt, funktioniert super, vielen Dank dafür!
Nun möchte ich eine Benachrichtigung per Telegram verschicken wenn ein Tag verwendet wurde.
In der 99_MySimpleTagUtils.pm werden die Variablen $owner und $tagdev für Besitzer und Tag-Device genutzt,
diese würde ich dafür gern benutzen. Die Variablen werden aber nicht aufgelöst sondern es wird dann
"Türöffnung von $owner mit $tagdev"
übertragen.

In der 99_myUtils.pm hab ich folgendes:

sub OpenHaustuer() {
#Öffen Keymatic und Statusmeldung per Telegram
fhem('set Keymatic open');
fhem('set telegram message Türöffnung von $owner mit $tagdev')
}


Was mache ich falsch? Tippfehler? Ich hab schon alles mögliche versucht, finde aber keine Lösung,

Gruß
Sven
--
FHEM auf Debian VM - ESXi 6.0 Intel Nuc i5 4th Gen, Homematic auf HMCCU - RaspberryMatic auf Raspberry PI 3,
EM1000 & FS20 über CUNO,  IT über Arduino Firmata, MiLight über WLAN-nRF Gateway, Ebus, 1Wire, diverse Squeezeboxen, Dreambox 920UHD, Homebridge

Brockmann

Zitat von: zentis666 am 17 Dezember 2017, 18:06:47
Was mache ich falsch? Tippfehler? Ich hab schon alles mögliche versucht, finde aber keine Lösung,
Schon mal doppelte Anführungszeichen ("...$variable...") probiert?