Support Thread: 5.0.16C (ISY994)

[simplextech]

54 minutes ago, dbuss said:

@simplextech, my experience with Elk wireless sensors is they are very reliable but the response time was much slower than Insteon response time in similar situations. 

In all cases I want reliability.  I only have 2 areas where I care about "speed" and that is relative.  1 second or below as long as it's consistent and doesn't swing upwards to 3-5 like I've had with Insteon I would be happy.  1 area reliability is critical of reporting correctly (Bathroom).  I use the sensor to verify occupancy if there's no motion as a secondary if the door is closed do NOT turn off the light.  The other areas for lighting control and that's where speed is important but it doesn't matter how fast they are if they don't report correctly half the time.

[blueman2]

3 hours ago, simplextech said:

This may or may not be a "C" related issue.  However I now have open/close sensors that are not updating as in they show "Open" as ON when they are Closed.  Something is not updating correctly or maybe it's just a Insteon Sensor mess with these newer open/close sensors.  I've always had minor issues with them not updating correctly so it may not be a FW related item but I thought I'd put it out there in case others have similar issues.

Have you tried looking at the other nodes of the device in ISY?  I too had this problem in the past, but was always able to use a different node.  For example, Open node was always on.  But Closed node worked correctly.  So I just used Close node for all my programs.  Not sure this will help you, but just an idea.  

[simplextech]

10 minutes ago, blueman2 said:

Have you tried looking at the other nodes of the device in ISY?  I too had this problem in the past, but was always able to use a different node.  For example, Open node was always on.  But Closed node worked correctly.  So I just used Close node for all my programs.  Not sure this will help you, but just an idea.  

I have not gone through and checked that.... However as lucky as I am guess what... another sensor is reporting Open ON and the door is closed... because it's freezing outside so why would it be open

I'll open the AC and check and maybe have to work around this.  However there is no work around when using 2 nodes for scene capabilities to get super fast reaction for lighting... so that kills my use of scenes for lighting with those doors.... as those are the one's being problems.

argh......

So I just check the Dining Room door that's showing on...

Open node = On

Closed node = Off

So the whole sensor both nodes are just screwy not reporting correctly.  I've watched it do this multiple times today already.  Practically every other time that door is opened to let the dog or cat out it reports wrong.

[firstone]

3 hours ago, simplextech said:

I'm about a year into the new open/close sensors and I've had nothing but problems with them from the very beginning... I'm looking for alternatives.  I don't want to go z-wave and litter the house with plugs just to have a mesh so I'm really debating installing an ELK panel just to have ELK wireless sensors.  Problem is that's a high cost going blind without having some to verify and make sure they work reliably and consistent.  I want below 1 second response time and reliable if the door is open or closed I want to know so I can run my programs and not have to guess or see on my dashboard that something is showing open when I know it's closed which then screws up the programs.

I'd been using open / close sensor (2 parts one, not hidden switch) for a few years with no issues whatsoever. That was before .16 though.

 

[simplextech]

18 minutes ago, firstone said:

I'd been using open / close sensor (2 parts one, not hidden switch) for a few years with no issues whatsoever. That was before .16 though.

 

Most have.  I think it's the "new" versions that I have issues with.  Nobody else that I know and I've asked a couple other friends and they have the older versions that they have no problems and they're great.  Mine are all of the new version and they are just "iffy".  Most of the time they are fine.  Every now and again they go wonky like today.  Which... reminds me I think I'll change the battery as that often times fixes their "wonky" behavior....

[firstone]

4 hours ago, simplextech said:

Most have.  I think it's the "new" versions that I have issues with.  Nobody else that I know and I've asked a couple other friends and they have the older versions that they have no problems and they're great.  Mine are all of the new version and they are just "iffy".  Most of the time they are fine.  Every now and again they go wonky like today.  Which... reminds me I think I'll change the battery as that often times fixes their "wonky" behavior....

Well, I have several sensors I've bought on black friday and but didn't get a chance to set them up. I will do it and will report.

[simplextech]

33 minutes ago, firstone said:

Well, I have several sensors I've bought on black friday and but didn't get a chance to set them up. I will do it and will report.

Please let me know what your outcome is.  I'm hoping maybe I have a couple bad sensors as that's the easy fix.

[Mustang65]

I just got back from Chicago and noticed that there is a 5.0.16C available now. I take it from the posts that the 2843 modules are still reporting false "Open", even in .16C. I had to get on line in Chicago because my mailbox 2843 was malfunctioning more than the normal and disabled it. I put a new battery in it prior to heading up north, so that is not the issue. I now have all 10 2843 sensors disabled. Down to SimpliSafe with "Alarm" only as I dropped the interactive "Alerts" to use the Insteon sensors on the perimeter entry points (gates, screen doors....). Thinking about reinstating the SimpliSafe interactive and reinstalling their sensors (Alert's) on the gates.... Will probably just wait for good news on newer ISY updates before going to the new version.

[Techman]

All my 2843 sensors are now working correctly after updating to 5.0.16C

[firstone]

13 hours ago, simplextech said:

Please let me know what your outcome is.  I'm hoping maybe I have a couple bad sensors as that's the easy fix.

I've tried a couple. Both seem to work fine with C.

[simplextech]

41 minutes ago, firstone said:

I've tried a couple. Both seem to work fine with C.

Mine work "fine" most of the time as well.  I have a couple that periodically don't respond for whatever reason.  I have them setup in programs to turn on lights when the door is opened.  Doors to garage and to the deck.

Issue 1 from previous post about the 1 that was false reporting on... actually was not a false alert.  I went and inspected it later and found that the door was in fact open but just a little.  Which was odd and I commented to my wife because she was the one that opened/closed the door.... CLOSE THE DOOR!!

Issue that has been a long standing item is the program to turn on lights does not always run and many times has a very slow response.  Open door and sometimes the lights are on fast and other times there's a 3-5 second delay and then sometimes nothing.  No lights.  Close door and re-open and things work.  I'm thinking in this case it's either some communications issue or something that is freaking annoying which is why it's so random for the not working but for the slow 3-5 seconds I don't know what this was from.  I've disabled some extra processing in my ISY to reduce load and see if that helps....

[hart2hart]

PROBLEMS with 5.0.16C after upgrade
1. Upon opening admin console I got an Zwave error message showing an Insteon address. I have no idea what the message is referring to.
2. On several of my programs an Insteon address was replaced by another Insteon address ( IOLinc was replaced with an ON/OFF module address)
 

Did the addresses correct when you reloaded the console?

[Techman]

I don't believe so, but I'm not sure.

What happened is that I had an on/off module that I hadn't assigned a unique name to so it displayed only it's Insteon address. The module appeared at the top of my device list.  Later in the day I noticed one of several programs weren't functioning. When I took  look at the programs I noticed that an IOLinc had been replaced by the on/off module.

I have a large number of programs and haven't checked them all but so far this seems to be isolated to one set of programs that were controlled by the IOLinc

 

[PPatla]

I loaded 15B and had devices dropping out and programs not running.

I went to 15C and had a hard time getting the devices back in the tree where I had to do Restore Device multiple times to get it to take.

My programs are quite simple and are very inconsistent now, I never had any communication issues in the past and no new devices or changes have occured to my house config. 

I'm a 100% insteon network

Everything seems to have bigger delays than before.

I'm thinking of starting from scratch and going back to 4.7.3 never had and issue and I'm not sure I need any new features.

P2

[Craigb]

I installed 5.0.16C (previously was on 5.0.16B)

Upon first login into the AC (using Launcher, and it showed correct version) I received a "Can not communicate with <device> "which is an Insteon ApplianceLink 2456S3 - v.42.  This is the only unit of this model in my system - all the rest are of newer vintage.

This device was seen properly for status by the ISY/PLM immediately before the upgrade.

The Appliance Link still responds to the KPL button it's scene is controlled by.

I cannot control device from device page of ISY or from scene page of ISY - however the scene on-off commands do change the state of the KPL button. The device and scene pages show no status for the ApplianceLink.

I tried a Write Updates to Device. - it runs a progress box but doesn't write anything to the ApplianceLink

I tried a Restore Device - The event viewer shows:

But there is no writing of restore data.

I've not seen this behavior before.

I also have a 2456S3B v.39 ApplianceLink, which continues to work properly with the ISY/PLM.

Each restart of AC gives the same "can not communicate with" message, and the device does not respond to AC commands for scene or device.

All other powered Insteon devices (Appliance, Dimmer modules, Dimmer switches, KPL's, Fan controllers)  appear to be working with AC/ISY/PLM correctly.

Not sure if this is due to the Upgrade or something else.  Its getting late here, I'll poke at it again tomorrow, as this device isn't scheduled in any programs tonight.

 

Edited January 30, 2020 by Craigb

[Techman]

1 hour ago, Craigb said:

I installed 5.0.16C (previously was on 5.0.16B)

Upon first login into the AC (using Launcher, and it showed correct version) I received a "Can not communicate with <device> "which is an Insteon ApplianceLink 2456S3 - v.42.  This is the only unit of this model in my system - all the rest are of newer vintage.

This device was seen properly for status by the ISY/PLM immediately before the upgrade.

The Appliance Link still responds to the KPL button it's scene is controlled by.

I cannot control device from device page of ISY or from scene page of ISY - however the scene on-off commands do change the state of the KPL button. The device and scene pages show no status for the ApplianceLink.

I tried a Write Updates to Device. - it runs a progress box but doesn't write anything to the ApplianceLink

I tried a Restore Device - The event viewer shows:

But there is no writing of restore data.

I've not seen this behavior before.

I also have a 2456S3B v.39 ApplianceLink, which continues to work properly with the ISY/PLM.

Each restart of AC gives the same "can not communicate with" message, and the device does not respond to AC commands for scene or device.

All other powered Insteon devices (Appliance, Dimmer modules, Dimmer switches, KPL's, Fan controllers)  appear to be working with AC/ISY/PLM correctly.

Not sure if this is due to the Upgrade or something else.  Its getting late here, I'll poke at it again tomorrow, as this device isn't scheduled in any programs tonight.

 

It's possible that the device's memory got corrupted. Do a factory reset on the device then a restore device.

[grumpy]

@Craigb

I have two of the ApplianceLinc 2456S3 - v.42  working with 5.0.16C .Don't see any communication errors and they respond to the commands, can read the link table etc..

No errors after a restart

Those modules are not dual band. I would suggest a module factory reset and move them to a different location for a test ( closer to the plm) and try again.

If they work after this, than you can redo the scenes etc...

[KeviNH]

I have a two Honeywell  Z-Wave thermostats (YTH8320ZW1007), they've been stable for years (running 4.x with Z-wave version 4.55 on original Z-wave module)

Upgraded from 4.7.3 to 5.0.16B.   Next day, one thermostat gave a "Communications Lost" message (on the thermostat's LCD), and also a Schlage lock disappeared from the ISY console.

Upgraded to 5.0.16C and I got the Schlage back, but now both Honeywell Z-Wave thermostats sporadically fail with "Communications Lost";  power-cycling the thermostat brings it back online.

[Craigb]

21 hours ago, grumpy said:

@Craigb

I have two of the ApplianceLinc 2456S3 - v.42  working with 5.0.16C .Don't see any communication errors and they respond to the commands, can read the link table etc..

No errors after a restart

Those modules are not dual band. I would suggest a module factory reset and move them to a different location for a test ( closer to the plm) and try again.

If they work after this, than you can redo the scenes etc...

I'm aware that these are power line only.  The ApplianceLink is plugged into the same circuit as the PLM, in the next outlet box on the wiring chain. If it were any closer to the PLM, it would have to be on a cube tap with the PLM.  I'll give that a try, and when I get  a moment I'll pull all PLM links, but I don't expect that anything in the PLM changed as part of the upgrade.
I didn't get more time to work on this tonight, so I'll get more time to troubleshoot this coming weekend.

[Whitehambone]

If this has been covered, I am sorry I missed it.  I might have a bug or something wrong.  Perhaps I have two problems, or they are related.  I had experienced this before and thought I might have done something wrong.  But recently, it happened again as I was testing PiCamMonitor by @markv58.  If you have Blue Iris software, you should check out PiCamMonitor; even my wife loves it.

I created a simple program that calls for PiCamMonitor, pretty simple.  But it stopped working, and the log in PiCamMonitor was not getting any request.  I could see the Blue Iris Nodes changing status in the ISY, and I could set the PiCamMonitor features manually from the ISY.  Then I remember I had this issue before.  I changed all the Blue Iris Node values to FALSE in the IF statement and saved the program.  Then flipped them back to TRUE and saved again.  Problem solved – the program works.  Has anyone else experienced this issue?  I had it happen one other time with a porch light.  Took me a long time to figure it out. 

The above happened in 5.0.16b and another previous version that I can’t remember.  Also every time I open the Admin Console, go to programs and hit save, I get this:

It happens on v 5.0.16b and 5.0.16c for me.  It also happens if I open the Admin Console, modify a program, and hit save.  It first tells me it is deleting a program and then saving.  It will not happen again until I re-open the Admin Console.  I have seen it on different computers as well.  

[larryllix]

25 minutes ago, Whitehambone said:

If this has been covered, I am sorry I missed it.  I might have a bug or something wrong.  Perhaps I have two problems, or they are related.  I had experienced this before and thought I might have done something wrong.  But recently, it happened again as I was testing PiCamMonitor by @markv58.  If you have Blue Iris software, you should check out PiCamMonitor; even my wife loves it.

I created a simple program that calls for PiCamMonitor, pretty simple.  But it stopped working, and the log in PiCamMonitor was not getting any request.  I could see the Blue Iris Nodes changing status in the ISY, and I could set the PiCamMonitor features manually from the ISY.  Then I remember I had this issue before.  I changed all the Blue Iris Node values to FALSE in the IF statement and saved the program.  Then flipped them back to TRUE and saved again.  Problem solved – the program works.  Has anyone else experienced this issue?  I had it happen one other time with a porch light.  Took me a long time to figure it out. 

The above happened in 5.0.16b and another previous version that I can’t remember.  Also every time I open the Admin Console, go to programs and hit save, I get this:

It happens on v 5.0.16b and 5.0.16c for me.  It also happens if I open the Admin Console, modify a program, and hit save.  It first tells me it is deleting a program and then saving.  It will not happen again until I re-open the Admin Console.  I have seen it on different computers as well.  

Save has flashed that message "Deleting 1 programs" since ISY V3. Apparently it is a side effect to do with the way the messages are displayed from java and does no harm. Nothing is being deleted.

[Craigb]

Follow up on my post earlier this week concerning 2856S3 and 2856S3B not communicating with ISY after update to 5.0.16C

First:

I rolled back to 5.0.16B.  No change to behavior of the 2856S3, and now the 2856S3B was now also flagged by the ISY as being not in communication. Both units were still fully controlled by both dual-band and power-line only KPL's. The non-dual-band KPL is plugged into the same outlet as the PLM.

I moved both units to the same plug (using a cube tap) as the PLM.  No Change.  Attempts to restore these devices from ISY AC results in "0 bytes written to device" in the event viewer.

Next:

I removed the devices from ISY, factory reset them, and re-included them to the ISY. They now work correctly.

So:

I re-updated to 5.0.16C.  The 2856S3 and 2856S3B appear to be working properly, although the ISY intermittently  reports losing communication with them.

This PLM (v9B) has been updated with the power supply fix from 2014 at the link below.  It doesn't appear to be failing, but perhaps I'll swap it out later.

 

 I can only guess that the PLM tables for these device became corrupt at some point, because all KPL's (both dual band and power-line only) were able to control these units (prior to the reset) via the scenes each were enrolled in.

 

 

[larryllix]

3 hours ago, Craigb said:

Follow up on my post earlier this week concerning 2856S3 and 2856S3B not communicating with ISY after update to 5.0.16C

First:

I rolled back to 5.0.16B.  No change to behavior of the 2856S3, and now the 2856S3B was now also flagged by the ISY as being not in communication. Both units were still fully controlled by both dual-band and power-line only KPL's. The non-dual-band KPL is plugged into the same outlet as the PLM.

I moved both units to the same plug (using a cube tap) as the PLM.  No Change.  Attempts to restore these devices from ISY AC results in "0 bytes written to device" in the event viewer.

Next:

I removed the devices from ISY, factory reset them, and re-included them to the ISY. They now work correctly.

So:

I re-updated to 5.0.16C.  The 2856S3 and 2856S3B appear to be working properly, although the ISY intermittently  reports losing communication with them.

This PLM (v9B) has been updated with the power supply fix from 2014 at the link below.  It doesn't appear to be failing, but perhaps I'll swap it out later.

 

 I can only guess that the PLM tables for these device became corrupt at some point, because all KPL's (both dual band and power-line only) were able to control these units (prior to the reset) via the scenes each were enrolled in.

 

 

The PLM is a dual band device receiving RF signals also. If you plug in a device with a magnetic power supply (coils and transformers) and/or blast very strong Insteon signals into it,  in the same receptacle, you may saturate the inputs and make it blind to other devices or even the device sharing the receptacle. Try a medium length extension cord maybe.

[grumpy]

@Craigb

These modules (none dual-band)  may not communicate directly with the PLM  if they are set on a different  “ phase ” of the electrical system.

They would rely on the mesh or cascading  network provided by the other modules. You can set the PLM in => Phase Detection Mode to do a test.

You might have to move the modules to an other ac receptacle for the test. Otherwise a bad mesh component might be corrupted or electrical interference

power bars filtering ...etc.

[jaygroh]

I just updated to this version from the 4.x branch and I'm having several issues. Several of my programs no longer work. Mostly the ones based on time of day, sunrise to sunset. It may be because of the way I was changing scenes during these times.

Example.

scene has a keypad and an inline dimmer controlled by a motion sensor 2.

UsBathroomDay - [ID 0024][Parent 0021]

If
        From    Sunrise
        To      Sunset  (same day)
 
Then
       
        // In Scene 'MotionSensors / MO-UsBathroom-Sensor' Set 'Keypads / KPD-UsBathroom' OL 255
        // In Scene 'MotionSensors / MO-UsBathroom-Sensor' Set 'InlineDevices / ILD-UsBathroomCab' OL 255
 
        In 'MotionSensors / MO-UsBathRoom-Motion' Set 'InlineDevices / ILD-UsBathroomCab' To 100% in 0.5 seconds, No retries
        In 'MotionSensors / MO-UsBathRoom-Motion' Set 'Keypads / KPD-UsBathroom' To 100% in 0.5 seconds, No retries
 
Else
   - No Actions - (To add one, press 'Action')

You can see that the upgrade commented out the original program. I then tried to recreate it which is what you see. I have another similar program for night time with the lights dimmed sunset to sunrise next day.

UsBathroomNightDim - [ID 0026][Parent 0021]

If
        From    Sunset 
        To      Sunrise (next day)
    And $UsBathroom is 0
 
Then
        
        // In Scene 'MotionSensors / MO-UsBathroom-Sensor' Set 'InlineDevices / ILD-UsBathroomCab' OL 12
 
        
        // In Scene 'MotionSensors / MO-UsBathroom-Sensor' Set 'Keypads / KPD-UsBathroom' OL 0
 
        In 'MotionSensors / MO-UsBathRoom-Motion' Set 'Keypads / KPD-UsBathroom' To Off in 0.5 seconds, No retries
        In 'MotionSensors / MO-UsBathRoom-Motion' Set 'InlineDevices / ILD-UsBathroomCab' To 25% in 0.5 seconds, No retries
 
Else
   - No Actions - (To add one, press 'Action')
 

In the night time program I also have another program set to turn the lights full on when requested from a switch which is why the variable is in the IF statement.

This is just an example and I've been playing around with it trying to make it work. As of this post I dont know if I got it working right.

When adjusting a scene in a program there are options I'm not sure on how to set correctly. There is Scene, Controller, Set, and To. I get the Scene, Set, and To is used for but why specify a controller? Is the above code the correct way to adjust a scene?

Is there any new documentation on how to use the new firmware programming? Maybe some examples?

Next issue is that my IRlinc transmitter no longer responds at all. I've tried resetting it and adding it back but when I send an On command nothing happens. I only have it setup to turn on and off my TV. It does respond to the local button press but it does not respond from a scene.

Here is my error log. Its filled with this "-170001    [ZBSEP] Cannot query meter" message. The regular log does not show a command for the IRlinc was ever sent.

Sun 2020/02/02 14:43:17    System    -170001    [ZBSEP] Cannot query meter
Sun 2020/02/02 14:43:23    System    -5006    uuid:34
Sun 2020/02/02 14:43:28    System    -5006    uuid:34
Sun 2020/02/02 14:43:37    System    -170001    [ZBSEP] Cannot query meter
Sun 2020/02/02 14:43:57    System    -170001    [ZBSEP] Cannot query meter
Sun 2020/02/02 14:44:18    System    -170001    [ZBSEP] Cannot query meter
Sun 2020/02/02 14:44:37    System    -170001    [ZBSEP] Cannot query meter
Sun 2020/02/02 14:44:57    System    -170001    [ZBSEP] Cannot query meter
Sun 2020/02/02 14:45:15    System    -5012    35

 

 

Edited February 2, 2020 by jaygroh