search

HomeSeer / Plugin-SDK

Plugin development kit for the 4th major edition of the HomeSeer platform.
https://www.nuget.org/packages/HomeSeer-PluginSDK/
GNU Affero General Public License v3.0
21 stars 4 forks source link

Adding a time block on an action not possible for plugins? #72

Closed wvuyk closed 3 years ago

wvuyk commented 4 years ago

In HS3 I have several actions using a time selector. For postponing an action, or setting a end time on an animation. In HS4 I see this timeselector on actions for devices, but I cannot find a way to add this through my plugin. Is this function yet to be implemented in the PluginSDK?

image Sample of HS3 action with time selection

image Sample of HS3 action with Timespan selection

image Sample of HS4 device action with Timespan selection

Can we please get these selectors available for plugin actions?

wvuyk commented 4 years ago

Bumping seems to be needed?

spudwebb commented 4 years ago

yes this is needed, logged as HS-407

wvuyk commented 4 years ago

Spud,

I remember you had it logged it internally for the "after waiting"part based on my forum post after waiting here for some time, but is also including the second method for setting a time?

spudwebb commented 4 years ago

I don't remember your forum post, was it a different issue. What is logged in HS-407 is a request to add a JUI Time Span View, so that it's possible to implement triggers/actions with a time span parameter.

rjhelmke commented 4 years ago

For HS4 plugins you are free to add whatever control you like. For HS4 triggers and actions we are just displaying a textbox and the user can enter the value they need. I would just do that for now. We have yet to find a good time picker that supports seconds. If you only need hours/minutes, you can use this one: https://mdbootstrap.com/docs/jquery/forms/time-picker/

wvuyk commented 4 years ago

Rich,

In the PluginSDK we are supposed to use the AbstractTriggerType class right? If I use this I have no opportunity to use my own HTML as we have to use the "ConfigPage" Page view objects? As far I know I cannot add my own controls here? There is an inputview, toggleview and a labelview. That is all. I have based this on the sample plugins. If there is a way to add my own controls, I really would like to know?

Aside from that, please help me out? I know you added a solution for device actions by using three columns with input fields, I do not see how I can do the same here in a plugin. If I add an inputview here, it is taking a whole line, not a column. How can I set this, I did search documentation a lot, but there is no guide helping me out on this?

Thanks,

Wim

Wim

jldubz commented 4 years ago

@wvuyk the Plugin SDK is open-source and you are invited to extend the AbstractView class to create your own controls. Anything you build into the Plugin SDK will work locally and then Pull Requests will be considered so everyone can take advantage of more standard controls. This issue is referenced by PSDK-58

I have a listed to-do item to write up more code style and contribution guides at some point; so let me know if you would find this useful sooner than later and I can prioritize it more.

This date/time picker is on the road-map and referenced by PSDK-1, but I cannot speak to exactly when it will be implemented by the HomeSeer team.

Aside from that, please help me out? I know you added a solution for device actions by using three columns with input fields, I do not see how I can do the same here in a plugin. If I add an inputview here, it is taking a whole line, not a column. How can I set this, I did search documentation a lot, but there is no guide helping me out on this?

There is no built in structure through JUI, at this time, to support multiple columns of data. All of the action and trigger types native to HomeSeer are built by Rich in HTML. It might not be a bad idea to create some kind of input view group or permit you to use group views to generate small grids or controls using the bootstrap row-column classes. PSDK-57

Reasons for JUI

The major reason why we opted for a structured view architecture like this is to avoid issues that have been encountered in the past when a plugin assembly changes or is removed, causing custom elements to throw errors as HS core tries to find the assembly to use for deserialization etc. This whole situation is anything but graceful from a code, computer resource, and user perspective. To mitigate this, JUI was created so any of the common items that users interact with (Events, Devices, and Plugins) that store data in HS core can still be read and analyzed with or without the corresponding plugin assembly. Some of the benefits to this include the ability to easily open all of these components up to cross-plugin scripting without requiring tight assembly version linking and a more uniform look and feel to all of the "common areas" of the application.

Tangent thoughts and ideas...

Another possible direction would be to allow HS core to accept View definitions up front in a similar way to the action and trigger types. These definitions might include a structured implementation of a ToHtml() method and ToJson() method allowing for plugins to register custom view types that can be used throughout the application, including by other plugins. This might present the same problems as stated above, but a workaround would be to define a default fallback view for undefined views that allows you to manipulate the JSON directly if desired? This also means we could open up all views to see the JSON code behind if desired. Ideas, ideas, ideas...

wvuyk commented 4 years ago

@jldubz

the Plugin SDK is open-source and you are invited to extend the AbstractView class to create your own controls. Anything you build into the Plugin SDK will work locally and then Pull Requests will be considered so everyone can take advantage of more standard controls.

This would have been a nice option if I felt at home with C#. But I do not. Up till now I did not feel the need to enter the learning curve to change from VB to C#. I can read it a bit of course, but actually using it is another game.

The challenge is that my users are using the date time picker and timespan entries in their events. When they move to HS4 there is no equal replacement. So that menas I will have to create an alternative with a timespan spread over three space consuming lines to at least give them the possibility to maintain the existing info... Guess that is it. Please let me know when a useable view gets enabled?

Wim

spudwebb commented 3 years ago

A TimeSpanView class has been implemented in PluginSdk 1.3.0.0 / HS 4.1.17.0

https://homeseer.github.io/Plugin-SDK-Docs/api/HomeSeer.Jui.Views.TimeSpanView.html?tabs=cs

Another addition of interest is the GridView class which allows you create group of views like ViewGroup but instead of being displayed stacked, they are being displayed in a bootstrap grid.

https://homeseer.github.io/Plugin-SDK-Docs/api/HomeSeer.Jui.Views.GridView.html?tabs=cs