-
Notifications
You must be signed in to change notification settings - Fork 24
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
protocol between in.touch and controller? #50
Comments
Total guess (based on the other products that can plug into that port like the 'in.stik') is that it's actually a USB connection with a with DIL pinout rather than the normal "consumer" connectors. but that's as far as I've got with investigations - I'll hook up a logic analyser once weather's a bit better |
IIRC correctly, someone on the Home Assistant forums went as far as discovering that RS-485 was being used., but there might be more than just RS485 on the 8 pins of the CO ports. There is an attempt to start a thread over in the Esphome/feature-requests repo: esphome/feature-requests#2893 Most of the bits of digging/reverse engineering people have done have been scattered around. Another issue here had a lot of useful pin probing info: #8 (comment) |
I've only ever sniffed the traffic between the in.touch module and the iOS app, but since I started this project, I have upgraded our spa (and of course I raided the old one for it's control system) so I have an entire piece of hardware to muck around with ... if only I had the time 😂 |
Hi - Have you ever identified the pinout and dumped the traffic between the in.touch receiver and the spa controller itself?
I know your geckolib is based on sniffing the transmitter to internet traffic, but I'd like to work on (likely an ESP32 esphome based) a single box replacement for the in.touch pair that connects directly to Home Assistant
The text was updated successfully, but these errors were encountered: