[erledigt] Wert manuell über Notify an HM-PBI-4-FM setzen

[Andy_C]

Hallo Zusammen,

ich habe über den Aktor eine Infrarot-Lichtschranke eingebunden. Bei dem Aktor hatte ich das Attribut "event-on-change-reading" nicht vergeben. Deshalb hat er mich nun mit Mails über den Batteriestatus so zugespamt dass das System nicht verfügbar war. Nun habe ich das auf hier umgestellt... allerdings reagiert jetzt natürlich die Lichtschranke nicht mehr, da ich den Wert ja lediglich neu setze... Ich möchte den Wert über ein Notify dann gerne nach dem setzen über die Lichtschranke auf einen anderen Wert zurücksetzen...

Die Lichtschranke ist auf dem Kanal 1 "Btn_01" angeschlossen und gibt den Wert "Btn_01 Long" aus. Das würde ich gerne nach einem sleep auf Short ändern...bin nur zu doof den zu setzen...

viele Grüße, Andy

[Andy_C]

Keiner eine Idee?

[amenomade]

Verstehe deine Frage nicht.

Nun habe ich das auf hier umgestellt... allerdings reagiert jetzt natürlich die Lichtschranke nicht mehr, da ich den Wert ja lediglich neu setze... Ich möchte den Wert über ein Notify dann gerne nach dem setzen über die Lichtschranke auf einen anderen Wert zurücksetzen... 

Das macht überhaupt keinen Sinn.

Bitte ein "list" vom HM-PBI-4-FM zeigen. Wenn Du event-on-change-reading richtig gesetzt hast, sollten (nur) die Ereignisse generiert werden, die dich interessieren.
Mails... gespamt... Wie ist deine Logik für die Mails gebaut?
"Long nach sleep auf Short ändern" => das ist auch unverständlich. Ein Ereignis kannst Du nicht ändern...

[Andy_C]

Hi und danke schon mal für deine Antwort. Ich weis zwar noch das man den Code einbetten soll, aber leider nicht mehr wie...

deshalb  hier nur mal schnell den Ausschnitt:

Attributes:
   IODev      hmlang
   autoReadReg 4_reqStatus
   event-on-change-reading state,battery
   expert     2_raw
   firmware   1.5
   model      HM-PBI-4-FM

gespamt:

Da ich vorher "event-on-change-reading"  nicht gesetzt hatte, bekam ich  bei jeder Meldung auf battery low eine Mail. Durch "event-on-change-reading" meldet er ja nur noch wenn es sich ändert... somit bekomme ich die Mail auch nur ein Mal.

ändern vom State:

Nach einer halben Stunde wird die Garage geschlossen, falls die Lichtschranke aus ist (aktiviere ich automatisch für 10 min wenn man durchläuft). Da sich der Wert ja nicht mehr ändert und nur bei Änderung meldet funktioniert das nicht mehr.... ich möchte als "dummy-Einstellung" auf short ändern .... dann ändert er sich beim Durchlaufen wieder auf long und meldet an fhem..... bleibt er auf long... laufe ich durch, bleibt der Wert gleich und ich kann ihn nicht auswerten / verwenden ...


vielleicht ein Denkfehler dabei...?  bis zum Batterieproblem lief es zumindest auch...

viele Grüße, Andy

[amenomade]

code => das # im Editor-menü.

Spam => um was zu sagen, brauche ich die Logik, die die Email sendet: ein "list" vom entspr. notify oder DOIF oder watchdog, oder was auch immer.

ändern von State => genauso brauche ich das Device (notify, DOIF, ...), das die Garage schliesst. Ohne es zu kennen, würde ich raten:

Code Auswählen Erweitern

event-on-change-reading battery
event-on-update-reading state

[Andy_C]

Hi, ich war mir nicht mehr sicher mit dem # ...

Das wäre der Code für die Warnungen:

Code Auswählen Erweitern


define Nf_MailInfo_BatChck notify .*:[Bb]attery:.* { if($EVENT !~ m/ok/) { { return if ($NAME eq 'Gar_Tortaster');; DebianMail("xxx\@xxx.de", "FHEM Batteriewarnung", $NAME.": ".$EVENT)};;   Log 3, "$NAME: Batteriewarnung $EVENT";;  } }



Das schliessen habe ich einfach über einen Timer (sind im Moment 2 Konakte...):

Code Auswählen Erweitern


# Timer AutoClose Garage
define Ti_AutoClose_Garage at +*00:30:00 { fhem("set Gar_Tortaster on") if (Value ("GaLiSchranke") eq "off") && Value ("Gar_Tor_Closed") ne "closed" && (Value ("Gar_Tor_Open") ne "open") }


Bei dem Tortaster hab ich das damals so gelöst.... jetzt wo du das schreibst wäre wohl "event on update" die richtige wahl oder?

Code Auswählen Erweitern


### Garagen Tor-Taster
define Nf_Gar_Tortaster notify Gar_Tortaster:on { fhem ("sleep 2;;set Gar_Tortaster off")}



List auf das Device:.. mit dem Event-on-update-reading wird das bei mir wieder gehen nehme ich an...

Code Auswählen Erweitern


Internals:
   DEF        5F31E8
   IODev      hmlang
   NAME       Ga_LichtSchranke
   NOTIFYDEV  global
   NR         714
   STATE      Btn_01 Long
   TYPE       CUL_HM
   channel_01 Btn_01
   channel_02 Btn_02
   channel_03 HM_5F31E8_Btn_03
   channel_04 HM_5F31E8_Btn_04
   READINGS:
     2018-06-03 00:32:30   D-firmware      1.5
     2018-06-03 00:32:30   D-serialNr      OEQ0613390
     2018-11-25 20:38:04   battery         ok
     2018-11-25 20:38:04   state           Btn_01 Long
   helper:
     HM_CMDNR   85
     mId        0034
     regLst     ,0
     rxType     4
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5F31E8,00,00,00
       prefIO     
       rxt        0
       vccu       
       p:
         5F31E8
         00
         00
         00
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
     tmpl:
Attributes:
   IODev      hmlang
   autoReadReg 4_reqStatus
   event-on-change-reading battery
   event-on-update-reading state
   expert     2_raw
   firmware   1.5
   model      HM-PBI-4-FM
   room       17_Garage
   serialNr   OEQ0613390
   subType    pushButton
   webCmd     getConfig:clear msgEvent



Gruß, Andy

[Andy_C]

Den Dummy habe ich noch vergessen:

Code Auswählen Erweitern


Internals:
   NAME       GaLiSchranke
   NR         246
   STATE      off
   TYPE       dummy
   Helper:
     DBLOG:
       state:
         myDbLog:
           TIME       1543192223.96844
           VALUE      off
   READINGS:
     2018-11-26 01:30:23   state           off
Attributes:
   event-on-change-reading state
   room       01_Wohnung,17_Garage
   setList    on off on-for-timer
   useSetExtensions 1
   webCmd     on:off


[MadMax-FHEM]

@amenomade: das wird schwer

Ich hab ja auch mal drüber geschaut aber:

von der Logik für das Garagentor fehlt mehr als die Hälfte: Gar_Tortaster, Gar_Tor_Closed, Gar_Tor_Open

Was sind das für Dinger!?

Du hast ein list von Ga_LichtSchranke welches aber sonst nirgendwo mehr vorkommt!?

Was macht der Dummy GaLiSchranke bzw. wie wird der gesetzt!?

Wofür ist das "at", das alle 30min "irgendwas macht" (zumindest was, was ich nicht erkennen kann was bzw. wozu)...

Das Unterbinden von Dauerfeuer geht auch anders.
Man kann sich z.B. merken für welches Gerät man eine Nachricht verschickt hat und dann erst wieder etwas frühestens nach einer bestimmten Zeit erneut schicken (z.B. mittels ReadingsAge) oder mittels OldReadingsVal oder OldReadings (nutze ich nicht, daher weiß ich grad nicht wie es genau heißt   ) abfragen, ob der alte Wert anders ist und erst dann schicken, wenn er tatsächlich wieder anders oder wieder "low" etc. ist.

Man kann zur Batterieüberwachung ein Modul nehmen: https://forum.fhem.de/index.php/topic,82637.0.html oder https://forum.fhem.de/index.php/topic,68765.0.html

Ein event-on-change-reading nur auf battery machen, dann bleibt state wie gewohnt, ...


Und wie geschrieben: ich verstehe die Logik des Garagentores (oder was auch immer) überhaupt nicht... Und auch nicht so ganz was das mit einer Batterieüberwachung zu tun hat/haben soll...

Gruß, Joachim

[amenomade]

Und auch nicht so ganz was das mit einer Batterieüberwachung zu tun hat/haben soll...

Also... wenn ich richtig verstanden habe, hat er durch unselektives event-on-change-reading (um das Spam zu vermeiden) Ereignisse unterdruckt, die den für die Garagesteuerung doch interessieren.
Aber wie bei dir fehlt mir das gesamte Blick von der Logik für die Garagesteueurung. Und diese Geschichte mit Long und Short verstehe ich überhaupt nicht

[MadMax-FHEM]

Jep so in etwa habe ich das schon auch verstanden...
...aber ohne die (Gesamt)Logik zu kennen ist es halt schwer das (genaue) Problem zu erfassen bzw. eher die (weiteren) Auswirkungen von Ratschlägen/Lösungsmöglichkeiten bewerten zu können bzw. überhaupt vernünftige zu finden...
...nachdem ja bereits ein (falsches) event-on-change-reading auf ein (für mich immer noch) "unbeteiligtes" Device" bereits die (für mich immer noch) unbekannte Logik aus der Bahn geworfen zu haben scheint...

Mal sehen, ob das noch klar(er) wird...

Gruß, Joachim

[Andy_C]

Hallo Zusammen...

sorry für das Durcheinander . Das mit dem "Short und Long" war eine falsche Herangehensweise von mir... durch das event-on-update kommt ja trotz gleichem Wert eine Info und es funktioniert wieder.

Von der (Un-) Logic :

Ich habe einen Batterietaster (=Gar_Tortaster), welcher den Garagentorantrieb ansteuert. Durch das "event-on-change" musste ich erst einen anderen Zustand "off" bekommen, damit ich wieder schalten konnte "on". Das Ganze kann ich mir mit "event-on-update" sparen.... vielen Dank hier auch.  Das Garagentor kann nur Ein/Stop/Auf über einen Tastendruck..

Nun habe ich dazu einen Timer gesetzt, welcher alle 30 min den Taster betätigt, wenn die Lichtschranke aus ist und die Torkontakte nicht in Stellung "geschlossen" sind. Durch die Unterbrechung der Lichtschranke ist dies im frühesten Falle nach 10 min, im längsten Fall nach 40 min.

Mit den beiden Kontakten und dem Timer ist aktuell, da die Garage ab und zu offen stand... Vielleicht habe ich mich da irgendwo reingerannt, bin sicher auch schon lang nicht mehr auf dem Stand mit fhem (Installation ist recht alt)

Gruß, Andy

[MadMax-FHEM]

Vielleicht ist auch die Logik in Summe etwas kompliziert

Aber wenn es wieder geht!?

Dann vielleicht den Thread als gelöst/erledigt kennzeichnen: umbenennen in beispielsweise [erledigt] Wert manuell über Notify an HM-PBI-4-FM setzen

Wenn nicht (habe ich es [wieder mal] falsch verstanden   ) und dann einfach weiter machen aber die Infos wären dann noch nicht ausreichend (wie du merkst    ).

Gruß, Joachim

[Andy_C]

Hallo Joachim,

ich werde es morgen noch mal testen... aber mein Problem sollte damit behoben sein. Den Thread werde ich markieren.... Hast Du evtl. ein paar Stichwörter für mich um das Ganze einfacher zu lösen... bin mir sogar sicher dass das viel zu kompliziert gelöst ist ....

vielen Dank und Grüße, Andy

[MadMax-FHEM]

Hallo Joachim,

ich werde es morgen noch mal testen... aber mein Problem sollte damit behoben sein. Den Thread werde ich markieren.... Hast Du evtl. ein paar Stichwörter für mich um das Ganze einfacher zu lösen... bin mir sogar sicher dass das viel zu kompliziert gelöst ist ....

vielen Dank und Grüße, Andy

Da kann man nur was vorschlagen, wenn wirklich alle "Geräe" (und/bzw. Devices in fhem) "bekannt" sind und der (möglichst) genaue Ablauf unter nennung dieser beschrieben wird...
...inklusive "Randbedingungen" (weil mir ist immer noch nicht klar warum das mit der Lichtschranke, Dummy, "at" usw. ganz genau gedacht sind bzw. tatsächlich wirklich notwendig)...

Aber das würde wohl eher einen kompletten Umbau bzw. neues Herangehen an die "Grundproblematik" bedeuten...

Stichworte kann ich mal nennen:

DOIF (nicht meins aber sehr mächtiges Modul! Anwendung darf man aber nicht unterschätzen: es gibt ein Haufen Attribute usw. Ist halt [mehr] konfigurieren statt programmieren / wobei es neuerdings auch mit Perl "erweitert" werden kann)

Notify und Sub in myUtils (https://wiki.fhem.de/wiki/99_myUtils_anlegen / eher meins, ist halt klar programmieren statt konfigurieren / dafür sehe/weiß ich aber genau WAS WARUM tut und wenn es nicht passt wird solange selbst geschraubt bis es tut   )

Es gibt/gab auch mal ein Modul "Statemachine"

Es gibt noch das MSwitch-Modul, ebenfalls sehr mächtig mittlerweile

und und und

Gruß, Joachim