I have the following rule:
But the temperature triggers don't seem to happen. The rule only runs if the thermostat state changes (but also weird, has a 50s hold off). Here's a sample of the logging:
Could the temp triggers be happening and the log output be incorrect or is there something else wrong?
Help!
Or is it because the trigger will only check when the set point changes and not the temperature?
If so, is there a way to make a trigger that fires depending on how far the current temperature is from the set point?
I'd trust the log output, but your triggers look messy. Wouldn't the first trigger be included with the second? That being said, there is no "stays" (sticky trigger) on the last trigger, so it should run the actions immediately. Something may be wrong. You should get a trigger any time a matching event happens (assuming you aren't using the "required expression" feature), with the exception of the triggers where you used "stays" and it will wait for the resulting condition to remain true for that long before triggering.
Thanks for the reply - I would love them to be cleaner but I'm a Hubitat newbie. This is about the 5th try. Some of the earlier attempts would have no log output at all other than 'Initialized'.
Regardless, any ideas on why the log is reporting that the operating state trigger is waiting for 50s? There is no stays option when you select the *changed* condition.
Is there a way to view/edit the rule in code/json rather than the UI?
If you only want the trigger when you cross a specific threshold, you might need different rules (you can create a separate, trigger-less rule and just run those from the other rules if that helps). Right now, you won't get a trigger when the reading crosses the threshold but rather any time it matches the trigger event. So if you say trigger on < 50 and get readings of 49 and 48 back to back, both will trigger the rule. You can combat this using a required expression of >= 50 and a trigger of < 50, or similar for other values. This takes advantage of one use of required expressions, capturing a specific state transition. I know this is mentioned in the docs, but it's pretty much imposible to mention every possible use for every feature since there are infinite ways you can combine them to get whatever outcome you want. This is not even the only way to do this, just one I happen to think is easiest. (For a slightly different approach, you could also just restrict the rule from triggering again before you reach the last action, retriggerinng within a specific time frame, or nearly anything else you can think of--just need the right tools to make that happen.)
I don't have any ideas on why that last trigger isn't working as expected, but it does look wrong. Removing and recreating that trigger may help, or even just hitting "Done" to re-initialize the rule's event subscriptions (be sure to do tho after you modify triggers; be aware it will also cancel any pending rule timers or waits).
I have found I usually have to "stop" a rule, edit it, and then hit the "Update Rule" for the changes to really take effect. It may be me, not sure. This is what I do each time I edit my rules.
Changes to triggers require a "Done" or "Update Rule" in order to take effect. (These are the same aside from the fact that the latter keeps you in the rule instead of closing it and returning you to the Apps list.) Either of these will also cancel any "timed" actions or temporary event subscriptions, like delays, repeats, and waits. In effect, either sort of re-initializes most aspects of the rule.
Changes to actions take effect as soon as the edit is complete. If you make significant changes and the rule actions are currently "running" or waiting on something, you may still wish to do one of the above to start over--or not, if it's important that your actions run to completion (e.g., resetting Private Boolean to true where you're also using that as part of an expression earlier on).
Pausing or stopping shouldn't be necessary, but it can't hurt if you want to!
Also, forgot to answer this before: but, no, the UI is the method by which rules are created. However, you can write custom apps for the hub (which would be code); the language for that is Groovy. Rule Machine exists so you don't have to just to create arbitrarily complex automations. There is also a community project, webCoRE, which is a sort of alternative rule engine that you may also want to look into--also not code, but an editor that exists outside Hubitat, also does pseudo-code, and that some people find a bit nicer due to not being subject to the hub UI constraints.
I've got a couple suggestions. When I first started, HE staff member Bruce was helping me fix a rule that I had made too complicated. His suggestion was that it was sometimes better to have several simple rules rather than one complicated rule. That advice may apply here. If different triggers are meant to have different actions, they should probably be separate rules.
Yes, the way I am reading it, these triggers will only initiate the rule when the setpoint changes, not the measured temperature of the tank.
The better question is, did it work when you were using that as the trigger? If yes, then there are ways to measure how much overhead the rule is causing and if it needs to be modified to trigger less often. These triggers do seem to be overly complicated.
Yes, there are many ways to accomplish the same goal. I usually write mine down on paper and try to think through all of the "what-ifs" before I ever open Rule Machine. Sometimes I'll start with a couple simple actions and then build up from there. It can be really hard to troubleshoot if your first trial run has nested IF statements, required expressions, and multiple triggers each requiring different outcomes.
The answer from HE staff is "No." You can export the rule into a JSON file, but the output is not likely something that would be useful to anyone. One of mine, for example, exports to a single line of over 65,000 characters.
I would go back to that version and see how it works. Its fairly common to evaluate triggers every time a sensor value changes. I wouldn't worry about bogging down the hub at this point.
I might also "clean up" some of your conditional statements. For example, you have a couple instances with a single simple conditional nested under an ELSE-IF. You could combine these as follows:
ELSE-IF (Cool setpoint of Pump Control is < Pump Control -14.0 AND Operating State of Pump Control idle THEN
Off: Pellet Boiler
This may also be a good candidate for a WHILE loop. Those can be a bit of a challenge for your first one, but they are powerful and can help simplify a rule.
Many thanks for the info and tips - will go away and re-think things!
Ok, still trying to get this thing happy. I've ended up storing the limits that I use to compare with the tank temperature in Hub Variables and that works quite well and breaking the rule up into several. Here's two of them.
The thing I'm struggling with the most is how best to implement "de-bounce" behaviour. That is, "If <condition> is true for <x> minutes then do <action>. But if it becomes false during the wait and then true, start the timer again. It would seem like the 'and stays' function would implement this but that only works with one value, not an expression. And then the delayed actions seem like it might do it but multiple triggers (like temperature reports) seems to mess things up.
In the screenshots here, is it possible to have the action run as soon as the Required Expression becomes true? In the 'Boiler Stop' rule, if the tank temp increases over 48 and the 'Pump Control' Operating State is already 'idle', I'd like the Boiler to turn off but as it is, it will only happen when the operating state changes...
If I had a 'and stays' style trigger and the Required Expression became true (while the trigger condition is true), would the trigger fire after the 'and stays' delay?
What does the 'Cancel Delayed Actions' action actually do? I had a rule where multiple triggers occurred during the 'delayed' period and produced many actions waiting for a delay to finish. Does 'Cancel Delayed Actions' cancel them all?
Any more wisdom much appreciated! 
I'm still trying to get this right. Either I totally missed it or it appeared in the meantime but I found the doc on Rule 5.1 and discovered the 'Wait for Expression' action with a hold-off duration. (which I'd love as a trigger). So, I tried the following and quickly discovered it will wait forever if false and any new temperature reports will result in a new instance that will also wait forever...
So, I then pivoted to this which will hopefully only trigger once per on/off cycle.
On reflection, what's really missing are edge-triggered triggers for continuously reporting sensors. Having a trigger fire every time a z-wave device decides to report a value has little meaning (other than for graphing and reporting), but what's much more interesting is when a sensor's value reaches a specified range/value - that's when you want a rule to run (and clearly an assumption I made of how it was working when I started this thing - I think the word 'trigger' implies it will happen when the trigger becomes true... but there is also the word 'reports' in there...). [ooh, and being able to use a thermostat set-point as a temperature for comparisons]
I might document this more if I finally get a solution that works.
For anyone interested, here's my final set of rules that seem to be working as expected. I have a virtual switch device that controls the process.
The only problem I can see is that the Boiler start/stop can get missed if there's some sort of interruption, but it's been working as intended for a week or so now. And, I'm also fighting the thermostat state not reporting when it reaches its set-point.
For some of my varibles I have changed them over to virtual devices. An example in this solution, instead of the variable "HeatingTime" Connector Contact. I would go to Devices and make a virutual contact switch device called HeatingTime (or zHeatingTime if I do not want the device name in the middle of my list).
May not be the case for everyone, but I have found this to be more reliable with my rules.
As I learned (re-learned) this is where you are suppose to set a Private Boolean to avoid re-triggering the rule as described here:
Even still, from what I've experienced with a much simpler app than yours'... I'd be scared-to-death to trust fail-safe outcomes dealing with the systems you've built your rule for!
Download the Hubitat app
