Intermittent network issue - GAs not switching

Hi all - I have a network that consists of a 12-channel relay, a SHAC and a bunch of DTSIs. I've included a few screenshots for more detail on what the network consists of. Each DTSI triggers an event script (thanks to help from Pie Boy in a previous post).

Previously I had an issue where the SHAC would lock up (as referenced in the previous post) which at the time I thought was just code related. It does still lock up occasionally, but not as frequently as it had been, but still maybe a few times a week. The biggest issue I have is that when the SHAC turns a GA on or off, more often than not the relay channel doesn't change.

In the screenshots, you'll see days/times that it supposedly turned the relays on based on them being below setpoint (which has been at 23 throughout testing). From the SHAC point of view it all looks fine - I've confirmed with the client the relays showing as 'on' in the SHAC screenshot currently are not.

DTSIs are set to broadcast at 150 seconds and .5deg change. I've tried at 300seconds and with just the .5 change (no timed interval) but it didn't seem to make a difference.

Some points that i've already looked at for troubleshooting:

- The client has a Tesla solar/battery setup; I've asked their electrician to isolate it to ensure it's not causing issues (after I read there was a possibility of pseudo-sinewave issues with them). i figured it was a longshot, but low-hanging-fruit to eliminate. It doesn't seem to have made any difference.

- I didn't install the equipment - was just meant to be commissioning. In troubleshooting I've discovered the connections are not as per instructions (the second set of pairs have been 'doubled up' from the DTSIs back to the board). So blue, orange, green and brown are positive. All four of the white-trace wires are the negative. Each sensor is individually wired back to the board, where they have all been joined together. I've asked for this to be corrected. The link between the relay and the SHAC is a standard pre-made pink patch cable. i've made sure the 'greens and browns' where they're all connecting in at the board end are not linking into the relay or SHAC.

Thoughts? I know it's not as per spec ,but could the 'doubled-up' cable be causing the issue? If it's not that, any other ideas on that or why the SHAC is locking up?

Code example below from an event script - they're all the same (apart from the obvious tag changes). I put the 'turn off at 28deg' code in there as a secondary if it doesn't turn off - in reality it's redundant code if the system works, and is unlikely to work if it's not - just haven't removed it yet.

-------------------------------------------------------------------
local setpoint = GetUserParam(0, 'setpoint')
temp = event.getvalue()

if temp > setpoint then
if GetLightingState('UFH-UpstairsBathroom') then -- Ga is on then switch off
SetLightingState('UFH-UpstairsBathroom', false)
end
end

if temp < setpoint then
if not GetLightingState('UFH-UpstairsBathroom') then -- Ga is off then switch on
SetLightingState('UFH-UpstairsBathroom', true)
end
end

if temp > 28 then
if not GetLightingState('UFH-UpstairsBathroom') then
SetLightingState('UFH-UpstairsBathroom', false)
end
end

 

Firstly double check how the relay is programmed. Particularly the ga number (not name). Changes in Toolkit are not reflected in the SHAC and vice-versa unless you re-import them so they could be out of sync.

Then run the diagnostic utility and check the commands are being issued on the bus. Ideally you want to do this with a different interface to the SHAC since it's issuing the commands.

You can also toggle relays from the diagnostic utility which is a good test if you don't have any switches.

This is doubly redundant because it says if the relay is not on then turn it off.

Also, you should have a hysteresis in your comparisons as the temperature can bounce around the setpoint and continually trigger the relay. e.g. if temp < (setpoint - 0.3) then ...

 

Thanks Ashley

I have checked all the GA numbers match between SHAC and the relay. Based on your suggestion i'll go and put in a CNI so I can run diagnostic separately from the SHAC.

Re the hysteresis, I had this previously but removed it as I thought I wouldn't need it given i'm only running the code on event (each broadcast change), which are 2.5 mins / 0.5deg temp change, so it was unlikely to create a flood of attempts to trigger the relay. Would you still suggest adding it anyway?

Any thoughts on the cabling issue? Is doubling up pairs likely to cause any issues?

 

Since you have the sensors set for a 0.5deg change, that will give you sufficient hysterisis. (Should have read your post better )

Using all pairs is a bit odd, but won't cause any problems. On domestic installs I just cut the green and brown wires off as they are never used and just a source of potential problems. It wouldn't hurt to get it fixed to save future confusion though.

Not sure about the SHAC locking up. I've never experience that. When it locks up is the power led green, red, or flashing between them?

 

I believe it's the power LED goes solid red - though i've asked for confirmation from client.

Interestingly, after my previous post I put a script in to run every five minutes, which does this for each group address:

if GetLightingState(11) then
SetLightingState(11, true)
end
if not GetLightingState(11) then
SetLightingState(11, false)
end

So far, that seems to have brought everything into line. However I obviously shouldn't need to be doing that, so will keep working to get to the bottom of it by putting in a CNI and using diagnostic as you suggested above.

 

Hi
I have had problems with a Job in the ACT about 10 years ago where the electrican did the same with the cabeling thinking it would be good for voltage drop as there were long cable runs there were only about 50 cbus units per network (8 networks) however there were all sorts issues with comms some would not scan correctly with PC others would miss commande from PIRs and switches. After the electrican corrected wiring to cbus standard we needed to put remote power supplies in the field. We did the worst network first and it worked fine so then rectified all the other networks.

Good luck hope ths helps
Graham

 

Thanks Graham - sounds like the electrician had the same idea here.

We've put a Cbus power supply in the network at the start because the calcs suggested we would need it (as we had the 12-channel relay being the only unit with CBus power, then the SHAC and 12 DTSIs), so I've said he shouldn't need to worry about voltage drop with the extra supply and the fact it's only a relatively standard four bedroom house. I've asked them to rectify the cabling so it's as per spec so will post an update once we get some feedback.

 

Is there a Burden activated or external added ???

 

The relay has its burden enabled. Still having issues so waiting on the electrician to go and fix up the wiring and we'll drop a CNI in at the same time as Ashley suggested to see if that gives any further clues.

 

I've not tested this code, but here's an idea to simplify your script deployment. Changing your scripts won't address the odd lock-ups encountered, nor the interesting wiring, but...

I'm a big fan of utilising keywords for scripting @zylex. Consider this code:

Code:

local setpoint = GetUserParam(0, 'setpoint')
local temp = event.getvalue()
local targetGroup = GetCBusGroupTag(0,228,tonumber(string.split(event.dst, '/')[3]))

if temp > setpoint or temp > 28 then
  if GetLightingState(targetGroup) then -- Ga is on then switch off
    SetLightingState(targetGroup, false)
  end
end

if temp < setpoint then
  if not GetLightingState(targetGroup) then -- Ga is off then switch on
    SetLightingState(targetGroup, true)
  end
end

If this single script were an event-based script triggered on a keyword, and not each individual measurement channel with a similar script duplicated nine times then maintenance would be simpler and implementation less error prone. You have nine scripts to modify the name of the target GA, while the script above has none of this. It is exactly the same for all nine measurement devices.

Just add a keyword like "TEMP" to each of the measurement channels, and fire the event-based script on that same keyword. It looks like the name of your target GA is the same as the measurement app device ID, so the script above will grab the device ID and use it to reference the target GA.

Of course they might not all be consistently named, as you only gave one example. Or they might be and this simple approach will work.

For what it's worth, the only time I have ever seen a SHAC lock up is when I did bad things to it by using Mosquitto library call-backs in a non thread safe manner. Might this one have a dodgy micro SD card? Another thought, have you tried upgrading the firmware to the same level it's running? I had another NAC that had turned to custard yet was revived by "upgrading" 1.11.0 to the same release.

(Edit: I Just looked at your screen shots again. This script approach will work for all but the Toilet-Garage, which doesn't have the same naming convention. Re-creating the measurement device ID for that one would make it work.)

Cheers.