Pulse commands intermittently fail to turn off

I would be most grateful for ideas on what is the cause of some very odd (but intermittent and therefore tricky to diagnose) behaviour that I have noticed in my Cbus setup.

The system was installed in about 2010 and has performed flawlessly until recently.

I have a mix of 19 units wired in a star configuration including a B&W CTouch unit that mainly does scheduling of hot water, blinds, underfloor heating and some logic that handles towel rail, extractor fans etc.

The programming and logic of the CTouch have not been altered since 2019. I have made no other changes to the network in many years.

Over the last 6 months or so I have noticed that groups that are controlled by pulse commands occasionally fail to turn off. This seems to happen most often with groups that are pulsed on for longest. The pulse commands are all issued by the B&W CTouch unit and all control groups that reference channels in a 12 channel DIN Rail-mounted relay unit. I have not noticed any problems with groups and channels in this relay unit that are controlled by other input units. Schedules that issue "On/Off" commands (rather then relying on a "pulse for X hours") are similarly fine.

Initially I suspected the CTouch unit and, as I had a spare with identical programming, swapped them over. The problem persists.

I have attached some screen shots from the diagnostic utility. All units ping and pass a reliability test. The only exception is a one channel relay that isn't reporting its voltage or firmware version (but this seems unrelated to the problem). The traffic analyser shows occasional errors when scenes are triggered from the DLTs.

Today I noticed that only 2 units had their CBUS clock enabled and as the recommendation seems to be 3, I enabled the clock in a third. I will see if this makes a difference.

Power supply issues seem to crop up frequently in ageing systems and my initial suspicions were with these. The network is powered by the integral supplies in 2 Din-mounted dimmer units. However the unit voltages are all over 26 volts. I can persuade myself that the green "Unit" LED on the front of one of the power supply containing dimmers is less bright than its counterpart. I was on the point of replacing these units but without expert advice or more evidence of PSU problems it seems an expensive long-shot.

Whilst I can sort out some workarounds to avoid the use of pulse commands or catch their failures. I am wondering if this is an early symptom of something else.

Has anyone seen this before and any clues about what is going on?

This forum has been a fantastic resource in the past and I look forward to your advice.

Phil

 

The general advice of years gone by in training sessions was that pulse commands longer than 2 hours was not advised. and to set seperate schedules to turn things off for better reliability.
From what you mention your system is functioning well, the single channel relay would be firmware version 1 and won't show it's voltage or serial number.
Three clocks enabled is what's advised to allow for backup, but only one of these clocks is active, hence I don't expect that to be the problem.
The error that you see when a data issues a scene is also typical when traffic is high.
It highlights that there is a comms error at that point in time. You could try altering you burden from software enabled one to a physical one, or even moving its location. But I doubt it would make much difference
Check your terminations are clean and tight on C-Bus wouldn't hurt.
To reiterate your system looks to be OK and reprogramming the schedules would be my advice.

 

Also, don't forget that pulse commands are cancelled if the associate group address is set by any unit whille the pulse is active, even if it sets it to the same value. This is why long pulse commands are discouraged. If say you use the pulse command to turn a light on for 5 hours and sunset and somone comes along and turns the light off for a short whole the back on again, then off pulse will not occur.

Try running the diagnostic utility for a few days and filter the approproate group addresses. You will see if the pulse is cancelled early or is ecexuted at all.

 

Thanks very much to both of you for such detailed replies.

Wonky- Most reassuring that the network seems healthy. The burden is a software one on one of the DIN rail units at the centre of things.

Ashley- Thanks, I had forgotten that, but I am pretty sure that nothing else is setting the group addresses (and it has only happened in the last 6 months). Nevertheless I will see if I can catch it with the diagnostic utility. It's only happening once a week at most. I use the CTouch as the network interface aswell as needing to use the screen when I am at home so this has got in the way of me doing this up to now.

 

Thanks Nick

After Ashley's suggestion that it might be other units or commands cancelling the pulse, I reviewed the code and, for at least 2 affected groups, there were no other input units or code modules controlling that group.

In the meantime I amended the code to use schedule-On; schedule-Off in place of one schedule calling a pulse.

So your suggestion that is the status correction mechanism cancelling the pulse timer makes the best sense.

I will get the "log all messages" file over to you when I can.

I have attached images of the indicators on the 2 DIN rail units that have the power supplies that power the system. Both are L5504D2A. It seems to me that one LED is dimmer that the other. I'm unsure if this is a red-herring/significant/within normal variation.

Thanks for the support

Phil