Jump to content
C4 Forums | Control4

Open Source Drivers Available?


jaycenornin

Recommended Posts

Background:
I'm a trekkie. I want LCARS light switches. I'm an IT guy by day, C4 installer part time (on-call), and hobbyist developer.

I want to write a driver and Windows app to provide an LCARS touch interface for Control4. I've built custom drivers before, but by that I mean using Composer and a lot of trial and error to write a control driver for an off-the-wall media device with no documented IR codes. I have a basic familiarity with LUA and C#. I'm pouring through the C4 API documentation and training videos, but I'd like to get my hands on some real source code for a "big picture" view of what a complete LUA driver looks like. I've searched the forum and the downloads section here and the open web but have come up a bit empty.

Are there any open source Control4 driver repositories hiding at the end of the universe? Or does anyone here have some source code for LUA drivers that they're willing to share?

Link to comment
Share on other sites


To note at the beginning - there are several people on here with vastly more experience than me in going this far out of the box in driver development.

The vast majority of drivers are not encrypted - Control4's are only if they are either C4's own devices, or a handful of exceptions due to licensing or security etc.

What you're looking to DO however is to create an interface device, not any 'source' or 'endpoint'.

 

To create what you'd want you'd have to likely treat both things as separate 'systems'.

Create a LCARS screen, and set it up to create triggers for each possible press - then communicate those triggers to C4 over some form of interface, serial or IP.

A driver can be created and you can set it up to have any type of 'device variable' and/or codes for each of the things you'd want to use - from there, you'd have to program C4 to act a certain way on these triggers.

You could conceivably then do this in full two-way communication as well - but keep in mind that it would potentially require a LOT of programming (as in composer programming) to go that far in C4, and additional programming on the LCARS side to accept the info and turn it into feedback.

The principal, in my mind, wouldn't be that different from a security panel driver. You may want to look and see if you can figure out one of those (serial would likely be easiest) and how it communicates in two direction - and have a look at some of the drivers made for 3rd party audio systems, also at their explanations (on how to keep the two in sync using programming).

 

Link to comment
Share on other sites

15 minutes ago, Cyknight said:

To note at the beginning - there are several people on here with vastly more experience than me in going this far out of the box in driver development.

The vast majority of drivers are not encrypted - Control4's are only if they are either C4's own devices, or a handful of exceptions due to licensing or security etc.

What you're looking to DO however is to create an interface device, not any 'source' or 'endpoint'.

Unfortunately, so far all the drivers I've looked at are strictly XML with no LUA in them. This tells me that the C4 Director is handling a lot of the communication on the back end. A number of the C4i files have comparable .DLLs in the \Drivers\Control\ folder where I think the fun stuff is happening.

 

16 minutes ago, Cyknight said:

To create what you'd want you'd have to likely treat both things as separate 'systems'.

Create a LCARS screen, and set it up to create triggers for each possible press - then communicate those triggers to C4 over some form of interface, serial or IP.

A driver can be created and you can set it up to have any type of 'device variable' and/or codes for each of the things you'd want to use - from there, you'd have to program C4 to act a certain way on these triggers.

You could conceivably then do this in full two-way communication as well - but keep in mind that it would potentially require a LOT of programming (as in composer programming) to go that far in C4, and additional programming on the LCARS side to accept the info and turn it into feedback.

The principal, in my mind, wouldn't be that different from a security panel driver. You may want to look and see if you can figure out one of those (serial would likely be easiest) and how it communicates in two direction - and have a look at some of the drivers made for 3rd party audio systems, also at their explanations (on how to keep the two in sync using programming).

My plan so far is to build a driver that is comparable to a configurable keypad. You could add and remove buttons in Composer and link them just like a C4 keypad. The app would then just have to send a "button press" command to the driver. The app would identify with a specific instance of the driver, just like a keypad. This is as simplistic as I could get the idea so far, and I'm mostly looking at this for use on wall-mounted smart-phones (you can get a smart phone for $40!) to replace the usual keypad. Adding additional screens and functions may come later, but I want to start simple.

Anyway, I've got an outline going for the app model that I'll be building a flow from soon. But being new to the Control4 side of LUA, I'd like to see some finished drivers. They don't even have to be related to what I'm trying to do, it'd just be nice to see what it looks like.

:edit:
Oh look, C4z files are just a standard .zip format.... who knew? 

Link to comment
Share on other sites

1 hour ago, jaycenornin said:

Oh look, C4z files are just a standard .zip format.... who knew? 

Most people who do driver :)

That said - and I WILL repeat that I'm NOT the best person on here to answer these more in-depth question - I think you misunderstand how Control4 uses LUA.

Link to comment
Share on other sites

If you're an on-call installer, presumably you're working with a Control4 dealership. Ask them to get you access to control4's training portal. There are 28 courses on there pertaining to drivers which will be a great start. Then as mentioned there's the driverworks SDK which is available in the dealer portal. From there, you could be the next Alan Chow. :)

Link to comment
Share on other sites

3 things:

Yes, there are .dlls for the C++ part of drivers.  The .dll types are used in Virtual Director, under Windows.  On a controller, with a 'real' Director, they're .so files, so the Linux equivalent of .dll's.

Second, that doesn't matter, because only Control4 can develop C++/C# based drivers.  All 3rd-party (and many Control4 drivers these days) are in DriverWorks, which always loads the same .dll/.so and same C# module, which runs the code of the driver in Lua.

Lastly, it's Lua, not LUA.  It's not an acronym, it's a name that means 'moon' in Portuguese.

.c4z's are 'open' .zip files, mainly because it's the standard way to containerize a variety of different format files, as some new drivers contain icons, etc., along with the driver's .xml and .lua files (which can be encrypted).

I second the notion of watching videos on the Control4 University if you're associated with a dealer.

RyanE

Link to comment
Share on other sites

17 hours ago, thecodeman said:

If you're an on-call installer, presumably you're working with a Control4 dealership. Ask them to get you access to control4's training portal. There are 28 courses on there pertaining to drivers which will be a great start. Then as mentioned there's the driverworks SDK which is available in the dealer portal. From there, you could be the next Alan Chow. :)

I already have the SDK for 2.6 that I downloaded ages ago but never got around to digging into. It's a long story but the shorthand version is the dealer I work with doesn't get a lot of business so I keep a day job and moonlight doing C4 every few months. It's been about 7 months since I last did a job for him and my dealer account has gone inactive. The 2.6 documentation references training on BlueVolt and I can still log in there, but apparently the C4 University there is no longer active (or it's tied to my dealer.control4.com account and has just locked me out). So until I get my dealer account reactivated I can't download the newer SDK nor do I have access to the newest training materials. Needless to say, I've asked my dealer to reactivate my account, but knowing him that could take weeks or even months. He's just that slow to respond (there's a reason he doesn't get much business).

So I'm reading over the documentation with the 2.6 SDK and I'm opening up drivers in Notepad++ and DriverEditor to figure out how everything goes together.

:edit:
Also, regarding the DLLs etc. The C4i driver for a keypad or keypad dimmer only has a couple dozen lines of XML outlining that it has buttons. The code that handles the actual communication between the controller and the keypad itself must therefore be handled outside of the driver. The fact that there's a "control4_keypad.c4d.dll" that's 640kb just reinforces my hypothesis (maybe it's a .dll for Composer and a .so on a live director, but the function is the same). Why C4 chose to do it that way over writing all of the code in Lua and wrapping it in a C4z file, I don't have a guess. 
p.s. My prior experience with Lua is with CryEngine, and I seem to recall it being capitalized (but that might just be my faulty memory). But if it makes you feel better, I'll adjust.

Link to comment
Share on other sites

Many/most 'Internal' Control4 drivers are still written in C++, and yes, those have very small .c4i files, with no Lua in them.

Most of those have C++ base classes, which implement much of the functionality, so it remains more efficient to keep them written in C++, while 3rd-party drivers and some new drivers which don't have base classes are written in DriverWorks.

RyanE

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.