Transmit Readings via SIM

Hi All,

I'm working on a small project and I need to send some readings from various sources onto the network. The intention is to use them much the same as the energy readings can be accessed.

So, for example, I need to measure flow rate and transmit the values say every 10 seconds or so. Just not sure of the best way to approach this or the basis of the commands that need to be sent.

For digital inputs setting GA on or off, this is easy and I've got it sorted. Any push in the right direction would be good. I still don't quite understand for example, how a measurement from the energy monitor would end up being consumed by the CTC.

Hope the above makes some sense.

Cheers,
Paul

 

I have written software to do a similar thing.

I read values from various pieces of equipment like my weather station and my APC UPS then sends these values onto the c-bus network via a PCI.

The short story is you need to convert each value into a C-Bus measurement application message and then send it to the PCI/CNI/SIM.

Once it is broadcast on the C-Bus network, it can be displayed just like any other Measurement from devices like the C-Bus temp sensors or current measurement units etc.

Cheers

Rohan

 

Hi Rohan, Thanks for the response.

So if I understand correctly I would simply transmit the following as an example

1. 0x0E - Measurement event with 6 arguments
2. 0x36 - Unit ID if this happened to be dec 54
3. 0x04 - For channel 4 of the unit
4. 0x00 - No multiplier
5. MSB of scaled measurement
6. LSB of scaled measurement

The bits that are unclear are:
1. How would I know that the bytes following the first command byte were associated with the 1st byte. If there was a bit of traffic on the network? Am I missing a vital piece, like including the ID on each transmitted byte or something.

2. How many channels can I have on one unit. Is there a maximum number or is it simply limited by the byte (255)

3. I'm still a bit confused about the measurement bytes 5 and 6 as to how to form them exactly. I'll do a bit of readon on 2's complement however for example if the reading I was returning was simply a pulse count of say 750 how would that look.


Regards,
Paul

 

Hi Paul,

You have mostly the right idea, but your missing a bit of the puzzle.

Let me go back a few steps.

If you want to communicate with C-Bus you do it via one of the interface units PCI/CNI/USB PCI/Sim Module.
These modules ommunicate with the outside world using a particular protocol. This protocol is specified and published as the C-Bus interface protocol and consists of several parts. All modules use the same protocol.

The protocol describes the overall communication framework for sending and receiving messages as well as the specifics of the payload message for each type of C-Bus application.
So it can be thought of as the main protocol wraps the application messages.

What you have described above is just the payload part of the message for the measurement application. What you have described is essentially correct (without me checking the documentation) but you are missing the main protocol wrapper that urns it into a valid message.

There is also an amount of setup messages you need to send to the interface first to tell it what mode and how you want it to operate.
If you look at the Quick start guide, you can see a simple example of how that is done as well as how to send and receive lighting messages.
You can essentially substitute measurement messages for the lighting ones in those examples.

Now about your specific questions;
You dont need to be concerned about associating the bytes, as they are all put together along with the protocol wrapper and sent as ASCII coded hex characters. i.e the value 10 decimal is 0A hex and is sent as the string "0A"

Because you are emulating a measurement device, that device must send its measured values with a Device ID and Channel ID these can be anything unique from 0-255 decimal.

The multiplier is a number that is used to scale the value. so you can represent very big and very small numbers and is 10^multiplier. This effectively shifts the decimal place left or right so you can turn the value 55 into 0.55 or 550000 for example.

The value is a 16bit (thats why there is 4 digits) integer value.

Dont forget all the decimal values and multipliers (in fact everything) are sent in ASCII coded Hex as described earlier.

Now if you are only ever sending positive values you dont need to calculate a 2's compliment, as the 2's complement of a value is the negative of that value. i.e. -55 is the 2's complement of 55 (as I was recently reminded in another thread)
The same thing applies to the multiplier, but if you have values with decimal places then the multiplier will be negative, so you will need to use the 2's compliment there.

To answer your last question the value for 750 decimal could be sent as 00 for the multiplier and 02EE for the value.

This has probably confused you a bit, and I am writing this on my iPad which is not the easiest to write long messages, but you should download the Diagnstics Utility and experiment sending and manually decoding messages using that, as it will show you the decoded message for you to check.

I hope that helps.

Cheers

Rohan

 

Hey Rohan,

I think I worked it out and had the message all typed up but somehow lost it when the session timed out. After looking more closely at the doco and using the diagnostic utility to generate a few messages I came to the same conclusion, so for example if I wanted to have unit 200 send a 26.3 lt/min message from channel 4, I would construct the following . . .

\05 E4 00 0E C8 04 0E FF 00 EC

where
05 - Point to multipoint, low priority
E4 - measurement application ID
00 - NFI
0E - Command Byte
C8 - Unit 200
04 - Channel 4
0E - Units - lt/min
FF - Multiplier -1 (236 / 10 = 23.6 lt/m)
00 - MSB not used in this example
EC - 236 decimal

Should I really send the lower case letter and look for the ack, or is it not that important.

I also noticed your post some time back where you wanted to use some unallocated values for additional unit types. I didn't really see a resolution to this as I would like to use a unit type of pulses per minute or pulses per second for example.


Regards,
Paul

 

The first thing that jumps out at me is the checksum is missing.

Second point is, you have a comment that MSB is not used. Whilst I know what you mean, it is used, it is just 00. Think of it as a 4 hex digit number, otherwise you might accidentally leave it out.

Without actually working out each value, it's either correct or pretty close.

Send the message values from the diagnostics utility (look for the measurement tab down the bottom) then see what the message looks like in the scrolling list.

BTW I think from memory the checksum is not shown for messages you send.

Sending the check char is a good idea, otherwise you won't know if the message was valid and received.

And no I didn't get any Official comment from Clipsal, so I just added a few of my own anyway. I can add yours to my unofficial list if you like, but be warned the display end also needs to know about them and if you are not handling that yourself and using a standard product, it will not work.

Cheers

Rohan

 

I didn't include the checksum as I didn't see it displayed in the diagnostic utility, that's fine, I have the function there to add the bytes and do it's magic.

Yes, should have been more specific about the MSB, I realise it is a 16 bit number and is "used", just zero for numbers under 256.

So, in regards to the measurement id number, (200 in my example) are you saying that this doesn't need to match the actual unit number in the serial interface? Actually that does make sense, and just looked at the configuration for the CMU where the measurement Device ID can be set at the unit level independant of the cbus device id.

Would be good to get some values on your list like pulses per minute for example, however that raises the question, if I'm measuring water flow should I . . .

Have the translation from pulses / sec to lt/min done in my unit, and use the units value for lt/min or simply have my unit send the pulse count every 10 seconds and have the CTC do the work?

Guess option 1 would be easier for others configuring the unit.

Open to suggestions here


Added: Actually, since gas usage is measured in MJ, would be good to get a MJ value onto your list rather than just the standard Joules.



Regards,
Paul

 

Correct

This is a point of some debate.
I believe Clipsal's view is the values should be sent using the base unit for that particular value, then scaled by the displaying unit.
My view is the opposite, I think the sending unit should scale the value and send the appropriate units so the display can just display it.
There is pro's and con's for both approaches, but in my case having the display relatively dumb was what I needed.
I think you need to look at how your going to display the value and on what to determine what capabilities that device has first. I'm could be wrong, but I didn't think you could display the full set of units on the CTC or wiser?

Anyway for what it's worth these are the extra units I have added to my devices, but remember the standard C-Bus units will have no clue what they are.

I tried to put them somewhere in the middle of the range where they would hopefully not bump into any official expansion.

$A0 KPH
$A1 MPH
$A2 Knots
$A3 mm
$A4 Inches
$A5 Degrees F
$A6 PSI
$A7 kPa
$A8 hPa
$A9 Feet
$AA Km
$AB Miles
$AC CM

Cheers

Rohan

 

Hi Rohan,

Thanks for the reply. Now that most of that logic is sorted, I'm looking closer at the comms for the serial. Which is the best approach when sending a message to the interface.

I gather that the response is based on the interface itself successfully putting the message onto the bus so using a response character is definitely a good idea. My question is more around timings.

How long should I wait for a response from the serial interface before moving on or taking some action. Also, does the interface itself handle retries or do I need to handle that again myself?


Regards,
Paul

 

If you use the ack character you will always get some sort of ack/nak if the PCI receives the message.

If you get nothing, then the message was not received (or was badly formed).
As for how long to wait, I don't know the official value, but in my experience it is usually very quick, so a few seconds should be ok, although others may know better.
BTW you can't assume the data you receive will be in the order it was sent, and it will often be interleaved with unsolicited activity data as well.
As a general rule you should not have a blocking send routine. You should send the command then stick it in a list or something and move on. When a reply comes in, then match it up and remove it from the list.

As far as I know, the underlying C-Bus protocol handles retries, so I don't, especially when it is a user instigated action, as they can retry it if required (which is almost never)

Cheers

Rohan

 

OK, all makes sense, I have some other bits to work on before actually trying to interface the hardware which shouldn't be too much of an issue.

So, I still kinda question whether I should send and check for the ack character, if the SIM handles the retries, and you never resend the messages it seems kinda mute to worry about it unless it's just to indicate a failure. I'll have to decide if my app would be that concerned.

Maybe I'll get the thing working first and sort the hardware as the firmware can always be upgraded

Regards,
Paul