I do wonder how spud's easytrigger would know about this change, however. If homeseer is not generating an event based on the json setdeviceproperty request, he would have to be actively checking for changed values in some sort of loop, wouldn't he? I'll pose the question in the easytrigger forum.
Announcement
Collapse
No announcement yet.
HELP: IFTTT Feature Request
Collapse
X
-
There may be another property you need to set to ensure it triggers an event, but I am sure its doable, will check tomorrow and post the JSON.
Originally posted by baudi View PostUnless setting the string property generates an event, it doesn't really matter whether we can set it or not. Setting it would be just as ineffective as setting UserNote.
What we're trying to do is get an arbitrary string into homeseer and have homeseer trigger an event based on that action. Based on one JSON request. So that a script can process that string and take action based on its contents.
Homeseer appears to defend itself against this very effectively.
If you have an alternative method for doing that, please let us know.
Comment
-
Plugins can register with HS for string changes on devices, so he only gets called when a change actually happens. The JSON will change the string just any other action changes the string, so it will trigger events.
Originally posted by baudi View PostI do wonder how spud's easytrigger would know about this change, however. If homeseer is not generating an event based on the json setdeviceproperty request, he would have to be actively checking for changed values in some sort of loop, wouldn't he? I'll pose the question in the easytrigger forum.
Comment
-
Originally posted by baudi View PostIt would be great if HS could match a voice command based on the beginning of the command. For example, suppose I want to do various things when the voice command starts with "lights". I already have a script that runs when "lights" is recognized. It toggles the lights on/off in the room where motion was last seen (and, maybe in the future, based on which google home unit heard the command).
Now what would be great would be to have that same script run whenever "lights" is recognized at the beginning of any command. Then the script would figure out what to do based on the rest of the command. "Lights up" would brighten the lights in the room, etc.
That would eliminate the need for a multitude of events that would be needed without this capability.
Comment
-
Originally posted by tpchristian View PostWell, I read through this message above and took, at least, a couple minutes to read through a what Jon put together a bit more. What I don't understand, Baudi, is what exactly you are trying to achieve. Are you try to bypass the built-in voice command processing and basically write your own? If I understand that correctly, is the main reason to make it location aware. I do like your idea of using motion detection -- I hadn't thought of that and was thinking I may need to wait for Home to send along the device name.
So the idea is that certain commands would just be passed through to the voice command processor, but others, depending on the presence of keywords, or absence of a room keyword (for example), would be handled differently -- made location-aware, time-aware, and so forth.
Comment
-
Makes sense -- I get it. I understand that you are trying to find a way to work this into the system as it is today. What it leads me to think, however, is that it would be nice to have a generic hook into the built-in voice processing.
I think it is probably still there, but there was a way to hook into the speech output and you are looking for hook into the speech input.
It might be worth pursuing that idea with Rich as well as trying to work out how you can do it as it is today. What do you think?
It is also interesting to think about a different engine for the voice processing. For instance, using something like api.ai that is one of the methods used by the new Home conversation API.
https://api.ai/
Comment
-
Originally posted by tpchristian View PostIt is also interesting to think about a different engine for the voice processing. For instance, using something like api.ai that is one of the methods used by the new Home conversation API.
I think this means that if we're going to use Google Home, we're going to have to use the api.ai. And if we want to develop a conversation API for HS, we'll have to have hardware to support it. Maybe something like the Conexant far field arrays.
Anyway, that seems like a much longer term project than what we're interested in at the moment.
Comment
-
If you want to handle the VR yourself, you can do this with a script.
Create a script named "check_vcmd.vb" and put it in the scripts folder. Whenever a voice command is given (from any source, including a mic or the Echo), your script will be called and the voice command passed. If you return an empty string, HS will continue to parse the command normally. If you return a non-empty string, parsing will stop at your script. Here is a sample script:
Code:Function Main(parm as object) hs.writelog("VCMD","Starting") hs.writelog("VCMD","Phrase: " & parm) return "I handled this in a script" End Function
Originally posted by baudi View PostI'm not sure about the api.ai approach for a new conversation API. It seems to me that the limiting factor for HS conversation is the hardware needed in each room. You can't have a conversation without a mic and speaker. That's of course what Google Home provides, but it doesn't provide any mechanism for a local computer running homeseer to take input from its mic or send output to its speakers.
I think this means that if we're going to use Google Home, we're going to have to use the api.ai. And if we want to develop a conversation API for HS, we'll have to have hardware to support it. Maybe something like the Conexant far field arrays.
Anyway, that seems like a much longer term project than what we're interested in at the moment.
Comment
-
Rich,
I wrote a Echo helper script using this method, however the script check_vcmd.vb is not functioning on Linux builds. Any chance this can be fixed?
Comment
-
Thank you! It works. Now if we can just get a voice command from IFTTT into HS, this is solved.
To that end, I set up an IFTTT Google Home => Maker applet, with the following Maker URL
Code:https://connected2.homeseer.com/JSON?user=MYEMAIL&pass=MYPASSWORD&request=voicecommand&phrase={{TextField}}
Code:Function Main(parm as object) hs.writelog("VCMD","Phrase: " & parm) try Dim webClient As New System.Net.WebClient Dim result As String = webClient.DownloadString("http://localhost/JSON?request=voicecommand&phrase=living room " & parm) hs.writelog("VCMD",result) catch ex as Exception hs.WriteLog("VCMD", ex.message) end try return "stop" End Function
Any idea how to fix this?
It would of course be better if we could do it through the MyHS IFTTT service instead of the Maker service.
Comment
-
Originally posted by jon00 View PostI wrote a Echo helper script using this method, however the script check_vcmd.vb is not functioning on Linux builds. Any chance this can be fixed?
Can this be made to work with Google Home, or is it only for Alexa?
Comment
-
[UPDATE 1-14-19] To trigger on a string change with an event you need to use the API call hs.SetDeviceString(...), otherwise the event will not trigger. Setting the properties overrides the triggering.
+++++++++++++++++++++++++++++++++++++++++++++++
There was some protection on the properties, I have put in a fix in build 304 which is posted here:
http://forums.homeseer.com/showthread.php?t=181241
To set them and trigger events, do this:
Code:http://IP/JSON?request=setdeviceproperty&ref=####&property=NewDevString&value=STRING_VALUE http://IP/JSON?request=setdeviceproperty&ref=####&property=ChangedValueORString&value=TRUE
Originally posted by baudi View PostIt occurred to me that the easy way to get an arbitrary string into HS would be to set a virtual device's string property to that string. However, that doesn't seem to be possible. Here's what I found.
According to the help file, the json setdeviceproperty request is:
/JSON?request=setdeviceproperty&property=NAME&value=VALUE
That's incorrect. The request is actually:
/JSON?request=setdeviceproperty&ref=####&property=NAME&value= VALUE
Also, according to Rich, the NAME param for the string property is HSdevString. Trying to set that property (or HS.devString or devString or String) returns { "Response":"ok" } but does not actually set the property.
The only properties I was able to change using this technique were UserNote, Name, Location, and Location2 (spelled and capitalized exactly as shown). The devString property is shown as read only here. That seems to be the case.
So does this help? I don't think so. A change to the value of any of the settable properties does not seem to generate any event of any kind. Nothing appears in the log, and even the TenScripting "Homeseer Events" log doesn't show any activity. I don't think we can trigger a script based on a change to any of those properties.
So the documentation is incomplete and wrong, and Rich's statement is wrong.Last edited by Rupp; January 16, 2019, 05:45 PM.
Comment
-
Linux had the wrong path, its fixed in the latest beta (304) posted here:
http://forums.homeseer.com/showthread.php?t=181241
Originally posted by jon00 View PostRich,
I wrote a Echo helper script using this method, however the script check_vcmd.vb is not functioning on Linux builds. Any chance this can be fixed?
Comment
-
Originally posted by rjh View PostThere was some protection on the properties, I have put in a fix in build 304 which is posted here:
http://forums.homeseer.com/showthread.php?t=181241
To set them and trigger events, do this:
Code:http://IP/JSON?request=setdeviceproperty&ref=####&property=NewDevString&value=STRING_VALUE http://IP/JSON?request=setdeviceproperty&ref=####&property=ChangedValueORString&value=TRUE
Comment
Comment