Ensure only one PowerCommand and ActivePowerCommand is queued

[schlimmchen]

Neither a PowerCommand nor an ActivePowerCommand shall be enqueued if another one (of the same type) is already pending.

Adding multiple PowerCommands or ActivePowerCommands is not bad in general, but suppose the following situation:

• An ActivePowerCommand was queued and the command state was set to CMD_PENDING.
• The radio is busy with the queue, maybe communication is unreliable and it takes some time.
• Another ActivePowerCommand is queued and the command state is set to CMD_PENDING again.
• The radio finished working on the first ActivePowerCommand. The "last command state" is changed to CMD_OK or CMD_NOK.
• The state is now inconsistent: There is an ActivePowerCommand pending, but the "last command state" is not CMD_PENDING.

This check restricts one of each of the commands per inverter. It seems to me that this is a reasonable limitation.

Another possible solution might be to check the radio queue for other commands of the same type and keeping the CMD_PENDING state. This is computationally more expensive, but would make sure that racing commands would all be processed. The current implementation will reject a second command of the same type.

[stefan123t]

Reading up on this in relation to #1201.
As this describes your reasoning quite well with regards to the core issue in queued Commands I would explicitly link it to that PR once more.

While I understand your restriction to one of the commands each per command type and inverter in the queue, I think there might be two intended solutions:

a) FIFO: as you described allow only one command per type and inverter and do not allow new commands until this has executed.
Easy to implement but maybe not intended.
It might send an outdated limit and prevents to send a new one until the old one has been acknowledged by the inverter.

b) LIFO: allow only one command per type and inverter and remove the old command from and add the new command instead to the queue. This may be more complex as we would need to discard the inverter response from the radio, eventually discarding received data and preventing the radio loop to request potentially missing frames / packets.
From an end-user perspective this may be better as it would always use the latest limit in the command. On the other hand it may try to send a limit and retry from scratch with a new limit before the inverter acknowledged the old limit.

Also note that the radio may have to send multiple packets or frames and/or may receive multiple response packets / frames. For multiframe responses the radio may have to re-request the missing packets.