SDS PLC/PAC: Měření Energie & OnlineTechnology.cz
Network Monitoring System - SDS - Síťový Dohledový Systém
Nejste přihlášen. Přihlaste se, nebo se zaregistrujte.
SDS PLC/PAC: Měření Energie & OnlineTechnology.cz » SDS-MICRO (LM) - light(2) E » [vyřešeno] Výpadek odesílání hodnot
Stránky 1
Chcete-li přispívat, musíte se přihlásit nebo projít procesem registrace.
Již delší dobu pozoruji že u mě dochází k výpadkům odesílání hodnot z SDS na server kde jsou hodnoty ukládány a pak zpracovány. Děje se tak po různě dlouhou dobu, někdy to vydrží dva týdny někdy týden. Stačí SDSko vypnout a zase zapnout a vše se vrátí do normálu.
Neřešil někdo tento problém? Aktuální firmware mám.
Mám podobné problémy. Odesílám na portál po 15 minutách a pak každou minutu na jiný server. Časové smyčky mám nastavené na 15 vteřin se sledováním sys65 a sys75. Nedovolím odesílání HTTP_GET pokud běží čas jiného požadavku. Vše funguje, ale po nějaké době občas příjde chyba v odesílání, kde sys75 obsahuje 0 a sys65 1029. Znamená to, že se nedokončil předchozí HTTP_GET. Pak se v náhodnou dobu stane, že deska přestane odesílat a každou minutu je vypsáno echo sys65 1029, sys75 0 a každou 15 minutu i u portálu. Co to znamená? Jak dlouho vlastně tvá funkci HTTP_GET než se po nezdařeném odeslání ukončí? Je možné, že by 15 vteřin nestačilo a každominutové volání funkce HTTP_GET ji soustavně udržuje ve stavu nedokončeného požadavku? Samozřejmě po restartu desky zase všechno na nějaký čas funguje. Když v jakoukoliv dobu při nefunkčnosti odesílání se dotáži přes výpis get_sys[65], dostanu hodnotu 1029. Prosím o nějakou radu.
Používáte nejposlednější firmware pro vaše SDS ?
15 vteřin může skutečně být málo. Je potřeba sledovat výstup sys[] pro zjištení stavu, a podle toho se zařídit - viz příklad na wiki.
Firmware má i bezpečnostní timeout, pokud si vzpomínám je to asi jedna minuta (když se HTTP GET nepovede, tak by se to mělo celé nulovat a pak by jste měl být funkci schopen znovu bez problému použít - opět je potřeba sledovat sys[] pro skutečný stav).
Firmware má i bezpečnostní timeout, pokud si vzpomínám je to asi jedna minuta (když se HTTP GET nepovede, tak by se to mělo celé nulovat a pak by jste měl být funkci schopen znovu bez problému použít - opět je potřeba sledovat sys[] pro skutečný stav).
Mám s odesíláním pořád problémy. Nějaký čas se to zdá dobré a pak to začne zase zlobit. Mohl byste popsat podrobněji funkci http_get ? Znamená to, že pokud sys[] obsahuje hodnotu 1029 a dojde k vnitřnímu ukončení této funkce, tak pak obsah sys[] je vynulován ? Pokud by tomu tak bylo, pak by bylo lepší v situaci kdy výstup sys[] dává 1029 tutu proměnou sledovat až se vynuluje a potom pokračovat s dalším odesíláním. Nejnovější firmware používám a čas odesílání jistím 100 vteřinami. Děkuji za každou radu.
Snad tohle pomůže:
(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
Můžu nějak programově v SDS-C ošetřit / předcházet chybě sys[65]=1029 - kousnutý http_get na portál? Dnes se mi stalo, že od 10hod do 16hod (než jsem to zjistil) zůstalo SDS micro E viset na 2. http_get - odesílání teplot. Pomohlo až vypnutí a zapnutí SDS. FW mám poslední a nikdy dřív jsem podobný problém neměl. Používám pouze výchozí http_get na portál. Plus vlastní procedury, které pracují mj. v 10s intervalech s hodnotami teplot - jestli by to nemohlo souviset s tím zamrznutím. Stačilo by ten můj výpočet zahájit podmínkou sys[65]==1024 ? Nebo jak zjistím, že právě (ne)probíhá http_get proces?
Soami, já řeším v podstatě stejný problém už rok. Někdy vše funguje bez problémů 14 dní a pak přijde období, kdy musím restartovat i dvakrát za den. V sys65 je hodnota 1029 a pořád tam drží, dokud nedojde k restartu. Administrátor Adam psal v jednom příspěvku, že vnitřní timeout funkce je jedna minuta. Já si myslím, že k ukončení vnitřní funkce HTTP_GET nedojde. Asi by to šlo řešit watchdogem a resetovat odpojením napájení relátkem, ale zdá se mi to takové neprofesionální. Já odesílám každou minutu meteorologická data a pak každých 15 minut na E-portál. Nevím, co způsobí zaseknutí funkce, jestli můj poskytovatel internetu, webhosting a nebo portál měření energie. Výpadky internetu ale od poskytovatele neregistruju. Chtělo by to nějak vyřešit. Moc mě to štve. Jinak jsem s deskou moc spokojený a vymýšlím pro ni stále nové uplatnění.
Stalo se mi to poprvé, za více než rok, ale určitě bych tomu chtěl předejít. Restartem smažu hodnoty průběžně ukládané v ram. V programu je sice timeout, jak píše Adamn, ale program se k němu nedostane nebo nulování neproběhne. V administraci jsem viděl probíhající/nedokončený http_get teplot, na konzoli DNS resolve OK, ale chyba komunikace s www serverem, http:0. Takto se to vypisovalo v intervalech časů pro upload na portál. Problémy s internetem nemám.
Velice rád bych to řešil, ale zasekávám se už na prvním kroku - a to je nasimulování této situace.
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).
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.
Dnes bylo vydáno BETA-FW pro SDS-MICRO, kde je přidána dodatečná kontrola na bezpečnostní timeout atd.
Vyzkoušejte a dejte vědět - jestli to bude OK, vydá se to jako oficiální firmware.
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.
BETA FW jsem hned nahrál do dvou desek. Zatím to funguje. Ale stávalo se, že to klidně 14 dní fungovalo bez problémů a pak to začalo zlobit. Pár výpadků jsem měl, ale ty měly status 1027 a 1026. Takže zatím v pohodě. Díky. Bylo by to super, kdyby to už fungovalo bez zaseknutí.
Nechci to zakřiknout, ale vypadá to, že se oprava FW povedla. Od nahrání nového FW nedošlo k zablokování funkce HTTP GET. Snížil se i počet nevyřízených požadavků HTTP GET se statusem sys65 1027 a 1026. Ještě jednou díky.
Máte nějaké další pozorování ? Jak si ten FW vede ?
Každopádně vše bylo překlopeno z BETA do oficiálního vydání, takže můžete aktualizovat.
Já jsem od nahrání bety neměl žádný výpadek v odesílání. Jak jsem uváděl, historicky to zamrzlo pouze jednou, takže to nemůžu objektivně hodnotit. Každopádně díky za opravu.
Edit: zjištěn problém se SMTP zadáno sem - http://forum.merenienergie.cz//viewtopic.php?id=882
Myslím, že po tak dlouhé době se dá hodnotit. Oprava FW se povedla. Za celé dva měsíce nenastal jediný problém s odesíláním HTTP. Jsem rád, že nemusím kontrolovat odesílání dat na server a tak nepřicházím o cenná data. Díky.
Děkuji za potvrzení. Byl to vskutku zajímavý problém, a jsem rád, že se to vyřešilo.
Opravy budou předány i do dalších výrobků SDS.
Můžu potvrdit vyřešeno, už jsem pomalu přestával doufat že se na to přijde.
Děkuji.
Stránky 1
Chcete-li přispívat, musíte se přihlásit nebo projít procesem registrace.
SDS PLC/PAC: Měření Energie & OnlineTechnology.cz » SDS-MICRO (LM) - light(2) E » [vyřešeno] Výpadek odesílání hodnot