The desolation of a quasi-poweruser

💬 Lounge
1

I am writing this because I have reached a point I have not reached many times, despite my limitation in this field. I feel helpless.

It's not like I'm a complete idiot. I have experience in rooting Android phones since the G1, using FTP, building my own towers, setting up personal servers, and I actually work for one of the big three in tech. I'm not technical, but I understand what is being talked about. I've always had a love for technology, and have always been an early adopter, whenever my geography and financial status allowed. I love beta testing things and sending feedback, trying out things that may not work 100%, but is always fun. As any, I have a leaning for open source and having things under my control.

So after researching how to start up a smart home project, I knew I wanted to start with the brains before I even considering buying any bulb, switch or dimmer, and Hubitat was my first and only choice, due to its openness, DIY-vibe, and onsite control.
Before making the purchase a couple of weeks ago, I read through the forums for at least a couple of months and sifted through issues people were running into, how it was resolved (if it was) just to make sure I could handle it. Truth be told, I wasn't sure at the time, but I thought "When I get the hub in my hands, it'll all click". All the different terms, jargon, workarounds. It seemed like all I was missing to understand the solution was facing the problem myself.

I was wrong. This subject is too overwhelming, and there isn't enough clear documentation, where someone with a lack of skill but plenty of determination can succeed. Despite the integrations and compatibilities that are being created by this wonderful, full of potential community, it's clear this technology still has a lot to develop before it reaches a cohesive solution.

Please don't take this as a complaint, but as me venting out the frustration of my incapability of carrying out this project.

I really wish I was able to get Hubitat up and running, but it seems I'll have to relegate myself to the discontent of the myriad apps that will inevitably run my house for the foreseeable future.

2

If this is the long version of "Help", can you explain where you are in the process? Is your hub Registered, for example? Have you added "Simple Lighting" app to get started or??

Do you have devices you are trying to control?

It's daunting, sure, but

"Small moves, Ellie, small moves"
-- Contact

Outline for us, the FIRST thing you want to get working, please

4 Likes
3

I understand you. The learning curve is quite flat at the beginning. but it's exponential. Had at least 2 days of thinkering to get a good strategy for my rules and the understanding. I own the hub for about 3 weeks now and are at the hardware limitations like (hue hub basically mandatory).

1 Like
4

I agree! The rule machine drives me nuts. I work through it with trail and error.

2 Likes
5

Doesn't that depend on your setup.
I have 3 Hue RGBW lightstrips that are connected to the Hue Bridge.
If I didn't have them I wouldn't need a Hue Bridge.

I do agree though that the whole thing can be a bit daunting in the early stages.
I found the more i played the easier it got and I now have a setup that doesn't need much maintenance.
(Doesn't stop me tinkering though). :wink:

2 Likes
6

Obviously it depends on the setup, but if you have smart bulbs on zigbee a hub is "recommend". doesn't matter what brand (hue, osram... what ever. slengled is an exception, but you need probably a repeater).
That's what was told me in a specific thread about "get rid of the bridge"

PS: I meant hue bridge... not hue hub.

7

Actually, osram smart bulbs in the US use the ZHA profile, and won’t work with the hue bridge because it requires the ZLL profile. Bulbs from most other brands can use ZHA or ZLL, and outside the US osram Lightify bulbs use ZLL too.

8

Pedro,

The first step is always the hardest and you do seem to have put a lot of effort into research before purchasing. But I’m not quite sure what your looking for as a response to this. It’s your first ever post so have you tried some things and they’re not working? if so give us some information as to where you are at and what’s making you feel so desolate.

9

Wow, guys! Thanks so much, I appreciate the support, and it's somewhat comforting knowing it's not just me having this feeling.

@csteele wasn't really a call for help, so much as it was a loud and desperate "AAAARRRRRGGHGHHHHH!!!!"

@kevin I appreciate your concern. I'm more of a reader myself as usually, in this type of setting, I don't have much value to add.

As for the help part, I'm not even sure what the problem here is. I'm not talking only about my issue at hand. I'm also referring to the instructions not being the most intuitive for non-techies as well as the plethora of possibilities depending on the scenario.

But to explain my POV, I'll have to share my "setup"

I have:

  • Hubitat Elevate (has been successfully configured) - Only hub
  • Some generic RGBW B22 WiFi Bulb x2 (associated names are Bomcosy, AOJA, and the controller inside seems to be Espressif, according to my router) - Connects via SmartLife app.
  • Aeotec Wallmote Quad x2
  • Google Home (Google Home is already linked to Hubitat and Smartlife)

Each bulb is a bedside table. Ideally, I'd be able to press button1 on one of the wallmotes and toggle on/off one the bedside bulbs. Maybe assign button 2 to toggle both and button3 for some colour. Also, control them with Google Home/Assistant (this I already do).

I realise the big hump over the wall is getting a Zwave device to connect to HE, which in turn goes through the router (I think), to activate a not-supported-out-of-the-box Wifi Bulb.

BUT!
I don't even know where to start! I mean, I've already added the driver's and the app code by erocm, but then the concept of Child and Parent came into play, and there were separate drivers for each, plus even once you do get them installed, the setup process within them is not very self-explanatory (What exactly IS a Virtual Device? What's the difference between the Device Name and Device Label? What is the Network ID? is it the MAC or IP, or none of the above??). And on SmartLife (SL), I, for the life of me, was not able to find a single relevant google search on the matter. I was. astonished.

Even the wallmotes were a nightmare to look at. Don't get me wrong, pairing them was as easy as any setup process, but once I got to see the configuration panel... I did not know which way to turn.

A simple toggle within the CPL to just the turn off the "beep on touch" from the wallmote proved unsuccessful (yes, I did save, and wait for the refresh).

I don't know, it's just too much discombobulation. For the first time, I feel like the butt of a "PEBKAC" joke. I'm usually everyone else's tech support around me, but this is a whole 'nother beast.

I'll probably calm down over the coming days and give it a "light try" on the weekend, but I'm not hopeful.

FWIW, if any HE dev's are reading this, don't despair with my words, I won't give up, just take a break. :slight_smile:
I'd love to help you guys sort out some of these issues. My experience is in UX Design and honestly translating code-talk to layman's terms (I worked at a couple of startups where the CEOs were not technical at all, even though their company was web-based). With some help in understanding the underlying concepts, we could hammer out some easy-to-read documentation and some appealing videos, as well as some scripting guidelines on how to write tutorials and articles.

10

I'll try to help with a few of what you listed.

What this is referring to is there is a "Primary (Parent device)" that also has "Secondary (Child Device) controllablility. For example My Roku TV is a "Parent Device" at which can be turned on/off AS WELL AS within the same application installed it provides the functionality to select or automate the actual APPS (child devices) on the Roku TV. In a broad sense its control of multiple different functions within one actual device.

A virtual device is true with it's name. It's a device IN NAME ONLY, that has the same functions as if an actual device were present. What this is especially used for is a trigger, for example I have a iHOME (wifi) plug in switch which is not a compatible device in Hubitat, but it is integrated into IFTTT (which does work with Hubitat), so I have the "virtual device" set to turn on when IFTTT says to turn on the plug in device and vice/versa, thereby providing actual direct control over a virtually integrated device into Hubitat without having to go to IFTTT or iHome app to access it.

Device Name is usually what you want to call the item (Ex: Bedroom Light)
Device Label is usually what brand and/or model the device is
Network ID is the identification that Hubitat uses to separate it from other devices (zwave devices usually use specifically numerical order) you can type in anything here for virtual devices, otherwise it's usually automatically assigned when the device is included/paired

1 Like
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