summaryrefslogtreecommitdiffstats
path: root/vehicle-signals/VehicleSignalsConfig.cpp
AgeCommit message (Collapse)AuthorFilesLines
2023-08-24Rework vehicle signals support to use KUKSA.val databrokerScott Murray1-0/+104
Rework the VehicleSignals class and its use in the Navigation and Hvac classes to switch from using the original KUKSA.val server via WebSockets to the KUKSA.val databroker's gRPC "VAL" API. Notable changes: - The VehicleSignals API has changed a bit with respect to setting signals, callers now need to pass the new value as the type that matches the signal as opposed to always passing a string, and optionally indicate if an actuator's target or value is being set. Subscribe operations now also allow subscribing for either actuator targets or values. - It is possible that the values returned by get and subscribe operations will be changed to using QVariant instead of QStrings in a future follow up, but that has not been done in these changes. - The connected signal from VehicleSignals still has roughly the same meaning, but the authorize function and authorized signals are to some degree redundant now. They have been kept for compatibility, but may be removed in a follow up set of changes. - The section header in the .ini files expected by the VehicleSignalsConfig class has been changed from "vis-client" to "kuksa-client" since the databroker is not a VIS server, and to some degree forcing an update on the part of clients is useful since their authorization tokens also need to change. - The client key and certificate support has been removed from the VehicleSignalsConfig class, as they are no longer used in either the server or databroker as of KUKSA.val 0.4.0. A new optional parameter, "tls-server-name", has been added to work with the new TLS support behavior. It can be used to override the expected host name for connecting to a non-local databroker instance. - The Navigation constructor now takes an additional parameter to indicate whether the instance acts as a router or a client. The underlying need for this stems from an application acting as a router needing to subscribe to the destination setting actuator targets. Bug-AGL: SPEC-4762 Signed-off-by: Scott Murray <scott.murray@konsulko.com> Change-Id: I253480ae2abf068dc6e41a495454960ed5c0feaf