Eleganterer Weg für Pushnachricht bei Internetverbindung

Begonnen von Pati_Alpha, 11 November 2016, 00:37:49

Vorheriges Thema - Nächstes Thema

Pati_Alpha

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! :)

Muschelpuster

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
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Pati_Alpha

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!!

Pati_Alpha

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?

justme1968

mach mal an den anfang deines homebridgeMapping noch ein clear. damit wird der default der automatisch für presence erkannt wird gelöscht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Pati_Alpha

#6
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?

justme1968

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
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Pati_Alpha


justme1968

0.2.61 wäre die richtige. einfach mit install noch mal drüber installieren. nur homebridge-fhem reicht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Pati_Alpha

#10
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.

Muschelpuster

#11
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
fhem @ ZBOX mit 1,6MHz Celeron, 4GB RAM & 120GB SSD mit Debian Bullseye # MiLight # Homematic via CCU3 # W&T WebIO # Rademacher DuoFern # ESPeasy # logdb@mysql # configdb@mysql # Shelly @ MQTT2 # go-eCharger mit PV-Überschussladung via DOIF

Ma_Bo

#12
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
NUC mit FHEM, HM Heizungsthermostate, HM Wandthermostate, Intertechno Funksteckdosen, 10" Tablet als Wanddisplay, KeyMatic, Fensterkontakte, Fensterkontakte umgebaut als Wassermelder und Briefkastenmelder, Aussenthermostat, Anwesenheitssteuerung über Fritz Box, Google Home usw. usw.

Pati_Alpha

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). :)

Per

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  :-\.