Thanks for that heads up, but only that zone is showing up in smart app for that vent. I am thinking the automatic shut off in code my also be triggering, but I have that on 5 minute delay.
Mike, do you resend the open command periodically or just once? Again wondering if slow communications could be responsible. First thing is to change back device handler code. Are you guys still using DH in link above?
The requested opening level seldom matches the device reported level, there is no fix for this, it’s an issue with the mechanical level implementation within the vent, not Keenect.
Try getting the level to stay at 100% when using the device tile and you’ll see what I mean.
[quote=“Cherokee180c, post:42, topic:39119, full:true”]
Thanks for that heads up, but only that zone is showing up in smart app for that vent. I am thinking the automatic shut off in code my also be triggering, but I have that on 5 minute delay.
Mike, do you resend the open command periodically or just once? [/quote]
I don’t understand your first sentence, but in any event.
While the main hvac is running any of the following should cause the zone to re-evaluate it’s state. (by re-evaluate it’s state we mean, see if we need to change the current vent opening)
–thermostat set point increases while heating, and decreases while cooling
–zone temperature changes
–mobile app changes, vo’s, set points, disable switch ect…
–enabling a previously disabled zone
I was thinking a built in safety for the unit itself if it opens too far or gets jammed. Remember I have had the obstruction error on each of these units in the first day. I am starting to think it might be the device handler itself as I have seen some weird behavior where when opening the device in things, the slide bar goes back to closed. So maybe in trying to verify if the vent is open, when opening the device it sends the close command via the slider in the device handler. Anyway first things first, let me get back to the proper device handler that Keen recommends, which obviously is not what ST installed.
Dunno, I think you’re trying to over analyze the device type, I’m currently using the stock published ST DTH (device type), the one Keen says to replace, and I also used @yvesracine DTH, neither of them did anything like what you’re talking about with any of my vents.
I seriously doubt this has anything to do with the DTH.
Mike,
You were right it has nothing to do with the device handler. I have been testing all night, and think I have isolated (2) issues. The issue with the one vent definitely has something to do with the vent close option that I had set to 5 minutes in the advanced settings. Maybe something to do with excessive communication time or a drop out, but that one vent goes from 100% to 2% instantly every time with that setting enabled almost like the timer gets reset to zero immediately after open command? See screen shot below again at 7:18pm.
I set to only close on disable in the advanced settings, which works fine and closes the vents once the zone disable is triggered, but only if you disable the zone while the heating system is running. If the zone is disabled when the heating system is off, it doesn’t seem to catch the fact that the vents have not been shut and just doesn’t update the running status of the system at all in he current report.
Few things, the reports are only generated when the zone is disabled while running or the zone shuts down from the main hvac going idle.
If the zone is disabled while the main is idle, no report is generated, as there is nothing really to report.
To understand your issue with the close vents option set to 5 Minutes I need to know the complete settings you were using, what state the zone was in when it closed, and if a disable switch was involved, and used.
Maybe it’s simpler for you to tell me what it is your trying to do, and I can help with the settings.
Thanks Mike I will send you tomorrow. When you say no report is generated, does that also affect actually closing the vent?
One of the main issues I am having is the Ecobee3 portal take about 30 seconds to update, then the Ecobee connect ST app only polls at 5 minute intervals. A few times you found out my system was running after the cycle had already stopped. I think I am going to now use the temperature climb in the vent itself to trigger a pull request, which should drop the time to verify the system is running to around 2 minutes after start.
Maybe you can add the vent temperature greater than a certain value as a proxy to trigger system run directly and dropping below another preset as switching to idle?
Ok, yea, this app isn’t going to work well with thermostat configurations that take that long to report. You need to get that sorted out first, this is an event driven app, which makes debugging the delay close issues almost impossible if we don’t have solid consistent reporting from your thermostat.
Sorry, I’m not going to do that, it’s compensating for a bad device integration.
Discussion of repeaters here. Although this topic is about Zwave, the same principle applies to zigbee.
The main difference is you don’t run a special utility to get all the address tables up to date; you just have to take The hub off of power (including taking out the batteries) for at least 15 minutes. Then when you bring it back online, the zigbee address tables will all be rebuilt with the current neighbors.
Thanks JD, I am doing that procedure now. Since I am new to smart things I was just worried about losing my configuration but read it is not an issue.
Mike,
I fully understand. I am pretty sure, however, the issue with the one vent is not related to the delayed update from TSat because it is isolated to the one vent only and very repeatable, and immediately fixed by removal of the 5 minute off vent delay. Configuring my zigbee network routing now, so the vent communications should now route through Hue bulb repeater, so we will see if that fixes it.
The only thing giving me hope is that my application is so simple. Open vents on occupancy, close on leave. I am sure I can do that in rule machine, but the temperature control was a very nice to have additional function. It also provides a great platform if I add more zones. Maybe you could add a simple system run permissive toggle switch to allow for control without the heating run signal? Just thinking out loud. Hoping the better communications eliminates the behavior.
Hi,
Instead of using the stock ST device, you should use My Ecobee Device as it can refresh every 15 seconds if you want.
I have two ways to ‘refresh’ the values at the thermostat: 1) by polling 2) by doing a ‘refresh’.
The ‘refresh’ method is used when you need to get the latest values at the thermostat. It is usually called by the UI, but you can also call the method from a smartapp.
The ‘poll’ command is usually issued every 5 minutes, but there is nothing that can prevent you to do it every minute if needed. The poll command is (as indicated by its name) for polling only in smartapps.
In my zoned solutions, I sometimes call the thermostat’s "refresh’ capability when available in order to get the latest setpoints. I need this capability as the smartapps can set any ecobee climate/program (even the custom ones defined by the user) and the setpoints can be changed at the ecobee portal anytime.
In all cases (“refresh” and “poll”), I do check the ecobee revision numbers in order to avoid polling the ecobee servers when no thermostat values have changed.
In brief, you get what you pay for, and like my dad used to say, there is no free lunch…
Regards.
Thanks again Yves as it maybe that I will need your code to get the system to be responsive enough.
As an update, I just forced the vents to hopefully connect to my Hue White A19 repeater. I am getting 3-4 second open and close performance from the vents now when initiated from the app. I should have measured before the power off, but it does seem faster on the issue vent. I will play again with everything tonight.
Open ended comments such as these confuse me.
My dad used to say, “do what you say and say what you mean”
Are you suggesting that this app being free is somehow less capable of meeting its objectives than your paid app?, or is that proclamation being directed at the stock device type…
In any event, everyone knows where to find you, if they want to purchase your code they will, in the mean time I don’t need you over here pissing on my thread.
Reminder to @yvesracine. You wrote this back in December.
@Mike_Maxwell, nowhere in my comments I was referring to your app… I was obviously talking about the ST stock device, so please tone down your comments (amongst community developers, we really do not need that tone)…
So chill a bit.
P.S. BTW, I came to your thread because you mentioned me in it (see your post above). I will never come back again!
Continuing the discussion from [RELEASE] Keenect (vent control app):
I’d love to hear from people who’s thermostats are confirmed to work with this script. I don’t have one yet so I’m looking for options.
CT100 works. Anything that can talk to ST will work fine with it. Nest may be problematic but that is nothing to do with ST or Keenect it is a nest issue
So I finally got around to installing and configuring the app, I only have two zones for now as I just got the 2 vent+hub started set.
I previously had one vent manually set to 25% open, I have configured it’s zone to allow fully open to fully closed with an offset from the main thermostat of 0.
The temperature of the sensor in the room says it’s the same temp as the thermostat but it’s not closing the vent, I’m just wondering if that is normal operation.
Does it need to go above the thermostat temp before it will shut off?
Cheers,
Matthew