Skip to content
This repository was archived by the owner on May 28, 2024. It is now read-only.
This repository was archived by the owner on May 28, 2024. It is now read-only.

Thoughts about socket connection life cycle #7

@bernimoses

Description

@bernimoses

This are just some thoughts about the socket connection life cycle. It would be nice to get some feedback. ;)

Currently every time the connection gets closed (ir remote, tcp timeout) we try to reopen it immediately. This causes (at least for me) to wake up the soundbar from standby. I found that if i turn the soundbar off via the ir remote it closes the tcp connection which in turn would immediately turn it back on (as of version 0.2). Edit: Not opening a connection turns it back on but sending data. This is just from my observations and i have to confirm if this is always the case.

For my use case (homeassistant, hass) this is even more pronounced since the current hass component uses polling. Since a already open socket would update the components state itself, i tried to disable the polling. But this caused (as of version 0.1) the connection to drop completely which makes the hass entity kinda like a "zombie process". I'm not going into more detail here since this is mostly hass related and there need to be changes made to the hass component to implement proper uuid handling.

Ok, now my proposal. Instead of reopening the connection after receiving the null byte we close the client socket. Edit: It seems that this part is not needed since only sending data would turn the soundbar back on. If any library method is called afterwards we reopen the socket connection (if it is closed). This means that we don't get status updates if the soundbar is turned on (wake up from standby) from outside (ir remote, other socket connection) but in turn we allow it to go to sleep.

For the hass part this would mean we use the zeroconf announce (the soundbar sends on broadcast/start) to create the entity and reopen the socket on the same event to get the current status. Maybe zeroconf would also be interesting to implement here in case we get a announce for "wake up from standby" (didn't check yet).

Is there a part of this you would consider adding to this library in one or another (pull request) way?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions