PlugExtraData Remote Plugin Windows to Linux

[rmasonjr]

I had a conversation via email with Rick Tinker this morning and he mentioned that if you add a named object in ped, you should clear it if it already has a value.

So, you would read in all the ped values, clear only the named value you want, then re-add it.

I'm changing my code now to see how it works.

[Kirby]

I am using named object in my plugin with out any problems. I found the trick is to use JSON to serialize the object to a string and store the string. The code in part looks like this:

 string jsonString = ConvertObjectToJSon<ThermostatRootDataV3>(statData);
            PlugExtraData.clsPlugExtraData EDO = new PlugExtraData.clsPlugExtraData();
            if (EDO.AddNamed(ThermostatRootDataV3.PedName, jsonString))
            {
                try
                {
                    dv.set_PlugExtraData_Set(hs, EDO);
                }
                catch (Exception ex)
                {
                    hspi.Log("Error Saving PlugExtraData to the Thermostat root device. Message: " + ex.Message, HSPI.LogType.Errors);
                }
            }
            else
            {
                hspi.Log("Error adding named data object to plug-in thermostat root device!", HSPI.LogType.Errors);
            }

[happnatious1]

If your saying delete the named object before saving your modified named object I think the sample plugin does this.

[beerygaz]

Yup the PEDAdd method in the Utility class for the sample does just this.

Again something that could easily have been abstracted from us by the SDK to avoid the fuss

[reidfo]

This old thread just saved me many hours of banging my head on the desk! I switched to storing a single unnamed JSON serialized string and my plugin is working properly now. I understand the issue is compatibility between .Net and mono, but since it's a know issue why doesn't HS simply use json serialization behind the scenes?

[Mario from Spain]

Hi Steve.

Did you finished your virtual thermostat plugin?

I'm in need of one for my own use.

Thank you.

I have been working on a Virtual Thermostat plugin that effectively emulates a fully scheduled thermostat but uses any temperature sensor device in HS as the input and any switch device as the output. I use PlugExtraData extensively in the root device of each VStat to store lots of information, e.g. schedules and device references. I have the plugin working in Windows and in Linux. However, what I am not having any success with is running the plugin remotely from a Windows PC connecting to a server on Linux. The problem seems to be the PlugExtraData in a device.
When I try to retrieve the PlugExtraData from the root device with
EDO = dvR.PlugExtraData_Get(hs)
it doesn't return any of the objects stored, i.e. EDO.NamedCount=0.

Has anyone had any success with PlugExtraData cross platform?

One of the main reasons for using PlugExtraData to store info in the root device, which I could otherwise have stored in an INI file, was so I could easily access it remotely. If it doesn't work across platforms then it rather scuppers things.

I'm a bit of a novice with plugins so I may be missing the obvious.

Steve

[DNATechnologySolutions]

I must have read this along with many other threads like 12 times, and it wasn't clicking.

Figured I'd break it down in lamens terms for the next person.

So... When you are running from Visual Studio and you click "Start" to debug it, it builds the program by compiling it LOCALLY. It is physically stored in the bin\debug folder. This compiled program is built for the machine you are working on. In my case, Windows 10, x64. It REMOTELY connects to whatever homeseer server you are using. In my case, Oracle VM VirtualBox, running Debian Linux. There in-lies the issue. Windows 10 uses a different runtime that conflicts with Linux when it comes to the PlugExtraData.

I spent hours trying to figure out why I got a "NULL" for a defined object. So how do you fix it?

In your project,
1. select BUILD > CONFIGURATION MANAGER
2. Make sure the project is set for the correct config under Project contexts (in this case Linux ZeePlus Release) x86.
3. Under Active select release and x86.
4. Click BUILD > Build Solution (Ctrl+Shift+B)

Now you will find a compiled linux release in the bin\x86\Linux ZeePlus Release folder.

5. Disable the plugin in your HS3 web interfaces
6. Delete the instance (this will delete the exe file from the homeseer machine
7. Copy the compiled exe to the homeseer
8. Refresh the HS3 Web interfaces page and reactivate the plugin
9. Test the devices

The downside of this is that it makes debugging really convoluted. The upside, is that PED actually works, if you use it right.

[IAmDotorg]

. There in-lies the issue. Windows 10 uses a different runtime that conflicts with Linux when it comes to the PlugExtraData.

Its a more substantial problem than that. The real issue is the folks at Homeseer disregarded Microsoft's explicit rules about binary serialization (that it *never* leaves the process -- its intended *only* for communication between app domains). There's a reason .Net Core no longer supports it -- because developers kept using it for IPC, even though they kept saying not to do that.

Unfortunately, there's more problems than just PlugExtraData -- Action UIs also don't work, for example, for the same reason. There's probably others, because the VB samples mostly don't work. The system is doing a binary serialization of a non-trivial data structure and Mono and .NET are not cross-compatible. You can make PlugExtraData work without that rigmarole by using unnamed entries, which does't stick a problem data structure in the list. I ended up just storing JSON formatted strings in there to work around the problem. (I also do the same into the INI files so you can properly store structured data in the configuration because, as much as I'm a fan of the 90's, INI files are something that was left in them for a reason.)

As far as I can tell there's no work-around for the fact that Windows<->Linux debugging doesn't work with action UIs, for example.

Its been annoying enough, I've considered rebuilding HSCF.dll with a properly written implementation of IScsWireProtocol that either permanently replaces binary serialization with JSON, or uses it only as a fall-back... it looks like everything runs through that class. As long as all the plugins on the server load that DLL, swapping it out would fix the problem. Its been on my list to try.

[IAmDotorg]

One thing that would *really* help would be for Homeseer to give people who have an SEL a second license to run a development system on Windows ...

[Kirby]

Does anyone know if mono 4.0 suffers from the same incompatibility with .NET?

[IAmDotorg]

Does anyone know if mono 4.0 suffers from the same incompatibility with .NET?

Yes, its a fundamental issue -- the binary serialization is an internal detail of the runtime -- its the raw binary format the object is stored in, in memory. Every runtime is different. Its not necessarily even compatible between x86 and x64 machines, or substantially different versions of the runtime.

That's a permanent issue -- no one at Mono would ever spend even a second working on it, because its explicitly not intended to work.

The new version of .Net doesn't even support it -- people using it was such a major problem, they just stripped out binary serialization entirely. .Net Core also doesn't support AppDomains, either, which again is the whole reason binary serialization existed -- under the covers it was meant to essentially allow a very fast copying of a block of memory and a pointer being passed to an in-process cross-domain RPC call.


IMO, the "best" way to work around it is to run a local copy of Homeseer in development, which is why I wish they'd just allow a second install.

In the long-term, I hope the folks at Homeseer will replace the clunky non-standard API between the plugins and Homeseer with a better, fully documented API that is standards based and works cross-platform properly (which would also free us from the clunky VB-derived interfaces, and massively reduce the headaches writing plugins).

[Kirby]

Got it. Thanks for the explanation.