[Ovmsdev] V3 progress

[Mark Webb-Johnson]

The #define will be seen by anything that pulls in vehicle_nissanleaf.h. You are pretty safe in this case, as vehicle_nissanleaf.cpp is probably the only thing that will ever pull in that .h.

Classes don’t have private #defines. That is a pre-processor directive, so is actually processed even before the C/C++ compiler is called.

Steve is looking at the ovms_command issue you identified. I think he’s fixed it already (based on commit history), but will leave him to reply. Very helpful - please keep hacking away at this to discover the edge cases.

I think the car-on and car-off detection will always be vehicle-specific. Perhaps something to help with this could be done in vehicle.{h,cpp}? Perhaps a CarAwakeTickle() function that the car module calls, and if that is not called in N seconds, then vehicle.{h,cpp} automatically records the car as off? Just not sure how many vehicles would need this. Perhaps simplest for you to implement:

OvmsVehicleNissanLeaf::CarAwakeTickle()
If metrics show car is off, then make it as on. Reset car awake tickle counter

OvmsVehicleNissanLeaf::Ticker1
A generic ticker to increment car awake tickle counter, and if it hits a limit then to metric the car as off.

Or, however you think best to implement this. The idea is to implement it using a generic mechanism, but in OvmsVehicleNissanLeaf class. If it is found to be generically useful, then it can simply be moved to the vehicle.{h,cpp} parent class and is then available everyone.

For high-level events like car-off, car-started, car-asleep, etc, I think these can be handled at a high level (probably in vehicle.{h,cpp}).

Regards, Mark.

> On 22 Oct 2017, at 6:40 PM, Tom Parker <tom at carrott.org> wrote:
> 
> On 15/10/17 02:47, Mark Webb-Johnson wrote:
>> The #define in vehicle_nissanleaf.h
> 
> Should that go in the .h? Is the preprocessor namespace global in cpp, or if I stick it in the private section of the class, will it be a class private define? I'm thinking the former and I should prefix the names with NL or something?
> 
>> Put back the ovmswriter puts on server startup (as Steve has fixed that)
>> Put in a 60/600 second timer, for transmission of status messages
> 
> Thanks for fixing these up for me.
> 
> I've sent another pull request with expanded support for the v2 server messages, including a silly bug fix due to an errant semicolon. 
> 
> I've also ported over some more of the v2 Leaf can bus decoding support, which led me to try to implement "car off" detection, which in v2 on the leaf was done by waiting for the can bus to go quiet. I bodged something together using a ticker and the staleness indicator on the car_on metric, but I think something better could be done in the core framework.
> 
> I've noticed that the wifi does not reconnect if it goes out of range. I made a terrible network manager to reconnect. It signals some events and I wrote some scripts to execute the relevant     commands, mostly because I don't know how to directly execute a command.
> 
> The network.down event doesn't seem to be generated when the wifi goes down, but system.wifi.sta.disconnected is.
> 
> I found a very odd bug, if you make a script which calls a command that doesn't log anything, you get a crash in ovms_console.cpp. It took me quite some time to trace this to commands that don't log, because start and stop do log if they're called in the right order, but my terrible network manager would call start whenever the network came up which would die the second time because the v2 client is already running and doesn't log anything if you try to start it again. 
> 
> In my terrible network manager branch I have worked around this by making the v2 server log even if it's already running or stopped but that obviously doesn't fix the underlying bug. It can be reproduced with the ticker event:
> 
> OVMS > vfs mkdir /store/events/ticker.10
> OVMS > vfs append "server v2 stop" /store/events/ticker.10/tick
> I (23885) script: Running script /store/events/ticker.10/tick
> Guru Meditation Error of type LoadProhibited occurred on core  1. Exception was unhandled.
> Register dump:
> PC      : 0x400efb54  PS      : 0x00060f30  A0      : 0x800efc07  A1      : 0x3ffe5220  
> 0x400efb54: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:58
> 
> A2      : 0x3ffe200c  A3      : 0x00000000  A4      : 0x00010002  A5      : 0x00000014  
> A6      : 0x00000008  A7      : 0x00000000  A8      : 0x800efb35  A9      : 0x3ffe5200  
> A10     : 0x00000001  A11     : 0x3ffc13cc  A12     : 0x00000001  A13     : 0x00000000  
> A14     : 0x3ffe2c2c  A15     : 0xff000000  SAR     : 0x0000001e  EXCCAUSE: 0x0000001c  
> EXCVADDR: 0x00000004  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  
> 
> Backtrace: 0x400efb54:0x3ffe5220 0x400efc04:0x3ffe5250 0x400ef8b4:0x3ffe5270
> 0x400efb54: _ZN11OvmsConsole7ServiceEv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./ovms_console.cpp:58
> 
> 0x400efc04: _ZThn304_N11OvmsConsole7ServiceEv at ??:?
> 
> 0x400ef8b4: _ZN8TaskBase4TaskEPv at /vagrant/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/main/./task_base.cpp:126
> 
> 
> Rebooting...
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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