[Ovmsdev] Terrible Network Manager

Mark Webb-Johnson mark at webb-johnson.net
Mon Oct 30 15:48:31 HKT 2017


If it helps to make it less terrible, I’ve updated the ovms_server_v2 code to be ovms_netmanager aware. It should now wait for a network transport to become available, disconnect if the network goes down, and try to reconnect repeatedly until it makes a connection. It also shows status in response to the ‘server v2 status’ command.

Wifi still won’t auto-recover, but at least the server v2 should be more robust.

Architecturally, we have ovms_netmanager. That should provide a network connection framework, as well as standardised events for network transport status. The other parts of the system should use this. I also want to extend ovms_netmanager to be able to automatically manage network transport logic (as an default option). For example, if wifi becomes available then shutdown the simcom modem link. If wifi becomes unavailable, then start the simcom modem link. etc.

Regards, Mark.

> On 28 Oct 2017, at 7:28 PM, Tom Parker <tom at carrott.org> wrote:
> 
> Hi,
> 
> I've been driving around with the v3 hardware in my car for a couple of weeks using my phone's wifi hotspot. I found that it wouldn't re-connect to my phone after I turned off the hotspot and it wouldn't connect to my house wifi when the car is at home. So fixed it with a terrible network manager:
> 
> https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/compare/master...carrott:terrible-network-manager
> 
> This network manager is terrible:
> 
> * it doesn't scan for available wifi and try to connect to only those that are available
> * it tries to connect to the next network once per minute, meaning it can take several minutes to connect
> * it iterates through a list of 3 networks, if you don't have 3 networks, you still have to wait
> * it's implemented using a mixture of events, scripts and terrible C++ code
> * it should use string concatenation to make the event names, rather than 3 hard coded names, but if it did that then the terrible C++ code wouldn't be so terrible
> * you can't turn it on or off except in sdkconfig. If it's compiled in, it tries to connect every minute
> * it doesn't connect to my office wifi, I haven't looked in to why, maybe it is because there is a space in the SSID name on that network
> 
> Despite being so terrible, it's been pretty reliable for me. I'm not sure if you want a pull request for this thing, or perhaps someone could re-write it "properly". The obvious thing to do is to scan for available networks, look at the list of configured SSID-Password pairs and if any are in range, trigger the wifi connection directly rather than triggering an event that runs a script that attempts to connect to the network.
> 
> If you want to try it out, I wrote some instructions:
> 
> Beware that the following advice appends to files, but does not confirm they are empty before doing so, be sure you don't end up with unexpected scripts or script content, as unexpected things could happen.
> 
> Store the credentials for your wifi network(s) with
> config set wifi.ssid <ssid> <password>
> 
> Create a script to stop the v2 server when the network goes down (note the "network.down" doesn't fire, so use system.wifi.sta.disconnected):
> vfs mkdir /store/events/system.wifi.sta.disconnected
> vfs append "server v2 stop" /store/events/system.wifi.sta.disconnected/shutdown
> 
> Create a script to start the v2 server client when the network comes up:
> vfs mkdir /store/events/network.up
> vfs append "server v2 start" /store/events/network.up/startmeup
> 
> Create a script to select a vehicle on startup:
> vfs mkdir /store/events/system.start
> vfs append "vehicle module NL" /store/events/system.start/startmeup
> 
> Create scripts to connect to your wifi network in response to the terrible network manager events:
> vfs mkdir /store/events/tnm.connect.0
> vfs append "wifi mode client <ssid_1>" /store/events/tnm.connect.0/connect
> vfs mkdir /store/events/tnm.connect.1
> vfs append "wifi mode client <ssid_2>" /store/events/tnm.connect.1/connect
> vfs mkdir /store/events/tnm.connect.2
> vfs append "wifi mode client <ssid_3>" /store/events/tnm.connect.2/connect
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev



More information about the OvmsDev mailing list