Evidentně na spodní časové ose nedochází ke konverzi NTP času na datetime. Dříve bylo v grafu na ose X datum a čas a nyní je tam počet sekund. Ale není ten počet sekund nějaký malý? Nemělo by to číslo být řádově vyšší? Není možné, že SDS zařízení odněkud dostává nesprávný údaj o čase? Jenom brainstormuju ...

Měření spotřeby i okamžitého výkonu funguje korektně, jenom ten graf je nečitelný (rozhozený). Prosím, čím by to mohlo být, jak to mám opravit?

Doplňující info: v menu "STAV - Historie" je dole následující blok:

Historie OSI7
Čas    Událost
up: +1625500     85.207.71.18, HTTP GET OK
up: +1626402     85.207.71.18, HTTP GET OK
up: +1627303     85.207.71.18, HTTP GET OK
up: +1628205     85.207.71.18, HTTP GET OK
up: +1629106     85.207.71.18, HTTP GET OK
up: +1630007     85.207.71.18, HTTP GET OK
up: +1630007     85.207.71.18, HTTP GET OK
up: +1630909     85.207.71.18, HTTP GET OK
up: +1631810     85.207.71.18, HTTP GET OK
up: +1632712     85.207.71.18, HTTP GET OK
up: +1633613     85.207.71.18, HTTP GET OK

Myslel jsem, že +1625500 je něco jako timestamp = počet sekund, ale tento počet sekund odpovídá cca 19 dnům. A mimochodem mám druhé SDS zařízení, ve kterém měřím jenom teploty a nikoli S0, a v něm je úplně stejně rozhozený graf (ačkoli je tam nulová spotřeba, protože není připojen žádný elektroměr), na ose X v grafu je úplně stejně neinterpretován datum a čas a v bloku Historie OSI7 jsou řádově stejné hodnoty.

Naměřené teploty zobrazuji na User Web Page (http://192.168.1.251/user.htm), kterou jsem upravil na základě nějakého příkladu z vaší podpory. Problém není přímo s User Web Page, nicméně uvnitř user.htm pomocí javascriptového http requestu načítám hodnoty teplot ze zařízení. Následující ukázka není přesnou kopií použitého kódu, ale "vyzobávám" z něj jen podstatné věci:

reqTemp=false;
if(window.XMLHttpRequest){
     reqTemp=new XMLHttpRequest();
}
else if (window.ActiveXObject){
     reqTemp=new ActiveXObject("Microsoft.XMLHTTP");
}
if (reqTemp){
     reqTemp.open("GET", "get_ram[292]?rn=16&rand="+Math.random(), true);
     reqTemp.onreadystatechange = reqTempComplete;
     reqTemp.send(null);
}

function reqTempComplete(){
  if(reqTemp.readyState == 4){
    if(reqTemp.status == 200){
      if (reqTemp.responseText!='') {
        var rE=reqTemp.responseText.split("|");
        var rE=reqTempXML.responseText.split("|");
   ...

Takže http requestem získám řetězec 16ti hodnot a ty pak splituju do pole a dále v kódu každou hodnotu dělím 100 ... to je vše v pořádku. Pro simulaci získaných hodnot mohu přímo do adresní řádky prohlížeče vepsat následující URL:

192.168.1.251/get_ram[292]?rn=16

Strukturu parametrů requestu chápu tak, že požaduji vypsání 16ti hodnot z RAM paměti od indexu 292. Je to tak?

A v prohlížeči pak vidím získané hodnoty:

6868|3975|2950|3250|2800|2631|5325|2818|2600|5125|5537|2350|6300|3675|768|687

PROBLÉM je, že takto získané hodnoty (citované v předchozím rámečku) neobsahují záporné hodnoty. Pokud je na některém z čidel záporná hodnota (menší než 0), tak na příslušném místě responseTextu je poslední naměřená nezáporná hodnota.

Včera jsem toto chování simuloval obložením jednoho čidla chladícími vložkami z mrazáku Myslel jsem si, že mám nějakou chybu v javascriptu User Web Page, ale pak jsem si to ověřil přímo v browseru zadáním výše zmíněné URL. Problém jsem vyřešil tak, že naměřené hodnoty získávám http requestem z jiné URL:

192.168.1.251/temp.xml

a na této URL správně dostávám XML se správnými (i zápornými) hodnotami.

Nicméně mě napadlo, že byste o tomto problému chtěli vědět. Předpokládám, že se to dá opravit ve firmwaru ... ale tím si nejsem jistý. Pro upřesnění dodávám, že pracuji jako webový programátor (PHP, SQL, HTML, JAVASCRIPT, CSS). Podle toho můžete formulovat odpověď.

Závěrem mi dovolte poděkovat vám za vaší práci a podporu. Pomocí vaší technologie měřím teploty v topném systému našeho domu a také spotřebu elektřiny. Získané hodnoty mi pomohli významně optimalizovat provoz topného systému i spotřebu elektřiny v domácnosti. Výborná práce!

POZOR: Při emulaci Windows na OsX (Parallels) se zablokuje z bezpečnostních důvodů přenos a aktualizace se neprovede a opakuje se hláška "sending initial packet to..."

Velký dík patří panu Prejdovi za rychlou pomoc.

C.Motl

Nějaké nápady? Máte někdo zkušenost z řízením kotlů Vaillant/ProTherm přes napěťové rozhraní? Musí se v řídící jednotce někde výslovně nastavit, že má reagovat na napěťový vstup, když jeho hodnotu už prokazatelně vidí?

Díky za každý tip.

Martin

Ještě přikládám log z arp.htm

[ARP:A]
210 50:D4:F7:D6:77:C5 - 192.168.0.1

[ARP:B]
210 8C:85:90:5F:4D:95 - 192.168.0.193

[HTTP-GET]
con=0 grl=295 rc=1026 timH=71147 timS=3915462163

[TCP]
[0] 192.168.0.193:17856 timew
[1] 192.168.0.193:20416 estab
[2] 192.168.0.193:52223 closed
[3] 192.168.0.193:52735 closed
[4] 192.168.0.193:53247 closed
[5] 192.168.0.193:53759 closed
[6] 192.168.0.193:54271 closed
[7] 192.168.0.193:56319 closed
[8] 192.168.0.193:55295 closed
[9] 192.168.0.193:55807 closed
[10] 192.168.0.193:56831 closed
[11] 192.168.0.193:57343 closed
[12] 192.168.0.193:57855 closed
[13] 192.168.0.193:18368 timew
[14] 192.168.0.193:18880 timew
[15] 192.168.0.193:19392 timew
[16] 192.168.0.193:50931 closed
[17] 192.168.0.193:51443 closed

Po jaké době od přivedení impulsu (např. na AD1) přepne čítač z T0 na T1 ? Jak dlouhý musí být tento impuls resp. jaké má mít parametry?

Dále uvažuji využít napěťová čidla jako dalčí čítač impulsů. Jaké impulsy by s nimi mělo jít načítat (min. a max. délka impulsu)?

Děkuji za odpověď

Děkuji. A