I have Yale YRD220 which I’ve had set up and working for quite a while. I’ve recently had the need to see some more stats in HomeAssistant, such as how the device was locked (with a code or manually with the deadbolt). This is possible as the device transmits Alarm_Types, however they don’t seem to be exposed at the moment. (see page 4 - https://www.cd-jackson.com/zwave_device_uploads/321/Yale-Z-Wave-Developers-Guide.pdf)
Reading around, it seems I need to have the lock paired in Secure Mode. Now I’m not sure if it already is, for starters, and if it’s not how do I actually do that? I can’t seem to find this information anywhere…
It is my understanding that the Yale devices can only be paired with security but I could be wrong.
The only way that I know to tell whether it was included in secure mode is to go look into the device/advanced/variables under the variable capabilities. If you see a bunch of “S” at the end of the capabilities and the number 152 at the end (corresponding to x98 in hex) then your lock was included with a security key. If you use ALTUI, you could see that under the configuration tab of the device which should list " * 0x98-COMMAND_CLASS_SECURITY" under the node info block.
It’s through the Vera. I can lock and unlock through HA just fine, and it does report the battery level and the state etc, I’m just not quite able to get at these alarm reports.
My issue (I think?) is I’m not really clear on where to find the correct name for “sensor.front_door_alarm_type” for example. Should that sensor already exist in HA? Do I need to change the “front_door” part to match my lock entity? I just can’t seem to work it out
I see, you are using the vera as a device bridge into home assistant. It wasn’t clear in your initial post. This I think is more of a question for the home assistant forum I am afraid. I am not using this integration myself. I am actually doing the reverse: I am using home assistant as an API bridge into openLuup. You likely need to bridge in this device variable.
Hmm, seems that when paired with Vera, these extra alarm parameters aren’t actually exposed. Using a Zwave stick with HomeAssistant (so Openzwave) does expose these values. That’s really annoying actually, I wonder if there’s a way to get the extra values out there
The lock supports 1 association group with 5 devices. Alarm Reports are sent out
unsolicited to devices included in the association group.
So presumably it exists, but it’s only passed around via association (which doesn’t really help I guess). Maybe I’ll bug Sorin to see if it can be added, otherwise I’ll investigate a zwave stick instead for a bit.
Using a Z-wave stick has it’s own set of challenges, so I’d prefer to stick with Vera for my Home Assistant system. I’ve evangelized Vera in the Home Assistant community in the past, but things like this (and a few other things that have soured some people to Vera) have set up make it difficult to recommend it wholeheartedly.
edited to add: even if it isn’t directly exposed on the UI, if there is a way to request it via http, it could be useful.
edit2: I think with just a little bit of work (on functionality and reputation), Vera could become the “defacto” recommendation for Home Assistant and other installs. It’s a rapidly growing community, and offloading Z-wave (and ideally, Zigbee and Bluetooth) has several notable advantages.
Home Assistant’s Vera component uses pyvera, which has some serious deficiencies in its implementation that would not be easily corrected–it would require a near-rewrite of pyvera, which would severely disrupt the Vera Hass component and thus require a near re-write of that as well. The issues, if you are interested, are pretty thoroughly discussed in the Issues section of the pavoni/pyvera Github repo. At one point, I contemplated taking this on, but there is little support from the developer to engage this level of work (he’s basically said in so many words that it works well enough for his needs and that’s good enough), and my real long-term interest lies with creating great work on Vera, not in Hass. Since trying Hass, my own interest has waned due to the problems I discovered, and I am now back to a 100% Vera environment. As far as I’m concerned, Hass is a dead-end for Vera users, at least for the moment.
That’s unfortunate, although I was looking at it from other other perspective: making Vera work somewhat better for Hass users could result in considerably more sales of Vera. As it stands right now, the defacto recommendations are Z-wave sticks. More sales of Vera would hopefully lead to more resources for improving Vera.
Having said that, are the deficiencies you’re referring actually blocking the additional lock parameters? My hope would be that if they were exposed by Vera, we could get them to Hass without a complete redo of pyvera.
They are blocking all parameters, save a few. The two big issues can be summarized this way: the polling/subscription service is based on sdata rather than status, so only those values that are represented by shortcodes in the service definitions can be subscribed to; anything else has to be explicitly requested through separate APIs (i.e. polled individually per value per device); and all of the APIs do not take service ID into account–the assumption throughout pyvera is that a variable name is unique on the device, not within the service, and the architecture and implementation reflect this (the service ID is basically ignored–its importance was never understood).
Vera publishes all of the necessary data. Unfortunately, even if pyvera were left alone and the Vera Hass component was to individually request what was needed, it would be so massively inefficient that it could not scale. It would bury the Vera in HTTP requests. And it would not be responsive. The Vera Hass component got built on a weak foundation, and so inherits its problems.
Worse yet, like pyvera’s maintainer, most people think it’s good enough, so even if one had the incentive, energy and time to fix it all, they’re in for a big hurdle getting the necessary breaking changes through the maintainers of the three projects affected. Not a hill I’d want to die on, I’m afraid.
Understand completely, and appreciate the detailed response.
Unfortunately I’m not a python guy and I don’t know the architecture of things to know how easy it’d be to build a pyvera replacement, but just after my last post, I found this that might or might not be of use to someone:
This thread is very depressing by the way. I really love homeassistant for the most part, but the Vera stuff is definitely lacking (honestly most stuff relating to Vera is lacking though, let’s be fair).
I wonder if, when the new guys here release their new branded hardware, if they’ll eventually just introduce their own software from scratch. I’d love that, Vera feels like it’s just built on shakey patches, and while I’ve been using it for years I’m not, and never have been, anywhere close to 100% confident in it.
This is not Vera’s fault. In fact, it’s part of Vera’s good implementation choices that makes the nearly-instantaneous response to device changes that Home Assistant (and others, like openLuup and ALTUI) possible. But pyvera had to choose between two views of state data, and they chose the trivial view, and that’s now severely limiting. And, as I said, they’ve made other mistakes as well. So, the Home Assistant debacle with locks, thermostats, and any other device that has more complex status and/or actions lies squarely on the shoulders of pyvera, and as I said, the developers of the Vera Hass component (probably unwittingly) built on top of a poor foundation.
Best Home Automation shopping experience. Shop at Ezlo!
