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