[Ovmsdev] Default values and fields...

[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