Wow, that's surprising. Is a rue engine not something processing instructions line by line ? If so, how much processing power it uses to ignore instruction lines beginning with "//" and how could this hinder the operation ?
1 Like
Sure, but Rule Machine checking to see whether an action is commented out and skipping it if so (or however this would be implemented) would also take some processing. Unless you are going crazy with logging (or "dummy notifications" like this or whatever), there should be no real-world impact.
That's more or less the explanation we've been given for some things in the past: their priorities generally focus on this the majority of users will notice, like device support, "regular" apps, or whatnot. Rule Machine is an advanced tool that is likely only used by a subset of users. We've also been surprised by the introduction of things they've said "no" to in the past. But none of us can control that, hence my suggestion for alternative solutions you may wish to explore.
Like Groovy? which you can also use to write automations on Hubitat? 
I'll suggest that again as something that may appeal to you more.
1 Like
Ok, I see I'm running again walls. Yes, I could use Groovy but it will have a steep learning curve. While I am actually a programmer and I have software (freeware) online, I don't use Java but a completely different language. If the politics of Hubitat are that people mainly do very simple automations and that programmers should use Groovy, then the rule machine makes no sense. The rule machine has also a learning curve, but a small one and that's why it is interesting as well for beginners as for programmers used to other langages. The fact that inline comments makes it easier to come back on a rule after weeks or checking for errors stays still valid. I think that I clearly showed my position, that is shared by others who requested such a feature, and if there is a wall I will not try to demolish it by force.
B.T.W. I also developed an app that permitted to add features by a scripting language and comments were also possible in the scripts.
Oh? You know how RM is coded so well that you know this is a trivial change that would be easy for them to do? Interesting.
That was obviously sarcasm, because you have no idea how easy/hard it would be to do.
You've made your feature request - nothing wrong with that. And it is a good, perfectly reasonable, request (I know I would use the ability if it were there). But unless Hubitat says why they won't add it, maybe hold back on assumptions of motive.
2 Likes
OK, this is a ridiculous and just wrong statement. We listen to our users all of the time, and frequently implement feature requests, sometimes within a matter of an hour.
Not everything that users ask for, just because they think it's a good thing to ask for, are in fact good ideas that we should leap to implement. At the moment there is a major rework of certain key RM structures going on for the next release. RM users are going to benefit directly from these as rules are going to be considerably more efficient. Honestly, adding comments would not rise to the top of the list of things that should get done right now, and would actually make rules less efficient. I'm sorry that you think that means we aren't "hearing our users".
6 Likes
Ok, I will bite.
What types of things do you think need commenting? Maybe give some examples of what and where you would propose to do this, maybe with a screenshot and MS paint or something.
And if RM is so confusing, why not use a simpler app? There are a variety of ones that may do what you are trying to accomplish, and apparently cannot?
Oh, no. Next we will be seeing GOTOs. 
5 Likes
Wait, that's a great idea! I could put line numbers on each action. Then GOTO n jumps to that action. Heck, why not just make it have embedded BASIC?
7 Likes
I also would like a comment function and recall rasing or supporting it a while back. It would be helpful to annotate complex rules in-situ. The suggestion to use Groovy instead is absolute nonsense.
1 Like
Hey, if that is so then it's great. You may then have to change your communication. There may be tons of reasons why comments are not at the top of your to do list, and I understand it. Just reply that you will consider this later and that you have actually other priorities, but I repeat it, a simple "NO" with a non valuable argument that rules are not programming gives users the impression that they are simply ignored.
I really appreciated your help on my other posts and I'm thankfully for it, but now you seem to take it personal and to mock me (and all the others with the same request) with dump comments about line numbering like basic. Please take a step back and stay professional. My intention was never to attack you or to hurt someone. I will not continue this discussion on this base. We can talk again in a polish and respectful way. I really appreciate your hub and it has the potential to become my absolute favorite. Critics may be considered as a positive thing and may contribute to getting better over the time. I understand that my opinion might not be representative and sometimes it may be a wrong good idea. But here I'm not alone with my opinion and I see a true advantage.
There are tons of problems with the Eurotronics Spirit implementation. Temperature not reported correctly in the dashboard, not always reacting on the first command, template (thermostat) not adopted for such a device, and so on. They work flawless in the eedomus system, so it depends on your implementation and I prefer that you fix this before looking at comments, just to tell you that I understand priorities. Can you fix it in an hour ? 
OK, let's stay on facts. From a programmers perspective they are already there. Everyone says that rules are not programming, but they have a similar syntax and the are hearing on events and they act like object oriented so ...
In a modern object oriented language the main coding difference is that the code is not a long list of code but broken down in blocks with names called methods. So calling one method from within another is a modern GOTO. Running one rule from inside another is de facto a GOTO.
Ok, I will bite back
I just use rule machine for complex logic BECAUSE simpler apps don't do it. As programmer, I like the power of rule machine. A while loop like this one (just some lines of a complex rule) is for me confusing:
In some weeks I don't remember that this is in fact a "while" loop, and I don't remember how I have done it. Second the need for a loop is a workaround for a device not always reacting on the first command.
The ability to add comments here like:
// This is the Rule Machine way to create a while loop
// Conditional actions -> Simple Conditional actions -> Repeat as action
// This loop is required to work around a problem with the Spirit device not always reacting on a command. Has to be reevaluated later (if fixed)
may be very useful once the rule takes 40 lines or more.
Just another note: Isn't something that starts with a condition (IF) and ends with a END-REP, instead of an END-IF confusing ?
The logic is to start with a loop, then install a looping condition and then to end the loop:
while (NOT Thermostat mode of Act_Heating_Living_Back heat)
..Thermostats: Act_Heating_Living_Back --> Mode: heat
..Delay: 10s
end while
1 Like
Where in my post do you see an assumption of the motive ? I only say that a company that is hearing on users, and I'm not alone to request this, (apparently they are in most cases) should not say NO with no valuable explication, and "rules are not programming" is no valuable reason.
I don't know how RM is coded but I code since more than 30 years and I coded many software, freeware, shareware, on demand coding for large companies and I know how code works. The rule engine is "probably" interpreting rules and a line beginning with "//" should simply not be treated after that. In the best case the conditions are evaluated before they are translated for the core service and ignoring comments at this level is really easy. If that is difficult to do, then it might really be badly coded. But maybe a coder of RM can convince me from the opposite...
I'm not going to argue with you.. I quoted the exact text where you ASSUMED that they weren't listening to users.
Have a good day.
3 Likes
As someone who still frequents the GOTO side of town, I'll just note that both of those examples are actually GOSUBs.
As someone who also heavily comments his code, I certainly wouldn't mind that ability here, if it can be done without significant performance penalty. Until then, I've been making do with "Notes" and, when necessary, off-device text files.
3 Likes
Sorry, no. GOSUB statements are still used in a long list of code and not between different methods. They are GOTO statements that do not refer to a line of code but a named block of code.
Like this:
PRINT "CHOOSE A MENU (1 OR 2)" :
...
ON MENU GOSUB MENU1, MENU2
...
MENU1: * CONTROL TRANSFERS HERE IF MENU 1 IS CHOSEN
..
RETURN
MENU2: * CONTROL TRANSFERS HERE IF MENU 2 IS CHOSEN
....
RETURN
I called it a modern GOTO as pendant to what it is today. In a real object oriented language it is a message. One method sends a message with arguments if needed to another method and this method decides what to do with the message. One objects method can't directly do changes or calls in another object (even if some so called languages do allow it).
It doesn't, really: the repeat starts with a "Repeat" and ends with an "END-REP," just like regular repeat syntax in Rule Machine. The "IF" is just part of a "Simple conditional action." What you're seeing is just a result of the fact that simple conditions appear on the same line as the action they are "attached" to. (It is a little odd that a simple conditional on a "Repeat" action acts as a check for the entire thing...but it makes things easy and is just something you have to learn, I suppose.)
Instead of this:
IF (Condition X) Repeat every Y
Do Z
END-REP
you could write this:
IF (Condition X) THEN
Repeat every Y (stoppable)
Do Z
END-REP
ELSE
Stop repeating actions
END-IF
...and they are exactly equivalent.
It's not "interpreting" things in the sense of looking at the pseudo-code you see on the screen. All Hubitat apps (of this kind, so ignoring things like service managers) work by asking the user to fill out inputs that get saved to an internal settings map (as in the data structure) for that app. In the case of RM, the inputs are things like devices and what type of action you want to run. Both what RM does and what it displays are the result of an undoubtedly complex set of app code that looks at the settings and devices what to do--but one of the reasons you'll see people say that RM rules aren't "code" is because they're not really. I will concede that what it displays looks a bit like that, and that you might consider it "programming" because it requires you to think like one--can't escape the fact that you need to know how things work, no matter how you do it. 
Given your comments, I don't think that the entry barrier to Groovy will be that high for you. I know it's not for everyone, but I think you might like it better in the long run given those same comments. Maybe come back to that possibility some day if you don't want to right now. I know lots of people would be willing to help you get started!
2 Likes
If that works, then it is even more confusing for me. My interpretation is that this will hang forever in the:
Repeat every Y (stoppable)
Do Z
END-REP
This is nice loop with no with condition in it to exit it and it should loop forever. If the surrounding condition makes this work it seems to be completely illogic.
Your explication of how RM is internally working is in line with my estimate (not knowing it) when I talk of "In the best case the conditions are evaluated before they are translated for the core service". So it should not be as complex to implement it, but I agree that it may take time and resources that are actually better invested in other implementations.
You're right; this really depends on what your trigger is. I was assuming a trigger like "X *changed*", which would often be the case with a rule written like this. The first (simple condition) variant is not as picky about the trigger since it does the check before starting (or re-starting) the repeat. But what I wrote above will work if the rule is written correctly--it should (re)trigger, run the ELSE actions, and stop the repeat.
And both go to show why I always ask people to share the entire rule, including triggers... 
