Monitor mit Datenbank-Unterstützung

[Magnet]

Achso, mir war nicht ganz klar was das nooutput bewirkt, aber die erste Lösung scheint ja zu funktionieren.

[jhr-online]

Aha aha, gecheckt und getestet :-) Die Ausgabe in den Mails erzählt mir jetzt nur noch von received cookies. Das ist doch nett und scheint was zu bewirken, auch wenn ich immer noch nicht weiß, warum ich das halbstündlich aufrufe. Falls du mir Lust hast zu erklären, gerne, wenn nicht, kann ich damit vermutlich so gerade eben leben :-)
Einzig ernsthaft offene Frage ist, warum mir Cron darüber immer ne e-mail schickt. Hab ich da die Reports zu empfindlich eingestellt? Falls jemand das zu beantworten versucht, auch gerne :-) (Debian sarge)

[ManuelW]

Das steht alles in dem Thread hier.

Man muss die nooutput Geschichte nur ausführen, wenn man sich
alarmieren lassen möchte, und eine volle Dokumentation in der DB wünscht.

Zur Alarmierung per Mail/SMS sollte man das ganze Minütlich ausführen
lassen, da so aller Min. geprüft wird, ob ein Alarm eingegangen ist der
von jemand Abonniert wurde...

Wünscht man keine Alarmierung sondern rein eine gefüllte und bearbeitete
DB dann reicht es das halb- oder ganzstündlich auszuführen, da beim
Aufruf der Seite im Hintergrund immer noch Aktionen wie Zurdnungen
und verschiedene Manipulationen an den Datensätzen ausgeführt werden.

Wer das alles nicht möchte und einfach nur ab und an in den Monitor schaut, der braucht das auch nicht auszuführen.

[jhr-online]

Ach so, jetzt verstehe ich den Sinn der Funktion erst. Ich danke dir für die Erklärung!

jhr

[ManuelW]

Keine Ursache :)

@ rhein-erft
Wie isses denn mit dem Patch ?

[nepomuck]

Original geschrieben von jhr-online
Das Problem ist, dass unterschiedliche ZVEI gesendet werden, aber nur die letzte erkannt wird.

Das kann ich jetzt überhaupt nicht nachvollziehen. Ich setze Monitor momentan ausschließlich als ZVIE-Meldeempfänger ein und bekomme stes die kompletten Alarmierung mit. Das geht bei uns immer nach dem selben Schema: KBI - FW - KBM und bei größeren Alarmen KBI - FW - FW - KBM - KBR - NaST. Ich kann im LOG sehen, dass alle Schleifen korrekt dekodiert werden und das System keine ausläßt. Bei Kleinalarmen läuft die Alarmierung hintereinander, ohne Pause und ohne MVF-Ton für die Sirenensteuerung oder Pieptönen für Wecker durch.

Kann das bei dir einen anderen Grund haben?
In meiner Config sind alle Module abgeschaltet, ausser ZVIE auf Kanal L. -- auf Kanal R hört Monitor gar nicht.

Andreas

[Buebchen]

Das liegt wohl im mySQL Support. Die ZVEI Routinen arbeiten so, das intern ein Zähler läuft, der auf die Auslösung des Melderwecktons warten soll. Wird die nächste Folge dann innerhalb dieser Zeitspanne empfangen schreibt der monitor das zwas auf dem monitor, aber wohl nicht in die mySQL Datenbank.

Zumindest habe ich die Sourcestelle gefunden, die vermutlich genau dafür da ist. Da die Sirenentonerkennung nicht im ZVEI Modul stattfindet ist das alles ein wenig durcheinander. Zumindest, wenn man es halt als Aussenstehender dann liest.

Die eigentlich Funktion des monitor ist schon so ganz korrekt.

[jhr-online]

Entschuldigt, aber ich muss noch einmal nachhaken. ManuelW hat gesagt, wenn ich das richtig in Erinnerung habe, dass es eine Lösung für die unsinnigen Ausgaben in der Zeit-Spalte gibt, oder? Ich hab jetzt echt noch mal gesaucht, sowohl um Quelltext um den Fehler zu finden, als auch hier im Forum. Weiß da noch einer was? Ausgabe war sowas wie
:0:9::6: statt Datum/Zeit.

jhr

[ManuelW]

ja ne, so hab ich das nicht gesagt :)

es gab schoneinmal jemand mit diesem problem. der hatte sich nach
der fehlersuche aber nicht mehr gemeldet und ich bin davon ausgegangen,
das er es gelöst hat. woran es aber nun lag weiss ich leider nicht.

wie stehen die dati denn in deiner datenbank drin ?
ich könnt mir vorstellen, das eine neuere mysql version die automatisch
erstellten zeitschlüssel anders einträgt.

[jhr-online]

Exakt so aus einer Statuszeile rauskopiert (hoch lebe phpmyadmin):

2005-09-19 21:11:17

ansonsten kann ich auch keine Unregelmäßigkeiten erkennen...

[ManuelW]

nja, dann is klar.
die datumsspalte muss so ausschauen

20050726114148

keine trenner dazwischen.

schau mal ob das feld timestamp(14) ist.

[jhr-online]

Meine mySQL-Kenntnisse wachsen noch. Bevor das zu einem Rate-Antwort-Spiel wird:

Feld: zeit
Typ: timestamp
Kollation:
Attribute: ON UPDATE CURRENT_TIMESTAMP
Null: Ja
Standard: CURRENT_TIMESTAMP
Extra:

Kannst du damit was anfangen? Also ne "(14)" steht da auf jeden Fall nicht.

[ManuelW]

nach "typ" kommt eingentlich noch nen feld "länge" und da sollte ne 14 drin stehen.

edit: achso, du musst natürlich noch auf bearbeiten klicken (Bleistift) in
der zeitzeile

[jhr-online]

Das kann ich auch noch fünf mal reinschreiben und dann auf Speichern klicken und es bringt doch nix. Es lässt sich einfach nicht eintragen. :-(


zur Info:
phpMyAdmin 2.6.2
MySQL 4.1.11-Debian_4Sarge1-log

[ManuelW]

hmm, ich hab noch ne mysql 4.0.15, ob das in neueren versionen anders gespeichert wird ?

vielleicht kann jemand in den monitor zusätzlich einbauen, das der
timestamp nicht von der db automatisch erzeugt, sondern vom monitor
selber mit eingetragen wird. so wäre es dann bei allen einheitlich.