Announcement

Collapse
No announcement yet.

More Device/Feature Creation Questions

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

    More Device/Feature Creation Questions

    I've seen several examples, but none of them have fully answered all my questions, and Lord knows the documentation has ZERO descriptive value, so I've just finished my attempt at the "CreateParent" and "CreateChild" functions from my Tesla plugin. Here's what I have right now:

    Code:
                'Setup Parent
                dfParent = New DeviceFactory()
                With dfParent
                    .WithName(Me.VehicleName)
    
                    If g_blnLocation2 And g_blnLocation1First Then
                        .WithLocation("Vehicles")
                        .WithLocation2(Me.VehicleName)
                    Else
                        If g_blnLocation2 Then .WithLocation2("Vehicles")
                        .WithLocation(Me.VehicleName)
                    End If
    
                    .WithMiscFlags(EMiscFlag.ShowValues)
                End With
    
                objType = New Identification.TypeInfo()
                objType.ApiType = EApiType.Device
                objType.SubTypeDescription = ChildCategory.Tesla_Vehicle.ToString.Replace("_", " ")
    
                'TODO: NOT SURE WHAT THIS IS OR HOW TO USE IT
                'objType.SubType = 1
    
                'set all the new device properties
                objParentData = dfParent.PrepareForHs()
                With objParentData
                    Me.ParentRef = .Device(EProperty.Ref)
    
                    .Device(EProperty.Relationship) = ERelationship.Device
                    .Device(EProperty.CanDim) = False
                    .Device(EProperty.DeviceType) = EDeviceType.Generic
                    .Device(EProperty.Address) = Me.VehicleID
                    .Device(EProperty.Interface) = HSPI.Id
                    .Device(EProperty.LastChange) = Date.Now
                    .Device(EProperty.Value) = m_intUNKNOWN_VALUE
                    .Device(EProperty.DeviceType) = objType
    
                    'TODO: NOT SURE WHAT THIS IS FOR OR HOW TO RECREATE IT
                    'devParent.Status_Support = True
                End With
    
                'now create the device
                Me.ParentRef = hs.CreateDevice(objParentData)
    Code:
            'set up the feature
            ffChild = FeatureFactory.CreateFeature(HSPI.Id, Me.ParentRef)
            With ffChild
                .WithName(strChildName)
                .WithDefaultValue(m_intUNKNOWN_VALUE)
                .WithLocation(devParent.Location)
                .WithLocation2(devParent.Location2)
                .WithMiscFlags(EMiscFlag.ShowValues)
    
                objPED = New PlugExtraData()
                objPED.AddNamed("ChildType", enmChildType)
                .WithExtraData(objPED)
            End With
    
            objType = New Identification.TypeInfo()
            objType.ApiType = EApiType.Feature
            objType.SubTypeDescription = enmChildCategory.ToString().Replace("_", " ")
    
            'TODO: NOT SURE WHAT THIS IS OR HOW TO USE IT
            'objType.SubType = 1
    
            objChildData = ffChild.PrepareForHsDevice(devParent.Ref)
            With objChildData
                .Feature(EProperty.Interface) = HSPI.Id
                .Feature(EProperty.Relationship) = ERelationship.Feature
                .Feature(EProperty.CanDim) = False
                .Feature(EProperty.LastChange) = DateTime.Now
    
                'TODO: NOT SURE WHAT THIS IS FOR OR HOW TO RECREATE IT
                'devChild.Status_Support = False
            End With
    
            intRef = hs.CreateFeatureForDevice(objChildData)
    From what I can tell, the idea is to use FeatureFactory to setup the basic device in memory, then use "PrepareForHS" to explode that shell out into a NewDeviceData object with even more details, then once you've set all the properties you want, you use "HomeseerSystem.CreateDevice(<NewDeviceData thing you got earlier>)". (And then substitute "Device" for "Feature" and use "HomeseerSystem.CreateFeatureForDevice" instead for children).

    My main question is: is this the way it's supposed to be done?

    Also:
    • What are the possible values for "SubType" - why isn't this an enum?
    • What about the old "AssociatedDevice_Add" methods? I assume they're not needed since devices and features seem to be inherently related - you pass the ref of your parent in to the featurefactory (right?) so this shouldn't be needed, but the NewFeatureData still has an EProperty of AssociatedDevices, but I have no idea when/why I would use that.
    • The "SaveEventsDevices" method isn't there - can I assume I don't need this? (not sure I ever did, but whenever I created a device, I used it...)

    I'm sure I'll have more, since the doc is SO bad (did I mention that?) and since the examples I've seen weren't nearly as robust as what I used to do with my plugins anyway, and I'm sure others used similar stuff...


    #2
    This is more or less how I am creating new devices as well. Guessing also this is the way it should have been done. The documentation indeed is not very helpfull at all there.

    I am trying to answer your question here, but only based on how I am doing it now:

    What are the possible values for "SubType" - why isn't this an enum?
    I am using my own enum for it, did that already in HS3, so I have copied those values over. I think that is how it is supposed to work, as in a plugin you have your own types of devices. A part of my enum:

    Code:
     Friend Enum PluginDeviceSubType
            Bridge
            Light
            Plug
            Group
            Sensor
            MultiSensor
            ComplexDevice
            <Description("Reserved type")>
            reserved1
            <Description("Reserved type")>
            reserved2
            <Description("Reserved type")>
            reserved3
            '======= Light 
            Bri
            Hue
            Sat
            CT
            White
            <Description("Reserved light")>
            reserved4
            <Description("Reserved light")>
            reserved5
            <Description("Reserved light")>
            reserved6
            '======= sensors
            <Description("Motion")>
            Presence
            <Description("Temperature")>
            Temperature
            <Description("Humidity")>
            Humidity
            <Description("Switch")>
            Switch
            <Description("Light level")>
            LightLevel
            <Description("Open/Close")>
            OpenClose
            <Description("Pressure")>
            Pressure
            <Description("Fire")>
            Fire
            <Description("Water")>
            Water
            <Description("Carbon Monoxide")>
            CarbonMonoxide
            <Description("Consuption")>
            Consumption
            <Description("Power")>
            Power
            <Description("Thermostat")>
            Thermostat
            <Description("Alarm")>
            Alarm
            <Description("Reserved sensor")>
            reserved7
            <Description("Reserved sensor")>
            reserved8
            <Description("Reserve sensor")>
            reserved9
            <Description("Reserved sensor")>
            reserved10
            <Description("Reserved sensor")>
            reserved11
            <Description("Reserved sensor")>
            reserved12
            <Description("Reserved sensor")>
            reserved13
    **** snip ****
    End Enum
    The contents of this enum depend on the type of devices you are planning to use.
    So as far I can see, there (should) be no enum comming from HS4 for this as it should depend only on the plugin?

    What about the old "AssociatedDevice_Add" methods? I assume they're not needed since devices and features seem to be inherently related - you pass the ref of your parent in to the featurefactory (right?) so this shouldn't be needed, but the NewFeatureData still has an EProperty of AssociatedDevices, but I have no idea when/why I would use that.
    I guess the AssociatedDevice_Add is only needed to support HS3 plugins. There is no need for them in a HS4 plugin.
    I am using the EProperty of AssociatedDevices to get hold of the "Device" when I get an update of one of the features of a device. Or the other way around, I can loop through the features when I working on a Device in the plugin. So I actually think it is nice to have the AssociatedDevices.

    The "SaveEventsDevices" method isn't there - can I assume I don't need this? (not sure I ever did, but whenever I created a device, I used it...)
    The way I understood this the hsfeature and hsdevice wrappers take care of saving and getting the device and features. So we do not need this in the plugin anymore.

    Again, that is just how I interpret it now in my plugin which is progressing step by step. The hard part for me here is the HTML part......

    Wim
    -- Wim

    Plugins: JowiHue, RFXCOM, Sonos4, Jon00's Perfmon and Network monitor, EasyTrigger, Pushover 3P, rnbWeather, BLBackup, AK SmartDevice, Pushover, PHLocation, Zwave, GCalseer, SDJ-Health, Device History, BLGData

    1210 devices/features ---- 392 events ----- 40 scripts

    Comment


      #3
      Originally posted by w.vuyk View Post
      I guess the AssociatedDevice_Add is only needed to support HS3 plugins. There is no need for them in a HS4 plugin.
      I am using the EProperty of AssociatedDevices to get hold of the "Device" when I get an update of one of the features of a device. Or the other way around, I can loop through the features when I working on a Device in the plugin. So I actually think it is nice to have the AssociatedDevices.
      To be clear, the "AssociatedDevice_Add" is not in the HS4 SDK, I was just trying to reconcile that old method with the "AssociatedDevices" property, but now I get it - thanks, that does improve things. (As does the idea of using custom sub types, which I have but store in a PED in my HS3 plugins... guess I missed that opportunity previously, too!).

      Comment

      Working...
      X