So I’ve followed this thread, and I get that we need to primarily use the Classic app. I finally got the notification to update to a Samsung account, though, so if I just open the app and log in, just to poke around a little. Is it likely to break anything? Some people have mentioned weirdness when using the app and things breaking, but I can’t really tell if that’s from trying to work within the app or just using the app that causes some other type of migration with my hub/devices…
I regularly use both. The only thing I’ve had “break” is if I turn on location tracking in STSC it no longer updates my mobile presence device in classic until I’ve gone back in to classic when home. STSC creates its own mobile presence device with the same id as the classic one, so must be some conflict.
You have both apps linked to the same hub?
How did you do that?
Because both apps login with the same Samsung username/password.
^what he said
Dome Siren is another. It has multiple sounds.
I have the same. Both my accounts have the same username/password, but the classic app gives my an “invalid code” when I try to setup, since the hub is already in the Samsung account.
Logout of the Classic app, then login but choose new user. It may detect your Samsung account (assuming you are logged into the STSC app).
Wow, that actually worked. Thank you
What DTH are you using?
The one provided from the Dome official site and not not the one you can select from the official ST DH in the DT list available on the Location site.
Right… this code: https://raw.githubusercontent.com/krlaframboise/SmartThings/master/devicetypes/krlaframboise/dome-siren.src/dome-siren.groovy
Indeed, IF the “rumor” is true that the new SmartThings App / API will no longer support the concept / use of ad hoc (custom) Attributes and Commands, then a lot of functionality for this Dome Siren will be lost.
Here are the ad hoc Commands for example (though for the life of me, I don’t understand why “"on"
” has been added as a Command, since this is already available in Capability “Switch”).
command "on"
command "bell1"
command "bell2"
command "bell3"
command "bell4"
command "bell5"
command "chime1"
command "chime2"
command "chime3"
command "siren1"
command "siren2"
Dome and/or third-party developers for them and companies like them would be wise to study the new API and App very, very closely and determine if they need to put pressure on SmartThings to change their plans and/or have the new Capability or “Capability-extension” process extremely streamlined.
- Capability “Multi-Toned Siren” is one possibility.
- or the Dome Siren could (should!?) actually be defined as a composite device: i.e., 11 distinct Things, each with its own particular sound. Composite devices are a feature of the new API, btw.
While option #2 can easily become unwieldy (unless the App UI is also substantially enhanced), it actually fits the SmartThings - SmartApp paradigm much better than #1. i.e., Any SmartApp that can trigger a “Siren” should allow the customer to select which of any of the 11 “(sub) Sirens” he/she wants. The unwieldy problem is that if the customer has a few physical Dome Sirens … and each of these is shown 11 times in the list…
Yup. That’s the one. I hope the make it easy for custommers of custom DH devices and let us use these DH’s
I hope so too. But … I, personally, am not optimistic. I want to be, really I do. But just consider the history…
I thought the plan was to support custom attributes, but there was currently no plan how to do so.
the good news is my Xiaomi contact sensor dth has a custom attribute (lastCheckIn), and that device works in STSC, it just doesn’t show the custome attribute. Works fine for contact and battery.
Yeh. I am here every day… Hopping that ST comes to some sanity…But as our fellow friend on this forum said:
using the Classic app will retain all sanity
IIRC, @TheSmartestHouse sells Dome products. Perhaps they could influence the Dome folks to consider following up on your cautionary notes…