"0" prefixed PINs in HASS not accepted

[alistairg]

Describe the bug

During the awesome new configuration flow in the beta component for apple_tv, I'm prompted for a series of PINs. The entry field is obviously expecting an integer, rather than a string, so cunningly deletes a "0" if the pin starts with one (e.g. 0123). This means pairing fails, and you have to keep retrying until Apple TV generates a new PIN.

To Reproduce

Try entering a PIN with a zero prefix, e.g. 0123. HASS will change it to "123" in the text field.

Expected behavior

I need to be able to enter 0123.

System Setup (please complete the following information):

• OS: [e.g. Debian] Hass.io
• Python: [e.g. 3.6.2] Hass.io
• pyatv: [e.g. 0.3.10] Beta plugin via CACS

Additional context

[postlund]

Ah, yes, I can see how this is a problem. I'll make sure to fix it in the next release. Thanks for reporting!

[postlund]

This should be fixed now since I merged #299. Next time I make a new pre-release and update the component it will be possible to verify.

[postlund]

Fix was included in latest component update, so I will close this now.

[JesseWebDotCom]

Still getting this issue - just installed. Pin code erases when the pin starts with a 0

[postlund]

@JesseWebDotCom Which protocol are you pairing?

[glassbase]

I think this is HA issue. Doesn’t accept leading zeros.

Related - I just had this happen when repairing my PS4. PS4 provided a leading zero pin, it said “invalid user input” or something like that. Regenerated code (that didn’t start with 0) on PS4 and it worked.

Could be wrong?