Update Virtual Device State Without Re-Sending State?

[NateR]

Hello all,

Is there any way to update a virtual device's state in Homeseer without having it immediately re-send its state out of the Homeseer nodes when it gets changed?

Example flow:


I've made an arduino-compatible device that checks the state of my computer, and can turn it on/off based using the pins for the power button.

I would like to be able to ask Google Assistant whether my computer is on or off, then be able to tell it if I want to turn it off/on.

Problem: When a message comes in from MQTT (lower of the above two flows) and updates the state of the "Computer" virtual device, it will also then send the new state from the Homeseer node in the upper flow, which would then toggle the real-life computer off/on.

Is there any way to prevent this from happening? I've come up with kind of an annoying workaround, which would involve asking Google Assistant "is my Computer Status on?" then telling it "Turn my Computer off" (i.e. using different keywords for status vs. control). I would really like to avoid duplicating these objects and having to remember to append the word "status" when checking the status of it vs. changing its state, so am asking here if there is another way to do it.

Thank you

[ksum]

Are you using two flows with different triggers to toggle the real life computer on/off? If yes, could you reduce that to just one? MQTT could set the HomeSeer device and that could toggle the computer.

[NateR]

Are you using two flows with different triggers to toggle the real life computer on/off? If yes, could you reduce that to just one? MQTT could set the HomeSeer device and that could toggle the computer.

I'm not sure that I understand what you mean. The flow for toggling the real life computer is one flow (the top one). The other flow is for updating the state of the virtual device, to update it when the computer state changes by any means other than Homeseer (such as when I shut it down).

As it stands, when the device senses a state change and sends the update to the virtual device (such as if I shut down the computer), the state changes. When the state changes, it sends a message out of the virtual node in the top flow to press the power button on the computer, which would turn it back on.

[ksum]

Since the image of the flow does not show many nodes it is difficult to know what is happening. Images of there flows only show a picture of things involved and do not fully convey the logic inside, so they are only partially helpful. Regardless, here area few things to consider based on what I believe you are doing:

Based on the image alone. you need to have these flows communicate to each other. I would look at the Gate node from the node-red-contrib-simple-gate. You would have a Gate node after the HomeSeer device triggering the On/Off toggle and you would use the other flow to close the gate for a set period of time. An RBE node might be able to be made to work if you remove the lower HomeSeer node and wire the MQTT pcpower/status node into the upper HomeSeer node. I see no reason why this wiring cannot be done and the RBE node is included with Node Red.

[dev120v]

I am still learning node red, but I've got an idea if I mostly understand the issue.

you basically dont want to send anything from a to b and c to d if it is already in that state. so check the current state of the virtual button and the state of the physical power before sending the calls over

I am guessing you can't call the microcontroller to get current state? I think this is the main issue because you are using it as a toggle

this solution uses a temp value to store the microcontroller state. might get issues if hs4 server is off and pc is already on. You would need to set microcontroller state on hs4/nodered/mqtt broker server boot, otherwise first time it is set youll get this issue once. Do a pc IP ping on nodered boot, set temp state value then?

part1 (bottom part update)

(may not be needed)
for the bottom part instead of updating the hs4 device right away, put in logic to check the devices current status. you can do this with node red logic or instead call 2 events based on hs4 device status and mqtt on/off state. in the events, only update state if needed. or do this with all node red logic.

**(required)**
also in the node red flow store the current state of the micro controller from the mqtt data in a temporary value in the flow, like this...

To retrieve values stored in the flow object use:
var powerstate=flow.get('powerstate') || 0;
and to store values use:
flow.set('powerstate',powerstate);

part2 (top part update)
now that you have the microcontroller powerstate as a temp variable, do basically the same concept, check current state before sending

in the top part, in node red, after the hs4 status update put in logic to only send to the microcontroller if needed, based on the powerstate value and the hs4 status. if powerstate hasnt been set, assume off

[ksum]

Here is how the Simple Gate contrib would be used to solve this. You must first install the simple gate contrib. The Gate node is a gate like on a fence, or a water valve. When it is Open, anything passed to it will go through. When it is closed, it stops the flow. To Open or Close the gate we send it a msg.payload of Open or Close and a msg.topic of Control

In the image below I have added a Gate node after the top HomeSeer node. When we receive the MQTT command, we do 3 things for the bottom half:

1. Go to a Change node which sends a command to the Gate node to Close the gate.
2. Go to a Delay node to wait 5 seconds before proceeding to a Change node which then sends a command to the Gate node to Open the gate. The delay can be changed as needed.
3. Go to the HomeSeer device to update the status. It would also go to the other items where it goes off image in the OP's image

Provided the HomeSeer device at the top of the image reports the status change before 5 seconds are up, it will not go past the gate.

Nodes to Import

Import the below nodes to your flow and connect them as shown. The nodes being imported are the Gate, Delay, and 2 Change nodes. Provided you first installed the Simple Gate contrib these should come in without issue.

[{"id":"d14b0189.2c2c5","type":"gate","z":"150262f9.9e6d7d","name":"","controlTopic":"control","defaultState":"open","openCmd":"open","closeCmd":"close","toggleCmd":"toggle","defaultCmd":"default","statusCmd":"status","persist":false,"x":610,"y":440,"wires":[["ab53a499.2e6778"]]},{"id":"55c8faf7.5b5aa4","type":"change","z":"150262f9.9e6d7d","name":"Close the Gate","rules":[{"t":"set","p":"payload","pt":"msg","to":"close","tot":"str"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":540,"y":520,"wires":[["d14b0189.2c2c5"]]},{"id":"47560bec.010ca4","type":"delay","z":"150262f9.9e6d7d","name":"","pauseType":"delay","timeout":"5","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":560,"y":560,"wires":[["f8116cd9.da6b3"]]},{"id":"f8116cd9.da6b3","type":"change","z":"150262f9.9e6d7d","name":"Open the Gate","rules":[{"t":"set","p":"payload","pt":"msg","to":"open","tot":"str"},{"t":"set","p":"topic","pt":"msg","to":"control","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":761.4285888671875,"y":521.4285888671875,"wires":[["d14b0189.2c2c5"]]}]

[dev120v]

thanks ksum . The gate stuff is a simple solution, and it does work but this still leaves the need to have a delay. I try to avoid delays as much as possible. This is why I proposed checking the status instead of a gate. You can press the power button (virtually and physically) as much as you want and the statuses will stay in sync, although thats a dumb idea for an adult to press a pc power button over an over.... people have children that have access to smarthome stuff lol

[ksum]

Normally I would have a delay shorter than 5 seconds, if/when I have one at all. I figure powering my Chromebook on is under 10 seconds from completely off to logged in and that is fast. So even if someone is speed pressing a power button for a PC, I suspect it will take longer than 5 seconds for the actual state of the PC to catch up. So in this case, unless I am misunderstanding something, I believe a Delay is fine and can be set to an acceptable value. The change if the HomeSeer node could be used to re-open the gate with a much shorter delay as well. It would mean you go out of the HomeSeer node at the top with 2 wires. One to the Delay and one to the gate. Delay the message by milliseconds, and you should be good.

[NateR]

Thank you for the replies, ksum and dev120v . Much appreciated!

I had some time to finish wiring this up to my computer this evening, and am now finishing off the flow in Node-RED.

I had not realized there was a gate node available - thank you for bringing that up. Either that, or dev120v's solution of storing the value and only passing when needed, will work for my needs. I'm leaning toward the gate for simplicity's sake - updating the status will not be as time-sensitive as sending a command, so a few-second delay shouldn't be an issue (even spamming the power button wouldn't cause any real issues that wouldn't shortly resolve themselves). Although, the suggestion of setting it up to directly check the status of the PC is appealing (that's the joy of DIY'ing these things - if I can program it, it can do it).

Again, thank you for taking the time to offer solutions for this!

[dev120v]

This is what I did since this situation came up...

[{"id":"254de179.c76a4e","type":"tab","label":"Flow 3","disabled":false,"info":""},{"id":"1b03df3d.6b26d1","type":"hs-device","z":"254de179.c76a4e","name":"HS4 Device","device":0,"server":"","feature":0,"reportonstartup":false,"x":210,"y":160,"wires":[["55fbf71c.947468","6b2cdf1c.6a57"]]},{"id":"6b2cdf1c.6a57","type":"change","z":"254de179.c76a4e","name":"","rules":[{"t":"set","p":"HS4DeviceStatus","pt":"flow","to":"payload.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":100,"wires":[[]]},{"id":"aedb2ea1.35cc9","type":"mqtt out","z":"254de179.c76a4e","name":"","topic":"OtherDevice/status","qos":"2","retain":"false","broker":"","x":850,"y":160,"wires":[]},{"id":"6095af01.8e0ec","type":"mqtt in","z":"254de179.c76a4e","name":"","topic":"OtherDevice/status","qos":"2","datatype":"json","broker":"","x":190,"y":240,"wires":[["9b55507d.038d5","cbcb1cb7.3b74c"]]},{"id":"77c7b573.9ae01c","type":"hs-device","z":"254de179.c76a4e","name":"HS4 Device","device":0,"server":"","feature":0,"reportonstartup":false,"x":830,"y":240,"wires":[[]]},{"id":"55fbf71c.947468","type":"function","z":"254de179.c76a4e","name":"Check If MQTT update needed  \\n   - if(flow.OtherDeviceStatus != msg.payload.value)","func":"if(flow.OtherDeviceStatus != msg.payload.value)\n{return msg}","outputs":1,"noerr":0,"initialize":"","finalize":"","x":530,"y":160,"wires":[["aedb2ea1.35cc9"]]},{"id":"9b55507d.038d5","type":"function","z":"254de179.c76a4e","name":"Check If HS4 update needed \\n   - if(flow.HS4DeviceStatus != msg.payload.value)","func":"if(flow.HS4DeviceStatus != msg.payload.value)\n{return msg}","outputs":1,"noerr":0,"initialize":"","finalize":"","x":520,"y":240,"wires":[["77c7b573.9ae01c"]]},{"id":"cbcb1cb7.3b74c","type":"change","z":"254de179.c76a4e","name":"","rules":[{"t":"set","p":"OtherDeviceStatus","pt":"flow","to":"payload.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":460,"y":300,"wires":[[]]}]

or same thing with switch node

[{"id":"254de179.c76a4e","type":"tab","label":"Flow 3","disabled":false,"info":""},{"id":"1b03df3d.6b26d1","type":"hs-device","z":"254de179.c76a4e","name":"HS4 Device","device":0,"server":"","feature":0,"reportonstartup":false,"x":210,"y":160,"wires":[["6b2cdf1c.6a57","d579437e.8802"]]},{"id":"6b2cdf1c.6a57","type":"change","z":"254de179.c76a4e","name":"","rules":[{"t":"set","p":"HS4DeviceStatus","pt":"flow","to":"payload.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":450,"y":120,"wires":[[]]},{"id":"aedb2ea1.35cc9","type":"mqtt out","z":"254de179.c76a4e","name":"","topic":"OtherDevice/status","qos":"2","retain":"false","broker":"","x":730,"y":160,"wires":[]},{"id":"6095af01.8e0ec","type":"mqtt in","z":"254de179.c76a4e","name":"","topic":"OtherDevice/status","qos":"2","datatype":"json","broker":"","x":190,"y":240,"wires":[["cbcb1cb7.3b74c","52cca78b.7a0ba8"]]},{"id":"77c7b573.9ae01c","type":"hs-device","z":"254de179.c76a4e","name":"HS4 Device","device":0,"server":"","feature":0,"reportonstartup":false,"x":710,"y":240,"wires":[[]]},{"id":"cbcb1cb7.3b74c","type":"change","z":"254de179.c76a4e","name":"","rules":[{"t":"set","p":"OtherDeviceStatus","pt":"flow","to":"payload.value","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":460,"y":280,"wires":[[]]},{"id":"d579437e.8802","type":"switch","z":"254de179.c76a4e","name":"Check if MQTT update needed","property":"payload.value","propertyType":"msg","rules":[{"t":"neq","v":"HS4DeviceStatus","vt":"flow"}],"checkall":"true","repair":false,"outputs":1,"x":470,"y":160,"wires":[["aedb2ea1.35cc9"]]},{"id":"52cca78b.7a0ba8","type":"switch","z":"254de179.c76a4e","name":"Check if HS4 update needed","property":"payload.value","propertyType":"msg","rules":[{"t":"neq","v":"OtherDeviceStatus","vt":"flow"}],"checkall":"true","repair":false,"outputs":1,"x":460,"y":240,"wires":[["77c7b573.9ae01c"]]}]