Schalten bei Anruf mit EibPC und Fritzbox

[jeans112]

Hallo,

Ich denke, dass du diese Variable "FritzBoxCallMonitor7270Message" bei Änderung auf deine GA schreibst... Um sicher zu gehen kannst du im EibStudio-Debugger diese Variablen mal prüfen.

ja du liegst richtig.
Aber wenn ich die Variable auslese kommen nur viele Nullen und im Debugger steht "nicht lesbar"

Irgendwelche Ideen

Grüße
Jens

(sorry für die verzögerten Antworten, aber ich bin momentan selten Zuhause)

[enertegus]

Hallo,
Aber wenn ich die Variable auslese kommen nur viele Nullen und im Debugger steht "nicht lesbar"

Was bedeutet, dass der String leer ist (das ist etwas irreführend und steht schon in der Bugliste). Das Monitorfenster zeigt die Bytes des Strings an.

Wenn Du sagst Du kannst Dich verbinden und das Auslesen klappt, was genau meinst Du denn da?

Probier doch mal das mit dem zyklischen Sendn von CR aus (sentcp mit Byte = 13). Dann sollte zumindest die Verbindung keinen Timeout bekommen.

[jeans112]

Hallo eneretus,

ich verstehe deine Frage gerade nicht wirklich?

Was meinst du mit:

Wenn Du sagst Du kannst Dich verbinden und das Auslesen klappt, was genau meinst Du denn da?

[enertegus]

Hallo eneretus,
ich verstehe deine Frage gerade nicht wirklich?

Ups, hab ich das was durcheinander gebracht? Ich dachte die Verbindung klappt und es wird auch ein event ausgelöst. Oder wer hat hier eigentlich nun was am Laufen - die Sache mit dem WG hat mich zusätzlich verwirrt.

Jedenfalls werden wir uns der Sache annehmen. Ich denke, das wird ca. 2 Wochen dauern.

[chg]

Kannst Du nicht einfach bei bestehender Verbindung ein list-dir oder ähnliches schicken?

Alternativ könnte man auch einfach mal alle 30 s einen Zeilenvorschub schicken (CR, LF).

Probier doch mal das mit dem zyklischen Sendn von CR aus (sentcp mit Byte = 13). Dann sollte zumindest die Verbindung keinen Timeout bekommen.

Hab ich fast alles probiert. Z.B. alle 30s ein $?$ oder 0x13 zu senden. Um keinen TimeOut zu bekommen, müsste es ja egal sein was ich sende... Aber das zyklische senden bringt keinen Erfolg.

Also keine Ahnung ob ein TimeOut passiert oder nicht. Fakt ist imho, dass der EibPC die Telegramme via event(readtcp()) ein paar Sekunden nach connecttcp() nicht mehr mitbekommt. Es hilft nur ein reconnect.

Ich bin da nicht so ganz der Experte und hab keine FB hier. Werde das mal am Montag in der Firma ansprechen.
Nach wie vor wäre es aus meiner Sicht das Beste zu wissen, was am LAN passiert (also Wireshark...)

Kann zuhause via Wireshark leider nur sehen was an den PC geht. Hatte gehofft, dass hier jemand aus dem Forum testen kann...

Ich sehe nur den Unterschied, dass wenn ich mich via telnet vom PC aus verbinde, ich problemlos jede Message der FB, auch nach einigen Minuten, angezeigt bekomme.
Der EibPC meldet die Messages aber immer nur für kurze Zeit nach dem connecttcp(). Nach einem neuen erfolgreichem connecttcp() (Ergebnis = 0) funktionierts dann wieder für ein paar Sekunden.

... das mit der persistenten Verbindung zur FBF geht natürlich...

Das bestätigen die Tests mit telnet.

Hast du da auch vorher die alte Verbindung mit closetcp geschlossen?

Ja. Damit konnte ich dann die Fehlerrückmeldungen (Ergebnis != 0) minimieren.

...ja du liegst richtig.
Aber wenn ich die Variable auslese kommen nur viele Nullen und im Debugger steht "nicht lesbar"... Irgendwelche Ideen

Dann ist der String leer. Was bedeutet, dass der EibPC noch kein Telegramm auf dem Port 1012 empfangen hat.

Versuch mal folgendes:
Via Debugger die Variable "FritzBoxCallMonitor^Name^Connect" auf EIN setzten. Wenn mit dem Verbindungsaufbau zur FB alles stimmt dann ist die Variable "FritzBoxCallMonitor^Name^TCPConnectResponse" = 0.
Innerhalb von Sekunden nach dem Connect einen Anruf auf die FB durchführen. Jetzt sollte auch die Variable "FritzBoxCallMonitor^Name^Message" mal etwas anzeigen.

Mehrere Versuche können nicht schaden... Oder verwende am besten die neue Version anbei.

Jedenfalls werden wir uns der Sache annehmen. Ich denke, das wird ca. 2 Wochen dauern.

Das wäre Toll! Ich/Wir kommen hier glaube ich nicht weiter.
Da ich ähnliche Probleme beim Denon-AVR-Macro hab, vermute ich leider ein Problem in eurer TCP-Implementierung...

Nachtrag: Anbei mal meine aktuelle Version. Mit zyklischem Reconnect (30s) geht's ganz gut... Ist aber eine sehr unschöne Lösung... Und die Gefahr besteht, dass Meldungen verloren gehen die genau bei closetcp() oder connecttcp() von der FB kommen...

[makki]

Mal so eine Frage (ohne jegliche Hinter/ander/zwischengedanken!!):
Laufen die connecttcp im EibPC als Prozesse, threads (mit/ohne select-callback?) oder in einer Mischung endlicher Anzahl von "workers" des Hauptprogramms?
Würde mein Verständniss fördern
(genau darüber stolpert nämlich der HS z.B. massiv..)

Makki

[enertegus]

Das wäre Toll! Ich/Wir kommen hier glaube ich nicht weiter.
Da ich ähnliche Probleme beim Denon-AVR-Macro hab, vermute ich leider ein Problem in eurer TCP-Implementierung...

Möglich, immerhin geht aber z.B. CF doch schon recht gut. Aber das finden wir schon noch raus. Ist jedenfalls ein Thema, das wir auf der TODO ganz oben hingeschoben haben.

[enertegus]

Laufen die connecttcp im EibPC als Prozesse, threads (mit/ohne select-callback?) oder in einer Mischung endlicher Anzahl von "workers" des Hauptprogramms?

Als Threads. Manche Threads kommen mit Rückmeldung, die jedoch z.T. "asynchron" zur Verarbeitungschleife gemeldet werden. Also z.B. wartet die Verarbeitung nicht etwa bis Connecttcp eine Verbindung aufgebaut hat. Mein Wissen ist da allerdings beschränkt, da weiss die Firmwareecke bei uns besser Bescheid.
Welche Probleme hat der HS da mit was genau?

[enertegus]

Hab ich fast alles probiert. Z.B. alle 30s ein $?$ oder 0x13 zu senden. Um keinen TimeOut zu bekommen, müsste es ja egal sein was ich sende... Aber das zyklische senden bringt keinen Erfolg.

Mach mal nur alle 10 Sekunden. Ggf. ist 30 Sekunden zu knapp.

[salixer]

Hab ich fast alles probiert. Z.B. alle 30s ein $?$ oder 0x13 zu senden. Um keinen TimeOut zu bekommen, müsste es ja egal sein was ich sende...

Besser ein korrektes Zeilenende für Telnet senden. Das sind üblicherweise die zwei Bytes CR, LF (0x0d, 0x0a). Genau das wird auch gesendet, wenn man in Telnet "Return" drückt.
Schickt man nur ein ? oder ein 0x0d könnte der Telnet-Server die Verbindung kappen, weil der Befehl nicht korrekt abgeschlossen ist.

[chg]

...Aber das finden wir schon noch raus.

Ja da bin ich mir sicher!

By the way: Hab das hier gerade gefunden:

Lasst den Closetcp weg.
Der EIBPC beendet die Sitzung eh nach ein paar Sekunden (waren mal 30).

Stimmt diese Aussage? Wie ist das verhalten nun genau?

Mach mal nur alle 10 Sekunden. Ggf. ist 30 Sekunden zu knapp.

Besser ein korrektes Zeilenende für Telnet senden... Schickt man nur ein ? oder ein 0x0d könnte der Telnet-Server die Verbindung kappen...

Okay! Das probier ich später daheim aus.
Aber wenn nichts gesendet wird, dann beendet doch wohl der EibPC die Verbindung oder!? Mit dem Windows-Telnet muss ich nichts, von Hand, senden und die Verbindung bleibt offen.

Wenn dem so ist: 1) Bitte Info ins Handbuch. 2) Featurewunsch: TimeOut abschaltbar/konfigurierbar machen...

[chg]

So ich hab´s getestet:
Mit dem zyklischen sendtcp() alle 10s funktionierts! Es ist egal was man sendet. Ob "0x0d, 0x0a" oder "$?$" egal Hauptsache alle 10s!!!

Ich gehe also davon aus, dass der EibPC die TCP-Verbindung beendet wenn nicht alle x Sekunden etwas gesendet/empfangen wird.
: Enertex bitte schreibt solche Dinge ins Handbuch! Das muss man Wissen...

Da es ja nun so ist:

1) Bitte Info ins Handbuch. 2) Featurewunsch: TimeOut abschaltbar/konfigurierbar machen...

Alles in allem und so wie es aussieht es funkioniert! Version anbei!

[Bodo]

Voll Cool!

Heureka, es funktioniert! Dann werd' ich mal einen Dauertest machen.

[jeans112]

super,

auch bei mir funktionierts.

Danke an alle.

Grüße
Jens


..... jetzt gehts ans auswerten ....

[Marha]

Könnt ihr bitte mal ein Bsp. geben, wie ihr was auswertet. Was kommt denn von der FB zurück?