Monitor mit Datenbank-Unterstützung

[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.

[jhr-online]

Das ist alles ein bisschen doof... und

Wenn das Feld vom Typ 'ENUM' oder 'SET' ist, benutzen Sie bitte das Format: 'a','b','c',....
Wann immer Sie ein Backslash ("\") oder ein einfaches Anführungszeichen ("'") verwenden,
setzen Sie bitte ein Backslash vor das Zeichen. (z.B.: '\\xyz' or 'a\'b').

ist das einzige, das zu dem feld noch angegeben ist...

Also hast du keinen Weg, der mir jetzt helfen könnte? Im monitor kann ich nämlich gar nicht rumspielen. Da müsste man Buebchen bitten... ;-)

[ManuelW]

ja ne, ich sag ja, da müsste man den quellcode von dem mysql patch ändern, das der monitor das vormat direkt vorgibt beim eintragen.
das wird ja jetzt zZ von der db selber gemacht.

[ManuelW]

So hab mal nachgeforscht, seit der mysql 4.1 wurde tatsächlich das
format für den timestamp geändert.

Hab hier schnell nen kleinen fix geschrieben, kann aber nich testen
ob das so klappt.

einmal bei ca. zeile 153 unter
while...
{

#--------- schnipp
// Berichtigung Zeitformat ab mySql 4.1
if( $row["zeit"]{5} == '-' )
{
$row["zeit"] = substr($row["zeit"], 0, 4).substr($row["zeit"], 6, 2).substr($row["zeit"], 10, 2).substr($row["zeit"], 14, 2).substr($row["zeit"], 18, 2).substr($row["zeit"], 22, 2);
}
#-------------------

und ca. zeile 290, ebenfalls direkt unter
while...
{

#---------schnipp
// Berichtigung Zeitformat ab mySql 4.1
if( $row["zeit"]{5} == '-' )
{
$row["zeit"] = substr($row["zeit"], 0, 4).substr($row["zeit"], 6, 2).substr($row["zeit"], 10, 2).substr($row["zeit"], 14, 2).substr($row["zeit"], 18, 2).substr($row["zeit"], 22, 2);
}
#---------------

versuch mal ob das klappt. Kann aber sein das das timestamp feld
dieses format garnicht mehr zulässt.

[Buebchen]

So, lese die Postings erst jetzt, aber dazu kann ich mal was sagen ;-)

Die TIMESTAMP Felder sind tatsächlich irgendwann in der (Standard-)Formatierung geändert worden. Die API gibt eigentlich immer nur Textfelder zurück. Egal ob es ein Zeit oder Zahlenwert ist. Das ist je nach Server-Version unterschiedlich. Ich meine der Wechsel kam zwischen der 4.0.x und 4.1.0.

Die einfachste Lösung wäre da wohl, eine Formatierungsanweise ins SQL "Select * ..." einzubauen, daß den Ausgabestring immer fest formatiert (Hab ich bei mir auch so gemacht).

Mit dem Schreiben in die DB kann ich da nix dran ändern. Denn intern speichert der MySQL Server den Wert in seinem eigenen Format ab (Sekunden ab 01.01.1970).