Hydros Maven is Delayed

[JeffB418]

My issue is with the device being cloud dependent, not cloud capable. You keep reframing this dependency as a neutral or positive "design choice". I simply reject that framing. In my view, these were deliberate "design choices" that prioritize vendor control over user autonomy and I want nothing to do with such a system, let alone one in control of life support for an aquarium. Full stop.

The cloud dependency thing is a whole interesting topic overall in the industry. The vast majority of reefing gear falls into the pitfall of requiring cloud servers to operate 100% of its features. And those products that DO have a backdoor capability without cloud requirement kind of inherited due to how they evolved. Take Apex for example, it was developed as a stand alone system back 10+ years ago since cloud control really wasn't a common thing. Apex Fusion was added on AFTER the local dashboard, and thus it inherited the backdoor that gives it the selling point. Typically you don't see (commercial) products developing a parallel non-cloud option on new releases since it increases costs and this market isn't big enough to cover that. Plus, oddly the vast majority of consumers either don't care or even understand the benefit of a parallel cloud/non-cloud dependant architecture. So there are a few factors overall that don't quickly bubble up the value of being non-cloud dependant. I agree I would LOVE to see more products have a local non-cloud backdoor but I can see why the industry trend is to ignore this as a value added feature.

 

[areefer01]

And so can APEX, the classic and A2 variants do. Somebody else can confirm if there is local access on A3, dont have one yet. No need to apex fusion for full on setup/control.

You can access the apex on the local network. This has always been the case and it is not going to change.

 

[n2585722]

You can access the apex on the local network. This has always been the case and it is not going to change.

You can access the Hydros locally even without wifi through bluetooth. You do that by entering the emergency mode. The only thing you cannot do in that mode is make changes to input and output programming but that is usually not an issue if you already have things setup on it. If you really need to make the change you can alway use a mobile phone as an wifi access with the same name as the channel the Hydros controllers are set to and then make the changes. The difference in emergency mode and normal are there are no pages in emergency mode so all inputs and outputs are displayed on a single page but since it is not a normal operating mode and for temporary use it works ok for that. I have screenshots of my collective in both no wifi at all mode and no internet only in the emergency mode if interested.

 

[BeanAnimal]

Your opinions are yours and mine are mine.

The word “crippled” means nothing in terms of engineering specificity. I’ve described exactly how product works and under what conditions functionality is available or not.

You’re now just reframing and arguing semantics for the sake of debate. I fully understand the product’s architecture, and that is why I won’t use it. There’s no argument to be had. I’ve stated facts, and those facts have informed my opinion.

The product is not fully cloud dependent regardless of how many italics used. If it were cloud dependent it would completely fail when disconnected from the cloud service.

Claiming it’s not “fully cloud dependent” because it doesn’t completely fail when offline is pedantic. The fact remains: setup, programming, and key functions are impossible without the cloud. The Maven will use DRM-locked reagents requiring cloud access. The system is designed to require a persistent cloud connection. Full stop.

Labeling these limitations as “design choices” doesn’t negate their impact. Call it a mode, a feature, or a limitation or functionally, it restricts local control. That is the point.

There are many products that are fully cloud dependent (eg Uber).

Bringing up unrelated examples like Uber is a straw man. We’re not discussing ride sharing platforms and we’re discussing devices marketed for automated aquarium monitoring and control.

I also have the electrical engineering and software skills to develop my own controller if I wanted to invest that time….

As for technical credentials: I have actually built multiple modular controller systems over a decade ago One was based on Windows XP Embedded with discrete DAC/ADC and full remote/network interfacing; another was modular and used Atmega 128/256 with custom PCBs, 1-wire, 0–10V dimming, ethernet PHY, current monitoring, and more. The software was geo accurate for solar, lunar and tidal control. This was all DIY discrete electronics, long before the days of full feature ready to program boards with Ethernet, WiFi, CANBUS and everything else under the sun built in.

This is my domain... hardware, software, network architecture, SaaS models. Please stop implying I don’t understand the terminology or architecture. And for clarity: electrical engineering and electronics design are not interchangeable disciplines.


I honestly don’t understand the aim of your responses. Are you defending the product itself, your decision to use it, or simply trying to counter every critique?

I’ve explained my position clearly and backed it with both facts and experience. I’m not trying to convince anyone to agree. I am merely outlining why I won’t use the product and responding when asked or confronted about the reasoning for my opinion. If it works for you, that’s fine. But at this point, there’s nothing more productive to be said.

 

[BeanAnimal]

You can access the Hydros locally even without wifi through bluetoot.... but that is usually not an issue if you already have things setup on it.

We all understand that and it may not be an issue for you or some others, but to many of us the architecture poses many potential issues.

It is an issue if you don't want to be connected or dependent on their cloud.

It is an issue if their cloud goes down.

It is an issue of their cloud gets hacked.

It is an issue if they decide to move on.

It is an issue if they decide to retire devices or force obsolescence to generate new revenue.

It is an issue if you have an extended outage (for any reason) ad need to accommodate by altering programming.

It is an issue if/when they decide to change or remove features.

It is an issue if/when they decide to paywall existing or new features.

 

[areefer01]

You can access the Hydros locally even without wifi through bluetooth. You do that by entering the emergency mode. The only thing you cannot do in that mode is make changes to input and output programming but that is usually not an issue if you already have things setup on it. If you really need to make the change you can alway use a mobile phone as an wifi access with the same name as the channel the Hydros controllers are set to and then make the changes. The difference in emergency mode and normal are there are no pages in emergency mode so all inputs and outputs are displayed on a single page but since it is not a normal operating mode and for temporary use it works ok for that. I have screenshots of my collective in both no wifi at all mode and no internet only in the emergency mode if interested.

I am not too caught up in the maven delay or hydros ecosystem. I was just replying to the members comment about the Apex model and local access.

With regards to this thread and maven I did send an email, constructive, to Coral Vue about my thoughts on the video, DRM reagents, and reselling of Neptune reagents.

Hope your day is well.

 

[areefer01]

We all understand that and it may not be an issue for you or some others, but to many of us the architecture poses many potential issues.

It is an issue if you don't want to be connected or dependent on their cloud.

It is an issue if their cloud goes down.

It is an issue of their cloud gets hacked.

It is an issue if they decide to move on.

It is an issue if they decide to retire devices or force obsolescence to generate new revenue.

It is an issue if you have an extended outage (for any reason) ad need to accommodate by altering programming.

It is an issue if/when they decide to change or remove features.

It is an issue if/when they decide to paywall existing or new features.

Unrelated to this thread I was going to PM you. Looks like Royal Exclusive is redoing their RD3 line of pumps being made in Germany. Uses the same RD3 body to include same plumbing sizes. I exchanged emails with them over the weekend as I've been looking for a spare RD3.

Hope your day is well.

 

[Dom_P]

You’re now just reframing and arguing semantics for the sake of debate. I fully understand the product’s architecture, and that is why I won’t use it. There’s no argument to be had. I’ve stated facts, and those facts have informed my opinion.

I am not. And you simply saying so doesn’t make it true. You are trying to frame these design choice as flaws. That is your opinion, not fact, and given my expertise with the product and countless systems like it, I don’t share it.

Claiming it’s not “fully cloud dependent” because it doesn’t completely fail when offline is pedantic. The fact remains: setup, programming, and key functions are impossible without the cloud. The Maven will use DRM-locked reagents requiring cloud access. The system is designed to require a persistent cloud connection. Full stop.

It’s not an issue of complete failure at all regardless of how many times you attempt to frame it as such. It works as designed. You don’t like that design, then you are free to choose different designs. You are free to have your own opinion.

Labeling these limitations as “design choices” doesn’t negate their impact. Call it a mode, a feature, or a limitation or functionally, it restricts local control. That is the point.

The point is the product has whatever features it has regardless of whether you prefer it’s design or not.

Bringing up unrelated examples like Uber is a straw man. We’re not discussing ride sharing platforms and we’re discussing devices marketed for automated aquarium monitoring and control.

The example is simply meant explain what full cloud dependence means in my opinion. There are countless other examples I could have chosen. It is quite appropriate in this case.

As for technical credentials: I have actually built multiple modular controller systems over a decade ago One was based on Windows XP Embedded with discrete DAC/ADC and full remote/network interfacing; another was modular and used Atmega 128/256 with custom PCBs, 1-wire, 0–10V dimming, ethernet PHY, current monitoring, and more. The software was geo accurate for solar, lunar and tidal control. This was all DIY discrete electronics, long before the days of full feature ready to program boards with Ethernet, WiFi, CANBUS and everything else under the sun built in.

Choice of Windows XP for an embedded system made me chuckle . I used to write my own microkernels, but so what? Neither choice diminishes the skill it takes to do what you describe. Im not at all challenging anyone’s technical credibility. Im simply stating facts.

This is my domain... hardware, software, network architecture, SaaS models. Please stop implying I don’t understand the terminology or architecture.

It’s my domain as well, and I’ll add high availability and mission criticality if we want to get into a credentials measuring contest.

And I didn’t imply you didn’t understand the terminology. I can understand there are design choices that you would prefer to be different. And again it’s your prerogative to look elsewhere for choice of controller if those design choices don’t fit your needs.

And for clarity: electrical engineering and electronics design are not interchangeable disciplines.

edit: Oh goodness. Electrical engineering is multi disciplinary. Digital design certainly falls under one of those disciplines, otherwise I’d have to wonder why I took so many digital design courses at school. And software engineering is similar. Designing and developing embedded software is unlike developing web applications

I honestly don’t understand the aim of your responses. Are you defending the product itself, your decision to use it, or simply trying to counter every critique?

The aim of my responses are to address the misinformation in the thread and to clarify exactly how the product works. I made no defense of the product or the design decisions made by CV. You, on the other hand, are providing critiques throughout this thread. Which, of course, you are free to do, but I’m also free to provide information as I see fit.

I’ve explained my position clearly and backed it with both facts and experience. I’m not trying to convince anyone to agree. I am merely outlining why I won’t use the product and responding when asked or confronted about the reasoning for my opinion. If it works for you, that’s fine.

You’ve provided your opinion based on your experiences and preferences to that I will agree. I have not confronted you about your opinion or reasoning. In fact, if anything you are the one doing so with each retort to my postings.

But at this point, there’s nothing more productive to be said.

Agreed

 

[BeanAnimal]

Typically you don't see (commercial) products developing a parallel non-cloud option on new releases since it increases costs and this market isn't big enough to cover that.

Absolutely -- supporting both local and remote interfaces adds some complexity and cost. But with modern, OS-agnostic stacks and robust messaging protocols like MQTT or OPC UA, building parallel interfaces on a shared architecture is rather easy and requires almost no extra development.

In Hydros’ case, replacing cloud dependence with a local head unit that offers equivalent functionality and UI should be entirely feasible. That is, unless the product is tightly coupled to a third-party IoT platform. That introduces an additional layer of vendor dependency (and risk), leaving end users at the mercy of both the product vendor and their IoT infrastructure provider.

Plus, oddly the vast majority of consumers either don't care or even understand the benefit of a parallel cloud/non-cloud dependant architecture.

I think that you will find a building movement toward rejection of fully cloud dependent products. But of course, there will always be those who don't care.

 

[Dom_P]

In Hydros’ case, replacing cloud dependence with a local head unit that offers equivalent functionality and UI should be entirely feasible. That is, unless the product is tightly coupled to a third-party IoT platform. That introduces an additional layer of vendor dependency (and risk), leaving end users at the mercy of both the product vendor and their IoT infrastructure provider.

This is something we can agree on

 

[BeanAnimal]

I am not. And you simply saying so doesn’t make it true.

Use whatever words you like, but nothing factual changes.

It can't be setup without the cloud.
Functionality is reduced without the cloud.
It is not designed to be run without the cloud.
Programming can't be changed without the cloud.

You are trying to frame these design choice as flaws. That is your opinion, not fact, and given my expertise with the product and countless systems like it, I don’t share it.

Yes - it is my opinion that Hydros is built in a flawed design methodology. I have made that clear.

It’s not an issue of complete failure at all regardless of how many times you attempt to frame it as such

I have not once, framed it as such.

Choice of Windows XP for an embedded system made me chuckle . I used to write my own microkernels, but so what? Neither choice diminishes the skill it takes to do what you describe. Im not at all challenging anyone’s technical credibility. Im simply stating facts.

The laughing response feels rather ironic considering it is being juxtaposed against a controller that is literally tied to the cloud, where changes by the vendor can affect the end user, without their knowledge or direct consent.

Moreover, I bet my two shoes and sister Sarah's mule that Hydros is not running an RTOS on their MCUs.

While XPe was not truly an RTOS, it checked most of the boxes and was more than suitable for the task at hand. The original plan was to use CE but that was limiting in numerous ways and likewise, embedding CE for RTOS tasks was overkill, complicated and unneeded. At the same time as I was extending the x86 based controller, the Atmega256 was released and I migrated the platform to a fully modular design.

The aim of my responses are to address the misinformation

There is no misinformation whatsoever, just an argument about semantics because you don't like my opinion.

You, on the other hand, are providing critiques throughout this thread.

I certainly am and have openly stated as much numerous times.

 

[BeanAnimal]

Unrelated to this thread I was going to PM you. Looks like Royal Exclusive is redoing their RD3 line of pumps being made in Germany. Uses the same RD3 body to include same plumbing sizes. I exchanged emails with them over the weekend as I've been looking for a spare RD3.

Hope your day is well.

Wow - I had just assumed they were basically out of business and peddling jaebo. No responses to several requests. I had to break down and put an RD3 online a month or two back. The ReeFlo dart was finally starting to seize up. Of the (3) pumps I have (130W and two 100's I think) only one of 100's worked. The impeller on the other 100 will not turn freely with the volute attached and I didn't have a union for the 130.

 

[BZOFIQ]

You can access the apex on the local network. This has always been the case and it is not going to change.

I said that.

 

[Dom_P]

Use whatever words you like, but nothing factual changes.

It can't be setup without the cloud.
Functionality is reduced without the cloud.
It is not designed to be run without the cloud.
Programming can't be changed without the cloud.

I’ve used no words other than those expressing facts.

You’ve finally gotten to the root of the matter. The product needs to be connected to a cloud service to be programmed or reprogrammed. That is the extent of reduction in functionality without cloud connectivity. Full stop. It is designed to run without the cloud however. So that’s point isn’t true no matter how you try to frame it.

Yes - it is my opinion that Hydros is built in a flawed design methodology. I have made that clear.


I have not once, framed it as such.


The laughing response feels rather ironic considering it is being juxtaposed against a controller that is literally tied to the cloud, where changes by the vendor can affect the end user, without their knowledge or direct consent.

While XPe was not truly an RTOS, it checked most of the boxes and was more than suitable for the task at hand. The original plan was to use CE but that was limiting in numerous ways and likewise, embedding CE for RTOS tasks was overkill, complicated and unneeded. At the same time as I was extending the x86 based controller, the Atmega256 was released and I migrated the platform to a fully modular design.

I only chuckled because of the issues I’ve had trying to use windows for embedded systems. Again you were and are free to make whatever design decisions you want when developing your own products.

There is no misinformation whatsoever, just an argument about semantics because you don't like my opinion.

It’s not at all semantics. It’s also not about whether I like or dislike your opinion, in fact, I completely understand your concerns about not being able to program it without the cloud services. I just don’t share those concerns and to frame that as safety concern is somewhat misleading. The product operates without the cloud services and performs its functions whether it’s connected or not. That’s the information that I was seeking to clarify.

 

[BZOFIQ]

That's a lot of back and forth about a product that doesn't exist.

 

[Dom_P]

That's a lot of back and forth about a product that doesn't exist.

Yeah. Let’s get back to the that vs the merits or shortcomings of cloud computing for a aquarium controller

 

[BeanAnimal]

I’ve used no words other than those expressing facts.

You’ve finally gotten to the root of the matter. The product needs to be connected to a cloud service to be programmed or reprogrammed

Gene Roddenberry, call your office....

This is patently absurd! you’ve just repeated the exact point I’ve made from the start and presented it as if it’s your own conclusion, as though that somehow discredits me. That’s rhetorical appropriation, plain and simple.

You’ve spent the entire exchange deflecting, reframing, and nitpicking semantics, only to now parrot my position as if it reinforces your argument, rather than simply acknowledging that what I’ve said all along is accurate.

Yeah. Let’s get back to the that vs the merits or shortcomings of cloud computing for a aquarium controller

Says the guy who kicked off this entire exchange by refusing to acknowledge a clearly stated opinion grounded in basic facts. If you didn’t want to debate the merits of cloud dependency, you shouldn’t have tried to reframe or dismiss the core issue in the first place.

 

[Dom_P]

I’ve used no words other than those expressing facts.

You’ve finally gotten to the root of the matter. The product needs to be connected to a cloud service to be programmed or reprogrammed

Gene Roddenberry, call your office....

This is patently absurd! you’ve just repeated the exact point I’ve made from the start and presented it as if it’s your own conclusion, as though that somehow discredits me. That’s rhetorical appropriation, plain and simple.

You’ve spent the entire exchange deflecting, reframing, and nitpicking semantics, only to now parrot my position as if it reinforces your argument, rather than simply acknowledging that what I’ve said all along is accurate.

Yeah. Let’s get back to the that vs the merits or shortcomings of cloud computing for a aquarium controller

Says the guy who kicked off this entire exchange by refusing to acknowledge a clearly stated opinion grounded in basic facts. If you didn’t want to debate the merits of cloud dependency, you shouldn’t have tried to reframe or dismiss the core issue in the first place.

Your opinion from the beginning was that the product is flawed. It isn’t flawed. It’s designed as such and you finally decided to give up the ghost and say so. To say I’ve changed my position in any way is patently false regardless of whether you call on Gene Roddenberry or not. You simply are trying to enflame in an attempt to deflect. Which generally seems your MO.

You don’t like being tied into a closed ecosystem, we all get it. And you’ve chosen not to. We all get that too. But some of your opinions are not based in fact regarding safety etc. if that rubs you the wrong way. Well c'est la vie.

 

[BeanAnimal]

Your opinion from the beginning was that the product is flawed. It isn’t flawed. It’s designed as such and you finally decided to give up the ghost and say so.

This is beyond parody at this point. You’ve spent the entire exchange arguing semantics, reframing positions, and now you’re co-opting not just my argument but even my exact language -- “reframing,” “deflection,” “Full Stop", etc. Claiming "projection". It is all ironically laughable. You just want to argue, even though there is nothing to argue about.

I have said from the beginning that it is my opinion the the product is flawed. That’s a critique of the architecture and methodology, not of its ability to function as intended within its "design". Each time you have tried to reframe my argument, I have offered clarity and yet here we are doing it again.

You’ve refused to acknowledge that point, dismissed it, argued around it, then circled back to repeat it as if it somehow supports your position. Now you accuse me of deflection for calling it out? I’ve held one consistent position and repeated it throughout this entire thread, let alone in the exchanged with you.

To say I’ve changed my position in any way is patently false

No - you have argued the same ridiculous semantics all along, then tried to co-opt them to say I have finally agreed with you. It is laughable and you are now doubling down on it.

regardless of whether you call on Gene Roddenberry or not. You simply are trying to enflame in an attempt to deflect. Which generally seems your MO.

Considering I’ve repeated the same core points throughout this entire thread—let alone this ridiculous side exchange with you -- and it’s you who continues to engage, move the goalposts, and twist context, I’ll happily clarify my MO:
It’s not tolerating people who argue in circles, reframe others' words, and refuse to concede when they’ve clearly misunderstood or misrepresented the discussion.

You don’t like being tied into a closed ecosystem, we all get it.

Clearly you don’t, because that’s not even remotely my argument.

I don’t object to a closed ecosystem. What I object to is the lack of autonomous control and the absolute reliance on a cloud or 3rd party infrastructure.

 

[areefer01]

I said that.

You did, correct. You also said "somebody else can confirm if there is local access on the A3" which is why I replied as I did. All Apex controller are accessible via the local host. I am not trying to nit pick with you just explaining why I replied the way i did.

Hope your day is well.