I just checked and the door open notifications are working fine. Check that you’ve selected a door sensor, the interval and check any mode restrictions. You need click
Done on the main page for it to start monitoring the sensor. See attached screenshot
Since it was working earlier and if the configuration is fine then it’s the door sensor or mesh which dropping or not sending the open event.
As for the deadbolt unlock when the door is open, that feature was disabled for security reasons. Some folks reported that by jiggling a door with an misaligned sensor or a faulty sensor it could lead the lock to spontaneously unlock
I’m sorry if this has been covered, or if this doesn’t even fit in this thread (maybe it belongs in the keypad device thread)…but is there a way for the keypads to reflect the status of STHM? I have done the workaround for the virtual devices, to control STHM…but I haven’t figured out how to have the keypad actually show the status.
Thanks @RBoy for the feedback and support as always - I think I got the notifications working.
I knew the events from the sensors were propagating because I have LUM set up with rules to turn on lights when unlocking and those that have been firing. I checked the GraphAPI page for the actual LUM settings and those implied I couldn’t figure anything out but I randomly just tried “Disable all Push Notifications” and then toggled them back on. Immediately I started to see the “Scheduled to run notifyOpenDoor XXXX” events in the logs and sure enough I got the event. In retrospect I am guessing that no notifications were getting through, not just the open door ones.
So, not sure if this got screwed up in the migration to the new ST app or what. You call obviously, but it might make sense to do a check in the app once a day or something to forcibly enable/disable notifications per the setting the user has made.
@RBoy…sorry but I think I spoke too soon. It seems that if I toggle the alerts it works but then it ends up going back to the state where I get no alerts. I did a bit of debugging today and noticed that there is a Groovy error when a door opens so my guess is that since errors halt execution that the callback execution never gets schduled.
I’ll slide into your DMs with the logs and specifics.
Under Door open/close action’s Is there any way to select more than one sensor? Whenever any of the doors in my house open I want my ring keypad to make a noise. It looks like you can only select one of the sensors at the moment.
Has anyone received any updates on the app history? I reported it to Samsung after switching to the new app in September but I’m still seeing the guy floating in the pool and no history for my Schlage 469 lock.
@RBoy is there any way lum can control my garage door? It’s a genie alladin brand. Its wifi & does work with alexa but I cant get it to appear as a device in smartthings.
There’s no way LUM can control a device until its visible in SmartThings…
That said. LUM is for locks, what do you want it to do?
I was looking to setup my door in smartthings & once Samsung’s fixes presence I could automate the door with it. Only other thing ulis wanted to do was setup alexa to announce garage door open & close but I cant find a way to add a virtual sensor to the door. It does work with alexa though.
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.
@all4dom , take a look at the Garage Door Manager for the automation needed.
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.