And this brings up a good point. When I initially brought up an issue with dropping connections, there were many that suggested the problem was due to running a VM...imagine if you mentioned you were running your HA software in the cloud. You'd have to setup everything on a separate machine internally to prove the cloud wasn't causing issues...no thanks.
New Home Security and Automation Design (Design the perfect system)
- Thread starter twinprice
- Start date
Dean Roddey
Senior Member
Part of the problem of course is that a non-trivial automation system is already somewhat complex when you throw in all of the environment issues that can come into play. Often it is the environment or setup or pilot error, and we spend a lot of time trying to figure that out. Before spending a lot of time digging into it, it's good to know that it at least still manifests itself within a fairly Plain Jane setup, since that makes it a lot more likely that it really is our problem, and we don't waste a lot of time digging where there's nothing to be found.
Of course we try to learn from such situations and update the product to deal with them if it was a lacking on our side, or at least better report the problem so that we can diagnose environmental issues. But the number of potential scenarios are legion so it's always a bit tough. We just went through one with Brendon, which involved code in some drivers that had been there for probably a decade or more in some cases, but it turned out to be an issue in multi-homed systems. Apparently he's the only customer with a multi-homed system in all this time. But live and learn, and that one should be taken care of now.
It's a balance that has to be maintained. Though I think that we do ultimately put in more than due diligence when someone reports an issue, and try to never just dismiss it out of hand as not our fault, even if we do want to have some assurance that it's likely that it is our fault, and to have some divide and conquer testing done to try to limit the problem to a reasonably targeted section of the code. And of course sometimes it's not always practical to try to deal with it immediately, if it would have the potential to destabilize the product at a crucial time (aka close to a release.)
Of course we try to learn from such situations and update the product to deal with them if it was a lacking on our side, or at least better report the problem so that we can diagnose environmental issues. But the number of potential scenarios are legion so it's always a bit tough. We just went through one with Brendon, which involved code in some drivers that had been there for probably a decade or more in some cases, but it turned out to be an issue in multi-homed systems. Apparently he's the only customer with a multi-homed system in all this time. But live and learn, and that one should be taken care of now.
It's a balance that has to be maintained. Though I think that we do ultimately put in more than due diligence when someone reports an issue, and try to never just dismiss it out of hand as not our fault, even if we do want to have some assurance that it's likely that it is our fault, and to have some divide and conquer testing done to try to limit the problem to a reasonably targeted section of the code. And of course sometimes it's not always practical to try to deal with it immediately, if it would have the potential to destabilize the product at a crucial time (aka close to a release.)
drvnbysound
Senior Member
An addition to the troubleshooting-type issues listed above, I don't want cloud-based services because they simply don't work when there is an ISP issue (at either end). I much prefer to keep my server and content locally.
Sure, maybe there are only a handful of outages per year, but when they happen, I'm scrambling to figure out why something isn't working, while my wife is complaining that said thing isn't working. Fun times... that I'd prefer to avoid.
Sure, maybe there are only a handful of outages per year, but when they happen, I'm scrambling to figure out why something isn't working, while my wife is complaining that said thing isn't working. Fun times... that I'd prefer to avoid.
Just to be clear Dean, there were several Cocoontech forum members that jumped on the VM issue and the conversation evolved/devolved into the reliability of VMs. So it wasn't that you ignored the issue, I just didn't want to hear any more discussion on whether VMs were reliable or not. In my case, the VM was 100% reliable but no way was I going to go through that proving process again. So I will only be running my home automation system on physical hardware from now on. As you say, it takes one possible variable out of the equation.Dean Roddey said:
pete_c
Guru
@bbrendon
Kind of did similiar to you (also utilized VMs) mostly though connecting to my home ISP (Comcast). I was always connected to "work" such that I was very dependent on my home transport for operational support stuff at 3 AM in the morning in the early 2000's.
Even got the opportunity to check out the local telco CO to get a "birds eye" view of my CC connection to the internet at the time.
Concurrently was playing a bit with mobile internet transport stuff.
IE: the home automation software was sitting at my home. I could get to it from any part of the world at any time and manage it just fine with a browser or my telephone in the early 2000's. (IE no issues with transport up time - QOS was very good). (Note other peers at the time used conventional dedicated analog T-1's (not DS) to their home)
The above was not cloudish but I did also evaluate "big data" stuff in the cloud as it existed in the middle 2000's. Mostly concerned at the time with transaction times and transport from the "cloud" to the endpoints. IE: a traceroute to the pacific rim at the time took almost xxx ms which was slow to me. (also managed capacity planning so we had the tools to look).
Note that today its way different.
Kind of did similiar to you (also utilized VMs) mostly though connecting to my home ISP (Comcast). I was always connected to "work" such that I was very dependent on my home transport for operational support stuff at 3 AM in the morning in the early 2000's.
Even got the opportunity to check out the local telco CO to get a "birds eye" view of my CC connection to the internet at the time.
Concurrently was playing a bit with mobile internet transport stuff.
IE: the home automation software was sitting at my home. I could get to it from any part of the world at any time and manage it just fine with a browser or my telephone in the early 2000's. (IE no issues with transport up time - QOS was very good). (Note other peers at the time used conventional dedicated analog T-1's (not DS) to their home)
The above was not cloudish but I did also evaluate "big data" stuff in the cloud as it existed in the middle 2000's. Mostly concerned at the time with transaction times and transport from the "cloud" to the endpoints. IE: a traceroute to the pacific rim at the time took almost xxx ms which was slow to me. (also managed capacity planning so we had the tools to look).
Note that today its way different.
