Skip to content

Use zeroconf UUID if not available via IPP properties #33991

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
balloob merged 1 commit into from
Apr 10, 2020
Merged

Use zeroconf UUID if not available via IPP properties #33991

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion homeassistant/components/ipp/config_flow.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,7 +116,8 @@ async def async_step_zeroconf(self, discovery_info: ConfigType) -> Dict[str, Any
_LOGGER.exception("IPP Parse Error")
return self.async_abort(reason="parse_error")

self.discovery_info[CONF_UUID] = info[CONF_UUID]
if info[CONF_UUID] is not None:
self.discovery_info[CONF_UUID] = info[CONF_UUID]
Comment on lines +119 to +120
Copy link
Copy Markdown
Member

@balloob balloob Apr 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why only do it sometimes? Are they the same? Could it be that we only detect one at some point and not another, so same printer is identified by 2 unique IDs?

Copy link
Copy Markdown
Contributor Author

@ctalkington ctalkington Apr 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so printer manufacturer decide what IPP spec and the device id property is recommended in 2.0 and required in 2.1 but that means the bonjour could provide an UUID but it not be available in the actual IPP data

Copy link
Copy Markdown
Member

@balloob balloob Apr 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So why not always use bonjour ?

Copy link
Copy Markdown
Contributor Author

@ctalkington ctalkington Apr 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

id have to check specs again but im not sure bonjour definition requires it either. Manufacturers like to play fast and loose with specs.

Copy link
Copy Markdown
Contributor Author

@ctalkington ctalkington Apr 11, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so according to IPP Anywhere 1.0 specthe values should match (though thats assuming manufacturer follows spec):

4.2.3.8 UUID
The REQUIRED "UUID" key provides the value of the "printer-uuid" Printer Description
attribute [RFC4122] [PWG 5100.13] without the leading "urn:uuid:". For example, if a
Printer reports a "printer-uuid" value of:
urn:uuid:12345678-9ABC-DEF0-1234-56789ABCDEF0
The "UUID" key will have a value of:
12345678-9ABC-DEF0-1234-56789ABCDEF0
Note: The "printer-uuid" value is used instead of "device-uuid" because DNS-SD identifies
services and not devices.

Copy link
Copy Markdown
Contributor Author

@ctalkington ctalkington Apr 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This printer-uuid property also was added as an extension PWG 5100.13 and isnt part if IPP 2.0,2.1 or 2.2 so that complicates the playing field

Copy link
Copy Markdown
Member

@balloob balloob Apr 11, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fun 😆


await self.async_set_unique_id(self.discovery_info[CONF_UUID])
self._abort_if_unique_id_configured(
Expand Down