Isn't there a way to allow the devices to be accessed through the local network? It doesn't need to interfere with the data collection or the encryption, you are just allowing the user to access the device locally, before it is even encrypted to be sent to the servers.

To be honest if I am choosing between two devices and one supports HA and the other doesn't, the choice is quite obvious. I think one way to convince your higher ups is that you will be more appealing to a big niche of tech users that have elaborate IOT setups (which means $$$).

One suspects, for numerous reasons, that your employer will never allow any user, especially a North American, to stop data collection by the central servers.

However, you might refer the customer to your colleagues in the EU. They will have stronger data protections that could be used to force the issue. The Europeans might be able to share how it works with your North American customer.

Are you from Tuya? They seem hellbent on locking their stuff down to the cloud.

Perhaps point out to your management that IOT is an enthusiast driven market. If you appease the enthusiasts, they will recommend your products to their less technically inclined friends.

Enthusiasts want both: a good initial software ecosystem, and the option to break out of that if required. If your company can offer that, even if it involves voiding the warrenty, we'll buy and recommend their stuff.

In the case of Tuya, their stuff was historically super easy to open, solder some jumpers and flash (or exploit the OTA to flash). I bought loads of their power boards and lights. In some ways I was an ideal consumer, I bought their stuff, voided the warrenty immediately (so no support calls), and never used their cloud, so didn't waste their resources. Now they are making it near impossible, and I won't touch their stuff.

All that said, good luck, your gonna need it.

So I've been the person who denies projects like these in the office.

There are two non-negotiable requirements for equipment like this.

1. It absolutely must not in any way interact with outside servers or remote services. All data must stay contained within the company.

2. The software must be open for inspection with a locally reproducible build. Or accredited by a trustworthy provider such as Microsoft.

Failure to meet those requirements and the proposal is dead.

It's above your pay grade. If I were you, I'd reach out privately and suggest that the customer seek a competitor's product that has the features that want, and tell them that there is no desire within the company to support free software or self hosting.

Perhaps it would be worth checking with the !homelab@lemmy.ml community and see if they have any advice? They are more likely to have dealt with such situations, by nature.

The only way to meaningfully advocate for it after your company already announced their conditions and offerings is to present value gain.

What do you suggest concretely? What should be offered under what conditions? What would that mean as cost? What would the benefit be? How substantial is it?

Reaching out privately to them is certainly going beyond what you are employed for. I don't know about ill-advised - if you never disclose it or are at least mindful of that. But it's a personal assessment. You seem to be willing to invest a lot into a single customer, who tries to do something not offered or considered by the company. Whether it's personal interest, or first a broader better understanding of the use case, I can see how it could be worth or worthwhile. But I wouldn't get my hopes up about changing the opinions of your company [from their information alone].

Your company offered API access. So there is an interface available. They won't make it free unless they see and deem it worth it to do so.

What are the suits specifically objecting to? Ie. what are the reasons they don't want to do this? If you don't know the exact objections and can't find out due to whatever reason, then you'll probably have to take an educated guess.

When you know what they're objecting to, you can then start thinking about whether the problems or obstacles they see are even valid in the first place or if they can be solved or worked around, and form an argument from there.

Asking a little bit more information from the client might be a good idea; you can build an actual business case out of it if their case is generalizable enough, and even if not it might still be useful. If you can get a developer in the loop on this it might be helpful, since they'll know better what questions to ask etc. if you're not clear on what the client wants to do and why it didn't work, and a developer could also help you with doing a quick guesstimate of what would need to be done. Don't want to go too far into planning at this point though, just enough to be able to make some sort of business case out of it.

Also, suits like money; you'll want build an argument where you can ultimately conclude "so if we do this, it'll make us $ X over K years based on these estimates, and it'll only cost us $ Y and we can outsource the development to this person here"

I only choose to buy hardware that I can connect to Home Assistant, because I can still use it if the company goes bust or no longer supports it. I have one dashboard in HA that manages all my different devices. Point is, I still buy the hardware and the sale is made. I'm not going to buy 5 different standard products which must all be managed through separate apps. Open standards can open up to a much bigger market. There is good reason why so many OEMs opened up to the Matter protocol.

But as I say, I check first for compatibility, then I narrow my choices from there. So yes, right now your company's IOT product won't get onto my radar. Been there, done that, and got a handful of dead paperweights to show for it.