Announcement

Collapse
No announcement yet.

Can our Device (the root) have a status?

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

    Can our Device (the root) have a status?

    Don't recall but can a device have a state (status?). I know it can't have controls but could it have a state like "on-line", "off-line", "sleeping"?
    I can probably dig through many postings here but maybe somebody knows off-hand and/or implemented state for the "device". The image property is gone but still some default (config) icon shows for the device. What is the recommendation from HS what we should do with it?
    Any help very appreciated.

    #2
    Originally posted by dcorsus View Post
    Don't recall but can a device have a state (status?). I know it can't have controls but could it have a state like "on-line", "off-line", "sleeping"?
    I can probably dig through many postings here but maybe somebody knows off-hand and/or implemented state for the "device". The image property is gone but still some default (config) icon shows for the device. What is the recommendation from HS what we should do with it?
    Any help very appreciated.
    Yeah, root devices can have status.

    And I don't understand what's the reason why root can't have controls? I asked HST rjh many times, but no explanation. I tried to reduce number of HS devices (makes sense?) and use root for control, but I was told I should add another device for control. Why?

    Comment


      #3
      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).
      website | buy now | support | youtube

      Comment


        #4
        rjh Can you explain this s-l-o-w-e-r please?

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

        Comment


          #5
          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).
          Rich you are losing me here a little. If some UIs can't display the device status, then why have things like a primary feature in the first place? I get the principle of allowing the users in the grid view to select what is import and pick a feature per their liking. But if the PI author adds a status to the device, the user wouldn't have to pick anything but could override the grid view if they desire. It appears that on some UIs like HSmobile, you are screwed one way or another, especially when you have devices with a ton of features like in my case.

          I have about 20 features per device, and in my humble opinion it clutters the interface in the most fundamental way.

          What are my options:

          1/ I create less features but I have them all under PI specific actions/events, something actually HS softly recommended against. Moreover, HS Touch screens really thrive around using HS devices (ie features now). That's why I have so many features, like art, album name, track, next track, radiostation name etc. They really clutter the interface but we don't have media or music APIs anymore so what else can I do?
          2/ At some point, I had suggested an author controller "hidden" property, where all this clutter is there to be used for HS Touch designs but everywhere else it is hidden from view and it doesn't show if you click on "unhide". I have more motivation to have a feature like that but too irrelevant to describe here.

          Thoughts?

          Comment


            #6
            Here are some examples: This is pretty much all we need from status

            Click image for larger version

Name:	4S5.png
Views:	220
Size:	64.6 KB
ID:	1396960



            And if you look below, what is in red is by far the most that should show in the regular UI, all else is just for creating HSTouch screens

            Click image for larger version

Name:	4S6.png
Views:	214
Size:	312.5 KB
ID:	1396961

            Comment


              #7
              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).
              I still don't get it Rich, for example my Sonoff relay has on on/off status and control - why do I need two devices for that? Why one simple device with two buttons isn't sufficient?

              Comment


                #8
                I’m with Rich on this. There is a device. The device can have one or more features. The status of the device is meaningless. It is the feature is what is manipulated and what has status. The default UI for a device is a tile. The status reflected in the tile is the status of the priority feature. Supporting features also have status, but you need to drill down to see the lower priority features.

                The mindset needs to change From HS3 where parent/child relationships exist only for display grouping. HS4 has a different way it represents entities. Consistency in honoring the new model has long term benefits. A HS4 plugin is not a warmed-over HS3 plugin, but is a plugin that embraces the new interface model.

                Many analogies are available. Buy a new car and you get a touch screen and need to press multiple buttons just to tune a radio station. Why didn’t the car come with a single knob that only tuned radio on the band that I was familiar? Obviously the new car has new features and the way to get to them is not with many single-purpose buttons, but though a consistent UI that gives access to all available features.

                Comment


                  #9
                  Originally posted by Michael McSharry View Post
                  I’m with Rich on this. There is a device. The device can have one or more features. The status of the device is meaningless. It is the feature is what is manipulated and what has status. The default UI for a device is a tile. The status reflected in the tile is the status of the priority feature. Supporting features also have status, but you need to drill down to see the lower priority features.

                  The mindset needs to change From HS3 where parent/child relationships exist only for display grouping. HS4 has a different way it represents entities. Consistency in honoring the new model has long term benefits. A HS4 plugin is not a warmed-over HS3 plugin, but is a plugin that embraces the new interface model.

                  Many analogies are available. Buy a new car and you get a touch screen and need to press multiple buttons just to tune a radio station. Why didn’t the car come with a single knob that only tuned radio on the band that I was familiar? Obviously the new car has new features and the way to get to them is not with many single-purpose buttons, but though a consistent UI that gives access to all available features.
                  Michael, not sure I agree. My device is a player. At the highest level (device) it has a state ex online , offline sleeping. It affects all features because if the device is off line all the features state and controls are mute.
                  Why would I need yet another feature to show the state of all the features ie the parent device, makes no sense in my mind.

                  Comment


                    #10
                    Some may exhibit this relationship and others may not. Take a simple smart plug that has temperature protection. If temperature is too high then you cannot turn the plug on. Should the temperature status be shown in the parent device because without a low temperature the On feature will not work?

                    There are all sorts of special case situations where one could “optimize” by using a device to serve as a feature as well. What this does, however, is add confusion to the user because the device/feature model will be different for each optimized entity. It is more important that a consistent model is used so the user knows what to expect in every situation.

                    In your media player tile the user will see the online status as you, the plugin author, has decided this is the priority feature. I can imagine where the plugin author will give the user the option to pick what is most important to them to show in the tile for status. For me it would probably show the title of what is now playing.

                    It sure seems to me that a simple change of which feature is the priority is much easier than recreating device/feature structure so the root can show title.

                    How is a tile with a feature status showing any different than a tile with a device status showing from the user’s perspective? I think the complaint is that the HS4 API is different than the HS3 API and as a plugin author you want the port to HS4 to be able to be a one-to-one API from HS3. The HS4 model is different so it is not possible to do a automated conversion like one can when going between C# and VB.NET.

                    Comment


                      #11
                      Originally posted by Michael McSharry View Post
                      Some may exhibit this relationship and others may not. Take a simple smart plug that has temperature protection. If temperature is too high then you cannot turn the plug on. Should the temperature status be shown in the parent device because without a low temperature the On feature will not work?

                      There are all sorts of special case situations where one could “optimize” by using a device to serve as a feature as well. What this does, however, is add confusion to the user because the device/feature model will be different for each optimized entity. It is more important that a consistent model is used so the user knows what to expect in every situation.

                      In your media player tile the user will see the online status as you, the plugin author, has decided this is the priority feature. I can imagine where the plugin author will give the user the option to pick what is most important to them to show in the tile for status. For me it would probably show the title of what is now playing.

                      It sure seems to me that a simple change of which feature is the priority is much easier than recreating device/feature structure so the root can show title.

                      How is a tile with a feature status showing any different than a tile with a device status showing from the user’s perspective? I think the complaint is that the HS4 API is different than the HS3 API and as a plugin author you want the port to HS4 to be able to be a one-to-one API from HS3. The HS4 model is different so it is not possible to do a automated conversion like one can when going between C# and VB.NET.
                      I think we should distinguish a few different things:

                      1/ in the tile view, I fundamentally believe that the tile is optimized for the function it represents. A tile for a thermostat should be very different from a tile for a media player. I wouldn't want every tool I have to look like a hammer because I know a hammer really well. I agree that across functions, things should look the same, so all media devices should use the same tile layout (give or take), same for lighting devices, thermostats with as you stated, you can customize a little.
                      2/ my point was to the list view, were there are tons of features that result in very very long lists for things that probably shouldn't have been there (or hidden permanently by PI author control).
                      3/ then there are "other UIs". People love to customize HS Touch screens, this forum has some amazing examples. In my case, this is the reason I have too many features and it has to do with the absence of a better way to allow HS Touch to design screens. In HS2 when we had the MusicAPI, I had a few features for each player, it jumped to 20 in HS3. Then there is HS Mobile, where I think the tail is wagging the dog and all these recommended rules that some of us can't get their head around, I suspect all originate from trying to make information presented as much as possible in a generic way. So the question is, is that the right priority?

                      Maybe what should have been is to allow the PI author to "deliver" a tile view and a HS mobile view (think some meta data file, perhaps JSON or HTML or XML) for their devices so they can optimize it to what they think is the best way to represents their device and its associated functions. I had this conversation with Rich but there was plenty of concern that it would be unmanageable for the HS team.

                      Comment


                        #12
                        Originally posted by Michael McSharry View Post
                        I’m with Rich on this. There is a device. The device can have one or more features. The status of the device is meaningless. It is the feature is what is manipulated and what has status. The default UI for a device is a tile. The status reflected in the tile is the status of the priority feature. Supporting features also have status, but you need to drill down to see the lower priority features.

                        The mindset needs to change From HS3 where parent/child relationships exist only for display grouping. HS4 has a different way it represents entities. Consistency in honoring the new model has long term benefits. A HS4 plugin is not a warmed-over HS3 plugin, but is a plugin that embraces the new interface model.

                        Many analogies are available. Buy a new car and you get a touch screen and need to press multiple buttons just to tune a radio station. Why didn’t the car come with a single knob that only tuned radio on the band that I was familiar? Obviously the new car has new features and the way to get to them is not with many single-purpose buttons, but though a consistent UI that gives access to all available features.
                        All these words don't explain why I heed two devices for single relay.

                        Comment


                          #13
                          I think it was for hsmobile ..and the way event works now : you have to select the root ... and after that you have to select the feature

                          Comment


                            #14
                            Originally posted by MattL0 View Post
                            I think it was for hsmobile ..and the way event works now : you have to select the root ... and after that you have to select the feature
                            It's software mate, you can do anything. If it makes sense.

                            Comment


                              #15
                              I know. But this is the path hey choose.

                              like in the z wave plugin. This is two standalones devices
                              Attached Files

                              Comment

                              Working...
                              X