To be fair, from a support standpoint that's the only thing they really can do right now.
Now if there were better troubleshooting/diagnostics in the platform so that we could see where underlying problems originate from other than log errors, maybe we wouldn't have to blindly troubleshoot by disabling user code.
Yeah a little impulsive of me I know. I had edited my post on the between
Just find the argument disable everything just to see if it works funny when the community can't even troubleshoot the issues as there isn't any debug tools.
I see both sides of the argument. They can't support everything...
But I still believe that this support stance will limit growth of the platform at some point.
They can't support everything internally, so I believe they need to have a framework in which user code and user drivers can be properly allowed/coexist/triaged.
I have the hub sitting on my desk. I just have to find the time to start poking at it.
But the problem is much larger than just the xiaomi devices. I have a custom driver for almost every Z-Wave device on my hub at this point, because the built-in drivers only provide the minimum/common functionality.
As soon as they tell me to turn off all user code, it might be time to just switch to a different hub. Because I would basically have to disable everything, and that isn't tenable.
Is not about them supporting everything is about not having the right tools for debug and assuming that the community code is ALWAYS at fault even if it on the majority of the cases.
I recommended to bravenel the implementation of containers and separate processes for stock and community as a solution. It would avoid this all together.
I won't speculate what they do or don't know, or how they feel about this topic. I just know what I've already said, that this support stance isn't long-term viable in my opinion.
I don't know all your backgrounds, but I used to manage teams of developers writing enterprise application software running on IBM Websphere. If one of them came to me with a problem with the system that they were not sure where it came from, first thing I would tell them is to remove their changes and see if the problem is still there. If instead they insisted on leaving all of their code in place and decided to fire up the monitoring tools, start doing heap dumps, wading through them and wanting to profile the application, I'd have to sit them down for a serious conversation.
In addition if we could not figure out the problem, we gave IBM a call and asked them to take a look. They were happy to help us out for an hourly fee. Which seems crazy, right? We paid them all that money in licensing fees and now they want more money to help us figure out our bad code? They really should have done that for free. /s
You will probably take this as rude, it's not intended to such, but the answer is they should have architected it in a more compartmentalized way so that user code couldn't take down the whole system...
If VMware or Microsoft took that stance they would both be out of business, because it's all about the user code.
If Microsoft said only load blank spreadsheets into Excel, we'd all still be using quattro pro.
Again, it's not the end of the world. But as the user code base grows faster than the built-in code base - which I believe will happen as you get more users - this is going to be an increasingly problematic issue.