barrygordon

No, Have had the same thought and have not yet discovered an answer. The fact that a family name of thermostat is surprising seems to do what it does is surprising. What about things like Master Thermostat, Guest Thermostat, or variants for more than one thermostat

I just ran my own test use the emulator Debugger capability. I set up a new device for the echo called thermostat. The onURL is set to the following: http:/userid:password@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/${intensity.percent} The device at 20 93 5 1 is an insteon dimmer/switch which controls my office ceiling lights. The debugging output verifies that when using the following phrase to Alexa: Alexa Set the thermostat to xx where xx is a number, the command sent to the isy has exactly the nunber I spoke. I tried the following numbers 71, 75, 77, 53, 82, 27, 94 The Debug log from the emulator had the following entries among others: ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.91 body: {"on": true,"bri":181} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/71HTTP/1.1 ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.90 body: {"on": true,"bri":191} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/75HTTP/1.1 ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.91 body: {"on": true,"bri":196} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/77HTTP/1.1 ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.90 body: {"on": true,"bri":135} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/53HTTP/1.1 ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.91 body: {"on": true,"bri":209} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/82HTTP/1.1 ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.90 body: {"on": true,"bri":68} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/27HTTP/1.1 ... hue state change requested: cUQ6FpY9yemZY7OTVn3HPRaGeTy629GKLAdSXWCe from 192.168.1.91 body: {"on": true,"bri":239} ... Making outbound call in doHttpRequest: GET http://admin:admin@192.168.1.229:80/rest/nodes/20%2093%205%201/cmd/DON/94HTTP/1.1 The above matches up perfectly with the spoken phrases and the office lights dimmed to the correct values. I am waiting to hear from the author of the emulator if he can make the change to add a math capability in the ${} expression

I am 99% sure that it is Amazon that sends the incorrect (adjusted) value. The emulator handles the scaling of the value as a byte (0-255) or as a percent (0-100). I was told by an Amazon Echo specialist that the Echo always adjusted brightness in multiples of 10. I have also seen the code in hue emulator that sets the value onto the onURL or offURL prior to sending it. On the Git hub where BWS stores the emulator (Google "bwssystems git") are instructions. The last, IIRC, instruction is how to turn on debugging. Turn it on. The log file will then show what was received from the Echo and what was sent to the end point. There will be a lot of information in the log file, but it is just a text file. Try Searching for something that looks like "bri": The quotes are in the string since it is a JSON value of the form {"on":false|true, "bri":xx} where xx is the value the echo sends. The next line IIRC is what is sent to the endpoint. In JSON a property name (the part before the colon) is always quoted, while the value (the part after the colon) is also quoted unless it is literal such as true, false or a number. The curly braces delineate a JSON object. Try speaking a lot of different values perhaps in a brightness phrase then look at the log and see what it says.

If you change the on and off URL's that the emulator sends in response to an on or off command you can send any sequence you want. The Echo, when hearing a number in what it thinks is a phrase to set a lights intensity value (brightness), will not send the number itself but the nearest multiple of 5 (or 10) to that number. This makes it unsuitable to use for setting a thermostat. If you write your own skill you can send any number you want but in your own skill you have to map out all the phrase's (Utterances) that Alexa will understand, that, I believe includes one for each number. I don't see how that is going to help you. What do you believe the REST command should be when sending the 999 or -999 to the ISY?

I can see why they did that when interpreting the spoken phrase. When I get around to working on my "Alexa skill" I will probably have the code subscribe to the ISY so you can say things like up/down or warmer/cooler. That would work if the current temperature were known, hence the subscribe, and Alexa would then speak the current setpoint.

BlueMan2, I indicated to the Author that perhaps he should make it more general allowing an arbitrary math expression to act on the value. Something like ${intensity.math(<some math expression>)} or ${math.<some math expression>} . It should not be a lot of code. As an example /CLISPC/${math.(2*X)} where X is taken as what ever Echo passes as the spoken word PS Did you mean Set 'Thermostat - Mail' Cool Setpoint '$Air_Conditioner Degrees' as opposed to Set 'Thermostat - Mail' Coll Setpoing '$Air_Conditioner Degrees' ??????

I have sent a request to BWS the Author of the emulator to see if he will make a change, ideally to allow math on the value spoken, or allow for ${intensity.temperature} which will send the ISY 2 times the value spoken.

Just looking at the error suggests that you should be at administrator level. Try running the mapper program as admin (right click the exe and select run as administrator). No program should put operational data into the system32 directory but rather into a directory related to itself or to the user. I have written a different program that works with the newer version of the Hue Emulator as developed by BWS Systems. You can find a lot of information regarding the BWS Hue Emulator and my configuration program (AWS_CONFIG) in this thread

While I know a great deal about the ISY I know nothing about the Harmony Hub. I would be more than willing to modify the AWS_Config to be Harmony savvy but would need a Harmony unit to test with. Can someone point me to information on the Harmony unit? I am fairly familiar with the Hue Emulator but will need to look at what BWS systems has done for the Harmony unit. I just took a look at what BSW published on the GIT. It seems that the REST server for the Harmony does all that is needed or am I missing something not being familiar with the Harmony Architecture. As an alternative I would need a Userid and Password to an active account at harmonyhub.com, and some one willing to work with me that has a Harmony Hub. I can write a quick Harmony-Emulator to show me what is sent to the Harmony Hub by the echo. Also helpful would be if whoever has a harmony hub could use Wireshark or Etherdetect to capture things that might be being sent to the hub so I have an idea what is correct. As I said I have no knowledge pertaining to the Harmony Hub so It will be a bit of learning in the beginning.

I just posted a new version of my Configuration program. This should fix the "Error 13 Type Mismatch". See the changed ini file which is in the package (CAB file). When sending a log file for me to look at because of a problem please ensure that the program was run with an ini file that had the line "Debug = All ISY DVC" (without the quotes). Also include a copy of the ini file you used when you ran the program instance that caused the problem. There is a change in the ini file. Your ini file should have the line that says "Zwave = 4" changed to "Irrigation = 4" (Without the quotes). With regard to the ini file I suggest the following: [Note, to comment out a line place a single quote in the first position] Unless you have your scenes in folders and you only wish to process certain folders remove the line "Scene Filters = ..." otherwise change the value to the names of the folders you wish to process The default value for "Show Scene Folders" is false so the line can be removed, especially if your scenes are not in folders. The "Location" is only needed if you want to specify the Location of the ISY and not have a uPnP search take place to find it\ If you are not using custom endpoints (endpoints other than the ISY) then the [Custom Endpoints] section can be removed and any lines in that section The Debug line is not necessary unless I request it to find an error. If I ask you to provide a log file, then the debug line should be "Debug = All ISY DVC" (without quotes) In the [Device Types] section set the name of type 4 to "Irrigation". The line should read "Irrigation = 4" (without the quotes) and not "Zwave = 4" (without quotes). PLEASE read the documentation on the ini file in the Word doc. I would like to hear back from any who were experiencing the Type 13 error, type mismatch to know if this new version resolved the issue.

Smileyw, I just received an email from the forum regarding a problem you are having with the configuration system. The post referred to in the email does not seem to be here. I sent you a private message as a reply. When sending me requests for help with the configuration system Please try and send 4 things: 1 - The version number of the AWS_Application and the version number of the HUE Emulator 2 - The log file AWS_Alexa.log from the same directory as the program. 3 - The ini file AWS-Config.ini from the same directory as the program. 4 - A screen capture of the screen when it fails with any error message moved to not cover the information. These can be 4 separate attachments or zipped into a single archive.

Thanks for the kind words. I do what I do because I really enjoy doing it. I like building things, any sort of things and solving puzzles. I sometimes think I subconsciously introduce minor errors so I can hunt for them later.

If you do the following I will be glad to look at the problem: Make sure the ini file has "Debug=All ISY DVC" in the system section, without the quotes. Run the system until it fails. Send me the following: The log file AWS_Alexa.log; The ini file, A statement as to the version of AWS_Config that is running (e.g. 2.0.19); If possible a screen capture of the screen when the error occurs. Information about the version of the HUE Emulator you are using. Exactly what you were doing when it failed. e.g. clicked on something after . . . I thought I had cleaned all the type mismatch errors, but I might have missed one. The program is a little sensitive to how your ISY is setup and the logfile plus the ini file should help me see where the problem is. Email the information to me at barry@the-gordons.net. If it works after repeated tries that generally indicates some sort of networking problem. When it fails it should fail consistently if you are not changing anything.

With the HUE emulator hub You can do just about the same things as with Insteon HUB, but using the ISY994. I even talk to Homeseer through that Emulator but only for very limited things as Homeseer does very little any more in my home. It is all detailed in this somewhat lengthy thread.

There are two places to look. bwssystems.com and the Mi Casa Verde site/forum. The Hue emulator was originally developed for the Mi Casa Verde platform. The owner of BWS Systems is the developer of the current systems and I know he has been trying to clean up any issues with the Harmony systems. My focus has strictly been on the ISY994 and other systems I own. When I develop software and tools I develop for myself and then share. I am willing to expand any thing I develop to handle more cases. The biggest issue is having equipment to test with I have no Harmony Gear I have no Mi Casa Verde gear. I have no Philips HUE hub. I don't like giving out software, even for free, that I cannot properly test . I wrote the configuration system aimed strictly at ISY994 users. It reads all the configuration data from the ISY so it can provide a pretty clean typing-free experience. It handles non-ISY end points in a limited manner. I use that capability to deal with an Autelis pool control and my Home Theater. To do so requires one to write their own end point. The HUE bridge and hence its emulators, were designed to control lights. On, Off, Dim. With the ISY994 as the endpoint devices can be turned on, off and set to specific brightness level. Scenes can be turned on or off, Scene brightness can not be controlled and that is an ISY issue. You can have different named scenes controlling different brightness of coordinated devices, or as I do in my home controlling fan motors to their 4 possible settings of Off, Low, Medium, and High. The phrases the Echo understands are quite limited unless you write your own "Skill" to control the Echo, and that introduces, IMHO, an extra layer of Cumbersome speech. The ones I use start with Alexa, Turn On ..., Alexa, Turn Off ..., Alexa, Shut ... Alexa, Set Brightness to ... I am getting way over 90% recognition and my home is not ideal in that it has a high reverb factor; lots of hard surfaces, Big spaces, and Little natural audio absorption.

I have just posted 2.0.19 if the configuration system. It has mostly changes relating to ISY controlled Z-Wave devices. The ini, exe and docx files have been Changed. The word document has been significantly revised to provide a lot more information relating to Z-Wave devices and how the Echo>Emulator>ISY994 system communicates and the role of the Configuration system in all this. I strongly suggest that you read the documentation.

Tungsten, I have done that but when you forget all devices on the Echo it forgets the group. I have put in a request to Amazon to separate deleting devices and deleting groups. The configuration tool has been updated to build 2.0.7. This build has changes to the ini file and updated documentation (word doc). Scenes no longer have to be in folders so a Scene filter entry is not required. Zwave devices are handled. If the device type in the ini file has the word "Dimmer" in it's name the device is considered dimmable and the onURL will accept a brightness value from the Echo. In all other ZWave device cases the device is treated is an On/Off switch for purposes of generating the URL Rest command to send to the ISY. The configuration tool merely sets up the values for the HUE emulator. The Hue Emulator is limited by what the Philips bridge can do. Requests for changes to the HUE Emulator should be addressed to bwssystems.com.

Thanks for the replies. You have confirmed my understanding. LeeG, I don't see why the Scene needs a p[lace holder for the Scene's on level. Why not just accept a DON/value and set the brightness (OL) of each member of the scene that is dimmable to that current level?

Running the emulators on an RPI makes for an easy relatively inexpensive always on solution. A small ups to keep the RPi's powered should also be inexpensive. A 6 volt storage battery with a little zenner diode to produce 5.2 volts and a cheap trickle charger should do it for a bank of RPi's. I am not sure how fussy the RPi is regarding its voltage but I am sure 5.2 is fine as that is what most 5 volt supplies produce anyways . What I developed replaces 'Mapper' not the emulators. It only has to be run when you want to change the configured devices for the emulators. The actual database of each emulator is kept as a file on the RPi.

But we have that today. All my lights and scenes respond to Alexa On / Off commands and my lights will dim to specific brightness levels on command. Alexa needs some more phrasing attention since she (echo) sometimes misunderstands what is being said, and she is very particular. If UDI had a command for scenes similar to the way they handle lights (/cmd/DON/level) the dimming of scenes would be trivial. I know of no way to set a scene to a specific brightness level, can someone help me there?. I can do it with a program that sets the scene to a specific level, but not with an argument that tells it the level.

In the ini file you need to tell me the the names of your scene folders using the command 'scene filters = name, name, name'. It should then show you the scenes from those folders. The scenes I want the echo to be cognizant of I keep in a folder named zScenes-Echo and zScenes-Fans. The z is there to cause all my scenes to came after my devices. it is stripped when I display the scene folders if requested by the 'Show Scene Folder' command. I guess I need to add an option 'All"' to not filter the scenes and allow the command to be removed, if you do not want to filter the scenes or you do not keep your scenes in folders. Next up date will probably have that. The command you provided works sporadically for me, while Alexa, Set brightness to xx percent on <light name>' works best for me. Perhaps different reverberation environments affect Alexa's speech recognition. My house has a long reverb time so it is a little echo-ey.

The only phrase that seems to work reliably for me is: Alexa, Set brightness to xx% on <device friendly name> as in : Alexa set tbrightness to 50% on test lights

What version is your echo software. Mine is 2723 The only way I can get lights to dim to a set value is the phrase 'Alexa set brightness to xx% on <NameOfLlights>' Sine the URL I use only has /DON/value, I can not understand how you get the Echo to respond to a DIM with no fixed value command unless you have changed the URL to DIM or BRT from /DON/${intensity.byte} to /DIM or /BRT. If I do that then it will probably work, but the dimming takes place very slowly. TIP: You can click on a device in the HUE devices pane to cause that device to load into the editor. You can then alter the onURL or the OffURL to be anything that is legal for the ISY and use the 'Test On' and 'Test Off' buttons to send the URL to the ISY to see what happens. Just don't do an Update unless you want to make a permanent change.

I have a scene with two members. one is an insteon dimmer switch and the other is an insteon keypad button. I can manually dim the scene to dim from the Admin console by using the dim button. Is there a rest command I can send to set the scene to a specific brightness? If so please show me the format as in /rest/node/<sceneID>/DON/128. I know that /rest/node/<sceneID>/DIM will dim it every time it is sent, but I am looking for a way that would set the intensity level to a specific value as in dealing with a plain dimmer switch.

Blueman2, All the commands for scenes should use cmd not set. All mine show as CMD. SET was a holdover from an earlier version and was in error. You can do an update for those scenes that say set after changing the command in the URL's to be CMD. Scenes do not seem to be working. That will be tomorrows task.