Ist es richtig, dass die Menge der Daten auf 1400 Byte beschränkt ist. Das Handbuch ist hier unklar, weil dort steht "arg vom Datentyp c1400 bzw. einer selbst definierten Stringlänge".
Meine Beobachtung ist, dass die Grenze auf 1400 steht, auch wenn ich zuvor $$c2000 festlege.
Ich beziehe mich auf diese Zeile:
Ich habe per E-Mail mir Debug-Daten gesendet, und weiß, dass meine Strings zwischen 1600 und 2200 Byte haben. Ich bekomme dennoch nur 1400 Bytes. Die Angabe
wird völlig ignoriert. Fehlermeldungen gibt's keine. Handshake und Ablauf sind stabil auf der Serverseite.
Herzlichen Dank,
Jörg
Nur für Neugierige:
Warum sollte man das überhaupt tun? Ich sende jedes (!) Event an einen Cloud-Dienst (Azure Worker Role), dort wird das dann in der CosmosDb gespeichert und nach Time Series Insight weitergeleitet. Die CosmosDb-Daten werden nach ein paar Tagen verdichtet und dann nach ein paar Wochen wieder. Unfug wird weggeworfen. Ist ein Experiment, wie sinnvoll langfristige statische Auswertungen im Smarthome sind. Immerhin fallen pro Tag ca. 11000 Events an (Wetter, PV, Elektrozähler, Wasserzähler, Schalter, usw. usw.). Falls es jemals stabil läuft, poste ich den Code hier.
Meine Beobachtung ist, dass die Grenze auf 1400 steht, auch wenn ich zuvor $$c2000 festlege.
Code:
/ async tcp out tcp_status=5u08 tcp_connect=AUS tcp_sendport=8118u16 tcp_readport=0u16 tcp_readip=0u32 tcp_readok=$$c50 tcp_buffer=$$c12500 tcp_send_buffer=$$c12500 tcp_close=AUS tcp_time=$$c22 ip=0.0.0.0 buffer_stop=AUS // Wir leiten alle Signale an die Visus durch if event(readknx(udp_adr, udp_info)) then { buffer_stop=EIN; udp_text = convert(udp_adr, $$c16)+ $=$ + convert(udp_info, $$c80); tcp_time = utcconvert(utctime()); stringset(tcp_time, 84, 10u16); tcp_buffer = tcp_buffer + udp_text + $@$c2 + tcp_time + $Z&$c2; buffer_stop=AUS; } endif // am start und einmal pro stunde reicht DNS if (systemstart()) then { ip=resolve($mein.toller.cloud.service.net$); } endif if (cycle(60u08, 0u08)) then { // IP via resolve URL (Azure Worker Role) ip=resolve($mein.toller.cloud.service.net$); } endif // KNX events werden 5min lang gesammelt und dann in einem Paket gesendet if (cycle(5u08,0u08)) then { // wir dürfen keine halben strings senden if (buffer_stop==AUS) then { // kopieren tcp_send_buffer = tcp_buffer; // damit es gleich frei wird für neue Telegramme tcp_buffer = $$c12500; tcp_connect=EIN; tcp_status=connecttcp(tcp_sendport, ip); } endif } endif // nach erfolgreicher Verbindung werden Daten gesendet, Antwort ist egal if (tcp_status == 0) then { tcp_status=5; sendtcparray(tcp_sendport, ip, tcp_send_buffer, size(tcp_send_buffer)); } endif if event(readtcp(tcp_readport, tcp_readip, tcp_readok)) then { if (tcp_readip == ip) then { tcp_close=EIN; tcp_send_buffer=$$c12500; } endif; } endif if (tcp_close == EIN) then { tcp_close=AUS; tcp_connect=AUS; closetcp(tcp_sendport, ip); } endif
Ich beziehe mich auf diese Zeile:
Code:
sendtcparray(tcp_sendport, ip, tcp_send_buffer, size(tcp_send_buffer));
Code:
tcp_send_buffer=$$c12500
Herzlichen Dank,
Jörg
Nur für Neugierige:
Warum sollte man das überhaupt tun? Ich sende jedes (!) Event an einen Cloud-Dienst (Azure Worker Role), dort wird das dann in der CosmosDb gespeichert und nach Time Series Insight weitergeleitet. Die CosmosDb-Daten werden nach ein paar Tagen verdichtet und dann nach ein paar Wochen wieder. Unfug wird weggeworfen. Ist ein Experiment, wie sinnvoll langfristige statische Auswertungen im Smarthome sind. Immerhin fallen pro Tag ca. 11000 Events an (Wetter, PV, Elektrozähler, Wasserzähler, Schalter, usw. usw.). Falls es jemals stabil läuft, poste ich den Code hier.
Kommentar