The number of on-board schedules and network scheduler to interact with is not limited. However, high numbers of schedules use hardware resources and may exceed the capabilities of the device during peak operation (e.g. lots of simultaneous property write actions at the same time).
A very high number of schedulers, schedules, and parameters may delay write operations or impair overall performance.
Currently, on-board schedule information cannot be exposed to the network (e.g. as a BACnet schedule object).
Preparing a setpoint message for generic LoRaWAN devices
The scheduler functionality is primarily intended to write setpoint information to connected LoRaWAN devices such as radiator actuators, thermostats or similar that can process the setpoint commands.
Only a limited set of very popular devices, commonly used with Connect Box, are currently supported via the simple way of writing LoRaWAN setpoints described in section 1 above.
Typically, and for all other LoRaWAN devices the manual encoding of the LoRaWAN downlink message is required. This message is always generated externally (e.g. on a Building Automation / Building Management station or the Cloud) and provided to the Connect Box that forwards it to LoRaWAN device(s).
The exact encoding procedure of the downlink message is defined by the device manufacturer and is usually part of the public codec documentation.
These encoded downlink messages can be typically communicated to the Connect Box via BACnet (IP) or Modbus (TCP) and might require advanced network and field bus knowledge. As a rule, simple message queuing suffices for most simple use cases and building installations. The Connect Box will pass on the messages in the same sequence to the different target devices.
Did you know? Although not covered in detail in this document, from a technical viewpoint, encoded LoRaWAN downlink messages can be used for a wide range of other system purposes. Influencing setpoints based on a schedule is just one common use case.
Retrieving a HEX encoded setpoint message for Connect Box
Supported BACnet IP data formats / object types capable of redirecting the encoded downlink message in HEX format to Connect Box are OBJ_CHARACTERSTRING_VALUE and OBJ_OCTETSTRING_VALUE.
It is essential to import / define all BACnet information as required by the instructions in the user interface.
Supported Modbus TCP data formats are listed below. We recommend using single coil / register preset commands (FC05/06 type) and not the preset multiple coils / register commands (FC15/16 type) for this purpose.
Desigo PXC 4/5/7 controllers currently do not provide BACnet and Modbus type communication compatible with the Connect Box.
We recommend using a previous generation Desigo PXC Controller such as PXC001-E (esp. in retrofit projects) or Desigo Optic (new installations). Current generation 3rd party BACnet system controllers such as Niagara4 framework-based controllers are also compatible.
In selected cases, where already available, Desigo CC or comparable Management stations may serve as an alternative location to generate the messages to the automation and system-level controllers.