[Ovmsdev] Network Manager Ideas

[Michael Balzer]

Am 12.12.2017 um 02:29 schrieb Mark Webb-Johnson:
> I’ve had lwip pppos (via SIMCOM) running on my desk overnight, and it seems stable. Of course, we’ll need to do some fine tuning based on feedback in the
> field, but at least PPP connections can be brought up and down cleanly, and that is the base capability needed for more sophistication to be built on top.

I did the same test since yesterday, but my ppp connection got lost somewhere and couldn't be reestablished, even after power simcom off / on.

I missed keeping my PC on, so I've lost the critical log output. The last state was a loop:

I (81512562) simcom: State: Enter NetStart state
I (81541562) simcom: State timeout, transition to 7
I (81541562) simcom: State: Enter NetLoss state
I (81541562) gsm-ppp: Shutting down (hard)...
I (81541562) gsm-ppp: StatusCallBack: User Interrupt
E (81541562) gsm-ppp: status_cb: User interrupt|
I (81541562) gsm-ppp: Shutdown (via status callback)
I (81541562) events: Signal(system.modem.down)
I (81551562) simcom: State timeout, transition to 5
I (81551562) simcom: State: Enter NetWait state
I (81551562) gsm-nmea: Startup
I (81555562) simcom: State: Enter NetStart state
I (81584562) simcom: State timeout, transition to 7
I (81584562) simcom: State: Enter NetLoss state
I (81584562) gsm-ppp: Shutting down (hard)...
I (81584562) gsm-ppp: StatusCallBack: User Interrupt
E (81584562) gsm-ppp: status_cb: User interrupt|
I (81584562) gsm-ppp: Shutdown (via status callback)
I (81584562) events: Signal(system.modem.down)
I (81594562) simcom: State timeout, transition to 5
I (81594562) simcom: State: Enter NetWait state
I (81594562) gsm-nmea: Startup
I (81598562) simcom: State: Enter NetStart state
I (81627562) simcom: State timeout, transition to 7
I (81627562) simcom: State: Enter NetLoss state
I (81627562) gsm-ppp: Shutting down (hard)...
I (81627562) gsm-ppp: StatusCallBack: User Interrupt
E (81627562) gsm-ppp: status_cb: User interrupt|
I (81627562) gsm-ppp: Shutdown (via status callback)
I (81627562) events: Signal(system.modem.down)
I (81637562) simcom: State timeout, transition to 5
I (81637562) simcom: State: Enter NetWait state
I (81637562) gsm-nmea: Startup
I (81641562) simcom: State: Enter NetStart state
I (81670562) simcom: State timeout, transition to 7
I (81670562) simcom: State: Enter NetLoss state
I (81670562) gsm-ppp: Shutting down (hard)...
I (81670562) gsm-ppp: StatusCallBack: User Interrupt
E (81670562) gsm-ppp: status_cb: User interrupt|
I (81670562) gsm-ppp: Shutdown (via status callback)
I (81670562) events: Signal(system.modem.down)
I (81680562) simcom: State timeout, transition to 5
I (81680562) simcom: State: Enter NetWait state
I (81680562) gsm-nmea: Startup

… and so on.


> So, now to think about how to manage this in general. To make it easier for the end user. Here are some notes/thoughts:
>
>  1. We continue to use events and scripting for fine-tuned control.
>
>  2. For configuration, we offer options to set values and have those automatically actioned at startup. Examples:
>       * If a vehicle type is configured, then automatically start a vehicle module of that type.
>       * If a v2 configuration is present, then automatically start a ovms server v2 connection.
>
>  3. For networking, we have the network manager component. The idea here is to extend that to provide network link logic. Examples:
>       * If wifi comes up, then sleep the simcom modem
>       * If wifi goes down, then wake up the simcom modem
>
>  4. The above configuration settings can be simply mapped to v2 protocol features/parameters.
>
>  5. While Config parameters are currently registered and visible (MyConfig.RegisterParam), instances are not. That makes it tricky to see what config
>     instances are available. In some of the code, we document the instances as comments after the parameter is registered. My suggestion here is to add a
>     MyConfig.RegisterInstance to allow for instance registration (with a default value). If the instance does not exist, then it would be created with the
>     value set as per the default. That would then make it visible to the user. The only downside to this is that the default value can’t later be changed.
>
>
> What do people think? Does that make sense as an approach? Implementation should not be difficult.

Re #2: yes, but we need some simple way to prevent the auto start, as the module may crash before interaction is possible.

Re #5: definitely, that may also allow tab command expansion down to instances.

Btw: I've always registered my config "x.rt" as readable, but "config list x.rt" will no longer show any values. I'm pretty sure it did before.

Regards,
Michael

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20171212/bf561e36/attachment.htm>