uzlonewolf

Also, I still plan on deleting all references to `nowait` and changing all functions to either send, or receive, but never both. The `_send_receive()` function is a hot mess and...

> I believe providing a separate `@classmethod create(...)` is a reasonable design choice for users who want to initialize the device without using the `async with` syntax. But where/who is...

> The previous `README` in PR #645 documented it Ah, I never noticed that. Anyway, I hated it, so I rewrote things to eliminate it.

In this particular case I think the old behavior was actually a bug - why should a device being offline throw an exception when the program starts, but dropping offline...

> Is a callback really needed for an async base class? I mean, kinda? Right now there's no way of getting the low-level `TuyaMessage` without them, though I guess I...

I was having issues where if you did something like call status from within the connect callback it was stepping on the toes of whatever caused it to connect in...

Ok, I did it. `nowait` has been removed. All functions either send, or receive, but never both at the same time. Devices are inherently asynchronous. If they decide to send...

Only v3.3/v3.4 devices allow that. v3.5 devices use a global seqno that persists across connections and never matches what you sent and only resets to 0 on power cycle. Ugh.

I don't know what v3.1 devices do offhand, I'd have to check. Sadly v3.5 devices also increment when asynchronous updates are sent, so they're always incrementing. I.e. ```python data =...

Non-persistent sockets are now held open for 100ms to give the user a chance to `.receive()` after a send since those are separate operations now. The socket is closed and...