- OvmsDev - Open Vehicles

Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] OVMSDEV mailing list - is it still functioning? (#467)
by Michael Balzer 17 Nov '20

17 Nov '20

Mark, I could not forward the mail below to you, your server responded with… <mark(a)webb-johnson.net>: host mailtp5.network-box.com[175.45.17.210] said: 554 command rejected for policy reasons (using messageid: 1d117116-28cb-11eb-af9f-7e589b37a1b9) (in reply to end of DATA command) …which is probably a local issue, because my server is on no block list. Can you have a look at the(se) issue(s)? Regards, Michael -------- Weitergeleitete Nachricht -------- Betreff: Re: [openvehicles/Open-Vehicle-Monitoring-System-3] OVMSDEV mailing list - is it still functioning? (#467) Datum: Tue, 17 Nov 2020 03:06:05 -0800 Von: elbow <notifications(a)github.com> Antwort an: openvehicles/Open-Vehicle-Monitoring-System-3 <reply+AAUU2QPIWGN6ZRPGNWBB7LV5X6HZ3EVBNHHCYREIHM(a)reply.github.com> An: openvehicles/Open-Vehicle-Monitoring-System-3 <Open-Vehicle-Monitoring-System-3(a)noreply.github.com> Kopie (CC): Michael Balzer <dexter(a)expeedo.de>, Mention <mention(a)noreply.github.com> Hi @dexterbg <https://github.com/dexterbg> @markwj <https://github.com/markwj> , The situation with the list is unchanged. I also received bounces from my mails to lists.openvehicles.com: `This is the mail system at host nbkfmailscanhq5.network-box.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. |The mail system | < ovmsdev-owner(a)lists.openvehicles.com <mailto:ovmsdev-owner@lists.openvehicles.com>>: connect to 10.8.12.188[10.8.12.188]:25: Connection refused ` So the mx targets for lists.openvehicles.com are "network-box.com" machines. Apparently they can't forward to mail on? For me I just want to be added to the dev mailing list. Can it be done by hand? I'm making good progress reverse engineering I3 canbus pids. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/467…>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUU2QMN7LH2HBRPKWYU5ZDSQ…>. -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

1 0

Fwd: [Contact Us] Mg zs ev
by Mark Webb-Johnson 31 Oct '20

31 Oct '20

Feedback from early users. > Begin forwarded message: > > From: Marius Saldukas > Subject: Re: [Contact Us] Mg zs ev > Date: 29 October 2020 at 1:20:33 PM HKT > To: Mark Webb-Johnson <mark(a)webb-johnson.net> > > Hi i noted that car 12 v battery is going down see picture > And if you can forward for developers > Thanks > > > > > > > > >

2 1

Re: [Ovmsdev] can log vfs crashes
by Derek Caudwell 27 Oct '20

27 Oct '20

Hi Michael It crashes on can2 when trying to log all, crash seems to be just after a zero length file is created. Kind regards Derek

2 1

Roadster ESS logs
by Mark Webb-Johnson 22 Oct '20

22 Oct '20

Given the age of Tesla Roadster battery packs, and known issues with bad bricks failing and bringing down the entire pack, it is getting somewhat more urgent to be able to see battery per-brick voltages in real-time. It would also be useful to upload those as historical data to the server for historical analysis (particularly in the case a brick fails and we can then go back and see if there was any way to predict this). OVMS v3 with the 3-bus cable should be able to get this data. I’ve got a good idea of the CAN bus messages involved, but the detailed ones are not always broadcast so it will take some work to find out how best to record them. So, I’m looking for volunteers with: One (or more!) Tesla Roadsters with OVMS Connected to wifi for extended periods (night/day, whatever) Using the 3 bus cable Willing to run edge OVMS firmware and let me remotely access to run CAN bus dumps If you can help, please eMail me directly. Thanks, Mark.

1 0

Full month uptime
by Michael Balzer 21 Oct '20

21 Oct '20

First time: a full month without a single crash :-) Last boot was 2610454 second(s) ago Time at boot: 2020-09-20 13:14:09 CEST This is reset #2 since last power cycle Detected boot reason: SoftReset (12/12) Reset reason: Unknown/unset (0) Crash counters: 0 total, 0 early ------------------------------------------------------------------------ Firmware: 3.2.015-99-g4902f5e6/ota_0/edge (build idf v3.3.2-881-g22d636b7b Sep 20 2020 13:06:26) Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

2 1

Plugin Repository
by Mark Webb-Johnson 20 Oct '20

20 Oct '20

I feel that our plugin system offers a missed opportunity. By making small extensions to available functionality, we can use this system to do so much - and with a much lower complexity and barrier to entry compared to C++ ESP IDF development. There are a couple of things I would like to now do: Implement a mechanism for plugins to directly extend the console command language (other than the current ’script exec PLUGIN.fn’). Implement a plugin repository, and command line tools for managing plugins. We simply need to have a store and directory of available plugins, a way of searching/listing those, and a uniform way to install/remove plugins. Once this is done, perhaps someone can handle the web UI side of this, and perhaps that can even be done as a plugin :-) I’m already working on #1. Just an extension to the existing script system to allow plugins to register commands, and to have the command register/deregister done automatically on plugin load/unload. However, #2 is a little more tricky and I’m looking for feedback on the design of this. My idea is: Store the plugins in a new github/openvehicles/Open-Vehicle-Monitoring-System-3/plugins folder. Eventually the /plugin folder will all be migrated to here. Each plugin has a unique name; the directory in /plugins. Within each plugin directory, there is a <name>.json file (JSON format) with defined tags to describe the plugin. If the plugin delivers a web extension, that is in the ‘web’ subdirectory. If the plugin delivered a script extension, that is in the ’script’ directory. Documentation (in rst format) is in the ‘docs' directory. The JSON file would need the following, at a minimum: Name: The plugin ID Title: One line title Group: Group for the plugin Version: The version string of the plugin Description: Longer textual description of the plugin Prerequisites: Prerequisites to be checked (Each plugin installed provides name=version, the system provides system-level ones such as the version of firmware, and then the prerequisites is simple a list of <name><operator><version> as required) We can automatically build the documentation, and list, for all plugins for our docs.openvehicles.com <http://docs.openvehicles.com/> (in a similar way to how it is done for /plugin now). On a repository server, as part of a nightly build job, we can automatically build a single directory JSON file from the <name>,json descriptors. We can publish this, as well as a git export/checkout of the plugins, on a http download site. On the module, we can store a list of repository servers (allowing the user to add/remove as they require). Contributors/authors of plugins simply GitHub clone our repository, and issue pull requests as appropriate. They can also have their own private repository servers (just need to host the directory json file and associated code files) and add it to their modules. The ‘plugin’ command tree on the module will provide commands for: List installed repositories Add a new repository Remove a repository List installed plugins List/Search available plugins Install a plugin Remove a plugin Update a plugin I would like to try to unify the web and script plugin systems a bit more closely. They are really two sides of the same coin (with some plugins providing both). Does that make sense? Any suggestions/comments? Regards, Mark.

4 7

Refactoring MODEM/SIMCOM for v3.3
by Mark Webb-Johnson 10 Oct '20

10 Oct '20

I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected: Component simcom (major changes) New component ovms_modem introduced ovms_webserver/dev/commands.htm ovms_webserver/src/web_cfg_init.cpp ovms_webserver/src/web_cfg.cpp Component powermgmt And several other components mentioning Simcom, but only very minor changes I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult. Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on. Regards, Mark. P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.

4 17

Re: [Ovmsdev] can log vfs crashes
by Derek Caudwell 10 Oct '20

10 Oct '20

Hi Michael, When I turn off polling the logging still crashes so it seems to be an issue with trying to log both buses at once with higher frequency messages. In terms of cpu usage it is hard to say because it crashes too quickly. Regards Derek

2 1

Modem won't start
by Chris van der Meijden 10 Oct '20

10 Oct '20

Hi all I'm suddenly having problems with the modem. It is stuck in PoweringOn and shows a signal of 0 dBm. Here the status: Network Registration: NotRegistered Provider: Signal: 0 dBm State: PoweringOn PPP: Not connected GPS: Not connected And here the debug log: I (201194) simcom: State timeout, transition to 2 I (201194) simcom: State: Enter PoweringOn state I (201194) simcom: Power Cycle D (201194) max7317: egpio.output.0.high D (202194) max7317: egpio.output.0.low D (202204) events: Signal(system.modem.poweringon) D (202204) events: Signal(egpio.output.0.high) D (202204) simcom: tx scmd ch=0 len=4 : AT D (202214) events: Signal(egpio.output.0.low) D (203194) simcom: tx scmd ch=0 len=4 : AT D (204194) simcom: tx scmd ch=0 len=4 : AT D (205194) simcom: tx scmd ch=0 len=4 : AT D (206194) simcom: tx scmd ch=0 len=4 : AT D (207194) simcom: tx scmd ch=0 len=4 : AT D (208194) simcom: tx scmd ch=0 len=4 : AT D (209194) simcom: tx scmd ch=0 len=4 : AT D (210194) simcom: tx scmd ch=0 len=4 : AT D (211194) simcom: tx scmd ch=0 len=4 : AT D (212194) simcom: tx scmd ch=0 len=4 : AT D (213194) simcom: tx scmd ch=0 len=4 : AT D (214194) simcom: tx scmd ch=0 len=4 : AT D (215194) simcom: tx scmd ch=0 len=4 : AT D (216194) simcom: tx scmd ch=0 len=4 : AT D (217194) simcom: tx scmd ch=0 len=4 : AT D (218194) simcom: tx scmd ch=0 len=4 : AT D (219194) simcom: tx scmd ch=0 len=4 : AT D (220194) simcom: tx scmd ch=0 len=4 : AT D (221194) simcom: tx scmd ch=0 len=4 : AT Hard reset did not help ... I found this discussion https://www.openvehicles.com/node/2381 with recent postings. Could there be a general problem with the modem, or is it my hardware (again ...)? Thanx Chris

4 10

USB port fragility
by Michael Balzer 10 Oct '20

10 Oct '20

Mark, I've had multiple cases now of damaged and broken off USB ports. I've added a fragility warning to the user guide: https://docs.openvehicles.com/en/latest/userguide/components.html#the-ovms-… Maybe we should add that to the multilingual quick start info sheet coming with the module as well? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

8 12