[Ovmsdev] Stat command
dexter at expeedo.de
Sat Nov 4 21:57:50 HKT 2017
Thanks for checking.
But... I checked before & again: STAT was privileged in V2, in fact there were no unprivileged standard commands.
Also the command should still be privileged because I don't want any person knowing my SIM number to be able to read my charge status & odometer. That info can
be used to precisely track a vehicle when combined with other data.
Or did I get the security concept wrong?
Am 04.11.2017 um 14:02 schrieb Mark Webb-Johnson:
> Looks good.
> Only change I made was to make it ‘non privileged’ (to match ovms v2).
> The way these are going to be implemented is using the BufferedShell() class. This implements an OvmsWriter that simply buffers the output for later
> collection. The SMS system will receive a command, then pass it to the OvmsCommandApp system using this BufferedShell() as the writer. Once the command
> completes execution, the output in BufferedShell() will be collected, and sent back out in an SMS reply. Privileged commands will be slightly different than
> OVMS v2. To run a privileged command, you either send it from the registered phone number, or prefix the command with the module password. Either will cause
> the IsSecure() to be set true on the BufferedShell(), before the command is executed.
> Regards, Mark.
>> On 4 Nov 2017, at 5:51 PM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>> I've added a default implementation for the "stat" command.
>> virtual vehicle_command_t CommandStat(int verbosity, OvmsWriter* writer);
>> I thought about letting the vehicle module generate a std::string, but it would still need the verbosity and would always need another memory buffer, so I
>> think passing the writer to vehicle methods generating output is better -- please correct me if there is a system design decision I'm breaking with this.
>> Am 30.10.2017 um 07:06 schrieb Mark Webb-Johnson:
>>> I’ve implemented these standard commands in vehicle framework:
>>> virtual vehicle_command_t CommandSetChargeMode(vehicle_mode_t mode);
>>> virtual vehicle_command_t CommandSetChargeCurrent(uint16_t limit);
>>> virtual vehicle_command_t CommandStartCharge();
>>> virtual vehicle_command_t CommandStopCharge();
>>> virtual vehicle_command_t CommandSetChargeTimer(bool timeron, uint16_t timerstart);
>>> virtual vehicle_command_t CommandCooldown(bool cooldownon);
>>> virtual vehicle_command_t CommandWakeup();
>>> virtual vehicle_command_t CommandLock(const char* pin);
>>> virtual vehicle_command_t CommandUnlock(const char* pin);
>>> virtual vehicle_command_t CommandActivateValet(const char* pin);
>>> virtual vehicle_command_t CommandDeactivateValet(const char* pin);
>>> virtual vehicle_command_t CommandHomelink(uint8_t button);
>>> Also implemented most of these for the Tesla Roadster, as an example implementation.
>>> I haven’t changed ovms_server_v2 yet, to implement the standard command processor for these, but that should be trivial.
>>> Vehicle modules are able to implement handlers for these standardised commands, as well as their own custom commands (if required).
>>> Regards, Mark.
>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev