Gen4 Cluster replacement, OBD2

Hope there is someone with more insight into this that can help me or guide me.
I was looking for a digital cluster but had not luck the closest what Carobotor but have not made one yet for the Jimny(already contacted them as well). So I decided to start the feat of making my own little digital cluster, I want to show some basic things additional from the things being displayed already like gearing position, tyre slip, etc. I know these info is on the computer box because I was able to plugin to the OBD2 port with a scanner and found the info. My first task is to try and get connection to the OBD2 bus to "sniff" for for all the data and then use a SBC(something like Raspberry pi Industrial compute module) with QT to create the screen. So I have three questions with this project I am embarking on:
1. From what I understant if you unplug the cluster most cars SRS warning light would trigger and stay on even if you plug in the cluster again. The only way around this is to sniff the bus to see what com's happens to and from the cluster and simulate the same, Any suggestions or corrections on this?
2. To my knowledge (again comments/corrections are welcome) the ODO reading is stored on mutliple computers on the Jimny and if one of the computers (ex cluster) is unpluged and repluged the system would take the highest reading between the computers and sync all to that value.
3. Anyone with success connecting to the CAN bus via Raspberry Pi Pico or Arduino or equivalent with some examples to speed things up a bit. I have came right with a bluetooth bought dongle but not getting joy with a MCP2515 on CAN. I know it has CAN and K-Line because of the bluetooth adaptor I used.

Apart from the technical problems you are going to encounter I think there might be legal/regulatory issues to overcome, but ot sure where you are based. Replacing the instrument cluster with an aftermarket unit that has been tested is one thing, but building one on a RPi (or similar) and then getting it approved is something else, especially when you have to reverse engineer (sniff) the messages just to make it work.

Would you not consider a secondary display, perhaps Android running something like Torque Pro?

Point 2 there are different OBD devices in a car, e.g. engine management, drive train, safety systems but as far as I know they don’t share information with each other, the data is too different and specific to the function.

There will be an exchange with the instrument cluster but you will probably find that the comms standard is not published and it might be a different interface, e.g. not on the OBD socket that you plugged your dongle in to.

There is a program called SZ Viewer, the guy who writes it probably knows as much as anyone, but don’t think he is on here, might be worth a search and send a message?

The legal side and registering is not really a problem for me. The reliability of a new untested product without the same level of robust as the OEM is a bit concerning for me. The biggest issue facing to this point is the lack of info available so I have considered the SZ Viewer with wireless dongle and a separate screen mounted independent of the existing system.
Seems like my best bet might be to speak to the developer of SZ Viewer to see how I can load than on a embedded linux device. Then have some form of integration on the SBC between my custom screen and the SZ Viewer to get the data.