ReefLogix Reflect - my GHL Profilx Dashboard Application

[BeanAnimal]

I built a custom monitoring/control layer for my GHL ProfiLux Ecosystem.

I am going to share the highlights here.

The source is approaching 20,000 lines of code, mostly Python and Javascript.

Given the scope and time spent, I have not made a decision on sharing the source publicly, or at all.

So, this may pop up as a freebie, or may not. I hope that you all understand. But I do want to share what is possible.

I think many of you know how I feel about GHL's dashboard. This project has been started and abandoned several times since 2021, mostly because of the incomplete GHL API creating a loss of interest for the diminished return, and hopes that GHL would eventually realize that 1990 wanted their dashboard back and build a new one.

So, with the recent API release, I picked the project back up.

I'd been through Home Assistant + Grafana + a proper time-series database for this, and honestly, all of it was a mess that never yielded clean results. HA integrations breaking on updates, Grafana and its bugs and rather rigid dashboards, even though they feel flexible at first. The time-series DB (InfluxDB) is bug-riddled, breaking-change garbage. The closest I got was with HA, but the integration eventually caused a real connection churn problem against the ProfiLux. It led to memory exhaustion on the P4, meaning hard boots every few days.

I am going to say this openly, not as an insult, but as an honest assessment. The GHL API is bespoke, finicky, and feels like it should have been abandoned instead of finished. The ProfiLux is genuinely fussy about its one TCP client. Reconnect too often or too aggressively and you're asking for trouble. Stay connected and poll, and you're guaranteed out-of-order responses, but responses aren't tagged to the request. It is, frankly, a mess. It should have been scrapped for a proper RESTful API and/or an MQTT server. I will note on that again in the summary.

Anyway, I scrapped all of it and built this ground-up on a Raspberry Pi with my own custom software stack.

• Custom poller service
• SQLite instead of a dedicated time-series DB
• Custom configurable dashboard system
  • responsive and fixed pages
  • kiosk (full screen) modes
  • editable html template and css templates
• Full setup menus
• Auth providers and tunneling so no firewall rules needed for remote access
• Back and Restore data and settings
• Panel drill downs for data
• Custom charting tool
• Adjustable warn and alarm thresholds per input/source
• Auto mapping of available GHL sensors, dosers, switches, level sensors, illumination, etc, .

Basically what the less-than-stellar GHL dashboard should have been in the first place.

This is the dash (almost complete) that will run on a 14" wall mounted touch kiosk in the office.

GHL gotchas that shaped the design​

A few things I only found out by getting burned:

1. Replies carry zero identifying information.** The protocol's response to a query is just a bare acknowledgement with a value. No sensor ID, no echo of what was asked. The only thing that tells you which reading belongs to which sensor is strict request-then-reply ordering. Get that ordering wrong even once and a reading from one sensor lands in another sensor's slot. So instant data corruption and no easy way to guardrail against it. There is no way to sugar coat it, the API structure is not good.
2. The device sometimes sends a duplicate reply to a single command. Undetected, that extra reply shifts everything polled after it out of sync.
3. The way to combat items 1 and 2 is to disconnect the socket after each call and then reconnect for the next call. This quickly exhausts resources on the P4 and it must be rebooted to recover from the bad socket state.

This is not criticism of GHL hardware, which does its actual job well. It is an API that lacks the structure needed for real polling for an external dashboard.

Part of the system screen. Stats, error rate, etc for the system and poller service.

Full control of associated services.

The polling layer​

The ProfiLux only accepts one connection at a time and it's genuinely picky about it. To work around the bad state caused by excessive connection flap. this runs a single persistent connection. Strict request/reply in order, with a plausibility check on every reading. Example brightness value that suddenly reads 2600% gets caught and thrown out before it ever hits a chart, not trusted as real. Everything gets written to a local SQLite history, polled at different rates depending on what the sensor actually is, and configurable in the settings. The poller is self healing with backoff states, reconnection logic and several watchdog mechanisms.

All available endpoints are automatically pulled into the app and can be given friendly names

Full debug and diagnostics logging with search for all poller and services.

Dashboards that are actually configurable​

Every tile, chart, and container on the wall-mounted display is built from a shared pool of panel definitions, not hardcoded per screen. Add a sensor once, place it on as many dashboards as you want, each with its own layout. There's a real Setup UI for all of it. It is not drag and drop (maybe one day) and all dashboards have editable HTML/CSS for customization, syntax checking, etc. So there is a code editor built in!

Part of the config for the 4:3 wall kiosk dashboard. The appliance can server numerous custom responses and fixed ratio dashes.

Bult in code editor with highlighting, auto indent and syntax checking.

Drill-downs​

Tap any tile on the kiosk screen and it opens a full, responsive detail view. A real chart with adjustable time range and bucket size (raw / 5-min / hourly) and smoothing. The illumination schedule: tap the light bar, see the actual programmed curve. Click a sensor and see its charted data with a data table beneath, also with time range and bucket size options.

Example Alkalinity Drill down and chart

The illumination schedule drill down

Remote access, without opening my network up​

This is the part I think is actually worth mentioning to anyone else doing something similar. Three independent options, pick any combination:

1. Plain LAN access no cert needed http://
2. Old-school port-forward + real cert, upload your own via CSR or use Acme certbot. Caddy handles the reverse proxy and TLS automatically. Set your own ports as needed
3. Cloudflare Tunnel - this is the one I actually use. No port forwarding, works fine behind CGNAT or a dynamic IP since there's nothing to forward to! The Pi makes an outbound-only connection to Cloudflare, and my public hostname just rides on top of that. I Added Google login in front of it through Cloudflare Access. Any other provide or method can be added at the Cloudflare node, nothing has to be changed on the appliance.

Some of the certificate and remote config settings.

Backup/restore​

Full snapshots. Database, dashboard layouts, systemd services, everything. They scheduled automatically and adjustable, restorable from a browser upload if the SD card ever dies and can be routed to a Google drive.

I am happy to answer questions but as I mentioned above I am not sure yet if I'll open-source the whole thing or not.

To the note about this API and GHL's options: I have leveraged the API into a workable piece of software, but it didn't have to be this hard. Even if the P4 doesn't have the capacity to house a real RESTful API, I can't fathom why they don't build a small add-on PAB card or PAB appliance that basically does what I just built. And or a less expensive option that streams MQTT. They would get their data off the PAB bus and act as a user-customizable dashboard server or standard MQTT data source. No SaaS or cloud needed.

 

[mainquesthobbies]

Wow, that's pretty crazy that the API doesn't offer any id or any data as to what it's replying to. I've been a dev for 30 yrs, and it blows my mind how many devices nowadays are sent out with half-baked software or api that doesn't even qualify as "bare bones". I'm thinking of starting a project to test out the Hydros controller API system to see what I can make work with that. I really hope they did a decent job with it.

Are you coding it all yourself, or are you getting a bit of help from our friend Claude? :)

 

[Seregus]

Your work is stunning! I can not say even how much I’m impressed! I must say I’d love to join if you need any help at all?

In my opinion they should have gone with Google Buffers protocol since its basically the most efficient one, have plenty of implementations in every language including C and almost zero overhead and speed… amazing. Would have created zero issues with protocol requirement since you would have a Python code to work with instead of parsing protocol.

 

[BeanAnimal]

Wow, that's pretty crazy that the API doesn't offer any id or any data as to what it's replying to. I've been a dev for 30 yrs, and it blows my mind how many devices nowadays are sent out with half-baked software or api that doesn't even qualify as "bare bones". I'm thinking of starting a project to test out the Hydros controller API system to see what I can make work with that. I really hope they did a decent job with it.

Are you coding it all yourself, or are you getting a bit of help from our friend Claude? :)

I have found Claude far better this time around, but it can still very easily make a large unrecoverable mess. Limiting its scope to specific functions and managing commits and versioning has been very helpful. It has also been great for code assessment, commenting and building a test suite alongside the code.

 

[BeanAnimal]

Your work is stunning! I can not say even how much I’m impressed! I must say I’d love to join if you need any help at all?

In my opinion they should have gone with Google Buffers protocol since its basically the most efficient one, have plenty of implementations in every language including C and almost zero overhead and speed… amazing. Would have created zero issues with protocol requirement since you would have a Python code to work with instead of parsing protocol.

One early iteration of this was a cloud endpoing with InfluxDB (garbage) and Grafana. I opted to go with a local full stack appliance instead and simply use the CF ZeroTrust tunnel for remote. So I am fully cloud independent other than remote access.

 

[BeanAnimal]

Also RE Claude Code:

It is far better than GPT or Gemini at this point with regard to following directions and not altering settled functions. Gemini just does what it wants, and GPT constantly goes back and changes existing code, always thinking "hey I can optimize this". In doing so it just outright alters functions, outputs, whatever.

Claude Code doesn't often go back and regress working functions, but it often (most of the time) builds what it wants, not what you ask for. Unwinding that mess is often more trouble than building it yourself.

 

[JeffB418]

I'm thinking of starting a project to test out the Hydros controller API system to see what I can make work with that. I really hope they did a decent job with it.

The Hydros API documentation is available here if you wanted scope it out prior to getting a developers key: https://developers.api.coralvuehydros.com/public-api.html

 

[BeanAnimal]

I think he already knows that -- otherwise he wouldn't be looking to see how well it works and if they did a decent job.

 

[JeffB418]

I think he already knows that -- otherwise he wouldn't be looking to see how well it works and if they did a decent job.

well you know what they say, "when you assume, you make an butt out of u and me"

 

[BeanAnimal]

well you know what they say, "when you assume, you make an butt out of u and me"

Of course, but the context was rather clear. This thread is about the GHL API and what I built with it. The only assumption required here would be that, despite specifically saying he was going to test the Hydros API, he was somehow unaware that the API or its documentation existed.

So what I read, rather than assumed, was Hydros being worked into an otherwise unrelated thread simply because the subject of an API came up, even though nobody was asking about it.

It’s okay, Jeff, you can post what you want. You can be a happy customer and spread the word. I personally just found it a bit contrived and out of place in this particular thread, so I responded as such. No offense intended.

 

[mainquesthobbies]

The Hydros API documentation is available here if you wanted scope it out prior to getting a developers key: https://developers.api.coralvuehydros.com/public-api.html

Thnx. I appreciate it. Will dive into it deeper soon.

Sorry, didn't mean to hijack the thread into a different brand/direction. Keeping to the original thread, I really like the idea of setting up a 14" touch screen/kiosk thing. That is what I was thinking about as well, as I'm not a fan of always having to pull out my phone to look at something or turn on feeding mode or whatever.

Would be way better to just have a permanent screen showing stuff and be able to just click buttons on there. Of course there are times when mobile is a plus, but most of the time it's not needed. Plus, a nice display showing stuff looks cool too. :)

 

[BeanAnimal]

Thnx. I appreciate it. Will dive into it deeper soon.

Sorry, didn't mean to hijack the thread into a different brand/direction. Keeping to the original thread, I really like the idea of setting up a 14" touch screen/kiosk thing. That is what I was thinking about as well, as I'm not a fan of always having to pull out my phone to look at something or turn on feeding mode or whatever.

Would be way better to just have a permanent screen showing stuff and be able to just click buttons on there. Of course there are times when mobile is a plus, but most of the time it's not needed. Plus, a nice display showing stuff looks cool too. :)

You didn’t hijack at all.

I don’t even need to drill down, or control. I built it in because i could. This started as just a kiosk, but morphed into a full local and remote access dash. The primary use is still just a large screen kiosk so that I can see a problem at a glance.