[Protocol] [WIP] Dash React Protocol (DRP)

  • This Protocol is a Work in Progress!

    Dash React allows us to quite literally program our systems in completely new ways. It is completely flexible, and thus can also get us into trouble if we don't really think out how we want to accomplish various tasks. In order to make it easier, we are providing the Dash React Protocol, a set of instructions to follow in order to successfully implement Dash React and provide a means to scale your systems.

    While you do not need to follow this Protocol, and while we expect others may come up with their own Protocols for you to check out, we will expect you are using DRP during Guides & Tutorials so in the very minimum, following DRP should be your starting point.

    When a common protocol is followed, we will be able to better provide assistance and guides on specific things without the fear that what you are being told to do may conflict with your current programming. This is likely to get quite long and may seem intimidating at first. However, I assure you that once you use it you will see the simplicity of it all!

    Key Concepts

    Our goal is to organize things in a way that is predictable, easy to remember, and something we can deploy across all of our projects regardless of size or complexity. We will be thinking out the specifics of how we generally require things be done and will provide examples and options for each.

    Here are some of the Key Concepts of DRP:

    • Each "Room" or "Zone" will have a Variable defined as it's "Control Variable." Our "Control Variable" will be the main Variable we set to do essential tasks in that room such as Source Selection.
    • A "Control Variable" will see an empty value as "Off" rather than using a value such as "Off" to turn a room off.
    • Our "Control Variable" will always be the name of the room, and will use "Upper Camel Case" which is upper case letters for each "word" in the room with spaces omitted (if applicable). For example: LivingRoom, MasterBathroom, KidsBedroom, Pantry, Office, Backyard
    • Each Parameter sent to our Variable will be separated by a "-" character. (For Example: isLISTEN-NetPlayer-Pandora)
    • Each Parameter will also be Upper Camel Case (see above). Note: Except Categories and Triggers
    • No Parameter should ever contain less than 4 letters unless it is a "trigger" command or value (see below).
    • Parameters may have special "trigger" commands which we will use in various ways. These will always be defined as all capitals and will contain between 3-4 characters (Examples: USE, APP, LNK, TRGR, CHNL, NUM, USR, BOX, SET...)
    • Our "Control Variable" Parameters will always include a category (power), a source (input) and will optionally include triggers & arguments.
    • Categories will always begin with "is" followed by the category name in all Upper Case lettering (Example: isWATCH).
    • It is valid to include multiple categories within a variable value to achieve a desired effect. This allows for easily selecting whether to use an OSD when listening to music, for example. (Example: isWatch-isListen-NetPlayer-Pandora)
    • Categories, Triggers, and Parameters may come in any order and are not guaranteed to be in the formats shown in examples. However, Trigger Commands and their values will always accompany each other.
    • When executing commands via DRP our system will be told to multi-task, triggering multiple commands simultaneously.
    • Cloud Logs & Timeline Events will be specified in a strict manner to aid in troubleshooting & debugging
    • Dash OS / Dash Mobile Support: One important note is that the DRP is Modeled in a way that will make working with Dash Mobile significantly easier at launch and onwards.

    Example Variables

    Control Variables: LivingRoom, Bedroom, Bathroom
    Example Values: isWATCH-Roku, isWATCH-Roku-APP-Netflix, isLISTEN-NetPlayer-APP-Pandora, isLISTEN-NetPlayer-APP-Pandora-FAV-Quickmix, isWATCH-Sat-BOX-One

    Core Categories

    While you are more than welcome to define your own categories on top of the Core Categories, every system should include the following categories and should be made to operate as shown. It is important to note that every category MUST begin with "is" followed by the category in all upper case letters, this allows us to build our commands with confidence that we will reduce false positive matches (more on that later)

    • isWATCH - The isWATCH Category should be defined for every room which includes a display. When defined, it will be used to indicate that the Display should be powered on and set to the proper configuration.
    • isLISTEN - The isLISTEN Category should be defined for every room which includes music sources and/or has speakers aside from the displays. It will be used to tell the system to power on any amplifiers and prepare the system to receive a source.

    It is valid to assume that one category may want to monitor the other. For example, if we were to sync a room that includes a display to a room which only has speakers, but can play the same source, the room will want to monitor Watch AND Listen so it can react easily without extra modification (more on that in the future).

    Naming Conventions for Device Events

    [Coming Soon]

    Handling Category Event Macros

    [Coming Soon]

    Setting Up Our Parameter Device Events

    [Coming Soon]

    Trigger Commands and their Values

    [Coming Soon]

    Braden R. Napier

  • 1
    Log in to reply

Internal error.

Oops! Looks like something went wrong!