Looking for HST Input: How would this device work in HS4?

[sirmeili]

I'm refactoring a plugin for HS3 that i got from simplextech* I want to know how this would work in the new "design" pattern for devices. I currently have a Root for each User and under each user as child devices there can be a ton of optional other devices for different stats. Would these "children" now be "features"? Here is a screenshot:



*Some will ask why I'm refactoring for HS3 instead of going to HS4 directly. To put it simply, I have a library that I use for HS3. I may update that in the future for HS4, but for now, it allows me to create plugins pretty fast for HS3. I'm merely refactoring this plugin to use that library and to better understand the API since I didn't write the plugin originally.

[Michael McSharry]

The design choice is yours. HS4 is Device (root/parent) oriented with Features (children) a little awkward to access. I suspect a ton of features would be hard for the user, but likely easier for you. I have been doing a similar thing with mcsMQTT over the months so the HS3 version will structure Devices and Features similar to HS4. In my case there are typically a handful of Features per Device. Some have only one and others have scores of Features.

I have considered splitting up some of the Hubitat plugin (from John) capabilities for multiple HS Devices per Hubitat Device. Echo Speaks, for, example has a potential of 50’ish Features. Some are for Text to go to Echo speaker. Some are for feedback and control of music and there are others. With a half dozen Echo’s it is a lot of data to expose to HS and it will be a compromise no matter what design choice is used.

The biggest driver is that Devices in HS4 do not show status or have controls. These capabilities are reserved for only Features.

[sirmeili]

Not sure I unerstand that last comment. So Features can have controls and statuses, but not the Root? Lets take MeiHarmonyHub for instance. My guess is that this grouping for a Hub would have to be split up into multiple device/features? or would it still work as 1 grouping like this?



If I remember correctly, in this case, I would need a new device/feature for each of the devices above (even though they belong to the same hub). Obviously this is a different case than the Withings plugin since all those devices have an action.. I guess I could wrap my head around that, but I will have to see how it affects my development if/when I get to an HS4 plugin.

I was hoping to some degree that they would find a way for us to create custom layouts for the "devices" like they do for thermostat. that would allow much more flexibility for us devs I think.

[simplextech]

I was hoping to some degree that they would find a way for us to create custom layouts for the "devices" like they do for thermostat. that would allow much more flexibility for us devs I think.

This is I think part of the overall problem.... You can't provide customized flexibility AND have a consistent UI. Everything must become generic and operate the same way to display the same way.

You either have a custom UI designer like before with HSTouch and have total flexibility of the devices and data or you shoe horn everything into a single structure to make UI presentation consistent and easy to handle. Current direction/goals of HS is for ease of use and consistent UI.

[sirmeili]

This is I think part of the overall problem.... You can't provide customized flexibility AND have a consistent UI. Everything must become generic and operate the same way to display the same way.

You either have a custom UI designer like before with HSTouch and have total flexibility of the devices and data or you shoe horn everything into a single structure to make UI presentation consistent and easy to handle. Current direction/goals of HS is for ease of use and consistent UI.

I think allowing the developer to lay out how a device group displays in HSMobile should be doable. They do it for Thermostats. My guess is they shoehorned it in instead of making it generic enough to work for other device types (purely a guess). Not asking for a purely custom layout, but for plugin devs to layout how their complex devices display in the mobile app (which would only benefit HSMobile)

[Michael McSharry]

For MeiHarmonyHub the minimum you need to do is create a new feature that contains the controls you now have in the root. All the existing children will remain features.

HS4 has a Tile view and a List view. List view would be similar to HS3 deviceutility with the root and grouped under it in individual rows are the features. The Tile view would contain one tile for the root and a set of icons at the top of the tile for the features. Multiple clicks to view or control a feature from the Tile view. Sorting and Filtering are evolving.

[sirmeili]

For MeiHarmonyHub the minimum you need to do is create a new feature that contains the controls you now have in the root. All the existing children will remain features.

HS4 has a Tile view and a List view. List view would be similar to HS3 deviceutility with the root and grouped under it in individual rows are the features. The Tile view would contain one tile for the root and a set of icons at the top of the tile for the features. Multiple clicks to view or control a feature from the Tile view. Sorting and Filtering are evolving.

Thing is I can't create 1 device with all those controls. So I guess the suggestion would be to split them out. I only grouped them so it wouldn't be confusing as to which hub they belonged to. However things like the the sleep timer really should be part of the main hub, but once again, can't really share a "control" unless they've completely changed how statusvalues work.

[dcorsus]

It really isn’t that much different. As Michael states, the list view is pretty much the same as HS3. The only major difference is that in HS3 you had children and in HS4 they are features, but it is pretty much 100% the same. What is a bit different is that you cannot put controls in your parent/root device but that was a minor change for me, where I created one more child (feature) and moved the root controls to that feature and they all looks the same

[sirmeili]

It really isn’t that much different. As Michael states, the list view is pretty much the same as HS3. The only major difference is that in HS3 you had children and in HS4 they are features, but it is pretty much 100% the same. What is a bit different is that you cannot put controls in your parent/root device but that was a minor change for me, where I created one more child (feature) and moved the root controls to that feature and they all looks the same

My concern is with the mobile view. I remember the mobile view not handling it very well early on (granted this was 6 months ago). I will try and install the newest beta just to see. For right now I don't really want to upgrade my plugins to HS4, I would prefer the HS3 ones just work for now.

[sirmeili]

Anyone from HST want to add their input? jseer JLDubz rjh

[rjh]

Looks like you could do it the same as H3. The root/feature in HS4 is the same as the root/child in HS3. We still have the list view so users could use that if they need to see everything on one page. On the grid view the user would simply click on the top bar and get a scrollable list of the features. You can have up to 2 features in the grid view (1 right now but more coming soon). If there is a feature that you really want to be up front on teh grid view, you could break that out to another device with just that feature. But I don't think that buys you much.

Anyone from HST want to add their input? jseer JLDubz rjh

[kriz83]

Are we still not able to set the main feature ?

[rjh]

We will have this soon. Build 4.0.6.0 has a better auto selection of the primary device.

Are we still not able to set the main feature ?