HS4 upgrade went fine - started porting plugins OMG.....

[dmurphy]

I must be as thick as a bump on a log or I'm missing something.

Moskus C# sample HS3 plugin had two very useful functions the core of lots of what I did....

1. public virtual bool DeviceExists(string name, string location, string location2)

2. public int CreateBasicDevice(string deviceName, string location, string location2)

I've spent the better part of today looking at how to recreate these and really got nowhere.

I discovered that getting devices by name is a no no in HS4 and that you can create multiple devices with exactly the same fullname. I must admit my brain thinks of devices by name the "living room fan" rather than device 4567.

Two of my HS3 plugins MQTT and MySensors relied on the above functions.

One idea I had was just read all the device refs into my plugin and handle the location/name stuff within the plugin, that just doesn't seem right. Am I missing something?

BTW The HS4 sample plugin is sadly lacking.

[alexbk66]

I must be as thick as a bump on a log or I'm missing something.

Moskus C# sample HS3 plugin had two very useful functions the core of lots of what I did....

1. public virtual bool DeviceExists(string name, string location, string location2)

2. public int CreateBasicDevice(string deviceName, string location, string location2)

I've spent the better part of today looking at how to recreate these and really got nowhere.

I discovered that getting devices by name is a no no in HS4 and that you can create multiple devices with exactly the same fullname. I must admit my brain thinks of devices by name the "living room fan" rather than device 4567.

Two of my HS3 plugins MQTT and MySensors relied on the above functions.

One idea I had was just read all the device refs into my plugin and handle the location/name stuff within the plugin, that just doesn't seem right. Am I missing something?

BTW The HS4 sample plugin is sadly lacking.

I always use device Address in my plugins - that's the only device property the user can't change. Which leaves the user with flexibility to change whatever they want without breaking plugin functionality.

[Michael McSharry]

One idea I had was just read all the device refs into my plugin and handle the location/name stuff within the plugin, that just doesn't seem right. Am I missing something?

I don't use location/name as identifiers, but I do use similar technique to bridge into HS4. Consider the difficulty when a plugin developed for the original HS when HS used Device Code as the identification mechanism. HS4 API has depreciated access to the Device Code property of devices so this information is not available when one desires to migrate an earlier HS configuration to HS4.

[rmasonjr]

The best way to find your plugin devices is with PlugExtraData (PED). You can keep unique values in there to identify the device/feature to your plugin.

[alexbk66]

The best way to find your plugin devices is with PlugExtraData (PED). You can keep unique values in there to identify the device/feature to your plugin.

Isn't the best way to check device "Interface" string?

[dmurphy]

You can get all refs beloning to a particular plugin, then either look at peds or devicetypes to make a further selection....

my point would be all developers have to develop some base level code to handle this

AND the sample plugin doesn’t help because it assumes devices are created from web pages....the sdk api docs tells me exactly whats available, but not what to use and why to use it.

So the initial investment is quite high to port to HS4, in my case a rethink and rewrite......

[rmasonjr]

Yep - you can use Interface to see if the device belongs to you, then drill-down into more granular matches with your own data.
For example, if you have multiple devices that all have the same interface name, you can use PED to pick which device matches what you are looking for:

EN = hs.GetDeviceEnumerator
If EN Is Nothing Then Throw New Exception(OMNI_NAME & " failed to get a device enumerator from HomeSeer.")
Do
     dv = EN.GetNext
     If dv Is Nothing Then Continue Do
     If dv.Interface(Nothing) IsNot Nothing Then
          If dv.Interface(Nothing).Trim = OMNI_NAME Then
          ''is this a parent device for this panel?
               PData = dv.PlugExtraData_Get(hs)
               If (PData IsNot Nothing) Then
                    If (PData.GetNamed("thermostatid") = i) Then
                         d = dv.Ref(hs)
                         Exit Do
                    End If
               End If
          End If
     End If
Loop Until EN.Finished

[dmurphy]

Yep - you can use Interface to see if the device belongs to you, then drill-down into more granular matches with your own data.
For example, if you have multiple devices that all have the same interface name, you can use PED to pick which device matches what you are looking for:

EN = hs.GetDeviceEnumerator
If EN Is Nothing Then Throw New Exception(OMNI_NAME & " failed to get a device enumerator from HomeSeer.")
Do
dv = EN.GetNext
If dv Is Nothing Then Continue Do
If dv.Interface(Nothing) IsNot Nothing Then
If dv.Interface(Nothing).Trim = OMNI_NAME Then
''is this a parent device for this panel?
PData = dv.PlugExtraData_Get(hs)
If (PData IsNot Nothing) Then
If (PData.GetNamed("thermostatid") = i) Then
d = dv.Ref(hs)
Exit Do
End If
End If
End If
End If
Loop Until EN.Finished

I don’t think device enumerator is an option in HS4 sdk or am I missing something?

[rmasonjr]

I don’t think device enumerator is an option in HS4 sdk or am I missing something?

The HS3 plugins that use device enumerator will work in HS4, but for a new HS4 plugin, you probably want to use the newer interfaces.

[w.vuyk]

I don’t think device enumerator is an option in HS4 sdk or am I missing something?

In HS4, using the PluginSDK, you can use "HS.GetRefsByInterface(IFACE_NAME, True)", which leaves the PluginSDK to do that work.
This delivers a set of devicerefs where you can put your own filter on.

[golfyankee]

I found that the best way to "tag" you devices is by specifying it within the Address property. The reason why this is better than the PED is that you can retrieve the device by Address to see if it exists. Unfortunately, you need to do this as an additional call after you create the device. Here is some sample code:

// Create device object
DeviceFactory df = DeviceFactory.CreateDevice(this.Id);
... // add your properties and features

// create new device in HS
NewDeviceData ndd = df.PrepareForHs();
int devRef = HomeSeerSystem.CreateDevice(ndd);

// update device with reference data
Dictionary<EProperty, object> additionalData = new Dictionary<EProperty, object>();
additionalData.Add(EProperty.Address, "Put your device ID here");
hsd = HomeSeerSystem.UpdateDeviceByRef(devRef, additionalData);

Then when you want to see if your device exists, you can easily do the following

HsDevice hsd = HomeSeerSystem.GetDeviceByAddress("Put your device ID here");
if (hsd == null)
{
  // device not found
}
else
{
  // found my device
}

To ensure that you don't collide with other plugin developers, I make my address to be in the format PluginName-ID. Hope this helps.

[dmurphy]

Thanks that's very useful.

[Michael McSharry]

I found that the best way to "tag" you devices is by specifying it within the Address property.

Consider the situation where a plugin desires to use devices created by other plugins. Since Address is just a convention there is no assurance that the other plugin's Address field will have any identifying information.

[dmurphy]

Michael
so using is not modifying? other plugin devices. Can one rely on other plugin devices safely?

[golfyankee]

There are two different things that are mutually exclusive.

The first is, how do you identify your own devices. In my case, I am pulling a cloud end-point and need to check if my device was already created so I don't create duplicates. Using the Address field on the device is most optimal because of the one call lookup I mentioned above with GetDeviceByAddress(). This field shouldn't be used by other developers because it's really an internal lookup for the plugin developer and no one really understands the format as there are no best practices and it's not published. i.e. In my case, my Address field for my garage door looks something like this Garageio-abc-123. I prepend my plugin name in the beginning to eliminate conflicts with others. Then the other 2 sections are the device ID and door ID. So what ends up happening is that when someone toggles the door, I can easily look at the Address and call into the web API to open/close the door without any further lookup of the device itself.

The second is, how do you identify devices created by others. The Interface field contains the plugin name which is what you can use. Unfortunately the features don't have any standardization nor do you know the device type. I'm not sure in what cases you are looking to access someone elses devices. I am actually building one right now which monitors battery levels across all devices as a convenience so you don't have to do it one at a time in an event. For my plugin I mentioned above, HsEvent() is raised and I do a multi-level filtering and ignore all devices that are not mine by rejecting using both the Interface, feature name and Address combination.