Hallo,
ich suche eine Möglichkeit eine vorhandene Meldung (wie z.B. „[FHZ1x00PC] = Write function failed (win error code: 5)“) zu triggern.
Irgendwie finde ich nix - brauche einen Impuls
DANKE
Ich glaube, der Grund warum noch niemand geantwortet hat ist, dass nicht ganz klar ist was du beabsichtigst.
Einen Log-Eintrag erzeugst du mit IPS_LogMessage.
Oder meintest du etwas anderes? 
Danke für die erste Antwort.
Vielleicht sehe ich wirklich den Wald vor lauter Bäumen …
Ich möchte allerdings Meldungen, welche von IP-SYMCON erzeugt werden auswerten und einem Script zuweisen.
Praktisch wenn die Meldung „kommt“ Script ausführen.
Bei der Meldung „[FHZ1x00PC] = Write function failed (win error code: 5)“ möchte ich gern mein Reboot -Script ausführen.
Derzeit mache ich dies über meine Überwachungen der verschiedensten Temperaturen. Wenn sich hier keine 15 Minuten lang geändert hat REBOOTE ich.
Funktioniert auch gut, allerdings könnte ich bei obigem Fehler direkt rebooten ohne 15MIN warten zu müssen.
Wäre es nicht sinnvoller, nach der Ursache des Problems zu suchen? Es ist nicht normal dass man den Rechner dauernd neu starten muss.
Hallo Sokkederheld,
vielen Dank für Deine Antworten - aber hilft mir leider nichts.
Das Problem mit dem abgesetzten FHZ über die FritzBox ist nicht DAUERND sondern nur ca. 1 mal im Monat.
Problem war diese Woche halt nur, dass es genau 6:30Uhr früh los ging und mein Frühstücksradio somit nicht startete.
Ich hatte gehofft bzw. hoffe immer noch, dass es möglich sein sollte EINE MELDUNG WELCHE IM IPS GELOGGT WIRD auch auswerten zu können und ein Script zu starten.
Hast du denn das mit dem Event Control (mein letzter Beitrag) mal probiert? Da kannst du ja überwachen wenn sich der Status deiner FHZ-Instanz ändert und dann per IPS_GetInstance prüfen, ob sie fehlerhaft ist.
Hallo,
wenn es um die Meldung „[FHZ1x00PC] = Write function failed (win error code: 5)“ geht habe ich vielleicht einen Tipp.
Ich habe das gelegentlich mit dem IPS RGB Modul. Der benutzt einen virtuellen COM-Port zur Ansteuerung. Manchmal, wenn ich meine virtuelle IPS Maschine „anhalte“ kommt es da zu Problemen, so dass es hilft, das Gerät zu trennen, den Port zu löschen und das Gerät wieder anzustecken - oder natürlich ein Reboot :rolleyes:.
Vielleicht belegt auch ein anderer Dienst kurzzeitig den Port und stört damit IPS?
Ich weiß, dass dieser Tipp vielleicht nicht direkt auf dein Problem zutrifft, aber eventuell gibt es einen Denkanstoß damit Du das Problem lösen kannst.
Gruß
Thorsten
Hallo Torsten,
genau richtig erkannt, all diese Lösungen beheben das Problem.
Ich möchte nur gern „SCHNELL“ zu einer Lösung kommen können in dem ich diese MELDUNG auswerten kann.
Ich suche einen Weg die MELDUNG als Trigger zu nutzen.
Gab’s es da fruher nicht was wie ein „watchdog“ ?? (IPS 1.0)
Ich verstehe wirklich nicht was dagegen spricht, den von mir vorgeschlagenen Weg über das Event Control zu gehen… schneller und einfacher geht es eigentlich nicht. De facto ist das genau was du machen willst: Auf das Ereignis, dass die Instanz einen Fehlerstatus einnimmt, zu reagieren.
Warum du nun unbedingt den Umweg über eine Textmeldung nehmen willst, ist mir ehrlich gesagt schleierhaft. Schneller oder einfacher wird es dadurch jedenfalls nicht.
Er kann sich ja seine Textmeldung in dem Eventscript ausgeben lassen, das Logfile regelmäßig pollen und dann die gewünschte Aktion ausführen. Sinn macht das zwar überhaupt nicht, macht ggfls auch den PC zu, aber übt beim programmieren.
Tommi
Auch richtig! Hatte ich auch schon ausprobiert, leider war das scheinbar out of spec bei meiner W2008-Hyper-V Lösung - für mich zu risikobehaftet. Da erscheint mir meine Überwachung der Temperaturänderungen wesentlich zuverlässiger. Nur habe ich da halt einen gewissen „Toleranzzeitraum“, bei mir 15Minuten.
Wenn ich nun die VORHANDENE MELDUNG im IPS „[FHZ1x00PC] = Write function failed (win error code: 5)“ auswerten könnte, kann ich im OPTIMALFALL 14:59 Minuten gewinnen.
Hallo Sokkederheld:
Wenn Deine Lösung funktioniert wäre das ja fast zu einfach. Bei meinen, zugegebenermaßen schon etwas zurückliegenden Beobachtungen, hat die INSTANZ keinen Fehler gemeldet.
Ich werde aber jetzt auf alle Fälle Deinen Vorschlag umsetzen.
Hallo Sokkederheld und Tommi,
vielen Dank für Eure Bemühungen.
Meine Erinnerungen haben mich aber leider nicht getäuscht.
Die Splitter Instanz FHZ1x00PC ändert nicht Ihren Status und kann (jedenfalls von mir) somit nicht überwacht werden, bei Fehler „[FHZ1x00PC] = Write function failed (win error code: 5)“.
Hoffentlich gibt es einen Trick, den ich noch nicht kenne.
Wenn die Instanz einen Fehler hat (so dass sie nicht mehr funtkioniert), aber den entsprechenden Status nicht einnimmt, wäre das dann m.E. ein Fall für eine Bugmeldung.
Hallo Sokkederheld,
ich habe mal eine Mail an IPSYMCON gesandt - mal sehen ob ich eine Rückinfo bekomme.
Die Idee mit den Events und dem überwachten Instanz-Status ist gut, aber was haltet ihr davon, noch eine Stufe früher den Fehler abzufangen?:
Eigentlich sollten doch alle Wert-und-Aktion-Schreibe-Befehle an die Module einen boolschen Status zurückliefern, der z.B. genutzt werden könnte, eine globale Fehlerstatus-Variable zu setzen, die wiederum einen Watchdog-Prozess triggert. Das dürfte doch noch schneller sein aber zumindest immer gleich schnell, weil vom gleichen IPS-internen Ereignis getriggert und geht nicht erst lange übers (evtl. erst verzögert geschriebenes wenn nicht sogar deaktivierte) Log. Leider kenne ich den ursprünglichen Befehl nicht, der zu der eingangs im Thread benannten Fehlermeldung führte. Könnt ihr den bitte mal nennen?
Sicher kann man damit nicht alle Fehler an FHZs abzufangen. Ich habe z.B. so ein- bis zweimal im Monat einen FHZ-Fehler „der höheren Art“, wo es im IPS gar kein Log o.ä. gibt. Der wirkt sich so aus, dass die Dinger in Richtung IPS zwar „ganz normal“ erscheinen, in Wirklichkeit aber nichts mehr funktechnisch tun. Einmal Strom ab- und wieder anschalten und schon gehts wieder. (z.B. per Homematic-Funksteckdose, getriggert über Timeout des letzten Empfangszeitpunktes eines per FHZ empfangenen Sensorwertes). Auch ein schöner Fall für einen Watchdog-Prozess, aber eben eine andere Fehlerklasse.
Dieser Nicht-Funk-Fehler treten übrigens an allen auf LAN umgebauten FHZs auf. (Xircom-Adapter). Per Ping sind sie auch im Fehlerfall konstant weiter erreichbar, nur wirken eben nicht funktechnisch auf ihre Aktoren, was leider den IP-Watchdog-Prozess als Fehleranalysator ausschließt.
Gruß Gerd
Das hier sollte in diesem Fall doch auch funkionieren, oder??
Gruß
Jens