Idee: „Telex-Anrufbeantworter“
Verfasst: Sa 6. Dez 2025, 13:31
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?
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?
