Idee: „Telex-Anrufbeantworter“

#1

Hallo zusammen,

ich grüble gerade über eine Erweiterung für piTelex und wollte mal in die Runde fragen, ob das außer mir überhaupt jemand braucht oder ob das nur Spielerei ist.

Idee: „Telex-Anrufbeantworter“

Ziel:
Der Fernschreiber soll zu definierten Zeiten komplett Ruhe haben (z.B. nachts), eingehende Verbindungen aber trotzdem entgegennehmen. Die Texte werden zwischengespeichert und erst später – in einer aktiven Zeit – automatisch ausgedruckt.

Rahmenbedingungen:

piTelex läuft wie gehabt.

Es kommt kein zusätzlicher Krempel an der Hardware dazu.

Alles wird über telex.json und ein zusätzliches Device („answerbox“) konfiguriert.

Grobes Verhalten
1. Zeitfenster: „active“ vs. „silent“

In telex.json gäbe es ein neues Device:

"answerbox": {
"type": "answerbox",
"enable": true,
"store_path": "answerbox/",
"weekly_schedule": {
"mon": { "active": [["07:00", "21:00"]] },
"tue": { "active": [["07:00", "21:00"]] },
"wed": { "active": [["07:00", "21:00"]] },
"thu": { "active": [["07:00", "21:00"]] },
"fri": { "active": [["07:00", "21:00"]] },
"sat": { "active": [["09:00", "20:00"]] },
"sun": { "active": [] }
},
"auto_print": true,
"auto_print_earliest": "07:05",
"print_header": true
}

Logik:

„active“-Zeiten = Fernschreiber darf laufen.

Alles außerhalb dieser Listen ist „silent“ = Anrufbeantworter-Modus.

Pro Tag können mehrere Blöcke angegeben werden, z.B.:

"mon": { "active": [["07:00", "12:00"], ["13:00", "16:00"]] }

Keine Mehrfach-Keys, sondern ein „mon“-Eintrag mit mehreren Zeitpaaren.

2. Welche Verbindungen werden „abgefangen“?

Unterscheidung:

Ausgehende Verbindungen (User ruft raus)
→ laufen immer ganz normal.
Egal ob 2 Uhr nachts oder 11 Uhr vormittags: wenn jemand bewusst wählt, hat er sich entschieden, dass der Krach ok ist. Hier mischt sich der Anrufbeantworter nicht ein.

Eingehende Verbindungen (Call von außen)
→ hier greift der Answerbox ein – abhängig von Zeit und Druckerstatus.

a) Eingehender Call in „active“-Zeit, Drucker frei

Verhalten wie heute:

i-Telex/MCP baut Verbindung auf,

WRU, Text, alles auf dem Fernschreiber,

Archive/Babelfish usw. arbeiten wie gewohnt.

Answerbox bleibt „transparent“ (kein Puffern).

b) Eingehender Call in „silent“-Zeit (Nacht), Drucker frei

Verbindung wird aufgebaut.

WRU wird normal beantwortet (siehe unten).

Alles, was danach kommt, wird nicht an den Fernschreiber weitergegeben, sondern:

in einer Session-Datei unter store_path gespeichert (z.B. 20251206_221341_from_54353.txt),

Archive, Babelfish & Co. sehen diese Daten nachts nicht.

Der lokale TTY bleibt aus / still.

c) Eingehender Call, während der Drucker besetzt ist

Beispiel:

Babelfish druckt gerade,

oder StartMsg läuft,

oder morgens werden AB-Nachrichten ausgedruckt,

oder irgendein anderer Automat hält ESC+A.

In diesem Fall, unabhängig von der Tageszeit:

Eingehende Daten werden immer vom Answerbox gepuffert,

der Call bekommt also keinen parallelen Druck,

später werden diese pufferten Nachrichten ganz normal hinten drangehängt und in einer geeigneten aktiven Phase gedruckt.

Damit gehen keine Nachrichten verloren, nur weil gerade intern Verkehr ist.

3. WRU-Sonderfall („Wer bist du?“)

Das WRU-Thema ist heikel:

Das WRU-Steuerzeichen selbst (ITA2 „WRU“) darf nicht im aufgezeichneten Text landen, sonst löst es später beim Ausdruck am eigenen TTY wieder den Hardware-WRU aus.

Gleichzeitig soll die Gegenstelle wissen, dass sie den Anrufbeantworter erwischt hat.

Geplantes Verhalten:

WRU-Zeichen von außen wird nicht gepuffert.

Es wird zum MCP durchgereicht, damit dessen WRU-Mechanik arbeitet.

Der MCP (oder ein entsprechender Teil) bekommt vom Answerbox nur ein Flag: „Für diese Verbindung läuft gerade Answerbox“.

Dann:

Ohne Answerbox: normale WRU-Antwort, z.B.:

54353 hoeck d

Mit Answerbox aktiv: WRU-Antwort um einen Zusatz erweitert, z.B.:

54353 hoeck d - answerbox

So weiß die Gegenstelle, woran sie ist, und beim späteren Ausdruck im eigenen Haus taucht kein WRU-Steuerzeichen im Text auf.

4. Morgendlicher Ausdruck („Abhören“)

In der ersten passenden aktiven Phase (z.B. ab 07:05, wenn auto_print=true):

Answerbox prüft:

Stehen noch nicht gedruckte Nachrichten im store_path?

Ist die Leitung frei (kein laufender Call)?

Falls ja:

ESC+A (Motor an),

Kopfzeile, z.B.:

TELEX ANSWERBOX
NIGHT MESSAGES 2025-12-06

dann alle gespeicherten Nachrichten hintereinander ausgeben.

Am Ende ESC+Z (Motor aus).

Während dieses Ausdrucks:

neue eingehende Calls werden ebenfalls gepuffert (s.o.), nicht parallel dazwischen gedruckt.

Wichtig: Archive (wenn aktiv) protokolliert beim Ausdruck ganz normal mit.
Wenn der Nutzer archive abgeschaltet hat, sind diese AB-Nachrichten ausschließlich auf Papier gespeichert – das wäre ausdrücklich so gewollt.

Nach erfolgreichem Printout:

die gedruckten Nachrichtendateien werden gelöscht bzw. verschoben.

5. Umsetzungstechnisch grob

Kein Code hier, nur Architektur:

neues Device answerbox in telex.json → txDevAnswerbox.

es hängt in DEVICES relativ weit vorne, damit es eingehende Zeichen abfangen kann.

es entscheidet für jede Netzseite-Session:

puffern oder durchlassen,

und ob zusätzlich eine WRU-Situation vorliegt.

morgendlicher Printout, Zeitlogik, „einmal pro Tag“-Schalter usw. laufen über idle2Hz() im Answerbox.

6. Offene Fragen an euch

Bevor ich das wirklich implementiere, würde mich interessieren, wie andere das sehen:

Braucht ihr so etwas überhaupt?

Nutzt ihr euren Fernschreiber nachts / am Wochenende als „Mailbox“?

Oder ist das Overkill und alle hängen das Ding sowieso per Schalter vom Netz?

Zeitsteuerung:

Reicht euch die Idee mit "weekly_schedule" und "active"-Zeiten?

Oder hättet ihr lieber explizit „silence start/stop“ pro Tag (würde dann intern in „active“ umgerechnet)?

WRU-Kennzeichnung:

Ist das Format wru_id - answerbox akzeptabel, oder würdet ihr etwas anderes erwarten?

Reicht euch das, um remote zu erkennen, dass die Gegenstelle auf AB läuft?

Archivierung:

Findet ihr es sinnvoll, dass der AB seine Dateien nach dem Ausdruck wegwirft und sich komplett auf Papier (und optional Archive) verlässt?

Oder würdet ihr die Rohdateien lieber dauerhaft behalten?

„Busy“-Fälle:

Wie wichtig ist euch, dass eingehende Calls auch dann gepuffert werden, wenn intern gerade Babelfish/StartMsg/etc. den Drucker blockieren?

Oder sagt ihr: „Wer da reinfällt, hat eben Pech gehabt“?

Wenn die Mehrheit sagt „brauche ich nicht“, dann lasse ich das als Idee in der Schublade.
Wenn aber ein paar Leute sagen „ja, genau sowas hätte ich gern“, würde ich das Konzept in ein echte Modul (txDevAnswerbox.py) gießen und zum Testen hier einstellen.

Meinungen, Kritik, andere Ideen?

#2

Hallo Wolfram,

die Idee eines Anrufbeantworters für PiTelex ähnlich wie beim i-Telex fände ich eine super Idee.

In der Tat ist das derzeit eine fehlende Funktion, weshalb ich PiTelex nicht 24/7 laufen lassen möchte. In der Nacht möchte ich und meine Nachbarn Ruhe haben. Wie lange ein Raspberry das tägliche Ausschalten per Hardware mitmachen würde, ist für mich fraglich, daher finde ich eine Softwarelösung ganz charmant.

Leider ist der Text in der Formatierung etwas durcheinander geraten und ich kann dem Fachchinesisch leider nicht ganz folgen, denke aber, daß ich Deine Idee schon verstanden habe.

#3

Nuja, so wie ich es gedacht habe, kannst Du z.B.
"weekly_schedule": {
"mon": { "active": [] },
"tue": { "active": [["07:00", "21:00"]] },
"wed": { "active": [["07:00", "21:00"]] },
"thu": { "active": [] },
"fri": { "active": [] },
"sat": { "active": [["09:00", "12:00"], ["14:00", "20:00"]] },
"sun": { "active": [] }
},
eingeben. Damit würde außerhalb dieser Zeiten der FS einfach ausbleiben und erst wenn eines dieser Zeitfenster kommt würde er alle Nachrichten ausspucken, die bisher gekommen sind...

Keine Nachricht wird verloren UND der Sender weiß, dass sie nicht live ausgedruckt wurde, sondern in der answerbox liegt...

Damit z.B. der Babelfish nicht einfach losrattert, kriegt er Nachrichten auch erst dann, wenn sie ausgedruckt werden.

Und Du brauchst Nachrichten nicht extra abzurufen. Sie werden automatisch ausgedruckt, wenn es Zeit ist...

#4

ok... das geht dann massiv ans MCP...

ach, ich wollte doch mal pausieren...

#5

Noch eine Idee für eine Option: Wie beim echten AB gibt es eine LED, die neue Nachrichten signalisiert und eine Taste, mit der man die „abhören“ kann. Dann kann man die ausdrucken, wenn es passt.

Sent from my iPhone using Tapatalk

#6

nö

Wenn es morgen wird, rasselt das nachts eingegangene Zeug alleine los. Keine Knöpfe, Tasten Codes...

#7

-- Loide, das ist alles andere als trivial. --

Man kann es nicht allein im MCP handeln, denn dafür isses zu kompliziert. Man müßte jedes einzelne Zeichen einzeln behandeln...

Und all die Ausgaberoutinen zu bearbeiten? Mit Verlaub, auch nicht elegant.

Der Anrufbeantworter ist alles Andere als einfach
Ich sehe keinen sauberen, bestehenden Hook, der mir zuverlässig sagt: „das hier ist sicher eingehend“.

Da ich auch noch ein paar andere Sachen habe, werde ich erstmal das Thema beiseite legen.
Vielleicht, wenn ich mich mal wieder ärgere, werde ich es wieder anfassen, aber vorerst ist es mir einfach zu erfolglos.

#8

Ich verstehe von der technischn Umsetzung leider gar nichts.
Ich zitire einmal Rolf aus einem anderen Beitrag, vielleicht gibt das einen Denkanstoß zur einfacheren Umsetzung.
Falls Du das aber nicht Umsetzen kannst oder möchtest ist das auch völlig okay, schließlich ist es ein Freizeit und Hobbyprojekt und es soll ja auch Spaß machen.

obrecht hat geschrieben: ↑Mo 9. Dez 2024, 00:08 Man kann z.B. zeitabhängig den piTelex-port auf eine andere piTelex Instanz ohne Drucker umleiten und dort das Modul "Archive" einschalten. Dann werden eingehende FS dort aufgezeichnet und nicht gedruckt.

Mit dem Mailtool aus dem Wiki kann man sich auch eingegangene FS als Mail zustellen lassen.

Oder man nimmt keine zwei piTelex-Instanzen mit Portumleitung, sondern stoppt den druckenden piTelex Prozess nachts und startet während dieser Zeit einen piTelex Prozess mit nichtdruckender, aber archivierender und ggf. mailender Erweiterung,

oder man findet eine andere individuelle Lösung

Mit piTelex geht vieles, aber es ist immer ein bisschen Basteln dabei.

damarco · #9

Was ist so schwer die Ausgabe in eine Datei umzuleiten?

#10

damarco hat geschrieben: ↑Mo 8. Dez 2025, 07:50 Was ist so schwer die Ausgabe in eine Datei umzuleiten?

Nun, es gibt einen zentralen Datenstom.

Jedes Device schmeißt seine Daten da rein und liest auch daraus.
Insbesondere auch MCP (MasterControlProgram).
Es ist kein Problem, den Ans ganz am Anfang Daten fischen zu lassen. Aber da kommen auch Steuerzeichen und alles Andere...
Und da wirds heikel: Der Ans funktioniert grundlegend. Aber weil er VOR dem MCP fischt wirds eben fishy.
Würde er nach dem MCP kommen, hätte das die Steuerdaten schon abgefischt.
Ans braucht aber nachts die Steuerdaten. Also muß er vor MCP
Nur tagsüber nicht...

Ich müßte also den Ans mit allem Wissen des MCP ausstatten und den Datenstrom umgestalten. Tagsüber MCP und nachts Ans?

Das muß ich erst genauer bedenken.
Und weil auch noch andere Probleme anliegen, ist Ans mit geringerer Priorität erstmal bis mindestens Juli 26 gerutscht.

Telexforum.de