rccoleman

Right. Query only gets the current status from the device (on/off, open/closed, dim level, etc.) and isn’t like an ‘ingest’ command that pulls in the existing links. You can have the ISY parse existing links when you first link a device, but it’s problematic and not recommended.

You’re correct in that that program is disabled and won’t trigger automatically, but I can watch the status update in the admin console, and I don’t think the ‘status’ in the ‘if’ is sending a query. In part because queries don’t work, as we’ve been discussing. My Alexa routine also appears to work without any program at all. I just set up the sensor device in the portal and my Dot announces when the door opens and closes. I’ll do some more research, but I’m pretty sure that it’s reporting the status. Okay, this works fine for me. I get an instant notification via a network resource when my garage door opens and when it closes. New Program - [ID 00A1][Parent 0001] If 'Devices / Garage / Garage Door Sensor' is switched On And 'Devices / Garage / Garage Door Sensor' is not switched Off Then Resource 'Garage Door Closed' Else Resource 'Garage Door Open' Here's a pic of the bottom of my MIMOLite and the wiring for my switch and sensor (from the outside, at least). Here's the info from the sensor node: Mon 11/26/2018 04:39:47 PM : [UZW-CMD 51 ] [ZWCMD cmd.51] Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] ---------------------------------------------- Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] Garage Door Sensor Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] ZW016_104 uid=16 type=4.16.0 mid=132 tid=1107 pid=273 model=11 Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] ZW016_1 - Primary Isy Node Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x72 V1 MANUFACTURER_SPECIFIC Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x86 V1 VERSION Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x71 V1 NOTIFICATION Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x30 V1 SENSOR_BINARY Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x31 V1 SENSOR_MULTILEVEL Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x35 V1 METER_PULSE Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x70 V1 CONFIGURATION Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x85 V1 ASSOCIATION Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - x25 V1 SWITCH_BINARY Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] - Secure Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] Mon 11/26/2018 04:39:55 PM : [ZW-SHOW ] ---------------------------------------------- Mon 11/26/2018 04:39:55 PM : [UZW-CMD 37 ] Show All Node Details : ZW016_104 Parameter 8 is set to "3", which means that both bits 0 and 1 are 1. Both bits are described here, but basically they both need to be 1 for the sensor to report digital values (0/1), rather than analog. https://www.cd-jackson.com/zwave_device_uploads/219/tech-appendix-mimolite-05may2015.pdf I was also getting unsolicited reports from the multi-level sensor, so I disabled those via parameter 9 (set to 0).

I don't think I did anything special when I added it. I might have done this: This is assuming that the MIMOlite configuration parameter 8 is set to ‘digital’ (b0 = 1) That's just setting a configuration parameter by right-clicking on the sensor node.

That's the same error message that's in the second thread that I linked to. It's been happening since I got the device, and definitely since 5.0.13 because I reported it here. I don't recall if I had to do anything special to get instant status. Here's a program that I use to tell me when my garage door is open: Garage Door Open - [ID 004A][Parent 0051][Not Enabled] If 'Devices / Garage / Garage Door Sensor' Status is Off Then Set Elk Speak Phrase 'Miscellaneous 1 ' Set 'Devices / Garage / Garage Door Switch' On Else - No Actions - (To add one, press 'Action') Note that it's disabled, but it works fine when I run it as part of my "good night" routine, and I don't think it kicks off a query. I also have Alexa routines that monitor the MIMOLite to tell me if my garage door opens or closes and a nearby Dot announces it. No queries there that I'm aware of. Here's a blurb from their FAQ:

I assume that it's the curl command, which basically lets you initiate lots of different network requests from the command line. I use a MIMOLite for my garage door and it automatically reports status. I do have some trouble getting the status to sync up after I reboot the ISY, but I suspect that's due to the query issue that I mentioned here, and earlier in one of the ISY 5.0.x release threads.

The best way to approach this is to configure everything through the ISY, rather than doing it manually. If the keypad and switches have never been added to the ISY at all, you will need to put the ISY into linking mode and hit the set button once for each device, but future programming can be done hands-off. This is really how the ISY is intended to work, allows you a lot more flexibility down the road, and doesn't have any obvious downsides. Having links outside of the ISY's purview is generally discouraged, and rarely, if ever, adds any value. Note that creating a scene in the ISY to allow a keypad button to remotely control a switch (as it sounds like you're doing) doesn't require or involve the ISY during operation - the ISY will just create a native link between the devices and the keypad will talk directly to the switch without going through the ISY. The only difference from what you're doing now is that additional links will be created from each device back to the ISY so that the ISY can also control the devices and can receive status changes from them. I recommend spending the effort to the add those devices to the ISY (which does require access to the device, and pressing the "set" button), clear all of the existing links while doing so, and re-build the links by using the ISY.

Since both the keypad and SwitchLincs are line-powered, there's no need to manually press the set button or touch any of the devices. Everything can set up through the Admin Console, either by creating a scene with the keypad buttons and SwitchLincs or by using a program that triggers when keypad buttons are pressed, and the ISY will take care of programming the links automatically. When you say that restoring the KeypadLinc "did not solve the problem", what was the problem? Did everything work properly in the past? How are the keypad and switches associated in the Admin Console? If you manually linked the devices in the past by pressing the set button, I recommend removing all pre-existing links and setting everything in the ISY via scenes or programs. All of that can be done without physically touching the devices.

I used acetate-free nail polish remover to clean them off. Works fast and does a great job.

Yeah, the Alexa apps are weird like that. Some things only show up in the web app (forget offline devices), some things only in the mobile apps (Routines), and apparently some of the mobile apps are different.

Glad to help. To get the URLs to call for in/out, just log into the portal, go to Tools->Node Server->Occupancy, and click the arrow/"share" button to the left of the phone name (second line for me).

The occupancy node is just a node controlled by the Portal that you can change by sending a REST call. You still need an app to make that REST call based on your location. I use Locative for that. There’s an Android app that UDI commissioned to do that, but I don’t think there’s an equivalent iOS app at this time.

Which app are you using to trigger the occupancy node? I'm using Locative and it's working fine on both an iPhone X and XS Max running iOS 12.0. No changes required.

I think this started to be a problem with the migration to the ISY Launcher, which dynamically downloads the admin/dashboard version required. Going back to the old way, as @MWareman describes, is the workaround.

@BigRic Make sure you have a good, recent backup. I had to pull the power on my ISY a few times due to lockups and it eventually started corrupting (truncating) files. Once that happens, future backups will fail, and you'll either need to solve the problem yourself (replace the file from an older backup, like I did) or you may just lose all recent changes.

I don't really know how to answer that, other than to provide the log. The only thing that I see is that the Z-Uno temp sensor, which is asynchronously reporting it's temperature every 5 seconds until it reaches the target temp, all seem to be bunched together. That's a little weird because I can usually watch it report at 5 second intervals, so I don't know what might have caused them to all be reported at once (other than the other discussion that we're having in the other thread, perhaps). To be clear, I set a parameter that tells the temp sensor to start reporting at 5 second intervals when I want hot water, and I tell it to stop when it reaches the right temp (between 1 and 3 mins). I bolded the line around the first "queue full" line in the error log. I'm just surprised that it didn't recover eventually and keeps spewing errors in the error log.

Yes, the Alexa app indicates that the Echo heard the right thing every time. The error log does appear to be interesting. I started getting these errors right around the time of the failed Alexa commands, and they're actually continuing through today, despite the fact that my Alexa commands and everything else is working fine. Mon 2018/09/03 08:15:57 AM System -170001 [TCP-Conn] -6/-140002, Net Module Rule: 33 Mon 2018/09/03 08:16:15 AM System -170001 [UDSockets] HTTP:29 error:6 Mon 2018/09/03 11:50:45 AM System -170001 [TCP-Conn] -6/-140002, Net Module Rule: 32 Mon 2018/09/03 11:52:21 AM System -170001 [TCP-Conn] -6/-140002, Net Module Rule: 33 Mon 2018/09/03 03:34:54 PM System -170001 [TCP-Conn] -6/-140002, Net Module Rule: 32 Mon 2018/09/03 04:15:00 PM System -170001 [TCP-Conn] -6/-140002, Net Module Rule: 33 Mon 2018/09/03 09:29:50 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 06:52:32 PM System -5012 96 Mon 2018/09/03 09:24:52 PM System -170001 [UDSockets] RSub:22 error:6 Mon 2018/09/03 09:24:57 PM System -5012 87 Mon 2018/09/03 09:30:01 PM System -170001 [TCP-Conn] -6/-140002, Net Module Rule: 32 Mon 2018/09/03 09:35:01 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:35:37 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:41:09 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:52:12 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:52:54 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:53:04 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:53:14 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:53:25 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:53:35 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:53:56 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:54:06 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:54:16 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:55:09 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:55:19 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:55:29 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:57:30 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 09:57:40 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:03:54 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:04:04 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:04:14 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:03:04 PM System -5011 uuid:0 Mon 2018/09/03 10:04:27 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:04:32 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:04:38 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:04:43 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:04:49 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:04:54 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:04:56 PM System -5006 uuid:0 Mon 2018/09/03 10:05:00 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:05 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:11 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:16 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:22 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:27 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:33 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:38 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:44 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:49 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:05:55 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:00 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:06 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:11 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:17 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:22 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:36 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:06:29 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:34 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:39 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:44 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:46 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:06:56 PM System -170001 UDQ: Queue(s) Full, message ignored Mon 2018/09/03 10:06:49 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:06:55 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:00 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:06 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:07 PM System -5006 uuid:0 Mon 2018/09/03 10:07:15 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:21 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:26 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:32 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:37 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:43 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:48 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:07:54 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:00 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:05 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:11 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:16 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:17 PM System -5006 uuid:0 Mon 2018/09/03 10:08:22 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:27 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:33 PM System -170001 [UDSockets] PSub:42 error:6 Mon 2018/09/03 10:08:38 PM System -170001 [UDSockets] PSub:42 error:6 I'm still getting these "error:6" messages every 5-10s this morning. Is that the connection to the portal? At the time, and even now, the portal lists my ISY as online. Here's the tail end of the error log: Wed 2018/09/05 09:02:07 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:12 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:17 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:22 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:27 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:32 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:37 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:42 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:47 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:52 AM System -170001 [UDSockets] PSub:42 error:6 Wed 2018/09/05 09:02:59 AM System -170001 [UDSockets] PSub:42 error:6 Is there any more useful data to be collected on the ISY for this? I'm tempted to reboot to get it out of whatever state it's in, even though it seems to be working.

The issue with ‘good morning’ turned out to be self inflicted when I ‘forgot’ all of my devices and rediscovered them the night before in an attempt to fix the ‘not responding’ issue. That erased the actions in all of my routines and I had to add them back. That’s working now. I really don’t think this is a connectivity problem. I’m using a fully updated, high quality pfSense router and there was no evidence of connectivity issues at the time. In any case, it hasn’t recurred and I’ll do more investigation if it happens again.

This was pretty bad last night and this morning, to the point that I ended up using the keypad in my bedroom instead. Last night, I kept getting "Downstairs lights are not responding" over and over again with it not actually turning off the lights, and then it finally worked after 10-15 mins or so. In the morning, it acted like it recognized "Good Morning", but did nothing over several attempts. I eventually just hit the keypad button that runs the exact same program and it worked immediately. Has anyone else had issues with Alexa in the last 12-24 hours? None of my devices are showing "offline" at alexa.amazon.com, and weren't last night.

This works great. Highly recommended.

If it works like other geofence apps, which are based on the OS location service, it uses cell geolocation to get a rough approximation and to see if GPS is necessary for a more granular result. I use location-based reminders and Locative on my iPhone every day and it doesn’t meaningfully affect my battery life.

You mean outside of the beta? It may still be available as part of the beta.

Interesting! I had both an online and an offline version of "bathroom sink", so I forgot the offline version and I'll keep an eye on it. Thanks for the tip.

I just had this happen again. I said ‘turn on the bathroom sink’, my hot water recirculator turned on as programmed, the Echo’s light ring spun for several more seconds, and then the Echo said ‘sorry, I can’t find a device named bathroom sink in Robert’s profile’. Like before, the command worked, but I also got an error message that doesn’t make any sense. I confirmed that the Echo heard the right command by reviewing the history in the app. This is after unlinking and relinking the v3 skill, and discovering devices, which I did a month or so ago.

I thought that I had saved an event log somewhere, but it looks like it was just the log and error log. Like I said, it would really helpful if I could just point the ISY at my local syslog server (my Synology NAS) and log events that way. For something that's so useful while debugging, they're quite ephemeral and easy to lose.

I considered that and did a heal, but it didn’t help. I then unplugged and plugged back in the sirens that act as repeaters, re-ran the heal, and it still didn’t help. Hopefully all of that is still in the log. I’ll see if I can find anything. Heals tend to show a number of failures because almost all of my Z-Wave devices are battery-operated and fail to wake up for the heal. I have several gen 5 sirens that form the mesh and don’t see a connectivity problem outside of this instance. Edit: I do see the heal attempts in the log and error log, but no indication of any device failures. Is any interesting information Event Viewer lost by rebooting the ISY later? Event Viewer history goes back to when I opened the admin console last night, after I had everything working again. If I could log Event Viewer messages to my syslog server, it would make it a lot easier to capture these failures. The heal shows up in my error log like this: Thu 2018/08/16 05:42:07 PM System -170001 <s:Envelope><s:Body><u:HealNetwork xmlns:u="urn Thu 2018/08/16 05:42:07 PM System -170001 [HTTP:0-41]: POST[1]-->/services Thu 2018/08/16 05:42:07 PM System -170001 <s:Envelope><s:Body><u:GetSystemStatus xmlns:u= Thu 2018/08/16 05:42:26 PM System -170001 [HTTP:0-29-5] 192.168.1.244:35162->80 But at the time, it seems to proceed as expected and it completed. I tried it several times without a change to the "route can't be found" message for only my secure devices.