Announcement

Collapse
No announcement yet.

New HomeSeer Mobile and plugins

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

    New HomeSeer Mobile and plugins

    We are working on a new mobile app and have a few issues to work out. The app displays common items in a special way, like battery status and notifications. However, currently we using the Z-Wave device type for this which obviously will not work for other technologies.

    Is anyone populating the current device type property in the device class in their plugin?

    Also, we would like to force root devices to not allow controls. Other than Sonos, is anyone adding controls to their root devices?
    💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

    #2
    SceneMaster uses the device type and my SmartLife plugin is absolutely planning on controls for the root device (its a good place to roll up common operations in that use case). Can I ask why you are considering disallowing that? Seems like a lot of wasted web/ui space if those device show but cant be controlled at all.

    Comment


      #3
      I do tend to set the Device_Type property however unless I am missing it there really is little choice - only thermostat/security/media or the generic type plugin? Unless I have implemented a thermostat then I just set them as plugin which seems the only other suitable option.

      No controls on the root device for me IIRC albeit I do tend to have a second value pair on the root device to raise a communications issue should my plugin have issue with a network call or something. That's rather than having a separate device solely for that purpose.

      If you pardon the pun is the dv.attention property going to get some attention? I've use it once or twice and the image raised does not fit with the contemporary set and would be great if the mobile client could implement it as it might negate the need for me to have the second value pair on the root device to show a comms issue.

      Comment


        #4
        The OMNI plugin does set the device type as:
        DT.Device_Type = DeviceTypeInfo.eDeviceAPI.Plug_In

        That said, the plugin does not actually *use* that value for anything else and I could probably remove it without too much effort.

        I have no controls on the Root Device for OMNI. It is used strictly for grouping and quickly finding the child devices without having to iterate through every device.
        HS4Pro on a Raspberry Pi4
        54 Z-Wave Nodes / 21 Zigbee Devices / 108 Events / 767 Devices
        Plugins: Z-Wave / Zigbee Plus / EasyTrigger / AK Weather / OMNI

        HSTouch Clients: 1 Android

        Comment


          #5
          We are trying to simplify the UI. So the root device will be used just a name for the device, and the child devices are status/control. If we know what the child is (like battery), we simply display a battery icon on the top of the view. Same goes for items like power, central scene (paddle taps), and z-wave notifications such as Door Open, or Motion. As you can imagine, this greatly condenses the UI and gives a more consistent look. See attached pic for what it looks like so far.

          In the image below, the "Assa Abloy..." is the name of the Root device, children with controls are listed next, then children with just status are in a list under "more".

          So I really don't want to support controls on the root device.

          Originally posted by bsobel View Post
          SceneMaster uses the device type and my SmartLife plugin is absolutely planning on controls for the root device (its a good place to roll up common operations in that use case). Can I ask why you are considering disallowing that? Seems like a lot of wasted web/ui space if those device show but cant be controlled at all.
          Attached Files
          💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

          Comment


            #6
            Mine use the device type as well
            Cheers,
            Bob
            Web site | Help Desk | Feature Requests | Message Board

            Comment


              #7
              Rich,
              Unfortunately, the answer is yes on both counts for my Arduino plugin. See Below.
              Attached Files
              Zwave = Z-Stick, 3xHSM100� 7xACT ZDM230, 1xEverspring SM103, 2xACT HomePro ZRP210.
              X10 = CM12U, 2xAM12, 1xAW10, 1 x TM13U, 1xMS13, 2xHR10, 2xSS13
              Other Hardware = ADI Ocelot + secu16, Global Cache GC100, RFXtrx433, 3 x Foscams.
              Plugings = RFXcom, ActiveBackup, Applied Digital Ocelot, BLDeviceMatrix, BLGarbage, BLLAN, Current Cost, Global Cache GC100,HSTouch Android, HSTouch Server, HSTouch Server Unlimited, NetCAM, PowerTrigger, SageWebcamXP, SqueezeBox, X10 CM11A/CM12U.
              Scripts =
              Various

              Comment


                #8
                I use the device type and some of my root devices use controls, but not for normal control (but for status and control of the connection to the technology device).

                Comment


                  #9
                  Have not looked at the attention properly lately, but will have a look.

                  The device type defines some generic types, but nothing specific like battery or notification, or a notification type.

                  Is anyone using the sub type?

                  We could create an enum for that which would define more specific device types. We could start with the enums for Z-Wave as that is pretty robust, but can easily add anything that is missing.

                  Or, we could add a new property and create a new enum. I cannot really add to the existing device type as it would break the API.

                  I suspect there may be a few plugins using the sub type so we may have stay away from that.

                  The goal of this enum would be so the UI knows exactly what this device is and does not need to know the technology underneath.


                  Originally posted by mrhappy View Post
                  I do tend to set the Device_Type property however unless I am missing it there really is little choice - only thermostat/security/media or the generic type plugin? Unless I have implemented a thermostat then I just set them as plugin which seems the only other suitable option.

                  No controls on the root device for me IIRC albeit I do tend to have a second value pair on the root device to raise a communications issue should my plugin have issue with a network call or something. That's rather than having a separate device solely for that purpose.

                  If you pardon the pun is the dv.attention property going to get some attention? I've use it once or twice and the image raised does not fit with the contemporary set and would be great if the mobile client could implement it as it might negate the need for me to have the second value pair on the root device to show a comms issue.
                  💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

                  Comment


                    #10
                    Originally posted by rjh View Post
                    Is anyone populating the current device type property in the device class in their plugin?
                    Which device type property? set_Device_Type_String or set_DeviceType_Set
                    I usually set the Device_Type_String with the name of the plugin

                    dev.set_Device_Type_String(hs, PLUGIN_NAME);

                    and set the devceTypeInfo with the enum value from DeviceTypeInfo_m.DeviceTypeInfo that looks the more appropriate:


                    Originally posted by rjh View Post
                    Also, we would like to force root devices to not allow controls. Other than Sonos, is anyone adding controls to their root devices?
                    A lot of my plugins add controls for root devices, usually something like connect/disconnect buttons, the status of the root device being the connection status.

                    What about device which don't have children, aren't they considered as root devices too?

                    Comment


                      #11
                      Device type string is not used by HS at all, so if its used, it may be used a plugin. A string is not specific enough.

                      A device without a child is displayed the same as a root device, a special case. I already can see many have controls on the root, we will have to look at that.

                      Originally posted by spud View Post
                      Which device type property? set_Device_Type_String or set_DeviceType_Set
                      I usually set the Device_Type_String with the name of the plugin

                      dev.set_Device_Type_String(hs, PLUGIN_NAME);

                      and set the devceTypeInfo with the enum value from DeviceTypeInfo_m.DeviceTypeInfo thatlooks the more appropriate:




                      A lot of my plugins add controls for root devices, usually something like connect/disconnect buttons, the status of the root device being the connection status.

                      What about device which don't have children, aren't they considered as root devices too?
                      💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

                      Comment


                        #12
                        Originally posted by rjh View Post
                        Have not looked at the attention properly lately, but will have a look.

                        The device type defines some generic types, but nothing specific like battery or notification, or a notification type.

                        Is anyone using the sub type?

                        We could create an enum for that which would define more specific device types. We could start with the enums for Z-Wave as that is pretty robust, but can easily add anything that is missing.

                        Or, we could add a new property and create a new enum. I cannot really add to the existing device type as it would break the API.

                        I suspect there may be a few plugins using the sub type so we may have stay away from that.

                        The goal of this enum would be so the UI knows exactly what this device is and does not need to know the technology underneath.
                        IMHO changing this could be quite a gargantuan task for plugin authors to write routines to go through their devices and change the properties - some developers may be less willing or indeed be absent which might create an issue as then users can't get as much value from the mobile client. I think I have used the sub type once or twice but since then I figure more appropriate ways to track devices.

                        Would it be more appropriate to add this as a editable property to the end user from the web UI? Much in the same way as the control use property is. That way people who create virtual devices who may not be as comfortable with scripting can at least have the option of having their devices behave in the mobile client.

                        Comment


                          #13
                          I have On/Off on the root device for each BOSE SoundTouch player.
                          Attached Files

                          Comment


                            #14
                            Originally posted by rjh View Post
                            Device type string is not used by HS at all, so if its used, it may be used a plugin. A string is not specific enough.

                            A device without a child is displayed the same as a root device, a special case. I already can see many have controls on the root, we will have to look at that.
                            Rich,

                            Is Device type string not used for the Device type filter on the device management page?

                            Greig.
                            Zwave = Z-Stick, 3xHSM100� 7xACT ZDM230, 1xEverspring SM103, 2xACT HomePro ZRP210.
                            X10 = CM12U, 2xAM12, 1xAW10, 1 x TM13U, 1xMS13, 2xHR10, 2xSS13
                            Other Hardware = ADI Ocelot + secu16, Global Cache GC100, RFXtrx433, 3 x Foscams.
                            Plugings = RFXcom, ActiveBackup, Applied Digital Ocelot, BLDeviceMatrix, BLGarbage, BLLAN, Current Cost, Global Cache GC100,HSTouch Android, HSTouch Server, HSTouch Server Unlimited, NetCAM, PowerTrigger, SageWebcamXP, SqueezeBox, X10 CM11A/CM12U.
                            Scripts =
                            Various

                            Comment


                              #15
                              Originally posted by rjh View Post

                              Is anyone using the sub type?
                              Yes - definitely using the subtype for thermostats:

                              DT = New DeviceTypeInfo
                              DT.Device_API = DeviceTypeInfo.eDeviceAPI.Thermostat
                              DT.Device_Type = DeviceTypeInfo.eDeviceType_Thermostat.Setpoint
                              DT.Device_SubType = DeviceTypeInfo.eDeviceSubType_Setpoint.Heating_1
                              dv.DeviceType_Set(hs) = DT

                              Changing that would likely break HSTouch and Amazon's connected home api...
                              HS4Pro on a Raspberry Pi4
                              54 Z-Wave Nodes / 21 Zigbee Devices / 108 Events / 767 Devices
                              Plugins: Z-Wave / Zigbee Plus / EasyTrigger / AK Weather / OMNI

                              HSTouch Clients: 1 Android

                              Comment

                              Working...
                              X