Az ido lenyegtelen igazabol, mert azt a szerver is kuldheti, es az esp kivonhatja az addigi merest, de ez mar azert kicsit brutal hibakezeles, hogy atomtamadasra is felkeszulunk:)
Szerintem az RTC nem lenyeges. A boottol eltelt idot szamolod es a mereshez elmented azt is, meg az aktualis idot, meg az utolso szinkronizalas ota eltelt idot.
Es vagy kliens vagy szerver oldalon korrigalsz ha kell. A szerver a keresben elkuldheti a sajat idejet.
> Az idő formátum szerintem nem olyan gáz, hogy magyar formátumú... Vagy mi ezzel a baj ??
UTC. Ha mindig mindenhol azt mented, azzal szamolsz, akkor sose lesz problemad. Amint elkezded a lokalis idot bekavarni, elobb-utobb szopoagra futsz.
Ez amolyan okolszabaly. Kijelezni persze lokalisban jelzel ki. De a program mindig UTC-ben ment, azt kuldi es azt fogadja.
> GET helyett mit javasolsz ?? GET /DARAB -formát , vagy ha átteszem más portra , mondjuk TCP 90 -re ??
GET /DARAB?parameter1=value1¶meter2=value2 hogyha kell, pl:
GET /DARAB?servertime=2021-02-13T17:13:51.184Z&previous_checksum=412586
Erdemes egy watchdog funkciot is betenni:
GET /WATCHDOG?a=40&b=2
Es a valasz az 42. Azaz a kliens valaszol *es* nincs kifagyva, mert kiszamol valami egyszeru feladvanyt, amit te adsz fel.
A valaszidot is beirhatod az esp valaszaba (response_time: 123ms). Jo lenne sima json-okat adnia.
Nem szabvanyos port szerintem marhasag. Minden kereshez uj szerver uj porton?:) esp nem is tudja imho...
Rendes REST protokoll, GET, POST, PUT, DELETE. Ebbol kell boldogulni. Mindent jozan paraszti esszel atgondolsz es hajra.
Ha valamiben nem vagy biztos (most PUT van POST legyen), akkor szanj ra 10-15perc google idot, es azutan donts.
Jo lenne egy sima .md fajlba betenni a hibalehetosegeket, es arra mit csinaltal, meg az egeszet egy git projektbe.
(pl.
1. hibalehetoseg: nincs jel,
megoldas: ha x ideje nem valtozott a bemenet, akkor ERROR lesz a statusz, es minden valaszba beleirom, hogy status: normal, vagy status: error
53. hibalehetoseg: nem sikerult az idoszinkronizacio
megoldas: boot ota eltelt idot es a sikertelen (vagy sikeres) idoszinkronizaciot is mentem egy belso valtozoba.
stb, stb)
Es elobb utobb az osszes felmerulo problemara lesz megoldas vagy workaround. En igy szoktam programozni.
Es a legjobb minel hamarabb kikuldeni a "terepre" a programot, mert ugyis ott derul ki, hogy mit erdemes fejleszteni rajta.
((OFF:
Egyszer egyik cegnel 4 honapig fejlesztettem egy eleg komoly featuret (ket motort nyomatekra kellett szinkronizalni), aztan a helyszinre kimentem,
es kerdezem a munkasokat, hogy hogyan valik be az uj rakodo markologep. Hasznaljak-e a joystick tetejen a piros gombot, ami full automatan bemarkol, es a ket kotelagat egyforman terheli es ugy emeli fel (automatan). A valasz: az egy rakas szar, mert lassu. Mi csak ugy szoktuk, hogy max sebessegen az egyik kotelagat feltekerjuk es amikor csattan a markolo, akkor a masik kotelet kicsit feljebb huzzuk, hogy ne legyen laza. Mondom, hogy ugy csak az egyik kotel viszi a teljes sulyt. Valasz: oh, kibirna ez 4x ennyit, a vasuti kocsikat is meg szoktuk emelgetni vele, hogy biztos mindent kirazzunk belole.
Fasza mondom, 4 honapnyi melo. ))