Question - Best practices for customizing the Essentials program

[jonavila]

Hi PepperDash team,

I read through the wiki links and I'm unsure at the moment of what's the right approach to take when wanting to customize the logic of the devices instantiated in the Essentials app if you are planning to stay in the real of S#Pro. For example, adding your own even handlers

Is the right approach to fork the Essentials S#Pro program and add/change logic as necessary, basically using it only as a starting template? If that's the way to go, would you then simply rebase your fork down the line to get fixes or updates to part of the program like PluginLoading or new Room types?

Speaking of Rooms, if you want to create a custom type, would that be best done as a plugin?

[ndorin]

Hi Jonathan,

Thanks for your interest!

The best approach to modifying anything in the Essentials Framework is indeed to fork the repo. That will allow you to pull request any changes back into the main repo if you should wish to do so. And yes, to incorporate upstream changes to your fork you could rebase your fork.

For custom room types, yes the suggested methodology would be to write a plugin.

Thanks,

Neil Dorin Software Developer /SC PepperDash www.pepperdash.comhttp://www.pepperdash.com/

PepperDash Mobile Controlhttp://www2.pepperdash.com/learn-about-mobile-control™ - BYOD Crestron Control, no special app required

From: Jonathan Avila notifications@github.com Sent: June 18, 2020 12:40 PM To: PepperDash/Essentials Essentials@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [PepperDash/Essentials] Question - Best practices for customizing the Essentials program (#267)

Hi PepperDash team,

I read through the wiki links and I'm unsure at the moment of what's the right approach to take when wanting to customize the logic of the devices instantiated in the Essentials app if you are planning to stay in the real of S#Pro. For example, adding your own even handlers

Is the right approach to fork the Essentials S#Pro program and add/change logic as necessary, basically using it only as a starting template? If that's the way to go, would you then simply rebase your fork down the line to get fixes or updates to part of the program like PluginLoading or new Room types?

Speaking of Rooms, if you want to create a custom type, would that be best done as a plugin?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/PepperDash/Essentials/issues/267, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AENNGSAXVMRHOH2I4MAA6UDRXJNQNANCNFSM4OCBOKVA.

[jonavila]

Thats for the prompt reply @ndorin. I guess my main question was related to program specific logic like, if I'm trying this for my home system, where to define the action functions that I want to trigger say when a remote control button is pressed or if I create a Crestron CLW-DIMEX-P plugin, where to add the keypad logic for specific buttons. I guess my first thought is to add logic directly in the Essentials program that uses the DeviceManager to get the device by key and in the case of remotes, add an action to each Button.UserObject?

[andrew-welker]

@jonavila Check out the UI classes that are in the Core assembly. There are examples of how we link up UI button presses with methods and functionality in the room classes. We also have some standard extension methods that we use with the Sig classes (Bool/Ushort/StringOutputSigs). For example, using the AddBoolSigAction extension method allows you to add an Action delegate method that takes a bool and does whatever you need to do. Combined with the Feedback classes, it is relatively easy to do what you need to do.

[jonavila]

Thanks all. I was able to create a plugin for a CLW-DIMEX-P and CLC-FANDELVEX devices and load those up to the essentials program. I went ahead and added some classes for custom logic using those new device types and called those at the end of the StartSystem method in ControlSystem.cs.

I guess I could have added this custom logic directly as an additional plugin since devices can be anything right? I may go that route as to avoid modifying directly the Essentials program.

A few things I noticed as I was building the plugins:

• I attempted to use the Feedback classes for these Crestron devices with the intention of hooking up the dimmer's load LevelFeedback to the fan's light load input level. This would work but I didn't see how I could use the ramping info from the dimmer to create the ramp on the fan load if I wanted a smooth transition. I had to keep a reference to the Crestron loads to hook those up since the LoadStateChange event does not trigger level changes as the load is ramping.
• For the dimmer keypad buttons, I needed different actions for different eButtonState values. So a HELD button may have raised the load while a HELDRELEASED would stop the raise. My first thought was to create button extension methods for the different eButtonState values, but then realized that the Button.UserObject would only hold the last action added. I guess I could have added a Collection of actions keyed by eButtonState to the UserObject but I ended up just creating a single extension method that would pass receive the eButtonState and then do if/else or switch for the different states.