On the command node, sure. But isn't he asking about the device node?
Just read it again and he is saying both. I'm not where I can check but I don't recall seeing this capability on the device node.
1 Like
But then couldn't you use a generic event node and parse that?
3 Likes
I haven't looked into that node but I think you're right about that. 
3 Likes
Ditto. Event node. I haven't found it that useful versus just making individual device nodes though.
Unless you put all of your parsing logic in one function node. Then it could clean things up / require fewer nodes I suppose.
But I hate burying code in function nodes. 
3 Likes
Also if you wanted to get specific and reduce the number from 45 to 15 - you could just trap all events for a particular device node and parse out "pushed" / "doubleTapped" / "held" and do it that way as well.
I agree I prefer the visual representation if it makes sense - easier to quickly see what's going on.
2 Likes
Wow that's a lot of help. Thank you all very much 
I'll try out your feedback tomorrow, but basically you're telling me I can override the dropdowns by populating msg.deviceId, and I'm guessing msg.arguments and msg.command with the relevant IDs and it should work?
Again, thanks a million
(and I'm with you on not hiding functionality in function nodes. It feels weirdly inelegant)
2 Likes
Yep! Very flexible are these nodes...
1 Like
I do something like this for logging events. I use a generic event node and have a function node that filters out events that I don't want to log. I did this specifically to filter out lux changes but then expanded it out as I kept finding other event types. Example below:
//Create an array of events to be filtered out
var filterEvents = ['power','current','voltage','energy','illuminance','temperature','lastActivity','humidity','energyDuration'];
if(filterEvents.indexOf(msg.payload.name)!== -1){ // check if published event needs to be filtered
msg = null //null should stop the flow
}
return msg;
Agree on not "hiding" code in a function node, but this function node is called "Filter Events" and is the first thing after the generic event node, so it's pretty self explanatory 
2 Likes
No argument! I don't have ZERO function nodes... They have their place for sure.
2 Likes
I know most people following or posting in this thread have found that Node-RED is incredibly powerful but also an almost infinitely deep rabbit hole. I also know that this forum is really for hubitat and Node-RED has its own forum, but I wanted to share a parallel rabbit hole that is very useful in Hubitat/Smarthome context if you are already using Node-Red.
(I do recognize that one could probably build custom code to eliminate Node-Red from what I am going to describe, but it is really similar in spirit and execution to Node-Red)
If you want to add intricate voice interactions with Alexa (and supposedly google home devices which I can't speak to as I don' t have any), then voiceflow.com is a lot like building in Node-RED only for voice flows. The cost of a real account is way out of reach for a hobbyist like me, but the free size is big enough for my needs.
I have been able to build with a combination of Node-RED and voiceflow an Alexa skill that does the following:
- When I initiate the skill, Amazon calls a http in NR node that tells the flow which room the interaction is in.
- Then it asks what I want to do in the named room
- So far, I have it so I can turn on/off, toggle, set max/min/1-99 brightness, and select a color. For the colors it recognizes all 140 different colors covered by standard CSS.
- It then sends a different http in NR node what was requested so that NR logic can do whatever is requested for whichever set of devices I want.
- I can also have NR return success or failure of the requested change and have alexa announce the change.
- I then have it ask for anything else I want to change. I have found this really cool as I have just gone down the list of colors changing from one to the next.
Now if you have already done a fair amount of Alexa integration, you might say that you don't need a skill for this sort of thing. This is true, but the level of interactivity you can build is almost limitless. For instance, I know I can build having Alexa say after a change, "Do you like how that looks?" and then if you say something negative, having her say "Shall I change it back?" and being able to do so. It also gives you that ability to enter a large number of phrases that you want interpreted in the same way. For instance I trigger the toggle based on toggle, toggle lights, change or change lights. Adding another phrase would take all of about 30 second plus the upload to Alexa step.
As best I can tell, voiceflow.com built this easy to use GUI that once you are ready to test on your echo device builds the skills in the way you can code the skill and uploads it into your Amazon developer account. You could then edit it like any other code, but I have done everything so far using voiceflow's GUI.
I think the biggest weakness in what I have described is that it does make you have a path for Amazon's cloud to reach a Node-RED http in node. Also clearly the skill is running in the cloud so for a hubitat local and Node-RED local guy, I know I wouldn't want to be wholly dependent on a cloud solution (but at least for now that seems par for the course on any voice assistant). Finally, unlike Node-RED there is no easy way to export/import flows. (Once it is in Amazon, it is just code so that is sharable, but there is no code to GUI path as far as I can tell)
I will conclude this novella by saying that I had started down the path of building a set of routines in the Alexa app that just waited 5 seconds and then using the Alexa event node to see what was said and drive logic, but I soon figured out that I was going to need at least 100 different ones to cover the different phrases family members preferred, I also couldn't come up with how to handle brightness at all of the different levels from 1-99 without either 99 different routines or a virtual device for each group that was then exposed to Alexa to send commands to. I think anyone comfortable with Node-RED could be just as comfortable with this GUI and the range of possibilities and just as limitless.
Feel free to DM if you have questions that might either be hijacking this thread or are no relevant to out happy community of Node-RED/Hubitat users.
Here is what my under development flow looks like in the voiceflow.com GUI:
Zoom on the query block:
2 Likes
Works beautifully
1 Like
Very interesting, does it support native control over Alexa linked devices or is it really just an interface for making a voice interaction with alexa? I guess what I am asking is, great talking to alexa with these custom conversations, and I mean conversations due to the back and forth which is friken cool, but what endpoints can you actually touch or is it all revolved around HTTP requests?
IIRC, Alexa natively supports this with any device designated as a bulb or dimmer. I just expose my hubitat connected bulbs/dimmers/switches via the native Hubitat Alexa Skill and then use the native alexa commands to do this, no custom code required. Am I missing something?
Are you referring to Node-RED in this instance? Because I have noticed this too, but for my use case it was not too bad, I just had some switch nodes that sent the variety of input voice commands that effectively mean the same thing all into the same logic.
You are hitting some of the voice flow weaknesses exactly right. As far as I have been able to learn, you can’t have your custom skill directly control devices that are known by Alexa. Thus the need to use api request in voiceflow’s parlance to relay to Node-RED which can control devices.
Also, you are right that for things like “set the living room table lamp to 63”, the native capability in Alexa works fine. If this is your use case, then voiceflow is overkill. By using the combination of VF and NR I can do things like turn on the lights and get the lights in the room with the echo without specifying the room. I can also control any device regardless of native Alexa support. This is really helpful for me because while most of my devices are Hubitat based, I also have homebridge and zigbee2mqtt controlled devices.
Voiceflow is a lot like Node-RED. Most things can be done natively in Hubitat with built in apps, but once you get complicated or creative enough, NR makes those things much easier to build.
The one last major that I think I will be able to do, but that I haven’t figured out is shortening the initiation trigger. It supports “Alexa, open ”, but I want “Alexa ”. I have other skills on my echos that do this so I am guessing it will be doable.
This technically is natively supported and is why there is a categorization between plug and light comes from. Now recently this function has had some issues, which result in my recreating it in NR using remote2, but it is there. BTW, according to Alexa support which I spent 2+ hours talking to, they seem oblivious to this feature even existing, smh.
For anyone interested, the issue I had was that saying "Alexa, turn on/off lights", note the lack of a room called, would not only turn the lights on/off, so in my case it also turned my fireplace and TV on/off even those are plugs, which is obviously unacceptable. So I circumvented it entirely and do it all in NR, which gives me a bunch of control including multiple ways to trigger it in fancier ways.
I'll be honest and say I have not had a good look at VF, but you can do this in NR now with the alexa.remote2 palette.
You can set which echo device will listen to specific phrases and act accordingly..
Or am I completely missing the point?
2 Likes
I am new enough to VF to have found it easier to do what I want than NR alone. I hope I don’t run into roadblocks, but I think your feedback is a good warning to me and others that until you have a final implementation it is impossible to know if it will meet your needs.
So I can know what to look out for, can you give an example or two of issues you ran into?
On your question about missi e point, I don’t think you are. Both tools can get to he same place. I just am finding VF very good at building of interactions with lots of supposed phrases and extracting variables from within those inputs.
Here is an example that I could build in NR, but that would be harder than in VF. (Keep in mind this can be done by Alexa natively, but I am pulling this out of a larger interaction for this VF vs NR interaction):
Extract the desired brightness level from all these user phrases:
- Set brightness to 63
- Brightness 63
- I want brightness to be 63
- Level 63
- 63 level birightness
- 63 brightness
- Make level 63
VF let’s me enter these as something like this:
- Level
- level brightness
This results in my flow having a variable with the requested 63 in it. While I could build this in NR, I think the maintenance overhead of adapting to other family member’s phrasing will be less in VF.
All of that being said, I think the best approach is to use the best tool that works for you to do what you want. I just wanted to share this tool for those who will find it useful and didn’t know it existed. I found it a revelation for voice in the same way that Node-Red was a revelation for me relative to rule machine.
One last weakness I wanted to share about Voiceflow.. When I have had questions I have gotten responses from 1 person in their forum. Knowing and loving this forum and the equally active Node-Red forum, the Voiceflow one feels like a ghost town. The guy that responded however was very helpful.
I am definitely going to have to check this out. I can do some of the room-recognizing stuff with the alexa2-remote palette. I wish there was someway to trigger Alexa to start listening without having to say one of the wake works or to send the text of an Alexa Command in NR without having to say it out loud.
1 Like
I can't get into another cloud service that may or may not be here in a few years - it's just not worth it for my use-case. I guess I am one of those "local" people! 
But thanks for sharing, looks interesting!
2 Likes
