Announcement

Collapse
No announcement yet.

JSON Device_type and Device_SubType

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

  • JSON Device_type and Device_SubType

    I'm trying to find a reference detailing the meaning of the numeric codes in the Device_Type and Device_SubType fields returned when you get status information using, e.g., the http://127.0.0.1:80/JSON?request-getstatus command. Can anybody point me to where this can be found? If tried looking in the online and PDF developer resources and assume it must be there somewhere, but I just can't seem to find it. Thanks.

    Similarly, is there a reference detailing the default "Device_type_string" used by HomeSeer for each device type? That may be almost as useful to me as the Device_type / Deice_Subtype codes.

    Similarly, I'm trying to figure out how to get the "full" address of a device using a JSON query (ie., the address of the form "E7AFA744-076-Q188" rather than just the reference), or at least get the Z-Wave HOMEID information. I'd like to be able to make a status query using the devices "short" reference number to get back this full address. Its not included in the "default" information returned via a JSON query.

  • #2
    In relation to problem one then I would look at the enum in Visual Studio for that device type, you will likely find the enum breakdowns and their meanings. I would personally not look at the SDK as it can be out of date, browsing the DLL files IMHO yields a more accurate result - this is a guess but I imagine this is what the numbers relate to and instead of the enum name coming across the JSON interface the value instead does.

    The device type string IMHO is to be avoided, plugin writers and end users can edit this at their own will and from memory I can't think of a situation where it is for any other reason than cosmetic to show in the interface (?anyone??). It's more just to know what type of device it is but in reality plugin writers can call their devices what they wish. The device type (not the device type string) is a more appropriate thing to query as that narrows things down to thermostats, alarms, media, energy things etc.

    I can't see a call for this in the SDK and as you say it does not come back in the data, I can only say that it is likely to be by design and I can't see a way around it although I imagine there is some way (as tools like Z-Tool probably use the JSON interface). You could try emailing support and asking if it can be added.
    My Plugins:

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

    Comment


    • #3
      Thanks for the suggestions. You mention looking at some enum data, but I'm not sure what file I look at and the enum. If you know of a specific item to look at, could you post it to this forum or clarify where / how I find it. Your help is greatly appreciated. I"m a but stumped by this as I'm not familiar with the HomeSeer SDK (my project is in JavaScript and is part of a homebridge plugin to allow HomeSeer - iOS interaction and, at least until this point, didn't require understanding of the HomeSeer SDK beyond the JSON interface).

      Basically, what I'm trying to do is pretty simple - I want to be able to look at the returned JSON data and confirm "this is a lock", "this is a dimmer", "this is a temperature sensor", etc. I'm assuming that's what the device type / subtype information will tell me, but if not, then how might I find this out.

      Regards,
      Jim
      Last edited by jvm; February 17th, 2018, 06:04 AM.

      Comment


      • #4
        Originally posted by jvm View Post
        Thanks for the suggestions. You mention looking at some enum data, but I'm not sure what file I look at and the enum. If you know of a specific item to look at, could you post it to this forum or clarify where / how I find it. Your help is greatly appreciated. I"m a but stumped by this as I'm not familiar with the HomeSeer SDK (my project is in JavaScript and is part of a homebridge plugin to allow HomeSeer - iOS interaction and, at least until this point, didn't require understanding of the HomeSeer SDK beyond the JSON interface).

        Basically, what I'm trying to do is pretty simple - I want to be able to look at the returned JSON data and confirm "this is a lock", "this is a dimmer", "this is a temperature sensor", etc. I'm assuming that's what the device type / subtype information will tell me, but if not, then how might I find this out.

        Regards,
        Jim
        If I can save you any pain then you won't be able to do what you are after, the device types are limited to;

        Code:
                Public Enum eDeviceAPI
                    No_API = 0		' All other devices.
                    Plug_In = 4		' Device is owned/managed by a plug-in.
                    Thermostat = 16	' Device is owned/managed by a plug-in and is a thermostat device.
                    Media = 32		' Device is owned/managed by a plug-in and is a media player device.
                    Security = 8		' Device is owned/managed by a plug-in and is a security device.
                    SourceSwitch = 64	' Device is owned/managed by a plug-in and is a matrix switch device.
                    Script = 128		' Device launches a script when the value and/or string changes.
                End Enum
        Then for example the security device can have the following types

        Code:
        Public Enum eDeviceType_Security
            Alarm = 1                           ' Alarm status & control (shows alarms that have occurred and 
            '                                         can also invoke an alarm - e.g. Duress)
            Arming = 10                        ' Arming status & control (shows the state of the security arming and can set arming state)
            Keypad = 20                       ' Keypad status & control
            Zone_Perimeter = 30            ' A perimeter zone
            Zone_Perimeter_Delay = 31   ' A perimeter zone with a violation alarm delay
            Zone_Interior = 32               ' An interior zone (not normally armed in stay mode)
            Zone_Interior_Delay = 33      ' An interior zone (with a violation alarm delay when armed)
            Zone_Auxiliary = 34              ' An aux zone, not usually included in any arming mode
            Zone_Other = 35                 ' A zone that does not fit any other zone description
            Zone_Safety_Smoke = 40     ' A smoke detector zone (not allowed to be bypassed)
            Zone_Safety_CO = 41          ' A Carbon Monoxide zone (not allowed to be bypassed)
            Zone_Safety_CO2 = 42         ' A Carbon Dioxide zone (not allowed to be bypassed)
            Zone_Safety_Other = 43       ' A zone for some other safety sensor that cannot be bypassed
            Output_Relay = 50               ' A general purpose output relay
            Output_Other = 51               ' A general purpose output (could be virtual as in a 'flag' output)
            Communicator = 60              ' Communicator status and (if available) control
            Siren = 70                          ' Siren output - status usually - control follows alarm state.
            Root = 99                           ' Indicates a root device of a root/child grouping.
        End Enum
        Then you can have a sub type which for security there is;

        Code:
        Public Enum eDeviceSubType_SecurityArea
            Invalid = 0
            PRIMARY = 1
            Area_Partition_2 = 2
            Area_Partition_3 = 3
            Area_Partition_4 = 4
            Area_Partition_5 = 5
            Area_Partition_6 = 6
            Area_Partition_7 = 7
            Area_Partition_8 = 8
            Area_Partition_9 = 9
        End Enum
        A similar approach exists for the thermostats, it's important to note that plugin authors do not have to use these if they don't want to. I'm not sure realistically of the benefit of the matrix/security options because the other device types are used for things like HSTouch, Alexa etc and there is no integration AFAIK from anything else that might use the matrix/security types.

        The problem is that the device types are limited to those options you see, as such there is no option to discover what a temperature sensor is, what a light is etc. Where it gets to be a bit of a mess is that there are control use pairs, the control use pairs can be a bit more useful and enables you to identify which value that a device can be set to can be attributed to a use. IE value 0 is off, value 100 is on, 1-99 is dim - you could use some powers of deduction to think well something with a dim pair is going to be a light (of some description anyway), anything with the thermostat pairs might be a thermostat, anything with the lock/unlock pairs might be a lock. The help file has not been updated with the latest controluse pairs however I will copy them from VS here;
        Last edited by mrhappy; March 31st, 2018, 05:59 AM.
        My Plugins:

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

        Comment


        • #5
          Thank you for the very helpful explanation.
          Best regards,
          Jim

          Comment

          Working...
          X