Project questions

[spbrogan]

This is more a question (would be great if you enabled discussions in this project). Is this project alive and kicking (you did merge my pr quickly. :) thanks)? Do you have any type of roadmap or ideas for it? I did see one other person fork it recently and enable the service in docker (which i really like). I am looking for a solution for my keystone RV and trying to decide between a couple of projects and/or running my own thing.

My goals are really just to get and set basic RV-C devices from my 2021 keystone cougar in home assistant.
I am a software developer by trade so i have some familiarity with this stuff but just getting up to speed on rv-c and even mqtt.

look forward to hearing back from you.
Thanks

[DumpySquare]

I have been watching projects like this one in the same endeavor to integrate the RV systems into HA, especially since HA is working on a watch app! I'm interested in helping where I can if you find a project to collaborate on. :)

[linuxkidd]

Discussions are now enabled! :)

The project is alive.. but life has gotten in the way on making more progress. I originally created CoachProxy ( which is now open-sourced at CoachProxyOS. This project 'rvc-monitor-py' is meant as a drop-in replacement for the Perl decoder that's part of CoachProxyOS.

As far as roadmap -- my intention is exactly the type of thing you're talking about... creating a proxy layer between RV-C ( and the rvc-monitor.py output / input ) and Home-Assistant. We ( @greendog99 and a few other random people here or there ) have discussed that that proxy layer would look like, but we've never gotten to consensus.

Ultimately, I think the best option is to have the 'proxy' handler allow for declarative configuration ( via Yaml ) the same as the decoder does. The way some devices in the coach are handled causes a lot of pain with this approach.

For Spyder Controls based RV-C systems (at least), not all of the controls in an RV are mapped to the explicit RV-C DGN that you'd think would be used. Example, Shade controls -- on most Tiffin coaches, the side of the coach with the highest count of motorized shades have a dedicated 'shade' controller, which does use the Windows Shade status/control DGNs. However, on the other side of the coach, they use the DC_DIMMER command/status DGNs which require turning on one dimmer ID, while turning off the other, in order to roll the shade up or down. Same for roof vents. The 2 speed ceiling fan in the bedroom also has 2 DC_DIMMER ID's associated, one for low, one for high -- but both cannot be on at the same time, and both off == the fan is off.

There are also variations in how heated floors are handled, based on the year of the coach. And, how the heating / cooling controls are handled, etc...

So, the declarative configuration has to be flexible enough to handle simple things ( Light to DC_DIMMER_ID mapping, easy ), to much more complex things which may need lots more helper code.

Very welcome to more contributions in the form of discussions, code, issues, etc..

fwiw, I use my CoachProxy with additional helper code in NodeRED to interface with HomeAssistant.

Welcome! I'm excited to see people interested in the project. :)

[greendog99]

As for me, after 7 years on the road full-time we sold our RV and are stationary again, so all my tinkering time goes into "normal" home assistant stuff, not RV-C related. Hope this project keeps moving forward though... would be great to have a real replacement for the old CoachProxy code some day :-)

[spbrogan]

Thanks for the updates and the background.
I did some pretty big refactor although i think you both will recognize a lot of code.
Because of that i spawned a new project. https://github.com/spbrogan/rvc2mqtt

I moved things around. Tried to decouple the rvc, app, and can layers. I cut out the MQTT layer so at the moment it really is just an RVC decoder. I plan to add back once the floorplan concept (map/config) is integrated.

My goal is next to make the docker image a little better, take a config file from a docker volume, and do the same with logging.
The idea with the config volume is that someone deploying the container could adjust the config from their host without having the change the docker image/src. I also think the config volume could contain the simple mapping file and maybe even a "python plugin" that could translate devices to friendly sensors. Anyway, just wanted to give heads up. we will see where the project will go and if any of that sounds interesting feel free to contribute in any way you see fit.

[linuxkidd]

Thanks for the link! I'm happy to see someone moving forward with an HA integration.

I'm curious.. what hardware are you using? Still the Pi + CAN-bus hat? Or something else?
( I ask because of the docker use -- seems excessive for a Pi.. :D )

[spbrogan]

I am using a pi zero right now...plan to switch to pi3 (lower power than 4 and wired ethernet).

Docker..because it is just so easy to keep iterations isolate and do deployment. it doesn't mess up native packages on the raspberrypi and lowers the dependencies. A pi 3 or 4 could run a fair number of docker containers without much impact so again it really is just about the easy deployment and maintenance model.

[rlust]

Happy to help with testing! I have an Entegra Aspire 2022 and using the CP version from ERVIN on pi 3 with CAN, and running latest HomeAssistant on pi4. I am using the HUE integration on HA to control lights and awnings and Node-red in Home Assistant to read sensors with MQTT.