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