Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

L command in sample.py not working #5

Open
WayneManion opened this issue Oct 14, 2019 · 3 comments
Open

L command in sample.py not working #5

WayneManion opened this issue Oct 14, 2019 · 3 comments

Comments

@WayneManion
Copy link

WayneManion commented Oct 14, 2019

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
Copy link
Author

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
Copy link

muchtall commented Nov 15, 2019

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?

@dave-vsdevs
Copy link

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....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants