new installer is HORRIBLE

[nightwalker]

Why not just go with the exe installer/un-installer and dump the updater, it's cumbersome anyway and I'm sure there is no one using the program who is not familiar with how to install software. It's really not that tough, shut down HS, run the EXE, start HS, do the config, done.

[Bill Brower]

Why not just go with the exe installer/un-installer and dump the updater, it's cumbersome anyway and I'm sure there is no one using the program who is not familiar with how to install software. It's really not that tough, shut down HS, run the EXE, start HS, do the config, done.

Agreed. I like downloading from the message board and installing manually. Plus, if you kept the old installer it would be easy to rollback a plugin. Unless I am overly simplifying this.

[completelyhis]

i also agree with my brothers in arms. It would be important, however, that the downloads be centralized. in other words, I can see myself thinking

"where is the current version of that? Updater? forum...which thread was that? HS web page on downloads? I don't remember?"

I don't really care which location it is as long as

1. it is easy for me to get to and find
2. it is easy for hst to manage.

I agree, though, i like the exe process, especially for what you mentioned about the uninstall. I don't like the hidden message box, though. other than that, make it a separate process from the updater - download, install, restart HS. easy money.

thanks Tink, for the response.

[rjh]

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.

[Wadenut]

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.

[completelyhis]

"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 :-)

[Rick Tinker]

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.

[Rick Tinker]

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.

[zimmer62]

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...

[Rick Tinker]

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.

[zimmer62]

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?)

[completelyhis]

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

[Rick Tinker]

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.

[rjh]

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.

[completelyhis]

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