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

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( ~[?:?]
        at org.openhab.binding.ecobee.internal.handler.EcobeeAccountBridgeHandler.refresh( ~[?:?]
        at java.util.concurrent.Executors$ ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset( ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]
        at java.util.concurrent.ThreadPoolExecutor$ [?:?]
        at [?:?]

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.

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?

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

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?

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?

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

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

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