bmercier

Hi Purdue, Thanks for the bug report, this is now fixed. Just an FYI, the Amazon API works all in Celcius. When you increase/decrease temperature, you can specify a delta. As an example: "Alexa, increase temperature for second floor by 2 degrees" So, the API has a delta parameter. However, when the delta is not specified in the spoken request, Amazon passes a value of 1 to the API by default. But 1 degree in celcius = 2 degrees F, which explains why you were seeing a variation of 2 degrees. So, I had to differentiate between a real request for a delta of 2 degrees which would be a request for a delta of 1.11 vs a default increase/decrease with no delta specified (1 passed to the API). Thanks, Benoit.

Hello Outlander, Thanks for the bug report. A fix has been deployed, can you try it again? I do not have an Insteon thermostat to test it, but I was able to pinpoint the issue and make a fix. Thanks, Benoit

Hi Michel, Xathros, That's a very good observation. I tried it myself, and Close was working, but open did not. My device was named "hallway". FYI, with smart home skills, we don't have control over the possible wording. I know "open" can be used to open a custom skill, so there is some competition over the possible use of this word, which may explain why it does not work. @Michel, I think we need to report this one to Amazon. Benoit.

For the purpose of clarification; "Smart home skill" is Amazon's new name for "Connected Home" "Custom skill" is Amazon's new name for what we called simply a "Skill", "ISY optimized for Smart Home" is the name of the original UDI Connected Home adapter. "ISY optimized for Smart Home V2" is the new Smart Home adapter using the new API that supports thermostat. It was planned that Amazon would make the original Smart home skill non-discoverable at the same time as the V2 became available, but they encountered a technical problem which is now resolved as of today. Benoit.

Hi Michael, Now that the V2 API supports thermostats, the older skill (those requiring "ask izzy") is more or less obsolete. It has a bit more functionality, but I doubt many people still use it due to the difficulty being understood. I mean, the skill supports locks, and in regards to thermostats, the control is more granular, you can get current temp, you can get the current setpoints, etc. But is there anyone using it? Benoit.

Hi Michael, This should be fixed now - Amazon told us today it is now removed. Benoit.

That would work in your current scenario. But what if it's 72 outside at the end of summer? You may never be able to reach the intended temperature of 75 if we change the cool setpoint instead of the heat setpoint. The way it is designed, when in Auto, it tries to reach the intended temperature ASAP. If you want to adjust only AC during summer, then it's probably best to just set the thermostat to A/C. Alexa will only change the cool setpoint. Benoit

Hi Michael, I traced your set temperature request in the logs. From what I see, the mode was indeed Auto, and it was left to Auto. Only the heat setpoint was changed to 75, which caused the thermostat to start heating. I believe you saw your thermostat indicating that it was now heating (as opposed to switching the mode to Heat, which is a different thing). Benoit.

FYI, here's the complete algorithm: A. Turn Off thermostat. That one is simple: I just set the mode to Off. B. Set temperature to X If mode is Heat: I set the heat setpoint to X If mode is Cool: I set the cool setpoint to X If mode is Auto - If current temp is above X, I set cool setpoint at X - else, I set heat setpoint to X If mode is Off - If current temp is above X, I set to cool at X - else, I set to heat at X C. Increase temperature by X If mode is Heat: Increase heat setpoint by X If mode is Cool: Increase cool setpoint by X If mode is Off: Set to heat at current temp plus X If mode is Auto - If current temp <= current heat setpoint: Increase heat setpoint by X - If current temp >= current cool setpoint: Increase cool setpoint by X - If current temp is between cool SP and heat SP: Increase heat setpoint by X D. Decrease temperature by X If mode is Heat: Decrease heat setpoint by X If mode is Cool: Decrease cool setpoint by X If mode is Off: I set to cool at current temp minus X If mode is Auto - If current temp <= current heat setpoint: Decrease heat setpoint by X - If current temp >= current cool setpoint: Decrease cool setpoint by X - If current temp is between cool SP and heat SP: Decrease cool setpoint by X Benoit.

Hello Michael, Are you sure the thermostat mode was initially set to Auto and was changed? It should not. When already in Auto mode, it should stay in Auto mode and only adjust one of the setpoint. The only situation where the mode is changed is when the thermostat mode is initially off and you request a temperature change; the mode will be set to heat or cool, depending on the target temp vs current temp. If in Auto, it should have set the heat setpoint to 75. If it was set to Off, then that would match what you saw. Benoit.

stu's, Not a problem, that will work. But once you have disabled the V1 skill on an echo, you can not re-enable it for that same echo. You can only enable V2 as V1 is now non-discoverable. Benoit.

Hi Smileyw, I saw the problem in the logs. Please PM me: - The brand/model of your thermostat - The output of: http://<your_isy_ip>/rest/nodes/2C%20B%2059%201 - What mode the thermostat was in when the request failed. For your information, the increment/decrement is based on information gathered from the thermostat. For example, if you want to "increase temperature", then the target temp will be the current mode's setpoint +1. On the other hand, if the mode was off, then the target temp will be based on the current temperature +1 (not current mode's setpoint +1). Please do not expect a quick resonse from me as I'm preparing to leave for vacations tonight. But when I return, the above information will help me find what's going on. This one looks like a bug. Thanks, Benoit.

Hello all, If you have a bug to report, in addition to a description to the problem, please add the following information in this thread: - What thermostat it is (Brand/model) - If the thermostat is set to Celcius or Fahrenheit - If the echo app is set to Metric or not (In the echo app, look for Settings / <user>'s echo / Metric measurements) - When you experienced the problem (date/time and your timezone) Please do not expect a quick response from me as I'm leaving tonight for vacations (I know, certification timing is not great). Thanks, Benoit.

I traced in the logs your requests relating to your kitchen shade (program 00AA), and all of them were successful. Now, it could be that Alexa did not understood properly, and the request was not sent to the server. FYI, open is not reliable to "open" a device. That word is also used to open a skill. When you say "Alexa, open verticals", if you hear a ding, it's an indication of a failure to open the skill named "vertical". Benoit

I confirm that a Open/TurnOn runs the then statement (not if).

Are you using CoHo for both programs, and devices/scenes? Please try to reuse a spoken that works on a device, and use it on a program. That should work. Yes, Open/TurnOn would runs then, close/TurnOff runs else. Benoit.

Alexa is not aware of the type of device. If you try the same exact spoken that you use successfully for scene and use it for a program, you should get the same results. Benoit.

Hi everyone, I looked into it, and it does work. However, it is very picky. First of all, for the purpose of clarification, we are speaking of CoHo (Connected Home) here, not the ISY skill. The ISY skill already works well with Open/Close. CoHo is another story. Alexa will route the open/close request to CoHo only if it clearly recognizes the "device" name. The "device" itself can of course be any "device" you have defined in ISY portal, be it a program, scene or regular device. When the Alexa request hits UDI servers, the request is always processed correctly, even for programs. The problem is that open/close can be used for other things than CoHo. For example, open can be used to invoke a skill. "Alexa, open ISY" will open the ISY skill. But as I mentioned, if it does recognize well the "device", it will be routed to CoHo. You can try this: In ISY portal, setup a program, and use "kitchen" as the spoken. "kitchen" is a very easy to understand spoken and it should be routed correctly to CoHo. More complex variations may not work as well as with a turn on/turn off. I have tested open/close and found it very picky. Perhaps too much to be really usable. But keep in mind we do not have control over this. If it's not routed to CoHo, we cannot help much. Benoit.

Hello Stu, We are speaking of 2 different things here. CoHo and Skill although they share a lot of in terms of functionnality use a completely different linking process that can be confusing. When you look in My Profile and see your amazon user profile, this is for CoHo only. When you edit your list of spokens, it checks if your user profile is linked for CoHo and Skill. The message tells you that the profile you are using has never been linked with an echo for use by a skill. To do account linking for a skill, you have to go on the echo app, find the skill, disable/re-enable it, and it will prompt you for a portal user profile. From now on, the message on portal will disappear (provided that you edit with the same user profile as the one you linked to). So in summary: CoHo Linking is initiated from portal, in my profile, and you have to enter your amazon account. (This is what you see under My Profile) Skill Linking is initiated from the skill, in the echo app, and you have to enter your portal user profile. (This can't be seen on portal, other that the message that you get) Please note that portal does not really know if a user profile is actually being linked to an amazon account for skill usage. It can only know that it has been linked at least once. If for example you go to the skill, enable it, and link to a portal user profile, then disable it, portal will not know it is not linked. The message will stop appearing, but it does not mean it is linked. When you unlink, Amazon does not tell portal. Hope that helps, Benoit.

Hi Stu, When you are in the echo app and want to link the skill, you get a portal login. You then login with a user profile which belongs to the sub-account. Is that correct? There are no error messages? Benoit.

Could it be a valid error this time, where there is really a spoken of that name? Please use the search to see if that spoken is already used or not. If it is not used, and it still does not work, please PM me your UUID along the spoken you are trying to use. Thanks, Benoit.

Hello All, There was a bug introduced yesterday which affected programs only, as rehills pointed out. This is now fixed. Benoit.

Multiple echo with different spoken for the same device is now supported. This is achieved by having 2 echos linked to 2 different Amazon accounts linked to 2 different portal user profiles in 2 different portal accounts (or sub-accounts), which each their own set of spokens. As of today, the same ISY can have a different set of spokens when it is registered in different accounts (or sub-accounts). In details, you need to: 1. Have your echos tied to 2 different amazon accounts. 2. In portal: - Create a sub-account - Add you ISY to this sub-account, and approve access to it in the admin console. - Create a user profile in this sub-account for the second echo - Link this user profile with your second echo's amazon account. - To edit spokens for your second echo, switch to your sub-account first - To edit spokens for your first echo, switch to your root account first Of course, you can have as many echo as you want, with each their own sub-account, user profile and set of spokens. Also, it is not required to have a primary echo in the primary account. All echos could be managed in sub-accounts only. For those of you who already had sub-accounts, you will start with the same spokens in each accounts/sub-accounts for all of your echos. When you add/edit/delete your spokens, the change will be applicable to that account only. Including the Delete all. NOTE: If your account selector is set to [All], you will see all of your ISYs, no matter which account/sub-account they belong to. When an ISY is in several account/sub-accounts, you will see it only once. When you edit your spokens, without explicitly choosing the account, you can't be sure of the context of which account you are working on. You should switch to the intended account first. Benoit.

No no, just this time. The only case where you may want to "forget devices" is if you remove spokens. Either if you remove a complete device with it's spokens, or if you remove some spokens on a device. In this case, they will be left in the list of devices. You may forget them individually, or forget all devices before doing a discovery. If you simply let's say change an alternate spoken to something else, it will keep the sequence number and it will be updated in the CoHo device list.

Devices imported through the discovery process gets assigned a device ID. Previously, the device ID was simply the address of the device/scene/program. Device IDs needs to be unique. Thefefore, with the introduction of the 5 spokens per devices feature, each devices IDs now have to have a sequence number. Bottom line, yes, there will be duplicates if they are not forgotten before.