Lowes IRIS Transition

Hubitat never forces an upgrade. You're in control of the upgrade cycle. You can pick to be an over excited early adopter, or a late adopter. You can roll back, if you decide the release isn't for you.

Worth Mentioning:
Roll back will only roll you back to a version you did download/install. Your hub retains copies that it downloaded. Browse to {your hub address}:8081 to see the list known to your hub.

04%20PM

Releases are Announced here in the Community in the News and Updates Category under Announcements.

Additionally, a red dot will appear over the Messages Icon (Upper right, squarish message bubble.) The message will be.. there's an update. That dot does not appear rapidly. You won't be an early adopter if you wait for that Dot. :smiley:

And it will likely start a holy war if you suggest an "enhancement" to have updates installed automatically! This was one of the biggest problems with SmartThings. They would always push upgrades to the hub when I was out-of-town.

LOL, yeah, I agree that updates should be chosen, not forced. In the forum, I guess I haven't visited the front page recently where I would have seen the notice.

SO, it hasn't worked. I downloaded a backup, installed the new release, went to my keypad device page and hit "Configure" and a few other random buttons, and the thing is still flashing away. Worse, my brand new batteries are at 90% now.

And the logs are full of stuff like : " dev:1942019-02-25 03:59:09.079 pm debugdescMap: [raw:catchall: 0104 0020 01 01 0040 00 D3DC 01 00 0000 00 01 , profileId:0104, clusterId:0020, clusterInt:32, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:D3DC, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:01, data:[]]"

It has to be factory reset and rejoined, it's not something that can be fixed via configure, might as well wait for a soon to be released hot fix that also has a few minor updates for these older firmware keypads.

Gracias

As a general heads up on the v2 iris keypads, there appears to be an older firmware version (not updatable), that exhibits an issue with the radio and iris led staying on when operated from the keypad using exit delay settings.
This led issue also exists when used on the iris hub as well, the leds will extinguish if you activate the motion sensor, however I have not found anyway to prevent this while the device is commanded with the exit delay sounds.
These keypads also have an issue pairing on 2.0.5 such that there is no confirmation beep issued and those same panel indicators remain on unless the batteries are pulled and re inserted.

If someone in position of one of the keypads that does not exhibit this issue can let me know the firmware version thats listed in the iris app I may be able to at least prevent the indicators from staying on at the expense of no exit delay sounds for the effected firmware version devices.

1 Like

In HSM, can anyone explain the difference between "Disarmed" and "All Disarmed" If I select "Disarmed" is the siren still going to go off at some surprising moment?

If you're talking about the options as presented in a Dashboard tile for HSM, I see eight options (a bit overwhelming...), including "Disarm" and "Disarm All" that you might be talking about. The "Disarm" option is the one that undoes an Arm-Home, Arm-Away, or Arm-Night. The "Disarm All" option does that but also disables monitoring rules you might have for smoke, water, and or any custom events you can configure HSM to notify you about or otherwise act upon. If you're using it as a DIY security system, the plain "Disarm" is probably all you'll usually want to do; the rest might be too much, though if you don't have any additional monitoring rules (what I just described) set up, there'd be no difference.

In the HSM app itself, I see "Disarm Armed-Home" (and similar) if "Armed-Home" (or similar) is pressed/activated, and "Disarm Monitoring: ..." buttons. (Interestingly, I don't see the option to set Armed-Away here.) These are analogous to the above, though staff and most users would encourage you to use a Dashboard or automation to arm and disarm rather than the admin page for the app itself.

Thank you! My next question for the gang is: Why does my RT 101 Thermostat randomly ignore commands? It seems like one out of 4 times, it does nothing when the temp should be changing. There was some discussion earlier that it might be because its a battery device which spends a lot off time asleep. It that is the case, does anyone know how to send it a "wake up" command before the "change temp" command? I'm thinking that Iris must have looked at your temp schedule and downloaded appropriate wake commands to the thing in the background... directly to it's memory... or something like that. Because it never failed randomly like this under Iris.

In Iris, we used to be able to set up 2 motion sensors to eliminate false alarms within a 5 min frame. Are we able to do that here?

There's a built-in app (needs to be installed) called Zone Motion Controllers that does that.

1 Like

And a question possibly related to my last one about waking the thermostat. Why does "Repair Z-Wave" never touch my thermostat or door lock? Those nodes are consistently missing from the logs. The devices are on the Z-Wave Details page and the lock, at least, responds to buton pushes on the device page, but they are never included in repair. They are the only battery devices in my mesh.

Battery powered z-wave devices repair differently than mains powered devices. They are supposed to update their neighbor list on next check-in, which is why it does not show during the zwave repair cycle.

Thank you. Is there a way to see if they have done it?

Not that I remember. Could be wrong, though.

You can see a node's neighbor info if you have a zwave sniffer/second controller/plug the USB stick into a PC and use the zensys tools. But that isn't something 'normal' people usually do.

Can I get a list of what normal people do?? I really need to do a better job of mimicking normal. :smiley: :smiley:

I have that:

1 Like

Me too. That's why I know it isn't normal, as few things I do are normal these days.

Maybe I should have said 'typical user'. :smile:

1 Like

My thermostat manual says: " Z-Wave and Battery Power

When your thermostat is running on battery power, the Z-Wave radio will turn off to help conserve battery life. The CT101 Z-Wave radio module supports Z-Wave beaming, which allows other devices in the network to wake up the Z-Wave module and accept commands, and then go back to sleep.

The node type is fixed during network inclusion. If C-Wire is not present and the thermostat is battery powered during network inclusion, the thermostat will remain a frequent listening routing slave (FLiRS) node until the thermostat is removed from the network via network exclusion."

Mine was in battery during inclusion. I got it working for a few days, but now, every time I expect a rule to change the temp, nothing happens. I have to walk to the thermostat, wake it up by poking it with my finger, then walk to my computer, go into edit mode on the rule and click "Done" to run the rule again. This is the opposite of "home automation"!

Why has it stopped waking for rules? Is there any way to send a specific wake command?

I think that's the answer. Beaming was 'invented' with battery Locks in mind. In other words, for perimeter devices (barrier class) that run on batteries and need to sleep to have even a snowball's chance of acceptable battery life. Look in the vicinity of your Thermostat and note which AC powered devices are within 15 feet. Look them up on the ZWave Alliance and verify they support Beaming. One of those 'in the vicinity of' AC Powered devices is supposed to intercept the Hub's traffic to the sleeping device and hold it.. then wake the device, wait for wake to occur, then send the saved command(s) and allow the device to return to sleep.

In other words the beamer :slight_smile: becomes the Hub for the few moments to that sleeping device.

1 Like

Ah... interesting. Well, 8 feet away are two GE 14288 in-wall Z-Wave plus outlets that respond to rules properly. I looked it up on Zwave Alliance, and don't see any category in the specs that's called "beaming". All I see is stuff like :

Z-Wave version: 6.51.09
Z-Wave library type: Enhanced 232 Slave
Z-Wave Device Type: On/Off Power Switch
Z-Wave Role Type: Always On Slave
Product Type ID: 0x4952
Product ID: 0x3133

So I guess they don't beam.