Michel Kohanim

Hello Automate The World, Is this a 994i? If so, do you know how many nodes/scenes/folders you have? It might be that you are reaching the 254 limit. With kind regards, Michel

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

Hi bilsk, What you are suggesting is illegal from a commercial use perspective. That's why we are currently paying HAM for their services (i.e. we would very much prefer not having to pay anything!!!). With 5.0.x, you can create a node server (or maybe one will exist) and have a climate node and simply push your variables to the properties for that node. As a matter of fact, if you are a developer and comfortable with Python, you can do that now using Polyglot on a Raspberry Pi. With kind regards, Michel

Hello all, We shall look into geofence. This said, can you please provide us with a list of features that you would like to work with MobiLinc/ISY Portal? Also, has anyone tried pointing http URL/Port in MobiLinc settings to ISY's local IP address/Port? Bob P, are you certain GeoFence works with MobiLinc and Dynamic DNS? If so, then it should automatically work with ISY Portal. With kind regards, Michel

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

Hi blisk, Have you tried having your PWS publish to CWOP which is then picked up by HAM? With kind regards, Michel

LeeG, Yes, precisely. Thanks so very much! With kind regards, Michel

Hi max90034, At the moment, unfortunately so. This said, however, we may be working on some type of discount for more than one ISYs per account. The challenge is how to distinguish individuals vs. installers. With kind regards, Michel

Hello larryllix, I totally understand your point alas I just do not know how we can make this into a more human readable format. Unfortunately, TLS/SSL is a little technical. Hi MWareman, Thanks SO very much for the details. With kind regards, Michel

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

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

Release Date: 2016-04-10 [Framework] - Proxy and Web server use different VMs - Default Proxy port is now 443 (used to be 8001) Release Date: 2016-02-28 [Echo] - Support for Multiple Echo/Accounts. Release Date: 2016-02-11 [Echo] - Improved performance for Echo/ISY Communications Release Date: 2016-02-07 [Portal] Remember me [Echo] - Scene Dim/Bright - Spoken lookups in red (when already used) - Spoken aliases (5)

Hello everyone, We would love for MobiLinc to support ISY Portal and we'll reach out to Wes. With kind regards, Michel

Hi majorlance, What I think the issue is that whatever is opening the socket (is it Startech?) is not closing it and thus the error. I think GC100 will help. With kind regards, Michel

Hi David, Thanks so very much for the excellent feedback. We do have virtual devices in 5.0.x but this specific issue is not going to be fixed in 5.0.x either. For now, and just for expediency, Benoit programmed the Dim function to dim 3 times (instead of one). We cannot do more since the Echo connector will timeout. With kind regards, Michel

Hi jerlands, Since we are not yet making on our app, the main question is whether or not MobiLinc would be able to work with ISY Portal. As such, I will have to leave this to Wes at MobiLinc. With kind regards, Michel

Hi doogledb, Yes, many. Please checkout the information on the first page of this post: http://forum.universal-devices.com/topic/4810-the-global-cache-wf2ir-works/?p=37381 With kind regards, Michel

Hello everyone, Thanks so very much for the feedback. It seems that we are going a little in circle: We are adding support for Dim/Brighten to scenes and sending multiple dim commands will work (incrementally). Asking ISY, the Portal, or REST commands to have a loop and send n number of Dim commands automatically is not a good idea regardless of how it's accomplished: 1. Scene commands create more traffic especially due to all the cleanup messages 2. If the scene is large, the caller MUST put a wait between each invocation (i.e. you are going to see incremental dimming) 3. There's no guarantee that all devices in the scene will have the same level to begin with. So, if A is 100%, B is at 75%, and C is at 50%, Dim to 50% will turn off C 4. Iterating through devices in a group/folder - and depending on the number of devices - may cause an Echo timeout The least ugly of all these ugly solutions is what Banichi suggested: a. Create a 50% dim scene and call it b. You can also use Adjust Scene in ISY Programs to change the on level of devices in #a according to some time or some event (warning, this might take a long time especially if you have too many devices in that scene) With kind regards, Michel

Hi David, Yes BUT you have to create a new sub account (under your account), assign ISY and the new user to it, and make sure you approve the request in the Admin Console. With kind regards, Michel

Hi Lee, That's very odd since I worked with a customer just a couple of weeks ago and setup volume up/down using an INSTEON KeypadLinc button which worked perfectly. Are there specific commands that exhibit this behavior or is it all commands? With kind regards, Michel

Hi ccclapp, Based on our measurements (you can test this yourself), every dim command you send to a scene, usually dims the members by 2-5% (varies depending on the device). The main issue is that, unlike devices, you cannot send a level to a scene with INSTEON. With kind regards, Michel

Hi ccclapp, See my previous post. Programs would need to iterate through and calling dim. This is ugly since each invocation will take 1 second ... less ugly solution would be to have a 50% scene instead. With kind regards, Michel

Hi David, With INSTEON, that would be impossible unless: 1. We have logic in the portal that keeps calling ISY to dim 'n' times (not very efficient) 2. Have an ISY program that loops and dims 'n' times (ugly) 3. Create another scene with your desired dim levels and just turn on that scene (not practical) With kind regards, Michel

Hi David, Please checkout: http://forum.universal-devices.com/topic/18060-dimming-scenes-with-echo/?p=165643. With kind regards, Michel

Thanks Teken! Just so that everyone's aware, dimming and brightening scenes will only dim by 3% (or something like that defined by INSTEON) for every invocation. So, if you want to dim a scene to 50%, you will have to tell Alexa to dim about 17 times. Also, it's important to note that you cannot send a % dim to a scene. So, the main question is: what is everyone expecting dim/brighten do for scenes? With kind regards, Michel