Hub Firmware Release Notes - 17.12/17.13/17.14

17.1 through 17.10 were internal or beta only. 17.11 was the first release to go out for general release.

2 Likes

I’m up at bat for tomorrow. I’m confident of success at this point!

1 Like

Not home, but see where hub went down then up. Showing right version. I am assuming everything is golden since I didn’t get a nasty gram from my family that things are not working.

I’ll sacrifice some steaks at the altar … umm, barbecue … to appease the Update Gods …

3 Likes

Thank you for that reply Nick, but I’m not sure what it means. Is there zero difference between 16.14 and 17.12 then?

I do not even know how high the sub-versions of 16 went (16.14 to 16.?). Maybe there is a place with details of each release, that I don’t know about? All I know is that I got an email about the pending update that said I was being updated from 16.14 to 17.12 and:

A brief summary of the changes is as follows:

  • Numerous stability improvements and bugfixes
  • New diagnostics for hub problems
  • Ability to selectively enable automatic updates for some devices
  • New, more reliable update delivery mechanism

Then linked to this thread. But if there are supposed to be details here, they appear to be hidden in the 170-odd messages.

What are the practical differences between 16.14 and 17.12? Any usable functionality differences I might want to know about? One would think that with such a gap there would be. But maybe it was all infrastructure.

Thanks if you can help.

Sorry about that, I misunderstood what you were asking. It has gotten a little tangled to get the details.

The changes in 17.12 versus 17.11 are only bug fixes in the update process. The description of what changed between 16.14 and 17.11 can be found in the original 17.11 discussion

Update, now 2 more doors dropped off.

I’m currently on 000.017.00012. What should I expect? My Hub went offline today after I got an email yesterday saying it was going to update today. But it apparently is not at 17.11 or 17.12, but at: 000.017.00012 (Unless you are leaving out the ZEROS when you talk about the versions.)

Confused.

Zeros are generally left off… it’s padding for internal iterations

I suspect this is likely not explicitly tied to the firmware, but more about the Zigbee network rebuilding after the reboot. You might find that if you disable/re-enable device health, the sensors will begin reporting again. If not, you might (unfortunately, I know) need to unplug and replug a repeater somewhere in the network. If you are having continued issues, contact support and we can help.

I disabled device health and they came back. But if I enable device health they go away again. So I am leaving device health off untill I get home on Monday.

I just got my email, I am up tomorrow, please pray for my hub, LOL!

2 Likes

Not sure what happened but my hub has been down for awhile now. When I go in and ping it, I get “The hub responded 10444.834 seconds ago, on Thu Apr 06 21:11:07 UTC 2017” which is 17:11 my time. Three hours it has been down and I don’t know how else to give it CPR. Unplugged, restarted, pulled the batteries… I think its dead… :frowning:

I had this before the update. The unavailable has been happrning to people. I think the device health is still a little buggy.

See this thread is where I was directed to look.

I just waited for 45min after the hub was back online to see all my devices connected again. Most wereresumed within a few minutes though.

My window was, “12:00 pm EDT and 4:00 pm EDT” and nothing yet on either hub! Keeping fingers crossed, as we leave next week & won’t be back here 'till November…

Mine did the same think, except it went offline twice. It was still showing the old firmware. I went into the IDE and rebooted the hub, now on 000.017.00012. So it looks like you need to reboot hub if not showing the 17.12 firmware.

I echo a lot of the sentiment communicated here. Smarthings engineering really needs to get their collective feces together. 70% of the time you guys update/reboot my hub I need to troubleshoot new problems. I’m close to the point where I need to find a new home automation hub from a company that takes this MUCH more seriously. I assume you are all working toward the smart home of the future yet you keep making those that have to live with our technology leading philosophy pissed off that their smart home just got dumber !

In case you were not aware. I for one expect that any standard switches, sensors, lights, locks etc… should always work. Period. The more you do that interferes with this simple philosophy, the slower you will make the migration to smart homes. Your Mission Statement should include a line similar to “It just works !”

Now if you’ll excuse me I have to go and troubleshoot my system after you upgraded it and rebooted it without my permission.

1 Like

Now another email says, “Friday, April 7, between 12:00 pm EDT and 6:00 pm EDT.”

Does that mean one hub today & the other tomorrow? Or has today’s update been postponed?

Device health probably (rightly) saw that some devices could not be contacted during the update and marked them offline. They should be marked online again once they perform a regular report after the hub came back online. There is currently no special logic here to attempt to contact the device again when it comes back online, so the device-specific regular reporting period would need to be hit before the device is marked online again.

Future updates will be much shorter than this migration update, so this generally should not be a significant issue moving forward (the device could still miss one report, but would probably not miss 2 which is generally what is required for it to be marked offline).

If you have multiple hubs, it is possible that they are split across days. If a hub was supposed to update today but is still reporting the old version, you may need to disconnect/reboot the hub to get it to report the new version as has been noted elsewhere in this thread.

1 Like