Hello @arrikhan - I still haven’t found the time to try it yet. But I’ve been using cgateweb successfully for years - where are you stuck?
Hello @Shubba - yes, you can leave a Pi permanently connected to your CNI. I was actually using a Pi Zero like this for most of the last couple of years. (I have now moved everything that was on the Pi Zero to Docker containers on a small i3 server, to avoid any future issues with sd card failure.) My Pi Zero (and indeed i3 server) live in a wiring cupboard alongside the 5500PC, just like your situation.
To get the data flowing in and out of Cgate the solution I am currently using is cgateweb. It is pretty rudimentary and old fashioned by today’s standards, but robust and reliable. (As I mentioned above, there is a newer solution that I am yet to try.) It was on the Pi Zero.
cgateweb acts a two way interface between cgate and MQTT (a pretty universally supported IoT messaging standard, in case you haven’t come across it). MQTT is built in to Home Assistant, so if you choose to run HA on your tablet then with a little fiddling you can easily get cgateweb to talk to HA.
So, yes, in practise the Surface Pro will run HA, which contains a MQTT broker, to which cgateweb on the Pi will publish, having connected to cgate which (via ser2sock) talks to the 5500PC!
FWIW I have ser2sock, cgate, cgateweb, an MQTT broker and Home Assistant all running on the same server in seperate Docker containers. (You can actually read a quick write up I did a few months ago of my then system here.) If you have a server room then I would strongly suggest that you run at least HA on a server rather than a tablet. If I wanted to use a tablet to control things (I don’t; I prefer voice) then I would have that tablet run the HA app to connect to the server.
I don’t use Google products, but my Amazon speakers are all integrated in to HA so that I - and, importantly, my spouse - can happily say “Alexa, goodnight” and the upstairs lights go on and the downstairs lights go off after 5 mins (regardless of whether they are cbus or other lights).
Thanks @PianSom
OK, so am a bit confused (it doesn’t take much :S) , do I keep what I currently have configured (on the homebridge install) and then add the cgateweb, MQTT broker and Home Assistant to that initial homebridge base, or do I flush the SD card and start again and install these on the Home Assistant install? Asking because when I go to the HA install (from their website notes), it looks like the instructions say to install on a blank SD card (https://www.home-assistant.io/hassio/installation/)
Hello @Shubba
In your situation - if budget allows - I would buy a new Pi Zero W and sd card, and use that to run ser2sock, cgate, and cgateweb. And then I would use your existing Pi to install home assistant on. HA will then be your MQTT Broker
I think that you will also be able to put homebridge on the Pi with HA, but if not then running it on the Pi Zero should be fine. (TBH it’s been so long since I did an installation from scratch that I’m not the right person to ask 
) Just so your existing setup continues to work. Alternatively, you may want to move to the Homekit integration that is included within HA - that is what I did a long time ago.
Then use the tablet to run the HA app.
Of course, take backups of your sd card before you start, so you have an easy way back if it all goes wrong.
Good luck, and shout if you need help.
I got cgateweb working. This is ok for now but I don’t think it supports much more than lighting due to lack of further development (guessing) which is a shame …
Cheers,
Arrikhan
Glad you got cgateweb working. Did you have a chance to try libcbus yet?
I did try this but it didn’t seem to like talking to my SHAC5500 CNI. Am not sure why but I will have a more thorough attempt. Auto discovery and the ability to see more than the lighting address that cgateweb limits me to (at least for status) is too good to pass up!
Why do people want to use libcbus ? I understand it removes CGate but what else is appealing ?
What other C-Bus applications does libcbus support that CGateWeb and the forked HVAC version don’t ?
If you have a SHAC then no need for either of these …
Hello @xAPPO
Well, I can’t speak for everyone else, but the reasons I am interested are
1 - Although the ser2sock+cgate+cgateweb combo is stable, none are being actively developed or maintained, and I would prefer to have someone I can go to for help if/when something goes wrong
2 - ser2sock seems to be a cpu cycle hog. Hopefully libcbus is more efficient
3 - one day I want to secure my mqtt broker with tls; no way of doing that in my current situation
4 - libcbus has more “modern” features, like mqtt discovery, which will streamline my HA implementation
All of these are “nice to have” rather than essential, hence the move to libcbus has not made it very far up my to-do list
(My c-bus system was installed 15+ years ago - no SHAC here)
OK… partly interested in case I’m missing out too
-
Agreed but there is a fork that adds HVAC control (a complex app) and because C-Gate is doing the heavy lifting it’s actually quite easy to add more apps if your C-Bus install uses them. The libcbus direct to C-Bus route is far lower level and much harder to code , or adapt. I am an authorised C-Bus Developer and implemented the C-Bus protocol in an embedded controller design about 20 years ago so very familiar with that.
-
I have not noticed this with my install but it is running on an i5 NUC so it is a powerful machine. C-Gate for me is running independently on a Raspberry Pi so my loading is divided. As I mentioned C-Bus decoding is more work than C-Gate so it might actually be worse. Just a view of course.
-
I have never worried about secure connection to my broker as I reason that if someone has access to that connect, i.e. my internal LAN, then I have bigger problems.
-
I only looked briefly and have seen that libcbus supports the time application and also a few derivative protocols of the lighting app, like enable and trigger (same protocol different app ID) so yes I appreciate that although surprisingly no HVAC but not many people use that.
The mqtt discovery is indeed useful into HA and not really hard to add to the C-Gate integration , but isn’t there currently or likely to be added. For me I didn’t want all my 140+ groups added to HAas both switches and dimmers so that has been quite beneficial but I can see it’s useful to most.
The SHAC which I recently got too to replace Wiser makes things much easier with it’s direct MQTT support. I saw arrikhan had one but as with everything Clipsal it’s overpriced and has seen no recent updates but works very well. Could do do much more though if Clipsal gave it some TLC.
Interested to see how you get on…
If MQTT HA Discovery is the big draw and I get a moment I might try and add that to the original fork. It’s not a difficult thing although it’s a low priority ‘todo’ for me as I wouldn’t use it.
I would however like the measuremnt app supported.
Re (3) the tls point - yeah, it’s a bit anal to worry about internal lan traffic encryption . But although I keep all my home automation devices on their own isolated vlan, ha stuff is becoming ever more entangled with everyday life. And one compromised device might give access to a simple brute force attack on my mqtt broker, which could be painful given the number of Tasmota’ed devices I have these days (nice article here). So, one day I’ll secure it.
Anyway, drifting WAY off topic
The want list is large and I can’t find the simple answers simplify integration of everyone’s setup.,
- Auto discovery enabled (less typing good)
- Track state beyond default lighting group (I use irrigation for example, and cant turn off switch on panel as it doesn’t track state, and I can’t log state to make decisions as it’s always off)
- Temperature sensor reading (I’ve used direct code in shac to post temps to topic, but that’s shac specific and most home users wouldn’t have one)
- Remove CGATE, Running more apps just adds more complexity, more things to go wrong.
I’m a n00b to shac coming from a wiser1 that was unstable/unreliable. All the coding I did in piced I’ve replaced with HA which is far easier when your automation is interacting and making decisions on more than just cbus devices.
If there’s a simpler way with a shac I’m all ears! … but I don’t want to forget about my friends using USB or wisers etc…
Arrikhan
@Shubba, in short… there are two install options for HA that I found.
1: dedicated image with OS+HA for a raspberryPI etc… ie: load image onto SD card, boot off SD card on RPI. You cannot load additional apps on there unless its managed through HA or you start mucking about with it which defeats the value of a prebuilt image.
2. Load HA application install on a Linux box or as a container. This method does NOT include supervisor functionality. You don’t NEED supervisor but all the howto vids out there expect you have it and there are some addons you need that are very complicated to install without it (for n00bs like me). I started this way…
Whilst my one experience isn’t the only one, I’d been on homebridge (lets call it HB) for some time resisting HA and it feels similar to where you are at. So here’s my story…
My primary use case for HB was Alexa integration for CBUS devices as well as Apple Home. I wanted voice control and I was considering automation in Alexa. I was taking care of most integration and automation within my CBUS network to date but this was limited to CBUS devices. HB allowed me to add more and more non CBUS smart devices as well and I got to a point where I was trying to suck BOM weather forecasts in to CBUS from my WISER to make decision on irrigation and I knew I was using the wrong tools for the wrong job (and my coding is crap).
So after watching too many DrZzs vids, and reading enough about CBUS integrations existing in HA from the great ppl in this forum, I made the transition … I loaded up HA using a container to keep things isolated and portable (on a Linux box). I’ve since moved this to a dedicated HA image on a second RPI to get Supervisor functions (this is so worth it, and all the howtos assume it). I loaded up an MQTT broker, cgateweb, and my original cgate container based on the ppls kind posts in here and the cbusforums on my existing RPI. After getting much working, duplicating my HB setup I decided to ditch HB as I felt like I just left the 2000s behind me using HA.
The outcome, a dedicated RPI3 for HA and a very underutilised RPI3 for integration pieces + CGATE (plus a bunch of other apps for music streaming, reverse proxy, etc) all running in containers. I now have so many devices plugged into HA I don’t know how I never got here earlier and there are so many people sharing and contributing to this world the support is incredible.
If this sounds like your journey, buy another RPI and install using a dedicated image. This means you download OS+HA as one image onto SD card and boot off it on your RPI. You CAN install HA (without supervisor) onto an OS directly or using a container on your RPI but the latter options mean you dont get supervisor (this adds streamlined addons installs, snapshots, system info. ALL YouTube howtos assume this btw and I think I’venow watched them all 
). Rebuilding / restoring using an image based approach is far quicker and far simpler than trying to fault find an install , reinstalling and restoring configs. If you come to rely on HA like I have, this is a better approach. This does mean you have to run the other components on a second platform. I bought another hefty RPI 3B+ just so I can reuse it some other day for something else, but CGATE, cgateweb and MQTT broker takes up very little CPU.
Anyway … there is my little story… I hope this helps you make a decision … or prompts you to ask more questions…
…and to keep on topic, having a CBUS addon that talks directly to the CBUS network means you could load this on a dedicated HA image using only one RPI.
Arrikhan
1 Like
It’s worth spending the time to get to know the SHAC as it supports nearly all the C-Bus apps and you can code MQTT very easily. Obviates the need for C-Gate and any library like libcbus.
I don’t have mine generating HA Discovery messages … but it would be possible.
Scripting on the SHAC/NAC can publish all C-Bus events to an MQTT broker and subscribe to MQTT topics without any hacks. No external C-gate needed or even CNI. Check out the C-Bus forums as the code is posted there.
2 Likes
Anyone using this Python based library with Home Assistant in 2022? Is it reliable?
About to spend some $$ on a C-bus network interface (5500CN2) and want to make sure the library works reliably before I take the plunge.
1 Like
Sorry folks, I’ve been buried in other distractions the last couple of years (gestures frantically at 
), and trying to pick this stuff up again.
The C-Bus + HA installation I normally maintain has been behind a bunch of border closures of varying degrees for the last two years, which really limits my ability to do anything. I have acquired some more kit during the last couple of years, which should make things easier.
The main reason why use libcbus is that it’s a fully open implementation, and you can get rid of some of the nasty binary blobs. Hopefully (when/if) I go missing again, the pieces are there that someone can implement more of the protocol, or move it to whatever the most fashionable home automation software is in 2025. 
To answer some questions / comments in the thread:
-
I don’t have a “newbie-friendly” turn-key solution for libcbus. If you’re familiar with using Linux at the command-line, and maybe know a little bit of Python (if something goes wrong), you can probably make libcbus work.
The install I manage has been ticking along fine… at least, I haven’t heard any complains from the owner.
-
I started working on the “excessive units” issue, but I can’t recall whether I uploaded those changes.
-
I started looking at Wiser 2 in the middle of 2021, from what I could tell the Wiser 2 presumes that it has exclusive control of everything, or that at most it needs to co-operate with Toolkit.
That’ll be a problem no matter which solution is used, but it’s a little less of a problem with Clipsal’s software: libcbus uses the “new” protocol mode that Clipsal’s documentation recommends, but Clipsal’s software uses the “old” protocol mode that Clipsal’s documentation advises against using.
-
If I was to suggest what you should spend money on right now, buy a USB or serial PCI; that’ll work regardless of whether you use libcbus or something else. Anything that has exclusive control of a PCI will generally be more reliable.
Supply chain issues have impacted availability of C-Bus hardware generally, and a bunch of the hardware I originally developed the software for is no longer manufactured. It sometimes pops up on auction sites, but outside of supply channels for electrical tradespeople, it’s very expensive.
3 Likes
hey @micolous - welcome back.
I’d like to engage you to develop your code into a official home assistant integration please.
I’ve had a go myself at developing your docker container into a supervisor plugin and its working but only just.
I think there’s a great oppotunity to have it as a proper integration or at least a non-crap supervisor plugin where people have variables for a CNI & address, MQTT address etc.
I’ve got a CNI serial and some cbus equipment im happy to donate to yourself to help along as as i mentioned, i’d like to engage you on a financial basis to develop this.
Drop me a PM and we can pick this up offline ?
Cheers
If anyone is interested in trying an addon for home assistant that runs cmqttd for connecting cbus to Home Assistant please give this a spin and let me know your feedback.
2 Likes