There must be another rule that sets EcoMode on, because that one sets to off. What build are you on? I'm having a hard time seeing what is causing this error.
Please show me the System Events log for the time when the error happens. Rule Machine sends a location event to communicate with Thermostat Scheduler, and something about that event must be causing this error.
I am not able to reproduce this error.
No idea what app 6 is. Thermostat scheduler is app 7.
You posted the Logs before. On the left side of the ui there is a link for System Events. That's different and shows the Location Events (events being sent within the system, in this case by RM to TS).
App 6 is TS by the looks of your log. Click on the app 6 link (on left side) and it will show you which app it is (above). Click on the red error, and it will open that app in a new tab.
What are the device id's for your thermostats? Open the device page, the device id is in the url.
Seems like it isn't updating either thermostat to EcoMode now.
There appears to be something wrong with your rule. Does setting EcoMode from the TS UI work as expected?
yes. I have uninstalled the full rule app reinstalled and remade the rule and it dose the same thing.
I still need to now the device ID for the thermostats.
For fun, I successfully replicated on my own system what @Gilboy was seeing .
In addition to this error on one scheduler instance, I also got an extra "Cannot get property 'id' on null object on line 838 (extHandler)" from another scheduler instance.
Not too sure what the exact steps would be (it would not be too hard for me to reproduce if necessary I think) but I instantiated more than one scheduler and in the end, when I got the errors, the extra schedulers didn't show up in the installed apps list anymore, even though they were the ones associated with the log errors. To be able to access the apps, I had to use the app ID directly in the brower address (450 in this case):
"http://192.168.1.25/installedapp/configure/**450**/mainPage"
I was then able to remove the app, strangely enough, the rule I created to turn on ecomode was not invalidated for that scheduler.
I would bet that @Gilboy had a similar problem (app 6 is a ghost scheduler?):
I might try to erase everything and reboot to start from scratch since a few things seem to be screwed-up....
[update, after erasing everything related to thermostat scheduler/related devices/rules and rebooting, I just did this:
-
Created a new virtual device "virtual thermostat", nothing else done there.
-
Instantiated a "thermostat scheduler" instance, choosing the thermostat above, no other default settings changed except setting ecomode offset to 2.0.
-
Created a rule to set ecomode ON on the "thermostat scheduler" with a periodic schedule of 1 minute
Log now shows "java.lang.NullPointerException: Cannot invoke method minus() on null object on line 814 (extHandler)" every minute for the new scheduler instance.
The errors went away when I created a valid schedule for the "thermostat scheduler". So I guess instantiating the scheduler app without creating a schedule is at the origin of the problem? In the case of @Gilboy, I suppose the "ghost" scheduler must have that problem.
Erasing the scheduling app still didn't invalidate the rule created to change ecomode to ON. Based on what I see, it's as if the rule is not associated with a particular instance of the scheduler, just any scheduler that is associated with the thermostat selected in the rule. Erasing the thermostat device invalidates the rule however. I would assume that if several instances of the scheduler app reference the same thermostat, the rule will be applied to all scheduler instances, ghost or not...
I did a few more things after that and now I get " 2020-02-23 11:49:23.452 errorgroovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.math.BigDecimal#minus. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 814 (extHandler)", oh well... enough already]
@bravenel Is there any way to add the option to turn the thermostat to an "off" mode/state at a certain time instead of just temperature setpoints?
For example most mini-split units have modes like heat/cool/dry/fan/off/on
Example:
I want my garage heat pump to come on at 11pm to heat mode at 18degC (or "on" since it remembers the last heat/cool/dry and temp state in the heat pump itself) and turn to "off" mode at 7am every day.
If the times are set, maybe use RM?
Yes i did that and it works fine, just thought it could be added to this app as a feature. I wrote 2 rules one for ON and one for OFF
I will look into this as a possibility...
I have looked into this.
There are several reasons not to do this:
- It's not just as simple as Off; for turning back on the thermostat mode would have to be selected.
- Programmable thermostats do not allow programming the thermostat mode on a schedule.
- This feature would burden all users with programming the thermostat mode as part of their schedules.
- There would be substantial UI impacts of implementing this feature, as well as runtime complexity.
- There is a very simple way to handle this need, as you have already discovered using a simple rule.
For these reasons, we won't be adding this feature to Thermostat Scheduler.
Ok ,no worries. Thanks for looking into it.
Hi, I'm controlling my Thermostats using RM/Thermostat Scheduler. One of them is stuck in EcoMode.
It doesn't really affect my routine because temps are set by RM on a schedule. But my OCD would like for the app list to show Hold, like my other Thermostat.
I know I could create a temporary rule to turn Eco off and then scuttle it, but shouldn't we be able to set Eco in Thermostat Scheduler?
Just a suggestion... cheers!
edit: just discovered that a quick toggle between schedule/hold removes EcoMode. Who Knew? 
Still think it would be nice to have a way to manually trigger Eco on/off. But not urgent/necessary.
