JoyOnWay Spa Control

Feature Requests
203

Hi @home-spa,

I happen to have the same Joyonway P25B85 controller box as you do (find details here), so the alexbde/ha-joyonway integration would be a good fit in general.

I let the AI do some research based on the board's wiring diagrams and here is a breakdown of what might be happening and the options you could consider.

The Physical Interfaces (CN25 vs. CN23/CN24)

Looking at the controller's lid diagram, the P25B85 has two different ports for topside panels:

  • CN25 (Panel): A 3-pin port carrying V+ G SIG (Power, Ground, and a Single-Wire Serial Signal). This is where your PB557 touchpad is connected. It communicates using a single-wire serial TTL protocol.
  • CN23 / CN24 (COM): 4-pin ports carrying V+ B A GND which use differential RS-485 signaling. This is designed for 4-wire touchpads like the PB554 or the WiFi modules.

Because you have the PB557 connected to CN25 (single-wire), the controller board likely defaults to communicating on that interface. As a result, the RS-485 bus on CN23/CN24 remains inactive/silent (which explains why you measure static bias voltages of 1.4V and 1.8V but see no data stream). Typically, Joyonway controllers seem to require an active RS-485 topside panel (like the PB554) to poll the controller on that bus for the transceiver to start broadcasting status frames.

Potential Options

Option 1: Swapping to a PB554 Touchpad (Verified Path)

One way to get the integration working is to replicate the setup with a PB554 color screen touchpad (or another compatible 4-wire RS-485 Joyonway panel):

  1. Disconnect the PB557 from CN25.
  2. Connect the new PB554 touchpad to CN23 using a standard 4-pin cable (carrying V+, B, A, GND).
  3. Connect your RS-485-to-IP bridge (e.g. Elfin EW11 or USR-W610) to CN24 (CN23 and CN24 are wired in parallel on the board, sharing the same bus).
  4. This should allow the PB554 to actively poll the controller over RS-485, activating the bus so that the bridge can receive the broadcast state frames.

Option 2: Hooking up a TTL-to-IP Bridge on CN25 (Experimental & Potentially Dangerous!)

Another possibility might be connecting a TTL-level serial to IP bridge (like the Elfin EW10) directly to the SIG and G pins on CN25. However, there are significant caveats:

  • Undocumented Protocol: The single-wire SIG protocol is completely different from the RS-485 protocol and is not decoded or supported by this integration.
  • Electrical Hazards: Connecting a standard RS-485 bridge (which uses differential signaling) directly to the single-wire TTL SIG pin could damage the microprocessor on the spa controller board due to voltage level mismatches. A dedicated TTL-to-IP adapter would be required.
204

Hello,

First of all, I would like to thank Gaet78 for their outstanding work. I have been using the module since its creation and have watched it evolve to where it is today.

As of now, all features (controls and sensors) are working perfectly, except for the filtration control. The button.spa_filtration has no effect; the filtration does not start when I click on it.

I noticed that the spa starts the filtration on its own every day from 5:30 AM to 7:30 AM, but I haven’t enabled any schedule on the spa’s control panel.

Could you help me understand how the spa currently operates and why the button in Home Assistant has no effect?

Thanks in advance!

205

Hi everyone, and huge thanks to Gaet78 for the amazing work on this integration!

I’d like to add my spa to the list of supported models: I own a JoyOnWay P68B123, sold in Italy under a different (rebranded) name by a local reseller. Attaching a few photos from the reseller’s listing below.

IMG5768
IMG57681920×1440 773 KB

IMG5769
IMG57691920×1440 277 KB

I tried to build a custom component myself following the same approach used for this integration (Alibaba Cloud IoT backend, iotToken, HmacSHA1-signed requests), but I got stuck on the X-Ca-Secret used to sign requests to the gateway — I could see the X-Ca-Key and the iotToken in the traffic capture, but not a usable signing secret (I found some candidate strings in the APK’s dex, like P3VARMboTE52sCoT, appearing near the spa’s nickname P23B23, but couldn’t confirm which one is the actual secret or how it’s derived).

Does anyone (especially @Gaet78) think it would be feasible to extend the existing component to support this model, or has anyone already solved the signing-secret issue for a similar SKU? Happy to share full traffic logs / APK strings if useful.

Thanks in advance!