[Ovmsdev] Stat command

[Michael Balzer]

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?

Regards,
Michael


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.
>>
>> Regards,
>> Michael
>>
>>
>> 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>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

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