Entities Failing to Trigger then Instability During Reboots

[beeferific]

This worked very well during the installation. It quickly found the sensors and I was able to change the entity ID and friendly names. It took a few reboots to get it to work again after the entity changes but everything was good for a few days. For the last two nights the sensors have stopped triggering in HA. Last night I noticed that an upgrade was available. The component was installed on HASSIO via HACS. I applied the upgrade and it again took a couple of reboots to get them stable in HA. Tonight the same thing happened and again I noticed an upgrade was available in HACS. I applied the upgrade and rebooted and the entities were unavailable. Another reboot and they were unavailable but some would show up after a state change. Others would not. I applied an update to HA and to HACS and checked the entities after each reboot. It took a few more reboots past the updates to finally get them to a state where they are all seen and triggering state changes.

[SeanPM5]

Having the same issue right now, this behavior only started today after I updated the wyzsense integration to latest version (d4079eb) through HACS. Apparently the only thing that was changed was the readme file, so perhaps it's just a coincidence? Only other change to my setup made today was updating HACS itself to 13.0.

Here is some potential relevant info from my home-assistant.log file.

2019-08-11 22:47:24 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for wyzesense which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you do experience issues with Home Assistant.
2019-08-11 22:47:29 ERROR (Thread-4) [wyzesense.gateway] Invalid packet: b'55aa531937a237373839423938394239383942394434020000016c839b'
2019-08-11 22:47:29 ERROR (Thread-4) [wyzesense.gateway] Mismatched checksum, remote=839B, local=065D
2019-08-11 22:47:39 WARNING (MainThread) [homeassistant.components.binary_sensor] Setup of platform wyzesense is taking over 10 seconds.
2019-08-11 22:47:39 ERROR (MainThread) [homeassistant.components.binary_sensor] Error while setting up platform wyzesense
  File "/config/custom_components/wyzesense/binary_sensor.py", line 76, in setup_platform
    ws = wyzesense.Open(config[CONF_DEVICE], on_event)
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 551, in Open
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 295, in __init__
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 484, in _Start
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 402, in _GetEnr
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 383, in _DoSimpleCommand
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 374, in _DoCommand

Sun Aug 11 2019 22:47:39 GMT-0400 (Eastern Daylight Time)
Error while setting up platform wyzesense
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 149, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
    return fut.result()
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/wyzesense/binary_sensor.py", line 76, in setup_platform
    ws = wyzesense.Open(config[CONF_DEVICE], on_event)
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 551, in Open
    return Dongle(device, event_handler)
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 295, in __init__
    self._Start()
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 484, in _Start
    self.ENR = self._GetEnr([0x30303030] * 4)
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 402, in _GetEnr
    resp = self._DoSimpleCommand(Packet.GetEnr(r_string))
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 383, in _DoSimpleCommand
    self._DoCommand(pkt, cmd_handler, timeout)
  File "/usr/local/lib/python3.7/site-packages/wyzesense/gateway.py", line 374, in _DoCommand
    raise TimeoutError("_DoCommand")
TimeoutError: _DoCommand

I am also on Hassio (HassOS 2.12 & Supervisor 173) / Home Assistant 0.97.1 on a Raspberry Pi 3B+.

[beeferific]

My concern is more about the failure of the sensors to trigger in HA when nothing else was done. If I have to reboot a few times to get the entities to be seen after an initial reboot for an upgrade or any other reason, that's an inconvenience and I don't mind that much, but if it just stops working with nothing causing that on the system, that's a different story.

[kevinvincent]

Hi @beeferific,

Can you enable debug logs for the component (instructions provided at bottom of README)? Whenever that issue occurs can you please post the log?

Also to ensure that it's not a signal strength issue, and if your sensors aren't fixed in place, can you move them closer to the hub and see if it triggers (without restarting or changing anything else). If they work only intermittently please post the rssi attribute from the sensor entity whenever it does as that is a measure of signal strength.

Also please report back with your setup (pi, nuc, etc, Hass OS or regular home assistant, which HA version, what operating system).

[kevinvincent]

Also you mentioned sensors not initially showing but appearing after a state change. That's a built in recovery mechanism if it isn't able to get the list of sensors initially, it'll be added the second it gets a state change from the sensor.

Like you, I'm also more concerned about the sensors stopping working with no change to the system. Someone else had a similar issue that was fixed by moving the hub to a better location but I want to make sure that is the same problem you're facing.

[schettada]

I too have the same issue. When i setup the sense everything worked. But whenever the ha is restarted or the rpi is restarted, the sensors will go missing. Have to restart ha couple of times for it to detect the sensors again. Another thing i noticed is that when the sensors are missing, the wyzesense services are also missing. Looks like its not detecting the sense hub.

[kevinvincent]

@schettada Can you also enable debug logging (from the instructions at the bottom of the readme) and submit another issue? The logs are super super helpful for me to track down whats happening.

[schettada]

Yes. Have it enabled since my comment. Let me see what happens.

Sent from my iPhone

On Aug 12, 2019, at 18:00, Kevin V. notifications@github.com<mailto:notifications@github.com> wrote:

@schettadahttps://github.com/schettada Can you also enable debug logging (from the instructions at the bottom of the readme) and submit another issue? The logs are super super helpful for me to track down whats happening.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/kevinvincent/ha-wyzesense/issues/8?email_source=notifications&email_token=AD3EREDI35KIKJCZ2JWPXEDQEH2RZA5CNFSM4IK5QMH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4EE6DI#issuecomment-520638221, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AD3EREA4TIVLGRVFT4NIVJ3QEH2RZANCNFSM4IK5QMHQ.

[beeferific]

Thanks Kevin. I've enabled debug logging. Everything has been fine today. There was even an HA update available and your component was showing an upgrade available in HACS. I applied your upgrade before rebooting for the logging and the sensors came back right away this time.

I don't think signal strength is a major factor. I have 7 motion detectors and 5 contact sensors. The closest is only a couple of feet from the bridge. The lowest signal strength is 50 and the others range in the high 50s, 60s, or 70s. When I see issues it seems to be more bridge related as it effects all of the sensors and as someone else mentioned the scan and remove services aren't available either. I did mention that last night all of the sensors shows as unavailable and that only a few came back when triggered but I failed to mention that they didn't change state again. So they went from unavailable to "on" and stayed that way never returning to clear. Even the contact sensors would trigger when the door was opened but would not clear when the door was closed. So I don't think it was because the others were out of range. All of them had some type of trouble.

I believe the recovery mechanism worked tonight as after the reboot two motion detectors showed as being triggered even though they were clear until I triggered them and then the state returned to normal. It was very different from last night's behavior. In fact, tonight I do have a couple of sensors in an "assumed state" since I didn't go and trigger them but I'm completely confident they would communicate normally based on the behavior of the others.

I'll update this if I see the issue again with the logs. In the meantime I'm running hassio 0.97.1 on a pi 3.

Great work on this component and I appreciate the time your taking to make it better.

[mediacowboy]

Can you try this?

1. Go to services

2. Select wyzesense.remove and past the following json command and change the mac address. You will need to add a line for each sensor by putting a comma after each sensor until you reach the last one.

   { "mac" : "777A4656", "mac" : "777A4657", "mac" : "777A4658" }

3. Reboot home assistant

4. Add each sensor back one at a time by going to services

5. Select wyzesense.scan and push the button on the sensor

Reason I ask is this is sounding like the same issue I had when I moved my hub from the camera to my computer.

[beeferific]

Sure. I can try that if the issue persists. I really think it's a problem with the interaction between the bridge and HA, though, based on the behavior. When there's an issue with the sensors showing up the scan and remove services usually aren't available either.

[kevinvincent]

Great thank you for all that information and for enabling that debug logging. Everything that you're describing (including the services not appearing) occur when the component fails to handshake with the hub and then bails out of the setup process. I released a change about 10 hours ago that will retry that handshake up to 10 times which hopefully will solve these issues. For some reason all the reports of this I've seen occur on a pi. For example @mediacowboy and I both run it on more powerful machines, and he may need to confirm but I have personally not been able to reproduce this and similar issues. Maybe its the pi's shared usb bus with ethernet?. Hopefully the retrying will help too. I really wanna get this sorted out.

EDIT: The retrying fixed the issue for another person here. Hopefully its the same for you.

Please let me know whenever the issue appears again, the debug log is invaluable as it has a byte by byte replay of the communication between the component and the hub.

[kevinvincent]

@SeanPM5 I opened a new issue (the one that appears above) for yours as it looks like some progress was made on this. Your's may be different but we can continue to debug this there.

[beeferific]

Thanks. I think you’re right about the pi and you’re retries may have already fixed things. I had to reboot again last night because of a different issue and the bridge and sensors came back right away again. It certainly appears more robust at boot time.

I’ll let you know if they drop out again with no system changes.

[kevinvincent]

Alright sounds good, FYI the retries won't kick in until you have updated via HACS. Just in case you haven't done that yet.

[kevinvincent]

Closing this out, feel free to reopen and/or comment below if it shows up again.

[beeferific]

That's fair. Things have been looking good. Thanks for the help.

[beeferific]

Unfortunately, it looks like it happened again with no changes and no pending updates available (except for one for HACS but I don't think that should effect your component). Log entries stop at 9:19am this morning. Do you want to take a look or should I try MediaCowboy's suggestion of removing then adding the sensors? Is there a way to share the logs with you without posting them here?

It took two reboots to get them to trigger in HA. They did not show as unavailable, however.

[kevinvincent]

Thats unfortunate :( You can email the log as a file to the address in my github profile if you'd like. I definitely want to take a look at it.

Just to be clear, the sensors always come back as available on restart, they just don't trigger correct?

[beeferific]

During tonight's first reboot, yes, the sensors came back as available but were not triggering. The second reboot is when they started triggering.

[kevinvincent]

Okay sounds good. I will definitely take a look at the logs you sent over. Also, I will luckily have access to a rpi 3b+ this weekend with the component running so I'll be able to try to replicate the issue there.

[kevinvincent]

So looking into the logs, I only see one restart after which the sensors come back and trigger successfully. I'm guessing this is after the second of the 2 restarts you mentioned?

When the sensors fail to trigger again, can you take a copy of the log as soon as you can and prior to restarting it? I think the log file only shows everything since the last restart. Thanks for your patience.

[beeferific]

That's interesting. I can't say I've come across that behavior before but I went it looked it up HA does reset the log file after a reboot. I'll have to capture it before rebooting next time. Maybe you will find something interesting trying to replicate the issue on a rpi before that happens.

[kevinvincent]

Yeah, hopefully I'll be able to replicate it. So it sounds like everything works fine for a couple days and then just randomly all sensors will stop triggering right? No restarts in between?

[beeferific]

Yes, it's been running fine since last night so maybe it'll stop around a similar time tomorrow. Maybe there's a memory leak of something that hits a critical point. I haven't done anything since last night. I'm just letting it run to see how long it lasts.

[TomBrandt]

I installed this a few days ago and see the same problem. I was wondering if there is a way to add a watch dog to restart wyze sense gateway. If communication to sensors drops. I also can provide log when this happens to me. I do this for nodeRed. Last freeze reported door open when I closed it. then no other info or reports in log.

2019-08-17 17:29:04 INFO (Thread-3) [wyzesense.gateway] LOG: time=2019-08-17T17:28:59.390000, data=b'a2373738413732433501010047' 2019-08-17 17:29:04 DEBUG (Thread-3) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '778A72C5', 'state': 1, 'device_class': 'door', 'timestamp': '2019-08-17T17:28:59.394000', 'rssi': -62, 'battery_level': 100} 2019-08-17 17:29:04 DEBUG (Thread-3) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '778A72C5', 'state': 1, 'device_class': 'door', 'timestamp': '2019-08-17T17:28:59.394000', 'rssi': -62, 'battery_level': 100}

[kevinvincent]

Just to be clear, you’re describing the situation where the sensors will just stop triggering after a certain amount of time, correct? Not sensors not showing up on restart?

If so, a log right after this happens (and before a restart) would be absolutely invaluable. Please turn on debugging as mentioned in the readme and let me know when it occurs again.

On Sat, Aug 17, 2019 at 5:03 PM TomBrandt notifications@github.com wrote:

I installed this a few days ago and see the same problem. I was wondering if there is a way to add a watch dog to restart wyze sense gateway. If communication to sensors drops. I also can provide log when this happens to me. I do this for nodeRed.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kevinvincent/ha-wyzesense/issues/8?email_source=notifications&email_token=AAKJUZPT3GUGKY65B4KGA33QFCGVLA5CNFSM4IK5QMH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QVTUY#issuecomment-522279379, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKJUZJCTM6WTUYDMNGB5BLQFCGVLANCNFSM4IK5QMHQ .

[kevinvincent]

Unfortunately there’s no way to detect a disconnection from the sensor as there isn’t a “connection” per say. However if I take a look at the logs and the component loses a connection with the usb dongle it’s straightforward to re-establish that. A log would go a long way towards figuring that out though. I have a suspicion that the usb device unmounts and remounts. Also are you on a pi by any chance?

On Sat, Aug 17, 2019 at 9:00 PM Kevin Vincent kevinsundar@gmail.com wrote:

Just to be clear, you’re describing the situation where the sensors will just stop triggering after a certain amount of time, correct? Not sensors not showing up on restart?

If so, a log right after this happens (and before a restart) would be absolutely invaluable. Please turn on debugging as mentioned in the readme and let me know when it occurs again.

On Sat, Aug 17, 2019 at 5:03 PM TomBrandt notifications@github.com wrote:

I installed this a few days ago and see the same problem. I was wondering if there is a way to add a watch dog to restart wyze sense gateway. If communication to sensors drops. I also can provide log when this happens to me. I do this for nodeRed.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/kevinvincent/ha-wyzesense/issues/8?email_source=notifications&email_token=AAKJUZPT3GUGKY65B4KGA33QFCGVLA5CNFSM4IK5QMH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4QVTUY#issuecomment-522279379, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKJUZJCTM6WTUYDMNGB5BLQFCGVLANCNFSM4IK5QMHQ .

[kevinvincent]

@TomBrandt On my computer now, I noticed you updated with the log. I'll try updating it to reconnect to the hub if it detects a disconnection. Probably should've had that in the first place. Unfortunately, there isn't a log message if it disconnects right now.

[TomBrandt]

Yes to your question. I'll get the both debug going again and watch for the issue and try and capture the exact time it stops triggering. And Thanks for looking.

Intel Nuc J5005, everything up to date version wise running windows 10/ vmbox ubuntu

[TomBrandt]

OK here my log stopped triggering at time stamp 21:34:29. Again I noticed it reported the state twice. no more triggered events home-assistant.log

[kevinvincent]

Alright thanks, I've noticed the double state reporting a couple of times. That's straight from the dongle but that's not too big of a deal. I'm gonna add some additional logging to check if the USB dongle is disconnecting on its end (instead of the component starting the disconnect). The logs are very helpful, thank you.

[viper71285]

I have a issue similar to what another person experienced. My Door sensor state shows "open" or "on" and never changes to off. This sensor is setup in Node-Red to turn on a light. I opened the door and the light came on (Tested it twice). However the strange part is, when the door closed it never updated in Home assistant (Still shows as on or open). However the automation fired and ran. Looked in Home assistant logbook, and there is nothing regarding that sensor.

[kevinvincent]

Alright after taking a look at those logs I've released a code change. It should help a bit with startup issues and it also adds more logging so I can identify usb communication issues. Please update your component and leave debug logging on.

[shauder]

EDIT: I think my device changed ID's and now its working.

I tried the update to .4 and I am getting long restart times and most components get the 10 seconds or longer to setup warning. Moving back to .3 I get an error setting up component but no longer any of the other issues.

Traceback (most recent call last):
  File "/usr/src/app/homeassistant/helpers/entity_platform.py", line 149, in _async_setup_platform
    await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT)
  File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for
    return fut.result()
  File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/config/custom_components/wyzesense/binary_sensor.py", line 82, in setup_platform
    ws = beginConn()
  File "</usr/local/lib/python3.7/site-packages/decorator.py:decorator-gen-2>", line 2, in beginConn
  File "/usr/local/lib/python3.7/site-packages/retry/api.py", line 74, in retry_decorator
    logger)
  File "/usr/local/lib/python3.7/site-packages/retry/api.py", line 33, in __retry_internal
    return f()
  File "/config/custom_components/wyzesense/binary_sensor.py", line 80, in beginConn
    return Open(config[CONF_DEVICE], on_event)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 561, in Open
    return Dongle(device, event_handler)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 297, in __init__
    self._Start()
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 492, in _Start
    self._Inquiry()
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 398, in _Inquiry
    resp = self._DoSimpleCommand(Packet.Inquiry())
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 393, in _DoSimpleCommand
    self._DoCommand(pkt, cmd_handler, timeout)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 379, in _DoCommand
    self._SendPacket(pkt)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 331, in _SendPacket
    pkt.Send(self.__fd)
  File "/config/custom_components/wyzesense/wyzesense_custom.py", line 106, in Send
    ss = os.write(fd, pkt)
BrokenPipeError: [Errno 32] Broken pipe

[kevinvincent]

Yeah [Errno 32] Broken pipe sounds like wrong usb device. If you unplug and plug it back in at all the system will assign it another device id. It kinda sucks but thats just how linux mounts them by default.

Does it work on .4 too or are you still on .3?

[shauder]

It is strange since I never removed it but nonetheless it is working now. I am on 0.0.4.

[beeferific]

Hi Kevin,

I thought I'd provide an update that doesn't contain any bad news for once. I've been running with no issues for five days now. I've just been letting things run without any reboots to see if I the sensors would lose connection but they've remained stable. I don't know if it's dumb luck or not.

The only thing that's really changed was that I removed a couple of unused components to clean things up. They were installed but were not running. They included Portainer and Mosquito MQTT Broker. I don't know if that will be helpful in troubleshooting or not. I am running version 0.0.3 of your component as you released 0.0.4 in the middle of this successful run.

I will have to reboot soon but hopefully things will go well again after.

[TomBrandt]

Hi Kevin log since .04 installed. FYI I removed everything and reinstalled after your change. Hope it helps. Just an interesting point. The pyecobee error went away after uninstalling Wyze.sense. and came back when I installed wyze.sense again. home-assistant.log

[kevinvincent]

@TomBrandt Looks like 3 or 4 reports came in of that same issue after .4. I will investigate tonight and hopefully have a fix.

[beeferific]

Hi Kevin,

For the latest drop in communication I found this log snippet which is something I think I've seen before. It seems to suggest a system wide error with Python but after the error it seems to be only the Wyze component that doesn't recover.

2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa531d190000016d12d13634a23737374246414230021e63000100582e3f070e' 2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Received: b'55aa531d190000016d12d13634a23737374246414230021e63000100582e3f070e' 2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] <=== Received: Packet: Cmd=5319, Payload=b'0000016d12d13634a23737374246414230021e63000100582e3f' 2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] ===> Sending: Packet: Cmd=53FF, Payload=ACK(5319) 2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Sending: b'aa555319ff026a' 2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.binary_sensor] {'available': True, 'mac': '777BFAB0', 'state': 0, 'device_class': 'motion', 'timestamp': '2019-09-08T17:39:23.828000', 'rssi': -63, 'battery_level': 99} 2019-09-08 17:39:49 DEBUG (Thread-3) [custom_components.wyzesense.wyzesense_custom] Trying to parse: b'55aa53190000011212d136bf0ea2373737453138453002002a5806e2' 2019-09-08 17:39:52 INFO (MainThread) [engineio.client] Sending packet PING data None 2019-09-08 17:39:52 INFO (MainThread) [engineio.client] Received packet PONG data None 2019-09-08 17:39:54 WARNING (MainThread) [homeassistant.helpers.entity] Update of camera.front_door is taking over 10 seconds 2019-09-08 17:39:55 ERROR (SyncWorker_14) [ring_doorbell] Error!! ('Connection aborted.', OSError("(104, 'ECONNRESET')")) 2019-09-08 17:39:55 ERROR (MainThread) [homeassistant.helpers.entity] Update for binary_sensor.ring_front_door_motion fails Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 603, in urlopen chunked=chunked) File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 387, in _make_request six.raise_from(e, None) File "", line 2, in raise_from File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 383, in _make_request httplib_response = conn.getresponse() File "/usr/local/lib/python3.7/http/client.py", line 1336, in getresponse response.begin() File "/usr/local/lib/python3.7/http/client.py", line 306, in begin version, status, reason = self._read_status() File "/usr/local/lib/python3.7/http/client.py", line 267, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") File "/usr/local/lib/python3.7/socket.py", line 589, in readinto return self._sock.recv_into(b) File "/usr/local/lib/python3.7/site-packages/urllib3/contrib/pyopenssl.py", line 309, in recv_into raise SocketError(str(e)) OSError: (104, 'ECONNRESET')

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 449, in send timeout=timeout File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 641, in urlopen _stacktrace=sys.exc_info()[2]) File "/usr/local/lib/python3.7/site-packages/urllib3/util/retry.py", line 368, in increment raise six.reraise(type(error), error, _stacktrace) File "/usr/local/lib/python3.7/site-packages/urllib3/packages/six.py", line 685, in reraise raise value.with_traceback(tb) File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 603, in urlopen chunked=chunked) File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 387, in _make_request six.raise_from(e, None) File "", line 2, in raise_from File "/usr/local/lib/python3.7/site-packages/urllib3/connectionpool.py", line 383, in _make_request httplib_response = conn.getresponse() File "/usr/local/lib/python3.7/http/client.py", line 1336, in getresponse response.begin() File "/usr/local/lib/python3.7/http/client.py", line 306, in begin version, status, reason = self._read_status() File "/usr/local/lib/python3.7/http/client.py", line 267, in _read_status line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1") File "/usr/local/lib/python3.7/socket.py", line 589, in readinto return self._sock.recv_into(b) File "/usr/local/lib/python3.7/site-packages/urllib3/contrib/pyopenssl.py", line 309, in recv_into raise SocketError(str(e)) urllib3.exceptions.ProtocolError: ('Connection aborted.', OSError("(104, 'ECONNRESET')"))

During handling of the above exception, another exception occurred:

Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 261, in async_update_ha_state await self.async_device_update() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 441, in async_device_update await self.hass.async_add_executor_job(self.update) File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, self.kwargs) File "/usr/src/homeassistant/homeassistant/components/ring/binary_sensor.py", line 116, in update self._data.check_alerts() File "/usr/local/lib/python3.7/site-packages/ring_doorbell/doorbot.py", line 80, in check_alerts self.update() File "/usr/local/lib/python3.7/site-packages/ring_doorbell/generic.py", line 54, in update self._get_attrs() File "/usr/local/lib/python3.7/site-packages/ring_doorbell/generic.py", line 86, in _get_attrs lst = self._ring.query(url).get(self.family) File "/usr/local/lib/python3.7/site-packages/ring_doorbell/init.py", line 190, in query req = self.session.get((url), params=urlencode(params)) File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 546, in get return self.request('GET', url, kwargs) File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 533, in request resp = self.send(prep, send_kwargs) File "/usr/local/lib/python3.7/site-packages/requests/sessions.py", line 646, in send r = adapter.send(request, kwargs) File "/usr/local/lib/python3.7/site-packages/requests/adapters.py", line 498, in send raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', OSError("(104, 'ECONNRESET')"))

[jwozny]

Hey guys, I was debugging this same issue with my 40+ sensors, specifically "Invalid Packet" error. I had to go to each missing entity and physically change the state (open a window) for it to add it back in to the system. After updating 2 entities I would need to reboot home assistant because it would lock up the wyze integration and not update states anymore. I came to the conclusion that one of the sensors had a critically low battery because it wouldn't update like the others. I replaced the battery and the rest of the missing updated just fine without reboots. It's been working without issue so far but it's something to look into for those that are having the same issue.

I suspect that the sensor had a low enough battery that it was still able to attempt to transmit on the radio but malformed the signal as it died mid-transmission. This in turn causes the "Invalid Packet" error in the integration and cause a fatal error in the script, but I'm just spit balling here.

[turbo4door]

Having a similar issue where every time I restart my HA instance (0.103.5 running on an rpi 4) I lose my sensors. They immediately come back every time upon an actual state change. Unfortunately, that isn't of much use in my case. On reboot they show as "Entity not available" until I manually open/close or introduce motion to the motion sensor. Running the latest version installed from HACS(0.0.6). Also, as others mentioned, when they are unavailable, there is no wyzesense services available either. Happy to provide logs if necessary.

Here's one example in my log that occurs after reboot:

Fri Jan 10 2020 15:03:28 GMT-0500 (Eastern Standard Time) Error while setting up platform wyzesense Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 150, in _async_setup_platform await asyncio.wait_for(asyncio.shield(task), SLOW_SETUP_MAX_WAIT) File "/usr/local/lib/python3.7/asyncio/tasks.py", line 442, in wait_for return fut.result() File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, *self.kwargs) File "/config/custom_components/wyzesense/binary_sensor.py", line 94, in setup_platform result = ws.List() File "/config/custom_components/wyzesense/wyzesense_custom.py", line 507, in List sensors = self._GetSensors() File "/config/custom_components/wyzesense/wyzesense_custom.py", line 479, in _GetSensors self._DoCommand(Packet.GetSensorList(count), cmd_handler, timeout=self._CMD_TIMEOUT count) File "/config/custom_components/wyzesense/wyzesense_custom.py", line 384, in _DoCommand raise TimeoutError("_DoCommand") TimeoutError: _DoCommand

[kevinvincent]

If your error contains result = ws.List() as @turbo4door posted above, v0.0.7 should fix it. Please update via HACS or use the master branch. There's still some other instability issues that need to be addressed but v0.0.7 fixes that common issue.

[robkiller26]

I am having the same issue as SeanPM5 on the second post. Same log and error any luck fixing the issue?

[finnzz]

I just set up my HomeAssistant and Wyze sense component through HAC a few days ago. I am also experiencing stability issues where the sensors stop responding after a day or two.

I am running Hassio in Virtualbox on Win10. I have been reading up on all I could find between here and the Hassio forum. I noticed a lot of people having issues are using virtualbox, but not all. Maybe this is a coincidence.

What I haven't seen anyone talk about are the power requirements of the Wyze hub. How many Amps does the Wyze cam put out, and how many Amps does the hub require? Generally on computers, USB2 ports put out 0.5A and USB3 0.9A. My second observation is that many people are using USB extension cords. Many cables use thin copper lines that limit the amperage. And longer cables may be prone to voltage drops.

All this is to ask, is anyone concerned that the Wyze stability issues may be related power instability?

I will see if I can dig up a powered USB hub to see if it makes any difference.

[robkiller26]

My wayze was stable with no issues for a while. Once i updated to .7 and added more sensors both happened around the same time it started the same thing as post 2. Pi4 hub in port directly no cable added.

[finnzz]

Just checking the specs on the Pi4. All 4 ports output 1.2A combined. Meaning if you have other devices connected, the Wyze bridge may been getting less than 1.2A.

Again I am just wondering about power stability relating to Wyze bridge stability. I have seen a few people mention that their sensors tended to stop responding when there was a lot of activity in a short period time. More sensors would be one way of increasing activity at the bridge.

I did find my powered USB hub, and have the Wyze bridge plugged directly into it. I'll report back in a few days to see if I notice a change in stability.

[robkiller26]

Please let me know what you find. I dont have anything else plugged into the usb ports but with higher activity could be to much power required. If that is all it is that is easy to fix.

[finnzz]

Using a powered USB hub did not fix the '[Errno 110] Operation timed out' issue. But I think there are multiple problems occurring. Occasionally, not even restarting Hassio (or shutting down the virtualbox host) would get the Wyze bridge working again, and the only solution was to unplug and plug the bridge back in. I did not experience any of these instances with the powered USB hub, so this may still be worth trying if that is something you are experiencing.

VirtualBox Users

Most of the people that I have seen reporting the '[Errno 110] Operation timed out' are using Virtualbox. I switched the USB controller type in Virtualbox from eHCI (USB2) to xHCI (USB3). I'm now going on 5 days without 'Errno 110'. From scouring the Virtualbox forums it appears that eHCI is the most unstable controller in Virtualbox. It doesn't matter if your host computer doesn't have USB3 ports, you can still use the Virtualbox USB3 controller. For reference I'm using Virtualbox 6 on Windows 10 with Home Assistant 0.105.5

Automatic Capture of Wyze Bridge after host Reboot

This may be helpful to others who are Running Virtualbox on a Windows host. If the Wyze Bridge is already plugged into your computer when you start Virtualbox, Virtualbox cannot capture the Wyze Bridge, and you have to unplug / and plug the bridge back in. This is annoying after you reboot Windows for instance.

To automate this: I have 1) Task Scheduler starts Hassio Virtualbox @ 3min after startup 2) Task Scheduler starts Bat file @ 3min and 10sec after startup

The bat file will disable the Wyze Bridge in Windows, and enable it, allowing Virtualbox to capture it while it's booting up Hassio.

Bat File: @echo [off] devcon disable "HID\VID_1A86&PID_E024" timeout /t 2 devcon enable "HID\VID_1A86&PID_E024"

Devcon.exe is a Microsoft tool to disable/enable devices from the command line, just as if you were to go into the device manage and disable/enable it. It's part of the Windows Driver kit: https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon

You can either install the whole kit, or google how to extract it from the cab, because the devcon.exe itself is >100kb. I used this link (post #5) as a guide: https://www.tenforums.com/drivers-hardware/77425-win10-switches-disabled-devices-back.html

Then put it where you want (i put it in windows/system32) and add it to your %path%. Just make sure you are getting a version that matches BOTH your Windows version (Win10, Win8 etc) and processor (32 or 64bit).

The Wyze Bridge shows up on my machine as HID\VID_1A86&PID_E024 with a bunch more numbers following it. HID\VID_1A86&PID_E024 with the wildcard at the end worked for me even when changing what USB port I used. Run 'devcon hwids ' to list all the devices on your machine with their complete hardware names. The Bridge is categorized as a HID or Human interface device. I found this post useful: https://stackoverflow.com/questions/47530182/enabling-disabling-the-device-in-windows-10-from-command-line

Lastly, I the reason for the 3min delay at startup was because timing is important. If I told Virtualbox to start immediately, it would startup slowly because of all the other Windows processes that were loading, and the bat file would disable/enable the Bridge before Virtualbox had loaded and was ready to capture it. So I wait 3min, letting Windows fully boot, then schedule Virtualbox to launch, which now starts reliably loading in a few seconds, followed by the bat file to disable/and enable the bridge. The bridge is captured by virtualbox while Hassio is still booting, and the Wyze bridge is up and running once Hassio has finished loading.