I'd like to determine the means of interfacing with comfort that will have the least latency in communicating sensor and alarm state to an external controller.
I've experimented with the Eht02 interface but there is a noticeable lag between a sensor triggering and a message being sent. I have an RS-232 interface but haven't got round to measuring it yet. Is it likely to be any faster?
I was wondering if the UCMs themselves introduce latency and if there was a way of using the native RS-485 bus directly?
RS232 may be faster only because ETH02 has to go through the network
The UCM directly sends all messages from the bus. There is very little latency
However sensors have a sensitivity setting in the zones settings eg 500 ms to prevent false alarms so the "latency " may not be due to the UCM
You cannot access the RS485 bus direct as that may affect the communications
You can see what is on the bus using the Bus Monitor tool in Comfigurator
The ETH02 is a serial to ethernet convertor
It translates the messages from the Comfort bus into a format which can be used by Comfigurator and other applications
So while it is true that ethernet can be much faster than RS485 the data rate for Comfort messages is still 9600 bits per second, the same as the Comfort bus, so it cannot become 100 MBps or 100 MBps. Sending messages on the network does not speed up the comfort messages
However the network itself can introduce latency or delays due to other traffic on the network eg streaming video
I think you've partly answered my question but I don't quite see how some of what you say is relevant.
Latency and bandwidth are two independent properties of a communication channel. My question is about the latency, not the bandwidth. You are stating bandwidth figures. Of course we aren't going improve the bandwidth or latency.
In this case there is no other traffic on the network. and I'm suspecting that the translation between RS485 and ethernet is introducing latency. I guess I can measure this by timing the difference in receiving over ethernet vs serial port but I was hoping someone might already know if this is where the latency is coming from.
Last edited on Wednesday Oct 23rd, 2013 09:01 am by Tas
The UCM will see data from the Internal RS485 bus and convert to serial data. The Ethernet module converts that to ethernet packets
There may be accumulated delays but they should not be significant. If you can provide any latency infomation let us know
If we consider that there is no congestion on any of the interfaces then the RS232 interface will be the quickest.
As Ident explained, the RS485 bus message is translated to RS232 at 9600bps, if I remember correctly, at this point it is ready for sending on the wire. Because things are hardcoded you have a few variables. Some of these are internal chip buffering and then most importantly you have the delay associated with clocking each of the bits out on the line at 9600. Add all these up and you get the absolute minimum delay that can be achieved from an output.
If you look at the Ethernet module you have the added delay of converting the RS232 signal again to Ethernet and then add it's own transmit delays.
In all honesty, all these combined should be fairly insignificant. The biggest contributor to perceived 'slow response' is the sensor itself - if it's a PIR device then it has to properly 'see' movement before it sends a command on the bus. Then you have your response latency, by this I mean your PIR trigger a response, the response does something and set's <something>.
I give you an example on Cbus. I have a Comfort PIR, first it takes some time to 'see' movement, once movement is detected there is something called 'debounce' delay to make sure there isn't multiple triggers for one event. Next, Comfort detects this and fires a Response. More processing is done to execute the response. Inside my response is a Cbus command that is fired over to the UCM/Cbus. Now we start the whole process again, the Cbus network is also waiting for the complete command to be clocked out on it's network, it then has to activate either a relay or dimmer depending on the command sent. All this takes time and doesn't happen instantaneously.
If you explain what you want to achieve perhaps we can help but to answer your question on which is faster? RS232 or Ethernet? Then the answer is RS232.
The quickest test you can do is to connect a door switch to an input and a relay to an output. Note the debouce time of the input zone type and then write a response to switch the Output On|Off as you press the button. You will find the response close to immediate once you subtract the debounce delay, which you can set to a different value at your own risk of false triggers.
Thanks for for taking the time to answer my questions.
I believe I've eliminated what's introduced by the sensors but still see a delay which is human observable. I will attempt a more objective test based on comparing rs232 and ethernet on comfort.
What am I trying to achieve. On the design of my next system I am considering maintaining home-automation logic outside of comfort while still leveraging the sensors that are connected to it. I'm trying to determine if any latency will be introduced and what the best interface is to use.