Problém v HTTP komunikaci POST pomocí bloku HTTPRequest

Zdravím přátele Foxtrotu,
po několika těžkých dnech a nocích bych potřeboval zkonzultovat se zkušenějšími, jak rozchodit HTTP komunikaci na Foxtrotu.

Pustil jsem se do řízení kotle Baxi Luna Platinum a to s využitím vynikajícího německého projektu BSB-LAN. Siemens patří k málo či vůbec sdílným firmám co se týká integrace jeho řadičů kotlů do jiných systémů ("příště" si dám pozor a budu samozřejmě hledat nějaký s lidštějším přístupem k integraci). Ale hlavní překážka - dekódování proprietární sběrnice je vyřešená právě výše zmíněným projektem.
HW ve formě Arduina s LAN shieldem funguje. Webový server na Arduinu funguje, z windows stroje Curlem pomocí POST dotazu také data získám, ale s Tecomatem mám problém.

Pro HTTP komunikaci samozřejmě používám blok z knihovny, konkrétně HTTPRequestL2 (zkoušel jsem všechny varianty bloku a to i s metodou GET). Dole přikládám deklaraci i kód a v obrázcích výstupy z ladění.


Problémem je to, že i přes navázané POST spojení, kdy arduino na sériovém monitoru zahlásí správný dotaz od Tecomatu dostanu do bufferu jen zbytek JSON odpovědi na prvních 80 bajtech, resp. všiml jsem si, že přepíše první část dat ve stejné pozici. Blok vůbec nezahlásí Done ani DataReady a délku přijatých dat hlásí 512 bez ohledu na to, že přijatá zpráva je mnohem kratší.

Z ladění mi vychází, že do bufferu se nejprve zapíše komunikace ve směru Tecomat -> arduino (viz obrázek Watch-beforePOSTquery.png). Poté proběhne zjevně i správná komunikace směrem opačným a HttpRequestL2.helpstring obsahuje správný text (Watch-afterPOSTquery-ConnectedArduino.png), který bych chtěl mít v bufferu.

Z nepochopitelných důvodů, je ale v bufferu pouze posledních 80 znaků odpovědi a zbytek znaků ještě pochází z volání Foxtrot -> arduino. Tím, že helpstring není přístupný z vnějšku nemám, jak data vydolovat, protože v průběhu volání není ani jednou True HttpRequestL2.DataReady (ani .Done). Progress zůstane na -1, proběhnou ale různé States a Busy se na okamžik objeví True. Metoda Get přináší stejné výsledky.

Dumám, jakou proměnnou by mohla odpověď být omezena na 80B a nenacházím odpověď, stejně jako na příčinu trvalých hodnot False v datových stavových příznacích. Nastavení UNI kanálu jsem kontroloval asi 5x.

Jediná nekonzistence je v použití HTTP\1.1 vs HTTP\1.0, ale co jsem studoval dokumentaci, rozdíl by neměl být směrodatný.



Předem díky za nápady,
Aleš Kulhánek

-----------------
readyht : bool := false;
Hostnutny : String := '192.168.3.155';
Actiona : STRING := '/JQ';
HttpRequestL2 : fbHttpRequestL2;
HttpRequest : fbHttpRequest;
JSONL2: tHTTPPostData;
JSONINOUT : STRING[255] := '{$0A$5C"Parameter$5C"$0A:$5C"712$5C"}';

DataB : THttpBuffer;
Typeofdata : string[255] := 'application/json';
PostSuccesful : bool := false;
httpresponsefrag : string;

END_VAR


HttpRequestL2(Post := Postnito, chanCode := ETH1_uni4,
IPadr := STRING_TO_IPADR('192.168.3.155'),
Action := Actiona,
Host := Hostnutny,
PostLen := len(JSONINOUT),
Data := JSONL2,
RecvData := DataB,
ContentType := Typeofdata,
Data := JSONL2,
DataReady => Readyht,
Close := false
);

Zmiňoval jste, že odpověď je v JSON. No já bych asi nepoužil pro vyčítání blok HTTPRequestL2, ale přímo bloky z knihovny JsonLibEx. Dle návodu ke knihovně bych nastavil vyčítání - parsování aktuálních hodnot, které potřebuji, nebo všech.

https://www.tecomat.cz/uploads/files/DOCS/cze/TXV00379_01_Mosaic_JsonLib_cz.pdf

No ano, to se zdá jako přirozená volba, jenže tak jako tak v bloku fbJsonPageParser je uvnitř přepoužitá funkce z InternetLib fbHttpRequest. Takže výsledek je úplně stejný httpRequest nedá signál Done ani délku přijatých dat a vše se nesmyslně přemaže v bufferu v prvních x znacích. Hm...firmware update nic, přepojení na jiný switch nic...zkusím se poradit v Tecu.