Recently I asked my first question of the community and got a great response. So I'm more open-minded to Hubitat because of it.
Being an old guy I come from a historical point of view - keep that in mind. I realized in the first 5 days of working on code with Hubitat there was what I believe a structural problem that is creating a logjam. It shows in the naming conventions used and also in the partitioning of stuff.
Having been around for many years working with Plex, Drupal, and then older technologies (protocol drivers were my forte) - I submit there is a weakness to the design of this product. It showed it's head when I tried to form a simple question, and further showed as I tried to wrap my head around the implementation.
2 Examples I find glaring. Variables and Apps.
Calling a user made addon an App is fine. but what do source apps get called? Apps? Why not System Modules so you can identify the source? How will you segment them down the road when the hubitat people want to start charging for features, which undoubtedly will happen (come on, it always does!) I submit apps should be broken into two (or 3 actually) - 3rd party Paid, 3rd party free and Source Modules.
Similarly, I find that since there are only five (really??) known system global variables, they be referred to as %system_global_xxx[variablename]%. User created global variables be called %global_xxxx% and finally specific routine variables %variable_name%.
I'm just setting this out in the Lounge for intellectual discussion - At this clearly early stage of design of the hubitat, while it's such a fresh concept being created, now is the time to use some forward thinking, not later. I think about how Plex killed apps (they called them Channels, then plugins then visual of throat slash ... and how badly that went for them. I'd just like to see Hubitat not lose the user base too quickly before the bean counters and greedies step in. BTW - this could be useful in licensing applications as well.
I recognize your viewpoint and interpret your observation regarding organization to be similar to reactions from transition from Office 2003 to 2008 or from forced-structure support forums to recent all-db-structured support forums. You are looking for ground truths in foundation but these days it seems to me people are less concerned with foundational structure if it works and can be separated in a sort. Such structure essentially leaves breadcrumbs of operational intent and initial design. But over time products these days drift, and old breadcrumbs of intent can become outdated or even confusing to people with less history with the product or perhaps once caffeine levels drop.
It took me a while to accept how a lot of things have changed, but I have come to appreciate more of a flat structure.
That said, from what I can tell the Hubitat team seems to be on a good path and I'm enjoying watching how they are quickly improving things, which as you know does get more challenging once more than 1-2 people are involved.
Not sure if this fully hits your observation, but at least keeps the thread alive.
I'm not sure what you mean with "source" apps. I'm actually really not sure about what you mean with "user-made add-on," either, but I'll assume you mean "custom app" (apparently formally called a "user app" in the UI), which leads me to conclude that perhaps by "source app," you mean what is what is typically called a "built-in app" (sometimes "native app" or "stock app").
If so, the difference when you're actually using the platform is of minimal consequence: both have access to same functions, etc.; the difference* is that built-in apps were made by Hubitat staff and they have the special ability to bake them into the hub firmware so you don't have to manually add them in the "Apps Code" section like you do with your own (or anyone else's custom) apps. Or perhaps that's the distinction you're referring to: installed instances of an app (any app) versus the abstract existence of the app "code" (visible or not), an instance (or many) of which may or may not actually be used on the hub? In that case, the hub doesn't install any apps for you, so you'll have nothing that you didn't install yourself. The only thing similar to what an app might do that the hub does on its own with minimal setup is "location"-based events like updating sunrise and sunset times, and it can respond to manual mode changes (but most people would use an app to automate that).
(*OK, the other difference is that built-in apps are also formally supported by Hubitat, but you're on your own if your custom code causes problems--though I have to say staff have still been quite helpful figuring things out there, too. If this is what you mean, the difference is again of little consequence: you can choose to use only built-in apps, and you can disable any installed app by enabling the "X" column in the app list and checking those you want to disable.)
Perhaps you could explain what you mean or why it would be useful? I think I'm missing something. Or perhaps Hubitat's model isn't clear: you basically have apps (other platforms call these SmartApps, robots, automations, or similar--and the latter is exactly what they are) and devices (other platforms call these Things, entities, or similar). In general, apps are ways to automatically, in some sense of the word, manipulate your devices. Hubitat comes with zero of each by default except those you add/install yourself, and in the case of either, you can use built-in/native or custom code to do so.
grins you sort of helped make my point! its like there is no line or definition of what goes where! But as the other comment I read suggests, maybe there isn't supposed to be. Thats a tough one for me to swallow but I did qualify with 'I'm old'.
yes, source apps in my tiny brain are built-in apps. Enabled or not, built in apps are foundational, and for the most part can't be played with like you mentioned - burned into the firmware.
I was listening to myself argue and what I explained poorly was the usefulness of this. As more and more modules (apps) add to the product as it evolves, the ability to identify modules source (3rd party or in-house) becomes more important. Take the discussion of webcore. To some developers, they may believe it was foundational and not an addon. The ability to return to a 'safe mode' for diagnostic purposes is just one bad example that comes to mind.
Being able to point toward the right help creates a faster response, and less finger pointing, which speeds future development along. Using the 2nd example regarding variables goes down the same lines - knowing where variables are defined helps find their definitions for enhancement and fixes. If it's 3rd party, you solve one way, if it's built in you go the other. Is this helping at all?
NOw - you do bring up something I may have totally misunderstood:
Blockquote
Hubitat comes with zero of each by default except those you add/install yourself, and in the
Blockquote - so your saying the user manual that says 'enable these apps' is referring to user supported/user written apps? I'm sure I'm misreading this....
No, enabling/disabling an app is done on a per-app basis (and for parent-child apps, you can disable the parent or any/all children). Custom or native does not matter, nor is there a way to enable/disable all of one type (custom or native) in one fell swoop. If you are not sure how to enable/disable apps (everything is enabled if you've installed it unless you explicitly disable it), see the last section in the Apps doc page, which I assume is what you're talking about so may have already seen.
There is already a way to distinguish: did you go to the "Apps Code" section under "Advanced" and add code yourself, then did you install an instance of such an app, knowing that you had to click "Add User App" rather than "Add Built-In App" to do so? If the answer to these is "yes," it's not stock/built-in app. (The idea is likely that anyone who gets this far should know what they're doing. Lots of people on the forums run custom code, but I suspect it's a small percentage of total users that actually do.) If you're really not sure and have already installed the app, the "gear" (info) icon next to the app will show you the app's status page that shows information you generally don't need to worry about except for troubleshooting with the developer (or Hubitat), but the top-right corner will show "User Created App" or "Built In App". Personally, I'm able to remember which I installed myself--I don't do a lot, only if a native app can't solve a problem I want or if I think it would be too much work (or repetition if I have a lot of similar automations, slightly lessened by the new rule cloning feature) to set up in Rule Machine.
There is no need to run custom code (on all of my hubs but one, I run only native code except the code I need to "link" my devices--and I guess one or two apps I wrote myself and take responsibility for.) Certainly anyone who went through all the effort of installing webCoRE would know that they added that code themselves...
A very simple answer to this similar to as @bertabcd1234 is saying. The only way to add an app to be used is to click one of the two icons in the above screen shot. So ask yourself which Icon did I click to add this app?
The Right Icon (Add Built-In App) is A Hubitat generated and are supported by Hubitat support and only they have the code to modify/fix/etc.
The Left Icon, YOU the user had to have gotten the code for the app from the "User creator" and added it yourself by clicking on "Advance / App Code" and providing the code for the app before you are able to add it with the "Left Icon" in the above screenshot. These apps require you to contact the app creator for issues/fixes/requests as they are not "supported" by Hubitat's support resources (although they do help if they can when available)
points all made. yes - I can easily tell at implementation time what is what. I'm not sure if I'm sounding humble and grateful here, but the tone I'm hearing is 'he has a problem lets fix' and I don't , really!- I was trying to be a bit more high level. If I was just nitpicking I'd point out you can't see user vs built-in app on the app panel, you have to drill in.
I think I'll go back to the woodwork.
That is true. I guess I've just been doing this for a while and remember the names (and sources) of apps I've installed.
I think staff values the perspectives of new users. This seems obvious to a lot of us because many of us came from other platforms--including one that was quite similar and whose terrible-ness we have to thank for Hubitat's mere existence--so it's sometimes hard for us to see things from the viewpoint of someone not already familiar with an analogue of this paradigm. That said, I'm still curious what the value is here--most people probably don't use custom code, and I guess I'm just familiar enough with what the native apps are so it's just something I'd know off the top of my head (and know a lot about any custom app I try before I install it: I can probably tell you the username, first name, and Github username of who wrote each as well as if I recognize them from other HA forums). If any app is (or you suspect it is) causing you problems--custom or not--you can try disabling it to see if it helps. If if turns out to be a native app (with native drivers), Support should be interested in hearing about it. if not, the developer probably would.
If you're a normal person who doesn't have the name and source of every built-in app memorized, most apps let you customize the name (app "label," technically) when you install them. Perhaps you could add "Custom - " or something to the front of your installed "user apps" to distinguish more easily. But most of the time, I don't see this really mattering.
If the distinction matters that much, consider using only native apps: the current built-in apps can do quite a bit for you, and there's always Rule Machine (also a built-in app), which has gotten quite powerful with its more recent revisions and which you can use to create nearly any custom automation that stock apps can't provide. (But if you're totally new, I'd really recommend trying the stock apps first to see if they can do what you want. Rule Machine is complex, especially if you're not familiar with Hubitat's event-driven model.)
I just noticed while making a Motion Lighting App I was unclear If I am using an app to make a new Motion Lighting App or what, and it reminded me of this thread. I am not confused by it, and I don't think the OP would be either, I think OP was merely calling attention to some details as somebody who is probably trained to spot such things. Akin to making a new language, distinctions matter in terms of definition which must be later relied upon without question and the initial formation of assumptions built into those definitions are typically called out occasionally by those who might apply slightly different logic that may have been originally intended, with the intention the attention might somehow better formulate a structure that may have improved robustness which benefits all. I think he is probably thinking along such lines, and irrespective of particular issues which may not be of substantial concern, such attention is generally useful by those tasked with managing the overall structure. He might be a new user, but I'll bet he is at least a power user on /something/ somewhere
There are currently two internal values for apps and drivers, user and system.
User is always applied when code is added to Hubitat from the web ui, system is always applied to drivers and apps that are built in.
System apps and drivers have access to several protected methods not available to user apps and drivers.
Most of these protected methods could be used for nefarious purposes or cause havoc if used incorectly, hence being blacklisted within user code.
There is actually a third enum allowing for driver and application retirement, it prevents new instance installs, but allows already installed instances to continue to function.
My only input to this is that as a new user I was confused by folks in the community using App interchangeably when referring to user community apps and drivers and Hubitat Apps.
I see that point of structuring to include a "store" for third party apps, including paid apps. I would appreciate a Hubitat reviwed/certified App program as a tier. It would include hoops to jump through such as self tests, code scanning, must have documented code, official support method/means, etc. Benifits for the dev would need to be sufficient enough to balance the work vs just slapping it up on Github.
I was aware of, but not familiar with the inner-workings of Github. That slowed down my adoption of the Apps and the platform. Being able to search a catalog of Hubitat certified apps wuth simple install would help the adoption of the platform for a broader consumer base.
I'm not sure what this means. The only officially supported apps are ones included with the hub firmware, so I'd guess that's already what you're looking for. Hubitat does not support third-party code (officially, though they've still been helpful with it in many cases), and the only thing I've seen them "bless" are HubConnect (saying they'd recommend using it when someone asked about something the native alternatives didn't support) and generally anything by Cobra (beloved author of many useful community apps; they commended his ability to write unproblematic code--there is always the risk of runaway code that could slow down your hub, etc.). That's probably as close as we'll get.
Thanks for the dialog - from all levels of this group! Much of what I read conveys an understanding and / or an open -mindedness and that's not always the case with this much brain power in one place (Grin).
My POV definitely is that of a newbie and that could easily translate to 'fresh look'. As a CMS web designer, (PHP/SQL) indeed my better skills seem to be around GUI's as some have guessed or intimated. We can't all be code ninja's right?
My first dialog with the community was related to debugging self-induced problems. That led me to look at the hubitat for ways I could track down problems. For example, I only have 30 devices but so many simple things like 'what groups does a device belong too', or 'what rules does a group include' - I was trying to trace why specific bulbs would not go off, thinking maybe a specific app was the cause. I'm using the web gui (firefox on a win 7 machine) - is this the best way to work with this unit? are any of you using telnet or cli or something I'm not yet aware of?
I laugh to myself about this - things like clicking an App take me to a front end page to create a new app, when I expect an app list of existing. It's these sorts of things I'm not sure where I go to look or feedback on. So far, my experience as a newbie is 'not ready for prime time [dumb user such as myself]'
And as my writing devolves into a wish list, I even wonder about pop-up text helps on things (like when you roll-over set Saturation and it says 'number 1-100'). [Ultimately, without using this board and just guessing at things, I found the problems that were causing all my stuff to act weird setting 'Enable device optimization'. Disabling that on all my groups fixed 80% of the problems I have]
My perspective is a wayward son's. My viewpoint tells me theres a missing balance to the work you all do, heavy on the code, weaker on the user feedback. Not everyone wants to write apps and drivers!
Anyways, it's early AM, and I'm not a great writer and I apologize if I post stuff that makes folks groan, I simply don't know where it's supposed to go, or if you even want/need my sort of feedback - so again, thanks for the responses! it was a great teaching aid to me about the heart and soul of this place!
Jim
Unlike say cell phones and computers that come pre-loaded with bloatware, apps, etc that clutter up your UI. Hubitat does not come with any app pre-installed, it is a complete blank slate. Therefore ONLY the apps you want and/or use will be on your UI. And the native apps Hubitat supports can be added from clicking the right tab here
Once YOU add an app that app is on your UI and will be on "list of existing" apps.
Thanks for the reply - I didn't state clearly. from the main web page, I select apps. Then I select 'groups and scenes'. Instead of seeing the create (add), list of existing (change) and move (re-move) which is what I expect, I get thrown directly into create new. The page should show MAC. Move/add/change, not just Add and (re)Move. imho this is just a simple gui fault. Same with
Notifications App and Simple Lighting app.
BTW - I have no idea if Groups and Scenes are System or User, one of the bugaboos I have as I have no idea how to report this or to whom :).
In the above screenshot, the "list of existing" is directly indented under "groups and scenes" If you want to "change" an existing group or scene you select the link of which scene that you've created that you want to edit. Clicking "Groups and Scenes" is used to "Create" them, not edit them.
In order to have groups and scenes available for you to create, you had to click the "Add built in app" in the previous post screenshot. ANY app in the "built in app" category, Hubitat directly supports and issues with them can be directed to Hubitat staff.
Many thanks Wayne! I appreciate your effort in your response -
I indeed had seen and was aware the list was on the main screen as you point out! I myself have many devices, and apps above that as well which pushes this pile of the list down off my screen. I wanted to sub-menu into it without the rest of the noise of the main page.
(The idea is likely that anyone who gets this far should know what they're doing. Lots of people on the forums run custom code, but I suspect it's a small percentage of total users that actually do.) If you're really not sure and have already installed the app, the "gear" (info) icon next to the app will show you the app's status page that shows information you generally don't need to worry about except for troubleshooting with the developer (or Hubitat), but the top-right corner will show "User Created App" or "Built In App". Personally, I'm able to remember which I installed myself--I don't do a lot, only if a native app can't solve a problem I want or if I think it would be too much work (or repetition if I have a lot of similar automations, slightly lessened by the new rule cloning feature) to set up in Rule Machine.
