HclX / WyzeSensePy

A python script communicating with WyzeSense gateway
MIT License
91 stars 15 forks source link

L command in sample.py not working #5

Open WayneManion opened 4 years ago

WayneManion commented 4 years ago

I'm using sample.py as the basis of a script to publish MQTT messages when connected sensors send their status. I've been playing around with unchanged sample.py over the last couple days, and every time I use the 'L' "L to list" option nothing happens for ~30 seconds and then the script crashes with this output:

  File "./sample.py", line 134, in <module>
    sys.exit(main(docopt(usage)))
  File "./sample.py", line 117, in main
    while HandleCmd():
  File "./sample.py", line 113, in HandleCmd
    handler[1](cmd_and_args[1:])
  File "./sample.py", line 61, in List
    result = ws.List()
  File "/home/wayne/WyzeSensePy/wyzesense/gateway.py", line 497, in List
    sensors = self._GetSensors()
  File "/home/wayne/WyzeSensePy/wyzesense/gateway.py", line 469, in _GetSensors
    self._DoCommand(Packet.GetSensorList(count), cmd_handler, timeout=self._CMD_TIMEOUT * count)
  File "/home/wayne/WyzeSensePy/wyzesense/gateway.py", line 374, in _DoCommand
    raise TimeoutError("_DoCommand")
NameError: global name 'TimeoutError' is not defined
WayneManion commented 4 years ago

I posted about another issue involving a sensor with no MAC ID here. When I saw the missing MAC ID in the output it took me a while to speculate that the missing MAC ID could be causing the crash when trying to list the sensors.

I unpaired the sensor with the missing MAC ID using a doctored version of sample.py. With the memory of that sensor flushed out of Wyze USB dongle, the L/list command worked exactly the way it was supposed to.

muchtall commented 4 years ago

I'm also running into this issue, as well as with Home Assistant as mentioned above.

@WayneManion I took some of your tips in https://github.com/HclX/WyzeSensePy/issues/6#issuecomment-542042312 to troubleshoot my bridge. I found that, at least on my bridge, and assuming there are no packet checksum errors in the communication, the sensor count comes back consistently one higher than the actual number of paired sensors. As a result, I think that the index never reaches the count value and this condition is never met:

            if ctx.index == ctx.count:
                e.set()

Multiply the number of sensors in the count by the timeout value (5), and it times out with an error after that many seconds.

I added this to my gateway.py around line 457 to compensate for what appears to be an invalid sensor count:

    count = resp.Payload[0]

    if count > 0:
        count = count - 1   # Decrease the sensor count by one
    ctx = self.CmdContext(count=count, index=0, sensors=[])
    if count > 0:
        log.debug("%d sensors reported, waiting for each one to report...", count)

        def cmd_handler(pkt, e):

Now it seems to be working reliably.

Also, when I unpaired all my sensors, it appeared that the bridge came back with a count of 0. So, in theory, you should never see a sensor count of 1, only 0, or >=2. At least that was my experience. I might have to test this further to re-verify.

I'm now curious if this is unique to my bridge now that it's had some use. Would the sensor count on a new bridge with also exhibit this issue? If not, perhaps the bridge is storing a sensor count value, and this had somehow gotten out of sync with reality?

dave-vsdevs commented 11 months ago

I'm also running into this issue, as well as with Home Assistant as mentioned above.

@WayneManion I took some of your tips in #6 (comment) to troubleshoot my bridge. I found that, at least on my bridge, and assuming there are no packet checksum errors in the communication, the sensor count comes back consistently one higher than the actual number of paired sensors. As a result, I think that the index never reaches the count value and this condition is never met:

            if ctx.index == ctx.count:
                e.set()

Multiply the number of sensors in the count by the timeout value (5), and it times out with an error after that many seconds.

I added this to my gateway.py around line 457 to compensate for what appears to be an invalid sensor count:

    count = resp.Payload[0]

    if count > 0:
        count = count - 1   # Decrease the sensor count by one
    ctx = self.CmdContext(count=count, index=0, sensors=[])
    if count > 0:
        log.debug("%d sensors reported, waiting for each one to report...", count)

        def cmd_handler(pkt, e):

Now it seems to be working reliably.

Also, when I unpaired all my sensors, it appeared that the bridge came back with a count of 0. So, in theory, you should never see a sensor count of 1, only 0, or >=2. At least that was my experience. I might have to test this further to re-verify.

I'm now curious if this is unique to my bridge now that it's had some use. Would the sensor count on a new bridge with also exhibit this issue? If not, perhaps the bridge is storing a sensor count value, and this had somehow gotten out of sync with reality?

While this is way old I encountered it - I would guess it is due to a failed pairing because everything was working - I did a test pairing to just see if the command worked. And boom the checksum issue....