Because USB is not a multi-tap network. It's a point-to-point between host and peripheral, or host and host pretending to be a peripheral (OTG mode).
That USB dongle was bodged on to the USB port D+/D- pins going to the tablet's SOC. If you then connect a PC to that port, you have two hosts (SOC & PC), and one peripheral on the same pair of data lines. No bueno.
I can't believe the bodge job inside that tablet. It looks like the prototype became the final product.
The "PoE"[0] board was also a USB device wired onto the pins for the single USB port on the board. USB is not a multidrop bus - if you directly wire two devices to a single USB port it will not work, you need an active USB hub.
[0]quotes because looking at that FTDI chip though my bet is it's actually serial over Cat5...
Cheers, I am looking at this for our system but it is still working so I didn't want to mess it up, but was planning for the eventuality... I've been reverse engineering the app, so your post has cleared a few things up for me :)
The plan is to get rid of the tablet and put a Amazon echo hub or HA on a tablet that directly controls the aircon in the future
Feel free to reach out, a few people from this thread seem to be doing similar things, including looking at the protocols involved and interop requirements. It would be good to combine efforts if you're that way inclined.
As far as HA integration goes, there's already an adapter available that uses the HTTP API that the tablet exposes. This of course still requires a working tablet though.
The next step for an open solution would be to either write a replacement for the tablet API that talks directly to the control box using RS485 (which will have the benefit of allowing existing integrations to work as-is), or perhaps even ignore the original API and start from scratch with something custom built for HA integration.
The original HTTP API that the tablet exposes is relatively straightforward, but it also commits quite a few sins against HTTP, such as mutating state on GET requests (making CSRF type attacks trivial). This makes a like-for-like replacement a little less palatable in my eyes.
The other tricky thing is that the tablet code is where a lot of the state is kept and the smarts of the system are located. Zone names and config, schedules, temperature sensor pairing, ... replacing the tablet API completely like-for-like might be tricky, but doing just enough to support HA integration (maybe submitting a patch to the existing integration to support the new custom API) is probably a much easier task. There should be no need to rebuild features that HA already has such as scheduling etc.
