macinspak
commented
3 years ago Hi Bart.
Thanks for your interest in these nodes. Some of those are great ideas, however they are all listed under this one ticket which makes it hard to discuss them or have anyone pick them up to help.
Next time, please submit ideas, bugs, etc as individual tickets to ensure they are more manageable. I'll split them out this time.
Your ideas were really useful, it's only through people coming together and sharing their perspectives and helping out that we can truly make a great, simple and really easy to use solution for everyone to benefit from.
Regards, Andrew
bartbutenaers
Dear,
I was developing my own home security node, but saw this one tomorrow and it looks very nice! I really like the concepts, and it is a very flexible design. I like what I have seen so far!!
I think I need some extra features, to replace my current flow by the alarm-nodes. Was just wondering if perhaps some of these things are already possible in another way, if you are open for my suggestions, if you like me to create a pull-request or you prefer to implement it yourself, ...
Don't know homekit so perhaps my proposals don't make in conjunction with homekit. Don't hesitate to let me know, then I will need to continue with developing my own nodes. No problem!
Thanks in advance!! Bart
Proposal 1 - extend the trigger dropdown
Currently the sensor node allows two trigger types ("all messages" and "msg.payload=true"). It would be nice if extra options could be added by using TypedInputs. For example:
Then it becomes possible to trigger an alarm when
msg.payload=1ormsg.payload="OPEN"or ...That way my flow would become much cleaner, since I could avoid a lot of Change-nodes (which I also see in the example flows on your readme page):
Of course the existing options should be migrated automatically, to make sure the existing flows are not impacted.
BTW It is not clear to me how the current filtering works. Because at first sight the
triggerTypeseems only to be used in the sensor.html file, but I might have overlooked something. Would be nice if you could explain it!Proposal 2 - allow the state change to be delayed
When I change the state (e.g. from Off to Away), I want to have some time to leave the building. However during that time some of the sensors might detect my presence, but I don't want to trigger an alarm in that time period.
I think this might be solved by adding a delay input field to the change-state node:
So the new state would become active only after that specified delay.
Of course this timer need to be stopped automatically when meantime a new state change request arrives. For example I have changed the state from Off to Away, but then I suddenly realize that I have left my jacket in the kitchen. So I switch the state back from Away to Off. This means that the running timer should be stopped automatically.
P.S. not sure what would be the best way to implement this, because multiple timings might be useful. E.g. from Off to Away might be 60 seconds, while from Away to Off will most probably be 0 seconds.
Proposal 3: don't only store problems
I have not analyzed the internal kitchen of these nodes yet into detail, so perhaps this is already possible somehow.
When I want to switch my alarm from Off to Away, I want to show a list of the current problems. In the following demo my Node-RED flow sees that there is still one door open, which it shows to me:
Then I can decide whether I cancel the state-change and close the door first. Or I can continue switching the state.
To keep my flow simple, it would be nice if the alarm-nodes could store this information, and make it queryable. Indeed the sensor node gets all values from all sensors, and it knows (based on the last sensor value and the Trigger dropdown options) which sensors currently have detected an issue.