1) I have noticed a weirdness on the EcoBee plugin that seems to occur sometimes after a restart. It seems when the luup engine is overloaded (causing a restart) both the cool and the heat go to their respective temperature extremes (-400, +400). It does not occur after EVERY restart, so I am trying to re-create the error in order to solidify more specific events which will be more helpful for you in thinking about this problem. In the meantime, I was wondering if you had ever observed such behavior?
I have not seen anything like you are describing, but when you say "go to their respective temperature extremes" do you mean that the UI is showing that the setpoints are at these extremes but checking at ecobee.com verifies that the UI is wrong, or that the plugin sets the setpoints as such to the thermostat, or what exactly? There is nothing in the plugin that will set these values to those extremes. Make sure you have debug logging (LogLevels must include 35 in the list) so if you are able to re-create this situation, we can have logs to examine. Sorry nothing comes to mind on this one, but maybe if you have more detail, it would help me think of something to try or inspect.
2) I also have noticed, rarely, but sometimes the plugin loses comms with the Ecobee server, requiring a re-entry of the PIN#. I know you have noted in your github notes that sometimes external events may cause this. Are there any events in particular you have noticed that we can be wary of in order to predict when a lost comm is more likely to occur? Or better yet, would it be possible to add a sent alert or notification when the ecobee loses comms?
I too have noticed this rare occurrence, requiring me to press "Get PIN" and then enter the new PIN in the ecobee.com portal. It might be weeks and weeks before this happens, and I have no idea what is causing it. I have always assumed that it was the consequence of some required maintenance going on at Ecobee with their API, where existing tokens need to be flushed, but that is just a wild guess. I can't think of anything in the plugin that would be falsely reporting the need for a new PIN. Look in your logs for "Encountered authorization error; forgetting tokens." and look for messages immediately preceding it to see what is being reported as to the cause. The set of errors that would tell the plugin to forget its auth_token are:
invalid_request = "The request is malformed. Check parameters.",
invalid_client = "Authentication error, invalid authentication method, lack of credentials, etc.",
invalid_grant = "The authorization grant, token or credentails are expired or invalid.",
unauthorized_client = "The authenticated client is not authorized to use this authorization grant type.",
unsupported_grant_type = "The authorization grant type is not supported by the authorization server.",
invalid_scope = "The requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner.",
not_supported = "HTTP method not supported for this request.",
account_locked = "Account is temporarely locked.",
account_disabled = "Account is disabled.",
authorization_pending = "Waiting for user to authorize application.",
authorization_expired = "The authorization has expired waiting for user to authorize.",
slow_down = "Slow down polling to the requested interval."
If the ecobee API returns any of these except "authorization_pending," then the plugin will throw away its auth_token and require you to request a new PIN. Perhaps check with your contact at Ecobee to determine if this list of API error returns is too long, and that some of these returns would not suggest that the session needs to be discarded.
On the subject of knowing when this happens, it is relatively straightforward for one to set up an automated notification when the plugin enters the state where it needs the user to request a new PIN. It is also easy to use the GetPIN UPnP action to perform the request for a new PIN, but much trickier (and outside the scope of the plugin) to automate the entering of that PIN in the ecobee.com web portal. So the process of knowing when authorization has been lost and then re-establishing authorization is nearly fully automatable (but that last step would be pretty tricky unless you had a web page automated testing tool, for example).
Thanks again for all your hard work -- it is not under-appreciated! 
My pleasure. Please report back here what you can so other plugin users can benefit, and thanks!
Regards,
watou
