Various fixes

[rlippmann]

Handle trouble codes
Defer starting background tasks
Remove zones.py.orig
Add create_task callback
rebase from master
detect login failure earlier
setup.py qa fix

[rlippmann]

@rsnodgrass, sorry about the massive number of commits, I messed up the rebase.

I also had a question about how to deal with something. When looking for a trouble status, I parse the entire line looking for the state. Which also will return information like Open, No Motion, etc. Before state was simply always "Online". I intend to expose this as an attribute in Home Assistant to allow automations based upon the attribute (i.e. send a notification on low battery, device tamper, etc).

So should I just leave state as Online if there's no trouble, or keep it as is?

[rsnodgrass]

Having insight into the current status would be useful, especially the battery state of sensors. I'll leave it to you to figure out what you prefer regarding the Online return status.

NOTE: There are still conflicts, see above.

[rlippmann]

I’ve been going back and forth on the state issue. On one hand, it would be nice to see the underlying state string, since you can’t actually set it for a binary sensor in HA. On the other hand, it makes writing an automation trigger for a device failure slightly harder, since you’d need to use templates.

I suppose the state string is somewhat redundant, though.

[rsnodgrass]

No reason in HA you can't expose both a binary_sensor and another sensor that includes more detailed state. Or a binary sensor for state, plus a separate sensor for battery.

[sbabcock23]

@rlippmann - for one of my other projects I created objects, let's call it door sensor, then it had different attributes including state, battery %, gps location, etc.

On the HA side of things, being aware of these attributes allows you to create different entities associated with devices.