Homeseer HS2
- Thread starter Guy669
- Start date
pete_c
Guru
Here I have been using Homeseer now since the late 1990's.
I also have been using an HAI OPII (s) now since the early 2000's.
I play a lot here in my home automation sandbox.
Homeseer today offers me the opportunity to play with multiple "things" IE: today main HS box has some 16 plus 5 USB port and XX connections to it.
Pending here building a quadrifilar helix antenna such that I could attach an SDR radio to my Homeseer box and download weather maps live from NOAA satellites. I was going to do a blog on it. Its easier to do this endeavor with my HS box rather than my HAI OPII panel.
I don't need Homeseer to do this but just giving it another "automation" function. I always am trying to break it.
I also have been using an HAI OPII (s) now since the early 2000's.
I play a lot here in my home automation sandbox.
Homeseer today offers me the opportunity to play with multiple "things" IE: today main HS box has some 16 plus 5 USB port and XX connections to it.
Pending here building a quadrifilar helix antenna such that I could attach an SDR radio to my Homeseer box and download weather maps live from NOAA satellites. I was going to do a blog on it. Its easier to do this endeavor with my HS box rather than my HAI OPII panel.
I don't need Homeseer to do this but just giving it another "automation" function. I always am trying to break it.
I started with HS in another house 7-8 years ago and then added an Elk. I later moved to Insteon and then an ISY. I loved HS version 1 several years ago, but about the time HS2 came out the HS Technology folks fell in love with Zwave and development resources increasingly went toward making HS work with that technology. IMO, the program also became less stable during this phase and depending on which plugins were being used, crashes and poor performance became a problem. My HS crashed often enough that I could never leave for a couple of weeks and have a high probability that things would run smoothly, and much of HS's functionality is highly dependent on 3rd party plugins, so it was difficult to figure who was to blame or how to fix it.
Because of this I find myself relying on my Elk and ISY, and have a new 994 sitting in my office, ready to replace my ISY 99, just for added functionality. Both are remarkably reliable and work well, going weeks without issue unless I do some tinkering and experimenting as I have time (and never, as I recall, crashing to the point they are a problem except for some issues with remote Elk access via the M1XEP, which is the weak link of Elk, but still serviceable).
HS, meanwhile, continues to be a problem. I fired it up on a fairly new install running only my VWS weather software about two weeks ago. It ran fine for several days with only one plugin installed and enabled (ACRF2, to read my Oregon Scientific temp / humidity sensors). But within 24 hours of turning on the VWS plugin to talk to the weather station, the VWS software crashed (it had been fine before HS entered the picture). I've tried running the VWS on a different machine from HS in the past, but somehow whenever I intro HS into the situation, I have a problem. And similar problems have occurred over time with other plugins.
So... I find that HS is a great toy for tinkering, but I just can't rely on it in its present form. It's one thing to WANT to tinker and to NOT rely on a program to "run your house". It's something else to be forced into fixing something just to maintain functionality. So HS is relegated to running toys (at best, and without depending on it) while the Elk and ISY do the real work.
HS is in beta with a new and supposedly very different version in which (as I understand it, but check with others) each plugin will run on its own rather than being tied into the main program so closely. I really hope that works, but am unlikely to test it until it is well out of beta and has proven itself much more reliable than the current program based on discussions on their board from users like Pete. I would test / tinker with it if I had more time, but will instead be focusing my limited time on the new ISY 994 and increasing my home's functionality without (hopefully) sacrificing reliability. I will, however, try to maintain a longer term hope that I can one day return to a more reliable version of a program I once really enjoyed, in HS.
Because of this I find myself relying on my Elk and ISY, and have a new 994 sitting in my office, ready to replace my ISY 99, just for added functionality. Both are remarkably reliable and work well, going weeks without issue unless I do some tinkering and experimenting as I have time (and never, as I recall, crashing to the point they are a problem except for some issues with remote Elk access via the M1XEP, which is the weak link of Elk, but still serviceable).
HS, meanwhile, continues to be a problem. I fired it up on a fairly new install running only my VWS weather software about two weeks ago. It ran fine for several days with only one plugin installed and enabled (ACRF2, to read my Oregon Scientific temp / humidity sensors). But within 24 hours of turning on the VWS plugin to talk to the weather station, the VWS software crashed (it had been fine before HS entered the picture). I've tried running the VWS on a different machine from HS in the past, but somehow whenever I intro HS into the situation, I have a problem. And similar problems have occurred over time with other plugins.
So... I find that HS is a great toy for tinkering, but I just can't rely on it in its present form. It's one thing to WANT to tinker and to NOT rely on a program to "run your house". It's something else to be forced into fixing something just to maintain functionality. So HS is relegated to running toys (at best, and without depending on it) while the Elk and ISY do the real work.
HS is in beta with a new and supposedly very different version in which (as I understand it, but check with others) each plugin will run on its own rather than being tied into the main program so closely. I really hope that works, but am unlikely to test it until it is well out of beta and has proven itself much more reliable than the current program based on discussions on their board from users like Pete. I would test / tinker with it if I had more time, but will instead be focusing my limited time on the new ISY 994 and increasing my home's functionality without (hopefully) sacrificing reliability. I will, however, try to maintain a longer term hope that I can one day return to a more reliable version of a program I once really enjoyed, in HS.
I back up Madcodger's take. HS is a great addition to my home automation scheme, but since HS 2.0, I cannot rely on it to run my house. I still have a Stargate that does all my critical home automation tasks - it's internal programming runs security lighting, driveway sensors, occupancy sensors, notifications, etc. HS talks to Stargate via a plugin, so device status is shared with HS allowing a whole world of functionality - really great and well worth the cost of HS. But if I lose HS, my Stargate keeps on going - my lighting schedules still work, I still hear the UPS guy coming up the driveway, motion detectors still let me know when if a racoon is working on my trashcan, etc.
So HS is primarily used to add goodies like touchscreen user interfaces (via HSTouch), real-time weather data,TTS anouncements, voicemail, and whole house music control. When HS crashes (every 1-3 weeks), I only lose the goodies until I reboot. I will be transitioning to ELK when I jump to HS 3 (Stargate will no longer be supported) and I plan to use the same strategy - let ELK run all critical functions, and let HS add the nice-to-haves.
So HS is primarily used to add goodies like touchscreen user interfaces (via HSTouch), real-time weather data,TTS anouncements, voicemail, and whole house music control. When HS crashes (every 1-3 weeks), I only lose the goodies until I reboot. I will be transitioning to ELK when I jump to HS 3 (Stargate will no longer be supported) and I plan to use the same strategy - let ELK run all critical functions, and let HS add the nice-to-haves.
donstephens
Member
As noted above; HS3 will handle plugins differently. Hopefully it will be as reliable as HS1 was, once it matures.
macromark
Active Member
With HS2, plug-ins load as .dll's and occupy the same memory space as the main program. In theory, this should not present a problem if everything is behaving "correctly" (ie no memory leaks or other similar problems). However, any plug-in with a memory leak can potentially bring the system down or cause erratic behavior.
The plug-in API for HS3 was rewritten and all HS3 plug-ins now run as .exe's, each occupying their own memory space. As such, memory and CPU usage can now be tracked for each process and the main program is better isolated from plug-in "mishaps".
The plug-in API for HS3 was rewritten and all HS3 plug-ins now run as .exe's, each occupying their own memory space. As such, memory and CPU usage can now be tracked for each process and the main program is better isolated from plug-in "mishaps".
pete_c
Guru
The "roots" of said methodologies do date back to the original Homeseer 1.X.
It did start though as a postulate based on statements assumed to be true but not proven. Later though it changed over to a theorems as it did get proven to work (for me it did).
Personally (relating to one specfic plugin/application that I use) it evolved into a running inside Homeseer application, running outside of Homeseer application dependant or independant of Homeseer in itself.
This is a a bit similiar to my use of the interaction between the HAI OPII panel and Homeseer. The variables float somewhat in networklandia sometimes seen or heard; sometimes controlling; sometimes not controlling; running as an "adjuvent" (my odd choice of a word here) of sorts in a paired symbiotic relationship (machines and not in a organic sense).
Its been some two years now that I have been running an original Homeseer "plugin" outside of Homeseer on a little Arm CPU some maybe 2" square off a tiny USB stick pure "meat" mostly with a customized OS which is plugin centric; no fluff, no additives still though with the same eye candy as over 10 years ago (here I picked one of those little HP USB memory sticks about the size of the USB port). It does today run independantly of Homeseer.
Ahhhhh.... though forgot; there are variables exchanged with Homeseer (mothership) to and fro networklandia such that today's "manual" interventions include just simple buttons on an HSTouch screen; such that it is really a Homeseer plugin "outside and inside" of the "box" and doing well these days.
It did start though as a postulate based on statements assumed to be true but not proven. Later though it changed over to a theorems as it did get proven to work (for me it did).
Personally (relating to one specfic plugin/application that I use) it evolved into a running inside Homeseer application, running outside of Homeseer application dependant or independant of Homeseer in itself.
This is a a bit similiar to my use of the interaction between the HAI OPII panel and Homeseer. The variables float somewhat in networklandia sometimes seen or heard; sometimes controlling; sometimes not controlling; running as an "adjuvent" (my odd choice of a word here) of sorts in a paired symbiotic relationship (machines and not in a organic sense).
Its been some two years now that I have been running an original Homeseer "plugin" outside of Homeseer on a little Arm CPU some maybe 2" square off a tiny USB stick pure "meat" mostly with a customized OS which is plugin centric; no fluff, no additives still though with the same eye candy as over 10 years ago (here I picked one of those little HP USB memory sticks about the size of the USB port). It does today run independantly of Homeseer.
Ahhhhh.... though forgot; there are variables exchanged with Homeseer (mothership) to and fro networklandia such that today's "manual" interventions include just simple buttons on an HSTouch screen; such that it is really a Homeseer plugin "outside and inside" of the "box" and doing well these days.
Dean Roddey
Senior Member
This is why we developed our CML language. We are periodically beaten on to allow drivers in any language, but have always made it clear that's not going to happen. This way we can have the benefits of drivers being loaded within a single server (we have one server that is dedicated to just hosting drivers), but don't have to worry about all of the possible bad things that an open ended language could cause.
The only thing that can generally happen is one gets caught in a loop, but that is easily diagnosed and the offender found and fixed. The real problem is when you can't assign blame, and it becomes a finger pointing exercise, which is why allowing any language to be used is so dangerous. Damage can be done that doesn't manifest itself in the code that did the damage, and an error can go unnoticed until the offending code happens to be loaded in the right combination with other code, making it more likely that the victim will be blamed than the offender in many cases.
Running them as separate executables has its own set of concerns as well, though it does certainly allow for arbitrary language usage without worries of corruption of the hosting application. The most significant issue is just increased complexity, which happens any time you increase the number of moving parts. And there will be some performance hit involved relative to a hosted driver scenario. The speed and frequency of interaction between the main app and drivers is generally very high, so having to move that across the process barrier may add some performance lag.
There's also the overhead issue. Having each one be a separate exe means each one has all of the overhead of a separate executable. We have some commercial systems with a hundred and fifty drivers. Each of those being a separate executable would be a sizeable bit of overhead.
Even when using hosted drivers, if you really need for some reason to detach a particular bit of functionality, it's easy enough to have a driver that's just a pass-through to a separate server.
The only thing that can generally happen is one gets caught in a loop, but that is easily diagnosed and the offender found and fixed. The real problem is when you can't assign blame, and it becomes a finger pointing exercise, which is why allowing any language to be used is so dangerous. Damage can be done that doesn't manifest itself in the code that did the damage, and an error can go unnoticed until the offending code happens to be loaded in the right combination with other code, making it more likely that the victim will be blamed than the offender in many cases.
Running them as separate executables has its own set of concerns as well, though it does certainly allow for arbitrary language usage without worries of corruption of the hosting application. The most significant issue is just increased complexity, which happens any time you increase the number of moving parts. And there will be some performance hit involved relative to a hosted driver scenario. The speed and frequency of interaction between the main app and drivers is generally very high, so having to move that across the process barrier may add some performance lag.
There's also the overhead issue. Having each one be a separate exe means each one has all of the overhead of a separate executable. We have some commercial systems with a hundred and fifty drivers. Each of those being a separate executable would be a sizeable bit of overhead.
Even when using hosted drivers, if you really need for some reason to detach a particular bit of functionality, it's easy enough to have a driver that's just a pass-through to a separate server.
Similar threads
