Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zwave_js: Possible to expose more entities from ID Lock? #45746

Closed
BoneheadFraggle opened this issue Jan 30, 2021 · 19 comments · Fixed by #48336
Closed

zwave_js: Possible to expose more entities from ID Lock? #45746

BoneheadFraggle opened this issue Jan 30, 2021 · 19 comments · Fixed by #48336

Comments

@BoneheadFraggle
Copy link

BoneheadFraggle commented Jan 30, 2021

The problem

To get full use of the lock and automations, it would be very nice to see which tag or code that locked or unlocked (interacted with) the lock and if the lock is in "away" mode.

This didn't work out-of-the box in the old Z-wave integration either, but then you could fetch the data in the log and create template sensors from the actions identified there.

Environment

  • Home Assistant Core release with the issue: Home Assistant 2021.2.0b1
  • Last working Home Assistant Core release (if known): None
  • Operating environment (OS/Container/Supervised/Core): OS
  • Integration causing this issue: zwave_js
  • Link to integration documentation on our website: https://rc.home-assistant.io/integrations/zwave_js/

Problem-relevant configuration.yaml

Traceback/Error logs

Example of the old logs https://community.home-assistant.io/t/integration-with-id-lock-150/78645/6

Additional information

Technical documentation for the lock's Z-wave module: https://idlock.se/wp-content/uploads/2019/08/IDLock150_ZWave_UserManual_v3.02.pdf

Attached the part of zwave_js_dump.jsonl regarding the lock.
zwave_js_dump.zip

@raman325
Copy link
Contributor

raman325 commented Feb 1, 2021

The PR I just linked will add support for Notification events. I think it's what you are missing, but we will know more once it's available for you to test with

@raman325
Copy link
Contributor

raman325 commented Feb 4, 2021

@BoneheadFraggle can you confirm that you have what you need with the new events?

@BoneheadFraggle
Copy link
Author

BoneheadFraggle commented Feb 4, 2021

@raman325
I have tested a little and the basic things, status change and user code works great. Thank you so much for this!

Enabling Away Mode however does not generate an event. Away mode is the natural trigger for arming/disarming the alarm, so being able to use that would be a great benefit.

Chronology for the example below:
1: Keypad Lock - no code used > Event 0. Works perfectly, user 0 identified (no user).
2. Enter Away mode - user code + lock key > No event generated.
3. Unlock with user code > Event 0. Works perfectly, user 1 identified.

Event 1 fired 9:10: 
{
    "event_type": "zwave_js_event",
    "data": {
        "type": "notification",
        "domain": "zwave_js",
        "node_id": 60,
        "home_id": 3803889724,
        "device_id": "ef43a40a818f97b547dbfc27e76ae191",
        "label": "Keypad unlock operation",
        "parameters": {
            "userId": 1
        }
    },
    "origin": "LOCAL",
    "time_fired": "2021-02-04T08:10:58.309768+00:00",
    "context": {
        "id": "d753c3d15c8507722c786cd35917eb43",
        "parent_id": null,
        "user_id": null
    }
}
Event 0 fired 9:10: 
{
    "event_type": "zwave_js_event",
    "data": {
        "type": "notification",
        "domain": "zwave_js",
        "node_id": 60,
        "home_id": 3803889724,
        "device_id": "ef43a40a818f97b547dbfc27e76ae191",
        "label": "Keypad lock operation",
        "parameters": {
            "userId": 0
        }
    },
    "origin": "LOCAL",
    "time_fired": "2021-02-04T08:10:35.760964+00:00",
    "context": {
        "id": "b49fb3e22ab83e904cbad124a93514c0",
        "parent_id": null,
        "user_id": null
    }
}

It seems like the "Notification Parameter / COMMAND_CLASS_NOTIFICATION (V4) / Access Control (0x06)" is the result I get from the event below, while the Away Mode is considered being in "COMMAND_CLASS_CONFIGURATION / Lock Mode".
Maybe possible to expose as a binary_sensor, Away mode true/false?

Anyway, thanks again!

@Skeletorjus
Copy link

@BoneheadFraggle Sorry if this is off topic, but how would one create a template sensor that, for example, shows the latest userId? I'm stumped at how to bring the data from an event into a template sensor.

@BoneheadFraggle
Copy link
Author

@Skeletorjus I'm sure there are several methods, but I googled and found this: https://github.com/azogue/eventsensor which does exactly what I wanted.

I made one sensor for the action (i.e. Keypad lock operation) and another for last user based on this: https://github.com/azogue/eventsensor#a-hue-dimmer-switch-integrated-in-ha-via-hue-integration.

And then a template sensor to combine them like "only show the user if the last action is Keypad unlock operation, otherwise show the last action only".

@raman325
Copy link
Contributor

raman325 commented Feb 4, 2021

@BoneheadFraggle hmm, well if it either has to be a value or an event. Can you take another state dump of your network and see if you can find the away mode as a value? If not, you may need to connect a client to your server to listen for messages and trigger away mode and see what gets generated. You can find instructions on how to do that here: https://github.com/zwave-js/zwave-js-server/

@BoneheadFraggle
Copy link
Author

BoneheadFraggle commented Feb 4, 2021

I did a new dump and I can't see anything about the away mode.

I'm not gonna pretend I understand how this works so forgive me if I don't make any sense, but from what I read in the docs, entering Away mode is a Configuration Parameter and not a Notification Parameter. Which sounds familiar, I remember from trying to fetch it last time, there was something about that. I think we "need to request the current config status from the lock", rather than waiting for the lock to tell us it changed to Away mode. Previously I read the logs and searched for the config string whenever the lock changed state which worked really well despite being a bit primitive..

I found the lock in the Z-wave alliance: https://products.z-wavealliance.org/products/3450/configs
What we are looking for is if the first parameter is 0 or 1 (away mode off) or 2 or 3 (away mode on).

I'll definitely try to connect a client and see what I can get from there, but since I'm totally new to Linux, it may take some time :-)

@raman325
Copy link
Contributor

raman325 commented Feb 5, 2021

thanks for the info @BoneheadFraggle so good news/bad news - the state dump should include configuration parameters, so if you didn't find it in there it may not be a configuration parameter. But the easiest way to tell will be to run the client and see what gets returned when you perform the action. BTW you don't need to be on Linux to run the client, but you do need npm and node

@BoneheadFraggle
Copy link
Author

BoneheadFraggle commented Feb 5, 2021

Sorry about that. I just didn't look close enough.

The value is indeed included in the dump, the value we want at the very end:

Away mode off

{"endpoint": 0, "commandClass": 112, "commandClassName": "Configuration", "property": 1, "propertyName": "Door lock mode", "ccVersion": 1, "metadata": {"type": "number", "readable": true, "writeable": true, "valueSize": 1, "min": 0, "max": 3, "default": 1, "format": 0, "allowManualEntry": false, "states": {"0": "Disable Away Manual Lock", "1": "Disable Away Auto Lock", "2": "Enable Away Manual Lock", "3": "Enable Away Auto Lock"}, "label": "Door lock mode", "description": "Set if the lock is in away mode and if automatic locking should be enabled", "isFromConfig": true}, "value": 0}

Away mode on

{"endpoint": 0, "commandClass": 112, "commandClassName": "Configuration", "property": 1, "propertyName": "Door lock mode", "ccVersion": 1, "metadata": {"type": "number", "readable": true, "writeable": true, "valueSize": 1, "min": 0, "max": 3, "default": 1, "format": 0, "allowManualEntry": false, "states": {"0": "Disable Away Manual Lock", "1": "Disable Away Auto Lock", "2": "Enable Away Manual Lock", "3": "Enable Away Auto Lock"}, "label": "Door lock mode", "description": "Set if the lock is in away mode and if automatic locking should be enabled", "isFromConfig": true}, "value": 2}

zwave_js_dump - away mode.zip

@raman325
Copy link
Contributor

raman325 commented Feb 5, 2021

OK so maybe we need to create sensors for Configuration Parameters at some point (disabled by default) so that you can access this value.

@BoneheadFraggle
Copy link
Author

Ok, sounds promising :-)
Is there anything I can do to help or test?

@raman325
Copy link
Contributor

raman325 commented Feb 5, 2021

Nope, nothing for now!

@BoneheadFraggle
Copy link
Author

@raman325 I have tried to keep up with all the changes and new functionality in Z-wave JS and I have seen a lot regarding Config Parameters, but I don't understand if that affects this issue. Do you know if it is possible now? Just curious, not asking for ETA.

@raman325
Copy link
Contributor

It's not possible yet in the upcoming release. I asked about the possibility of creating entities for config parameters and the idea was shot down. The alternative is to target specific parameters to make entities. I'm not a huge fan of this approach but it seems to be the one most accepted among the dev team. I will ask again about this and if that's where we land, we can add support for it in 2021.4. Truthfully I forgot about this and was focused on other areas for 2021.3

@BoneheadFraggle
Copy link
Author

No problem, just curious. Thanks for all your efforts!

@BoneheadFraggle
Copy link
Author

BoneheadFraggle commented Mar 25, 2021

Just being curious, I activated debug mode zwave logs today.

logger:
  default: info
  logs:
    zwave_js_server: debug
    homeassistant.components.zwave_js: debug

And then I can fetch the mode change from the log.
However, those are still not visible while listening to "events" in Dev Tools / Events.
Confusingly enough for me, it seems like listening to "Events", only gives me "type": "notification", not "type":"event"

Anyway, in the debug log it shows up like this, "newValue" showing the lock mode:

From Home Mode > Away Mode

2021-03-25 16:45:14 DEBUG (MainThread) [zwave_js_server] Received message:
WSMessage(type=<WSMsgType.TEXT: 1>, data='{"type":"event","event":{"source":"node","event":"value updated","nodeId":60,"args":{"commandClassName":"Configuration","commandClass":112,"property":1,"newValue":2,"prevValue":0,"propertyName":"Door lock mode"}}}', extra='')

From Away Mode > Home Mode

2021-03-25 16:59:56 DEBUG (MainThread) [zwave_js_server] Received message:
WSMessage(type=<WSMsgType.TEXT: 1>, data='{"type":"event","event":{"source":"node","event":"value updated","nodeId":60,"args":{"commandClassName":"Configuration","commandClass":112,"property":1,"newValue":0,"prevValue":2,"propertyName":"Door lock mode"}}}', extra='')

I can grep it there, but is there any way to configure the "type":"event" to show up in zwave_js_event?

@raman325
Copy link
Contributor

These will not show up as events because they are value updates. Think of them like state updates. What we are missing is an entity for this particular property. Can you send me a current dump of your lock? I can look at adding support

@BoneheadFraggle
Copy link
Author

Ok, that makes sense even to me.

Thanks. Here's a new dump of the lock. Quite nice to read now compared to the old structure :-)
zwave_js_dump.zip

@raman325
Copy link
Contributor

Ok, that makes sense even to me.

Thanks. Here's a new dump of the lock. Quite nice to read now compared to the old structure :-)

zwave_js_dump.zip

FYI this entity has been added and will be released in 2021.4. The entity is disabled by default so you will have to enable it

@github-actions github-actions bot locked and limited conversation to collaborators Apr 26, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants