Mark, 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 effective. -- Steve On Thu, 17 Jan 2019, Mark Webb-Johnson wrote:
We're up to 3.1.011-202-g3974d64, and looking good from my point of view. My javascript object code is in place, and working well. I've ported over a bunch of vehicle functions to OvmsVehicle object and they work well.
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@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@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@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev