battery_blocks() merges battery specific information from /api/system_status and /api/device/vitals
Currently, it is only pulling data from the TETHC block but more information is available in the TPOD and TINV blocks.
Pulling data from those blocks is a little harder since we'd have to match against the componentParentDin to find the battery serial number.
There should also be some thought on which design path to take when pulling in the info from the other blocks as, at first glance, there may be the same data already exposed via system_status. As such, we'd want to consider whether battery_blocks() should provide a merged view of all data or present the TPOD/TINV data in a separate block. I'd probably lean towards providing more data fidelity and show the data provenance, over ease of access.
battery_blocks() merges battery specific information from /api/system_status and /api/device/vitals
Currently, it is only pulling data from the TETHC block but more information is available in the TPOD and TINV blocks.
Pulling data from those blocks is a little harder since we'd have to match against the componentParentDin to find the battery serial number.
There should also be some thought on which design path to take when pulling in the info from the other blocks as, at first glance, there may be the same data already exposed via system_status. As such, we'd want to consider whether battery_blocks() should provide a merged view of all data or present the TPOD/TINV data in a separate block. I'd probably lean towards providing more data fidelity and show the data provenance, over ease of access.