Remote access for api

[Stefan Schmelz]

I would like to build a semi permanent installation for my local community center.

I am using a prototype of my distributed scene control. For now it is made for use with a raspberry pi and touchscreen that I use for my tabletop gaming sessions and livestreams.

But for now I did not implement something like sACN or my client server system, because I got a little carried away by adding midi support to my control client.

But until I implement my client server system, I would like to bridge the local rpc that the python library uses to the raspberry that runs ola. Could you give me a little hint, what rpc system it uses, so I could try to implement a proxy.

Or may there is a proxy in existence already...

Thanks in advance guys

[Peter Newman]

It's Google Protocol Buffers.

Please read this section before you do this:

http://docs.openlighting.org/ola/doc/latest/rpc_system.html#rpc_OLA_RPC

Remind me again, what's the reason for not just running OLA on the Pi which has the touchscreen and is already running the python RPC? Then send sACN to the other Pi if that's doing output via a physical dongle.

If you really insist on extending it, I've not tried, but I'd imagine just tunnelling it over SSH port forwarding would be fine, you probably don't need a proxy to extend it.

[Stefan Schmelz]

I don't really know again, what let me believe that I would have to tunnel it.

I have 4 PIs with screens that are mounted to the wall and should all be able to send commands.

Maybe I should go and implement my client server thing to send commands

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en
---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/4035ec3a-391a-48ff-811e-5d6a2f2f4b5cn%40googlegroups.com.

[Peter Newman]

So if you've got four devices, are they all supposed to be in sync, or can you have multiple people running different scenes/controlling different bits of it?

If the former, you need some way to keep them in sync, I'm a big fan of things like MQTT and OSC, if the feedback is all actually driven by the messages, it just happens for free, so you press a button to load preset 1, either all the buttons light up when they hear the preset 1 message, or for the really safe method, the server sends the preset 1 loaded message when it's received and acted on the request, so you've got full revertive control.

If you're doing the latter, then something needs to merge the different requests, which could be your existing control system (sACN and Art-Net should allow that) or it could be an OLA downstream merging them. Merging can get a bit involved depending on what behaviour you actually want, versus the options offered.

[Stefan Schmelz]

I want to build my own thing for the scene server that is somewhat like mqtt, but without broker and with service discovery. 

To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/be3b5078-66fa-4a2c-a781-abc0b7e09839n%40googlegroups.com.

[Peter Newman]

Obviously it's entirely up to you if you want to reinvent the wheel, but I suspect you'll find there's a suitable stack/server available already to do what you want. Something like Avahi could probably deal with the service discovery bit for you.

[Stefan Schmelz]

I wanted to use avahi. But I wanted to save having a separate mqtt server like mosquitto, or at least make the clients autodiscover thge broker

To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/731aa419-3562-42fa-abe4-cbeb66a8a322n%40googlegroups.com.

[Peter Newman]

Ah, as I say I'd imagine someone might have written something that does both already you could use if you wanted.