Why is HS dependent on my plugin EXE even if it's not running?

[shill]

Recently (not exactly sure when, unfortunately, but a couple months maybe) I've been noticing that I have trouble updating with my HS system being dependent on one of my plugins - specifically my Tesla plugin (legacy). Here's what I know:

• Starting HS (either 3 or 4) with my plugin in the HS root directly immediately makes the file locked - it can't be deleted.
• In Visual Studio, if I launch a different plugin that calls hs.GetDeviceEnumerator(), it complains if the Tesla EXE isn't in the reference path of the plugin (!!).
• This happens even though the plugin is disabled in HS and not supposed to even be loaded at startup.
• It only happens if there are devices created by the plugin defined - if I delete all the Tesla devices and restart HS, the EXE is no longer locked.
• I store JSON in the root device's PED as an unnamed entry, and I store a long value representing child type as an unnamed PED on each child device, nothing strongly typed.

Any suggestions on where to look?

[dcorsus]

same problem (or derivative) of this?

https://forums.homeseer.com/forum/de...s19-debug-mode

No solution that I'm aware off, if not solved many upgrades will fail.

[shill]

same problem (or derivative) of this?

https://forums.homeseer.com/forum/de...s19-debug-mode

No solution that I'm aware off, if not solved many upgrades will fail.

Yeah, I had similar problems when working on an HS4 plugin and trying to run it from VS but in this case it's happening with an HS3 plugin even in HS3 and even as a normal EXE, without VS at all...

[dcorsus]

Yeah, I had similar problems when working on an HS4 plugin and trying to run it from VS but in this case it's happening with an HS3 plugin even in HS3 and even as a normal EXE, without VS at all...

This has nothing to do with VS, I just noticed it while using VS but if you go through the postings, you see it has something to do with pluginfunction.

I actually had something similar, more than once in HS3, but typically it resulted in me figuring out that there was something I wasn't releasing properly when shutting down.

Do know that even if the PI is disabled, at start-up, HS looks for all HSPI-xxxx.exe in the root and does make calls to them , the one method being called that I know off is "Capabilities", maybe there are others. I think it is used to first check whether the PI is for pay and whether a license key is installed before allowing the PI to start. Then there is the "load in the background" option, not sure what it does but check it and if set turn off and see if it makes a difference.

[shill]

This has nothing to do with VS, I just noticed it while using VS but if you go through the postings, you see it has something to do with pluginfunction.

I actually had something similar, more than once in HS3, but typically it resulted in me figuring out that there was something I wasn't releasing properly when shutting down.

Do know that even if the PI is disabled, at start-up, HS looks for all HSPI-xxxx.exe in the root and does make calls to them , the one method being called that I know off is "Capabilities", maybe there are others. I think it is used to first check whether the PI is for pay and whether a license key is installed before allowing the PI to start. Then there is the "load in the background" option, not sure what it does but check it and if set turn off and see if it makes a difference.

Yeah, I'm aware of the "check in" that happens at start up. But since it doesn't do this if there are no devices defined, I don't think it's that. And since this is an HS3 plugin demonstrating this problem on both HS3 (where the "load in the background" check doesn't exist) and HS4, I'm assuming it's something in my code but I can't for the life of me figure it out. The other evidence is that when I run my Device History plugin in VS, it chokes on hs.GetDeviceEnumerator unless I copy the Tesla EXE to my build folder.

I'll spend some more time going through main and the other default plugin methods looking for anything that might be doing something to get it hung up, and also ensure I'm killing every object those hold onto...

[shill]

FYI, I added some more aggressive cleanup in the main sub after the connection was closed and that seems to have done the trick. Thanks for the pointers!

[tenholde]

I would look at the PED storage. I have run in to problems in the past with enumerating devices in a remote plugin that had PED entries. Needed the plugin .exe available, I believe for HS to have access to any class definition for an object stored in the PED. I'm fuzzy about the details. It may be that even if you are not using custom classes to store into the PED, that HS still tries to access the .exe.

[shill]

I would look at the PED storage. I have run in to problems in the past with enumerating devices in a remote plugin that had PED entries. Needed the plugin .exe available, I believe for HS to have access to any class definition for an object stored in the PED. I'm fuzzy about the details. It may be that even if you are not using custom classes to store into the PED, that HS still tries to access the .exe.

Yeah, I switched to JSON a while back to avoid that problem