[quote=“RBoy, post:79, topic:7284”]
change the poll function
[/quote]Yep, that seems to continue to work after the change - at least then it makes sense why you’d be getting that event 
Sorry guys, this is my fault. I should have given notice of this change but it slipped through the cracks. It is important to specify which versions of each command class to use in the zwave.parse method. Otherwise it will use the highest version. There was an error that had been causing it to use multiinstancev1 for 0x60 when the highest version is actually multichannelv3 (because they changed the name of the command class). I fixed that, but I neglected to include that in the release notes or announce it here. Sorry!
Works great, thanks everyone! Looking forward to getting better at debugging these things myself.
Updated the code here and on the website
Fixed a bug with humidity and battery not being reported. One needs to use sensor multi level v2 and not v3 since sensormultilevelv3 doesn’t exist and hence consequently was never being called from parse.
Code has been updated above. Also removed redundant sentEvents
The server version of the code also contains a battery saver mode which reduces the polling time to save the thermostat battery.
Actually found a simpler way, the stock code support sensor level v3, so just remove the custom code for v2 and call v3 instead and it works fine. Updated.
For the folks who are using the custom code on the RBoy server with the Battery Saver Mode, use the updated code which fixes an issue with the ST platform not calling poll after a while.
For the devs customizing it yourself, execute this piece of code if you’re not invoking any zWave commands in your poll function:
device.activity() // workaround to keep polling from being shut off
Just wanted to say a big THANK YOU!!! I am really into programing and this was a major help!!!
P.S. my first initial is R and last name Boyer so I love your tag haha.
Thermostat quickSetHeat/quickSetCool Question?
This may seem a little long winded, but I want to give a little background before asking my question. I am currently using @RBoy’s Thermostat Device type.
Looking at the code there are two ways to change a temperature setpoint. The first are the standard commands of setHeatingSetpoint/setCoolingSetpoint and the others are custom commands for quickSetHeat/quickSetCool. As the quick command implies the thermostat setpoints changes quicker, due to the shorter delay implementation time.
I have a smart app that changes the setpoint via virtual dimmer or momentary dimmer switches. Primarily this is used to get some thermostat controls with the Amazon Echo. The switch devices I use/made have a slider and up/down step temperature changes. The one feature my app has is to make sure that the thermostat and the slider level match when either the thermostat or dimmers are changed.
Currently changing things directly at thermostat or device in Things in the phone app, the dimmer slider updates quickly. When I change things from the dimmer there is about a 30-40 delay using the standard setHeatingSetpoint/setCoolingSetpoint commands. I know that delay is built into the device type.
My question, should I have any concern with using quickSetHeat or quickSetCool when changing the temps via the dimmer device via my smart app interface?
I will add that the app does have a built in default temperature max/min override option, so before passing any change request to the thermostat it modifies the request if needed. If the temperature selected via the dimmer device, is below 50, it reset the dimmer to 50. If the temperature selected via the dimmer device,is above 80, it reset the dimmer to 80. This range is updatable within the app. I chose this method instead of limiting the range within the device type, so not to impact other switches have that use the same device type.
I don’t see any reason why not. Make sure you’re subscribed to the temperature updates from the thermostats so you SmartApp know when the temp changes to keep it in sync.
Thanks for the response. I have subscribe to the thermostat setpoints, I just wanted to limit the delay between the virtual dimmer and the thermostat update without changes any device types
Updated the code to support the new ST App MultiTile User Interface. Now you can get the various parameters on on the Status page
The Humidity is not colorized. I do not see it in the code.
That’s correct. Humidity has a new icon and layout optimized. What color palette should humidity have?
I sorry I read it wrong. I thought it said color battery and humidity.
For one of my devices types I use this palette.
, backgroundColors: [
[value: 15, color: "#153591"],
[value: 30, color: "#1e9cbb"],
[value: 45, color: "#90d2a7"],
[value: 60, color: "#44b621"],
[value: 75, color: "#f1d801"],
[value: 90, color: "#d04e00"],
[value: 96, color: "#bc2323"],
[value: 100, color: "#5e1111"],
]Shouldn’t it be the other way around? Dry (low humidity) is yellow/red and wet is Blue (green being optimal range)
Yeah your right. I added this a long time ago once I figured out how to add color to device types. I never thought to correct it, it was just a copy/paste from temperature and changing the values. I had not given it much thought until I miss read you last update post.
So this would be a nice way to represent based on acceptable home values:
backgroundColors: [
[value: 20, color: "#ffe700"],
[value: 30, color: "#d6ff00"],
[value: 45, color: "#3cff00"],
[value: 60, color: "#00ffb8"],
[value: 80, color: "#00dfff"]
]Just updated the app on the server, it crashes with the new ST app release. That’ because the app team decided they don’t like the up/down buttons anymore so using
tileAttribute ("device.level", key: "VALUE_CONTROL") {
attributeState "level", action: "levelUpDown"
}
will cause it to crash, anyways commented out the code for now. This is just a FYR for everyone else build their own apps