So I made a rule to do EcoMode and set a fixed temp rather than doing an offset with the Thermostat Scheduler. I've made the rule three times now. It installs and I can edit it up but it seems like after it runs once or twice then I get:
Here's the rule after I just recreated it will see if it fails for the third time:
The "Door Contacts" are a collection of 3 sensors and grouped into this virtual device using the "Device Group" app. Note that I have had this group working just fine with other rules for over a year but I mention it just in case.
I don't see anything there that should cause a problem. From the error, if I had to guess, it's failing when trying to convert some numeric value--probably not that contact "group"--but I can't really say anything for sure. If "Logs" shows any specific line number for the error, staff may be able to look into this more (and might want additional information like the "App Status" page).
Will look if it occurs again. Thanks.
So this morning the rule didn't fire again and sure enough:
I did notice one thing I forgot in the rule that I did fix yesterday but it worked fine after during the day. I added a statement in each block of code to toggle the Eco_Set boolean as approprite.
Here is the log:
@bravenel any idea what might be causing this? The rule has done this 3 times now. Each time I recreated it and within a day it throws that error.
Thanks!
Look at the Application State right after it throws the error, and see what values it shows for the local variables there, most likely for "lv.Temp.Hold".
I'll need to setup the rule again. It should be 77 as it always was showing the correct value in the rule so not sure why it would be anything but a number. I'll work on that tomorrow again.
Actually it's there from earlier and it's blank. But I never set it to blank so how is that happening?
Dunno. But that's the reason for the NPE. Something set it to null most likely. And the obvious culprit would be the thermostat setpoint fetch.
It's odd as it will run a full cycle a couple times but then the next day it fails. Maybe someone else will have a similar problem over time and whatever causes it will be come apparent.
Have you check the events in the Thermostat device to see if there are events that are setting the thermostatSetpoint to null?
I did not. I did just rework the logic a bit. Made the temp hold variable global just in case I want it in the future and changed the Eco_Set to a switch so I can disable the thermostat scheduler when Eco_Mode is on as that was also causing issues for me. Will see if this behaves better.
@bravenel
Same thing with this modified rule but it didn't take overnight to fail. It did successfully trigger and set the thermostat and turned on the Eco Mode virtual switch. But I just tried to go back into it now and I get:
Log is:
Full status:
I hope all that helps....
I made the Temp_Hold variable global and it shows that it's still null yet it was assigned in the rule. Unless the thermostatSetpoint doesn't have a value. I assumed it would be the current setpoint no matter the mode of cool or heat. If not what should I use to get that value?
Thanks.
As suggested above, pull up the device events. Something is setting that variable to null.
Thermostat status...
Rule Machine status...
Note I had initialized the global Temp_hold variable to 77.0 but now it shows null. I have nothing setting it to null so I have no clue what is doing that. Note that I just set it back to 77.0 and now I can get into the rule again but still no idea what made it null other than the assignment of:
Is there a different way I should be getting the current thermostat setting?
Changed it to use "temperature" as it should match the setpoint when I want to freeze it. So maybe that will work without nulling it out. I'll cycle it and see what happens.
Looks like that didn't null it out but did set it correctly. So I guess I'm not understanding what "thermostatSetpoint" is used for or my device doesn't return anything for that value. I can probably live with it like this.
Just look at the device page. It shows all of the current attribute values.
thermostatSetpoint is an odd one, as it is derived from heatingSetpoint or coolingSetpoint depending on thermostat mode being auto. It's not a base level attribute, and I can well imagine it being set to null in some circumstances. It's created in the first place for Alexa and GH.
Changed it to use the heatingsetpoint and the coolingsetpoint directly. Will see how those behave.
Looks like those work (well at least the coolingsetpoint).
