fix: Companion X10s Express, ISRM receiver name missing

[mha1]

fixes #3273

The reason Companion doesn't show any registered ACCESS receivers is simply because color LCD radios don't populate the pxx2.receivers bit field after successfully binding receivers. Companion checks the bit field in yaml tag receivers: and as the bit filed results to no bit set it doesn't show the receiver names. Which in turn leads to the situation that all receivers are lost when playing back the model.yml file to the radio, forcing users to bind their receivers again.

Changes:

1. Color LCD (and simu) now set the correct bit in the pxx2.receivers bit field after a successful (or simulated) bind
2. Companion and radio firmware check after loading model.yml if pxx2 receiver names are given. If so it updates the pxx2.receivers bit field accordingly to spare users having to rebind their receivers.

As this is not only a 2.9 problem (it's present at least in 2.8.1 too) I think a similar fix (or a better one) should be worked out for 2.8.2 as well.

Edit: actually this can be cherry picked into 2.8.2 if desired

Edit2: don't know why the checks are failing with:

 Error response from daemon: received unexpected HTTP status: 503 Service Unavailable
  Warning: Docker pull failed with exit code 1, back off 1.551 seconds before retry.

[pfeerick]

Other than Neil's comments, I don't see any real problem with this going into 2.8.2 as well. I do wonder if the postModelLoad stuff could be better fixed as part earlier in the yaml load, but that is probably as good a place as any.

Edit2: don't know why the checks are failing

It's worth checking www.githubstatus.com when that happens, errors like that suggests it's github intrastructure having issues - which according to the history it looks like there was something.

[mha1]

@elecpower Thanks for your review. Following your suggestion I transferred correcting .receivers to the Companion yaml parser (decode()) and changed the comment.
@pfeerick I think postModelLoad() is the perfect place as it looks like it was made to do onetime cleanup/additional stuff after loading model data. Doing the same thing as for Companion would be much harder as Companion bare bone parses yaml data. Radio firmware seems to use a tree walker driven by data definitions. Wouldn't want to go there.

Tested ok. Faulty Yaml in:

moduleData: 
   0:
      type: TYPE_ISRM_PXX2
      subType: ACCESS
      channelsStart: 0
      channelsCount: 8
      failsafeMode: CUSTOM
      mod: 
         pxx2: 
            receivers: 0
            racingMode: 0
            receiverName: 
               0:
                  val: "RX4R    "
               2:
                  val: "SimuRX2"

Companion corrects receivers:

Companion or radio corrected yaml out:

moduleData: 
   0:
      type: TYPE_ISRM_PXX2
      subType: ACCESS
      channelsStart: 0
      channelsCount: 8
      failsafeMode: CUSTOM
      mod: 
         pxx2: 
            receivers: 5
            racingMode: 0
            receiverName: 
               0:
                  val: "RX4R    "
               2:
                  val: "SimuRX2"

[mha1]

Github status ok but checks failing with:

  Warning: Docker pull failed with exit code 1, back off 3.301 seconds before retry.
  /usr/bin/docker --config /home/runner/work/_temp/.docker_96985be7-949d-4376-bdae-5aabf9441d89 pull ghcr.io/edgetx/edgetx-dev:latest
  Error response from daemon: Get "https://ghcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

[pfeerick]

Give it time, probably just hit the start of another outage event. Some of the tasks are running though, so it's intermittent.

[mha1]

Thanks.

Shouldn't this also go into 2.8.2?

[pfeerick]

Yes, when I push the 2.8 branch next.