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.
The 14288 supports beaming. It is in the conformance report,
So do you know if the thermostat joined as a repeater (always powered) or flir device? I don't have that thermostat, but on other Z-wave thermostats I have you can see the z-wave operating mode in settings.
It had no power. It joined in battery mode. (Yes, I see you have to click "view" to see the full conformance report on the outlet. I thought the summary was the full report.) So, it's sounding like the beaming is not working to wake the thermo any more. The thing I don't get about Hubitat is why things work for a while, then... just... stop.
I can't answer for your inconsistent operation - I don't experience that on my system. I believe you, mind you, I just don't have any suggestions to help. All my thermostats have a c-wire (luckily), so I don't deal with this.
Have you explored adding a C wire or adding an external (wall wart) transformer (between C and RH) ?
I'm thinking you're still migrating devices and each add alters the mesh's 'shape'.. or at least it's potential to alter the 'shape.'
Zwave repairs will assist with that. You don't want to be constantly running a repair, but you want the repairs to not just complete the one pass, but if one pass improves the mesh, are there any more repairs to be done? Ideally you run repairs til nothing is changed in the pass. I don't remember any of my 5 hubs giving great detail in that regard. So usually I'd run it three times. I am not moving or adding things much these days.. my last one was to split my house (upstairs downstairs) between two hubs. Exclude and Include half the house.. fun stuff. I think that was about a month ago. I ran repairs yesterday. (Once per hub) which makes it a once a month event for me. 
As JasonJoel said.. believe you, just not my experience with the Hub in recent memory... no magic cure pops into my head.
Yeah, I hear you. Z-Wave mesh voodoo. I ran two repairs this morning, and they were mo' robust than the last time, but both appeared to be the same in relation to each other.
I think the answer is going to have to be a C wire.
So, whoever is keeping track of the "What do you miss about Iris?" question, add this: I never had to drag a C wire through a 150 year old house with Iris. 
Also, here's how you manually adjust the temp with Iris:
You just drag the dot around with your finger. How would I make the temperature temporarily go up or down 2 degrees with Hubitat? Anyone have a tip or trick for that? I'm not even sure where to start.
I know there was some kind of "manual" setting in the Thermostat scheduler app, but I deleted that app because I was afraid it was conflicting with my Rule Machine rules. (I finally gave up on controlling thermo with modes, and went with RM instead.)
How would y'all do on-the-fly temp adjustments?
You both are delusional. Why kid yourselves into think you can even try? 
Only if the thermostat has constant power (C-Wire). When running on batteries it doesn't support beaming.
Right. We've probably beaten this to death at this point, but for future people reading....
For z-wave:
Battery powered devices = Can support FLiRS (but doesn't explicitly have to)
Mains powered devices = Can support Beaming (but doesn't explicitly have to)
But the two features are also interactive. 
Well, what do we mean by "supports"? If beaming was invented to wake battery powered devices and pass them commands, then the battery powered devices must be able to receive the beams? It should not be surprising that they can't send beams, but in this case what I need (and what is happening inconsistently) is receiving instructions.
We're lost in semantics. Some battery powered z-wave devices support FLiRS. FliRS works by listening for the beamed command from a compatible hub/repeater. When it hears it, it comes fully awake and thus able to talk to the hub right away without waiting for its normal wake-up schedule.
Original goal with FLiRS was ~1s wake-up times for battery devices that supported it.
But not all battery powered devices support FLiRS - in fact MANY do not. Thermostats and Locks almost always do, though.
Mine supports FLiRS. But it ain't working consistently. Or the beaming devices aren't beaming any more. Either way, I'm going to try to get a C wire to the thing.
But here's another problem I'm noticing today: 2 days ago I realized that the week-old batteries in my Kwikset 910 Z-Wave lock were dead. I changed them. Today they are reporting only 80%. That's 10% drain per day. At this rate, if I leave home for a week, i will come back to a dead lock. With my iris system, batteries lasted at least two months even with heavy use. Is this the opposite problem? That the lock is never sleeping?
Beaming is specifically for assisting battery devices with their battery-life-extension plan.
A battery operated Door Sensor wakes when the door opens. It wakes to report battery usage. But it really isn't expecting the Hub to speak to it. It gets commands for setting parameters sure, but it is expecting to never hear from the hub again, for months or even a year. Thus the battery-life-extension plan is very crude... sleep, and sleep often, sleep deeply. 
Locks, and battery operated Thermostats.. all need to be poked and prodded by the Hub all day long. The battery-life-extension plan necessitated an improvement in the way battery devices were commanded.
Beaming was their solution.
I see. Is this the way that Hubitat works then? Is it going to eat lock batteries once a week? I can't use a system that does that. I will have no way to buzz employees in to my place when I'm out of town, for starters. Or do you think this is not how it's supposed to be and I should contact support for this?
I had 3 z-wave kwikset 914 on HE (before converting them to zigbee for non-battery life, and non-HE reasons), and I never changed batteries once the entire time I was using HE (maybe 4 months before converting to zigbee, cycling an average of 3 times/day).
So I would say, no, that is not normal.
Also keep in mind that battery % isn't exact. I've put brand new batteries in my kwikset locks before and they STARTED at 80% (not 100%)... So one data point is isn't worrisome to me. But, if they drop to, say, 60% in a few more days, then you definitely have a problem.
I have Yale locks and they lasted about 8 months or so. I guess it's usage dependent. Do the Kwiksets have an external way of getting power to the lock like plugging in a battery? Also you could look into running power to the lock directly and faking out the batteries (AA battery cases). Not the prettiest solution but if the door is in a hidden place like mine (basement side door) - definitely workable.
This is interesting. I have the same Radio CT 101 (IRIS Bundle) and I have added it to HE (Generic Z Wave Thermostat). I wrote a rule to change the mode to "HEAT" at 7PM and "OFF" at 7AM (Target Temp remains the same). It's been running this function with no problem the last handful of days. I didn't include the CT 101 until I had a GE Smart Switch (Generic Z Wave Smart Switch) running nearby (6 feet away). I'm fairly certain it's running exclusively on battery (No C Wire). I'm away at the moment but will double check the device when I'm around and would be happy to forward any other details your way. Just let me know what info you need.
On the fly adjustments? That's not "Automation" that's "Control". (HE Community Sarcasm 
)
Now I'm mad. I just got locked out of my house. None of my codes worked.
Does anyone know what these logs mean? alarmLevel? alarmType? payload?
dev:1302019-02-26 02:12:01.639 pm debugparse: zw device: 08, command: 9881, payload: 00 71 05 1B 01
dev:1302019-02-26 02:11:29.583 pm infoFront Door Lock was locked manually [physical][21]
dev:1302019-02-26 02:11:29.576 pm debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:21, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:0, zwaveAlarmStatus:0, zwaveAlarmType:0)
dev:1302019-02-26 02:11:29.569 pm debugparse: zw device: 08, command: 9881, payload: 00 71 05 15 01
dev:1302019-02-26 02:11:21.484 pm infoFront Door Lock battery is 80%
dev:1302019-02-26 02:11:21.483 pm debugBatteryReport: BatteryReport(batteryLevel:80)
dev:1302019-02-26 02:11:21.472 pm debugparse: zw device: 08, command: 9881, payload: 00 80 03 50
dev:1302019-02-26 02:11:21.291 pm infoFront Door Lock was unlocked manually [physical][22]
dev:1302019-02-26 02:11:21.289 pm debugalarmv2.AlarmReport: AlarmReport(alarmLevel:1, alarmType:22, eventParameter:[], numberOfEventParameters:0, zensorNetSourceNodeId:0, zwaveAlarmEvent:0, zwaveAlarmStatus:0, zwaveAlarmType:0)
dev:1302019-02-26 02:11:21.191 pm debugparse: zw device: 08, command: 9881, payload: 00 71 05 16 01
Download the Hubitat app
