[Ovmsdev] Introduction - message replay and other topics

Ludovic LANGE ll-ovmsdev at lange.nom.fr
Sat Oct 22 20:25:20 HKT 2022


Hi Michael,

So if you don't mind, I'll be creating GitHub "issues" for following 
those improvements, in order to describe, plan, document, follow the 
progress on those ideas.

Regarding WiFi, the idea would be more like the "mesh" mode ; but with 
different SSIDs.
Say you have a list of different SSIDs / password. The device should try 
to connect to the first one in the config. If unable to connect, or if 
the RSSI steadily falls below a certain minimum, it will try the next in 
order in the config. Then when it reaches the end of the list, it cycles 
back to the start. Or optionally it should try to connect via modem 
connection (but I'd make this a config option also) - and if this one 
drops also, back to wifi APs list.
(RSSI level should be a config item also).

Use-case is the following:
I have a vehicle under test ; it has a OVMS on-board. The test pilot 
does some different journeys. Some starting from "home", ending at "shop 
A". Then from "shop A" to "shop B". etc... and back to "home".
It's not possible (and not wanted) to have all these locations set up 
with the same SSID / Password. So it could be interesting to have OVMS 
able to connect to each different AP.
(Automatically - the test pilot is not expected to deal with OVMS 
configuration)

Scanning mode seems (I have not fully tested all the configuration) to 
be able to list the visible APs ; but it seems there is no provision to 
configure passwords for multiple one ? Let me know if I understood it 
incorrectly.

Regards,


Le 21/10/2022 à 15:43, Michael Balzer a écrit :
> Ludovic,
>
> sounds all reasonable.
>
> Regarding Wifi, doesn't our client "scanning mode" implement what 
> you're looking for?
> (https://docs.openvehicles.com/en/latest/userguide/wifi.html#client-access-point-modes)
>
> Regards,
> Michael
>
>
> Am 19.10.22 um 00:44 schrieb Ludovic LANGE:
>> Thanks Michael !
>>
>> I'll try to have a look at the can play framework - it could surely 
>> help me speed up my dashboard development work (for the moment I'm 
>> injecting on a real CAN Bus but it's not always ideal). But not 
>> everything is clear for me in this concept, given that I don't know 
>> the whole ecosystem very well (not helping is my inability to read C++).
>> If @Mark is reading, would you mind exchanging on this topic if you 
>> have some time (and memories of what you had in mind when designing 
>> this part) ?
>>
>>
>> Here is a random dump of some other crazy ideas I'd like to share 
>> with the list (read: things I thought would be nice to discuss):
>>
>>   * Some features I like (seen in the doc of a related product):
>>
>>       o Wifi: multiple AP/SSIDs defined in order to auto-connect to
>>         the strongest signal (or ability to "roam" from one site to
>>         another without having to re-configure the Wifi)
>>
>>       o CanLog: ability to "split" log files according to some
>>         criterion : either the size (in bytes) of the log file ; or
>>         the timespan of the capture
>>
>>       o CanFormat: support for reading / writing a compressed file
>>         format (e.g. Vector's BLF, etc...)
>>
>>       o CanLog: ability to sync the log files to an external server
>>         (whenever a network connection is available), with (optional
>>         in my mind) local delete of the file after transfer.
>>
>>   * DBC-based vehicle :
>>       o In my DBC experiments, I found I needed to register new
>>         metrics. While it's possible to create a new "vehicle_"
>>         module and have the registering occur there, it kinds of
>>         defeat the dynamic aspect of the DBC approach. So I was
>>         wondering if we could introduce a dynamic registration of
>>         metrics (e.g.: have a config setup, or a file in the vfs,
>>         that lists all the metrics that we want to register during
>>         vehicle module loading)
>>
>>   * Wireguard interface : I was toying with the idea of having a
>>     network-enabled OVMS auto-registering in a dedicated network ;
>>     and being "locally" available, mdns working, web and ssh
>>     reachable... while exposing no local service on its main
>>     interface. I've seen discussion around a "firewall", and with
>>     this approach there is no more need to have one if no services
>>     are exposed.
>>     Don't know if it's feasible, a project like
>>     https://github.com/smartalock/wireguard-lwip is certainly
>>     interesting to look at (and also
>>     https://github.com/ciniml/WireGuard-ESP32-Arduino).
>>
>>
>> Let me know what you think about any of this
>>
>> Regards,
>> Ludovic
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20221022/4893e935/attachment.htm>


More information about the OvmsDev mailing list