What-am-I-looking-at-here.md

@@ -16,12 +16,14 @@ Let's go over the components one by one.
 ## AAS Server
 
 The [AssetAdministrationShell Server](https://wiki.eclipse.org/BaSyx_/_Documentation_/_Components_/_AAS_Server) hosts the AAS themselves and offers endpoints for the active Submodels hosted by the individual providers explained later. It starts up empty and gets filled by the Providers on startup.  
-To start, the AAS Server needs the registry to be running. All other Components utilizing BaSyx depend on the AAS Server being available.
+To start, the AAS Server needs the registry to be running. All other Components utilizing BaSyx depend on the AAS Server being available.  
+See [here](implementation/AAS-Server-starter-walkthrough) for the implementation of the AAS server starter.
 
 ## Registry
 
 The [AAS Registry](https://wiki.eclipse.org/BaSyx_/_Documentation_/_Registry) provides means to lookup all available AAS and their submodels, together with their various endpoints and available metadata.  
-It is the first BaSyx component to boot, as all others, including the AAS Server depend on it being available.
+It is the first BaSyx component to boot, as all others, including the AAS Server depend on it being available.  
+See [here](implementation/AAS-Registry-starter-walkthrough) for the implementation of the AAS registry starter.
 
 ## Light hosts
 
@@ -30,15 +32,22 @@ Light host 0-2 by default each create and upload four AAS to the AAS Server and
 
 Why doesn't a light host host exactly one light?  
 Frankly, to have a bit more to see and because it would be quite wasteful. It also demonstrates, how one additional device can send controls to multiple assets (here, LEDs), reducing costs of integration of existing Assets into an Industrie4.0-environment.  
-Changing the amount of lights present on a light host is quite simple, too and provides an easy entry point in understanding the Demo itself. More on that in the documentation for the startup scripts [here](implementation/start_component.sh) and [here](implementation/run_demo.sh).
+Changing the amount of lights present on a light host is quite simple, too and provides an easy entry point in understanding the Demo itself. More on that in the documentation for the startup scripts [here](implementation/start_component.sh) and [here](implementation/run_demo.sh).  
+Please not the current limitations mentioned in the [wiring guide](setup/Wiring-of-the-demo).
+
+See [here](implementation/Light-host-walkthrough) for the walkthrough of the light host. See [here](implementation/Walkthrough-for-the-general-light-classes) for the documentation for the code representing the lights themselves.
 
 ## ESP32 Controller
 
-The ESP32 Controller demonstrates how to integrate components utilizing a proprietary protocol into a BaSyx environment. ESP32 #0 through #2 are controlled via a simple proprietary protocol, [explained here](Proprietary-Protocol), while the ESP32 Controller uploads their AAS and hosts the submodels doing the actual controlling. 
+The ESP32 Controller demonstrates how to integrate components utilizing a proprietary protocol into a BaSyx environment. ESP32 #0 through #2 are controlled via a simple proprietary protocol, [explained here](Proprietary-Protocol), while the ESP32 Controller uploads their AAS and hosts the submodels doing the actual controlling.  
+
+See [here](implementation/ESP32-Controller-walkthrough) for the walkthrough of the ESP32 Controller code. See [here](implementation/Walkthrough-for-the-general-light-classes#redproprietarylight) for the documentation for the code representing the lights themselves.
 
 ## ProprietaryLight0-2
 
-These are ESP32 microcontrollers, connected to single Red/green LEDs each and via WiFi to the rest of the network. They implement a proprietary protocol and are integrated into the BaSyx environment by the ESP32 Controller. The protocol is [explained here](Proprietary-Protocol).
+These are ESP32 microcontrollers, connected to single Red/green LEDs each and via WiFi to the rest of the network. They implement a proprietary protocol and are integrated into the BaSyx environment by the ESP32 Controller. The protocol is [explained here](Proprietary-Protocol).  
+
+See [here](implementation/Proprietary-Light-code-walkthrough) for the documentation of the code for the microcontroller.
 
 ## Light Controller
 
@@ -48,15 +57,22 @@ TODO
 
 The invokation happenes through the BaSyx API, directly to the exposed endpoint either on the AAS Server (which then forwards it) or to the Submodel hosted on the light controller directly.
 
+See [here](implementation/Light-Controller-walkthrough) for the implementation of the Light Controller.  
+In the [AASX-Branch](https://gitlab.hrz.tu-chemnitz.de/vws-demo/vws-spielwiese/-/tree/aasx), the Asset and AAS of the Light Controller is loaded from a supplied AASX package.
+
 ## Light Animator
 
 While one could argue the Light Controller already constitutes a Type 3 AAS, Adding another makes sure that we really have a Type 3 AAS in the Demo.  
-The light animator looks up all available light controllers (which is usually just one) and orchestrates it to cycle between different states, every time orchestrating the lights in turn.
+The light animator looks up all available light controllers (which is usually just one) and orchestrates it to cycle between different states, making it orchestrate the lights in turn.
+
+See [here](implementation/Light-Animator-walkthrough) for the implementation documentation of the Light Animator.
 
 ## Demonstration Controller
 
 The demonstration controller uses predefined calls to represent the condition of the demo kit and allows for user interaction with the Light Animator and Light Controller.
 
+See [here](implementation/Demo-Controller-walkthrough) for the implementation documentation.
+
 ## AASX Server
 
 The AASX Server hosts an [AASX Server](https://github.com/admin-shell-io/aasx-server), as provided by the [Industrial Digital Twin Association e.V.](https://idtwin.org/). More specifically the `blazor` variant. As of now the AASX Server and the BaSyx environment are incompatible. It is here, to have it as part of the Demo for future evaluation of compatibility  and eventual integration.