Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Charging elapsed time display is incorrect due to time zone issues #170

Closed
sandeen opened this issue Mar 29, 2018 · 8 comments
Closed

Charging elapsed time display is incorrect due to time zone issues #170

sandeen opened this issue Mar 29, 2018 · 8 comments
Assignees

Comments

@sandeen
Copy link
Contributor

sandeen commented Mar 29, 2018

When RAPI tells me elapsed time is 1144s, the HTML display tells me "18:19:04" instead of the correct 00:19:04. This is because of time zone issues apparently, and the way that elapsed time is handled:

self.elapsedNow(new Date((openevse.status.elapsed() * 1000) + ((new Date()) - self.elapsedLocal())));

I can't quite tell what this is trying to do, to be honest... but the 18 hours above seems to be because I am at GMT-6:00, so 00 hours GMT is 18H in my time zone.

Would using new Date(0,0,0,0,0,1144,0) give the right answer for an elapsed time, which should not care about time zones? I admit I get confused w/ javascript time, browser time, time zones, and the like.

@glynhudson
Copy link
Contributor

Thanks for reporting. I tired setting my PC's time to -6hrs but I'm unable to replicate. Please could you post the output of

http://openevse.local/status

@sandeen
Copy link
Contributor Author

sandeen commented Mar 30, 2018

{"mode":"STA","wifi_client_connected":1,"srssi":-83,"ipaddress":"10.0.0.103","emoncms_connected":1,"packets_sent":39772,"packets_success":37285,"mqtt_connected":1,"ohm_hour":"NotConnected","free_heap":23144,"comm_sent":594703,"comm_success":594666,"amp":0,"pilot":24,"temp1":157,"temp2":0,"temp3":230,"state":1,"elapsed":13853,"wattsec":31999214,"watthour":1006230,"gfcicount":0,"nogndcount":0,"stuckcount":0,"divertmode":1}
image

@sandeen
Copy link
Contributor Author

sandeen commented Mar 30, 2018

(hm, weird that divertmode:1 but the slider is off?)

@glynhudson
Copy link
Contributor

Thanks, I can see the issue.

Divertmode 1 is means normal charge. While divert mode 2 is 'eco' mode:

#define DIVERT_MODE_NORMAL 1

@sandeen
Copy link
Contributor Author

sandeen commented Mar 30, 2018

Oops sorry. Base-0 brain here ;)

@sandeen
Copy link
Contributor Author

sandeen commented Mar 30, 2018

Sorry - after an update to 2.7.0 and a restart, now I don't see it. Somehow I had missed this change:

-    return addZero(dt.getHours())+":"+addZero(dt.getMinutes())+":"+addZero(dt.getSeconds());
+    return addZero(dt.getUTCHours())+":"+addZero(dt.getMinutes())+":"+addZero(dt.getSeconds());

which was kinda buried in commit bf14d0f RTC detect complete

@sandeen sandeen closed this as completed Mar 30, 2018
jeremypoulter added a commit to jeremypoulter/ESP8266_WiFi_v2.x that referenced this issue Apr 8, 2018
This was referenced Apr 8, 2018
@glynhudson
Copy link
Contributor

@sandeen this issue should be now fixed in a better way in the latest version V2.7.1. Please could you test and confirm. Thank you

https://github.com/OpenEVSE/ESP8266_WiFi_v2.x/releases/tag/2.7.1

@sandeen
Copy link
Contributor Author

sandeen commented Apr 12, 2018

Thanks, I'll give it a shot soon; I'm recently having a strange problem where I cannot reach the web interface or even ping the device after it's been up for a while, but mqtt messages are still sent/received... I'll need to reset it to get the new firmware image on it.

Stef-Sijben pushed a commit to Stef-Sijben/ESP8266_WiFi_v2.x that referenced this issue Apr 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants