WebCoRE asks a question, my voice response determines the action

text-to-speech
answer
query
voice
alexa
#38

The value of this sim switch arrangement is that I might not be always turning all those lights on/off via the Christmas group. I might turn them on manually… if I do that, then the sim switch never gets flipped back to ‘on’. If it never gets flipped back to ‘on’, then ST would not know the command to turn them off came from Alexa. And therefore would never engage the ‘interactive’ questions.

Turning off the sim switch is the signal to Webcore to initiate the question.
It can’t do that if the switch is already off.

EDIT: I created the ‘AlexaSimSwitch’, and included it in all of my Alexa groups except music groups.
So now any time I ask for action on a group of devices, ST/Webcore can be flagged for a follow up.

#39

since we’re using Alexa for this piston is there any reason why we wouldn’t use the Alexa virtual device creator versus creating it device in the in the IDE?

#40

Feel free to try, but I won’t be able to troubleshoot that with you here. I have heard from multiple sources that creating Simulated Switches using third party apps is less than reliable.
(Thankfully, it only takes 2 minutes using the official IDE)

#41

Kinda a Tasker question but would I need a task for each “question” piston I set up? I’m familiar with Tasker but can’t wrap my mind around fitting it in with all this.
Also, would IFTTT work with this? If so, what are some possibilities?

#42

Tasker is good at regex and at handling passed variables, so you can do an awful lot in a single context - and even within a single task within a context.

It is IFTTT that is limited. That said, it’s also a terrific tool for those instances where you need it.

#43

No Tasker programming is required for these pistons whatsoever.

Personally, I use Tasker to speak my text outloud, (full details here) but there are other methods you can use to have text spoken outloud.

In other words, the only prerequisite is that you find someway to have webCoRE speak a question outloud. The two pistons here are basically building blocks, so when webCoRE asks a question, it waits for your answer, and continues with the piston based on your reply to Alexa.

If you follow along my steps above, when you import the two pistons into your SmartHome, you can change line 26 in the “My Question” piston to whatever method you use to speak text outloud. Obviously, you can beef this up a bit, but once you see it in action, it will click. I made it so it would be easy to add this to some of your current pistons and make it custom for your house.

IFTTT can work in any piston, so technically, yes. You could have a IFTTT recipe trigger when the waves are high (surf’s up!) and then webCoRE can ask a question outloud, and wait for your answer. Really, the possibilities are limitless.

To me, this is kind of the missing key, that can improve hundreds, if not thousands of pistons.

The beauty of it is, it only uses two SimSwitches, and one permanent piston (My Answer), no matter how many different questions you want to incorporate into your various pistons.

#44

I agree 100%.
I like IFTTT, but I only use it as a last resort when nothing else will work.

#46

Since I’ve finally learned how to use the FOLLOWEDBY command, could this be used to wait for a response instead of your timers? Just seems like it can take awhile for the YES or NO response to finally play.

I tried messing with that, but couldn’t get it to work correctly. I still don’t quite understand how your piston functions, so it’s difficult making such changes. Maybe I’ll try again this weekend.

#47

I don’t think followed by will work because one of the key elements to this double piston is that the two SimSwitches must remain conditions. If you make them triggers, then you would have to make new SimSwitches for each question. Bleh.

As a condition, you can answer hundreds of questions using the same two SimSwitches and the same phrase to Alexa.

This breakdown summarizes the “My Question” piston:

IF something happens       <-- Trigger
Then ask a question
Wait 15 seconds
    IF "Answer Yes" is on  <-- Condition
    Then do cool stuff
    END IF
    IF "Answer No" is on   <-- Condition
    Then do other stuff (or nothing)
    END IF
END IF

The other piston (My Answer) is there to simply reset each switch to it’s off position shortly after it is triggered. (to prepare itself for the next question)

#48

Oh, I get the question parts, it’s the timers. I was just trying to cut down on the wait time. The FOLLOWEDBY command has a built-in timer.

I’m not criticising your piston design. I’m just trying to reconcile your workflow with my (limited) understanding of Webcore. The Yes and No conditions (or even as global variables) could be set by the response in other ways.

Another question I have is, when you talk about it answering hundreds of questions, does that mean copying this into every piston that you want such a choice to be made, or using it as a separate piston that other pistons can refer to (carrying the responses over through global variables)?

See, I don’t understand why that can’t be done at the end of this piston. Why does it need to be a separate piston? That’s what I’m having trouble wrapping my head around. Like I said, I’m still exploring Webcore… In fact, I kinda wish it was more like BASIC, where I could use GOTOs and IF-THENs to lines, instead of having to create so many variables, so I’ve had to adjust my approach to creating my own pistons.

#49

I split them up into two mini pistons for a few reasons:

(1) If I combined these 2 pistons into one, it would add two new triggers and waits to pre-existing pistons. This has the potential to cause logic flow issues. (in other words, pistons currently working could potentially break) … But… by keeping “My Answer” separate as a “reset” piston, it should work with all types of pistons. (both old and new)

(2) The code in “My Answer” is used once. And only once. No matter how many questions you add at a later time. You just need the one piston. Think of it as the “clean-up” piston.

(3) The code in “My Question” piston can be inserted inside any piston, whenever you want a question prompt. It can use a current trigger, and then just continue with the couple lines of my code right after.

These are adjustable… in both pistons. Just keep in mind, the wait in “My Answer” must always be longer than the wait in “My Question”. During testing and real life use, my best results was when:

  • My Answer was 20-30 seconds (but no harm if you extend it to 60)
  • My Question was 12-15 seconds (I would not go below 10 in normal uses)

Personally, for rock solid reliability, I would keep “My Answer” to a 30 second reset. You can push it to 20, but why? This design is not set for a rapid fire list of questions, one after another.

2 questions per minute is the current limit, but you may be able to squeeze in 3 per minute if you lower the delay to 20 seconds. Just keep in mind if you choose that route, you will not be able to ask long questions without the switches resetting themselves.

As far as the timers in “My Question”… that can actually be adjusted on a per piston basis. So, for example, if you are asking a real short question (IE: Are you cold?), you could likely drop that 15 second timer all the way to 10 seconds.

This was the reason I found 12-15 seconds the most reliable in the most circumstances:

  • 1 sec for the speaker to begin
  • 6 sec for the question to be asked (although your question may be shorter)
  • 4 sec for our reply (Alexa Yes, or Alexa No)
  • 1 sec for the change to be recognized by SmartThings
  • 3 seconds for good measure.

Obviously, everyone’s environment is different, with different needs, and our speakers are likely not responding at the same rate, so feel free to tweak away! I made this public so you could all benefit from it, and incorporate it into your house. Make it personalized.

Just to make one thing clear:
If you drop the timers too low, you may have to scramble quickly to get a reply back into Alexa before it resets itself.

Some specifics:
I didn’t use globals in this, because pistons often do not see a change in globals until the piston completes, and then starts again.

I did not want to pass the data into another piston, because that would mean three pistons, and also the extra coding to send the command back. (My Question to Relay… Relay to My Question… My Answer to clean up)

The method I chose is streamlined… basically adding 4 lines of code to any piston.

  1. Ask a question
  2. Wait 12-15 seconds
  3. If Yes, then do stuff
  4. If No, then do stuff (or not)

Actually, I am leaving out the 4th line in many of my pistons. I can say “yes” if I want action, and ignore the question if I don’t. So yea, literally 3 lines of code per piston.

What more can you ask for?

#50

:+1:

Me too…

#51

If I follow this right you are saying you can have a virtual device trigger the question piston but would you need a separate virtual device and question piston for each type of question you set up?

Is there a way to have a global piston that just has Alexa wait for yes or no?

Ex. If motion just detected in Den ask questions #1.
If motion is detected in LR ask questions 2…

#52

You can have any normal trigger. Time of day, Garage door opens, Motion sensor changes to active, SimSwitch flips on/off etc. You just add this to the piston you want to ask a question:

IF something happens       <-- Trigger already existing in your piston
Then ask a question
Wait 15 seconds
    IF "Answer Yes" is on  <-- Condition, NOT a trigger
    Then do cool stuff
    END IF
    IF "Answer No" is on   <-- Condition, NOT a trigger
    Then do other stuff (or nothing)
    END IF
END IF

If you follow my method, all you need is two Simulated Switches, 1 copy of “My Answer” piston, and three lines of code added to any piston where you want to ask a question. This included hundreds of questions in hundreds of pistons. It is still the same requirements. 2 SimSwitches in total, 1 piston in total, and 3 lines of code per question.

Global variables will not work reliably with this.

This could definitely work. Just add a different question to the two pistons. (and don’t forget the 30 second cool down between questions)

#53

Did anyone ever figure out a way to determine which echo will ask the question depending on which one you’re talking to?

#54

My method on this page uses webCoRE to ask the question BEFORE you say a word to Alexa.
(So how would webCoRE know which speaker to use?)

Alternatively, there are many interesting options out there for Text-to-Speech (TTS). I am sure you can code some sort of logic to “guess” which room to play to… It sounds like it’d be worth digging thru some previous posts, or creating a new topic. I am sure you would get hundreds of views and opinions!

Personally, I use this method to speak outloud. I give up the ability of having it spoken on a particular device, but I gain the freedom of having absolutely NO restrictions when sending commands to my Echo. (any Alexa Skill or command that you can use your voice to activate, will work 100% with that method)

To be honest, if I had to choose, I definitely prefer having this freedom over restricting the voice to a specific device. I am using webCoRE to make Alexa do things that no third party app can do…

Sorry I cannot be of more help on that topic. I am very pleased with my text to speech, and think it will be quite some time before another method impresses me enough to switch over.

#55

From author of Ask Alexa…“There is a serial number that is identified by my lambda (and then passed to the app) to determine what speakers are being spoken to. So I have mine set up to say “turn on the lights in here” and it knows ‘in here’ as a cross reference to a room that is associated with the device. However, this is NOT passed to SmartThings in any way.”

#56

Well, to be honest, I was curious to see if there was a method of determining which echo was bring talked just for future reference. I also thought it would be nice if, having given a command to an echo that might require a later question/answer, it would be possible to send the question to the echo where the original command was sent. It wasn’t a big deal… Just wondering.

#57

It is likely possible with an alternative TTS in place…

Just keep in mind the method you are describing is:
Alexa > ST > webCoRE > 3rd Party App > Spoken Question > Alexa > ST > webCoRE

The method I am describing here is:
webCoRE > Spoken Question > Alexa > ST > webCoRE

(notice the last steps are the same)

My advice would be to get the core functionality up and running first, and then have fun with it.

I intentionally designed it simple so that things could be added to it later.

#58

I ran into one issue. I have this running a AnswerYes in my Den if motion is detected in my Den ask If I want to watch TV and is Yes it will run a harmony routine. The issue is each time i am close to the motion it asks.

I am trying to think of a elegant way to present the question from being asked over and over if people walk in while I am already ion that room.