Any chance of really discussing this "main device" and "features"?

[sirmeili]

The title says it all.

I know I've been MIA (Been killing myself at my day job), but I still find myself thinking about how devices will work in HS4. Do we really have to go to a model where the UI dictates the device model? Shouldn't the device model be simple and the UI be flexible enough to handle it? My first love of HS3 was that each device was a value and/or a control. That is to say that if a piece of hardware had 3 status, 2 of which were controllable, you would end up with 3 devices in HS.

Device 1 - status only
Device 2 - status, with controls to control it
Device 3- status with Controls to control it

With HS4 I will end up with 6 devices (if I'm reading it right):
Device 1 - main device
Device (Feature) 2 - Status 1
Device (Feature)3 - Status 2
Device (Feature)4 - Status 3
Device (Feature)5 - Control for Status 2
Device (Feature)6 - Control for Status 3

For instance, you already support the old model by allowing HS3 plugins, why the push to move from 1 device for a status and value? What is the real benefit of now having to have 2 devices if I have a device that has a status and a value (i.e. a light bulb)?

Just seem that the old model was cleaner and allowed more flexibility overall. Anyone (Especially HST) have any thoughts on this?

Basically it seems like it's Form over Function to me. Seems like you've created a device model that you think best works with your mobile design. It seems like you're going Mobile first. Not that Mobile is bad, but I don't think the product should center around it. If so it looks like you're lowering yourself to the lowest common denominator of people who want to control their house, not automate it.

Not looking to put HST down, looking to see if it's possible to discuss the device model or if it's set in stone and the implications of that

[dcorsus]

Can't talk to why a device doesn't really have anything anymore but to compare my HS3 versus HS4 implementation, they are actually almost 100% identical.

In HS3, I had a root device with a bunch of controls on them and a status and then close to 20 child devices that had the root device as a parent, and that made up a player in all its controls. In HS3 there were device and subdevice classifications, they are now called identifications. It was in fact the intention already in HS3 that by creating parent and children that tools like HS Touch could use the associations and easy but great media control screens, it just never happened.

In HS4, the only difference is actually that the root device became 2 objects, one a device and the second object became a feature to host the controls and status and all the child devices I had in HS3 are now features attached to that root devices. I really can't say what it really solved but when the dust settled (for me) the difference was minute. In fact features have reference ids, exactly the same as devices, so my HS3 code, almost completely remained intact. It was just the way of creating and updating these devices/feature that had a bunch of changes in them, and in my opinion they remained the same complex to create, just different complex from HS3 .

At this point, almost all of the HS3 functions are working and the HS4 version is getting close to "updated", which meant rewriting the multipleinstancesingeExe into no more instances but internal classes; rewriting creating and updating devices, rewriting all config pages and re-writing triggers and events.

One benefit right off the bat is that a media device (basic functions) can now be nicely presented.






My $0.02

Dirk

[dcorsus]

Here's another view. First picture is HS3 as is, no modification running in HS4 with list view




Or the HS4 view, just creating all the children as features ....



Not a lot of difference, which you can see as good an bad

[alexbk66]

Not a lot of difference, which you can see as good an bad

Two "would be nice to have" features from your HS4 screenshot:

1. Ability to re-order (or group) features would greatly improve usability
2. Ability to change buttons labels - i.e. rename "UP" and "DOWN" buttons to "LEFT" and "RIGHT" for balance control, etc.

[spud]

The title says it all.

I know I've been MIA (Been killing myself at my day job), but I still find myself thinking about how devices will work in HS4. Do we really have to go to a model where the UI dictates the device model? Shouldn't the device model be simple and the UI be flexible enough to handle it? My first love of HS3 was that each device was a value and/or a control. That is to say that if a piece of hardware had 3 status, 2 of which were controllable, you would end up with 3 devices in HS.

Device 1 - status only
Device 2 - status, with controls to control it
Device 3- status with Controls to control it

With HS4 I will end up with 6 devices (if I'm reading it right):
Device 1 - main device
Device (Feature) 2 - Status 1
Device (Feature)3 - Status 2
Device (Feature)4 - Status 3
Device (Feature)5 - Control for Status 2
Device (Feature)6 - Control for Status 3

For instance, you already support the old model by allowing HS3 plugins, why the push to move from 1 device for a status and value? What is the real benefit of now having to have 2 devices if I have a device that has a status and a value (i.e. a light bulb)?

Just seem that the old model was cleaner and allowed more flexibility overall. Anyone (Especially HST) have any thoughts on this?

Basically it seems like it's Form over Function to me. Seems like you've created a device model that you think best works with your mobile design. It seems like you're going Mobile first. Not that Mobile is bad, but I don't think the product should center around it. If so it looks like you're lowering yourself to the lowest common denominator of people who want to control their house, not automate it.

Not looking to put HST down, looking to see if it's possible to discuss the device model or if it's set in stone and the implications of that

I think you misunderstood. A HS4 feature can have both a status and some controls. The only difference is that in HS4, a root device can't have any status or controls, so you will have to move those to an additional feature.

[sirmeili]

I think you misunderstood. A HS4 feature can have both a status and some controls. The only difference is that in HS4, a root device can't have any status or controls, so you will have to move those to an additional feature.

Gotcha, Thanks spud that makes mores sense.

[alexbk66]

The only difference is that in HS4, a root device can't have any status or controls, so you will have to move those to an additional feature.

That actually means that HS3 plugins can't work with HS4 without change?

I tried in HS3 the opposite - minimise number of devices by not having "useless" root device. BTW - what's the rationale for the change?

[dcorsus]

Two "would be nice to have" features from your HS4 screenshot:

1. Ability to re-order (or group) features would greatly improve usability
2. Ability to change buttons labels - i.e. rename "UP" and "DOWN" buttons to "LEFT" and "RIGHT" for balance control, etc.

great suggestions. When I posted them side by side last night I noticed I had forgotten balance controls and the up/down buttons for all sliders. They were added in about 30 min and they indeed now (in HS4) read left, right,.

The ability to order is in interesting request or to change button labels. I believe this was something we were able to do in HS3, but haven't seen any config screens in HS4 for this.