rccoleman

The things I mentioned, but unless you know of a way to do them And I'm specifically talking about Mobilinc here, so it's possible that the ISY exposes some things that Mobilinc or Agave don't use.

Orchestrated, but I don't use it very often and very rarely on the iPad, so I haven't done much to customize it or use the more complex features. Mobilinc looks nice, but I prefer Agave overall because it's more intuitive for me. eKeypad lets you control individual keypads from the app, activate function keys, bypass/un-bypass zones, etc. The ISY exposes the features that you're actually likely to use on a daily basis, but it is missing some more esoteric options.

Which version of Mobilinc? I have it on both my iPhone and iPad, and I'm using the latest version of each from the app store. Both have similar-looking and acting Elk support. Note this is just talking to Elk through the ISY, which somewhat limits what it can do, and Agave does the same thing (which also has Elk support). You can arm the alarm in several modes, disarm it, and see the state of the alarm and the zones and outputs, but it's not at the same level of eKeypad, which talks directly to the Elk.

Yes, iOS Mobilinc has an Elk plugin.

So you start and stop that program from somewhere else, considering that it has no "if" clause? It sounds like a limitation or flakiness in the text message (SMS) relay for your cell service provider. I assume that it's going through an email relay, so you could test it yourself from any email client to see if you can reproduce the failures. Also, it's a little simpler to use "Repeat every 30 mins" as the first line and get rid of the wait/run combo.

Great, thanks for the confirmation Michel.

Fair enough, but that implies that it either doesn’t store those values or that the mechanism is broken because they just show up as zero, regardless of what was last set. Is that the intended behavior?

Good to know about the beep. The backlight level, which was what the original poster was asking about, does work (I can see the LEDs change brightness when I change the percentage), but the backlight level will always be shown as 0% when I open the admin console. It's not a good user experience and is not consistent with the state of the device, so that's why I called it a bug and responded to the OP as I did. I'm guessing that the default value is around 50% for the switch that I'm looking at based on visual inspection, but I don't think there's an easy way to know for sure. Maybe by dumping and decoding the links in the admin console, but it's possible (even likely) that the memory address that the admin console is modifying isn't part of a link and is just inaccessible to normal humans. The bottom line is that if I click on "query" with a device highlighted in the admin console, I expect it to read and populate all of the values from the device, just as I can set them through that same interface, and it doesn't. That's the main point that I'm trying to get across, and I hope that the UI of the upcoming non-Java interface is more consistent. I don't really expect anything like this to get fixed in the current Java version.

Set the beep or backlight level to something non-zero, observe that the values are written to the device, close and reopen the admin console, and notice that the values that you set are now reported to be zero.

Be that as it may, it seems misleading that you can change the value and it clearly writes to the device, but then displays zero the next time the admin console starts. Some of the fields reflect the current values and others do not. To answer the OP’s question, it seems like there’s no way to get the current value.

Weird. It looks like the "beep" and "backlight" values aren't refreshed when re-opening the admin console or querying the device, but the others (on-level, ramp rate, current level) are. I think that's a bug. Here's what I get when I query the device, but I don't have enough experience to know what's actually contained in the response. Perhaps other commands need to be issued to pull those values. I started perusing this, but there's a lot to digest. Sun 12/30/2018 01:36:56 PM : [INST-TX-I1 ] 02 62 41 29 7E 0F 19 00 Sun 12/30/2018 01:36:56 PM : [INST-ACK ] 02 62 41.29.7E 0F 19 00 06 LTSREQ (LIGHT) Sun 12/30/2018 01:36:56 PM : [INST-SRX ] 02 50 41.29.7E 3D.95.02 2F 00 0D (0D) Sun 12/30/2018 01:36:56 PM : [Std-Direct Ack] 41.29.7E-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 Edit: it looks like it's just ready and writing a memory location in the switch: Sun 12/30/2018 01:48:16 PM : [All ] Writing 1 bytes to devices Sun 12/30/2018 01:48:16 PM : [41 29 7E 1 ] Memory : Write dbAddr=0x0264 [0C] cmd1=0x2E cmd2=0x00 Sun 12/30/2018 01:48:16 PM : [INST-TX-I2CS] 02 62 41 29 7E 1F 2E 00 00 07 0C 00 00 00 00 00 00 00 00 00 00 BF Sun 12/30/2018 01:48:16 PM : [INST-ACK ] 02 62 41.29.7E 1F 2E 00 00 07 0C 00 00 00 00 00 00 00 00 00 00 BF 06 (00) Sun 12/30/2018 01:48:16 PM : [INST-SRX ] 02 50 41.29.7E 3D.95.02 2F 2E 00 (00) Sun 12/30/2018 01:48:16 PM : [Std-Direct Ack] 41.29.7E-->ISY/PLM Group=0, Max Hops=3, Hops Left=3 But I don't see any attempt to read specific memory locations during a query, and I suspect it's not done when the admin console opens. @Michel Kohanim, do you agree?

Or query the device, presumably, which should happen automatically every night and when the ISY boots (if you have that selected).

It looks like that field should reflect the current value, as well as letting you change it. It writes to the device when I change the value and I expect that whatever's stored in the device is reflected in the admin console.

Can you successfully update it by right-clicking, selecting "write changes", and waking it up? If it keeps switching into "I need to be updated" mode every day, are you using the "adjust scene" functionality in a program to change the way it responds? If so, that will unfortunately and mistakenly (in my opinion) mark the motion sensor as needing an update every time and you won't be able to easily clear that state. I just turn off writes to battery-operated devices to prevent the ISY from getting stuck trying to update my motion sensors.

The ISY won’t talk directly to any sort of beacon, which work via Bluetooth. You’d need an app on your phone like Locative (no longer being developed, but still available and working) to see the beacon and tell the ISY via a REST call. In theory, it should work with strategic beacon placement and tuning of the beacon signal strength. In reality, beacons have only led to frustration for me and I’ve abandoned them as anything but a curiosity. They’re just not at all reliable for me.

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