Closed IIAIronWolf closed 3 months ago
Configuration.yaml entry:
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
# Uncomment this if you are using SSL/TLS, running in Docker container, etc.
http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
# Text to speech
tts:
- platform: google_translate
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
binary_sensor:
- platform: wyzesense
device: auto
alarm_control_panel:
- platform: manual
code_arm_required: false
code: !secret alarm_code
arming_time: 0
armed_home:
arming_time: 0
trigger_time: 120
armed_away:
delay_time: 30 #Seconds to put in PIN when returning home
trigger_time: 120
arming_time: 60
homekit:
- filter:
include_domains:
- alarm_control_panel
entity_config:
alarm_control_panel.ha_alarm:
code: !secret alarm_code
logger:
default: warn
logs:
homeassistant.components.homekit: debug
pyhap: debug
custom_components.wyzesense: debug
wyzesense.gateway: debug
custom_components.wyzeapi: debug
More logs:
Logger: homeassistant
Source: custom_components/wyzesense/wyzesense_custom.py:388
First occurred: 9:50:12 PM (1 occurrences)
Last logged: 9:50:12 PM
Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/wyzesense/binary_sensor.py", line 116, in setup_platform
ws = beginConn()
File "<decorator-gen-2>", line 2, in beginConn
File "/usr/local/lib/python3.8/site-packages/retry/api.py", line 73, in retry_decorator
return __retry_internal(partial(f, *args, **kwargs), exceptions, tries, delay, max_delay, backoff, jitter,
File "/usr/local/lib/python3.8/site-packages/retry/api.py", line 33, in __retry_internal
return f()
File "/config/custom_components/wyzesense/binary_sensor.py", line 114, in beginConn
return Open(config[CONF_DEVICE], on_event)
File "/config/custom_components/wyzesense/wyzesense_custom.py", line 565, in Open
return Dongle(device, event_handler)
File "/config/custom_components/wyzesense/wyzesense_custom.py", line 299, in __init__
self._Start()
File "/config/custom_components/wyzesense/wyzesense_custom.py", line 505, in _Start
self._FinishAuth()
File "/config/custom_components/wyzesense/wyzesense_custom.py", line 489, in _FinishAuth
resp = self._DoSimpleCommand(Packet.FinishAuth())
File "/config/custom_components/wyzesense/wyzesense_custom.py", line 397, in _DoSimpleCommand
self._DoCommand(pkt, cmd_handler, timeout)
File "/config/custom_components/wyzesense/wyzesense_custom.py", line 388, in _DoCommand
raise TimeoutError("_DoCommand")
TimeoutError: _DoCommand
Just for transparency, I deleted the comment, I understand his frustration, but the the few comments made on this repository have not been anything but inflamatory/unhelpful.
I imagine there will be need to be some code change, and I assume the reason this happened was because this wyzesense integration and HomeKit Bridge do not play well together; However, I fixed the issue by completely removing the wyzesense integration after settings HomeKit to not autostart. I then re-added the wyzesense integration and then went to HomeKit and told it to exclude the Wyze sensors. Then I set HomeKit back to auto start and everything appears to be working again.
I also noticed an issue with the documentation for this, so I will submit a pull request.
What kind of HA setup are you running? Docker/VM/Supervised?
I ask because it's failing at the initialization of the sensor. It's long been on my mental list of improvements to adjust the logic around the initialization to check if it's already active if it fails to initialize, but I've had limited time to work on it. My thinking behind this is I've seen cases where when HA is restarted, we don't shutdown the connection to the dongle properly, this results in the LED staying blue but the component fails to initialize on restart until the system is rebooted or the dongle is unplugged/replugged.
So that question has always confused me a bit, and I know the clarification is probably somewhere in the HA documentation; but, I am running Home Assistant on a Raspberry Pi using host_os HassOS 4.13 and installation_type Home Assistant OS. Home Assistant version is 0.115.0b10, latest beta as of today.
I too noticed that the LED does stay blue and that very well could have been the only issue: I didn't unplug and replug. Might have saved a slight headache of reinstalling and only needed to do the above instead. But my solution thankfully did get it all back up.
What I wonder about now, though, is: Why did it fail right after I successfully got HomeKit running? Is there an issue with having the wyzesense integration be in charge of the door contacts, while also allowing HomeKit to push the wyzsense devices to the Home app?
I'm guessing in your case, HA is getting reloaded in the background and the Wyzesense component doesn't get properly unloaded. You shouldn't 'need' to unplug and re-plug the adapter. I'm not a python expert and haven't had a ton of luck reproducing issues like this, will keep trying to see if I can find a good solution.
Well let me know if I can be of any assistance. I've done some programming for per-engineering courses, but I'm definitely still a novice. Haha
I'm thinking we can make some improvement around here: https://github.com/kevinvincent/ha-wyzesense/blob/1e193496f656fc871cd14cabb8d1c33a21fc1620/custom_components/wyzesense/wyzesense_custom.py#L492
If we can adjust the initialization (start function) to not instantly fail on a failed auth/init command and have it, for example, call the dongle get mac command to see if the dongle is alive would probably be a good secondary test before throwing an exception and failing the setup.
Is this in the normal startup code path as well? I've had issues with reboots of my system (ProxMox/HassIO VM) alternatively working and not working for many months. I've suspected some initialization logic may be to blame since it fixes itself randomly on reboots.
Is this in the normal startup code path as well? I've had issues with reboots of my system (ProxMox/HassIO VM) alternatively working and not working for many months. I've suspected some initialization logic may be to blame since it fixes itself randomly on reboots.
It is the normal startup path. I've noticed on my system (HassIO VM running in ESXi) that I'll have to unplug the dongle before vmware will even recognize it, been thinking about trying a wyze firmware update on it (through one of the cameras), but haven't wanted to break my setup. But that only happens after a power cycle of my vm host.
It is the normal startup path. I've noticed on my system (HassIO VM running in ESXi) that I'll have to unplug the dongle before vmware will even recognize it, been thinking about trying a wyze firmware update on it (through one of the cameras), but haven't wanted to break my setup. But that only happens after a power cycle of my vm host.
Oh wow. I didn't even realize the hub was being updated itself from the Wyze cam's. I assumed the camera just received new control software to use with the hubs. I might try updating mine since I only have 2 door contacts at the moment. Fingers crossed I don't break it again. Haha
Now that I think about it, a recent Wyze update did mention fixing the battery level reporting, so it might be really cool to update the hub.
I got my HomeKit integration working today, thanks to the newest beta release of Home Assistant Core, 0.115.0b6. My sensors were working on this beta until I setup HomeKit. I am now getting the following errors in my logs and my contact sensors, which control my Custom Alarm, do not work: