Supporting raw and pronto optional parameter without type specifier.

[cnrd]

I think that as we support auto detection of the command type without needing to specify the command type, we should also be able to use the optional parameter of those commands without needing to specify the command type.

I tried running the following two commands which both specify the optional parameter for each command type:

{
  "entity_id": "remote.bedroom_mi_ir_remote",
"command": "Z6VPAAUCAABgAgAAxQYAAOUIAACUEQAAqyIAADSeAABwdQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFEBAQEBAQEBAgICAgICAgEBAgECAQEBAQIBAgECAgICBgNXA1cDUA:38400"
}

{
  "entity_id": "remote.bedroom_mi_ir_remote",
"command": "0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0622 015B 0057 0016 0E6C:4"
}

Here are the error messages:

2018-01-30 23:49:46 ERROR (SyncWorker_3) [homeassistant.components.remote.xiaomi_miio] Transmit of IR command failed, Z6VPAAUCAABgAgAAxQYAAOUIAACUEQAAqyIAADSeAABwdQEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFEBAQEBAQEBAgICAgICAgEBAgECAQEBAQIBAgECAgICBgNXA1cDUA:38400, exception: Invalid command type

2018-01-30 23:51:04 ERROR (SyncWorker_0) [homeassistant.components.remote.xiaomi_miio] Transmit of IR command failed, 0000 006C 0022 0002 015B 00AD 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0041 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0016 0016 0016 0016 0016 0016 0041 0016 0016 0016 0041 0016 0016 0016 0041 0016 0041 0016 0041 0016 0041 0016 0622 015B 0057 0016 0E6C:4, exception: Invalid command type

[syssi]

Are you sure this is a good idea? IMHO two variants (string without colons, string with colons and optional end) are straightforward. We shouldn't introduce more complexity here.

Especially if you validate the optional parameters at home assistant properly you would be lost. At the moment you are able to implement a service schema which validates the optional parameters (repeats vs. frequency) dependending on a (required &) supplied command type.

[rytilahti]

After giving this some more thought, I agree with that notion. It's better to keep the interface simple and try not to handle all weird corner cases. The error message will be just fine to notify the caller on that error.

One thing that could be done to make it easier to spot the error would be echoing the command type which is considered invalid back, then there'd be no mistake whatsoever. What do you think?

[cnrd]

I agree with both of you, I did also have a concern about the optional parameter having different meanings.

Either echo it back or return an error about not supporting it (If that is possible without it being as complex to support as different cases).

[yawor]

I've actually omitted this case on purpose when implementing the auto-detection and prefixes. In addition to the reasons you've already mentioned (different meaning of the optional argument) there's also the fact that if the user needs to play with optional argument they should know what format they are dealing with. Adding few extra characters as a type prefix won't do any harm. I even think that explicit type declaration is still a lot better (even when no optional args are used) than using the auto-detection, as it makes things less likely to break.

[rytilahti]

Ok, I think we are in agreement that this is better kept as it is, let's close this!