Never used it, but maybe:
Played around with that last night. Couldn't get it work. Will try again today. Had better luck writing a function node that required a payload from two topics before continuing.
It's a good question, though... I can see needing that capability sooner or later myself.
Fresh eyes Coffee in the morning fixed the issue. Here's the test sequence I used:
(The switch node tests for flow.test >= 3)
Here's the outcome:
The three wait-paths timeouts correspond to injecting 0, 1, and 2.
So it works pretty much the way I would like.
Okay, so I've removed node-red and installed via npm.
I'm not seeing weird behaviour, however I haven't tested much.
I need to figure out how to add a check if the device is already on so I'm not constantly sending on commands to my lutron hub when the actual light is on.
Does anyone have a screenshot they could share that inclues how they check the switch states before sending the on or off commands?
This is what I have so far.
I know I'm a little late but how about "node-red-contrib-queue-gate"
Haven't used it though.
1 Like
Will check it out later today. First day back at work! Got my face mask on!
2 Likes
Stay safe!!!
1 Like
@fblackburn - So just noticed because I had node-red-log running when I rebooted my HE hub I am getting an error when initializing my mudroom door sensor - a "SmartSense Multi V1". Not sure if it is affecting anything but thought I'd report it..
Also submitted on Github as well...
14 May 09:45:25 - [info] [hubitat device:Mud Room Door Sensor 2] Initialized. contact: closed
14 May 09:45:25 - [info] [hubitat device:Mud Room Door Sensor 2] Fix "threeAxis" attribute desynchronization: "[object Object]" --> "[object Object]"
(node:1188) UnhandledPromiseRejectionWarning: TypeError: value.match is not a function
at castHubitatValue (/home/node-red/.node-red/node_modules/node-red-contrib-hubitat/nodes/device.js:26:38)
at eventCallback (/home/node-red/.node-red/node_modules/node-red-contrib-hubitat/nodes/device.js:109:25)
at /home/node-red/.node-red/node_modules/node-red-contrib-hubitat/nodes/device.js:144:11
at Array.forEach ()
at EventEmitter.systemStartCallback (/home/node-red/.node-red/node_modules/node-red-contrib-hubitat/nodes/device.js:136:10)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:1188) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag--unhandled-rejections=strict(see Command-line API | Node.js v21.6.2 Documentation). (rejection id: 4)
1 Like
Thank you for reporting on github 
I fixed it
3 Likes
Just got around to testing this. It also works - thanks for the suggestion! The author of "node-red-contrib-queue-gate" has another node called "node-red-contrib-simple-gate".
This also can be used for my purpose. So now there's at least three choices of nodes for a wait until function (wait-paths, queue-gate, simple-gate).
3 Likes
Not trying to be rude, but that might be better to ask in a smartthings forum.... It doesn't really have anything to do with the Hubitat node-red node set.
(Also, I don't know the answer to your question)
I understand but the experts are over here. Thanks
We broke that barrier about 1,937 posts ago. 
1 Like
Fair enough. Well, then by all means, continue.
I know zero about the current state of smartthings, so I'll sit that out. 
2 Likes
Not good. I go there once in a while. They've got their own influx of former Wink users. And the support issues that comes along with that .....
1 Like
I still have my v2 hub in the drawer in case I ever need it. Haven't so far ...
I actually had a pretty positive experience with ST overall. All of my light automation ran locally, so the cloud issues and downtime rarely affected me.
If they wouldn't have moved to the new app and custom code model I might have stayed.
1 Like
Holding on to mine as well.
OTOH, my Wink stuff sold on eBay for a premium last year. And I have zero guilt over it - it worked as described when I sold it and it is up to the buyer to do their due diligence vis-a-vis Wink's long-term survival.
2 Likes
Anyone using node-red-contrib-alexa-remote2 have trouble with it disconnecting regularly?
I'm using it for TTS to my 4 echo dots.
It works fine for a while but then randomly stops acting on TTS commands. I can watch the flow and get "success" appear under the node but get no announcement. If I go into the configuration node, reload and redeploy it then works fine for a bit, then stops again. I think it may be to do with the refresh cookie system, but I don't fully understand what happens with that. I have mine set to the default 3 days, but what determines what that needs to be? Is there a setting somewhere in my Amazon account that means the cookie needs to be refreshed every so often? Can I change it so it stays connected? It's affecting the WAF at the moment so I'm under pressure to sort it. How do Echo Dots play direct with Hubitat for TTS? I would switch to that if it's reliable.
@Geoff_T I have the same issues that you are and been trying to figure it out and uninstall and reinstall node-red-contrib-alexa-remote2 but still having the same issues? I also have another issue and that is with presence. The Device node shows that I'm still in but the devices driver on the Hub show I'm not present??? I was thinking that there is something wrong in the Device node but all my other nodes are good?? Is anyone else having an issue with presence? Thanks
Current States
- bedId : -9223372027370855302
- mode : Right
- presence : not present
- switch : off
