[Ovmsdev] BMS generalization (was: Custom metrics)
Tamás Kovács
kommykt at gmail.com
Sun Nov 18 00:01:06 HKT 2018
i tested on Peuogeot iOn:
Welcome to the Open Vehicle Monitoring System (OVMS) - SSH Console
Firmware: 3.1.011-52-gbe9798f6/ota_0/main
Hardware: OVMS WIFI BLE BT cores=2 rev=ESP32/1
OVMS# bms alerts
Voltage: SD=6mV ?1:+3mV !2:-4mV !3:-4mV !4:+3mV ?5:+4mV !6:+4mV ?7:+4mV
!8:+4mV ?9:+4mV ?10:+3mV ?11:+4mV ?12:+4mV ?13:+4mV ?14:+3mV ?15:+4mV
!16:+4mV !17:-5mV !18:-5mV ?19:+3mV !20:+3mV !21:+4mV ?22:-4mV !23:-5mV
!24:-4mV !25:+3mV ?26:-4mV ?27:+3mV ?28:-3mV !29:+4mV !30:+4mV !31:+4mV
!32:+4mV ?33:-3mV ?34:-3mV !35:+4mV ?36:+4mV !37:-3mV ?38:-3mV !39:+4mV
?40:+4mV !41:-5mV !42:-3mV !43:+3mV !44:+4mV !45:-5mV ?46:-3mV !47:+4mV
!48:+4mV ?49:+4mV ?50:+4mV !51:+4mV !52:+4mV !53:+4mV !54:+8mV !55:+4mV
?56:+4mV ?57:+4mV ?58:+4mV !59:+4mV !60:+4mV ?61:+4mV !62:+4mV !63:-3mV
!64:-3mV !65:+4mV ?66:+4mV !67:-4mV !68:+4mV !69:+4mV !70:+4mV !71:+4mV
?72:+4mV ?73:+8mV !74:+8mV !75:+5mV !76:+4mV !77:+4mV !78:+4mV ?79:+4mV
?80:+4mV ?81:+4mV !82:+4mV ?83:-4mV !84:-3mV !85:+4mV ?86:+4mV !87:+4mV
?88:+4mV
Temperature: SD=1.7C ?3:+1.8C ?4:+2.8C ?5:+1.9C ?6:+3.7C !8:+3.8C ?10:+1.9C
?16:+2.8C ?18:+2.7C ?20:+2.7C ?22:+1.8C ?23:+3.8C ?27:+1.9C ?29:+2.8C
?31:+2.8C ?39:+1.9C ?41:+1.9C ?43:+1.8C ?55:-2.3C ?56:-2.3C ?57:-2.3C
?58:-2.3C ?66:-2.3C
OVMS# metrics list v.b.c
v.b.c.temp
13,14,15,16,15,16,14,17,12,15,13,13,13,14,14,15,14,15,14,15,12,14,17,13,14,12,15,13,16,13,16,13,14,12,12,12,13,12,15,13,14,13,14,12,14,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,12,12,12,11°C
v.b.c.temp.alert
0,0,1,1,1,1,0,1,0,1,0,0,0,0,0,1,0,1,0,1,0,1,2,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,1
v.b.c.temp.dev.max
-0.35,1.65,1.8,2.85,1.85,3.7,0.85,3.8,-1.35,1.85,-0.35,-0.35,-0.35,1.73,0.85,2.76,0.85,2.67,0.83,2.7,-1.35,1.76,3.85,-0.35,0.8,-1.35,1.85,-0.35,2.82,-0.35,2.79,-0.35,0.85,-1.35,-1.35,-1.35,0.77,-1.35,1.85,-0.35,1.85,-1.35,1.79,-1.35,0.82,-1.35,-1.35,-1.35,-0.35,-1.35,-0.35,-1.35,-1.35,-1.35,-2.35,-2.35,-2.35,-2.35,-1.35,-1.35,-0.35,-1.35,-1.35,-1.35,-1.35,-2.35°C
v.b.c.temp.max
13,15,15,16,15,17,14,17,13,15,13,13,13,15,14,16,14,16,14,16,12,15,17,13,14,12,15,13,16,13,16,13,14,12,12,12,14,12,15,13,15,13,15,12,14,12,12,12,13,12,13,12,12,12,11,11,12,11,12,12,13,13,13,12,12,11°C
v.b.c.temp.min
13,14,14,16,15,16,14,16,12,15,13,13,13,14,14,15,14,15,13,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,12,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,12,12,12,12,11°C
v.b.c.voltage
4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02V
v.b.c.voltage.alert
2,1,1,1,2,1,2,1,2,2,2,2,2,2,2,1,1,1,2,1,1,2,1,1,1,2,2,2,1,1,1,1,2,2,1,2,1,2,1,2,1,1,1,1,1,2,1,1,2,2,1,1,1,1,1,2,2,2,1,1,2,1,1,1,1,2,1,1,1,1,1,2,2,1,1,1,1,1,2,2,2,1,2,1,1,2,1,2
v.b.c.voltage.dev.max
0.00352,-0.00472,-0.00494,0.00375,0.0046,0.00489,0.00494,0.00494,0.00432,0.00347,0.00455,0.0046,0.00415,0.00375,0.00415,0.00449,-0.005,-0.005,0.00347,0.00375,0.0046,-0.00494,-0.0054,-0.00455,0.00375,-0.00455,0.00398,-0.00335,0.00477,0.00494,0.00494,0.00494,-0.00335,-0.00335,0.00494,0.00483,-0.00392,-0.00369,0.00415,0.00455,-0.005,-0.00392,0.00375,0.00449,-0.00506,-0.00369,0.00483,0.00489,0.00426,0.00455,0.00477,0.0046,0.00483,0.00886,0.00489,0.00494,0.0046,0.00466,0.0046,0.0046,0.00483,0.00472,-0.00392,-0.00392,0.0046,0.00426,-0.00455,0.00415,0.00477,0.00472,0.00489,0.0046,0.00886,0.00886,0.00511,0.00494,0.00483,0.00477,0.0046,0.00472,0.00477,0.00489,-0.00455,-0.00392,0.00466,0.00432,0.00466,0.00449V
v.b.c.voltage.max
4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.035,4.04,4.04,4.04,4.04,4.04,4.035,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04,4.04V
v.b.c.voltage.min
4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02,4.02V
v.b.cac 1Ah
v.b.consumption 0Wh/km
v.b.coulomb.recd
v.b.coulomb.used
v.b.current -0.88A
OVMS# metrics list v.b.p
v.b.p.level.avg
v.b.p.level.max
v.b.p.level.min
v.b.p.level.stddev
v.b.p.temp.avg 13.23°C
v.b.p.temp.max 17°C
v.b.p.temp.min 11°C
v.b.p.temp.stddev 1.43°C
v.b.p.temp.stddev.max 1.74°C
v.b.p.voltage.avg 4.01903V
v.b.p.voltage.max 4.02V
v.b.p.voltage.min 4.015V
v.b.p.voltage.stddev 0.00599V
v.b.p.voltage.stddev.max 0.00691V
v.b.power 0.311256kW
OVMS# bms reset
BMS cell statistics have been reset.
OVMS# bms alerts
Voltage: SD=6mV ?1:+0mV ?2:+0mV ?3:+0mV ?4:+0mV ?5:+0mV ?6:+0mV ?7:+0mV
?8:+0mV ?9:+0mV ?10:+0mV ?11:+0mV ?12:+0mV ?13:+0mV ?14:+0mV ?15:+0mV
?16:+0mV ?17:+0mV ?18:+0mV ?19:+0mV ?20:+0mV ?21:+0mV ?22:+0mV ?23:+0mV
?24:+0mV ?25:+0mV ?26:+0mV ?27:+0mV ?28:+0mV ?29:+0mV ?30:+0mV ?31:+0mV
?32:+0mV ?33:+0mV ?34:+0mV ?35:+0mV ?36:+0mV ?37:+0mV ?38:+0mV ?39:+0mV
?40:+0mV ?41:+0mV ?42:+0mV ?43:+0mV ?44:+0mV ?45:+0mV ?46:+0mV ?47:+0mV
?48:+0mV ?49:+0mV ?50:+0mV ?51:+0mV ?52:+0mV ?53:+0mV ?54:+0mV ?55:+0mV
?56:+0mV ?57:+0mV ?58:+0mV ?59:+0mV ?60:+0mV ?61:+0mV ?62:+0mV ?63:+0mV
?64:+0mV ?65:+0mV ?66:+0mV ?67:+0mV ?68:+0mV ?69:+0mV ?70:+0mV ?71:+0mV
?72:+0mV ?73:+0mV ?74:+0mV ?75:+0mV ?76:+0mV ?77:+0mV ?78:+0mV ?79:+0mV
?80:+0mV ?81:+0mV ?82:+0mV ?83:+0mV ?84:+0mV ?85:+0mV ?86:+0mV ?87:+0mV
?88:+0mV
Temperature: SD=1.7C ?3:+1.8C ?4:+2.8C ?5:+1.8C ?6:+2.8C ?8:+2.8C ?16:+1.8C
?18:+1.8C ?20:+1.8C ?23:+3.8C ?27:+1.8C ?29:+1.8C ?31:+1.8C ?39:+1.8C
?55:-2.2C ?56:-2.2C ?57:-2.2C ?58:-2.2C ?66:-2.2C
OVMS# metrics list v.b.c
v.b.c.temp
13,14,15,15,15,16,14,16,12,14,13,12,13,14,14,15,14,15,14,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,13,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,12,12,12,11°C
v.b.c.temp.alert
0,0,1,1,1,2,0,2,0,0,0,0,0,0,0,1,0,1,0,1,0,0,2,0,0,0,1,0,1,0,1,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,0,0,0,0,0,0,0,1
v.b.c.temp.dev.max
-0.2,0.85,1.85,2.82,1.85,2.85,0.85,2.85,-1.18,0.85,-0.2,-1.15,-0.2,0.85,0.85,1.85,0.85,1.85,0.85,1.85,-1.2,0.85,3.85,-0.2,-0.2,-1.2,1.85,-0.2,1.85,-0.2,1.85,-0.2,0.85,-1.2,-1.2,-1.2,-0.2,-1.2,1.85,-0.2,0.85,-0.2,0.85,-1.2,-0.2,-1.2,-1.2,-1.2,-0.2,-1.2,-0.2,-1.2,-1.2,-1.2,-2.2,-2.2,-2.2,-2.2,-1.2,-1.2,-0.2,-0.2,-1.2,-1.2,-1.2,-2.2°C
v.b.c.temp.max
13,14,15,16,15,16,14,16,13,14,13,13,13,14,14,15,14,15,14,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,13,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,13,12,12,11°C
v.b.c.temp.min
13,14,15,15,15,16,14,16,12,14,13,12,13,14,14,15,14,15,14,15,12,14,17,13,13,12,15,13,15,13,15,13,14,12,12,12,13,12,15,13,14,13,14,12,13,12,12,12,13,12,13,12,12,12,11,11,11,11,12,12,13,13,12,12,12,11°C
v.b.c.voltage
4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.01,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015V
v.b.c.voltage.alert
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
v.b.c.voltage.dev.max
6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,-0.00494,-0.00494,6e-05,-0.00494,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,-0.00494,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05,6e-05V
v.b.c.voltage.max
4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015V
v.b.c.voltage.min
4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.01,4.01,4.015,4.01,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.01,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015,4.015V
v.b.cac 1Ah
v.b.consumption 0Wh/km
v.b.coulomb.recd
v.b.coulomb.used
v.b.current -1.04A
OVMS# metrics list v.b.p
v.b.p.level.avg
v.b.p.level.max
v.b.p.level.min
v.b.p.level.stddev
v.b.p.temp.avg 13.15°C
v.b.p.temp.max 17°C
v.b.p.temp.min 11°C
v.b.p.temp.stddev 1.39°C
v.b.p.temp.stddev.max 1.74°C
v.b.p.voltage.avg 4.0146V
v.b.p.voltage.max 4.015V
v.b.p.voltage.min 4.01V
v.b.p.voltage.stddev 0.00451V
v.b.p.voltage.stddev.max 0.00691V
v.b.power 0.374498kW
OVMS#
Michael Balzer <dexter at expeedo.de> ezt írta (időpont: 2018. nov. 17., Szo,
16:43):
> Obviously not working for you. Cells that exceeded the alert threshold
> deviation from average get marked with "!", and "?" = warn threshold
> exceeded.
>
> So at some point, many cells exceeded 200% stddev -- obviously not in the
> established overall situation. Is there maybe some init phase with unstable
> / incomplete readings that needs to be skipped on the Model S?
>
> If so, a "bms reset" should clean the alerts up. Can you try that?
>
> Regards,
> Michael
>
>
> Am 17.11.18 um 16:01 schrieb Mark Webb-Johnson:
>
> Not really sure how to interpret this. I get:
>
> OVMS# bms alerts
> Voltage: SD=7mV !1:-7mV !2:-4mV !3:-4mV !4:-5mV !5:-5mV !6:-6mV !7:-1mV
> !8:+2mV !9:+0mV !10:+0mV !11:+0mV !12:-2mV ?13:+0mV !14:+4mV !15:+2mV
> !16:+2mV !17:+0mV !18:+0mV !19:-3mV !20:+0mV !21:-1mV ?22:+0mV !23:-2mV
> !24:-2mV !26:+2mV !27:+1mV !28:+2mV ?29:+0mV !30:+0mV !31:-2mV ?33:+0mV
> !35:-1mV !36:-2mV ?37:-5mV !38:-3mV !39:-2mV !40:-2mV !41:-4mV !42:-6mV
> !43:-3mV !44:+0mV !45:-1mV !46:-1mV !47:-1mV !48:-1mV !49:+6mV !50:+7mV
> !51:+6mV !52:+8mV !53:+7mV !54:+6mV !55:+1mV !56:+4mV !57:+1mV !58:+4mV
> !59:+0mV !60:+0mV !61:+3mV !62:+5mV !63:+4mV !64:+4mV !65:+2mV !66:+3mV
> !67:-1mV !68:+2mV !69:+1mV !70:+1mV !71:-1mV !72:-1mV !74:+2mV !76:+1mV
> ?77:+0mV !78:-1mV !79:+1mV !80:+3mV !81:+1mV !82:+2mV !83:+2mV !84:+1mV
> !85:-3mV !86:+2mV !87:-1mV !88:-1mV !89:-3mV !90:-2mV !91:-2mV !92:-1mV
> !93:-2mV !94:-2mV !95:-3mV !96:-4mV
> Temperature: SD=0.6C ?1:+0.5C ?2:+1.0C ?3:+0.3C ?4:+0.3C ?5:-0.2C ?7:-0.3C
> ?9:-0.2C !10:-0.2C ?12:-0.4C ?13:-0.3C ?14:-0.4C ?15:-0.5C ?16:-0.3C
> ?17:+0.8C !18:-0.3C ?19:-0.1C ?20:-0.3C ?21:-0.1C !22:-0.4C !24:-0.5C
> ?25:-0.3C ?26:-0.4C ?28:-0.3C ?29:+0.7C ?30:+0.3C ?31:+0.9C ?32:+0.5C
>
> OVMS# metrics list v.b.c
> v.b.c.temp
> 28.8652,29.4386,28.6334,28.6822,28.1942,28.5114,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,28.9262,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1454,28.1088,28.4626,28.2186,28.975,28.7554,29.0604,28.9384°C
> v.b.c.temp.alert
> 1,2,1,1,1,1,1,0,1,2,0,1,1,1,1,1,2,2,1,1,1,1,1,1,1,1,0,1,2,1,1,2
> v.b.c.temp.dev.max
> 0.52,1.03,0.31,0.26,-0.23,0.1,-0.29,-0.07,-0.25,-0.18,0.04,-0.44,-0.31,-0.39,-0.46,-0.34,0.76,-0.27,-0.15,-0.3,-0.13,-0.45,-0.08,-0.49,-0.28,-0.41,0.09,-0.28,0.73,0.34,0.92,0.52°C
> v.b.c.temp.max
> 28.8774,29.4386,28.6578,28.6822,28.1942,28.5236,28.1454,28.4626,28.182,28.3406,28.3894,28.121,28.1088,28.1454,28.0112,28.182,29.1092,28.243,28.2674,28.2186,28.2918,28.0844,28.3528,28.0356,28.1576,28.1088,28.4626,28.2186,29.0848,28.7554,29.2678,28.9384°C
> v.b.c.temp.min
> 28.853,29.3654,28.6212,28.5724,28.1332,28.3894,28.1088,28.2796,28.1332,28.1698,28.3894,27.9136,28.0966,27.9624,27.9014,28.0112,28.9262,28.0844,28.2674,28.0478,28.2796,27.9014,28.3406,27.8648,28.121,27.938,28.426,28.0722,28.975,28.609,29.0604,28.8042°C
> v.b.c.voltage
> 4.13794,4.14099,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14556,4.14465,4.14373,4.14556,4.14922,4.14739,4.14709,4.14586,4.14586,4.14251,4.14556,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14586,4.14709,4.14526,4.14526,4.14342,4.14556,4.14526,4.14556,4.14434,4.14342,4.14038,4.14251,4.14282,4.14312,4.14099,4.13946,4.14251,4.14586,4.14434,4.14465,4.14465,4.14434,4.15197,4.15318,4.15166,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14586,4.148,4.15074,4.14983,4.15044,4.1477,4.148,4.14465,4.148,4.14678,4.14647,4.14403,4.14403,4.14556,4.148,4.14586,4.14647,4.14465,4.14526,4.14617,4.148,4.14617,4.14647,4.14739,4.14678,4.14251,4.14709,4.14373,4.14434,4.14282,4.14373,4.14312,4.14465,4.14282,4.14312,4.14282,4.1419V
> v.b.c.voltage.alert
> 2,1,1,1,1,1,2,1,2,2,2,2,1,1,1,2,2,2,1,2,2,1,1,1,0,1,2,2,1,2,1,0,1,0,2,2,1,1,1,1,1,1,1,2,2,2,2,2,1,2,1,2,2,1,2,1,2,1,2,2,1,1,1,1,1,1,2,1,2,2,2,2,0,1,0,2,1,2,2,1,2,2,2,2,1,2,2,2,1,1,1,2,1,1,1,1
> v.b.c.voltage.dev.max
> -0.0082,-0.00487,-0.00498,-0.00508,-0.00583,-0.00674,-0.00139,0.00257,0.00096,0.00086,-0.00096,-0.00221,-0.00061,0.004,0.00275,0.00217,0.00096,0.00077,-0.0034,0.00081,-0.0017,-0.00091,-0.00234,-0.00304,0.00068,0.00288,0.00124,0.0022,-0.00052,-0.00078,-0.0024,0.00095,-0.00103,-0.00061,-0.00179,-0.00224,-0.00546,-0.00335,-0.0032,-0.00271,-0.00506,-0.00644,-0.0036,0.00087,-0.00129,-0.00168,-0.00139,-0.00132,0.00648,0.00824,0.00648,0.00883,0.0081,0.00641,0.00161,0.00443,0.00222,0.00401,0.00096,0.00095,0.00342,0.00597,0.00469,0.00505,0.00318,0.00315,-0.00127,0.00291,0.00132,0.00197,-0.0024,-0.00168,-0.00072,0.00275,0.00069,0.00184,-0.00096,-0.0012,0.00125,0.0032,0.00166,0.00203,0.00291,0.00153,-0.00355,0.00214,-0.00225,-0.00171,-0.003,-0.00249,-0.00292,-0.00152,-0.00295,-0.00296,-0.00311,-0.00432V
> v.b.c.voltage.max
> 4.13794,4.14129,4.14099,4.14099,4.14007,4.13915,4.14465,4.1477,4.14586,4.14586,4.14556,4.14403,4.14556,4.14922,4.1477,4.14709,4.14586,4.14586,4.14251,4.14586,4.14434,4.14495,4.14373,4.14342,4.14586,4.148,4.14617,4.14709,4.14556,4.14526,4.14342,4.14586,4.14526,4.14556,4.14434,4.14373,4.14099,4.14282,4.14282,4.14312,4.14099,4.13946,4.14282,4.14617,4.14465,4.14465,4.14465,4.14434,4.15197,4.15349,4.15197,4.1541,4.15318,4.15166,4.14709,4.14922,4.14709,4.14861,4.14617,4.14647,4.14861,4.15105,4.15014,4.15044,4.1483,4.1483,4.14465,4.148,4.14678,4.14709,4.14403,4.14403,4.14556,4.148,4.14586,4.14709,4.14526,4.14526,4.14647,4.148,4.14709,4.14739,4.1483,4.14678,4.14282,4.14709,4.14403,4.14434,4.14312,4.14373,4.14312,4.14465,4.14312,4.14312,4.14312,4.1419V
> v.b.c.voltage.min
> 4.13123,4.13427,4.13397,4.13397,4.13336,4.13214,4.13732,4.14038,4.13915,4.13885,4.13794,4.13641,4.13824,4.14159,4.14068,4.14007,4.13855,4.13824,4.1355,4.13885,4.13702,4.13794,4.13611,4.1358,4.13855,4.14099,4.13915,4.14007,4.13794,4.13794,4.13641,4.13855,4.13794,4.13824,4.13702,4.13641,4.13367,4.1358,4.1355,4.1358,4.13397,4.13275,4.13488,4.13855,4.13702,4.13702,4.13702,4.13732,4.14342,4.14586,4.14403,4.14617,4.14526,4.14403,4.13824,4.14159,4.13946,4.14038,4.13824,4.13824,4.14099,4.14342,4.14251,4.14251,4.14068,4.14038,4.13732,4.14099,4.13946,4.13976,4.13671,4.13671,4.13794,4.14038,4.13824,4.13946,4.13763,4.13763,4.13885,4.14038,4.13915,4.13946,4.14068,4.13885,4.1355,4.14007,4.13671,4.13732,4.13611,4.13641,4.13641,4.13732,4.13611,4.13641,4.13611,4.13458V
> v.b.cac
> v.b.consumption 0Wh/km
> v.b.coulomb.recd
> v.b.coulomb.used
> v.b.current
>
> OVMS# metrics list v.b.p
> v.b.p.level.avg
> v.b.p.level.max
> v.b.p.level.min
> v.b.p.level.stddev
> v.b.p.temp.avg 28.43°C
> v.b.p.temp.max 29.4508°C
> v.b.p.temp.min 28.0234°C
> v.b.p.temp.stddev 0.36°C
> v.b.p.temp.stddev.max 0.65°C
> v.b.p.voltage.avg 4.14669V
> v.b.p.voltage.max 4.15532V
> v.b.p.voltage.min 4.13855V
> v.b.p.voltage.stddev 0.00669V
> v.b.p.voltage.stddev.max 0.00717V
> v.b.power
>
>
> And a bunch of push notifications every time I connect the App, like this:
>
>
> Regards, Mark
>
> On 17 Nov 2018, at 10:51 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> First implementation of general cell deviation checking and alerts is
> pushed.
>
> Vehicle BMS: cell deviations & alerts
>
> Renamed metrics:
> - v.b.c.level.* → v.b.p.level.* (for consistency)
>
> New metrics:
> - v.b.c.(voltage,temp).(dev.max,alert)
> - v.b.p.(voltage,temp).(min,max,avg,stddev,stddev.max)
>
> New configs:
> - vehicle [bms.dev.voltage.warn] -- threshold [V]
> - vehicle [bms.dev.voltage.alert] -- threshold [V]
> - vehicle [bms.dev.temp.warn] -- threshold [°C]
> - vehicle [bms.dev.temp.alert] -- threshold [°C]
> …all optional, default: warn at 120% stddev, alert at 200% stddev
>
> New commands:
> - bms alerts → show cells with warn/alert levels
>
>
> I changed the config scheme hoping a manual configuration normally isn't
> necessary with this automatic adaption to the standard deviation.
>
> Please check and report if that idea works. If it doesn't, please report
> the deviations and necessary threshold levels on your batteries.
>
> I also omitted the overall stddev alerts for now, I don't think those
> really are necessary, haven't had a single trigger on the Twizy for this.
>
> Integration into the web chart page and historical data updates are still
> todo.
>
> Migration for the Twizy battery monitor to the generalized scheme is in
> progress.
>
> Regards,
> Michael
>
>
> Am 17.11.18 um 11:53 schrieb Mark Webb-Johnson:
>
> Short video showing Model S charging;
>
> https://youtu.be/Q4vMPSwBFAo
>
> On 17 Nov 2018, at 6:13 PM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
> Ok. Will do.
>
> Now you remind me, bms looks good on iPhone:
>
> <image1.jpeg>
>
> On 17 Nov 2018, at 6:08 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Yes, you can add a new menu to PageMenu_t like that. I suggest introducing
> a general tools menu instead of a specific one, i.e. "PageMenu_Tools".
>
> To still fit the menu on one line in tablet mode (width down to 768 px) I
> suggest moving the Shell into the tools menu then.
>
> Go ahead, I'm not working on the web framework at the moment.
>
> Regards,
> Michael
>
>
> Am 17.11.18 um 10:48 schrieb Mark Webb-Johnson:
>
> Twizy code overrides the virtual short name function, so won’t suffer the
> issue.
>
> I think it is a bug in vehicle factory (as modifying the vehicle type is
> reasonable), so fixed it there. Returning NULL is problematic. It would be
> so much easier for everything to return std::string, but concern is memory
> consumption and overhead.
>
> I’d like to start converting RE TOOLS to just use the web server. First
> step is to work out how to add a menu onto the web server. It seems that
> the PageMenu_t is a fixed enum list (and similarly hard-coded in the
> web_framework.
>
> Do I just add a ‘CAN bus’ menu there, by adding it to PageMenu_t, and
> supporting it where the other top level menus are? Or do you have any other
> suggestions/plans for this?
>
> I don’t want to step on anything you are working on here.
>
>
> The second stage will be to add displays under that, but I think that is
> fairly straight forward. I will mostly be displaying tables, and sending
> those over the web socket would be good.
>
> Regards, Mark
>
> On 17 Nov 2018, at 5:37 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Mark,
>
> nice, thanks.
>
> The short name is used for the menu label. It's meant to fall back to the
> long name (and seems to do so in your screenshot), so should not be null.
> But I admit I haven't tested it on a vehicle without a short name.
>
> Btw, I'm currently working on the deviations and alerts.
>
> Regards,
> Michael
>
>
> Am 17.11.18 um 10:08 schrieb Mark Webb-Johnson:
>
> Michael,
>
> Looks good. It seems that you did everything necessary for the Model S
> already in your commit 2a84d861403f48142d6adcc16ad7a20cd458e427:
>
> #include “ovms_webserver.h"
>
> OvmsVehicleTeslaModelS::OvmsVehicleTeslaModelS()
> MyWebServer.RegisterPage("/bms/cellmon", "BMS cell monitor",
> OvmsWebServer::HandleBmsCellMonitor, PageMenu_Vehicle, PageAuth_Cookie);
>
> OvmsVehicleTeslaModelS::~OvmsVehicleTeslaModelS()
> MyWebServer.DeregisterPage("/bms/cellmon");
>
>
> From my devbench, replaying a CAN CRTD log file, I get this output:
>
> <PastedGraphic-2.png>
>
> The animation is very nice.
>
> I am, however, getting crashes, as follows:
>
> # xtensa-esp32-elf-addr2line -pfiaC -e 3.1.011-25-g2a84d86.ovms3.elf
> 0x400935d3 0x4009372b 0x400db90c 0x4012c0f7 0x4012d0e1 0x4012d1e0
> 0x4012ebc1 0x4012ecbd 0x400f8b65 0x400f912d 0x400fa27c 0x400fa29a
> 0x400f8b65 0x400fa3e3 0x400fa7ad 0x400faa77 0x400f767e 0x400ee40a 0x400ee459
> 0x400935d3: invoke_abort at
> /home/openvehicles/build/esp-idf/components/esp32/panic.c:670
> 0x4009372b: abort at
> /home/openvehicles/build/esp-idf/components/esp32/panic.c:670
> 0x400db90c: __cxx_fatal_exception_message at
> /home/openvehicles/build/esp-idf/components/cxx/cxx_exception_stubs.cpp:19
> 0x4012c0f7: void std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::_M_construct<char const*>(char const*, char const*,
> std::forward_iterator_tag) at
> /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.tcc:216
> (inlined by) void std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::_M_construct_aux<char
> const*>(char const*, char const*, std::__false_type) at
> /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:195
> (inlined by) void std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::_M_construct<char
> const*>(char const*, char const*) at
> /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:214
> (inlined by) std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> >::basic_string(char const*, std::allocator<char>
> const&) at
> /home/openvehicles/build/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/5.2.0/bits/basic_string.h:457
> 0x4012d0e1: OvmsWebServer::CreateMenu[abi:cxx11](PageContext&) at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:393
> 0x4012d1e0: OvmsWebServer::HandleRoot(PageEntry&, PageContext&) at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/web_framework.cpp:510
> 0x4012ebc1: PageEntry::Serve(PageContext&) at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558
> 0x4012ecbd: OvmsWebServer::EventHandler(mg_connection*, int, void*) at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/ovms_webserver/src/ovms_webserver.cpp:558
> 0x400f8b65: mg_call at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400f912d: mg_http_call_endpoint_handler at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400fa27c: mg_http_handler2 at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400fa29a: mg_http_handler at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400f8b65: mg_call at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400fa3e3: mg_recv_common at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400fa7ad: mg_if_recv_tcp_cb at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> (inlined by) mg_handle_tcp_read at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3723
> (inlined by) mg_mgr_handle_conn at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:3844
> 0x400faa77: mg_socket_if_poll at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400f767e: mg_mgr_poll at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/components/mongoose/mongoose/mongoose.c:1701
> 0x400ee40a: OvmsNetManager::MongooseTask() at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:560
> 0x400ee459: MongooseRawTask(void*) at
> /home/openvehicles/build/Open-Vehicle-Monitoring-System-3.1/vehicle/OVMS.V3/main/ovms_netmanager.cpp:545
>
>
> On my development bench module I get this crash 1 in 4 times or so. On my
> real car, 100% of the time.
>
> That code path leads into MyVehicleFactory.ActiveVehicleShortName(). Those
> should all be ‘const char*’, but it is possible for NULL to be returned. I
> will look into it in more detail.
>
> Regards, Mark.
>
> On 17 Nov 2018, at 7:35 AM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Mark, Tamás,
>
> I haven't had the time yet to take care of the stddev port, but I've just
> added the generalized web UI.
>
> Please see git log for details and send some screenshots.
>
> Regards,
> Michael
>
>
> Am 11.11.18 um 16:47 schrieb Mark Webb-Johnson:
>
> OK. I spent some time on this today, and sent in a first draft (as a bunch
> of extensions to vehicle.{h, cpp}). I migrated the Tesla Model S code to
> use it, and support came down to just a few simple lines of code.
>
> For the moment, I dropped the idea of ‘readingsperrow’, as I think that is
> Tesla Model S specific, and not really necessary. Purely presentational.
>
> c++ std::bitset is fixed size, so that doesn’t work for us. The
> std::vector<bool> seems a workable alternative, but I am not really happy
> with using std::find as a way of looking to see if we have everything. It
> works as it is, but is not very optimal. It seems there should be a better
> way of doing that. I think it is a pretty key feature, given the broadcast
> nature of the buses, to help the vehicle module know when it has a set of
> data ready to commit to metrics, so will need to think about this some more.
>
> I also implemented min and max, for voltages and temperatures. They went
> in cleanly. Haven’t tackled stddev yet (or the watchers/alerts, overall
> aggregates, etc). There is a very basic ‘bms status’ command implemented.
>
> Let me know what you think of it.
>
> Regards, Mark
>
> On 11 Nov 2018, at 5:11 PM, Michael Balzer <dexter at expeedo.de> wrote:
>
> Mark,
>
> yes, .min & .max are the minimum and maximum readings seen since last
> battery monitor reset. The reset should be available as…
>
> - OvmsVehicle::ResetCellStats();
> - Command: "vehicle bms reset" …or just "bms reset" as we also have
> other vehicle commands on the root level?
>
> On the Twizy I do an auto reset each time the vehicle is turned on and
> each time a charge starts, but that behaviour should be controllable by the
> vehicle / user.
>
>
> There's additionally the overall { .stddev, .avg } on voltages and
> temperatures of the pack. These and the cell level statistics can be
> calculated by the framework, so the vehicle simply needs to provide the
> readings. The framework needs to provide a way to reset the readings
> completion bitset, i.e.
>
> - OvmsVehicle::RestartCellVoltages();
> - OvmsVehicle::RestartCellTemperatures();
>
> …as sometimes readings get lost, and adding new to the previous readings
> may lead to an inconsistent view leading to wrong standard deviation.
>
>
> Speaking of standard deviation, the framework should also provide warnings
> and alerts flags. On the Twizy it does so by checking deviation thresholds,
> and there's a general stddev warn & alert threshold to detect overall
> condition and two alert thresholds on the cell level, one for normal stddev
> and one for stddev alert mode. Warning flags on the cell level are set when
> the cell deviation is above stddev. On the Twizy these thresholds are
> currently fixed to…
>
> // Battery cell/cmod deviation alert thresholds:
> #define BATT_DEV_TEMP_ALERT 3 // = 3 °C
> #define BATT_DEV_VOLT_ALERT 6 // = 30 mV
>
> // ...thresholds for overall stddev:
> #define BATT_STDDEV_TEMP_WATCH 2 // = 2 °C
> #define BATT_STDDEV_TEMP_ALERT 3 // = 3 °C
> #define BATT_STDDEV_VOLT_WATCH 3 // = 15 mV
> #define BATT_STDDEV_VOLT_ALERT 5 // = 25 mV
>
> …these are good defaults for the Twizy 43 Ah pouch cells, but may be too
> low for an 18650 pack, and will especially not fit cheap LFP type cells. So
> these should be configurable, i.e.
>
> - vehicle bms.dev.temp.alert [°C]
> - vehicle bms.dev.voltage.alert [V]
> - vehicle bms.stddev.temp.watch [°C]
> - vehicle bms.stddev.temp.alert [°C]
> - vehicle bms.stddev.voltage.watch [V]
> - vehicle bms.stddev.voltage.alert [V]
>
> I can generalize the Twizy code for all of this.
>
>
> The Twizy battery monitoring command set is:
>
> OVMS# xrt batt ?
> data-cell Output cell record
> data-pack Output pack record
> reset Reset alerts & watches
> status Status report
> tdev Show temperature deviations
> temp Show temperatures
> vdev Show voltage deviations
> volt Show voltages
>
> The "data" commands provide the server historical records output. The
> other commands originate from the V2 and have been designed to keep the
> output within the SMS msg size limit.
>
> "status" gives an operative overview of the standard and max deviation
> levels of cells with warning or alert status. "volt", "vdev", "temp" and
> "tdev" show all cells.
>
> The Twizy generates a battery alert notification from the "status" output
> whenever some cell alert flag is set.
>
>
> The Twizy server records also originate from the V2 limits, and can now
> better be changed to vectors. I've just finished a virtual dynamometer on
> the Twizy, sending a vector metric to the server is just a matter of…
>
> std::string msg = "RT-ENG-MotTrqDrv,0,86400,";
> msg.append(m_mon.m_mot_torque_drv->AsString());
> MyNotify.NotifyString("data", "xrt.pwr.mon", msg.c_str());
>
> Neat.
>
> The Twizy sends server records once per minute during drive/charge. The
> server update frequency should become tunable as well, as that would be a
> lot of additional data volume on large packs.
>
>
> The Twizy layout may be either…
>
> - 14 cell groups in the pack
> - 2 cell groups in each module
> - 7 modules in the pack
> - Each cell group has 1 voltage measurement (so, 14 individual voltage
> measurements)
> - Each module has 1 temperature measurements (so, 7 individual
> temperature measurements)
> - That means:
> - OvmsVehicle::SetCellArrangementVoltage(14, 2, 7)
> - OvmsVehicle::SetCellArrangementTemperature(7, 1, 7)
>
> …for the original battery, or for an LFP type replacement…
>
> - 16 cell groups in the pack
> - 16 cell groups in each module
> - 1 module in the pack
> - Each cell group has 1 voltage measurement (so, 16 individual voltage
> measurements)
> - Each module has 3 temperature measurements (so, 3 individual
> temperature measurements)
> - That means:
> - OvmsVehicle::SetCellArrangementVoltage(16, 16, 8)
> - OvmsVehicle::SetCellArrangementTemperature(3, 3, 3)
>
>
> Regards,
> Michael
>
>
> Am 11.11.18 um 08:10 schrieb Mark Webb-Johnson:
>
> Looking at the discussion with Michael back in May, we came to some
> conclusions for this. I was happy back then with using ‘cell’ rather than
> ‘module’ as the naming, because (a) we are talking about cell/brick/module
> level here, not pack, and (b) it is shorter. It seems that the twizy has:
>
> xrt.b.cell.01.volt.act 3.995V
> xrt.b.cell.01.volt.max 4.12V
> xrt.b.cell.01.volt.maxdev 0.01V
> xrt.b.cell.01.volt.min 3.795V
> ...
> xrt.b.cell.cnt 14
> ...
> xrt.b.cmod.01.temp.act 17°C
> xrt.b.cmod.01.temp.max 23°C
> xrt.b.cmod.01.temp.maxdev 1°C
> xrt.b.cmod.01.temp.min 16°C
> ...
> xrt.b.cmod.cnt 7
> ...
> xrt.b.pack.1.temp.alerts
> xrt.b.pack.1.temp.max 23°C
> xrt.b.pack.1.temp.min 16°C
> xrt.b.pack.1.temp.stddev.max 1°C
> xrt.b.pack.1.temp.watches
> xrt.b.pack.1.volt.alerts
> xrt.b.pack.1.volt.max 57.6V
> xrt.b.pack.1.volt.min 52.8V
> xrt.b.pack.1.volt.stddev.max 0.005V
> xrt.b.pack.1.volt.watches 1,2,4,5,6,7,11,12,14
> xrt.b.pack.cnt 1
> ...
> xrt.b.soc.max 100%
> xrt.b.soc.min 69.78%
>
>
> Trying to come up with a standard representation for this (so everyone can
> use a shared library, and share output displays), that works across all
> vehicles... Assuming we have one-dimensional arrays for different types of
> measurement (for voltage, temperature, etc), measurements are taken at the
> group of cells level (with perhaps different groupings for different
> readings), and aggregations/limits being automatically calculated, I think
> this has:
>
>
> 1. v.b.c.voltage
>
> Vector<float> metric type array of voltage measurements
>
> 2. v.b.c.temp
>
> Vector<float> metric type array of temperature measurements
>
> 3. Aggregations / limits
>
> We could have v.b.c.voltage.min, v.b.c.voltage.max,
> v.b.c.voltage.maxdev, v.b.c.temp.min, v.b.c.temp.max, and v.b.c.temp.maxdev
> if we wanted to store these. Presumably they could be automatically
> calculated? I am guessing ‘min’ is the minimal value seen, and ‘max’ the
> maximum?
>
> 4. Setting as a batch
>
> The way I’ve implemented the Model S is to keep a bitmap of values
> set. For example, say we have 32 cell voltage measurements. Every time we
> set a voltage measurement, we set the appropriate bit. When the bitmap is
> full, zero the bitmap, then set the metric in bulk (setting the entire
> vector). That seems to work well for Model S at least. The
> aggregations/limits would be calculated (and set) when the batch is ready.
> I suggest something like:
>
> - OvmsVehicle::SetCellVoltage(int index, float value);
> - OvmsVehicle::SetCellTemperature(int index, float value);
>
> 5. Arrangement
>
> My thinking is that the count of measurements available can be defined
> when the module initialises. We can also simply count the size of the
> vectors, to know that. The issue is the cell/brick/module/pack arrangement;
> How many voltage or temperature measurements per module, how many modules
> in the pack, etc. I think we need to tell the system (a) the number of
> readings expected, (b) the number of readings per module, and (c) a hint to
> say how many readings to show per row. I suggest something like:
>
> - OvmsVehicle::SetCellArrangementVoltage(int readings, int
> readingspermodule, int readingsperrow)
> - OvmsVehicle::SetCellArrangementTemperature(int readings, int
> readingspermodule, int readingsperrow)
>
> 6. Commands
>
> Once the above is defined we can have a ‘vehicle bms status’ command
> to show the status (like the Tesla Model S one shown here, albeit more
> polished):
>
>
> -------------------------------
> 1 | 3.981 V | 3.981 V | 3.981 V | 29.5 C
> | 3.981 V | 3.981 V | 3.981 V | 30.3 C Max
> -------------------------------
> 2 | 3.981 V | 3.981 V | 3.982 V | 29.4 C
> | 3.981 V | 3.981 V | 3.981 V | 29.8 C
> -------------------------------
> 3 | 3.982 V | 3.982 V | 3.981 V | 29.1 C
> | 3.981 V | 3.981 V | 3.982 V | 29.7 C
> -------------------------------
> 4 | 3.982 V | 3.982 V | 3.982 V | 28.9 C Min
> | 3.981 V | 3.982 V | 3.982 V | 29.7 C
> -------------------------------
> 5 | 3.982 V | 3.982 V | 3.982 V | 29.0 C
> | 3.982 V | 3.981 V | 3.981 V | 29.6 C
> -------------------------------
> 6 | 3.982 V | 3.982 V | 3.982 V | 29.3 C
> | 3.982 V | 3.982 V | 3.982 V | 29.6 C
> -------------------------------
> 7 | 3.981 V | 3.981 V | 3.981 V | 29.0 C
> | 3.981 V | 3.981 V | 3.981 V | 29.6 C
> -------------------------------
> 8 | 3.982 V | 3.983 V | 3.982 V | 29.2 C
> | 3.983 V | 3.982 V | 3.982 V | 29.9 C
> -------------------------------
> 9 | 3.982 V | 3.982 V | 3.981 V | 30.0 C
> | 3.982 V | 3.981 V | 3.981 V | 29.7 C
> -------------------------------
> 10 | 3.979 V | 3.980 V | 3.979 V | 29.1 C
> | 3.980 V | 3.979 V | 3.979 V | 29.8 C
> -------------------------------
> 11 | 3.980 V | 3.981 V | 3.981 V | 29.1 C
> | 3.981 V | 3.981 V | 3.981 V | 29.4 C
> -------------------------------
> 12 | 3.981 V | 3.982 V | 3.981 V | 29.1 C
> | 3.981 V | 3.981 V | 3.982 V | 29.3 C
> -------------------------------
> 13 | 3.982 V | 3.983 V | 3.982 V | 28.9 C
> | 3.982 V | 3.982 V | 3.982 V | 29.4 C
> -------------------------------
> 14 | 3.981 V | 3.982 V | 3.982 V | 29.3 C
> | 3.982 V | 3.982 V | 3.982 V | 29.5 C
> -------------------------------
> 15 | 3.981 V | 3.982 V | 3.981 V | 29.6 C
> | 3.982 V | 3.981 V | 3.981 V | 29.9 C
> -------------------------------
> 16 | 3.982 V | 3.982 V | 3.982 V | 29.5 C
> | 3.982 V | 3.981 V | 3.981 V | 29.8 C
> -------------------------------
> Tmin: 28.9 Tmax: 30.3 Vmax: 3.983 Vmin: 3.979 Vmax-Vmin: 0.003
> Vtot: 382.23
>
> Another variant of this display would be:
>
> --------------------------------------------------------------
> --------------------
> 1 | 3.981 V | 3.981 V | 3.981 V | 3.981 V | 3.981 V | 3.981 V | 29.5 C. 30.3
> C Max |
> --------------------------------------------------------------
> --------------------
> 2 | 3.981 V | 3.981 V | 3.982 V | 3.981 V | 3.981 V | 3.981 V | 29.4 C 29.8
> C |
> --------------------------------------------------------------
> --------------------
> 3 | 3.982 V | 3.982 V | 3.981 V | 3.981 V | 3.981 V | 3.982 V | 29.1 C 29.7
> C |
> --------------------------------------------------------------
> --------------------
> 4 | 3.982 V | 3.982 V | 3.982 V | 3.981 V | 3.982 V | 3.982 V | 28.9 C
> Min 29.7 C |
> --------------------------------------------------------------
> --------------------
> 5 | 3.982 V | 3.982 V | 3.982 V | 3.982 V | 3.981 V | 3.981 V | 29.0 C 29.6
> C |
> --------------------------------------------------------------
> --------------------
> ...
> --------------------------------------------------------------
> --------------------
> 16 | 3.982 V | 3.982 V | 3.982 V | 3.982 V | 3.981 V | 3.981 V | 29.5 C 29.8
> C. |
> --------------------------------------------------------------
> --------------------
> Tmin: 28.9 Tmax: 30.3 Vmax: 3.983 Vmin: 3.979 Vmax-Vmin: 0.003
> Vtot: 382.23
>
> (The vehicle itself having the control via the SetCellArrangement methods)
>
>
> To provide a baseline usage case, the Tesla Model S has:
>
>
> - 96 bricks in the pack
> - 6 bricks in each module
> - 16 modules in the pack
> - Each brick has one voltage measurement (so, 96 individual voltage
> measurements)
> - Each module has two temperature measurements (so, 32 individual
> temperature measurements)
> - That means:
> - OvmsVehicle::SetCellArrangementVoltage(96, 6, 3)
> - OvmsVehicle::SetCellArrangementTemperature(32, 2, 1)
>
>
> Tesla Model X seems identical to Model S.
>
> I am still working on reverse engineering the Tesla Roadster, but it seems
> to have:
>
>
> - 99 bricks in the pack
> - 9 bricks in each module (aka sheet)
> - 11 modules in the pack
> - Each brick has one voltage measurement (so, 11*9 = 99 individual
> voltage measurements)
> - Each module has four temperature measurements (so, 11*4 = 44
> individual temperature measurements)
> - That means:
> - OvmsVehicle::SetCellArrangementVoltage(99, 9, 9)
> - OvmsVehicle::SetCellArrangementTemperature(44, 4, 4)
>
>
> For other cars that support cell-level measurements, do they fit this
> representation? If so, can we fill in the following for each car, to see
> how it fits in?
>
>
> - XX cell groups in the pack
> - XX cell groups in each module
> - XX modules in the pack
> - Each cell group has one voltage measurement (so, XX individual
> voltage measurements)
> - Each module has four temperature measurements (so, XX individual
> temperature measurements)
> - That means:
> - OvmsVehicle::SetCellArrangementVoltage(N, Y, Z)
> - OvmsVehicle::SetCellArrangementTemperature(N, Y, Z)
>
>
> If they don’t fit, what changes are needed to make it work?
>
> Regards, Mark.
>
> On 11 Nov 2018, at 12:16 AM, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
> I originally thought ‘brick’, or ‘module’ rather than ‘cell’, but happy
> with either. These are readings for groups of cells, rather than whole pack.
>
> Tesla Model S is 16 modules. 6 voltage readings, and 2 temperatures, per
> module.
>
> What is Kia Soul arrangement?
>
> Regards, Mark
>
> On 10 Nov 2018, at 11:26 PM, Henrik Scheel <henrik.scheel at spjeldager.dk>
> wrote:
>
> Hi Mark.
>
> Good idea with a generic array type metric, and standard metrics for
> common EV features!
>
> Just a quick note:
> The Kia Soul EV vehicle module will be able to utilize these
> metric-arrays. However, on the Soul, the voltages are for each physical
> pair of cells connected in parallel, and the temperatures are for 6 battery
> modules, and for the battery cooling air inlet.
>
> So, for the Kia Soul EV, the name “v.b.cell.temp” would be misleading, as
> each measured module temperature is representing the state for 16 pairs of
> cells.
>
> Aside from that, I am all for mapping the values in these new standardized
> metric types. Currently, the temperature average is calculated and mapped
> to a metric, and the 96 cell voltages are unmapped for Kia Soul EV.
>
> Best regards,
> Henrik
> --
>
> Venlig hilsen / best regards
> Henrik R. Scheel
>
> Spjeldager Consult ApS
> Spjeldager 9
> DK-2630 Taastrup
> CVR: 34491399
> T: +45 2720 9828
> http://www.spjeldager.dk/
>
> Den 10. nov. 2018 kl. 15.34 skrev ovmsdev-request at lists.openvehicles.com:
>
> Send OvmsDev mailing list submissions to
> ovmsdev at lists.openvehicles.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> or, via email, send a message with subject or body 'help' to
> ovmsdev-request at lists.openvehicles.com
>
> You can reach the person managing the list at
> ovmsdev-owner at lists.openvehicles.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OvmsDev digest..."
>
>
> Today's Topics:
>
> 1. Re: Custom metrics (Mark Webb-Johnson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 10 Nov 2018 22:34:46 +0800
> From: Mark Webb-Johnson <mark at webb-johnson.net> <mark at webb-johnson.net>
> To: OVMS Developers <ovmsdev at lists.openvehicles.com>
> <ovmsdev at lists.openvehicles.com>
> Subject: Re: [Ovmsdev] Custom metrics
> Message-ID: <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11 at webb-johnson.net>
> <1E30255B-5CC6-4EC4-BA9F-9CA41D156B11 at webb-johnson.net>
> Content-Type: text/plain; charset="utf-8"
>
> I?ve added UnregisterCommand() methods to ovms_command.{h, cpp}. I?ve also
> updated the vehicle_teslamodels code to UnregisterCommand in the
> destructor. I think that is cleaner. The unregistering of CAN buses already
> seems to be working properly, config parameters should persist (even
> without vehicle module loaded). I am still considering the situation with
> metrics (but tend to think that they should disappear when the vehicle
> module is unloaded).
>
> I?ve also changed the vehicle_teslamodels code to use single voltage and
> temperate metric arrays (I think my previous dual voltage temperature
> arrangement was incorrect). I think these can now become standard metrics
> (one for battery voltage, and another for temperature). How about
> v.b.cell.voltage and v.b.cell.temp? The interpretation of those vectors
> (how many modules primarily - with the calculation of voltages and
> temperatures per module being dependent on the realtime size of each array)
> will still be vehicle dependent, and I guess the vehicle module can provide
> hints to our standard component for this. Perhaps we can just implement it
> in vehicle.{h, cpp}? I think this standard module can deal with:
>
> An interface for specific vehicle module to specify the number of modules,
> number of voltage measurements, and number of temperature measurements
> available.
> Internal storage of cell voltages and temperatures.
> Tracking of when all voltages and temperatures have been set, and these
> should be written to metrics (as a transaction).
> Standardised command to display on terminal (like ?xts bms?).
> Web interface extensions (including the charting you have, a textual
> display, etc).
>
> I can handle all of the above, except the web interface. What do you
> think? Can these be standardised? Certainly for Tesla Roadster and Tesla
> Model S they appear to be able to be unified under one standard framework.
>
> Regards, Mark.
>
> On 8 Nov 2018, at 6:49 AM, Michael Balzer <dexter at expeedo.de>
> <dexter at expeedo.de> wrote:
>
> Mark,
>
> 1) yes, we're approaching a generic form now. The chart currently displays
> actual, min & max values from the arrays, and derives the overall average
> value. It automatically adapts to the number of voltages and temperatures
> stored in the arrays.
>
> It still lacks:
> a) Displaying max deviations, current standard deviation and max standard
> deviation recorded.
> b) Displaying cell/module warn & alert status. These are currently set
> metrics on the Twizy, could better be generalized as arrays as well, i.e.
> 0=normal, 1=warn, 2=alert.
> c) SOH / capacity and internal resistance should be generally available
> per cell as well (no data on these yet on the Twizy).
>
> And as this will visually overload the chart it will need some buttons to
> show/hide the parts.
>
> A general vehicle base support for these metrics could automatically keep
> min & max values, calculate deviations and derive warn/alert status from
> these. So basically a vehicle adapter only needs to provide voltages and
> temperatures (+ SOH and internal resistance as available). The reset
> command then can also normally just be a generalized version.
>
> 2) I should add some basic documentation on this to the developer manual
> (lacking time). For the RE tools I've got an API to inject arbitrary data
> into the websocket stream on my todo list, so live updates can be
> transported without polling.
>
> 4) Interesting idea, similar to a reverse proxy. As the channel will be
> very slow we will need to reduce the websocket update frequency, make it
> configurable or maybe auto-adapt to the current speed. Also, the proxy
> should cache static assets to speed up first time connects.
>
> The v2 protocol using RC4 encryption is a bad base for this. What's the
> current encryption on v3/MQTT?
>
> Regards,
> Michael
>
>
> Am 07.11.18 um 01:50 schrieb Mark Webb-Johnson:
> Some questions/comments:
>
> I guess this is fairly generic. Voltages and temperatures, with possibly a
> different number of readings for each. Model S has two temperatures, but I
> guess we can just treat those as interleaved. Could it be put into a
> reusable component? Or could we have standard metrics for this now (battery
> module voltages and temperatures)? Maybe a single component that does all
> this (functions to set individual voltages and temperatures, define the
> layout for display, include web interface for chart and table, etc)?
>
> I really need to look at integration of extensions to the web interface.
> See how that is done. For my work on DBC and RE tools, it seems easiest to
> just create a web interface (rather than messing around with command line).
>
> Regarding the registration of commands and metrics, I am not sure if that
> is done correctly at the moment. In particular in the case a vehicle module
> is loaded, unloaded, then loaded again. It seems that RegisterCommand
> doesn?t do it right, and the metric object creation needs a guard to make
> sure the metric doesn?t already exist. I will try to tidy this up in Model
> S code, as a reference, before moving on to Roadster.
>
> I really haven?t used the web interface much, as it is not available over
> cellular. I was wondering if it could be encapsulated somehow within the
> v2/v3 protocol, and made available via the server? Something like
> https://api.openvehicles.com:8080/VEHICLEID
> <https://api.openvehicles.com:8080/VEHICLEID>
> <https://api.openvehicles.com:8080/VEHICLEID> tunnelled through (with
> authentication at the server level using the normal web server user
> account). Similarly for SSH access. These are both simple tcp/ip
> connections, so presumably could be injected into mongoose as fake
> connections. One possible approach would be SOCKS, and there is some
> reference code for LWIP <https://github.com/russdill/lwip/commit/dfeba616>
> <https://github.com/russdill/lwip/commit/dfeba616>. Another is TUN/TAP,
> again with reference code for LWIP
> <https://github.com/russdill/lwip/commit/47ca42f8>
> <https://github.com/russdill/lwip/commit/47ca42f8>. And then there is the
> standard PPP (although that would technically then be PPP within tcp/ip
> over PPP within async within GSM, which is a bit freaky).
>
> Regards, Mark.
>
> On 7 Nov 2018, at 4:52 AM, Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de> <dexter at expeedo.de>> wrote:
>
> Mark, Tam?s,
>
> I've prepared a more or less generalized array version of my Twizy battery
> chart (OvmsVehicleRenaultTwizy::WebBattMon) for you. Easier to collect the
> data from actual arrays than separate metrics.
>
> This ZIP?
>
> https://dexters-web.de/f/ovms-dev/ovms.zip
> <https://dexters-web.de/f/ovms-dev/ovms.zip>
> <https://dexters-web.de/f/ovms-dev/ovms.zip>
>
> ?contains my local ovms web test/development folder. Unzip it into some
> local web server (needs to be run via http for javascript), then open the
> folder from a browser. You should see an OVMS web UI lookalike.
>
> Config ? CellChart loads "cellchart.htm". The blue button generates and
> injects test data. Should look like this:
>
> <eoibkbnkbpofdlab.png>
>
> Assuming you'll add some min/max records as well I left that code
> including the reset button in there. If you can't provide that yet, you can
> simply set min & max = act in the get_xxx_data functions. Other than that
> you should basically just need to change the metrics names.
>
> To generate C/C++ syntax from the file, use the script bin/mksrc:
> "bin/mksrc cellchart.htm >cellchart.cpp". The chart init URL needs to be
> changed for the production environment (see comment), and the test data
> generator can be removed. See OvmsVehicleRenaultTwizy::WebBattMon for
> reference.
>
> Maybe I should add that stuff to the repository as well?
>
> Regards,
> Michael
>
>
> Am 06.11.18 um 15:56 schrieb Mark Webb-Johnson:
> Nice. I just implemented this for Model S using your new metric type.
>
> 96 individual brick voltages for each of the bricks, plus two temperatures
> for each of the 16 modules.
>
> Works well.
>
>
>
>
> On 1 Nov 2018, at 5:58 PM, Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de> <dexter at expeedo.de>> wrote:
>
> Tam?s,
>
> I've been creating separate metrics for all cell values on the Twizy, but
> that only has 14 cells.
>
> We discussed this before, a better approach is introducing a new metric
> class for arrays. I have just done that for you, please pull.
>
> Usage example:
> OvmsMetricVector<float>* vf = new OvmsMetricVector<float>("test.volts",
> SM_STALE_MIN, Volts);
> vf->SetElemValue(3, 1.23);
> vf->SetElemValue(17, 2.34);
> float myvals[3] = { 5.5, 6.6, 7.7 };
> vf->SetElemValues(10, 3, myvals);
> With this data set, you get:
> OVMS# met lis test
> test.volts
> 0,0,0,1.23,0,0,0,0,0,0,5.5,6.6,7.7,0,0,0,0,2.34V
> ?and in the web framework:
> metrics["test.volts"]
> (18) [0, 0, 0, 1.23, 0, 0, 0, 0, 0, 0, 5.5, 6.6, 7.7, 0, 0, 0, 0, 2.34]
> metrics["test.volts"][11]
> 6.6
> See template definition in ovms_metrics.h for more.
>
> Regards,
> Michael
>
>
> Am 31.10.18 um 20:08 schrieb Tam?s Kov?cs:
> I have a Peugeot iOn, and i wan't to create own metrics for battery temp
> (66 piece) and voltage (88 (old) or 80(new) piece) for all cell (and show
> on web interface), and i don't understand how can i create it. Now my data
> in array-s from can messages 6E1-6E4.
> My git fork:
> https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot
> <https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot>
> <https://github.com/KommyKT/Open-Vehicle-Monitoring-System-3/tree/peugeot>
> vehicle_mitsubishi
>
>
> --
> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> <OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> <OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> <http://lists.openvehicles.com/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.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> <OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
>
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
> <OvmsDev at lists.openvehicles.com>
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
> <http://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181110/b17e54e7/attachment.html>
> <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181110/b17e54e7/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> ------------------------------
>
> End of OvmsDev Digest, Vol 82, Issue 10
> ***************************************
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://lists.openvehicles.com/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.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
--
Üdvözlettel:
Kovács Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20181117/3be26046/attachment-0001.html>
More information about the OvmsDev
mailing list