So I still do not have the new fimrware on my hub yet. Has Samsung pulled the updates again? I can try rebooting my hub by pulling the power but did not want to force anything since all is working okay right now. Anyone from Samsung know the status of the upgrades?
Thanks
If you just activated your Hub recently, within the last 3 weeks, you will still be on 16.14 for a short while longer. We’ll make sure to let you know by email when your Hub is going to be updated.
My mode is stuck in “Night” although it isht reacting as such. Anyone els having trouble with modes?
It’s possible the hub isn’t stuck but the app is. My IOS app often doesn’t update to the mode the hub is actually in. Try force closing the app then reopen and see if the mode is updated. You can also log into the IDE to double check the current mode.
Here’s a potential issue, I’d like to report/share. Some users are facing an issue pairing locks with the hub.
When the lock pairs the mfr, prod and model numbers show up as 0000 in the raw description. It happens for some locks and not others (same model, e.g. Schlage BE599, two of them show up as 0000 and the third pairs fine). It’s also happening with Yale locks.
This is an issue because some of the DH’s and SA’s use the MSR codes to make decisions, with the MSR showing up as 0000 it complicates the issue.
A few different questions to help us narrow this down:
Doesn’t make a difference, but leaving it for 24 hours make the MSR pop up correctly
No one reported this issue until this week, suddenly I saw two reports. Coincidence?
FYI, @nastevens another user emailed me with the same issue but a Yale lock. This happened with the stock ST DH, he reported it to ST support who pointed him back to the manufacturer. The same model (210) has been working fine until this week.
Hi guys, can you tell me if anything has happened on the back end that might affect UK users and their ability to execute a z-wave v1 set point command on a thermostat?
Specifically as mentioned here:
https://graph.api.smartthings.com/ide/doc/zwave-utils.html#thermostatSetpointV1/thermostatSetpointSet
Thanks.
I have been back and forth with Schlage who has escalated the problem to higher up in there development team but I have not heard back from them yet as of today. I also spent quite a bit of time on the phone with ST and they have also escalated the problem to there higher techs and I got an email back from them today letting me know they are still working on the problem. I will update as soon as I get an answer. On my end I removed the custom DH … excluded the locks and rebooted the hub … then I paired the locks again still resulting on all 0000 in the same locations as before. Now it is in ST hands and see what they come up with.
I’m not sure if this is the proper forum for this, but I was wondering if anybody else is experiencing random disconnection issues after the 17.12 firmware update? Ever since my hub updated it has been randomly disconnecting and reconnecting maybe twice per day. I don’t see anything posted about the servers having an issue, so I assume it’s a local issue with my hub. Nothing else has changed with my configuration and it’s hard wired to my network, so no wifi issues.
I know there is a thread that talks about this issue (see below) but I can’t find it. I believe it is related to this update so I figured I’d ask if anyone else knows the thread or is having this issue.
I have a single (as far as I know just one) z-wave device that is no longer reporting it’s status back, however I can control it via the SmartThings app. I press “on” it turns on but the ST app still thinks its off.
A number of people have reported problems with Z wave devices in the last few weeks. Probably the fastest way to find these is on the bug first reports page in the community – created wiki.
http://thingsthataresmart.wiki/index.php?title=Bug:_First_Reports
There’s also a specific issue that has been affecting some Z wave switches that appears to be related to a bug with the refresh command. You can find that technical discussion in the following thread:
Since the numbering is also a bit confusing, I wanted to provide a link to the Open Source license information (and source where required) for the 17.X release series. The artifact for these releases are the 103 ones (the Open Source packages used are the same for all public 17.x releases). The “103” is the build tag we use for the whole image (which is not currently reported to the cloud but meaningless to most of you).
SmartThings FOSS (Free and Open Source Software)
We want to give out a big shoutout to the Rust Language core team, Mozilla, and the many contributors to packages in the Rust language ecosystem. We are making use of Rust for the backbone of our new update client and server as well as a few other pieces of software and are looking to continuing to expand our use of the language over time as makes sense.
If something with the license information or SmartThings open source practice doesn’t seem right, please contact opensourcesupport@smartthings.com
Side Pitch: @nastevens and I are both maintainers on several projects within the https://github.com/rust-embedded org if you are interested in using Rust to talk to hardware (most of those are focused on embedded Linux).
My hub firmware is being reported as 000.017.00013 (online since 28/04/2017), yet there are no official release notes associated with this firmware?
17.11, 17.12, and 17.13 are all essentially the same release but with a few minor platform changes to deal with corner cases in the migration and improve robustness of the update client. No functional differences to worry about.
Thanks for pointing this out - I’ve updated the topic to clarify that it applies to both 17.12 and 17.13 and edited the initial post.
just wanted to say that I am also seeing the “mfr:0000 prod:0000 model:000” issue with my two Schlage locks. I have tried repeatedly to repair them, even taking them as close as one inch from the hub and it still takes many attempts and quite a bit longer to get them to even be seen in the app. I have also tried removing them, then I did a general device exclusion, and then just for good measure I factory reset them by pulling the battery, pushing the schlage button and then pushing it again after reinserting the battery. Even after all that and rebooting the hub I am still seeing the mfr:0000 prod:0000 model:000 every time I try to pair.
I can also confirm that pairing the locks to an iris hub is significantly faster and while paired to the iris hub I am able to see the successful code entries on the locks. I am unable to see any info relating to keypad entry or unlocking via the keypad in the recently tab in the smarttings app.
I am seeing the following error in the Recently tab though:
Basement Door contact developer is unkn own lock. Contact developer quote MSR null
Removing cloud and making everything local with the update? Didn’t think so. 
its not a hard concept, st cloud=unreliable and slow. Perks of a corporate owned automation system I suppose.
@nastevens this issue isn’t limited to Locks but other devices also. Today I excluded a perfectly working Z-Wave Switch and then paired it again. It paired up with all 0000 for MSR and more missing information (see below)
Original Raw Description
Raw Description zw:L type:1001 mfr:027A prod:0003 model:0087 ver:3.81 zwv:4.05 lib:03 cc:5E,72,86,85,59,5A,73,70,25,27,71,32,20 role:05 ff:8700 ui:8700
Re-Paired Raw Description
Raw Description zw:L type:1001 mfr:0000 prod:0000 model:0000 ver:0.00 zwv:0.00 lib:00 cc:5E,72,86,85,59,5A,73,70,25,27,71,32,20
We’re getting reports from users across the board about this issue, it’s also messing up with the platform picking the right device handler. It’s also causing other random communication issues with the device according to some users.
Apparently ST support is telling users that it’s a device issue or the locks/devices aren’t supported.
I think it may warrant an investigation, this issue started only after the October firmware update.