Changes for page **General Overview and Design Considerations
Last modified by Alexander Mott on 2023/12/08 18:37
From version 20.1
edited by Alexander Mott
on 2023/12/08 18:37
on 2023/12/08 18:37
Change comment:
There is no comment for this version
Summary
-
Page properties (2 modified, 0 added, 0 removed)
Details
- Page properties
-
- Title
-
... ... @@ -1,1 +1,1 @@ 1 -* *General Overview and Design Considerations1 +*General Overview and Design Considerations - Content
-
... ... @@ -12,38 +12,16 @@ 12 12 13 13 Zūm Wired systems consist of ZUMNET-JBOX-* room controllers and a number of connected ZUMLINK-* devices. ZUMLINK-* devices can be ZUMLINK-JBOX-* load controllers, ZUMLINK-OCC-* presence detectors, or ZUMLINK-KP-R-W keypads (wall switches). ZUMNET-JBOX-* and ZUMLINK-JBOX-* devices have additional inputs for third-party presence detectors, 0-10V analog photocells, and contact-closure local override. 14 14 15 -ZUMNET-JBOX-* room controllers can be operated in App Mode or CNETMode, with an additional setting to be either the Primary room controller or a Secondary load controller.15 +ZUMNET-JBOX-* room controllers can be operated in App mode or CNET mode, with an additional setting to be either the Primary room controller or a Secondary load controller. 16 16 17 17 == App Mode == 18 18 19 - Using ZUMNET-JBOX-* devices in App Mode means that the majority of theroomlogic is handled by the [[Primary>>WebHome||anchor="HPrimaryvsSecondaryMode"]] ZUMNET-JBOX-* for the room. This room logic must be configured over Bluetooth using the Crestron Zūm App. In [[Standalone>>WebHome||anchor="HStandalone"]] systems, the Primary ZUMNET-JBOX for each room is the only device handling control logic, whereas [[Networked>>WebHome||anchor="HNetworked"]] systems also have a centralized control processor which handles additional functions such as scheduling and coordinating controls between rooms and third party systems.19 +Lorem 20 20 21 21 == CNET Mode == 22 22 23 - Using ZUMNET-JBOX-* devices in CNET Mode is only possible on a [[networked system with a custom program>>WebHome||anchor="HNetworkedwithCustomProgram"]]. While in CNET Mode, ZUMNET-JBOX-* devices suspend any local logic and act as a "dumb" Cresnet-to-Ethernet bridge with a built-in load controller. Instead of receiving communications from ZūmLink devices and deciding what each device should do, the ZUMNET-JBOX simply passes the information on to thecontrol processor to do all the thinking. While in CNET Mode, ZUMNET-JBOX-* devices cannot be connected to through the ZūmApp, and any attached ZUMLINK-KP or ZUMLINK-OCC-* sensors will not work without the processor.23 +Lorem 24 24 25 -The benefit of using CNET Mode with a custom program over App Mode is that it allows for the control processor to have direct control over all hardware in the system. This enables a custom program to meet a significantly wider range of sequences than App Mode. Additionally, CNET Mode offers increased security over App Mode as it is not possible to connect to a device with the Crestron Zūm App while it is in CNET Mode. 26 - 27 -The main drawbacks of using CNET Mode are the added hardware and installation costs that come with requiring a networked system and custom program. Systems running on outdated firmware have the additional drawback of losing all local controls in the event that connection to the control processor is lost, but this risk has been addressed with the introduction of the [[Zūm Mode Auto Switch>>WebHome||anchor="HZ16BmModeAutoSwitch"]] feature. 28 - 29 -//As of February, 2023, Crestron is shipping all ZUMNET-JBOX-* devices preconfigured in CNET mode, though this may change in the future.// 30 - 31 -== Zūm Mode Auto Switch == 32 - 33 -Zūm Mode Auto Switch is a feature introduced in November of 2022 with .puf firmware v1.04.05 (device firmware 1.004.00005). This feature is intended to address concerns that arose from projects using custom programs with ZUMNET-JBOX-* devices in CNET Mode. Previously, if a device in CNET Mode lost connection to the processor, then it would be impossible to maintain any sort of control over the lighting. With Zūm Mode Auto Switch enabled, a ZUMNET-JBOX running in CNET Mode will automatically switch to App Mode and process local logic in the event that it loses connection to the processor. 34 - 35 -Enabling this feature eliminates one of the biggest risks of designing a system to use ZUMNET-JBOX-* devices in CNET Mode by enabling the system to use local logic as a backup in the event of a loss of connection to the control processor. 36 - 37 -//As of February, 2023, Crestron is shipping all ZUMNET-JBOX-* devices preconfigured with Zūm Mode Auto Switch disabled, as this feature is only intended to be used with systems that are running custom programs.// 38 - 39 -//Any configuration changes made through the Zūm App should be made while the control processor is disconnected: the easiest ways to accomplish this are to either disconnect the Cat5e/Cat6 cable at the processor or use Text Console commands to temporarily suspend the custom program on the processor.// 40 - 41 -== Security Considerations == 42 - 43 -Any ZUMNET-JBOX that is running in App Mode with an attached ZUMLINK-KP can be connected to via the Crestron Zūm App, which is publicly available in the Google Play store. Although unlikely, it is technically possible that a bad actor could download the Zūm App and interfere with the lighting controls. Crestron ships all ZUMNET-JBOX-* devices with a default PIN that is intended to be changed during commissioning, however there is no guarantee that the technician who configured the Zūm Wired hardware knew or remembered to do this. 44 - 45 -One way to counteract this security risk is to design the system to operate with the ZUMNET-JBOX-* devices in CNET Mode. In CNET Mode, it is impossible to connect to any devices using the Zūm App. Leaving the Zūm Mode Auto Switch function disabled will add another layer of security in exchange for a loss of localized control when the system is experiencing issues, as devices will stay in CNET Mode even when connection to the control processor is lost. 46 - 47 47 == Primary vs Secondary Mode == 48 48 49 49 (% class="box infomessage" %) ... ... @@ -56,123 +56,50 @@ 56 56 * In Primary mode, the ZUMNET-JBOX acts as the Zūm Link host, and is able to detect all connected Zūm Link devices. If connected to in Crestron Toolbox, a Primary ZUMNET-JBOX can be used to view and manually address any connected ZUMLINK-* devices. While in App mode, a ZUMNET-JBOX in Primary mode is the logical room controller for the space and is the device that should be used for configuration via the Zūm App. 57 57 * In Secondary mode, the ZUMNET-JBOX acts as if it were a ZUMLINK-JBOX. It does not process any room control logic, and when connected to via Crestron Toolbox it will not be able to see any other ZUMLINK-* devices. Using Secondary mode is rare, and should only be used in cases where a spare ZUMNET-JBOX is being used to add a load to another ZUMNET-JBOX or replace a ZUMLINK-JBOX that has been lost or damaged. 58 58 59 - //As of February, 2023, Crestron is shipping all ZUMNET-JBOX-*devicespreconfigured in Secondary mode, howevertheyhaveannounced their intentionto beginshipping hardwareon newerfirmware preconfigured in Primary mode.//37 +As of February, 2023, Crestron is shipping all ZUMNET-JBOX-* preconfigured in Secondary mode, though this may change in the future. 60 60 39 +== Security Considerations == 40 + 41 +Although unlikely, it is technically possible that 42 + 61 61 = Control Paradigms = 62 62 63 -Designs for Zūm Wired systems are broadly categorized as either "standalone" or "networked" designs. Both standalone and networked systems should be designed with one ZUMNET-JBOX-* per room or logical control space connected to a number of ZUMLINK-* devices within that same space. In standalone systems, there isnocentralcontrol processorandnoZūm Netcablingconnectingroomstoeach other,whichreducesthecostand complexityof the installationbutalsocomes withsomeof its own limitations.Networkedsystems,bycontrast,dohave acontrolprocessorwhichprovidescentralizedcontrolofthentireystem.Zūm Net cablingis usedto daisy-chainZUMNET-JBOX-*devices togetherand thenconnectthem tothelightingnetwork for control by theprocessor.45 +Designs for Zūm Wired systems are broadly categorized as either "standalone" or "networked" designs. Both standalone and networked systems should be designed with one ZUMNET-JBOX-* per room or logical control space connected to a number of ZUMLINK-* devices within that same space. In networked systems, there is also a control processor which provides centralized control of the entire system. ZUMNET-JBOX-* must be daisy-chained together with Zūm Net and then connected back to the processor. In standalone applications, there is no processor and no Zūm Net cabling connecting different rooms to each other. 64 64 65 -Networked systems can be further subdivided into those that use the default program included with ZUM-HUB4 processors and those that use a custom program, such as SHOWRUNNER™. The below sections cover in detail the advantages and disadvantages of each control paradigm. 66 66 67 - ==Standalone==48 +The difference between the two is that in a networked system there will be Zūm Net cabling connecting each ZUMNET-JBOX-* 68 68 69 - StandaloneZūmWired designs consist of completelyindependentZūm Rooms.EachZūmRoom hasa single ZUMNET-JBOX-* with anynumber of ZUMLINK-* devicesconnected to it. There is no Zūm Net connectingindividual rooms, and thereisno processor required. This resultsin a system which has areduced hardware cost and can theoretically be commissioned and configured entirely by the electrical contractor,however there are some important drawbacks to consider.50 +In standalone applications, each room has one ZUMNET-JBOX-* with a number of connected ZUMLINK-* devices. There is no Zūm Net connecting different rooms, 70 70 71 - Theprimarybenefits ofastandalone ZūmWired systemare:52 +Networked systems can be further subdivided into "Networked with Default Program" or "Networked with Custom Program". 72 72 73 -* Reduced installation time and cost as no Zūm Net cabling is required between rooms 74 -* Reduced hardware cost as no ZUM-HUB4 or networking hardware is required 75 -* Theoretically possible to start-up using only the Crestron Zūm App, with no programming or specialty software required 54 +Depending on which control paradigm is selected, there will be various impacts to the hardware cost, start-up cost, start-up complexity, ease of maintenance, control capabilities, integration with third-party systems, available user interfaces, and the ability to meet a provided sequence of operations. 76 76 77 - Somedrawbacks of a standaloneZūmWired system are:56 +== Standalone == 78 78 79 -* As of 2/2023, ZUMNET-JBOX-* devices ship with factory settings that are incompatible with an App only startup, resulting in extra expense to configure and update devices prior to installation or extra time spent during startup to accomplish these tasks post-installation: 80 -** ZUMNET-JBOX-* devices must be manually set to Zūm App mode 81 -** ZUMNET-JBOX-* devices must be manually set to Primary mode 82 -** Updating firmware with the Crestron Zūm App is not possible with out-of-the-box firmware and must be initially done through Toolbox 83 -* ZUMNET-JBOX-* devices can only be connected to via the App if there is a ZUMLINK-KP on their Zūm Link bus 84 -** During start-up, a technician must bring a ZUMLINK-KP to connect to the ZUMNET-JBOX in order to configure any rooms that were designed without a ZUMLINK-KP 85 -* Firmware updates through the Zūm App can consume a large amount of time on-site 86 -** Only one room can be updated at a time using the Zūm App, and it is not possible to do anything else while the room is updating 87 -** The time required to update a room's firmware varies depending on the number of ZUMLINK devices in the room 88 -* Standalone systems are limited compared to Networked systems in terms of what sequences can be met 89 -** No scheduling capabilities 90 -** No support for third-party integrations beyond the override contact-closure relay at each ZUMNET/ZUMLINK-JBOX and the relay output of any *-RLY model occupancy sensors 91 -** No support for DMX control 92 -** Any future modifications to the sequence requires reconfiguration through the Zūm App 93 -* No support for Cresnet devices 94 -* No cross-room control capabilities (i.e., ZUMLINK-* keypads and occupancy sensors are restricted to controlling loads that are attached to the same ZUMNET-JBOX as they are) 95 -* No possibility for remote support or management, as the only way to connect to any of the devices is by being using the Zūm App, which requires being within Bluetooth range of the device 96 -* Potential security concerns if the default PINs are not changed during start-up 97 -* Not possible to provide a graphical UI (touch screen) 58 +Lorem 98 98 99 99 == Networked == 100 100 101 -(% class="box errormessage" %) 102 -((( 103 -section incomplete 104 -))) 62 +Lorem 105 105 106 -Networked systems are generally preferred over standalone systems for most applications. Networked systems, and in particular networked systems with custom programming, are able to meet a much wider variety of sequences compared to standalone systems. Additionally, start-up and maintenance can be simplified, and certain aspects completed remotely, compared to standalone systems. 107 - 108 -In general, the drawbacks of any networked system are: 109 - 110 -* Requires additional hardware (at minimum a processor and a network switch for the Zūm Net) 111 -* Requires additional Zūm Net cabling between rooms 112 -* Additional start-up time required to configure the program 113 - 114 -All networked systems have the following benefits: 115 - 116 -* Some aspects of start-up can be accomplished remotely if there is remote access to the lighting network 117 -* Updating firmware and modifying hardware configurations can be accomplished over Zūm Net 118 -** Loadscripts can be written to simultaneous update firmware for up to 10 rooms 119 -*** These can be run remotely if there is remote access to the lighting network, or scheduled by the technician to execute after working hours in order to free up time on-site 120 -** Loadscripts can be written to bulk modify hardware settings (such as changing from Secondary to Primary modes) and configure IP settings (such as changing hostnames or updating IP tables) 121 -* Able to meet a wider range of sequences compared to standalone systems 122 -** Scheduling capabilities 123 -** BMS/BACnet integration 124 - 125 125 === Networked with Default Program === 126 126 127 -(% class="box errormessage" %) 128 -((( 129 -section incomplete 130 -))) 66 +Lorem 131 131 132 - Somebenefitsofusingthedefaultprogram are:68 +=== Networked with SHOWRUNNER™ === 133 133 134 - *70 +Lorem 135 135 136 - Somedrawbacksof using thedefaultprogramare:72 +== Start-Up Considerations == 137 137 138 -* Requires a ZUM-HUB4 processor (other types of processors can only be used with a custom program) 139 -* Limited support for Cresnet devices on the Zūm Link bus (n**o support?**) 140 -* Limited scheduling capabilities 141 -* N**o end-user UI availa**ble 74 +Lorem 142 142 143 -== =Networkedwith CustomProgram===76 +== Processor Selection for Networked Systems == 144 144 145 -(% class="box errormessage" %) 146 -((( 147 -section incomplete 148 -))) 78 +Lorem 149 149 150 - Someof thegeneralbenefitsofusingacustomprogram are:80 += Device Count Limitations = 151 151 152 -* 153 - 154 -The primary downside to using a custom program is that it is necessary to actually write a custom program for the system. With the SHOWRUNNER™ platform however, this downside is averted as it comes with a suite of tools to simplify configuration and commissioning easier compared to other custom programs. For more information, see our [[Crestron Zūm Wired and SHOWRUNNER™>>doc:Design Guide.Hardware Design Guide.Crestron Zum Wired.Crestron Zum Wired Overview.WebHome||anchor="HTheSHOWRUNNER2122Advantage"]] page. 155 - 156 -= Hardware Design Limitations = 157 - 158 -There are a handful of limitations to keep in mind when designing Zūm Wired systems, with different restrictions applying to Zūm Net and Zūm Link. 159 - 160 -Zūm Net limitations: 161 - 162 -* Do not exceed 100m or 328' between subsequent ZUMNET-JBOX-* devices, or between the first ZUMNET-JBOX and the network switch 163 -* Do not exceed 20 ZUMNET-JBOX-* devices on a single run of Zūm Net 164 -* Do not "loop" Zūm Net cables. ZUMNET-JBOX-* devices should be daisy chained together, with the first device on the run connected to the network switch and no home-run connecting the end-of-line device back to the network switch. 165 - 166 -Zūm Link limitations: 167 - 168 -* Do not exceed 31 ZUMLINK-* and Cresnet devices on a single ZUMNET-JBOX-* device 169 -* Do not exceed 85mA of 24VDC power consumption per ZUMNET/ZUMLINK-JBOX-* device on the Zūm Link bus 170 -** Each ZUMNET/ZUMLINK-JBOX-* is limited to 85mA of 24VDC output shared across their Zūm Link ports and sensor inputs 171 -** Power is shared between ZUMNET/ZUMLINK-JBOX-* devices on a single Zūm Link bus, so adding more ZUMNET/ZUMLINK-JBOX-* devices to a network increases the available power 172 -** ZUMLINK-IR-QUATTRO-HD-DLS/RLY occupancy sensors are rated at 32mA of power consumption 173 -** Other ZUMLINK-OCC-* sensors are rated at 25mA of power consumption each 174 -** ZUMLINK-KP keypads do not have a listed power consumption, but designing for approximately 20mA is safe 175 -* Available power on the Zūm Link bus can be increased by adding additional ZUMLILNK-JBOX-* devices, or by adding a separate power pack to provide power for non-system sensors or Cresnet devices on the Zūm Link bus 176 -* Do not "loop" Zūm Link cables. ZUMLINK-* devices should be daisy chained together, with no home-run connecting the end-of-line device back to the ZUMNET-JBOX-* controller for the room 177 -* Do not connect the Zūm Link busses of two separate ZUMNET-JBOX-* devices. There can only be one Primary ZUMNET-JBOX per Zūm Link bus, and any ZUMNET-JBOX-* devices intended to be operated as Secondary devices should instead be replaced with the corresponding ZUMLINK-JBOX-* model 82 +Lorem 178 178 )))