Values not updating

[volatilflerovium]

Hi,

I tried to use kuksa-mock-provider agains databroker running on agl image on qemu: I was expecting to see the value 85.71 in the dashboard of the agl-demo... but it is not the case... Any suggestions?

[lukasmittag]

Please give more info on your setup and the agl demo. Where is databroker running. Where agl demo? Where mock provider?

[volatilflerovium]

Hi lukasmittag,

Thanks for replying.

The agl demo image I am using is pike. The agl and the kuksa-mock-provider are running on the same laptop. The agl is using a bridged network.

For agl:

qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:35:02 -netdev bridge,br=br0,id=net0 \
    -drive file=agl-demo-platform-crosssdk-qemux86-64-20240308022242.rootfs.ext4,if=virtio,format=raw -usb \
    -usbdevice tablet -device virtio-rng-pci -vga virtio -machine q35 -cpu kvm64 \
    -cpu qemu64,+ssse3,+sse4.1,+sse4.2,+popcnt -enable-kvm \
    -m 2048 -serial mon:vc -serial mon:stdio -serial null -kernel bzImage \
    -append 'root=/dev/vda rw console=tty0 mem=2048M ip=dhcp oprofile.timer=1 console=ttyS0,115200n8 verbose fstab=no'

For databroker running in the agl:

RUST_LOG="debug" databroker --vss /usr/share/kuksa-val/vss_release_3.0.json  --address 0.0.0.0 --insecure

As it shows the picture, the agl is able to receive the request from the kuksa-mock-provider (so communication is not an issue).

Now, the agl pike image has also kuksa-val-server. If I run the kuksa-val-server, and send data using agl-demo-control-panel I can see the speed gadget in the dashboard been updating as data in sent . The settings for kuksa-val-server are:

kuksa-val-server --address 0.0.0.0 --vss /usr/share/kuksa-val/vss_release_3.0.json --insecure --log-level ALL

As kuksa-val-server and databroker are running at the same time by the agl, the speed values set using kuksa-val-server are not registered by the databroker; which means that there are two instances of the VSS tree, one initialized by kuksa-val-server and the other by databroker. However, only one is used to pass data to the dashboard kuksa-val-server is deprecated, and the new version of agl only has databroker with the same issue...

From the log of kuksa-val-server:

VERBOSE: SubscribeThread: Started Subscription Thread!
VERBOSE: VssDatabase::VssDatabase : VSS tree initialized using JSON file = /usr/share/kuksa-val/vss_release_3.0.json

which I do not see anything similar when databroker starts

root@qemux86-64:~# RUST_LOG="debug" databroker --vss /usr/share/kuksa-val/vss_release_3.0.json  --address 0.0.0.0 --insecure
2024-08-30T08:59:04.629388Z  INFO databroker: Init logging from RUST_LOG
2024-08-30T08:59:04.629452Z  INFO databroker: Starting Kuksa Databroker ce8b6526492e69a3c4217a5651be00cc5109fbad
2024-08-30T08:59:04.629484Z  INFO databroker: Populating metadata from file '/usr/share/kuksa-val/vss_release_3.0.json'
2024-08-30T08:59:04.816300Z DEBUG databroker: Adding VSS datapoint type Vehicle.ADAS.ABS.IsEnabled
...
2024-08-30T08:59:17.071060Z  INFO databroker::broker: Starting housekeeping task
2024-08-30T08:59:17.071133Z  WARN databroker::grpc::server: TLS is not enabled
2024-08-30T08:59:17.071143Z  WARN databroker::grpc::server: Authorization is not enabled
2024-08-30T08:59:17.071213Z  INFO databroker::grpc::server: Listening on 0.0.0.0:55555

Wonder if one has to start those (SubscribeThread and VssDatabase::VssDatabase) manually when using databroker...

[lukasmittag]

Hey @volatilflerovium,

thanks for providing me with more information. I can not help you asap. We might need to check with AGL members how the demo is connected (if it is updated to use databroker). We have a bi-weekly meetup were one of the AGL developers always joins. The next on is in two weeks thursday. We might could clarify it then. Else I will post this discussion into a chat for the kuksa-val-community located here https://app.gitter.im/#/room/#kuksa-val_community:gitter.im . Maybe Scott is answering there. Let's see.

Sorry for the inconvenience and have a nice weekend.

[volatilflerovium]

Hi @lukasmittag,

Thank you for reply. Hopefully the guys at the kuksa-val-community or the AGL developers can put light to the issue...

Cheers

[argerus]

It does sound like the UI application is a using the custom VISS (websocket) protocol implemented by the legacy kuksa-val-server.

By default, databroker only supports a new GRPC based protocol. I don't know if this is something supported by the AGL UI as well?

Databroker also supports VISS - or more specifically - standards compliant VISSv2. This differs from the custom VISS protocol used by kuksa-val-server, which was not standards compliant.

Furthermore, VISSv2 in databroker will only be available if it is compiled with that feature enabled (I don't know whether that is the case for AGL?), and even then it is not enabled unless the flag --enable-viss is passed at startup.

[volatilflerovium]

Hi @argerus,

The downloadable image of AGL Quillback (17.0) has databroker with VISSv2 support. However, correct me if I am wrong, VISSv2 is not for setting values ("I"nformation). Let's do some tests. Start databroker:

RUST_LOG="debug" databroker --vss /usr/share/vss/vss_rel_4.0-agl.json --enable-viss --viss-port 8090 --viss-address 0.0.0.0 --address 0.0.0.0 --disable-authorization --insecure
2024-09-02T12:54:18.976203Z  INFO databroker: Init logging from RUST_LOG
2024-09-02T12:54:18.976967Z  INFO databroker: Starting Kuksa Databroker afaf54200ab8bf2126c9ad4a3dec746828cfecb1
2024-09-02T12:54:18.977974Z DEBUG databroker: Adding attribute Kuksa.Databroker.GitVersion
2024-09-02T12:54:18.979130Z DEBUG databroker::broker: setting id 0 to EntryUpdate { path: None, datapoint: Some(Datapoint { ts: SystemTime { tv_sec: 1725281658, tv_nsec: 979128448 }, value: String("N/A") }), actuator_target: None, entry_type: None, data_type: None, description: None, allowed: None }
2024-09-02T12:54:18.981371Z DEBUG databroker: Adding attribute Kuksa.Databroker.CargoVersion
2024-09-02T12:54:18.982220Z DEBUG databroker::broker: setting id 1 to EntryUpdate { path: None, datapoint: Some(Datapoint { ts: SystemTime { tv_sec: 1725281658, tv_nsec: 982219675 }, value: String("0.4.1") }), actuator_target: None, entry_type: None, data_type: None, description: None, allowed: None }
2024-09-02T12:54:18.984354Z DEBUG databroker: Adding attribute Kuksa.Databroker.CommitSha
2024-09-02T12:54:18.985182Z DEBUG databroker::broker: setting id 2 to EntryUpdate { path: None, datapoint: Some(Datapoint { ts: SystemTime { tv_sec: 1725281658, tv_nsec: 985181283 }, value: String("afaf54200ab8bf2126c9ad4a3dec746828cfecb1") }), actuator_target: None, entry_type: None, data_type: None, description: None, allowed: None }
2024-09-02T12:54:18.987540Z  INFO databroker: Populating metadata from file '/usr/share/vss/vss_rel_4.0-agl.json'
2024-09-02T12:54:19.319180Z DEBUG databroker: Adding VSS datapoint type Vehicle.ADAS.ABS.IsEnabled
... (more stuff)
Adding VSS datapoint type Vehicle.Width
2024-09-02T13:14:15.592630Z DEBUG databroker::broker: setting id 936 to EntryUpdate { path: None, datapoint: Some(Datapoint { ts: SystemTime { tv_sec: 1725282855, tv_nsec: 592629517 }, value: Uint32(0) }), actuator_target: None, entry_type: None, data_type: None, description: None, allowed: None }
2024-09-02T13:14:15.596464Z  INFO databroker::viss::server: VISSv2 (websocket) service listening on 0.0.0.0:8090
2024-09-02T13:14:15.598173Z  INFO databroker::broker: Starting housekeeping task
2024-09-02T13:14:15.599580Z  INFO databroker::grpc::server: Listening on 0.0.0.0:55555
2024-09-02T13:14:15.600901Z  INFO databroker::grpc::server: TLS is not enabled
2024-09-02T13:14:15.602190Z  INFO databroker::grpc::server: Authorization is not enabled.

Sending a request to update Vehicle.Speed via websocket. Server log:

2024-09-02T13:15:27.955339Z DEBUG databroker::viss::server: Received request: {"action": "set", "path": "Vehicle.Speed", "attribute": "value", "value": "21", "requestId": "59ea411a-c993-4588-8b7b-098f9f02ad29"}
2024-09-02T13:15:28.011580Z DEBUG databroker::viss::server: Sending response: {"action":"set","requestId":"59ea411a-c993-4588-8b7b-098f9f02ad29","error":{"number":401,"reason":"read_only","message":"The desired signal cannot be set since it is a read only signal."},"ts":"2024-09-02T13:15:28.011Z"}

which seems expected (since VISSv2 is only for requesting information, assuming that is true).

Now, using gPRC protocol: sending request to set Vehicle.Speed to 38.0. Log:

2024-09-02T13:22:08.605955Z DEBUG databroker::grpc::kuksa_val_v1::val: request=Request { metadata: MetadataMap { headers: {"content-type": "application/grpc", "te": "trailers", "grpc-accept-encoding": "identity, deflate, gzip", "user-agent": "grpc-python-asyncio/1.66.0 grpc-c/43.0.0 (linux; chttp2)", "authorization": "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJrdWtzYS52YWwiLCJpc3MiOiJFY2xpcHNlIEtVS1NBIERldiIsImFkbWluIjp0cnVlLCJpYXQiOjE1MTYyMzkwMjIsImV4cCI6MTc2NzIyNTU5OSwia3Vrc2EtdnNzIjp7IioiOiJydyJ9fQ.QQcVR0RuRJIoasPXYsMGZhdvhLjUalk4GcRaxhh3-0_j3CtVSZ0lTbv_Z3As5BfIYzaMlwUzFGvCVOq2MXVjRK81XOAZ6wIsyKOxva16zjbZryr2V_m3yZ4twI3CPEzJch11_qnhInirHltej-tGg6ySfLaTYeAkw4xYGwENMBBhN5t9odANpScZP_xx5bNfwdW1so6FkV1WhpKlCywoxk_vYZxo187d89bbiu-xOZUa5D-ycFkd1-1rjPXLGE_g5bc4jcQBvNBc-5FDbvt4aJlTQqjpdeppxhxn_gjkPGIAacYDI7szOLC-WYajTStbksUju1iQCyli11kPx0E66me_ZVwOX07f1lRF6D2brWm1LcMAHM3bQUK0LuyVwWPxld64uSAEsvSKsRyJERc7nZUgLf7COnUrrkxgIUNjukbdT2JVN_I-3l3b4YXg6JVD7Y5g0QYBKgXEFpZrDbBVhzo7PXPAhJD6-c3DcUQyRZExbrnFV56RwWuExphw8lYnbMvxPWImiVmB9nRVgFKD0TYaw1sidPSSlZt8Uw34VZzHWIZQAQY0BMjR33fefg42XQ1YzIwPmDx4GYXLl7HNIIVbsRsibKaJnf49mz2qnLC1K272zXSPljO11Ke1MNnsnKyUH7mcwEs9nhTsnMgEOx_TyMLRYo-VEHBDLuEOiBo"} }, message: SetRequest { updates: [EntryUpdate { entry: Some(DataEntry { path: "Vehicle.Speed", value: Some(Datapoint { timestamp: None, value: Some(Float(38.0)) }), actuator_target: None, metadata: None }), fields: [Value] }] }, extensions: Extensions }
2024-09-02T13:22:08.618107Z DEBUG databroker::grpc::kuksa_val_v1::val: permissions=Permissions { expires_at: None, read: Everything, actuate: Everything, provide: Everything, create: Everything }
2024-09-02T13:22:08.620128Z DEBUG databroker::grpc::kuksa_val_v1::val: Settings fields: {Value}
2024-09-02T13:22:08.621215Z DEBUG databroker::broker: setting id 906 to EntryUpdate { path: None, datapoint: Some(Datapoint { ts: SystemTime { tv_sec: 1725283328, tv_nsec: 621211637 }, value: Float(38.0) }), actuator_target: None, entry_type: None, data_type: None, description: None, allowed: None }

Using databroker-cli to verified data was successfully set:

kuksa.val.v1 > get Vehicle.Speed
[get]  OK  
Vehicle.Speed: 38.00 
kuksa.val.v1 > 

but still the GUI of the AGL (17.0) still no changing. It seems as the GUI has not been integrated to the databroker infrastructure?....

[argerus]

Sending a request to update Vehicle.Speed via websocket. Server log:

2024-09-02T13:15:27.955339Z DEBUG databroker::viss::server: Received request: {"action": "set", "path": "Vehicle.Speed", "attribute": "value", "value": "21", "requestId": "59ea411a-c993-4588-8b7b-098f9f02ad29"}
2024-09-02T13:15:28.011580Z DEBUG databroker::viss::server: Sending response: {"action":"set","requestId":"59ea411a-c993-4588-8b7b-098f9f02ad29","error":{"number":401,"reason":"read_only","message":"The desired signal cannot be set since it is a read only signal."},"ts":"2024-09-02T13:15:28.011Z"}

which seems expected (since VISSv2 is only for requesting information, assuming that is true).

It is correct that you cannot use VISSv2 to provide the current value of signal like Vehicle.Speed for example. But you can use it to set (actuate) actuators, so it's not strictly a one way protocol. Hence, providers do need need to use one of the grpc protocol(s) of databroker in order to provide it with current values. The mock-provider is one example of such a provider.

but still the GUI of the AGL (17.0) still no changing. It seems as the GUI has not been integrated to the databroker infrastructure?....

I don't know the functionality of this GUI, but VISSv2 should be sufficient if it's only used to display values and / or actuate actuators. If that's the case, maybe it needs some small modification to support standards compliant VISSv2? But that's just a guess as I am not familiar with it.

[SebastianSchildt]

Hi, I am also not so deep into AGL details, but the guy you shown above seems to be the "classic" (QT?) based AGL GUI, and I am not sure this is connected to VSS. The version I have seen where based on the new Flutter interface. Maybe @g-scott-murray can shed some light onto which versions on AGL support what databroker features.

At least Pike did not include databroker yet, but the predecessor "kuksa.val server", which is using a slightly different VISS dialect as explained by @argerus .

I the meanwhile slides 16ff here https://fosdem.org/2024/events/attachments/fosdem-2024-2842-vehicle-abstraction-in-automotive-grade-linux-with-eclipse-kuksa/slides/22324/Vehicle_Abstraction_in_AGL_with_Eclipse_KUKSA_1MvE4AB.pdf might also help

[g-scott-murray]

The Qt demo in AGL supports VIS with the kuksa.val server in the Pike release, and the gRPC interface against the databroker in Quillback and newer. I would advise not running the databroker by hand in the agl-ivi-demo-* images without doing some investigation into how it is already being run in the images by default, as the applications expect to use TLS and authorization tokens when connecting to the databroker instance. With the stock qemux86-64 IVI demo images for AGL Quillback or Ricefish, you should be able to test whether the databroker -> app connection is working by booting up, logging in on the serial or SSH, and running "simple-can-simulator.py can0", which will loop sending vehicle and engine speed messages to the virtual CAN interface and thus into the CAN provider -> databroker -> dashboard.

With respect to VIS support, I do build the databroker in the in demo images with the VIS support feature enabled, but to my knowledge it has never been tested. The one potential AGL demo use case never materialized, and no AGL member has so far asked us to support VIS.

[volatilflerovium]

iHi @g-scott-murray

Thank you very much for replying. I can confirm it works as you indicate (just a correction in the command):

qemux86-64 login: root
root@qemux86-64:~# python3 /usr/sbin/simple_can_simulator.py can0
Using can0