OBDII rewrite

[icecube45]

Stemming from discussion in #18, looks like a rewrite of the OBD implementation is due.

A couple of points I want to bring up as we start discussion around a rewrite:

1: What types of adapters are we trying to support? Off the top of my head, I'm thinking anything SocketCAN compatible, as well as serial/bt versions of the elm327.

2: What is the goal of OBD implementation? The guages tab already exists, but with my recent foray into more in depth car hacking, I'd love to be able to integrate CAN messages as "actions" in intelligent auto, such as using the status of CAN message to toggle day/night mode in android auto. Something that might be easy to accomplish with #25 being implemented.

[icecube45]

(the edits are what happen when I accidentally press enter on a blank issue)

[rsjudka]

I haven't forgotten about this feature! Just been pushing it off because I anticipate quite some effort for all this :p

1: What types of adapters are we trying to support?

I agree with you here. This will give users the flexibility to either have a simpler data UI (elm327) or more advanced and custom data UIs (will need to come up with some sort of module support here since cars will have all kinds of data protocols).

I'm not even sure if there's any other interfaces that would need to be implemented.

2: What is the goal of OBD implementation?

I kinda alluded to this above, but I think the end goal would be to have the gauge tab become more of a "car interface" tab. Based on user configuration, it would either be for basic OBD data (will be read-only) or more advanced CAN data (where this one can actually end up being read/write - for example controlling fan speed).

Alot of ia super modular so making custom UI elements (while keeping it in sync with the theme and what not) shouldn't be that hard to do given a decent understanding of C++ and Qt. I'd also be willing to implement UIs upon request and start building up a "library" of sorts where people can just pick from a list of what "car interface" tab they want to use.

I'd love to be able to integrate CAN messages as "actions" in intelligent auto, such as using the status of CAN message to toggle day/night mode in android auto. Something that might be easy to accomplish with #25 being implemented.

So depending on what "actions" you're looking for, you should already have the ability to integrate some controls of ia. Really, you can use anything accessible within the config and theme classes. Let me know if you feel that's too limiting, I'm planning on implementing some sort of "manager" that should give you even greater control across the app.

[WardBenjamin]

For what it's worth, my company will soon be releasing a SocketCAN-compatible device (alternate firmware will also let it enumerate as a native CAN interface in Linux). I can talk to my co-founder about supplying one discounted or free for @rsjudka if you're in need of something like that for testing.

[rsjudka]

@WardBenjamin that would be great, would definitely help in developing this feature

[stefan-sherwood]

I have implemented analog gauges in a separate car project of mine and would be happy to contribute that code to this effort.

[stefan-sherwood]

One feature that I think would be welcome would be to be able to view engine codes (with descriptions) and clear them.

[rsjudka]

yeah i planned for showing engine codes but that ended up being a bit harder to read than just some values so i figured i would push that off for a later date

clearing them would obviously require writing to the car which and I wasn't sure how comfortable i was doing that lol

[stefan-sherwood]

There's pretty much no way to mess up the car with a bad write operation since (I believe) the only write operation is clearing codes. The protocol is so limited that it's safe. Regardless I'll be happy to take a look at it.