What's in the next release (2.8.16)

[ddsaitta]

Thanks.

[hart2hart]

What would a sympton of this bug look like? I need more detail to understand.

 

 

Known Bugs in 2.7.9

 

 

KPL/RL issues: adding a button to a scene removes the slave link in the PLM

 

[Michel Kohanim]

Hello hart2hart,

 

This means that after you add a KPL/RemoteLinc button to a scene, the status of the KPL/RL button is no longer updated in ISY if you activate/deactivate the button physically. This problem is not readily reproducible but it does happen once in a while and especially with KPL v36 and new installations.

 

With kind regards,

Michel

[hart2hart]

Thanks for the explanation. I had just created a scene that included a KPL button as a controller and was having issues. Turns out that the Switchlinc is bad. It will not accept any links. Performed all steps reset etc but replaced with spare and it works well.

 

Hello hart2hart,

 

This means that after you add a KPL/RemoteLinc button to a scene, the status of the KPL/RL button is no longer updated in ISY if you activate/deactivate the button physically. This problem is not readily reproducible but it does happen once in a while and especially with KPL v36 and new installations.

 

With kind regards,

Michel

[hart2hart]

I have a scene with 4 SwitchLinc Relays and they are all responders (they are controllers for other scenes). I turn the scene on via ISY console or HomeSeer events through Plugin and all 4 SL show ON status on ISY console page. However one switch is not physically ON so I query it and it returns OFF.

 

In these cases, how is the Insteon retry logic working/not working. The PLM and hence ISY are acting as controller, correct? Should there be error message to say SL did not respond? If I control a single device via ISY and there are comm issues, it will give the status bar and show system busy -- this does not occur in this case.

 

I've deleted scene and devices a couple times but it still occurs.

[Michel Kohanim]

hart2hart,

 

First let me ask if that specific SWL is version 35. If so, that explains the issue you are having.

 

With group commands (activating/deactivating a scene), ISY does not hear acks back. So, it assumes that they all worked out OK unless one (or more) send a NACK. In most cases, this does not happen.

 

With kind regards,

Michel

[hart2hart]

Thanks. They are v35. Has this been fixed in a later SWL version or is it just a SWL Scene/Group limitation?

 

hart2hart,

 

First let me ask if that specific SWL is version 35. If so, that explains the issue you are having.

 

With group commands (activating/deactivating a scene), ISY does not hear acks back. So, it assumes that they all worked out OK unless one (or more) send a NACK. In most cases, this does not happen.

 

With kind regards,

Michel

[Michel Kohanim]

Hi hart2hart,

 

Yes, there was a small batch of SWL v35s that exhibited signal sensitivity issues. The newer versions all work fine.

 

With kind regards,

Michel

Thanks. They are v35. Has this been fixed in a later SWL version or is it just a SWL Scene/Group limitation?

 

hart2hart,

 

First let me ask if that specific SWL is version 35. If so, that explains the issue you are having.

 

With group commands (activating/deactivating a scene), ISY does not hear acks back. So, it assumes that they all worked out OK unless one (or more) send a NACK. In most cases, this does not happen.

 

With kind regards,

Michel

[hart2hart]

Is there anyway via physical inspection or testing I can determine if mine were in that "small batch" because I have a house full of v35 SWL that were purchased in a Jan-Feb and April timeframe last year.

 

If I got newer versions, would the group command limitation still exist -- I'd just have SWL that were more "responsive" to commands in general?

 

Thanks,

 

Paul

 

Hi hart2hart,

 

Yes, there was a small batch of SWL v35s that exhibited signal sensitivity issues. The newer versions all work fine.

 

With kind regards,

Michel

Thanks. They are v35. Has this been fixed in a later SWL version or is it just a SWL Scene/Group limitation?

 

hart2hart,

 

First let me ask if that specific SWL is version 35. If so, that explains the issue you are having.

 

With group commands (activating/deactivating a scene), ISY does not hear acks back. So, it assumes that they all worked out OK unless one (or more) send a NACK. In most cases, this does not happen.

 

With kind regards,

Michel

[Sub-Routine]

Is there anyway via physical inspection or testing I can determine if mine were in that "small batch" because I have a house full of v35 SWL that were purchased in a Jan-Feb and April timeframe last year.

 

If I got newer versions, would the group command limitation still exist -- I'd just have SWL that were more "responsive" to commands in general?

 

Thanks,

 

Paul

 

Hi Paul,

 

I hope you don't mind that I chime in a bit...

 

Please do not panic because all your switches are v.35, most of them function perfectly. From my conversations with installers it is usually only one or two out of a "houseful" of switches and Smarthome is very good about replacing those.

 

Rand

[hart2hart]

Thanks. I re-read my post and it does have a ring of panic. Really though, I've replaced several switches after working to remove noise and make sure electrical legs were properly joined so I've likely seen the v35 problem without knowing it. In fact I've got two on cross ship with SH now and, yes, they have been great about replacing. My post was to see if I could quickly locate any other switches which may be weak in signal recogition and get them replaced at one time.

 

Back to one of my original questions, does the insteon protocol have a weakenss with the group commands in that you can not confirm that all scene devices responded/get retries on failed SW. SH sure implies it has retry logic etc.

 

 

 

 

Is there anyway via physical inspection or testing I can determine if mine were in that "small batch" because I have a house full of v35 SWL that were purchased in a Jan-Feb and April timeframe last year.

 

If I got newer versions, would the group command limitation still exist -- I'd just have SWL that were more "responsive" to commands in general?

 

Thanks,

 

Paul

 

Hi Paul,

 

I hope you don't mind that I chime in a bit...

 

Please do not panic because all your switches are v.35, most of them function perfectly. From my conversations with installers it is usually only one or two out of a "houseful" of switches and Smarthome is very good about replacing those.

 

Rand

[Michel Kohanim]

Hi hart2hart,

 

It was a design decision on our part to fake the PLM into thinking that it was sending a direct command. PLM's group commands caused major network issues for us and they do even to this day and thus the decision. One of the issues is that since ISY is very adamant about receiving each and every signal, when PLM sends a group command the process of counting the the acks may be interrupted by any other signal. And, thus, we could never count on its accuracy anyway (just like KPLs that might blink one time and not other times). This is especially the case for large scenes.

 

With kind regards,

Michel

[Z3phyr]

Recently upgraded to 2.7.9 from 2.7.4, and am planning on purhasing the Weatherbug module. When I select the link through the admin console it returns:

 

Purchasing Modules requires firmware 2.7.7 (and above)!

 

Cleared the Java cache multiple times with no change.

 

Regards,

Z

[Sub-Routine]

Recently upgraded to 2.7.9 from 2.7.4, and am planning on purhasing the Weatherbug module. When I select the link through the admin console it returns:

 

Purchasing Modules requires firmware 2.7.7 (and above)!

 

Cleared the Java cache multiple times with no change.

 

Regards,

Z

 

Please use any of these methods to access your ISY:

 

a. http://isy/admin - applet

b. http://isy/admin.jnlp - Java application

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/2.7.9 - applet

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

 

Using the link from the UDI support page uses the 2.7.0 applet.

[MarkJames]

I don't know if this was reported or not - and I'm not entirely certain it's a bug as I'm reasonably new to ISY but I noted that if I perform a restore device to a motion sensor in 2.7.9a the ISY software doesn't challenge me to put the motion sensor into linking mode. I don't know for certain that it's necessary but I would assume it to be.

 

If this is normal behavior or has already been reported then my apologies.

[RLIKWARTZ]

I noticed this also and this shouldn't work this way. I didn't notice if you explicitely select the motion sensor from the pull down and it does ask you to put it in link mode.

[Michel Kohanim]

Hi,

 

If you have ISY99i PRO and if you are in the Batch Mode, then ISY does not ask you to do anything till you either click on Write updates to device menu item (right mouse click on the node) OR you get out of the batch mode.

 

If neither is the case, then this must be a bug.

 

With kind regards,

Michel

[MarkJames]

Hi,

 

If you have ISY99i PRO and if you are in the Batch Mode, then ISY does not ask you to do anything till you either click on Write updates to device menu item (right mouse click on the node) OR you get out of the batch mode.

 

If neither is the case, then this must be a bug.

 

With kind regards,

Michel

 

Nope.. I have an ISY99i-IR. It prompts when linking but not when restoring.

 

Mark

[Michel Kohanim]

Hi,

 

Thanks so very much. We will look into this.

 

With kind regards,

Michel

[hart2hart]

I have taught IRLinc about 30 IR commands and have linked them successfully to Scenes with lamplincs, switchlincs, and thermostats. Yesterday, I replaced three non-responsive switches. I removed the old switches and added new switches and then included them in scenes.

 

At least one of the scenes included IRLinc Devices. I could see ISY saying it was updating the IRLinc devices as it worked throught the scene setups. Later, I discovered that none of the IRLinc devices were working so I used the restore feature and had some success (a couple still will not respond).

 

Today, I was teaching IRLinc a couple of new IR commands to replace what appears to have "gone bad". In the recent past (using 2.7.9), I would send IR command to teach IRLinc and create link to ISY. I followed this by sending the IR command to confirm learning and linking worked by seeing status of OFF or ON flash on console. However, today, I had to exit ISY console and re enter before pressing remote button would cause state of ON/OFF to appear on console. I then added the IRLinc Devices to scenes and they do not respond.

 

What should I capture in event viewer to help diagnose?

[nachthorn]

After upgrading to firmware 2.7.9, my system experienced a similar problem to what this user experienced.

 

Immediately following upgrade, any attempts by ISY to communicate with v.33 LampLinc devices resulted in in a "Request Filed" error. V.37 LampLincs and non-LampLinc v.33 devices were unaffected. Additionally, their On Levels and Ramps Rates were reset to 100% and 0.1s, respectively, in all related scenes. I found that I had to remove each device from ISY and relink in order to regain functionality. Fortunately, it affected only 3 devices in a couple of scenes.[/url]

[hart2hart]

EDIT:Unless I misread, the following describes the issue and that it is resolved. Should have read a few more posts before typing...

 

http://forum.universal-devices.com/viewtopic.php?t=3785

---------------------------------------------------

 

I've got a scene with:

3 Switchlinc Dimmers

1 Keypadlinc Dimmer as load

1 button on above kpld

2 IRLinc Devices one on and one off

 

I can set the scene with 100% on with a 30 second ramp and it sets up but setting the keypadlinc button with same settings appears to work until you click another device and and then back to button device and it either shows a very low on level or 100% on and .1 second ramp rate. Ive removed and added devices and the scene and it does not fix.

[Michel Kohanim]

nachthorn,

 

This is fixed in the next drop.

 

hart2hart,

 

We have to investigate the IRLinc issue. Currently, the best thing to do would be to send us your backup files (tech@universal-devices.com) and please let us know the address of your IRLinc. Thanks SO very much.

 

The KPL issue should be fixed in the next drop.

 

 

With kind regards,

Michel

[gfridland]

Michel...

 

Can you provide an estimate for release of 2.7.10.

 

I'm currently in 2.7.9 and due to the amount of links, am reluctant to move back to 2.7.7 unless absolutely necessary. I'm hpoing that the new release is close.

 

Thanks for your continued support!

[picc02766]

Notice:

Due to the relatively high severity of bugs found in 2.7.9, it's strongly advised to either wait for release 2.7.10 or install 2.7.7 instead. If you would like to get instructions for 2.7.7, please send an email to support@universal-devices.com.

 

Please note that if you so choose to install 2.7.9, all your INSTEON changes will be lost in 2.7.10 as you would have to restore a backup from a release prior to 2.7.8.

 

If you are already using 2.7.9::

1. Please do not make any changes to your INSTEON configuration (i.e scenes, devices, restoring devices, restoring PLM, etc.). Program changes are OK

2. Please do not use any backup of 2.7.9 on 2.7.10 and above

 

Hi, sorry if this was discussed already but I could not find any reference to it. In regard to the second paragraph above - As I was an early adopter of 2.7.8/2.7.9 and my implementation began the last week in December, I don't have a useful backup prior to 2.7.8, if any at all - am I reading this right then that with 2.7.10 I'll need to start from scratch?

 

Also, is there a way for me to tell with what version a particular backup was made?

 

Thanks,

Rob