What does command reply ! mean?

Sometimes I get a command reply of ! which I cant find in the documentation.

I have found the following;
. = Positive ack
# = negative ack - too many retries
$ = negative ack - corruption
% = negative ack - loss of clock

But no !

Cheers

Rohan

 

I looked all over that document, and I couldn't see it.

I don't think it is related to an error in the command as such, because I can make it happen or not by changing the timing of the commands.

Is it something like "too busy to process" perhaps?

Cheers

Rohan

 

Did an electronic search of the document and I found it.

"The ! character reply is returned at any time if the PCI cannot accept the data supplied. For example, because of a checksum failure or because of the buffers were full and more information could not be accepted."

Cheers

Rohan

 

hmm ...

I agree this is a very ambiguous error ...

I just noticed that sometimes when a device on my test network sends a command, I receive a copy of the command preceded by the "!" character, but find the command is accepted by the rest of the network !@#!@

EG: I sent the command "ON //project1/254/113/05" from my C-Gate box connected to a PCI .. turning on a valve in my retic App ...

My CNI sent me a "!056571007905A7" .. however, my TouchScreen chirped in with a "056471007900AD" (turning on my master valve) as expected! so it received and processed the command with no problems.

The CNI was doing nothing else at the time (ie I was not sending it anything or expecting any other response - just monitoring the network so I could verify my reply processing!).

Or am I reading page 28 of the serial interface guide wrong and should just be processing the "!" character as a singular and not associating the following command - ie reading input to the <CR><LF> ... that is, receiving a "!" from the CNI just means it missed some data, but gives no idea what it missed, and if I didn't send anything, just ignore the "!" character?

Thoughts?

 

No ... cgate is just one of my machines ... The main development I am working on is cni/pci/SIM and hence the interest ...

I was using the cgate box to generate network traffic because I am lazy and it is easier to type a string there that the hex string on a pci!

 

Thanks for the network troubleshooting tips ... is a test network, so likely bus issues ...

interesting your comment about "insufficient" burden though ... I thought it was only ever max 1 per network?

PCI is USB dated 2009, so not too old ..

Of more interest to me at the moment is how to treat these characters in an application monitoring the network ...

While I cant make these errors occur, they do seem to happen soon after my application connects to the CNI and rarely after (so maybe no bus issues).

Is this more an error in the CNI doing a buffer dump to the client as it seems to do and then network traffic at the same time?

I recently also received a string where the "!" character seemed to replace the <CR><LF> between to SAL updates ... hence invalidating both strings as per chapter 4 of the protocol!

What do other applications do? just ignore the entire string between <CR><LF>'s?

 

you'll get '!' if the checksum is not correct, so if you're sending the command a second time, make sure the checksum calculation is right.

 

Think that was it ... some stupid programmer added some code and didn't mark it up ... no idea who that was, but I will reprimand him later

I had put in a status request command high up in my connection passage ... it didn't have a checksum at all (nor alpha) ... the CNI was echo'ing the command back to me, making me think it was coming from the network ..

I think I may add some new code in my connection passage to force the CNI into a mode I want .. ie ~A3300079 and ~A342000F (and their checksummed equivs) ...

 

Thanks Ashleigh ... yes, been going through the docos ... some are a bit ambiguous though and at times seem wrong (for example changing settings on a CNI seems to be sending me confirmation back with just a <CR> and not <CR><LF> as per the doco ...)

I didn't know about the source being available .. Im nearly finished my version, so will use that to compare too now (if I can find it!).

 

It may be because when you first connect, the CNI is set to one mode and you are communicating with it expecting it to be in a different mode.

For example, if the CNI was left in a mode expecting checksums on the messages and you start communicating with it with no checksums, you would get this happening. Once you have set the mode of the CNI, the problem will disappear.

 

Thanks Darren .. I am pretty sure that is exactly what the problem was .. I implemented the solution for this and all seems ok now

 

Ashleigh, has there been any subsequent revisions to the C-Bus Module source code since initial release that is marked version 3.30 2009-12-14 or is it really still considered "up to date" with current C-Bus functionality?

The reason I'm asking is: I'm needing to dust off the 5000SM/2's I have, to rework how my heating system works to reduce the dependance on custom DIY gear. I looked hard at changing to just using a few 5104DTSI units and in part of the house that would be fine but because of the way the 1-Wire Cat5 cable runs other parts of the house are quite hard to get at, so I need a way to work with the current temperature sensors and get their values onto the C-Bus.

Currently my heating system uses a bunch (20+) of custom DS28EA00 based Dallas 1-Wire sensors, connected to 2 x 1-Wire LANs in my house. The sensors connect to a RPi via 2 x LinkUSB 1-Wire to USB adaptors. I'm running OWFS on the RPI with some custom Python code that averages floor temperatures in each zone and implements 3 simple thermostats with 2 degC of hysteresis. I drive 3 x Opto-Coupled Triacs from I/O on 3 of my custom sensors to power the zone pumps and valves. Its worked like this for many years, but is quite custom and a RPI needs periodic maintenance, which is more than I'd expect any future resident or C-Bus integrator to manage.

So, I'm looking to move the Dallas 1-Wire temperature sensors into the C-Bus world using an ESP32 (as it has heaps of RAM) and the C-Bus Module software. The ESp32 has multiple serial ports to link directly to a 5000SM/2 (and maybe the PAC via RS232) so I can publish all the temperatures on C-Bus and maybe move the control back into the C-Bus world - so others can maintain it should we sell our house.

The ESP32 also has Wi-Fi and can run a simple web server as well which might be useful for configuring the Dallas 1-Wire IDs to C-Bus Measurement Groups for the temperature values.

Regards

Alex Shepherd