Announcement

Collapse

Contacting HomeSeer This Week

HomeSeer is open and operational this week. All orders are being processed and shipped as usual. However, some staff are working from home. If you need to contact HomeSeer for support or customer service, please use our Email or Chat options. https://homeseer.com/contact-us/
See more
See less

Device type demystified

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

  • Device type demystified

    Can someone demystify the "device type" for me. It is covered poorly in HS3 documentation and I'm at loss.

    An excerpt from HS3 JSON report is attached below. So my questions are

    1. What is device API ?
    2. What is "device type"? If numerical than are there any reserved values and what are they? Is there a relation between numerical value and "Device type description"?
    3. Same questions about "Device sub type".
    4. What is used in the "device type" filter in Device Management screen. I assume it is "Device Type description". How about "Device sub type description", any use of it ?
    5. What is "rtelationship" ?
    6. What is "associated devices" and how are they created in HS3. Manually or by a plug-in only.
    7. Any online documentation that highlights the above issues?


    {
    "ref": 1606,
    "name": "Root",
    "location": "Family",
    "location2": "Google",
    "value": 1,
    "status": "Connected to 192.168.1.176",
    "device_type_string": "Chromecast",
    "last_change": "/Date(1560073759770-0700)/",
    "relationship": 2,
    "hide_from_view": false,
    "associated_devices": [1607, 1608, 1609, 1610, 1611, 1612, 1864],
    "device_type": {
    "Device_API": 32,
    "Device_API_Description": "Music API",
    "Device_Type": 99,
    "Device_Type_Description": "Music Root Device",
    "Device_SubType": 0,
    "Device_SubType_Description": ""
    },
    "device_type_values": null,
    "UserNote": "",
    "UserAccess": "Any",
    "status_image": "",
    "voice_command": "",
    "misc": 4352,
    "interface_name": "Chromecast"
    },



  • #2
    Did you check the online documentation? I'm pretty sure all the answers are there for you:

    http://help.homeseer.com/help/HS3/st...icetype_object

    Thanks,
    Frank

    Comment


    • #3
      The link above doesn't answer much and confirms my point that "...is covered poorly in HS3 documentation" All I get from the link is that device type and device sub type are integers and device type description is string. This is easy to guess. Now what do the integers mean? Is any of 1, 2, 3, 4, 5, .. reserved. What does each mean. How can a HS3 user read these values and what is the use if he can? What if plug-in x assigns value 22 and plug-in y assigns same value 22 without knowing of the use of 22 by another plug-in. In my example above the device type value is 99. It is a root device. Is 99 reserved for root devices? Where all this stuff is explained in details?

      Thanks,

      RISquare

      P.S. A dig deeper in the documentation (link provided by sirmeili above) unveils some details but it doesn't seem that it is all intended for HS3 end user. Looks like it is targeting developers. It seems that the end user can see "device type description" only and use it in the device filters.

      Comment


      • #4
        I think your P.S says it all. There are many things that are documented poorly, device type info is not one of them, IMHO.

        Some quick notes on HS's documentation:
        1. don't just depend on the items in folders, also click on the folders. They often contain more information
        2. For some reason the Device information is mostly in the HS3 online docs for end users (for scripting) and most of it is lacking from the SDK for plugins, so just get used to looking in both areas to find answers (I use this as a general rule, even though it particularly applies to devices)
        The information isn't just used for plugins because HST's opinion on plugins is that if you can do it via a Script, it shouldn't be done in a plugin. So device creation and manipulation is important for managing devices in scripts.
        Thanks,
        Frank

        Comment


        • #5
          Off the top of my head they are used at least by Alexa/GH (to determine what and which devices are thermostats) and HSTouch/HSMobile (again to determine and display thermostats, music devices etc). If you didn't have a device type API then HS would not know that device x/y/z was part of a thermostat as they could all originate from different plugins and they could all be named differently, then the type could be a set point then the sub type could be a heating/cooling set point. The energy API also was of use in the energy pages (again so third parties could integrate their own energy devices) in HSTouch, again a sub type/type was the type of energy.

          There were security API's as well as I think a multi zone one but they exist purely in the documentation as my understanding was that HSTouch/voice never actually utilised them in any way. You will find the enums for the respective types in the documentation, if they are missing from there (there were some historically that never made it in) then you will need to browse it in visual studio.

          They are not really designed for the end user to be concerned about, they are so HS can understand what a device actually does and display/control them correctly. It is a bit of a mess if you ask me as there are additional properties to determine if a device is a light and whether or not it can dim (which is part of the main device class) which I would've thought would make more sense for the device type to be a light then a sub type of it being able to dim or not, those properties are used again by things like Alexa.

          Relationships are there so that devices appear to be grouped correctly in the UI/HSMobile, they also mean that if you delete the parent device then the children come with it automatically rather than having to delete the individual child devices. The associated devices are part of this so HS knows which devices are it's children.

          Be wary with the device_type_string, this is something that can be set to whatever you want and is the thing that the UI uses to filter devices. The documentation is absent with one dependency with this and that is the HSTouch default project uses/used this field to determine whether or not to display the device with a slider (to control the brightness) or an on/off switch. The default project was hard coded to only accept X10/Z-Wave lights and as such only those types of lights appeared in the HSTouch device browser. HSTouch IIRC could use this field in a couple more places but it is a long time since I have used HSTouch now.
          My Plugins:

          Pushover 3P | DoorBird 3P | Current Cost 3P | Velleman K8055 3P | LAMetric 3P | Garadget 3P | Hive 3P |
          Yeelight 3P | Nanoleaf 3P

          Comment


          • #6
            mrhappy Thanks a lot for the detailed explanation. Device type does make much more sense to me now. I do agree with you that it's messy and maybe unnecessary. The problem is (in my view) that HS3 took upon adding functionality (music, thermostats, security) that shouldn't be part of their core, but rather a job for a dedicated plug-in.
            I for example use HS3 to manage 6 HVAC units, 18 zones music system, 64 zones security system without using any of HS3 specialized "devices" and "services". I'm using just the core HS3 functionality and standard devices with blank "device type". I have to admit though that evens were somewhat complex for the thermostats for example, however I managed to simplify them to 1 line after adopting Big5 plug-in. Furthermore, grouping devices under one "root" device creates more confusion for me than convenience. I remember HS 3-in-1 motion sensor was doing it and it was horrible as it was creating devices under the "root" as well as individually. Total mess. I bought about 15 of these sensors and removed them all after struggling for a while to make them work.

            Comment


            • #7
              Originally posted by risquare View Post
              mrhappy Thanks a lot for the detailed explanation. Device type does make much more sense to me now. I do agree with you that it's messy and maybe unnecessary. The problem is (in my view) that HS3 took upon adding functionality (music, thermostats, security) that shouldn't be part of their core, but rather a job for a dedicated plug-in.
              I for example use HS3 to manage 6 HVAC units, 18 zones music system, 64 zones security system without using any of HS3 specialized "devices" and "services". I'm using just the core HS3 functionality and standard devices with blank "device type". I have to admit though that evens were somewhat complex for the thermostats for example, however I managed to simplify them to 1 line after adopting Big5 plug-in. Furthermore, grouping devices under one "root" device creates more confusion for me than convenience. I remember HS 3-in-1 motion sensor was doing it and it was horrible as it was creating devices under the "root" as well as individually. Total mess. I bought about 15 of these sensors and removed them all after struggling for a while to make them work.
              Do you use HSTouch and/or HSMobile? They depend on these for things like Thermostats so that it can display them and their children. Security and Media I think are just remnants of when HS used to worry more about those technologies. I doubt HSMobile worries about it, but HSTouch I'm sure still uses them (at least for Media). It's actually a great concept to be able to generalize a group of devices into a set pattern (like thermostat, media, etc) when you move away from the single device interface like the HS3 admin screen.

              I guess visually grouping is a personal preference. I prefer that all the HS devices for a single physical device are all grouped together. IT keeps me from having to guess which child goes with which parent. Setting relationships is necessary though for the way HS handles those types of devices that fall in the device type APIs.
              Thanks,
              Frank

              Comment


              • #8
                Yes, I do use HSTouch and manage all 6 of my thermostats without using HS3 devices that are "thermostat" type as I'm not using an off the shelf thermostats either. My thermostats are custom made (by me). I have relays in the mechanical rooms that control the furnace and the cooling directly. I the rooms I do have temp/humidity sensors. Relays are ESP8266 based WiFi enabled and controlled over TCP and the sensors report to HS3 over HTTP. UI is either by voice - GoogleHome or HSTouch client running on desktops and tablets.
                The thermostat GUI screen is shown below. I'm not a great artist as you can see but it all works. The indicators for HVAC on/off are duplicated for a reason. Big squares are toggle buttons and show if HVAC function is on or off. The smaller boxes show the status of the relay and if the equipment is actually running. As you know the heating maybe ON but the furnace will not be running if current temperature in the room is higher than the target temperature. Click image for larger version

Name:	Screenshot (200)_LI.jpg
Views:	231
Size:	85.0 KB
ID:	1309924

                Comment

                Working...
                X