Closed JPDMaker closed 1 year ago
Having same issue, also the door status is always open. Doesn't seem to report the state of the sensors correctly. According to their zwave documentation both should be on the reports. Different parts of the door condition
I'll try on Monday
Thanks. There really should be two entities for the pro if the sensor is present. One for the lock, and one for the door sensor
That's a bug in the device firmware, at least in v1.1.3 which my lock is on.
When being queried for the supported door components, it has the byte set to 6:
which means Bolt and Latch states are supported, Door state isn't:
Given that the manual states that Bolt and Door are supported, this seems like a bug.
Despite that, I can't get the lock to report any change in door state. It always reports door open.
Well that's not awesome. I send an email to them about this issue with this thread... Maybe they can fix it. Would be great to be able to get door status
Hi @AlCalzone ,
I wonder if we can put some special code in to make a fix for this device and this version firmware? the outdoorhandle value is clearly matching the door sensor state.
Or, if you can give me a quick hint where the related code is, I can try to make a change, then you can choose if you want to merge it in.
Thanks.
We don't hardcode such one-time device-specific behavior.
I've heard that U-Tec finally managed to reproduce the issue, but no idea if and when this will be fixed.
@AlCalzone do you have a link to their issue I can follow ?
Nope, that was all back-channel information. Haven't head anything since.
I would like to add that they have seemingly made no progress on fixing this issue and I have discovered a second issue and it seems others have as well.
When the lock is triggered to lock, even if the locking process fails, say the door isn't closed all the way or something happens to make it not engage the deadbolt, the lock will beep and error out but the reported status to z-wave is that the lock was successful. This is dangerous as even though you should always manually check for security, it should report some kind of error or at least fallback to the previous state. Kind of disappointed in Ultraloq on the development of this.
Yeah, the lock is good, but if they don't actually fix bugs then it's really not a great choice
On Tue, Jul 4, 2023, 10:31 TheOgre @.***> wrote:
I would like to add that they have seemingly made no progress on fixing this issue and I have discovered a second issue and it seems others have as well.
When the lock is triggered to lock, even if the locking process fails, say the door isn't closed all the way or something happens to make it not engage the deadbolt, the lock will beep and error out but the reported status to z-wave is that the lock was successful. This is dangerous as even though you should always manually check for security, it should report some kind of error or at least fallback to the previous state. Kind of disappointed in Ultraloq on the development of this.
— Reply to this email directly, view it on GitHub https://github.com/zwave-js/node-zwave-js/issues/5445#issuecomment-1620360640, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADAEABHC2QPSLJ2OFVBKUTLXOQSNJANCNFSM6AAAAAAUXA6EVU . You are receiving this because you commented.Message ID: @.***>
Yeah, the lock is good, but if they don't actually fix bugs then it's really not a great choice
I completely agree. The firmware version of my lock is 02.26.0022 which, from how it reads, is from February of 2022, so no firmware updates in almost a year and a half. For something that's supposed to be a "Work With Home Assistant" product, that's a pretty unacceptable lack of updates especially when there are glaring bugs.
We have decided to terminate the Works with Home Assistant relationship with Ultraloq. We had reported these issues with them and were discussing solutions. However, they ceased communication from their end and we have received no further updates.
We have decided to terminate the Works with Home Assistant relationship with Ultraloq. We had reported these issues with them and were discussing solutions. However, they ceased communication from their end and have received no further updates.
Good to see some action being taken about this. Thanks for keeping Home Assistant great!
I'm afraid there's nothing to be done in this project, since the functionality is just broken.
Could we update https://www.home-assistant.io/integrations/ultraloq/ ?
@TheOneOgre @holblin @AlCalzone https://github.com/home-assistant/home-assistant.io/pull/28166
This problem has been solved in the new firmware, which can be upgraded online through Home assistant.
Will it be added back into the WWHA partner program?
Yes, we do our best to add it back.
Thanks!
@.***
From: God-TM Date: 2023-08-23 08:51 To: zwave-js/node-zwave-js CC: jack; Comment Subject: Re: [zwave-js/node-zwave-js] Ultraloq Pro Z-wave (Issue #5445) Will it be added back into the WWHA partner program? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
Will it be added back into the WWHA partner program?
I wouldn't think it would or should be added back. Ignoring HA devs, not providing timely updates, not notifying users of issues, and overall not being easy to work with, is an easy disqualifier for being in a partner program. I think the biggest thing was the untimely manner in which they handled this and the complete lack of communication.
Also, I haven't tested it yet but, can anyone confirm if the "false lock" bug is still occurring where if the lock is told to lock, but fails due to the door being slightly open or something, the state is still reported as "Locked"? Was a HUGE oversight before if you relied on that status for your door being locked.
Also, I haven't tested it yet but, can anyone confirm if the "false lock" bug is still occurring where if the lock is told to lock, but fails due to the door being slightly open or something, the state is still reported as "Locked"? Was a HUGE oversight before if you relied on that status for your door being locked.
Tested and the "false lock" bug still exists.
Will it be added back into the WWHA partner program?
I wouldn't think it would or should be added back. Ignoring HA devs, not providing timely updates, not notifying users of issues, and overall not being easy to work with, is an easy disqualifier for being in a partner program.
Things have changed drastically in the last few weeks! Please feel free to put that to a test! I' doing exactly so with the last statement, the "false lock" bug which I expect to be worked on very soon. But that's why, yes, we plan to add them back to the WWHA partner program!
Also, I haven't tested it yet but, can anyone confirm if the "false lock" bug is still occurring where if the lock is told to lock, but fails due to the door being slightly open or something, the state is still reported as "Locked"? Was a HUGE oversight before if you relied on that status for your door being locked.
Tested and the "false lock" bug still exists.
Thanks for Testing. I will check it ASAP.
I just tested it. Perhaps I'm not understanding what's wrong here, but when I open and close the door, the sensor labled "Current status of the door" goes from Open to Closed and vice-versa accurately reflecting the state of the door. I can tell it to lock in either state, and the state is still either Open or Closed depending on if it's actually open or closed...
I have tested it, the door status is correct depending the open or close operation.
Please put the door magnet as close as possible to the lock, the farther the magnet is, the weaker the magnetic is.
Can you show me your test environment picture include the lock and door magnet ?
I used to have a Gen 2 August Pro there, so I left the magnet from that and used it with the Ultraloq Pro. So far it's been working without any issues.
Please let me know if I can take any better measurements or angles that might be helpful for you.
I did test the scenario where you close it mostly but leave it a bit misaligned. If I tell it to lock, it technically goes into a lock status (and I see I can unlock the door). But the sensor is still showing the door is open as well. I don't believe this is any different than what the August Pro would do.
Thanks for your info.
I'm not the one having issues with this lock (I figured I'd take pictures of a working environment if it could help anyone)... I'd rather not break what's currently working for me.
I tested the lock jam bug. Does not update status.
lock serial number: 8030305122130050
This occurs both when the door is sensed to be closed or open
Paper used to force jam while closed.
Do our best to optimizing them.
hi JPDMaker, Where should the status of Jam be displayed in home assistance UI?
It’s the state of the lock entity. Should update state to either ; Jammed, Locked, Locking, Unlocked, Unlocking, Unavailable, Unknown
It’s the state of the lock entity. Should update state to either ; Jammed, Locked, Locking, Unlocked, Unlocking, Unavailable, Unknown
The Z-Wave integration does not support any of the extra lock states like jammed. It only supports locked or unlocked.
You can make HA feature requests at https://community.home-assistant.io/c/feature-requests/13.
Oh we definitely should have those states!
Took me a while to track this down but this appears to be set in https://github.com/home-assistant-libs/zwave-js-server-python/blob/0.51.1/zwave_js_server/const/command_class/lock.py#L81-L86
Then mapped in HA core in https://github.com/home-assistant/core/blob/2023.8.4/homeassistant/components/zwave_js/lock.py#L40-L49
Jammed is not a lock state in node-zwave-js
. It's a notification variable, which gets translated to a sensor in HA, I think here:
https://github.com/home-assistant/core/blob/7548c4aced3872c0d685ae0b07529a1f20fddbcd/homeassistant/components/zwave_js/discovery.py#L773-L785
Yes, there is a lock jammed sensor (https://github.com/home-assistant/core/blob/7548c4aced3872c0d685ae0b07529a1f20fddbcd/homeassistant/components/zwave_js/binary_sensor.py#L139-L145).
So the lock entity could use this value. PRs are welcome.
(Deleted my other incorrect reply).
This issue( When the lock is jammed,the lock status is lock, user can not lock again) is fixed. We are trying to add the jammed notifacation funcation, need more time.
New Z-Wave U-Bolt Pro, latest firmware applied, latest HAOS/core, status is still stuck at open for u_bolt_pro_z_wave_smart_lock_current_status_of_the_door. The app shows correctly so the position sensor is working.
I still find it tricky to trigger changes of the sensor without mounting the lock in a doorframe, but I haven't managed to get the state in the app and HA out of sync. When the status does change, I see it in both. Might be a connectivity issue?
I still find it tricky to trigger changes of the sensor without mounting the lock in a doorframe, but I haven't managed to get the state in the app and HA out of sync. When the status does change, I see it in both. Might be a connectivity issue?
Don't think so? After latest update the door status seems to be working slightly better. What consistently seems to not work is auto-lock after X seconds doesn't seem to update the lock status. Opening the door from outside and then it locking automatically when closed is working. But if I open it from HA, then it auto locks after 15 seconds... the status does not get updated.
auto-lock after X seconds doesn't seem to update the lock status
Wait, are we talking about the lock status or the door status?
auto-lock after X seconds doesn't seem to update the lock status
Wait, are we talking about the lock status or the door status?
Sorry I kind of switched gears. Door open status seems to be a bit better since the latest update. However the auto-lock has been an issue since adding the lock. Anytime I manually unlock it, that gets tracked properly in HA. Anytime it automatically locks it seems to not get tracked. I hit the lock in HA, and the status changes but the lock does nothing which is what I'd expect. So it knows it's already locked at least!
Ok I'll try to reproduce that tomorrow
I have tested in our site. The lock updates the correct status after auto-lock. For testing door status,please move the lock body,don't move magnet.
The version of my lock. The firmware version(in u-tec app show):02.26.0022 The Z-wave firmware version(HA show):1.5.3
Can you share me the testing video? We want more operate details to debug the issue. Thanks.
I have tested in our site. The lock updates the correct status after auto-lock. For testing door status,please move the lock body,don't move magnet.
The version of my lock. The firmware version(in u-tec app show):02.26.0022 The Z-wave firmware version(HA show):1.5.3
Can you share me the testing video? We want more operate details to debug the issue. Thanks.
Ok I have some further testing results. Door open status seems to be working perfectly fine for the moment. Door lock status status when opened at the lock seems perfectly fine, including when it auto locks. When I open the lock via the app, and it auto locks, status is reported fine. It's only when I open the door via HA that this issue occurs. And it doesn't seem to matter which kind of card I use. I can open the lock, it will update the status, but when the lock auto locks the HA state still reflects unlocked. When I click it again, it will beep and indicate lock. Sometimes this can get totally out of sync where it think it's unlocked but it's actually locked or vice versa. So it's only when controlling via HA that this is occurring. I can try and make a video if it's helpful I just wanted to clarify that first.
Is your problem within Home Assistant (Core or Z-Wave JS Integration)?
NO, my problem is NOT within Home Assistant or the ZWave JS integration
Is your problem within Z-Wave JS UI (formerly ZwaveJS2MQTT)?
NO, my problem is NOT within Z-Wave JS UI
Checklist
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem was not mentioned there.
Describe the bug
[77-98-0-latchStatus] Current status of the latch is always reporting "OPEN"
U-tec support said the issue could be on the z wave hub side. Thread of others reporting the same issue: https://community.u-tec.com/t/expand-and-fix-z-wave-capabilities/502/18
Device information
Manufacturer: u-tec Model name: U Bolt Pro Z wave Node ID in your network: <077>
How are you using
node-zwave-js
?zwave-js-ui
(formerlyzwavejs2mqtt
) Docker image (latest)zwave-js-ui
(formerlyzwavejs2mqtt
) Docker image (dev)zwave-js-ui
(formerlyzwavejs2mqtt
) Docker manually built (please specify branches)ioBroker.zwave2
adapter (please specify version)HomeAssistant zwave_js
integration (please specify version)pkg
node-red-contrib-zwave-js
(please specify version, double click node to find out)Which branches or versions?
zwave-js-ui: 8.6.3.c12b1c6 zwave-js: 10.3.1
Did you change anything?
no
If yes, what did you change?
No response
Did this work before?
Don't know, this is a new device
If yes, where did it work?
No response
Attach Driver Logfile
zwavejs_current.log