Mars Hydro API reverse engineered

[SmokeyCoder]

Hi Firstly I hope this is the right place for such a thread automation kinda equates with grow room design/set up

Secondly if this is against form rules just say so and I won't post on this topic any further.

Mars Hydro supply affordable tent equipment, the stuff is okay I guess for entry level but it is lacking in a number of areas, the standout one to me is the app and integrations like home assistants are non existent and they refuse to publish their API...

The the crux of this post is to let others know I have reverse engineered their app to reveal their entire API, endpoints, schemas etc. and share my findings and this is where perhaps the forum moderators might object to me going any further.

What I have uncovered:

• Authorization
• REST endpoints
• MQTT endpoint - this is how the controller communicates with their back end think of it as poor mans web sockets
• Object shapes for all the devices they support that I own (only thing I am missing is their smart power strips - but now I and anyone could build their own)

What have I done with this information

• python CLI to interface with the backend to change controller settings and retrieve historical data among other things
• MCP To give my AI agent the ability to take tent readings and make changes (don't worry I have guard rails in place)
• iOS app to replace the clunky Mars hydro app
  • fixing a lot of the little quirks, bugs and behaviors I didn't like
  • create a dash board view
  • Build my own features such as VPD targeting

What I plan to do:

• Alexa skill
• raspberry pi
  • allow push notifications, send reports via email etc
  • more automation control such as integrating with IFTTT and TUA devices such as smart power boards

Possibilities are endless really, and the work I have done I think is important to share with the community.

But let's be clear Mars/LG LED Solutions stipulate in their terms and conditions they prohibit reverse engineering of their app and don't publish their api. Using the information could potentially get your account black listed (although it would be impossible for them to distinguish their app vs any other entity making requests - I used a junk account while probing their api to keep my logs clean).

Keep in mind this isn't a turn key solution for anyone unless you are a developer or someone with some coding experience the information will be lost on you.

If there is interest from the community and no objection from the site moderators I will post the API documentation I have written

 

[logic]

Love it please continue bro

 

[SmokeyCoder]

OK as promised here is the Mars Hydro API documented to the best of my ability after days probing and MITM captures. Took a little longer as Mars recently released an app and firmware update that added multiple soil probe compatibility.

GitHub - iClint/MarsHydroAPIDocs: Documentation on what i know of the Mars Hydro tent controller and how it communicates with its backend infrastructure

Documentation on what i know of the Mars Hydro tent controller and how it communicates with its backend infrastructure - iClint/MarsHydroAPIDocs

github.com

I have included a quick start guid with both command line only and a simple python script which does most the heavy lifting for you as a code example you could leverage as the start of your own project.

 

[SmokeyCoder]

... and here is my iPad app I created - it can do everything the official client does plus some neat little features the official client cannot.

 

[SmokeyCoder]

Next project is going to be integrating with IFTTT so I can create my own smart power strip driven by the sensors in the grow tent.

I also plan to release the iOS version to the app App Store and potentially port to android as well

 

[compostmike]

This is exactly the sort of thing Mars should have published themselves. The hardware is decent enough for the money, but locking basic telemetry and control behind a clunky cloud app makes the whole tent feel dumber than it needs to be.

I had a look at the repo and the important part is that you're documenting the ugly bits, not just the happy path. The humidifier/dehumidifier liveness weirdness, dumb actuator command echo, and full-object write behavior are the details that save people from writing an automation that looks right and quietly does the wrong thing. For grow-room control those edge cases matter. A light stuck high or a dehu state read wrong can stress plants faster than a bad feeding schedule.

For the IFTTT/power strip side I'd keep the fail-safes boring and hard coded: min/max run times, cooldown between toggles, stale-telemetry lockout, manual override, and a sane default state if MQTT/API dies. VPD targeting is useful, but only if it has hysteresis and doesn't chase every little sensor wiggle. Same with soil probes, I'd treat them as trend data more than instant commands.

Really nice work though. The iPad dashboard already looks more useful than the stock app, and the way you separated quickstart, behavior quirks, and known gaps makes it a lot less sketchy for other people to learn from.

 

[SmokeyCoder]

This is exactly the sort of thing Mars should have published themselves. The hardware is decent enough for the money, but locking basic telemetry and control behind a clunky cloud app makes the whole tent feel dumber than it needs to be.

I had a look at the repo and the important part is that you're documenting the ugly bits, not just the happy path. The humidifier/dehumidifier liveness weirdness, dumb actuator command echo, and full-object write behavior are the details that save people from writing an automation that looks right and quietly does the wrong thing. For grow-room control those edge cases matter. A light stuck high or a dehu state read wrong can stress plants faster than a bad feeding schedule.

For the IFTTT/power strip side I'd keep the fail-safes boring and hard coded: min/max run times, cooldown between toggles, stale-telemetry lockout, manual override, and a sane default state if MQTT/API dies. VPD targeting is useful, but only if it has hysteresis and doesn't chase every little sensor wiggle. Same with soil probes, I'd treat them as trend data more than instant commands.

Really nice work though. The iPad dashboard already looks more useful than the stock app, and the way you separated quickstart, behavior quirks, and known gaps makes it a lot less sketchy for other people to learn from.

Thanks I put a lot of work int this. To be honest the API is just as clunky as the app. There are literally zero safety rails no 400 bad requests. if you send a bad request chances are its getting written to the device, and just inconsistencies between payloads per device made it really hard to figure a lot of this out.

For the most part the iPad dash was the win I wanted as well as my iPhone app which is just more intuitive in my opinion.