Migrate to MQTT from HTTPS polling

[unlobito]

The integration currently uses HTTPS polling to retrieve data from the CAD, but it'd be beneficial to use mqtt for real-time data instead.

This PR will cover implementing this in various stages:

• Use Bright appID rather than public appID (closes Use the standard app ID #15)
• Extend Glow bindings to implement the /api/v0-1/device endpoint for ZigBee device discovery
• Discover the Zigbee Glow Stick hardwareId for MQTT topic setup (SMART/HILD/$hardwareId)
• Migrate HTTPS sensors to MQTT (closes Use MQTT to get instant updates #14)
  • Current electricity usage
  • Last reported gas usage (closes Instantaneous usage reads are not available for gas meters #10)
• Extend with more sensors from MQTT data (closes Adding additional sensors #12, Add support for meter reading in addition to instant power #13)
  • Investigate available data fields
• [~] Create services for historical usage reads

[unlobito]

I think next up is refactoring Glow's constructor to accept the username/password from the restored ConfigEntry rather than a session token. Once the object has instance variables for the credentials, these can be used to calculate the MQTT connection URI (rather than the currently hardcoded USER:PASS).

Locally, this PR currently causes my HomeAssistant instance to console print the JSON messages received over MQTT (but the individual sensors report unavailable).

[unlobito]

Very rough on the edges, but we now have instantaneous electricity consumption being routed to an electricity sensor after MQTT autodiscovery.

MQTTPayload is heavily based on https://gist.github.com/ndfred/b373eeafc4f5b0870c1b8857041289a9, but I'd like to rewrite this to use a Colander schema instead of the if ... else None catches.

Afterwords, I'd like to route messages to sensors on a more unique key than the resource classifier (e.g. "electricity.consumption") so gas meters can be supported.

[bje]

Would it be possible to make the MQTT topic configurable as well? Happy with HILD being the default, but for some reason I've got a legacy account and I need to use SMART/DCAD/{hardwareId}

Maybe name it mqtt_topic_prefix, that has a default value of HILD?

[unlobito]

Hey @bje 👋 Thanks for raising this! That's an interesting edge case. I wonder if there's some way to automatically discover the right topic.

In the meantime, it seems there aren't any issues from subscribing to both topics (and only receiving messages from one), so I've put that in db42193.

[unlobito]

btw- I've opened a post on the official forums seeking advice on properly discovering the MQTT topic https://forum.glowmarkt.com/index.php?p=/discussion/75/mqtt-topic-variations

[unlobito]

Today:

• Attempted rewriting MQTTPayload in Colander but was unable to transparently rename the JSON key names (see stackoverflow/17975416)
• Built out MQTTPayload with manual payload mapping
• untested: attempted gas meter integration

I don't have a gas supply at home, so I'm eagerly looking for feedback on the gas readings added in 71af3ba. I've released this branch so far as https://github.com/unlobito/ha-hildebrandglow/releases/tag/0.1.0-beta for easier installation through HACS.

Next, will look into exposing more of the MQTT data as separate sensors so this PR can be released (services shouldn't hold this back).