Updated Essentials Architecture (markdown)

Essentials-Architecture.md

@@ -7,7 +7,7 @@ Essentials Framework is a collection of C# / Simpl# Pro libraries that can be ut
 
 The table below is meant to serve as a guide to understand the basic organization of code concepts within the various libraries that make up the architecture.
 
-![Table](https://pepperdash.github.io/Essentials/arch-table.png)
+![Table](https://pepperdash.github.io/Essentials/arch-table.PNG)
 
 The diagram below shows the reference dependencies that exist between the different component libraries that make up the Essentials Framework.
 
@@ -47,11 +47,11 @@ This flat structure ensures that every device in a system exists in one place an
 
 #### Architecture drawing
 
---- DRAWING HERE!!! ---
+![Architecture overview](https://pepperdash.github.io/Essentials/arch-overview.png)
 
 #### Essentials Configurable System Lifecycle 
 
---- ANOTHER DRAWING !!!!
+![Lifecycle](https://pepperdash.github.io/Essentials/lifecycle.png)
 
 ### Activation phases additional topics and examples  (OTHER DOCS)
 
@@ -107,5 +107,42 @@ namespace PepperDash.Essentials.Core.Config
     }
 }
 ```
+_Every_ `Device` present must adhere to those five properties plus a properties object. The properties object will have it's own deserialization helpers, depending on what it's structure is.
 
+Once the ConfigReader has successfully read and deserialized the config file, then `ControlSystem.Load()` is called. This does the following in order:
 
+1. Loads Devices
+2. Loads TieLines
+3. Loads Rooms
+4. Loads LogoServer
+5. Activation sequence
+
+This ordering ensures that all devices are at least present before building tie lines and rooms.  Rooms can be built with their required devices being present.  In principle, this could break from the loosely-coupled goal we have described, but it is the most-clear way to build the system in code. The goal is still to build a room class that doesn't have functional dependencies on devices that may not be ready for use.
+
+In each device/room step, a device factory process is called. We call subsequent device factory methods in the various libraries that make up Essentials until one of them returns a functional device.  This allows us to break up the factory process into individual libraries, and not have a huge master list of types and build procedures.  Here's part of the code:
+
+```
+// Try local factory first
+var newDev = DeviceFactory.GetDevice(devConf);
+ 
+// Then associated library factories
+if (newDev == null)
+    newDev = PepperDash.Essentials.Devices.Common.DeviceFactory.GetDevice(devConf);
+if (newDev == null)
+    newDev = PepperDash.Essentials.DM.DeviceFactory.GetDevice(devConf);
+if (newDev == null)
+    newDev = PepperDash.Essentials.Devices.Displays.DisplayDeviceFactory.GetDevice(devConf);
+ 
+if (newDev != null)
+    DeviceManager.AddDevice(newDev);
+else
+    Debug.Console(0, "ERROR: Cannot load unknown device type '{0}', key '{1}'.", devConf.Type, devConf.Key);
+```
+
+In each respective factory, or device constructor, the config's properties object is either converted to a config object or read from using `JToken` methods. This builds the device which may be ready to go, or may require activation as described above.
+
+A similar process is carried out for rooms, but as of now, the room types are so few that they are all handled in the `ControlSystem.LoadRooms()` method.
+
+_This process will soon be enhanced by a plug-in mechanism that will drill into dynamically-loaded DLLs and load types from factories in those libraries. This is where custom essentials systems will grow from._
+
+After those five steps, the system will be running. That's it.