I always heard it as: "if you make something idiot-proof, someone will make a better idiot." 
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.
-
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.
-
(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. 
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 
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 
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
Not going to get into some of the specifics here, but I have been using Hubitat for about 10 months now. I started in the very early X10 days with two lamp modules and a Stanley clock which had four buttons to control up to 8 devices. It was basically a glorified light timer. I then moved to two different X10 controllers which worked about 70% of the time. But that was better than pushing buttons on my Stanley clock. When I found Ocelot as an X10 controller I thought that I had died and gone to heaven. It worked at least 95% of the time and had lots of ways of controlling things. Mind you the learning curve would have been very steep if I had not already done Industrial Controls programming using ladder logic.
Once I got frustrated with X10 and it's unreliable communications, I found Insteon and began a difficult transition to Insteon. Again two different controllers before I found ISY which again was the best that I had worked with. Very happy with it for many years, but in the last two or three the development was off in different directions and the logging in process and Java was just plain frustrating.
Moved into a new house 11 months ago and after lots of research I decided to jump from Insteon to Zwave and Zigbee. In the process I found Hubitat and have been extremely happy from Day 1. Yes the programming is more drop down box than ladder logic, but I have been able to do so much more with my Hubitat in way shorter time than I ever could with my ISY. I automated my Christmas lights in about 2 hours where it took about 2 days with my ISY and I had way more flexibility with Hubitat.
So, from a guy that has been controlling lights and other devices in his house for almost 40 years, I can say without a doubt that you will never find the perfect product. But with 40 years under my belt, I can say that not only the product, but the support from Hubitat is the best that I have encountered so far. I have become so happy with it, that I am going to replace my Insteon at my recreational home this summer with Zwave/Zigbee and Hubitat.
10 Likes
Try Teamviewer for remote access, running on an rPi or other spare computer at home. No VPN required. It's excellent and free!
2 Likes
Because there is no need when I have a vpn built into my network already.
I have separate phone and PC dashboards set up. For the phone I keep to 3 or 4 columns wide, leave the width blank, and set the height to 150. On the 4 column wide dashboards I combine the middle 2 (plus the 2 below for some) for notifications, weather, or whatever needs more room. I also have Homebridge running and admittedly mostly use that as my dashboard.
1 Like
