Device status/control via payload

[bakman2]

Perhaps a weird subject title, but it would be nice to have a node that accepts the device as input, this would eliminate the use of multiple status/control nodes and adds more flexibility.

For the control node something like:

{"device":"fan_livingroom","On":true,"RotationSpeed":50}

or inject into status node:

{"device":"fan_livingroom"}

Is this feasible ?

[NorthernMan54]

As the nodes are stateful, this is not feasible at this time. Great thought

Sent from my iPad

On Aug 12, 2019, at 5:52 AM, bakman2 notifications@github.com wrote:

Perhaps a weird subject title, but it would be nice to have a node or updated status node that accepts the device as input, this would eliminate the use of multiple status/control nodes and adds more flexibility.

For the control node something like:

{"device":"fan_livingroom","On":true,"RotationSpeed":50} or inject into status node:

{"device":"fan_livingroom"} Is this feasible ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dxdc]

@bakman2 @NorthernMan54 Cool idea. I've been wondering about this as well as managing states.

1. Suppose I want to send {"On": true} to a hallway light if the entry light is on AND motion is detected. So, I find myself using the event-driven behavior for the motion trigger, then polling the state of the entry light, finally checking to make sure the hallway light isn't already on, and then preparing/sending the JSON to the hallway light.

This gets more complicated if the state behavior isn't always one-way... and private msg. variables seem to get overwritten, so the only way I've been able to accomplish this is with various join nodes. Are you guys doing something different for that?

2. I had a clever way that could address your situation @bakman2 ... just thought about it.

[{"id":"afe67722.aba5f8","type":"switch","z":"f2ecc746.8566a8","name":"Switch","property":"device","propertyType":"msg","rules":[{"t":"eq","v":"Office Fan","vt":"str"},{"t":"eq","v":"Backyard Gate","vt":"str"},{"t":"eq","v":"Backyard Patio","vt":"str"},{"t":"else"}],"checkall":"true","repair":false,"outputs":4,"x":340,"y":440,"wires":[["8a5ccfc2.9c2e3"],["aea1b304.d332b"],["97944d0a.84a78"],["3f5346d9.fdfcfa"]]},{"id":"ac0eec69.17ec","type":"change","z":"f2ecc746.8566a8","name":"Set device","rules":[{"t":"move","p":"payload.device","pt":"msg","to":"device","tot":"msg"}],"action":"","property":"","from":"","to":"","reg":false,"x":170,"y":440,"wires":[["afe67722.aba5f8"]]},{"id":"8a5ccfc2.9c2e3","type":"hb-control","z":"f2ecc746.8566a8","name":"Office Fan","Homebridge":"Homebridge","Manufacturer":"Default-Manufacturer","Service":"Fan","device":"HomebridgeCC:22:3D:E3:CE:30Default-ManufacturerOffice Fan00000040","conf":"27ab7bfb.cc01b4","x":530,"y":380,"wires":[]},{"id":"70bfa754.0e94f8","type":"link in","z":"f2ecc746.8566a8","name":"","links":[],"x":55,"y":440,"wires":[["ac0eec69.17ec"]],"icon":"node-red-contrib-homekit-bridged/homekit.png"},{"id":"3f5346d9.fdfcfa","type":"debug","z":"f2ecc746.8566a8","name":"","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"false","x":530,"y":500,"wires":[]},{"id":"aea1b304.d332b","type":"hb-control","z":"f2ecc746.8566a8","name":"Backyard Gate","Homebridge":"Homebridge","Manufacturer":"Belkin WeMo","Service":"Switch","device":"HomebridgeCC:22:3D:E3:CE:30Belkin WeMoBackyard Gate00000049","conf":"27ab7bfb.cc01b4","x":540,"y":420,"wires":[]},{"id":"97944d0a.84a78","type":"hb-control","z":"f2ecc746.8566a8","name":"Backyard Patio","Homebridge":"Homebridge","Manufacturer":"Belkin WeMo","Service":"Switch","device":"HomebridgeCC:22:3D:E3:CE:30Belkin WeMoBackyard Patio00000049","conf":"27ab7bfb.cc01b4","x":540,"y":460,"wires":[]},{"id":"27ab7bfb.cc01b4","type":"hb-conf","z":"","username":"031-45-154"}]

[NorthernMan54]

@dxdc If motion is detected, why not just send the On request regardless of the current state of the light? I think I'm missing something from your example.

In my setup, I use the resume node with my motion sensors. So when the Off signal is received, the light goes back to the previous state before the most recent On signal. So if the light was already on, the motion sensor going off doesn't turn it off afterwards.

[dxdc]

@dxdc If motion is detected, why not just send the On request regardless of the current state of the light? I think I'm missing something from your example.

I was worried about hitting API's too many times. Do you know how this is handled on the backend? If the current state = target state is it just ignored by HK or Homebridge or both? Are only the needed parameters adjusted?

In my setup, I use the resume node with my motion sensors.

I didn't quite understand how the resume node works from the docs. Do you have an example flow you can share?

[NorthernMan54]

My hub-resume example, posted yesterday ( looks like I saw this question coming )

https://github.com/NorthernMan54/node-red-contrib-homebridge-automation/wiki/Stateful-Lights

In regards to extra calling of an api, I have not noticed an issue, but ymmv.

[dxdc]

@NorthernMan54 thanks, I think I get it! So, the resume feature essentially just stores the payload of that device (in memory I presume?) so that it can be fed back into a control at a later point. Is that right? If that's the case, I'm not sure the resume terminology makes sense to me, it's almost like capturedState, savedState, etc. may be more clear but it makes sense.

One question on your flow, what is the purpose of the Join node? It seems like you could tie directly into your resume nodes, but maybe I'm missing something.

In regards to extra calling of an api, I have not noticed an issue, but ymmv.

I've been very curious about this myself. Maybe I'll run some experiments on this later using dummy switches and MQTT and see if updates get pushed.

[NorthernMan54]

The Join node takes multiple messages and combines them into a single message. And comes into play when you set brightness or change colour etc, as these commands generate multiple messages. Not necessary if you don’t plan on using those type of commands.

As I’m using this with Alexa, I like being able to dimm all the lights in a room at the same time.

On Oct 31, 2019, at 8:40 AM, dxdc notifications@github.com wrote:

 @NorthernMan54 thanks, I think I get it! So, the resume feature essentially just stores the payload of that device (in memory I presume?) so that it can be fed back into a control at a later point. Is that right? If that's the case, I'm not sure the resume terminology makes sense to me, it's almost like capturedState, savedState, etc. may be more clear but it makes sense.

One question on your flow, what is the purpose of the Join node? It seems like you could tie directly into your resume nodes, but maybe I'm missing something.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[bakman2]

Although I suggested a while ago, I have since used homebridge-mqtt for more flexibility to add/control additional characteristics to a device (like eg. battery status), although these 2 could be used interchangeably.

[dxdc]

And comes into play when you set brightness or change colour etc, as these commands generate multiple messages.

Gotcha, thanks... didn't know that. That explains the short timeout delay as well.

[dxdc]

FYI:

In regards to extra calling of an api, I have not noticed an issue, but ymmv.

For repeated requests, it definitely asks Homebridge to send the API call again. I verified this with MQTT and repeatedly sent the same payload. I don't love the fact that this happens for numerous reasons (esp. considering how this can affect external API's), but probably it's a Homekit/HAP-JS issue and not related to this plugin. Still, I'll probably keep my way of checking the status first before deciding whether to send or not.

[dxdc]

@NorthernMan54 wanted to thank you for developing this awesome plugin. I've had a lot of fun with it over the past few months. I wanted to share with you a plugin I've developed join-wait (https://flows.nodered.org/node/node-red-contrib-join-wait), that I think could be relevant to a lot of home automation use cases and I think nicely complements the work you've done here.

One thing I've found myself wanting is the ability to send triggers if a sequence of events happen within a specific timeframe. Either - in a specific order - or not.

For example:

• If Event A, B, and C happen within 5 minutes, then send command X.
• If Event A, B, and C happen within 5 minutes - but not Event D - then send command X.
• If Event A, B, and C don't happen within 5 minutes -- e.g., if just A and C.

So for example, here's a flow I've developed to handle the following issue:

1. Lights go off
2. Motion sensor triggered
3. Lights go back on

Using the join-wait node, I can now look for this specific sequence to happen within a 12 second window - and if so - turn the lights back off. I've added a number of features as well that allow for some more powerful processing - and the nodes can be chained. Feel free to add this to your Wiki, btw.

[{"id":"258e8d9c.cf4cc2","type":"switch","z":"ee7b2f38.64383","name":"Motion detected","property":"payload.MotionDetected","propertyType":"msg","rules":[{"t":"true"}],"checkall":"true","repair":false,"outputs":1,"x":680,"y":620,"wires":[["850e6a8a.c27418"]]},{"id":"84838c8a.c48d","type":"hb-event","z":"ee7b2f38.64383","name":"Front Door","Homebridge":"Front Door","Manufacturer":"Ring","Service":"Motion Sensor","device":"Front Door9B:FC:9C:85:98:6FRingFront Door00000085","conf":"27ab7bfb.cc01b4","x":500,"y":620,"wires":[["258e8d9c.cf4cc2"]]},{"id":"874e684c.ff2588","type":"delay","z":"ee7b2f38.64383","name":"","pauseType":"delay","timeout":"2","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":1020,"y":520,"wires":[["9701a6eb.4d90c8"]]},{"id":"e235d9c4.0e43a8","type":"hb-control","z":"ee7b2f38.64383","name":"Front Walkway","Homebridge":"Homebridge","Manufacturer":"Belkin WeMo","Service":"Switch","device":"HomebridgeCC:22:3D:E3:CE:30Belkin WeMoFront Walkway00000049","conf":"27ab7bfb.cc01b4","x":1340,"y":520,"wires":[]},{"id":"a7503f84.b028d","type":"function","z":"ee7b2f38.64383","name":"On/Off","func":"msg.name += ((msg.payload.On) ? ' On' : ' Off');\nreturn msg;","outputs":1,"noerr":0,"x":690,"y":520,"wires":[["850e6a8a.c27418"]]},{"id":"677df444.c8e33c","type":"hb-event","z":"ee7b2f38.64383","name":"Front Walkway","Homebridge":"Homebridge","Manufacturer":"Belkin WeMo","Service":"Switch","device":"HomebridgeCC:22:3D:E3:CE:30Belkin WeMoFront Walkway00000049","conf":"27ab7bfb.cc01b4","x":520,"y":520,"wires":[["a7503f84.b028d"]]},{"id":"850e6a8a.c27418","type":"join-wait","z":"ee7b2f38.64383","name":"","paths":"[\"Front Walkway Off\", \"Front Door\", \"Front Walkway On\"]","pathsToExpire":"","ignoreUnmatched":false,"pathTopic":"name","pathTopicType":"msg","correlationTopic":"","correlationTopicType":"msg","timeout":"12","timeoutUnits":"1000","exactOrder":"true","firstMsg":"true","mapPayload":"false","disableComplete":false,"x":860,"y":540,"wires":[["874e684c.ff2588"],[]]},{"id":"9701a6eb.4d90c8","type":"change","z":"ee7b2f38.64383","name":"Off","rules":[{"t":"set","p":"payload","pt":"msg","to":"{\"On\": false}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":1170,"y":520,"wires":[["e235d9c4.0e43a8"]]},{"id":"27ab7bfb.cc01b4","type":"hb-conf","z":"","username":"031-45-154"}]

[NorthernMan54]

I’m not sure if you aware but GitHub Wiki’s allow anyone to create pages and edit.

I read thru this and it took me a while to figure out why, you have a motion sensor that has a lot false positive’s and you built this to avoid the false positives.

Have you thought about just getting a different sensor?

But what this provides is really cool.

On Jan 16, 2020, at 3:29 AM, dxdc notifications@github.com wrote:  @NorthernMan54 wanted to thank you for developing this awesome plugin. I've had a lot of fun with it over the past few months. I wanted to share with you a plugin I've developed join-wait (https://flows.nodered.org/node/node-red-contrib-join-wait), that I think could be relevant to a lot of home automation use cases and I think nicely complements the work you've done here.

One thing I've found myself wanting is the ability to send triggers if a sequence of events happen within a specific timeframe. Either - in a specific order - or not.

For example:

If Event A, B, and C happen within 5 minutes, then send command X. If Event A, B, and C happen within 5 minutes - but not Event D - then send command X. If Event A, B, and C don't happen within 5 minutes -- e.g., if just A and C. So for example, here's a flow I've developed to handle the following issue:

Lights go off Motion sensor triggered Lights go back on Using the join-wait node, I can now look for this specific sequence to happen within a 12 second window - and if so - turn the lights back off. I've added a number of features as well that allow for some more powerful processing - and the nodes can be chained. Feel free to add this to your Wiki, btw.

[{"id":"258e8d9c.cf4cc2","type":"switch","z":"ee7b2f38.64383","name":"Motion detected","property":"payload.MotionDetected","propertyType":"msg","rules":[{"t":"true"}],"checkall":"true","repair":false,"outputs":1,"x":680,"y":620,"wires":[["850e6a8a.c27418"]]},{"id":"84838c8a.c48d","type":"hb-event","z":"ee7b2f38.64383","name":"Front Door","Homebridge":"Front Door","Manufacturer":"Ring","Service":"Motion Sensor","device":"Front Door9B:FC:9C:85:98:6FRingFront Door00000085","conf":"27ab7bfb.cc01b4","x":500,"y":620,"wires":[["258e8d9c.cf4cc2"]]},{"id":"874e684c.ff2588","type":"delay","z":"ee7b2f38.64383","name":"","pauseType":"delay","timeout":"2","timeoutUnits":"seconds","rate":"1","nbRateUnits":"1","rateUnits":"second","randomFirst":"1","randomLast":"5","randomUnits":"seconds","drop":false,"x":1020,"y":520,"wires":[["9701a6eb.4d90c8"]]},{"id":"e235d9c4.0e43a8","type":"hb-control","z":"ee7b2f38.64383","name":"Front Walkway","Homebridge":"Homebridge","Manufacturer":"Belkin WeMo","Service":"Switch","device":"HomebridgeCC:22:3D:E3:CE:30Belkin WeMoFront Walkway00000049","conf":"27ab7bfb.cc01b4","x":1340,"y":520,"wires":[]},{"id":"a7503f84.b028d","type":"function","z":"ee7b2f38.64383","name":"On/Off","func":"msg.name += ((msg.payload.On) ? ' On' : ' Off');\nreturn msg;","outputs":1,"noerr":0,"x":690,"y":520,"wires":[["850e6a8a.c27418"]]},{"id":"677df444.c8e33c","type":"hb-event","z":"ee7b2f38.64383","name":"Front Walkway","Homebridge":"Homebridge","Manufacturer":"Belkin WeMo","Service":"Switch","device":"HomebridgeCC:22:3D:E3:CE:30Belkin WeMoFront Walkway00000049","conf":"27ab7bfb.cc01b4","x":520,"y":520,"wires":[["a7503f84.b028d"]]},{"id":"850e6a8a.c27418","type":"join-wait","z":"ee7b2f38.64383","name":"","paths":"[\"Front Walkway Off\", \"Front Door\", \"Front Walkway On\"]","pathsToExpire":"","ignoreUnmatched":false,"pathTopic":"name","pathTopicType":"msg","correlationTopic":"","correlationTopicType":"msg","timeout":"12","timeoutUnits":"1000","exactOrder":"true","firstMsg":"true","mapPayload":"false","disableComplete":false,"x":860,"y":540,"wires":[["874e684c.ff2588"],[]]},{"id":"9701a6eb.4d90c8","type":"change","z":"ee7b2f38.64383","name":"Off","rules":[{"t":"set","p":"payload","pt":"msg","to":"{\"On\": false}","tot":"json"}],"action":"","property":"","from":"","to":"","reg":false,"x":1170,"y":520,"wires":[["e235d9c4.0e43a8"]]},{"id":"27ab7bfb.cc01b4","type":"hb-conf","z":"","username":"031-45-154"}] — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[dxdc]

I’m not sure if you aware but GitHub Wiki’s allow anyone to create pages and edit.

Didn't know that... will look into a submission then!

I read thru this and it took me a while to figure out why, you have a motion sensor that has a lot false positive’s and you built this to avoid the false positives.

It's a Ring doorbell. It only happens like 5% of the time that this is a problem. I don't want to turn the sensitivity down. It happens only rarely that it gets triggered like this, but it starts an annoying loop if it does.

[moshed]

I know this issue is real old but was there even any progress on allowing device choice to be dynamically set eg:

msg = {
    device: 'abc light ',
    payload: {
        On: 1
     }
}