The Fault in Our SmartThings Overall Architecture Logic – or how I learned to be confused by SmartApps and not-SmartApps

Ironically, the Aeon Minimote is an “improper” SmartDevice Type, per SmartThings’s architecture. There is no Capability “Buttons” (plural), and arbitrary SmartApps which look for a single Button (capability.button), the way they may look for a single Contact Sensor or Switch, will not function properly, since the only Attribute is “button — ["held", "pushed"]” – i.e., nothing to do with which button has been pressed on a multi-button device. :scream: (In other words, it is a hack – a very functional hack, but still… I’m literally OCD, and this keeps me awake sometimes).


Absolutely – and there’s even the nebulous world I entered at the beginning of this repose where I’ve given an example of something that actually “works”, and we can understand why it works, but most of us don’t understand why it is “architecturally incorrect” and what the implications of this are, and what information and/or fix we should expect from SmartThings on this, etc…


Hence I’ll self-promote my earlier post again: Categorizing Issues will help identify constituents for each issue and also their priorities, status, etc…

Knowing the “constituents” (target audience) helps to ensure that a true mutual “understanding” of the issue can be reached, by using the appropriate level(s) of technical detail.

See #9 and #10: SmartThings is in the process of improving Documentation, and we’ve added Community generated FAQs here. That will go a long way to improving “understanding” of the Platform.

But features that just “don’t work” or work significantly inconsistently or unreliably can be categorized in the other areas I suggested…

1 Like

You guys really want to argue who understands network architecture better? :wink:

My point is I don’t care if the minimote install through the official ST app is a hack. It’s a reliable officially supported hack that does what I need done and that ST support will help me with if the install gets stuck.

I have no problem with black box hacks that work. As a custom code developer, someone may have a complaint after they lift the lid in the IDE and see gerbils instead of hamsters on the wheel. But that’s a separate issue.

1 Like

Definitely not against your experience, JD! :wink:, I wouldn’t stand a chance.
But I would argue that the Minimote hack has nothing to do with “network architecture”.

My point, and I’m not sure if this is on or off Topic anymore (as you all know, when I get into ST’s theoretical architecture, the discussion could fly-off into any direction…):

This is indeed a “black box” failure. The label (contract) on the black box says (or should say, if I could point to a literal paragraph somewhere) that if a SmartApp requests a Device Instance of a particular Capability (e.g., Button), then it has exactly the Attributes and Commands listed in the Capability Taxonomy. The SmartDevice Type of Aeon Minimote cannot do this accurately because it has multi-Button capability, which does not exist, so it cheats and says it has Button Capability.

It is quite possible to hack-the-hack and fix it, actually… by creating Virtual Button Device Instances for each individual Button on the Minimote (or any supported Multi-Button Device Type) and using a SmartApp to map the physical device hack to the respecitive individual “conforming” Virtual Button.
(And I’ll spin that off into another topic before this Topic is called “hijacked”…).

This thread was supposed to be about “Overall Architecture Logic”, and in a section about SmartApps.

Learn about SmartApp development or share your SmartApps here.

But that isn’t how it began, which was about someone’s UI confusion. I don’t think anyone on the thread has raised a meaningful critique of the “overall architecture logic”, unless it’s @tgauchat pointing out inconsistencies and documentation fails . Mostly, people complain about UI issues. UI issues are one of the reasons that people write apps for ST. It’s very interesting to note that @geko and @625alex, both who’ve written major ST apps, don’t have many complaints about the “overall architecture logic”. They were able to make it sing, dance and do amazing tricks.

If you understood that there is “not a way to even force the system to do what you want”, then it wouldn’t be a shortcoming worth mentioning? If it doesn’t work as expected, was the fault in the expectations, or of a shortcoming in the implementation? It’s important to make that distinction. I didn’t expect z-wave dimmers to not respond instantly to being turned on. Bad expectation, not a bad implementation (by ST anyway). So many of the complaints about ST are complaints of expectations not met, mostly UI related. That may be poor marketing, or it may be poor documentation, or a 'hot mess" UI design, but it isn’t about a shortcoming of the system itself, or its architecture.

Agreed, the minimote is a black box hack. No one’s going to know how it works unless for some reason they want to open the box.

But that’s my point. Most of ST’s marketing, including at CES, is aimed at people who just care if it works. As is. They don’t care about conformance statements or interface contracts or completely unlabeled black boxes.

They just want to open the official app, push a few buttons, tick a few checkboxes, and have a device available on their network.

They then want to use some kind of scheduler and rules engine (whatever terms you use) so they can make the available devices do what they want, when they want.

Cellphones are incredibly sophisticated devices. Most people who have them have no clue what LTE stands for. Or where the term Wi-Fi comes from, or that it’s trademarked. Or what WLAN means. And none of that matters. Not to their ability to use the phone, not to their satisfaction with it, and not to the transactions that keep the company selling the phones in business.

There’s a secondary market, which is app developers and accessory makers. They have a much deeper understanding of the phone, which is good. They open a few black boxes. All good.

But for the phones to be a success, they have to work well for the people who don’t want to open the boxes. Whatever their reasons for that.

@bravenel ,

It seems pretty clear that a lot of the perceived “UI” issues are really the underlying architecture issues caused by running multiple protocols. Viz. the fingerprint issue for zwave. Or the lack of groups support.

There are some great coders here, but nobody’s making the older zwave certified GE remotes “sing and dance.”

3 Likes

I’m confused.

Isn’t there such a thing as “reasonable” expectations? And many which SmartThings currently fails at meeting? (While not denying there are also many more unreasonable or mistaken expectations).

A few which I think are reasonable:

  1. Scheduled actions should run reasonably close to schedule, including sunrise and sunset.

  2. The UI should reflect the current state of Devices (switches on or off).

  3. Cloud outages should be rare.

  4. Devices listed as “works with SmartThings” should… work (with exact limitations documented).

  5. As a Development Platform, the available methods should be accurately documented and there should be good “Best Practice Guidelines” and Developer level support.

  6. Some degree of home automation should be as simple and consistent as implied or demonstrated in marketing materials (ie, please, no disrepect intended here: Alex Hankinson’s keynote demos, especially – They work. But do they imply features that don’t work? In one interview, I think Alex himself mentioned that his own genesis story for SmartThings, the flooded home disaster, would not have been preventable with the current implementation of ST, since his Internet was also down at the time. He emphasized this is a great reason for the Hub v2.0 local processing ability…).

4 Likes

YES. Literally just seconding this.

Also, @bravenel - I wanted to give you a specific example of what I would consider an architectural flaw, since you seem very concerned about staying on topic here.

I have, for instance, many actions that happen when I leave the house and my house goes into Away mode. I would love to take a look at what all those things are, and make sure…but I can’t, because I can’t open up Away mode and edit what happens or doesn’t happen when it’s triggered. I literally have to go into every single device that is affected by Away mode and edit what happens in Away mode for that device only. It’s jenky. That’s just one of many examples.

I would consider this to be mostly a User Interface flaw.

The architecture stores and can report on what you desire, for the most part.

It cannot interpret how Mode is used in arbitrary SmartApps, though, which is an architectural flaw! SmartThings is a little too loose on how some important structural elements can be used in the system.

A rules engine overlay could solve your requirements, I think.

1 Like

It’s a good point.

As is the fact that some usability problems can be solved by a UI change, or an architecture change, or a mix of both, and the person reporting the problem doesn’t only not necessarily know which, they shouldn’t have to know.

2 Likes

Can I watch? :wink:

1 Like

Ok, I think we have drifted from my original post. :smile:

This was never intended to be a bash ST or find everything wrong thread.

I ran into an issue when doing something that seemed like a basic function of automation - a variation, based on mode, of the same action. If you go back to my original post, you will see how I followed the UI logic down multiple dead ends. I thought it would be interesting to discuss and see thoughts others had on how to rectify this in the UI (which is obviously influenced by the underlying architecture) - basically, a thought experiment. I encourage you to go back to post number 1 here and re-read it.

So, in the end, I’m still a little stuck on this. I’m looking for a simple app that will just set the dimmer level on motion, add a timeout to turn off after no motion and I’ll insert the “only this mode” option at the end. Basically, the same functionality as the base setting that I referenced in my original posts. I have had helpful suggestions for SmartApps, which I appreciate greatly. But, I was looking for something simple and straightforward.

The workaround is to create a new duplicate Lights & Switches shortcut for the light and add the schedule there.

The feedback in this thread is great and definitely hits home for the shortcomings our next-gen solution will have to solve.

4 Likes

Well… that throws a wrench :hammer: into the works!

I proposed earlier that it would be helpful if SmartThings carefully distinguished and categorized every known issue.

This would “force” them to pre-designate whether an issue is architectural vs. UI vs. documentation, etc…

Perhaps there’s less value to such categorization than I thought, or some other ways of classifying issues is preferable??

My gut feel is that, indeed, at the Consumer-User level, knowing what part of the black box has an issue and what parts may be changed to address the issue is counter-productive.

To Power-Users and Developers (i.e., most of the active members of Community), these details are highly relevant, as we are able to code workarounds and plan regression testing on planned fixes, may have our “own” user sub-communities to inform, and our contributions should be written to best practice recommendations based on the current state of the Platform, in order to run optimally, consistently, and supportably.

This keys into the part of my wish that not only should issues be fully identified and categorized, but issues should also have their constituents (stakeholders, target audience members, whatever) identified and the issue and status reported appropriately for that audience.

Thanks, @Tyler. I realize that is one easy workaround. As I’m sure you know, that doesn’t play out well in the long run…as in imagine how many of these entires I’ll have in Lights & Switches! Time for me to come up with a new and better naming convention for my entries!

But, I know that this has to be something the devs see and will obviously rectify in the future. I was hoping for a fun thought experiment here to see what everyone in the community could come up with, since there is a great diversity of background here.

2 Likes

Of course - and I certainly encourage the discussion. I just wanted to chime in with a recommended workaround for the specific issue you used as an example of a confusing experience in our app. I also acknowledge that the workaround is absolutely more confusing in the long run!

2 Likes

That will probably be my short term solution. I think my long term will be to completely redo everything once either hub v2 is launched or a revamp of the interface / architecture happens.

Personally, I think it is a great thing to start from scratch every once in a while! :slight_smile:

Oh, and I highly encourge those revamps from scratch to occur when you have had a few glasses of wine or bottles of beer…like I have now! It makes it more fun! :slight_smile:

This topic is now closed. New replies are no longer allowed. Thread is locked per the request by OP.

1 Like