Remote GPIO with Xojo?

Is there any way to perform Remote GPIO functions using Xojo? I'm intrigued by the idea of a Mac laptop centrally controlling several remote Raspberry Pi Zero's on the same wireless network with a single Xojo desktop app.

I've been able to write a Xojo desktop app on the Mac using shell commands to run a Python script which in turn imports functions from the Python gpiozero library, but I'm not thrilled about having to use Python. In my research, I ran across Einhugur's Python 3 script plugin (http://einhugur.com/Html/ScriptEngines.html ), which sounds like it can import the Python library functions, but I'm on a very limited budget and this is currently just a hobby. Also, in my ignorance I'm not even sure that would work.

I know that Xojo has provided a GPIO module, and I've used it on a number of little projects, but as far as I can determine, there are no remote function calls included.

After a solid week of staring at Python code, endless Googling, and seemingly endless trial and error, I was finally able to achieve the first steps toward achieving my goal of native Xojo control of remote Raspi GPIO function over Wi-Fi without an intermediate Python layer.

In answer to my original questions:

1) Einhugur's Python 3 script plug-in is fine work, but it uses Python (of course) and it does not address remote GPIO functionality.

2) Xojo's own GPIO module is also excellent work, but it too does not provide remote GPIO functionality.

In the end, I was able to communicate with the pigpio daemon remotely via TCPSocket natively in Xojo with surprisingly little code.

Of course, my code is probably a bit sloppy since I am still very inexperienced, but it's simple and it works well.

Amazing! How is Xojo not at the top of the list of the most popular programming languages?!

I've marked this reply as the answer to my original question. I hope that is not breach of protocol or appears vain in any way. I just thought the question should be properly closed with a detailed answer for anyone else who might stumble upon the same issue.

Hello Scott.Not that I have tried it yet, but since Linux used a million scripts, I would look at using scripts called by the remote (webapp) to be executed locally. I have just finished doing this for Windows to perform restarts and other functions for windows services and apps. I also use a shell to execute scripted commands within the same app, but compiled for linux.

A quick look at the documentation suggests that you probably don’t need Python to do this. All you need to be able to is communicate with the remote interface, so I’d expect if you spend some time digging into the client Python calls you should be able to implement the same natively in XOJO.

I'm also interested in deploying Raspberry Pi's around my home to control various things. My "whole-house" attic fan is one of the things I'd like to be able to control from multiple locations. The WebIOPi package is probably what I'll use on each Pi and then use Xojo to make calls to the WebIOPi REST API.

Currently, I can control GPIO remotely on multiple devices with just a simple single shell command:

myShell.WriteLine "PIGPIO_ADDR=192.168.2.16 python ~/scripts/led.py"

This is surprisingly simple and requires only the installation of the pigpio daemon on the receiving RasPi(s) - also a very easy thing to do. It has the added benefit of being able to maintain the functional scripts on the central controlling computer (in my case, my Mac laptop). I was just hoping to be able to bypass the Python aspect and incorporate the gpiozero functions in Xojo directly.

I installed the Demo version of Einhugur's Python Script plug-in and it seems like a viable way to go, but the code necessary to drive it rapidly become a negative return:

This is just a simple snippet to multiply two numbers! Sure, I realize it's all necessary for what it's doing. You have to setup the parameters of the function, pass the values, handle the results, and deal with errors, but my current solution is basically "Hey, Raspi at 192.168.2.16, do this: led.py". I just have to learn Python, which ironically, I would have to do FAR more if I used Einhugur's plug-in.

Dim package as PythonModule
Dim func as PythonFunction
Dim params as PythonParameters
Dim result as PythonResult
Dim f as FolderItem
PythonScript.SetConsoleOutput(new ConsoleHandler(TextArea1))
#if TargetMacOS
f = App.ExecutableFile.Parent.Parent.Parent.Parent.Child("PythonModules")
#elseif TargetWin32 or TargetLinux
f = App.ExecutableFile.Parent.Child("PythonModules")
#endif
// Add search path where Python can find our module
PythonScript.AddSearchPath(f)
// We try to load the Python module
package = PythonScript.GetModule("SomeSimpleTest")
if package <> nil then
// We add a property called x to the module and set its value to 29
package.IntegerField("x") = 29
// See if we can find function called multiply in the module
func = package.GetFunction("multiply")
if func <> nil then
// Build some parameters to pass to the function
params = new PythonParameters(2)
params.IntegerValue(0) = 5
params.IntegerValue(1) =3
// run the function
result = func.Invoke(params)
if result <> nil then
MsgBox Str(result.IntegerValue)
else
if PythonScript.ErrorOccurred then
MsgBox PythonScript.GetError()
PythonScript.ClearError()
end if
end if
end if
else
MsgBox "Could not load module"
end if

@James D : I'm hoping you're right about being able to communicate directly with the client. That sounds promising. I just hope it's not over my head. I'll look into it further. You might be hearing from me again. :@)

@WilliamReynolds , @Tim S , @Pedro I;Tellez&nbsp;Corella : While I know you're right about using client-server scripts and TCPSocket, etc., with my limited experience, it seems that may be reinventing the wheel in this case, since gpiozero and pigpio have already been written, though I could be wrong.

@Wes W : Thanks for reminding me of WebIOPi. I'll look into it again. Sadly, a while back, I looked into both WebIOPi and Cayenne but when I ran into some confusion and tried to contact them for help, I was completely ignored. That left a bad taste in my mouth. I chalked it up to them being new and still getting their feet settled and decided to revisit them later. Perhaps now's the time.

@Wes W : Thanks again for suggesting WebIOPi. However, after carefully re-researching it, I quickly realized why I had decided that it was not the proper fit for me in the past (other than the non-existent customer service at the time). A while back, I committed to Xojo dedicated web apps as opposed to CGI installations for reasons I won't go into unless prodded. Regardless, WebIOPi would require knowledge of HTML, Javascript, AND Python. I can hold my own with the first two from years of experience, but I'm trying to avoid Python. So sadly, this seems to be more on top of what I already don't want. Unless I'm missing something. Please let me know.

@James D : You appear to have been spot on. If I understand this correctly, "the pigpio daemon offers a socket and pipe interface to the underlying C library."-- (http://abyz.me.uk/rpi/pigpio/index.html ) which means I should be able to use Xojo to send data to the remote RasPi using pigpio commands on the Mac. ...I think. As I mentioned before, I'm fairly confident I'm in over my head here.

As it stands, I'm still in the "Ooh, magic!" stage just trying to figure out how setting an environment variable and running a python script on the same line even works. I mean, what sorcery is this?

PIGPIO_ADDR=192.168.2.15 python3 ~/Temporary/led.py

I'm guessing pigpio on the Mac "watches" for the ADDR to know where to send the .py code and then once the code gets there, gpiozero runs it?

So, if I understand this correctly, I should be able to have Xojo use the pigpio library on the Mac, which in turn will send commands to whichever host I setup in the pigpio.pi(host, port, show_errors) command. I'm mostly clear on the last part, but the Xojo connection to the pigpio library has me stumped. I'm guessing there's a command for Xojo to link to outside libraries. If I'm on the right track, please let me know. I'll look into the linking methodology just as soon as my head stops pounding.

Man! What is this pain behind my ears?! I might need a dentist. ...or an exorcist. Or maybe just a stiff drink.

From my limited understanding however, I believe Mr. Bogun's library does not include remote gpio functions. If I'm mistaken, please let me know, as that would seem the most ideal route.

After further investigation into the suggestion from @James D regarding direct use of the pigpio library in Xojo, I believe I may be able to declare the libray in Xojo and work directly with the specific pigpio commands for remote access. However, my experience with Xojo is very limited. I hope to try my hand later tonight to see if I can get it work. Any help along those lines would be greatly appreciated. :@)

Another option would be to mount the Pi's /sys/class/gpio over NFS. The /sys folder is a special file system. It would give you full GPIO control and monitoring without scripts on the Pi. You could just create a new mount target folder for each pi on your mac host.

@Daniel W : That's actually really clever. Unfortunately, from a Xojo programming perspective, it still requires use of the shell commands and instead of then running Python, it's running Bash commands. I'm trying to find a more Xojo-centric solution that does not require knowledge of additional languages (with the exception of a few new gpio library commands of course).

Thank you for sharing this though. I doubt it would ever have occurred to me, yet it's very much a Linux move in that "everything is a file". Very cool.

2) (Seemingly more promising) Use the Xojo pigpio wrapper developed by @Ulrich B . I have read everything I could and stared at the code for hours and I just can't seem to find any mention of the remote gpio functions. (Mr. Bogun, if you're reading this, I opened am issue on your Github page and have not attempted any further communication so as not to bombard you from all directions.)

It is my hope that either or both of these options will have the commands necessary for remote gpio functionality AND that the Xojo code can be built into a Mac app.

As always, any further help or advice along these lines would be greatly appreciated. Thanks! :@)

I want to thank you all for your kind assistance and beg your continued indulgence as I explore this project. My biggest challenge is that I don't know what I don't know, so I don't know what to ask. But I feel I'm getting closer. And I'm learning quite a lot. Hopefully, some day I'll be able to help others as well.

I've communicated with the developer of the pigpio library as well as @Ulrich B regarding his Xojo pigpio wrapper module regarding my goal of Mac > Xojo > Wi-Fi > Raspberry Pi > pigpio daemon > Remote GPIO and both suggest that what I need is a Xojo code that can communicate with the pigpio daemon over a socket connection. As I mentioned earlier...

@William Reynolds , @Tim Seyfarth , @Pedro Ivan ;Tellez Corella : While I know you're right about using client-server scripts and TCPSocket, etc., with my limited experience, it seems that may be reinventing the wheel in this case, since gpiozero and pigpio have already been written, though I could be wrong.

...while it may require some "reinvention of the wheel", it seems that half of the work has already been done with the daemon functional on the Raspberry Pi side. It appears now all that is needed is the Xojo side to communicate with it. So, I feel I'm getting closer!

Preliminary search on "socket" yielded "Xojo.Net.TCPSocket". I'll be looking into that further. However, if anyone could tell me if I'm getting hot or cold here, I would certainly appreciate it. Of course, some example code would be awesome!

@Scott R I'm trying to find a more Xojo-centric solution that does not require knowledge of additional languages (with the exception of a few new gpio library commands of course).

I see... those bash commands are simply manipulating files. With the help of text streams Xojo's FolderItem should be do it. Perhaps I will build a class for this one day. I tire of partially compatible GPIO libraries that never work on different ARM devices. That is why I switched to using the gpio folders... no headaches since!

As others here suggested, I believe you should be able to address the C daemon quite easily. It establishes a connection on a specified port, so you should be able to talk to it using TCPSocket(s) (and possibly ServerSockets if you the daemon can talk to the host too). I wrote a blog post about a similar project connecting FileMaker and Xojo via Sockets, but it is in German only and I am afraid the built-in Google translator will work as … hmm … usual: https://xojoblog.me/2017/11/23/1-x-filemaker-zu-xojo-und-zurueck-bitte/

Anyway, I think a similar approach would work. Let me know if the translation is completely unreadable.