Announcement

Collapse
No announcement yet.

Can our Device (the root) have a status?

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

    #16
    Originally posted by MattL0 View Post
    I know. But this is the bath they choose.
    like in the z wave plugin. This is two standalones devices
    Yeah, I love status "No Status". What a waste.

    Comment


      #17
      Again, the root is just for the name, it will not say "no status" next to it. You only see that because its an HS3 device. Devices now have a version property and HS3 devices are set as version 3.2 and HS4 as 4.0. We use this to alter the display. If the device was an HS4 device you would not see any status.

      I would stop thinking about a device made up as multiple devices. HS3 called them that and they were all created like devices, but the new SDK abstracts that for you so you don't need to deal with a root device. You create a device and add features to it. If you don't look under the hood (or the HS3 devices page), you would not even know it was 2 devices.
      πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

      Comment


        #18
        All these words don't explain why I heed two devices for single relay.
        You don't need two devices. You have one device, a Relay. The Relay has a feature of being able to be in the open or closed state. Maybe this relay has other features as well such as current sensing, temperature sensing, duration in a state etc.

        You are trying to mix apples with oranges. It would be like saying that you have a collection of widgets. If there is only one widget in the collection then the collection should be changed to behave like a widget. I think you head is still in the HS3 API and not the HS4 API.

        Comment


          #19
          I think what Alex is sawing is that for only one feature, you need to ref numbers. In hs3 you only needed one ref number if your device only had one β€˜β€™feature’’.

          I also think that we need to explain that with apple and orange term ... since both use different paradigm.

          Comment


            #20
            A Device object in HS4 (Orange) is different than a Device Object (apple) in HS3. They serve different purposes even though they have many, but not all of the same properties. Skins (Ref) coincidentally exists in both Apples and Oranges, but they are different. Both Oranges and Apples are good eating, but do taste different. If you plant Oranges in cold climates they do not do very well. If you try to make a HS4 with only Apples you will also not do very well. The HS3 Device seed will grow both Apples and Oranges, but you need a special environment (HS3) to cultivate both Apples and Oranges from the same HS3 seed.

            Comment


              #21
              Mike has the right idea, and just to re-iterate what I posted. Yes, under the hood there will be 2 refs, but that is only because we needed to use the HS3 API for devices so as to not create an entire new API for devices. When you create devices with the HS4 plugin API the refs are pretty hidden so it really doesn't add much overhead to your code. The ref for the root is never used as you would not have a reason to mess with the root once created. HS deals with managing it (like name/location/settings etc.).
              πŸ’‍♂️ Support & Customer Service πŸ™‹‍♂️ Sales Questions πŸ›’ Shop HomeSeer Products

              Comment


                #22
                For a cleaner look in HS4 and to reduce new user confusion why not get rid of the icon and the No Status so it looks like the title for the device and children and not another configurable device?

                Comment


                  #23
                  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:	309
Size:	25.8 KB
ID:	1414184

                  Instead it looks like this:

                  Click image for larger version

Name:	after.jpg
Views:	293
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.



                  Comment


                    #24
                    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

                    Comment


                      #25
                      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?
                      James

                      Running HS 3 on Win10 .

                      Comment


                        #26
                        Nope, not implemented

                        Comment


                          #27
                          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.

                          Comment


                            #28
                            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) .

                            Comment


                              #29
                              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

                              Comment


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

                                Comment

                                Working...
                                X