SHAC locking up regularly

Hi all - I have an issue with a SHAC I installed for a client. It's locking up regularly (maybe five times a day) and the client has to power cycle it to get it going. When it happens, it stops running its script, but nothing responds (timeout to web interface, and from memory it doesn't even respond to pings). I vaguely remember the client saying the status light (or maybe power light) goes red, though I can't be sure of this.

It's about a year old and running 1.6 firmware.

There's not a lot going on with the unit. There is only one script, and for now it's been kept simple, i've tried it as a resident with 60sec sleep, and have also tried it as scheduled, running every five minutes. Unit still crashes.

The client has about ten floor temp probes, each connected to a separate DTSI. The script checks the temperature and turns a GA on or off, in turn turning relays to floor elements on or off.

The script looks like this, just multiplied ten times with varying names.

if GetCBusMeasurement('SiteName', 'UFH-Kitchen-Dining', 1) > 22.5 then
SetLightingState('UFH-Kitchen-Dining', false)
end

if GetCBusMeasurement('SiteName', 'UFH-Kitchen-Dining', 1) < 21.5 then
SetLightingState('UFH-Kitchen-Dining', true)
end

I called support today and was told to try a factory reset, then re-upload the 1.6 firmware, then setup script again. I tried this but it hasn't made any difference. I was also told the new version would be available soon and it has more memory so if i do a warranty replacement, but delay doing it, i might get that instead. However I don't think it's a memory issue, and I want to wrap the issue up for the client as quick as possible.

So before I do a warranty claim, any ideas?

 

A couple of thoughts,
try adding a check before setlightingstate as the command currently as code above doesn't care what state the GA is in and will write the true/false command each time even if not required, also if you connect to toolkit and watch the application log at the time the script executes this might give you some insight as to what the SHAC is doing as far as sending to the cbus network.
At this stage im assuming the SHAC will send the SetLightingState('UFH-Kitchen-Dining', false) or ture depending on the DTSI temp, a number of times while the script is running and as there is 10 of them, its seems plausible this could create massive traffic which could be the reason for the device "locking up"

-- add check before SetLightignState
if GetCBusMeasurement('SiteName', 'UFH-Kitchen-Dining', 1) > 22.5 then
if GetLightingState('UFH-Kitchen-Dining') then -- Ga is on then switch off
SetLightingState('UFH-Kitchen-Dining', false)
end
end

Are these DTSI added into the objects for the measurement application, if so do an event script on each DTSI temp object eg, this script would run when DTSI temp changes instead of every 60 sec. down side is you will need to make 10 of them...

--event script for DTSI Temp object
temp = event.getvalue()

if temp > 22.5 then
if GetLightingState('UFH-Kitchen-Dining') then -- Ga is on then switch off
SetLightingState('UFH-Kitchen-Dining', false)
end
end

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

 

Awesome thank you - certainly seems more stable changing to event based and giving it less work to do. It hasn't locked up yet. I figured the quick few lines of code would do to get the client up and running quickly but didn't consider the workload. Cheers!