Zen32 question
-
OK. Let's unravel for a minute.
First, the pulse from changes is very short, and you will not usually see it in the UI without a delay. Adding a delay reset helps this, at the expense of losing responsiveness if the button is hit several times. This may be OK with the ZEN32, because it allows double, triple, quadruple and quintuple presses, so it has a delay of its own to detect that. But in reality, you don't need any delay in Reactor.
I was not suggesting you add actions to the reset; I was actually asking to make sure you didn't, because having them will actually work against you. You don't want to do that. Without the delay, or even with a short delay, there's a high likelihood that you will make the changes condition resetting itself (and thus its parent rule going back to RESET) preempt the SET reaction (because that's what happens when the RESET reaction isn't completely empty) and your SET reaction won't finish.
Also you may be experiencing an artifact of the way toggle.toggle is implemented. There is no toggle command in Z-Wave, so ZWaveJSController simulates it by looking at the current state of the target device and telling it to go opposite -- off if it's currently on, on if it's currently off. The issue, though, is that it can take from a few milliseconds to several seconds for the state of the Reactor switch entity to update, and this is highly dependent on the quality of your mesh as always. So if you're hitting the buttons fast, the entity states may not be fully caught up, and so it won't send the right on/off to the device. That's just a function of the responsiveness of the mesh and the connection between the controller, zwave-js and Reactor, all of which add latency. Not much to do there but take it as it comes.
Rather than use toggle.toggle, what I use in testing is a simple local variable on the rule as a counter that I increment in the SET reaction every time a button press is detected. This makes it very easy to tell if the changes is working, as the feedback is immediate and not reliant on any external hub, service, or device performance.
The ZEN32 is also not a perfect device. There is at least one firmware update for it that has been published that I am aware of, and there is discussion in various forums about bugs that people hope will soon lead to another. In my own experience, I can make it stop updating by pressing buttons too quickly. I have found that if I press a button again while its LED is blinking (during transmit of the previous press), about half the time the device will stop sending updates for that button. I don't need Reactor to see this, I can see it in the zwave-js logs and message stream (or lack thereof). It corrects itself usually after a few seconds, so I imagine something inside the ZEN32 gets in some state that times out after that period. So that also could be happening to you and befuddling your testing. Hopefully they find and fix whatever that is, but of course, it will require you to update the firmware on your ZEN32 when they do, which is a bit of a pain. That's a shame, really, because in terms of WAF, anything that makes buttons stop working, even briefly, is a non-starter for widespread use in my house.
-
Hi Patrick,
Couple questions on the ZEN32's. Since the 2002.3.x upgrade of HA my zwaveJS2mqtt has been very unstable, especially with the multi tap scenes on the ZEN32. They usually work for a period of time following a reboot and then become unresponsive at some point. Haven't been able to nail down a time frame on how long it runs till becoming unstable.
Currently working right now so I cannot get you any info.
Are you and I the only users in your test group using Zen32's? If not, anyone else seeing stability issues? -
HA has nothing to do with ZWave-JS, except for the fact that it uses it, but that has nothing to do with ZWaveJSController and what Reactor may see and do with those devices. Based on the above and your other post, I'm not clear if we're talking about entities that are coming from your HassController instance or your ZWaveJSController instance. More information/clarification is required here.
They usually work for a period of time following a reboot and then become unresponsive at some point.
Again, it's not clear to me what you are rebooting (Hass? zwavejs2mqtt? Reactor? ZEN32 itself?). And not clear what is unresponsive.
Are you and I the only users in your test group using Zen32's?
Based on the data, I think that's the case. I am using ZEN32s directly sourced from ZWaveJSController, though, having nothing to do with Hass, and having no issues other than those I have previously described to you, which are a result of the ZEN32 not sending data to the mesh temporarily under certain conditions. And that is only temporary and the ZEN32 recovers in 10-15 seconds.
EDIT: I just checked that last data update I have from your system, and the ZEN32 nodes 36 and 45 are both marked dead as of the moment that snapshot was taken. I'm guessing you rebooted zwavejs2mqtt and then immediately rebooted Reactor? That Reactor reboot would be around 5:30PM Eastern time/22:30GMT yesterday 3/8?
EDIT 2: Are you on the new 22067 build? If not, what build are you running?
-
Hey Patrick,
My setup for the ZEN32's is I use MSR to monitor zwavejs button.state(primary) for the string value with an AND condition to monitor zwavejs button.since for any changes. Works for awhile and then no response. When I look at it in MSR Entities nothing is changing on the entity for the button I am pressing. I usually reboot the HA box and it works for awhile. sometimes, though not all, MSR status reports zwavejs down though not always. -
Hey Patrick,
My setup for the ZEN32's is I use MSR to monitor zwavejs button.state(primary) for the string value with an AND condition to monitor zwavejs button.since for any changes. Works for awhile and then no response. When I look at it in MSR Entities nothing is changing on the entity for the button I am pressing. I usually reboot the HA box and it works for awhile. sometimes, though not all, MSR status reports zwavejs down though not always.@rogero See my other comment in your other thread. Based on what you've said there, it seems like you are running Hass with ZWave.me and a Razberry card, and trying to run zwavejs2mqtt at the same time interfacing to the same card? That sounds to me like a dog that won't hunt (i.e. two different interfaces wrestling for control of the same card seems like it's doomed to failure).
-
@RogerO OK. Since I'm squared away on the ZWave.me/zwavejs issue (you're using a ZWave.me card/hardware, but running only zwavejs software, all good)...
On the Z-Wave data from your system received yesterday mentioned above in my edit... the ZEN32s were not ready (interview completed) when ZWaveJSController connected to zwavejs. That would suggest either (a) you had just rebooted zwavejs and Reactor together (one immediately after the other), or (b) you have a serious mesh issue and initialization of the ZEN32s is taking a long time (maybe both). Either way, I can see how there's an opportunity for ZWaveJSController to miss setting up the update of some device values, because zwavejs doesn't transmit any values if the device isn't fully ready, so I've fixed that and there's now a 22068 build available for download. My zwavejs runs for days/weeks and doesn't crash, and I rarely restart it, so it's almost always in a state of readiness with all devices interviewed when I restart Reactor (which I do a lot during development) — I would not often see the conditions your data file was suggesting, and that would account for the difference in experience with this device. But that's now handled. I'm curious to hear if your ZEN32s improve on this version.
-
T toggledbits locked this topic on