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

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, 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

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

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.

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

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 do not use he IZZY Skill, ergo I never have reason to go to the portal, so if yo do not mind, refresh my memory, what is the URL to the Portal?

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". The ISY is working fine I can deal with it from my iPads and other programs that interfaces to it using REST. Nothing on the LAN has changed. Internet access is fine even to alexa.amazon.com. The ISY configuration entry for the Portal is correct. Alexa shows that the COHO for ISY is enabled. All 99 devices are listed as discovered. I even did a forget all devices and a re-discover but same message comes up. I dropped power on the Echo to cause a reboot and that did not help. I have two Echos, so I don't think it is an Echo hardware issue as they are both acting the same way. Any Assistance/suggestions greatly appreciated.

I just tried the following dim commands with an Insteon Switchlinc Dimmer (Office lights is the friendly name) : Alexa dim the office lights to 30 Alexa dim the office lights to 70 Alexa dim the office lights to 50 Alexa dim the office lights to 90 All worked properly. I did not look in the admin console, but rather looked if the light was doing what I would consider reasonable Also I can use the word Set in lieu of Dim and things still worked properly, and I cen finalize the command with percent (%) or not. All cases work perfectly.

doogledb The "IRCODE" word is the TiVo command to be used when the TCP string is received. It will then emulate what the IR remote would have caused to happen as an action. In this case the Tivo would perform the same action as if it received the IR code for the number 6 from its IR Remote. There are only a few (5 IIRC) TCP commands, that the Tivo accepts. It does most of the IP work through emulation of the IR code.

In the connected home, didn't they allow for a "Set" command to control a dim-able light as in "Alexa, Set the <friendly name> to 50" ? I kind of remember this working with the HUE Emulator and using it to set the temperature of a thermostat. Eventually I found that the best way to run the HVAC was not to touch the settings. I leave them on Auto and let the thermostat do its job. They are Z-Wave thermostats that ISY can control and report full status on.

could start here: https://simple.wikipedia.org/wiki/SOAP_(protocol) Also SOAP for the ISY is documented in their SDK docs.

Where I see a need is in the connected home. I would like to be able to end a command with "and then" and have Alexa come back to me to get another command ad infinitum until I say "nothing" or "stop". Too many times I want adjust a couple of lights and which ones is variable so I don't want a thousand scenes

jon, Eliza is in Alexa app under skills. It is an implementation of the original Eliza program from MIT circa 1970's by J Wizenbaum, IIRC. It mimics a particular type of Psycho-therapist

The real advantage of the intermediate app is that it completely obeys the GC protocol so it waits for the completion response prior to sending the next command. This is very important in the case of a Macro. Naturally I have a companion program that makes the correct timing strings from an IRP file which is a verbal description of the IR protocol to be used.

jerlands, LOL. Made me remember the Bill Cosby monologue where he described how his kids though their names were "Stupid" and "Jesus Christ" since that was how he addressed them most of the time.

I have that solution working with a small caveat. I have an intermediate program that is always running on a 24/7 PC It handles the issue of sending the GC the correct timing strings. In The ISY I have a network resource that basically sends this program, the name of the device. The little program does a few things so the actual TCP string sent is: DOIR, <port number>, <Device ID>, <Function Name> or MACRO, <port Number>,<Macro Name> where <port number> is the port number to use on the GC (I have a GC 100 which has 6 IR ports) <Device id> is the device Identifier; a 3 letter code such as STB for set top box or ISG for insignia TV and VIZ for Vizio TV, etc. <function name or command name> should be obvious. typical command names are Power On, Mute, Guide, etc., typical macro names are CNN, ABC, etc. If anyone wants a copy of the little program I will clean it up (so it only does the IR stuff) document it and make it an install-able Windows package. If there are any RPi programmers who deal with python or node.js and would like to collaborate with me on turning some of my code (mostly Visual Basic (VB 6) or VB.net into little self sufficient function for the RPi drop me an email eMail address is in my profile). I will get to it sooner or later but probably latter. I'll supply the code, you port it, I'll test it, and we can then give it away.

In the overall process case should not matter. The voice does not reflect case, the ear or an audio pickup (microphone) does not know case. Speech recognition does not reflect case unless you perform some grammatical inference. In Linux as in many programming languages text comparisons are case sensitive. In some languages you can specify if text compares (the comparison of strings of text) are to be done case insensitive or case sensitive. The only variability in the overall process of "Speech" to Action" are the speech recognition phase, a possible timing problem or a programming error. If there is a case sensitivity then there has to be a programming error. In fact you should be able to use homonyms (homophones) with no effect on the recognition process. For example "Alexa turn off the pier lights" and "Alexa turn off the peer lights" should achieve the exact same interpretation via speech recognition. After the speech is sent to the Amazon cloud, the recognition process will hopefully use the words entered into the portal for matching. This better be case insensitive. When a match occurs the associated text will be whatever you typed into the portal resulted in being stored. My experience has been that no matter what I typed in as the spoken word(s) the portal always stored them as lower case. It is possible the process when it records what it "heard" will apply a little logic and convert "kitchen lights" to "Kitchen lights". In theory, theory and practice are very close; in practice, theory and practice may not be.

Instead of turn off I often say shut as in Alexa, shut the kitchen lights. That seems to always work, but for me turn off works as well

I am writing this to help clarify what goes on behind the scenes with the Echo/ISY Connected Home" capability. In particular why there is a difference in responsiveness (time from the end of a spoken command e.g. "Alexa, turn off the kitchen lights" to the instant the lights actually go off) between the HUE Emulator and the ISY connected home skill .The following is the meat of a discussion between myself and Brad of BWS Systems. With all the new Connected Home (CoHo) skills out there, there is another server that handles the request from amazon after the trigger word is said. This means there are 2 cloud services handling the request instead of just one server, Amazon's service. The HUE Emulator is completely local and is called by the Echo using the HUE API, no internet needed for that to happen as the Echo and the Emulator are on the same LAN. The Emulator is discovered by the Echo via uPnP at which time the Echo believes it will be talking to a Phillips HUE hub. This is in addition to any other connected home skill that has been enabled for that Echo. It appears that the Amazon Lighting API, the foundation lighting skill inherently knows about the Philips HUE hub. All other hub devices or cloud connected devices require a secondary process, what Amazon calls a "Skill Adapter" Path diagram for HA-Bridge (HUE Emulator): 1- Speaker says "Alexa, turn on kitchen Light" --->> Amazon Echo: records what it heard and sends it to the Amazon server via the Internet (first internet traverse) 2- Amazon server decodes message and sends back to the Echo a synopsis of what was understood; basicly the command, and a device ID via the Internet (second Internet traverse) 3- Echo sends the information (command, ID) to the HUE Emulator via the LAN 4- HUE Emulator sends RESTful command to UDI ISY Via the LAN 5- UDI ISY turns on the kitchen light Note: The above required two traverses of the Internet Path diagram for a skill Adapter in Echo Connected Home (The ISY entry in the connected home is a skill adapter): 1- Speaker says "Alexa, turn on kitchen light" --->> Amazon Echo: records what it heard and sends it to the Amazon server via the Internet (first Internet traverse) 2- Amazon server decodes message and sends message to UDI ISY ASK (Alexa Skill Kit) Server via the internet (second Internet traverse) 3-UDI ISY ASK server parses message and sends information back to the registered UDI ISY via the Internet (third Internet Traverse) 4- UDI ISY turns on the kitchen light Note: The above required three traverses of the Internet. The additional Internet traversal is what proably takes the additional time causing the difference in responsivenes between the two systems. I do not believe this will be changing since it is how Amazon makes some of its money, providing the hosting environment for a Skill Adapter in the cloud. In fact I suspect Amazon may delete direct support for the HUE API since it allows the overall process to run without using the cloud a second time reducing their income. As they say in forensic accounting "Follow the money". The following is a reference to the Amazon lighting API. I am not sure if you need to be an Amazon developer to see the material, but the reference is in the public domain on the Github. The term skill adapter is used for those skills that work off of the Amazon Lighting api. https://developer.amazon.com/public/binaries/content/assets/html/alexa-lighting-api.html

Teken et al, Just a point of clarification as I am a stickler about attribution and giving credit where credit is due. The HA Bridge (Hue Emulator) was developed by Brad at BWS Systems based on earlier work by another developer. It was written specifically for the Casa Verde Home Automation hub. My Contribution was in assisting Brad in expanding the HA Bridge to handle the ISY and then writing the user interface program that allowed a simple graphic interface to the HA Bridge for ISY users. At the current time I am not using the HA Bridge just the ISY connected home skill adapter. I do not use the skill (IZZY) as I have no devices that needs its control capability. I believe the current rash of ISY connected home issues as documented in the prior 15 or so posts has to do with the transition from beta to full availability and is only transient. I have not had any issues but have not been to the ISY portal lately as my system just keeps on ticking. I even did an upgrade to ISY 5.0.2 with no issues. I agree that an ISY soft (warm) boot and an ISY hard (cold) boot are quite different. After a firmware upgrade I must do a hard boot before the ISY starts to behave correctly.

Jameson, I do not think it is an "Allowed" issue, but I am not sure. I know that Amazon does invite and support developers to build connected home skill adapters and I do not believe they specify that the code must run in their cloud. I believe it is up to the developer to determine how best to implement the adapter to meet their needs. I could be wrong though.

ISY always wins on all fronts when compared to most of the current offerings of a similar nature.

Amazon Echo Skills and the Connected Home. In the context of the Amazon Echo a skill is any process that extends the Echo's ability to deal with other devices, normally devices in the realm of Home Automation or Home Control. Amazon provides a native skill to deal with lighting systems, specifically the lighting system made by Phillips and known as the HUE lighting system. Since the native skill was designed for lighting, its command structure is built around the words On, Off, and Dim. Technically the Amazon Echo "Connected Home" is a set of worker programs or devices running such worker programs that are used by the Amazon cloud process that handles speech recognition for the Echo. These worker programs can be hosted in the Amazon cloud, on a local Area Network (LAN) or any place that the Amazon cloud process can reach through the Internet. Amazon calls these worker programs "Skill Adapters". In effect they adapt the Amazon Native Skill to specific end points that have specific functionality and their own protocol for communications. The ISY is such an end point, the Smart-things hub is another one as are the Insteon hub and the Philips HUE Hub. The Amazon native skill, and its skill adapters, is the one skill that does not need a name to be invoked. It is the skill that is native to the Echo and will be used by the Echo when not told to use a different named skill such as IZZY. The echo is inherently able to do other things such as playing music and answering some questions, but lets stick with skills for now. Amazon encourages developers (any one with programming skills can become an Amazon developer for the Echo and it is free cost wise to do so) to build new skills and to build skill adapters. There are two significant differences between a skill and a skill adapter. A skill adapter is limited in what can/will understand. It is basically limited to "Turn on", "Turn off" and "Dim", but I have been successful with "Shut". It also allows for noise words such as "the". A skill adapter is invoked by stating the Echo's wake up word (normally Alexa) followed by the command followed by the device name with a possible value for the Dim command. For Example "Alexa, turn off the Kitchen lights" or Alexa, dim the bedroom lights to 50 percent" A skill, as opposed to a skill adapater, has a name such is Izzy, which is the name of the UDI skill. The name must be used when the skill is invoked. The skill is not limited in its command vocabulary and has a more flexible syntactic structure as to what is spoken and can be recognized. For example "Alexa, tell Izzy to lock the front door", or "Alexa, ask Izzy what the bedroom temperature is" would all be possible with a skill (the UDI skill "Izzy" may not be able to handle this yet but in the future . . . The skills available for the connected home are listed in the "settings/connected home" section of the Alexa app. The full skills (such as Izzy) are all listed in the skills section of the Alexa app. The HUE adapter is not listed in the connected home as it is the default device that is assumed by the Amazon native skill. All other skill adapters are listed by name, and somehow you must register a desired skill adapter from the connected home with Amazon so it knows what to look for and query for device names. An Amazon Echo account can have associated with it multiple skills and/or skill adapters. The HUE Emulator which was used by many in this forum before UDI published its skill and skill adapter was a software program that emulated the Philips HUE and ran on he same LAN as the Echo using a PC, MAC or Raspberry PI as the hosting computer. It had to be running 24/7 which made the Raspberry Pi a good hosting candidate. UDI's connected home skill adapter is accessed and set up through the UDI Portal add on. This add on for the ISY costs $50 for a two year subscription. When properly set up it allows Amazon to discover the desired spoken names of those things the ISY controls that you wish to be controllable by the Echo. The Amazon data base for this is in the cloud and all Echos in the same Amazon account use this one database of device names. When the Amazon speech recognition process resolves what is spoken into text strings it checks to see what skills (native or non-native) that Echo account has associated with it. The skill adapter for the HUE is associated with every account. It then sends a synopsis of the text to the worker program that is associated with the skill adapters that you have indicated you are using, or to a skill whose skill name you have enabled is associated with the account. The Hue emulator, being local, was very fast in getting the desired action to the ISY. The ISY skill adapter is not local but rather hosted somewhere in the amazon cloud so it has to be a little slower performance wise. Amazon charges UDI for the hosting of its skill adapter and for its Skill, hence the portal charge. The ISY skill adapter does appear to be a little more forgiving, or perhaps I should say understanding with regards to what is spoken to the Echo. In all cases there is a security trust issue that is handled since a major portion of the overall process is non-local, i.e. in the cloud. You wouldn't want a stranger to be able to command your Echo/ISY to unlock the front door. The UDI skill adapter for the ISY allows the association of a name with a device, program or scene that is configured in the ISY. For a device the action of the commands are fairly obvious. For a scene the Dim command can not be used since a scene can not be dimmed. For a program the On command runs the Then section and the Off command the Else section and the Dim command is not used. The only issue I have with the ISY skill adapter is the speed factor. It takes 2-3 seconds (to me an eternity) for the actual action to occur after I finish speaking. The Hue Emulator responded almost instantaneously. I have things I would like to see Amazon do such as allow me to say "and" or "and then" to have the echo come back after the first action to hear a second command sequence with out having to begin all over with "Alexa, . . .". Perhaps the Echo would say "what" in this case thereby providing for an extended dialog to handle multiple devices without setting up a scene or group. Naturally I could also end the second command with "and then". Due to the architecture of the ISY many interesting things may be accomplished. I am completely controlling my Kitchen TV (on, off, channel selection, volume, etc) through the Echo using ISY program entries (runThen) for the most part) that run network resources that send strings to a Global Cache unit via an intermediate process that simplifies the strings for me. In a similar manner I control turning on my Home Theater. At the current time all my needs are handled by the ISY skill adapter so I am not using the Izzy skill. I am confident it will only get better!.