Ness M1 unable to handle CBUS traffic

Hi all,
Wondering if anyone has hit this problem and particularly if anyone has solved it.

I have got a Ness M1 Gold control panel hooked up to a CBUS network via the standard ness interface board, but whenever traffic on the cbus network builds up, i.e. if there is an all off command issued from the PAC, or other detailed scene, the Ness M1 disconnects itself from its own keypads which begin to beep.

I've done days of diagnostics with it, even with the help of Ness, and have tried replacing almost all the Ness components, but still can't fix the fault.

The issue did not exist with the V1 and V2 of the cbus board, however we had to upgrade to the V3 board due faults with the earlier boards design, which result in commands being regularly missed. (The V1 and V2 missed commands due to poor design, so I'm not surprised they work differently)

I am able to easily reproduce the problem using the CBUS toolkit by simply toggling a group address rapidly and observing the Ness keypads disconnecting, basically like clockwork. The big problem is the keypads go into an "unknown" state during these events, so it can be problematic if someone touches the keypad when it disconnects. (which would typically happen when arming as the system doe an "all off" when the alarm is armed)

CBUS network is pretty typical, about 50 units, including DLTs, indoor sensors, Neos, standards, PAC, dimmers, relays, changeovers, CNI, PC Interface, (no couplers) Termination looks normal, cbus logging shows no retransmissions or anything unusual. I've done some basic experimenting with removing devices from the network without much luck (within limits as I don't want to pull the whole network apart)

Ness has checked out the M1, no identifiable wiring issues, and we checked basically all parts for faults. So can't blame poor data bus wiring or rules programming. At least if thats it, Ness can't find it.

Only other thing to note is the V3 network connection is not 100% reliable when talking to it with the NessRP software, and despite having changed now to the V3 board, I still see missed cbus commands from the M1.
Cbus network is otherwise rock solid if you exclude the M1 problems.

Anyone seen anything like this?? Any ideas?

I was able to help Ness replicate this initially at their labs but now they say the can't replicate using the V4 board, however I've tried the V4 and it does not make any difference (actually does not even talk to the network interface). I have a feeling its got to do with one of the more interesting cbus devices, perhaps DLT's or sensors.. perhaps there are commands being issued that the ness board just cannot handle and because the Ness labs have cut down cbus networks they have never tested it with a fully CBUS system. I note by observation that the Ness system does not seem to follow the normal rules or handling errors for the network, so I wonder if its not processing something on the cbus network correctly.

Anyway, looking for ideas. Happy to post more info if it will help.

Paul

 

Paul

while I cant answer your question, you might have more luck posting in the M1 forum on the ness site. Reps from Ness are on there and will be able to help with more technical issues.

http://www.ness.com.au/nessforum/index.php

Mick

 

Hi Guys,
Thanks for the responses.

Actually, I've been talking with the Ness guys about it for a few months now. They already tried sending me a new firmware that did nothing but they claim it fixed the fault I reproduced for them in the test lab (Seemed like the same fault but I reproduced it differently to my test case here. Hence perhaps it was not the same fault)

In any case Ness seem to be short on ideas, and I have not seen any progress for about a month.

I was hoping to see if any other cbus people might have hit something similar and have some ideas to help the Ness guys understand the problem. Ness say there was one other customer with the same problem, but it was caused again by a different issue.

Interesting what your saying about the diagnostic program. I can trigger the issue so easily with it.

Technically, it appears that the cbus interface board is overloading the M1 control processor with "work" causing it to stop talking to the keypads. So again that would be a multi-tasking error with the M1.

All of my testing has been around confirming the reliability of the system, so I'm 99% confident that there is no technical glitch with the way things are connected, either with the ness gear and with the cbus gear. Only caveat on that is I am not 100% confident on the M1 network interface, BUT I can reproduce the issue with the network interface board totally disconnected.

Matter of fact I can disconnect everything except for the cbus board, M1 and 1 keypad and get the issue just the same, even with every rule deleted from the M1. Soon as the clipsal network data is entered into the M1 it causes the fault.

To me, it sounds like firmware.. but why it triggers for easily for this system, and Ness claim they can't reproduce it in the test lab after making the latest firmware adjustment, is the issue I can't figure out.

Another question perhaps worth asking, is there any other traffic on the cbus network that could make the cbus interface work harder than normal based on the cbus network configuration?

If I could work out what was special about this cbus network, it might help.

F.Y.I. Encase it triggers any ideas, the cbus network is configured as follows
3 x 5504D2A Dimmers
1 x L5508D1A Dimmer
1 x Elk M1 V3 board
1 x C5032NL Keypad
4 x C5034NL Keypads
1 x 5034N Keypad
5 x 5055DL DLTs
15 x 5058NL Neos
1 x 5500PC PC Interface
1 x 5500PC CNI
1 x 5500PACA PAC
3 x L5504RVFCP Change Over Relays
4 x L5512RVF Relays
1 x L5508RVF Relay
2 x 5753L Sensors

Total of 44 active units.
At the Ness lab they have standard relays, dimmers, one pac (un-programmed) a PC interface and a couple Saturn switches in their Melbourne test lab. I don't recall if they have any of the other types of components, but it was pretty basic and I don't think its complex enough to provide a solid test bed for trouble shooting these problems.

Paul

 

I've had the V1, V2 and V3 M1-cbus boards. V1 and V2 had problems wrt missed commands, V3 seems mostly fine. I've never experienced the M1g shutdowns you describe and would be very surprised and concerned if it is a system issue, since it would allow disabling of an M1g alarm system by deliberately flooding cbus.

In your shoes I'd keep doing as you describe, sniffing cbus looking for anomalous traffic associated with the problem. It may not be volume at all, but a particular sort of traffic. I see you have a PAC, as do I: check out your rules/triggers to make sure they aren't invoking each other or provoking an unexpected sort of command. Maybe it's associated with non-lighting cbus commands? Are all your cbus devices entered into the M1g? If so, how have you entered the cbus sensors?

I hope you can find it: the concept of cbus reproducibly killing the security system is not compatible with use of the M1g as a security system interfaced to cbus.

 

After disappointingly not hearing any news from Ness in a very long time, I've continued my research and have some positive results.

I've pretty much locked this down to a sync problem on the Rs-485 data bus. I've managed to trick it into stabilizing, whether its permanent or until the next reset I don't know and right now I'm not willing to experiment further.

Basically what I confirmed is that by writing a simple program (or using the cbus diagnostic toolkit) I could take the M1 offline by flooding it with varying group address on/off commands. I think Ness addressed the problem for a single group address being toggled but not for different group addresses.

The problem actually manifests itself as instability in using the keypads. If a tiny bit of traffic occurs on the cbus network while using the keypad, then you get various problems such as keypad menu's dropping back to home while in use, or authorisation prompts on non-secured menus, plus the keypad responds as if it is has two broken legs. So its not as simple as a "delay" in responding, it actually impacts the operation quiet severely. Basically I can cripple my M1 no problems if I can get access to a cbus cat 5 cable anywhere in or around the building.

Now, I experimented a fair bit trying to see why this is not reproduced every single time (by Ness), and what I found is that by manipulating (toggling) the port speed settings directly through the keypad resulted in a "stabilization" of the issue.

As we tested "replacement" parts for basically every part in the system, I believe the problem may exist in the way the RP software controls global values in the M1. In theory there should be no difference to changing these values on the keypad rather than on Ness RP, but it appears there is.
I'm not familiar with precisely how these values are controlled (i.e. IC with fixed speeds, or adjustable circuit) as Ness won't typically provide these specs, but I would imagine if the clock is digitally controlled a precision error in the Ness software might be a possibility.

Still no solution to the V3 missing CBUS commands, I'm convinced the design of this board is flawed as too many people are still not seeing stable operation (yes better than the V1 and V2, but I can get flawless operation of cbus components made by Clipsal, why not the V3 board maybe by Ness?)

Anyway, crossing fingers this little trick holds, anyone need more details just let me know.

I still wait in hope that Ness address the missed commands issue sometime soon. I hate not being able to trust if the M1 will turn off equipment after it activates them.

 

What I have ended up doing to get around the unreliability of the M1 C-bus interface is to program the C-bus interface to use a different lighting application. Then I just write logic in a C-touch (or whatever) to perform the appropriate action, or alternatively the TrackGroup2 procedure to map it back to the normal lighting application. This way the M1 only has to process commands destined for it (which are usually simple on/off commands) and will ignore all standard lighting commands. I also keep the rules in the M1 very simple and do all the processing in a C-bus logic engine. So far (touch wood) it's working very reliably.

 

M1

What has been described above is very similar to what I have been experiencing myself. I have just this week installed 2 M1 interfaces to existing jobs. On 1 in particular I have found that some groups on CBus, which have operated perfectly for the last 2 years, will now ramp to 100% then to 0% then to the scene. This has just happened when the M1 interface was installed
I had never really thought about creating a separate lighting application for M1, that sounds like a simple fix. I will give that a go.

 

interested in progress

Hi Ray
Just wondering how you went with your issues.

I'm reasonably confident isolating the M1 to a different lighting application would not actually solve the issues I've seen, however it would likely reduce the issues. Reprogramming would be major effort so would only do it if I could be certain it would work.

The M1 board, even the latest V4 board is still not 100% compatible with CBUS. I'm pretty certain of this because I've seen failures occur even when the only command to hit the CBUS network is the one that fails, so basically the V4 board is doing nothing but processing a single command.

P.S. The fix I mentioned to stop the M1 from being unstable is permanent, I am reasonably sure an earlier version of the Ness RP software must of introduce a bug causing the M1 main port speed to be out-of-sync somehow. Ness had very little to say regarding this.

By programming directly from the keypads overrode the faulty Ness RP programming. Too bad it does not fix the remaining sync issues with the system. I'm using CBUS AUX relays these days for input over using the M1 CBUS interface to avoid the whole drama.

 

I had a Ness M1 Gold installed a few weeks ago to replace a Minder system.
So far it has been working without any problems at all.

C-Bus commands work without issue here.

I have been using an all off command for years on my PACA, even with the Minder the All off caused some issues.

I ened up programming the PACA to do the All off in groups with various scenes and a time delay between each scene and with a max of 8-10 units being turned off with each scene.

I found that it was the PACA that could not handle the All off.
The PACA could not handle more that approx 10 units being turned off at once, so it had to be broken up into groups.

Have you tried that?

 

It was many years ago.

I initialy had the All off turn of each individual light one after the other.
That is, when I press the button which triggers the All off, PAC would send an Off to each light group.
I tested it on the PC quite a few times without problem, but then when it was loaded into the PAC and run from there, it always had problems, really annoyed me.
It was then that I started to use a few scenes with about 10 lights in each, plus some individual lights after a set delay.

Since then, no problems.