Just launched the Myro:Bridge website. Pre-orders begin now and if there aren’t any production issues, we should be shipping orders in a few weeks. The first batch of bridges will be a limited run to see how much interest there is so get your order in now to guarantee shipment!
The goal is to add more support (via firmware updates) as there are requests (via forum). I am also looking to expand support for Control4, Crestron and HAI controllers.
Find out more about Myro:Bridge here.
There’s not much to look at, but don’t let that fool you. This little black box is the Swiss Army Knife of connecting systems together. The platform, based on an ATMEL 1280 microprocessor (Arduino Mega family roots), can be loaded with different firmware that can turn it into a “Russound RNET to Sonos Bridge” or act as a bridge for many other kinds of devices (Apple TV/Windows Media Center, etc). It features an ethernet port for bridging IP based devices as well as two RS232 (prototype of single RS232 version shown above), one for connecting to the master RS232 device (e.g. Russound) and the other for connecting to a slave device (e.g. Matrix Switcher which only has RS232 control). The first of many firmware releases is the USCe-RS which is the Russound to Sono’s bridge (you can find out more about that here). The USCe will be sold under the Myro Control brand and will be soon available for pre-order.
UPDATE: Thanks for the feedback on the name. It’s not set in stone yet and will probably change when it’s officially released. This is a “working” name for now and it may end up being named the “Myro Control Bridge”.
(This product is now available for purchase)
While it was possible to use an Arduino duemilanove (Atmel 328 chipset) for this project (See Part 1), I was really limited due to the 2K of RAM. It was fun trying to optimize code to get things to run in that amount of memory, however, it caused me to not be able to expand on functionality and features. I have upgraded the project to an Arduino MEGA (Atmel 1280 chipset). This platform gives me up to 8K of RAM — which should be more than enough memory (famous last words).
A lot of people have asked me to explain what exactly I’m doing with the Arduino. It’s pretty simple. First, I’m using a RS232 shield (not shown) to capture RS232 commands from the Russound Controller. When a key is pressed on the Russound keypads I read the RS232 data and either ignore or react to the events. Currently, I’m looking for +, -, Next, Previous, Play/Pause, Menu events. I plan on using the Menu button to offer deeper content browsing menus (need to sniff the RS232 or wait for Russound to publish protocol). The + & – buttons will allow to scroll playlists and the rest of the transport buttons are self explanatory.
// Example RNET Next Track Event: F0 0 7D 7 0 0 7F 5 2 1 0 2 1 0 E 0 0 1 7 0 1 2A F7 |
Since the Sonos is a uPnP based system there is no IR or way to traditionally control it. Everything needs to be done via HTTP calls. I’m using an Ethernet Shield to translate the RS232 events to uPnP messages. The biggest challenge has been parsing the huge amounts of VERY VERBOSE SOAP-based notification messages. I parse the data real time, looking for strings that I want to store (things like playstate and metadata).
To make matters worse, Sonos is URL encoding XML data inside of an XML structure. So writing a simple XML parser is not possible. You have to look for things like &lt; for a less-than bracket (<). There were times I wanted to scrap the whole project because of this due to the limited RAM and string utilities — it really makes things a lot harder to deal with.
// Example of nested URL encoded XML: <Event xmlns="urn:schemas-upnp-org:metadata-1- 0/AVT/" xmlns:r="urn:schemas-rinconnetworks-com:metadata-10/"> <InstanceID val="0"><TransportState val="PLAYING"/ ... |
When I get a notification message, I package it up into the RNET protocol and send it back into the Russound controller, which gets displayed on the keypads and automation systems that use that data (like Myro:Home which is connected to a HAI OmniPro II). Since uPnP uses a subscription model, I also need to keep subscription expiration timing so I can renew the subscription. It’s basically a client (outgoing to the Sonos to send subscription requests) and a server (to receive incoming notification events from Sonos). Then I have to deal with all the HTTP issues, like if it fails to renew or I have connection issues, I have to clean up and start the connection process all over again.
This project is now code complete and any new features will be made in a future revision. I plan on creating a custom PCB — any interest?
If you have any questions or comments feel free to post them in the comments section below!
