plus (na základě prohlídky sds-c programu) je potřeba ten použitý sds-c program správně doplnit o ošetření chování na po zavolání http_get (tzn. čekání na výsledek a jeho správné zpracování).

odpověďi na otázky:
1/ teoreticky ano, ale chceme jít vpřed a použít nový FW (a do něj zakomponovat opravy)
2/ v archivu u výrobce / z archivu vývoje, ale vzhledem k tomu že je potřeba spravit nový FW a jít tímto směrem, tak dávám k dispozici nový FW (zatím jako beta, během následujících dní po potvrzení root cause pak i jako oficiální FW)

Opakuji tedy otázky:
1/ je možné provést downgrade ?
2/ kde předchozí firmware získat ?

díky

Nicméně - podle popisu je zřejmé o co se jedná (aktivace timeoutu pokud portál nekomunikuje) a buď je chyba v SDS, nebo je chyba v programu který si s tím neumí poradit.

Potřebuji vidět program, který máte v SDS nahrán, můžete mi to zaslat na sds@an-d.cz - děkuji

Je tam chyba 2 a chyba 9, tedy obojí timeout (viz wiki) - např. se nepovedlo se připojit k serveru nebo server přestal komunikovat. Obojí se může stát, jde o to jak si s tím buď SDS nebo uživatelský sds-c program poradí.

Podívejte se také na http://sds-ip-adresa/arp.htm a pošlete mi obsah této stránky, hned potom co se to zasekne.

Downgrade udělat eventuálně jde ale není potřebný - bude-li skutečně potřeba, tak opravený FW bude dnes k dispozici.

Každopádně, k další části - pokud nechcete ePortál, můžete zkusit využít integrovaný MQTT klient a posílat si to na MQTT server, těch je k dispozici několik veřejných, a privátní jdou velice snadno udělat (např. opensource Mosquitto).

Jedno z dočasných řešení je také využítí watchdogu SDS-C programu, viz návod na wiki. Ten by při eventuálním záseku natvrdo restartoval SDS-C program, takže není pak potřeba na SDS vzdáleně chodit a ručně modul restartovat.

po aktualizaci na nejnovější FW dochází u obou zařízení po nedefinované době k zaseknutí odesílání dat na portál ( u toho  druhého hlásil v historii OSI7 trvale Http_get_error 3) - možná to není přesný zápis, kód chyby je číslo 3 (u prvního )
U toho druhého poslední zápis, pak dál už nic, viz dále

Historie OSI7    
Čas    Událost
ve: 01:59:10 16.07.2020     77.93.211.207, HTTP GET OK
ve: 01:59:10 16.07.2020     77.93.211.207, HTTP GET OK
ve: 01:59:11 16.07.2020     77.93.211.207, HTTP GET OK
ve: 01:59:11 16.07.2020     77.93.211.207, HTTP GET OK
ve: 02:14:12 16.07.2020     192.168.1.110, HTTP GET OK
ve: 02:14:12 16.07.2020     77.93.211.207, HTTP GET OK
ve: 02:14:12 16.07.2020     77.93.211.207, HTTP GET OK
ve: 02:14:13 16.07.2020     77.93.211.207, HTTP GET OK
ve: 02:14:13 16.07.2020     77.93.211.207, HTTP GET OK
ve: 02:15:23 16.07.2020     77.93.211.207, HTTP GET chyba 9
ve: 02:15:23 16.07.2020     77.93.211.207, HTTP GET chyba 2

Restart na dálku (přes nastavení IP adresy) to rozběhne, ale u obou zařízení jsem to už musel dělat 2x.
Přitom SDS je funkční, jen neprojde odesílání dat na portál, přes SDS control panel se na zařízení dá podívat, totéž přímý přístup na web zařízení. Také uvažuji o nahrání předchozí verze FW, která fungovala bez problémů.
Používám pouze mírně modifikovaný program vygenerovaný z webu, jen odečty a záznamy 3 S0 měřidel a asi 7 teploměrů, hlídání překročení mezních hodnot a watchdog. Žádná složitost. User WEB stránku nepoužívám, na adrese 192.168.1.110 je spuštěn sds_log, pokouším se o záznam abych v budoucnu mohl obejít pomalý a nespolehlivý portál, na jehož problémy jsem už několikrát upozorňoval.