Global Moderators

The ZWay plugin uses the high-level interface to the ZWay firmware. As such, it only has access to those things which that API provides. It seems somewhat random sometimes. Through this interface we are seeing the sensor in question, but it's an issue to do with how we represent these as child devices. However, the 'raw' variable in the parent device zway_71-0-49-4 is available for you to read, but you can't set a variable watch on it. You'd have to poll it with a timed scene, or such like.

I will look further into adding this to the child device, but, as mentioned, there may be a conflict with other reported power variables. We'll see.

Edit:

Yes, there is potential conflict. Just checked the source code and find this comment:

--  2020.03.05  "Watts" conflicts with meter "50-2" if both present

I may, in general, be able to code around this in the event that there is no reported command class 50-2, but for this device there IS, so that's a problem.

Hmm, I see a bit of a conflict here. Command class 50 is for metering, but 49 is a multi-level sensor. It’s going to be hard to find a rule to deal with that automatically. Let me see if there’s a fix to achieve this manually… or, perhaps, @rafale77 has a suggestion?

I've had app.sh on my deprecation list for some time, so I don't use it or test with it. I may review that choice.

That suggests that server/lib/Logger.js cannot be found under the directory given. Make sure your unzip and copy of the files from the distribution is complete.

Edit: looking more carefully at it, it appears that the ':' at the end of the path in NODE_PATH is not from the messages, but is actually in the path. That's an error.

This actually is a separate topic, so I forked it here...

I'll need to add a sort() function to the expression language. This is something I've had on radar for a while, but doing it "right" is not as simple as one might think.

Can you show me the complete variable list for the actual parent device? This should have all the values received from ZWay.

Of course it would. You didn't mention you also had a single click action. If you are implementing that with a condition in Reactor, the single click then needs a "sustained for" with "longer than" and the same delay as the "less than" on the double-click condition. That way, they oppose each other (one happens when the on period is less than the setting, the other happens when the on period is longer). But, that means the single-click on will now have a delay before it acts (because it's waiting to see if it's going to be a single click or a double click). Unavoidable.

@rhcpng said in Reactor: double click action:

When I double click it, it gives me on-off, instead of on-off-on. That makes it a bit more tricky.

In that case, instead of using repeat, use sustained for with the "less than" modifier and a short time span (15 seconds?). This will cause the condition to go true only if the "on" state persists for less than that time, which it sounds like it would if you press the button twice rapidly and it goes on-off rapidly when you do.

@rhcpng said in Reactor: double click action:

This is probably for a toggle switch, right? How does it work for a momentary switch?

Works the same. What happens when you press a momentary switch and release it? It goes on, then off. So double-press would be on-off-on-off... in which case you can detect either on-off-on ("is TRUE") or off-on-off ("is FALSE") and it will work pretty much the same.

This is MSR, but Reactor for Vera is almost identical in this respect, and this rule was imported from my old R4V configuration, in fact.

@rhcpng The repeats condition restriction with a time constraint is an easy way to detect quick successive transitions of a switch (or any device):

Here is exactly such a condition from my own house. In this case, a rapid transition of a switch at the base of my basement stairs from off-on-off launches a scene that turns off all lights on the basement level of the house. To get on-off-on, just change the "is FALSE" test to "is TRUE".