You're not that far off 
I might be able to the option to send all events as a preference, let me see how many events we're looking at.
Edit: Might be better to only create the option to send all temperature events.
Yep. That works. (Since it's a keyword labelled argument, I stuck it at the start of the argument list.) I see that using refresh soon after refresh does not trigger another temperature response from the thermostat. But it does create an event for every temperature response from the thermostat.
I note that the "presence" event always appears even if it has the same value as previous. Why is that, when all the other events have duplicates suppressed?
Of course, if we're going to allow events to be forced using a preference setting, we should really give users the option of which events they want to force. I count 11 events:
$ grep -o 'eventProcess(name:[^,]*' Advanced-Honeywell-T6-Pro-Thermostat.groovy | sort
eventProcess(name: "coolingSetpoint"
eventProcess(name: "currentSensorCal"
eventProcess(name: "heatingSetpoint"
eventProcess(name: "humidity"
eventProcess(name: "idleBrightness"
eventProcess(name: "presence"
eventProcess(name: "temperature"
eventProcess(name: "thermostatFanMode"
eventProcess(name: "thermostatMode"
eventProcess(name: "thermostatOperatingState"
eventProcess(name: "thermostatSetpoint"
Does allowDuplicate take a list of event names? A list of event numbers (after we arbitrarily assign them 11 numbers)? A single integer that is the binary OR of powers-of-two event numbers from 2^^1 through 2^^11 (that we arbitrarily assign)? So much choice; so much parsing!
Well, if you're only going to force temperature, you should also force humidity.
If you're only going to force some events, then force only those events that change by themselves in the thermostat without external command intervention, i.e. humidity, temperature, and thermostatOperatingState. All the other values only change if they are commanded to change.
Because it's a ghost attribute at the moment, i.e. the value actually isn't being stored which makes it unavailable for any real usage - I'll fix that in a minute.
Edit: Fixed in v1.2.5
2 Likes
1 Like
Was just looking at your github and I haven't seen version info used quite the way you are...does the "v1.2.5" section w/nothing in it just mean you haven't updated the changes yet, or that this is still 1.2.0 and 1.2.5 is on the way? Thanks.
It's actually v1.2.5, still need to change a few of the documentation type entries over to my normal.
1 Like
Typo needs fixing for import to work: Change .com0/ to .com/ in the metadata definition line.
I don't think the T6 has a presence sensor in it. What does presence actually do?
I don't remember it having presence either, but one of the pull requests added the code to capture a presence change if the device supported it, and I do recall seeing some thermostats that claimed to do presence so I merged the code in. If the device doesn't support it, the code will never get called so no real harm.
Edit: fixed the import typo, thanks.
1 Like
There is one feature I would like to see.
I had my boiler serviced today and about half of my six T6 Pro's lost the time.
Supposedly the driver periodically sets the time. But a nice feature would be to monitor Z-Wave connectivity (can a driver do that?) and when it comes back after more than a couple minutes, perform a clock sync.
Thanks.
Jeff
Just installed a new furnace today and thought I would come over from the Generic driver as this supports more of the new furnace.
I noticed my Dashboard has F instead of C in one spot, temperature needs to be converted as well for my pistons :).
Please and thank you
WTH 
The temp just went to C after 30 minutes of being F. Guess some automagic Refresh happened on the var.
I did notice after using this for a bit that it rounds the temp to an Integer. I use 0.5 degree increments as that's a large delta for C, not for F.
Can you make the temp work in 1/2 degrees?
I'll flop back to the Generic one for now as it does 0.5 degrees.
Can you post the temperature events? Latest version (v1.2.5) should be maintaining at the 10th of a degree.
2 Likes
Your image shows Setpoint numbers without decimal places and is missing some states; this is not the current version of this driver. You need to import the new version. It should look like this for the T6:
Doesn't the thermostat normally preserve its own time using battery power, when the AC power is removed?
There is skeleton code in this driver that says it deals with "power management" notifications, so maybe this driver could schedule a call to synchronize the thermostat clock when it sees a particular power management notification such as "Power has been applied". (This might not work after a power failure if the thermostat comes alive and sends the notification before Hubitat is booted and ready to receive it, but it could work in the case of furnace servicing.)
There are things you can do in the interim:
The driver currently doesn't keep track of the last time it heard from the thermostat. We could probably add some watchdog code that ran every minute, sending a command to the thermostat and noticing when we haven't heard back in a timely manner and scheduling a time sync. But if we're going to use bandwidth to send a command to the thermostat every minute to notice when it's not there, it would be simpler to just send clockSync commands every minute, and you can do that now:
This driver already calls its own clockSync command every three hours to send the Hubitat time to the thermostat. The refresh command also calls clockSync, and the Thermostat Scheduler app has a Refresh Interval that calls the refresh command as frequently as you want. You could also probably write a Rule to call clockSync more often.
Simpler method would be to add a last activity attribute and update it whenever the thermostat processes a command whether it generates an event or not and then check if the elapse time is greater than x minutes. Even when off, the thermostat is taking temperature and humidity readings.
v1.2.6 Changes:
- Add force Clock Sync time
- Add lastActivity attribute
- Add Clock Sync if mains reconnected event occurs
Not quite sure what I'm seeing here...the power source state is coming up as a number and also it keeps changing. Its also showing units of degrees F. Maybe I need to remove the device and reinstall it. It's been a little weird the last week or so with different versions of Z-wave thermostat drivers installed and it's possible the states are very scrambled. Here's a couple of screen shots.
( running the 9/30 version of the driver)
Before you exclude, or anything else.
Change to the built-in driver called "Device". Click save. Then click "Delete All States". Then change back to this driver, click save. Then click "Configure". Wait a day or two and make sure that all the states/attributes have the anticipated values and units.
Thanks....had done that already to clear all previous states as far as I could tell. Usually using that "device" driver to clear states works really well for me...but not sure what's going on here at this point.
The t-stat is running just fine..and working the way I'd expect it to with the stock thermostat controller and schedulers. It just appears the states are a little messed up at this time. Also, I did verify that the power source for the thermostat is currently "mains", just to make sure there wasn't a power failure going on at the device.
1 Like
