search

niklaswall / node-red-contrib-light-scheduler

Light Scheduler is a node-red node that provides a weekly schedule mainly focused on controlling light in home automation scenarios.
Apache License 2.0
41 stars 15 forks source link

Using the Light-Scheduler in the middle of a flow #17

Open brammh opened 6 years ago

brammh commented 6 years ago

Hi Niklaswall, I really like this node though using it in a different way. In my use case a sensor triggers an event, which passes this payload to your scheduler, based upon it's settings it forwards the message to enable or disable a light. Since your node is one at the beginning of a flow, I needed to make some mod's for a middle-flow node. If you want I can merge it back, but not sure if you like the idea therefore checking. I'm using your scheduler and evaluation / matchevent(), keeping the original payload (sensor info) in-tact. forwarding it to output 1 if matchevent is true, to 2 if false. simple as that. See it as an Light-Schedule-Switch. Plus added an option to not use the local timer, but be event driven. I can also use 1 output as currently and add the 'on or off' message to the original payload. Let me know if you are interested in this idea, otherwise also fine, I keep it locally.

niklaswall commented 5 years ago

Hi,

I have actually done this myself as well, but have not decided to release it since it has it's problems. If you have the code available, please make a pull request so that I can look into it in more detail!

/Niklas

tsprivate commented 5 years ago

I have the same used @brammh .. but I have setup a dedicated flow with your node which is switching a global variable (eg. global.Light =true/false or ON/OFF) .. I check now the my flow on the variable to pass-through the sensor-trigger or not

niklaswall commented 5 years ago

Just pushed v0.0.14 that adds a new filter-node with this functionality. Please try it out and report any issues.

Have a nice week end! /Niklas

rhoddan commented 5 years ago

Really good function with the filter. It seems not to be possible to send override codes to the filter node.

niklaswall commented 5 years ago

@rhoddan that's correct. It does currently don't care about the overrides.

Since I used msg.payload for the overrides, that would mean that I have to block these msg from being forwarded to the outputs and since the override keywords are so basic that could have a problem if you for exmaple want a msg.payload of 'stop' to be forwarded to the correct output based on the schedule.

I'm going to add the override functionality back, but will move it to msg.override so that it's easy to determine if it's a override msg or a "normal" one.

/Niklas

rhoddan commented 5 years ago

perfect! Maybe it can be good to change (or complement) the standard node (not the filter node) so it uses msg.override as well (just to have a standard behavior)?

niklaswall commented 5 years ago

Absolutely. I think that one will need to use both msg.payload and msg.override initially to not cause to many breaking setups.

/N