Guys,

if you all agree on merging both ways to connect now, a single vehicle implementation with some kind of connection configuration is again the right option.

Copying the code from the separate vehicles to build a third one will not be acceptable as the general solution. That would become hell for code maintenance and user support.

So you first need to agree on working together on this now. You split up because there were some hard to resolve issues in your earlier collaboration.

I understand there are some features and metrics available on both buses, but most are available either only on the OBD bus or only on the KCAN bus.

Users should be able to decide if they connect either or both of the buses, unless you find a simple option to provide connectivity to both from a convenient mounting place for the module.

So for stuff available on both buses the code will need to decide which bus to use at a given time/state, depending on the connections available and the data quality available on each of the buses.

That means you need to agree on which bus to prioritize if both are available, you need to collaborate on this with the goal of providing the best solution to the user, regardless of your personal preferences.

It seems sharkcow is the perfect choice as a moderator on this. If you can agree on him/her for this role, you should contribute your changes to sharkcow's repository first. Sharkcow would take care to integrate your submissions and then forward the results to the OVMS repository for inclusion.


On a first glance into the code I think you should reorganize the modules to separate the bus handling from the general logic / dispatching layer and factor out common utilities.

As a side note: I can see there are now two bool configs reserved for this ("con_obd" & "con_t26"), both not actually used yet. This should become a combined config instance, as there are only three valid options.

But I won't look further now. If you decide to work together now, I'm sure there will be a much better integration in no time.

Regards,
Michael


Am 09.10.20 um 19:19 schrieb Chris van der Meijden:
Hey sharkcow,

great to see that you are pushing the VW e-Up to the next level :-)

I completely agree that merging the T26A and OBD code is finally the way to go. 

For now we still need a "simple" way to connect the hardware to the comfort can and the OBD port simultanously.

I took a quick look at your index.rst and would like to suggest to document how you connect your OVMS to T26A and OBD. Perhaps with a picture or two?

Also nice to read you started with a "Schneider". My starting point was a "Sinclair ZX81". Z80 assembler rulez :-)

Greetinx

Chris
(devmarxx)




Am Freitag, den 09.10.2020, 18:50 +0200 schrieb sharkcow:
Dear developers,

I have just submitted a pull request for (yet another :) module for the
VW e-Up. It's nothing really new as I simply combined the two existing
VW e-Up modules for access via Comfort CAN and OBD2 into one module. For
now it seems like I'm the only one with both connections, but in the
long run I think this is the way to go, because write functions like AC
are working on C-CAN, while OBD offers a wealth of metrics (when the car
is on or charging). I have started adding additional metrics on OBD and
will continue mainly on this route.

A few words about myself: I'm an electrical engineer who has always been
fascinated by programming hardware functions (started using the
extension port of a Schneider CPC computer, which only Germans will
know... a competitor to the Commodore C64 at the time). I have been
dabbling in microcontrollers (mostly Atmel) and Raspberry Pi for the
last few years. Since I never really learned modern programming
languages, I go by google-paste-and-error :) So please forgive if you
see horrible code; I promise I'm always willing to learn!

In 2019, I bought a (generation 1) VW e-Up and ever since tried to
figure out as much about the OBD metrics as I can. The breakthrough came
beginning of this year, when I managed to sniff about 1100 OBD codes by
using a commercial OBD adaptor and a Y-cable with a PC to log the codes.
At about the same time, devmarxx showed up and brought me to OVMS.

Concerning OVMS, I can only thank you guys for a really great hard- and
software platform! This is the perfect playing ground for someone like
me. Currently, I just keep discovering how matured this system already
is... I try to learn from existing code and can't see any limits to the
possibilities :)

So, I would be very happy if VWEUP.ALL can be included and maybe one or
the other of you can give me helpful hints on how to do things the right
way :)

Have a great (hacking) weekend!

sharkcow
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev


_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev


-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26