I would be interested in implementing an S-Link interface in espHome. S-LINK or CTRL-A(II) is a two-wire bidirectional bus system mostly used in audio equipment (Sony), where many devices can be connected together.
This link provides some details of the S-Link protocol.
My understanding is that to implement something similar in espHome external component(s) will be needed. Potentially two external components: one to send commands to the to the audio devices and one to receive information from the audio devices.
To send the commands to the audio devices I envision a component that behaves like espHome Remote Transmitted where the service can be called from Home Assistant passing the Hex code to transmit.
To receive the information from the audio devices I think two approaches are possible: either a text sensors that passes on to Home Assistant the Hex code received (to then be processed via templates) or individual sensors (device status, disk #, track number etc.).
My coding skills are quite limited and I’m looking for some guidance on what would be the easiest path to implement this.
First of all I’m looking for some advice if it would be best to do the whole implementation for the S-Link protocol in espHome (i.e. connect the S-Link bus directly to the esp8266 running espHOME with a circuit similar to the ones proposed by Robho here) or use an aurduino to run a slightly modified version of the sketch created by Robho and interface this with the esp8266 running espHome via UART. Which approach would you recommend?
In the documentation available regarding external components it is mentioned that the loop is called every 16ms and that the external component should not block for more than 10ms. Now in the S-Link protocol each message has a precursor of 3,000 micro seconds and each bit is 1,800 micro seconds if it is a 1 or 1,200 micro seconds if it is a 0. Now each command is 16 to 32 bits and the messages from the device can be up to 48 bit long. Therefore commands and messages on the S-Link protocol that are longer then 16ms.
Would this be a no-go for trying to implement this directly in an espHome external component and it is therefore better to implement this on a separate Arduino and relay the commands and messaged with the espHome esp8266 over UART?
Have you implemented an S-Link transmitter using ESPHome yet?
I have not looked into S-Link for some time. And many will say that you can accomplish everything using a common off the shelf IR Blaster + ESPHome + Home Assistant. However, if your Sony A/V equipment is hidden in a cabinet, IR may not work as well.
IIRC, S-Link is just the Sony IR remote serial data with out the ~40KHz modulation. And, again IIRC, the upstream data is nothing more then a long wake up pulse. For example, I press DVD eject on a remote and the DVD player opens up. Maybe the DVD player saw the IR. Or maybe the TV saw the IR and sent the command down stream over the S-Link to the DVD player. Regardless, once I push the DVD try close, the DVD player sends a long wake up pulse up stream over the S-Link which wakes up the A/V Receiver and switches toward the DVD’s video and sound. The long wake up pulse continues up stream to the TV which does the same.
Further, I think S-Link is a lot like RS488. The data line is held high at both ends with a pull up resistor and an open collector transistor shorts the data path to ground when sending a message.
I’m wondering if the easiest thing to do here is to simply use an off the shelf IR Blaster but re-write the ESPHome code to just send out the S-Link pulses rather than to use those pulses to modulate an ~40KHz carrier.
Sorry for delay in getting back to you. Yes, I somehow mange to connect Home Assistant to a Sony CD Player via ESPHome. The solution I came up with is not elegant at all but it works, at least for my needs.
And many will say that you can accomplish everything using a common off the shelf IR Blaster + ESPHome + Home Assistant. However, if your Sony A/V equipment is hidden in a cabinet, IR may not work as well.
I also agree that an IR Blaster is not the solution. In addition to IR needing line of sight as you mention, with an IR Blaster you can only transmit to the Sony device while S-Link is a bi directional protocol.
Creating a ESPHome component for S-Link was above my level. S-Link is a slow serial protocol and I’m therefore unsure if ESPHome could even directly send and receive S-Link messages, as for example a command can take up to 44ms to send and a response can take significantly more to receive. See here for details of how the S-Link protocol works. To my understanding a ESPHome component should not hold up the execution of the main loop for more than 20ms.
The solution I came up with is to use an Arduino Pro Mini as interface between the S-Link bus and the ESP8266 running ESPHome. The ESP8266 and the Arduino Pro Mini communicate via UART. When sending a command the ESP8266 just send the Hex Address+Command to the Arduino via UART. When a message is received over S-Link the Arduino decodes it and send it in Hex format to the ESPHome over UART.
Below is the link to what I implemented for a CDP-CX225. I believe this could be easily modified to work with other S-Link devices (see list of know commands and responses)
I know this is somewhat resurrecting an old thread, but I also wanted a Control-A1 / S-Link integration - although I went a bit further and wanted the CD and MiniDisc players to appear as media players in Home Assistant.
an ESPHome component that implements the one-wire bus for Control-A1 in an approach similar to the IR proxy. It uses the ESP32 RMT peripheral for decoding received data, so is ESP32-only. When bus data is received, it puts an event onto the Home Assistant event bus. It also registers a service to transmit data onto the bus (which should also get read by the RMT as a local loopback).
A Home Assistant integration (with associated HACS custom repository at the same address). When it sees an event from the ESPHome component, it creates a bus device with a sensor tracking the last received message. Additionally, if a CD or MD player is seen on the bus, it creates a device relating to that player, including a media_player (and some other sensors). Play/pause/skip on the media_player sends the expected commands to the device.
A read of the TOC of CDs and MDs is triggered under some circumstances (still not perfectly triggered). Based on the TOC data, an external metadata lookup at MusicBrainz can be done (there’s a switch per device, defaulting to on, for the external metadata lookup). From my limited testing, the number of tracks and individual track lengths is good enough to match CD releases and populate metadata for the media player.
It’s worth acknowledging that both the ESPHome component and HA integration have largely been coded by AI agents, although they were prompted to align with ESPHome and Home Assistant coding conventions and standards, and I’ve done a limited amount of code review.