C-Bus development

OK - firstly - I have just posted a Quick Start Guide.... (check for New Posts and you will see it). I will arrange for that to go up on the web site next week.

Secondly - please please please download and read AT LEAST the first 4 documents in the cbus protocol section of the web site downloads page.

You can't (and must not) just send any old commands over cbus. The commands have a structure and you must stick to it or all sorts of very bad things will happen. Those first 4 documents describe enough essential features that you will begin to see the structures that matter. After that the other documents fill in lots of holes. The Quick Start guide tells you some setup, and basic lighting control. What is in that document is about 1% of what can be done... but it is a short simple start.

If you want a s/w driver (you have downloaded the s/w driver for linux) then I might have a nice surprise for you in a couple of days.... just in time for Christmas. Source Code.

 

Yes. I don't know when this will get done, though.

Not if you design your devices correctly.

There is a bit of a common thing that comes up sometimes: "ooh, its just a bus, I can send whatever I like".... wrong!

You can't, you must stick to the defined commands. The commands define what happens on devices on the bus. Use the commands. If you make up your own commands, then they MAY overlap existing commands, in which case existing devices may interpret your commands and then do things you did not expect. This would be bad.

(Now you may say: "Oh thats OK I'll look carefully and allocate commands that dont exist". BUT this does not take into account that you don't set the commands for public release into the future, so your solution may work today and still turn to custard tomorrow when a new FORMAL application layer protocol is released. New application layer protocols have come out about 1-2 per year for the last 6-7 years... so going your own still poses a risk into the future. Hence, don't do it.)

When it comes to something like HVAC, you are in a different world... you really can do some damage with big chillers and compressors. For example, and little accident like switching a compressor repeatedly on and off might be a bad thing to do - for both your power bill and for the health of the compressor.

The lesson here: use the defined commands. And think.

I can't recommend anything! If it went bad you'd blame me! I can suggest things for you to consider but the choice of anything you do is yours.

I looked at the coolmaster documentation on the link you sent.

YOU CAN NOT JUST ATTACH THIS TO CBUS!

The coolmaster talks an ascii serial (text) command language. You need to do these things:

1. Understand the cbus Air Conditioning application
2. Design code that uses a cbus SIM to attach to a microcontroller or small microprocessor (attaching the cbus to the micro).
3. Write code running on that micro to accept cbus air conditioning commands, build an internal object model of the plant controller part, and then emit suitable commands to the coolmaster.
4. Similarly for taking information from the coolmaster and send things back onto cbus.

What you propose is not trivial. You will need a microprocessor with 2 serial ports (one for SIM connection, one for coolmaster).

Then you have a stack of firmware to write.

I'm really not sure what you mean. I get the impression you want to tunnel your own proprietary command set over cbus and do your own stuff on the other side of a "bridge".

Suggest you look again at how cbus works, especially the multicast communication aspect. There may be a disconnect between how it works and what you want to do.

As for making a bridge, or gateway, or whatever. This depends on if you mean a protocol translator, or if you mean an application layer object-model interface device. They are very different beasties.

You can't.

A SIM, like all cbus devices, will receive messages sent to an "Application Address". So will all other devices on that application address - they all receive those messages at the same time. It's an acknowledged multicast.

No. A SIM, like all other cbus devices, can transmit messages. If they are sent to an application address then there may be multiple recipients (but there will only be one sender).

Toolkit is commissioning software. Its process for things like "open network" are fairly abstract - there is a lot going on under the hood. But in general, the commissioning is about loading settings into devices, those settings determine the normal run-time operation of the devices.

There is a defined standard method of doing commissioning (and getting those settings into devices). This is NOT published as part of the open protocol set. If you want that level of access you need to request it through Cbus Enabled, and then you must do it exactly the way laid out. This is also all possible but not trivial.

 

Hi Ella

Thanks - this makes it much clearer. See below for some suggestions.

Ok - so you are the coolmaster developer - you are not trying to use it, you are designing / changing / improving it. Excellent!

OK, so you propose to put the SIM inside the coolmaster and use it to form the bus interface.

Understood. My SUGGESTION is that you model each A/C unit as a separate cbus HVAC Zone Group. This means that you need to pick some number of them that you can support, and then you need to run a number of object models (one per cbus HVAC zone group). (But see below for more information).

OK.

If you go the bridge path, you have imposed a new topology, effectively a virtualised cbus network sitting behind a cbus interface. This is possible, in theory, but it is very complex. I personally would not go this way, because it makes the setup of the device complex, its complex to commission, and its complex for other equipment to control it. Every message would rely on a suitable routing.

If you think of it as a thermostat with N zones, you end up with a different problem - how many is N? The cbus protocol - for zones - allows up to 7 zones, comprising an unswitched zone and 6 others. These zones are normally used for regulation inside a spatial area, or for really simple damper switching.

It *sounds* like you want to run one or more a/c units - so the question here is... "are these units ZONES inside a zone group, or should they be zone groups their own right?"

This really depends on how the coolmaster works, how you envisage zones working inside a zone group, how many zones you can have, and how many a/c units you can support.

Another factor to consider is: Do you want to allow the a/c systems to be controlled from a cbus thermostat? If you do then bear in mind that cbus thermostats only support a max of 4 zones (+ the unswitched making 5 in all). You CAN disable the plant control function of the cbus thermostat, allowing what you produce to be a separate back-end plant controller.

If you want to go this way, then there is really only one cbus message that matters - "SET PLANT HVAC LEVEL" - which is where the demand gets placed onto the plant. The plant controller then figures out how best to deliver that demand.

Part of this is answered above.

The terminology needs to be clear, it is often not clear and terms get used loosely with often wrong meanings.

PLANT - the big piece of equipment with motors and fans and things.

PLANT CONTROLLER - an electronic thing that takes a plant demand (using the SET PLANT HVAC LEVEL message), and figures out which compressors, fans, etc, to run to try and deliver according to the demand.

THERMOSTAT - a device that measures temperature, and produces a demand to the plant controller.

(NOTE THAT THE CBUS THERMOSTAT also includes its own plant controller for relay switched basic plant, but you do not have to use this.)

(NOTE ALSO that many thermostats do much the same as the cbus thermostat and include the plant control / relay switching funcitons.)

(NOTE ALSO that many thermostats are just a basic temperature sensor and ALL THE SMARTS is done somewhere else)

(AND FINALLY a thermostat might just be a mercury switch on a coiled up bi-metal strip, as they were 50 years ago).

So... what I'm getting at here is "be a thermostat" could have many meanings, from the very simple to the very complex.

There is a defined method of a CAL command through a SIM, allowing the device on the other side to be set up. You need to define a memory map to allow this, and then you need to EITHER write you own commissioning software, or work with Clipsal to integrate your commissioning into cbus toolkit. Both approaches are FAR FROM TRIVIAL! It may also be that you allow setup using for example a plain serial port and your own software - in which case you don't need to worry about CAL commands.

If you decide to go down the CAL commands path, then you need to go through the cbus enabled path to get more information.

I hope the questions above help you decide. A factor to include is how much time and money you want to spend. The tighter your integration, the more you need to do things the official way, and this WILL take longer (and therefore cost more, but it will produce a better result).