Love the new Dashboard!!
I am just having display problems when using the template "multi" with my SmartSense Multi Sensor v4. It is showing the temperature non-rounded, filling up the entire top of the tile and covering the reading in the middle.
Same goes for my SmartThings Water Sensor:
And the SmartThings Motion Sensor 
If you go into the driver details for one of these devices, is the temperature unrounded there as well?
Yes.
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.
