I'm hoping someone here can give me a thought on where to even look at this...
I have a plugin I've written, and I'm trying to deploy it on a new Hometroller SEL Pro. The plugin runs fine in Visual Studio, connecting remote. It turned out the version of Mono on the SEL had both platform compatibility and unimplemented methods I was using, so it took a bit of rewriting to get it to run under Linux, but I worked through those...
As it stands after removing a bunch of async code that required C# 5 and admittedly uncommon use of JIT code generation, if I run the plugin on the SEL directly -- "/usr/bin/mono /usr/local/HomeSeer/HSPI_MyPlugin.exe server=127.0.0.1", it starts up and runs perfectly on the device.
If I enable it in the UI, however, I get:
WARNING: Failed getting InterfaceStatus from MyPlugin - the interface was not found in the list of active interfaces, the list may need to be refreshed.
The logs say simply:
Finished initializing plug-in MyPlugin
The actual logging from it doesn't show up, and there's no errors. I actually instrumented the entire set of IPlugInAPI methods, on the off chance the startup sequence when being managed isn't the same as starting it from the command line, but nothing got logged, either. Nothing gets logged, so I see no indication its even trying to start it.
The HomeSeer docs are terrible, and the sample plugin is even worse, so its hard to tell what should be happening. The docs say the plugins are executed via reflection, but I can see that's not the case -- there's mono processes running for all the "working" plugins, so its not loading them into app domains, for example, in-process. So it sure looks like the normal entry point is the main method, not an actual loading of the assembly and calls via reflection. (Although it looks like maybe it does runtime discovery of the names of the plugins that way?)
That'd make me think they should behave identically -- there's no reason the homeseer user running it from the shell should behave any differently, so I'm guessing the problem is happening before it tries to launch the executable in mono.
Is there any better way to diagnose this? Does anyone have any documentation about what precisely Homeseer is doing related to the plugin lifecycle?
The hacky fix would be to bypass the homeseer lifecycle code and just have Linux start the plugin directly... but given there's others I'm going to write, figuring out whats going on would be preferable to a hacky fix.
Any help would be appreciated.
I have a plugin I've written, and I'm trying to deploy it on a new Hometroller SEL Pro. The plugin runs fine in Visual Studio, connecting remote. It turned out the version of Mono on the SEL had both platform compatibility and unimplemented methods I was using, so it took a bit of rewriting to get it to run under Linux, but I worked through those...
As it stands after removing a bunch of async code that required C# 5 and admittedly uncommon use of JIT code generation, if I run the plugin on the SEL directly -- "/usr/bin/mono /usr/local/HomeSeer/HSPI_MyPlugin.exe server=127.0.0.1", it starts up and runs perfectly on the device.
If I enable it in the UI, however, I get:
WARNING: Failed getting InterfaceStatus from MyPlugin - the interface was not found in the list of active interfaces, the list may need to be refreshed.
The logs say simply:
Finished initializing plug-in MyPlugin
The actual logging from it doesn't show up, and there's no errors. I actually instrumented the entire set of IPlugInAPI methods, on the off chance the startup sequence when being managed isn't the same as starting it from the command line, but nothing got logged, either. Nothing gets logged, so I see no indication its even trying to start it.
The HomeSeer docs are terrible, and the sample plugin is even worse, so its hard to tell what should be happening. The docs say the plugins are executed via reflection, but I can see that's not the case -- there's mono processes running for all the "working" plugins, so its not loading them into app domains, for example, in-process. So it sure looks like the normal entry point is the main method, not an actual loading of the assembly and calls via reflection. (Although it looks like maybe it does runtime discovery of the names of the plugins that way?)
That'd make me think they should behave identically -- there's no reason the homeseer user running it from the shell should behave any differently, so I'm guessing the problem is happening before it tries to launch the executable in mono.
Is there any better way to diagnose this? Does anyone have any documentation about what precisely Homeseer is doing related to the plugin lifecycle?
The hacky fix would be to bypass the homeseer lifecycle code and just have Linux start the plugin directly... but given there's others I'm going to write, figuring out whats going on would be preferable to a hacky fix.
Any help would be appreciated.
