FEEDBACK: What is holding you back from HS4?

[w.vuyk]

Rich,

Like I said the issues I mentioned in post 6? I am not complaining, but hoping to get clear answers and pointing at issues that need attention to get the plugin sold?
Github issues prioritized below:

Very important for my conversions: https://github.com/HomeSeer/Plugin-SDK/issues/75
Most important question: https://github.com/HomeSeer/Plugin-SDK/issues/71
Most annoying: https://github.com/HomeSeer/Plugin-SDK/issues/68
Bothering existing users with existing events: https://github.com/HomeSeer/Plugin-SDK/issues/72

This and the plugin submittal page issues I mentioned in my earlier post would really help me/

[jseer]

• production HS4 plugin version 4.0.0.4 submitting 4.0.0.10 gets complains that beta version is lower then production version (known by Jon)
• Production HS4 store picture, features and description are not published in the store (known by Jon)

Wim, working on getting #1 fixed asap. As for #2, that will be fixed prior to release of HS4.

~Jon

[enigmatheatre]

One thing that is stopping me is TextBox entry in the device manager is not registered as a string change and is not calling HSEvent.


I also agree that the documents could do with someone looking over them and adding some examples and checking it is correct. I like to see comments on what each method will do and a small example is even better. see below for an example that is almost good but what are the params? I know as I have used them in HS3 but new developers will be lost. AbstractPlugin.HsEvent Method

Skip to end of metadata

• Created by Jon-Luke West, last modified on Sep 09, 2019

Go to start of metadata
When you wish to have HomeSeer call back in to your plug-in or application when certain events happen in the system, call the RegisterEventCB procedure and provide it with event you wish to monitor. See RegisterEventCB for more information and an example and event types.
The parameters are passed in an array of objects. Each entry in the array is a parameter. The number of entries depends on the type of event and are described below. The event type is always present in the first entry or params(0).
Parameters

eventType
Type: HSEvent
The type of event that has occurred
params
Type: System.Object[]
The data associated with the event
Implements

IPlugin.HsEvent(HSEvent,Object[])

[alexbk66]

Rather than spending a week writing docs that only address a portion of your issues, please post what you need in order to finish your port, or work on a new plugin and we will do our best to assist.

That's not quite correct:
1. You should know better what we need. That's like you come to the doctor, but he/she tells you - you better tell me what treatment you need.
2. A week? You had at least 5 months since you informed the developers about HS4.
3. And again, you promised (or jseer ) to at least document your own experience porting Z-Wave plugin to HS4. Is it done somewhere?

[rjh]

No, I don't know what you need. As I said, let me know exactly what you need and I will see what I can do. Ideally, if you are working on something specific like a specific type of feature page we can put together a sample and add it to the sample plugin. We do have a page with details on porting a plugin, I will see where that is at.

That's not quite correct:
1. You should know better what we need. That's like you come to the doctor, but he/she tells you - you better tell me what treatment you need.
2. A week? You had at least 5 months since you informed the developers about HS4.
3. And again, you promised (or jseer ) to at least document your own experience porting Z-Wave plugin to HS4. Is it done somewhere?

[rjh]

We are going through github issues today.

Rich,

Like I said the issues I mentioned in post 6? I am not complaining, but hoping to get clear answers and pointing at issues that need attention to get the plugin sold?
Github issues prioritized below:

Very important for my conversions: https://github.com/HomeSeer/Plugin-SDK/issues/75
Most important question: https://github.com/HomeSeer/Plugin-SDK/issues/71
Most annoying: https://github.com/HomeSeer/Plugin-SDK/issues/68
Bothering existing users with existing events: https://github.com/HomeSeer/Plugin-SDK/issues/72

This and the plugin submittal page issues I mentioned in my earlier post would really help me/

[rjh]

Ok, I added the HSEvent issue into our tracking system as HS-522 and marked it as critical. It may not make it into the update going out today but for sure it will be in the next one.

One thing that is stopping me is TextBox entry in the device manager is not registered as a string change and is not calling HSEvent.


I also agree that the documents could do with someone looking over them and adding some examples and checking it is correct. I like to see comments on what each method will do and a small example is even better. see below for an example that is almost good but what are the params? I know as I have used them in HS3 but new developers will be lost. AbstractPlugin.HsEvent Method

Skip to end of metadata

• Created by Jon-Luke West, last modified on Sep 09, 2019

Go to start of metadata
When you wish to have HomeSeer call back in to your plug-in or application when certain events happen in the system, call the RegisterEventCB procedure and provide it with event you wish to monitor. See RegisterEventCB for more information and an example and event types.
The parameters are passed in an array of objects. Each entry in the array is a parameter. The number of entries depends on the type of event and are described below. The event type is always present in the first entry or params(0).
Parameters

eventType
Type: HSEvent
The type of event that has occurred
params
Type: System.Object[]
The data associated with the event
Implements

IPlugin.HsEvent(HSEvent,Object[])

[rjh]

#1 is a work item that we need to get to, and yes we want to offer an API for this.I have made sure this is in our tracking system, logged as issue HS-523
#2 I am going to work with you on this. I have some of it documented, will get with you soon. I have to travel for 2 weeks, but I am working, albeit off and on.
#3 I have done some pages where I needed to dynamically change content and have the tags regenerate code, I will add an example to the docs.
#4 I think I touched on HSTouch in another post, but I want to stay with what we decided for HS3 where media is handled with devices. But if that is not working as is, let me know what we need to change.
#5 Can you move the HS3 root device to a feature when you do an upgrade? Create a new root then take the old root and make it a child to that root? That way if the user was referencing that device the device ref stays the same. When you say "events", do you mean plugin triggers and actions? If you mean standard HS4 events, then they should just work if you don't change the device refs or the control pair values.

1/ Speakproxy support. Believe you were going to simplify the interface which is currently the HSTOUCH.SpeakerClient
2/ Player Device tile view
3/ I'm still struggling with creating html pages, especially doing AJAX updates on sections which are created with scriban enumerations and liquid tags. How do you re-generate a section like to that have it dynamically updated
4/ Do we have any idea what is to become from HSTouch? Is the mediaAPI completely dead or are you guys thinking about something else allowing your users to create great mediacontrol screens?
5/ how do we migrate our users from HS3 to HS4, especially when controls on root devices need to turn into features etc. I'm also not clear on how events created in HS3 migrate to how it is suggested to be used in HS4

[kriz83]

For my new plugin (not a HS3 port), is there an indication when we can expect the main feature selection ? Also I need to get the colorpicker working. Holding me back for migration: missing linked devices and the NEVER action.

[enigmatheatre]

Ok, I added the HSEvent issue into our tracking system as HS-522 and marked it as critical. It may not make it into the update going out today but for sure it will be in the next one.

rjh

Thank you for your reply.

This might help track the textbox bug.:https://forums.homeseer.com/forum/de...when-submitted

Greig.

[dcorsus]

#3 I have done some pages where I needed to dynamically change content and have the tags regenerate code, I will add an example to the docs.

Great thanks. I do want to add some clarification about what I'm struggling with, as this might just be a decision to go one way or another.

I'm creating the HTML file (page) which represents the controls associated with a media device, including things like navigation controls to navigate and select content, queue views, player controls, what's playing etc.
I began creating html pages and began using scriban and liquid tags to create tables with content, art, clickable items etc. So far all good. In order to play nice with bootstrap there are a lot of attributes used.

SO ..... when something changes and I want to use AJAX to update the absolute minimum, say an item was changed to the Queue list, or perhaps another song is playing and I want to highlight the item in the queue currently being played, short of now moving exactly the same code (scriban do loops, bootstrap attributes, resolved liquid tags ...) into my PI so I regenerate the div section that encompassed the queue (table element), I fail to see why I would even try to do it in the HTML code. I studied (or at least tried) your devices.html code, as far as I can tell, you use hsref ids to uniquely identify divs, I guess I'm not as lucky as there is a lot more going on. Regenerating the full page, isn't an option, especially when you just navigated content, say a list of 1000 tracks that you don't want to have regenerated because something with the queue changed!

So the question I have and if your example answers that questions then that would be great, the question is: should I perhaps NOT use any code in my .html file and just code up call backs and generate html (as it was in HS3) in my PI? I suspect you have ran into similar issues, for example the album art suddenly changes size on tile view, suspect because your ajax regen code is different from what is in the devices.html file. I also on occasion note "flickering" which I suspect is that the whole page is refreshed.

#5 Can you move the HS3 root device to a feature when you do an upgrade? Create a new root then take the old root and make it a child to that root? That way if the user was referencing that device the device ref stays the same. When you say "events", do you mean plugin triggers and actions? If you mean standard HS4 events, then they should just work if you don't change the device refs or the control pair values.

Some clarification: are you suggesting I add this with an HS3 to HS3 upgrade, something I put in my legacy code to prep for a seamless HS4 migration or were you referring to migration code that ONLY runs the first time when my HS4 PI starts up and detects HS3 kind of information? I suspect the latter. The proposal to create a new root and then make the old root a feature to the new root is very attractive. Could you confirm that you have NO attribute that declares a DB entry to be a device versus feature. As I wrote somewhere, I seem to recall in the earlier days when I was converting my PI to HS4 "style" that it complained when I tried to use a devices as a feature or vice-versa.

As to events, I like to hear other people's experience. I might have been very confused about the different call back in HS4 over HS3 as to how I craft the event/action data. Maybe it was because the classes for TAction etc. changed so I interpreted that all the data-structure for an action was totally different. You seems to suggest it isn't? What am I missing?

[alexbk66]

Some clarification: are you suggesting I add this with an HS3 to HS3 upgrade, something I put in my legacy code to prep for a seamless HS4 migration or were you referring to migration code that ONLY runs the first time when my HS4 PI starts up and detects HS3 kind of information? I suspect the latter.

No, I think the suggestion is to modify HS3 code so your root doesn't have any controls - then it's cleaner migration to HS4 - when users upgrade from HS3 to HS4.
I guess I also have to do it in all my HS3 plugins

[pcp]

Rich,

While I am still exploring (trial / error) the HS4 SDK before adopting any real implementation of my six plugins, below are some observations

• Missing features or deprecated ones especially single exe multiple instances which require re-design / re-write of several of my plugins. Not sure about SpeakProxy support changes as I have not looked into it but would be important for one of my plugins.
• Adaptation to device-feature model and understand UI outcome / layouts. There is a relationship between the device-feature (with and without controls) structure and presentation/usability in the (tile) UI. More examples (code snippets and UI mockups) and documentation on how device-features should be constructed for optimal usability (in list view, tile view and HSTouch). For example should there always be a device without feature and control? If all are features with a dummy device, how can I control what is displayed in tile view for an optimal usability (status and controls and avoid many extra clicks/navigations for users)? Another example to better document is the location 1/2 which in HS3 might be different on child devices versus the parent device in several of my cases. To accommodate the device-feature and related changes a reasonable amount of time I spent on my HS3 setups and plugins (6 of them) to try to accommodate for this change but not if I took the right approach.
• Is the media API dead and/or how will it be leveraged and how a plugin implementation needs to change to support the list view, tile view and HSTouch UI? Before rewriting one of my plugin understanding this (with examples of how the UI will be rendered in each) is important.
• How to move HS3 users to HS4 in an automated and transparent way (device-feature, possibly events) and requires plugin developers to maintain two code basis for a while.
• As someone else was saying the HS3 plugin work in HS4 (even if usability due to UI integration is not optimal). Moving all of my plugins to the HS4 SDK is a lot of work (re-design, re-coding, testing, dual code maintenance) due to the amount of changes and not just an evolution of the HS3 code without being clear on the benefits at the end (from a functionality, usability, ..). Why do all plugins need to be rewritten from scratch for the new SDK (6 of them for me with three requiring re-design due to missing single exe multiple interface feature). Could’t the new UI support have been extensions to the prior HS3 core plugin functionality / APIs? It will take time to transition.
• Additional documentation and (more complex) plugin examples would help.

[Michael McSharry]

As to events, I like to hear other people's experience. I might have been very confused about the different call back in HS4 over HS3 as to how I craft the event/action data. Maybe it was because the classes for TAction etc. changed so I interpreted that all the data-structure for an action was totally different. You seems to suggest it isn't? What am I missing?

I found the actions and triggers to be easier in HS4 than HS3. For device-oriented conversion the general strategy was to copy the HS3 code and then modify it to comply with HS4 SDK. For actions and triggers that approach does not work. It is better to start with the example provided by HST and then paste a little bit of the original event code from the HS3 plugin. I provided a step by step at https://forums.homeseer.com/forum/de...-action-to-hs4 for actions and a similiar one for triggers.

[shill]

#3 I have done some pages where I needed to dynamically change content and have the tags regenerate code, I will add an example to the docs.

This would be very helpful.