Tixi.Com

Wenn ich mir Ihre GetJob-Meldung ansehe, dann muss neben der Process-LED auch mindests noch die Data Out LED geleuchtet haben !?
Wenn die Line-LED nicht angefangen hat zu leuchten, dann wurde die SMTP-Session auch noch nicht begaonnen, ergo kann es auch keinen JobReport-Eintrag geben.
Dauerhaftes "Process-LED" leuchten ist ein Zeichen für die Überlastung des Modems. Hier wäre wie gesagt Ihre Projektdatei für die Auswertung nötig. Vielleicht haben Sie zuviele Prozessvariablen definiert ?

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Der JobReport range="last 24 hours" war aber leer. Kann das mit der ständig leuchtenden Process LED zu tun haben?

Hypothese: Der SMTP-Prozess hat einen Fehler der nur in einer bestimmten Situation, z.B. beim Absetzen einer Fehlermeldung, auftritt. Der Prozess bleibt hängen und es gibt keine Meldung.
(Solche Fehler kenne ich von früher, bei S12.)

Dazu gibt es den JobReport und die Event-Kaskadierung über OnError.

Aus dem JobReport müsste hervorgehen, ob es sich um Einwahlprobleme (Modem connection failed, NO CARRIER), oder E-Mail-Probleme (SMTP server, last command) handelt.

Ich würde zunächst 2 Wahlwiederholungen mit 180s Abstand einbauen, was in den meisten Fällen schon ausreicht, um sporadische Einwahlprobleme zu kompensieren.
Um ganz sicher zu gehen, würde sich dann eine OnError Kaskadierung anbieten, die bei E-Mail-Problemen eine Meldung per SMS oder Fax absetzt. Die Anwahl eines anderen ISP im Fehlerfall ist derzeit leider nur mit großem Aufwand möglich, siehe Beispielprojekt.
Die besten Erfahrungen haben unsere Kunden mit der Kombination Freenet (Einwahl) und GSM (E-Mail) gemacht.

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Ich hatte Glück und am Sonntag ist der Fehler am Referenz-Modem aufgetreten, die Mail aus dem Modem in Munster, mit gleichen Projekt, ist aber angekommen.
Das Problem trat in SMTP-Verbindung auf.
Die Process LED war an, aber die Line LED aus.

<GetJob>
<Modem_Mode _="Started"/>
...
<SMTP_Client _="Started">
<Job_3>
<Time _="2007/09/02,01:10:01"/>
<Type _="2"/>
<Priority _="1"/>
<Origin _="currently unavailable (running)!"/>
</Job_3>
</SMTP_Client>
...
</GetJob>

Heute kamen beide Mails, die aus dem Labor und die aus Munster.

Für mich sieht es wie eine kurzfristige Störung beim Provider aus.
Gibt es Erfahrungen über die Häufigkeit solcher Störungen?
Haben Sie eine Tip, wie ich das im Modem erkennen kann?

Da gibts nur drei Gründe:
1. Es gibt keinen EventHandler mit dem namen "DataReport", denn dann erscheint der Scheduler-Aufruf auch nicht im EventLog.
2. Das EventLog wurde ausgelesen, bevor das Event vollständig erstellt wurde.
3. Modem war überlastet, und kam dadurch nicht hinterher die Jobs abzuschließen. Ursache könnte hier der Abbruch des DoOn sein.

Ich denke nach der Umstellung auf den Variablentrigger dürfte das nicht mehr auftreten...

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Im Projekt steht
<Schedule>
<Time1 _="LogPeriod">
<Minute _="0,15,30,45"/>
</Time1>
<Time2 _="DataReport">
<Time _="01:10"/>
</Time2>
</Schedule>

Im Eventlog finde ich nur alle LogPeriod, aber kein DataReport.
Auch die "umgebenden Events sind da:
<ID_2843 _="2007/08/31,01:00:01">
<Event>
<Event _="LogPeriod" Origin="Scheduler"/>
</Event>
</ID_2843>
<ID_2844 _="2007/08/31,01:15:02">
<Event>
<Event _="LogPeriod" Origin="Scheduler"/>
</Event>

Wie kann so etwas passieren, for allem weil seit gut 14 Tagen die Reports im Probebetrieb pünktlich gekommen sind. Auch der gestrige, mit einer zusätzlichen Variablen seit vorgestern 11:00.


Den Report mit einer Variable zu triggern ist ein guter Tipp. Werde ich gleich einbauen. Ich hatte DoOn verwendet und nach ca 4 Minuten ohne [/DoOn] abgebrochen.

Wie sah es mit dem Event-Log aus ? Wurde das Event getriggert ?
Waren aktive Jobs im Modem ? [<GetJob/>]


Was meinen Sie mit "starte Report manuell" ? Das Auslesen per ReadLog, oder das Anstoßen des Versands per "DoOn" ? Letzters kann, wenn man die Rückantwort nicht abwartet, zu einer längeren Blockierung der Rufannahme führen. Wir empfehlen daher den Versand besser druch eine Variable zu triggern, die man Remote setzen kann.

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Heute blieb der tägliche Report des Modems aus.
Remote login war erfolgreich, aber kein Eintrag im JobLog

Dann startete ich den Report manuell, doch es kam innerhalb von 5 Minuten keine Antwort. So habe ich die Verbindung abgebrochen.

Der zweite Anruf schlug fehl. Auch 20 Minuten später keine Antwort vom Modem. Doch inzwischen habe ich einen Ansprechpartner vor Ort und weiß wie die LEDs standen:
Power an, Prozess an, Line an, Data out aus, Modem Mode aus.

Power off, Telefonstecker raus, Power on Telefonstecker rein
hat geholfen.

Jetzt geht es wieder!
Der Anstoß lief in folgenden Schritten:

Sicherung aus.
Stecker aus TAE-Dose ziehen.
Sicherung ein.
Stecker in TAE-Dose stecken.

Darauf wurde der Datenreport von 02:10 geschickt und das Modem war erreichbar.

Melde mich später wieder, wenn die eigentliche Ursache besser eingegrenzt ist.

OK, die Modemdaten sind aktuell, es handelt sich also um keinen bekannten Fehler.

Das Dauerleuchten der Process-LED ist ein Zeichen dafür, daß das Modem ausgelastet ist, und dadurch keine Rufe mehr annehmen kann.
Ob dieser Zustand durch das Lesen des Logfile zum ungünstigen Zeitpunkt hervorgerufen wurde, oder das Projekt generell zu umfangreich ist, kann ich erst nach Erhalt der Projektdatei beurteilen.

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Das erste, jetzt ausgebute Modem:
<ProdName _="HM71"/>
<Firmware>
<Version _="2.2.12.0"/>
<Date _="2006-11-15 17:51:34"/>
</Firmware>
Das zweite erreiche ich ja nicht, doch sollte das Gleiche sein.

Das Joblog um zu sehen, was nicht geht. [<ReadLog _="JobReport" ver="y"/>]

Die Originalgröße weis ich nicht mehr. Jetzt lese ich 78 Zeilen mit insgesammt 1660 Zeichen. Ist eigentlich nicht so groß.
Ich vermute eher, dass es an einem ungünstigen Timing mit Senden, SPS und Anfrage gelegen hat.

Das könnte ein Problem sein, denn ich nutze mytixi, ein Perl-Script unter SuSE 9.3. Allerdings funktioniert es biser problemlos.
Wenn ich ein spezielles Verhalten entdecke, so wird das berücksichtigt, doch ich weiß nicht ob ich schon alles entdeckt habe.

Beim ersten Mal sah es wie folgt aus.
Power: an, Process: an, MPI: an und flackern, die anderen sind aus.

Ja, aber erst möchte ich es mit aus/ein versuchen und weitere Indizien sammeln.

Bitte teilen Sie uns noch den Modemtyp und die FW-Version mit.


Haben Sie ein Daten- oder ein Systemlogfle gelesen ?
Wie groß war es ?
Nutzen Sie TILA oder TICO ?
Ist Ihnen der LED-Zustand am Gerät bekannt ?
Würden Sie uns das Projekt inkl. Rufnummer per Mail zukommen lassen ?


Eigentlich müsste ein simples aus/ein das Modem reaktivieren.
Wenn das nicht hilft, dann ein Werksreset über den Service Button (siehe Hardware-Handbuch Kap. 14.2.2).

_________________
Tixi Support Team

E-Mail-Support, Mo-Fr, 9:00 - 17:00: Tixi-Support@tixi.com
techn. Hotline, Mo-Fr, 9:00 - 12:00 und 13:00 - 17:00: 0900-100 90 11 für 2€/min

Hallo, ich habe ein Modem als Datenlogger eingebaut. Es hat recht gut funktioniert, doch jetzt antwortete es zum zweiten Mal nicht mehr. Genauer gesagt, nachdem eine Sitzung mit der Ausgabe eines größeren Logfiles abgebrochen wurde reagiert es einfach nicht und das rufende Modem meldet NO CARRIER.
Beim ersten Mal habe ich das Modem getauscht, weil Aus- und Einschalten nicht geholfen hat. Das Neue hat mit dem alten Projekt wieder funktioniert. Diese Methode ist jedoch unbefriedigend, zumal dazu eine Tagesreise nötig ist.

In meinem Büro kann ich das Fehlverhalten nicht nachstellen, allerdings habe ich dort auch keine MPI-Verbindung.
Weder mit dem jetzt eingebauten vor dem Tausch, noch mit dem ausgetauschten gelingt es mir den Telefoneingang zu blockieren.

Woran kann das liegen?
Was muss jemand vor Ort tun um das Modem wieder flott zu bekommen?