rccoleman

I just had a really weird thing happen. My various Z-Wave locks, motion sensors, etc. have been working fine with the new dongle and 5.0.13C for a while, but today they all stopped working. The event viewer log for each one showed the ISY trying to wake it up, it failed to get a response, retried a few times, and gave up. I rebooted my ISY and that brought the non-secure devices back (a temp sensor and my motions sensors started working), but my three Kwikset locks still failed with the same symptom. I did a "Show all info" on each one and all returned what looked like good data, but it said that the last known route couldn't be found for each one. I manually pulled the power on the ISY for 30s or so, powered it back on, and it was still giving inaccurate route info. I restored the Z-Wave backup that I made the last time I added a device, rebooted the ISY, and now everything is working again (including proper route information for my locks). So, I recommend making a Z-Wave backup right now if you haven't already, but I don't really know what happened in my case. @Michel Kohanim Is there something interesting that I can look for in my error log? There's a lot in there and I can't really tell what's important.

It's a standard Wiki feature that lets users discuss the page contents. Here's an example on Wikipedia:

That would depend on the capabilities and settings of your sensors. My motion sensors default to sending an ‘off’ command after 2 min, but I reconfigure them to only send ‘on’ when they see motion and never ‘off’. This keeps the lights on as long as I’m in the room, and I use a program to start a timer to turn the lights off whenever they turn on. That way, you get the best-instant on with a more flexible ‘off’ program. Edit: and to be clear, there’s no way to code any sort of timer logic into the scene itself. It’s just going to react to what your motion sensors do.

I can't speak to the spontaneous reboot (nothing on my box), but perhaps the strange responses from your Google Home device are related to similar ones from Amazon Echos/Dots: I unlinked and relinked my Smart Home skill and I've gotten a "not responding" once after a long delay.

Yep, just like that. You need to finesse the old board out because the LED protrudes a bit through the case and resists extraction, but the new board does not have an LED and is an easier fit.

Mine came with nothing but the board in an envelope. Yes, you need to unscrew the case of the ISY, pull out the board, remove the old Z-Wave module (connected via a row of pins plugging into the main board horizontally) and plug the new module into the lower-row of the connector on the main board. The Z-Wave board and the main board should be on the same plane when you're finished. Edit: Obviously unplug everything from the ISY first

That confused me too. It stores it internally and restores from the saved file - you’ll never see it.

If you are interested, please send an email:To: sales@universal-devices.comSubject: Z-Wave 500 Series BetaBody: Your address

Done, and will report back. May take a few days or even a week to know for sure.

I just enabled ‘brief mode’ on Friday after being prompted, and this was happening well before that for me.

Yes, I checked right after each instance and it heard the right thing.

I have that happen from time to time, and I suspect that one possibility is that the ISY being busy with other things and the action is simply delayed. One of my new Z-Wave devices puts the ISY into a constant state of activity (separate post), and I noticed that that caused this same symptom: I'd get an "ok", nothing would happen for a while, and then the correct action would finally happen after a minute or so. When I've had it happen in the past (before I got that device), I often checked the Alexa app for what it heard and it would sometimes hear something else (Light instead of Downstairs Lights, for example). Other times, it heard the right thing, said "ok", and then apparently did nothing. In any case, it's interesting that two completely opposite issues seems to be happening - error message despite the correct action happening, and "ok" with no action.

Because lights turn on, my alarm arms, my water recirculator turns on, all as expected. All indications are that the programs and devices respond, but my Echos/Dots tell me that something's wrong. Like I said, only happens 20-30% of the time. Maybe less often, but happened last night and this morning with different messages.

I use my fleet of Echos to control much of my home automation and the voice recognition success rate has gone way up compared to a year ago. Within the last few weeks, though, I'm starting to get some weird error messages despite the commands doing exactly what they're supposed to. When I issue a command, the light ring spins for a bit, whatever activity I asked for starts, the light ring spins a bit more, and I get a "Sorry, xxx is not responding" or (this morning) "Sorry, I can't find a device named xxx in your profile". I've made no changes to my Echo setup in the ISY portal for a while, and the only recent change was updating to 5.0.13A. I get these weird responses maybe 20-30% of the time now, but like I said, the ISY programs/scenes are triggered as expected. Is something strange going on with the portal or Echo integration, or does it have something to do with 5.0.13A?

To add a data point here, here's the info from one of my Kwikset locks with a route through an Aeotec Gen 5 Siren: Sat 07/14/2018 09:51:40 AM : [UZW-CMD 51 ] [ZWCMD cmd.51] Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] ---------------------------------------------- Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Front Door Lock Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] ZW006_1 uid=6 type=4.64.3 mid=144 tid=1 pid=1 model=4 Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x72 V1 MANUFACTURER_SPECIFIC Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x86 V1 VERSION Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x98 V1 SECURITY Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Secure Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x72 V1 MANUFACTURER_SPECIFIC Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x86 V1 VERSION Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x98 V1 SECURITY Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x80 V1 BATTERY Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x85 V1 ASSOCIATION Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x70 V1 CONFIGURATION Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x75 V1 PROTECTION Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x62 V1 DOOR_LOCK Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x63 V1 USER_CODE Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x4E V2 SCHEDULE_ENTRY_LOCK Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x4C V1 DOOR_LOCK_LOGGING Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x71 V1 NOTIFICATION Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x8B V1 TIME_PARAMETERS Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x20 V1 BASIC Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - x5D V2 ANTITHEFT Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - xEF V0 MARK Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Last working route from ISY to Node 6 - Front Door Lock Sat 07/14/2018 09:51:40 AM : [ZWAVE-TX ] [01040092066F] REQ ZW_GET_LAST_WORKING_ROUTE Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Node 3 - ZW 003 Siren Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Sat 07/14/2018 09:51:40 AM : [ZWAVE-TX ] [01070080060000FE80] REQ ZW_GET_ROUTING_INFO Sat 07/14/2018 09:51:40 AM : [ZWAVE-TX ] [01070080060100FF80] REQ ZW_GET_ROUTING_INFO Sat 07/14/2018 09:51:40 AM : [ZWAVE-TX ] [01070080060001EB94] REQ ZW_GET_ROUTING_INFO Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Node 6 - Front Door Lock has the following neighbors Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - - Node 3 - ZW 003 Siren Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Repeater - Node 14 - ZW 014 Siren Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Repeater - Node 16 - Garage Door Switch Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Repeater - Node 18 - ZW 018 Siren Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Repeater - Node 27 - ZW 027 Siren Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Sat 07/14/2018 09:51:40 AM : [ZWAVE-TE ] [85/05] Assoc Groupings Get ACK,AUTO,EXPLORE To=0x06 Sat 07/14/2018 09:51:40 AM : [ZWAVE-TX ZW006_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE To=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-RX ZW006_1] [98/80] Security Nonce Report - nonce=[A083C2D396F13CA8] ACK,AUTO,EXPLORE From=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-RX ZW006_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE From=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-TX ] ... Sat 07/14/2018 09:51:41 AM : [ZWAVE-RD ] [010A001306038506012500AB] REQ ZW_SEND_DATA Sat 07/14/2018 09:51:41 AM : [ZW-SHOW ] Node 6 - Front Door Lock has 1 association group Sat 07/14/2018 09:51:41 AM : [ZWAVE-TE ] [85/02] Assoc Get grp=0x01 ACK,AUTO,EXPLORE To=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-TX ZW006_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE To=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-RX ZW006_1] [98/80] Security Nonce Report - nonce=[B25A2BFFCC959687] ACK,AUTO,EXPLORE From=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-RX ZW006_1] [98/40] Security Nonce Get ACK,AUTO,EXPLORE From=0x06 Sat 07/14/2018 09:51:41 AM : [ZWAVE-TX ] ... Sat 07/14/2018 09:51:41 AM : [ZWAVE-RD ] [010D001306068503010500012500B4] REQ ZW_SEND_DATA Sat 07/14/2018 09:51:41 AM : [ZW-SHOW ] Associations for group 001 of ZW006_1 Front Door Lock Sat 07/14/2018 09:51:41 AM : [ZW-SHOW ] Max Associations = 5 Sat 07/14/2018 09:51:41 AM : [ZW-SHOW ] - Node 1 - [This ISY] Sat 07/14/2018 09:51:41 AM : [ZW-SHOW ] Sat 07/14/2018 09:51:41 AM : [ZW-SHOW ] ---------------------------------------------- Sat 07/14/2018 09:51:41 AM : [UZW-CMD 37 ] Show All Node Details : ZW006_1 Here's the snippet that shows the "last working route": Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] Last working route from ISY to Node 6 - Front Door Lock Sat 07/14/2018 09:51:40 AM : [ZWAVE-TX ] [01040092066F] REQ ZW_GET_LAST_WORKING_ROUTE Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ] - Node 3 - ZW 003 Siren Sat 07/14/2018 09:51:40 AM : [ZW-SHOW ]

I was afraid of that, but my three Kwikset locks (2 914 and 1 910) work fine with just a restore. All are securely included.

Correct.

I can confirm that all of my functionality worked without needing to do a Heal, and it all still worked after doing a Heal.

All good here. As before, I have to manually query my three Kwikset locks before I can see the state, battery status, or lock/unlock them. After I run a query, they work fine. I still get a "Request Failed" when querying my MIMOlite sensor/relay, but I mentioned that in the 5.0.13A thread.

Will the Java cache be a problem? Or is that now handled in some way via the Launcher?

Full or Normal? I'm in the middle of "Full", but wanted to clarify.

Locative has been working for me for a couple of years now with only minimal babysitting. It used to crash sometimes when issuing the portal REST call and that would stop it from running in the background and monitoring the location, but that hasn't happened in a long time. I found its beacon support to be worthless for anything approaching a geofence and gave up after trying a few different types of beacons. The beacons are now just sitting in a bag at home waiting for me to come up with another project.

I do exactly what paulbates does - Locative + portal occupancy node. Works great.

Correct. The main thing to keep in mind is that there are controllers, which send commands to other devices and are colored red in the AC, and responders, which react to commands and are colored blue. Some devices can be both controllers and responders in the same scene (switches are a good example), and will be colored red. If you click on a controller (red) device in a scene, you can see and set the levels of all responder devices in that scene if you turn that controller "on" (such as a keypad/remote button, or wall switch). Each controller in a scene can have a different set of levels for each responder or responder/controller in that scene, and you can use "adjust scene" to programmatically adjust those levels or do it manually in the AC This, for instance, lets you have a different set of levels for a light switch vs. a remote in the same scene. This is now clearly laid out in 5.0.12 when you select "Adjust Scene" in a program (in scene w, controller x, set y to z). It was more confusing in previous versions. The PLM itself also acts as a controller for all of the scenes managed by the ISY, and that's what you're looking at when you click the scene name in the AC. You'll see the levels that will be applied when you send "on" to the scene itself, manually in the AC or via a program. There are a couple of different ways that you can go if you want to have a switch act differently at different times Write a program that looks for the switch to change state and turn on a scene that's configured as you want (and yes, you can have multiple scenes with different settings for the same responders) Create a scene with that switch and any responders (lights, for instance) and use a program to adjust the scene as necessary. This is what I did in the program that I pointed to earlier. If you're still confused and have a specific use case that you're trying to solve, please describe it and I'll try to help. Rob