[Control4 Driver Wizard Serial
Abdul Soumphonphakdy
There is a Lumagen Radiance Pro in this system. This is a high end 4k video processor. The existing driver simply treats this device as an AV switch. It is, however, much more. I have written a new RS232 driver using the closest category (Receiver) and have included all the relevant functions with the intention that a GUI would be created by C4 with the appropriate Arrows-Enter-Menu, etc. However, when I click on the icon, all I get is a blank screen. Is there a way, for a novice, to create a GUI for this product?
I made that old driver - originally for the XD series - and I know their site hosts the 'dvd proxy' companion driver. Using that driver and an IR connection, you can bind it to an unused input and select it and have control over the functions.
if you use an sr remote all of the buttons are mapped to the keys if you programmed them, but the touch screen ui is only meant to select sounds modes. and if it has a tuner will give you some basic tuner options when that is selected.
Well, I feel pretty stupid. I programmed a new driver, using the DVD proxy, and while it allowed me to set up all the HDMI input/outputs and gave me an acceptable GUI; C4 will not accept it as a switch. All codes and macros work, but C4 will not send the HDMI input switching commands to the Lumagen. I see now why the existing IR driver was tag on to the AV switch driver. Is a full blown A/V processor proxy with switching, and a GUI, a missing link in C4, or is this type of driver beyond my novice capabilities?
I opened up the OppO Gateway driver in Notepad and found the proxy statements. I also found that the OppO 93 driver had one of the tags referenced "5001". I did not find the Netflix or Vudu proxys. To create a similar driver, what driver creation program do I need to use? The "create a new driver" in composer does not appear to have any options to combine proxys.
The driver wizard is out dated, limited and not really good for anything but a basic IR driver (serial is also only one-way) - you'll have to dig into the more advanced driver creation using Driver Editor.
I set up an EA-1 for basic training and testing. It's running 2.8.2. Everything was working fine originally. About 2 weeks ago, I became unable to edit any of the drivers (IR commands and such) on any of the devices. I've tried a full power cycle and pulling/readding drivers to the project over the same timespan. A couple other issues come and go, such as the wrong audio device being controlled, but that's a different connection issue I think. Any ideas on the drivers? I can also add a copy of the project if that will help at all. Thanks
I just looked. The one I need to edit is a c4z driver (Device File: cable_ir_xfinity_x1_v2.c4z). I'm trying to set up a program that tells my receiver to turn off whenever the cable box turns on so that the audio is routed and controlled correctly. However, I checked my tv driver (that I used to be able to edit) and its a c4i (Device File: tv_Samsung_PN51F8500AFXZA.c4i) I haven't been able to edit anything since before I swapped to the new Xfinity driver.
That driver, at least the existing one in the database, is a combo serial/ir driver - by default meaning it's a driverworks driver, Driverworks drivers cannot (and could never) be edited in Composer - I fear I'd have to say you're likely mistaken int hat you ever edited THAT specific driver.
That may be. I don't think I ever had a reason to try to edit the TV driver. I think I just had to change the power on delay. My old receiver didn't have a driver so it might have been that one that I was thinking of. It adding actual abxy buttons to the Xbox one. Also had to mess with the old x1 driver (c4i) to try to fix the previous channel button. I haven't tried to do that on the new driver (that's c4z so I can't anyway).
Driver WIZARD is the built-in tool in composer. It's a limited tool in that it only does fairly simple driver - basic IR drivers and one-way serial drivers, as well as is only able to make a/v equipment drivers.
DriverWORKS is the term for the SDK that allows for far more complex drivers to me made, but isn't really a (computer) program as such. It is/was used to to create more complex dirvers, such as two-way serial, IP, combo control drivers and even in some instances more complex IR drivers (drivers not for a/v, receivers with multi-zone function and some of the later added proxies like iPod and mediaplayer etc).
I suppose any driver could be considered a driverworks driver, and it isn't completely accurate to say that a driverworks driver cannot be edited be driverwizard (you could make a driverworks or drivereditor driver that you can still edit with driverwizard) - I suppose I generalized a bit in my earlier post on that.
* All other "C++ Driver API" drivers, which do not use Driver Wizard or DriverWorks. This includes all touchpanel, controller, most lighting device drivers, etc. These are only written internally by Control4.
If I understand it right there is only some list of driver types and I do not know which type to choose, our goal is to integrate Inputs, Outputs, both analog and digital (I think that it will be some bridge between two systems).
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 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
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.
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.
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.
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?
The content contained in this repository is the intellectual property of Snap One, LLC, (formerly known as Wirepath Home Systems, LLC), and use without a valid license from Snap One is strictly prohibited. The user of this repository shall keep all content contained herein confidential and shall protect this content in whole or in part from disclosure to any and all third parties except as specifically authorized in writing by Snap One.
The content in this repository is provided in connection with Snap One products. No license, express or implied, by estoppal or otherwise, to any intellectual property rights is granted by this document or in this repository. Except as provided in Snap Oneʼs terms and conditions for the license of such products, Snap One and its affiliates assume no liability whatsoever and disclaim any express or implied warranty, relating to the sale and/or use of Snap One products including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright or other intellectual property right. Snap One products are not intended for use in medical, lifesaving, or life sustaining applications.
795a8134c1