Hi folks, One thing I've noticed in setting up the OVMS module is that my experience with the term "default" is a bit different than what we have implemented. In the past, I have come to expect "default" to mean "if you don't do anything, you will get this". Instead, we seem to be using it to mean "unless you need to use something else, use this value". In the former case, one properly leaves the entry empty or otherwise unchanged. In the later case, we show the value, but it is up to the user to actually configure it. Leaving the entry in its default state is not correct. Where this most recently affected things was the automatic update to version .006, which did not occur on time. Investigating, there were a couple of fields labeled with the default phrasing (e.g. the server address) that were, as I thought instructed, left blank. Filling them in with the default contents and pressing save worked. Next morning, I awoke to .006 running on the module. Yea! Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT. Is this just my own weird view of the world? Is it worth changing either the on-screen instructions to clarify what action needs to be taken, or should we actually implement (pre-configure) the defaults so that no further action needs to be taken by the user? My recollection is that this is not just with the webserver UI; the command line setup is equally in need of active management, for example to get the v2 server to connect. There are lots of defaults all over the place, but none of them are implemented by default. At least we are consistent... Greg
Greg, in my view, a default is always also the fallback if the config is missing. For config options that must have a value, it's the preconfigured value and the one you would get from a "reset" action. Every other behaviour is a bug. Regarding the OTA server & tag inputs, I'm sure they work as they should. I fixed the server fallbacks, and I tested that: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7cac... As you now have SD logging activated, please provide the log of the night you expected the update to happen, so we can see what failed. Another idea… if you've still been using the last "main" release (?), you didn't have my fix, as it wasn't included in the 3.1.005 release. If you do, please consider changing to the "edge" tag, to help avoid redundant bug searches and to help in testing the development head. Regarding the server v2 config, that is absolutely working with the defaults. I know that, because I'm using them. I've got no explanation for your time zone issue. My timezone is "CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" and has been stable since I set it some main releases ago. Regards, Michael Am 22.05.2018 um 19:19 schrieb Greg D.:
Hi folks,
One thing I've noticed in setting up the OVMS module is that my experience with the term "default" is a bit different than what we have implemented. In the past, I have come to expect "default" to mean "if you don't do anything, you will get this". Instead, we seem to be using it to mean "unless you need to use something else, use this value". In the former case, one properly leaves the entry empty or otherwise unchanged. In the later case, we show the value, but it is up to the user to actually configure it. Leaving the entry in its default state is not correct.
Where this most recently affected things was the automatic update to version .006, which did not occur on time. Investigating, there were a couple of fields labeled with the default phrasing (e.g. the server address) that were, as I thought instructed, left blank. Filling them in with the default contents and pressing save worked. Next morning, I awoke to .006 running on the module. Yea!
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT.
Is this just my own weird view of the world? Is it worth changing either the on-screen instructions to clarify what action needs to be taken, or should we actually implement (pre-configure) the defaults so that no further action needs to be taken by the user?
My recollection is that this is not just with the webserver UI; the command line setup is equally in need of active management, for example to get the v2 server to connect.
There are lots of defaults all over the place, but none of them are implemented by default. At least we are consistent...
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, Ok, perhaps it is time for me to blow my module back to factory defaults and start over. If blank entries really default to the default settings, that should be visible now. That my module's config dates back to version .003 might be the issue here, and not be representative of what a new user would see. Unfortunately, while I do have the SD card inserted, I got distracted and didn't turn on active logging to it. So, no log files are present. My conclusion, however, is that the server name was not present (not configured), as the field was blank when I went back to the config page. This may simply be that my configuration was first initialized back with version .003, and your changes to manage the initial bring-up were checked in later. If I were to have just received the module with version .006, it would behave differently. Starting over should prove that. As for the timezone, see my next email... :) Greg Michael Balzer wrote:
Greg,
in my view, a default is always also the fallback if the config is missing. For config options that must have a value, it's the preconfigured value and the one you would get from a "reset" action. Every other behaviour is a bug.
Regarding the OTA server & tag inputs, I'm sure they work as they should. I fixed the server fallbacks, and I tested that: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7cac...
As you now have SD logging activated, please provide the log of the night you expected the update to happen, so we can see what failed.
Another idea… if you've still been using the last "main" release (?), you didn't have my fix, as it wasn't included in the 3.1.005 release. If you do, please consider changing to the "edge" tag, to help avoid redundant bug searches and to help in testing the development head.
Regarding the server v2 config, that is absolutely working with the defaults. I know that, because I'm using them.
I've got no explanation for your time zone issue. My timezone is "CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" and has been stable since I set it some main releases ago.
Regards, Michael
Am 22.05.2018 um 19:19 schrieb Greg D.:
Hi folks,
One thing I've noticed in setting up the OVMS module is that my experience with the term "default" is a bit different than what we have implemented. In the past, I have come to expect "default" to mean "if you don't do anything, you will get this". Instead, we seem to be using it to mean "unless you need to use something else, use this value". In the former case, one properly leaves the entry empty or otherwise unchanged. In the later case, we show the value, but it is up to the user to actually configure it. Leaving the entry in its default state is not correct.
Where this most recently affected things was the automatic update to version .006, which did not occur on time. Investigating, there were a couple of fields labeled with the default phrasing (e.g. the server address) that were, as I thought instructed, left blank. Filling them in with the default contents and pressing save worked. Next morning, I awoke to .006 running on the module. Yea!
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT.
Is this just my own weird view of the world? Is it worth changing either the on-screen instructions to clarify what action needs to be taken, or should we actually implement (pre-configure) the defaults so that no further action needs to be taken by the user?
My recollection is that this is not just with the webserver UI; the command line setup is equally in need of active management, for example to get the v2 server to connect.
There are lots of defaults all over the place, but none of them are implemented by default. At least we are consistent...
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Greg, there was no change involving clearing the v2 server config, so that's not the reason your config was lost. There is no default for the v2 server host name. I took care to make the web config help texts and placeholders tell users where defaults exist (i.e. "optional" or "leave empty"). It's an open todo to add the "enable" options and config tests (i.e. as in the setup wizard) to the single config pages. If "enabled" is checked, the config page can then make a missing mandatory input an error. Until this has been implemented, you need to know/guess what is going on behind the scenes. Regards, Michael Am 23.05.2018 um 01:18 schrieb Greg D.:
Hi Michael,
Ok, perhaps it is time for me to blow my module back to factory defaults and start over. If blank entries really default to the default settings, that should be visible now. That my module's config dates back to version .003 might be the issue here, and not be representative of what a new user would see.
Unfortunately, while I do have the SD card inserted, I got distracted and didn't turn on active logging to it. So, no log files are present. My conclusion, however, is that the server name was not present (not configured), as the field was blank when I went back to the config page. This may simply be that my configuration was first initialized back with version .003, and your changes to manage the initial bring-up were checked in later. If I were to have just received the module with version .006, it would behave differently. Starting over should prove that.
As for the timezone, see my next email... :)
Greg
Michael Balzer wrote:
Greg,
in my view, a default is always also the fallback if the config is missing. For config options that must have a value, it's the preconfigured value and the one you would get from a "reset" action. Every other behaviour is a bug.
Regarding the OTA server & tag inputs, I'm sure they work as they should. I fixed the server fallbacks, and I tested that: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/7cac...
As you now have SD logging activated, please provide the log of the night you expected the update to happen, so we can see what failed.
Another idea… if you've still been using the last "main" release (?), you didn't have my fix, as it wasn't included in the 3.1.005 release. If you do, please consider changing to the "edge" tag, to help avoid redundant bug searches and to help in testing the development head.
Regarding the server v2 config, that is absolutely working with the defaults. I know that, because I'm using them.
I've got no explanation for your time zone issue. My timezone is "CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" and has been stable since I set it some main releases ago.
Regards, Michael
Am 22.05.2018 um 19:19 schrieb Greg D.:
Hi folks,
One thing I've noticed in setting up the OVMS module is that my experience with the term "default" is a bit different than what we have implemented. In the past, I have come to expect "default" to mean "if you don't do anything, you will get this". Instead, we seem to be using it to mean "unless you need to use something else, use this value". In the former case, one properly leaves the entry empty or otherwise unchanged. In the later case, we show the value, but it is up to the user to actually configure it. Leaving the entry in its default state is not correct.
Where this most recently affected things was the automatic update to version .006, which did not occur on time. Investigating, there were a couple of fields labeled with the default phrasing (e.g. the server address) that were, as I thought instructed, left blank. Filling them in with the default contents and pressing save worked. Next morning, I awoke to .006 running on the module. Yea!
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT.
Is this just my own weird view of the world? Is it worth changing either the on-screen instructions to clarify what action needs to be taken, or should we actually implement (pre-configure) the defaults so that no further action needs to be taken by the user?
My recollection is that this is not just with the webserver UI; the command line setup is equally in need of active management, for example to get the v2 server to connect.
There are lots of defaults all over the place, but none of them are implemented by default. At least we are consistent...
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
On Tue, 22 May 2018, Greg D. wrote:
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT.
Because the ESP-IDF system does not have all the compiled-in timezone code, we need to specify how to manage daylight saving time using the long value for the TZ parameter. So not even PST8PDT is sufficient, you need "PST8PDT,M3.2.0/2,M11.1.0". -- Steve
While I agree in general with the points you make, there are limitations on both the platform and the community. Firstly, we don’t currently target this as an end-user device. We clearly say "Designed for technically experienced OVMS v2 users and v3 developers”. Main reason for this is to limit support calls, until firmware gets more mature, but also because it is relatively easy to make a developer kit when compared to an end-user product. We simply don’t have paid commercial support; everybody here are unpaid volunteers. We could dumb-down the config setting for timezone, by not supporting DST auto-switch. A simple -12 .. 0 .. +12 dropbox selection. That is what a lot of consumer devices do. But, that just seems wrong if we have the capability. Does your HP 100LX handle DST auto-switch at all? We can’t add nice country/city selection because of this: $ du -sh /usr/share/zoneinfo 5.5M /usr/share/zoneinfo That is from a Linux box. We don’t have 5.5MB of flash to store all the timezone settings. Maybe we could do some api in the cloud to look-up, but that is quite some work. There are the iana rules files, which are smaller at 1.1MB, but still too big. They include all the historical info that we don’t need. I guess we could write some sort of parser and library to get it, but not at all easy. So, the options are: Dumb it down, and drop DST switching Leave it as it is Someone take it on as a sub-project to make it easier (just a simple country/city -> posix string mapping) Regards, Mark. P.S. As to the politics of timezones, I live in ‘HKT-8’ (POSIX string). No DST (since the 70’s). I have never really understood how DST can still exist in the modern age, and how the rules can be so complex. The cost of lost productivity must be horrendous.
On 23 May 2018, at 7:36 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Steve, all,
This totally highlights the problem. No offense intended to the developers (myself included), but we've not structured the product very well for "normal" folks who are somewhat technical, but have no inside knowledge of the product, prior versions, Linux, ESP-IDF, etc.
How was I to know what to put in the Timezone field? Bear with me as I walk through my troubled mental process... And please take this as me trying to be helpful.
// Begin Rant
So, I've seen configuration screens a bazillion times asking for timezone. If there's not a pull-down, usually I would put in -7 for the US Pacific Daylight Time that I'm in right now, or -8 if on Standard Time, and make a mental note to change it next fall. Not a big deal; there are a dozen "clocks" here at the house that need semi-yearly care. What's one more? Sometimes the config would be -8 with a checkbox for enabling DST. More recent product config screens sometimes use cities, with Los Angeles being our "local" example. That's been the set, so glancing at (but not truly understanding the implications of) the fine print on the configuration screen, I simply put in my -7 and moved on. It's been that way for weeks, and I never noticed anything wrong until I saw the "GMT" reference on the Time at Boot status that I recently added. Should have been "PDT". Something's wrong. Playing the ever-so-observant beta tester, I dig in...
So, back to the config screen I went. First, where was it? I was doing a firmware update, but it's not there, and there's no General config tab. Nothing labeled "Time". Finally found it under Vehicle. Really? I see my -7 still sitting there, so it wasn't lost. Finally I re-read the comment about a web link to "Example Timezone Strings", and think, huh, I guess there must be some other way to say "-7". I click on the link, and scan down the table. It says USA & Canada, Pacific Time, and PST8PDT. Odd, but ok. Copy & paste. Hit Save. Go back to the status page, and see PDT on the aforementioned boot status line. Also see the upgrade was done yesterday afternoon, and realize that was 2am GMT, so I guess it checks out. Annoying, but DONE.
Now you tell me I'm not done, and that I really needed to click on the second link to the man page on glibc? And understand it? Then research what the rules for DST computation are in my country, state, and so forth, to craft some sort of command lingo for the TZ engine?
Reality check here. My HP 100LX palmtop, manufactured in 1992, does a better job at handling this. We've taken a simple task of entering a small, well known signed integer, and turned it into an exercise in POSIX programming and international politics. This for a parameter that has little, if any, consequence on the daily operation of the product as I currently use it.
// End Rant
With a grateful acknowledgment to Michael for his awesome work on the Webserver UI, I think we should take a pass through the configuration steps with an eye towards making this as turn-key as possible. I understand that he's made some significant changes to the UI since my module arrived (back on .003 code), so the improvements in initial config have not been reflected in what I am running now (since the config has already been set). As I noted in my previous email, I will blow my module back to factory defaults and start over, looking for places where we might improve things.
I know that the V3 OVMS module is a VAST improvement over the prior versions, even without having experienced them myself. But to reach a broader audience, we need to continually look to improve the setup / configuration experience, especially as we add new and even more powerful features.
Greg
Stephen Casner wrote:
On Tue, 22 May 2018, Greg D. wrote:
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT. Because the ESP-IDF system does not have all the compiled-in timezone code, we need to specify how to manage daylight saving time using the long value for the TZ parameter. So not even PST8PDT is sufficient, you need "PST8PDT,M3.2.0/2,M11.1.0".
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Greg, I think your complaints are unfounded. Right under the field in the Vehicle config page where you enter the timezone are two web links, the first giving a list of strings for various locations and the second pointing to the specification for the string. This tells the user what input is expected. Now, I concede this is not perfect because in the first link the US/Canada strings are not complete (e.g. just "PST8PDT" rather than "PST8PDT,M3.2.0/2,M11.1.0") and I don't know what the code does in that case. Perhaps we can find another link that gives the complete strings for a more complete list of locations. And the second link is fine for geeks but may not be for the average user. Furthermore, I think your expectation that most people understand their timezone in numerical format is not correct. Even those who know that the difference between PST and GMT is 8 hours might be uncertain whether they should enter 8 or -8. And many do not know whether DST means that number should be 7 or 9. Just as a test, I asked my wife; she did not know. And for anyone using OVMS for scheduling, having it not handle the DST shift automatically is a real liability. If we did accept a simple numeric format, users in zones with DST would have to change the config twice a year. That's a pain. I compare it to the cheap little DVR box I use. It requires that I set or clear a DST checkbox at the beginning and end of summer. More than once I have forgotten this and missed my intended recording. -- Steve
Greg, I haven't found a web site that offers a simple timezone string generator, your links also don't provide that. I can include a list of standard zones for the main regions/capital cities into the web UI. Can you provide that? Thanks, Michael Am 23.05.2018 um 01:36 schrieb Greg D.:
Hi Steve, all,
This totally highlights the problem. No offense intended to the developers (myself included), but we've not structured the product very well for "normal" folks who are somewhat technical, but have no inside knowledge of the product, prior versions, Linux, ESP-IDF, etc.
How was I to know what to put in the Timezone field? Bear with me as I walk through my troubled mental process... And please take this as me trying to be helpful.
// Begin Rant
So, I've seen configuration screens a bazillion times asking for timezone. If there's not a pull-down, usually I would put in -7 for the US Pacific Daylight Time that I'm in right now, or -8 if on Standard Time, and make a mental note to change it next fall. Not a big deal; there are a dozen "clocks" here at the house that need semi-yearly care. What's one more? Sometimes the config would be -8 with a checkbox for enabling DST. More recent product config screens sometimes use cities, with Los Angeles being our "local" example. That's been the set, so glancing at (but not truly understanding the implications of) the fine print on the configuration screen, I simply put in my -7 and moved on. It's been that way for weeks, and I never noticed anything wrong until I saw the "GMT" reference on the Time at Boot status that I recently added. Should have been "PDT". Something's wrong. Playing the ever-so-observant beta tester, I dig in...
So, back to the config screen I went. First, where was it? I was doing a firmware update, but it's not there, and there's no General config tab. Nothing labeled "Time". Finally found it under Vehicle. Really? I see my -7 still sitting there, so it wasn't lost. Finally I re-read the comment about a web link to "Example Timezone Strings", and think, huh, I guess there must be some other way to say "-7". I click on the link, and scan down the table. It says USA & Canada, Pacific Time, and PST8PDT. Odd, but ok. Copy & paste. Hit Save. Go back to the status page, and see PDT on the aforementioned boot status line. Also see the upgrade was done yesterday afternoon, and realize that was 2am GMT, so I guess it checks out. Annoying, but DONE.
Now you tell me I'm /not done/, and that I really needed to click on the second link to the man page on glibc? And /understand/ it? Then research what the rules for DST computation are in my country, state, and so forth, to craft some sort of command lingo for the TZ engine?
Reality check here. My HP 100LX palmtop, manufactured in */1992,/* does a better job at handling this. We've taken a simple task of entering a small, well known signed integer, and turned it into an exercise in POSIX programming and international politics. This for a parameter that has little, if any, consequence on the daily operation of the product as I currently use it.
// End Rant
With a grateful acknowledgment to Michael for his awesome work on the Webserver UI, I think we should take a pass through the configuration steps with an eye towards making this as turn-key as possible. I understand that he's made some significant changes to the UI since my module arrived (back on .003 code), so the improvements in initial config have not been reflected in what I am running now (since the config has already been set). As I noted in my previous email, I will blow my module back to factory defaults and start over, looking for places where we might improve things.
I know that the V3 OVMS module is a VAST improvement over the prior versions, even without having experienced them myself. But to reach a broader audience, we need to continually look to improve the setup / configuration experience, especially as we add new and even more powerful features.
Greg
Stephen Casner wrote:
On Tue, 22 May 2018, Greg D. wrote:
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT. Because the ESP-IDF system does not have all the compiled-in timezone code, we need to specify how to manage daylight saving time using the long value for the TZ parameter. So not even PST8PDT is sufficient, you need "PST8PDT,M3.2.0/2,M11.1.0".
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
A topic on esp32.com brought up this: https://github.com/nayarsystems/posix_tz_db The approach seems similar to what I spoke about before (scrape tzdata, although they scrape install zone files directly in /usr/share/zoneinfo). I’ve attached the csv output of that. 460 time zones, about 15KB code size. That is up-to-date with tzdata 2018d-1. Including a simple library wrapper, to (a) iterate over the zone names, and (b) return the posix string for a particular name, probably less than 20KB overhead. I live in such a simple timezone, it is hard for me to judge. Is this any use? Regards, Mark.
On 26 May 2018, at 2:17 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi Michael,
Yeah, I'm not finding any good source either, which is partly why I'm scratching my head about it. Seems like it should either be a common problem (thus generating a lot of web support), or one that is highly unusual. Since there is not the plethora of helpful web sites (*), and there are a bazillion IoT devices out there, I wonder why are we so unusual / unique in this? What did we miss?
Regardless, we are here. I think at this point the site we currently link to is probably the best resource. You do have good prompts within the empty fields, but perhaps add "Refer to Example Strings link below for your locale" to make it more explicit that this requires a little bit of work to set properly.
Greg
(*) Most of the sites I found were either for programmers looking for source examples to access the locale data, or links to create random gibberish which I find oddly appropriate. None were for common folks in need of a TZ string.
Michael Balzer wrote:
Greg,
I haven't found a web site that offers a simple timezone string generator, your links also don't provide that.
I can include a list of standard zones for the main regions/capital cities into the web UI. Can you provide that?
Thanks, Michael
Am 23.05.2018 um 01:36 schrieb Greg D.:
Hi Steve, all,
This totally highlights the problem. No offense intended to the developers (myself included), but we've not structured the product very well for "normal" folks who are somewhat technical, but have no inside knowledge of the product, prior versions, Linux, ESP-IDF, etc.
How was I to know what to put in the Timezone field? Bear with me as I walk through my troubled mental process... And please take this as me trying to be helpful.
// Begin Rant
So, I've seen configuration screens a bazillion times asking for timezone. If there's not a pull-down, usually I would put in -7 for the US Pacific Daylight Time that I'm in right now, or -8 if on Standard Time, and make a mental note to change it next fall. Not a big deal; there are a dozen "clocks" here at the house that need semi-yearly care. What's one more? Sometimes the config would be -8 with a checkbox for enabling DST. More recent product config screens sometimes use cities, with Los Angeles being our "local" example. That's been the set, so glancing at (but not truly understanding the implications of) the fine print on the configuration screen, I simply put in my -7 and moved on. It's been that way for weeks, and I never noticed anything wrong until I saw the "GMT" reference on the Time at Boot status that I recently added. Should have been "PDT". Something's wrong. Playing the ever-so-observant beta tester, I dig in...
So, back to the config screen I went. First, where was it? I was doing a firmware update, but it's not there, and there's no General config tab. Nothing labeled "Time". Finally found it under Vehicle. Really? I see my -7 still sitting there, so it wasn't lost. Finally I re-read the comment about a web link to "Example Timezone Strings", and think, huh, I guess there must be some other way to say "-7". I click on the link, and scan down the table. It says USA & Canada, Pacific Time, and PST8PDT. Odd, but ok. Copy & paste. Hit Save. Go back to the status page, and see PDT on the aforementioned boot status line. Also see the upgrade was done yesterday afternoon, and realize that was 2am GMT, so I guess it checks out. Annoying, but DONE.
Now you tell me I'm not done, and that I really needed to click on the second link to the man page on glibc? And understand it? Then research what the rules for DST computation are in my country, state, and so forth, to craft some sort of command lingo for the TZ engine?
Reality check here. My HP 100LX palmtop, manufactured in 1992, does a better job at handling this. We've taken a simple task of entering a small, well known signed integer, and turned it into an exercise in POSIX programming and international politics. This for a parameter that has little, if any, consequence on the daily operation of the product as I currently use it.
// End Rant
With a grateful acknowledgment to Michael for his awesome work on the Webserver UI, I think we should take a pass through the configuration steps with an eye towards making this as turn-key as possible. I understand that he's made some significant changes to the UI since my module arrived (back on .003 code), so the improvements in initial config have not been reflected in what I am running now (since the config has already been set). As I noted in my previous email, I will blow my module back to factory defaults and start over, looking for places where we might improve things.
I know that the V3 OVMS module is a VAST improvement over the prior versions, even without having experienced them myself. But to reach a broader audience, we need to continually look to improve the setup / configuration experience, especially as we add new and even more powerful features.
Greg
Stephen Casner wrote:
On Tue, 22 May 2018, Greg D. wrote:
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT. Because the ESP-IDF system does not have all the compiled-in timezone code, we need to specify how to manage daylight saving time using the long value for the TZ parameter. So not even PST8PDT is sufficient, you need "PST8PDT,M3.2.0/2,M11.1.0".
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Just tested this entry from the list: "Europe/Berlin","CET-1CEST,M3.5.0,M10.5.0/3" Same problem as with other public examples: local time is correct, but file dates are offset 1 hour into the future. # con set vehicle timezone "CET-1CEST,M3.5.0,M10.5.0/3" Parameter has been set. # time stat Time Zone: CET-1CEST;M3.5.0;M10.5.0/3 UTC Time: 2018-06-06 08:15:18 UTC Local Time: 2018-06-06 10:15:18 CEST Provider: ntp PROVIDER STRATUM UPDATE TIME gsm-nmea 2 12 Wed Jun 6 08:15:18 2018 *ntp 1 53 Wed Jun 6 08:15:17 2018 # vfs ls /sd … 5 06-Jun-2018 11:14 testdate Maybe this is a bug in the vfs. "CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" works correctly now but I haven't tested if it would adapt to winter time. Regards, Michael Am 06.06.2018 um 08:56 schrieb Mark Webb-Johnson:
A topic on esp32.com <http://esp32.com> brought up this:
https://github.com/nayarsystems/posix_tz_db
The approach seems similar to what I spoke about before (scrape tzdata, although they scrape install zone files directly in /usr/share/zoneinfo). I’ve attached the csv output of that. 460 time zones, about 15KB code size. That is up-to-date with tzdata 2018d-1. Including a simple library wrapper, to (a) iterate over the zone names, and (b) return the posix string for a particular name, probably less than 20KB overhead.
I live in such a simple timezone, it is hard for me to judge. Is this any use?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
My mac is showing Europe/Berlin as CET-1CEST,M3.5.0,M10.5.0/3. That seems correct. I think that if local time is showing correct, then the posix time zone string is correct. It is now 8:34am UTC, and 10:34 CEST (Central European Summer Time). Perhaps VFS is not handling DST correctly? Can you put the SD card in a PC and see what time is shown there? That would tell us if it is the VFS or our handling? I read the FAT filesystems have no concept of time zone, so timestamps could either be local or utc. Seems messy. Regards, Mark
On 6 Jun 2018, at 4:28 PM, Michael Balzer <dexter@expeedo.de> wrote:
Just tested this entry from the list: "Europe/Berlin","CET-1CEST,M3.5.0,M10.5.0/3" Same problem as with other public examples: local time is correct, but file dates are offset 1 hour into the future.
# con set vehicle timezone "CET-1CEST,M3.5.0,M10.5.0/3" Parameter has been set.
# time stat Time Zone: CET-1CEST;M3.5.0;M10.5.0/3 UTC Time: 2018-06-06 08:15:18 UTC Local Time: 2018-06-06 10:15:18 CEST Provider: ntp PROVIDER STRATUM UPDATE TIME gsm-nmea 2 12 Wed Jun 6 08:15:18 2018 *ntp 1 53 Wed Jun 6 08:15:17 2018
# vfs ls /sd … 5 06-Jun-2018 11:14 testdate
Maybe this is a bug in the vfs.
"CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" works correctly now but I haven't tested if it would adapt to winter time.
Regards, Michael
Am 06.06.2018 um 08:56 schrieb Mark Webb-Johnson:
A topic on esp32.com <http://esp32.com/> brought up this:
https://github.com/nayarsystems/posix_tz_db <https://github.com/nayarsystems/posix_tz_db>
The approach seems similar to what I spoke about before (scrape tzdata, although they scrape install zone files directly in /usr/share/zoneinfo). I’ve attached the csv output of that. 460 time zones, about 15KB code size. That is up-to-date with tzdata 2018d-1. Including a simple library wrapper, to (a) iterate over the zone names, and (b) return the posix string for a particular name, probably less than 20KB overhead.
I live in such a simple timezone, it is hard for me to judge. Is this any use?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
A PC shows correct file dates, and a file created on the PC is again shown incorrectly on the module, so it's clearly the VFS. The stat() call seems to only apply the default time offset to get UTC from the file date. localtime() then applies the correct offset regarding summer time, ending up with an additional hour. I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 → localtime() applies +2 → 11:14. Regards, Michael Am 06.06.2018 um 10:43 schrieb Mark Webb-Johnson:
My mac is showing Europe/Berlin as CET-1CEST,M3.5.0,M10.5.0/3. That seems correct.
I think that if local time is showing correct, then the posix time zone string is correct. It is now 8:34am UTC, and 10:34 CEST (Central European Summer Time).
Perhaps VFS is not handling DST correctly? Can you put the SD card in a PC and see what time is shown there? That would tell us if it is the VFS or our handling?
I read the FAT filesystems have no concept of time zone, so timestamps could either be local or utc. Seems messy.
Regards, Mark
On 6 Jun 2018, at 4:28 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Just tested this entry from the list: "Europe/Berlin","CET-1CEST,M3.5.0,M10.5.0/3" Same problem as with other public examples: local time is correct, but file dates are offset 1 hour into the future.
# con set vehicle timezone "CET-1CEST,M3.5.0,M10.5.0/3" Parameter has been set.
# time stat Time Zone: CET-1CEST;M3.5.0;M10.5.0/3 UTC Time: 2018-06-06 08:15:18 UTC Local Time: 2018-06-06 10:15:18 CEST Provider: ntp PROVIDER STRATUM UPDATE TIME gsm-nmea 2 12 Wed Jun 6 08:15:18 2018 *ntp 1 53 Wed Jun 6 08:15:17 2018
# vfs ls /sd … 5 06-Jun-2018 11:14 testdate
Maybe this is a bug in the vfs.
"CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" works correctly now but I haven't tested if it would adapt to winter time.
Regards, Michael
Am 06.06.2018 um 08:56 schrieb Mark Webb-Johnson:
A topic on esp32.com <http://esp32.com/> brought up this:
https://github.com/nayarsystems/posix_tz_db
The approach seems similar to what I spoke about before (scrape tzdata, although they scrape install zone files directly in /usr/share/zoneinfo). I’ve attached the csv output of that. 460 time zones, about 15KB code size. That is up-to-date with tzdata 2018d-1. Including a simple library wrapper, to (a) iterate over the zone names, and (b) return the posix string for a particular name, probably less than 20KB overhead.
I live in such a simple timezone, it is hard for me to judge. Is this any use?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
The FAT directory structure seems to store the Y, M, D, H, M, S bitshifted into some words. It doesn’t store it as a julian date. esp-idf/components/fatfs/src.vfs_fat.c static int vfs_fat_stat(void* ctx, const char * path, struct stat * st) { ... memset(st, 0, sizeof(*st)); st->st_size = info.fsize; st->st_mode = get_stat_mode((info.fattrib & AM_DIR) != 0); fat_date_t fdate = { .as_int = info.fdate }; fat_time_t ftime = { .as_int = info.ftime }; struct tm tm = { .tm_mday = fdate.mday, .tm_mon = fdate.mon - 1, /* unlike tm_mday, tm_mon is zero-based */ .tm_year = fdate.year + 80, .tm_sec = ftime.sec * 2, .tm_min = ftime.min, .tm_hour = ftime.hour }; st->st_mtime = mktime(&tm); The code in ff.c seems to just use localtime_r. For example, f_sync just uses XDIR_ModTime that uses get_fattime which is in diskio.c as using localtime_r. That seems correct and would match your observation that the timestamp is written correctly. But given that FAT filestamps are in localtime already, presumably DST shifted by the localtime_r function, why are we calling localtime() again in the vfs_ls() function in ovms_vfs? The localtime function is defined as: The functions ctime(), gmtime(), and localtime() all take as an argument a time value representing the time in seconds since the Epoch (00:00:00 UTC, January 1, 1970... But in vfs_ls, the st.st_mtime is already localtime, not UTC.
I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 → localtime() applies +2 → 11:14.
I think maybe different: file date is 10:14 local time → stat() returns 10:14 → localtime() applies +1 (DST accounted for) → 11:14. Maybe we should be using gmtime not localtime in vfs_ls? That won’t mess with DST or east/west shifts. Regards, Mark.
On 6 Jun 2018, at 4:59 PM, Michael Balzer <dexter@expeedo.de> wrote:
A PC shows correct file dates, and a file created on the PC is again shown incorrectly on the module, so it's clearly the VFS.
The stat() call seems to only apply the default time offset to get UTC from the file date. localtime() then applies the correct offset regarding summer time, ending up with an additional hour.
I.e. file date is 10:14 → stat() applies -1 from "CET-1" → 09:14 → localtime() applies +2 → 11:14.
Regards, Michael
Am 06.06.2018 um 10:43 schrieb Mark Webb-Johnson:
My mac is showing Europe/Berlin as CET-1CEST,M3.5.0,M10.5.0/3. That seems correct.
I think that if local time is showing correct, then the posix time zone string is correct. It is now 8:34am UTC, and 10:34 CEST (Central European Summer Time).
Perhaps VFS is not handling DST correctly? Can you put the SD card in a PC and see what time is shown there? That would tell us if it is the VFS or our handling?
I read the FAT filesystems have no concept of time zone, so timestamps could either be local or utc. Seems messy.
Regards, Mark
On 6 Jun 2018, at 4:28 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Just tested this entry from the list: "Europe/Berlin","CET-1CEST,M3.5.0,M10.5.0/3" Same problem as with other public examples: local time is correct, but file dates are offset 1 hour into the future.
# con set vehicle timezone "CET-1CEST,M3.5.0,M10.5.0/3" Parameter has been set.
# time stat Time Zone: CET-1CEST;M3.5.0;M10.5.0/3 UTC Time: 2018-06-06 08:15:18 UTC Local Time: 2018-06-06 10:15:18 CEST Provider: ntp PROVIDER STRATUM UPDATE TIME gsm-nmea 2 12 Wed Jun 6 08:15:18 2018 *ntp 1 53 Wed Jun 6 08:15:17 2018
# vfs ls /sd … 5 06-Jun-2018 11:14 testdate
Maybe this is a bug in the vfs.
"CET-2,M3.5.0/02:00:00,M10.5.0/03:00:00" works correctly now but I haven't tested if it would adapt to winter time.
Regards, Michael
Am 06.06.2018 um 08:56 schrieb Mark Webb-Johnson:
A topic on esp32.com <http://esp32.com/> brought up this:
https://github.com/nayarsystems/posix_tz_db <https://github.com/nayarsystems/posix_tz_db>
The approach seems similar to what I spoke about before (scrape tzdata, although they scrape install zone files directly in /usr/share/zoneinfo). I’ve attached the csv output of that. 460 time zones, about 15KB code size. That is up-to-date with tzdata 2018d-1. Including a simple library wrapper, to (a) iterate over the zone names, and (b) return the posix string for a particular name, probably less than 20KB overhead.
I live in such a simple timezone, it is hard for me to judge. Is this any use?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Mark, no, st_mtime is UTC. The bug here…
struct tm tm = { .tm_mday = fdate.mday, .tm_mon = fdate.mon - 1, /* unlike tm_mday, tm_mon is zero-based */ .tm_year = fdate.year + 80, .tm_sec = ftime.sec * 2, .tm_min = ftime.min, .tm_hour = ftime.hour }; st->st_mtime = mktime(&tm);
…is vfs_fat_stat() doesn't set tm_isdst = -1 (auto), so it remains 0 telling mktime() to generally not apply DST. With that added, the timezone"CET-1CEST,M3.5.0,M10.5.0/3" works correctly. I've pushed the fix to our esp-idf repository. I'll include the timezone list in the web UI then. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi all. As far as I can see, when the climate control is activated, the OVMS module is supposed to detect when the car is turned on and then disable climate control. This does not work very good. My car starts climate control when I park the car one hour later. This will drain the battery if not manually disabled. The solution: The original TCU sends a frame after all the "start CC" frames. The frame looks like this, and is sent only one time: data[0] = 0x46; data[1] = 0x08; data[2] = 0x32; data[3] = 0x00; This will cause the climate control to stop after 15 min (if not connected to grid), or when car is turned on. Kind regard, Stein Arne Sordal
On 11/06/18 00:18, Stein Arne Sordal wrote:
As far as I can see, when the climate control is activated, the OVMS module is supposed to detect when the car is turned on and then disable climate control. This does not work very good. My car starts climate control when I park the car one hour later. This will drain the battery if not manually disabled.
Yes, this isn't a problem on my 2012 car -- it turns off by itself. However it is a problem in model year 2013 and onwards. The OVMS is supposed to turn off the climate control after a suitable time or when the car is turned on, but this isn't something I've tested a lot as I haven't had a chance to make the hands-free microphone work when the TCU is unplugged on my 2016 car.
The solution: The original TCU sends a frame after all the "start CC" frames. The frame looks like this, and is sent only one time:
data[0] = 0x46; data[1] = 0x08; data[2] = 0x32; data[3] = 0x00;
This will cause the climate control to stop after 15 min (if not connected to grid), or when car is turned on.
Thank you! I'll test this out over the weekend. Do you have can bus captures from car with working Nissan Connect? My car has Nissan Connect but it doesn't work because it was originally built for Japan and it's now in New Zealand and I don't have a capture of what Nissan do. I believe you have a 2016 car, and this information is for that model year? Do you happen to know (or does anyone else know) whether this is an equivalent for the 2013 through 2015 model years?
On 14 Jun 2018, at 02:46, Tom Parker <tom@carrott.org> wrote:
On 11/06/18 00:18, Stein Arne Sordal wrote:
As far as I can see, when the climate control is activated, the OVMS module is supposed to detect when the car is turned on and then disable climate control. This does not work very good. My car starts climate control when I park the car one hour later. This will drain the battery if not manually disabled.
Yes, this isn't a problem on my 2012 car -- it turns off by itself. However it is a problem in model year 2013 and onwards. The OVMS is supposed to turn off the climate control after a suitable time or when the car is turned on, but this isn't something I've tested a lot as I haven't had a chance to make the hands-free microphone work when the TCU is unplugged on my 2016 car.
The solution: The original TCU sends a frame after all the "start CC" frames. The frame looks like this, and is sent only one time:
data[0] = 0x46; data[1] = 0x08; data[2] = 0x32; data[3] = 0x00;
This will cause the climate control to stop after 15 min (if not connected to grid), or when car is turned on.
Thank you! I'll test this out over the weekend.
Do you have can bus captures from car with working Nissan Connect? My car has Nissan Connect but it doesn't work because it was originally built for Japan and it's now in New Zealand and I don't have a capture of what Nissan do.
I have attached a capture from the 2014-model when starting climate control. I see that the “stop after 15 min frame” actually is sent multiple times. I always send it one time and thats ok.
I believe you have a 2016 car, and this information is for that model year? Do you happen to know (or does anyone else know) whether this is an equivalent for the 2013 through 2015 model years?
The "stop after 15 min frame" for pre-2016 looks like this: data[0] = 0x46; Regards, Stein Arne Sordal
On 15/06/18 19:02, Stein Arne Sordal wrote:
I have attached a capture from the 2014-model when starting climate control. I see that the “stop after 15 min frame” actually is sent multiple times. I always send it one time and thats ok.
On my 2016 car if I send the 0x46 frame once, after the last 0x4e frame, the car wakes up and then goes back to sleep without enabling climate control. I adjusted things to send it a couple of seconds after the 0x4e frame and this made it work. Climate control came on and then turned off again after about 15 minutes (I removed the old code so this was the car switching itself off). Do you happen to have a capture of everything on the bus with timestamps for the whole remote climate control start up sequence? I'm guessing that the TCU is waiting for something from the car before switching to the next step. I suspect this is the same with locking, the ovms is blindly sending the remote command message a fixed number of times and the lock message causes my car to try to lock multiple times.
The "stop after 15 min frame" for pre-2016 looks like this:
data[0] =0x46;
Nice, the existing code to support new and old will work on this too.
On 22 Jun 2018, at 12:54, Tom Parker <tom@carrott.org> wrote:
On 15/06/18 19:02, Stein Arne Sordal wrote:
I have attached a capture from the 2014-model when starting climate control. I see that the “stop after 15 min frame” actually is sent multiple times. I always send it one time and thats ok.
On my 2016 car if I send the 0x46 frame once, after the last 0x4e frame, the car wakes up and then goes back to sleep without enabling climate control. I adjusted things to send it a couple of seconds after the 0x4e frame and this made it work. Climate control came on and then turned off again after about 15 minutes (I removed the old code so this was the car switching itself off).
Do you happen to have a capture of everything on the bus with timestamps for the whole remote climate control start up sequence?
Attached is a complete capture without timestamp (i used an arduino with a simple receive library).
I'm guessing that the TCU is waiting for something from the car before switching to the next step. I suspect this is the same with locking, the ovms is blindly sending the remote command message a fixed number of times and the lock message causes my car to try to lock multiple times.
Even when the TCU is completely isolated from the car, it still sends the “stop frame”. My guess is that it´s timer-based.
The "stop after 15 min frame" for pre-2016 looks like this:
data[0] = 0x46;
Nice, the existing code to support new and old will work on this too.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Am 07.06.2018 um 20:59 schrieb Michael Balzer:
I'll include the timezone list in the web UI then.
Included. Btw, there's a minor issue with strftime() and zone names for those "<…>" zones, e.g. OVMS# con lis vehicle vehicle (readable writeable) id: DEXZE85 name: Rhaa, lovely! timezone: <+1245>-12:45<+1345>,M9.5.0/2:45,M4.1.0/3:45 * timezone_region: Pacific/Chatham* units.distance: K OVMS# time stat *Time Zone: <+1245>-12:45<+1345>,M9.5.0/2:45,M4.1.0/3:45* UTC Time: 2018-06-13 21:41:32 UTC *Local Time: 2018-06-14 10:26:32 >* Provider: ntp PROVIDER STRATUM UPDATE TIME gsm-nmea 2 10 Wed Jun 13 21:41:32 2018 *ntp 1 43 Wed Jun 13 21:41:31 2018 …but I wouldn't know what name to show for such a zone as well… Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Looks good. Neat solution. If it starts with a ‘<‘, can we display the timezone as ‘local’? Or use timezone_region if available? Regards, Mark.
On 14 Jun 2018, at 5:52 AM, Michael Balzer <dexter@expeedo.de> wrote:
Am 07.06.2018 um 20:59 schrieb Michael Balzer:
I'll include the timezone list in the web UI then.
Included.
Btw, there's a minor issue with strftime() and zone names for those "<…>" zones, e.g. OVMS# con lis vehicle vehicle (readable writeable) id: DEXZE85 name: Rhaa, lovely! timezone: <+1245>-12:45<+1345>,M9.5.0/2:45,M4.1.0/3:45 timezone_region: Pacific/Chatham units.distance: K
OVMS# time stat Time Zone: <+1245>-12:45<+1345>,M9.5.0/2:45,M4.1.0/3:45 UTC Time: 2018-06-13 21:41:32 UTC Local Time: 2018-06-14 10:26:32 > Provider: ntp
PROVIDER STRATUM UPDATE TIME gsm-nmea 2 10 Wed Jun 13 21:41:32 2018 *ntp 1 43 Wed Jun 13 21:41:31 2018
…but I wouldn't know what name to show for such a zone as well…
Regards, Michael
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
And the reason it doesn’t is this (from a Linux box): $ du -sh /usr/share/zoneinfo 5.5M /usr/share/zoneinfo Regards, Mark.
On 23 May 2018, at 3:09 AM, Stephen Casner <casner@acm.org> wrote:
On Tue, 22 May 2018, Greg D. wrote:
Oh, almost... My timezone was also wrong. It was set to -7 like I do everywhere else, instead of PST8PDT. Where did that come from? My only clue to this was that the new boot status display of time at last boot said GMT instead of PDT.
Because the ESP-IDF system does not have all the compiled-in timezone code, we need to specify how to manage daylight saving time using the long value for the TZ parameter. So not even PST8PDT is sufficient, you need "PST8PDT,M3.2.0/2,M11.1.0".
-- Steve _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (6)
-
Greg D. -
Mark Webb-Johnson -
Michael Balzer -
Stein Arne Sordal -
Stephen Casner -
Tom Parker