rccoleman

I'm just trying out some Z-Wave plug-in modules (these) and the delay introduced by the roundtrip to the ISY is immediately noticeable compared my original Insteon setup (which was instantaneous using native links). The sequencing of "on" and "off" for each device is clear if I create a separate scene with only two plug-in modules and turn the scene on and off, while turning each device on or off independently via the admin console is essentially instantaneous. There are no configuration parameters in these modules and they're not dimmers, so I don't think there's anything that I can do to improve the scene response time. I started to look at the actual Z-Wave traffic and I wonder if the sequence within the ISY can be optimized. Here's what the sequence looks like: I believe that the two first two bolded lines are the points at which the ISY tells each switch to turn on, and they do both appear to happen within a second of each other. Still, it looks like the ISY, after turning on the switch, immediately queries it and waits for a response before moving on to the next switch. I wonder if the response time could be improved by either moving the status check to the end (after setting all devices in the scene to their new states) or even completely eliminating it. Or perhaps there something else that I could tweak? Since these are Z-Wave Plus switches, I think they subsequently report their status themselves in the last two bolded lines, making the manual queries unnecessary. Maybe the easiest thing to do is to recognize when a device is Z-Wave Plus, know that it will report its own status asynchronously, and skip the query in that case. The best case would be central scene support, where I believe the Z-Wave devices would operate more like Insteon. The delay is certainly noticeable in a scene including only two Z-Wave modules, but is more irritating and looks more amateurish as I include more devices. I have a scene in my living room that includes an Insteon SwitchLinc and 3 plug-in modules, and it takes a few seconds for all the lights to independently turn on. It adds up. I have a pretty good mesh now, I’ve healed many times, the routes seem reasonable (1-2 hops from the ISY), and controlling the modules individually is fast, so I don’t think there’s anything deficient about my Z-Wave network.

This sounds a lot like the issue I reported back in 5.0.13, but with a simpler setup: I added a few new Z-Wave devices tonight and watched the ISY freeze and then rapidly process all of the backed events several times.

I mentioned it in the 5.0.14 thread, but I've had good luck just copying the file from an old backup onto the SD card. I couldn't back up my ISY because of a 0-length .REC file that had apparently become corrupt and copying a good version fixed it. Once you do that and have a current backup, I'd switch to a new SD card and restore that backup.

I tried a couple of different Estimote models and found them to be completely unreliable for location. I have them in a bag for the next electronics recycling event. They’re really sold as a dev kit for building a more complete solution, so they don’t really have a support plan for consumers.

The Locative iOS app with its built-in geofence + notification through the ISY portal has been working so well for me that I don't even think about it anymore. It just works, even though the app is no longer supported. It sounds like the main differences for your solution are: You can use some other hardware that may provide more accurate geofencing or quicker reporting. The effectiveness of phone geofencing is somewhat related to the quality of the app (it'll fail if it crashes in the background), so I suppose that I can see the value in using different hardware if you can't get what you need from the phone in your pocket. You host servers that serve as an intermediary/translator between the GPS/sensor device and the HA system (such as the ISY). From the perspective of the ISY portal, which already supports direct URL calls to change states, I don't really understand the value that offers beyond just having the device talk directly to the endpoint (ISY/ISY portal). Locative allows the user to specify a URL to call when crossing the boundary, and it sounds like you assume that any compatible device has a similar capability?

This is interesting. So without any IR hardware, I could just create fake Hue bulbs and use a Hue device on the Harmony to control them? And then trigger programs based on state transitions?

Here's my Query All program: Query All - [ID 00A0][Parent 0001] If Time is 3:00:00AM Then Set 'ISY' Query Else - No Actions - (To add one, press 'Action') Factory Query Program I renamed the top of my node tree to "ISY", but I think it starts as "My Devices" or something like that.

I think he's talking about the program that runs every morning at 3am or so to query devices. The "query" command stopped working somewhere in 5.0.13 and was fixed in 5.0.14, so I wonder if that somehow caused the program to disappear. Like you said, it's easy to replace.

It would be awesome if it were possible to trigger on button presses using the Harmony Hub node server. Right now, the only hooks are commands to the hub or triggering on starting or ending an activity.

Ah, my apologies. I see the keypad and function keys at the bottom. I’ll have to try the arm/bypass thing when I get home.

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.