[RELEASE] Remotec ZRC-90 Scene Master - Button Device Supporting 24 Unique Button Commands (see post 177 for 2021 app version)

Thanks again. My Ikea remotes are working now - I think that problem was just a coincidence. I haven’t had a chance to progress your recommendation because I don’t live all the time in the place that has Smartthings.

Have had a Zrc90 for sometime programmed via Smartlighting. The first 6 buttons toggle different lights. The problem I have is that mostly when I use it after a little while it will ignore the first press, 2nd press will toggle on then 3rd will toggle off. After this all buttons will operate as programmed. Does the zrc90 go to sleep and need a press to awaken it?

Yes, this is true of most battery operated zwave and zigbee devices.

Most mains powered devices do not have this issue. If it’s an essential use case rather than just a convenience and you are in North America, you could try the following. It fits a regular single gang box and supports up to 5 taps on each of the small buttons plus long hold. So not as intuitive as the remotec, but probably more reliable if you don’t use it every day.

Supports 1-tap, 2-tap, 3-tap, 4-tap, 5-tap, button held

It’s been very popular. Due back in stock this week.

1 Like

No, these battery devices don’t “go to sleep and need a button press to wake up”, they would be pointless if they did, I’ve had these for years and each responds normally to a click as it should.

My experience with this device says otherwise. Leave it sit on the bedside table more than 12 hrs. and need an extra press to wake it up before it sends something.

“60% of the time - it works every time…” - Champ Bucks

1 Like

I definitely find that the issue where they need an extra press to wake them. Not sure of the timespan but generally after hours it goes to sleep.

Sorry you’re not having the expected behaviour with this device, I know that would be unbearable for me, if a device didn’t respond as it should 100% of the time I would either find the cause or throw it out after a week. I bought my first one after reading @erocm1231 comments about it’s reliability and good engineering, using his dth it’s never missed a beat, one is next to a bed and sometimes goes 48hrs without a button press, works first time every time. Think about it logically, how could a device make it to manufacture if they had to have a sticker on the box that said “by the way, sometimes this device goes to sleep so you may need to press a button to wake it up, then press it again to send a command”, just wouldn’t happen. Tech reviewers would crush sales after day 1.

It just depends on the competition and the buyer’s expectations. There are quite a few inexpensive battery operated devices that have exactly this issue and yet continue to remain on the market. They compete on price, not reliability.

This particular device does have a section in the user manual which discusses the fact that it might go to sleep from time to time. In fact, the device has a W button specifically to wake it up if it has gone to sleep.

Communication to a Sleeping device (Wakeup)


This device is battery operated and turned into deep sleep state most of the time to save battery life time. Communication with the device is limited. In order to communicate with the device, a static controller C is needed in the network. This controller will maintain a mailbox for the battery operated devices and store commands that can not be received during deep sleep state. Without such a controller, communication may become impossible and/or the battery life time is significantly decreased.
This device will wakeup regularly and announce the wakeup state by sending out a so called Wakeup Notification. The controller can then empty the mailbox. Therefore, the device needs to be configured with the desired wakeup interval and the node ID of the controller. If the device was included by a static controller this controller will usually perform all necessary configurations. The wakeup interval is a tradeoff between maximal battery life time and the desired responses of the device. To wakeup the device please perform the following action: Enter to the Listening mode (Wake up) by click once on “W” button.


And here a comment from the Domotics board:

have the ZRC-90 working with blocky for all buttons, 1 to 8 are each activating its own scene.
It works as long as the remote does not go into sleep mode.
After half a day or so I have to open the battery lid and press the button W to have it activated again.

That said, it appears that there is a related issue with this specific model and it depends on the individual network configuration which is why some people see it and some people don’t.

This device can act as a primary controller or as a portable scene controller, which is how it will be used with SmartThings. But it has some built in timeout features and it’s pretty sensitive to latency. In addition, multiple people on multiple home automation boards, including Homeseer, vera, Domotics, and Zwave. me have reported that it tends to choke if there’s a zwave network has more than about 75 nodes. But that may be related to that timeout issue, because there are some people who do have more nodes who do get it to work without going to sleep.

Anyway, the main point is that because this device thinks it might be the primary controller even when it isn’t, if it doesn’t get a message through quite quickly it tends to throw away the command instead of resending it. This is what makes it look like it’s asleep. :sleeping:

Here’s one typical comment from the Homeseer community:

Where they fail:
Because they cannot be configured to have any neighbour node (because they’re a controller I presume) IF they cannot reach their associated controller the LED flashes 4-5 times to signal no handshake and then they go back to sleep, the command doesn’t get received and the controller won’t do anything. This I’ve analysed is due to range and most of the time, pushing the button again manages to get the command through to the controller and things are good…but still far from ideal.
If you think about it it makes sense - a device on the edge of a transmission range, or a busy network will get sporadic send/receive success but by moving them to a separate z wave network reduces contention on the network and their probability for a command to get through . If these devices where able to be configured with a neighbour node (they are Z- wave plus after all right) then this issue would go away because of the store/forward/mesh network.
So in summary, they work IF the network isn’t busy or they’re close to the master controller.

All of which is to say…

Whether or not it’s likely to go to sleep and need an additional button push will depend on where it is located relative to your hub, how many Z wave devices you have, how long it’s been since you last pushed a button, and how much traffic there is on your network. Plus the usual smartthings cloud latency issues. And it’s the combination of all of those together which can cause the device to go into sleep mode. :thinking:

If it is going to sleep a lot and you have fewer than 60 Z wave devices on your network, I would try temporarily moving it close to the hub And leaving it there for a week or so and see if that solves the issue of its going to sleep.

If it does, I would guess that the issue is network traffic. You can start trying to troubleshoot that, but it’s going to be pretty tedious to do so. so it may be that this device just isn’t a good match for the specific environment it’s in.

But all of this together would explain why it seems to work great for a lot of people and have this issue for others.

1 Like

Thanks for that explanation JDRoberts.
In my case my ZRC90 is the only Zwave device t 2tcurrently active on my network. Also it is located about 4 mtrs directly in front of ST hub.
In Australia there are very few multi button devices so this one is attractive (about 2/3 cost of others).
I will try and set up another zrc90 (that I have stashed away) and see how it behaves - given we appear to have variable results).
Will also check the dth and see if mine is out of date. It is a little intriguing that a simple second press does the job rather than needing to resort to the W button.

1 Like

For most sleepy devices, any button press would work. In this case, I think the W button is there specifically because of the controller functions that this device has, but you wouldn’t be using those in a smartthings set up anyway.

That said, in your setup it doesn’t sound like network traffic would be an issue. How’s the cloud latency?

Not sure how to measure cloud latency.

If you mean wifi connected devices, my ST to Tplink operations takes about 4-5 second.

Well, I set up a second zrc90 to see if it had the same “sleep” problem. Initially it did ! However, over recent days Both now seem to work correctly - first button press!
Magic does happen!?!?

1 Like

Glad you got it sorted. This theory that these devices “go to sleep and need a button press to wake up first” is truly the funniest thing I’ve heard in a long time. So illogical and from an engineering point of view doesn’t even make sense. I have one of these that I haven’t used since the Chromecast Google TV was released last year, pressed it once, and my music muted immediately, that’s over 6 months sitting idle!

The manufacturer mentions the issue in the user manual for the device, and even provides a “W“ (for “wake up“) button on the device itself.

It may seem odd from an engineering standpoint, but it’s how they chose to do it in order to extend battery life. There is a parameter you can change if you want to keep it from going to sleep as often, but then the batteries won’t last as long.


This has confirmed you have no idea what you’re talking about. I may consider contacting the manufacturer to tell them there is a non user of their product deliberating spreading disinformation about their product. So please don’t delete your comments.

Wow! That’s an interesting reaction.

It looks like you’re right, there isn’t a changeable parameter, and I won’t change my post. I certainly wasn’t “deliberately spreading disinformation,” i’m sorry you felt that way. I did link to the manual, and there is a W button.

However, I find these kinds of conversations very stressful and very confusing. So I’m just going to leave the forum now. No ill feelings, if you want to limit the conversations to people who are currently using the devices, that’s fine.

I find that reaction odd as well. Anyone who’s been on this forum for any amount of time knows that @JDRoberts has a great deal of an idea what he is talking about. In fact, a lot of what’ I’ve learned over the years are from his posts.

Anyway, for this device, I may not have it personally, but having written the updated devices handler, and having similar battery powered Zwave devices that have almost identical specifications, I think I can speak a lot to what is happening here and try and actually offer some helpful advice to get this thread back on track.

The wakeup interval is hard coded into the device handler. It’s currently 24 hours based on these lines of code.

def zwaveEvent(physicalgraph.zwave.commands.wakeupv1.WakeUpNotification cmd) {
	def results = createEvent(descriptionText: "$device.displayName woke up", isStateChange: false)
    def cmds = []
	if (!state.lastbat || now() - state.lastbat > 24*60*60*1000) {
        logging("Battery report not received in over 24Hrs. Requesting battery level.")
        cmds << zwave.batteryV1.batteryGet().format()
        cmds << "delay 3000"
	cmds << zwave.wakeUpV1.wakeUpNoMoreInformation().format()
	return [results, response(cmds)]

Zwavejs2mqtt which I use now, allows you to set this wakeup interval for any battery powered zwave device. Smartthings leaves advanced configuration settings locked down and up to the coding in the Groovy device handler. I could add code to change that to this handler, but honestly I don’t use Smartthings anymore and I’m not sure if I’m going to release any new updates on this. @Alwas , since you seem to know so much about the device, I’d be happy for you to contribute a PR on my github to update the code.

Why does wakeup interval and sleepy battery powered zwave devices matter? Battery powered zwave devices go in a deep sleep to save power. However, life in the zwave network goes on. Devices go on and offline. Battery powered remotes get moved around. All zwave devices mesh, and to do that, they store the Node id’s of their neighbors. Mains powered devices are always on and updating this, with constant communication to the hub. Battery powered devices don’t. When they wake up, with say a button press, they use the same configuration they had when they went to sleep.

How does this potentially cause trouble and the first press to not get recognized? Seeing an example with a battery powered device on my network might help. Here is the network map of the relevant battery powered device, a GoControl remote, in ZwaveJS2Mqtt. Again, Smartthings does not have these advanced Zwave features to really dig into what is going on, but this should help explain:

You can see my go control battery powered device needs two hops to get to the controller. It is on the other end of the house, and commands would have to route between one of 3 devices closer to the hub in the map to get through. You can also see the Node ID’s of the neighbors ,which is stored in the configuration of the remote. Notice Node 1 - the hub, is not in that list.

Now imagine one of two scenarios - Scenario 1 is my kitchen light or one of the three devices it tries to communicate through is off line. Imagine going to sleep, you wake up and need to drive to work, but the road you usually take is closed and you slept through the traffic report. You’d have a hard time getting through and might get lost right?

Another scenario - since this is a remote, I move it to another part of the house. Imagine waking up somewhere you didn’t go to sleep. You probably would be confused. Even if I moved this remote next to the hub, its first press might not go through because its trying to communicate with what it thinks are its “neighbors” when in fact they are now on the other end of the house.

Another thing that happens here is when the button is pressed, it blurts out its message on the Zwave network based on its config, and doesn’t ask for any confirmation from the hub the message actually went through. This is very different from a Zwave Lock, which will actually ask the hub “did you get the message?”, and if the hub says no or it doesn’t get a response, it tries again. All that happens fast and you likely won’t notice.

These are only some of the possible failure points. Add in cloud latency and other connection issues, mix of devices, intermittent outages, signal interference, etc and the problem compounds. Once you start seeing all the ways this can go wrong, it is no surprise now that sometimes the first button press on a battery powered device does not go through. You might wonder why the second press goes through then. Once the device “wakes up” with the first press, it then gets the updated configuration report of the network from the hub by the hub recognizing it is awake, which involves some back and forth communication. The device will now know how to properly route a new message, and then the second message will almost always go through.

So, what can we do to help eliminate problems like the ones @Geoffs is facing? It clearly is a problem because he is posting about it. I’ve experienced it too. Just because a user hasn’t experienced the problem doesn’t mean others haven’t. It could work fine in one setup and always get messages through, but have problems in another.

So, steps I would take to improve stability:

1- Go around you house and place all zwave remotes where they will be used the most. Most Zwave manuals will tell you to “pair the device in place”. This is because it will get the relevant neighbors based on where it is.

2- After they are in place, wake them up by pressing any button. This way they will be awake to receive a new configuration.

3- Run a Zwave network repair. Critically with ALL battery powered zwave devices on/awake and in place where they will be used. This should update all routes and improve stability, so hopefully their message gets through on the first press.

I just have to add, telling anyone on a forum they “have no idea what they’re talking about” is incredibly rude. Saying you’re going to contact the manufacturer on them and telling them not to delete comments is border line threatening, and threats violate the communities guidelines and terms of service. I would hope we can avoid a similar escalation in the future.

I hope that this post can provide some help and please feel free to chime in or ask any other questions.

1 Like

@JDRoberts, you have always been a huge asset to the SmartThings community. You have helped countless people with your thoughtful, informed, professional, and kind comments. I’m sorry if it seems some people don’t appreciate that and come across as rude, but I appreciate you and everything you have done. :slight_smile:


As a relative newby I certainly appreciate the help above. @JDRoberts and @mwav3

Am still a little confused. The original zrc90 was the only acive zwave device and permanently say 4mtrs across the lounge from the ST hub and Always needed a second press if left idle for long. However as soon as I added a second zrc90 (sitting near the first) neither has needed that second press.
I am left wondering whether this was a consequence of adding the second device in some way, or possibly forced a dth update ?

A lot of things could have caused that but I don’t know for sure. Could be an unpublished device handler, code change not applied, bad data in the zwave table, all of which might have been fixed when the new devices was added and everything got refreshed. Also could be this device can function as a primary controller, and with only two devices that created a conflict on which one (the remotec or Smartthings) is primary. Adding the second device to Smartthings would clearly show the first remotec “who’s in charge”.

The important thing is its working more reliably for you now. If it happens again, I would still recommend the zwave repair steps outlined in my post above.