That was my original thinking, guess it's time to learn javascript!
Nice!
Spinning a msg in a loop works, just note that can be very impactive from a CPU loading standpoint. Might be worth using a delay loop to throttle it to maybe 1 msg/s.
Looks like your way is easier than mine, with a few caveats/conditions yours doesn't handle that mine does (at the expense of much more complexity). Such as hitting ON after you hit OFF... In yours the OFF stays spinning around, in mine hitting ON after OFF cancels the OFF.
thx! yeah that was my worry too - also maybe an abort for infinite loops. Totally fun to play around with.
2 Likes
@rocketwiz @erktrek @JasonJoel
I think this is another solution that only uses core nodes (assuming the counter node is a core node). Seems to work as expected in my testing (I used 10 seconds instead of 5, but it should work with 5 just as well).
2 Likes
I put a switch node after the count node in my version to limit the number of iterations to 10.
Actually just realized I have a second infinite loop. If OFF is pushed when count = 0. That's easy to fix also with a switch node before the 100 ms delay node. This would be the fixed version then.
1 Like
Merry x-mas. I think this works, I tested it for all of 5 seconds 
:
Function node code (now with comments!). Note that you need 2 outputs on the function node the way I did it:
/// Init variables used
if (typeof context.sendOff === "undefined") {
context.sendOff=false;
}
if (typeof context.inTimer === "undefined") {
context.inTimer=false;
}
if (msg.payload.value === "on") {
// Set variables
context.inTimer=true;
context.sendOff=false;
// Clear existing timer, if there is one
clearTimeout(context.to);
// Create timer with 5s (5000 ms) delay
context.to = setTimeout(function(){
// Clear inTimer varable, as the timer is now expired
context.inTimer=false;
// Check sendOff to see if we should send a queued OFF message
if (context.sendOff) {
// Clear sendOff as we are going to right now
context.sendOff=false;
// Send the queued OFF message out output 2
node.send([null, context.offQueue]);
}
}, 5000);
// Send the ON message out output 1
return [msg, null];
} else if (msg.payload.value === "off") {
if (context.inTimer) {
// If we are inTimer, then set sendOff to queue the OFF message for later
context.sendOff=true;
// Save the queued message for sending later
context.offQueue = msg;
} else {
// If sendOff is true, clear it. Shouldn't
// need this, but just to be safe...
if (context.sendOff) {
context.sendOff=false;
}
// Send the OFF message out output 2
return [null, msg];
}
}
5 Likes
Thanks, I will study it!
1 Like
so with the help of @bill.d i got this flow.
Ass you can see, both quiet mode switches are off, but i still get the incorrect output which sets the wrong mode.
Even adding inject node, changes correct mode, but straight back to incorrect.
It's like the 1st change node doesnt recognize the hubitat node has changed
Any idea what may cause that?
Is this where an RBE node may help??
Cheers
Do you have any other sequences on NR or leftover rules on HE that could be secretly impacting this?
I would also look at your change nodes.. make sure there isn't something odd going on in there - sometimes its the simple stuff.
Unless there is an issue with setting modes. Maybe create some test sequences that manually change modes via inject. See what happens.
It could be the wifes phone and the MakerAPI it connects to....As in wrong Maker API
Is it better to have a seperate MakerAPI instance for each phone which controls the virtual switch, or can both phones user same MakerAPI just specifing different VS devices ID's??
(if that makes sense)
I am unclear what you mean by this sorry... It should not matter what goes into HE as long as it's Maker API exposes the correct device(s) to NR?
edit: unless your setup is somehow overwriting changes in NR..
So have 1 Maker API instance for NR with all the devices i need selected.
I also have another MakerAPI which my phone connects to pointing the the v/switch.
The only thing i can think of that was screwing with NR, was my wifes phone was connecting the MakerAPI that NR connects to!
But if that doesnt matter, not sure whats wrong with NR, as i have nothing else running in HE that would affect modes
Mmmm... that is something to try. Seems like with webhook the stuff might get a little wonky as it wouldn't return properly. Interesting, never thought about it like that.
not sure ay!!
Ive just changed my wifes phone to connect to the same MakerAPI as mine, and just changing the device ID it points to
We'll see how that goes...
1 Like
@fblackburn, Possible enhancement. Is it feasible to have the command node's device field filled in with a change node, i.e. "set msg.device"? The use case I see is that a subflow could be set up with a command node in it, and the device could be passed into the subflow.
Edit: I guess I can do this now by using deviceID, but that's not very intuitive. I'd rather prefer to use a device name.
Yes it should be feasible. I already worked on this feature to know if it should be easy or not. Because I agree with you that is more intuitive to select device by name than by ID
But there are some major downside with this method
- device name is not unique, so we would need to pickup the first device found with the selected name
- we would need to make a cache of all available devices (costly on some setup) to map name with ID (but need to refresh cache each time a new device is added/updated... probably manually?)
There are maybe better solutions or tradeoff but it's actually not so simple/costless
alternative should be to make a feature request on Maker API to allow to search device by name to have the device ID instead of requesting ALL devices 
2 Likes
I don't like the downsides, so maybe it's not that important. I'm sure the number of users wanting this feature will be small, so I'd hate to overload the process if that is what would happen. Thanks for responding, anyway.
2 Likes
Does anyone know if Modes stay persistant each HE daily backup?
This morning my mode change to Away then Home, causing my bedroom light to come on and wake us up at 3 in the morning!! Suffice to say, wife was NOT happy!!!
I checked NR and what sets my modes hadnt changed, but the mode node had
This is from HE logs
I had to manually change my v/switch on/off for it to go back to correct mode
Not sure what this means.
I was under the impression HE reboots each time it does it nightly backup???
Just wondering why my device went into Away mode, then Home mode, without anything telling it too!!
