Ecobee v3.4.1 Periodically Stalls - java.lang.NullPointerException: null

Add-ons Bindings
1

I starting using the Ecobee binding on a RaspberryPi 3B on openHAB 3.4.1(openhabian build).in April. In early August, I noticed that the temperature was not updating. Checking the logs around the time of the last update, I found:

2023-08-02 23:07:23.729 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
        at org.openhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler.refreshThermostats(EcobeeAccountBridgeHandler.java:219) ~[?:?]
        at org.openhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler.refresh(EcobeeAccountBridgeHandler.java:210) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]

Disabling and re-enabling the Ecobee Account ‘Thing’ resolved the issue. However, it happened again a few days ago - same error.

A quick check found Ecobee Stopped Reporting which appeared related to DST, and Ecobee binding v2 - #212 by Dave_Baldwin in “Ecobee binding v2” but I could not find a resolution. Is there anything I can do to help diagnose the problem? I do not see anything earlier in the logs that might trigger the issue.

2

I am the OP of that first thread you link to. I am not away of a way of preventing these things from dropping. They are good for a while, then I get a slew of them go offline. I get notification so I know when it happens, but I do have to go in there and delete/reinstall the account Thing.

Are you saying you have been able to get the same result by just disabling and re-enabling with the pause button?

image
image741×48 2.51 KB

3

Yes, via the control that you showed for the “Ecobee Account” Thing. As soon as I enabled it again, OpenHAB started receiving data from the Ecobee. When I get a chance, I will see if I can automate the process of detecting that there have been no updates for a while, either directly via a rule or through the CLI.

1 Like
4

You might try comparing against the runtime#lastStatusModified channel value. I am a bit confused by the timezone that I see there but assuming you don’t have or can resolve that confusion, I have seen that datetime stamp freeze when updates stop. Perhaps you can enable/disable the Thing when the thermostat Thing’s last modified channel is too old?

5

Or, alternatively, set an Expire timer on the thermostat’s measured temperature value that sets the value to UNDEF, and use the temperature change to UNDEF as a trigger for a script to disable and then re-enable the Thing?

6

It looks like I can define an expire time via the item’s Add Metadata. I could use Actual_Temperature and set a long expiry time (a few hours) in case the temperature in the house is stable. I can then set up a rule that detects when Actual_Temperature becomes UNDEF (or whatever value I select) that then invokes a script to restart the Ecobee Account. I can test it by setting a short ‘expire’ time.

I will try this next week and report back.

1 Like
7

I created a rule that triggers when Ecobee_Thermostat_Main_Floor_Actual_Temperature is updated to UNDEF and calls a resetecobee.sh script passing the thingUID

#!/bin/sh
echo "Attempting restart" | /usr/bin/mail -s "OpenHAB Ecobee appears to be hung" "<email>"
/usr/bin/openhab-cli console -p <password> openhab:things disable "$@"
sleep 5
/usr/bin/openhab-cli console -p <password> openhab:things enable "$@"

To test it, I set the Actual_Temperature Expiration Timer to five minutes. Once I verified that the rule worked, I increased the timer to three hours which appears to be a good balance between timely response and false positives. If anyone is interested, I can write up what I did in more detail.

To speed up detection and recovery, I believe I can pipe events.log, scan for the java.lang.NullPointerException event, and use that to trigger my script.

1 Like