Controlling Lights from an eRVin Terminal Window
This post is for those of you that are eager to explore the inner workings of coachproxy/eRVin. And potentially for those of you that have a coach for which an eRVin configuration does not already exist and you need to create a ‘map’ of what commands are required to control individual lights.
A prerequisite to this post is that you have access to your eRVin Raspberry Pi (RPi) desktop, learn how to do that here.
Coachproxy users will not be able to access their system as described below because it does not support the Raspberry Pi Desktop or VNC . However, I believe coachproxy has SSH enabled and it is possible to accomplish the same thing by using an SSH client.
Here we go!
- Connect to your RPi desktop and open a terminal window, then type or copy and paste:
/coachproxy/rv-c/dc_dimmer.pl
- Hit Enter and you will be presented with a screen like below, This is actually an error screen because no command parameters were specified, but it provides a convenient list of all the possible commands.
- The command to turn on a light will be as follows:
/coachproxy/rv-c/dc_dimmer.pl 13 2where 13 is the lighting channel or “instance” and 2 is the “on” command. To turn off the same light the command will be:/coachproxy/rv-c/dc_dimmer.pl 13 3where 3 is the “off” command.
For now, don’t use any other commands except 2 and 3, more on this later.
So how do I know what the instance number is?
For Firefly panels 2015 and newer (G5 and G6), typically the instance number is equal to the number and light name printed on the front of the panel, or in the accompanying printed list mounted to the wall or a cabinet door nearby. For older Firefly panels there may be an offset between the printed numbers on the panel and the actual instance.
NEW! – in v0.6x configurations there is a new diagnostic tool that will display the instance number on your eRVin dashboard when you press a wall switch or Vegatouch button on your RV! Read about it <here>.
In the case of an offset, to determine what instance number goes with which light, a trial and error process can be employed. Simply send the command as shown in step 3 with a starting instance number and observe what happens, then send another command and increment the instance number by 1 – and so on. Build a spreadsheet or chart with the name of each light and it’s instance number.
The starting instance number can be 1 or an educated guess. In the case of one owner with the Firefly panel pictured below (from a 2014 Entegra) the offset seems to be 24 (although this has not yet been fully confirmed for all the lights).
In the circa 2012-2014 panel above, by observing the associated printed circuit list, we see the first 24 ports are circuit breaker loads and are not controllable instances. Positions 25 – 36 on the panel are lighting instances, these are probably dimmable. 37 – 44 are aux relay instances for the slide rooms. 45-64 appear to be standard relay channels that control non-dimmable lighting instances as well as the generator.
A standard Relay instance switches +12 volts on and off. An Aux Relay instance is typically a contact closure or possibly can be configured to switch +12 volts or a connection to ground.
Most likely the first light (Driver Side Sofa Lights # 25) will be at instance 1, the next light (Living Room Light Rail #26) will be instance 2 – and so on.
Tips and Other Notes
- When testing an instance, an actual light might not be activated, most firefly panels have a few instances with no physical light connected to it. Or it is possible you won’t notice the light, perhaps because it is outside or has a secondary manual switch. Even on the older Firefly panels, each instance has an LED indicator light that comes on when the light is supposed to be on, so if you don’t see a light coming on, watch the LED’s on the firefly panel itself.
- You should also be able to distinguish a dimmer instance by looking at and operating the wall switch buttons. Dimmer instances will often have up and down arrows printed on the wall switch and if you hold the button down the light should dim or brighten. Another way to tell if you are dealing with a relay instance or a dimmer instance is a relay will give a faint click at the Firefly panel when it is turned on and off. So use the 2 (on) and 3 (off) commands and listen for the click, if you don’t hear it most likely it’s dimmable.
- If you are SURE you have identified dimmable light instances, as an example you can send the following command:
/coachproxy/rv-c/dc_dimmer.pl 13 0 40
This will turn on and dim instance 13 to 40% (100 being brightest, 1 being dimmest)
DO NOT SEND THIS COMMAND TO A RELAY CHANNEL! If you do the relay will oscillate (you will hear it buzzing) and eventually burn out. - Sending the following command:
/coachproxy/rv-c/dc_dimmer.pl 13 5
Will toggle the light – if it’s off it will turn on, if it’s on it will turn off. The wall switches mostly send toggle commands in my experience.
- The following command:
/coachproxy/rv-c/dc_dimmer.pl 13 0 125
Will turn a light on and restore the previous brightness value. For example if the light was dimmed to 40% when it was turned off, sending the dim command with a value of 125 will turn the light back on to 40% dimmed.
Command line issue:
“pi@coachproxyos:/coachproxy/rv-c $ dc_dimmer.pl 21 2
-bash: dc_dimmer.pl: command not found”
So, I need help, please. Thanks.
Never mind, I got it to work. 🙂
Somwhat unrelated to lights but here goes…
I’ll bet you get a lot of inquiry’s and I’m sorry to be one of them.
Our Coach House as the Firefly G12 control panel, Vegatouch blue tooth interface, and the firefly touch screen. This whole system looks and operates like amateurs put it together and there is no cost effective way to get issues addressed.
I came across your website and thought there may be hope which is where my questions come in. If you have time to address I would be grateful.
My desire would be to use the Firefly G12 as an I/O panel and have something else provided the control logic. I would reuse (unlikely) or replace (likely) the touch screen with a custom programmed unit that actually made sense. I have an industrial automation background (PLC’s etc) but am unsure exactly how the Firefly system works. With this in mind, my questions include:
-Where is the Firefly control logic located (it now controls HVAC, load shedding, lights, etc.). Is there a way to defeat that logic and read inputs and control outputs with another custom programmed device (raspberry pi)?
-If so, how do I address/access the input data and control the outputs. I don’t seem to see that on the website? Did I miss it?
-In addition to the G12 we have an HVAC module, fan modules, and the vegatouch module. Are those modules addressable/accessible to another device on the network (raspberry pi)?
-Is the raspberry pi the only option for this type of control? There is a reason industry uses PLC’s and not PC’s for control.
Lots of preliminary questions I know. Thanks if you can address.
Will Lloyd
Hi Will, I have provided some basic info below. Yes I do need to find the time to write all this stuff up in a post. You can email me direct with additional questions at rob@myervin.com
-Where is the Firefly control logic located (it now controls HVAC, load shedding, lights, etc.).
Probably most of it is in your G12, possibly some in the touch screen.
– Is there a way to defeat that logic and read inputs and control outputs with another custom programmed device (raspberry pi)?
I’m sure that is possible to change the programming, but as far as I know, no one has hacked the Firefly/Spyder software. FYI most of the hardware you have is made by Spyder Controls in Canada. I believe Firefly is a value added (???) reseller? In the case of some coach brands, Spyder does the customized programming (Tiffin I think is one example), otherwise it is Firefly. Firefly in my experience has become difficult to work with and charges a kings ransom to do any kind of customization. However, there may be a workaround by isolating devices on either side of a bridge, more on this below.
-If so, how do I address/access the input data and control the outputs. I don’t seem to see that on the website? Did I miss it?
First to know is the whole thing is RV-C CANbus based. This is an open protocol and is fully documented online at rv-c.com. Some of the functions you mentioned, such as lighting, are basic RV-C devices in your G12, so simply receive an RV-C command for off/on/dim and then send status info back to the CAN. In these cases the G12 doesn’t really do any decision making so these are easy to control by some other device such as eRVin. In fact when you turn on a light from your touch screen or a wall switch, those devices simply send the RV-C command, and then listens for the status and reports it back to the display. eRVin or any other device sending the same commands is fully compatible – turn on a light with eRVin and the touchscreen or wall switch will show it’s on and vise versa. The same should also be true of fans, shades, etc. Where it get dicey is for things where the status of inputs determine the output, load shedding logic for example. There is preprogrammed logic (probably in the G12) that is doing something like watching the AC line current, then making a decision to shut off an AC circuit if needed. While eRVin or some other device can easily do a similar function, this is a case where you would need to find a way to disable the Firefly version if you wanted to roll your own. As mentioned previously, there is a way I know of to do this by using an RV-C bridge to isolate the device being controlled – basically block the device from receiving commands from the Firefly and insert your own. In regard to HVAC, I’m not really sure where that logic is, possibly it’s in the touch screen. But I think regardless of where it’s located, you could probably override the touchscreen settings. I don’t have one of those so aren’t that familiar with the specific PGN’s (RV-C commands). That is of course as long as there is nothing proprietary (not RV-C based) going on. I know in a few cases on the Vegatouch Entegra’s there are proprietary commands involved. They can be figured out, but it takes a bit of sleuthing.
-In addition to the G12 we have an HVAC module, fan modules, and the vegatouch module. Are those modules addressable/accessible to another device on the network (raspberry pi)?
Yes, as described above, as long as all the modules are RV-C devices, just like the lights, any other device can control them. The Vegatouch module is probably a special case, it is mostly just a variant of an eRVin/coachproxy device (end user interface), but may have some additional capability. Sorry I don’t have one so don’t know many details.
-Is the raspberry pi the only option for this type of control? There is a reason industry uses PLC’s and not PC’s for control.
No, anything that can talk to the CAN at 256K with extended frames could do the job. However, that could entail a lot of reinventing the wheel. Here’s a quick overview of how eRVin works: eRVin/coachproxy is basically a gateway. One function is to listen to the RV-C and gateway all the RV-C PGN data to MQTT. Another function is to send RV-C commands back to the RV-C to get something to happen. The intermediary of all of this is programmed mostly in Node-Red which runs on the Pi. If you’re not familiar with it, it’s a graphical environment with a plethora of “nodes” that have inputs and/or outputs and do specific functions. The nodes are “wired” to each other to create a “flow” of data that gets processed in some meaningful way. Customized “function” nodes can be written in javascript. Node-Red also has MQTT nodes and the original coachproxy developers took advantage of that. The current version of eRVin/coachproxy uses a perl script rvc2mqtt.pl that constantly runs and parses all the RV-C traffic to MQTT which is then processed in node-red. There is a newer version rvc2mqtt.py written in Python (by Michael Kidd who invented coachproxy). The nice thing about these scripts is they present all the RV-C info in JSON format so it’s easy to read and process in node-red. But now there is even another option, a “socketcan” node for node-red that will talk to the CAN directly so there is no need for the MQTT conversion, eventually I want to explore a node-red only version of eRVin that doesn’t need customized scripts. When node-red needs to send a command to the CAN, it currently uses a specialized perl script, there are several that handle different types of data, for example one for lights, another for shades, control of a generator, etc., etc. Again, using a socketcan node, this data could be sent directly to the CAN. Node-red also has a bunch of “dashboard” nodes, so has the user interface built in.
So of course all of this could be done in another environment. I have minimal coding background and little coding expertise, so for me it was easiest to go with the flow. I have since become somewhat proficient with node-red and I’m even having a lot of fun with it.
In regard to PLC’s I actually found some excellent node-red tutorials from this site: https://opto22.com/support/resources-tools/videos/playlist-node-red-workshops
I have found the Pi to be extremely reliable for both my RV and Marine applications. Unfortunately it is very hard to get right now at a reasonable price. I have a couple of RP2040 boards from Seeed Studio with a CAN interface built in for $14, but the RP2040 can’t run node-red so that will be a big learning curve for me. My idea is to use the RP2040 or a Pi Pico to create my own RV-C customized devices.
Looking forward to working with you in the future.
Thanks a lot for the detailed response. I have a lot to read and learn. As I become more retired I plan to focus more on this. I’ll share anything I figure out. Will
Greetings. What file or files do I need to modify to customize myervin (Coachproxy) for my rig? I have a Tiffin Wayfarer 25TW 2023. The only configuration in the program for a Wayfarer is for a 2018 BW. This configuration (with my RPi) only partially works – I can control just one light and no vents. It reads the status of the tanks fine, but not the DC voltage. Thanks. Elliott
Just starting to play with this. Thanks for creating! Has anyone integrated with Home Assistant? Thanks
Stephen, yes several folks have done that. Randy Lust is one I am aware of. I think he hangs out on the coachproxy Facebook group. There may be others over there that have as well. I haven’t tried it myself, most of the logic for what I want to do I’ve just been able to do in node-red itself.
I really don’t understand why Tiffin isn’t adopting coach proxy and using it.
If I were them I wouldn’t touch it either. As a former IT guy myself I don’t need to imagine the support headaches involved. Especially when you throw in things that are totally non-Tiffin related like Alexa, ngrok, etc. If they could devise a way to produce a lucrative revenue stream, perhaps, otherwise I doubt the ROI would be anywhere near positive, and if they did I’m sure it would cost you a pretty penny. Throw in the open source nature of RV-C, which changes often, and the tendency of the RV-C product developers to be proprietary, and the plot thickens. I don’t know the circumstances, but my guess is Mike F had to close coachproxy down to retain his own sanity for similar reasons.