|
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
|
Scott Murray