I additionally had custom switches to power on or off any nodes via home assistant, but I know that it didn't work the last time I tried it. I believe this was during testing the new version of the boards OS and I didn't had the time to invest fixing it at that time. As I remember, the changed some api calls, so maybe I just messed up some parameters to call the endpoints: configuration.yaml

yaml
command_line: !include_dir_merge_list commands/

commands/turing_nodes_power_switch.yaml

yaml
- switch:
    name: turing_pi_node_1_power
    command_on: "curl --insecure -u '<username>:<password>' -X POST 'https://<ip-address>/api/bmc?opt=power&type=set&node1=1'"
    command_off: "curl --insecure -u '<username>:<password>' -X POST 'https://<ip-address>/api/bmc?opt=power&type=set&node1=0'"
    command_state: "curl --insecure -u '<username>:<password>' -X GET 'https://<ip-address>/api/bmc?opt=power&type=get'"
    value_template: "{{ value_json['response'][0]['result'][0]['node1'] | int == 1 }}"
# Code would become to long for Discord, so just replace 'XXX' with the node index.
- switch:
    name: turing_pi_node_XXX_power
    command_on: "curl --insecure -u '<username>:<password>' -X POST 'https://<ip-address>/api/bmc?opt=power&type=set&nodeXXX=1'"
    command_off: "curl --insecure -u '<username>:<password>' -X POST 'https://<ip-address>/api/bmc?opt=power&type=set&nodeXXX=0'"
    command_state: "curl --insecure -u '<username>:<password>' -X GET 'https://<ip-address>/api/bmc?opt=power&type=get'"
    value_template: "{{ value_json['response'][0]['result'][0]['nodeXXX'] | int == 1 }}"

I'm still figuring out this part. Using the BMC API for on makes a lot of sense, but I'm wondering if leaving a switch on the card for an SSH based shut down command to the nodes (and possibly a later power down in BMC on a time/ping based automation) would be better.

Sorry to hear your tpi is unreliable too 😕. I really appreciate the help.

I didn't end up using info sensors, as this was depreciated with the new version of the BMC API, but did create a custom sensor for USB state, which combines the three fields (node, mode, and whether USB port/BMC routed) into a single value:

- resource: https://xx.xx.xx.xx/api/bmc?opt=get&type=usb
  authentication: basic
  username: user
  password: pass
  verify_ssl: false
  sensor:
    - name: tpi-usb-state
      value_template: "{{ (value_json['response'][0]['result'][0]['mode']) }} mode - {{ (value_json['response'][0]['result'][0]['node']) }} to {{ (value_json['response'][0]['result'][0]['route']) }}"
      unique_id: tpi-usb
      icon: mdi:usb

Still haven't decided exactly how to integrate power control yet into my cards. I'm tempted to make power off commands ssh-based calls to the individual nodes (to avoid dirty shutdowns), and possibly automate closing the power on the BMC if idle >10mins (this becomes a pseudo-watchdog) but worry it might fire inadvertently. I'm also grappling with whether to make the panel accessible to my partner for me-away troubleshooting, but there's possibly a need then to lock down certain things as you could end up with a non-operational state (eg. reverse proxy that most services rely on is powered off)

So I've got Home Assistant speaking nicely with the BMC now. It wasn't as straightforward as I hoped, as a command style switch wasn't reliably updating it's state based on the BMC. However in a slightly roundabout way I got it working with three entities per node. A) a binary rest sensor that provides on/off state of the node. B) A command-style switch which can send an on or off command for each node via a shell script. C) A template switch, that relies on the sensor to set states, and forwards any user On/Off requests to the command switch. Note this is only needed if you want a toggle style switch. If you're comfortable displaying state one one line of an entities card, and having separate on/off buttons on another row, you can skip step C.

A) Binary REST sensors /config/rest/turing_state.yaml:

- resource: https://IP-OR-HOST/api/bmc?opt=get&type=power
  authentication: basic
  username: user
  password: pass
  verify_ssl: false
  binary_sensor:
    - name: tpi-power-node1
      value_template: "{{ value_json['response'][0]['result'][0]['node1'] }}"
      unique_id: tpi-p1
      device_class: connectivity
      icon: mdi:power
{.... and so on}

B) Command switch Note the core issue with @blaickgaming's template above seems to be the use of http POST requests, because the API confusingly uses GETs for set commands. I've tried dozens of different permutations of the command_state and value_template options, and not been able to find anything that reliably updates the switch state over time. Not including them here means that this switch entity has separate on/off buttons rather than a toggle. This entity is where HA attributes all on off activity for graphing/activity log purposes (rather than the Template switch below, or the binary sensor) /config/commands/turing_switches.yaml:

- switch:
    name: tpi-node1
    command_on: "/config/commands/tpi-api.sh power_on node1"
    command_off: "/config/commands/tpi-api.sh power_off node1"
{...and so on}

I've also attached my shell script below: https://cdn.discordapp.com/attachments/1194509611139596318/1198935982075027498/tpi-api.sh?ex=65c0b725&is=65ae4225&hm=eeb8dffdefcb390ad863469f46156a02d92ee9911c62fc0cf46b0d1c575c4d5b&

C) Template Switch to tie it all together These are stored in /configuration/configuration.yaml because I couldn't be bothered troubleshooting a bigger config issue.

switch:
  platform: template
  switches:
    tpi_ts_node1:
      friendly_name: "Turing Pi Node 1"
      value_template: "{{ is_state('binary_sensor.tpi_power_node1', 'on') }}"
      turn_on:
        - service: switch.turn_on
          target:
            entity_id: switch.tpi_node1
        - service: homeassistant.update_entity
          target:
            entity_id: binary_sensor.tpi_power_node1
      turn_off:
        - service: switch.turn_off
          target:
            entity_id: switch.tpi_node1
        - service: homeassistant.update_entity
          target:
            entity_id: binary_sensor.tpi_power_node1
{... and so on}

This is an example of what the two-part non toggle switch looks like in HA https://cdn.discordapp.com/attachments/1194509611139596318/1198936695144460338/Screenshot_20240122-212526.png?ex=65c0b7cf&is=65ae42cf&hm=a524b1094d9ba528cee713fcc2f6a0a5a0aa02757f4d3b8b48104ac75d749544&

Note that the script I've attached here also implements most of the other state-changing API commands usb_boot, clear_usb_boot, network, node_to_msd, power_on, power_off, reboot and reload in case I need them in the future. Yes, I'm aware I reinvented the tpi binary in Bash 😕 but it was more suitable for my needs here. Due to bugs in how the API manages reset (my script couldn't handle node numbering in the original API's starts-at-zero-sometimes format) I haven't implemented it here, nor do I plan to try for the uart endpoint either.

Next steps are to get uptime and temperature integrated, but these will be via SSH calls as the API doesn't expose them.

I fully intend to run home assistant on the tpi so I will be grateful for your work once my board comes in