[BETA RELEASE] Keenect V2.7 and Keenzone 2.8, Proportional Vent Control with System Wide Zone Balancing

I think I found the cause of the vent that is being told to be closed once a minute. I will see if this clears the rest of the issues. I had a smart lighting routine that was doing it. I was suprised that when I removed a turn off vent @ 5AM and turn on @ 5pm that it was doing a 1 per minute close command. (I had forgotten I had that rule.

Thanks for the help!

Well it took care of the close every minute issue, but I still have behavior issues:
All zones are set to a min opening of 30

Main
12:44:49 PM: debug checkNotify:exit-
12:44:49 PM: debug notifyZones:exit-
12:44:48 PM: info Main HVAC state changed to: cool
12:44:48 PM: debug notifyZones:enter-
12:44:48 PM: debug dataSet: [msg:stat, data:[initRequest:false, mainState:cool, mainStateChange:true, mainMode:auto, mainModeChange:false, mainCSP:79.0, mainCSPChange:false, mainHSP:72.0, mainHSPChange:false, mainOn:true]]
12:44:48 PM: info PARENT Ouput Reduction Off
12:44:48 PM: info checkNotify- mainOn: true
12:44:48 PM: info checkNotify- mainState: cool
12:44:48 PM: info checkNotify- mainHSP: 72.0, mainHSPChange: false
12:44:48 PM: info checkNotify- mainCSP: 79.0, mainCSPChange: false
12:44:48 PM: info checkNotify- mainMode: auto, mainModeChange: false
12:44:48 PM: info checkNotify- mainFan: on, temStr: on
12:44:48 PM: info checkNotify- mainFan: on, mainFanChange: false
12:44:48 PM: debug checkNotify:enter-

zone 1
12:45:49 PM: info setVents- [Becca Vent], changeRequired: false, new vo: 0, current vo: 0
12:45:49 PM: warn setVents- newVo: 0
12:45:49 PM: debug setVents:enter-
12:44:49 PM: info CHILD Requesting System Reduced Ouput
12:44:49 PM: info setVents- [Becca Vent], changeRequired: false, new vo: 0, current vo: 0
12:44:49 PM: warn setVents- newVo: 0
12:44:49 PM: info vent at min VoLocal null
12:44:49 PM: debug zoneEvaluate:exit-
12:44:49 PM: info CHILD zone temp is 80.0Ā°F, cooling setpoint of 77Ā°F is not met, setting vents to 0% output reduction false
12:44:49 PM: debug setVents:enter-
12:44:49 PM: info Parent needs offset
12:44:49 PM: info CHILD evaluateVents Cooling
12:44:49 PM: info Main HVAC is on and cooling
12:44:49 PM: info zoneEvaluate- system start up, evaluate: true
12:44:49 PM: info no change in state
12:44:49 PM: info Zone is enabled no zone climate selected always enabled
12:44:48 PM: info Zone output redution disabled

zone 2
12:46:55 PM: info Zone output redution disabled
12:45:49 PM: error java.lang.NullPointerException: Cannot invoke method toInteger() on null object @ line 1040
12:45:49 PM: warn setVents- newVo: null
12:45:49 PM: debug setVents:enter-
12:44:48 PM: debug setVents:enter-
12:44:48 PM: info Parentdose not need offset
12:44:48 PM: info Main HVAC is on and cooling
12:44:48 PM: info zoneEvaluate- system start up, evaluate: true
12:44:48 PM: info no change in state
12:44:49 PM: debug zoneEvaluate:exit-
12:44:49 PM: info CHILD Clearing System Reduced Ouput
12:44:49 PM: info setVents- [Master bath Vent], changeRequired: true, new vo: null, current vo: 42
12:44:48 PM: info CHILD zone dose not need offset
12:44:48 PM: info CHILD evaluateVents Cooling
12:44:48 PM: debug zoneEvaluate:enter-- parameters: [msg:stat, data:[initRequest:false, mainState:cool, mainStateChange:true, mainMode:auto, mainModeChange:false, mainCSP:79.0, mainCSPChange:false, mainHSP:72.0, mainHSPChange:false, mainOn:true]]
12:44:48 PM: info Zone is enabled no zone climate selected always enabled
12:44:48 PM: info Zone output redution disabled
12:44:49 PM: error java.lang.NullPointerException: Cannot invoke method toFloat() on null object @ line 904
12:44:49 PM: debug levelHandler:enter-

zone 3

12:46:55 PM: info Zone output redution disabled
12:45:48 PM: error java.lang.NullPointerException: Cannot invoke method toInteger() on null object @ line 1040
12:45:48 PM: warn setVents- newVo: null
12:45:48 PM: debug setVents:enter-
12:44:49 PM: error java.lang.NullPointerException: Cannot invoke method toFloat() on null object @ line 904
12:44:49 PM: debug levelHandler:enter-
12:44:48 PM: debug zoneEvaluate:exit-
12:44:48 PM: info CHILD Requesting System Reduced Ouput
12:44:48 PM: info CHILD zone temp is 79.0Ā°F, cooling setpoint of 79Ā°F is met, setting vents to null%
12:44:48 PM: warn setVents- newVo: null
12:44:48 PM: info Parent needs offset
12:44:48 PM: info zoneEvaluate- system start up, evaluate: true
12:44:48 PM: info no change in state
12:44:48 PM: debug setVents:enter-
12:44:48 PM: info CHILD zone needs offset
12:44:48 PM: info Zone is enabled no zone climate selected always enabled
12:44:48 PM: info CHILD evaluateVents Cooling
12:44:48 PM: info Main HVAC is on and cooling
12:44:48 PM: debug zoneEvaluate:enter-- parameters: [msg:stat, data:[initRequest:false, mainState:cool, mainStateChange:true, mainMode:auto, mainModeChange:false, mainCSP:79.0, mainCSPChange:false, mainHSP:72.0, mainHSPChange:false, mainOn:true]]
12:44:48 PM: info Zone output redution disabled

Can you try changing from an absolute temp value for a zone to an offset on all zones.

Before you change the temp try changing out of auto and setting to cool or heat. Looks like I have not taken into account auto changeover.

I put it into cool only and I get:
3:40:20 PM: error java.lang.NullPointerException: Cannot invoke method toFloat() on null object @ line 476
3:40:20 PM: info checkNotify- mainCSP: 79.0, mainCSPChange: true
3:40:20 PM: info checkNotify- mainMode: cool, mainModeChange: false
3:40:20 PM: info checkNotify- mainFan: on, mainFanChange: true
3:40:20 PM: info checkNotify- mainFan: auto, temStr: on
3:40:20 PM: info checkNotify- mainState: cool, mainStateChange: true
3:40:20 PM: debug checkNotify:enter-

Line 476 is unhappy since it is cool only and there is no hot setpoint?

I get no logging from my zones now.

what thermostat do you have?

if its a nest please change the setpoints of the thermostat this seams to be a common problem with nest the first time connected to smartthings.

the line 476 is complaining because your thermostat is sending back a null and the system is checking to see if a difference between the stored mainCSP and the current setting is changed. Because your stat is returning null the system recognizes a change but does not have a value.

I have seen this several times when a person starts the system on heat and connects to smarthings with a nest or other thermostat it appears not to transfer the temp values correctly.

change the cooling setpoint and this should resolve the problem.

I do have a Nest.
I tried what you suggested, but I still get the exception.
I can get it to go away by going to heat or auto.
looking at the line, it sort of makes sense that the line could have an exception since there is no heating setpoint in cool:
tStat.currentValue(ā€œheatingSetpointā€).toFloat()

Craig

can you go to your thermostat in smartthings in the ide and see what the device is reporting for a heatingsetpoint in the ide it should persist as a value?

I can write around nest if it does not provide a setpoint for cool when in heat or vice versa.

Looks like my nest handler does not do it, bummer.

				if(hvacMode in ["cool", "auto", "eco"] && state?.can_cool) {
					coolingSetpointEvent(coolingSetpoint)
				} else {
					clearCoolingSetpoint()
				}
				if(hvacMode in ["heat", "auto", "eco"] && state?.can_heat) {
					heatingSetpointEvent(heatingSetpoint)
				} else {
					clearHeatingSetpoint()
				}

And there it is. Now why would someone write into the dth to clear the setpoints is beyond me, no other thermost device type does this. That entire section needs to be reworked so as to not call both clear setpoint functions during mode changes. The if sections can remain, but the else sections need to go.

Mike your correct the dht sucks. I can also write around this problem and based on the thermostat operating state grab the appropriate set point. This is a pain but will ultimately work.

I should probably identify a set of dhtā€™s that work with our system and recommend them.

1 Like

Craig

In you dht for nest comment out using // before the clear statement after else and see if the system works as planned.

it is important to note, that the value is ā€œinvalidā€. Nest does not allow reading of the setpoint.

You can set it to any value you like, just know that it is ā€œnot the truthā€. Making a decision on an invalid piece of data can have other reprecussions.

That section of code is clearly part of the dth implementation, it is forcing a null value when changing modes, this isnā€™t being set by the thermostat proper, and I doubt setting it to null (or not), has any effect on the nests internal functionality. The dth is clearly overriding the setpoints when changing modes, and I can see no valid reason for it to do so. Maybe this was put in place as a simplistic way of determining what operating state the system is in, but there are thermostat attributes for that, even when the stat is running in autoā€¦

FYI, I am using the nest manager found here. Nest Manager

When I can sit down and spend some time looking at it, I will go in and comment out the code.

Commenting it out did not fix the exception.
Craig

On another note, anyone know how to modify the Smartthings motion sensors to report 0.1 degrees or suggest a different sensor?

After commenting this out did you cycle the ac?, unless you flipped the ac on at least once the set point will still be null.

This is the one I useā€¦

1 Like