Jump to content

Release 3.2.2 (Beta) Is Now Available


Michel Kohanim

Recommended Posts

Some SwitchLincs, InLineLincs, and KPLs reverting to 0% and 9min ramp (locally Applied Settings in Admin Console) after 3.x upgrade.

 

I noticed that a non-load switch controlling a scene was not turning on a light. When I checked ISY, I noticed that my locally applied settings for:

 

SWL Dimmer v.27, v.28, v.37, v.38

ILL v.53

KPL v.39

 

had all been changed to 0% and 9min ramp time.

Once I changed the settings for > 20 units, everything seems to be working again.

Has anyone else noticed this?

 

Greg

Link to comment
Share on other sites

I noticed that the momemtary hold time option for v.33 or v.36 I/O Linc units cannot be changed. You can enter a number and save it but the hold time reverts to 0 upon reopening the IOLinc Options pop-up.

 

I thought that I had a bad IOLinc but I replaced the v.33 with a previously unused v.36 spare. Both versions exhibit the same problem.

 

Greg

Link to comment
Share on other sites

gviliunas

 

Right click the IOLinc Sensor node, select Diagnostics | Query Insteon Engine.

 

Try the Set Options update again. I am able to set the timeout interval okay and the IO Linc relay does respond with the new value but the new value is not displayed the next time I click Set Options. I know why that is and I will send a trace to UDI about that.

 

If the new timeout value does not have an effect on the device, independent of the fact that the new value does not display, run an Event Trace with Level 3 set, trace a Set Options changing the timeout value . Exit Set Options and then click Set Options again and post the trace.

Link to comment
Share on other sites

Hi LeeG and gviliunas,

 

I think we have found the bug with IOLinc ... as we had expected, supporting i2cs in combination with i1 and i2 is basically a nightmare. We should have a build hopefully by Friday.

 

Hi molney, if you have PLM version 98, that's the root cause.

 

If not, would you please use Event Viewer on the last level (Device Communications), retry and paste the contents on a reply.

 

With kind regards,

Michel

Link to comment
Share on other sites

I have a fanlinc v.41, 6 button dimmer kepadlinc v.40.

 

I set buttons A-D to toggle on. I created 4 scenes, fan off/low/med/high, with A,B,C,D as controller and fan as responder with the scene setting of off/low/med/high.

 

Now, all buttons A-D put the fan to high and isy always sets the fanlinc status to off when any buttons is pressed (which i then have to tell isy to query the device so it can figure out the fanlinc is actually on).

 

I've worked around this by removing the scenes and just using programs to set the status to high/medium/low/off, but this seems sub-optimal.

Link to comment
Share on other sites

With the Scenes deleted there is no way to verify but it sounds like the FanLinc Fan Responder On Level for each KeypadLinc Controller button was not adjusted to the required On Level. Setting the On Level for the Scene (when Scene name selected) sets the FanLinc Fan On Level when the Scene name is used. Each KeypadLinc button node listed below the Scene name has to be selected and the respective Fan On Level set for each KeypadLinc button as a Controller. Insteon establishes unique responder values for each Controller. When the Scene name is selected the ISY PLM is the Controller.

 

EDIT: was the FanLinc added to the ISY under 3.2.2?

Link to comment
Share on other sites

Okay, thanks for that information. I will see if I can recreate. Note that there is a glitch with Query on the Fan side of the FanLinc that does not report the correct Fan state. This will be fixed in 3.2.3. I did not think it affected the displayed Fan state from a KeypadLinc button press.

 

EDIT: Confirmed. The KeypadLinc buttons turn the FanLinc Fan to Low/Med/High/Off as the Scenes are defined but the FanLinc Fan node does not reflect the change in state except for Off.

Link to comment
Share on other sites

I'll check that next. I'm on an Alpha where the Query is fixed so I will have to reload 3.2.2. Perhaps the Query problem was found on 3.2.1 and fixed on 3.2.2.

 

EDIT: my apologies, the FanLinc Fan Query does work correctly on 3.2.2

Link to comment
Share on other sites

Can you use auto-detect to link new I2CS modules in V3.2.2?

 

I updated my ISY99 to 3.2.2 last Sunday. All went well. I added an existing Fanlinc, created a couple of scenes and all went well. Confirmed Running 3.2.2 in both listings in "about".

 

I did not log into the ISY until last night again. I had a lot of trouble even getting the ISY up and running. Only initial white screen (no 2nd Blue screen) would come up. Authentication input would fail to work.

I will not expound on that for now but wanted to mention it. I eventually got it running after reloading Java (perhaps just the cache needed emptying? ... I had emptied cache after the install on Sunday).

 

Now all seemed to be running as it should. Did a few queries to be sure of comm.

I then tried to link a new Appliancelinc (2456S3, V 4.6). I used auto-detect. A few intial commands were sent and the Appliancelinc went into link mode (fast blinking white LED).

The ISY then hung in a loop "initializing system". It timed 0-100% on that screen 3 times (over 10 minutes) and I could not exit. Rebooted computer.

 

As soon as I entered the ISY again it was still hung in that loop. I rebooted the ISY.

Now I could not get a query to work. Exited and reentered ISY. Now all is fine.

 

Tried a second attempt at Auto-detect linking and it failed in the same manner. Had to reboot the ISY and reenter program twice to get query working again.

 

On my third attempt I did not use auto-detect and instead picked the 2456S3 device. I also manually put the appliancelinc into link mode using the set button.

This time it linked fine.

 

What I expected to take 5 minutes took over an hour. All I really wanted to accomplish was getting a log of the new device link to confirm it was I2CS.

I think there may have been a few things going wrong at once and I did not want to focus on all of them.

 

Just the question of auto-detect for I2CS?

 

Here is the log from the very first attempt that failed and hung:

Wed 04/04/2012 09:48:53 PM : ---- Initializing the linked devices ----

Wed 04/04/2012 09:48:53 PM : ---- All Linked Devices are now initialized ----

Wed 04/04/2012 09:48:53 PM : ---- Add remaining devices ----

Wed 04/04/2012 09:48:53 PM : [iNST-TX-I1  ] 02 62 1C F3 17 0F 0D 00

Wed 04/04/2012 09:48:53 PM : [iNST-ACK    ] 02 62 1C.F3.17 0F 0D 00 06                 (00)

Wed 04/04/2012 09:48:54 PM : [iNST-SRX    ] 02 50 1C.F3.17 1B.FD.23 2B 0D FF           (FF)

Wed 04/04/2012 09:48:54 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Wed 04/04/2012 09:48:54 PM : [iNST-TX-I2CS] 02 62 1C F3 17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6

Wed 04/04/2012 09:48:54 PM : [iNST-ACK    ] 02 62 1C.F3.17 1F 09 01 00 00 00 00 00 00 00 00 00 00 00 00 00 F6 06 LNK-ON (01)

Wed 04/04/2012 09:48:54 PM : [iNST-SRX    ] 02 50 1C.F3.17 1B.FD.23 2B 09 01    LNK-ON (01)

Wed 04/04/2012 09:48:54 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Wed 04/04/2012 09:48:54 PM : [LNK-BGN     ] 02 64 01 00 06 

Wed 04/04/2012 09:49:26 PM : [        Time] 21:49:26 0(0)

Link to comment
Share on other sites

“Can you use auto-detect to link new I2CS modules in V3.2.2?â€

 

I used Auto Discover with an I2CS FanLinc.

 

The event trace shows the I2CS ApplianceLinc and PLM did not complete an exchange. This is what should have happened…

 

Fri 03/16/2012 06:55:49 PM : [LNK-BGN ] 02 64 01 00 06

 

Fri 03/16/2012 06:55:50 PM : [LNK-STAT ] 02 53 M(01) gid=00 14.9E.F5 012E 41

 

Note the 02 53 response from the PLM identifying the FanLinc Insteon address, cat/subcat and firmware level.

 

This does not appear in the posted event trace. I would try moving the ApplianceLinc closer to the PLM but I don’t see a comm issue up front as the previous commands sent to the ApplianceLinc worked fine.

 

What is the PLM firmware level?

Link to comment
Share on other sites

Hi LeeG,

I do not think this would be an network communication reliability issue. When I linked it manually all the comm was very good and the process completed very fast. If it would not have linked manually I would have put the device right next to the PLM just to be sure, but manual link worked great ( as best as I can tell).

 

I was short on time as it was bed time last night and I expected the process to only take 5 minutes.. I will delete it and try auto-Discover once again tonight.

 

I am unsure of firmware level but I just replaced the PLM a few weeks ago. I believe it is V99 firmware.

 

Now you have me thinking...

As we introduce I2CS devices how does that work without upgrading the PLM to be I2CS compatible?

 

When I have time I am reviewing the successful manual link log. It looks like the get engine request returned an "0x02" in cmd2. Guess this must indicate I2CS device?

 

I just looked at the failed attempt and the get engine returned 0xFF in cmd2?

Link to comment
Share on other sites

A 0x02 indicates an I2CS device. I don't think it is a comm issue either. The PLM does not require any changes that I am aware of to support I2CS. All the commands needed have been there, just not needed in this sequence to get a device added to the ISY (or any other application for that matter). Might try a PLM power cycle the next time. The commands being executed to add an I2CS device should produce the same results as if a manual Set button link was being generated. Only being done programmatically without need to press any Set buttons.

 

Do you know if the FanLinc that was added is an I2CS device? The FanLincs I purchased when they first came out are not I2CS. The later ones at Rev 1.05 v.41 are I2CS. If the FanLinc is I2CS and it added successfully with Auto Discover that clears the PLM. I do not think this is a PLM issue unless it was in a bad mode because of some power glitch that also hung up the ISY.

Link to comment
Share on other sites

LeeG,

I do not know if my Fanlinc was I2CS. I do not think it was but I will check on that. I never attempted to add it to my ISY prior to upgrading to 3.2.2 , ... knowing that I needed that version.

 

I did power cycle both the PLM and ISY before my second failed attempt last night.

 

I had some time so I tried communicating to the new Appliancelinc with my ELAM (isolated bench test). As expected it gets response messages (to a direct msg send) but they are not acted on since the ELAM is not in the I2CS devices link data base. When I added the ELAM to its (appliancelinc) link record then the direct commands were accepted and acted on.

 

What this allowed me to see is that if the device is not in the link record the response sets the MSB of the flags (broadcast/NAK bit), Flag byte =0xA1. It also puts a 0xFF in the Cmd 2 byte.

 

So what is very interesting is when compared to my original failed log, ... The I2CS appliancelinc returned the 0xFF in cmd2 but it DID NOT set the NAK bit ??? This seems to be an inconsistency?

Link to comment
Share on other sites

I have tried several times to upgrade from 3.1.17 to 3.2.2 and run into the following errors:

 

Upgrade process went to 8%, then failed with the following two errors:

 

1 - Upgrade falled: failed uploading file (reported written size is invalid)

2 - Socket timeout error

 

Downloaded the file 3 times, but upgrade generated the same error each time.

 

Environment:

Windows XP Pro SP3

Java SE 6 1.6.0_31-b05

ISY 99i/IR Pro

Networking and Mobilinc modules

 

Any ideas on how to resolve this?

Link to comment
Share on other sites

Did the ELAM issue a 0x0D command? The FanLinc does NAK the 0x0D command, the event trace would indicate the ApplianceLinc does not NAK that command.

 

The ISY took the 0xFF as an I2CS indicator and issued the I2 command to put the ApplianceLinc into linking mode which worked as the ApplianceLinc LED started to blink. The PLM command 02 64 should have generated the PLM side of the link with an exchange of information from the ApplianceLinc to the PLM with the ApplianceLinc address, cat/subcat and firmware information. That exchange appears not to have happened since the PLM command did not issue the 02 53 response.

 

I’ll be gone for a few hours this afternoon. Think I will order a new ApplianceLinc when I get back.

Link to comment
Share on other sites

Did the ELAM issue a 0x0D command? The FanLinc does NAK the 0x0D command, the event trace would indicate the ApplianceLinc does not NAK that command.

 

Yes LeeG the ELAM issues the 0x0D command.

I will attempt the auto-discover again this evening.

 

here is the beginning of the log from my third attempt last night, using manual linking.

Wed 04/04/2012 10:29:55 PM : ---- Initializing the linked devices ----

Wed 04/04/2012 10:29:55 PM : ---- All Linked Devices are now initialized ----

Wed 04/04/2012 10:29:55 PM : ---- Add remaining devices ----
												                    // Flags ..         get engine
Wed 04/04/2012 10:29:55 PM : [iNST-TX-I1  ] 02 62    1C F3 17                0F           0D 00

Wed 04/04/2012 10:29:55 PM : [iNST-ACK    ] 02 62    1C.F3.17                0F           0D 00     06                 (00)
																				// I2CS = 02
Wed 04/04/2012 10:29:57 PM : [iNST-SRX    ] 02 50    1C.F3.17   1B.FD.23     2B            0D    02           (02)

Wed 04/04/2012 10:29:57 PM : [standard-Direct Ack][1C.F3.17-->ISY/PLM Group=0] Max Hops=3, Hops Left=2

Wed 04/04/2012 10:29:57 PM : [1C F3 17 0  ] Calibrating engine version

Wed 04/04/2012 10:29:57 PM : [  1C F3 17 1] Adding device to ISY t=02.0C.0000

Wed 04/04/2012 10:29:57 PM : [1C F3 17 1  ] Start : Adding device to ISY

Wed 04/04/2012 10:29:57 PM : [1C F3 17 1  ] Finish : Adding device to ISY was Successful

No nak bit and a valid "0x02" response. This makes me think that the appliance link must have been "aware" or at least partially linked from the previous 2 attempts?

 

I will do a factory reset before any further attempts tonight.

Link to comment
Share on other sites

Hello GMD99,

 

Do you have any firewall software on your computer. Some firewall software prevent your computer to communicate with devices that are not in their trusted zone.

 

You might want to try https://your.isy.ip address instead. Some firewall software are more lenient on HTTPS communications.

 

With kind regards,

Michel

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