Many of my devices statuses won’t register, I’m assuming due to custom DH. They show up with no “on” “off” status on the main page but will allow me to control if I expand.
I am not sure how to fix the DH to work, using one called enhanced dimmer which allows me to have instant on/off on the lights as opposed to the dimmers default slow on off that the wife despises
Is there any way to delete Smart Home Monitor from the Samsung Connect version of the app? I wanted to try the new functionality in the new app, quickly discovered it doesn’t work for me, and it seems silly to have two different smartapps for the same function. There doesn’t appear to be any entry for the new app’s SHM in the IDE site.
Also, from the new app, you can turn off smoke or security in SHM, but you can’t turn off both.
Edit: Oh, never mind, I figured it out. You can’t do it from the SHM page, but you can from the automations page.
Just an update on my experiment. Putting it on hold until Sunday. Going to go a bit further and disable all custom apps, custom DH’s and only use the ST automations etc and see how far I can get. Currently the mix of custom DH and webCore makes the new app painful to use.
Also, if any IOS users can check. It’s been brought to my attention that sometimes on IOS when using auto detect on the new app to add a device, it’s not picking up z-wave devices. Works with no issues using the android app as well as the ST classic app on ios.
I personally don’t use ios so can’t test myself.
I moved 5 of my webcore pistons to the custom automation creator. Took 10 rules to replace the 5 pistons, but I like the direction the custom automation creator is moving.
as far as auto detect, that is more controlled by the hub than the app AFAIK. Hub V3 doesn’t go into general inclusion mode unless you pick a specific device from the list. This is because it supports zigbee 3.0 QR code scanning and the app is forcing you to use the most secure pairing mode possible.
If SHM had equivalent functionality in the new app and the custom automations could do everything a routine could do (SHM and locks), I’d finish my move. A few leftover pistons and my routines almost totally deal with SHM and my door lock at this point. I have one custom DH (LIFX Group of Groups), but that is all I use at this point in the old app.
Well, I use SmartLighting in both, but even though that’s in the Classic app, I haven’t heard anything about it going away like Routines seem to be.
But then that wouldn’t explain why it works using the android app and auto detect. It works on Ios intermittently.
Got off the phone with support. Deleting & re installing the app seems to have helped with my missing time. She said for automations that dont work, try unpairing & repairing the device including deleting the automation & see if that works. Foegot about unlocking the door with mobile presence…its gone in the new app.
Probably due to a lot accidental door unlocks due to flaky presence.
Still, it should have been up ro the user…not samsung.
I’d say so. I read time after time in the forum where people complain about how flaky and unreliable presence sensor results are. Many even complain that they can sit and watch their phones come and go repeatedly without them moving an inch and yet some continue to unlock their doors with those same ‘flaky’ presence sensors. Seems like an obvious security issue to me. Mine seems fairly good - but not always rock solid.
I’m not pointing at anyone at all. A lot of people do it and everyone has different risk-level tolerances. To each their own. But I’m sure companies such as Samsung and others do not want the liability risk on them.
I guess I chalk mine up to the joys of living in a semi-rural neighborhood. I have a pretty good buffer around my house. I don’t see any accidental departure events, but then again, I’m sometimes a couple hundred feet away when it recognizes that I’m home too. That’s worked well for me, but I do forget that other folks live in more densely populated areas where that kind of thing can cause a problem…
And I’m fine with not being able to do it with presence. Though, I would like to be able to trigger it from other devices, though. Kind of defeats the purpose of connecting them if you can’t fully control them. Most of my unlock commands are built around a sequence of events, not presence, and a virtual switch actually triggers the unlock. That way, I know that I’m close or have arrived. After that, the garage door opened, and then, a motion sensor tripped. Add in two virtual switches, and you’d be surprised how well it works…
They could also only allow presence control of SHM via the new pin pad and fobs they showed at CES.
True… I can say for sure I would be annoyed if they limit it to their devices.
Not to mention, well, really must mention, that the Arm/Disarm API for Classic SHM has been used by developers (unofficially, but in plain view) since Classic SHM was released.
But no such API has been published for New SHM.
ActionTiles cannot currently control New SHM. 
Has anyone tried writing a basic smart app using the new api to see if it allows unlocking?
No… but why do we suspect that “unlock” isn’t available to SmartApps?
The new API documentation for Capability “lock” clearly offers the unlock() Command:
https://smartthings.developer.samsung.com/develop/api-ref/capabilities.html#Lock
"commands": {
"lock": {
"arguments": [
]
},
"unlock": {
"arguments": [
]
}
SHM is a different situation. SHM is, itself, a SmartApp; not a device.
Only because it isn’t offered as an option in the custom automation creator (or anywhere else in the new app). So in theory someone can write a smart app for automating unlocking doors.
With the new version of SHM using the new smartthings APIs i suspect it functions completely external to smartthings itself. The classic version uses the location alarm state. It seems very reasonable based on some testing i am doing for converting ADT Tools that Smartthings has no awareness of the SHM state in the new app. It just nows to send it the events on monitored sensors. Then Smartthings just reaponds to commands from the api calls as SHM triggers its actions when a event occurs.
