Release 3.2.3 (Beta) Is Now Available

[LeeG]

gviliunas

 

That looks like a bug. It is using the old I1 Peek/Poke method to set the Local Ramp Rate. I see the same results on a v.36 SwitchLinc where it should be using the I2 method.

[LeeG]

gviliunas

 

I power cycled my SwitchLinc and it picked up the new Local Ramp Rate of 6.5. That is one of the issues with the I1 method. The newer I2 method does not require a power cycle. Don't know if it will work with your v.27 SwitchLinc.

[andyf0]

While I was trying to figure out what Query Insteon Engine actually did I tried running it on a SwitchLinc and a LampLinc. The result was that it said something like reverting to I1.

 

Can you tell if this is really an I1 device? This is for a (2476S) SwitchLinc Relay W/Sense v.37

 

Sat 04/07/2012 03:35:34 PM : [All ] Writing 1 bytes to devices

 

Sat 04/07/2012 03:35:34 PM : [iNST-TX-I1 ] 02 62 13 52 12 0F 0D 00

 

Sat 04/07/2012 03:35:34 PM : [iNST-ACK ] 02 62 13.52.12 0F 0D 00 06 (00)

 

Sat 04/07/2012 03:35:34 PM : [iNST-SRX ] 02 50 13.52.12 18.CF.62 27 0D 01 (01)

 

Sat 04/07/2012 03:35:34 PM : [standard-Direct Ack][13.52.12-->ISY/PLM Group=0] Max Hops=3, Hops Left=1

 

Sat 04/07/2012 03:35:34 PM : [13 52 12 0 ] Calibrating engine version

 

Sat 04/07/2012 03:35:34 PM : [13 52 12 0 ] May not fully support i2, reverting to i1

 

Is there a bug in the Query? Have I messed up my switch? Can I get it back to I2?

 

The other problem is I don't remember exactly which devices I did this on but they all reverted to I1.

[LeeG]

andyf0

 

That SwitchLinc supports I2 but not I2CS. Before there was I1 and I2. Now there is I1, I2 and I2CS. It appears the Query Insteon Engine function considers only two options, I1 and I2CS. This leaves the newer but pre I2CS devices regressed to using I1 with all its limitations and short comings. 3.2.4 should be out sometime next week. Let’s hope this is resolved in that image. Lots of things will stop working when regressed to using I1.

[andyf0]

That's scary. So when the new firmware supports I1, I2 & I2CS in the Query Engine, I should just be able to do new queries to get my devices back to I2?

[LeeG]

I don't know. Will have to wait and see if a new Query Insteon Engine solves the problem. I hope so. Otherwise the device would have to be deleted and added back.

[andyf0]

Ah! Got it. I hope so too. Thanks, helpful as always.

[Brian H]

Event Viewer Level #3 for a Query Insteon Engine for an I2 ApplianceLinc v.38. Dropped back to I1 as it thought all of the I2 features may not be supported as we know some don't.

Sat 04/07/2012 06:14:07 PM : [All ] Writing 1 bytes to devices

 

Sat 04/07/2012 06:14:07 PM : [iNST-TX-I1 ] 02 62 15 F0 EC 0F 0D 00

 

Sat 04/07/2012 06:14:07 PM : [iNST-ACK ] 02 62 15.F0.EC 0F 0D 00 06 (00)

 

Sat 04/07/2012 06:14:07 PM : [iNST-SRX ] 02 50 15.F0.EC 19.70.1A 2B 0D 01 (01)

 

Sat 04/07/2012 06:14:07 PM : [standard-Direct Ack][15.F0.EC-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

 

Sat 04/07/2012 06:14:07 PM : [15 F0 EC 0 ] Calibrating engine version

 

Sat 04/07/2012 06:14:07 PM : [15 F0 EC 0 ] May not fully support i2, reverting to i1

[LeeG]

I think the decision on which link database management technique (I1 versus i2) to use may have to be separated from the decision on which device configuration to use. Except for devices that had no I1 option, all link management has been done with I1. However, many devices have been configured using I2 for a long time. KeypadLinc configuration, SwitchLinc configuration just to name a few will be broken if device configuration is forced back to I1. The requirement to power cycle the newer SwitchLincs to get the Local values to take affect is only the tip of the ice berg. I suspect KeypadLinc configuration involving buttons is broken using I1 for device configuration.

[mlvarnell]

Upgraded from 3.1.17 to 3.2.3. Smooth as silk! Thanks!

[Michel Kohanim]

Hello mrobles,

 

Please do make sure your devices are NOT in a folder.

 

Hello all,

 

Sincere apologies for tardy reply.

 

Just for the sake of clarification:

1. For database management, all devices use I1 (calibrated) UNLESS they report as I2CS or if they are listed in our list of explicit I2 devices (such as RL2, Motion Sensor, TriggerLinc)

2. For I2 commands, all devices that report I2 or I2CS are communicated with using extended commands

 

We should have 3.2.4 out shortly. We are hoping that someone can categorically let us know if it was ever possible to actually set the timeout value on an SWL Timer. And, if so, on which release?

 

With kind regards,

Michel

[Michel Kohanim]

Hello all,

 

Release 3.2.4 is now available.

 

With kind regards,

Michel

[bcall]

Hi Michel,

 

I have 3.2.3 installed and everything seemed ok. But I just noticed that I'm not getting appropriate communication with a dual band switchlinc dimmer v.40 (2477D).

 

The ISY is able to turn it on and off but it can't do the following:

1. i have programs triggered when FastOn is used from this switch. But, when I double click the switch, the program does not get triggered.

2. I tried restoring the device. I got no errors on the restore, but it didn't solve the problem.

3. Then I tried a couple of tests: I tried adjusting the ramp rate and the on Level. The ISY seemed to think it had made the adjustments, but the switch didn't get the changes (i.e., ramp rate and on level stayed the same as before).

 

I believe this was working in 3.1.x. I didn't notice that it wasn't working until after I upgraded to the new beta. I didn't have a chance to install 3.2.1 or 3.2.2.

 

I checked the error log and it has no entries related to this (or anything around the same time frame).

 

Any help would be appreciated.

bcall

[bcall]

update:

 

I tried switching the program to trigger from another dual band switchlinc. Still not working.

Tried a regular switchlinc. not working

Tried an icon dimmer. not working

for each, i tried faston and on.

 

I upgraded to 3.2.4 and tried everything again. not working

I downgraded to 3.1.17. not working.

 

Ok. I'm stumped.

 

fyi - i created a program that turned a light on at a specific time and it worked. I also created a program that triggered based on the armed status of my ELK (I have the ELK module), and it worked as well. So, as far as I can tell, it seems to be only the programs that trigger from Insteon functions.

 

Also, the admin console does not update when I turn a light on or off. For example, if I have my kitchen light selected in the console and it's currently on, the console will show its state as on. However, if I go to the switch and turn it off, the console still shows it as off. If I right click on the device and force a query, it then shows up as off. However, I thought that previously, when I turned a switch on or off at the switch itself, the console would instantly update. Is my memory incorrect on that? Could it be that my ISY just isn't hearing the commands from the switches? I'm still able to turn the switches on and off from the console.

[LeeG]

bcall

 

It sounds like the PLM was reset. Try a File | Restore Modem (PLM) to rebuild the link database in the PLM. The problem with the local ramp rate and on level not changing is resolved with 3.2.4.

[bcall]

LeeG,

 

You are a genius! It's working again. Thank you!!!

[Illusion]

Things to test:

- MorningLinc

- SynchorLinc

- EZxx

- SwitchLinc Timer

-- You might have to remove devices and then add them back to ISY

 

I am getting ready to upgrade to 3.2.4, I and see this in regards to 3.2.3. I have many Syncrolincs. The only issue I have with them is that the 'Delay' function does not appear to affect the devices. Is this something that will be fixed by deleting them and adding them back in when I go to 3.2.4? If not, I sure do not want that hassle if it is not necessary. I have lots of programs referencing them and do not have a spare to do the add/replace and we still do not have my requested 'phantom devices'

 

What other functionality should I gain by undertaking the large task of removing and adding back these devices when I upgrade from v3.1.17?

[Michel Kohanim]

Hi Illusion,

 

You do not necessarily have to remove these devices and add them back. We had a problem with migration which was solved in 3.2.3 (and .4).

 

With kind regards,

Michel