It's this bit at the very bottom of the driver where you can set the default update which is defined in seconds. therefore 600 seconds / 60 = 10 minutes
You could try halving it to 300 maybe, but that means it's waking every 5 minutes and i guess will soon eat batteries, but you could monitor this and adjust for a happy medium
private getUserWakeUp(userWake)
{
if (!userWake)
{ userWake = '600' // set default 10 mins if no user preference
}
// make sure user setting is within valid range for device
if (userWake.toInteger() < 60)
{
userWake = '600' // 10 minutes - Mininum
}
if (userWake.toInteger() > 36000)
{
userWake = '36000' // 10 hours - Maximum
}
return userWake.toInteger()
}
Just tried 300 and it certainly did not change in 5 minutes. So 10 minute update seems to be in, I'm quite happy with this time for a thermostat to update. I'm going to have a few running as i plan to install underfloor heating into a few rooms so running this on a scheduler will be fine.
Just timed it, I have 2 thermostats and 2 relays. Change the tile temperature within seconds of each other, one changes in 4 minutes, the other holds on for 10 minutes. Guess it's the luck of the polling each node
Want to work out now how to override the tile to get rid of the mode and fan buttons, and just keep it simple up down, and work out what the 'unknown' part still on display is doing and or should read..
This isn't possible I'm afraid. The coding behind the dashboard tiles is not accessible to the user. The only way to achieve this is to create your own dashboard tiles for up and down and use attribute tiles for current and setpoint temperatures. Doing this will mean you lose the ability of the tile to change colour on operating mode change as it does with the built in thermostat tile.
Surely in the customise part of the tile you should be able to include some kind of css "disable" type override to hide various elements. After finding that certain variables need to be defined into set states to be recognised by the tile I find the tile element a little "dumb" and restricting rather than being able to report freely its chained to set rules.
The latest dashboard system is relatively new as is the thermostat tile - for a long while there wasn't one at all. While I agree that more tile customisation would be nice, I think it needs to be kept in perspective just how far and how quickly Hubitat has evolved. I think they have rightly focussed on the more important core issues.
Have you seen or tried Sharptools? https://sharptools.io/ I haven't used it for a while but it offers lots more customisation than the built in dashboards.
I've seen it but am dead against buying or renting a license to use such applications. In Vera I was using imperihome which is a great purchase once app. I've approached them about supporting he as they already support Vera, smartthings, lutorn, harmony remote all integrated and drag and drop. They seem keep to investigate further as they've emailed me back asking for more information on the device
I liked Imperihome too, and used it with my old Vera. I agree it would be a nice addition to Hubitat, but while Vera definitely needed a better interface with Hubitat dashboards it's much more usable as it is and keeps everything under one roof which I prefer.
Interesting I just had another HRT4-ZW arrive which must have been an older kind( has the older radiating circular logo of waves), it didn't report correctly and back to square one. It was updating the theromstatMode from idle to heat which again was screwing with the tile. Tweaking some descriptions and forcing the mode to be on heat only using the below map define worked fine.
Hi,I've been watching this thread with interest. I have a SRT321 on my HE and I am getting an issue where the wall stat isn't ALWAYS reporting back the increase in room temerature to HE. Often I have to select N option on the wall stat to get an update. Otherwise the TPI funtion of the SRT321 seems to work just fine. HE setpoint updates seem to work ok.
I've never really noticed this as i don't use this temperature as a reference. The only weird thing I have noticed is that the temperature is always XX.3 deg C in the dashboard. Whereas you can only modify by the 0.5deg C on the buttons. I've never really been bothered to look further into it as it's direct link to the secure relay direct it's merely connected to the Hub to provide the rule machine thermostat temperatures based on mode. I've not replaced the hot water element of the heating with a secure relay only and control the hot water on time of day, and included a virtual switch to enable a 1 hour "boost" function to completely get rid of the antique previous time controller.
Are you noticing it only updating X times a day, or at particular intervals? Just trying to establish a pattern to identify possible routes to investigate?
ok I think I have figured it out. Quick recap. I'm using TPI. If I make setpoint in HUB to 19..and the actual temperatureroom is lower then 18.5 it fires up. If the actual temperature was 18.6 it doesnt. It doesn't appear to fire up when it's 18.5 either. I thought I had issues always when the room was cooling down, never when the temperate was rising. Kinda all makes sense now.
Oh dear it doesnt work all the time... maybe its because of this,,
groovy.lang.MissingMethodException: No signature of method: user_driver_meavydev_SRT321_Thermostat_1379.pollDevice() is applicable for argument types: () values: []
Possible solutions: collect() (pollDevice)
