Announcement

Collapse
No announcement yet.

PlugExtraData Remote Plugin Windows to Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kirby
    replied
    Got it. Thanks for the explanation.

    Leave a comment:


  • IAmDotorg
    replied
    Originally posted by Kirby View Post
    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).

    Leave a comment:


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

    Leave a comment:


  • IAmDotorg
    replied
    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 ...

    Leave a comment:


  • IAmDotorg
    replied
    Originally posted by DNATechnologySolutions View Post
    . 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.

    Leave a comment:


  • DNATechnologySolutions
    replied
    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.

    Leave a comment:


  • Mario from Spain
    replied
    Hi Steve.

    Did you finished your virtual thermostat plugin?

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

    Thank you.

    Originally posted by SteveMSJ View Post
    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

    Leave a comment:


  • reidfo
    replied
    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?

    Leave a comment:


  • beerygaz
    replied
    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

    Leave a comment:


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

    Leave a comment:


  • Kirby
    replied
    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:
    Code:
     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);
                }

    Leave a comment:


  • rmasonjr
    replied
    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.

    Leave a comment:


  • rmasonjr
    replied
    Originally posted by SteveMSJ View Post
    Yes, it foxed me for a while as it was just disconnecting without any error messages. The most annoying type of bug to pin down.

    Steve
    I have a plugin user that is having this same problem but I can't reproduce it on my dev machine. The plugin just quits when setting ped.

    Sent from my SCH-R970X using Tapatalk

    Leave a comment:


  • SteveMSJ
    replied
    Originally posted by shill View Post
    Thank you, thank you, thank you! This was driving me nuts on the plugin I'm working on now - I would hit a PlugExtraData_Set(hs) command and my plugin would suddenly disconnect with no logging info or hints at all as to what the hell was going on...

    Switching to unnamed worked fine, and as I'm only using one item, it was a pretty easy transition.
    Yes, it foxed me for a while as it was just disconnecting without any error messages. The most annoying type of bug to pin down.

    Steve

    Leave a comment:


  • shill
    replied
    Originally posted by SteveMSJ View Post
    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
    Thank you, thank you, thank you! This was driving me nuts on the plugin I'm working on now - I would hit a PlugExtraData_Set(hs) command and my plugin would suddenly disconnect with no logging info or hints at all as to what the hell was going on...

    Switching to unnamed worked fine, and as I'm only using one item, it was a pretty easy transition.

    Leave a comment:

Working...
X