Change State Variable With Rule Machine

Hello All,

Hoping someone can point me in the right direction and/or let me know if what I am trying to achieve is even possible.

I have a Zooz Zen 16 multi-relay, wired up between a traditional door bell chime and door bell button. The idea is that I can manually trigger the door bell from a rule machine rule for other alerting purposes (alarm arm/disarm confirmation, specific times of day as a class room bell type scenario, etc...), but more importantly it gives me the ability to enable/disable the door bell during baby nap times or late in the evening. Below is a rudimentary wiring diagram. Forgive the terrible artwork, I am writing this with a broken hand. :slight_smile:

image

At any rate, in order to enable/disable the physical door bell button attached to the switch port associated with the relay port in question (for this example relay 1 and sw 1) I have to manually change a state variable in the zen 16 device page from enabled to disabled. See screenshots below.

Through some trial and error, I have found that this value is tied to state variable "configVal12". When its set to 0, sw1 is disabled. When set to 1, sw1 is set to enabled and allows the exterior door bell button to trigger relay 1.

image

What I am trying to figure out, is, is there a way, without a custom driver, to configure something like rule machine to change this state variable configuration value; i.e. 0 or 1.

Hopefully this all makes sense, but if you require any additional clarification or details, please let me know.

Kind Regards,
Mark

There are a few issues here, but the takeaway is that right now, what you want is not possible, at least with the stock driver.

  • The configVal12 thing you see under "State Variables" is internal to the driver and is entirely up to the driver author (Hubitat or a contractor, in this case) how it is used, but it's often used for storage as part of a comparison between what the device reports the parameter as being versus what it should be set to based on your preference selections (many of which, for Z-Wave devices, are intended to modify Z-Wave parameters supported by the device). In general, "state" is not intended for end-user consumption, just internal app or driver storage.

  • "state" variables cannot be viewed or set by Rule Machine or any app or driver except the app or driver code running that particular app or driver (again going along with the fact that they're really just for the app or driver's internal use)

  • What apps like RM (or any) can do is read attribute values ("Current States") and execute commands (the buttons you see under "Commands" under the device page, not pictured in your screenshot but just above what you see there). Unfortunately, this driver does not expose anything as a command here that can modify this parameter, though that would theoretically be possible with a custom/community driver.

But, here's something that may help: Hubitat staff have teased an upcoming feature in platform 2.2.5 (no estimated release yet) that will allow you to automate the changing of any device preference, something previously not possible. Exactly what you can use to "trigger" these changes remains to be seen, but it looks like there might be something coming up that could help you. So maybe soon! :smiley:

Something else to consider in the meantime: is there an automation on Hubitat that makes the chime "ding." or is that handled entirely by the Zooz unit? If it's an app/rule (and not just a driver setting) on Hubitat that actually causes the chime, there should already be a way to restrict that on the app side. I'm not familiar with how this Zooz device works...

@madutam Maybe you just could swap out the bell press button for a wireless (zigbee/zwave one) and then use a rule to control when the chime would sound. If and when 2.2.5 comes out you could swap it back?

Whoa - the holy grail. I asked about this months ago and Bruce said it wasn't possible.

i use this.. works well,

it pairs as a button device as it can monitor two doorbells if you have both hooked up to your chimes.. it is zigbee, there is a built in driver.

NEW SAGE Doorbell Sensor by Hughes - Security & Home Automation - Factory Sealed | eBay

Yes, I have thought about that as well and have actually already purchased some hank four-key scene controller z-wave button I planned to hack up if I had no other options.

However, my wife prefers the look of a traditional door bell and I would prefer to have one less battery operated device outside. I live in the pacific northwest where its raining about 70% of the year and/or freezing cold so batteries drain quickly outside and a waterproof enclosure would be a must.

A xiaomi zigbee door sensor is way smaller and the reed switch contacts could easily be soldered to the bell press button and (maybe) all fit into the housing you have.

This is pretty neat, but what I am trying to do is a little different. I want to be able to not only monitor the chime, but control when it does or does not make a sound. I can do this manually now by either disabling or enabling manual control of physical button port associated with the the ZEN16 relay port attached to the chime. What I am after, is a way to do this though an automation rule. i.e. at X time of day, turn off and at Y time of day, turn back on.

Not a bad idea with the smaller reed switch contact sensor and it would serve the same purpose. Something I will consider if what I am asking for is not possible. Thanks.

One workaround comes to mind: get a second 24v door bell transformer. Wire the first to the "+" and "-" for the Zen 16 as you have it now; wire the second to the chime, through R1. Then, plug the second transformer into a Zigbee/Z-Wave controlled outlet.

The Zen is powered at all times, so you can always detect the button press; the chime only sounds when the second transformer is powered on, which you can control with a rule.

2 Likes

I use the zen 16 for my front and back doorbell as well. Love it. It allows me to keep the original chime that came with the house (a beautiful piece with brass tubes) and the original doorbell buttons at the house. If you are only using one or two of the three relays on your zen16 there is an easy solution to your problem.

Just run the power to the chime through a spare relay on the zooz and decide when you want it to be open/close. (i.e. chime sounds/chime doesn't sound). The great thing about this is your hubitat will still know when the doorbell button(s) has been pressed to provide you with other types of notifications.

1 Like

Great idea. I am currently only using relay ports 1 and 2 for the front and back door chimes. Port 3 is free. I can just control power to the chimes using relay port 3 and not worry about the physical switches outside. Thanks!

Looks like you have 2 unused relays there. Run the doorbell switch wiring thru R2 in series with sw1. Then then the doorbell switch can only turn on sw1 if relay R2 is closed. And R2 can be controlled by rule machine.
Or, if during the nap time you want to have the doorbell silent, but receive a notification or have a light flash to indicate someone is pushing the doorbell, then instead of wiring the doorbell switch thru R2, wire the doorbell power thru R1 and R2 in series. Then if you have R2 off, you can still detect that sw1 was on (from someone pushing the doorbell) without actually having the doorbell ring.

Unfortunately it looks like preference manager isn't it. Unless there's some way to access the fields from RM?

Yeah, didn't turn out to be quite what I thought it would be. :slight_smile: No way to automate, just a way to change them (manually) from an app instead of individually in each driver. So, to really automate it, you'll still need the driver to expose a command.

Just thinking this through you’d have to create an app that would allow you to select all devices you’re interested in, and then create a composite device that would expose a setter function for each preference.....not simple, but not impossible. A getter should also be possible, but would need to return a map object to be useful.

Way above my skill level I'm afraid although as you say it must be possible (as Preference Manager exists).

I don't actually think this could be done. Unless a parent/child relationship exists between the app and device, there is no way to access anything from the device other than its (declared or capability) commands and attributes. The fact that Preference Manager can do this is undoubtedly due to the (existing but rarely-used) superpowers that system/built-in apps can wield compared to user apps.

EDIT: A clunky workaround, I suppose, would be to simulate the HTTP calls that a user clicking the right preference on the device page would do. Easier without hub security, awkward either way.

That's too bad. TBH I'm not sure about the usefulness of preference manager (for me) due to the lack of control granularity for individual devices.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.