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