Hub process slowdown after several days

Nice allusion. One of my favorite movies. And wasn't the original released around Christmas?

1 Like

August 30, 1985
Almost Christmas :sunny: -> :christmas_tree:

1 Like

I did run into a sort of anomaly with using a small app vs RM. I had something that apparently was turning on and then immediately back off. In RM it didn't catch both events, just the ON. But my app caught them both. It was good in a way as I found out a problem I didn't know I was having. Bad in a way as it wasn't really affecting anything and now I have to solve it.

2 Likes

Yeah, I found the same thing in one of my home arrival apps. RM was triggering my door locks to unlock even if they were already unlocked, which does nothing but drain more battery. sigh I guess I could have handled that in RM with an IF statement, but I find it easier in Groovy.

Copyright or intellectual property issues aside, I could almost see this being an app used on a desktop or laptop computer, then just copy/paste the code it spits out into Hubitat. It seems like that would give faster processing or building of the rule, and keep things off the hub that aren't really needed on there. For good or for bad, you also could share rules that way without having to export them off the Hubitat somehow, or write rules for other people who cannot do it for whatever reason.

3 Likes

Or, have a method (or app) like Maker API that allows a JSON post from the app that created the code to post it directly into HE.

Poor @bravenel... He's going to be working for years on our ideas. :wink:

I neither like this:

nor this

Reason is simple. Hubitat shouldn't be reliant on a third system to operate. To make an "IDE" that runs on a desktop creates a lot of complexities, e.g. which devices are available, what are the capabilities, commands and attributes, etc. Also the "desktop app" would need to communicate with Hubitat. How many different clients do you need to code for to accommodate all the different operating systems that are out there?

IMO, Hubitat should stay on the course that they are now. Don't be reliant on a third system. However, if there is an opportunity to reduce overhead, like @bravenel 's (so far) theoretical idea does, than I am all for it.

4 Likes

True and valid points. Make it a web interface off of HE.

However, if people were able to create their own IDEs, I'd be supportive of that especially since we have the Maker API already.

Not necessarily: you could just have a desktop app--or web app or anything, really--that just spits out Groovy you can copy and paste into the Hubitat app editor. (That was actually how I interpreted one of the ideas above.)

I'm not saying this is a good idea, and I'm certainly not saying it's user-friendly, but by the time you get to creating custom code, you're out of the "regular user" category, anyway. :slight_smile:

3 Likes

The overhead I was referring to was the size of the source code. At run time, the overhead has to do primarily with settings and state. So a simple rule does not have very much overhead. A Simple Lighting rule would have less. But the code itself is loaded once, not multiple times.

What you can try sometime is create a small simple rule, and make the first action a Log Action. Trigger it with motion or a contact or a switch. Then you can look at the timings in the Logs to see how long it took to get from the motion event (from the device itself) to the log action. Now, do the same with a small app, and put a log.debug in the app for when it comes to life from the motion event. Compare the two timings.

Sorry, but RM is not an interpreter. It actually executes code fairly directly to implement the actions of a rule. The amount of overhead to do that is actually quite small. However, obviously, if you create a humongous rule with elaborate conditions, it will take more effort to evaluate those conditions.

You know better than I do so I'll be quiet from now on :slight_smile:

Are you sure that RM had both events subscribed to? A second event will launch a second instance, and this certainly happens for events only a couple of milliseconds apart. There is no reason that closely spaced events would not cause RM to catch both, as the platform does it.

We already have the JSON output thing working, and the reimporting of it. Hmmmm, I wonder what that could be used for?

But you're missing all the fun!

2 Likes

What can import JSON and convert that into rules? Did I miss an announcement somewhere?

No, it's just some dev work.

3 Likes

Man... to be a fly on your wall... LOL

Sooooo, rules expressed as JSON objects? Holy crap that would awesome.

That's what I am doing when I mentioned above that I created an app to do the same thing as a rule. Which I am just using to monitor whether I'm getting a slow down. I run the rule, or app once a day and note the timing.

In all my tests the rule takes about 200 msecs to run (at it's fastest) and the app runs in about 50 msecs.

The trigger was set up as changed. So it should have. I had it happen twice since I created an app and disabled the Rule I was previously using. I had never had it happen when using the rule. Course, it could be something that just started happening. It was no big deal and easy to fix.

EDIT: I should clarify this. I am using Mode Manager to control my modes. One of the controls is presence based on 2 phones. I then had a rule that looked for Mode changes and did quite a few things based on what mode it went to. One of the things was to send push notification of what the mode was. Apparently one of the phones was going out, back in, and out again within a very short period of time. And Mode Manager was changing the mode along with it. Once I made an app to look for the mode changes I started getting the notifications of the mode change. Which I didn't get the fast changes with the rule.

Hope that made sense.