Hallo,
ich habe mir folgendes gebastelt:
- Ein WOL device "Google" prüft, ob Google (8.8.8.8) erreichbar ist (Mac-ID ist fake, damit kein Gerät im LAN wirklich geweckt wird und ShutdownCmd ist "")
- Ein DOIF schickt eine Pushnachricht per pushover wenn "Google" AUF "on" schaltet: ([Google:"on"])
Das Dumme an der Sache war nur: Wenn man "Google" refreshed geht es kurzzeitig auf den state "refresh" und dann auf "on". Damit dabei aber nicht jedes mal auch eine unnötige Pushnachricht gespammt wird, sondern nur wenn das device vorher off war (wenn es AUF "off" geht etwas senden macht ja keinen Sinn, denn in dem Moment ist ja die Internetverbindung platt!) habe ich mir eine art Pufferdevice eingerichtet:
define Internet dummy
attr Internet event-on-change-reading.*
define InternetNote DOIF ([Google:"on"]) (set Internet on) DOELSEIF ([Google:"off"]) (set Internet off)
Das device "Internet" wird nun wenn Google auf "on" geht auf "on" gesetzt und wenn es auf "off" geht wird es auf "off" gesetzt. Der status "refresh" wird damit ignoriert. Wenn ich das DOIF nun auf "Internet" und nicht auf "Google" triggere bekomme ich nicht bei jedem refresh von "Google" eine Pushnachricht. Es funktioniert also, allerdings habe ich nun ein WOL, einen Dummy und zwei DOIFs.... ist das nicht ein bisschen viel? Ich hab das Gefühl, dass all das mit höchstens dem halben Aufwand geht. Hat jemand dazu eine Idee?
Viele Grüße! :)
Dann drehe den Spieß um! Prüfe nicht auf on, sondern auf off!
define di_Inet DOIF ([Google:state] eq "off") (set Internet off) DOELSE (set Internet on)Ist kurz, aber hat natürlich den Nachteil, dass bereits beim state refresh die Nachricht raus geht, dass das Internet da ist.
Aber wenn Du auf beide Zustände prüfst, dann ignorierst Du doch den state refresh...
define di_Inet DOIF ([Google:state] eq "off") (set Internet off) DOELSEIF ([Google:state] eq "on") (set Internet on)So kommt doch auch keine Nachricht, wenn der Staus von off oder on auf refresh wechselt, solange nicht das Attribut 'do always' gesetzt ist. DOIF merkt sich ja im Reading state, welcher Befehl zuletzt ausgeführt wurde (cmd_1, cmd_2´) und führt diesen nicht nochmal aus. Vorher muss DOELSE(IF) gelaufen sein.
Oder verstehe ich das Problem falsch?
Zitat von: Device specific helpDas DOIF-Modul arbeitet mit Zuständen. Jeder Ausführungszweig DOIF/DOELSEIF..DOELSEIF/DOELSE stellt einen eigenen Zustand dar (cmd_1, cmd_2, usw.). Das Modul merkt sich den zuletzt ausgeführten Ausführungszweig und wiederholt diesen standardmäßig nicht. Ein Ausführungszweig wird erst dann wieder ausgeführt, wenn zwischenzeitlich ein anderer Ausführungszweig ausgeführt wurde, also ein Zustandswechsel stattgefunden hat. Dieses Verhalten ist sinnvoll, um zu verhindern, dass zyklisch sendende Sensoren (Temperatur, Feuchtigkeit, Helligkeit, usw.) zu ständiger Wiederholung des selben Befehls oder Befehlsabfolge führen.
nachgeschlagene Grüße
Niels
warum nimmst du WOL und nicht PRESENCE? da gibt es keinen zwischenzustand beim wechsel von absent auf present. da kannst du dann auch event-on-change-reading direkt verwenden ohne den umweg über den dummy und das DOIF.
gruss
andre
Na, weil ich nicht auf dem Schirm hatte, dass das mit PRESENCE geht. ;)
Funktioniert wunderbar. Jetzt muss ich nur noch etwas basteln, dass es mir im Webinterface ein Icon anzeigt (finde ich schöner) und das mapping/device-type für HomeBridge etwas ändern (sonst ist es da ein Alarmsensor der bei "present" einen Alarm mit "Ausgelöst" anzeigt). :)
Danke dir!!
Ok, das ist komisch...
Ich habe es jetzt wie folgt eingestellt:
define Google PRESENCE lan-ping 8.8.8.8 30
attr Google ping_count 1
attr Google event-on-change-reading.* 1
attr Google eventMap present:on absent:off statusRequest:refresh
attr Google webCmd refresh
attr Google room Haustechnik,Homekit
attr Google genericDeviceType switch
attr Google homebridgeMapping On=state,valueOn=present,valueOff=absent,cmdOn=refresh,cmdOff=refresh
Damit:
- prüft er 8.8.8.8 per einmaligem ping
- sendet nur ein reading wenn sich der status ändert
- zeigt im Webinterface eine Glühbirne für an/aus, welche auf present/absent gemapped wurde
- zeigt im Webinterface eine Schaltfläche "refresh" statt "statusRequest"
Aber wunderlicherweise zeigt er trotz des "genericDeviceType switch" und des homebridgeMapping (das steht sogar so für dieses Beispiel im Wiki!) in der Home-App das Ding als "Belegungssensor" und nicht als Schalter. :/ Wie kann das sein?
mach mal an den anfang deines homebridgeMapping noch ein clear. damit wird der default der automatisch für presence erkannt wird gelöscht.
Sowohl
attr Google homebridgeMapping clear On=state,valueOn=present,valueOff=absent,cmdOn=refresh,cmdOff=refresh
als auch
attr Google homebridgeMapping clear,On=state,valueOn=present,valueOff=absent,cmdOn=refresh,cmdOff=refresh
(wobei das erste sowieso richtig wäre, soweit ich weiß) führen beide zu keiner Veränderung. Es wird immer noch als "Belegungssensor bereit" mit "Belegung entdeckt: Nein" angezeigt. :/
Kann man das devicetype evtl. auch clearen?
ja. die erste variante ist richtig.
device type zu überschreiben war für PRESENCE, ROOMATE und RESIDENTS noch nicht drin.
sollte ab sofort gehen. homebridge-fhem updaten bzw. noch mal drüber installieren.
gruss
andre
Ist das im Screenshot schon die neueste Version?
Hab das update so wie hier beschrieben versucht:
http://www.fhemwiki.de/wiki/Homebridge_einrichten#Homebridge_aktualisieren
0.2.61 wäre die richtige. einfach mit install noch mal drüber installieren. nur homebridge-fhem reicht.
Allerallerbesten Dank!!!! :)
Nochmal für alle Suchenden (ich weiß ja wie es ist):
Ich verwende nun:
define Google PRESENCE lan-ping 8.8.8.8 30
attr Google event-on-change-reading.* 1
attr Google eventMap present:on absent:off statusRequest:refresh
attr Google webCmd refresh
attr Google ping_count 1
attr Google room Haustechnik,Homekit
attr Google genericDeviceType switch
attr Google homebridgeMapping clear On=state,valueOn=on,valueOff=off,cmdOn=refresh,cmdOff=refresh
EDIT: Wobei hier genau wie beim WOL-Modul wenn man "statusRequest" bzw. jetzt "refresh" klickt der Status trotzdem kurz von "on" auf "refresh" und dann wieder auf "on" geschaltet wird und damit der DOIF trotzdem dann ausgelöst wird und eine Push-Nachricht spammt. ;) Also eigentlich back-to-square-one.
Zitat von: Pati_Alpha am 11 November 2016, 20:08:36Wobei hier genau wie beim WOL-Modul wenn man "statusRequest" bzw. jetzt "refresh" klickt der Status trotzdem kurz von "on" auf "refresh" und dann wieder auf "on" geschaltet wird und damit der DOIF trotzdem dann ausgelöst wird und eine Push-Nachricht spammt. ;) Also eigentlich back-to-square-one.
Mhh, das verstehe ich nicht. Dass sollte IMHO beim DOIF mit einem DOELSEIF nicht passieren. Aber vermutlich hast Du kein DOELSEIF. Mache da doch etwas Sinnloses rein, dann sollte es gehen.
Mir ist noch was Anderes aufgefallen: Wenn I-Net dow, geht auch pushover nicht ;)
Das wurde aber sicher berechnet und daher kein DOIF nur ich hatte das bislang nicht berücksichtigt 8)
unberücksichtigte Grüße
Niels
Versuch´s mal mit
define InternetNote DOIF ([Google:"on"]) (set meineNachricht) DOELSEIF ([Google:"off"]) (set meineNachricht) DOELSE
attr InternetNote wait 0:0:2
Da das DOIF im Falle von statusRequest oder refresh kurzzeitig in das cmd3 geht und dann wieder zurück in cmd1 oder cmd2 musst du es mit wait verzögern.
Ggfs. die 2 Sekunden Verzögerung erhöhen, ich weiß nicht, wie lange der refresh/statusRequest ansteht.
Grüße Marcel
Ja, wait könnte funktionieren!!
Teste ich die Tage sofort.
Das mit dem "kein Internet" habe ich bedacht, daher wollte ich ja pushen, wenn das Google device WIEDER ZURÜCK auf "on" geht, denn dann weiß ich, dass Internet nicht ging. Die Erweiterung der Idee ist, dass fhem den Router bei "kein Internet" neustartet (per Funkdose). :)
Zitat von: Pati_Alpha am 12 November 2016, 23:32:59Die Erweiterung der Idee ist, dass fhem den Router bei "kein Internet" neustartet (per Funkdose).
Diese Variante hatte ich auch, ABER: damit das funktioniert, musste ich das Mailsystem auf einen zweiten Raspi auslagern, weil dieses ohne INet sonst das gesamte FHEM blockiert hat. Damit kam der Reboot in der Regel erst, nachdem das INet wieder da und die Blockade gelöst war :-\.
Ja gut, mein RPi3 macht nur FHEM und das entsprechende dazugehörige, aber im Moment lass ich ihn das auch nur loggen, wann er meint, dass Internet down war, denn ich vertraue dem Braten noch nicht so. :D
Zitat von: Pati_Alpha am 16 November 2016, 22:43:52und das entsprechende dazugehörige
Ähm, die Mails gehören bei mir dazu: Statusmails senden, Befehlsmails empfangen...
Mache ich alles per Pushover bzw. HomeKit. :)