pepperdash/Essentials
1
0
Fork 0
mirror of https://github.com/PepperDash/Essentials.git synced 2026-01-11 19:44:52 +00:00
Code Issues Packages Projects Releases Wiki Activity

updates for changing master->main

Andrew Welker
2020-06-17 12:18:02 -06:00
parent d5b32eeef3
commit d02ec50641
6 changed files with 87 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
Arch-topics.md

@@ -4,7 +4,7 @@ Configuration is central to Essentials. On this page we will cover configuration
## Classes Referenced
* `PepperDash.Essentials.Core.Config.DeviceConfig`
- `PepperDash.Essentials.Core.Config.DeviceConfig`
## Configure-first development
@@ -34,13 +34,13 @@ In Essentials, most everything we do is focused in one layer: The Devices layer.
Types of devices:
* Rooms
* Sources
* Codecs, DSPs, displays, routing hardware
* IR Ports, Com ports, SSh Clients, ...
* Occupancy sensors and relay-driven devices
* Logical devices that manage multiple devices and other business, like shade or lighting scene controllers
* Fusion connectors to rooms
- Rooms
- Sources
- Codecs, DSPs, displays, routing hardware
- IR Ports, Com ports, SSh Clients, ...
- Occupancy sensors and relay-driven devices
- Logical devices that manage multiple devices and other business, like shade or lighting scene controllers
- Fusion connectors to rooms
A Device doesn't always represent a physical piece of hardware, but rather a logical construct that "does something" and is used by one or more other devices in the running program. For example, we create a room device, and its corresponding Fusion device, and that room has a Cisco codec device, with an attached SSh client device. All of these lie in a flat collection in the `DeviceManager`.
@@ -76,11 +76,11 @@ Often, code is written and tested first without consideration for configurabilit
At the heart of the Essentials framework is the configuration system. While not technically necessary for a system written with the Essentials framework, it is the preferred and, currently, the only way to build an Essentials system. The configuration file is JSON, and well-defined (but not well documented, yet). It is comprised of blocks:
* info (object) Contains metadata about the config file
* devices (array) Contains, well, the devices we intend to build and load
* rooms (array, typically only one) Contains the rooms we need
* sourceLists (object) Used by one or more rooms to represent list(s) of sources for those rooms
* tieLines (array) Used by the routing system to discover routing between sources and displays
- info (object) Contains metadata about the config file
- devices (array) Contains, well, the devices we intend to build and load
- rooms (array, typically only one) Contains the rooms we need
- sourceLists (object) Used by one or more rooms to represent list(s) of sources for those rooms
- tieLines (array) Used by the routing system to discover routing between sources and displays
In addition, a downloaded Portal config file will most likely be in a template/system form, meaning that the file contains two main objects, representing the template configuration and its system-level overrides. Other metadata, such as Portal UUIDs or URLs may be present.
@@ -127,7 +127,7 @@ Once the ConfigReader has successfully read and deserialized the config file, th
This ordering ensures that all devices are at least present before building tie lines and rooms. Rooms can be built without their required devices being present. In principle, this could break from the loosely-coupled goal we have described, but it is the clearest 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:
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 list of types and build procedures. Here's part of the code:
```cs
// Try local factories first

10
Debugging.md

@@ -61,7 +61,7 @@ Debug.Console(0, Debug.ErrorLogLevel.Notice, "Hello World");
The following console commands all perform actions on devices that have been registered with the `PepperDash.Essentials.Core.DeviceManager` static class
### Appdebug:[slot] [0-2]
### Appdebug:[slot][0-2]
Gets or sets the current debug level where 0 is the lowest setting and 2 is the most verbose
@@ -118,7 +118,7 @@ RMC3>[16:34:05.819]App 1:28 Devices registered with Device Mangager:
[16:34:05.849]App 1: [tcp-1-tcp]
```
### Devprops:[slot] [devicekey]
### Devprops:[slot][devicekey]
Gets the list of public properties on the device with the corresponding `deviceKey`
@@ -163,7 +163,7 @@ RMC3>
```
### Devmethods:[slot] [devicekey]
### Devmethods:[slot][devicekey]
Gets the list of public methods available on the device
@@ -206,7 +206,7 @@ RMC3>devmethods:1 cec-1-cec
RMC3>
```
### Devjson:[slot] [json formatted object {"devicekey", "methodname", "params"}]
### Devjson:[slot][json formatted object {"devicekey", "methodname", "params"}]
Used in conjunction with devmethods, this command allows any of the public methods to be called from console and the appropriate arguments can be passed in to the method via a JSON object.
@@ -226,4 +226,4 @@ RMC3>devjson:1 {"deviceKey":"cec-1-cec", "methodName":"SendText", "params": ["he
RMC3>devjson:1 {"deviceKey":"cec-1-cec", "methodName":"SimulateReceive", "params": ["hello citizen of Earth\r"]}
```
For additional examples, see this [file](https://github.com/PepperDash/Essentials/blob/master/devjson%20commands.json).
For additional examples, see this [file](https://github.com/PepperDash/Essentials/blob/main/devjson%20commands.json).

4
Get-started.md

@@ -2,7 +2,7 @@
## Download or clone
You may clone Essentials at <https://github.com/PepperDash/Essentials/tree/master>
You may clone Essentials at <https://github.com/PepperDash/Essentials/tree/main>
You may download ready-to-run Essentials at <https://github.com/PepperDash/Essentials-Builds>
@@ -14,7 +14,7 @@ To help understand Essentials Framework, we recommend starting with the current
1. Using an SFTP client, load `PepperDashEssentials1.4.32.cpz` to the processor in program slot 1 and start the program by sending console command `progload -p:1`
1. On first boot, the Essentials Application will build the necessary configuration folder structure in the User/Program1/ path.
1. The application has some example configuration files included. Copy `/Program01/Example Configuration/EssentialsSpaceHuddleRoom/configurationFile-HuddleSpace-2-Source.json` to the `/User/Program1/` folder.
1. The application has some example configuration files included. Copy `/Program01/Example Configuration/EssentialsSpaceHuddleRoom/configurationFile-HuddleSpace-2-Source.json` to the `/User/Program1/` folder.
1. Copy the SGD files from `/Program01/SGD` to `/User/Program1/sgd`
1. Reset the program via console `progreset -p:1`. The program will load the example configuration file.
1. Via console, you can run the `devlist:1` command to get some insight into what has been loaded from the configuration file into the system . This will print the basic device information in the form of ["key"] "Name". The "key" value is what we can use to interact with each device uniquely.

26
Home.md

@@ -8,8 +8,8 @@ Essentials is a collection of C# libraries that can be used in many ways. It is
## Get started
* [Download essentials build or clone repo](Get-started#)
* [How to get started](Get-started)
- [Download essentials build or clone repo](Get-started#)
- [How to get started](Get-started)
Or use the links to the right to navigate our documentation.
@@ -17,13 +17,13 @@ Or use the links to the right to navigate our documentation.
## Benefits
* Runs on Crestron 3-Series, **4-Series** and VC-4 Control System platforms
* Reduced hardware overhead compared to S+ and Simpl solutions
* Quick development cycle
* Shared resources made easily available
* More flexibility with less code
* Configurable using simple JSON files
* Is awesome
- Runs on Crestron 3-Series, **4-Series** and VC-4 Control System platforms
- Reduced hardware overhead compared to S+ and Simpl solutions
- Quick development cycle
- Shared resources made easily available
- More flexibility with less code
- Configurable using simple JSON files
- Is awesome
---
@@ -47,14 +47,14 @@ Essentials is an open-source project and we encourage collaboration on this comm
### Open-source-collaborative workflow
The `master` branch always contain the latest stable version. The `development` branch is used for most development efforts.
The `main` branch always contain the latest stable version. The `development` branch is used for most development efforts.
[GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) will be used as the workflow for this collaborative project. To contribute, follow this process:
[GitFlow](https://nvie.com/posts/a-successful-git-branching-model/) will be used as the workflow for this collaborative project. To contribute, follow this process:
1. Fork this repository ([More Info](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/working-with-forks))
2. Create a branch using standard GitFlow branch prefixes (feature/hotfix) followed by a descriptive name.
* Example: `feature/add-awesomeness` or `hotfix/really-big-oops`
* When working on a new feature or bugfix, branch from the `development` branch. When working on a hotfix, branch from `master`.
- Example: `feature/add-awesomeness` or `hotfix/really-big-oops`
- When working on a new feature or bugfix, branch from the `development` branch. When working on a hotfix, branch from `main`.
3. Make commits as necessary (often is better). And use concise, descriptive language, leveraging issue notation and/or [Closing Keywords](https://help.github.com/articles/closing-issues-using-keywords) to ensure any issues addressed by your work are referenced accordingly.
4. When the scope of the work for your branch is complete, make sure to rebase your branch in case further progress has been made since the repo was forked
5. Create a Pull Request to pull your branch into the appropriate branch in the main repository.

36
SIMPL-Bridging-Updated.md

@@ -272,7 +272,7 @@ To control diplay power from SIMPL Windows, we would connect Digital Signals to
To utilize the com port device, we would connect Serial Signals (VTC_TX$ and VTC_RX$) to join 51 on the EISC.
You can refer to our [SIMPL Windows Bridging Example](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for a more complex example.
Example device config: <https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json>
Example device config: <https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json>
## Notes
@@ -308,100 +308,100 @@ Please note that these joinmaps _may_ be using a deprecated implementation. The
> supports: AM-200, AM-300
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/AirMediaControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/AirMediaControllerJoinMap.cs>
### AppleTvController
> supports: IR control of Apple TV
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/AppleTvJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/AppleTvJoinMap.cs>
### CameraControlBase
> supports: any camera that derives from CameraBase
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/CameraControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/CameraControllerJoinMap.cs>
### DisplayController
> supports: IR controlled displays, any two way display driver that derives from PepperDash.Essentials.Core.DisplayBase
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DisplayControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DisplayControllerJoinMap.cs>
### DmChasisController
> supports: All DM-MD-8x8/16x16/32x32 chassis, with or w/o DM-CPU3 Card
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmChassisControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmChassisControllerJoinMap.cs>
### DmRmcController
> supports: All DM-RMC devices
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmRmcControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmRmcControllerJoinMap.cs>
### DmTxController
> supports: All Dm-Tx devices
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmTxControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmTxControllerJoinMap.cs>
### DmpsAudioOutputController
> supports: Program, Aux1, Aux2 outputs of all DMPS3 Control Systems
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmpsAudioOutputControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmpsAudioOutputControllerJoinMap.cs>
### DmpsRoutingController
> supports: Av routing for all DMPS3 Control Systems
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmpsRoutingControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/DmpsRoutingControllerJoinMap.cs>
### GenericRelayController
> supports: Any relay port on a Crestron Control System or Dm Endpoint
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/GenericRelayControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/GenericRelayControllerJoinMap.cs>
### GenericLightingJoinMap
> supports: Devices derived from PepperDash.Essentials.Core.Lighting.LightingBase
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/GenericLightingJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/GenericLightingJoinMap.cs>
### GlsOccupancySensorBase
> supports: Any Crestron GLS-Type Occupancy sensor - single/dual type
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/GlsOccupancySensorBaseJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/GlsOccupancySensorBaseJoinMap.cs>
### HdMdxxxCEController
> supports: HD-MD-400-C-E, HD-MD-300-C-E, HD-MD-200-C-E, HD-MD-200-C-1G-E-B/W
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/HdMdxxxCEControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/HdMdxxxCEControllerJoinMap.cs>
### IBasicCommunication
> supports: Any COM Port on a Control System or Dm Endpoint device, TCP Client, SSH Client, or UDP Server
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/IBasicCommunicationJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/IBasicCommunicationJoinMap.cs>
### IDigitalInput
> supports: Any Digital Input on a Control System, or DM Endpoint device
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/IDigitalInputJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/IDigitalInputJoinMap.cs>
### SystemMonitorController
> supports: Exposing the system monitor slot for any Control System
<https://github.com/PepperDash/Essentials/blob/master/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/SystemMonitorJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/essentials-framework/Essentials%20Core/PepperDashEssentialsBase/Bridges/JoinMaps/SystemMonitorJoinMap.cs>
## Example SIMPL Windows Program
We've provided an [example program](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for SIMPL Windows that works with the provided example Essentials configuration file [SIMPLBridgeExample_configurationFile.json](https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json). Load Essentials and the example SIMPL program to two slots on the same processor and you can get a better idea of how to take advantage of SIMPL Windows bridging.
We've provided an [example program](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for SIMPL Windows that works with the provided example Essentials configuration file [SIMPLBridgeExample_configurationFile.json](https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json). Load Essentials and the example SIMPL program to two slots on the same processor and you can get a better idea of how to take advantage of SIMPL Windows bridging.
Next: [Essentials architecture](Arch-summary)

70
SIMPL-Bridging.md

@@ -2,7 +2,7 @@
**Note : this entry is out of date - please see [SIMPL Windows Bridging - Updated](SIMPL-Bridging-Updated)**
Essentials allows for devices defined within the SIMPL# Pro application to be bridged to a SIMPL Windows application over Ethernet Intersystem Communication (EISC). This allows a SIMPL Windows program to take advantage of some of the features of the SIMPL# Pro environment, without requiring the entire application to be written in C#.
Essentials allows for devices defined within the SIMPL# Pro application to be bridged to a SIMPL Windows application over Ethernet Intersystem Communication (EISC). This allows a SIMPL Windows program to take advantage of some of the features of the SIMPL# Pro environment, without requiring the entire application to be written in C#.
Some of the main advantages are:
@@ -16,9 +16,9 @@ Some of the main advantages are:
## Implementation
Bridges are devices that are defined within the devices array in the config file. They are unique devices with a specialized purpose; to act as a bridge between Essentials Devices and applications programmed traditionally in Simpl Windows. This is accomplished by instantiating a Three Series Intersystem Communication symbol within the bridge device, and linking its Boolean/Ushort/String inputs and outputs to actions on one or multiple Essentials device(s). The definition for which joins map to which actions is defined within the device to be bridged to in a class that derives from JoinMapBase.
Bridges are devices that are defined within the devices array in the config file. They are unique devices with a specialized purpose; to act as a bridge between Essentials Devices and applications programmed traditionally in Simpl Windows. This is accomplished by instantiating a Three Series Intersystem Communication symbol within the bridge device, and linking its Boolean/Ushort/String inputs and outputs to actions on one or multiple Essentials device(s). The definition for which joins map to which actions is defined within the device to be bridged to in a class that derives from JoinMapBase.
Let's consider the following Essentials Configuration:
Let's consider the following Essentials Configuration:
```JSON
{
@@ -141,9 +141,9 @@ We have four Essentials Devices configured:
1. Bridge with a Key of "deviceBridge"
We want to have access to the com port for VTC Control from Simpl Windows and we want to control the display from Simpl Windows. To accomplish this, we have created a bridge device and added the devices to be bridged to the "devices" array on the bridge. As you can see we define the device key and the join start, which will determine which joins we will use on the resulting EISC to interact with the devices. In the Bridge control properties we defined ipid 03, and we will need a corresponding Ethernet System Intercommunication in the Simpl Windows program at ipid 03.
We want to have access to the com port for VTC Control from Simpl Windows and we want to control the display from Simpl Windows. To accomplish this, we have created a bridge device and added the devices to be bridged to the "devices" array on the bridge. As you can see we define the device key and the join start, which will determine which joins we will use on the resulting EISC to interact with the devices. In the Bridge control properties we defined ipid 03, and we will need a corresponding Ethernet System Intercommunication in the Simpl Windows program at ipid 03.
Now that our devices have been built, we can refer to the device join maps to see which joins correspond to which actions.
Now that our devices have been built, we can refer to the device join maps to see which joins correspond to which actions.
See below:
@@ -268,7 +268,7 @@ PowerOn = 2
IsTwoWayDisplay = 3
VolumeUp = 5
VolumeDown = 6
VolumeMute = 7
VolumeMute = 7
```cs
namespace PepperDash.Essentials.Bridges
@@ -338,37 +338,37 @@ SendText = 1
SetPortConfig = 2
Connect = 1
Connected = 1
Status = 1
Status = 1
Considering our Bridge config, we can see that the display controls will start at join 1, and the VTC Com port will start at join 51. The result is a single EISC that allows us to interact with our Essentials devices.
Considering our Bridge config, we can see that the display controls will start at join 1, and the VTC Com port will start at join 51. The result is a single EISC that allows us to interact with our Essentials devices.
To control diplay power from Simpl Windows, we would connect Digital Signals to joins 1 & 2 on the EISC to control Display Power On & Off.
To utilize the com port device, we would connect Serial Signals (VTC_TX$ and VTC_RX$) to join 51 on the EISC.
You can refer to our [Simpl Windows Bridging Example](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for a more complex example.
Example device config: <https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json>
Example device config: <https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json>
## Notes
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. 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...
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...
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.
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.
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.
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.
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.
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.
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.
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.
## 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. 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.
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.
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)
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)
## Device Type Join Maps
@@ -376,100 +376,100 @@ Example device config: <https://github.com/PepperDash/Essentials/blob/master/Pep
> supports: AM-200, AM-300
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/AirMediaControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/AirMediaControllerJoinMap.cs>
### AppleTvController
> supports: IR control of Apple TV
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/AppleTvJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/AppleTvJoinMap.cs>
### CameraControlBase
> supports: any camera that derives from CameraBase
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/CameraControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/CameraControllerJoinMap.cs>
### DisplayController
> supports: IR controlled displays, any two way display driver that derives from PepperDash.Essentials.Core.DisplayBase
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/DisplayControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/DisplayControllerJoinMap.cs>
### DmChasisController
> supports: All DM-MD-8x8/16x16/32x32 chassis, with or w/o DM-CPU3 Card
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/DmChassisControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/DmChassisControllerJoinMap.cs>
### DmRmcController
> supports: All DM-RMC devices
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/DmRmcControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/DmRmcControllerJoinMap.cs>
### DmTxController
> supports: All Dm-Tx devices
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/DmTxControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/DmTxControllerJoinMap.cs>
### DmpsAudioOutputController
> supports: Program, Aux1, Aux2 outputs of all DMPS3 Control Systems
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/DmpsAudioOutputControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/DmpsAudioOutputControllerJoinMap.cs>
### DmpsRoutingController
> supports: Av routing for all DMPS3 Control Systems
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/DmpsRoutingControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/DmpsRoutingControllerJoinMap.cs>
### GenericRelayController
> supports: Any relay port on a Crestron Control System or Dm Endpoint
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/GenericRelayControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/GenericRelayControllerJoinMap.cs>
### GenericLightingJoinMap
> supports: Devices derived from PepperDash.Essentials.Core.Lighting.LightingBase
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/GenericLightingJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/GenericLightingJoinMap.cs>
### GlsOccupancySensorBase
> supports: Any Crestron GLS-Type Occupancy sensor - single/dual type
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/GlsOccupancySensorBaseJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/GlsOccupancySensorBaseJoinMap.cs>
### HdMdxxxCEController
> supports: HD-MD-400-C-E, HD-MD-300-C-E, HD-MD-200-C-E, HD-MD-200-C-1G-E-B/W
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/HdMdxxxCEControllerJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/HdMdxxxCEControllerJoinMap.cs>
### IBasicCommunication
> supports: Any COM Port on a Control System or Dm Endpoint device, TCP Client, SSH Client, or UDP Server
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/IBasicCommunicationJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/IBasicCommunicationJoinMap.cs>
### IDigitalInput
> supports: Any Digital Input on a Control System, or DM Endpoint device
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/IDigitalInputJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/IDigitalInputJoinMap.cs>
### SystemMonitorController
> supports: Exposing the system monitor slot for any Control System
<https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Bridges/JoinMaps/SystemMonitorJoinMap.cs>
<https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Bridges/JoinMaps/SystemMonitorJoinMap.cs>
## Example SIMPL Windows Program
We've provided an [example program](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for SIMPL Windows that works with the provided example Essentials configuration file [SIMPLBridgeExample_configurationFile.json](https://github.com/PepperDash/Essentials/blob/master/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json). Load Essentials and the example SIMPL program to two slots on the same processor and you can get a better idea of how to take advantage of SIMPL Windows bridging.
We've provided an [example program](https://github.com/PepperDash/EssentialsSIMPLWindowsBridgeExample) for SIMPL Windows that works with the provided example Essentials configuration file [SIMPLBridgeExample_configurationFile.json](https://github.com/PepperDash/Essentials/blob/main/PepperDashEssentials/Example%20Configuration/SIMPLBridging/SIMPLBridgeExample_configurationFile.json). Load Essentials and the example SIMPL program to two slots on the same processor and you can get a better idea of how to take advantage of SIMPL Windows bridging.
Next: [Essentials architecture](Arch-summary)