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
Keiner eine Idee?
Verstehe deine Frage nicht.
ZitatNun 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...
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
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:
event-on-change-reading battery
event-on-update-reading state
Hi, ich war mir nicht mehr sicher mit dem # ;-)...
Das wäre der Code für die Warnungen:
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...):
# 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?
### 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...
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
Den Dummy habe ich noch vergessen:
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
@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
ZitatUnd 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
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
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
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
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
Zitat von: Andy_C am 26 November 2018, 19:00:20
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