Announcement

**mrhappy** · February 16, 2018, 04:37 PM

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.

**jvm** · February 17, 2018, 05:24 AM

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

**mrhappy** · February 17, 2018, 12:11 PM

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;

**jvm** · February 17, 2018, 05:11 PM

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

Announcement

JSON Device_type and Device_SubType

JSON Device_type and Device_SubType

Comment

Comment

Comment

Comment