Bug in HomeSeer GetPluginsEx()

[Rick Tinker]

There is a script that I wrote years ago that enumerates all of the thermostats in a system as a means of proving most of the compatibility with the Thermostat API, and it uses GetPluginsEx. I converted it to VB.NET a couple of years ago and ran it recently to verify that GetPluginsEx was still working fine when you started this thread. It works fine, and you can run it on your HomeSeer system to verify. It does not test any of the Thermostat API commands, but it will give you a good start on getting thermostat information.

If this works in your HomeSeer system, and then you convert it to your VB.NET program and it fails, then you know that the environment that you need to set up for the VB.NET program (HomeSeer2.dll mainly) is not right, or perhaps you did not use a valid username and password when you made the connection to HomeSeer.

I will enclose it here for you to use. The zip file has both VBS and VB versions of the script.

[metalideath]

I thank you very much for the continued support. I should have a chance to try this out later this week.

[metalideath]

Now this is interesting; it does work when I run it as a script but when I run it from a vb plugin it does not and gives the same type of errors as before.
I am running the sample I found somewhere on the forums for getting real time status; and I have put your stuff in the function Test that is getting called below. The real time status works fine; so I know the connection is good, but for some reason the thermostat related stuff throws errors when trying to read the name of the plugins as before. Is there something goofy in the code below that I am not seeing?

Module Globals
    Public hs As Scheduler.hsapplication
    Public hsapp As HomeSeer2.application
End Module

    Private Sub Form1_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
        hsapp = New HomeSeer2.application
        hsapp.SetHost("localhost")
        Dim rval As String = hsapp.Connect("default", "default")
        If rval <> "" Then
            MsgBox("Unable to connect to HomeSeer, is it running? You need to be on the same subnet as HomeSeer", MsgBoxStyle.Critical)
            End
        End If
        hs = hsapp.GetHSRef
        hsapp.RegisterEventCB(4, Me)
        Test()
        UpdateDevices()
    End Sub

I have verified that the project does pull in scheduler.dll and HomeSeer2.dll as you had said to check for this.
I wonder if there is anything special that I have to do to the VB project to get the marshaling working.

If I comment out the on error resume next in your code then I can see the error that is getting raised at s = PlugItem.name:

Public member 'name' on type 'MarshalByRefObject' not found.

[metalideath]

Update.

I just discovered that if I run my program from within the HomeSeer directory then it does work. If I run it from anywhere else then I get the can't find .name errors. Does the dll files of the plugins have to be located in the same directory for calling their .name and other thermostat items? If so does that mean that you cannot get this sort of information without pasting these dll files on every computer in your network that wished to remotely connect?

[mrhappy]

Update.

I just discovered that if I run my program from within the HomeSeer directory then it does work. If I run it from anywhere else then I get the can't find .name errors. Does the dll files of the plugins have to be located in the same directory for calling their .name and other thermostat items? If so does that mean that you cannot get this sort of information without pasting these dll files on every computer in your network that wished to remotely connect?

Whenever i've written VB apps that interface with HS i've had to include the DLL files in the same directory as the application for it to work..i'm sure theres some way to include them automatically (perhaps if you package the app) but otherwise yes they need to be included.

[metalideath]

I am guessing this is a drawback of using dll files and remoting. I am not terribly familiar with how this type of setup works. Most of my experience with app to app communication is with Rest and SOAP based web services.

[Rick Tinker]

It has nothing to do with remoting and everything to do with how Microsoft resolves DLL locations. DLLs are not ActiveX/COM, so they are not registered in the registry where an app can search by GUID or name to find them. Thus, they are resolved by looking in the app path, windows directory, system/system32 directories, and perhaps a few other places - but they definitely cannot be in any old directory to be found. One of the other places I think is the set of paths in the PATH environment variable - apps used to add their directory to that thing all the time years ago because of this!

[zimmer62]

It has nothing to do with remoting and everything to do with how Microsoft resolves DLL locations. DLLs are not ActiveX/COM, so they are not registered in the registry where an app can search by GUID or name to find them. Thus, they are resolved by looking in the app path, windows directory, system/system32 directories, and perhaps a few other places - but they definitely cannot be in any old directory to be found. One of the other places I think is the set of paths in the PATH environment variable - apps used to add their directory to that thing all the time years ago because of this!

Well I've got one thing for you to look into after reading that... it's call the GAC.

Global Assembly Cache

It's where you can put DLL's that you want to find by name from anywhere.

You can code against versions, and have multiple versions stored in the GAC perfect for solving problems where you require a certain version or newer.

[Rick Tinker]

Well I've got one thing for you to look into after reading that... it's call the GAC.

Global Assembly Cache

It's where you can put DLL's that you want to find by name from anywhere.

You can code against versions, and have multiple versions stored in the GAC perfect for solving problems where you require a certain version or newer.

No kidding? Wow that sounds great - we should try it sometime...

The interface is designed to be used on a remote system. If you are creating an app to interface with HomeSeer on the same system as HomeSeer, that is called a plug-in and should use the plug-in API, or it is a script. Thus, the HomeSeer installer cannot install the DLL in the GAC on the remote systems, so we do not even try. We do put other things in the GAC on the HomeSeer system.

If you want a quick and easy way to install the needed files on a remote system, run the Speaker client installer, then just have it install the speaker client into the directory of the application you are writing to connect to HomeSeer.