[Ovmsdev] test works, what next

Nikolay Shishkov nshishkov at yahoo.com
Mon Jan 7 15:05:16 HKT 2013


Mark, 
I think you have misunderstood the following part from my e-mail:


In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text.



What "car_" variables I should use for the pack voltage and pack current? 
What "car_" variables I should use for statuses that are not available as a car_variables?
Also the nominal pack temperatures (for the zebra battery) are around 270C (two hundred and seventy Celsius) - any idea if this would be a problem with the current setup?

Eventhough the Tesla and Think are both EVs, they have some significant differences in technology and thus significant differences at what drivers would be interested in seeing. 

So should I define my own handling and "think_" parameters, or should I add more "car_" ones?

Thanks,
Nikolay




________________________________
From: Mark Webb-Johnson <mark at webb-johnson.net>
To: OVMS Developers <ovmsdev at lists.teslaclub.hk> 
Sent: Monday, January 7, 2013 2:27 AM
Subject: Re: [Ovmsdev] test works, what next


Nikolay,

In general, all the car module needs to do is put the correct data into the car_* global variables (defined in ovms.h). From there, SMS commands are implemented in net_sms.* and smartphone app comms are implemented in net_msg.* - the vehicle module itself doesn't need to do anything. For example, if you store the state-of-charge percentage in car_SOC, then an SMS STAT command will return it, and the battery gauge on a connected smartphone App will show it.

You only need to override / add SMS or MSG commands if you want to do something vehicle-specific. The default net_sms and net_msg modules will do the standard stuff all for you.

Assuming that you are doing the above (e.g. writing state of charge to car_SOC), to get this on the smartphone all you need to do is configure the car module for GPRS and SERVER, then get the app running on your smartphone. You can follow the instructions in the Tesla Roadster User Guide to do this.

Regarding notifications, those are initiated by the vehicle module, using net_req_notification() and one of the NET_NOTIFY_* notification types (defined in net.h). The framework will issue the notification - you just need to set the bit to request it.

Regards, Mark.


On 6 Jan, 2013, at 10:04 PM, Nikolay Shishkov wrote:

Thanks to Michael, Mark and google the code now works. 
>I am fetching SOC, pack current, pack voltage, and pack average temperature. 
>So what next?
>The current code is based on the Twizy, I have changed the implementation of the Debug command and am getting correct values... but I would like to have the STATE command work too, and I will implement a custom one too (based on the Twizy code) so it will report what I want it to report. There is for example no range.
>How to go about with integrating server and android/iphone app?
>In the simplest form I would like to have at least SOC, Temperature, Pack voltage, Pack current, a some kind of text or bit map for state (like charged, charging enabled, plugged, waiting temp) there are some more states, some additional parameters like PWM signal for charge power, and eventual errors and warnings - there is a warning "please charge to full soon" for example. These can also be bits or text.
>From the Twizy code I can see how to handle this for the sms commands, and I see some ways of generating semicolon separated message to the server... but would that mean that the message will be later understood/presented by the apps? 
>
>
>I would also like to have the SOC notifications - low SOC, charge finished, charge stopped - I can also fix this the Twizy way.
>
>
>Very exciting!
>Thanks,
>Nikolay
>
>
>
>
>
>
>
>
>
>_______________________________________________
>OvmsDev mailing list
>OvmsDev at lists.teslaclub.hk
>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>

_______________________________________________
OvmsDev mailing list
OvmsDev at lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev 


More information about the OvmsDev mailing list