Introduction - message replay and other topics
Hello everyone, My name is Ludovic and I've just bought an OVMS for a R&D project I'm working on. I know how to read/write some (easy) code, and am not afraid of (digital) electronics too. I've managed to compile, and flash FW to this unit. My use-case is to use OVMS as an aid during the testing phase / tuning of an EV vehicle: * Using OVMS as a pure data-logger of the CAN Bus (to SD card, with an automatic offload to a remote server as soon as a network connexion is available) - i.e. logging during the runs, and dumping the data either as soon as possible, or when the vehicle is back in the shop. * Also making use of the "dashboard" functions to have an in-vehicle display (phone/tablet) of the main parameters of interest : GPS Speed, Motor RPM, some BMS parameters, some controller parameters, ... so that the test driver can have some feedback on the internals of the vehicle. Part of my plan is to explore the DBC-based vehicles of OVMS, and for that I was interested in using the "replay mode" that has been contributed to the code in 2019 : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/611b... ; however it does indeed look like a work in progress - as I wasn't able to make it replay something. I've not delved much into the code (yet ?) but it looks that some implementations are incomplete (like `canplay_vfs::InputMsg`) and could explain that. But first I wanted to ask here what was your experience with this part - is it working for you in some state, even buggy ? "replay mode" is not absolutely necessary but could be a huge time saver - otherwise I'd have to replay from another CANBus transceiver - and I'd prefer an integrated environment. "replaying" is interesting for the setup phase as I'll be able to fine-tune the DBC setup ; have the metrics generated and then have the dashboard displaying "live" data - without needing a real vehicle test. Also in the plan is to build a customized dashboard from a chosen set of metrics. This looks easy and well documented as far as I could tell, and I do not expect a lot of difficulties here ; what do you think ? Also part of the plan would be to have a way to log to fixed-size files (either based on the number of events captured on the CANBus ; or based on the duration of the capture - like every 5 minutes) and to find a way to "rsync" them to a remote server. I do not intend to use the "server" connection (be it V2 or V3) as my use-case is a little bit different and I need to retrieve raw CANBus data, not processed metrics - for later post-processing (with SavvyCAN etc...). I'm open to any advices on the feasibility of this. Finally, as a newcomer I'll also try to help with documentation on things that I struggled with or that are evident but not in the doc yet. Thanks everybody who created (and contributed to) this project that looks a fantastic tool to observe and tinker with vehicles! Please feel free to share your thoughts on this. Regards from France, Ludovic LANGE
Ludovic, welcome :-) you're right, can play is unfinished. It seems it wasn't needed up to now, you're welcome to finish it. Mark would best comment on what's missing there, as it was his concept & framework draft. Another local option is replaying a set of specific frame sequences by scripts running series of "can tx" and/or "can rx" commands. Regarding dashboard development, you can simply add a random metrics data generator to the UI. You can find templates for this in the examples: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master... Documentation of course can always be improved :-) Regards, Michael Am 10.10.22 um 00:34 schrieb Ludovic LANGE:
Hello everyone,
My name is Ludovic and I've just bought an OVMS for a R&D project I'm working on. I know how to read/write some (easy) code, and am not afraid of (digital) electronics too. I've managed to compile, and flash FW to this unit.
My use-case is to use OVMS as an aid during the testing phase / tuning of an EV vehicle:
* Using OVMS as a pure data-logger of the CAN Bus (to SD card, with an automatic offload to a remote server as soon as a network connexion is available) - i.e. logging during the runs, and dumping the data either as soon as possible, or when the vehicle is back in the shop. * Also making use of the "dashboard" functions to have an in-vehicle display (phone/tablet) of the main parameters of interest : GPS Speed, Motor RPM, some BMS parameters, some controller parameters, ... so that the test driver can have some feedback on the internals of the vehicle.
Part of my plan is to explore the DBC-based vehicles of OVMS, and for that I was interested in using the "replay mode" that has been contributed to the code in 2019 : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/611b... ; however it does indeed look like a work in progress - as I wasn't able to make it replay something.
I've not delved much into the code (yet ?) but it looks that some implementations are incomplete (like `canplay_vfs::InputMsg`) and could explain that. But first I wanted to ask here what was your experience with this part - is it working for you in some state, even buggy ?
"replay mode" is not absolutely necessary but could be a huge time saver - otherwise I'd have to replay from another CANBus transceiver - and I'd prefer an integrated environment.
"replaying" is interesting for the setup phase as I'll be able to fine-tune the DBC setup ; have the metrics generated and then have the dashboard displaying "live" data - without needing a real vehicle test.
Also in the plan is to build a customized dashboard from a chosen set of metrics. This looks easy and well documented as far as I could tell, and I do not expect a lot of difficulties here ; what do you think ?
Also part of the plan would be to have a way to log to fixed-size files (either based on the number of events captured on the CANBus ; or based on the duration of the capture - like every 5 minutes) and to find a way to "rsync" them to a remote server. I do not intend to use the "server" connection (be it V2 or V3) as my use-case is a little bit different and I need to retrieve raw CANBus data, not processed metrics - for later post-processing (with SavvyCAN etc...). I'm open to any advices on the feasibility of this.
Finally, as a newcomer I'll also try to help with documentation on things that I struggled with or that are evident but not in the doc yet.
Thanks everybody who created (and contributed to) this project that looks a fantastic tool to observe and tinker with vehicles!
Please feel free to share your thoughts on this.
Regards from France, Ludovic LANGE
_______________________________________________ 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
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 Le 10/10/2022 à 19:34, Michael Balzer a écrit :
Ludovic, welcome :-)
you're right, can play is unfinished. It seems it wasn't needed up to now, you're welcome to finish it. Mark would best comment on what's missing there, as it was his concept & framework draft.
Another local option is replaying a set of specific frame sequences by scripts running series of "can tx" and/or "can rx" commands.
Regarding dashboard development, you can simply add a random metrics data generator to the UI. You can find templates for this in the examples: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...
Documentation of course can always be improved :-)
Regards, Michael
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-po...) 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
Le 10/10/2022 à 19:34, Michael Balzer a écrit :
Ludovic, welcome :-)
you're right, can play is unfinished. It seems it wasn't needed up to now, you're welcome to finish it. Mark would best comment on what's missing there, as it was his concept & framework draft.
Another local option is replaying a set of specific frame sequences by scripts running series of "can tx" and/or "can rx" commands.
Regarding dashboard development, you can simply add a random metrics data generator to the UI. You can find templates for this in the examples: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/blob/master...
Documentation of course can always be improved :-)
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
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-po...)
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
Ludovic, you've possible mistaken the scan command for the scan mode. Scan mode is meant for that scenario. You can configure multiple APs via the web UI (Config→Wifi: client networks) or via shell using the config command. You can also configure the signal levels for dropping network associations. To configure from the shell, add a network like this: "config set wifi.ssid <ssid> <passphrase>" Regards, Michael Am 22.10.22 um 14:25 schrieb Ludovic LANGE:
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-po...)
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
_______________________________________________ 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
Michael, You're absolutely right, I did not have a look at the web UI (Config / Wifi) while researching this feature, and have been only using the shell for the configuration and the doc. In order to complement the existing doc, please find here an update proposal: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/746 Regards, Ludovic Le 22/10/2022 à 15:30, Michael Balzer a écrit :
Ludovic,
you've possible mistaken the scan command for the scan mode. Scan mode is meant for that scenario. You can configure multiple APs via the web UI (Config→Wifi: client networks) or via shell using the config command. You can also configure the signal levels for dropping network associations.
To configure from the shell, add a network like this: "config set wifi.ssid <ssid> <passphrase>"
Regards, Michael
Am 22.10.22 um 14:25 schrieb Ludovic LANGE:
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,
participants (2)
-
Ludovic LANGE -
Michael Balzer