New App Features in 2.2.8

I almost always use the conditional while for this reason, I find it works better. I just have a LV that I set in the rule with the conditions, then at the end I use the simple condition with the Boolean and repeat action to do what I want.

1 Like

Any more?

Global Variables, as a part of Rule Machine Legacy could be used as triggers, as the parent app did all of the work (hence Global Variables could be slow).

Hub Variables do not generate events. We didn't think we should create an entirely new event infrastructure just for Hub Variables, especially when Connectors exist and do generate events. When a Hub Variable (with Connector) changes state, it calls the Connector parse method, and that causes the appropriate event to be thrown. These events can be used like any other events in the system, i.e., in this case, as triggers.

We will continue to evaluate whether or not Hub Variables should generate events, and if so how that should be accomplished. But, Hub Variables are a brand new feature of the hub, and we are taking it slow in this regard.

2 Likes

Sorry I meant as in HV are a replacement for GV and you could do it with GV.

Thanks for the explanation :slightly_smiling_face:

:muscle::ok_hand:

2 Likes

@bravenel I'm not sure if it is just me, but when I have time announced via TTS in a rule it no longer says AM or PM. It changed with 2.2.8. I'm using %time%.

When you use %time% you can pick the time format. This shows up on the Action page after you've created an action with %time% in it. The default omits AM/PM, but that can be selected,

2 Likes

4 posts were split to a new topic: Errors on Aeotec Siren 6 with 2.2.8.151

I'm having a problem with HV connectors in hub mesh. I've reproduced the error with multiple HV connectors and multiple hubs. Here's my process.

  • Create boolean HV and its connector switch cousin on hub 1
  • Add the connector in the hub mesh
  • Go to hub 2, and link to the remote HV on hub 1
  • Enjoy automation goodness

Except the connector switch on hub 2 is showing OFFLINE. On hub 1, the HV and its connector look and operate normally AFAIK. No other devices in the same mesh are showing OFFLINE. Are we not allowed to use HV connectors in hub mesh?

Did you share the parent device for the Connectors? That would have to be there as well.

I could not reproduce it, changing connector value either in Hub Variables or in the connector switch device would also change value on a linked device for me.

Which hub is the connector on and which hub doesn't pick up the value change? Hub names are ok, I can look them up.

Yes.

Actually, my description above was wrong. I didn't add the connector switch to the hub mesh (I don't think that's even possible, is it?)--I added the "Variable Connectors" parent device to the mesh. My understanding is that, just like GV Connectors, you add the parent holistically, not individual connectors.

My problem isn't with value change -- it's about the fact that the remote connector shows up as OFFLINE, even though other devices are fine. See "HE Upstairs Ground-SW" for remote hub and "Server" for hub where HV's are.

When I did it it showed the same issue, clicked sync all a few times at it seemed to take ( I also tried clicking other stuff but can't remember)

It was strange one time I looked it was OK, then went back to use it and it was off line then back it did it a few times

Are there other linked devices from the same hub and if yes, do they show up as offline? Is "Upstairs Ground-SW" hub reporting "Server" hub as visible on Hub Mesh page?

I suspect this is an issue of how hub mesh does discovery and maintains the list of active nodes afterwards as opposed to anything specific to remote connectors. My theory could be wrong, but it also is pretty easy to make hub mesh send more discovery requests and wait for replies longer.

This is exactly my experience too. The device seems to rotate between OFFLINE and normal, and back again periodically. Can't find a pattern. Even when it's offline, the hubmeshdisabled state shows as FALSE, per the device details page. Also, I'm seeing repeated situations where, on the main device listing view, the device does not show as OFFLINE, then you click on the device to access the individual device details view, and it says DEVICE IS DISABLED in red text. Makes me wonder.

No, that's what I mentioned in the original post. It's what makes me suspicious of some other problem I'm not understanding.

Yes.

Is this something you want me to try somehow. Not sure what you're suggesting, but I'm game for anything! :slight_smile:

Edit: @gopher.ny, one other bit of insight that will hopefully be helpful to problem solving....from the device listing page, I see this:
Screen Shot 2021-08-03 at 5.28.46 PM

If I simply reload the page, I get this:
Screen Shot 2021-08-03 at 5.28.57 PM

Every time I reload the page, it cycles back and forth between those two states. Odd.

As a predicate, the day is tested at midnight. If I were to edit the rule at 9am to change one of the predicate days to today, does this mean I am too late for anything in the rule to run today, or will it re-evaluate the predicate when I save the changes?

It is re-evaluated when you hit Done (or Update Rule).

4 Likes

In the earlier discussion here about Predicate Conditions not allowing Local Variables, @bravenel suggested this wasn't a useful combination (so was disallowed) because only the rule could change the local variable, and the rule is already running.

However, there can be multiple instances of a rule running concurrently, and its common in Rule-4.X to use a local variable to help protect against these colliding (IF local-var=true EXIT-RULE as the first statement) . Since RM doesn't appear to have a nice mechanism to stop multiple instances of a rule, using a Predicate Condition with the same local variable seems natural in Rule 5.0, but that is not allowed.

@bravenel what is your recommendation in Rule 5.0 to protect against multiple instances of the same rule executing at the same time ? Thanks!

Are you already using Private Boolean for anything? Because if not, that is an easy option, and it is available for predicate conditions (other rules can modify its value, so it's not 100% private/local). Otherwise, the general suggestion for the situation you describe is to use a variable connector, which is a device and thus generates events on value changes--which variables, even global variables, do not (at least in their current implementation, and possibly never).

For your very specific question, however, I'm not Bruce and would be curious what his recommendation is, but my recommendation would be to carefully consider your triggers so this is unlikely to happen (fewer triggers/devices are generally better; targeted triggers like "motion active" are generally better than "motion changed"); carefully weigh the actions you use (e.g., waits vs. delays; waits are automatically cancelled on retrigger and can often be used to your advantage in this regard, and the fact that waits can dynamically create subscriptions ties nicely in with the suggestion to use targeted triggers--you can still do something on "motion inactive" this way in my example before); or to try to address things at the device/driver level if the problem you're really trying to work around a problem there (e.g., a contact sensor that sends duplicate events in quick succession).

2 Likes

@bertabcd1234 Thanks for the reply. I'll try private-boolean again with predicate conditions.

1 Like