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.

Any ideas? Thanks! :@)

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.

Tim

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.

There’s a package out there called “WebIOPi” that runs nicely on the Raspberry Pi and lets you control the GPIO pins via a web browser or a REST API.

WebIOPi

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.

-Wes

Hey Wes, that’s kind of cool! Thanks for bringing it up!
Tim

FWIW xojo has a cool class called AutoDiscovery, and perhaps you can use that and TCPSocket and do all your work natively in xojo. (no, I have not tried any of this personally)

lol
You have to make an app to run LOCAL on each raspberry and Another app to control them.
Client - Server

Thanks for all the great advice folks!

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.

[code]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 [/code]

@James Dooley : 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. :@)

@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.

@Wes Westhaver : 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 Westhaver : 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 Dooley : 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?

You suggested “digging into the client Python calls”. The best I could find that sounded like what you mean is this from http://abyz.me.uk/rpi/pigpio/python.html:

pi1 = pigpio.pi()       # pi1 accesses the local Pi's GPIO
pi2 = pigpio.pi('tom')  # pi2 accesses tom's GPIO
pi3 = pigpio.pi('dick') # pi3 accesses dick's GPIO

pi1.write(4, 0) # set local Pi's GPIO 4 low
pi2.write(4, 1) # set tom's GPIO 4 to high
pi3.read(4)     # get level of dick's GPIO 4

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.

Thanks again!

I assume you’ve seen @Ulrich Bogun 's Xojo-pigpio https://github.com/UBogun/Xojo-pigpio - doesn’t that remove the need for any Python?

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 Dooley 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.

Here is some great documentation on controlling GPIO pins from the /sys/class/gpio folder.
https://docs.getchip.com/chip_pro_devkit.html#export-digital-gpios

I had a pi like device handy. I tested it by mounting the /sys folder over wifi using sftp. Worked great!

@Daniel Wilson : 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.

After staring at code and reading endless web pages, it seems the closest solution to finding a Xojo direct programming option for Remote GPIO without Python is one of two possible methods:

  1. Find a way to compile the pigpio library for the Mac and then declare the library in Xojo to use the commands. Sadly my attempts to compile the library myself have failed - no surprise there. But back in 2015, @Matthias Kniephoff appears to have possibly done so (See: https://forum.xojo.com/28520-how-to-use-soft-declare-for-the-libpigpio-so/0#p234476).

  2. (Seemingly more promising) Use the Xojo pigpio wrapper developed by @Ulrich Bogun . 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 Bogun 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…

…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!

Thanks again folks! As always, much appreciated. :@)

http://developer.xojo.com/userguide/userguide/tcp-ip-communications

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!

Have fun Scott!

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.