Option to disable "force" action during "motion" timeout

[Kilill]

Background

I have an zigbee controlled wall/light switch that i want to control via a motion detector and also connect it to the force signal to override the timeout. But there is a problem. The switch does not send an event if it has been manually activated, it only sends a state change event, so it is not possible to differentiate between a remote activation and a manual one.

So if connecting the state of the switch to the force input and connecting the motion state to the motion input will ofc lock the state into the force position as soon as it is turned on remotely.

Sugestion

An option to disable recognition of the force on signal in the node from the moment the motion signal goes active and until the timeout occurs. Observ that it is only the force on signal that needs to be ignored

[danube]

Thanks Kilill for your contribution! Are you able to verify the latest commit on branch motionOverridesForceOn against your suggestion?

[Kilill]

There seems to be a bug there: Enabling Ignore while powered on by motion then motion off no longer seems to work, have to use the force off to turn off lights.

Also in the sim bellow had to put a rate limiter in. otherwise the flow goes in a loop. So maybe also ignore if subsequent messages are the same as the previous one.

Hmm.... in this particular case, maybe the feedback feature can be used. I shall experiment a bit....

Simple simulation of the flow:

Simulation Flow

``` [ { "id": "ab844b2fa78745d3", "type": "tab", "label": "Flow 2", "disabled": false, "info": "", "env": [] }, { "id": "2671777132e2f293", "type": "group", "z": "ab844b2fa78745d3", "name": "Simulated light switch", "style": { "label": true, "fill": "#bfdbef" }, "nodes": [ "7f7d1af64f98dcb7", "c83b9d73cee87260", "67d6645324867680", "82d37d389f0c2ab8", "7608cf1b3c76d261" ], "x": 649, "y": 74, "w": 472, "h": 167 }, { "id": "2f7f520c15acd844", "type": "powerswitch", "z": "ab844b2fa78745d3", "name": "", "toggleTopic": "", "togglePayload": "true", "togglePayloadType": "bool", "motionTopic": "motion", "motionPayloadOn": "true", "motionPayloadOnType": "bool", "motionPayloadOff": "false", "motionPayloadOffType": "bool", "motionTimeoutValue": "1", "motionTimeoutUnit": "s", "motionTimeoutOverride": true, "motionOverridesForceOn": true, "feedbackActive": "", "feedbackTopic": "", "feedbackPayloadOn": "true", "feedbackPayloadOnType": "bool", "feedbackPayloadOff": "false", "feedbackPayloadOffType": "bool", "forceTopic": "force", "forcePayloadOn": "true", "forcePayloadOnType": "bool", "forcePayloadOff": "false", "forcePayloadOffType": "bool", "absTimeoutActive": false, "absTimeoutValue": "1", "absTimeoutUnit": "h", "x": 890, "y": 330, "wires": [ [ "7f7d1af64f98dcb7", "d742e6aedfe05879" ] ] }, { "id": "82d37d389f0c2ab8", "type": "inject", "z": "ab844b2fa78745d3", "g": "2671777132e2f293", "name": "D Force on", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "force", "payload": "true", "payloadType": "bool", "x": 760, "y": 155, "wires": [ [ "c83b9d73cee87260" ] ] }, { "id": "7608cf1b3c76d261", "type": "inject", "z": "ab844b2fa78745d3", "g": "2671777132e2f293", "name": "D Force off", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "force", "payload": "false", "payloadType": "bool", "x": 755, "y": 115, "wires": [ [ "c83b9d73cee87260" ] ] }, { "id": "ebe2f583c4103dc2", "type": "inject", "z": "ab844b2fa78745d3", "name": "D Motion On", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" }, { "p": "debug", "v": "true", "vt": "bool" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "motion", "payload": "true", "payloadType": "bool", "x": 615, "y": 305, "wires": [ [ "2f7f520c15acd844" ] ] }, { "id": "4db1a97f4765d0a8", "type": "inject", "z": "ab844b2fa78745d3", "name": "D Motion Off", "props": [ { "p": "payload" }, { "p": "topic", "vt": "str" }, { "p": "debug", "v": "true", "vt": "bool" } ], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "motion", "payload": "false", "payloadType": "bool", "x": 610, "y": 390, "wires": [ [ "2f7f520c15acd844" ] ] }, { "id": "7f7d1af64f98dcb7", "type": "delay", "z": "ab844b2fa78745d3", "g": "2671777132e2f293", "name": "", "pauseType": "rate", "timeout": "5", "timeoutUnits": "milliseconds", "rate": "1", "nbRateUnits": "5", "rateUnits": "second", "randomFirst": "1", "randomLast": "5", "randomUnits": "seconds", "drop": true, "allowrate": false, "outputs": 1, "x": 760, "y": 200, "wires": [ [ "c83b9d73cee87260" ] ] }, { "id": "c83b9d73cee87260", "type": "change", "z": "ab844b2fa78745d3", "g": "2671777132e2f293", "name": "", "rules": [ { "t": "set", "p": "topic", "pt": "msg", "to": "force", "tot": "str" } ], "action": "", "property": "", "from": "", "to": "", "reg": false, "x": 955, "y": 195, "wires": [ [ "67d6645324867680", "2f7f520c15acd844" ] ] }, { "id": "67d6645324867680", "type": "debug", "z": "ab844b2fa78745d3", "g": "2671777132e2f293", "name": "switch out", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "statusVal": "", "statusType": "auto", "x": 1015, "y": 130, "wires": [] }, { "id": "d742e6aedfe05879", "type": "debug", "z": "ab844b2fa78745d3", "name": "Power Switch out", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "true", "targetType": "full", "statusVal": "", "statusType": "auto", "x": 1175, "y": 330, "wires": [] } ] ```

[danube]

There seems to be a bug there: Enabling Ignore while powered on by motion then motion off no longer seems to work, have to use the force off to turn off lights.

True, I'll check that.

Also in the sim bellow had to put a rate limiter in. otherwise the flow goes in a loop. So maybe also ignore if subsequent messages are the same as the previous one.

Sounds reasonable.

I'll check that in the coming days. You should get notified.

Thank you so much for your feedback! Tom

[danube]

Rewrote that logic a bit. Would you be so kind and doublecheck?

I'm actually working on making the output message configurable in another branch (output). I'll implement your suggestion of an output filter there.

[danube]

Wait with your run. There's one thing I need to correct... 🙄

[danube]

There you go, everything should work now. Are you able to verify that?

[Kilill]

Much better but... 2 things:

1. motion on is not recognized unless the config is opened on the node, saved and deployed again.
2. motion off is not recognized unless Ignore while powered on by motion is checked

As a side note: not sure if your familiar with state machines, but this should probably have one at its heart ;-) there are several fsm nodes for node red. Haven't really looked at the innards of them so not sure how easy it would be to transplant some of that code...

[danube]

1. **motion on** is not recognized unless the config is opened on the node, saved and deployed again.

I can reproduce that. I created the new issue #15.

2. **motion off** is not recognized unless _Ignore while powered on by motion_ is checked

This one I cannot reproduce, but the reason may be the same as above. The node does obviously not work if the config has never been loaded (as in #15 explained). Can it be that motion off works for you after you have opened and closed the configuration, even with the option Ignore while powered on by motion unchecked?

As a side note: not sure if your familiar with state machines, but this should probably have one at its heart ;-) there are several fsm nodes for node red. Haven't really looked at the innards of them so not sure how easy it would be to transplant some of that code...

Never considered that. I'll take that as suggestion for future improvement and thank you for that.

[Kilill]

2. motion off is not recognized unless Ignore while powered on by motion is checked

That took longer to figure out than i'm willing to admit ;-) It only happens if you have a feedback from a switch...

When deploying the node and the Ignore option is not set on first deploy then, if there is a motion on event followed by a force on event, (as happens when you have it connected to the silly switch i have) the PSW correctly, gets stuck in the forced on state and ofc does not care about the motion off until its forced out with a force off. The important part here, (that i'm uncertain is a bug or a feature) if the PSW is in the forced on state and the ignore option is set, it is not kicked out of the forced on state upon redeployment.

So the question is should the PSW be reset upon deployment ?

[danube]

if the PSW is in the forced on state and the ignore option is set, it is not kicked out of the forced on state upon redeployment

Thought about that for a while. With the new ignore option I'm happy to provide you with a solution regarding your special switch and hopefully this also applies to one or the other user. Regarding the automatic reset I rather prefer the behaviour as it is. Meaning in this very specific case you are required to manually force off the switch. Then, the switch behaves as expected. It also applies only to users (1) upgrading the node and (2) being in that specific state at exactly the time of deployment. Every automatic behaviour may also raise more questions than to solve.

Hope that solution is acceptable for you. I'll merge this with the upcoming version 1.1.0 which I will publish the next days.