Chris Jahn Posted November 25, 2020 Posted November 25, 2020 Please note: As part of Z-Wave Certification, the ISY-994 5.x series no longer supports the 300 Series Z-Wave board. Please check your upgrade discount eligibility and ordering instructions. If you have any other questions, please submit a support ticket Hello, The 5.3.1 *Test Build* is now available. As part of Z-Wave Plus certification, some incompatible changes were made that may cause issues when migrating from older versions of the ISY. We are looking at mitigating these issues in future builds. If you have a stable working system, you may want to wait before migrating. Guides Z-Wave Plus for ISY-994 Getting Started Z-Wave Plus for ISY-994 User Guide Z-Wave Plus for ISY-994 Advanced User Guide Notes - Upgrading to this version may require a lot of manual intervention including verifying scenes, programs and program settings are correct. In some cases it will be easier to rebuild your network. - If you are rebuilding your Z-Wave network, it is recommended that you Factory Reset the Z-Wave dongle prior to adding devices back into your Z-Wave network. - If you are upgrading from version 5.0.10 or earlier then Devices and programs are migrated in the current version. After upgrading: o Please ensure your device nodes and programs are correct; in some cases you may need to update them. o Wakeup your battery devices after the ISY has restarted and the initial query has finished - If you are upgrading from version 5.0.8 or earlier, you will have to manually update the Adjust Scene entries in all of your programs. - Starting in version 5.0.15A, the event value for the Low status of Insteon FanLinc Motor changed from 63 to 64 - If you have the climate module, please go here to choose a new weather service. Important User/Password changes: - If your current version is 5.0.7 or earlier, then after installing 5.0.8 or later your userid and password will be reset back to the system default. - If you restore a backup created from 5.0.7 or earlier, your userid and password will be reset back to the system default. - If you downgrade from version 5.0.8 or later to version 5.0.7 or earlier then after installing version 5.0.7 or earlier, you will have to Factory Reset the ISY and optionally install a backup taken in that version or earlier. Java runtime memory (when Admin Console is very slow to respond) - If the admin console is slow to respond, it is likely you need to increase the amount of memory allocated to the Java runtime (JRE). - Open the Java Control Panel, select Java tab, press View button, then add or modify the Runtime Parameter -Xmx to the following: o -Xmx512m - Press Ok to close the window, then Press Apply to save the changes Fixes in this build: 0000773 - Some 300 Series Z-Wave backups cannot be restored on 500 Series 0000772 - Elk turns Insteon Lamp to 50% instead of 100% 0000770 - Support old lock notification values 0000769 - Insteon NLS missing some nodedef names 0000767 - Fix invalid UTF-8 special characters in some units of measure 0000766 - Associations not allowed for some older devices Notes: - SSLv3 is now disabled. All models now support TLS1.2 and high grade cipher suites - 4.1.1 backups may corrupt Z-Wave configuration in case they are restored. 4.1.2 and above releases fix this issue - See our Wiki for additional information (e.g. Program Variables) Prerequisites: - You must use the 5.0.9 Admin Console or greater to upgrade to this release (5.3.0). - If you are migrating from 5.0.8 or older than in the Admin Console, you will have to manually close the Initialization progress bar - The latest release of Java must be installed - If you are using MAC Yosemite and Java 1.8.40, please follow these instructions Install: 1. Backup your ISY (File | Backup ISY) - Do not backup from a version 3.1.6, or 4.1.1 system (there were bugs in those versions that caused the backup to be corrupted) 2. Make sure you have done everything in the Prerequisites section 3. Download firmware - ISY 994i Series including Z-Wave support - ISY 994i ZW, Z, or ZS Series (Z-Wave/Zigbee and/or if you do NOT have a PLM) 4. Login to the Admin Console and choose Help | Manually Upgrade [the name of your system] 5. Choose the file downloaded in step 3 6. After the upgrade, You must clear your Java Cache 7. Launch the 5.3.0 Admin Console and/or Dashboard by going to the following link: - https://isy.universal-devices.com/start.jnlp Note: If you have version 5.0.8 or lower installed on your ISY, then use this link instead: - http://isy.universal-devices.com/994i/5.3.1/admin.jnlp Note: MAC 10.6.x users must use the following links instead - http://isy.universal-devices.com/994i/5.3.1/admin16.jnlp (Admin Console) - http://isy.universal-devices.com/994i/5.3.1/dashboard16.jnlp (Dashboard) 8. To launch the Admin Console directly from your ISY, go to the following link: - http://your.isy.ip.address/admin.jnlp 9. If you are using Z-Wave and upgrading from a 4.x.x or earlier version of the ISY, see Z-Wave migration from 4.x.x branch below 10. Backup your ISY (File | Backup ISY) Z-Wave migration from 4.x.x branch All Z-Wave nodes will be recreated when migrating from 4.x.x. Some nodes will have different addresses, and some devices will have a different set of nodes. In some cases, it is easier to rebuild your network rather than migrate. 1. Before moving to 5.3.0, in 4.x.x, Backup your Z-Wave Dongle and then Backup your ISY. 2. Replace the 300 Series Z-Wave board in your ISY with a 500 Series Board 3. Install 5.3.0 4. Start the Admin Console and Restore the Z-Wave dongle (will take the Z-Wave network you backed up in step 1, and writes it to the new 500 series board) 5. Do Z-Wave -> Synchronize Nodes -> All - Do not open ‘Programs’ tab until step 6. - This will add back all of the ISY nodes that were deleted at startup. - If you have multichannel devices, you will see more nodes added - After sync is complete, restart the Admin Console and go to step 6. 6. Open the programs tab - Most old Z-Wave device actions/conditions are automatically converted to the 5.3.0 framework - Make sure to visually check all programs that contain Z-Wave device actions or conditions. - Programs containing nodes from multichannel devices will have to updated - Node addresses for multichannel devices change from ZW003_143 style to ZW003_002_143 (where _002_ is channel number) - If everything looks good, save the program changes made by the migration. 7. Make an ISY Backup 8. If you are missing any Z-Wave devices you may have to exclude/include them again. For battery devices, make sure they have communications turned on and try doing a synchronize again.
Bumbershoot Posted November 26, 2020 Posted November 26, 2020 I've got it running. Nothing unusual so far, but I'll watch my Schlage lock for anything unusual. The ability to set parameters for it is available in the AC. 53 minutes ago, Chris Jahn said: 0000770 - Support old lock notification values
asbril Posted November 26, 2020 Posted November 26, 2020 @Chris Jahn Did this upgrade address status vs control ?
blueman2 Posted November 26, 2020 Posted November 26, 2020 (edited) @Chris Jahn, I installed without issue. However, my devices that had the "GREEN 1011" label continue to have this label even after forcing writes. Example here is a Schlage BE469. It still thinks it has associations that are not written. Same with 2 other z-wave devices I have, not all of them locks. Events log attached. events.txt Edited November 26, 2020 by blueman2
WFP Posted November 27, 2020 Posted November 27, 2020 I am not sure if this is a 5.3.0 or a 5.3.1 change: I have programs that send me text alerts for my Schlage BE469ZP Locks. The Alerts tell me whether the lock was locked or unlocked User Number and Battery Level Type of action( Keypad, Manual, Automatic or Remote. I was using the "Basic" Node and the dropdown menu with a Control IF Statement For the Remote one, I used Status first and then a second (disabled) program to check if it was NOT, Manual, Keypad or Automatic. Now, it seems that the logic is being ignored. I probably have to use one of the newly added nodes since 5.3.0, specifically "Access Control" in the program. I Had the following simple program:If Control #Lock-Garage is Switched Alarm Unlocked by keypad Then (Send a text with a specific Configuration) I am changing it to:If Status of #Lock-Garage / #Lock-Garage Access Ctl Access Control is Keypad Unlock Then (Send a text with a specific Configuration) Will report back if it works. I think this is something I was not expecting but is probably the result of modifying the way ISY interfaces with Z-Wave devices now. I wonder what other easter eggs I can find if I dig into this further! Bill
Bumbershoot Posted November 27, 2020 Posted November 27, 2020 5 minutes ago, WFP said: I Had the following simple program:If Control #Lock-Garage is Switched Alarm Unlocked by keypad Then (Send a text with a specific Configuration) I've got a program doing this (Control instead of Status in the AC programming interface), and it still works. This program has been in place for quite a while. I think my lock is an older model that yours, and I don't have a Basic node. I'm not aware of any node changes due to migrating from 5.3.0 to 5.3.1. Garage Door Unlock - [ID 0109][Parent 0013] If 'Devices / dirGarage / ZW 024 Schlage Door Lock' is switched Alarm Unlocked by Keypad And 'Devices / dirGarage / ZW 024 Schlage Door Lock' User Number is not 0 And $s.Occupancy is 0 Then $i.LockUser = 'Devices / dirGarage / ZW 024 Schlage Door Lock' User Number $s.GarageDoorStatus = 0 Wait 5 seconds Send Notification to 'Admin' content 'Garage Door Lock' Else - No Actions - (To add one, press 'Action')
WFP Posted November 27, 2020 Posted November 27, 2020 (edited) 11 minutes ago, Bumbershoot said: I Thanks for pointing that out...I had not dug into it yet but see it now...I need to examine this more closely! Bill Edited November 27, 2020 by WFP
danbutter Posted November 27, 2020 Posted November 27, 2020 Upgraded this afternoon from 5.2.0 and still seeing the issues of on/off plugs not reflecting status when changed. This happens when hitting the button on the device itself as well as hitting the button in the AC. A query will instantly pop in with the correct status. This wasn't a problem before as I had programs to turn on certain things when my holiday plugs were turned on. The programs worked earlier this year before I upgraded to 5.2.0, but not since. Some of these plugs are the older zwave and some are zwave plus modules. If any specific info from them is needed I can provide it.
blueman2 Posted November 27, 2020 Posted November 27, 2020 12 minutes ago, danbutter said: Upgraded this afternoon from 5.2.0 and still seeing the issues of on/off plugs not reflecting status when changed. This happens when hitting the button on the device itself as well as hitting the button in the AC. A query will instantly pop in with the correct status. This wasn't a problem before as I had programs to turn on certain things when my holiday plugs were turned on. The programs worked earlier this year before I upgraded to 5.2.0, but not since. Some of these plugs are the older zwave and some are zwave plus modules. If any specific info from them is needed I can provide it. Did you try updating the association with the ISY by doing Z-wave | Repair Links? I had to do that with several older z-wave devices I had. 1
WFP Posted November 30, 2020 Posted November 30, 2020 (edited) Again, not sure if it was specific to 5.3.1 or 5.3.0, but I believe my program was working in 5.3.0 still. In my BE469ZP programs, I include Battery Life and the "Last User" information in my notifications: last user ${sys.node.ZW004_1.USRNUM} Now, it no longer reports the user number using that entry. Battery Life appears correct on Node ZW004_1. I ran a test on all six nodes and only the "Access Control" Node reports the User. or me it was assigned 306 in my Grouped Device Tree: last user ${sys.node.ZW004_306.USRNUM} For all I know, this is the proper way for the z-wave network to work but it does highlight the little changes that affect programs...that take some of us a lot longer to notice! /Bill Edited November 30, 2020 by WFP
Bumbershoot Posted November 30, 2020 Posted November 30, 2020 56 minutes ago, WFP said: Again, not sure if it was specific to 5.3.1 or 5.3.0, but I believe my program was working in 5.3.0 still. In my BE469ZP programs, I include Battery Life and the "Last User" information in my notifications: last user ${sys.node.ZW004_1.USRNUM} Now, it no longer reports the user number using that entry. Battery Life appears correct on Node ZW004_1. I ran a test on all six nodes and only the "Access Control" Node reports the User. or me it was assigned 306 in my Grouped Device Tree: last user ${sys.node.ZW004_306.USRNUM} For all I know, this is the proper way for the z-wave network to work but it does highlight the little changes that affect programs...that take some of us a lot longer to notice! /Bill I have a older lock (not Z-Wave Plus), and the "Last User" still appears in the primary node ZW024_1, not in node ZW024_306, which exists, but has never been populated with data. No breakage with this upgrade here. This probably illustrates why Z-Wave certification was difficult to achieve.
danbutter Posted November 30, 2020 Posted November 30, 2020 On 11/27/2020 at 4:25 PM, blueman2 said: Did you try updating the association with the ISY by doing Z-wave | Repair Links? I had to do that with several older z-wave devices I had. I have tried doing the repair links, I have tried Synchronize, I have tried update neighbors. I have updated Java and cleared the cache (did this before upgrading to 5.3.1) If I go to Help and about both firmware and UI are 5.3.1 No change. I just think it is crazy that even the UI doesn't know it changed when I just used the UI to change it.
lilyoyo1 Posted November 30, 2020 Posted November 30, 2020 On 11/27/2020 at 5:11 PM, danbutter said: Upgraded this afternoon from 5.2.0 and still seeing the issues of on/off plugs not reflecting status when changed. This happens when hitting the button on the device itself as well as hitting the button in the AC. A query will instantly pop in with the correct status. This wasn't a problem before as I had programs to turn on certain things when my holiday plugs were turned on. The programs worked earlier this year before I upgraded to 5.2.0, but not since. Some of these plugs are the older zwave and some are zwave plus modules. If any specific info from them is needed I can provide it. What are the exact model plugs you are having issues with
danbutter Posted December 2, 2020 Posted December 2, 2020 First one is an old aeon labs plugin on/off module. The paper that came with it says only Smart energy switch...Amazon says it is the Aeon Labs DSC06106-ZWUS. This is one that I had a holiday lights program that used this plug. The program would react to the turning on of this plug and then turn on other things. I have two of these and same thing with both. Node Dump of one of them: <node flag="128" nodeDefId="UZW001E"> <address>ZW003_1</address> <name>Living Holiday</name> <family>4</family> <parent type="3">13535</parent> <type>4.16.1.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>ZW003_1</pnode> <rpnode>ZW003_1</rpnode> <sgid>1</sgid> <custom flags="40" val1="0"/> <devtype> <gen>4.16.1</gen> <mfg>134.3.6</mfg> <cat>121</cat> </devtype> <ELK_ID>B13</ELK_ID> <property id="ST" value="0" formatted="Off" uom="78"/> </node> <node flag="0" nodeDefId="UZW001F"> <address>ZW003_143</address> <name>Living Holiday Power</name> <family>4</family> <parent type="3">13535</parent> <type>4.16.1.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>ZW003_1</pnode> <rpnode>ZW003_1</rpnode> <sgid>143</sgid> <custom flags="8" val1="0"/> <devtype> <gen>4.16.1</gen> <mfg>134.3.6</mfg> <cat>143</cat> </devtype> <ELK_ID>B14</ELK_ID> <property id="ST" value="0" formatted="0.000 Watts" uom="73" prec="3"/> </node> The second type is the HomeSeer Zwave Plus HS-PA100+ that they don't seem to make anymore. I have a few of these around the house and I know that the status was reflected in the AC before 5.2.0 <node flag="128" nodeDefId="UZW00BE"> <address>ZW028_1</address> <name>OfficeFan</name> <family>4</family> <parent type="3">28692</parent> <type>4.16.1.0</type> <enabled>true</enabled> <deviceClass>0</deviceClass> <wattage>0</wattage> <dcPeriod>0</dcPeriod> <startDelay>0</startDelay> <endDelay>0</endDelay> <pnode>ZW028_1</pnode> <rpnode>ZW028_1</rpnode> <sgid>1</sgid> <custom flags="40" val1="0"/> <devtype> <gen>4.16.1</gen> <mfg>388.17479.12337</mfg> <cat>121</cat> </devtype> <ELK_ID>L13</ELK_ID> <property id="ST" value="0" formatted="Off" uom="78"/> </node> Anything else I could provide that would help?
Chris Jahn Posted December 2, 2020 Author Posted December 2, 2020 29 minutes ago, danbutter said: First one is an old aeon labs plugin on/off module. The paper that came with it says only Smart energy switch...Amazon says it is the Aeon Labs DSC06106-ZWUS. This is one that I had a holiday lights program that used this plug. The program would react to the turning on of this plug and then turn on other things. I have two of these and same thing with both. Anything else I could provide that would help? Open the Admin Console Event Viewer to Level 1, clear it, and then right+click on the device and select Z-Wave | Show Information in Event Viewer | Link Details You should see something like the following. If you don't see [This ISY] then it is not associated with the ISY and the ISY will not be automatically updated with status .. in this case, try installing isy version 5.3.1 because it has a fix related to Associations that may fix this problem. After installing 5.3.1, do right+click on the device and select Z-Wave | Repair Links Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] ---------------------------------------------- Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] Node 2 - ZW 002 Remote has 1 association group Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] Associations for group 001 of ZW002_147 ZW 002 Binary Switch 1 Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] Max Associations = 5 Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] - Node 1 - [This ISY] Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] Wed 12/02/2020 11:16:46 AM : [ZW-SHOW ] ---------------------------------------------- 1
danbutter Posted December 3, 2020 Posted December 3, 2020 (edited) Thanks for the reply Chris. I am running 5.3.1 and I have already tried the repair links to no avail, but I haven't checked the association by looking in the event viewer. I'll do that tonight and report back. ---------------------------------EDIT---------------------------------- Okay I tried checking the link details and aside from the name of device of course...it looks identical to what you have posted. Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] ---------------------------------------------- Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] Node 3 - Living Holiday has 1 association group Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] Associations for group 001 of ZW003_1 Living Holiday Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] Max Associations = 5 Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] - Node 1 - [This ISY] Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] Sat 12/05/2020 11:12:02 AM : [ZW-SHOW ] ---------------------------------------------- Same with all the other plugs showing me issues. Any suggestions? Edited December 5, 2020 by danbutter Update
Niick_W Posted December 9, 2020 Posted December 9, 2020 (edited) I upgraded without any issues. I have noticed an odd thing, which may always have been there. When connected via websocket, when I receive a RR update (Ramp Rate) for a device of type RelayLampSwitch_ADV, the formatted value in the xml is incorrect. It shows the unformatted value, in this case 28, when it should be 0.5 seconds. eg: <?xml version="1.0"?><Event seqnum="225" sid="uuid:99"><control>RR</control><action uom="25" prec="0">28</action><node>33 20 55 1</node><eventInfo></eventInfo><fmtAct>28</fmtAct></Event> All other RR values (and other settings) are formatted correctly, it's just RelayLampSwitch_ADV which is wrong. It's annoying, as I'm using the `formatted` value to get the real world values for things (which works well), except for this one value that I have to put a trap in my program for (not that I use it, but it messes up my logic). Edited December 9, 2020 by Niick_W typos
asbril Posted December 10, 2020 Posted December 10, 2020 Yesterday I had an issue of a Zwave (GE/Jasco ZW+) switch no longer working in a program and I decided to remove and re-add the switch to my ISY. As the switch is located at the the other end of my home (kitchen), I removed it from the box and performed the remove/re-add close to the ISY (I have a special switch box for that purpose that I plug in). After re-adding to my ISY I replaced the switch in the kitchen and everything works fine, including in the original program. However I noticed in (right-click) Zwave-Show information in Event Viewer that the switch is still routing through the Zwave devices close to the ISY rather than those in between the kitchen and the ISY. I tried several times Update Neighbors, but each time this shows failed in the event viewer. As noted above, the switch works fine, but for the principle I wonder why I can not get it to go through the proper route. I may repeat the remove/re-add while keeping the switch in the kitchen, just to satisfy my OCD, but I wonder why the Update Neighbors does not work.
Niick_W Posted December 10, 2020 Posted December 10, 2020 I would leave it, Zwave networks sort themselves out in time. They usually run a "heal network" overnight which sorts the neighbors out.
asbril Posted December 10, 2020 Posted December 10, 2020 1 hour ago, Niick_W said: I would leave it, Zwave networks sort themselves out in time. They usually run a "heal network" overnight which sorts the neighbors out. As I said, everything works fine, but my (small) concern is why the update neighbors does not work. I actually believe that something is wrong with the switch as I had issues with it yesterday. That is why I removed it from my ISY and re-added it. If it gives me new issues, I may just replace it.
lilyoyo1 Posted December 10, 2020 Posted December 10, 2020 (edited) 1 hour ago, asbril said: Yesterday I had an issue of a Zwave (GE/Jasco ZW+) switch no longer working in a program and I decided to remove and re-add the switch to my ISY. As the switch is located at the the other end of my home (kitchen), I removed it from the box and performed the remove/re-add close to the ISY (I have a special switch box for that purpose that I plug in). After re-adding to my ISY I replaced the switch in the kitchen and everything works fine, including in the original program. However I noticed in (right-click) Zwave-Show information in Event Viewer that the switch is still routing through the Zwave devices close to the ISY rather than those in between the kitchen and the ISY. I tried several times Update Neighbors, but each time this shows failed in the event viewer. As noted above, the switch works fine, but for the principle I wonder why I can not get it to go through the proper route. I may repeat the remove/re-add while keeping the switch in the kitchen, just to satisfy my OCD, but I wonder why the Update Neighbors does not work. Id let the self healing take care of that. You should be able to use Network wide inclusion since you have plus devices. Make sure that is checked as well Edited December 10, 2020 by lilyoyo1 1
Niick_W Posted December 10, 2020 Posted December 10, 2020 (edited) Another odd thing I have noticed. When a switch (or motion sensor) is turned ON (and sometimes OFF) with the paddle you get two events like this (seqnum 911 and 915): <?xml version="1.0"?><Event seqnum="911" sid="uuid:114"><control>DON</control><action>0</action><node>34 CB 62 1</node><eventInfo></eventInfo></Event> [2020-12-10 12:19:51,134][DEBUG](pyisy ) Node 34 CB 62 1 (closetLight) received EVENT NodeProperty('34 CB 62 1': control='DON', value='0', prec='0', uom='', formatted='0') <?xml version="1.0"?><Event seqnum="912" sid="uuid:114"><control>ST</control><action uom="100" prec="0">255</action><node>34 CB 62 1</node><eventInfo></eventInfo><fmtAct>100%</fmtAct></Event> <?xml version="1.0"?><Event seqnum="913" sid="uuid:114"><control>_1</control><action>3</action><node></node><eventInfo>[ 34 CB 62 1] DON 0</eventInfo></Event> <?xml version="1.0"?><Event seqnum="914" sid="uuid:114"><control>_1</control><action>3</action><node></node><eventInfo>[ 34 CB 62 1] ST 255 (uom=100 prec=0)</eventInfo></Event> <?xml version="1.0"?><Event seqnum="915" sid="uuid:114"><control>DON</control><action>0</action><node>34 CB 62 1</node><eventInfo></eventInfo></Event> [2020-12-10 12:19:55,653][DEBUG](pyisy ) Node 34 CB 62 1 (closetLight) received EVENT NodeProperty('34 CB 62 1': control='DON', value='0', prec='0', uom='', formatted='0') The DEBUG output is my program (based on PyIsy), so that you can see the timing - there is about 4.5 seconds between the two events. I don't remember this happening before (but it's possible it was happening, and I just didn't notice). The event viewer does show the extra event (this is a different switch): Thu 12/10/2020 12:37:58 PM : [ 44 F0 C6 1] DOF 0 Thu 12/10/2020 12:37:58 PM : [ 44 F0 C6 1] ST 0 (uom=100 prec=0) Thu 12/10/2020 12:38:08 PM : [ 44 F0 C6 1] DON 0 Thu 12/10/2020 12:38:08 PM : [ 44 F0 C6 1] ST 255 (uom=100 prec=0) Thu 12/10/2020 12:38:15 PM : [ 44 F0 C6 1] DON 0 It's weirdly inconsistent, sometimes you get two OFF's, mostly you get two ON's. Is this another weird Insteon thing? or is the event getting duplicated somehow? This doesn't happen if you turn the switch ON/OFF with an insteon command, just with the paddle (because you get no EVENT reporting if you do that). It doesn't cause a big problem, as the ST value is only sent once, (and I mostly trigger off that), I do have some logic that looks for Faston/off events, and they trigger twice (but again it doesn't really matter). Just thought I would point out the odd double event triggering. Edited December 10, 2020 by Niick_W
danbutter Posted December 23, 2020 Posted December 23, 2020 Running 5.3.1 and can't remove a zwave device. Had a switch go bad but it still showed up on the zwave network so I excluded it successfully, but when I try to delete it it just says "Request Failed" and sits there with the Red Exclamation point. Is this a bug in 5.3.1?
Michel Kohanim Posted December 23, 2020 Posted December 23, 2020 @danbutter, Right mouse click | Z-Wave | Remove failed node. With kind regards, Michel
Recommended Posts