Horstmann ASR-ZW a.k.a. Secure SSR303 Z-Wave Configuration

Horstmann ASR-ZW a.k.a. Secure SSR303 Z-Wave Configuration

I have the Horstmann ASR-ZW / Secure SSR303 thermostat relay switch installed with my boiler.

I purchased it from Vesternet here.

Other components of my setup:

  • Raspberry Pi 3
  • Running HA All-in-One (up-to-date)
  • Aeon Z-Stick Gen5
  • Several Fibaro Relay Switches (working perfectly)
  • Fibaro Sensor (working perfectly)

The manual for the ASR-ZW can be found here.

I have been using open zwave control panel (ozwcp) to set up my devices.

The open-zwave config file for the ASR-ZW is here.

My problem is that I have never been able to have get the ASR-ZW to work correctly. I have tried adding it with the ozwcp, both adding it as a standard device and as a secure device (with the key). In both cases the device is added but after several seconds is considered by ozwcp to be a dead node.

Healing the network does not seem to fix the issue. The only thing I have found online is related to the Vera Z-wave system this post which states:

“The ASR-ZW does not have Instant Status reporting so, when its state is changed by direct Z-Wave association or the manual buttons, Vera will not know until the next poll.”

I also have the suspicion that the device may be falling into the failsafe overide mode permentanlty, maybe because of a lack of a connection? The manual (linked above) states:

"In the unlikely event of a communication failure it is possible to override the system and switch On and Off using the On/Off buttons on the SSR303 receiver as a local override.

If the override is used to override the system when it is functioning correctly then the override will be cancelled by the next switching operation and normal operation will be resumed. In any case, with no further intervention, normal operation will be restored within one hour of the override being operated."

More from Vesternet on the failsafe mode of the Secure recievers can be found here.

Interestingly though, I am sometimes able to exclude the ‘dead’ node from the network by specifying the remove node action and pressing the network button on the ASR-ZW.

Other than the fact that I cannot get it working with Z-wave, as manual on/off switch, it works great!

Hopefully I can figure something out and post a step-by-step guide so any advice would be much appreciated.

I will also post this on the Vesternet site.

1 Like

I don’t have any useful information for you I’m afraid, but I’d be really interested in whether you’re able to solve this…

I’m planning to buy the SSR302, which I think is pretty similar to the SSR303 but is dual channel (so I can control my hot water as well as central heating) - I imagine the SSR302 may have similar problems to the ones you’re seeing.

Off-topic for this problem, but are you planning to use a smart thermostat with your system? I’m debating between getting one of the corresponding Horstmann/Secure z-wave thermostats so that I can associate it directly with the boiler relay, or just using the existing non-zwave temp/humidity sensors I have on the network and putting the control logic in Home Assistant…

Thanks for the reply.

I have set up the generic thermostat device in HA which (I guess you know) is a virtual thermostat where you choose the the sensors and switch individually from existing devices.

I would prefer to do this so that at different times of the day/year, I can choose which rooms I care about and ultimately so I can set it up with some radiator valves. But that is down the line.

The thermostat implemented in HA seems really nice and appears to do exactly what I need. Plus I already have a few Fibaro sensors which appear more than accurate enough for my use case.

I now have a few more ideas no about how to fix my current problem though as it appears that you must repeatedly (every 30 min) send on signals to the device. I’m not 100% sure how to do this best in HA but will try by have the automation trigger be repeated every 5 min. However, I am not sure if this will force an on signal if HA knows the switch is already set to on.

Will keep you updated anyway.

For anyone else who comes across this, I just noticed that last month an addition was made to the generic thermostat component.

A new option called keep_alive was added which allows a period time to be specified at which HA sends packets to the device to keep it alive. This should work nicely to overcome the failsafe issue.

See here

The example show it nicely:

climate:
  - platform: generic_thermostat
    name: Study
    heater: switch.study_heater
    target_sensor: sensor.study_temperature
    min_temp: 15
    max_temp: 21
    target_temp: 17
    keep_alive:
        minutes: 3

I’m currently testing it with the SSR303 and working great so far. Will post more if I have any other issues.

Thanks to the developers for adding this feature and to @aronsky for suggesting the feature.

Cheers!

I developed it for my A/C, and thought that others might enjoy this functionality - I’m glad it’s useful!

1 Like

I’m in the uncommon situation of having both a dual-channel oil boiler and a newer combi oil boiler so I have both the SSR303 and the SSR302.

The SSR303 (single-channel) is a chronic pain.

Initial inclusion into the zwave network had to be accomplished without its sibling [SCS317 Thermostat controller] (http://www.vesternet.com/z-wave-secure-7-day-programmable-room-thermostat) - which I then added later.

When restarting the zwave network it appears I have to trigger a NIF (manually, from the outdoor boiler enclosure…).
It’s possible the SSR303 is falling into failsafe mode (the SCS317 should be preventing this) and this state persists across ZWave network restarts.

Despite being mains powered it still has to be polled for state changes (those which are not triggered by HA, that is).

The SSR302 has been faultless and being quite centrally located probably carries the majority of routed messages in the network. I have an automation resending commands every 20 mins - though I’ll definitely look in to keep_alive. I’m fairly certain though that HA will happily repeat a command even if the state of the device (from HA’s PoV) would not be changing.