PlugExtraData Remote Plugin Windows to Linux

[happnatious1]

Good question. If it is possible I would think it would have to be done maliciously. I'm not worried about it.

[beerygaz]

Thanks for the clarification happ. Unless I'm mistaken, is there a possibility for one plugin to modify the PED for another plugin's devices and wreak havoc? Not that it's in the interest of any plugin dev to do such a thing, but if accidentally done, I can see it causing no-end of support fun & games.

[happnatious1]

From the plugin SDK documentation:

AddNamed
This procedure in the clsPlugExtraData object adds a named object to the EDO storage.
Public Function AddNamed(ByVal Key As String, ByVal Obj As Object) As Boolean

AddUnNamed
This procedure in the clsPlugExtraData object adds an unnamed object to the EDO storage.
Public Function AddUnNamed(ByVal Obj As Object) As Boolean

It would be good to know if serializing a complex object as either a string or byte array works with Linux.

[beerygaz]

Steve can you elaborate on your 'named' vs 'unnamed' objects? Are you talking about creating an instance of an object from an existing class vs using an anonymous object?

[SteveMSJ]

I have had a bit more time to experiment with PlugExtraData cross platform, Windows to Linux.
What I have found is that as long as you don't store 'named' objects it works ok. It's a shame as using 'named' objects is a lot nicer way of storing and retrieving data. It would be helpful if HS could look into this bug.

I have rewritten my plugin to use only 'unnamed' objects in PlugExtraData and I have it working on a remote windows machine manipulating the PlugExtraData in devices on a linux server. I did have some random issues when writing the data. It worked fine in testing but then at some later time the plugin would crash when writing dvR.PlugExtraData_Set(hs) = EDO. I found the most reliable way was to create a new EDO object rather than clearing objects from the existing EDO.

I know people have had issues with remote plugins working cross platform, this maybe one of the reasons.

Steve

[SteveMSJ]

I am doing the same thing as you (storing data in the PED of the root node). It will work fine running a remote windows machine to a windows HS server. It will not work remoting to a Linux server. Apparently it is not an issue with PED, it is an issue with Mono serialization. The Windows and Linux Mono serialization is incompatible. You can google it for more info.



I am considering serializing my data into a JSON string and storing the string in the PED. This may remove the incompatibility.

Thanks for the info, that seems to be the problem. The same issue appears to prevent copying the HS database between windows and Linux.
Let us know how you get on with the JSON approach.
Steve

[Kirby]

I am doing the same thing as you (storing data in the PED of the root node). It will work fine running a remote windows machine to a windows HS server. It will not work remoting to a Linux server. Apparently it is not an issue with PED, it is an issue with Mono serialization. The Windows and Linux Mono serialization is incompatible. You can google it for more info.

I am considering serializing my data into a JSON string and storing the string in the PED. This may remove the incompatibility.

[SteveMSJ]

Are you going between 32bit and 64bit across platforms?

Good question. The compile in visual studio is set to target x86 although it is running on an x64 windows 7 PC. The plugin runs ok locally on an x64 PC and locally on a Raspberry PI-2 (standard Raspbian). The issue shows when the plugin is run remotely on the x64 PC with HS3 running on the PI-2. I haven't tried it in the other direction.
Steve

[rmasonjr]

Are you going between 32bit and 64bit across platforms?

Sent from my SCH-R970X using Tapatalk

[SteveMSJ]

I tried storing a custom object and it does work, however, HS doesn't know the object type unless the plugin is loaded. Rick told me to only store base types like integer, string, etc. in PED.

I am only storing strings, integers and booleans albeit arrays of booleans. It works fine with the plugin locally just not remotely cross platform. I haven't actually tried remotely between two windows installations. I must give that a try at the weekend.
I did start with trying to store more complex objects but that didn't even work locally for me so I fell back on base types.
I have a feeling that there are generally cross platform issues with serialised data but I need to experiment more.
Steve

[rmasonjr]

I tried storing a custom object and it does work, however, HS doesn't know the object type unless the plugin is loaded. Rick told me to only store base types like integer, string, etc. in PED.

Sent from my SCH-R970X using Tapatalk

[SteveMSJ]

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