Been working on a local TCP driver for Roborock vacuums and keep hitting the same wall, and I think it affects more than just this use-case.
Here's what I can confirm from a live authenticated test with a valid local key:
- interfaces.rawSocket connects fine.
- Commands send fine (135 bytes, confirmed in logs).
- The vacuum receives and executes them and I can watch it physically respond. But parse() never fires.
- The driver logs a warning right after the send saying "if parse() fires you will see it below within 3 seconds" and nothing appears.
- The next log entry is 12 seconds later from an unrelated poll.
No parse(), no error, no socketStatus. Just silence.
I'm not sure yet whether this is specific to binary TCP responses or a rawSocket parse() issue. If this is a known limitation I'd love to know, and if not I'd appreciate the team taking a look.
My best theory is that parse() doesn't handle responses arriving in multiple TCP packets reliably, or there's a gap with binary data specifically. But the dev team has better visibility into that than I do.
What I'd love to see is reliable inbound data delivery to parse() for rawSocket connections, or a synchronous send/receive method as an alternative. Basically the httpPost pattern applied to rawSocket.
Flow: Send, wait briefly, get the response back inline.
This isn't just a Roborock problem. Tuya local control hits the same wall. Any device using binary TCP instead of HTTP or MQTT is effectively blocked from true local driver support right now. Fixing this opens up a whole category of devices.
Happy to share the driver code or full diagnostic output if it helps.