Hydros Maven is Delayed

[n2585722]

This may or may not be an issue depending on ones setup.

Local access is always good to have in case of a need of a fall back.

I have battery backup through my wave engine and Kraken for the controllers and also have my cable modem and router on a UPS so I still get communications with the controllers even during a power outage. The controllers do go into a low power mode which turns off everything but the flow pumps which go to a schedule that slows them down to a lower speed. So I would still have communications with the controllers one way are another during a no power situation.

 

[Dom_P]

Forgot this is Wi-Fi (like the A2, A3 apex) - I've always been wired kind of guy.


Ethernet has never failed me, can't say the same for spotty wireless setups I see tons of everywhere.

I have a lot of experience in networking (both wired and wireless). I’ve had both fail me many times .

I will say I have had zero issues with the Hydros Wi-Fi. I do have several access points in my home so coverage is quite good. I pretty much run most things wireless. Including multiple 4K TVs without issue.

I also understand that most people however don’t have the background to design their home wireless network and usually just use the Wi-Fi router their ISP provides and end up with less than good experiences with Wi-Fi

That all said. I don’t see any reason why CV couldn’t have hardwired Ethernet. They wouldn’t need to have an RJ45 jack on the controller. They could develop a couple meter cable that would connect in a water proof manner to the controller and have an RJ45 jack at the other end

 

[Dom_P]

Personally I find the cloud setup super convenient (as is true with many cloud based apps). Of course, it creates dependencies:

1. For internet access
2. To a cloud provider (eg. AWS)
3. To the organization providing the service (ie. CoralVue)

This is pretty much the case for many IoT devices these days.

I can understand how people might be uncomfortable with this, but it isn’t atypical anymore. If those dependencies make one uncomfortable, then I suppose the Hydros ecosystem (or others like it) aren’t for them.

 

[BeanAnimal]

It will not matter if they go out of business since even one that does not require the cloud will still eventually become unreachable. I have a Archon that now only one web

That’s a ridiculous equivocation — like saying “everything breaks eventually, so design doesn’t matter,” or “we all die, so safety is irrelevant.” It’s a lazy deflection that ignores the entire point of good design.

I could still access it using bluetooth and could override outputs to off, auto or on. You can setup the emergency mode now to make it easier to use bluetooth when you have no internet.

That’s crippled access to basic toggles, not full local control. You can’t configure, tune, or manage the system without the cloud. The devices are entirely cloud dependent.

Stop glossing over critical flaws and spinning limitations as features. It undermines your credibility and makes you sound less like an informed user and more like a brand apologist.

 

[Dom_P]

It will not matter if they go out of business since even one that does not require the cloud will still eventually become unreachable. I have a Archon that now only one web

That’s a ridiculous equivocation — like saying “everything breaks eventually, so design doesn’t matter,” or “we all die, so safety is irrelevant.” It’s a lazy deflection that ignores the entire point of good design.

I could still access it using bluetooth and could override outputs to off, auto or on. You can setup the emergency mode now to make it easier to use bluetooth when you have no internet.

That’s crippled access to basic toggles, not full local control. You can’t configure, tune, or manage the system without the cloud. The devices are entirely cloud dependent.

Stop glossing over critical flaws and spinning limitations as features. It undermines your credibility and makes you sound less like an informed user and more like a brand apologist.

I don’t see these as design flaws. They are simply design choices.

The cloud functionality was a design choice and the addition of the Bluetooth emergency mode was also a design choice.

This design may not suit everyone, that’s understandable… but in my experience the product has been quite sound and reliable.

And the Bluetooth mode is a useful capability to allow access/control when cloud services are unavailable. That is to say the product doesn’t “brick” because it isn’t connected to the cloud. It continues to operate in its last known configuration and the Bluetooth mode supports basic controls while cloud service is unavailable. As such, it seems critical safety issues are addressed (ie. monitoring and manual control over connected devices is available should they be needed)

 

[BeanAnimal]

This design may not suit everyone, that’s understandable…

All “flaws” are inherently “design choices”. In any case I made it clear that I was giving my opinion regarding their “design choices” and that the system and their “design choices” may be fine for other people.

That is to say the product doesn’t “brick” because it isn’t connected to the cloud. It continues to operate in its last known configuration…

The product may have a minimal “emergency mode” once setup but it can’t be setup or used without full dependence on their cloud and programming can’t be altered without their cloud. So “brick” no, but it’s close.

 

[Dom_P]

All “flaws” are inherently “design choices”. In any case I made it clear that I was giving my opinion and that the system and their “design choices” may be fine for other people.


The product may have a minimal “emergency mode” once setup but it can’t be setup or used without full dependence on their cloud and programming can’t be altered without their cloud. So “brick” no, but it’s close.

Yes, agreed. But that is not what that mode is intended for. It’s intended to provide basic control while cloud services are unavailable. Im not sure I agree with “close” to bricked, but I do understand your points. It simply operates as it was before disconnection from the cloud no different than every time I choose to reboot my router.

Yes, programming can not be updated while disconnected from the cloud. And so, should CV decide to no longer provide those cloud services then it could no longer be programmed. But as I noted earlier if CV was no longer offering support for the product for whatever reason I’d be looking for an alternative at that point regardless.

Also I don’t think all flaws are design choices, usually they are bugs

 

[BeanAnimal]

But that is not what that mode is intended for.

It is not a question of intent, it is the basic fact that the device is cloud dependent and crippled without.

But as I noted earlier if CV was no longer offering support for the product for whatever reason I’d be looking for an alternative at that point regardless.

As I said, such a caveat is a 100% deal breaker for me.

In niche markets like this, controller hardware is a durable good with a finite customer base. Cloud reliance creates a deferred liability — recurring costs without recurring revenue. It’s a self-inflicted pyramid where new sales subsidize ongoing cloud infrastructure. Once the market saturates, the model collapses unless the vendor pivots to subscription based services and/or DRM-style consumables. The paradox is unavoidable. Long term customers become a financial burdened and new customers become scarce due to competition and saturation of a limited demographic.

 

[BZOFIQ]

I have a lot of experience in networking (both wired and wireless). I’ve had both fail me many times .

Your experience differs - I get that.

There is no discussion however, how much more reliable a wired connection is vs wireless.

I also understand that most people however don’t have the background to design their home wireless network and usually just use the Wi-Fi router their ISP provides and end up with less than good experiences with Wi-Fi

That all said. I don’t see any reason why CV couldn’t have hardwired Ethernet. They wouldn’t need to have an RJ45 jack on the controller. They could develop a couple meter cable that would connect in a water proof manner to the controller and have an RJ45 jack at the other end

Background not an issue here. Running off pfSense and Ubiquiti, no ISP equipment in this household so plenty of coverage even way outside the walls. Have 2 dozen devices on Wifi Subnet here but I don't view them as essential as a live support controller. A wired connection will always take the cake.

 

[BZOFIQ]

I spoke to CV reps at the RAPNY last week - no more release dates are given after the fiasco last year. It's been more than a year since I first saw nothing, to be released in November of last year for between $899-$999.

Perhaps one day, who knows. I'll let someone else work out the kinks and I most certainly won't be switching controllers because of a single tester.

 

[Dom_P]

It is not a question of intent, it is the basic fact that the device is cloud dependent and crippled without.

Your definition of “crippled” is simply a mode in which the device is intended to operate. That is, it cannot contact the cloud services it requires to perform programming functions and therefore it continues to operate in its last known state. It does that without failure of its primary function which is to control the devices it was last programmed to. This is not atypical for cloud based devices.

As I said, such a caveat is a 100% deal breaker for me.

This is surely your choice. No one is forced to purchase products they feel do not meet their requirements.

In niche markets like this, controller hardware is a durable good with a finite customer base. Cloud reliance creates a deferred liability — recurring costs without recurring revenue. It’s a self-inflicted pyramid where new sales subsidize ongoing cloud infrastructure. Once the market saturates, the model collapses unless the vendor pivots to subscription based services and/or DRM-style consumables. The paradox is unavoidable. Long term customers become a financial burdened and new customers become scarce due to competition and saturation of a limited demographic.

The platform in a cloud environment is generally durable. As is the case here with the controller being the platform. Again one may or may not prefer the cloud model, the subscription models that may or may not follow, or being locked in to a given vendor’s particular ecosystem. But that doesn’t mean the design is poor or incorrect. The devices perform as intended and in fact do that with quite a bit of redundancy.

 

[Dom_P]

Your experience differs - I get that.

There is no discussion however, how much more reliable a wired connection is vs wireless.

Yes, of course.

Background not an issue here. Running off pfSense and Ubiquiti, no ISP equipment in this household so plenty of coverage even way outside the walls. Have 2 dozen devices on Wifi Subnet here but I don't view them as essential as a live support controller. A wired connection will always take the cake.

Ok, then Im not sure i understand the concern about an “essential live support controller”. If the device loses temporary connectivity to your network, the internet, or the cloud service, it continues to perform its intended function without failure.

 

[Dom_P]

I spoke to CV reps at the RAPNY last week - no more release dates are given after the fiasco last year. It's been more than a year since I first saw nothing, to be released in November of last year for between $899-$999.

Perhaps one day, who knows. I'll let someone else work out the kinks and I most certainly won't be switching controllers because of a single tester.

It will be interesting to see what the take up is if the product is ever released and whether it will work well. I’d prefer a testing device that’s part of the same vendor ecosystem but only if it does the intended job of decreasing the time spent testing.

 

[Hyphnx]

I too spoke to the reps at RAPNY and they told me they are constantly making changes and are on their 11th revision. They want to perfect this product to avoid failures in customers' hands. I applaud that, as I am currently on my 5th Trident NP and have been dealing with Trident NP failures since July of last year.

 

[BZOFIQ]

I too spoke to the reps at RAPNY and they told me they are constantly making changes and are on their 11th revision. They want to perfect this product to avoid failures in customers' hands. I applaud that, as I am currently on my 5th Trident NP and have been dealing with Trident NP failures since July of last year.

Trident NP is crap!!!

Not sure why this is still offered for sale, below from that Bulk store.

 

[BZOFIQ]

It will be interesting to see what the take up is if the product is ever released and whether it will work well. I’d prefer a testing device that’s part of the same vendor ecosystem but only if it does the intended job of decreasing the time spent testing.

Provided it tests well and tests when you want it to test and not when they want you to test to blow through reagents - regardless of what anybody says.

Imagine a printer manufacturer that says we need to print 3 pages per day even if you're not home just to keep the heads clean? Yeah ok!

 

[BZOFIQ]

Ok, then Im not sure i understand the concern about an “essential live support controller”. If the device loses temporary connectivity to your network, the internet, or the cloud service, it continues to perform its intended function without failure.

It's not hard, APEX retains FULL functionality, I mean FULL, not crippled, not minimal, not essential by your standards.... FULL functionality without the cloud component. That's running its automated functions AND the ability to modify its programming on the fly.

There is LOCAL (or remote) access to the web interface to change anything you please. Apex brain will continue to function with ALL its current features even if APEX mysteriously closes shop tomorrow or in the event that AF component is unreachable.

 

[Dom_P]

It's not hard, APEX retains FULL functionality, I mean FULL, not crippled, not minimal, not essential by your standards.... FULL functionality without the cloud component. That's running its automated functions AND the ability to modify its programming on the fly.

There is LOCAL (or remote) access to the web interface to change anything you please. Apex brain will continue to function with ALL its current features even if APEX mysteriously closes shop tomorrow or in the event that AF component is unreachable.

Yes, I understand that. But that simply isn’t how the Hydros works at this moment. It has a dependency on the cloud services to update programming. It does however not fail because of lack of connectivity to the cloud, as such it performs the essential functions of controlling all devices in its last known programming state.

Now again this may not be a design that is preferred by some, and there might be concerns about obsolescence etc if cloud services were to be terminated. But, to me, that is a different concern and is more one of long term investment and cost vs whether the device maintains the reef tank during a Wi-Fi, internet or cloud service outage.

 

[BeanAnimal]

Your definition of “crippled” is simply a mode

Yes, the "mode" you're referring to is a direct result of a "design choice" that cripples the unit’s functionality. No amount of wordsmithing, reframing, or optimistic advocacy changes that.

It does that without failure of its primary function which is to control the devices it was last programmed to. This is not atypical for cloud based devices.

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.

This is surely your choice. No one is forced to purchase products they feel do not meet their requirements.

I have not purchased these producst for the reasons stated -- and others. I have been clear about that. This thread of the conversation is about why those design decisions are unacceptable to some of us. It relates to the Maven, as it will be part of the ecosystem, as well as the overall context of how its release has been handled and the DRM-locked reagent announcement.

Nobody is asking you to dislike the product, but for goodness sake, stop trying to convince us that our opinions are invalid because you are happy.

 

[Dom_P]

Yes, the "mode" you're referring to is a direct result of a "design choice" that cripples the unit’s functionality. No amount of wordsmithing, reframing, or optimistic advocacy changes that.


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.

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.

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. There are many products that are fully cloud dependent (eg Uber). Hydros relies on the cloud for the programming aspects of its functionality. As such, it’s cloud dependent for those particular features, however, when disconnected from the cloud service it continues to operate as did without the ability to modify programming. As such safety concerns are addressed.

I have not purchased these producst for the reasons stated -- and others. I have been clear about that. This thread of the conversation is about why those design decisions are unacceptable to some of us. It relates to the Maven, as it will be part of the ecosystem, as well as the overall context of how its release has been handled and the DRM-locked reagent announcement.

That is always one’s prerogative as a consumer. If the product doesn’t meet someone’s use cases, then they may look to other products. Of course in this case choices are somewhat limited given the addressable market.

Nobody is asking you to dislike the product, but for goodness sake, stop trying to convince us that our opinions are invalid because you are happy.

I have certainly not made the case that anyone’s opinions are invalid nor am I optimistically advocating for the product. And whether I personally like or dislike the product isn’t germane. Im simply providing detail about what the product is and what it isn’t. As in all things such as this there are trade offs and people are free to do their own trade off analysis. However that analysis should be done without misinformation. I chose to clarify some of that in this thread. As with most things in life separating opinion from fact is very important when making decisions.

Also, I’ve been using aquarium controller products a long time. My first was the Neptune aquacontroller with X10. I also have the electrical engineering and software skills to develop my own controller if I wanted to invest that time…. So, Im no novice to the features and functions of aquarium controllers. I took a hiatus from reefing and when I returned I made my choices of what equipment to purchase. At that time, for a controller, the Hydros best fit my use cases. Again, those are my use cases and may completely differ from yours and others. The product works well for my requirements but may fail miserably for yours. Those are both viable outcomes.