How to write code for Hubitat

Developers
#21

In the past 6 months a lot of the popular apps got tagged as 'bad' for various reasons, not many of them clear except in the form of "remove them, the hub runs quickly again."

Therefore, about an hour after I decided to convert my "development hub" into an "upstairs hub" and thinking through the utility of Link to Hub, I saw I'd have complications with certain apps/integrations. Alexa and Google (Chromecast) were the first on my list because neither supports multiple hubs on one account. I also thought HomeBridge and Lutron were on that list but eventually determined that to not be true. I decided a third hub as some form of 'coordinator' of those apps that could exist on one Hub AND were tagged as 'bad'. (Homebridge is running on the third hub, but Lutron remains on both the other hubs.)

At the time I borrowed a new hub from a friend that hadn't even gotten around to unpacking it. I knew that if I was going to give it back, I'd have to get that 'coordinator function' moved back onto one of the two remaining hubs.

I like how it's working out though.. I may not go back to just two hubs. I'd say it's 90% unlikely I'll reduce to two. I like that the two hubs that have the radios (coordinator doesn't have the stick plugged in,) can't have Apps blamed on them. I like that I can contact support and not have to spend time on removing apps.

I like having double the radio meshes. I like that each Hub is handling a reduced set of devices and that it can spend more time on keeping those radio's unclogged. :slight_smile:

2 Likes
#22

That makes sense. I don't think I'll run into that issue myself. I haven't started on the basement portion of my house yet so I'm still unsure if I'll get a second hub. I still haven't finished all my upstairs switches (40) lol, but I'm close.

#23

I have more than a hundred ZWave devices and we know some devices can be chatty, for example power reporting. Time is our enemy because manufacturers keep creating products that we crave. And the more they pack in, the more ZWave (or Zigbee) bandwidth they seem to consume.

I didn't have this problem on Staples Connect, I can say to myself (and others), I didn't have this problem on SmartThings I can say. But since I've left those systems behind, my home automation 'habit' has not diminished. 12 Aeon MultiSensor 6's all wanting to keep me apprised of their Temp, humidity, lux, UV, etc.
The remaining 7 motion sensors (4 Iris, 3 Dome) are less than 6 attributes, but they keep me apprised too.

I've always had more than one Hub. For a brief few months, I had only one Hubitat running. Then I got a development hub, and kept adding devices to that Production hub. It was like getting back from vacation, being constrained to a laptop or tablet size screen, and having my full sized screen again... I'm back to multiple hubs.

#24

I'll be over 100 by the time I'm done. I have tile floors to do before I get started downstairs though.

How do you like those? I like the recessed install option, but I haven't been in the attic lately to visualize running outlets to where I'd want them. I have 5 of the Iris and 1 zooz 4in1. I'd get more of the iris if I could, but the one store I checked wasn't selling their iris stuff. The zooz is solid, but it's an eyesore so it stays in the garage.

#25

I'm of the same opinion of many many here... they are great, for ZWave :smiley:

The Iris v2 or v3 are much faster at waking up and getting their radios active than any ZWave , including the Multisensors. But the Multisensor is good enough and the extra attributes of humidity and lux means I can make a lot more use of them than is possible with the Iris.

I have two recessors still in their boxes because adding power is too challenging, at this time.

#26

I forgot about them being z-wave. I'm struggling to find a low profile option that isn't iris lol

#27

Wires :wink:

#28

Soon, I may want to try my hand at coding just to avoid a Frankenstein set of variables needed to calculate temperature variations throughout my home. Because RM's "Variable Math" function is limited to a single unary or binary operator per step, it's agonizing to create (much less edit!) any meaningful (i.e. nested) arithmetical expression.

Especially coming from Vera hubs (where we could utilize a programming language called Luup, an extension of Lua), or Multi-Hub Reactor (imbued with its own robust language called lexpjs). In Reactor, for instance, it is child's play to craft what I need from a single expression, which I demonstrate here in pseudo-code:

Average_temperature_fluctuation = ( abs(sensor_A - thermostat) + abs(sensor_B - thermostat) + abs(sensor_C - thermostat) ) / 3

In Rule Machine, this is a 20-minute process involving nearly a dozen intermediate local variables, multiple 'variable math' actions, and a Hub Variable to receive the results. But here's the kicker: The computed result appears to be non-deterministic — same numbers in, same steps, yet two or three wildly different answers come out!!

Answer should be ~ 0.667, which it always is at first. Then it swells to 72.5, then a few minutes later to 213.4, and then back to 0.667 or so. Not very comforting, and I suspect indicates some problem with the way RM handles order of operations. (Where do we file bug reports?)

Anyway, I digress...

Is there a simple template out there showing how one can write a few lines of (Groovy?) code to accomplish this task as a separate process, placing the result into a Hub Variable for my Rule(s) to watch?

Thanks for any master-class tips, guys.

  • Libra
#29

Not sure what you are looking for, but this thread about a dew point calculator might be what you are looking for.

Also some sample apps here

1 Like
#30

this is likely easier in webCoRE also, without going to groovy.

2 Likes
#31

Forget that. RM is ok for simple rules, but it's just not suitable for creating complex mathematical expressions or logic constructs, and probably never will be, at least not without a major UI overhaul. I don't think that's its intended audience anyhow.

Install webcore. The learning curve isn't bad, and you can create arbitrary expressions and assign the result into a local or global variable. The expression is parsed and evaluated on the fly so you can test things as you code.

The webcore UI runs in the cloud, but the rules you create (webcore calls them "pistons") run locally. If you're so inclined, you can also run the webcore UI on your own web server, but unless the webcore cloud UI goes away someday, I personally don't see the need.

I've got stuff running in both RM and webcore, but I find that almost any non-trivial rule is many orders of magnitude easier to write and debug in webcore.

1 Like
#32

Agreed and already devouring video tutorials like this one https://youtu.be/6d3wtjjCLiM

Thanks for the moral support!

#33

To me relying on any cloud service for a system like HE who's key strength is "local processing" does not seem like good a good idea. Cloud services can change on a whim or go dark. Much better to run the WebCoRE UI locally if you can. Looking at the WC forums it's not clear what is going to happen in the future if WC switches to using the ST Rules API.

As an aside - I'm not saying NOT to use cloud services just keep them on the periphery and not be the core part of your home automation setup.

#34

In general, I agree with you. However, as I understand it, even if you run the Webcore UI locally it still relies on cloud components for authentication, and maybe other things.

If/when ST discontinues its groovy platform then ST Webcore users may be SOL, but the servers the UI runs on are owned and maintained by the original developer of Webcore and have nothing to do with ST.

Of course, there's no guarantee he will continue operating those servers, but I figure there are enough people using Webcore on HE that something will be worked out so it can continue. Worst case, the pistons would still run, and I could rewrite them in NodeRed.

1 Like
#35

The developer works for Samsung/SmartThings and is possibly working on a native to SmartThings rule engine based on WebCoRE - at least that is what I am reading in the forums but could be wrong. Not sure what will become of the UI interface after that..

I was under the impression that that was all you needed. Only ST stuff requires additional cloud auth/whatever because of its cloud based services/components but dunno..

I really like the programmatic style interface of WC but in the end it will always be somewhat less efficient than using one of the RM apps or rolling your own.

#36

I don't expect that to happen (the SoL scenario). It would likely have folks host them locally.

1 Like
#37

Do you know if the local server requires additional cloud components if using HE?

#38

Today you can use the local server and if cloud components are unavailable, then the some features don't work (but there are local ways to do them on HE)

Note 2 of the webcore forum describes what are cloud functions of webcore.

Primarily it is:

  • save restore pistons via cloud (piston sharing)
    • this can be done with local backup files of the piston
  • webcore's email service
    • HE has community apps for email or one can use notification services in HE
1 Like
#39

If you can wean yourself off of those cloud components then using the UI server should be okay (local pistons still work even offline of course) with the caveat of possibly having to do a local server setup at some point in the future.. otherwise maybe "biting the bullet" and getting it set up now might be worth doing.. at least that's probably what I would do if I still used WC.

Note: I did run a local WC server for a while under SmartThings. Worked well..

1 Like
#40

As an(other) aside, for the benefit of future readers, I also understand that WebCore can run inside a Docker container, which means you could host it on an RPi or Synology NAS, even in Windows or a Linux box, etc.

2 Likes

Download the Hubitat app