Should UDI push updates to customers?

[bpwwer]

This is a poll to get a general idea on how customers would like to see updates handled.  With the eisy, the various components UDI creates are becoming more interdependent.  This means that updating one, can effect others.  Because of this, the more reliable way to handle a lot of updates is to simply reboot the eisy to make sure everything starts correctly and is in sync.  

Updates typically add new features but may also only be bug fixes.   In the past, it's been mostly left up to the user to "pull" the update, however, we are seeing a lot cases where user's are running older versions of components and then reporting bugs that have already been fixed in newer versions.  So there are pros and cons to "pushed" vs. "pulled" updates.   What's your opinion?

 

[larryllix]

I was all against forced updates but after the bug complaints on old versions comment...now I am undecided.

Maybe the usual forced push update load but user time decision when to install.

Only danger I see is being half way around the world and an introduced bug shuts me out and there is no remote fix. Been there, done that previously with other problems on ISY

Sent from my SM-G781W using Tapatalk

[bpwwer]

Being aware of the pros and cons of both ways, there's not a clear "single solution" that works for everyone.  But it is clear that communication is key to however it is handled.

Also, when things go bad, it doesn't really matter if it was a pushed update or a pulled update.  It just needs to be fixed as quickly as possible.

[MrBill]

I'm very happy to see this poll.   After recent events I've come to some conclusions that I personally am very against forced updates, but why not let the user decide the level of automatic that they want.   Perhaps with options like "Auto", everything happens (hopefully) automatically, "Download only" - download but don't install, "none" no auto updates.  Perhaps a check box, for "no updates that require reboot"

Personally, I don't want an update to take place, if I'm out of town.  Either it could break and I wouldn't know right away, or I could end up doing remote work when I need to be doing something else.  For time management aspects I would prefer to control when an update is installed, example I also run Home Assistant, and for the major update at the beginning of the month I choose to wait a few days and load it on a day that I can afford to spend a few uninterrupted hours if something goes south. I also make it a habit not to make too many changes to my ISY in the weeks before I leave town. 

I'd also suggest that there should be a method to roll back a node server update to the previous version.  I've been watching the discussion in this thread and I think it points out the obvious, something was wrong with an update, but the developer doesn't have any time until "next week", or maybe some other circumstance could arise.  Should the user need to wait if the prior version worked?   It shouldn't be hard to implement, create a last_version.tar of the node server directory, so it can be unpacked and used if necessary.

I've also got to point out the forced reboot of yesterday of eisy's running PG3x and IoX 5.5.9.   That didn't go well for some people.  While early on in the thread @bmercier mentions it should only amount to a few second, but it takes much longer for IoX to get up and running and happy again after a reboot.   Another point on reboots, is I write complicated ISY programs, and sometimes at reboot something comes up that I didn't think about-- most of the time I try to remember to take startup into account and create a program to run on startup if any re-initialization needs to occur... but sometimes I forget, or sometimes forget a possible condition.

While I personally don't want updates to occur unattended some people may be more interested in that occurring, so I vote for options.

 

 

[bpwwer]

Great comments @MrBill 

I agree that options are always good, but options aren't free.  It takes resources to implement them in the code and more resources to maintain multiple options.

I didn't want to make the poll to complicated and appreciate the comments like yours to provide context to the results.

[MrBill]

4 minutes ago, bpwwer said:

but options aren't free. 

Then don't update automatically. 

UDI should then deprecate old versions, that is no support for 2 versions ago and beyond.  If support is requested on an older version the answer should be please update and retest.

[DennisC]

I also don't normally like forced updates for anything. This is especially true while I am not home or even worse, traveling.

As a result of yesterday's forced update, at 6:00 pm last night I finally got around to looking at my notifications from throughout the day. I receive some notifications during the day that update me certain things around the house. It was at that time I realized my ZWave thermostat notifications had no value associated with them. 

For some reason, and I have noticed this since I have been on IoX that some device do not update in the admin console (and notifications) until they have been queried. I had to go to both of my thermostats and query them. After that all was good.

It is not a communications issue, as there has never been errors or commands not executed, and this only started with IoX.

However, I also acknowledge the concern over some systems not getting critical updates and/or reporting issues that have already been corrected. Maybe as previously suggested some type of notification system (possibly email)? 

I would have to vote no forced updates.

[Geddy]

@bpwwer

I agree with @MrBill about not forcing/pushing updates. His thoughts about possible updates being pushed while away are huge. And we've seen a lot of users on here that have systems in two houses and one might be their seasonal home so long distances between properties. While I see that the desire is for PG3x to be accessible remotely, much like IoX, that's a plus, but sometimes when traveling the last thing I'd want to do is be stuck on questionable wifi in a hotel (or somewhere else) and trying to troubleshoot/fix/band-aid a system back home. 

 

57 minutes ago, MrBill said:

UDI should then deprecate old versions, that is no support for 2 versions ago and beyond.  If support is requested on an older version the answer should be please update and retest.

This makes perfect sense! Usually that's what the forums replies have been if somebody came in and was running an "outdated" system. Especially since eisy and PG3x release. But also during the ISY994 v5.x transition.

This brings me back to a comment on the forums a few months ago about perhaps UDI has a new page/area on their website showing what the "Current Supported" versions are. Yes, it is another place to keep up with something, but would be a simple place for those that are more active on the forums to point others to for an "official" listing of what versions are tested and supported "at the moment". If users aren't willing/able to update to the latest versions then the forums remain the place to get the user-to-user help. But from the official support it should be limited to only the most recent builds. As you say...new builds should be fixing the bugs that many might experience on older machines.

 

However, the big "BUT" to all this...there has long been those that just setup the ISY994 and never touched it again. I think what IoX (and Polyglot) has evolved the system into can no longer be considered a "set it and forget it" type of system. There are just too many moving parts if you have any node servers integrated into your system. So the issue becomes how involved will users be in maintaining their systems? That's where it gets dicey and could leave the door open to having options of how/when to update/upgrade. 

Good luck! No "easy" way to make everybody happy, but at least the question is being asked. So thank you for that!

[gzahar]

I am totally in @MrBill ‘s camp. Especially when we have to manually deal with broken node servers when an unplanned reboot/restart forces it to update.

[matapan]

Home Assistant seems to have a good model for this. If the update doesn't work, there appears to be a feature allowing rollbacks. I have no experience with that, as I have thankfully never had HA not comeback from an upgrade. But their model seems pretty sensible.

[jec6613]

1 hour ago, matapan said:

Home Assistant seems to have a good model for this. If the update doesn't work, there appears to be a feature allowing rollbacks. I have no experience with that, as I have thankfully never had HA not comeback from an upgrade. But their model seems pretty sensible.

Sort of?  I've tried HA several times, their rollback doesn't work well unless you're in a VM template.

pfSense, which runs on FreeBSD like eisy and Polisy, have some other rollback features.

Either way though, an unexpected restart from an update is going to cause me problems.

[mbking]

I prefer being notified that an update(s) is available and letting me plan a time to actually execute the update.  I like to monitor the update process so I can report any unusual beeps or messages I might get during the update.  And most importantly, I want to create a backup of IoX, PG3, and UD Mobile before doing the update.

I think it's reasonable to expect users to be at the current version when reporting issues unless the issue occurred during the actual update.  Most companies will ask you if you are on the current version when you call for help.  UDI should be able to expect the same thing from us.

With so many systems making up the whole now, I don't do interim updates anymore.  I wait for a notice under the assumption that all the necessary pieces will be updated and will work together. I would like the notice to come in the form of an email or other automated notification instead of waiting to read about it on the forum, AC, or UD Mobile.

[TRI0N]

Why not make it easy and just add checkbox for Auto Updates. Done deal...

I guess it would depend on the user, its purpose, etc. But at this time I would never enable the feature. Reboot causes problems and even if that was no longer an issue, I'd still opt out. While I have one at home and it's purpose is pretty critical to not have it crash on a reboot. While the one at the office only controls lights and that would be feasible for some, it's still too critical for me not having things properly restoring upon reboot.

 

TRI0N

Edited March 26, 2023 by TRI0N

[larryllix]

5 hours ago, matapan said:

Home Assistant seems to have a good model for this. If the update doesn't work, there appears to be a feature allowing rollbacks. I have no experience with that, as I have thankfully never had HA not comeback from an upgrade. But their model seems pretty sensible.

That sounds like a great idea and sounds simple to keep a complete duplicate system, to me but...

...if there are bugs there may be no recovery back to a previous version to the controls system to recover may be crashed.

[Bumbershoot]

I make a backup of IoX every time I make changes, so I can likely survive an IoX update that doesn't go well fairly easily. However, upstream FreeBSD package updates can now break things in ways that would never occur on the ISY994 - node servers seem particularly vulnerable to this - so I'm very much in favor of some sort of update management that UDI, and only UDI, control the content of.

Disallowing (or at least not supporting) command line updating has been a good start.

For my particular purposes, once IoX reaches feature stability (after Matter is enabled and hopefully settles down), then I'd suggest an option for automatically updating outdated installations to one version behind current after a new version is released, in order to maintain free support.  By this I mean IoX/PG3x versions, not FreeBSD versions.  It would be up to UDI to manage the host OS. 

This would put the onus on people to either maintain a Portal account or update their systems periodically, which would no doubt cause some users untold anguish and cause others to abandon the platform.

Personally, I don't expect UDI to support every outdated version of IoX/PG3x/FreeBSD that was released, forever.  That's crazy.  At some point, for some folks, there'll be some pain.

For remote installations that do not maintain an Internet connection, or for installations that just fall behind, then some sort of paid update service wouldn't be a terrible idea.

[MrBill]

I have a strong opinion that I feel the need to re-state.  It's important not to cause reboots, or push changes that may break a local installation.  It's my understanding that even after the attention focus on last weeks unannounced portal induced eisy reboot, there was another one of those this morning during portal maintenance.  

In a perfect world everyone's ISY/IoX will reboot and chug onward.  But what if they don't? What if update causes 1000's of ISY's not to restart correctly?  What about a new ISY program that the owner hasn't taken into account startup conditions?  What if the owner is on vacation in Timbuktu, or sailing around the world with no wifi?  or on the beach margarita in hand?  Automatons that I have for convenience when I'm home are nice, but I RELY on automation when I'm out of town.

[sjenkins]

Just want to echo both points made by @Bumbershoot& @MrBill. 

I rely on my automation & am away regularly. I also do think this small company would do well to focus on up to date systems (free) with paid options for older (revenue). It actually may speed up the path to stabilization which is a main reason I am with UD for 12yrs. 

Not my choice to make for them but we get to voice an opinion. Also, none of this is to be critical to anything UD is doing, just encouragement. 

[fmk2]

I prefer an option where updates get pushed to the device and I'm notified that they're available, but don't get activated until I say so.  That way I can make sure they are implemented when I'm around to monitor the result.

That said, I'm probably OK with being nagged (via recurring emails, maybe?) if an update doesn't get activated in my system for some prolonged period of time.  But of course then you have to define "prolonged period of time"...

[brians]

They should use ZFS and snapshot before each upgrade, if something goes wrong then can easily revert back.

Since this is in EISY forum, what about Polisy also?

 

 

[Ross]

It is confusing to me what the current version is of everything.  I'm still an ISY/Polisy guy and I haven't been able to update my Polisy for a few months.  However, it still works, so I concentrate on other things in my life that need fixing!

It would be nice to get a notice "You are on version 1.5.  The current version is 6.7. Please update by following these instructions: Link".   I recently went on a couple of business trips and couldn't read these forums for about 3 weeks.  I don't have time to go back and see if I missed an update or something important.

I wrote the following post about 6 weeks ago from what I could glean.  It was probably incorrect then and it's definitely incorrect now, but it would be nice if this were posted somewhere convenient and kept up to date: 

Current Versions

EISY PG3x - 3.1.22

EISY IoX - 5.5.5

Polisy PG3 - 3.1.17

Polisy IoP - 5.5.5

994 - 5.3.4 for those using 500 series Z-Wave

994 - 5.0.16c for those using 300 series Z-Wave

Thanks,

Ross

[Geddy]

3 hours ago, Ross said:

it would be nice if this were posted somewhere convenient and kept up to date

Quickest place to find current releases is in the "Current Release Announcement" area of the forums. While not a clean list like you've got above it is only the "current" versions for UDI Releases. 

The good thing about that area of the forums now is it  is truly only an "Announcement" type post. Not 100 replies of help. Those are the "Support Thread" for each release. 

 

[MrBill]

2 hours ago, Geddy said:

The good thing about that area of the forums now is it  is truly only an "Announcement" type post. Not 100 replies of help.

For those that don't realize the significance of the current releases area of the forum being locked down, it was done so that users can subscribe to that section of the forum.. and ONLY get release announcements and not a lot of noise following.   Go here and click "follow" on the right side of that screen.

[EWhite]

just add a check box so those who want to be automatic can do so.

those who wish to be in control, can be by not checking the box and doing manual updates.

just my 2 cents

 

[bpwwer]

First off, I want to thank everyone for responding.  There are a lot of good suggestions and comments.

I do want state that this poll was something I put up without any prompting from UDI.  We've all experienced issues with the updates lately and I just wanted to get some idea if pushed updates might be helpful.  And personally, I've been thinking about the all the problems with the PG3(x) node server auto-update feature.

Based on this, I've decided to remove the auto-update from PG3(x).  Instead, it will still pop up notices when updates are available and it will add an "Update" button to the node server details page that you can use to update when it is convenient for you. 

I've also been thinking about the ability to roll-back to the previous version of a node server.  I think the ability to do this exists today, but it needs the node server developer to configure the store entry to support it.  So I'll experiment with this and if it works, I'll provide the node server developers with instructions on how to set it up.

And while I don't work any of the other update process, there is on-going work to make the process more robust and provide better communication about what is happening during the update.

The poll remains open, probably for another week so please continue to provide comments.

[tjfhartmann]

Yes