Announcement

Collapse
No announcement yet.

Can our Device (the root) have a status?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Dr. McKay
    replied
    Unless it changed dramatically for the better in the past two years, HASS is still way too immature to be a decent competitor to HS in my opinion.

    Leave a comment:


  • alexbk66
    replied
    Originally posted by Rick Tinker View Post
    Everybody said that when (20 years ago) HS went from 1 to 2 and from 2 to 3.
    The only difference is - HASS (and others) didn't exist back then. Now they do.

    Leave a comment:


  • Rick Tinker
    replied
    Originally posted by MattL0 View Post
    That’s HomeSeer, the irony here is they act with us like a parent-child relationship. They will just loses consumers over time. Do they care, I do not know. I guess hs4 will be the last version...
    Hee hee - sorry, had to chuckle at this one. Everybody said that when (20 years ago) HS went from 1 to 2 and from 2 to 3. The later part of 1 (1.7?) is when the plug-in API was created.

    I fight app UI changes in my mind all the time; most of the time I cannot figure out why a UI that people are used to has to change, but it is what it is. I worked alongside Rich for 13 years and I did not always agree, but I did always respect his decisions and sometimes I was wrong. We all hate change... but - I think that having gone through 1 to 2 and 2 to 3, that to suggest going from 3 to 4 will wipe them out is a bit of a chuckle to me.


    Leave a comment:


  • alexbk66
    replied
    Originally posted by happnatious1 View Post
    When I look at the plugin now using HS4 grid view it looks like treble is the primary feature, how did that happen?
    They pick the features to display in grid view based on what type/subtype you set on each feature - the enums from Devices/Identification folder in PluginSdk.
    I.e. for volume control to display in grid view the "feature" device should have type/subtype (EFeatureType.Media, EMediaFeatureSubType.PlayerVolume)
    Since their selection logic is not documented (and will never be) - it takes trial and error to get it right (as close to right as possible).

    Leave a comment:


  • happnatious1
    replied
    With my monoprice amp plugin I gave up trying to conceptualize how it should be constructed with the new API.
    It's an amplifier with 6 zones each having multiple controls.
    The amp itself has features such as "all zones off" but then each zone has "on/off"
    so is the amp the root of all it's features and zones or is each zone a root? Amps can be daisy changed for up to 18 zones, so when someone adds an additional amp who's the root now? What about multi instance? I heard that has gone away. So if I have two chains of 3 amps for a total of 36 zones what should the root be?
    I just don't get it.

    When I look at the plugin now using HS4 grid view it looks like treble is the primary feature, how did that happen? When I click on any of the place holders at the top for things like power, balance, treble, etc.. it bring up a menu that has all the features on it, but if I click on controls I just get treble? That doesn't make sense, if anything it's backwards.

    What I decided to do is just use the HS3 method of things then I tell my users to run the "fix parent child relationships" tool under labs and ignore the grid view. If you don't like it I'll give you your money back. (It's a free plugin, ).

    Leave a comment:


  • kriz83
    replied
    Originally posted by MattL0 View Post
    I’ll finish this there , the comment will be moderated anyways.
    It might not me moderated, since the development section is almost entirely ignored by HST :-)
    Same as with GitHub ...

    All joking aside, I feel your pain...

    Leave a comment:


  • Guest's Avatar
    Guest replied
    That’s HomeSeer, the irony here is they act with us like a parent-child relationship. They will just loses consumers over time. Do they care, I do not know. I guess hs4 will be the last version...Realistically, they can’t compete with new platform... and if they would wanted to .. it would take a complete rewrite of hs. Hs seems to have added wrapper to another wrapper since the beginning with their code, and doing half projects (hsmobile, hstouch, hs4). I am pretty sure the limit doing that is in a near future.

    I’ll finish this there , the comment will be moderated anyways.

    Leave a comment:


  • kriz83
    replied
    Originally posted by MattL0 View Post
    Nope, not implemented
    This is pretty sad. We asked for it more than a year ago :-(

    Leave a comment:


  • alexbk66
    replied
    Originally posted by MattL0 View Post
    I think thia is an attemps to seduce new users.

    people without automation background will think about a device and what features it permits... so it is easier for them to associate this construct with real devices.
    For the end user they could call it whatever they want, but in the source code it still should be parent->children->more children

    Leave a comment:


  • Guest's Avatar
    Guest replied
    I think thia is an attemps to seduce new users.

    people without automation background will think about a device and what features it permits... so it is easier for them to associate this construct with real devices.

    They won’t think about parent and child in real world. So in hs3, they might have to learn the concept.



    That said, ... I do prefer the old parent child system. I would have like 150 devices less...and it was easier to threat the parent as a categories of something with virtual devices. Ex : lan as a root, all the mac adress as children.
    Fortunately , Jon00 grouping package still allow this. But it take a ‘’lot’’ more step ( removing association of all devices first) .

    Leave a comment:


  • alexbk66
    replied
    I think the way they've done it in HS4 is completely stupid (I know, I know, I will be called bad apple). Why limiting to Device/Feature relationship? The whole archtecture is based on this assumption that the device can be either "device" or "feature". Why not just have parent/child relationships. Even for now if there's only one child level is supported - they could enforce it.

    But at least it would be open for future support of multi-level relationships. Like Shelly 2.5 - there's the device root, then two relays roots, then children for each relay.

    With current HS4 approach - if they decide to support multi-level relationships - every plugin will have to be re-written. Again.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Nope, not implemented

    Leave a comment:


  • jasv
    replied
    Originally posted by rjh View Post
    Our goal with HS4 was that the root device is just a descriptive device, so in some UI's it will not have the space to display any status (like HSMobile). This is not an issue though as we will soon allow you to specify a primary feature device to display in the UI. We currently automatically pick one. Once you have this, create a feature as your status, set this as the primary, and it will display in the grid under the device name (which comes from the root).
    Did the "specify a primary feature" get implemented? If so can someone let me know how to use it?

    Leave a comment:


  • rge
    replied
    Originally posted by steve6341 View Post
    There is an exceedingly "hacky" method I have been using to achieve what some folks are looking for here - displaying a single device with its feature on a single line with status and controls or however you'd like to describe it: The buttons to control the widget, the status of the widget, and it's description are all displayed in a single rectangular grouping unit on the devices page.

    The single device that I create with my plugin would ordinarily look like this using the new API:

    Click image for larger version  Name:	before.jpg Views:	57 Size:	25.8 KB ID:	1414184

    Instead it looks like this:

    Click image for larger version  Name:	after.jpg Views:	50 Size:	12.2 KB ID:	1414185

    This is achieved by modifying the devices.html page. I have added some logic to look for devices with a single feature that has the same name as the parent device. Then essentially create the root device with the buttons, etc from that feature and never create the feature on the screen.

    Code:
    {{-for d in devices_local-}}
    {{use_child=false}}
    {{if !((user_has_access_for_display d.ref user)=='checked')}}
    {{break}}
    {{end}}
    {{if !(d.children[0] == null)}}
    {{if (d.children[0].name == d.name)}}
    {{use_child=true}}
    {{end}}
    {{end}}.........
    Then this further on down the line when the controls are drawn

    Code:
    <div id='controlsallrt_{{d.ref}}' class="col-md align-items-center">
    {{if (use_child==true)}}
    {{controlsall d.children[0].ref}}
    {{else}}
    {{controlsall d.ref}}
    {{end}}
    </div>
    And this to prevent the child objects from displaying on the screen

    Code:
    {{if !((user_has_access_for_display c.ref user)=='checked') || (use_child==true)}}
    {{break}}
    {{end}}
    This has not been thoroughly tested. I am guessing this probably introduces some interesting problems, like using the bulk edit feature?? Maybe this will inspire someone else to come up with a better solution. It seems like there should be an easy "fix" to this issue by modding the html template for the devices screen.


    A far simpler method is to change the relationships (I posted a simple script and jon00 has a full UI-enabled script) so the thing you want to display is a parent, and you can also add other related devices (e.g. power, voltage) as children. Also you can then hide stuff you don't want using the standard control.

    I can't see how a single level relationship is ever going to work with Z-Wave, particularly for something like a two-relay switch where what you really have is:

    - Z-Wave root
    ---- switch 1
    ------- amps 1
    ------- power 1
    ---- switch 2
    ------- amps2
    ------- power 2
    ---- temperature
    ---- misc Z-Wave status device etc

    Changing the relationships you can set this nicely to:

    - switch 1
    ---- amps1
    ---- power1
    - switch 2
    ---- amps2
    ---- power1
    - temperature
    - Z-Wave root (hidden)
    ---- misc Z-Wave status device etc

    Leave a comment:


  • steve6341
    replied
    There is an exceedingly "hacky" method I have been using to achieve what some folks are looking for here - displaying a single device with its feature on a single line with status and controls or however you'd like to describe it: The buttons to control the widget, the status of the widget, and it's description are all displayed in a single rectangular grouping unit on the devices page.

    The single device that I create with my plugin would ordinarily look like this using the new API:

    Click image for larger version

Name:	before.jpg
Views:	220
Size:	25.8 KB
ID:	1414184

    Instead it looks like this:

    Click image for larger version

Name:	after.jpg
Views:	202
Size:	12.2 KB
ID:	1414185

    This is achieved by modifying the devices.html page. I have added some logic to look for devices with a single feature that has the same name as the parent device. Then essentially create the root device with the buttons, etc from that feature and never create the feature on the screen.

    Code:
    {{-for d in devices_local-}}
         {{use_child=false}}
         {{if !((user_has_access_for_display d.ref user)=='checked')}}
         {{break}}
         {{end}}
         {{if !(d.children[0] == null)}}
             {{if (d.children[0].name == d.name)}}
                 {{use_child=true}}
             {{end}}
         {{end}}.........
    Then this further on down the line when the controls are drawn

    Code:
    <div id='controlsallrt_{{d.ref}}' class="col-md align-items-center">
    {{if (use_child==true)}}
         {{controlsall d.children[0].ref}}
    {{else}}
         {{controlsall d.ref}}
    {{end}}
    </div>
    And this to prevent the child objects from displaying on the screen

    Code:
    {{if !((user_has_access_for_display c.ref user)=='checked') || (use_child==true)}}
    {{break}}
    {{end}}
    This has not been thoroughly tested. I am guessing this probably introduces some interesting problems, like using the bulk edit feature?? Maybe this will inspire someone else to come up with a better solution. It seems like there should be an easy "fix" to this issue by modding the html template for the devices screen.



    Leave a comment:

Working...
X