Plug-in support on Linux (Plug-in authors please read!)

[beerygaz]

Wow - I ran MoMA against the sample plugin and it threw about 250 missing methods! Most of them appear to be string comparisons and exception handling. This Linux thing is going to be fun...

[vasrc]

Wow - I ran MoMA against the sample plugin and it threw about 250 missing methods! Most of them appear to be string comparisons and exception handling. This Linux thing is going to be fun...

I ran our Concord security panel plugin against MoMA as well and it gave a depressing amount of errors. Nonetheless, it does seem to work, errors withstanding. I"m assuming most of those exceptions don't occur normally.

What I ended up needing to do to get the plugin to run was:
#1. Make the EXE root:root (duh)
2. Make sure the plugin.exe.config points at /bin/plugin name)
3. Put your SQL dll's (I use System.Data.SQLite and SQLite.Interop) in the bin/pluginame directory (I know this is std procedure, but Windows seems to be more forgiving if you don't put them there)
4. If you do any file access, add a Linux check (I used getOStype = 1) to control a simple internal function that does a replace(path,"\","\") if isLinux
5. Change all of your /data/xxx entries to /Data/xxxx

Eureka, running plugin..
Of course I also had to remove the MDB file support and change it to SQLite (which broke more things, like boolean field checks)

Z

[rjh]

To get the platform:

hs.GetOSType

Returns 0 for Windows and 1 for Linux (The return is enum type eOSType)

For the path, we don't give an API for this, here is our function: (you can replace the #if with the function above so you have one build for both OS's)

Public Function FixPath(ByVal fpath As String) As String
#If Linux Then
fpath = fpath.Replace("\", "/")
fpath = fpath.Replace("//", "/")
Return fpath
#Else
fpath = fpath.Replace("/", "\")
fpath = fpath.Replace("\\", "\")
Return fpath
#End If
End Function

I don't remember seeing what the hs. call is to determine the platform as well as the function to fix the path?? I've looked at the hs. options on both the Windows and Linux dll's and can't find anything obvious.

I can of course make a unique EXE just for Linux but would prefer to integrate it into one source either by realtime calls or compile options.

Thanks,
Z

[spud]

Rich, for several of my plugins I need to install different third party libraries on windows and linux, namely A.dll on windows and B.dll on linux, the rest of the install package (exe, config files, etc...) being exactly the same on both platforms.

Would it be possible to add a "if linux" condition in the install script commands?

[rjh]

The updater supports multiple install zip packages, so for Z-Wave we have 2 packages. Just add "_linux" in the name for the Linux one. Maybe in the future we can a condition in the install script so you would only need one zip file.

Rich, for several of my plugins I need to install different third party libraries on windows and linux, namely A.dll on windows and B.dll on linux, the rest of the install package (exe, config files, etc...) being exactly the same on both platforms.

Would it be possible to add a "if linux" condition in the install script commands?

[spud]

thanks
a condition in the install script would be great, do you want me to add a bugzilla ticket for this?

[rjh]

Sure, you can put in an enhancement request ticket.

thanks
a condition in the install script would be great, do you want me to add a bugzilla ticket for this?

[mnsandler]

Guys,
is there a real how-to guide for converting an existing windows .net hs plugin to linux mono?

running the mono tool isn't the complete picture.

[mrhappy]

Guys,
is there a real how-to guide for converting an existing windows .net hs plugin to linux mono?

running the mono tool isn't the complete picture.

With one of my plugins I didn't need to change anything at all for it to work. I think the two main sticking points are file handling and ports, the latter is a problem if you use the .net serial port control as the data received event handler is missing from mono. I think it's one of those you have to try it, find the errors and work on them individually...

[Pete]

Here I have tested a few of the Wintel plugins in Linux mono running in HS3 and remotely. They work fine. I have seen some wierd stuff relating to directories; and creation of directors were I have plugins that create a lower or upper case directory and program talks to the opposite (lower or upper case).

[vasrc]

Guys,
is there a real how-to guide for converting an existing windows .net hs plugin to linux mono?
running the mono tool isn't the complete picture.

As stated, file paths are different (just build a simple replace routine like this)
Public Function fixPath(ByRef path As String) As String
Dim newPath As String = ""
If isLinux Then
newPath = Replace(path, "\", "/")
Else
newPath = path
End If
Return newPath
End Function

For linux determination:
If hs.GetOSType = 1 Then isLinux = True

I use SQLite and prefer unixtime, so I also built a datetime/Unixtime converter as well.

I also had problems with a couple of Clng calls in a hex conversion routine that I had to recode as well.

I never could get the mono test tool to do anything but give me a lot of (what seemed to be) unrelated errors, so I just ran it in debug for awhile and looked for errors.

Z

[mnsandler]

With one of my plugins I didn't need to change anything at all for it to work. I think the two main sticking points are file handling and ports, the latter is a problem if you use the .net serial port control as the data received event handler is missing from mono. I think it's one of those you have to try it, find the errors and work on them individually...

so both of my plugins require the .net serial port class. so am i out of luck or does mono have a completely different serial class? or do i just have to write my own DataReceived based on some other event?

does Visual Studio have a mono plugin so you can see all these issues, or is it all trial and error?

so how to i "try" my plugin? i think i recall that HST provides a VM with linux and hs already installed; is that correct? so i just need to run that and drop in my plugin?

thanks for the insight and guidance

[mrhappy]

so both of my plugins require the .net serial port class. so am i out of luck or does mono have a completely different serial class? or do i just have to write my own DataReceived based on some other event?

does Visual Studio have a mono plugin so you can see all these issues, or is it all trial and error?

so how to i "try" my plugin? i think i recall that HST provides a VM with linux and hs already installed; is that correct? so i just need to run that and drop in my plugin?

thanks for the insight and guidance

I can only speak for when I was messing with it but if you read the port manually somewhere else using something like ReadLine then you are fine, if however you rely on (like I was) the DataReceived event handler then you are out of luck. MONO does not support it http://stackoverflow.com/questions/7...received-event and the workaround is then to poll the port, check whats available and then pick out the data using ReadLine or something. As I was looking at potentially hundreds of characters of XML data it was well outside what I felt comfortable with.

I've not seen the VM with it installed, I know they said they would provide one but I only ever found the linux installer for HS3. I got it up and running in a VM (and I am completely inept at virtualisation) relatively easily though. I think (racking my brain) I basically built the VS project to the VM by sharing a path and just deploying there, I ended up manually launching the plugin on the VM though. No idea if there is an easier method...

[mnsandler]

anyone know how to debug a plugin on a remote linux/Mono platform

I understand there used to be a VS plugin called MonoTools but it has disappeared from the net.

anyone have the tools for VS10?

anyone have another suggestion for remote debugging on Linux/mono

[Pete]

For X windows or whatever GUI there is a suit of tools out there along with a little web server that you can test your stuff with. It was part of the development package. I think if you go into the Raspberry Pi GUI via a VNC X windows setup you might still see it there.

Testing the mcsSprinklers on Linux a couple of years ago; I used it.