Hallo!
Ich nutze pushover schon für meine Waschmaschine die wenn sie fertig ist eine Meldung auf mein Handy schickt,klappt Top!
Nun würde ich gerne bei zu niedrigem Batterie stand auch per Push informiert werden,
Habe im Netz was gefunden
Kann man das einfach nehmen ?
Ab welchen Level warnt der wandsender überhaupt ?
#Pushover-Batteriewarnung
define BatteriewarnungNotify notify .*:[Bb]attery:.* { if("%" !~ m/ok/) { system ("curl -s -F 'token=am4uA61Gx2Jw9GA24rePRyMJw8B3hz' -F 'user=u4zDygNRGFbQUSmcxXj6fGsWJl9d93' -F 'message=Batteriewarnung\n@ %' https://api.pushover.net/1/messages.json")}}
Gruß
Jonny
Hallo Jonny,
ZitatAb welchen Level warnt der wandsender überhaupt ?
welcher wandsender?
manchmal ist dies einstellbar - hast du einmal die Register angesehen?
ZitatKann man das einfach nehmen ?
wenn es das ist was du willst - ja.
Mir würde es nicht genügen. Batteriewarnungen werden gerne von Usern verarbeitet - wobei die sowieso eher langsam sind. Es ist auch eher eine Warnung - errors (weil nicht so einfach ersichtlich...) werden dabei gerne ausgelassen.
Ausser acht gelassen werden hierbei Alarme des ActionDetector (Batterie nicht low sondern leer) sabotage, power Error, motor error und mehr.
ggf auch Kommunikationsfehler - können auch wichtig sein. Ich würde mir daher immer einen Systemalarm senden. HMInfo macht dies (incl Batterie error)
wenn du also
define hm HMInfo
schon hast kannst du
#Pushover-SystemError
define SystemNotify notify hm:Err.* { system ("curl -s -F 'token=am4uA61Gx2Jw9GA24rePRyMJw8B3hz' -F 'user=u4zDygNRGFbQUSmcxXj6fGsWJl9d93' -F 'message=SystemEvent\n@ %' https://api.pushover.net/1/messages.json")}
Gruss Martin
Hallo Martin!
Oha das soviel konfigurierbar ist hätte ich nicht gedacht
Habe einen HM-PB-6-WM55 und mehrere HM-PB-2-WM55
Wie muss ich mir denn eine hminfo Meldung vorstellen ? Und wann kommt die immer ?
Dann noch eine kleine offtopic frage :
Wenn ich ein Gerät (ZB. HM-PB-2-WM55) umbenenne in Name....
Werden dann automatisch alle Sachen die ich mit dem verknüpft habe angepasst ?
Gruß
Jonny
Hi Jonny,
ZitatWie muss ich mir denn eine hminfo Meldung vorstellen ? Und wann kommt die immer ?
probiere es - definiere ein HMInfo - wenn es nicht gefällt, lösche es wieder
define hm HMInfo
attr hm autoUpdate 0:30
attr hm event-on-change-reading .*
dann wird alle 30 sec der status geprüft - das sollte für einen push-service genau genug sein.
Die bekannten "fehler" sind automatisch vorkonfiguriert - auch Batterie.
schaue einmal in
http://fhem.de/commandref.html#HMinfo
insbesondere "variablen"
Gruss Martin
Hallo Martin,
hab bei mir deinen Vorschlag umgesetzt und das funktioniert auch super.
Ein Problem hab ich damit aber noch :
Wenn ein Fehler wieder vorbei ist, löscht hminfo das jeweilige ERR Reading. Leider erzeugt das Löschen eines Readings kein Event. Deshalb sehe ich keine (einfache) Möglichkeit, eine Entwarnung per Mail zu schicken.
Hast du dafür eine Idee bzw. wäre es möglich, vor dem Löschen das Reading erst nochmal auf einen Leerstring zu setzen, damit man das Ereignis mitkriegt?
Gruß
Leo
Hört sich sinnvoll an. Werde ich mir ansehen.
probier mal
Zitat von: martinp876 am 28 Mai 2014, 12:59:26
Hi Jonny,
probiere es - definiere ein HMInfo - wenn es nicht gefällt, lösche es wieder
define hm HMInfo
attr hm autoUpdate 0:30
attr hm event-on-change-reading .*
dann wird alle 30 sec der status geprüft
Laut Anleitung wäre das alle 30 Minuten, nicht Sekunden?
Anonsten habe ich das jetzt auch mal so eingeführt und werde auch dabei bleiben, das ist wirklich ne sehr gute Möglichkeit um sich über Vorgänge im System informieren zu lassen! Viele Probleme die sonst unter dem Radar waren werden jetzt direkt gemeldet. Einzig für "dead" Devices wird soweit ich sehen kann keine Notifikation generiert, die werden nur in ERRactNames gesammelt. Ist das Absicht oder was ist hier der "Best practice"?
Gruß Marcel
Korrekt, Minuten. Min 1min sollte mehr als reichen.
Dead sollte auch erkannt werden. Das sind error actors
Zitat von: martinp876 am 12 Januar 2016, 21:36:44
Dead sollte auch erkannt werden. Das sind error actors
Erkannt wird es in ERRactNames, aber soweit ich das im Code sehe wird kein Event dafür auf @updates gepushed.
Super Sache! Ich habe mir ein notify für pushbullet auf hm:Err.* eingebaut. Ich würde ja gerne mal testen welche Variablen sinnvoll in der Nachricht wären. Gibt es eine Möglichkeit einen Fehler zu produzieren? Wenn ich bei einer meiner Steuerungen die Batterie rausnehme sollte das ja zu einer Meldung führen oder?
Zweite Frage: Wo sehe ich eigentlich die Nachrichten vom hm? HmInfo hat ja kein eigenes logfile. Sollten die Nachrichten im logfile auftauchen oder wo kann ich die sehen?
Grüße desmo
Zitat von: desmoloch am 13 Januar 2016, 13:33:30
Super Sache! Ich habe mir ein notify für pushbullet auf hm:Err.* eingebaut.
"ERR" muss hier groß sein.
ZitatIch würde ja gerne mal testen welche Variablen sinnvoll in der Nachricht wären. Gibt es eine Möglichkeit einen Fehler zu produzieren? Wenn ich bei einer meiner Steuerungen die Batterie rausnehme sollte das ja zu einer Meldung führen oder?
Naja, wenn's irgendwann als tot erkannt wird schon, aber wie ich oben geschrieben habe, derzeit funktioniert das glaub noch nicht. Du kannst das Attribut "sumERROR" einfach abändern mit "battery:xyz" statt "battery:ok", zum Beispiel, dann wird eben "ok" als Fehler signalisiert.
ZitatZweite Frage: Wo sehe ich eigentlich die Nachrichten vom hm? HmInfo hat ja kein eigenes logfile.
Definier doch einfach ein LogFile? Kein Device kommt von Haus aus mit einem Log, nur AutoCreate legt Dir vielleicht welche netterweise welche an.
Gruß Marcel
Zitat von: MarcelK am 13 Januar 2016, 14:29:57
"ERR" muss hier groß sein.
Naja, wenn's irgendwann als tot erkannt wird schon, aber wie ich oben geschrieben habe, derzeit funktioniert das glaub noch nicht. Du kannst das Attribut "sumERROR" einfach abändern mit "battery:xyz" statt "battery:ok", zum Beispiel, dann wird eben "ok" als Fehler signalisiert.
Definier doch einfach ein LogFile? Kein Device kommt von Haus aus mit einem Log, nur AutoCreate legt Dir vielleicht welche netterweise welche an.
Gruß Marcel
Oh OK danke dann muss ich das noch von Err auf ERR ändern. Dann war meine Überwachung ja bisher in aktiv ;)
Das mit dem Attribut ist ne super Idee, das probiere ich nachher mal aus.
Auf die Idee, per Hand ein log anzulegen, kam ich noch gar nicht. Ich habe mich jetzt fast ein Jahr nicht mehr mit fhem beschäftigt, wird also mal wieder Zeit. Eins muss man (leider) sagen: Zum perfekten einstellen von fhem muss man sehr viel googeln, Tutorials lesen und sich durch die Commando ref wühlen. Eine Oberfläche die einen dabei etwas besser unterstützt (Beispiel: plot löschen) fände ich klasse. Da ihr das hier aber alle kostenfrei macht, der Support und die Community super ist, komme ich trotzdem ganz gut zurecht ;) danke euch allen!
Interesse halber: Wenn es kein logfile gibt, kann ich die Nachrichten trotzdem irgendwo sehen?
Zitat von: desmoloch am 13 Januar 2016, 16:17:23
Auf die Idee, per Hand ein log anzulegen, kam ich noch gar nicht. Ich habe mich jetzt fast ein Jahr nicht mehr mit fhem beschäftigt, wird also mal wieder Zeit. Eins muss man (leider) sagen: Zum perfekten einstellen von fhem muss man sehr viel googeln, Tutorials lesen und sich durch die Commando ref wühlen.
Ja, geht mir nicht anders. FHEM ist nichts für Gelegenheitsuser, auch wenn vieles mittlerweile schon besser ist.
ZitatInteresse halber: Wenn es kein logfile gibt, kann ich die Nachrichten trotzdem irgendwo sehen?
Im Event Monitor. Vielleicht den Filter auf "hm.*" setzen.
Gruß Marcel
Zitat von: martinp876 am 04 Januar 2016, 18:22:32
probier mal
Martin, hast du was geändert? Bei mir ist im Code von hminfo nämlich keine Änderung angekommen.
Hab's grad aber auch nochmal probiert: Die Entwarnung nach dem Wechsel meiner Batterie wirft weiterhin kein Event.
Gruß
Leo
Es sollte eine Entwarnung kommen.
Zitat von: martinp876 am 13 Januar 2016, 21:09:14
Es sollte eine Entwarnung kommen.
Der neue Code hat zumindest ein kleines Problem: Dead Devices werden nie wieder gelöscht, da das Reading nicht mehr wie früher generell gelöscht wird, aber auch nicht neu geschrieben wird wenn kein Device mehr dead ist.
$hash->{ERRactNames} = join",",@Anames if (@Anames);Gruß Marcel
Edit: das gleiche gilt auch für sumERROR Readings:
$hash->{ERR_names} = join",",@errNames if(@errNames);# and name entities
Zitat von: MarcelK am 11 Januar 2016, 10:17:41
Einzig für "dead" Devices wird soweit ich sehen kann keine Notifikation generiert, die werden nur in ERRactNames gesammelt. Ist das Absicht oder was ist hier der "Best practice"?
Als Follow-Up für zukünftige Leser, man kann dead Devices ganz einfach überwachen wenn man sumERROR um "alive:unknown:switchedOff" ergänzt, leider fehlt das per Default. Für die Auswertung verwende ich jetzt eine Kombi aus Notify
define SystemCheck notify HM:ERR.* { HM_Error($NAME, $EVENT) }und etwas MyUtils Perl code:
sub HM_Error($$)
{
my ($hminfo, $event) = @_;
my $text = "";
if ($event =~ /^ERR_[^_].*/) {
# Event caused by sumERROR
$text = "$event:".InternalVal($hminfo, "ERR_names", "");
}
elsif ($event =~ /^ERR__protocol:.*/) {
# Protocol error
$text = "$event:".InternalVal($hminfo, "ERR__protoNames", "");
}
elsif ($event =~ /^ERR__unreachable:.*/) {
# Unreachable
$text = "$event:".InternalVal($hminfo, "W__unreachNames", "");
}
else {
$text = "Unknown event: $event";
}
sendPushMsg "System event", $text;
}
Vielleicht hilft das ja jemandem.
Gruß Marcel
Zitat von: martinp876 am 13 Januar 2016, 21:09:14
Es sollte eine Entwarnung kommen.
Hallo Martin,
zumindest ERR_battery wird offenbar nicht zurückgesetzt. Das wurde bei mir am 20.01. auf "low:1" gesetzt. Gestern habe ich die Batterie gewechselt - das Reading bleibt aber unverändert.
Batteriestatus aller HM-Devices ist ok:
fhem> list TYPE=CUL_HM battery
az_Sensor 2016-01-25 20:17:53 ok
az_Thermostat 2016-01-25 20:18:02 ok
bd_Thermostat 2016-01-25 20:18:22 ok
dg_Thermostat 2016-01-25 20:19:24 ok
hm_RC4_Tobi 2016-01-24 17:41:36 ok
ku_Switch1 2016-01-24 18:12:09 ok
te_Sensor 2016-01-25 20:19:49 ok
wz_Thermostat_E 2016-01-25 20:17:07 ok
wz_Thermostat_S 2016-01-25 20:19:23 ok
wz_Wandthermostat 2016-01-25 20:08:34 ok
HMinfo autoUpdate aktiv, doch:
fhem> list hm
Internals:
CHANGED
ERR_names wz_Thermostat_S
I_HM_IOdevices disconnected: myCULv3;ok: hmusb;
NAME hm
NR 143
STATE updated:2016-01-25 20:32:59
TYPE HMinfo
Version 01
W_unConfRegs az_Thermostat
Readings:
2016-01-25 20:32:59 CRIT__protocol -
2016-01-20 21:43:43 C_sumDefined entities:70,device:19,channel:59,virtual:3
2016-01-25 20:32:59 ERR__protocol -
2016-01-24 14:00:52 ERR__unreachable 0
2016-01-20 21:43:43 ERR_battery low:1,
2016-01-24 13:06:58 I_actTotal alive:9,dead:0,unkn:0,off:0
2016-01-24 14:00:52 I_autoReadPend 0
2016-01-25 18:52:58 I_rssiMinLevel 59<:6 60>:8 80>:3 99>:0
2016-01-25 12:32:53 I_sum_battery ok:10,
2016-01-25 18:52:58 I_sum_motor stop:off:1,stop:80:1,stop:89:1,
2016-01-25 20:32:59 W__protocol -
Helper:
autoUpdate 300
weekplanList:
az_Thermostat_Clima
bd_Thermostat_Clima
dg_Thermostat_Clima
wz_Thermostat_E_Clima
wz_Thermostat_S_Clima
wz_Wandthermostat_Climate
Nb:
cnt 7
Attributes:
autoArchive 1
autoUpdate 00:05
configDir setup
configTempFile tempList.cfg
event-on-change-reading .*
sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorError:no,error:none,uncertain:yes,smoke_detect:none,cover:closed
sumStatus battery,sabotageError,powerError,motor
webCmd update:protoEvents short:rssi:peerXref:configCheck:models
HMinfo ist aktuell:
fhem> version
...
98_HMinfo.pm 10518 2016-01-16 11:38:39Z martinp876
Oder habe ich etwas falsch verstanden?
Tobias
Zitat von: tpm88 am 25 Januar 2016, 20:41:08
Oder habe ich etwas falsch verstanden?
Nö, nur noch ein kleiner Bug, siehe meinen Beitrag oben. Wenn Du die "if (@xyz)" jeweils am Zeilenende entfernst sollte das schon richtig funktionieren.
Gruß Marcel
Zitat von: MarcelK am 26 Januar 2016, 01:07:01
Nö, nur noch ein kleiner Bug, siehe meinen Beitrag oben. Wenn Du die "if (@xyz)" jeweils am Zeilenende entfernst sollte das schon richtig funktionieren.
Leider doch nicht ganz so einfach, die sumERROR Readings werden nicht mehr geupdated wenn ein Fehlerfall wegfällt. Anbei ein neuer Versuch eines Patches. Die Readings werden zurückgesetzt wenn der jeweilige Fehler nicht mehr da ist und beim nächsten Update dann komplett gelöscht damit die Sache etwas aufgeräumter aussieht.
Gruß Marcel
Und noch etwas, die aktuelle Implementierung führt zu so schönen Kaskaden:
2016-01-26_16:51:43 HM ERR__protocol: CmdDel:1,ResndFail:1
2016-01-26_16:52:44 HM ERR__protocol: ResndFail:1,CmdDel:1
2016-01-26_16:53:44 HM ERR__protocol: CmdDel:1,ResndFail:1
2016-01-26_16:57:44 HM ERR__protocol: ResndFail:1,CmdDel:1
2016-01-26_16:59:44 HM ERR__protocol: CmdDel:1,ResndFail:1
2016-01-26_17:00:44 HM ERR__protocol: ResndFail:1,CmdDel:1
2016-01-26_17:03:45 HM ERR__protocol: CmdDel:1,ResndFail:1
2016-01-26_17:04:45 HM ERR__protocol: ResndFail:1,CmdDel:1
2016-01-26_17:05:45 HM ERR__protocol: CmdDel:1,ResndFail:1
2016-01-26_17:06:45 HM ERR__protocol: ResndFail:1,CmdDel:1
2016-01-26_17:10:45 HM ERR__protocol: CmdDel:1,ResndFail:1
2016-01-26_17:11:45 HM ERR__protocol: ResndFail:1,CmdDel:1
2016-01-26_17:15:46 HM ERR__protocol: CmdDel:1,ResndFail:1
Aktualisiertes .diff anbei.
Edit: nochmal kleines Update.
Hallo Martin,
kannst Du Dir meine Änderungen bei Gelegenheit bitte mal anschauen? Ich will die ungern bei jedem Update wieder verlieren. Danke schön!
Beste Gruß, Marcel
Wenn mein system wieder läuft...
Ah, bist Du Hardware-technisch noch gehandicapt. Alles klar, danke für die Rückmeldung.
Besten Gruß, Marcel
nehmt doch einfach das Beispiel aus dem Wiki Alarm Modul und packt folgendes als Actor in die Einstellungen des Alarm Moduls mit rein:
{Pushover('FHEM',ReadingsVal('alarm', 'short','undef'))}
dazu dann noch in die 99_Utils:
sub
Pushover($$)
{
#Log 2,"sendPushMessage Title: $_[0]";
#Log 2,"sendPushMessage Message: $_[1]";
fhem("set pushmsg msg '".$_[0]."' '".$_[1]."'");
}
Ich hol den Thread mal wieder nach oben. Martin, schaust Dir bitte den Patch noch an?
Besten Gruß Marcel
done
Danke schön. Aber gibt's nen spezifischen Grund wieso Du diese Änderung nicht übernommen hast?
@errNames = grep !/^$/,HMinfo_noDup(@errNames);
- $hash->{ERR_names} = join",",@errNames if(@errNames);# and name entities
+ $hash->{ERR_names} = join",",@errNames;# and name entities
push @updates,"C_sumDefined:"."entities:$nbrE,device:$nbrD,channel:$nbrC,virtual:$nbrV";
# ------- display status of action detector ------
push @updates,"I_actTotal:".join",",(split" ",$modules{CUL_HM}{defptr}{"000000"}{STATE});
- $hash->{ERRactNames} = join",",@Anames if (@Anames);
+ $hash->{ERRactNames} = join",",@Anames;
Mit dem eingecheckten Code wird ERR_names und ERRactNames niemals zurückgesetzt.
Gruß, Marcel
Sollte schon. Bei meiner Installation wird der Wert gelöscht . bei dir nicht?
Nein, hier nicht. Versteh auch nicht wie das bei Dir funktionieren kann, die einzige Zeile in der ERRactNames gesetzt wird ist
$hash->{ERRactNames} = join",",@Anames if (@Anames);und diese wird nicht ausgeführt wenn @Anames leer ist. Ergo wird ERRactNames gesetzt wenn ein Actor dead ist, aber nie wieder zurückgesetzt wenn keiner mehr dead ist. Wenn Du natürlich mehrere tote Aktoren hast werden die wiederbelebten wieder gelöscht, bis auf den Letzten halt.