Jump to content

Release 3.1.17 (RC) Is Now Available


Michel Kohanim

Recommended Posts

Hello all,

 

I am happy to announce the availability of our 3.1.17 release! For a list of changes, please take a look at this post.

 

This is a minor release to address outstanding bugs and feature enhancements for 994 iZ Series. This release is our Official Release candidate so, please do be kind enough to test thoroughly.

 

Things to test:

- ELK issues for those who do not have ELK module installed

- 994 iZ, multiple ECMs and nodes

 

Important Information

1. Due to the sensitive nature of supporting MorningLinc/ELK Security Systems, users now must agree to terms and conditions upon Admin Console start up otherwise the dialog keeps popping up every time the Admin Console is started

 

2. Important If you have already installed a self signed certificate and your current firmware is 2.7.10 and below, you must reinstall a new one before the upgrade.

 

3. Please note that Network Resource modules are now running in their own task. This might have some ramifications as calling network resources from programs no longer waits for the resource to complete. As such, a) you will experience quicker handling of network resources/programs and B) if you are using DSCLinc and WebLinc, your programs may behave a little differently. Please do test your network resources thoroughly

 

4. Please note that Safari does not support SSL session reuse and thus might take an exorbitant amount of time to communicate with ISY. As such, when using 2048 bit SSL, it's best not to use Safari.

 

5. If you are using the Irrigation Module and are upgrading from releases prior to 3.1.5, you must edit the programs using Irrigation variables and save the programs again. Irrigation module is no longer on promotion

 

6. Upgrading from 3.1.3 and below: If you are using WeatherBug Module's Rain Today in your programs, please note that the precision has changed from 1/10 to 1/100 and thus your programs might not run properly

 

7. For a discussion of variables, please look at our Program Variables forum.

 

 

Instructions:

1. Please backup your ISY (File | Backup ISY). If you are backing up a 3.1.6 system, please note that the backups are corrupted. If you have a backup from prior releases, you should be OK

 

2. Please download the firmware for your platform - please do not unzip

ISY 99i Series

ISY 994i Series

 

3. Important (If upgrading from 2.8.5 through 2.8.14)

Due to invalid Java certificate chain, please make sure to remove all Universal Devices certificates from Java:

a. Close all browser sessions

b. Open Java Control Panel (Java Preferences on MAC)

c. Click on the Security tab. Remove all Universal Devices certificates (on MAC, click on the '-' button at the bottom)

e. Clear your Java Cache

 

 

4. Login to the Admin Console and choose Help | Manually Upgrade [the name of your system]

 

5. Choose the file saved in step 2

 

6. After the upgrade, ISY reboots. Please do ensure to clear your Java Cache

 

7. IMPORTANT Once upgrade is completed and ISY reboots, use any of the following methods to access your ISY's Admin Console:

a. 99/994i - http://isy/admin - applet (Windows only)

b. 99/994i - http://isy/admin.jnlp - Java application (Windows only)

c. http://your.isy.ip.address/admin - applet

d. http://your.isy.ip.address/admin.jnlp - Java application

e. http://www.universal-devices.com/99i/3.1.17 - applet

f. http://www.universal-devices.com/99i/3.1.17/admin.jnlp - Java application

 

Dashboard - not fully supported

- http://www.universal-devices.com/99i/3. ... board.jnlp

 

8. Please backup your system again

 

Thanks and with kind regards,

Michel

Link to comment
Share on other sites

Michel,

 

Tonight I observed a serious issue upon sending a *ALL OFF* command via the ISY Admin Center. When I pressed the *All Off* command the garage door opened up! :evil:

 

I can't begin to tell you, when the central alarm system went off showing a breach in the perimeter of my home, I almost jumped out of my skin!

 

Please let me know why this happened and how to resolve this issue . . .

 

Regards

 

Teken . . .

Link to comment
Share on other sites

Teken,

 

I am sorry to hear but there's not much you can do if your garage door is part of a scene. All INSTEON devices respond to All On/All Off commands regardless of their type. Even thermostats respond to All On/All Off commands (and go to 0!!!).

 

We may be able to put an option to disable All On/All Off but this does not mean that these commands cannot be issued via other means.

 

Also, I am not sure if you are still maintaining multiple installations (HouseLinc/ISY) and, as such, I would not know what configuration is where.

 

With kind regards,

Michel

Link to comment
Share on other sites

Teken,

 

I am sorry to hear but there's not much you can do if your garage door is part of a scene. All INSTEON devices respond to All On/All Off commands regardless of their type. Even thermostats respond to All On/All Off commands (and go to 0!!!).

 

We may be able to put an option to disable All On/All Off but this does not mean that these commands cannot be issued via other means.

 

Also, I am not sure if you are still maintaining multiple installations (HouseLinc/ISY) and, as such, I would not know what configuration is where.

 

With kind regards,

Michel

 

Michel,

 

Could you please explain this to me in layman's terms? :?: When I look at my ISY tree all of the devices are off. If I review the status of garage door sensor / relay, it too is in a off condition.

 

If I look at the SmartLinc (Which is the only thing linked) it too is in a off state. I do not understand how a global off command can make something which is already off, turn on??

 

The Garage I/O kit is set up with momentary C, the KPL is set for toggle. As far as I am aware there are no other related links / scenes attached to this device.

 

Regards

 

Teken . . .

Link to comment
Share on other sites

Teken

 

Take a look at the description of Momentary C in the I/O Linc user Guide. Both the On command and the Off command turn the Relay On.

 

The ALL OFF (or ALL ON) use a special Scene (Group) number that all devices with a responder link record react to even though the Scene (Group) number does not actually match the Scene number in the responder link record. The I/O Linc Relay is reacting to the Off command as though it were a normal Off command for Momentary C.

 

As Michel mentioned earlier even the tstat reacts in ways not desired.

 

You could switch to Momentary A mode where the Relay reacts to only one command, On or Off, but not both. It could be defined to react only to an On command but that may mess up what happends with the KeypadLinc when it sends an Off command.

 

Lee

Link to comment
Share on other sites

Teken,

 

You may already have considered this, but you could set up a scene with everything but the garage door relay. Then use that scene rather than all on. It's a bit of a pain, but it seems like that work around should address the problem.

Link to comment
Share on other sites

LeeG / Bcall,

 

Thank you both for the clarification on this matter. I just find this part very hard to understand and accept to be honest. :roll: I understand based on how it is described by LeeG now. But, it truly boggles my mind knowing a *ALL OFF* command would turn something *ON*?? :?:

 

What I am trying to grasps is this so please bare with me. :mrgreen: Right now everything (keeping the I/O Linc out of the picture) is off.

 

If I select the *ALL OFF* from the ISY Admin Center, everything that is OFF, will remain OFF. If I turn everything on, or random devices to a on state. Selecting *ALL OFF* will in fact send a off command and those things will turn off. There will be no device which was off, will turn on.

 

Now, we have this I/O device . . . It is off, for both relay and sensor. I am trying to grasp why a OFF command would even have any play into this situation??

 

OFF is OFF . . . It is not ON !! :evil:

 

I apologize for the rant - But, realize that my home is extremely secure and I have two things I value the most. My family, and then the possessions which I have worked very hard for, for more than three decades for.

 

Having the whole family dead asleep one moment, then having the entire house in an alarming state, all zones being locked down, sirens, strobes, alarm company, police coming in the dead of night.

 

Is NOT something I take lightly . . . The only saving grace is that I am aware of this strange behavior and will NOT use it any further. As aside I checked all the configurations and the only scenes created is for the I/O link to the KPL to control the OH Door.

 

The only other links / scenes are those attached to the SmartLinc device. This device is also linked to a Appliance Linc, to provide a status feed back with respect to the doors open / close status.

 

There is nothing else linked, or attached to the Insteon Network. I know this because this time last week the entire ISY melted down and I literally had to erase all links manually in all 70 plus devices in my home. Then, do a hard reset of the PLM, and the ISY.

 

Just to bring that device back to a usable state . . . For reference: When this ISY meltdown occurred the device indicated some cryptic message about the ELK module (I don't have one, nor did I purchase it) then everything took a shit and died! :evil::oops:

 

Regardless, I just wanted everyone who has a Garage I/O kit know if they use the *ALL OFF* they may be inadvertently opening the biggest door in your home to strangers and potential thieves!

 

If other members could please confirm / validate this does happen I would appreciate it. If it does NOT happen. Please do be kind enough to let me know how your environment is different to allow this to operate as expected.

 

Lastly, besides this none sense. The latest firmware release is working as expected, and much thanks goes to the UDI team for their continued support and endless commitment to their customers! :mrgreen:

 

Regards

 

Teken . . .

Link to comment
Share on other sites

Hi Teken,

 

You are 100% correct ... this IS an undesired effect and I think we should simply disable it by default in the next release. It really does cause a lot of problems especially with thermostats.

 

In the meantime, and as you mentioned, please do not use it.

 

With kind regards,

Michel

 

May I humbly suggest that you provide a check box for the I/O device, and RF TSTATS. To allow the user to determine IF this command is required.

 

I do not want to take away something from the masses, just because (I) do not see a benefit. There may be others who do like this strange behavior and use this to their benefit.

 

I believe having a option check box for these two devices would allow the best balance for all parties concerned. As always your continued support, guidance, and feed-back is greatly appreciated.

 

Regards

 

Teken . . .

Link to comment
Share on other sites

I seem to use my Garage Door I/O linc backwards than everybody else. My sensor is ON when the door is closed and I send an OFF to close the door and an ON to open it. If the sensor is OFF sending an ON has no effect, if the sensor is ON sending an OFF has no effect. It is in momentary C mode but the way the I/O Linc works depends on the state of the sensor when you set the momentary mode.

 

I believe in my case an ALL OFF would close the door or have no effect if already closed.

Link to comment
Share on other sites

Teken

 

Take a look at the description of Momentary C in the I/O Linc user Guide. Both the On command and the Off command turn the Relay On.

 

It was a while ago when I set up my I/O Linc but I seem to remember that in Mom C the relay action depends upon the state of the sensor when you set it up.

 

From the manual:

 

Momentary C

Use the I/O Linc sensor input to determine whether the I/O Linc relay will trigger. An ON command’s desired state can be programmed to either open or closed. I/O Linc will use the opposite for the OFF command’s desired sensor state. For example, if an ON command is programmed to trigger only when the sensor is closed, an OFF command will trigger only when the sensor is open.

Link to comment
Share on other sites

Hi Michel,

 

So far everything I have tested has worked perfectly except for the new "Send user friendly From (last name/first name) in Notifications." It only worked only for the first email sent. Test button presses after the first press resulted in Mail Server Failure [from timed out]. I increased the timeout to 2 seconds, again the test button worked only one time, after that the same error occured. Turns out any time the Save button is pressed to save any changes, the test button will work only 1 time then the errors start. Confirmed the 1 test email was sent and received.

 

Text message test resulted in no text message sent and no error on the first test button press, any test after the first did result in error message and no text sent.

 

Results were the same from running a program, after a smtp save a program would send an email only once.

 

Just to make sure I have the SMTP settings proper:

 

SMTP Server: smtp.comcast.net

User id: myemailaddress@comcast.net

From: My House:myemailaddress@comcast.net

SMTP Port: 587

Password: XXXXX

Timeout: 1,000ms

 

Is this an issue with comcast? I have not had any issues with text or emailing before or after the upgrade to 3.1.17 and if I delete "From" my text and emails go back to working fine.

 

As a side note, it is nice to see an email come in with my own customized name instead of just by ho hum email address!

 

Thanks,

Tim

Link to comment
Share on other sites

Not sure if this has always been the case, or just an issue in this release..

 

I have a Morninglinc controller. The isy-99i does read the status of the controller (locked, unlocked), but I'm not able to use this status in a program??

 

I realize the controller status may not be accurate if the lock is manually controlled.. but I'd like to setup a program to lock the door at night if it's not already locked, but don't want the program to send a lock command continually through the night... only if the controller reports it's in an unlocked state.

 

Can you guys assist?

Link to comment
Share on other sites

Use a time based Program trigger that locks the lockset regardless of MorningLinc Status.

 

Because the MorningLinc Status is so unreliable regarding the actual lockset status UDI may have chosen not to allow its use in Programs as a Condition. That is only speculation.

Link to comment
Share on other sites

I seem to use my Garage Door I/O linc backwards than everybody else. My sensor is ON when the door is closed and I send an OFF to close the door and an ON to open it. If the sensor is OFF sending an ON has no effect, if the sensor is ON sending an OFF has no effect. It is in momentary C mode but the way the I/O Linc works depends on the state of the sensor when you set the momentary mode.

 

I believe in my case an ALL OFF would close the door or have no effect if already closed.

 

 

andyf0,

 

Would you mind performing a test for me and see if the *ALL OFF* does indeed operate as you indicate above.

 

I would greatly appreciate it . . .

 

Teken . . .

Link to comment
Share on other sites

I seem to use my Garage Door I/O linc backwards than everybody else. My sensor is ON when the door is closed and I send an OFF to close the door and an ON to open it. If the sensor is OFF sending an ON has no effect, if the sensor is ON sending an OFF has no effect. It is in momentary C mode but the way the I/O Linc works depends on the state of the sensor when you set the momentary mode.

 

I believe in my case an ALL OFF would close the door or have no effect if already closed.

 

 

andyf0,

 

Would you mind performing a test for me and see if the *ALL OFF* does indeed operate as you indicate above.

 

I would greatly appreciate it . . .

 

Teken . . .

 

I hit ALL OFF. Everything turned off and the garage door closed. I hit it again and the garage door stayed closed. As I anticipated.

I also have two Venstar thermostats and their settings were maintained, they were not reset.

Link to comment
Share on other sites

I seem to use my Garage Door I/O linc backwards than everybody else. My sensor is ON when the door is closed and I send an OFF to close the door and an ON to open it. If the sensor is OFF sending an ON has no effect, if the sensor is ON sending an OFF has no effect. It is in momentary C mode but the way the I/O Linc works depends on the state of the sensor when you set the momentary mode.

 

I believe in my case an ALL OFF would close the door or have no effect if already closed.

 

 

andyf0,

 

Would you mind performing a test for me and see if the *ALL OFF* does indeed operate as you indicate above.

 

I would greatly appreciate it . . .

 

Teken . . .

 

I hit ALL OFF. Everything turned off and the garage door closed. I hit it again and the garage door stayed closed. As I anticipated.

I also have two Venstar thermostats and their settings were maintained, they were not reset.

 

I know you tested as indicated above. But, could you please confirm 4 more times for me while the door is down and closed.

 

Pressing the *ALL OFF* button and confirming the door does NOT attempt to open. If so, I will rewire the I/O link accordingly. I thank you so much for doing these tests for me and the UDI membership.

 

Teken . . .

Link to comment
Share on other sites

Hit ALL OFF 4 times while garage door was closed. Aside from my home turning everything off on the first hit, the remaining 3 hits didn't change anything, the garage door remained closed.

 

FYI, the IO Linc is wired to the Green & Black wires on the sensor so the sensor is ON when the door is closed. Good Luck, if you need anymore info I'm happy to help.

Link to comment
Share on other sites

Hit ALL OFF 4 times while garage door was closed. Aside from my home turning everything off on the first hit, the remaining 3 hits didn't change anything, the garage door remained closed.

 

FYI, the IO Linc is wired to the Green & Black wires on the sensor so the sensor is ON when the door is closed. Good Luck, if you need anymore info I'm happy to help.

 

andyf0,

 

You're fantastic and I thank you for the follow up and testing. :D I would have done this test straight away but it is currently -36'C in my garage right now so fumbling around with little frozen wires 10 feet in the air wasn't going to be fun. :cry:

 

If the results proved unproductive or helpful . . . :evil:

 

Much thanks again Sir!

 

Teken . . .

Link to comment
Share on other sites

Hit ALL OFF 4 times while garage door was closed. Aside from my home turning everything off on the first hit, the remaining 3 hits didn't change anything, the garage door remained closed.

 

FYI, the IO Linc is wired to the Green & Black wires on the sensor so the sensor is ON when the door is closed. Good Luck, if you need anymore info I'm happy to help.

 

andyf0,

 

You're fantastic and I thank you for the follow up and testing. :D I would have done this test straight away but it is currently -36'C in my garage right now so fumbling around with little frozen wires 10 feet in the air wasn't going to be fun. :cry:

 

If the results proved unproductive or helpful . . . :evil:

 

Much thanks again Sir!

 

Teken . . .

 

-36'C? OMG Come to Houston, it's 64' F

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...