From c275f7cef1446315aff009c04b81e25a2ac9f82c Mon Sep 17 00:00:00 2001 From: UlfBj Date: Tue, 12 Nov 2024 11:40:08 +0000 Subject: [PATCH] Auto-deploy docs built from commit bad09c31284d257ab2c6c458412e5cd086e54217 --- 404.html | 16 +- build-system/hello-world/index.html | 1091 ++++++++++++++++++++++ build-system/hello-world/index.xml | 10 + build-system/index.html | 118 ++- categories/index.html | 104 ++- client/index.html | 106 ++- datastore/apache-iotdb/index.html | 104 ++- datastore/index.html | 104 ++- datastore/memcached/index.html | 104 ++- datastore/redis/index.html | 104 ++- datastore/sqlite/index.html | 104 ++- docker-step-by-step/index.html | 104 ++- feeder/index.html | 104 ++- index.html | 104 ++- index.json | 9 +- peripheral-components/index.html | 104 ++- pocs/index.html | 104 ++- pocs/poc1/index.html | 104 ++- pocs/poc2/index.html | 104 ++- server/access-control-servers/index.html | 104 ++- server/index.html | 104 ++- sitemap.xml | 2 + tags/index.html | 104 ++- tools/index.html | 104 ++- 24 files changed, 2648 insertions(+), 472 deletions(-) create mode 100644 build-system/hello-world/index.html create mode 100644 build-system/hello-world/index.xml diff --git a/404.html b/404.html index 361d0f75..71eecde8 100644 --- a/404.html +++ b/404.html @@ -9,15 +9,15 @@ 404 Page not found - - - - - - - + + + + + + + - + + + + + + + + + +
+
+
+ +
+
+ + + + + + + + + + +
+
+ +
+
+ + +
+
+ +
+ +
+ +
+ +

+ + VISSR Hello World example +

+ + + + + + +

Two Hello Worl alternatives are available:

+ +

Native build based Hello World example

+

Building the server and many other software components require that the Golang build system is installed on the computer, +please see here how to get that done. +The next step is to clone the VISSR repo.

+
$ git clone https://github.com/COVESA/vissr.git
+

This is followed going to the directory where the main server code is located, and build the server.

+
$ cd vissr/server/vissv2server/
+$ go build
+

This could be followed by directly starting a client to issue requests to the server, +but the server would then tr to read data from an empty data store, so all responses would say ‘data-not-available’. +To be able to get some real data back we will therefore start a feeder that will write simulated data into the data store.

+

To do this, open a new terminal window, go to the feederv3 directory, and build the feeder.

+
$ cd vissr/feeder/feeder-template/feederv3/
+$ go build
+

Now we can start the server and the feeder in respective terminal window. +The server will connect to the feeder, so to avoid server logs complaining it cannot find the feeder it is preferred to start the feeder first.

+
$ ./feederv3
+$ ./vissv2server
+

Both the server and the feeder will by default be configured to use Redis for the data store. +This requires that Redis has been installed on the computer, how to do this can be read here. +Other data stores can be configured, more info can be found here.

+

Now it is time to start a client, there are many clients to be found in the client directory and subdirectories. +We will here use the Javascript based client that connects via the Websocket protocol. +But first we need to find out the IP address of the computer as the client connects to the server over a socket based on this address. +How to do that can e. g. be found here, on Ubuntu the command

+
$ ifconfig
+

can be used. You will then have to search i a lot of information for an address that likely starts with ‘192.168’ followed by two more segments. +Please copy this and use the file browser on the computer to go to the client/client-1.0/Javascript directory. +There you click on the file ‘wsclient_uncompressed.html’, which leads to that it starts up in the browser. +You will there see a field whch says ‘host ip’, please paste the IP address in there and click on the button to the right that says ‘Server IP’. +The client will then print ‘Status: Connected’ in the area below if it succeeds to connect. +Now we can start to issue client requests to the server by pasting or writing them into the field where it says ‘JSON payload, +followed by clicking on the button ‘Send’. +Try with the command

+
{"action":"get","path":"Vehicle.Cabin.Door.Row1.DriverSide.IsOpen","requestId":"232"}
+

which should return a response like the below.

+
Server: {"action":"get","requestId":"232","ts":"2024-11-12T11:26:44.546855082Z", "data":{"path":"Vehicle.Cabin.Door.Row1.DriverSide.IsOpen", "dp":{"value":"Data-not-found", "ts":"2024-11-12T11:26:44.548180993Z"}}}
+

The value is set to ‘Data-not-found’ which is due to that the federv3 is not instructed to create simulated values for this signal. +At startup the feederv3 reads the file VssVehicle.cvt which has been created by the Domain Conversion Tool. +This file contains the insructions for how signals are mapped and scaled when they traverse between the ‘vehicle domain’ and the ‘VSS domain’, +but the feederv3 also uses this information to select which signals to create simulated values for. +The cvt-file that comes with the repo only contains the five signals that can be read in the tools/DomainConversionTool/Map-VSSv0.1-CANv0.1.yaml file. +So if we want to get a response with a simulated value a client request to any of these signals must be issued, e. g.:

+
{"action":"get","path":"Vehicle.Speed","requestId":"232"}
+

Please issue this request, se the response, wait about 30 secs and issue it again. +The values returned in the two responses should differ as the feeder randomly generates new values. If not wait another 30 secs and issue it again. +This could more easily be seen if a time-based subscribe request is issued:

+
{"action":"subscribe","path":"Vehicle.Speed","filter":{"variant":"timebased","parameter":{"period":"10000"}},"requestId":"246"}
+

The server will issue event messages every ten seconds, and it can after a number of events has been received that the value is randomly changed. +To unsubscribe, issue the request:

+
{"action":"unsubscribe","subscriptionId":"1","requestId":"240"}
+

The file client/client-1.0/Javascript/appclient_commands.txt contains examples of different requests that can be used, either as is or modified.

+

The feederv3 can at startup be configured to read simulated tripdata from files like ’tripdata.json’ or ‘speed-sawtooth.json’, +the latter suitable if the curve log filter subscription is to be tested, maybe with a request like this:

+
{"action":"subscribe","path":"Vehicle.Speed","filter":{"variant":"curvelog","parameter":{"maxerr":"2","bufsize":"18"}},"requestId":"275"}
+

More simulation info can be found here. +These files can easily be modified and extended with data for more signals and longer trips.

+

Docker based Hello World example

+

This is not ready yet…

+ + + + + +
+ +
+ + +
+ + +
+ + + +
+ +
+
+
+ + + + + + + + + + + + + + + + + + + + diff --git a/build-system/hello-world/index.xml b/build-system/hello-world/index.xml new file mode 100644 index 00000000..3084f17b --- /dev/null +++ b/build-system/hello-world/index.xml @@ -0,0 +1,10 @@ + + + + VISSR Hello World example on COVESA VISSv2 Reference Implementation (vissr) + https://covesa.github.io/vissr/build-system/hello-world/ + Recent content in VISSR Hello World example on COVESA VISSv2 Reference Implementation (vissr) + Hugo -- gohugo.io + en-us + + diff --git a/build-system/index.html b/build-system/index.html index 6b84837d..94b08a8c 100644 --- a/build-system/index.html +++ b/build-system/index.html @@ -12,21 +12,21 @@ VISSR Build System :: COVESA VISSv2 Reference Implementation (vissr) - - - - - - - - - + + + + + + + + + - + - +