Andrew H

I'm sure they do have redundancy ... within the AWS cloud. Keep in mind that a large scale outage like this is uncommon for AWS. While I agree that its very inconvenient to have all of their cloud services offline for a day, lets not pretend as though AWS does this often, or that C4 is the only major company who experienced outages as a result. Having an in-house server for redundancy negates a lot of the incentives of using a 3rd party cloud provider in the first place. Maintaining both increases both the cost and work required to keep everything online, where the main benefit of a hosted solution is to decrease both cost and effort. If AWS was dropping off like this every week, every month, or even once every couple of months then, yes, it would be reasonable to suggest that they move away from hosting there or that they have redundancy someplace else. That's simply not the case though. Here I would tend to agree with you. I can see why authentication is best done through their servers, but it seems like there should have been some fail-over process which would have allowed the controllers to authenticate locally. I'm not familiar with the details of Control4's authentication process, and it's possible that something like this is in place but was not triggered due to the fact that AWS was not totally offline. Again, that's just speculation and if someone from C4 would like to correct me, I'd be glad to know.

According to Control4's status tracker the AWS outage is causing issues with many SnapOne services.

Hey Nick, You are correct in thinking that you'll need to have both Python3 and Lua installed. I would recommend using your Ubuntu machine for this if you're comfortable with it and/or willing to learn. I do all my driver development on Ubuntu and have had good luck so far. First, start with installing Python3. It's important to be sure that you're using Python3 (not Python2, often referred to simply as Python) to be able to use dp3. After you've installed/updated Python3, install pip3. You can use the command 'pip3 --version' from the terminal to check if it exists on your machine already. If it does, you can skip install. Pip3 is the package manager for Python3. You are also correct that you will need to install M2Crypto to encrypt your drivers. You should be able to install lua using the command 'sudo apt install lua5.3' . Squish does not need installed apart from installing lua. As for getting the driverpackager tool: open a terminal session where you wish to store the utilities. I'd go somewhere close to where you will be writing your drivers for ease of use. You can use the command 'git clone --recurse-submodules https://github.com/control4/drivers-driverpackager.git driverpackager'. This will pull everything from the driverpackager github module. Here's how I've found helpful to structure my development folders. DriverDev driverpackager createc4z ... dp ... dp3 build_c4z.py driverpackager.py encrypt_c4z.py squish dplite ... dplite3 ... gosquish ... .... MyDriver1 driver.lua driver.xml others.lua manifest.xml squishy MyDriver1 squishy ... MyDriver2 driver.lua driver.xml others.lua squishy manifest.xml MyDriver2 squishy ... Then, from the terminal, inside the folder DriverDev, I can call 'python3 driverpackager/dp3/driverpackager.py MyDriver1 DestinationLocation manifest.xml' DriverEditor and driverpackager are two different tools for doing the same thing. DriverEditor is a Windows-only tool that will build your c4z file for you, and will encrypt it if you mark your <script> tag with 'encryption=2'. If you choose to go this way, you'll have no need for driverpakager. The reason that I and others suggest to use driverpackager over DriverEditor is that the latter is slow and buggy. I found it to be helpful in learning the anatomy of a C4 driver, but it quickly became the biggest hurdle to me in writing drivers. I also prefer to work in Linux as much as possible, and driverpackager gives me the freedom to do that much easier than using DriverEditor. I hope this helps. Let me know if I can clarify anything.

The Github link (driverpackager) is definitely where you want to look. That said, I had a hard time getting things going until I figured a few things out with driverpackager. YMMV, but here's the steps I had to take in order to get driverpackager to work correctly on any of my projects. 1. In the manifest file, you don't need to point to every lua file that you use, since they'll be squished into one file before encryption. You'll also need to include the encryption option in the Driver tag. Ex. <Driver type="c4z" name="sample" squishLua="true" Encryption="True"> <Items> <Item type="dir" name="www" recurse="true"/> <Item type="file" name="driver.xml"/> <Item type="file" name="squish.lua"/> </Items> </Driver> 2. You'll need to create a file called 'Squishy' that details how lua should squish your source files. That follows the basic format of Main "../driver.lua" Module "common.c4_command" "../common/c4_command.lua" Module "common.c4_common" "../common/c4_common.lua" Output "squish.lua" For each module, the first option is the module name. The second is the file path so that the squish utility can find it. Each lua file that you intend to be packaged into your driver should be listed as a module. In my experience, I have to have two copies of the 'squishy' file. One goes in the main project directory, and one goes in a folder inside the main directory with the same name as the project directory. It seems that the one inside the subfolder is the one that gets referenced, but both have to be there to squish (this is why I have all source files prepended with '../' : the output seems to know where to go). I can't explain why this is as I didn't bother to look too far into the driverpackager utility and debug what was going on, but I was never able to get my lua to squish without including both. No squish, no encrypted driver. 3. You need to amend your script tag in your document.xml file to point to the output of your squishy file and to include 'encryption=2' to use the newer c4 encryption method. ex. <script file="squish.lua" encryption="2"> 4. Run the driverpackager utility specifying the project directory, manifest file name, and output directory. I always run with the verbose option to get some more useful information on output.

You'll need a valid copy of Composer Pro to be able to test anything. Assuming you are a C4 dealer, you should have this. If you are, there are some resources on the C4 training site that explain the basics of how drivers are set up and work. You can watch those for a fundamental understanding, but I found it much more helpful and interesting to learn by poking around at the driver templates that Control4 provides. Also available for download on the C4 dealer site is a tool called DriverEditor 3.0. This tool is good to use to learn the structure of drivers as it provides a C4-specific interface in which to write your drivers and includes C4s packaging tools all in one program. I'd use it to start, but I highly recommend switching to Visual Studio Code or some other toolset once you have a basic idea of what makes a C4 driver tick. There are also publicly available resources at Control4's Github page. They have their driver SDK listed there, which includes most of what you need to create your own driver. The three that I reference the most are the DriverWorks Fundamental Guide, the DriverWorks Proxy Protocol Guide, and the DriverWorks API. As mentioned, C4 does provide some driver templates that you can use to reference/ model. These are especially helpful in understanding how the C4 proxy works, and can be built upon if you are building a driver that fits one of the proxy's especially well. The last tool that I use in driver creation is the DriverPackager tool. The tools in that last link are what you need to bundle your driver into a c4i or c4z driver file for use with Control4. I hope this enough to get you started.

@LollerAgent You would need to be an Authorized Mirus Dealer to do that. If you're interested in more information on that process, you can contact our sales/info guys using this form and they will contact you with answers.

This is correct. Mirus is a dealer only product. We have C4 integration through custom drivers that give you network control of our products. We have drivers to control our LED products (single channel dimmer driver as well as 3 channel driver for RGB), as well as drivers for our contact and relay products, and our ARL(Audio Reactive Lights) module which works with our driver suite to make lights dance to music.

Check out Mirus Lighting

Mirus Lights are great for both accent and recessed lighting. The systems are all low voltage and are great for whole-home panalized as well as smaller systems. We have both strip and can lights offered in white as well as RGBW.

I have my computer connected to serial port 2 (DB9) on my EA5. This is connected to my computer using a DB9-to-USB adapter. Have you tried your setup using a second serial cable?

I tested the blind_proxy_template this afternoon using PuTTY on my computer, and I was able to get serial data to communicate both ways. Are you seeing anything at all in the Lua Output window of your blind proxy driver? Any errors or anything that I could possibly help you troubleshoot?

So you have your computer running realterm and connected to your C4 processor, correct? And you can see data sent from C4 to your computer but not the other way around? I've never used realterm, so I'm not very sure where to begin troubleshooting on that side. If you can not see any data coming back from to Control4, make sure your serial settings such as baud rate are set the same on both systems. I would have to think that you have that correct if you are seeing data even one way, but again I'm not familiar with realterm to know how it works. The only graphical wizard that I am aware of for creating drivers is DriverEditor. If you're comfortable writing the lua and xml in an external editor, you can open your project in DriverEditor to generate the c4z if you are more comfortable doing that. I would suggest though that you don't have your project open in both DriverEditor and an external editor at the same time as I've had this cause issues from the DriverEditor side.

C4's Python tool (called driverpackeger) does allow you to generate .c4z files. What are you doing with ReceivedFromSerial()? If you haven't yet, try adding the line print(sData) as the first line in the function ReceivedFromSerial() in the file c4_serial_connection.lua (found in the common folder). This will show you what exactly C4 is reading in on your serial binding. I'm not quite sure I understand your last question. Are you asking about navigator and composer categories? Those are used for driver organization inside of C4, so choose whichever looks closest to the intended application of your driver.

As Ryan said, a proxy mostly serves as a way to give interaction to your end users through the C4 UI. If you will not need UI integration, a proxyless driver is the best way to go. To do this, your driver should effectively reference itself as its own proxy. You'll need to set an additional flag in your xml file <combo>true</combo> As for your proxy tag: <proxies> <proxy> My Driver Name </proxy> </proxies> The templates are still a good place to start and to learn how C4 driver structure works, but I'd recommend writing your own for your application. Without knowing how the other (non C4) side of your device will work, my guess would be that you should look specifically at C4:SendToSerial() and ReceivedFromSerial() in the C4 API. Another thing worth noting if you're just getting started is that DriverEditor works for creating drivers, but I'd recommend using Visual Studio Code with the Control4 extension instead. C4 provides a python tool on their Github for packaging your driver as well. These two tools work much better than DriverEditor in my opinion.

Hi Antek, The driver type that you'd want to choose depends largely upon what inputs and outputs you need to integrate, and what you need to do with them. There's not enough information in your post to determine which I'd recommend. Can you give me a better idea what you are trying to accomplish? As for documentation, I typically find these documents to be the most helpful for most of my drivers. Control4's Github also has a lot of good resources for learning/modelling, including more documentation and some example projects. Do you have any specific questions or things that you're trying to accomplish that we could help you figure out?

Not related to the DALS lights driver, but more to the original question: Mirus Lighting offers RGBW cans similar to the ones shown in the original picture as well as RGBW LED strip that is all controllable through Control4.

I am writing a driver that needs to be able to dynamically create and destroy SSL connections in order to connect (and disconnect) to an indeterminate number of devices. Due to the inherent unpredictability of how many devices will be connected at a given time, I need this to be able to be done programmatically. I'm comfortable enough with Lua, and have written a few simple drivers before, but none with this type of requirement. I'm essentially looking for the opposite of C4:CreateNetworkConnection(). Can someone point me in the right direction? I looked at the example drivers provided on C4's Github and it looks like they use C4:NetDisconnect() calls to 'remove' connections created with C4:CreateNetworkConnection(). I attempted this approach, but all it seems to do is to temporarily (until my reconnect handler executes) break the connection, without actually removing it. So far, the only thing I've found that will remove the connections is doing a driver reboot, but I'd like to avoid having to do that every time I need to remove a connection. Thanks all!