any other temperature sensors doing this?, or just the ones you mentionedā¦
Well, I only have the SmartThings Zigbee devices and my eCozy Thermostats that supply temperature data. My eCozy rounds the temperature, but I. created the driver myself (originally created a ST DTH for it) and am rounding the output in the driver. It also supplies an unrounded version of the current temperature when retrieving it from the device via the ZigBee cluster.
So, I suspect it is the job of the driver to round temperature it receives. For the Smartthings devices I am using the drivers supplied by hubitat (either the SmartSense or Generic Zigbee drivers).
Youāre obviously Celsius correct?
This issue is either in the driver, or the conversion function, in any event weāll get it fixed in the next release.
2 Likes
Yeah. Actually all zigbee devices supply temperature in Celsius. These ST devices were all purchased in the US. So, any driver would always need to convert the temperature if they need to display Fahrenheit.
Looking at ST, the hub itself has a global setting for temperature display and thatās how it knows whether to convert the retrieved temperature to Fahrenheit or leave it as Celsius. But in any case the temperature would need to be rounded in the driver. Typically celsius is displayed in increments of 1/2 degree (so, 20, 20.5, 21, 21.5 etc.) and Fahrenheit per degree (no digit behind the decimal).
If you donāt want to make the temperature display a global setting in the hub, then it would need to be an option in the driver settings.
I just noticed that Hubitat also has a global temperature setting in the location settings:
So, maybe the driver is ignoring the conversion when that is not set to "F". But, then it at least needs to round the temperature, like I'm sure it does while converting to Fahrenheit. The driver potentially just says "if NOT Fahrenheit then leave as is".
we convert or not based on what unit the driver provides in conjunction with what the hub settings are.
we donāt get super cute with the data formatting, we should be showing up to 2 decimals max in the driver events.
OK, that sounds good. Then it was probably only coded that way for Fahrenheit today and needs to be updated for Celsius as well.
Thanks. Iāll wait for the next update to verify the fix.
1 Like
BTW, is there anybody in the community that can help get drivers functioning from a ST DTH? I have this driver for my eCozy Thermostat:
But, it is only retrieving data properly. I can't control the thermostat at all. It doesn't accept any setHeatingSetpoint commands etc. And as expected any Rule Machine rule I set to modify temperature on the thermostat is not triggering either. I can't see any type of logging for Rule Machine triggers, so I am a little lost with getting this driver working.
Not seeing anything obvious in that driver that shouldnāt work.
When you say wonāt accept, youāre saying that you write attribute xyz via setHeatingSetpoint in the driver, then read it back that itās retaining the old value?, or that you arenāt able to change the setPoint from RMā¦
Before troubleshooting RM, I would first like to have it wirk from within the driver. For instance, the driver details page shows me all the commands I have available in my driver and then some. Apparently hubitat adds commands to that page based on the capabilities listed in the driver. I suppose for instance that the Fan commands were added because it is a Thermostat. Since it is a TRV, it is a thermostat, but doesn't have fan functionality.
But, that is a different topic that Would like to get into later after my main functionality works. So, at some point I would like to know if we can affect what commands are displayed from the driver, like hiding commands that don't apply.
OK, but for main functionality I have a command setHeatingSetpoint that shows up in my driver details:
If I set for instance "20" in the NUMBER field and hit the Set Heating Setpoint area, nothing happens. My thermostat remains at the heating set point it was before.
The code it should run would be this (and it works on ST fine):
I had issues with ST running multiple commands in certain instances which is why I did it the way I did by creating a collection of commands that were sent via the fireCommand function that uses the sendHubCommand. Not sure if this is also necessary in hubitat or if this is even what is causing the issues altogether.
Anyways, I am unable to set a new Heating Setpoint via the driver. I can only read attributes from it. So, I can see the current temperature and heat setpoint and battery value. But, any zigbee.writeAttribute command doesn't seem to work.
not possible ATM
for the code, try replacing fireCommand(cmds) with "return cmds"
temp rounding fix will be out in the next release
2 Likes
Thanks. I fixed my code. It was an error on how a converted integrer to hex was interpreted by hubitat. Apparently, ST wasn't complaining when I converted an integer into hex for placing into the value field of the zigbee.writeAttribute command. Hubitat was complaining that it is a String and not an integer as it expected. So, I just change the code by supplying the integer as is without converting to hex. That works as well.
One more question (I know it is off topic now), when hubitat adds commands to my driver details page based on the configured capabilities, do I need to add code to my driver for them to work? Or are those "hidden" commands relevant for the device type that will function as expected?
I ask because my thermostat supports setting a weekly schedule, but I never coded the capability to do so in my ST DTH (now HE driver) and see that command in the driver details page:
So, I was wondering if I could set a schedule in the thermostat without any further coding? Or should I create an App for that type of task?
Thanks again for the help.
Just to confirm, this was fixed in the latest release 1.0.6.709. Awesome job and such quick turnaround for reported bugs.
1 Like
yes, any commands that you see in the driver details would need to be implemented in the driver should you wish to do so.
we currently have two zigbee thermostat drivers, the zen stat does not support built in scheduling that I'm aware of, the other driver (generic zigbee thermostat) was written and tested against a centralite perl, which supposedly does, however I didn't implement, nor attempt to test this.
Personally, I believe setSchedule should not have been part of the thermostat capability, its not well documented and I've not seen it implemented.
At this point we don't have any intention to implement this in our drivers due to the above as well as opening the door to scheduling and other "who's in charge" of the thermostat conflict issues...
Honestly, for the complexity involved, I just don't think there's a value add here.
Mike, I personally use the Ecobee and Lennox apps to define the schedules. Those apps should be the "system of record" for schedules. However the only reason I have them integrated with SmartThings is so I can set them in Away mode when we leave and then resume schedule when we return. It would be great if Hubitat would allow this type of interaction with the thermostats. Also in the event of a fire to turn off the thermostat. So again the thermostat physically or via software should be responsible for the schedule but integration wise allow HE to set things like off, away mode, and resume schedule.
This isn't a Hubitat limitation, what you speak of in here is dictated by the driver implementation.
There's multiple classes of thermostats in my mind, so lets have a walk through them.
--Dumb thermostat, what you had in your house before you replaced it, no remote control of any sort, may or may not have had self contained scheduling.
--Smart Dumb thermostat, zigbee/zwave/wifi, no inherit scheduling capabilities or UI on the device for schedules.
--Smart thermostat, as above but with local and or cloud based scheduling capabilities.
The class of devices that I have been talking about are the Smart Dumb thermostats, these require setpoint and operating state control via an app of some sort.
The Smart thermostat class, may or may not be scheduled using the manufactures API, schedule UI ect, this should be left to the user to decide in my opinion.
I say this, as running a schedule in the cloud could potentially conflict with automation overrides ect.
1 Like
Most ZigBee thermostats could have built-in scheduling as is a standard cluster for thermostats.
In my case the ZigBee TRV has the scheduling cluster included and I would like to program it via HE since I am not using the vendors own hub and app since the are paired with HE.
But Iām fine with leaving to an App to do that job in which case I will code an App for my eCozy thermostats to accompany the driver I have already ported over.
If you already ported a driver, nothing is preventing you from implementing setSchedule using the thermostat cluster!
Yeah, will do. I just never got around to it on ST. I had just wondered when I saw the setSchedule command show up on the device since I didnāt have that command in the driver. So, I thought maybe HE had something implemented where I could just add the respective JSON in that field.
But, no problem, I will program a setSchedule command when I get around to it.
