Nikolay,

congratulations :-)

Mark already said it: look for "car_" variables, these will transport common properties. "can_" variables are currently vehicle locals, see my previous suggestion on renaming these to reflect their vehicle specific nature. Only common properties and commands will currently be supported by the Apps -- adding vehicle specific code and UIs to the Apps is the next main todo.

Note there are some variables already in the Twizy code, that could/should become common. Generally, the more vehicles turn up to need some value, the more likely it will become common.

Without App support, you still can do vehicle specific data collection and analysis by sending "H" MSGs to the server. "H" msg types are basically free-form, they can transport all vehicle specific data to the server and to any client. There are multiple examples in the Twizy code for that, and I've added user guides and a perl utility "cmd.pl" to query them from the server last night, take a look. The output is simple CSV format, so you can load that into any spreadsheet or database.

For text messages, note there is already an App msg defined ("P" = push message), the only current caveat is, the Apps (at least the Android one) will only process these if backgrounded. That certainly can be fixed soon, so push messages will become a fully functional SMS alternative.

Regards,
Michael

Am 06.01.2013 15:04, schrieb Nikolay Shishkov:

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@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26