HydraBridge ESP32: Local Control for Hydra Lights Without Mobius App

[Branzol]

I wanted to share a project I've been working on for a few weeks that I feel others can benefit from. My background is in PLCs, embedded systems, and software engineering. My tanks run on a CODESYS PLC, and I’ve always been a big proponent of automation systems that don’t require cloud services, proprietary apps, or vendor lock-in.

Over the years, aquarium equipment manufacturers have made this harder and harder. There are fewer devices today with open API access or simple 0-10V control than there were 15 years ago.

That is why I started HydraBridge ESP32.

My goal was to let myself, and eventually others, integrate Hydra 64HD and Hydra 32HD lights into their own automation systems, or use the software as a fully independent local controller without needing to rely on a phone app.

HydraBridge ESP32 currently supports:

• Local BLE control of AquaIllumination Hydra lights
• Automatic light discovery
• MQTT integration
• Home Assistant auto-discovery
• RS485 / Modbus RTU support for PLC integration
• Local web UI
• Reusable lighting profiles
• Scheduled lighting control
• Sunrise and sunset ramping
• Multi-light group support
• OTA firmware updates with rollback
• First-boot WiFi setup portal
• Fully local operation with no cloud dependency

Reverse engineering for this project was done using clean-room methods for interoperability, consistent with 17 U.S.C. § 1201(f).

The repo is here:

https://github.com/roygabriel/hydrabridge-esp32

In the future, I would like to extend support to more Mobius-based devices. To do that, I’ll either need access to the hardware or Bluetooth communication captures from users who own those devices.

The bigger goal is simple: give reefers more control over the equipment they already own, and less reliance on cloud based systems.

 

[Gumbies R Us]

This is pretty cool!

 

[Branzol]

This is pretty cool!

Thanks! I put it together for my own use so my hydra lights could integrate with my CODESYS PLC. But I figure this might be helpful to others as well, so I decided to not keep it locked away.

I also have the Trident testers working with my PLC and no Apex controller. I’m hesitant to release that one right now until I see if there is any legal pushback on this one first.

 

[vandy]

What a great project! Was there any lingo in their terms of service that prevents this type of reverse engineering?

 

[Branzol]

What a great project! Was there any lingo in their terms of service that prevents this type of reverse engineering?

As long as I’m operating within the scope of 17 U.S.C. § 1201(f), and I’m not distributing any proprietary source code, encryption keys, or copyrighted firmware, there is generally not much they can do from a legal standpoint. They could attempt DMCA takedowns, but those can be challenged if the project is based on lawful reverse engineering and interoperability. I’ve been through similar situations with other projects in the past I’ve been part of.

I also reached out to the FULU Foundation ahead of time since they tend to support interoperability and reverse-engineering projects like this.

As for Neptune, they’ve largely left the AquaBus protocol library alone. From what I’ve read, there was an effort to add support for the Trident, but Neptune reportedly objected to that portion of the project. The rest of the AquaBus work appears to have remained available.

 

[Tyguy]

very very cool, I’ve always been someone who wants what I buy to be like and allows me to do what I want and your project is just that. I also think it would be very cool if you could integrate things like the Apex brain to connect with like a Nero 3 or any aquailinarion device without needing those expensive modules

 

[commod0re]

This is exactly what I need for my project. I was going to do this reverse engineering myself and you beat me to it. Thanks! I will contribute back to your project since I have several different mobius devices already

 

[13rodo]

I wanted to share a project I've been working on for a few weeks that I feel others can benefit from. My background is in PLCs, embedded systems, and software engineering. My tanks run on a CODESYS PLC, and I’ve always been a big proponent of automation systems that don’t require cloud services, proprietary apps, or vendor lock-in.

Over the years, aquarium equipment manufacturers have made this harder and harder. There are fewer devices today with open API access or simple 0-10V control than there were 15 years ago.

That is why I started HydraBridge ESP32.

My goal was to let myself, and eventually others, integrate Hydra 64HD and Hydra 32HD lights into their own automation systems, or use the software as a fully independent local controller without needing to rely on a phone app.

HydraBridge ESP32 currently supports:

• Local BLE control of AquaIllumination Hydra lights
• Automatic light discovery
• MQTT integration
• Home Assistant auto-discovery
• RS485 / Modbus RTU support for PLC integration
• Local web UI
• Reusable lighting profiles
• Scheduled lighting control
• Sunrise and sunset ramping
• Multi-light group support
• OTA firmware updates with rollback
• First-boot WiFi setup portal
• Fully local operation with no cloud dependency

Reverse engineering for this project was done using clean-room methods for interoperability, consistent with 17 U.S.C. § 1201(f).

The repo is here:

https://github.com/roygabriel/hydrabridge-esp32

In the future, I would like to extend support to more Mobius-based devices. To do that, I’ll either need access to the hardware or Bluetooth communication captures from users who own those devices.

The bigger goal is simple: give reefers more control over the equipment they already own, and less reliance on cloud based systems.

Regarding adding other devices, have you seen this thread: https://www.reef2reef.com/threads/c...led-vortech-pump-using-0-10v-and-ble.814921/?

 

[Branzol]

very very cool, I’ve always been someone who wants what I buy to be like and allows me to do what I want and your project is just that. I also think it would be very cool if you could integrate things like the Apex brain to connect with like a Nero 3 or any aquailinarion device without needing those expensive modules

It should work with any Mobius-compatible device. Right now I’m adding support for the AI Orbit 2 and Orbit 4 since I picked those up for my frag tank.

The biggest hurdle isn’t understanding the protocol itself. At this point, I mainly need Bluetooth captures from people using the devices with the Mobius app so I can confirm pairing procedures, device identifiers, and any model-specific behavior.

If anyone has Mobius-based equipment and would like to help, I can put together a guide explaining how to collect the captures I need. The hardware required is just a Bluetooth sniffer that’s available on Amazon for around $20.

 

[Branzol]

I wanted to share a project I've been working on for a few weeks that I feel others can benefit from. My background is in PLCs, embedded systems, and software engineering. My tanks run on a CODESYS PLC, and I’ve always been a big proponent of automation systems that don’t require cloud services, proprietary apps, or vendor lock-in.

Over the years, aquarium equipment manufacturers have made this harder and harder. There are fewer devices today with open API access or simple 0-10V control than there were 15 years ago.

That is why I started HydraBridge ESP32.

My goal was to let myself, and eventually others, integrate Hydra 64HD and Hydra 32HD lights into their own automation systems, or use the software as a fully independent local controller without needing to rely on a phone app.

HydraBridge ESP32 currently supports:

• Local BLE control of AquaIllumination Hydra lights
• Automatic light discovery
• MQTT integration
• Home Assistant auto-discovery
• RS485 / Modbus RTU support for PLC integration
• Local web UI
• Reusable lighting profiles
• Scheduled lighting control
• Sunrise and sunset ramping
• Multi-light group support
• OTA firmware updates with rollback
• First-boot WiFi setup portal
• Fully local operation with no cloud dependency

Reverse engineering for this project was done using clean-room methods for interoperability, consistent with 17 U.S.C. § 1201(f).

The repo is here:

https://github.com/roygabriel/hydrabridge-esp32

In the future, I would like to extend support to more Mobius-based devices. To do that, I’ll either need access to the hardware or Bluetooth communication captures from users who own those devices.

The bigger goal is simple: give reefers more control over the equipment they already own, and less reliance on cloud based systems.

Regarding adding other devices, have you seen this thread: https://www.reef2reef.com/threads/c...led-vortech-pump-using-0-10v-and-ble.814921/?

No I’ve not I’ll have to take a look. Thank you.

 

[Branzol]

Last night, after working on the new 260-gallon tank build, I was able to add support for the AI Orbit 2 and Orbit 4 powerheads. I’ll be testing everything on actual pumps tonight before pushing it out in a release.

I also have a friend sending me a spare Nero powerhead, so I should be able to add Nero support and have it included in a release sometime next week if testing goes well.

Progress has been moving pretty quickly, and it’s been nice seeing more pieces of the Mobius ecosystem come together under a single bridge for my PLC to control via RS-485.

One feature I’ve been brainstorming is a high-availability (HA) setup where you can run a primary and backup ESP32. If one goes down for any reason, the other would automatically take over. With how inexpensive ESP32s are, I think it would be a great and affordable insurance policy.

 

[13rodo]

Last night, after working on the new 260-gallon tank build, I was able to add support for the AI Orbit 2 and Orbit 4 powerheads. I’ll be testing everything on actual pumps tonight before pushing it out in a release.

I also have a friend sending me a spare Nero powerhead, so I should be able to add Nero support and have it included in a release sometime next week if testing goes well.

Progress has been moving pretty quickly, and it’s been nice seeing more pieces of the Mobius ecosystem come together under a single bridge for my PLC to control via RS-485.

One feature I’ve been brainstorming is a high-availability (HA) setup where you can run a primary and backup ESP32. If one goes down for any reason, the other would automatically take over. With how inexpensive ESP32s are, I think it would be a great and affordable insurance policy.

Redundancy is always a great idea!

My big gripe with the current ecosystems of reef automation is none of the ecosystems can do everything / play nice. Apex doesn't have 12V motor control and limits Mobius features. Hydros doesn't support Mobius. I'm currently planning my reef automation and have seriously been toying with the idea of trying to produce an open standard for reef device command & control + telemetry + HW interfaces. I've also been toying with the idea of trying to put together my own open source reef controller (mainly as an excuse to teach myself Rust... I write a bunch of C).

 

[Branzol]

Redundancy is always a great idea!

My big gripe with the current ecosystems of reef automation is none of the ecosystems can do everything / play nice. Apex doesn't have 12V motor control and limits Mobius features. Hydros doesn't support Mobius. I'm currently planning my reef automation and have seriously been toying with the idea of trying to produce an open standard for reef device command & control + telemetry + HW interfaces. I've also been toying with the idea of trying to put together my own open source reef controller (mainly as an excuse to teach myself Rust... I write a bunch of C).

I completely agree. One of the main reasons I decided to roll my own system was that I didn't want to be locked into a closed ecosystem after spending thousands of dollars on automation hardware. If a company goes under, changes direction, or abandons a product line, you're left with a significant investment tied to a platform you don't control.

I also don't like how fragmented the current market is. Every ecosystem has strengths and weaknesses, but none of them really play well with one another. In my opinion, the first company that embraces an open ecosystem and allows users to integrate whatever equipment they want is going to do very well.

Another issue for me was the heavy reliance on power bars for electrical control. In my fish room, I have a dedicated subpanel and critical equipment such as return pumps are on their own breakers. If a breaker trips, it only affects a small portion of the system. With the commercial controller ecosystems, I would have needed multiple power bars just to match the electrical segregation I already have.

My original plan was to build a completely open-source controller around an STM32H7. Instead, I had a spare PLC and a 17-inch Spectra touchscreen HMI sitting on a shelf after being removed from a decommissioned project at work. Since those were already available, I decided to use them for the mission-critical control logic and save myself a lot of development time.

Around that, I've built STM32-based remote I/O nodes that handle Atlas Scientific UART/I2C dosing pumps and Atlas lab-grade probes. Those nodes communicate back to the PLC over RS-485. I originally considered MQTT, but ultimately chose RS-485 because it's simple, reliable, and doesn't require another service running in the background that could potentially become a failure point.

Once the new 260-gallon system is up and stable, I may revisit the idea of a fully opensource stm32 based controller and migrate everything over. At that point I'd probably build in controller redundancy from the beginning so there isn't a single point of failure.

 

[13rodo]

I also don't like how fragmented the current market is. Every ecosystem has strengths and weaknesses, but none of them really play well with one another. In my opinion, the first company that embraces an open ecosystem and allows users to integrate whatever equipment they want is going to do very well.

Preach! I started putting together a spreadsheet to match features I wanted with various controller configurations and it was super frustrating. I didn't want to pick equipment around the controller, which made it even worse. I think that's part of the calculus with these companies though; if an open standard is used then the best-of-breed will win so they use vendor lock strategies of yesteryear. That's why I had toyed with the idea of trying to put together an open standard. I figured if someone else did the work it'd be easier for a big player to stomach. If equipment manufacturers adopt an open standard, the controllers will have to support it.

Another issue for me was the heavy reliance on power bars for electrical control. In my fish room, I have a dedicated subpanel and critical equipment such as return pumps are on their own breakers. If a breaker trips, it only affects a small portion of the system. With the commercial controller ecosystems, I would have needed multiple power bars just to match the electrical segregation I already have.

Ya I'm not a big fan in general of control by pulling the plug, but what do I know?

If I actually start working on something I'll let you know. Otherwise, I might just grab some data for you once I get these XR15 & MP40s setup (working on setting up a 75g at the moment). I assume there are enough folks in this hobby with technical backgrounds that could make something really cool happen. For me it's just been work craziness that has been holding me back from really diving in; by the end of the day my brain is mush lol.

 

[Branzol]

If I actually start working on something I'll let you know. Otherwise, I might just grab some data for you once I get these XR15 & MP40s setup (working on setting up a 75g at the moment). I assume there are enough folks in this hobby with technical backgrounds that could make something really cool happen. For me it's just been work craziness that has been holding me back from really diving in; by the end of the day my brain is mush lol.

When I get a chance I'll upload the work I've done with the atlas lab grade probes, and dosing pumps. If you do decide to do something in the future you can most likely use portions of that code or use it as a reference.

I started putting together a spreadsheet to match features I wanted with various controller configurations and it was super frustrating.

I did the same thing with a spreadsheet, honestly I probably spent the same amount on this system as I would have if I had gone the commercial route, as atlas probes are not inexpensive by any means. If I add my labor cost in it's far more expensive. I feel far more confident going on vacation with my current setup versus a commercial controller.

Also once I have a chance to ensure nothing isn't in compliance with 1201, I'll release my trident controller bridge.

 

[13rodo]

I did the same thing with a spreadsheet, honestly I probably spent the same amount on this system as I would have if I had gone the commercial route, as atlas probes are not inexpensive by any means. If I add my labor cost in it's far more expensive. I feel far more confident going on vacation with my current setup versus a commercial controller.

Funny enough I started my search looking at Atlas Scientific thinking it'd be a fun, cost-effective way to add some automation. I started the spreadsheet after I realized it wasn't cost-effective. Then after the spreadsheet frustration I kind of put it all down for a bit. Wholeheartedly agree about trusting systems that I can review more than blackboxes :)

Edit: My original plan was to use a little zynq-7000 board I have lying around.

 

[Branzol]

I did the same thing with a spreadsheet, honestly I probably spent the same amount on this system as I would have if I had gone the commercial route, as atlas probes are not inexpensive by any means. If I add my labor cost in it's far more expensive. I feel far more confident going on vacation with my current setup versus a commercial controller.

You’re braver than I am using an FPGA for this. I’ve worked with them a bit in the past, but only for signal-processing applications.

I got the Orbit pumps tested and working last night. I’m going to let them run in an empty tank for a few days to make sure there aren’t any unexpected issues before I call them fully validated.

I also put together a plan for redundancy. The idea is to have two ESP32s communicating over CAN bus and continuously synchronizing the full configuration, including registered devices, schedules, profiles, and other settings.

If the backup unit stops receiving heartbeats from the primary, it automatically takes over and broadcasts an “I’m the primary now” message on the CAN bus. That way, when the original primary comes back online, it knows to remain in standby mode and avoid communicating with devices. This prevents both controllers from trying to manage the same equipment at the same time.

I’ll probably spend the next few evenings working through that design and getting a prototype running. I’m still trying to come up with the best pattern where you don’t have to login to two devices on your network that doesn’t feel hacky.

 

[13rodo]

The zynq was really more about what I had lying around lol. It has a couple ARM cores plus the IO options through the PS and the FPGA are pretty much endless. It's really easy to build embedded Linux for it too (Xilinx, now AMD, keep really good Yocto layers). It was either that or an Nvidia Jetson

I ended up buying the Arduino version of the ESP32 to tinker with :-D

 

[Dark_Reefs]

Sweet! This aligns with what I’m currently working on.

-Dark Reefs