creating a can id list !?

[medo]

It would be very helpful if all the canbus IDs were listed and added to the wiki to have an overview of what is already used (inverter, VCU, OBC,Foccci) and what is not. This way you can also develop new applications without getting into conflict with the can IDs. Anyone can then find out the vehicle-specific can IDs during a log trip.

[Zieg]

I like it. Should be easy enough to pull together the ids used by various oem equipment, maybe list the IDs in decimal and hex so it's easy to search. I don't use a proper VCU so no pre-mapped IDs for any of the open source devices on my network. I've had to just check the oem components and verify against a sniffer log, then everything I add is pretty much arbitrary.

The only conflict I've had (that I know of) is Foccci's default node ID of 22 didn't work with my Thunderstruck MCU/display screen on the bus. Changed it to 11 and all was well.

[johu]

This has been requested many times. Thing is there is only one hard coded CAN message in the OI "product line" and that is the control message to the inverter described here: https://openinverter.org/wiki/CAN_communication

Besides that all CAN communication is programmed by the user as needed in their system. E.g. Foccci by default sends and receives no CAN message at all.

[Mitchy]

Likely the request originates from a Zombieverter standpoint.
There's definite merit in generating a can bus address matrix of compatible and non-compatible configurations for the different OEM devices and addresses spoofed.

Right now I look into the codebase and manually write down the addresses used for whatever configuration I use.

But this does not account for those devices that also read some addresses that aren't spoofed, such as a vehicle can network, there's quite a few addresses that are on the bus, but aren't part of the VCU code. So there's potential to have conflicts outside of the configured addresses.

[medo]

That's exactly what I'm talking about. Everyone can then read out their vehicle and compare whether they are in conflict, and can then adjust the CAN mapping accordingly.
I am currently compiling all the can bus IDs I know in order to set up my setup

[Zieg]

Will this apply to extended IDs or just the 11 bit ones? Not sure what hardware cares about what..

[johu]

Moved to Zombieverter forum

[powercontrol]

A quick braindump before coming with a more structured approach to it. ( a reply to my own message later on)
To have a maintainable list, we have to consider CAN ID as a data object, and build a database schema that we deliver and maintain in Mediawiki without a database. I have played with Semantic for Mediawiki (SMW) 8 years ago and got acceptable results.
I am also thinking that
- we need to be able to move from a wiki view to a library which developers can use, and vice-versa, otherwise we need to create and maintain the information twice.
- we need to have at least semi-automated way of entering the information.
- ideally a data-object owner would be nice to have a person of reference.

[powercontrol]

I believe we need to refer the CAN IDs to what produces and consumes them, as well as what triggers and requires them. the software is linked to a hardware component built by an entity (a person, a manufacturer, etc) - same as for the software, and potentially reversed ( which could then refer to community members - somehow the "owner" of the content).

Being able to build relations between these objects and defining for each object what attributes they have could then be displayed in a templated format, with the rest of the template available from traditional wiki content development. The aim is very much create and maintain the object relations in this approach (which can also evolve) - but independently of the wiki page content.

The use of semantic for mediawiki (SMW) allows (to a certain extent?) to create such relationship and build a knowledge graph. the object attributes can evolve with time, and that's great because we can have multiple iteration of the template and the existing pages will be adapted as well. Last, if some of the object attributes are relevant for development purpose (and this is not my field of expertise), my hope is that they can be exported to build libraries. So, in essence, the maintenance of the library content could be managed from mediawiki. this might just be a wet dream so far.

So, I started taking a practical approach thinking of how to document the hardware elements composing a Nissan Leaf stack (less battery pack), and decompose its hardware in objects, and defining in parallel an ontology for the objects with parent and child classes, attributes and relations between classes. I want to test that in mediawiki and give it a try.

question for the wiki admin: is it possible to have Semantic for Mediawiki installed on the server? If not, that's fine, I will spawn an instance and do a proof-a-concept for review. I just do not want to divert content outside of the wiki without consent.

thanks

[powercontrol]

Okay, so I have been playing with the concepts of these objects and using semantic for mediawiki (SMW) templates to be able to have dynamic queries inside templates instantiation to be able to navigate.
With that, I can now look into the specifics of CAN IDs ( I really would want to link the CAN IDs to what generates them). My original idea of transforming wiki to libraries is bad, because the developers are in lead, not the information managers. So, I considered instead taking DBC files as input and transforming them in wiki format. This makes I believe more sense.

I am testing on my local wiki instance, as I need SMW to be able to show it on the openinverter wiki. If the admins are willing to install it, I can migrate my proof of concept. If not, I will look at making it available on internet for comments/validation.

[johu]

Hi, thanks for your efforts. Forgot about replying to the SMW request, will look into it

[powercontrol]

these are the extensions I am using so far:

• SemanticBundle (comes with most of the extensions in just one composer command)
• SemanticResultFormats (is installed with SemanticBundle but must be activated with wfLoadExtension)
• PageForms 6.0.0 (5.6.3 has a bug - this needs to be installed by cloning https://github.com/wikimedia/mediawiki- ... eForms.git and replacing the content of extensions/PageForms - composer will not want to do it)
• MagicNoCache ( git clone https://gerrit.wikimedia.org/r/mediawik ... gicNoCache in the extensions folder + wfLoadExtension)
• CategoryTree (is installed by default but must be activated with wfLoadExtension)

[powercontrol]

Okay, so aside of templating the creation of page for car components, I have taken a parallel approach of reading from a DBC file to generate wiki pages, and using Dala's Leaf DBCs as my input test files. Again, the intent is to present the work of reversers as human-processable information, as well as tackling the problem of which components generates and consumes which CAN ID, and which car components can possibly have conflicts if they share the same canbus.
The DBC contains the information of which device generates the CAN message and this is how (not sure how automatic at this stage, though) one could link a CAN message to a component, itself part of car.

so far, the python script read the DBC and generates the wiki pages. To make things clear, I do not have the competence to write that myself in a reasonable amount of time, so I am leveraging chatgpt to write the code for me, then I tweak it.

An example of such wiki page for CANID 0x5BC where I manually added the categories: Nissan, BMS, Battery, CAN

To make it visually more readable, I played with defining colored cells for every byte, but for that it requires a modification on the Mediawiki:Common.css file to work, for which I do not have the rights. the content should be

Code: Select all

/* CSS placed here will be applied to all skins */
.byte-0 { background-color: #ff007f; } /* pink */
.byte-1 { background-color: #00BFFF; } /* cyan */
.byte-2 { background-color: #FFEA00; } /* yellow */
.byte-3 { background-color: #ff6f00; } /* orange */
.byte-4 { background-color: #39ff14; } /* green */
.byte-5 { background-color: #ff3d00; } /* red orange */
.byte-6 { background-color: #cddc39; } /* greenish */
.byte-7 { background-color: #ffB300; } /* light orange */

so, when applied, it should look like this

the name of the page is not easily changeable in Mediawiki, so the choice is crucial. My example is wrong already, as any other component which would define the same message name would be duplicating the name. It is also possible the same CANID from a given vendor has different content based on hardware of firmware revision. (I think I have seen that on the different CAN messages from Kia Soul vs Niro) - so page naming is not set yet, suggestions welcome. so far I am thinking of

Code: Select all

 message_ID - (Manufacturer group)

in our case

Code: Select all

 0x5BC - (Nissan Motor Group) 

In my mediawiki testbed using Semantic for Mediawiki, I have group car model (ie Nissan Leaf AZE0) as part of a bigger category (Nissan Motor Group), because cars may be sold with different names/brand depending the regions, and Nissan and Renault are sharing parts. so it is remotely possible to find nissan branded parts in an electric renault (this is pure speculation).

[powercontrol]

going back to the SMW organization. After having created manufacturing groups (and associated/connected brands)

I can then create a specific car. the car template contains a dynamic query asking which components is part of this car. Here it shows the coolant heater as I have created it. So, no need to update the car page, it will update itself.

Looking at the car heater I create it with a template and tell which car it is part of (this is how the car page knows about it) and give a picture, the details, and also which physical connector is using it

it means each physical connector is also defined - once - and then can be referred to by the different components using it. For connectors, a "mating connector" is defined as well. See example of how it could look like below

Still need to refine the model to avoid pitfalls...

[johu]

I installed the SematicBundle, this is the result:

https://openinverter.org/wiki/Special:Version

Will that do?