Každopádně vše bylo překlopeno z BETA do oficiálního vydání, takže můžete aktualizovat.
]]>Nevím, jestli to dobře chápu, ale hodnota timeoutu by neměla být vyšší než 45000. Nebo se pletu?
Může být klidně vyšší, je to volně běžící čítač, který se jen ve vybraných okamžicích nuluje (kdy - viz text výše).
Pokud neprobíhá http_get nebo jiná OSI7 funkce, tak hodnota čítače stále roste - to je OK.
Zatím jsem pozoroval, že k vynulování timeoutu dojde pouze zavoláním funkce http_get, pokud předešlý stav SYS65 nebyl 1029.
Ano, přesně tak - nulování pouze když lze začít nový http_get, popř. v jeho průběhu.
Pokud by se to nulovalo při dalším zavolání http_get, když už jedno http_get "běží", tak by význam bezpečnostního čítače byl ztracen.
Mě to připadá, že je problém s tím nulováním.
Ano, je to dost možné. Zkusím to udělat robustnější - vyzkoušejte nový FW.
Pokud by bezpečnostní timeout fungoval, tak by přeci po 45 vteřinách měla sys 65 obsahovat 0 a né aby to pořád drželo 1029 nebo v případě, že vše funguje 1024.
Nula v sys[65] nebude, protože po (jakémkoliv) ukočení http_get se do sys[65] zapíše hodnota 1024 nebo vyšší, a nula se tam už nemá jak dostat (tj. je tam jen po startu zařízení až do prvního zavolání funkce, pak už nikdy). Ale to už je jen detail, nepodstatný k původnímu tématu.
]]>
NETWORK
[ARP:A]
209 38:2C:4A:65:66:E4 - 192.168.1.1
[ARP:B]
210 20:CF:30:36:FE:F6 - 192.168.1.71
131 60:D9:A0:D2:62:B7 - 192.168.1.25
209 40:16:3B:C7:98:CC - 192.168.1.162
[HTTP-GET]
con=1 grl=84 rc=1029 tim=523273839
[TCP]
[0] 192.168.1.71:2294 timew
[1] 192.168.1.71:2550 timew [HTTP-GET]
[2] 192.168.1.71:2806 timew
[3] 192.168.1.71:3830 timew
[4] 192.168.1.71:4086 timew
[5] 192.168.1.71:4342 timew
Tak jsem zrovna nachytal desku přímo při činu. Podle hodnoty bezpečnostního timeoutu to odpovídá asi 6 dnům. V databázi, kam se odesílají data to také sedí. Nevím, jestli to dobře chápu, ale hodnota timeoutu by neměla být vyšší než 45000. Nebo se pletu? Zatím jsem pozoroval, že k vynulování timeoutu dojde pouze zavoláním funkce http_get, pokud předešlý stav SYS65 nebyl 1029.
Pokud vše funguje a deska odesílá po jedné minutě, tak načítání timeoutu se též vynuluje až se zavoláním funkce HTTP_GET. Takže timeout načte hodnotu 59999.
Tady je výpis, pokud odesílání funguje.
NETWORK
[ARP:A]
204 38:2C:4A:65:66:E4 - 192.168.1.1
[ARP:B]
210 20:CF:30:36:FE:F6 - 192.168.1.71
016 60:D9:A0:D2:62:B7 - 192.168.1.25
209 40:16:3B:C7:98:CC - 192.168.1.162
[HTTP-GET]
con=0 grl=0 rc=1024 tim=58012
[TCP]
[0] 192.168.1.71:50938 timew
[1] 192.168.1.71:51194 timew
[2] 192.168.1.71:51706 timew
Mě to připadá, že je problém s tím nulováním.
Pokud by bezpečnostní timeout fungoval, tak by přeci po 45 vteřinách měla sys 65 obsahovat 0 a né aby to pořád drželo 1029 nebo v případě, že vše funguje 1024.
Desku zatím nerestartuji, kdyby Vás něco napadlo.
]]>Pokud by někdo mohl udělat záchyt komunikace právě v době kdy se toto děje / stane (určitě to nebude snadné udělat, chce to vybavení), a poslat mi .pcap soubor, bylo by to ideální.
---
Dívali jste se na příklad na http://wiki.merenienergie.cz/index.php/Sdsc_sysf ?
Pokud sys[65] vrátí 1029, tak to znamená, že neskončila předchozí činnost (jakákoliv OSI7 funkce, tj. třeba ještě nedoběho odesílání emailu, předchozí http-get dotaz, atd.) a proto se tento aktuální požadavek nevyřídil = to znamená, že když dostanete 1029, tak to teď "neprošlo" (ani nezačalo) a máte to zkusit za chvíli znovu.
Je potřeba programovat podle návodů a dokumentace.
Tady jsou vypsány všechny případy, kdy volání funkce http_get() vrátí sys[65]=1029:
* když není dostupný Ethernet (výpadek na PHY/MAC - např. odpojený kabel, mrtvý externích switch atd.)
* když právě probíhá odesílání emailu (toto nelze přerušit, musí to doběhnout a až pak lze dělat další OSI7 požadavek)
* když právě probíhá http-get (tj. ještě neskončil ten poslední co jste spustili, musí nejprve doběhnout)
* pokud se čeká na odeslání SNMP TRAP paketu (tohle je obvykle tak rychlé, že se to zde neuplatní)
---
Aktuální vnitřní stav http_get() lze vidět na stránce arp.htm
(tj. webové rozhraní SDS, typická adresa: 192.168.1.250/arp.htm ).
Zkuste se tam podívat v okamžiku kdy vám to dělá problémy, snad to něčemu napoví.
Text: [HTTP-GET] con=0 grl=0 rc=0 tim=0
Kde:
* con = stav připojení (když je zde nenulová hodnota, tak požadavek na nový http_get skončí ihned jako 1029)
* grl = kolik ještě zbývá odeslat bajtů dat na server (tj. zbývající velikost původního GET požadavku)
* rc = OSI7 result code - toto se zapisuje do sys[65]
* tim = bezpečnostní timeout
Bezpečnostní timeout je neustále a trvale zvyšován, a to o 1 za každou milisekundu.
Bezpečnostní timeout je nulován:
- při začátku SDS-OSI7 funkce (tj. například každým zavoláním http_get funkce, která ale není předčasně zrušena chybou 1029).
- v okamžiku otevření TCP spojení na server
- v okamžiku platné TCP komunikace (přijaty nové data, odeslány data, nebo TCP ACK nebo retransmit).
Pro http_get je (stav ve verzi FW do a včetně 8/2017) nastaven bezpečnostní limit na 45 sekund.
To znamená, jakmile hodnota bezpečnostního timeout překročí 45000, tak dojde ke zrušení činnosti (např. přerušení právě prováděného http_get, nebo odesílání emailu atd. - platí pro všechny SDS-OSI7 funkce).
Do některého nového FW přidám možnost číst tuto hodnotu jako jeden ze sys[] indexů, zatím to tam není (a není to potřeba, bude to k dispozici prakticky jen pro informaci a debug).
]]>(ZDE JE VYSVĚTLENÍ CHYBOVÝCH KÓDŮ) http://wiki.merenienergie.cz/index.php/OSI7_status_code
(ZDE NAJDETE PŘÍKLAD V SDS-C) http://wiki.merenienergie.cz/index.php/Sdsc_sysf
http://wiki.merenienergie.cz/index.php/Sdsc_sysp