Systemstart und sendtcp()

[saft6luck]

Immer nach einem Neustart bekomme ich massenweise Ereignisseinträge zu sendtcp(). Aber auch der Rest ist sicherlich nicht gut!

Beispiel:
- Der eibPC fragt die GAs in der InitGA um 19:04:54 ab.
- Erste reguläre Telegramme kommen 19:05:09 vom eibPC.

% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:09
% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:09
[B][COLOR="Blue"]% Event: sendtcp(iPad_Galerie_Socket_Po..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:11
% Event: sendtcp(iPad_Galerie_Socket_Po..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:11
% Event: sendtcp(iPad_WZ_Socket_Port,iP..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:11
% Event: sendtcp(iPad_WZ_Socket_Port,iP..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:11
% Event: sendtcp(iPad_Galerie_Socket_Po..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:11
% Event: sendtcp(iPad_Galerie_Socket_Po..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:11
% Event: sendtcp(iPad_WZ_Socket_Port,iP..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:12
% Event: sendtcp(iPad_Galerie_Socket_Po..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:12
[/COLOR][/B]% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:18
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:28
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:38
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:48
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:05:58
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:06:08
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:06:18
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:06:28
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:06:38
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:06:48
% Event: sendtcp(1012u16,192.168.1.1,0x..:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:06:58
% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-21 19:07:08

Hier ist ganz offensichtlich das readTCP() bereits möglich gewesen, denn die blau markierten Meldungen beziehen sich auf den CommandFusion, der erst aktiv sendet, wenn die Verbindungen von den Tablets aufgebaut wurden und die Passwort-Antwort gesendet wird.

Was ist denn da der Hintergrund und kann man da nichts machen?

[enertegus]

Was ist denn da der Hintergrund und kann man da nichts machen?

Hast Du denn einen einfachen Beispielcode?

[saft6luck]

Eigentlich schon, die nächsten Einträge sind vom FritzBoxCallMonitor-Makro aus der CHGLibrary_FritzBox.lib.

Diese Ereigniseinträge kommen z.B. auch mit nur diesem Makro als Code.

Was bedeuten denn die teilweise leeren Einträge?

[enertegus]

Was bedeuten denn die teilweise leeren Einträge?

Ich habe das mal an die Entwicklung weitergegeben. Die werden sich bei dir melden oder einfach hier.

[EPIX]

Ereignisspeicher - oder was will mir mein eibpc sagen?

% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-22 08:49:38
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:42
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:42
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:45
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:45
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:48
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:48
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:54
% Event: <>:ERR_PROC_OBJECT@2014-07-22 08:49:54

was bedeuted das?

wie kann ich das problem eingrenzen?
(ausser Codeteile manuell deaktivieren?)

patch 3.014 ist eingespielt

[Marha]

So sieht mein Eventspeicher nach einem Neustart auch aus.
Hatte mir bisher nichts dabei gedacht, da die Firmware beim Neustart wohl einiges zu tun hat. Nach einer gewissen Zeit nach dem Neustart funktioniert es dann ja auch.

[fEnertex]

Aus der Anleitung:

ERR_PROC_OBJECT_MSG_OUT
Ein Ausgabeobjekt konnte nicht verarbeitet werden. Dies kann
die folgenden Funktionen betreffen: 1 Schreibzugriff auf den
KNX-Bus 1.1 settime 1.2 setdate 1.3 settimedate 1.4 write 1.5
read 1.6 writeresponse 1.7 scene 1.8 storescene 1.9 callscene
1.10 eibtelegramm 2 Netzwerkfunktionen 2.1 closetcp 2.2
connecttcp 2.3 ping 2.4 resolve 2.5 sendhtmlmail 2.6 sendmail
2.7 sendtcp 2.8 sendtcparray 2.9 sendudp 2.10 sendudparray 3.
RS232-Schnittstelle 3.1 resetrs232 3.2 sendrs232 4. VPN-Server
4.1 closevpnuser 4.2 openvpnuser 4.3 startvpn 4.4 stopvpn Bitte
überprüfen Sie, ob eine entsprechende Verbindung besteht.

Bei dem FritzBoxCallMonitor aus der CHGLibrary_FritzBox.lib konnten die leeren Fehlermeldungen <> und die mit Bezeichnung sendtcp(...) beobachtet werden.

Die leeren Fehlermeldungen konnten dem closetcp zugeordnet werden und sind darauf zurückzuführen, dass eine TCP-Verbindung geschlossen wurde, die bereits geschlossen war. Die Fehlermeldungen sind leer, weil der Compiler dem closetcp keinen internen Funktionsnamen gegeben hat.

Die Fehlermeldungen vom sendtcp kamen daher, dass keine TCP-Verbindung zur Fritzbox bestand. Nicht weiter tragisch, weil es bei dem Versuch keine Fritzbox gab.

Also bei diesen Fehlern überprüfen, ob eine TCP-Verbindung besteht.

Warum das closetcp des FritzBoxCallMonitors vom Compiler keinen Funktionsnamen bekommt, ist noch unklar (beim Wettermakro aus der EnertexV2.lib hat das closetcp einen Funktionsnamen). Hab das mal in die Entwicklung eingespeist.

[saft6luck]

Bei dem FritzBoxCallMonitor aus der CHGLibrary_FritzBox.lib konnten die leeren Fehlermeldungen <> und die mit Bezeichnung sendtcp(...) beobachtet werden.

Die leeren Fehlermeldungen konnten dem closetcp zugeordnet werden und sind darauf zurückzuführen, dass eine TCP-Verbindung geschlossen wurde, die bereits geschlossen war. Die Fehlermeldungen sind leer, weil der Compiler dem closetcp keinen internen Funktionsnamen gegeben hat.

Klingt einleuchtend.

Ich habe den Start des FritzBox Makros mal von 5 Sek auf 2 Min verzögert und das Alive kommt nur bei bestehender Verbindung (könnte man evtl. in die Lib aufnehmen):

[highlight=epc]
// TCP Connection Keep alive
if cycle(00,20) AND (FritzBoxCallMonitor^Name^TCPConnectResponse==0) then {
sendtcp(FritzBoxPort,FritzBoxIP, 0x0d, 0x0a)
} endif
[/highlight]

- InitGA: 18:45:31
- Programm: 18:45:50
% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-22 18:45:50
% Event: sendtcp(iPad_Galerie_Socket_Po..:ERR_PROC_OBJECT_MSG_OUT@2014-07-22 18:45:51
% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-22 18:47:49
% Event: <>:ERR_PROC_OBJECT_MSG_OUT@2014-07-22 18:47:49
% Event: sendtcparray(4001u16,192.168.1..:ERR_PROC_OBJECT_MSG_OUT@2014-07-22 18:55:51

Abgesehen von den CommandFusion Einträgen (wo es kein closetcp() gibt) gibt es jetzt 2 leere Einträge nach 2 Minuten, die Fritzbox wird aber abgefragt. Und später macht das Wärmepumpen-Makro Probleme beim Versand(?) (hier besteht aber eine Verbindung, da nur dann auch gesendet wird).

Die Fehlermeldungen vom sendtcp kamen daher, dass keine TCP-Verbindung zur Fritzbox bestand. Nicht weiter tragisch, weil es bei dem Versuch keine Fritzbox gab.

Also bei diesen Fehlern überprüfen, ob eine TCP-Verbindung besteht.

Bei mir besteht sicher "die Möglichkeit einer Verbindung". Gesendet wird wohl aber trotzdem (noch) nichts.

Warum das closetcp des FritzBoxCallMonitors vom Compiler keinen Funktionsnamen bekommt, ist noch unklar (beim Wettermakro aus der EnertexV2.lib hat das closetcp einen Funktionsnamen). Hab das mal in die Entwicklung eingespeist.

Und falls das closetcp() nicht der Grund für den Eintrag ist?
Die Frage ist auch noch, warum der eibPC anstatt zu senden die sendtcp-Einträge erzeugt.

[fEnertex]

Und falls das closetcp() nicht der Grund für den Eintrag ist?
Die Frage ist auch noch, warum der eibPC anstatt zu senden die sendtcp-Einträge erzeugt.

In dem Fall ist das closetcp der Grund für den Eintrag.

Die sendtcp Einträge, weil die TCP Verbindung nicht besteht.. Vielleicht mal ohne Makro versuchen oder mit wireshark beobachten.

[saft6luck]

In dem Fall ist das closetcp der Grund für den Eintrag.

Und das erzeugt also 2 Einträge? Wenn die Verbindung möglich ist? Bei mir wird die Verbindung sicher nicht gleichzeitig 2x geschlossen!

Die sendtcp Einträge, weil die TCP Verbindung nicht besteht..

Bei dir mag das der Fall sein, bei mir nicht.

Vielleicht mal ohne Makro versuchen oder mit wireshark beobachten.

Ohne Makro?

Ich habe den Start des Makros bereits verzögert und erhalte dann ein funktionierendes Makro. Sendtcp() funktioniert also offenbar später problemlos. Dann liegt es wohl nicht am Makro, oder?

[saft6luck]

Gestern noch ein extremes Beispiel (wobei nicht auf Systemstart bezogen).

Es waren hunderte, gefühlt unendlich viele Einträge zu einem iPad im Logging. Das Auslesen war nach einer Stunde noch nicht fertig. Da ich aber eigentlich "nur" ein weiteres iPad einhängen wollte, konnte ich dann nicht mehr warten und habe neu geflasht.

Die Einträge waren vom 23. ab 00:15. Es kam pro Sekunde ein sendtcp() Eintrag wegen des regelmäßigen Updates der Uhrzeit im CF.
Eingestreut waren sendtcp() Einträge zu den Antworten der Passwortabfrage des CFs, da dieser keine Antworten bekam.
Das ging so mindestens bis 00:45.

An diesem Gerät ist mir am nächsten Morgen aber sicher nichts ungewöhnliches aufgefallen. Es läuft immer durch (genauso, wie 2 weitere auch) und morgens komme ich immer vorbei und schaue nach den aktuellen Daten, Wetter, schalte das Radio ein und prüfe allgemein die Funktion des CFs. Das Problem hat sich also "geheilt".

Meine Schlussfolgerungen:

• Senden ging bei nur an diesen CF nicht, der Empfang ging aber, denn jeder einzelne CF wird zwar aus der Sendeliste ausgehängt, wenn 20 Sek keine Kommunikation vorhanden ist, die Passwortabfragen der CFs aktivieren jeden einzelnen aber -> die regelmäßigen Telegramme gehen weiter
• Nur diese Verbindung (bei der der eibPC der Server ist, also kein connecttcp() möglich) ist gestört, denn es gibt keine Einträge zur Fritzbox oder der WP, die in diesem Zeitraum auch regelmäßig abgefragt wurden. Auch die anderen CFs werden weiterhin bedient.
• Ich sehe keine Möglichkeit, wie externe Probleme dieses Verhalten verursachen könnten.

[KNXFan1970]

Hallo eibPC und CF-Nutzer -

ich bin mir nicht sicher, ob ich hier das Thema richtig fortsetze, aber ich habe echte Probleme mit dem Verbinden meiner iPads (via Commandfusion) mit dem eibPC. Prinzipiell lassen sich die iPads verbinden und funktionieren nach einiger Zeit problemlos. Legt man die CF-App in den Hintergrund oder startet die App neu wird auch eine neue Verbindung aufgebaut, da über das iPad sich relativ schnell Schaltvorgänge ausführen lassen, aber ich erhalte minutenlang keine Rückmeldungen vom eibPC. Dafür laufen eine Vielzahl von sendtcp() -Fehlermeldungen.
Nach einiger Zeit 1-10 min "heilt sich das System selbst" und läuft dann fehlerfrei und flüssig - eben bis man eine andere App in den Vordergrund holt. Da dadurch nach - ich meine - 7s die Verbindung getrennt wird, tritt beim Aktivieren der CF-App das Problem erneut auf.

So macht das aber keinen Spass

In welche Richtung kann man sich hier auf Fehlersuche machen? Hat jemand eine Idee? Gefühlsmäßig - was nichts heißen muss tippe ich auf ein Problem beim eibPC. Habt ihr Ideen oder Hinweise oder/und die gleichen Beobachtungen mit eurem System gemacht?

Danke schon mal, dass ihr drüber nachdenkt.

[enertegus]

Habt ihr Ideen oder Hinweise oder/und die gleichen Beobachtungen mit eurem System gemacht?

Kannst Du einen Wireshark rein hängen (braucht wohl einen Switch mit entsprechenden Ausgang). Die Events werden bedeuten, dass CF die Verbindung nicht gehalten hat bzw. die schon zu war (s.o.). Ohne weiteres Logging kann man da von der Ferne nicht viel machen.

[saft6luck]

Hab nach dem Urlaub mal das Auslesen der Fehlerspeichereinträge angestoßen.
Seit nunmehr über 3 Stunden werden diese Übertragen und es dauert immer noch an?!
Gibt es denn wirklich keine schnellere Art, diese Daten zu übertragen? Muss das wirklich derart langsam sein?????

EDIT: Läd nach 4 Stunden immer noch!
EDIT2:
Nach fast 5 Stunden werden immer noch Einträge übertragen (mit Wireshark geprüft); in einer wahnsinnigen Geschwindigkeit von ca. 2 Einträgen pro Sekunde. Jeder Eintrag eine neue Übertragung (neuer Port etc.).
Nach also ca. 30.000 Einträgen habe ich jetzt abgebrochen. Alle Einträge bisher waren von sendtcp(), wobei das EibStudio nicht alle anzeigen kann.

[KNXFan1970]

Kannst Du einen Wireshark rein hängen (braucht wohl einen Switch mit entsprechenden Ausgang).

Sorry - hab leider keinen richtigen Plan, wie man das macht. Was meinst du mit Switch mit entsprechendem Ausgang?

Gruß
Frank