bmercier

Ask Alexa: "Alexa, refresh my devices" This will refresh the change from ISY Portal to Echo. Benoit

Yes "Alexa scene" was a typo. I should have called it a Google scene. Google and Echo both have a device type named "scene". I call them an Alexa scene (or a Google scene in this case) to distinguish from an ISY scene. The only advantage, to my knowledge, is the ability to use a wording like "Ok google, activate <name>". Also, if you don't want the ISY scene to have a light, outlet or switch icon, then exposing it as a scene may be a good option. If your scenes are used primarily for lighting, then it's probably best to expose them as light. One of the drawbacks of exposing an ISY scene as a Google scene is that they can't be dimmed. FYI, the Echo skill already has all of that functionality. One of the goal of this update is to bring GH functionality at par with the Echo skill. Benoit

Hello everyone, We will have a maintenance this Sunday 12-24-2017 at 5:00 AM PDT which will last 1 hour. During this period, your ISY will be offline for a few seconds. Changes - Google Home: Color bulb support. - Google Home: Ability to expose scenes/devices/programs a Google scenes (in addition to light/switch/outlet) - Google Home: Ability to expose devices as Light, Switch or Outlet - Google Home: Preferred ISY is no longer required if there is only one ISY in the account. - Proxy bug fixes and additional logging - Subscription servers bug fixes and additional logging When adding color bulbs, you need to add the zwave color node (ZW999_186) Merry Christmas and Happy Holidays! Benoit

I made a fix on the 13th. I was trying to figure out if the issue started before, or after. If before, then it's good news. Benoit

When did it stop working? Sent from my iPhone using Tapatalk

I'm not seeing any approval request for a UUID ending with :67. I searched for the last 5 days. It looks like the request is not reaching ISY Portal. I would suggest to open a ticket, and please specify your UUID. I'm not sure what it could be. Michel will investigate. Thanks, Benoit

I believe the limit is 5 or so. Michel could confirm. Is your UUID ending with :90? I see 5 successful linkings, but somehow, some are like 3 seconds apart. Benoit

I believe you are hitting a limit on the number of approved accounts (or sub-accounts) in ISY. I investigated logs and reported the case. Benoit

It’s up to you. If they start getting a few support requests on that topic, maybe this will push them to investigate further. Sent from my iPhone using Tapatalk

The ISY Smart home skill V3 Sent from my iPhone using Tapatalk

Hello Everyone, I found a potential cause for this issue and made a fix. This is now in production. I also added additional oAuth logging, should the fix not solve the problem. Please report any other occurrence of this problem. Please PM me: - Your UUID - Specify at what time the problem started, and if possible, when was the last successful request. Feel free to fix it immediately by unlinking and relinking. Thanks for your help, Benoit

The reason for multiple devices is because somehow, Amazon is making a request for a previous skill version. They are doubled because the device unique IDs are generated differently. I have seen cases where Amazon keeps remnants of former skills. Here in the dev environment, whenever I do a discovery, I keep getting requests from Amazon that are from former test oAuth client IDs that belong to test skills that have long been disabled. I had reported that to Amazon, but this seems to be a complex issue. I would try this; Go to www.amazon.com, go to Your Account, and under Other accounts, click Login with Amazon. If using V3, you no longer need a consent for ISY Portal. Alternatively, you can go to ISY Portal, My Profile, and unlink from Amazon. If using V3, you no longer need that. Either way, that will block access for the V1 and V2 skill. FYI, V1 and V2 were using Amazon's oAuth "Login with Amazon". V3 is using our own oAuth server. Benoit

ISY is not aware of an action by Alexa vs other means. This is why I was proposing to use an intermediary (state var or program). However, if we are considering only lights, and you want to differentiate between physical action vs other means, then yes it’s possible. In your program, use ‘control’ instead of ‘status’. Control is triggered only by physically actions on the switch. Benoit Sent from my iPhone using Tapatalk

I would suggest to use state variables, or programs. If you want to use dimming, then use a state variable. You can expose it to Alexa as a light. Then a program can actually turn on/off the light or set the brightness level whenever the state variable changes. If you don't use dimming, then you could directly control a progran (On = then, Off = Else), and do whatever you want in it, including turning your device on or off. Benoit

Hello Everyone, Quick update, I have investigated Condor's log. It seems to point towards an oAuth2 authorization issue. When Condor's request failed at 13:24 EST, there is no request at all made to ISY portal. The last working request is a discovery, which runs every hour or so automatically, and that was at 5:43 EST I will need more time, but at least, I'm on something. Thanks! Benoit

Hi Mike, Can you either PM me or open a ticket and specify your UUID. I will investigate this. The details you posted will help greatly. Thanks, Benoit.

Hello everyone, After investigation, many errors are referring to non-existent spokens in ISY Portal. This case can happen when a spoken has been added in ISY Portal, then discovered by Echo, then later deleted from ISY Portal. If such a spoken still exists in echo, it will be marked as (offline). You can still try to use it, the request will be sent to ISY Portal, but an error will be sent to Echo. So, if you encounter that issue, please do the following in the echo app: 1 - Go to Settings / History, and look at the request understood by Alexa. Take note of the spoken. 2 - In Smart Home / Devices, lookup your spoken, see if it is marked offline. Please make a search to find out if you have more than one. If you Created a spoken "abc", discover, remove it from ISY portal, then re-create spoken "abc", then discover, you will end up with 2 spokens named "abc". One of them will necessarily be marked offline. If that happens, please forget that device. If you still have issues, please open a ticket and specify your uuid, and the date you tried it. ISY Portal has been updated an hour ago with additional logging to help troubleshoot this issue. If you already have a ticket opened, please reply to the ticket and let us know you still have the issue, and when you tried it. Thanks, Benoit

For now I would suggest to just keep live update disabled Sent from my iPhone using Tapatalk

If you change the mode, then setpoint, then again, that would be several events in a short period of time. Then the fan may come on. That's another event. Benoit

Then I may need to revise that logic. FYI Thermostat events are already debounced. If there are multiple events for the same thermostat within a short period of time (1 second), only one lookup will be done. I may need to increase that delay. Benoit

I can share some insights on this one. When you have both the V3 skill enabled and Live update enabled, then a "permanent" subscription is started. That subscription is the same as when the admin console is started, or when Mobilinc is used. This is used to capture the state of Alexa devices, and send it to Amazon so that it can be displayed on the mobile app. Whenever a light goes on or off for example, an event is sent, it is captured, and sent to Amazon. Now, for thermostat specifically, the logic is this. Whenever a thermostat event is received, a /rest/nodes/<thermostat address> is sent to get all of the thermostat properties. Amazon wants to receive all of the device properties, so this is the reason for this "lookup". Now the question becomes why are there so many requests? A thermostat property should not change that often. Benoit

Ok great, I was not aware of that. Benoit Sent from my iPhone using Tapatalk

To my knowledge, it's not possible to dynamically set the content of a network resource. If someone really wanted that, I guess you could configure 20-30 network resources with each a specific numeric value, 20-30 programs, and use a state var to trigger the corresponding network resource. But that's a lot of network resources and programs for the task. Benoit

I think in most cases, it’s easier to use fixed network resources to increase and decrease volume, and assign them to the volume up/down, and not use network state variables at all. Sent from my iPhone using Tapatalk

Thanks for the report. It’s now fixed in dev. Sent from my iPhone using Tapatalk