I would like to suggest to add a field called 'Global variable' in the Dashboard button creation form.
The purpose of this new field would be to store the name of a global variable which in turn would store the information entered into the 'Button Number' field. This would create a way for the dashboard to interact with RM rules and custom apps.
An example: I have an air-to-air heat pump. For the purpose of controlling this heat pump I have a rule in Rule Machine that controls the heat pump automatically based on a set of criteria. I also have a dashboard set up that enables me to use my phone as a remote controller of the heat pump in case I want to override the rule. The rule and the dashboard send the same commands to the heat pump. The rule stors the last sent commands in a set of variables. But the dashboard and the rule are not connected in any way. Thus, overriding the rule using the phone dashboard remote may result in the variables in the rule holding the wrong values. The dashboard and the rule become out of sync.
By adding the possibility to link a global variable to a button in Dashboard, the dashboard would be able to link with the rule. In this way the set of parameters in the rule would always show the correct values and thus eliminating the problem of being out of sync with the physical unit. These values could then for instance be displayed on a custom display on the wall next to the air-to-air heat pump.
A similar result could be achieved by using buttons of type variable with global variables. But, as far as I understand, using this method, the values, i.e. the button number message, needs to be entered every time with this solution. This is not ideal for instance, for the type of purpose I have described above.
Similarly, a way to solve the problem could, as far as I understand, be to use virtual buttons. But again, they would not have the same look and feel as the normal dashboard buttons of a remote controller.
An advantage of the solution suggested is that the variables would integrate seamlessly without the user knowing they are there. This is a good improvement for usability when non tech interested people use the solution.
Sorry but sounds like a design flaw in your process, not a change that needs to be made by Hubitat, and the HE Dashboard has a native interface for Hub Variables. If you have an outside process that can override a parameter that affects the way one of your rules processes, then the rule needs to be able to handle that situation.
Let’s start with your “dashboard”, is it a native HE dashboard or?? If native what type of tile template are you using, if not native how does it interact with HE?
It may likely come down to the thermostat driver, rather than the dashboard and rule design, but will keep an open mind.... I know that for my cloud-hosted Mitsubishi units there is a juggling act between manual control in HE, control via physical interfaces and any automated options.
Thanks @thebearmay , you may be absolutely right. I am using native HE dashboard. It is very simple with just buttons that do one thing. Each button has a command that it sends to the air-to-air heater via an RM2 PRO. But it works well, apart from not being connected with the RM rule.
Here is what parts of the remote looks like:
Thanks @sburke781. Well, the thermostate driver sort of does not exist. Or rather, the RM rule is the thermostate driver. The indoor climate of my house is affected by the outside weather, partly because it is painted black. Especially with regards to heating up in the summer. So the 'thermostate driver' (RM Rule) is based on combinations of average outside temperature, average inside temperature, the amount of sunlight and if it is raining or not. I am happy with it and it works reasonably well. It also gives me a reason to learn more about RM and Groovy, which is a good thing.
I am by far no expert on HE, Groovy or Rule Machine, which should be evident by now, but I am not aware of any other way to 'digitalize' the non digitalized air-to-air heater where the heater, the phone remote and the physical unit is in sync all of the time, making the original remote not needed. I still think that is an attractive outcome in principal. Any thoughts on how, in principal, to go about to do such a solution with current standard functionality?
Not knowing what the “driver” rule looks like, if you need to know that a button was pushed to override you could store that button push in a hub variable using the rule that creates the command from that push and then check the hub variable in the “driver” rule.
Hi @thebearmay , Thank you for assisting and for your advise. Yes, this sounds like about what I would like to do, but I am not sure I quite understand. You have to remember that I am a merry amateur in this field . When reading your sentence above I am with you all the way untill "using the rule that creates the command from that push" . That is a mind bending formulation The button that is pushed is just a standard tile in a dashboard, so I am not with you here which rule this should be? I only place the command to the RM2 Pro in the 'Button Number' field and that's it. It is because I miss what you are describing that I suggested this ER to connect the the button press with the global variable. Please elaborate!
When I have bit of time I often change this rule to tweak it in various directions. But here is the current 'production' version (which will be changed shortly).
This bit here is not part of the rule, it's just me fiddling with global varables to understand how they work, so please disregard that.
I want to offer a follow-up response to the latest posts, but I feel some of the initial requirements may have been lost... And I may be starting to talk like I am at work...
The best I can offer would be to think about and re-state the automated logic / situation you want to happen, plus the manual set of events you want to cater for, such as the pressing of a button.
In terms of your understanding of @thebearmay 's explanation... I would suggest setting up a virtual button device, a new RM rule or Button Controller App triggered by the pressing of a specific button number, e.g. button 1, triggering an action to toggle a virtual switch (for example). You can then include a Hub Variable into this mix, adding the setting of the Hub Variable to a particular value when the specific button number is pressed. You could change it manually or introduce another button number into the mix to alter the Hub Variable value if you want.
There's a couple more steps involved in spelling out this example to explain the concepts involed... but I expect it is worth stopping here to gauge your involvement and interest in pursuing this further...
Hi @sburke781 and @thebearmay ,
Thank you for taking the time to think about the challenge I put forward. I learn so much from dialogues with guys like you. And thank you for your patients. It is really apreciated.
I think you solved the problem here. As I understand the situation the solution is to create one virtual button for each command (to get the right name on each button tile) and assign that virtual button to a button tile in the Dashboard.
As the virtual button is available to RM I can do a rule there which sets the global variable and sends a command to the heater. The global variable can then be picked up by the thermostat rule.
I did an initial test now with on button to turn the heater on and another to turn the heater off. They have one rule each and share a global variable which in fact is updated using the buttons. So problem solved I guess
I will test more with the thermostat rule tomorrow but again, it seems to work.
Many thanks!
PS. @thebearmay s suggestion and explanation is off course excellent. I was a bit tired and all reasons that i did not get it at first is of course only my own.
Sorry but sounds like a design flaw in your process, not a change that needs to be made by Hubitat, and the HE Dashboard has a native interface for Hub Variables. If you have an outside process that can override a parameter that affects the way one of your rules processes, then the rule needs to be able to handle that situation.
. When reading your sentence above I am with you all the way untill "using the rule that creates the command from that push" . That is a mind bending formulation 
The button that is pushed is just a standard tile in a dashboard, so I am not with you here which rule this should be? I only place the command to the RM2 Pro in the 'Button Number' field and that's it. It is because I miss what you are describing that I suggested this ER to connect the the button press with the global variable. Please elaborate!
