If you think I've misunderstood how your example would work with my sensors, then can you explain where I'm wrong? If you look at my "Kitchen Dome Sensor" example, it would send an initial "active" event to the 2 minute delay trigger node, but then it wouldn't send any other message until almost a full hour later, when it finally sent the "inactive" event. Meanwhile, the trigger node would've sent an "off" command to my lights after only 2 minutes of not receiving any events. Have I got that wrong?
I ran 2 tests with my nearby Iris V2. This one was constant motion:
And this one was with 2 pauses in my "dance routine" of about 5 seconds each:
It seems that the first pause caused the sensor to repeat reporting "inactive" but that doesn't matter with my flow because both messages reset the trigger node and my simple flow works as I like.
If it doesn't work for you then don't use it. Don't even try it if your reasoning trumps a test. It doesn't matter to me.
I have no desire to defend my offering further.
I don't care either way...
But I will point out that it reporting something in the log is different than it creating an EVENT and sending it to node-red via maker api.
I have tons of things that will report repeat things in the LOG, but never make an actual event that gets sent out due to the inherent de-duplication of events in the hub. It all depends on how the driver was written.
Again, not arguing. I know exactly what my sensors do (and don't do) in terms of sending events to node-red. That isn't up for debate.
To your point - use what works for you. 
It isn't a contest/argument.
1 Like
Aha! I use websocket for all motion inputs/outputs to get the best response but the side effect is that I DO get the duplicate events. This may be the key factor.
I'm glad you mentioned that because it hadn't crossed my mind.
2 Likes
Yup, that 100% makes a difference, as web socket doesn't do any deduplication. That is almost the entire reason it is a few milliseconds faster than webhook.
(Web socket also omits and messes up some other data, which is why I don't use it, but that is a completely different discussion.)
Makes sense! It works well for that.
1 Like
I use webhook for every other in or out node and I hadn't considered websocket for any reason other than the improved response, however minute, so I stumbled my way into the simplest flow.
Makes sense to me!
I'm sorry that you seem to feel that I'm somehow attacking you. My point is that I know exactly how my sensors behave in my system, and I was showing you evidence of that and the reason why your flow wouldn't work for me (and for @mike). This wasn't purely speculation. All those sensors I posted are currently used in motion lighting flows, so I've observed their behavior first-hand, and had to design my flows accordingly. Not only is that behavior supported by the event logs I posted, but I even did run a quick test of your flow with one of my sensors, just to make sure there wasn't something that I was misunderstanding (it happens). But, the result was as I expected, and the "off" command was sent to the light even though motion was still active.
I'm generally motivated by truth, facts, and understanding, and I'm genuinely curious as to why your Iris v2 is showing different behavior to mine (and I have more than one). I turned on debug logging on one of mine to see if there were log entries in there that weren't making it into the Event log, but that didn't seem to be the case. My Iris continues to only report a single "active" event, no matter how long the sensor remains active, so this doesn't seem to account for the difference. I even tried changing the driver to "Device," as I think that should log every raw Zigbee event received from the sensor. But even with this driver chosen, the logs don't show the extra "active" events.
The theory that @JasonJoel brought up about WebSockets sounded interesting, so I've just done some testing, but my testing didn't seem to account for the difference, either. I set up two of my sensors (an Iris and the Hue) as WS devices in NR, and observed their reports with debug nodes. The events that I'm seeing in NR still correspond to what I'm seeing in my HE event logs.
So right now I can think of 3 other possible causes:
-
Drivers - I'm using the "Generic Zigbee Motion Sensor" for my Iris and SmartThings sensors, since they don't have corresponding drivers built into HE. What drivers are you using for your sensors?
-
Firmware difference (although it would seem strange that a firmware change would introduce such a fundamental difference in device functionality). I'm not even sure how to check the firmware on the Iris?
-
Demo mode? I've seen mention of some sort of demo or test mode that the Iris sensors can be put into. I believe it reports much more frequently, but also chews through batteries much faster. Could your Iris be in this mode, somehow?
20 here.
Ditto
No idea.
Definitely not.
As I said, YMMV and I'm sorry that my simple flow doesn't work for you. It works for me and hopefully others.
Strange. I guess we might never know why they're different.
I don't want to discourage your willingness to help out, but when 3 different people pointed out why your flow wouldn't work in this particular case (and for a lot of other people out there), you could have taken that constructively, instead of seeming to insist that we were all mistaken.
BTW, I actually wish a flow like yours would have worked for me. It's an extremely simple solution, but it just won't work with the sensors I have.
2 Likes
I am trying to install Node red on a PI and when I run the install script
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)
I am getting
sh: 3: Syntax error: "(" unexpected
Any ideas?
I would install node.js and install it w/npm in two separate steps (which is the recommended installation method, too).
1 Like
I'd like to politely disagree with you. if you go to the Node red pi page, they say to use the script.
We provide a script to install Node.js, npm and Node-RED onto a Raspberry Pi. The script can also be used to upgrade an existing install when a new release is available.
2 Likes
@fblackburn Question - is there any way to put the node id or flow id in the log error messages in node-red? Every once in a while I'll do something stupid and misconfigure a node. It then logs an error - which is good.
But like in the example below, I have 8 different command nodes for that device and have no idea which of the 8 are generating the error. I did eventually find and fix it, but it would help greatly if I could see the node id that generated the error.
10 Sep 22:07:54 - [error] [hubitat command:Living Room Light] {"error":true,"type":"java.lang.Exception","message":"An unexpected error occurred."}
Here is an example from a different node type that does show the id, as an example:
10 Sep 21:09:23 - [error] [xml:e619331e.39c9d] Error: Non-whitespace before first tag.
OK. Then I don't know. I always follow the general install guide, which always works for me. I've never used the raspberry-pi specific script, as I'm picky about which version of node.js is being used.
Or of course you could install docker on the pi and run it in docker, too.
well, I figured it out, but I think my pi has issues...
I had to type bash then run the script... wierd.
1 Like
I think you can feed a catch-all catch node into a debug node showing full message and the node that threw the error is in the data you will be able to see.
Yes you can remove the name of all your nodes and leave the default command, then you will have the node id 
More seriously, I could easily add some prefix to the error message, ex:
10 Sep 22:07:54 - [error] [hubitat command:Living Room Light] [e619331e.39c9d]{"error":true,"type":"java.lang.Exception","message":"An unexpected error occurred."}
I can send any error message/format with this line. Just type the exact format/info you want 
1 Like
You can. That's just a bunch of work when you have 80+ flows. Good suggestion though.
Har har har. You are right though - technically. 
I used a poor example, as if the node were named I wouldn't have had an ID on that error either...
I was thinking a prefix to the error - very much like your example.
Something vaguely like:
done(new Error('[' + node.id + '] ' + response.text()))
Or I suppose I could use a catch, or name the nodes uniquely (I actually didn't even thing of that until your comment above).
Trying to figure out the workflow, I didn't figure out why you can't easily find the faulty node.
If you end up with this error, your node will have the status response error under it
Is it because you send a correct command after the wrong one and you lose that status?
Or you have too many tabs/nodes to look?
