Skip to content

Fixes and enhancements

Choose a tag to compare

View all tags
@m3tac0de m3tac0de released this 31 Jan 15:11
0.0.8
4e88bce
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Changes to the card, now at version 0.0.8:

  • Fixed an issue where the Select would not repopulate when coming back online after the remote entity being unavailable.
  • Moved the position of the Automation Assist switch in Visual Configuration (i'd like it to be slightly more findable)
  • Added support for Activity changes/Power Off to Automation assist:
    • Automation Assist will now also provide YAML for Activity changes and POWER OFF.
    • When deploying MQTT triggers, users now have the option to also create triggers for Activity changes.

Automation Assist is designed for making your own automations and dashboards a little bit easier.

image image image

Please note:

While working on this card issues with the X2s MQTT implementation were found. The official X2 integration is most impacted, and symptoms of underlying problems include: the integration's entities no longer being available, the integration's remote entity no longer being available, or not populated with Activities, the integration no longer being aware of Activity changes.
This card is impacted by these issues. The known workaround, to request "basic_data" from the hub, has been built into this card since its initial version. But this is not bulletproof.

The official integration itself does exactly this "basic_data" request as it starts up, yet somehow loses state along the way. It's been identified that this is due to the hub itself inconsistently returning data when requested to. This appears to be a progressive issue, where ultimately a hub reboot is the only 100% fix, until the conditions have been created for the MQTT implementation to start failing again.

To understand the hub's failing MQTT implementation, we distinguish between between STATE and METADATA. METADATA is our list of activities and their IDs. STATE is which one is active right now. METADATA is also the list of all commands that are part of a particular device and their IDs, and STATE is which one you pressed now.

In the X2s MQTT implementation, everything METADATA is essentially broken. 2 major problems:

  • It does not deal with concurrency. Sending a request for METADATA, while the hub is still processing a response for a previous request for METADATA, leads to state corruption and ultimately the failing of the entire hub. Only recoverable through a restart of the hub.
  • It does not deal with large responses. Large datasets, such as commands for an AVR, fail to return over MQTT, while significantly increasing exposure to concurrency issues.

Note that even while METADATA starts to fail on the hub, STATE and the ability to manipulate it remain fully functional (to the extent that STATE is not internally dependent on METADATA, which in the case of "Activity change" it is).

METADATA is mostly static, yet the current architecture makes clients constantly retrieve the same data, while the mechanism for it is a liability.

Assets 3
Loading