One more minor wording bug. These should be "seconds":
From the manual:
Whoops.. Fix coming shortly
Also, on the comment made previously about your default max heat and min cool, the manual I have shows a different default than yours. I realize you took it from the zwave certification, but those values are wrong.
OK. Enough pedantic criticisms for one day. lol. Driver is working great for me. THANK YOU.
Both fixed.. v1.4
In case you don't have it, and want it, this is the most correct listing of parameter descriptions I could find.
http://manuals-backend.z-wave.info/make.php?lang=en&sku=GC-TBZ48L&cert=ZC10-17055590
(there is also a link to the actual maunfacturers manual near the top of the page)
Yea.. I actually flipped back and forth.. But obviously missed a couple things.. Glad others are finally using it to identify these things..
Heck, I'm not throwing stones. If that is the worst "mistake" you made, you are doing a lot better than me. lol
In any case, I bet this is the last version. I can't think of anything left I haven't gone through in terms of text or function. Nice job!
I wish these thermostats were... umm... prettier. I'd like to kick the nest to the curb.
Check out the honeywell T6 pro ..
You spend a lot of time looking at your thermostat? Not sure why it would matter that much.
But all kidding aside, they aren't "attractive" or "flashy", that's for sure! I wouldn't call them "ugly"... But maybe "plain".
I agree it doesn't really look great. Maybe a tad bit on the "ugly" side... I ended up going for the RCS-branded version: RCS TBZ48. This version has a more squared-off body and rectangular buttons. I think that's enough to push it ever so slightly from "ugly" to the very middle of "neutral" or "nondescript". From what I can tell, it behaves identically. <$30 on ebay
T6 Pro does looks much better - thanks.
Hi @bcopeland, any thoughts on how to add a 'last changed by' attribute?
The optional attribute could be populated by apps so you could see what app made the change responsible for the current settings.
Real reason I want it is to possibly deduce that if the field isn't populated by an app, then a setpoint change was invoked physically at the device and downstream app logic could take that into account.
ie. set up Rule Machine to use thermostat schedules unless the temperature was physically changed at the device. Then use those setpoints for X hours and then resume accepting setpoint changes by apps.
I might try this in the driver code myself but thought I would run it by you first.
something like:
attribute "lastChangedBy", "string"
that can get set/reset every time a setpoint change is made?
Am i making sense?
edit: spelling
Would physical vs digital on the event type satisfy this?
sorry, was racing off to find out where event type
is
I guess as long as Rule Machine/app code can find it that would work?
I think it can. It’s pretty standard for switches and dimmers and such.. I can add the code in there to handle this..
I prefer sticking to established standards as much as possible..
understood, I can appreciate that 100%.
no rush at all - thx!
Done.. V1.5 pushed to my github..
Also noticed and fixed a bug in the setpoint unit event reporting ..
SWEET! - thx for getting to it so quickly.
Cheers!
Nice, I was going to suggest that the other day, but forgot. It isn't as useful on a thermostat as it is on a swich, but is nice to have in the events at times.