Cool, still doesn’t have anything to do with LUM. Your best bet is the WebCoRE solution in the other thread (I’ve seen you read it so I wont link it here) you’re on until Genie/Aladdin makes its official integration available.
You’ll still need to figure out how to add your door as a SmartThings device as has been noted elsewhere. Given it is WiFi, you will need to find a compatible Device Handler. I will note that the Chamberlain MyQ Smart Hub Black was on sale for $17 USD as an Amazon Black Friday deal today, and MyQ plays well with SmartThings.
Just to confirm for anyone else reading this…thanks to some quick support from @RBoy they determined it was due to having a door where you’ve turned on the feature but never selected any options (sensor, timeout, etc.). Once I removed the “unconfigured” setup, the alerts started to work again. It should be a non-issue going forward as RBoy tweaked the code to avoid the issue in the future.
I seem to be having an issue with multiple Ring keypads. When I arm 1 keypad, that status is not reflected on the other. And I can remedy that specifically for the away mode by toggling the “keypad lock actions” to have it “lock locks” for both keypads, but without a “stay locks” type option to set them as stay mode, I can’t find a way to accomplish stay being synchronized between multiple keypads. Is there another way? If not, can a stay option be added on within these settings so it will work the same way as “lock locks” is done?
To set stay mode, requires webcore.
I am having the same issue. I’m using LUM and the Universal Z-Wave Lock with Alarms device handler. The history is all there in the IDE events log. I am also getting push notifications in IOS. But no history in the new app.
Some time in the past week I started to receive history updates in the new app under my lock device. Nothing was changed on my end, so not sure what made it start working again.
There are a couple of different places you can view the user history, some are controlled by SmartApps, some by the DTH and others by SmartThings. Here’s a summary:
Device Event History -> Open the individual lock/device page in the ST app and at the bottom click on the History tab. This is where the device/DTH (stock or enhanced) logs the messages, SmartApps like LUM/RLA cannot log messages here. A key point to note here, there’s a separate ST service that’s responsible for showing this event history here. Sometimes this server takes time to catch up for some users so it can take anywhere from a few minutes to few days to show up depending on how the service is performing. It can help to “pull down” on the history page to force an update in some cases. That’s why it started showing up by itself after a few days. It’s not related to the DTH but to the event history service. Another known issue with this page in the new app is that it doesn’t display the name of the user or the source (keypad, manual etc) used to lock/unlock. SmartThings is aware of it and hopefully it’ll be fixed in future. (click image to enlarge)
In-App Usage dashboard -> This feature is currently only available in the Rental Lock Automater (RLA) app which has a Usage History page. (click image to enlarge)
History page (Device events) -> On the ST mobile app click the Hamburger menu and then click on History. This shows all the device events reported by the DTH (the same events you see in option 1 above). Here you can filter by devices, this is also subject to the same event history service in option 1. No SmartApps can log messages here, only DTH’s. (click image to enlarge)
Messages page (SmartApp notifications) -> On the ST mobile app click on the Hamburger menu and then click on Messages. This shows all the messages logged by SmartApps. So this is where LUM logs it’s messages. Every time you get a Push or SMS notification from LUM, a copy of it is logged in SmartThings and can be accessed from this page. This is the only place where SmartApps like LUM and RLA can log messages. No devices/DTH’s can log messages here. (click image to enlarge)
TLDR; there are different sources of history, some from DTH’s, others from SmartApps. Be sure to read the above to see the differences and how they work.
Thanks for clarifying, Rboy. #1 was not updating in my app for a few weeks and was just displaying the guy face down in the pool. #2 I don’t use. #3 has worked well as long as the history service is working. (i.e. sometimes doesn’t update even after pulling down the screen to refresh). History service sometimes gets truncated in time to a few hours too. #4 has also worked well.
Lock User Management works GREAT!!
As a SmartThings and Schlage Connect owner, I got screwed by buying two of the same Schlage Connect locks a few years apart. The first one worked fine (with limited functionality) with the old SmartThings app, however, once I added the new lock it would not show up with the same functionality. I tried changing the device type, etc. as others have mentioned. Didn’t work. The upgraded/new app would not let me add codes for the new lock.
After a fair amount of research, kept running into the RBoy LUM SmartApp. Decided to give it a go and 30 minutes later both of my locks are working seamlessly. All functionality worked as promised and I even used the custom Device Handler to provide more functionality in the device interaction screens beyond the LUM SmartApp options.
Coulnd’t be more pleased and well worth the price of admission.
When my Smart Hub goes offline for a while and then turns back on, all the notifications I get on my phone are time-stamped at the time the Hub restarted.
Is there a way to get LUM and other Rboy related apps to show actual time stamps after the Smart Hub reconnects to the Internet/Samsung server?
Did you ever figure this out or get an answer? I had asked about this a while back, before migrating to the new app. I just assumed it would be even more impossible with the disassociation of STHM and ability to be automated with smartapps. This is actually one of the things holding me back from making the keypads part of my standard security setup. The primary reason I would want keypads at my doors is to indicate if the house is armed and if it’s ok to open a door. I have kids, so without that feature they’re sort of useless. I really wish ST would open up STHM bc I know that’s the key to a lot.
I did not. I’m not sure if that’s because there is some obvious fix or setting that I’ve overlooked and people just thought I would eventually realize it on my own…or if it’s because it’s not possible and people are sick of talking about it.
This week is set to be a slower work week, so maybe I’ll have some time to do a little more reading/research. I’ll post if I figure anything out…
Thanks. I actually just stumbled on that post myself and was messing with it. I’ve come to the conclusion that my keypads are the most frustrating part of my setup. I have 3, and I can’t get any of them to function as they should. Even before worrying about syncing the STHM status, I figured that I would just make sure they were functioning by having them turn off a light switch when I “unlock”. Even that didn’t work. One keypad (Xfinity HFK) accepts my code, and beeps as if it worked, but nothing happens. The other (Xfinity 3400-X) throws an error on my phone saying that in is an invalid code (same code, so yes it is valid). I’m stepping away from them for the evening, or I might throw one against the wall and regret it tomorrow
does anyone know what might be causing my keypads to now throw an error that the user code is invalid? The codes are not invalid, they are configured by LUM. The DTH for the keypads, as well as the Smartapp are all running the latest versions.
Thanks for the link. It doesn’t really solve for complete sync. For example, I need my keypad to update to “OFF” if I disarm my system through the ST app. But either way, if I’m needing to use webcore, I’m able to do that utilizing the virtual switches that I setup for LUM. I also needed to add another automation in ST “if STHM changes to disarm, then set keypad to disarmed”. Easy enough. I just wish I didn’t have to configure all of this between 3 or 4 different smartapps and virtual switches.
Can you tell me how I can disable auto lock please on a Yale Keyfree door lock? What I need to do on occasions is unlock the lock remotely and keep it unlocked until I choose to re lock it, this could be after 1 hour or 6 hours, it would be a random length of time that I cannot determine with a regular lock/ unlock sequence.
In the previous Smartthings app, there was a setting where I could unlock the lock, this would override anything I had set in my automations and the lock would stay unlocked until I re locked it, I cannot find anything in the new app to do this. I use rboys lock user management and Universal Enhanced Z-Wave Lock but cannot find a setting to do this as I need to.
I have been onto Smartthings and Yale and neither have helped much, Smarthings say my module is old and Yale want me to purchase a z wave 2 module which I am reluctant to do until I know it will do what I want, plus my module 1 worked perfectly until the new smartthings app was implemented.
All of my automations including my automations ‘lock door’ were migrated from the previous app and have not been changed by me or anyone else so I can’t see how that would change anything.
Hopefully you can help, thanks again
Can someone who uses webcore with the LUM device handler tell me how I can find out which lock code in webcore is assigned to the lock code I have in ST. I am trying to connect virtual switches to each user-code, which would trigger Alexa to announce the usercode that unlocked the door, since echo speaks stopped working.
EDIT: Forgot to mention it’s a Schlage BE469.
Hi there. Please note that SmartApps run concurrently and are not dependent on each other. What that means is one SmartApp cannot “override” another app, they all work independent of each other. If you have two SmartApps which provide an auto lock feature, then they will both operate simultaneously and can therefore create expected locking behavior. Hence it’s a good idea to verify that SmartApps features don’t conflict with each other or execute at the same time.
There are two types of auto lock:
- SmartApp based auto lock, for example what LUM and RLA offer through the Door Open/Close Actions page
- Hardware based auto locks, these are built into the lock hardware, some are configurable (e.g Yale), other are fixed (Schlage, Kwikset)
It’s a good idea to check that both SmartApp and Hardware based auto lock aren’t enabled at the same time to avoid conflicts. To configure Hardware based auto lock you can do it directly on the lock itself (refer to the lock manual) or for supported locks you can use the Enhanced Z-Wave Lock device handler to manage them through SmartThings. If you’re upgrading from the Classic app to the new App be sure to update your device handler and follow the instructions here to clear the cache for the new controls to show up in the new app.