Best way to pass variables from one rule to anotherā€¦?

šŸ“ Rule MachineĀ®
1

Iā€™m trying to pass several numerical values from one rule to another in RM 5.1.1. I use to do this with connector variables in Legacy, and know that I can use Hub Variables, but I wonder if there is a better way to do this without needing to create multiple hub variablesā€¦

2

The only thing I could think of besides a Hub variable would be using an virtual omni sensor and you could pass values back and forth using the Humidity, illuminance, and temperature. Not sure that's really better or easier than a hub variable.

Interested if anyone has something else.

1 Like
3

Hub variables are probably the easiest but should be able to pass via http endpoint parameters also I would think.

2 Likes
4

Well, while I agree with @thebearmay, you could also do it with Hub Variables, but a slightly different way: use one Hub Variable as a Command Channel, and another Hub Variable as the Data Channel. Put data in the Data variable, then distinguish the type, or whatever, into the Command variable (Temp, DeviceNameNewValue, whatever). Then, when the receiver consumes the value, it could put Ack into the Command variable. This solves the problem of detecting that repeated values are being sent, and synchronizes the sender and receiver.

But the endpoint messaging suggested by @thebearmay might, in the end, be just as simple because each message would arrive as a separate event. However, I suspect that Hub Variables would be faster.

1 Like
5

I used to do the virtual omni thing to store string variables for access across multiple hubs, but I've been using the Generic Attribute Storage Driver by @sburke781 for some time now. Easy enough to store four different kinds of variable (date, float, integer, string) and Hub Mesh 'em around.

3 Likes
6

Thanks all!

Good idea!

Not sure what that means - Might require some research on my part.

Very interesting! More complex than anything I have done up to now, but might be worth a look!

Thanks! Iā€™ll probably start with that option.

1 Like
7

Explained a bit differently, what this implements is a shared memory messaging system. The Hub Variables, when you think about it, are memory shared between Rules. Very fast. And, I understand that it will soon work over Hub Mesh (but @thebearmay has a workaround driver to share variables over Hub Mesh until Hub Variables work natively across Hub Mesh).

The reason there is a need for a Command channel (variable) is so the data emitter (sender) can signal that a new value has been put into the Data channel (variable). The data consumer (receiver) needs to communicate back (Ack) that the data has been received, and that new data can be sent without overwriting the prior data.

The receiver can trigger (or Wait for Event) on the command channel (variable) not being = to Ack, which it knows it put there. The sender can trigger (or wait for event) on the command channel being = Ack, which means data has been consumed.

And sender and receiver can just loop along on a Repeat.

1 Like
8

I am expecting Hub Variables will surpass this, they do in many respects already, but glad to see people are still getting a use out of the driver. This has made me realise I have forgotten to get back to a request for more Strings....

1 Like
9

Some variation from this is what I was talking about:

The method that @672southmain was referring to, to share Hub Variables across hubs is:

1 Like