C-Gate on Linux

There are a number of threads here about this, and I've read them, and I now have C-Gate working fine under Ubuntu 11.04.

However, most of the threads are relatively old and all seem to be mostly theoretical. So my question is: is anyone running C-Gate on Linux for a real 24/7 application?

Everything else that I'm going to be running for my application will run better on Linux so I don't want to move to Windows unless I have to.

 

Not quite Linux

While it's not Linux, I've been running C-Gate under FreeBSD for some years. Have some basic web page control and a few TCL apps/cronjobs running around to automate some things.

 

This is good to hear!

Partly because I'm nosey, and partly because I'm looking for anything that'll give me confidence to proceed down the Linux route, can you tell me anything more about your setup? (Eg size of the application? Any problems you encountered?)

 

As for problems, there has been remarkably few. It's handy to have a decent XML file editor available for 'tweeking' the comms. settings but it's not essential (like kxmleditor for example). I originally had some TCL apps driving an Ethernet based interface using the direct interface code. This worked well but the lack of multiplexing on the interface unit was a problem if using more than one app. So then I switched to C-Gate running on a serial port interface to fix that (and that still allowed the Ethernet version to be around if needed). It's been a while but there was a bit of fun getting the COM Java interface stuff all working, not too bad and my dislike of Java prob. made it seem a lot worse than it was ;-)

Having a PC running all the time could be a problem (but not for me), but there are some pretty nice low power units that could be used. I've seen some nice 'all in the plug-pack Linux boxes' with a very small power load that would do the job nicely (with an Ethernet, or perhaps USB interface).

I'm toying with the idea of doing an embedded 'C' version of C-Gate on a small PIC32 with one of the 5000SM/2 I have sitting around waiting until have some spare time. This would get rid of the PC issue (and the Java issue ;-) There's a bunch of other uses for such a thing that I'd love to try out as well - if only I had the time ;-(

 

That's certainly good to hear! Thanks for the useful; info.

I have C-Gate running on an Ubuntu Server virtual machine with 512MB RAM. I am noticing that the CPU usage sometimes gets very high, which I can fix for the time being by restarting C-Gate but that's not a long term solution. Any hints on how to control the memory/CPU usage?

Are you using the Sun JVM or a different one?

I have one here to play with one day, but unless I can get it to play nicely in 512MB RAM on an x86 platform I don't think I'm ready for it yet!

 

If you have a ReadyNAS already running I expect it would make an excelent choice for a C-Gate platform. It could source some music at the same time ;-) I'm not sure if there is a ready made Java plugin handy but I don't expect it would that much work to get going (although I still think a 'C' version would less painful ;-)

In response to your question more-solutions, I'm running C-Gate via the FreeBSD native port of Java 1.6 but have run it under most versions as they popped up over the last few years. As mentioned the only effort is getting the COM rxtx stuff working. Looking at the direction Java is taking that could be even more difficult in future. 512M of RAM should pose little problem I've often run small servers in that, careful trimming of the basic system maybe needed and it can speed things up a lot if you have a larger (but compatible) machine to do any of the source builds on (unless you have a lot of spare time). I've not noticed any problems once it's up & running but typically it's only running with an uptime around 60 days or so, which is the typical time-frame between rebooting the machine for other reasons. I had it on s small VIA mini-ITX board for a while but decided that as I had a fully-fledged server running all the time it may as well run on that.

 

I too would love to have an embedded C-Gate solution, with minimal power usage for 24/7 operation. Ideally a C version but Java is fine too. One of those Linux in a plug devices would seem ideal.

K

 

I'd be interested to know what

Code:

java -version

reports?

Mine was saying:

Code:

java version "1.6.0_22"
OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1)
OpenJDK Client VM (build 20.0-b11, mixed mode, sharing)

.. which was a surprise as I thought I'd installed the Sun JVM (so many virtual machines!); it now reports:

Code:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

so I'll see whether that makes a difference. (My instinct was to use IcedTea if it worked but to start with Sun, so I'm not doing things in reverse.)

That is definitely worth knowing, as we're planning to use a CNI but there is a PCI on site already that I could just hook into, so knowing not to make assumptions about how easy that might be may be a life saver!

I'm testing in a low memory environment to catch problems early, but the final version will run in more (maybe as "little" as 1GB, maybe more but not less).

I'm looking forward to this!

 

Hey there.
I am in this boat too and can offer some info for you.

I am running C-Gate on an OpenVZ Debian server. Info on it is below.

It is running full-time now with the C-ChangePHP web frontend on it with apache to allow for simple web based access to the lights.

I am surprised how much memory it is using now you have made me look at it haha.

Code:

cbus@cbus:~$ free -m
             total       used       free     shared    buffers     cached
Mem:           692        379        312          0          0          0
-/+ buffers/cache:        379        312
Swap:            0          0          0
cbus@cbus:~$ java -version
java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode)

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cbus     21919  0.0  7.2 320260 51632 ?        Sl   Jun13   3:35 /usr/bin/java -jar cgate.jar

 

Thanks for the comparison. My figures for the same things are:

Code:

$free -m
             total       used       free     shared    buffers     cached
Mem:           495        434         60          0        122        201
-/+ buffers/cache:        110        385
Swap:          507          3        504

$/usr/lib/jvm/java-6-sun/jre/bin/java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)

$ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     10720  0.1  7.3 291976 37260 pts/1    Sl   Jun13   7:53 /usr/lib/jvm/java-6-sun/jre/bin/java -jar -noverify /opt/cgate/C-Gate2/cgate.jar

I've made no attempt to optimise this yet (Java isn't something I know well). Running it as root isn't great either before someone points it out (it's a test box but that's not really a good excuse.)

 

That's all fine as long as I'm confident that the resources will be managed within the constraints of the hardware. I'm looking at a basic Linux server with 1GB RAM for the current job, which aside from C-Gate will need to run a webserver and database but not a lot else. The operating system + web/database stuff would run in 256M (probably less) if it needed to, so there should be plenty left for even a large C-Bus system.

I need to do some more tests; it's the high CPU usage that worried me (the system was "idle" at the time, in that there were no lighting changes being initiated via C-Gate, and nothing much happening on the networks themselves aside from routine sync stuff). However that was with the non-Sun Java, maybe things will be fine with the "genuine article"?

Is there any way to spec this? Eg for 8 networks, 50 devices/network, 600 groups site-wide, comms via one CNI and multiple bridges; what server spec should I expect to need to keep C-Gate happy?

 

Hmm, lets see;

java version "1.6.0_03-p4"
Java(TM) SE Runtime Environment (build 1.6.0_03-p4-root_23_sep_2010_09_41-b00)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-p4-root_23_sep_2010_09_41-b00, mixed mode)

So somewhat older, but not unexpected as this machine is overdue for some software upgrades (mainly the O/S which is 2 versions behind the current).

as for memory....

PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
2656 cgate 37 44 0 1248M 105M sbwait 1 6:52 0.00% java
2779 cgate 1 44 0 51040K 16796K select 0 0:01 0.00% wish8.5
2684 cgate 1 44 0 9188K 2892K ttyin 1 0:00 0.00% bash
2635 cgate 1 57 0 9188K 2892K wait 3 0:00 0.00% bash


which looks hi (yes Java is somewhat bloated), but is not a very accurate indication. A 1Gb machine could handle this type of thing without hardly noticing it. Just don't run all the other junk usually found on a desktop machine and you would be hard pressed to even notice that C-Gate was ever running. The bulk of this stuff wont even be paged in. The only real issue is the time it takes to build Java from source on these small machines ;-) This is on a FreeBSD box rather than Linux, but I'd hope that the memory performance wouldn't be too far off. I tend to prefer FreeBSD over Linux as in the past it's been much more work to admin. Linux boxes and when there's more than a couple it becomes an issue.

I switched to the serial port version of the Cbus interface as so far it's been more reliable. I've had one of the Ethernet ones die for no obvious reason, and it's replacement will go 'off the reservation' every year or so and require a cold boot to get it back on. I suspect the Ethernet to serial module is not as robust as it could be, but I may have just been unlucky.

The home setup has 2 networks (wireless gateway) and perhaps 50 or so units (all the lights and a few other bits & pieces) so not overly large. One of the stranger duties it has is to keep the Yogurt maker box at a constant 40 degrees using a wireless dimmer and a halogen light for the heat source. Which is done with an old Tini Ethernet based Dallas-semi 1-wire temp. sensor scripted back to the C-gate box which turns the light up/off to control the temp. It was only a temporary hack at the time but when something works it tends to hang around....

 

Hi
Can you please tell me which version of java Cbus was compiled against?

I am getting the "unsupported major.minor version 52.0" when starting CGate on a Raspberry PI. The Pi was working prior to upgrading to the latest CGate (V2.11.4). I believe the error message means my version of the jre does not match the version CGate was compiled with. But happy to be wrong

thanks!

 

Latest CGate requires Java v8
For my last build I used this.
sudo apt-get update && sudo apt-get install -y oracle-java8-jdk

 

Just for reference from CGate release notes
"C-Gate 2.11.0 Released April 2017
What’s New Java 8 Update C-Gate now includes a Java 8 JRE instead of Java 7"

 

Thanks!,

I did that but it was still showing Version 7. It turns out I had to set the default Java:

sudo update-alternatives --config java

 

As a general update to the old original post; I've been running C-Gate for over a year now on Linux. I do find issues with the Windows C-Bus toolkit and PICED working properly with this C-Gate server. There are repeatable issues with programming the EDLTs when using this remote C-Gate server that don't happen if you use the local Windows C-Gate server.

My current (Jan 2019) setup is:

• Clipsal C-Gate v2.11.1 Build 3240 Date: 20170606-0311
• Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux
  
• openjdk-8-jre:amd64 8u181-b13-2~deb9u1 OpenJDK Java runtime, using Hotspot JIT

I have a long background in developing web and server software. I personally find the documentation poor. Official support is hard to track down. The community is great when they can help.

I guess that part of the problem is that there are a lot of moving parts in a C-Bus system. I'm mostly happy with the C-Bus hardware - though the EDLTs continue to be a pain - with things like the proximity sensor turning the switches on ever 15 minutes etc. My installers solution? Require a physical click and turn proximity off.

I have a real problem with the software though - I have a WISER2 acting as the gateway to the C-Bus network. The Wiser2 / PICED / FLASH architecture is dire - Flash has been discontinued for years, and will soon be removed everywhere. I've asked - and been told there isn't a solution planned. I'm not sure where that leaves us - it is getting harder and harder to keep / run old insecure browsers, even in VMs.