From 988ceb6b2302d587efb6188562d432732d9bafd9 Mon Sep 17 00:00:00 2001
From: Trevor Payne <tpayne@pepperdash.com>
Date: Tue, 5 May 2020 16:43:21 -0500
Subject: [PATCH] Updates to Links

---
 Arch-1.md                 |  2 +-
 Home.md                   |  2 +-
 SIMPL-Bridging-Updated.md | 18 +++++++++++-------
 Standalone-Use.md         |  2 +-
 4 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/Arch-1.md b/Arch-1.md
index 604dc04..4baf81c 100644
--- a/Arch-1.md
+++ b/Arch-1.md
@@ -34,4 +34,4 @@ This flat structure ensures that every device in a system exists in one place an
 
 ![Architecture overview](https://pepperdash.github.io/Essentials/arch-overview.png)
 
-Next: [Configurable lifecycle](Arch-lifecycle)
\ No newline at end of file
+Next: [Configurable lifecycle](Arch-lifecycle)
diff --git a/Home.md b/Home.md
index 065fb70..d2383cf 100644
--- a/Home.md
+++ b/Home.md
@@ -44,7 +44,7 @@ Thanks!
 
 ## Collaboration
 
-Essentials is an open-source project and we encourage collaboration on this community project. For features that may not be useful to the greater community, or for just-plain learning, we want to remind developers to try writing plugins for Essentials. More information can be found here: [Plugins](Plugins)
+Essentials is an open-source project and we encourage collaboration on this community project. For features that may not be useful to the greater community, or for just-plain learning, we want to remind developers to try writing plugins for Essentials. More information can be found here: [Plugins](Plugins-Updated)
 
 ### Open-source-collaborative workflow
 
diff --git a/SIMPL-Bridging-Updated.md b/SIMPL-Bridging-Updated.md
index 3d16b99..adb95d5 100644
--- a/SIMPL-Bridging-Updated.md
+++ b/SIMPL-Bridging-Updated.md
@@ -278,23 +278,27 @@ Example device config: <https://github.com/PepperDash/Essentials/blob/master/Pep
 
 1. It is important to realize that there are no safety checks (yet) when assigning joinStarts in bridge configurations.  If you were to put two devices on a bridge with overlapping joins, the most recently bridged join would overwrite previously bridged joins.  For now it is on the programmer to ensure there are no conflicting join maps.
 
-1. There is _no_ limit to the amount of times a device may be bridged to.  You may have the same device on multiple bridges across multiple applications without problem.  That being said, we recommend using common sense.  Accessing a single com port for VTC control via multiple bridges may not be wise...  
+2. There is _no_ limit to the amount of times a device may be bridged to.  You may have the same device on multiple bridges across multiple applications without problem.  That being said, we recommend using common sense.  Accessing a single com port for VTC control via multiple bridges may not be wise...  
 
-1. A bridge need not only bridge between applications on the same processor.  A bridge may bridge to an application on a completely separate processor; simply define the ip address in the Bridge control properties accordingly.
+3. A bridge need not only bridge between applications on the same processor.  A bridge may bridge to an application on a completely separate processor; simply define the ip address in the Bridge control properties accordingly.
 
-1. For devices included in Essentials, you will be able to find defined join maps below.  If you are building your own plugins, you will need to build the join map yourself.  It would be beneficial to review the wiki entry on the [Feedback Class](https://github.com/PepperDash/Essentials/wiki/Feedback-Classes) for this.
+4. For devices included in Essentials, you will be able to find defined join maps below.  If you are building your own plugins, you will need to build the join map yourself.  It would be beneficial to review the wiki entry on the [Feedback Class](https://github.com/PepperDash/Essentials/wiki/Feedback-Classes) for this.
 
-1. When building plugins, we highly recommend reusing JoinMaps, as this will make code more easily interchangeable.  For example; if you were to build a display plugin, we'd recommend you use/extend the existing ```DisplayControllerJoinMap```.  This way, you can swap plugins without needing any change on the Simpl Windows side.  This is extremely powerful when maintaining Simpl Windows code bases for large deployments that may utilize differing equipment per room.  If you can build a Simpl Windows program that interacts with established join maps, you can swap out the device via config without any change needed to Simpl Windows.
+5. When building plugins, we highly recommend reusing JoinMaps, as this will make code more easily interchangeable.  For example; if you were to build a display plugin, we'd recommend you use/extend the existing ```DisplayControllerJoinMap```.  This way, you can swap plugins without needing any change on the Simpl Windows side.  This is extremely powerful when maintaining Simpl Windows code bases for large deployments that may utilize differing equipment per room.  If you can build a Simpl Windows program that interacts with established join maps, you can swap out the device via config without any change needed to Simpl Windows.
 
-1. Related to item 5, you can use the same paradigm with respect to physical device communication.  If you were to have a DSP device in some rooms communicating over RS232 and some via SSH, it would be trival to swap the device from a Com port to an SSH client in the Essentials Devicee Config and update the Bridge Config to brigde to the desired communication method.  Again this would require no change on the Simpl Windows side as long as you maintain the same join Start in the Bridge Device Configuration.
+6. Related to item 5, you can use the same paradigm with respect to physical device communication.  If you were to have a DSP device in some rooms communicating over RS232 and some via SSH, it would be trival to swap the device from a Com port to an SSH client in the Essentials Devicee Config and update the Bridge Config to brigde to the desired communication method.  Again this would require no change on the Simpl Windows side as long as you maintain the same join Start in the Bridge Device Configuration.
 
 ## Common Use Cases
 
 1. There are 10 conference rooms that all operate the same, but have hardware differences that are impossible to account for in SIMPL Windows.  For example, each room might have a DM-MD8X8 chassis, but the input and output cards aren't all in the same order, or they might be different models but function the same.  You can use Essentials with a unique configuration file for each hardware configuration.  
 
-1. You have a floor of conference rooms that all share some centralized hardware like DSP, AV Routing and a shared CEN-GWEXER gateway with multiple GLS-OIR-CSM-EX-BATT occupancy sensors.  All the shared hardware can be defined in the Essentials configuration and bridged over an EISC to each program that needs access.  The same device can even be exposed to multiple programs over different EISCs.  
+2. You have a floor of conference rooms that all share some centralized hardware like DSP, AV Routing and a shared CEN-GWEXER gateway with multiple GLS-OIR-CSM-EX-BATT occupancy sensors.  All the shared hardware can be defined in the Essentials configuration and bridged over an EISC to each program that needs access.  The same device can even be exposed to multiple programs over different EISCs.  
 
-1. You have a SIMPL program that works for many room types, but because some rooms have different models of processors than others (CP3/CP3N/AV3/PRO3/DMPS3 variants), you have to maintain several versions of the program, compiled for each processor model to maintain access to features like the System Monitor slot.  You can use Essentials running in a slot on a processor to expose the System Monitor and many other features of the processor, regardless of model.  Now you only need to maintain a single SIMPL program defined for your most complex processor application (ex. PRO3)
+3. You have a SIMPL program that works for many room types, but because some rooms have different models of processors than others (CP3/CP3N/AV3/PRO3/DMPS3 variants), you have to maintain several versions of the program, compiled for each processor model to maintain access to features like the System Monitor slot.  You can use Essentials running in a slot on a processor to expose the System Monitor and many other features of the processor, regardless of model.  Now you only need to maintain a single SIMPL program defined for your most complex processor application (ex. PRO3)
+
+## Join Map Documentation
+
+[Join Map Documentation](JoinMaps)
 
 ## Device Type Join Maps
 
diff --git a/Standalone-Use.md b/Standalone-Use.md
index e5e198c..0807a4b 100644
--- a/Standalone-Use.md
+++ b/Standalone-Use.md
@@ -21,4 +21,4 @@ By defining devices and a room in a JSON configuration file, Essentials can cont
     - Schedule awareness via Video Codec
     - One button meeting join for Video Calling (with supported Video Codec)
 
-Next: [Simpl Windows bridging](SIMPL-Bridging)
\ No newline at end of file
+Next: [Simpl Windows bridging](SIMPL-Bridging-Updated)
\ No newline at end of file