The v5.190.38 software release for the Z-Box Hub is currently available when logged in locally to the hub and the accompanying changelist can be viewed on the Z-Box Update tab of the hub web interface. (I’m currently away from home and am looking forward to some of the updates it promises when I return later this week. )
Other than some more UI changes, updated icons, and template updates for select Zooz devices–all very welcome–I thought the following changes look pretty interesting:
Performance improvements in scenes execution in large systems and
Scenes launch optimization.
We’ve seen discussion here recently about load times on the mobile app and occasional comments about intermittent delays executing some scenes, so it will be interesting to me to hear of peoples’ experience with the hub after loading this release.
Anyone have experience so far with this update you can share?
I’m over 100 devices and over 100 scenes, so far not really the big change I had hoped for. There are times where it does seem snappier, but other times where it still seems just as laggy.
I still have sensors that seem to get stuck open, or motion sensors that get stuck activated, occasionally. I also have scenes that will activate very delayed, both block scenes and LUA. It’s almost like the HUB gets busy doing something and just has to wait till it’s done processing whatever it is or something.
I don’t believe any performance issues for scenes are related to the hardware. A scene is simply a list (sometimes long list) of commands sent over the wire. The more devices in a scene, the more commands that have to be sent out. This overwhelms most z-wave networks, especially when devices must be routed through other devices, or the commands are not received, etc. That is why I asked for this feature: Feature Request - Add CC 43 (Scene Activation v1) and CC 44 (Scene Actuator Configuration v1) to all devices . With this, one radio command would be sent out, and each device that is part of that scene would have a preset level that it would go to. That is the purpose of CC 43 and CC 44. Zooz would just need to add support for these in device firmware. I have some GE/Enbrighten devices that support this.
Interesting proposal, @jut. Just today I loaded v5.190.38 on my hub, after returning home. Too early to say there’s any noticeable change here in scene execution.
Your suggestion for the sequence of commands sent “over the wire” caused me to wonder if there was any subtle improvement in a scene that controls multiple switches if those switches were controlled as a group–rather than two or more individual switches in a scene. To that end, I changed one of my configurations–a scene controller that turns on the basement lights and the basement stairway light together–to watch in the coming weeks. Occasionally, but not often, a substantial delay can occur (seconds, usually, although we’ve seen tens of seconds upon occasion) when turning the lights on or off.
Edit: just observed a four-second delay before the first of two lights went off. However, no delay between light switches, which was the objective. Yet.
Still not possible to control LED color, brightness, etc. on a ZEN32 Scene Controller from a Block Scene with the 5.190.38 release. Any idea when this might become available, @Sara, @BartekZooz, or @Agnes?
This is a tricky one, it would require a whole new logic in the platform to control parameter values in a scene. We’ll keep pushing the developers to add it but it’s not an easy ask since there’s the lua scene workaround.
Agreed. But Lua scenes are awkward to do for non-programmers, plus the potential is there for Device IDs to be changed (see the warning on the Device Reconfiguration button on the Z-Box hub) which requires editing any scene containing hard-coded device IDs (assuming one can remember all places that Device ID was used).
Another way to accomplish this is in a Lua QuickApp. I’ve been playing around with this idea off and on for months, but keep getting tripped up by having been unable to get a drop-down selection to work in a Block Scene. The drop-down control appears in the Block Scene, but the control ID is displayed as the only available selection in the scene–even though the fully populated drop-down control is visible and usable in the QuickApp itself! I’ve asked about this and basically gotten the response that QuickApp programming questions are beyond the expertise of Zooz support staff–not an unreasonable response, IMHO, as Lua programming is an entire subject in itself. I’ve scoured the Fibaro forums, as well, to no avail. And yet, these same drop-down selections are available in Block Scenes for actual hardware devices–the ZSE50 Siren/Chime is an excellent example. Since a QuickApp is akin to a Virtual Device, it should work and I’m still searching for whatever it is I am missing as time allows. If it did work, a dynamic list of all devices of that class can be queried and their device numbers used to populate the drop-down, without danger of messing up Device IDs. [Thinking out loud here–thank you for your indulgence! ]
This gets impossible quickly. I haven’t figured out a good way to name scenes or keep things organized to where when I replace something (or the ID changes) I can easily figure out what needs fixed. I almost have to wait till something’s not working, and go hunt it out.
Absolutely true, IMHO. I have a spreadsheet of devices with IDs, names, device type, Model number, etc., which helps. But is it quite a bookkeeping chore to keep it current.
For all these reasons, I hesitate every time I’m tempted to click on the Device Reconfiguration button to try fixing some issue with a device. If this warning is true (what causes the Device ID to change, I don’t know–@BartekZooz or @Sara can you enlighten us or point us to a support article that addresses what triggers a Device ID to change?), this will sooner or later rear its ugly head with the ZSE50 Siren/Chime–which advises using Device Reconfiguration to update the list of sound files loaded on the device!
We’ll definitely look into it, all valid feedback and good points. I’ll let @BartekZooz speak to the device ID issue (give him a few days since most of our on-site team is working on order fulfillments after Black Friday), I don’t think it’s expected behavior and agree, absolutely shouldn’t be happening.
I don’t believe it happens normally. I’ve only had it happen a couple times, out of many, many times I’ve gone through the process. I think it seems to happen when something goes wrong.
Yeah I’ve only had it happen when something goes wrong. One of the times I specifically remember it even lost the name of the device during the process.
)