The desolation of a quasi-poweruser

đź’¬ Lounge
11

Thanks @waynespringer79, it does help! You gave a very clear and understandable answer. But it also corroborates what I was saying, that the documentation isn't clear enough for, I would say, most people.

The terms themselves don't help either. Are these terms already in use by other platforms, or is this an HE-thing?
If so, I would definitely change the terms to something more tangible. Calling "Devices" to both HW and SW components is sure to create confusion. This may make sense in coding, as the definition would be pretty much the same, but a regular user would never see the distinction if the same word is being used.
The same thing goes for "Virtual Device". I understand the concept (thanks to wayne), but in practice it is still a REAL device, not virtual. It's just an unsupported device, which needs some extra steps in order to be integrated with HE.
Instead of "HEcommand --->device", it goes "HEcommand---middleman-->device". But that's it. It's still a real device.

Also, regarding the "Virtual Device" menu, instead of having the title greyed out and replaced when something is typed, it should have a permanent title in black, and a small explanation of what it wants in the greyed out area, just like in most websites.

107%2098ffd145a1c7
2019-04-24 11.39.58 192.168.1.107 98ffd145a1c7.png1073Ă—319 7.58 KB

An example: Title: "Zigbee ID"; Greyed out: "You can find this number on the device" OR "check your device's box for locating this number". Something that, if I don't intrinsically know what I'm being asked for, at least can point me in the right direction.

I don't know, maybe I'm overcomplicating things. Does anyone agree with this, or am I subconsciously passing on the blame? lol

12

Most of the terms are a carryover from the Smarrthings platform (we have a LOT of users from there). HE is built on a similar framework from a software perspective. Some of the terms are shared across other platforms as well.

Not necessarily. A lot of people use virtual devices to tie in incompatible integrations in order to control real devices but it's a lot more than that. Sometimes it is used to provide a visual representation of a mode or state the hub is in. Virtual is in fact the best name for this device because it in itself is not directly tied to any hardware. It can be, but it may not be. It is one of the most powerful aspects of of this and other platforms because it is very versatile and it's uses are limited only to the imagination of the platform's users.

Learning to use this platform can indeed be challenging. The best advice I can give you is to start with simple and fully supported devices and apps .Build a simple automation like lights on with motion to get your feet wet. Stay away from wifi lights etc until you are more familiar with things and use the greatest tool Hubitat has to offer before pulling your hair out....the community. It is our greatest strength.

1 Like
13

I understand your point, but unfortunately, I had no choice in this case. B22 lights are not easy to come by (I should just throw my fixtures away), and the only ones I found were on WiFi. Plus, I'm still having issues wrapping my head around the Wallmote setup and that IS supported...

Can you explain this a bit further? I'm not sure I'm grasping the whole idea yet. Otherwise, why not just have a "status" box for what you're referring to?

14

No, I'm not saying you shouldn't attempt to get all your devices online. I am saying that you should start with devices that don't require jumping through hoops to get configured. If the device driver isn't built in, then you may get frustrated trying to put a square peg in a round hole....especially if you are not yet familiar the platform basic yet. Always start simple, learn a little and branch out from there. When I started on Smartthings, I felt the same way so I bought a cheap motion sensor, contact sensor and a zwave switch. I built a couple of simple automation and slowly started adding devices. Over time and with the help of that community I am now able to build pretty complex automation and even write my own apps.

My point is that I think you're jumping in the deep end and getting overwhelmed.

2 Likes
15

Virtual devices can be a rabbit hole because like I mentioned...their uses are practically limitless.

In essence they are devices that can look and act like real devices but don't physically control anything.

For example, I can make a virtual switch. This device type has 2 states, on and off. The virtual device will never change states because the is no REAL switch to trigger a change in state. However, through apps I can programmatically change the state to on or off. I can then tie events and automations to start or stop based on the state of this virtual switch. All thus can be done within an app itself but the benefit of doing it this way is that I can put this virtual switch on a dashboard that let's me "physically" trigger the automation to occur. I can also add the virtual switch to a voice assistant like Alexa to "turn on or off" the automation.

Hopefully that makes sense.

2 Likes
16

You're totally right about this. I overestimated my capabilities on this OR underestimated the difficulty xD

It does make sense. And for tech-savvy people, I'm sure it's more than enough. But from an end-user standpoint, I would say it would make more sense to have a viewer to show what state the device is currently in, with a dropdown for all the automated modes you'd be able to put it in.

I'd just like to point out that I'm building upon your points to show a possible way of improving the userfriendliness of the system. After reading back my answers, it seems I'm trying to argument what you're saying, but I'm not. :slight_smile: I appreciate your explanation and I get it.

I'd like to suggest to the HE Team a Glossary blog entry (not just the Common Acronyms and Abbreviations Wiki), located in the tutorials section of the website, so that when a user is looking for a solution and comes to the forums, they already have a good vocabulary on what is being said.

17

I would jump in to say have you looked at the tutorial videos? They are very helpful in getting started.

I realize you are probably further along with your tech knowledge but the videos can fill in some missing pieces. Also I agree with the others.. step by step. I would say a lot of us have had issues especially at the beginning. There is a logic to it even if it is different from what you are used to.

1 Like
18

I think what would help is for you to understand the Architecture of the Hubitat Platform. From a very high level, Hubitat and SmartThings are based upon two main tenants - Devices and Apps.

Devices have Capabilities. Each Capability defines a standard set of Commands and Attributes. For example, a device which implements the Capability "Switch", must implement the "on()" and "off()" commands, and expose the attribute "switch", which must be one of two states - "on" or "off".

To implement the Switch Capability, a Device uses some groovy code called a Driver. The Driver is where the actual code is implemented to determine what happens when the commands "on()" and "off()" are called. In the case of a Physical Device (i.e. Zigbee, Z-Wave, or LAN), the driver will make calls to Zigbee, Z-Wave, or LAN API libraries which in turn communicate with real physical devices within your home. These devices will then respond back with an update which the driver translates into a status update to the "switch" attribute. Virtual Devices, on the other hand, will only modify the internal "switch" attribute value when "on()" and "off()" are called. In both cases, whenever the "switch" attribute is updated, an "Event" is created system-wide to let Apps know that something has changed.

Apps are the glue that links everything together. Apps typically subscribe to "Events" from Devices that your choose within the App. Once an Event is generated by a device, the App will call a function within its groovy code to perform some sort of logic. Often, this logic will be to call a Command on a Device. So, in the example of your Wallmote Button Device, it creates button "pushed" Events, which an App like "Button Controllers" can subscribe to. When your "Button Controller" app instance receives the proper event from the Wallmote Device, it will perform the logic you have defined to call the "on()" or "off()" command on the Switch Device that you've chosen within the Button Controller App.

Understanding this architecture will server you well as you continue your journey of learning this new platform.

I hope this helps in some way! :wink:

Dan

7 Likes
19

Welcome to Hubitat.. As others have suggested, there some excellent tutorials that are available. Some may appear to be very basic, while others may not. I suggest spending an hour some evening and watching a few of them to get better acquainted. You'll probably have the basic layout of the system mastered within that hour.

Following on what Dan wrote... Here's a good example of why watching the videos is helpful... There's no need for what you are asking because the information is already available in each device page. Those states are called attributes, and within each device page all of the current values of those states are displayed.

Heres an example...

54%20AM

Under Current States you will see a list of all attributes and their current state for a particular device.

2 Likes
20

... for sure, but screw-to-bayonet adapters are. Although it could be limited by your particular light fixture dimensions, maybe something like this might allow you to use Zigbee bulbs that are natively supported by HE?

1 Like
21

Also - some of the SmartThings documentation is very good and will help you, for example articles on capabilities, device handlers (drivers) and attributes, devices / child devices, apps / child apps.

You will have to be wary that some of the nomenclature is different and the way of installing apps and drivers is totally different but if you get stuck on something in HE it may be worth seeing if there is a something helpful on the ST site.

I wouldn't recommend just arbitrary reading of the ST site though as that would just add more confusion for you.

Are you in the UK @SmoothMarx ? If so IKEA stock those B22 converters too. It might be beneficial to add at least one 'officially supported' bulb to your setup to see how easy it can work.

1 Like
22

Yes, these terms are almost universally adopted as the 3 different platforms I've used all used these terms.

Most of everything you have listed that you are confused about, the answers can be found in one of two places. 1. Hubitat Tutorials or 2. YouTube Videos on Smart Home automation basics.

1 Like
23

The terms themselves don't help either. Are these terms already in use by other platforms, or is this an HE-thing?

Yes. I knew the terms only cause I came from Smartthings. The thing about Smartthings is it does allow a very shallow pool to dip your toes in. You find out though if you want to integrate anything not supported you need to start accessing the dev panel.

Hubitat gives you the dev panel it of the box and that can be overwhelming. I credit Smartthings though with making my transition easier.

3 Likes
24

I watched them when I was researching the different options, and used them to setup the Hubitat. I'll go through them again, but I don't recall any mention on how to interface with WiFi bulbs. Could've missed something, though.

After going through your link and explanation, it's becoming clearer.

So, if I understand correctly, these capabilities of the device, what a particular device is able to do (ie features), are all segmented. So a Color light Bulb (like my WiFi RGBW), has the capability "bulb", but also the "color control" and "color temperature", and possibly some others, and then these commands will get translated to the appropriate protocol of the device in question when activated.
Am I assuming correctly?

I still am not entirely clear on the Apps part. I understand what you mean, it's basically a series of triggers that call for other things to happen. It's the mix with Virtual devices that is not clicking with me. I don't know what's missing, but my lightbulb moment hasn't happened yet, although thanks to you, I'm much closer. :slight_smile:

I definitely have to spend more than an hour, lol
That example just made it more confusing.

That's my issue exactly. I previously had some adapters, but made the bulbs sit above the lamp covers, rendering the covers pretty much useless and would have the bulbs shooting direct light in my eyes. Not the best when you just want to do some light reading before sleeping, lol

Given that SmartThing is a bit more easier for users, I'm gonna give it a look, and see if they have further explanations for all the terms.

I'm in Portugal (close enough). I have some other bulbs on the way, but regrettably they're also WiFi. I guess I may order one supported bulb, just to ease off the rage, but the Wallmote was daunting enough and that is supported.

Trust me, I've already gone through my share of video tutorials, reviews, etc. I'm not very logically driven in these things, and have this need to completely grasp the concept before being able to tackle it.

Yeah, although I'm used to this kind of situation. I guess the difference is that I usually already have some background on what I'm doing before delving in, such as rooting. But this is completely new to me.

.
.
.
Despite my struggles with HE, one thing I cannot fault is its community! Thank you :slight_smile:
You guys are great. Your support and help has definitely given me a second wind to face the hill again.

So, besides all the intro tutorials I'm going to re-watch and ST glossary I'm going to take a look at, can anyone point me in some documentation regarding generic WiFi bulbs that use the SmartLife app? I've read somewhere you may need to flash new firmware, but there's no way I'm going to do that right now, lol

1 Like
25

One thing to consider.....when purchasing "wifi" devices....by design they are "intended" to work with you internet router (which is why they are called wifi devices), they are not intended for a home automation platform initially.....whether they are able to integrate with a home automation platform like Hubitat is a "bonus" but not being able to integrate them is not a bug or fault of the platform, as they are not Zwave or Zigbee devices at which Hubitat is built for.

Also considering that anytime you try to adapt something that it wasn't initially designed to do (device not listed in the compatibility list), you should expect to not have what you hope to accomplish happen without issues, there may be workarounds to accomplish what you seek, but if you looking to have a more seemless adaptation of the platform, then I would highly recommend you take the advice of @stephack by adding devices that are listed as compatible, then after you have played with them and the platform to learn the operation, then begin to adapt the devices you have that aren't currently listed yet.

.

1 Like
26

Yes, that is correct.

Virtual Devices... they are very useful for some users, and for others not necessary at all. Let me provide an example where I use a specialized virtual device using a driver that I wrote. This driver implements both the Switch and Motion Capabilities. I use this driver to create a virtual device that is not connected to a real physical switch or motion sensor.

So why would I create this? Well, I have a Ring Doorbell. Since Hubitat currently does not have an official integration with Ring, I wanted to come up with a way to tie Ring to Hubitat. So, I found a common denominator between the two systems in the form of Amazon Alexa. Both Ring and Hubitat have Alexa Skills. The Ring Skill allows Ring Motion events to trigger an Alexa Routine. Within the Alexa Routine I am able to manipulate Hubitat devices. However, Alexa can not change the state of a Hubitat Motion Sensor. It can, however, change the state of a Hubitat Switch. So, by creating a Hubitat virtual device using my custom driver, and then exposing it to the Alexa Skill, and then using an Alexa Routine... I am able to link Ring Motion Events to Hubitat Motion Events. I can then use these motion events in Hubitat Apps to perform any logic desired. For example, I turn on my outside lights if my Ring Doorbell detects motion in the middle of the night.

This is only possible due to the availability of virtual devices. Does this help?

1 Like
27

Hey guys, sorry I took so long to reply, but life.

yes, but it was the openness of Hubitat that became one of the deciding factors in my purchase. It is the only one that supports all wireless protocols, one way or another. Although, I'm quite surprised they didn't offer WiFi integration out-of-the-box. I thought that'd be a given, even if it didn't come with a radio.

I was actually referring to some simple B22 --> E27 adapters so I could have regular lights on it, but they just sat too high up for their use. But point taken, I should just change the fixtures, lol

I started off with "yes!", read it a second time, changed to "maybe", and I'm currently on "not sure". You're basically using the Virtual Device as a double translator between Alexa Skills and Hubitat Skills. Let me write down my math to make sure I'm getting it

  • Ring senses motion --> Triggers Alexa Skill
  • V.Device detects alexa skill --> activates VD motion switch
  • Hubitat activates HE motion switch ---> can do anything else

Was that right?

Today I'm spending the time going through tut's and learning how to setup a wallmote. I'll think about the bulbs when I get there.

28

Almost...

It is the Alexa Routine that is the bridge between the Ring Skill and the Hubitat Skill.

  • Ring Senses Motion —> Triggers Alexa Routine
  • Alexa Routine —> Turns “on” Virtual Hubitat Device
  • Virtual Hubitat Device —> Causes a “Motion event” within Hubitat to do whatever logic you want.
1 Like
29

I'm sure Hubitat would like to hear from you about what is non-intuitive about the docs. That kind of feedback is very valuable.

I've noted that a lot of frustration from new owners is caused by not reading the documentation. Not sure how Hubitat could do better to show new hub owners that it's there. They show you it in the start up overview that's built into the hub registration process, they have a button that links to them on the welcome screen of the hub, you can get to them from the question mark in the upper-right corner of the hub UI, and it's in the title bar of the Community landing page. Have any suggestions for them?

I'd like to call to my fellow owners to always point new users to the docs when they express frustration. I only noticed @ogiewon linking to the docs in this thread, and @erktrek linking to the video tutorials. However, I'll caution against pointing to the video tutorials only, as many of them are dated now, and platform/setup isn't always the same in the current builds that new owners will have. It's very costly and time consuming for a small company to update videos, but it is fast and low cost to keep a wiki updated. Seems many are skipping reading the documentation, just like @mike.maxwell did for the Hue Outdoor Motion Sensor :wink: The Hubitat Documentation Wiki is your best place to start, and then hit up the community for help when you don't understand the doc you're reading, or you need further assistance.

https://docs.hubitat.com/index.php?title=Hubitat_Elevation_Documentation

3 Likes
30

That is an excellent point except the videos are the "official" company ones. If they need to be updated that is on HE and is potentially a serious issue for newcomers - why have them up at all? Will definitely rethink recommending them in the future. Thanks for the heads up.

1 Like