Currently we have two brands and four integrations.
(Brand SiHAS (Shina Iot Home Automation System) and integration SiHAS Cloud WWST were added later to publish Zigbee and Wi-Fi devices as WWST, respectively.)
For Hub-Connected devices, if your device’s fingerprints are included in the stock SmartThings drivers, users can click on “scan nearby” in “add device” directly which will put the Hub in discovery mode.
Then, they can put the physical device into joining mode and follow the steps in case it needs to enter a code.
The problem @Shina_System_Co_Ltd has is that there are four integrations. One hub-connected and one cloud schema for their WWST devices, and one hub-connected and one cloud schema for their older compatible devices (non-WWST). These are unevenly spread across two brands. One has both the schemas and the compatible hub-connected devices, and one has the hub-connected WWST devices only. The bottom line is that only three of the four integrations can usefully be reached with the new Add Devices.
The natural flow is now to use ‘Partner Devices’. That gives the users two choices:
SiHAS takes the user to a page that starts a flow towards the WWST Schema (via the ‘Next’ button). So that is 1/4. There is also an alternative branch via the tiny ‘directly’ link that allows onboarding of their compatible hub-connected devices (non-WWST). So that is 2/4.
The SiHAS (Shina IOT Home Automation System) option starts the flow to onboard their WWST hub-connected devices. So that is 3/4.
That leaves one missing, which is to their other Schema which is for compatible devices (non-WWST). That should also be reached by the SiHAS brand.
A particular example is the PMM-300-W device. It can be located in Supported Devices but there doesn’t seem to be an obvious way to locate it via Partner Devices, and so there is no way to start the flow to the schema for their compatible devices.
UPDATE
There is actually a non-obvious way to get to the PMM-300-W. That is to pretend that it is a hub-connected device. So follow the ‘directly’ link mentioned and then follow the sub-miniature link to ‘Add without QR code’. Choose a hub and then wait quite some time for the list of devices to be populated. That is where you’ll find the PMM-300-W. If you click on that you launch a schema flow. Whether it is the right one or not I’ll leave to @Shina_System_Co_Ltd to determine.
I can only find the one called “SiHAS Cloud WWST” in the certification tickets (which is where the model “PMM-300-W” was included but you mentioned it belongs to a project called “SiHAS” only), if you have two different Schema projects, then, we need to report that one is not appearing correctly in the catalog and that’s why I need their app ID.
@orangebucket, PMM-300-W is the model certified, not the name of the integration, if a partner has a Schema integration, we can only see the Schema name in the catalog and if there are two in the same brand, both should be listed there, so, I wouldn’t expect the name “PMM-300-W” to appear directly because that’s not the name according to the ticket I found.
I’ll check this situation further with them, thank you for your comments.
In trying to clarify what the specific issue was (no way of getting to one of the schemas) as I felt you may have missed it first time around (about three times less than it took me) I realised it also demonstrated how ill conceived the change to the flow is …
It used to be that to install a certified device via the mobile app you went to Add Device and either specified the brand followed by the device type, or the device type followed by the brand. Either way you ended up with a list of available device models (or families) to install and you chose whatever one you were trying to install. That made sense because you had a pretty good idea what you were trying to install. You didn’t need to know anything about the name or nature of the integration, you just followed the flow and you were guided to the correct place. So in this example a user would know they were installing a PMM-300-W and that is what they would find.
In the latest Android app the flow has changed. You specify the brand and device type (only that way around) and then it jumps straight in without checking which device you are trying to install. If there is a schema it tries to propel you in that direction and only the tiniest of links will alert you to the option of a hub-connected integration. Even if you get to the hub-integration it straight away opens up a camera asking for a QR code. It doesn’t say which QR code it wants or where to find it. I can imagine a lot of users presenting a QR code that links to an extended warranty or something. Eventually you notice there is a tiny uncommented link to use if your device doesn’t have whatever QR code is required and only then are you eventually presented with the list of devices and asked what you have.
If you want a simple example, imagine you have a v2 hub and see how ridiculous the flow is.
It looks pretty but it is totally unfit for purpose.
I apologise to @Shina_System_Co_Ltd for interrupting this thread with this rant, but I do feel my previous post was valuable.
can you share the app ID of each of your Schema projects certified to build@smartthings.com, please? Eg. “viper_xxxx”
Sure.
One question here: Is it acceptable responding with a list of compatible devices when receiving a SiHAS Cloud Integration WWST Discovery request?
When we got WWST for PMM-300-W, ST asked us to make new integration. In this context, we thought that it’s because compatible devices and WWST certified devices should not be mixed in one integration.
