Používám verzi R2 zakoupenou v lednu tohoto roku s posledním fw z 28.3.2016. Obě relé ovládám z portálu a náhodného sepnutí jsem si rovněž všimnul. V programu jsem si proto udělal počítadlo těchto nežádoucích stavů a výsledek mě překvapil. Za 24 hod. obě relé náhodně sepnou 6 - 10x. Tento nevyžádaný stav (obě relé sepnutá) trvá vždy do nejbližší komunikace s portálem.
Na portálu je psáno, že se jedná o beta verzi programu pro ovládání relé, tak snad můžeme očekávat nějakou opravu.

Jsem připraven k jakékoliv spolupráci, která povede k opravě chyby.
Komunikace nejlépe přes mail l***@volny.cz, případně přes telefon, uvedený při registraci.
Luboš

Pracujeme na tom...

Tak včera jsem data viděl, ale dnes ráno opět výpadek a nedostupný portál. Aktuálně už je dostupný, ale poslední data jsou zapsaná v 6.45, takže netuším, jestli se zapisují a nezobrazují, nebo vůbec nezapisují. Tak nějak jsem si na tu nespolehlivost zvykl a než zprovozním vlastní řešení, tak to prostě musím přetrpět.

Taktéž LTE T-Mobile. V době výpadku jsem měl plně funkční net, ale nebyla dostupná doména merenienergie.cz Tzn. forum a eportal. Zároveň mi jiný uživatel potvrdil, že on problém s dostupností v tom čase neměl.

Tak změna - spletl jsem to. Mám LTE doma i ve firmě. Ve firmě mám T-Mobile, doma mám O2.

Po nějakém čase tedy doplním zkušenosti s výpadky. Výpadky dostupnosti se u mě týkaly serveru eportal. Poté, co jsem přemigroval na energycloud (polovina prosince), měl jsem pouze jediný výpadek v zápisu S0. Odesílám přes O2 LTE. U mě tedy tímto vyřešeno.

Tak nově mám více informací. Konečně se mi podařilo zprovoznit odesílání emailů a hned první den v noci se mi podařilo zachytit falešné sepnutí relé- Překvapení je na světě - povel přišel z e-portálu. Takže omluva programátorovi , SDS se chová správně, netušil jsem, že portál zasílá nesprávné povely. (přepnutí kolen 2 hodiny v noci na většinou 30 minut. Po přijetí nesprávných dat nastane výpadek komu nikace s portálem, většinou 2x15 minut.  Škoda že mezipaměť pro CONZOLE je jen na cca 1200 bytů, takže záznam o dění v SDS mám jen (po ořezání večkerého balastu) na 1,5 hodiny. Při změně ve 2 hodiny v noci mi tak data utečou mimo paměť. Poznatky jsem hned v neděli zaslal panu j@m, zatím bez odezvy.

Zde vypisuji data, zaslaná mailem

Správný stav při přepínání:

ram[0]=3ram[1]=49ram[2]=48ram[3]=32ram[4]=0ram[5]=0ram[6]=0ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0

ram[0]=3ram[1]=48ram[2]=48ram[3]=32ram[4]=0ram[5]=0ram[6]=0ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0

Data zaslaná při nevyžádaném sepnutí
ram[0]=10ram[1]=78ram[2]=101ram[3]=112ram[4]=111ram[5]=100ram[6]=97ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0

Chyba komunikace s www serverem, http: 200

Zatím používám verzi firmware ze srpna 2017, jak se dostanu k zařízení, nahraji nový firmware z 23.10.2017.

Moje berlička - zapojení tak, že rele=1 fyzicky znamená odpojení topení a rele=0 zapne topení, způsobilo očekávaný efekt, tedy netopí se v době kdy nemá, naopak povel na rele=1 ve 2 hodiny v noci způsobí přerušení vytápšní na cca 0,5 hodiny, což zatím nevadí.

Informace pro ostatní - s novým FW z 26.10.2017 zatím vše funkční, podařilo se zachytit log při nevyžádaném sepnutí ve 2:14 dnes ráno. Pokud se v tom někdo vyznáte, tady jsou data - odesílá mail s daty z portálu pro ovládání Relé, z důvodu redukce velikosti záznamu na CONSOLE je zkráceno ram[0]=3 na r0=3 :

CONSOLE:

105 r9=108
Odesilam email...
2:14
Uspesne odeslano: ram[0]=10ram[1]=78ram[2]=101ram[3]=112ram[4]=111ram[5]=100ram[6]=97ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0
Chyba komunikace s www serverem, http: 200
2:29 Te A OK.
2:29 Server pro rele
r0=10 r1=78 r2=101 r3=112 r4=111 r5=100 r6=97 r7=248 r8=105 r9=108
2:29 AD OK.
2:29 rele OK.
2:44 Te A OK.
2:44 Server pro rele
r0=3 r1=48 r2=48 r3=32 r4=111 r5=100 r6=97 r7=248 r8=105 r9=108
Odesilam email...
2:44
Uspesne odeslano: ram[0]=3ram[1]=48ram[2]=48ram[3]=32ram[4]=111ram[5]=100ram[6]=97ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0
Chyba komunikace s www serverem, http: 200
2:59 Te A OK.
2:59 Server pro rele
r0=3 r1=48 r2=48 r3=32 r4=0 r5=0 r6=0 r7=248 r8=105 r9=108
2:59 AD OK.
2:59 rele OK.
3:14 Te A OK.
3:14 Server pro rele
r0=3 r1=48 r2=48 r3=32 r4=0 r5=0 r6=0 r7=248 r8=105 r9=108
3:15 AD OK.
3:15 rele OK.
3:30 Te A OK.
3:30 Server pro rele
r0=3 r1=48 r2=48 r3=32 r4=0 r5=0 r6=0 r7=248 r8=105 r9=108
3:30 AD OK.
3:30 rele OK.
3:45 Te A OK.
3:45 Server pro rele
r0=3 r1=48 r2=48 r3=32 r4=0 r5=0 r6=0 r7=248 r8=105 r9=108
3:45 AD OK.
3:45 rele OK.
..................................................................
VÝPIS HISTORIE

Zde je výpis zaznamenaných událostí.
Čas je počítán od zapnutí zařízení (tj. ve: +0 sec).

Statistiky připojení (ETH):
IN: 12229610 bytes (122858+154 packetů, 154 zahozeno, 255 neznámé)
OUT: 10296435 bytes (58851+0 paketů, 0 zahozeno, 0 chyb)

Poslední uživatelé    
Čas    IP
22:58:49 26.10.2017     (in) 192.168.1.100

Systémová historie    
Čas    Událost
+0     Zařízení zapnuto
+0     Relé RE1: VYP
+0     Relé RE2: VYP
+0     Výstup pin D0: log0
+0     Ethernet odpojen !
+1     Ethernet připojen
+1     Ethernet připojen
22:59:02 26.10.2017     přepnuto na Letní Čas (UTC+2)
00:30:40 27.10.2017     IP Watchdog - ztracen ping
00:30:40 27.10.2017     Relé RE2: ZAP
00:31:00 27.10.2017     Relé RE2: VYP
02:14:52 27.10.2017     Relé RE1: ZAP
02:14:52 27.10.2017     Relé RE1: ZAP
02:44:56 27.10.2017     Relé RE1: VYP

Historie OSI7    
Čas    Událost
03:15:00 27.10.2017     77.93.211.207, HTTP GET OK
03:15:00 27.10.2017     77.93.211.207, HTTP GET OK
03:30:01 27.10.2017     77.93.211.207, HTTP GET OK
03:30:01 27.10.2017     77.93.211.207, HTTP GET OK
03:30:02 27.10.2017     77.93.211.207, HTTP GET OK
03:45:02 27.10.2017     77.93.211.207, HTTP GET OK
03:45:03 27.10.2017     77.93.211.207, HTTP GET OK
03:45:03 27.10.2017     77.93.211.207, HTTP GET OK

Přijaté maily s povely z portálu pro přepnutí relé

nevyžádané sepnutí ve 2:14

ram[0]=10ram[1]=78ram[2]=101ram[3]=112ram[4]=111ram[5]=100ram[6]=97ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0

návrat do správného stavu ve 2:39 (v historii nesprávně 2:44)

ram[0]=3ram[1]=48ram[2]=48ram[3]=32ram[4]=111ram[5]=100ram[6]=97ram[7]=248ram[8]=105ram[9]=108ram[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0

Pro snadnější analýzu - shrnutí záznamů za poslední týden

28.10.2017 v 17:19 vypnuto topení (RELE=1), opět zapnuto 2.11.2017 ve 12:10 (RELE=0).
V této době i při falešném povelu k sepnutí nedojde k odeslání mailu o změně stavu RELE (změna z 1 na 1).
Navíc 29.10. kvůli vichřici několik různě dlouhých výpadků napájení, 1.11. a 3.11. 2017 v dané lokalitě od 0 hodin do
cca 6 hodin předem ohlášené možné výpadky internetu Tmobilu (úprava konfigurace sítě).
V tomto období bych tedy raději záznamy nehodnotil, příčiny chybějících dat mohou být různé.

Nicméně v ostatní době, kdy bylo požadováno RELE=0 dochází pravidelně po 2 hodině ráno k příchodu dat z
portálu, která jsou vyhodnocena jako požadavek na RELE=1, dojde k přepnutí, odejde odeslání mailu o změně
stavu na RELE=1, výpisu v konzole "Chyba komunikace s www serverem, http: 200"  a následně k výpadku
komunikace s portálem, na 1-2 x 15 minut. Pak se vše zase srovná na požadované hodnoty. Nežádoucí data
zaslaná z portálu pro relé jsou zdá se vždy stejná:
ram[0]=10ram[1]=78ram[2]=101ram[3]=112ram[4]=111ram[5]=100ram[6]=97ram[7]=248ram[8]=105ram[9]=108ram
[10]=111ram[11]=0ram[12]=0ram[13]=0ram[14]=0ram[15]=0ram[16]=0ram[17]=0ram[18]=0ram[19]=0.

Maily jsou z těchto dnů:
Datum               nechtěné přepnutí     návrat do správného stavu
27.2.2017          2:14                          2:44
28.2.2017          2:33                          2:48
28.2-2.11. požadavek RELE=1 (chyba neodešle mail) - výpadky zápisu dat na portál jsou
3.11.2017          2:28                          2:43
4.11.2017          2:31                          2:46
5.11.2017          2:19                          2:49

Po intenivnějším bádání a zkoumání programů jsem našel příčinu nechtěného spínání relé a nalezl i částečné řešení problému:
Ten sestává ze dvou částí-

1. Občas z eportálu při příjmu povelu pro rele přijdou (a jsou korektně přijata, teprve následně je chybová hláška a ztráta komunikace se serverem)  zcela nesmyslná data . S tím si poradit neumím.

2. V základním programu pro ukládání dat a ovládání relé po 15 minutách, staženém z webové stránky jsem zjistil, že stav 48 se vyhodnocuje jako povel k vypnutí RELE, cokoliv jiného jako zapnutí RELE. V souvislosti s chováním viz bod 1 tohoto příspěvku následně dojde k nevyžádanému sepnutí RELE. Změnou podmínky na 48= vypni, 49=sepni a ignorováním ostatního došlo zcela k odstranění falešných sepnutí.

Takže problém falešného sepnutí je alespoň opticky vyřešen, zbývá dořešit, proč chodí občas nesmyslná data s následným výpadkem komunikace s eportálem.