I have created two virtual switches for now. On activates Home the other Away.
They toggle each other off when activated to prevent more than one switch being on at a given point.
Now my problem is getting them to Synchronize status with the House Modes plugin that is controlled via Vera Mobile UI7.
If a user activates Home on the phone or Away on the phone, I need the Virtual Switches to reflect those changes but there is a logic problem for me.
My meshbot can detect the change in house mode in UI7 Mobile and turn on the corresponding virtual switch.
That switch when activated this way, re-activates the same mode a second time and that is not really what I need to happen.
So “Home” mode for example is being triggered twice?
If you use the mobile app to change the system to “Home” mode (event 1) and then your Meshbot is also detecting that change and triggering again right ? (event 2)
I need to do the same setup you are trying to do on my own Ezlo hub. So I will give it a go probably next week though now.
Maybe an Ezlo support staff person will know the answer to your question?
Yes it does seem that the virtual switch would re-trigger the mode but may not matter. It is necessary to have virtual switch act accordingly showing “On” if changes are made in the Mobile Home modes.
The double activation may not have any real effect but its redundant so I posted it here.
I have used an XOR function in a meshbot in the past when I had two states that needed to be mirrored (one was an input and one an output).
I would trigger on XOR of the input and the state of the output. If they were different it would trigger, then in the actions I simply toggled the output state such that they would now be equal (effectively mirroring the input to the output).
In your case XOR home and your virtual switch and if different (ie triggered) then action is to toggle virtual switch.
I suggest a delay of say 5 seconds to start your action to avoid a race condition in the trigger logic. Then toggle the VSwitch.
To avoid triggering the switch twice a more structured logic will be needed. We will be working on setting up an alternative method to avoid such a situation - it might be helpful for other kinds of applications as well where triggering the same action twice would cause a different effect. I will post the logic here as soon as I can make sure it works accordingly.
I think I have avoided this problem by adding the delay at the start of my action. I had some instability due to what I perceived was a race condition (changing trigger elements on the action side of same meshbot).
I might have this wrong but it seemed to sort out my situation.
Input 2 proxy is an input and input 2 is an output (yes poor choice of words by me). The meshbot always changes the output to match the input (when the input changes state).
I found it was unstable until I added the delay. I assumed it was some sort of race condition in the Ezlo logic engine but I was never sure (because the action is changing the variable on the trigger side).
The reason for the XOR was because originally I had created two meshbots for either trigger scenario 0,1 or 1,0 but after thinking about it I could condense back to one rule with XOR.
