…just pushed. I've also made some minor changes & extensions to the framework, hopefully helpful. This is very basic support (~10%). It covers CAN processing and battery / power monitoring. Just metrics output for now, no commands or notifications. Free RAM is down to 36.6 K after loading the module. I've removed the "v." from the "x.rt.v." metrics names, as nearly all "x.rt" metrics are (of course) vehicle metrics. "x.rt.m.version" does not fit the scheme and breaks into the "motor" namespace, as "m." was in use before, maybe we should better use "mot." for motor metrics. Regards, Michael OVMS > config list x.rt x.rt autopower: yes autoreset: yes canwrite: no cap_act_prc: 87.4 cap_nom_ah: 108.0 chargelevel: 0 chargemode: 0 console: no kickdown: yes maxrange: 71 suffrange: 65 suffsoc: 85 OVMS > metrics list m.freeram 36644 m.hardware OVMS WIFI BLE BT cores=2 rev=ESP32/1 m.monotonic 541Sec m.net.mdm.iccid m.net.mdm.model m.net.provider WLAN-214677 m.net.sq m.net.type wifi m.serial 30:ae:a4:37:25:88 m.tasks 17 m.time.utc 546Sec m.version 3.0.0/factory/main build (idf v2.1-20-g88ab5d48) Oct 29 2017 09:15:17 s.v2.connected s.v2.peers v.b.12v.current 1.6A v.b.12v.voltage 0.527473V v.b.cac 94.392Ah v.b.current -36A v.b.energy.recd 0.000739342kWh v.b.energy.used 0kWh v.b.power -2.0224kW v.b.range.est 50Km v.b.range.full 68.2571Km v.b.range.ideal 49Km v.b.soc 71.92% v.b.soh 100% v.b.temp 15.4286°C v.b.voltage 56.2V v.c.charging yes v.c.climit v.c.current 36A v.c.duration.full 82Min v.c.duration.range 50Min v.c.duration.soc 25Min v.c.kwh 0.000739342kWh v.c.minutes 6Min v.c.mode standard v.c.pilot yes v.c.state charging v.c.substate go v.c.temp 25°C v.c.timermode v.c.timerstart v.c.type v.c.voltage 230V v.d.cp yes v.d.fl v.d.fr v.d.hood v.d.rl v.d.rr v.d.trunk v.e.alarm v.e.awake no v.e.c.config no v.e.c.login no v.e.charging12v yes v.e.cooling v.e.drivemode v.e.handbrake v.e.headlights v.e.heating v.e.hvac v.e.locked no v.e.on no v.e.parktime v.e.temp v.e.valet no v.i.temp v.m.temp 0°C v.p.altitude v.p.direction v.p.gpslock v.p.latitude v.p.longitude v.p.odometer 3456.51Km v.p.satcount v.p.speed 0Kph v.p.trip 3456.51Km v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type RT v.vin 7378280 x.rt.b.cell.01.voltage.act 4.025V x.rt.b.cell.01.voltage.max 4.025V x.rt.b.cell.01.voltage.maxdev 2.85712V x.rt.b.cell.01.voltage.min 4.02V x.rt.b.cell.02.voltage.act 4.015V x.rt.b.cell.02.voltage.max 4.015V x.rt.b.cell.02.voltage.maxdev 0.857117V x.rt.b.cell.02.voltage.min 4.01V x.rt.b.cell.03.voltage.act 4.015V x.rt.b.cell.03.voltage.max 4.015V x.rt.b.cell.03.voltage.maxdev 0.857117V x.rt.b.cell.03.voltage.min 4.01V x.rt.b.cell.04.voltage.act 4.01V x.rt.b.cell.04.voltage.max 4.015V x.rt.b.cell.04.voltage.maxdev 0.857117V x.rt.b.cell.04.voltage.min 4.005V x.rt.b.cell.05.voltage.act 4.015V x.rt.b.cell.05.voltage.max 4.015V x.rt.b.cell.05.voltage.maxdev 0.857117V x.rt.b.cell.05.voltage.min 4.01V x.rt.b.cell.06.voltage.act 4.015V x.rt.b.cell.06.voltage.max 4.015V x.rt.b.cell.06.voltage.maxdev -1.14288V x.rt.b.cell.06.voltage.min 4.005V x.rt.b.cell.07.voltage.act 4.015V x.rt.b.cell.07.voltage.max 4.015V x.rt.b.cell.07.voltage.maxdev 0.285706V x.rt.b.cell.07.voltage.min 4.01V x.rt.b.cell.08.voltage.act 4.01V x.rt.b.cell.08.voltage.max 4.01V x.rt.b.cell.08.voltage.maxdev -1.14288V x.rt.b.cell.08.voltage.min 4.005V x.rt.b.cell.09.voltage.act 4.01V x.rt.b.cell.09.voltage.max 4.01V x.rt.b.cell.09.voltage.maxdev -1.14288V x.rt.b.cell.09.voltage.min 4.005V x.rt.b.cell.10.voltage.act 4.01V x.rt.b.cell.10.voltage.max 4.01V x.rt.b.cell.10.voltage.maxdev -1.14288V x.rt.b.cell.10.voltage.min 4.005V x.rt.b.cell.11.voltage.act 4.015V x.rt.b.cell.11.voltage.max 4.015V x.rt.b.cell.11.voltage.maxdev 0.285706V x.rt.b.cell.11.voltage.min 4.01V x.rt.b.cell.12.voltage.act 4.01V x.rt.b.cell.12.voltage.max 4.01V x.rt.b.cell.12.voltage.maxdev -1.14288V x.rt.b.cell.12.voltage.min 4.005V x.rt.b.cell.13.voltage.act 4.01V x.rt.b.cell.13.voltage.max 4.01V x.rt.b.cell.13.voltage.maxdev -1.14288V x.rt.b.cell.13.voltage.min 4.005V x.rt.b.cell.14.voltage.act 4.025V x.rt.b.cell.14.voltage.max 4.025V x.rt.b.cell.14.voltage.maxdev 2.14288V x.rt.b.cell.14.voltage.min 4.015V x.rt.b.cell.15.voltage.act 0V x.rt.b.cell.15.voltage.max 0V x.rt.b.cell.15.voltage.maxdev 0V x.rt.b.cell.15.voltage.min 0V x.rt.b.cell.16.voltage.act 0V x.rt.b.cell.16.voltage.max 0V x.rt.b.cell.16.voltage.maxdev 0V x.rt.b.cell.16.voltage.min 0V x.rt.b.cell.cnt 14 x.rt.b.cmod.01.temp.act 16°C x.rt.b.cmod.01.temp.max 16°C x.rt.b.cmod.01.temp.maxdev 0.57143°C x.rt.b.cmod.01.temp.min 16°C x.rt.b.cmod.02.temp.act 15°C x.rt.b.cmod.02.temp.max 15°C x.rt.b.cmod.02.temp.maxdev -0.42857°C x.rt.b.cmod.02.temp.min 15°C x.rt.b.cmod.03.temp.act 16°C x.rt.b.cmod.03.temp.max 16°C x.rt.b.cmod.03.temp.maxdev 0.57143°C x.rt.b.cmod.03.temp.min 16°C x.rt.b.cmod.04.temp.act 15°C x.rt.b.cmod.04.temp.max 15°C x.rt.b.cmod.04.temp.maxdev -0.42857°C x.rt.b.cmod.04.temp.min 15°C x.rt.b.cmod.05.temp.act 16°C x.rt.b.cmod.05.temp.max 16°C x.rt.b.cmod.05.temp.maxdev 0.57143°C x.rt.b.cmod.05.temp.min 16°C x.rt.b.cmod.06.temp.act 15°C x.rt.b.cmod.06.temp.max 15°C x.rt.b.cmod.06.temp.maxdev -0.42857°C x.rt.b.cmod.06.temp.min 15°C x.rt.b.cmod.07.temp.act 15°C x.rt.b.cmod.07.temp.max 15°C x.rt.b.cmod.07.temp.maxdev -0.42857°C x.rt.b.cmod.07.temp.min 15°C x.rt.b.cmod.08.temp.act -40°C x.rt.b.cmod.08.temp.max -40°C x.rt.b.cmod.08.temp.maxdev 0°C x.rt.b.cmod.08.temp.min -40°C x.rt.b.cmod.cnt 7 x.rt.b.pack.1.temp.stddev.max 0.495093°C x.rt.b.pack.1.voltage.max 56.2V x.rt.b.pack.1.voltage.min 56.1V x.rt.b.pack.1.voltage.stddev.max 0.00586302V x.rt.b.pack.cnt 1 x.rt.m.version 0.1.0 Oct 29 2017 10:44:20 x.rt.p.stats.acc.dist 0Km x.rt.p.stats.acc.recd 0kWh x.rt.p.stats.acc.spdavg 0Kph/s x.rt.p.stats.acc.used 0kWh x.rt.p.stats.cst.dist 0Km x.rt.p.stats.cst.recd 0.000739342kWh x.rt.p.stats.cst.spdavg 0Kph x.rt.p.stats.cst.used 0kWh x.rt.p.stats.dec.dist 0Km x.rt.p.stats.dec.recd 0kWh x.rt.p.stats.dec.spdavg 0Kph/s x.rt.p.stats.dec.used 0kWh x.rt.p.stats.ldn.dist 0Km x.rt.p.stats.ldn.hsum 0m x.rt.p.stats.ldn.recd 0kWh x.rt.p.stats.ldn.used 0kWh x.rt.p.stats.lup.dist 0Km x.rt.p.stats.lup.hsum 0m x.rt.p.stats.lup.recd 0kWh x.rt.p.stats.lup.used 0kWh -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Looks good. I”ll look at the standardised commands tomorrow. My thinking is that OvmsVehicle implements standardised virtual functions for these with an enum (NotImplemented, Success, Fail) return value (and default implementations ’NotImplemented’). Then, if a vehicle implements the command, it does it and returns Success/Fail. OvmsVehicle can then implement OvmsCommands for all the standardised commands. That would replace the commandhandler(BOOL msgmode, int code, char* msg) from v2. If a vehicle wants to implement it’s own custom commands, it can do as normal (via it’s own command space, I guess, like “RT” for Renault Twizy). If anybody has got any ideas how this should be done better, let me know, otherwise I’ll continue along those lines. Regards, Mark
On 29 Oct 2017, at 6:37 PM, Michael Balzer <dexter@expeedo.de> wrote:
…just pushed.
I've also made some minor changes & extensions to the framework, hopefully helpful.
This is very basic support (~10%). It covers CAN processing and battery / power monitoring. Just metrics output for now, no commands or notifications.
Free RAM is down to 36.6 K after loading the module.
I've removed the "v." from the "x.rt.v." metrics names, as nearly all "x.rt" metrics are (of course) vehicle metrics. "x.rt.m.version" does not fit the scheme and breaks into the "motor" namespace, as "m." was in use before, maybe we should better use "mot." for motor metrics.
Regards, Michael
OVMS > config list x.rt x.rt autopower: yes autoreset: yes canwrite: no cap_act_prc: 87.4 cap_nom_ah: 108.0 chargelevel: 0 chargemode: 0 console: no kickdown: yes maxrange: 71 suffrange: 65 suffsoc: 85
OVMS > metrics list m.freeram 36644 m.hardware OVMS WIFI BLE BT cores=2 rev=ESP32/1 m.monotonic 541Sec m.net.mdm.iccid m.net.mdm.model m.net.provider WLAN-214677 m.net.sq m.net.type wifi m.serial 30:ae:a4:37:25:88 m.tasks 17 m.time.utc 546Sec m.version 3.0.0/factory/main build (idf v2.1-20-g88ab5d48) Oct 29 2017 09:15:17 s.v2.connected s.v2.peers v.b.12v.current 1.6A v.b.12v.voltage 0.527473V v.b.cac 94.392Ah v.b.current -36A v.b.energy.recd 0.000739342kWh v.b.energy.used 0kWh v.b.power -2.0224kW v.b.range.est 50Km v.b.range.full 68.2571Km v.b.range.ideal 49Km v.b.soc 71.92% v.b.soh 100% v.b.temp 15.4286°C v.b.voltage 56.2V v.c.charging yes v.c.climit v.c.current 36A v.c.duration.full 82Min v.c.duration.range 50Min v.c.duration.soc 25Min v.c.kwh 0.000739342kWh v.c.minutes 6Min v.c.mode standard v.c.pilot yes v.c.state charging v.c.substate go v.c.temp 25°C v.c.timermode v.c.timerstart v.c.type v.c.voltage 230V v.d.cp yes v.d.fl v.d.fr v.d.hood v.d.rl v.d.rr v.d.trunk v.e.alarm v.e.awake no v.e.c.config no v.e.c.login no v.e.charging12v yes v.e.cooling v.e.drivemode v.e.handbrake v.e.headlights v.e.heating v.e.hvac v.e.locked no v.e.on no v.e.parktime v.e.temp v.e.valet no v.i.temp v.m.temp 0°C v.p.altitude v.p.direction v.p.gpslock v.p.latitude v.p.longitude v.p.odometer 3456.51Km v.p.satcount v.p.speed 0Kph v.p.trip 3456.51Km v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type RT v.vin 7378280 x.rt.b.cell.01.voltage.act 4.025V x.rt.b.cell.01.voltage.max 4.025V x.rt.b.cell.01.voltage.maxdev 2.85712V x.rt.b.cell.01.voltage.min 4.02V x.rt.b.cell.02.voltage.act 4.015V x.rt.b.cell.02.voltage.max 4.015V x.rt.b.cell.02.voltage.maxdev 0.857117V x.rt.b.cell.02.voltage.min 4.01V x.rt.b.cell.03.voltage.act 4.015V x.rt.b.cell.03.voltage.max 4.015V x.rt.b.cell.03.voltage.maxdev 0.857117V x.rt.b.cell.03.voltage.min 4.01V x.rt.b.cell.04.voltage.act 4.01V x.rt.b.cell.04.voltage.max 4.015V x.rt.b.cell.04.voltage.maxdev 0.857117V x.rt.b.cell.04.voltage.min 4.005V x.rt.b.cell.05.voltage.act 4.015V x.rt.b.cell.05.voltage.max 4.015V x.rt.b.cell.05.voltage.maxdev 0.857117V x.rt.b.cell.05.voltage.min 4.01V x.rt.b.cell.06.voltage.act 4.015V x.rt.b.cell.06.voltage.max 4.015V x.rt.b.cell.06.voltage.maxdev -1.14288V x.rt.b.cell.06.voltage.min 4.005V x.rt.b.cell.07.voltage.act 4.015V x.rt.b.cell.07.voltage.max 4.015V x.rt.b.cell.07.voltage.maxdev 0.285706V x.rt.b.cell.07.voltage.min 4.01V x.rt.b.cell.08.voltage.act 4.01V x.rt.b.cell.08.voltage.max 4.01V x.rt.b.cell.08.voltage.maxdev -1.14288V x.rt.b.cell.08.voltage.min 4.005V x.rt.b.cell.09.voltage.act 4.01V x.rt.b.cell.09.voltage.max 4.01V x.rt.b.cell.09.voltage.maxdev -1.14288V x.rt.b.cell.09.voltage.min 4.005V x.rt.b.cell.10.voltage.act 4.01V x.rt.b.cell.10.voltage.max 4.01V x.rt.b.cell.10.voltage.maxdev -1.14288V x.rt.b.cell.10.voltage.min 4.005V x.rt.b.cell.11.voltage.act 4.015V x.rt.b.cell.11.voltage.max 4.015V x.rt.b.cell.11.voltage.maxdev 0.285706V x.rt.b.cell.11.voltage.min 4.01V x.rt.b.cell.12.voltage.act 4.01V x.rt.b.cell.12.voltage.max 4.01V x.rt.b.cell.12.voltage.maxdev -1.14288V x.rt.b.cell.12.voltage.min 4.005V x.rt.b.cell.13.voltage.act 4.01V x.rt.b.cell.13.voltage.max 4.01V x.rt.b.cell.13.voltage.maxdev -1.14288V x.rt.b.cell.13.voltage.min 4.005V x.rt.b.cell.14.voltage.act 4.025V x.rt.b.cell.14.voltage.max 4.025V x.rt.b.cell.14.voltage.maxdev 2.14288V x.rt.b.cell.14.voltage.min 4.015V x.rt.b.cell.15.voltage.act 0V x.rt.b.cell.15.voltage.max 0V x.rt.b.cell.15.voltage.maxdev 0V x.rt.b.cell.15.voltage.min 0V x.rt.b.cell.16.voltage.act 0V x.rt.b.cell.16.voltage.max 0V x.rt.b.cell.16.voltage.maxdev 0V x.rt.b.cell.16.voltage.min 0V x.rt.b.cell.cnt 14 x.rt.b.cmod.01.temp.act 16°C x.rt.b.cmod.01.temp.max 16°C x.rt.b.cmod.01.temp.maxdev 0.57143°C x.rt.b.cmod.01.temp.min 16°C x.rt.b.cmod.02.temp.act 15°C x.rt.b.cmod.02.temp.max 15°C x.rt.b.cmod.02.temp.maxdev -0.42857°C x.rt.b.cmod.02.temp.min 15°C x.rt.b.cmod.03.temp.act 16°C x.rt.b.cmod.03.temp.max 16°C x.rt.b.cmod.03.temp.maxdev 0.57143°C x.rt.b.cmod.03.temp.min 16°C x.rt.b.cmod.04.temp.act 15°C x.rt.b.cmod.04.temp.max 15°C x.rt.b.cmod.04.temp.maxdev -0.42857°C x.rt.b.cmod.04.temp.min 15°C x.rt.b.cmod.05.temp.act 16°C x.rt.b.cmod.05.temp.max 16°C x.rt.b.cmod.05.temp.maxdev 0.57143°C x.rt.b.cmod.05.temp.min 16°C x.rt.b.cmod.06.temp.act 15°C x.rt.b.cmod.06.temp.max 15°C x.rt.b.cmod.06.temp.maxdev -0.42857°C x.rt.b.cmod.06.temp.min 15°C x.rt.b.cmod.07.temp.act 15°C x.rt.b.cmod.07.temp.max 15°C x.rt.b.cmod.07.temp.maxdev -0.42857°C x.rt.b.cmod.07.temp.min 15°C x.rt.b.cmod.08.temp.act -40°C x.rt.b.cmod.08.temp.max -40°C x.rt.b.cmod.08.temp.maxdev 0°C x.rt.b.cmod.08.temp.min -40°C x.rt.b.cmod.cnt 7 x.rt.b.pack.1.temp.stddev.max 0.495093°C x.rt.b.pack.1.voltage.max 56.2V x.rt.b.pack.1.voltage.min 56.1V x.rt.b.pack.1.voltage.stddev.max 0.00586302V x.rt.b.pack.cnt 1 x.rt.m.version 0.1.0 Oct 29 2017 10:44:20 x.rt.p.stats.acc.dist 0Km x.rt.p.stats.acc.recd 0kWh x.rt.p.stats.acc.spdavg 0Kph/s x.rt.p.stats.acc.used 0kWh x.rt.p.stats.cst.dist 0Km x.rt.p.stats.cst.recd 0.000739342kWh x.rt.p.stats.cst.spdavg 0Kph x.rt.p.stats.cst.used 0kWh x.rt.p.stats.dec.dist 0Km x.rt.p.stats.dec.recd 0kWh x.rt.p.stats.dec.spdavg 0Kph/s x.rt.p.stats.dec.used 0kWh x.rt.p.stats.ldn.dist 0Km x.rt.p.stats.ldn.hsum 0m x.rt.p.stats.ldn.recd 0kWh x.rt.p.stats.ldn.used 0kWh x.rt.p.stats.lup.dist 0Km x.rt.p.stats.lup.hsum 0m x.rt.p.stats.lup.recd 0kWh x.rt.p.stats.lup.used 0kWh
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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.
On 29 Oct 2017, at 8:58 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Looks good.
I”ll look at the standardised commands tomorrow. My thinking is that OvmsVehicle implements standardised virtual functions for these with an enum (NotImplemented, Success, Fail) return value (and default implementations ’NotImplemented’). Then, if a vehicle implements the command, it does it and returns Success/Fail. OvmsVehicle can then implement OvmsCommands for all the standardised commands.
That would replace the commandhandler(BOOL msgmode, int code, char* msg) from v2.
If a vehicle wants to implement it’s own custom commands, it can do as normal (via it’s own command space, I guess, like “RT” for Renault Twizy).
If anybody has got any ideas how this should be done better, let me know, otherwise I’ll continue along those lines.
Regards, Mark
On 29 Oct 2017, at 6:37 PM, Michael Balzer <dexter@expeedo.de> wrote:
…just pushed.
I've also made some minor changes & extensions to the framework, hopefully helpful.
This is very basic support (~10%). It covers CAN processing and battery / power monitoring. Just metrics output for now, no commands or notifications.
Free RAM is down to 36.6 K after loading the module.
I've removed the "v." from the "x.rt.v." metrics names, as nearly all "x.rt" metrics are (of course) vehicle metrics. "x.rt.m.version" does not fit the scheme and breaks into the "motor" namespace, as "m." was in use before, maybe we should better use "mot." for motor metrics.
Regards, Michael
OVMS > config list x.rt x.rt autopower: yes autoreset: yes canwrite: no cap_act_prc: 87.4 cap_nom_ah: 108.0 chargelevel: 0 chargemode: 0 console: no kickdown: yes maxrange: 71 suffrange: 65 suffsoc: 85
OVMS > metrics list m.freeram 36644 m.hardware OVMS WIFI BLE BT cores=2 rev=ESP32/1 m.monotonic 541Sec m.net.mdm.iccid m.net.mdm.model m.net.provider WLAN-214677 m.net.sq m.net.type wifi m.serial 30:ae:a4:37:25:88 m.tasks 17 m.time.utc 546Sec m.version 3.0.0/factory/main build (idf v2.1-20-g88ab5d48) Oct 29 2017 09:15:17 s.v2.connected s.v2.peers v.b.12v.current 1.6A v.b.12v.voltage 0.527473V v.b.cac 94.392Ah v.b.current -36A v.b.energy.recd 0.000739342kWh v.b.energy.used 0kWh v.b.power -2.0224kW v.b.range.est 50Km v.b.range.full 68.2571Km v.b.range.ideal 49Km v.b.soc 71.92% v.b.soh 100% v.b.temp 15.4286°C v.b.voltage 56.2V v.c.charging yes v.c.climit v.c.current 36A v.c.duration.full 82Min v.c.duration.range 50Min v.c.duration.soc 25Min v.c.kwh 0.000739342kWh v.c.minutes 6Min v.c.mode standard v.c.pilot yes v.c.state charging v.c.substate go v.c.temp 25°C v.c.timermode v.c.timerstart v.c.type v.c.voltage 230V v.d.cp yes v.d.fl v.d.fr v.d.hood v.d.rl v.d.rr v.d.trunk v.e.alarm v.e.awake no v.e.c.config no v.e.c.login no v.e.charging12v yes v.e.cooling v.e.drivemode v.e.handbrake v.e.headlights v.e.heating v.e.hvac v.e.locked no v.e.on no v.e.parktime v.e.temp v.e.valet no v.i.temp v.m.temp 0°C v.p.altitude v.p.direction v.p.gpslock v.p.latitude v.p.longitude v.p.odometer 3456.51Km v.p.satcount v.p.speed 0Kph v.p.trip 3456.51Km v.tp.fl.p v.tp.fl.t v.tp.fr.p v.tp.fr.t v.tp.rl.p v.tp.rl.t v.tp.rr.p v.tp.rr.t v.type RT v.vin 7378280 x.rt.b.cell.01.voltage.act 4.025V x.rt.b.cell.01.voltage.max 4.025V x.rt.b.cell.01.voltage.maxdev 2.85712V x.rt.b.cell.01.voltage.min 4.02V x.rt.b.cell.02.voltage.act 4.015V x.rt.b.cell.02.voltage.max 4.015V x.rt.b.cell.02.voltage.maxdev 0.857117V x.rt.b.cell.02.voltage.min 4.01V x.rt.b.cell.03.voltage.act 4.015V x.rt.b.cell.03.voltage.max 4.015V x.rt.b.cell.03.voltage.maxdev 0.857117V x.rt.b.cell.03.voltage.min 4.01V x.rt.b.cell.04.voltage.act 4.01V x.rt.b.cell.04.voltage.max 4.015V x.rt.b.cell.04.voltage.maxdev 0.857117V x.rt.b.cell.04.voltage.min 4.005V x.rt.b.cell.05.voltage.act 4.015V x.rt.b.cell.05.voltage.max 4.015V x.rt.b.cell.05.voltage.maxdev 0.857117V x.rt.b.cell.05.voltage.min 4.01V x.rt.b.cell.06.voltage.act 4.015V x.rt.b.cell.06.voltage.max 4.015V x.rt.b.cell.06.voltage.maxdev -1.14288V x.rt.b.cell.06.voltage.min 4.005V x.rt.b.cell.07.voltage.act 4.015V x.rt.b.cell.07.voltage.max 4.015V x.rt.b.cell.07.voltage.maxdev 0.285706V x.rt.b.cell.07.voltage.min 4.01V x.rt.b.cell.08.voltage.act 4.01V x.rt.b.cell.08.voltage.max 4.01V x.rt.b.cell.08.voltage.maxdev -1.14288V x.rt.b.cell.08.voltage.min 4.005V x.rt.b.cell.09.voltage.act 4.01V x.rt.b.cell.09.voltage.max 4.01V x.rt.b.cell.09.voltage.maxdev -1.14288V x.rt.b.cell.09.voltage.min 4.005V x.rt.b.cell.10.voltage.act 4.01V x.rt.b.cell.10.voltage.max 4.01V x.rt.b.cell.10.voltage.maxdev -1.14288V x.rt.b.cell.10.voltage.min 4.005V x.rt.b.cell.11.voltage.act 4.015V x.rt.b.cell.11.voltage.max 4.015V x.rt.b.cell.11.voltage.maxdev 0.285706V x.rt.b.cell.11.voltage.min 4.01V x.rt.b.cell.12.voltage.act 4.01V x.rt.b.cell.12.voltage.max 4.01V x.rt.b.cell.12.voltage.maxdev -1.14288V x.rt.b.cell.12.voltage.min 4.005V x.rt.b.cell.13.voltage.act 4.01V x.rt.b.cell.13.voltage.max 4.01V x.rt.b.cell.13.voltage.maxdev -1.14288V x.rt.b.cell.13.voltage.min 4.005V x.rt.b.cell.14.voltage.act 4.025V x.rt.b.cell.14.voltage.max 4.025V x.rt.b.cell.14.voltage.maxdev 2.14288V x.rt.b.cell.14.voltage.min 4.015V x.rt.b.cell.15.voltage.act 0V x.rt.b.cell.15.voltage.max 0V x.rt.b.cell.15.voltage.maxdev 0V x.rt.b.cell.15.voltage.min 0V x.rt.b.cell.16.voltage.act 0V x.rt.b.cell.16.voltage.max 0V x.rt.b.cell.16.voltage.maxdev 0V x.rt.b.cell.16.voltage.min 0V x.rt.b.cell.cnt 14 x.rt.b.cmod.01.temp.act 16°C x.rt.b.cmod.01.temp.max 16°C x.rt.b.cmod.01.temp.maxdev 0.57143°C x.rt.b.cmod.01.temp.min 16°C x.rt.b.cmod.02.temp.act 15°C x.rt.b.cmod.02.temp.max 15°C x.rt.b.cmod.02.temp.maxdev -0.42857°C x.rt.b.cmod.02.temp.min 15°C x.rt.b.cmod.03.temp.act 16°C x.rt.b.cmod.03.temp.max 16°C x.rt.b.cmod.03.temp.maxdev 0.57143°C x.rt.b.cmod.03.temp.min 16°C x.rt.b.cmod.04.temp.act 15°C x.rt.b.cmod.04.temp.max 15°C x.rt.b.cmod.04.temp.maxdev -0.42857°C x.rt.b.cmod.04.temp.min 15°C x.rt.b.cmod.05.temp.act 16°C x.rt.b.cmod.05.temp.max 16°C x.rt.b.cmod.05.temp.maxdev 0.57143°C x.rt.b.cmod.05.temp.min 16°C x.rt.b.cmod.06.temp.act 15°C x.rt.b.cmod.06.temp.max 15°C x.rt.b.cmod.06.temp.maxdev -0.42857°C x.rt.b.cmod.06.temp.min 15°C x.rt.b.cmod.07.temp.act 15°C x.rt.b.cmod.07.temp.max 15°C x.rt.b.cmod.07.temp.maxdev -0.42857°C x.rt.b.cmod.07.temp.min 15°C x.rt.b.cmod.08.temp.act -40°C x.rt.b.cmod.08.temp.max -40°C x.rt.b.cmod.08.temp.maxdev 0°C x.rt.b.cmod.08.temp.min -40°C x.rt.b.cmod.cnt 7 x.rt.b.pack.1.temp.stddev.max 0.495093°C x.rt.b.pack.1.voltage.max 56.2V x.rt.b.pack.1.voltage.min 56.1V x.rt.b.pack.1.voltage.stddev.max 0.00586302V x.rt.b.pack.cnt 1 x.rt.m.version 0.1.0 Oct 29 2017 10:44:20 x.rt.p.stats.acc.dist 0Km x.rt.p.stats.acc.recd 0kWh x.rt.p.stats.acc.spdavg 0Kph/s x.rt.p.stats.acc.used 0kWh x.rt.p.stats.cst.dist 0Km x.rt.p.stats.cst.recd 0.000739342kWh x.rt.p.stats.cst.spdavg 0Kph x.rt.p.stats.cst.used 0kWh x.rt.p.stats.dec.dist 0Km x.rt.p.stats.dec.recd 0kWh x.rt.p.stats.dec.spdavg 0Kph/s x.rt.p.stats.dec.used 0kWh x.rt.p.stats.ldn.dist 0Km x.rt.p.stats.ldn.hsum 0m x.rt.p.stats.ldn.recd 0kWh x.rt.p.stats.ldn.used 0kWh x.rt.p.stats.lup.dist 0Km x.rt.p.stats.lup.hsum 0m x.rt.p.stats.lup.recd 0kWh x.rt.p.stats.lup.used 0kWh
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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
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@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
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@expeedo.de <mailto:dexter@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@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
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@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@expeedo.de <mailto:dexter@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@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <http://lists.teslaclub.hk/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@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@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (2)
-
Mark Webb-Johnson -
Michael Balzer