Amazon Echo - Connected Home Feature!

[bmercier]

I thought you had to go to the portal to add the devices so the echo can see them?

 

 

Sent from my iPhone using Tapatalk

 

Yes, that's the only way.

[KMan]

All of a sudden the Echo responds to all spoken CoHo commands with "Sorry the device <device name> is not responding.  Please check its network connection and power supply".

I had the same symptoms for a short time when I was first switching from the emulator to the connected home. I don't remember doing anything specifically that made it clear up (it lasted less than a day for me). I know that I cycled power to the echo, ISY and PLM ... but I don't really think that had anything to do with clearing it up.

[barrygordon]

When I go to tools and select the amazon echo it tells me the ISY is not on line which sounds logical. 

In the ISY console under configuration/portals it states that it is off line

 

The CoHo skill has been working fine since it became authorized (weeks ago) up to today. It was working at 10AM, but not later in the day. Still not working but at least I think we know why.

 

Now why is it off line and what do I need to do get it back on line?

 

 

 

PS thanks for the quick response.

Edited February 8, 2016 by barrygordon

[bmercier]

When I go to tools and select the amazon echo it tells me the ISY is not on line which sounds logical. 

In the ISY console under configuration/portals it states that it is off line

 

The CoHo skill has been working fine since it became authorized (weeks ago) up to today. It was working at 10AM, but not later in the day. Still not working but at least I think we know why.

 

Now why is it off line and what do I need to do get it back on line?

 

 

 

PS thanks for the quick response.

 

I looked up in the logs.

 

For some reason, I see it dropping off and trying to reconnect around 12:35 EST. But then, on the /rest/whoami request (portal requests that to know who is connecting), there is a timeout. ISY does not respond. It has not tried to connect.

 

Could you reboot the ISY?

 

Benoit.

[barrygordon]

The reboot of the ISY fixed the problem, All is working normally with regard to the Echo

 

About the time you mention I was working on a new program for the RPi using Windows 10 Visual Studio 2015. The program was running on my Windows development system not the RPi. The program does interrogate the ISY to get the configuration of variables, but I never saw anything very unusual. It then updates a set of 6 State variables every 30 seconds with temperatures read from one-wire sensors in each room of my home. Eventually I will cut the update cycle back to once a minute.  The program will eventually (when it is on the RPi) go to my grandson to control floor vents using Insteon micro-modules and the ISY.

 

I can not think of any reason why the access using REST requests would ever drive the ISY off line from the portal. I did have some issues and had to change the program logic.  It seems that in ISY v4.2.36 when a REST Request completed sending a response to the requester it closed the socket. I used the socket close to signal completion of the reply and begin processing.  ISY v5.0.2 does not seem to close the socket.  The request does have  a header entry for "close connection".  I posted this issue on a version 5 thread and am waiting for some response.

 

Now that I know that a reboot fixes the off line issue I will not have to ask again.

 

Thanks for the help

[Michel Kohanim]

Hi barrygordon,

 

You are using 5.0.2, correct? Can you please take a look at your error logs?

 

Also, if you are using MobiLinc, I know it does not close sockets and keeps opening sockets and in 4.4.2 (and above) we are now actively looking for open sockets that have no activity and close them (it will eventually exhaust all ISY sockets and buffers). Unfortunately 5.0.2 does not have the fix that we included in 4.4.2.

 

With kind regards,

Michel

[barrygordon]

Yes I am running 5.0.2.  I am not using MobiLinc.  I have my own program that I am developing as I am quite familiar with the ISY TCP command/response structure (mostly REST). I really do not want to revert back to 4.3.26 as I can work around it in my code for 5.0.2.  The configuration program I wrote for the HUE Emulator showed me the problem when it started timing out waiting for a reply to a configuration request with v5.0.2. I am working on some other programs that pull ISY configuration data and really liked the fact that the ISY closed the socket when a reply was completed.

 

I will run some test later today and see if there are any error logs.

[barrygordon]

Beniot, Michel,

 

re ISY going off line to the Portal:

 

Now that I know that a reboot fixes the off line issue I will not have to ask again. Perhaps the Configuration/Portal screen needs a way to get the ISY back on line to the portal without a reboot.

 

Barry

[Jamison_IO]

I have the portal and Echo running (so slick). Now, if I want to add Mobilinc, which I have not yet purchased. What steps do I need to take in order to get it working properly?

 

 

Sent from my iPhone using Tapatalk

[jerlands]

I have the portal and Echo running (so slick). Now, if I want to add Mobilinc, which I have not yet purchased. What steps do I need to take in order to get it working properly?

 

 

Sent from my iPhone using Tapatalk

 

To configure Mobilinc use these setting...

 

Host Type = ISY

User Name = Portal Username (email address)

Password = Portal Login Password

Local http://= blank

Local Port = 80

Secure https:// = my.isy.io

Secure Port = 443

Connection Method = Secure Connection

 

 

Jon...

[Michel Kohanim]

Hi Barry,

 

ISY retries connecting to the portal every time it gets disconnected automatically. I think what you are experiencing is due to 5.0.2 (which does not have the fix for sockets that are left open).

 

With kind regards,

Michel

[Xathros]

Hi Barry,

 

ISY retries connecting to the portal every time it gets disconnected automatically. I think what you are experiencing is due to 5.0.2 (which does not have the fix for sockets that are left open).

 

With kind regards,

Michel

Any idea when 5.0.3 will roll out?  As a regular user of Mobilinc, this fix will be most welcome on my ISY.

 

-Xathros

[barrygordon]

Michel,  I agree that would explain the ISY dropping offline and never reconnecting to the portal.  I assume that a fix for 5.0.2 will be forthcoming, although if it is going to be a while then perhaps I will revert to 4.3.26 but I first want to help you  track down the lack of a session close after a reply. I am holding off on millinc till the reconnect gets fixed.

 

Barry 

[Michel Kohanim]

Hi Barry,

 

Please go to 4.4.3 (which has a fix for clients that do NOT close socket and ISY waits 12 minutes before closing them).

 

With kind regards,

Michel

[barrygordon]

I will try that, but I am a little confused.

 

Why the wait for 12 minutes? An ISY "service" (e.g. a REST request) receives a request. The ISY service should then reply to the request and wait a short time (100 milliseconds or after the "send complete" event fires), close the connection and listen for the next request from any client.  In the case of a connection to the Portal where the ISY is acting more as the client, if that connection drops putting the ISY Offline relative to the portal it should be restarted as soon as practical.

 

All my requests to the ISY are GET /rest/. . .  except for the very first one which is a SOAP request to get the ISY description information, and a request to subscribe to events if my program chooses to do that. AFAIK the subscribe to events is the only request that needs the data from the ISY description.t

[Michel Kohanim]

Hi barrygordon,

 

The reason is TCP State Flow diagram. Even if ISY closes the socket, it goes into a close-wait state waiting the client close. So, if your app does not close the socket, ISY will have to stay in that state for that socket for approximately 6-12 minutes as per TCP specs. So, in 4.4.3, we now actively look for sockets that are in this state for more than 1 minute (from the last packet) and release all their resources regardless of the last-ack.

 

You might want to check your code and make sure it DOES respond to close-notify from ISY and sends a Last Ack/FIN.

 

With kind regards,

Michel

[barrygordon]

Hi Michel,

 

I actually check the socket state at the end of each data arrival at the socket.  I look for the state "Peer closing socket"  At which time I do close the socket.

 

It is working this way in both 4.3.26 and 4.4.3.  I am currently running on 4.4.3 and all is running well.  It is not working on 5.0.2 as I never see the state "Peer is closing socket" in Windows Winsock this is a state of 8

 

Thanks for the suggestion to try 4.4.3.

 

I believe you may have an issue in 5.0.2 though.

 

Barry

[Mastermog2]

Any ideas why the ISY Portal and Amazon Echo was working fine and then started responding that commands like on/off were not available for my devices.,   I try to delete and setup the link to the ISY again but now I can't get the ISY to show up under Connected Home again.  The ISY Portal profile shows that it is linked to my amazon account but when I go to the Alexa application ISY doesn't show up.

[hmatos]

Same issue here, it started last night (i'm guessing portal maintenance?).  I tried a forget all devices and a discover -- alexa can no longer find any of my ISY connected devices.

 

I opened a support request.

Edited February 11, 2016 by hmatos

[Michel Kohanim]

Hello everyone,

 

http://forum.universal-devices.com/topic/18145-isy-portal-maintenance-02-10-2016/

 

With kind regards,

Michel

[barrygordon]

I have noted a significant improvement in response time between when I finish speaking and the action takes place.  Good Job!!  Unfortunately the time it takes for the "OK" to came out is way too long, but I do not believe that is your problem but rather Amazons and related to the number of network interactions needed.  If Amazon were to provide an option in Alexa app to short circuit the "OK" and have Alexa ready for another command as soon as the action has been sent that would help. Perhaps even the inclusion of "And Then" at the end of a spoken command to make Alexa quickly ready for another command.  I know that is more like a skill as opposed to the CoHo, but . . . 

[Michel Kohanim]

Hi barrygordon,

 

Thanks so very much for the feedback and I totally agree.

 

Currently, Connected Home only supports commands from Amazon servers to a Lambda function (i.e. Echo -> Amazon Server -> Lambda -> Portal -> ISY -> Portal -> Lambda -> Amazon Server -> Echo). And, in each step of the way, the certificates and authentication are checked.

 

Benoit spent a significant amount of time figuring out where the bottlenecks were and it turns out that geographical proximity between Lambda and Portal caused between 500 and 1000 m.s. delay. To make the matters worse, Amazon server only talks to a Lambda function in a specific region. So, instead of having the ability to simply have Amazon talk to a Lambda closer to ISY Portal, we had to move the WHOLE portal to be closer to Lambda. Quite painful especially since DNS records didn't get updated for about 11 hours!

 

All and all, I am happy that we made the move and, again, I do apologize for the interruption in service.

 

With kind regards,

Michel

[Xathros]

Just FYI...

 

I had to power cycle my ISY before I could regain access via Alexa/Echo.  Until I did that, I was unable to rediscover my devices this morning.  ISY showed online in the portal.  I tried a reboot via the portal but that didn't resolve the problem.  Hard reboot did the trick.

 

-Xathros

[Michel Kohanim]

Hi Xathros,

 

Thanks so very much for the feedback. Definitely has to do with 5.0.2.

 

With kind regards,

Michel

[Xathros]

Excellent.  I had to leave for the office before I could do any response time tests.  I will follow up again after I get to play with it this evening.  From the sounds of it I should see an improvement in response times.  For what its worth, the response times for me prior to the server move were already quite acceptable.

 

-Xathros

 

EDIT: Response time does appear to be faster now.  Both time to device response and time till Alexa says "Ok" have been reduced.

Edited February 12, 2016 by Xathros