In some cases, multiple device info update events are triggering,
causing the queue to be flooded with multiple unneccessary messages containing the same info.
This clogs the queue and makes it harder for UIs to come online when Essentials restarts,
especially in systems with a lot of NVX devices.
The events are now debounced. If there are no new messages for 1 second, then the MC message
is sent out.
Introduced a new method `ApplyLayout` in the `IHasScreensWithLayouts` interface. This method enables the application of a specific layout to a screen using the provided screen ID and layout index. XML documentation has been added to clarify its purpose and parameters.
Added `LayoutType` and `Windows` properties to the `LayoutInfo` class. Introduced a new `WindowConfig` class with `Label` and `Input` properties to represent window configurations within a layout.
Introduces a new enumeration `PresenterTrackMode` that defines four tracking modes for the Cisco codec's Presenter Track feature: `Off`, `Follow`, `Background`, and `Persistent`. Each mode includes a summary comment for clarity.
Introduced new interfaces and classes for screen and layout management, including `IHasScreensWithLayouts`, `ScreenInfo`, and `LayoutInfo`. Enhanced `IPresenterTrack` and `ISpeakerTrack` interfaces with additional properties and methods for managing presenter and speaker tracking. Added `IHasCodecRoomPresets` interface for room preset management and updated `CodecRoomPreset` class with a new constructor.
Introduced two new interfaces, `IPresenterTrack` and `ISpeakerTrack`, in the `PepperDash.Essentials.Devices.Common.Codec.Cisco` namespace. These interfaces provide properties and methods for managing presenter and speaker tracking functionalities in Cisco codecs, including availability, status feedback, and control methods.
When MC is running on a processor with a control subnet and a user
attempts to access the UI via the control subnet, the return _config.local.json
needs to reflect the CS LAN IP address for the processor rather than the LAN IP Address.
In order to accomplish this, there will now be 2 config files written to disk on startup:
1. the original file, /user/programX/mcUserApp/_local-config/_config.local.json
2. A file with the correct CS IP Address /user/programX/mcUserApp/_local-config/_config.cs.json
When a user requests the _config.local.json, the processor will compare the remote IP address
with the CS LAN IP Address and determine if they're in the same subnet, the assumption being
that if the IP Addresses are in the same subnet, then the app or end user is on the CS LAN and needs the CS config.
If the addresses are in the same subnet, then the contents of the _config.cs.json will be returned.
In some scenarios when working with NVX, a route is intended to use the
secondary audio (NAX) path instead of the primary audio path. A route
that's both `Video` and `SecondaryAudio` should be considered a
dual-path route instead of a single path.
Added the `ILightingScenesDynamic` interface to add an event for devices that support retrieving scene data from the lighting system at runtime. Also added the `sortOrder` property for the `LightingScene` type to allow for control over the sort order of scenes on the UI
Due to how the `BeginPolling` method was written and being called, there
were situations where multiple PollTimers were created, causing there to
be multiple messages sent to the end point for each poll cycle.
In order to match up with how existing front-end apps are expecting to
recieve data for devices that implement the `IHasInputs<T>` interface,
there is now an IHasInputsMessengers that is implemented for devices
that implement `IHasInputs<string>`, `IHasInputs<int>` or
`IHasInputs<byte>` interfaces.
In order to satisfy the requirements for the `MessengerBase` class, the
`ISelectableItemsMessenger` class needs to take an `IHasInputs<T>`, as that is
the device that implements `IKeyName`. We may want to consider adding a
`IHasInputsMessenger` specifically for those devices that implement that
interface vs the `ISelectableItemsMessenger`.
`CrestronGenericBaseDevice` was NOT calling `base.CustomActivate()` in
it's `CustomActivate` override, causing the
`CreateMobileControlMessengers` method to not be called as expected when
plugin devices were inheriting from `CrestronGenericBaseDevice` or
`CrestronGenericBridgeableBaseDevice`.
If the grant code was not provided, the `mobileadduiclient` console
command would fail silently. The command now checks that the correct
number of arguments was provided and prints an error to the console of
one is missing
