ISSUE: Code Slot Stuck in delete create loop #59
Assignees
Labels
automation/scripts
Related to automation/scripts
bug
Something isn't working
sensors
Related to sensor(s)
Comments
|
Code slot in question is code_slot_3. Which is currently sent Likely the sync automation firing too quickly? |
firstof9
added
bug
|
also @firstof9 Should I create a separate issue about the |
|
Ah shoot, I know why that's not working, should be |
i'm not following. is there some option I need to add or boolean to toggle? |
|
Edit: I've adjusted the Wiki |
Ah, okay i've updated my file, then tried a docker restart and a ha restart Click to show yaml```yaml config/packages/lock-manager# cat lock_manager_additional.yaml input_boolean: allow_automation_execution: name: 'Allow Automation' initial: offbinary_sensor: automation: |
|
@firstof9 looking at what you changed, and the event page [https://www.home-assistant.io/docs/z-wave/events/], should it be |
|
No network ready isn't the right one, I see you have sleeping nodes, let me compile this with a full list. |
|
I've updated the wiki again. |
got it, looks like it's working. Looks like it's triggering on all 3 of those events? (just wanting to double check my understanding) |
|
Correct, it's been a while since I used |
|
is there anything I can do to help on this? |
|
@firstof9 is the sensor being updated? |
|
@nweave03 Try putting this sensor.py file into your |
Okay there are some differences here. Mostly seems like the calls to zwave aren't happening anymore. I am still seeing that weird create/delete loop. And I captured a crash from notifications. I have also tried to disable all of the codes to get them to clear. The one thing that I can say is that zwave traffic tells me, and manual attempts to confirm also show that no actual code sets go out on disable. Click to show logLogs |
|
i was restarting HA and found a bunch of crashes Click to show logLogs |
|
okay, so I have tried to disable all the codes, see below Then I check the logs and zwave logs, it appears to be stuck in the loop, but for all of them Click to expand logsLogs |
|
it also happens with the codes being enabled now. I had to shut off the |
|
Did the PIN status ever go The debug messages will always show up because the sensor's refreshing the data, these messages don't mean the code are being updated/cleared constantly. That only happens when the automation(s) fire. |
|
It always says |
|
That's very odd, once the |
is there some way I can add logs or something to help you two see why it thinks it needs to fire? |
|
I'll see what I can conjure up in the morning. |
|
Very strange, we see in the screen shot that the sensor is reporting it empty. So it should flip the binary_sensor to 'on'. Can you verify that the |
|
yup, it is Click to see screenshot
I was also looking at how Click to see yaml pin_synched_frontdoor2_1:
friendly_name: 'PIN synchronized with lock'
value_template: >
{% set lock = 'sensor.frontdoor2_code_slot_1' %}
{% set local = 'input_text.frontdoor2_pin_1' %}
{% set status = 'binary_sensor.active_frontdoor2_1' %}
{% set lockpin = states(lock).strip() %}
{% set localpin = states(local).strip() %}
{% set pinstatus = states(status) %}
{% if lockpin == "0000" %}
{% set lockpin = "" %}
{% endif %}
{% if pinstatus == 'on' %}
{% set correct = localpin == lockpin %}
{% else %}
{% set correct = lockpin == "" %}
{% endif %}
{{ correct }}and it also depends on the Click to see screenshot
and Click to see screenshot
|
|
okay, so despite the fact that it appears to be empty by the higher level, if I look at the details I see Click to see screenshot
is it incorrectly storing this previous value somewhere? Why doesn't it overwrite with the empty as a result of the lock code queries? |
|
in fact, all of the code slots show something weird. They are all Click to show screenshot
|
|
aha! its not empty string its |
|
You can see it here: |
|
nope, just needed to strip the found this on stackoverflow about it: https://stackoverflow.com/questions/38883476/how-to-remove-those-x00-x00 |
|
i'll try your method as well |
|
i think i recognize this on older binary protocols. Since they must have a certain size in there, say 10 bytes, if there is only a need for 4, some protocols specify to null out the rest of the bytes. I think in this case, they just null padded it out to 6, since these locks support code sizes of up to 6, but that is a guess. |
|
unfortunately your method crashed @firstof9 Click to see logsI was having issues with this as well. it seems to want it to be an Click to see python code elif ZWAVE_NETWORK in self._hass.data:
if data[ATTR_NODE_ID] is not None:
network = self._hass.data[ZWAVE_NETWORK]
lock_values = (
network.nodes[data[ATTR_NODE_ID]]
.get_values(class_id=COMMAND_CLASS_USER_CODE)
.values()
)
for value in lock_values:
_LOGGER.debug(
"DEBUG: code_slot_%s value: %s",
str(value.index),
str(value.data),
)
# do not update if the code contains *s
code = value.data
if "*" in str(value.data):
_LOGGER.debug("DEBUG: Ignoring code slot with * in value.")
code = self._invalid_code(value.index)
# Build data from entities
enabled_bool = (
f"input_boolean.enabled_{self._lockname}_{value.index}"
)
enabled = self._hass.states.get(enabled_bool)
if not enabled:
_LOGGER.debug(
"DEBUG: Utilizing Zwave clear_usercode work around code."
)
code = ""
code = code.strip().strip('\x00')
sensor_name = f"code_slot_{value.index}"
data[sensor_name] = code
self._data = data
_LOGGER.debug(
"DEBUG: setting data to %s",
str(self._data)
) |
|
which is really odd, because it says it is using the |
|
which kinda begs a separate question of why it concludes nothing is enabled and doesn't override the previous settings of code since the logs say it is utilied on every single code slot that isn't there. ah, its always false for antyhing that exists, i'm not sure that is working like you intended: Click to see logs _LOGGER.debug("DEBUG: enabled is %s (%s) %s",enabled, type(enabled), not enabled) |
|
maybe something like if isinstance(code, str):
code = code.strip().strip('\x00')works better since I'm not sure how many locks report codes as strings vs integers. |
crap you're right, I forgot the .state on it. I've pushed another update, and typecast/converted the value.data to a string to fix that issue too. |
|
got a crash Click for logs |
|
Doh, forgot the |
|
okay, so that isn't crashing, but it isn't working either. the Click for screenshot
I can confirm that the strip method I outlined above does work with the |
|
I missed a 2nd none type and pushed another update a few seconds ago, sorry. |
|
okay, tested again, still the same, Click to see screenshot
Logs show that instead of an empty string it is returning the value of the Click to see logs |
|
my guess is that you meant if enabled.state == "off":instead of if not enabled.state:on line 120 probably also on line 169 |
|
I'm not sure why Click to see logs |
|
also if I do that, then it will believe a lock code is set for an enabled code, even when it is not because of the workarounds. It thinks it is synchronized and correct despite there being no code set at all (see Click to see screenshot
Click to see logs |
|
I think there is a more fundamental issue here. without the ability to distinguish between the following:
There really isn't a way to fix this on these locks. I have noticed multiple times it concludes that a code that is present is somehow not, and a code that is not present somehow is. These always revolve around this case. It can't work for these locks because those three cases appear identical. I've been able to get some success with the following Click to see python code # pull codes for zwave
elif ZWAVE_NETWORK in self._hass.data:
if data[ATTR_NODE_ID] is not None:
network = self._hass.data[ZWAVE_NETWORK]
lock_values = (
network.nodes[data[ATTR_NODE_ID]]
.get_values(class_id=COMMAND_CLASS_USER_CODE)
.values()
)
for value in lock_values:
_LOGGER.debug(
"DEBUG: code_slot_%s value: %s",
str(value.index),
str(value.data),
)
# do not update if the code contains *s
code = value.data
if "*" in str(value.data):
_LOGGER.debug("DEBUG: Ignoring code slot with * in value.")
code = self._invalid_code(value.index)
# Build data from entities
enabled_bool = (
f"input_boolean.enabled_{self._lockname}_{value.index}"
)
enabled = self._hass.states.get(enabled_bool)
_LOGGER.debug("DEBUG: code is now %s", str(code))
if isinstance(code, str):
code = code.strip().strip('\x00')
sensor_name = f"code_slot_{value.index}"
data[sensor_name] = code
self._data = data
_LOGGER.debug(
"DEBUG: data is %s",
str(self._data)
) def _invalid_code(self, code_slot):
""" Return the PIN slot value as we are unable to read the slot value
from the lock. """
_LOGGER.debug("Work around code in use.")
# This is a fail safe and should not be needing to return ""
data = ""
# Build data from entities
enabled_bool = f"input_boolean.enabled_{self._lockname}_{code_slot}"
enabled = self._hass.states.get(enabled_bool)
pin_data = f"input_text.{self._lockname}_pin_{code_slot}"
pin = self._hass.states.get(pin_data)
# If slot is enabled return the PIN
if enabled is not None:
if pin.state.isnumeric():
_LOGGER.debug("Utilizing BE469 work around code.")
data = pin.state
else:
_LOGGER.debug("Utilizing FE599 work around code.")
data = ""
return dataClick to see yaml - conditions:
- condition: template
value_template: "{{ is_state('binary_sensor.active_frontdoor2_1','off') }}"
sequence:
- choose:
- conditions: >
{{ False }}
# this comment preserves formating
sequence:
- service: ozw.clear_usercode
data_template:
entity_id: lock.detached_garage_door_lock_locked
code_slot: >-
{{ 1 }}
- service: system_log.write
data_template:
level: warning
logger: homeassistant
message: "ozw.clear_usercode from binary_sensor.active_frontdoor2_1 being off"
# #Debug for flaky clear
# - service: persistent_notification.create
# data_template:
# title: Slot 1
# message: 'ozw clear_usercode called'
- conditions: >
{{ False == False }}
# this comment preserves formating
sequence:
- service: lock.clear_usercode
data_template:
node_id: >-
{{ state_attr('lock.detached_garage_door_lock_locked','node_id') }}
code_slot: >-
{{ 1 }}
- service: system_log.write
data_template:
level: warning
logger: homeassistant
message: "lock.clear_usercode from binary_sensor.active_frontdoor2_1 being off"Then I need to increase the time it takes for the With all of that, the code doesn't attempt to do the wrong thing, or get into weird loops. However, the general unreliability of these locks still means that its a 50/50 shot whether the operation actually succeeds thanks to: Click to see zwave logsWhich appears to be as stale and unverified as it warns because a simple I'd like to decrease the |
It's already set to 1 second refreshes. See line 50.
Codes are updated independently of set/clear code operations. I've pushed a new sensor.py which should strip the |
|
Oh, then that isn't working, just check any of my longer log statements, they are still 30 seconds apart. Also tried your current fix and it crashes Click to see logsAlso, I have tried a few things to see if I can get a Click to see yaml - service: lock.set_usercode
data_template:
node_id: >-
{{ state_attr('lock.detached_garage_door_lock_locked','node_id') }}
code_slot: >-
{{ 1 }}
usercode: >-
{{ "\x00\x00\x00\x00\x00\x00" }} - service: lock.set_usercode
data_template:
node_id: >-
{{ state_attr('lock.detached_garage_door_lock_locked','node_id') }}
code_slot: >-
{{ 1 }}
usercode: >-
{{ "\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\n" }}It looks like openzwave is attempting to fix this. I will be moving on to them, or possibly new locks, but from here, I don't see how a solution is possible, basic operations cannot be counted on to work when they claim they have, and that has definitely resulted in the system thinking user codes are present that are not and codes that are not present, thought to have been deleted, but definitely still work. |
Ya I'm trying to deal with these as best I can rather than just say "well you're outta luck, use openzwave beta" I've made another push that makes sure the code gets placed into a string. Should resolve the error you were getting. |
okay after spending a day messing around with all the various docker containers necessary in order to get openzwave beta working, I can confirm what I suspect you already know. This works perfectly with openzwave. In doing this I have lost the ability to test your new code though >< I'm sorry about that. I think I'm done on this one, if you need anything else from me, please let me know. Lastly, thanks a ton @firstof9 for working with me on this. I realize now that you likely knew where this would end up, but it did help me to see for myself all these details and how they mess with each other. Thanks man. |
|
No problem. At least you're on track for the future. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Lock-Manager is deleting and recreating a lock code in a loop. Not sure why.
Environment (please complete the following information):
Click to show log
Logs
Additional context
see discussion on bug #55
The text was updated successfully, but these errors were encountered: