Underwhelmed and Overwhelmed (I couldn't look at Underwelmed any longer) all Welcomed

I've found over the years that when something has been rendered "idiot proof".... only an idiot can use it.

What if you're not an idiot?

:thinking:

3 Likes

[2ndchanceor]
[SoundersDude]
What? No. You guys misunderstand. I don't want that. Reliable and idiot proof are different things.

If I connected to my hub, ssh-ed in just had a place to start writing Groovy and solid specifications documentation making calls to the appliance on this website, it would be A+

Casting it in a melodramatic light:
I'm hobbled into "code-through-lego," a half-broke half-baked gui that should still be beta release, and less then 1000 words on how to Develop anything on the framework bellow it.

Stepping back to a diplomatic tone:
It isn't that bad. It's just not that good either.

However, it feels like it could be...

In the old days the saying was "if it's made so any idiot could use it...only an idiot would use its!"

1 Like

If being an engineer, programmer and techy, yet still struggling with how complex a system can be is due to being an 'idiot', than I have no words for you that would be kind.

Many of us want to see HE continue to exceed, and thrive as a business. I'm sorry if you don't.

HE has the potential to be fantastic for the die-hard who wants to do everything on their own through code (e.g. groovy apps, webcore, more direct scripting) AND be friendly enough that someone not that technical can pick up and automate their home. And everyone who is in-between those lines. None of those are 'idiot', thinking that way might reflect something else in the mirror. :thinking:

1 Like

I always heard it as: "if you make something idiot-proof, someone will make a better idiot." :wink:

6 Likes

@cstempmail_hubitat. As a first time user, you landed in the right spot and are fortunate you didn't go through using products like Wink and Vera prior. What you'll find is most everyone here came from another platform prior and for good reason.

Edit: And welcome!!!

6 Likes

This is something I really miss in Hubitat, compared to a couple of other hubs I tried before (mainly Vera and HomeAssistant). Writing Rule Machine apps can be extremely clunky, and I wish I could just do them with a bit of scripting, even if just through a built-in IDE. (I really like HomeAssistant's GUI and scripting for automations)

BUT... I did give up those other hubs in favor of Hubitat. On balance, I'll take Hubitat any day.

4 Likes

That's pretty much what a Hubitat application written in groovy is...

5 Likes

My experience was like a cold shower when I tried that approach. After spending a lot of time fiddling around I ended giving up. Just because the documentation isn't there and the logic of groovy is just not my cup of tea. So I guess this depends on who's doing it.

This is NOT recommended by anyone at HE and you will not get support for hub issues but if you recently picked up or have a spare hub you might want to check out webCoRE. It's gotten much better apparently in terms of system impact and performance. The IDE and logic structure is great - one thing I miss from the ST days. Of course RM4 is very capable and native to HE and I've been able to do everything I've needed to using it. Again YMMV!!!!!

1 Like

Could this work if you have a ST hub and use hubconnect?

1 Like

I'm sure it could! Sadly my ST hub has gone missing.. so not a solution for me.

Well.... Yes and no...

While I do understand that writing an app is the way to go if I want to be able to write out code and bypass the RM GUI, there are some big differences between this route and a simpler scripting route for automations.

  1. First of all, it's "writing an app!" Not only does it sounds scarier to less experienced users, but it also does entail creating a whole app. That includes defining the app, declaring any app settings, creating pages, setting up logging functions, etc. And, as has been noted numerous times, the documentation on how to do all this is woefully lacking. We're forced to look through official code examples (also very lacking), and community apps. But, upon looking through a lot of different app code, I see many ways of doing things. There does not seem to be any "best practices" defined for Hubitat code, leaving developers and tinkerers to just make guesses as to what works.

  2. (I may be wrong about this, as I haven't actually tried writing my own app, yet. I would love to hear that I'm wrong on this.) Do apps allow us to address devices, variables, other apps, etc directly in the code? From what I can tell, you can only code an app to define eg. the type of device you want to work with, and then you will have to go into the GUI of the app after installation to select the actual device(s) you want to work with. In Home Assistant, you can code device IDs right in. (I know many will decry having hard-coded device IDs in scripts, but in reality, a device ID should never change unless you remove/reinstall a device, so I'm happy enough hard-coded them into scripts)

Here's a snippet of code taken from their "Cookbook"

automation:
  - alias: 'Rainy Day'
    trigger:
      - platform: state
        entity_id: sensor.precip_intensity
        to: 'rain'
    condition:
      - condition: state
        entity_id: all
        state: 'home'
      - condition: time
        after: '14:00'
        before: '23:00'
    action:
      service: light.turn_on
      entity_id: light.couch_lamp

I would love if Hubitat had something as easy as this for setting up my more complex automations. Especially when it comes to debugging, and inevitably wanting to make changes and move things around. In Hubitat (without creating my own app), I can't simply cut/copy/paste a block of code and move it elsewhere. I pretty much have to delete a bunch of lines, then re-insert the code again, one line at a time, using the clunky point-and-click interface.

Having said all that, I'm really not trying to knock the Hubitat team, and Home Assistant's automation engine isn't perfect, either. Like I said, Hubitat is absolutely my favorite Home Automation platform at the moment. I just think it could be that much better if a few things were different.

1 Like

Hubitat has published a very tiny set of example code.

Example Apps and Example Drivers.

They make good starting points, since deleting lines of non-useful code is easy. :slight_smile:

There are many apps provided by Community members too:

You can edit them in the Hub's own editor, or in your favorite programming editor and then just paste the code in.

I'd start there and see if this is good news or not..

To clarify, device IDs are a recent addition and were never intended for the user to "code device IDs right in". The goal was to allow users to create triggers (for automations) that are device-oriented as opposed to entity-oriented. The belief is that this is a more intuitive way for new users to create automations (using the GUI-based Device Automation Editor).

The Editor displays devices by their names whereas their auto-generated, long-winded IDs are not revealed to the user (in the UI).


The automation example you posted from the cookbook uses an entity-based trigger. This is Home Assistant's traditional way of creating automation triggers. You can create automations using the built-in Automation Editor (similar to but not nearly as elaborate as what Hubitat offers) or using a text editor.

Personally, I prefer to use a text editor (VS Code). The resulting files can be backed up anywhere and shared with anyone. Some users use their personal GitHub repo to both store and share their files with the world. Sharing automations is easy because you can post them (wherever) and others can simply copy-paste them (like you've done above with the cookbook's example).

The ability to easily share one's automations (through simple copy-paste) is, I feel, an important advantage. It allows automations to be easily distributed and consumed.

It's important to point out that some people not only do not find it easy, they dislike it to the point they offload all automations to Node-Red (or simply move away from Home Assistant altogether). Although the automation you posted is simple for me (I've been writing them for over a year), learning its structure (YAML) doesn't come easily to everyone. That's why there have been efforts to improve the GUI-based Automation Editor.

Effectively, Hubitat and Home Assistant have approached the problem from opposite directions. Hubitat's approach is entirely GUI-based whereas Home Assistant's has been text-based (with lip-service paid to a GUI-based facility). Now Home Assistant is focusing more attention to refining its GUI-based editor. Perhaps Hubitat's team should add to their roadmap a text-based means of creating/storing/sharing automations.

4 Likes

Oh, when I referred to "device ID" in my post, I didn't mean it in quite such a specific sense. I realize that there's a difference between the device ID and entity ID in HASS, but I basically just wanted to point out that you can refer directly to a device in a script :grin:

This is definitely another good point, which I forgot to include.

And yeah, very complex automations can get a bit overwhelming to code, but sometimes you have an automation that isn't necessarily very complex but it might be quite lengthy. eg. You might have several blocks of similar code, that would be easy to copy/paste in an editor, but tiresome to do in the GUI.

Another point I forgot: I recently saw a post from somebody who had a rule that appeared to be broken somehow. Something perhaps in the DB. I don't recall if it was a particular complex rule, but I don't think it was a very simple one. I believe the only solution offered to him/her was to scrap the rule and write it again from scratch :confused:

1 Like

There's another concept in YAML called anchors and aliases. In Home Assistant, anchors and aliases are more applicable to defining entities, where there may be more repetition, than to automations.

Let's say you have a ten sensors and each sensor requires 6 lines of data to define it. That's 60 lines of text to define ten sensors. However, you notice that 4 of those 6 lines are repeated verbatim in each sensor. Sure, you can copy-paste all those lines or you can just use anchors and aliases.

In the first sensor you assign those 4 repetitive lines to be an anchor called "stuff". In the remaining 9 sensors, you simply add an alias that refers to "stuff". Done. So now each one of those 9 sensors just need 3 lines to define it (2 lines of data plus an alias) and not 6 lines.

To be clear, this is a capability of YAML (and is not unique to Home Assistant).

1 Like

@123 @jason-lane,
<3s don't adequately express how happy I am to see this thread resonating with you. Thank you for understanding, empathizing, and elaborating.

1 Like

I've ben with ST since the beginning. Took me about 4-5 hours of setting up all of my stuff. This was because I hd other work going on at the same time and kept getting up and walking around. I also didn't bother reading any documentation outside of asking a few questions or watching something on YouTube. I like using Rule Machine, but it does have a learning curve. I like that I can clearly see what something I set up is going to do. And if it doesn't, I can easily see where my error was and quickly fix it. I really wish that I could change things when away from home, but I just need to set up my VPN again and should solve that problem. I do wish the app was something rather than a dashboard. The tiles are way too big and should be smaller for creating a dashboard to work on your phone. I'll get back in to learning css and customize it more to my liking. I'm liking it so far.

You may also wish to consider SharpTools, which has an interface to Hubitat.

And, if you get really adventurous you can use HubConnect to connect Hubitat to your old SmartThings, and use their app again. (You will be surprised at the performance).

1 Like