new remote control for JBL 7 Series Powered Speakers

[JonathonZ]

Hi,

This is my first post. I've been reading for quite a while.


Recently, as part of a seemingly never ending home theatre upgrade, I purchased a JBL 708P speaker, and was surprised when I found out that it was not remotely controllable by AudioArchitect.

That said, I wanted to control it, so that I could utilize the PEQ functionality, and after all, it had a network port, so surely I thought, it must be controllable.

Well, with a bit digging around, and working with Codex, I was able to put together a fully functioning remote control software which I'm announcing here.
I've released it as a fully prebuilt package and with all the code: https://github.com/JonathonZener/jbl-7-series-remote-control

The software will discover speakers, connect to them, read all relevant parameters and allow changes to be done to all user facing settings. But from the practical comfort of a remote computer instead of with the physical scroll controls on the back of the speaker.

I've organized the controls into a logical fashion (at least logical for me) and limited all the controls so that they just allow valid inputs.

I've also added graphs for all the EQ functions which shows both the factory tuning for low and high as well as user and room EQ and a combo graph for all.
Room delay, AV-Sync delay, gain, input selection and other settings, are all remotely controllable.

Some parameters, such as limiter settings, I've chosen not to expose, as I felt that exposing them could cause more trouble then value add.

There is also a diagnostics section for the software itself, and a kind of parameter browser for all the available options.
I also make available in the repository the scripts I used to explore, in case others want to continue to make things out for whatever reason.

In my work, I found out that the speakers did not seem to support 169.x.x.x style auto-IP that get generated when you direct connect to the speakers, as such, direct connect is not supported unless the speaker has been manually IP'd. That said, DHCP on the speakers works fine, so if you plug them into your network, then you can connect to the speakers without issue.

I tested and developed using a JBL 708P, but I suspect the software will work identically for 705P speakers as well.
Also, a useful note, while factory controlled settings such as PEQ for the low and high drivers are exposed and are tunable, those settings do not hold after a power cycle. I find this to be a feature, as it makes the speaker hard to screw up. That said, all the other settings do hold after a power cycle as expected.

The software has two modes of operation, an instant-update mode where by any changes in the UI are reflected back to the speaker immediately, and a more conservative ask-before-apply mode.

I would be happy to hear your feedback, as well as real world usage examples. If you find any features to be added, please let me know. Same with bugs.

This is also my first project that I felt worth sharing via Github. So let me know if anything seems off about the repository.
Happy to answer any questions around the project.

Take care,
-Jonathon

 

[Edgar]

Wow! Out of interest, how long did it take you to do all this? It looks like a lot of work.

 

[JonathonZ]

That’s what was really incredible about this.

I started work Monday evening and had something bare bones functional in about 3 hours. After that, I put in maybe another two evenings and a bit to get it to this. Around 100 prompts going back and forth with Codex.

So in absolute time, started work Monday night, published it on Wednesday night.

Pretty amazing.

 

[beefkabob]

Where did you get the specs to interface remotely?

 

[JonathonZ]

Where did you get the specs to interface remotely?

The specs to interface remotely really came from the speaker itself.

I had tried standard ports thinking that it would speak like a normal HiQNet device, but when that was found to be unresponsive, with a bit more digging was able to find another port on which the the speaker was listening. From there it was found that the speaker spoke with unencrypted plain text command web sockets. At this point, Codex wrote a crawler to map out the tree of parameters which had been exposed. At first that seemed fragile as the speaker would stop responding, but after some refinement a stable connection was acquired. This was used to map out the tree's nodes and its parameters. Once we had a top level overview, I asked Codex to build the UI, and then refined UI via Codex as well.

To have Codex tell it:
“I didn’t get a single official published spec for the 708P remote-control interface itself. The starting point was Harman/JBL documentation that confirmed the speakers were network-capable and part of the HiQnet ecosystem, including the HiQnet Third Party Programmer’s Guide, the JBL 7 Series owner’s manual, and Harman support docs around HiQnet discovery and control. From there, the actual usable control path was determined by direct inspection of the speaker on the network.

In practice, the important part came from live reverse-engineering: probing the speaker, testing the exposed ports, capturing traffic, and interacting with the device directly. That led to the WebSocket interface on tcp/19273, where I verified the command structure (lc, get, set) and mapped the object tree from the device itself. So the implementation is based on a mix of official Harman/JBL documentation for context plus hands-on protocol discovery against the speaker.

The third-party programmer guide helped with general Harman/HiQnet context, but it did not document the speaker’s WebSocket interface or the specific command structure I ended up using. The tcp/19273 WebSocket control path, the plain-text command grammar, and the object tree were determined empirically by connecting to the speaker and observing how it responded to live requests. So the guide provided ecosystem context; the actual WebSocket protocol details came from direct testing of the device.”

 

[JonathonZ]

The specs to interface remotely really came from the speaker itself.

I had tried standard ports thinking that it would speak like a normal HiQNet device, but when that was found to be unresponsive, with a bit more digging was able to find another port on which the the speaker was listening. From there it was found that the speaker spoke with unencrypted plain text command web sockets. At this point, Codex wrote a crawler to map out the tree of parameters which had been exposed. At first that seemed fragile as the speaker would stop responding, but after some refinement a stable connection was acquired. This was used to map out the tree's nodes and its parameters. Once we had a top level overview, I asked Codex to build the UI, and then refined UI via Codex as well.

To have Codex tell it:
“I didn’t get a single official published spec for the 708P remote-control interface itself. The starting point was Harman/JBL documentation that confirmed the speakers were network-capable and part of the HiQnet ecosystem, including the HiQnet Third Party Programmer’s Guide, the JBL 7 Series owner’s manual, and Harman support docs around HiQnet discovery and control. From there, the actual usable control path was determined by direct inspection of the speaker on the network.

In practice, the important part came from live reverse-engineering: probing the speaker, testing the exposed ports, capturing traffic, and interacting with the device directly. That led to the WebSocket interface on tcp/19273, where I verified the command structure (lc, get, set) and mapped the object tree from the device itself. So the implementation is based on a mix of official Harman/JBL documentation for context plus hands-on protocol discovery against the speaker.

The third-party programmer guide helped with general Harman/HiQnet context, but it did not document the speaker’s WebSocket interface or the specific command structure I ended up using. The tcp/19273 WebSocket control path, the plain-text command grammar, and the object tree were determined empirically by connecting to the speaker and observing how it responded to live requests. So the guide provided ecosystem context; the actual WebSocket protocol details came from direct testing of the device.”

What also gave me good clues, was learning about the existence of Intonato, and examining how it communicated. That was really the tipping point that opened the door.

 

[beefkabob]

Wowza. How much of this would have been something you could have done without Codex?

 

[JonathonZ]

It would have taken months.

Perhaps I’d end up wiser in the end about how web socket APIs work, but truly I just would rather have a tool that I can use, and I find it very satisfying and rewarding to build, tweak and iterate with Codex on something like this. It’s remarkable. You think up a new feature, describe it, and a minute or two later it’s implemented.