Announcement

Collapse
No announcement yet.

new installer is HORRIBLE

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • completelyhis
    replied
    Originally posted by nightwalker View Post
    Wow, does this really have to be this hard? To me anyway, any time I do an update for anything on a system be it HS or any other program I prefer to be right there in front of it. RDT works just fine but, I still prefer to be there if I'm upgrading or updating something. If i can't be there then the update can wait till I can be. I understand for a remote system you have no choice but to log in remotely for some things but updates are not one of them. Just my personal opinion of course.
    I agree. I was right there in front of Alfred when i had my morning of horribleness, though. So, FWIW, the fact that you have to be right in front of or even RDP into it is a non issue for me. the aforementioned difficulties are my gripe.

    Leave a comment:


  • zimmer62
    replied
    I get it... I just don't like it. I know the problems are separate but related.

    Knowing that homeseer could halt during startup is an uneasy feeling.

    I also understand that when applying updates you should be there... makes sense. Something goes wrong, you might need to fix something.

    Lets go back to the whole been doing this since 1.7.

    In 1.7 it was a windows application, not a web application, so being local or RDP'd in was to be expected. I can also tell you that adding events and seting up devices was WAY easier with a windows front end, but we don't need to get back to that conversation either... You made the decision to move towards all web-based (this is backwards from that, and NOT web based)

    I'm my opinion this is a step backwards... I really don't need to see a dialog box everytime I want to install or update a plug-in. I've seen organizations install very complicated software on 1000's of machines automatically without a hitch or hiccup or needing to go on location or RDP in to hold each computers hand during the installation... If a plug-in needs specific information from a user such as paths or something I get it... but clicking next on a dialog box, and I agree, and ok, and ok again etc... and then it's done and then click ok again is something that could just happen automatically.

    Going back one more time to my real point...

    Blocking operations with automation is unacceptable when you rely on the system to perform more than one function.

    I wouldn't want my furnace to stop working because I didn't get my mail from my mailbox yet right? I rely on my house to perform both functions and even though there is a phone bill in the mailbox that needs my attention the furnace doesn't wait for me to get the mail out of my mailbox to keep the house warm.

    I'm using that analogy because while I need homeseer to startup and run, I also need it to do things unconditionally. And even with HSPro and the watchdog it won't catch the case of homeseer sitting there waiting for user input when what I really want it to do, is just keep on doing what it was doing before it asked me a question..

    Leave a comment:


  • nightwalker
    replied
    Wow, does this really have to be this hard? To me anyway, any time I do an update for anything on a system be it HS or any other program I prefer to be right there in front of it. RDT works just fine but, I still prefer to be there if I'm upgrading or updating something. If i can't be there then the update can wait till I can be. I understand for a remote system you have no choice but to log in remotely for some things but updates are not one of them. Just my personal opinion of course.

    Leave a comment:


  • completelyhis
    replied
    Rich,
    I agree. I'll reitterate the core issues I had:
    1. having to restart HS AND the pc several times, to install one simple update
    2. staring blankly at a screen waiting for it to finish, when all along it was finished, and secretly hiding behind a window, mocking me :-)
    Both of those issues will/would be resolved with the separation of the exe installer from the updater process.

    Thanks,

    Ian

    Leave a comment:


  • rjh
    replied
    This thread is bizzare, HS has been displaying prompts after updates for 10 years, so I am surprised there is now a concern. HS will NEVER automatically apply an update, it is done this way so that a stable system is never changed unless YOU change it. If you are updating the system for any reason, you need to be sitting in front of it or connected via remote desktop. I just don't see any issue here that we need to deal with.

    In my opionion, you NEVER want to update an unattended system without having full access to the system just in case the update fails, this goes for Windows Update also. I would highly recommend that you do not have Windows auto update, just have it download the updates then install them when you have full access to the system, this is how I update all my systems.

    Leave a comment:


  • Rick Tinker
    replied
    Exactly - if you don't install any updates until you are ready to restart the system, then there is no problem.

    I have run the W2C for several years now and never had it prompt me for anything - production system and development system.

    Leave a comment:


  • completelyhis
    replied
    Joe,
    The two issues are related, but separate. I think you have a very valid point with the w2c diag. boot up problem. That would totally tick me off, but is separate from the installer process. assuming you never select any updates without rebooting (just leaving them in there waiting until the next reboot, intentional or otherwise), you wouldn't have the w2c problem with the installer.

    Ian

    Leave a comment:


  • zimmer62
    replied
    Gulp, not the answer I wanted to here.... There are situations where the restart of homeseer is out of my control, and may happen at a time where monitoring it is not possible. After power outages, is one example. This goes beyond the level of just a new installer, it applies to everything that happens during startup. (An example is my homeseer fails to boot right now because it's hung up on a dialog box with the HiPhone driver... I click retry and then homeseer can finish...) I'd prefer that the rest of homeseer keep on trucking without a failed feature, or a delayed feature... (As with the media plugins why should I be waiting for indexing my library before I can turn on and off lights?)

    Here is where I see great concern...

    I'm thinking of setting up homeseer at my parents cottage so that things can be monitored when they arn't there, or during the winter when it's closed up.

    Say there is a storm which knocks out the power and internet for a while. (long enough for a UPS to die)

    Power comes back on but the cable internet takes a few days to get repaired.
    Maybe one thing homeseer is supposed to do is call us using homeseer phone if the temperature drops below a certain temp. Or call us to say that the internet connection is down. Etc...

    I still want homeseer doing it's monitoring, not sitting at some screen waiting for a prompt. Can't RDP into it (internet is down), and might not even know to go check on it since 200 miles away the weather is fine.

    The panic to show up in the spring and find the furnace failed which caused lots of issues, or driving 200 miles to figure out why homeseer didn't call me on it's weekly status update isn't a pleasant feeling.

    It used to be an understanding that you don't run home automation on Windows PC's and expect 100% reliability, but times have changed. (Hometrollers etc.) This is a problem which could be overcome, monitoring the startup process (not by sitting and watching it with my eyes, but by using automation to do so) The software should start, and pay attention to what's happening, or at least spawn off these things in a separate non blocking threads, allowing homeseer to function normal even if something got overlooked.

    Blocking processes are awful.

    I've noticed that when Homeseer is ringing the internal phones getting ready to speak something.... it stops processing anything else? I just don't understand why blocking processes are used anywhere. I shouldn't have to queue up turning on the lights, then answer the phone, and then homeseer turns on the lights..

    Sorry I'm going on a rant, but part of hs2 getting rid of the windows interface was so that everything could be done from the web interface.. It's just simply not so.

    What about people running as a service (I'm not one of them, but what will the installers do on startup in that case?)

    Leave a comment:


  • Rick Tinker
    replied
    Zimmer,

    You have been heard! And while I am in agreement with you about the particular prompt that is in there now needing to be removed, I have to point out that the updater has had tools available to application providers to prompt for things and ask questions every since its inception in HomeSeer 1.7

    We cannot control whether the uses of these are legitimate for each package or not, but the bottom line is that restarting HomeSeer after an update is something that should be monitored - ALWAYS - because these tools do exist. Even if we get rid of the prompt we have been discussing here, there are other ones that could exist. That is what you have RDP for.

    Leave a comment:


  • zimmer62
    replied
    I'm going to say this again....

    http://board.homeseer.com/showthread.php?t=131878

    I'm extremely displeased that an installer would require any windows forms user interaction when starting homeseer.

    To have to RDP into my homeseer box to figure out why it didn't restart after performing updates to plugins is NOT a good idea.

    PLEASE PLEASE PLEASE make installer run in silent mode and don't require any user interaction for homeseer to start.

    If it happens after homeseer starts so be it, but to prevent the further loading of the application and halt until its done is just awful.

    It's things like this that make homeseer unreliable. Homeseer must start everytime, without user interaction. At the very minimum put a timeout on these installers so that if they don't complete, homeseer still will start...

    Leave a comment:


  • Rick Tinker
    replied
    Rich just told me that the installer EXE does not check to see if HomeSeer is running, which means this should have worked the way we wanted. I suspect that Ian's situation was caused by the plug-in DLL being loaded because perhaps WMP was still running - that was the plug-in he was installing. It would have stopped loading the plug-in if the file it was trying to replace was locked, which is what happened to Ian. I am seeing if we an get the activate plug-in dialog box completely removed - handy when you run it stand-alone for the first time, but not really necessary the rest of the time - it is better not to hold up the startup of HomeSeer.

    Leave a comment:


  • Rick Tinker
    replied
    Originally posted by Wadenut View Post
    I kept quiet last night because I didn't expect things to go in this direction. The Updater provides one stop shopping. Indicates which plugins are installed, version installed, version available, etc. It allows plugins to be installed remotely, which is important to me, while at the same time automating the entire process. The only thing it lacks is an uninstall facility, which to be honest has never been a problem for me. It's easy enough to disable a plugin as things are. When I feel the need to eliminate a plugin I no longer use, I simply delete the DLL.
    Surely we don't need to lose this. I vote for the updater. I hope I'm not the sole dissenter.
    You aren't because that is where my vote lies as well, but I think we can have the best of both worlds. The first step is to get rid of the Updater ASPX page and move it into HomeSeer with the other web pages so that it works more reliably on systems. The next step would be to change the installer EXEs to not check for HomeSeer to be shut down so that they can be run during the startup time when the updater installs things because that is before HomeSeer has loaded the plug-in making it impossible to update. This would mean that to also post updates to the message board that we would need two versions of the installer EXE, and so this is where Rich will have to determine if that is something we want to do. My preference is to have only one version and keep the updater the place to go for updates. However (again), we did change our 3rd party policy last summer to no longer put free plug-ins in the updater, so we would still have the installer EXE template that does installs that check to make sure HS is not running for free plug-ins posted to the message board, and then one template that creates the installer for use with an updater package.

    Leave a comment:


  • completelyhis
    replied
    "automating the entire process"

    - My process was not very automated. Other than that, I completely agree with you. It is nice to be able to see versions, what's installed, what isnt, do it via the web interface w/out having to be in front of the machine (which I can't currently do because of the way the exe works).

    is it posible to keep the best of both worlds? I want my cake, but I want to eat it too :-)

    Leave a comment:


  • Wadenut
    replied
    I kept quiet last night because I didn't expect things to go in this direction. The Updater provides one stop shopping. Indicates which plugins are installed, version installed, version available, etc. It allows plugins to be installed remotely, which is important to me, while at the same time automating the entire process. The only thing it lacks is an uninstall facility, which to be honest has never been a problem for me. It's easy enough to disable a plugin as things are. When I feel the need to eliminate a plugin I no longer use, I simply delete the DLL.
    Surely we don't need to lose this. I vote for the updater. I hope I'm not the sole dissenter.

    Leave a comment:


  • rjh
    replied
    Our goal is to have a single web page that you go to, select the update you want, download it, and execute it, just like any other update to an application. Its simple, its more flexible, people understand it, Google can find it, and you can uninstall any plugin if you don't use it anymore. Plus the new installer allows us to custom things on install like automatically activating the plugin, updating INI files, etc.

    But like Rick said, we don't have installers for all the plugins yet, so until we do we have this "hybrid" solution. Soon we will have the web page up and both will be active so you can choose which one you want to use. I hope that will happen soon. Sorry the confusion.

    Leave a comment:

Working...
X