missing a Current Setpoint hs device

[mnsandler]

Kirby,
how do i recreate this without deleting and readding the stat

[Kirby]

Go to the plug-in configuration screen. Choose the stat and click on the refresh icon.

[mnsandler]

thanks for the quick response. that procedure didn't add the missing device

[Kirby]

Mark,
The current setpoint will only be added if auto change over is configured. What model thermostat do you have? Does auto show up as a mode?

[mnsandler]

i have two rc2000 units.

i don't use auto change over (on either), but i do have the 'current setpoint' on one stat but not the other. maybe its because i had auto set when i registered the device but not the other.

if i can ignore/hide the 'current setpoint' and just focus on "Heat Setpoint" while the stat is in heat mode then that would be fine.

can i delete the current setpoint on the one stat that has it defined without breaking anything?

[Kirby]

can i delete the current setpoint on the one stat that has it defined without breaking anything?

Excellent question. I will have to look at the code to be sure. The ref Id would still be in the thermostat data structure but I try to always check for existence of the device before I perform an operation.

Another option would be to enable auto change over on the thermostat that doesn't have the current setpoint device, refresh the thermostat and then disable the auto change over.

[mnsandler]

i'll try your procedure and report back.

fwiw, the plugin can get a callback from hs when a user deletes a device; good for avoiding problems.

[mnsandler]

Ok. that procedure worked. enabling auto, then refresh created current setpoint device. so i did the reverse and the current setpoint went away.

turns out i had auto cutover enabled on one stat. so i disabled cutover, refreshed, and the device went away.

all is well. thanks

[mnsandler]

any chance you could add support for scheduled programming to the plugin?

i find the occupancy mode rather difficult to manage

[Kirby]

any chance you could add support for scheduled programming to the plugin?

i find the occupancy mode rather difficult to manage

Now you are pushing it.....

Realistically I don't see that happening any time soon.

• I am moving into a new condo and I have a number of projects going on for that.
• I would never use the schedules because they are too static. I would much prefer to use events to control occupancy states.
• Since I don't see their value, I can't come up with a use case for them. Should they be devices? Should their settings reside on the configuration screen, etc.
• You could use the set register functionality of the plugin to set the schedules, but it is not clear to me what the user interface would be.

Sorry,

Kirby

[mnsandler]

Now you are pushing it.....

Realistically I don't see that happening any time soon.

• I am moving into a new condo and I have a number of projects going on for that.
• I would never use the schedules because they are too static. I would much prefer to use events to control occupancy states.
• Since I don't see their value, I can't come up with a use case for them. Should they be devices? Should their settings reside on the configuration screen, etc.
• You could use the set register functionality of the plugin to set the schedules, but it is not clear to me what the user interface would be.

Sorry,

Kirby

no big deal, just thought i would ask..never hurts.

but to answer your question, in the prev plugin there was screen/table with the days of week across the top and different time periods (morn, day, even, night) down the side, and you just selected the temperatures in each cell. then load them into the stat.

You could save each profile by name. I had a summer, spring, fall, and winter schedule and could just load them when necessary.

Creating all the events to change the temp at various times of the day, for the various days gets to be a lot. also given that i have two stats.

Have fun with the new condo!

[Kirby]

Thanks, Mark.
There may be some others that share your vision.

I think you should start another thread. If there is consensus on the spec, I may be able to implement it but I don't want to be iterating to a solution.

Kirby