I have a rule which I have used for some time and that has worked fine. The rule basically tracks the outside light and the outside temperature and sets the heater inside depending on the combinations of light and temperature in relation to a given threshold value for each variable.
Today I was going to adjust and extend the rule a bit. The changes I made was to remove hard coded values and replace the hard coded values with variables. I also wanted to ad a check to see if any door was open before turning on the heat. But after the changes was complete and I pressed 'Done' I got an error message. Since the error message I am no longer allowed to access the rule. When I try to open the rule, I only get the error message. The error message is as follows:
I am not sure if you can do an IF-statement within an ELSIF statement and I wondered if that was the problem, so I disabled the IF-statements. Even if that was the error I should still be able to save right as the lines now are disabled?
And the defined variables are as below. I have not used all of the variables yet, I just defined them for future use. Can that be an issue?
If I use an ELSIF statement, can I only use the same variables in all ELSIF statements (I had to ad a temperature reading in two of them which does not occure in the other statements)?
Yeah @FriedCheese2006 , it is, and it takes for ever to write and adjust. I haven't gotten around to learning Groovy yet, but I do realise it would probably be much easier to write a driver and/or an app. Learing Groovy is on the to do list. Any tips on good starting points for learning Groovy?
In all seriousness, I started by doing just that. You obviously understand logic flow. From there it's just figuring out how to lay the functions out. I started by looking at someone else's code for an app (they left Hubitat but left the code accessible in GitHub) that was a similar function to what I was trying to do. I used that as a template to get started, cherry picking the functions I was looking for and ditching the rest. From there, I would rinse an repeat by looking at how other devs did certain things. Like, I wanted to write a file to the hub. Thebearmay has an app that does just that so I reverse engineered what he was doing to fit my needs. I had another function where I wanted to dynamically populate a child list based on whether or not the code for a given child was installed. Found someone else that had written up a web scrape function that I modified to fit my needs.
Nowadays, I usually just turn to ChatGPT or the HE docs for figuring out how to do new stuff. I feed it my current code and tell it what I want to do (make sure you specify that it's for a Hubitat app). It'll spit out some code with an explanation of how it works.
The developer docs are an awesome resource to get going.
Robert has a page in there that walks through building a simple app that's a solid intro. The gap to some of the stuff in there, for a non-dev (me) at least is that there are some common functions laid out with no explanation on how to actually implement it. For me, I can brute force my way through most things, but it really helps having an example to go off of.
I had no idea what the bytes argument meant. I did a search of the function "uploadFile" in the forums and figured out I need to use getBytes() against my data to create the file.
Thanks for taking the time to give such valid advise @FriedCheese2006 ! I will use your advise as a starting point. I haven't used Chat GPT yet either, but I am keen to try. Can it really produce code with explanations?!
Of course, it does lack the experience that asking a real dev brings to the table. A conversation with a person would probably include something like "this is when you would want to use XX function".
Feel free to tell me what things like this are, and I'll consider whether they are a good fit for the docs. (I don't plan to turn the whole thing into a Groovy tutorial, but I don't mind laying down the basics — and did, I think — and certainly do intend to explain anything Hubitat-specific.)
Yeah, totally did not mean that as a knock on you. The only two I can think of is the file management stuff and the functions for variable removal/rename; the part about needing accompanying functions inside the app to handle updates. I realize the actual functions will be app dependent, but just knowing that they're needed.
Didn't take it as a knock at all! Just wanted to know what could be more helpful from a perspective that isn't mine (since it's hard to see things that way myself).
The hub variable rename function is actually documented with the Hub Variable API: Hub Variable API | Hubitat Documentation (might make sense to put this in the regular app docs too, though aside from the Missing Method Exception you'll get — and I don't even know that for sure, as it's possible the platform is smart enough to only call this exactly on the apps registered — it's really only needed if you do use them, i.e., would be using this API in the first place...)
File Manager methods are documented in the Common Methods documentation as well as the File Manager API notes, though how to use them does assume sufficient knowledge of how to use the byte arrays they work with (possibly something that could use an example at some point).
Being locked out of Rule Machine tends to happen to me on my (much) more complex rules -- usually as long or longer than the one you posted above, and involving lots of Local Variables, IF-THEN blocks and/or Managed Conditions.
Even after two years using RM, I haven't pinned the problem down to a specific set of steps in order to replicate the issue. What I have learned is that it's most often necessary to rebuild the rule from scratch, rather than try to "save" it. Cloning usually results in another unopenable copy of the rule.
To hedge my bets, I now make it a habit to Clone large rules early and often (and simply Disable the copies). By "large" I mean having a size (Logs > App Stats > State Size) in the realm of 17,000 or greater, which in my case correlates with a rule containing 80+ Actions, 4 nested IF-THEN levels, 27 Conditions, and 16 local vars!
Wish I had any more solid advice than that. KEEP IT SIMPLE WHEN YOU CAN!
I should be able to track this down and get it fixed. If you would be so kind as to Export any rule that does this and send me the json file I can do that. See PM.
I try to create RM's that can be called by a Main RM - sort of like a function or sub-routine. It then makes it easy to redo just the sub-routine if necessary. My longes rule is probably 15 to 20 lines long. It does mean more rules, but sometimes they can be used in more than one Main RM.
Thanks for your reply and for your suggestion. Yes, I have thought about doing that as well but as my programming days are well over 20 years back, I haven't really found the currage to try that yet. Do you use the technique on a rule by rule basis when a rule gets too big to keep them smalish or have you aimed a for sort of 'master script' in which you incorporate as many calls as you can or? Have you encountered any caveats to avoid suing this way of building your rules?
The only downside is that it is hard to remember what Main Rules are using a sub-routine. You have to open any rules that may be using it to verify. The reason I started doing this is because the previous versions of Rule Machine were much harder to edit rules, so having them smaller made it easier to just recreate them if I screwed them up to much. I actually used to use this method more than I do now.
I tend to do both of your methods you listed - rules getting too big and complicated, or routines that I can use in more than one place.
.
Thanks 
(I don't plan to turn the whole thing into a Groovy tutorial, but I don't mind laying down the basics — and did, I think — and certainly do intend to explain anything Hubitat-specific.)
