C-Bus Driver for Charmed Quark Controller

Hi Folks,

Just a quick note to let you know I have finished, and am currently testing, a C-Bus driver for the CQC control software.

It will be available FREE with CQC.

It interfaces directly to a C-Bus PCI. I have got it talking both ways and it understands the commands on, off, ramp to, ramp to over time, both initiated from CQC out and from the C-Bus network in.

It auto discovers the network and the initial boolean state of the loads (off or not off).

It creates fields that match each of the programmed "Group addresses" it finds on the network as well as a "Command" field that can be used to send any command to any group address, to handle "Area addressing" and "Phantom addressing".

More information on CQC can be found at

http://www.charmedquark.com

and there is a user forum at

http://charmedquark.com/phpBB2/index.php

This is an example of the kind of user interface page that can be built with CQC.

This particular one is displaying a weather page.

Rohan

BTW This is not my product, I just think it's fantastic!

 

That is excellent news.....

 

It is great to see people integrating products with C-Bus. Keep up the good work

There are a couple of points to keep in mind for people considering using this driver :
1. You will need to obtain a copy of the C-Bus Public Release Protocol before this driver can be used.
2. This driver has not been developed under the C-Bus Enabled Program and hence has no guarantee nor support from Clipsal Integrated Systems.
3. No technical support can be provided for a C-Bus site while any non-certified product is connected. These devices will need to be disconnected before technical support can be provided by CIS.

 

Can you clarrify, isn't this related to HARDWARE and since this uses a PCI which is certified then I thought support was in place?

 

Thanks for the positive feedback guys.

I think the more stuff that talks C-Bus the stronger it will get.

It is also worth noting that CIS to not charge any money for a copy of the public release protocol, it is more of a registration process. The reason this step is required is it is possible to reverse engineer the driver and figure out the protocol, however if you already are entitled to it, then their is no point.

I have discussed this very point with Ashleigh and we have a process in place to make the process as quick and easy as possible.

I'm also interested in Richo's comment, I would have thought he was correct, as I am not connecting anything directly to the network, I am simply interfacing via RS232 to a PCI in accordance with the Public Release Protocol.

And I fully understand that support can not be provided for my work by CIS, But you will be able to talk to the CQC folk and me.

Regards

Rohan

 

Yes, we will certainly provide support for CQC customers wrt to any devices we provide drivers for.

 

Fair point.

Rohan

 

We may submit it for compliance testing at some point in the not too distant future. I assume you just snoop the bus while it's connected and see what activity it causes? This particular driver is quite passive from what I understand and would only send a wee flurry of messages at connection and a little activity when CQC causes a write operation through the driver.

 

What we'll probably have to do in the long run is for me to take the driver that Rohan has done, which will have all the issues pre-worked out, and just translate it to a C++ driver. We prefer not to do any drivers in C++ if we can avoid it, but sometimes it is necessary. We didn't go that route in this case because Rohan was doing the driver and we only expose CML/PDL languages to end users to do drivers in.

But, with a known working driver, and my being able to get access to some test hardware (that I can actually plug in in the US , I could pretty easily convert it to a C++, but that would mean that the driver then becomes only updateable by us, though Rohan could still work in CML and pass on changes to us to implement.

In terms of purposefully throttling output from the driver, I'm not sure that's really advisable. Our users don't pay us to tell them what they can do. If they tell us to write something to the device, we write something to the device. It's not our place to do otherwise.

 

Ok, here is a bit of a rundown from my perspective.

The driver as written does not poll, in fact using the Public release protocol it can't poll. I do agree that having to poll a device just to see if something has happened is bad design, on both ends. What I do do is poll CQC's own RX buffer to extract any inbound information. This buffer is initially loaded with unsolicited inbound activity i.e. someone turnes on a light from a wall switch.

Yep, this is well understood and I can see the benefits, I just neet to crawl before I sprint

This is very similar to what I am doing. The 'model' if you like resides in CQC as a series of fields (group addresses) that have values (levels) associated with them. It is the job of the driver to keep these fields up to date with information it receives from the network and transfer the values of the fields back to the network if they are changed by the user. The model is updated as traffic is received from the network and only sends outbound commands as a result of the user actively pressing a button, or initiating the action.

I do however take your points, and I understand where you are coming from. Long term I will probably write another version that uses C-Gate or your enabled dll, but for the moment what we have is functional, and so far through the testing I have done, reliable. It was designed to be used by me and anybody else who wants it, in a domestic environment.

I think the best thing to come out of this is it demonstrates CIS's willingness to work with third party providers to enable connectivity, and third party companies desire to achieve the same. It is discussions such as these that help everybody in the long run. Even if we disagree on some points.

This is my 2c worth, and remember I don't represent anybody but me.

Regards

Rohan

 

Oh, OK. I didn't catch at first what he meant by a model. But yes, CQC is a highly network distributed system. There could be, in a large system, 10 or 20 'customers' of information from a given device out there on the network. There is no way that could be dealt with if every request from one of those clients caused a round trip out to the actual device. CQC drivers cache in memory all the info about a device that they make available, and that information is served up to clients on their behalf by the CQCServer service that the drivers run inside. So requests for state data don't even go all the way to the driver, CQCServer gets that data from the driver's cache. And a pretty elaborate scheme of 'serial numbers' insures that only those values that have actually changed since the client's last request even get streamed back over the network to the requesting cient.

So the only activity that a CQC driver imposes on the device is polling activity, if that is required and in the bulk of devices out there it generally is required, and outgoing messages that are caused by a client CQC application somewhere on the network asked to change something in the device. In that case of course it does require a trip all the way out to the device to cause that change to happen.

But in a device that provides asynch notifications of state change, the driver is almost completely passive and is just accepting changes and storing them in the driver's 'fields' and that data is being served up to clients out of that field cache. It's highly efficient and minimizes latency, and can scale up quite well.

 

Here I disagree. I think each unit on the network needs to play it's part in ensuring the network doesn't become destabilised. If the minimum each unit does is maintain the consistency and reliability of the actual bus, then its failure (defect or bad configuration) can be limited and generally easier to find.

If a unit fails in such a way to destabilise the newtork this can create a large scale failure of the system which is very hard to diagnose sometimes.

I believe you should consider adding this feature into the driver as it not only helps protect the installer from causing problems accross the entire network. But also makes it a lot easier for the installer to islolate problems if something does go wrong.

Using your current concept the installer has take on responsibility for understanding network bandwith and transmit rates and need to allow for this in every aspect of the configuration of your software. This isn't fair and adds unnecessary complexity for the installer. If the driver takes on this responsibility the installer can just configure your software to do the job and driver ensures it is done correctly.

If all for giving the "power to the people" and letting them do things their way. Flexability is great. I'm a software developer and thrive on it. But when the flexability becomes counter intuative and makes my life a lot harder and may cause the destabalisation fo the system, I'm all for constraints.

 

I think maybe you misunderstood what I meant. The installer generally doesn't have to understand anything other than how to install the driver and what features the driver makes available to him or her.

The user/installer driven activity are typically things like configuring button X or IR button press X to write value Y to field Z, for instance to turn on a light. That's mostly what is going on. Yes, it's theoretically possible they could write a bad macro that would loop, writing the same value over and over until stopped, but even that's usually not a problem, because CQCServer (the service in which drivers run) will not even call to the driver if the new value written to a field is the same as the previous value written to that field, because it won't have any practical effect.

The only exception are 'command' type fields, in which a string field is used to pass in non-value stuff, such as "ON : GROUP1 10" or something like that, which the driver parses and turns into one or more outgoing messages. Because of the nature of those fields, they are marked 'write always' so that the written value always goes through to the driver. And there are toggle fields, in which any value written will cause them to toggle, so they are usually marked as 'write always' also, since it doesn't matter what is written to them to cause the toggle.

Anyway, only via a gross mistake, of the sort that would be quickly recognized, could the installer or user cause a high rate of outgoing activity. But in any practical usage of CQC, they have no need to understand anything, other than in those cases that are of the opposite sort, where a device is really slow to respond after certain operations and they need to insert artificial delays, or watch for a new state to arrive, before invoking a subsequent operation.

But most operations are of the sort of 'press this button, and that causes this message to be sent to device X' (though they see it as a much more abstract level), so I don't see any real need to have the driver provide artificial governers of user driven activity. It's rare that any user invoked action is going to kick off a really large number of operations. In terms of those types of pathological errors like an endless loop, some burden has to be on the installer or user to verify their automation logic, IMHO, rather than putting artificial limits on what someone can do with their own system.

And of course most outgoing operations will wait for a positive acknolwedgement from the target device, which provides a natural throttling mechanism for just a fast (but legitimate, as apposed to bug) burst of operations. The driver can only feed out those operations as fast as the device will accept and acknowledge them.

Of course Rohan can do whatever he wants, but I personally don't really see a need for this.

 

I think the point here is clear and everybody is essentially agreeing.

Take all reasonable steps to prevent a device (any device) from thrashing the network.

The driver that I have written, combined with the architecture of CQC it's self, will make that almost impossible.

I dont believe it is any worse than having a user continually press a button on a wall switch for example.

Anyway the proof of the pudding will be in the eating

Regards

Rohan

BTW When will the new C-Gate documentation be ready, that will probably make all this a moot point

 

By the way Rohan, I never did say great work in writing the driver. Everyone in engineering is truly happy that third-party gear is turning up around the place. This is great for Clipsal and great for our customers.

Sorry if the direction the thread has taken some of the gloss off of that.

Good questions. I raised that recently and will do so again with the relevant people.

 

For my part, please don't ever hesitate to raise any issues or criticisms you might have of our product. I will argue my point if I think you are wrong, but I NEVER take it personally, ever. Business is business, and we can't improve if we don't get feedback about what people think is wrong or might be wrong. I'm basically un-offendable, at least since they upped my meds