[Ovmsdev] Default values and fields...

Michael Balzer dexter at expeedo.de
Wed May 23 15:23:56 HKT 2018


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.


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/7cac6b50d0de30e424d81dc0f74bd287cf4e0710#diff-f9cef0533dbf226f05322479428add0c
>> 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 at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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

More information about the OvmsDev mailing list