[Ovmsdev] Reducing wifi/netmanager log messages
casner at acm.org
Fri Jan 18 15:18:03 HKT 2019
To be clear, the change I committed should fix the problem for Michael
that my earlier commit introduced, but this is not a fix for the weak
wifi performance nor the wifi getting stuck. This change only avoids
repeated log messages every 10 seconds when the wifi client is out of
range of any AP. You can observe that right away by just driving away
from your AP.
I have now implemented the changes to ovms_location to support adding
action parameters to the location configuration. I have not committed
it yet, though, because there's no code yet to make those actions
On Thu, 17 Jan 2019, Mark Webb-Johnson wrote:
> I see Steve committed another change to try to address this. I'll run it in my car, but might take a while to see if it solves the problem or not.
> Once we've got that stable, I think we are well overdue for a 3.1.012. Or maybe a 3.2.0 given the number of changes we have now?
> Regards, Mark.
> > On 17 Jan 2019, at 5:33 PM, Michael Balzer <dexter at expeedo.de> wrote:
> > Steve,
> > I'll try to find some time for a closer look this evening, but the error seems to be in there: I've reversed your commit yesterday for my module
> > and it's working perfectly again today.
> > My situation is standard (I believe...) of using wifi client mode at home and modem + wifi ap on the road. My wifi mode is apclient, using my
> > phone for the dashboard on the road.
> > Regards,
> > Michael
> > Am 17.01.19 um 00:44 schrieb Stephen Casner:
> >> I'll change the implementation to more explicit checks.
> >> -- Steve
> >> On Wed, 16 Jan 2019, Stephen Casner wrote:
> >>> Michael,
> >>> I thought that skipping the netif_set_default() and > SetDNSServer()
> >>> calls would be OK there because they should be called when the
> >>> priority interface (pri) changes. This worked for me. It was a
> >>> simplification to avoid having to make a separe check inside the DNS
> >>> code to suppress its messages when DNS did not change.
> >>> Now, I admit that comparing interface object addresses could give a
> >>> false result if the objects come and go, but again I thought that did
> >>> not happen here. Do you know why this would be different for your
> >>> situation compared to mine?
> >>> -- Steve
> >>> On Wed, 16 Jan 2019, Michael Balzer wrote:
> >>>> Steve,
> >>>> I think you broke something, I'm now losing connectivity after changing from wifi to modem or back.
> >>>> On a first quick glance, your change on OvmsNetManager::PrioritiseAndIndicate() looks suspicious to me, as the return skips the netif_set_default() and
> >>>> SetDNSServer() calls.
> >>>> Regards,
> >>>> Michael
> >> _______________________________________________
> >> 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
> > _______________________________________________
> > OvmsDev mailing list
> > OvmsDev at lists.openvehicles.com
> > http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
More information about the OvmsDev