[Ovmsdev] Stat command

[Mark Webb-Johnson]

My bad. Here are the commands from v2:

// The command strings are prefixed with a security control flag:
//   space: no security control
//   1:     the first argument must be the module password
//   2:     the caller must be the registered telephone
//   3:     the caller must be the registered telephone, or first argument the module password

rom char sms_cmdtable[][NET_SMS_CMDWIDTH] =
  { "3REGISTER?",
    "1REGISTER",
    "3PASS?",
    "2PASS ",
    "3GPS",
    "3STAT",
    "3PARAMS?",
    "2PARAMS ",
    "1AP ",
    "3MODULE?",
    "2MODULE ",
    "3VEHICLE?",
    "2VEHICLE ",
    "3GPRS?",
    "2GPRS ",
    "3GSMLOCK?",
    "2GSMLOCK",
    "3SERVER?",
    "2SERVER ",
    "3DIAG",
    "3FEATURES?",
    "2FEATURE ",
#ifndef OVMS_NO_HOMELINK
    "2HOMELINK",
#endif // OVMS_NO_HOMELINK
#ifndef OVMS_NO_LOCK
    "2LOCK",
    "2UNLOCK",
    "2VALET",
    "2UNVALET",
#endif // OVMS_NO_LOCK
#ifndef OVMS_NO_CHARGECONTROL
    "2CHARGEMODE ",
    "2CHARGESTART",
    "2CHARGESTOP",
    "2COOLDOWN",
#endif // OVMS_NO_CHARGECONTROL
    "3VERSION",
    "3RESET",
#ifndef OVMS_NO_CTP
    "3CTP",
#endif //OVMS_NO_CTP
    "3TEMPS",
#ifdef OVMS_ACCMODULE
    "2ACC ",
#endif
    "3HELP",
    "" };

You are correct. Everything is privileged.

Regards, Mark

> On 4 Nov 2017, at 9:57 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> 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 <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
> 
> -- 
> 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
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

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