Roller shades have multi-second popcorn effect in Hubitat, but the remote works perfectly

🛎️ Get Help
1

Hey all!

I am having very bad latency with my Z-Wave roller shades. The brand is Bali, manufactured by Springs Window Fashions. They also manufacture Graber shades. I suspect my problem can be solved by a custom driver, and that suggests to me that other people are probably experiencing the same things. I can potentially author or help author the driver, but it would be my first time doing so. I'm a software engineer, but new to home automation.

What is happening

I have three roller shades (really more, but we will use three for this example) registered as generic Z-Wave shades. I have created a simple rule that closes the shades at a certain time. The only condition is "When time is..." and the only action is "Close shades 1, 2, and 3".

When I wait until the specified time or press "run actions", all three shades close. However, it can take up to ~5 seconds for the first shade to start closing. The other two follow, each delayed by 2-5 seconds. That is incredibly slow, and not particularly aesthetic.

More info

Here's where it gets interesting: the shades also came with a remote. After pairing the shades with Hubitat, I also paired the remote with Hubitat and then "associated" the shades with the remote. The remote allows me to then assign shades to "channels", which are basically scenes in the remote. When I assign all three shades to a channel and then try to open/close them with the remote, they respond instantly and simultaneously. They close at the exact same time, perfectly aligned. Zero perceptible latency.

When I look at the logs after running a remote command, I see the following:

Z-Wave command:CentralSceneNotification(keyAttributes:0, sceneNumber:13, sequenceNumber:20, slowRefresh:true)

In the above string, sequenceNumber increases each time I press the button the remote. sceneNumber varies based on the channel, but in this example, I am using channel #1. I do not know if the remote's "scenes" always begin on 13 or if that increments for some other reason. I'm guessing the latter.

My understanding/guess is that Z-Wave has some sort of built-in scene management functionality that allows for multiple actions to occur simultaneously. I suspect that the remote is taking advantage of that functionality, but Hubitat is not. This is probably because the generic Z-Wave shade driver does not know about it. I do not know whether that functionality is specific to the remote, or rather the combination of the shades+remote.

In the past, before purchasing Hubitat, the company provided me with an Ezlo Atom and some cheap app for basic routines. It was terrible in every way, but it also had zero latency. This was also the case when I did not have a remote, which rules out the remote being magic. If an Ezlo Atom can do it, I am confident that it is possible to make Hubitat have the same non-delayed behavior. I also know that the logged command is part of the Z-Wave specification, but my insight ends here.

Does anyone have any additional insights? I appreciate your help.

FAQ

  • My hub is connected via Ethernet.
  • The shades are approximately 10 feet away from the hub.
  • The shades are not blocked by a wall.
  • I have rebooted and power-cycled the hub.
  • I have tried using groups.
  • I have tried using scenes.
  • I have tried using "Room Lighting".
  • I only have ~15 Z-Wave devices connected.
  • I have no ghost devices.
  • I have run a Z-Wave repair.
2

Tagging @bcopeland @mike.maxwell

1 Like
3

I believe the delay you are seeing is that the command(s) must first go to the hub then the hub generates the proper commands and send them out the shades. The hand held remote communicates directly to the shades so latency is greatly reduced.

If your shades support Z-Wave associations, you should be able to use that to speed things up.

4

Wouldn't the hub be directly communicating with the shades, though? The time between manually triggering the actions to the shades' response could conceivably be delayed, but that wouldn't explain the staggered effect.

5

I don't have intimate knowledge of how the Hubitat sends commands, but I would think any group of device commands are sent one at a time rather than simultaneously.

6

They are sent 1 at a time.

There is always 'popcorning' with zwave when multiple devices are driven by a hub - any hub.

Direct associations, where supported, can help with that. But that requires some user setup/know-how.

7

Considering there was no popcorn effect when using an Ezlo Atom (a very cheap Z-Wave hub, but with the blinds' mobile app), and Hubitat is the only variable that has changed, Hubitat must be doing something that the previous hub/app was not.

I think the command that the remote is sending out is a very good hint. It's clearly interracting with an entire "scene" with only one Z-Wave command. I'm just wondering A) where the "scene" came from/how it is defined, and B) how I can make Hubitat replicate that same behavior (again, probably with a proper driver).

8

Maybe so.

That said, there are only a few ways it could be doing it in the zwave spec. And not all of the ways are supported in every device or hub, so it is a research exercise every time someone goes into this area.

Looking at the remote devices on the zwave alliance webpage, if I had to GUESS I would expect the remote is using associations (Group 2) to command them all at once. You can do the same thing in Hubitat, but it is a pain to setup and you still need an end zwave device to issue the association commands (a switch, button, other). I don't know of any way to generate association messages from the hub itself - they are intended and designed to be issued from a zwave device to other zwave devices.

image
image3814×427 90.6 KB

Good luck!

2 Likes
9

Did you figure this out? I have the same issue, and while I understand that we may not get exact synchronization, like you, I'm seeing multi second (like usually 5-10 second) delay from when I press a button, or issue a command directly from the hub to the shade.
I get that it has to tell one shade, then the other, but even the first shade takes 5 or more seconds to start moving (usually), and the second is often several to many seconds behind that.

10

Hey Gabe,

I got it working by not using Hubitat. At least, not for the blinds.

Assuming you have the same blinds (I have Bali, but I assume their other brands are the same), they probably gave you a hub for controlling them with your phone. It's a pretty terrible hub, and it's a pretty terrible app, and getting it all paired is a nightmare. However, if you survive that, then the blinds open and close correctly.

Someone (not me) reverse-engineered their web-based API. It's also a nightmare (for some reason, it's both an HTTP API and a socket-based API). However, if you have experience coding, you can take advantage of that here. If you do that, you can control your blinds programmatically.

I ported the code to PHP (Here is an exerpt of my code; you'll notice I'm using a couple third-party libraries as well. Good luck!) and then hosted it on my personal website. You can then ping the script using either Hubitat or a cron job (or whatever else).

As long as you're able to do some coding to port either the bash code or my PHP code into an environment you're familiar with, you can work around the issue. But no, I could not get it to work with pure Hubitat.