Add rescan function

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.

[ThanhCN0]

Was looking at #60 and discovered openrgb added client rescan with their 1.0 release.
On 0.9 there is no effect, and on 1.0rc2 it triggers the rescan.

[felipecrs]

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

[jath03]

Does this work as is, or do you have to manually override the protocol version when you run it?

I wonder if the default protocol should be bumped:

openrgb-python/openrgb/network.py

Line 9 in 605b5f3

OPENRGB_PROTOCOL_VERSION=4

https://gitlab.com/CalcProgrammer1/OpenRGB/-/blob/master/Documentation/OpenRGBSDK.md

The rest of the features from protocol version 5 haven't been implemented, which would be a prerequisite to bumping the default version for the library as a whole.

[ThanhCN0]

Does this work as is, or do you have to manually override the protocol version when you run it?

I need to specifically call protocol_version=4, but that is because of the openrgb version. simply running

from openrgb import OpenRGBClient
from openrgb.utils import RGBColor, DeviceType
client = OpenRGBClient()

causes this error on 1.0rc2
ValueError: 655360 is not a valid ZoneType

[jath03]

causes this error on 1.0rc2 ValueError: 655360 is not a valid ZoneType

Huh, this seems to work for me with 1.0rc2. protocol_version=4 is the default at the moment, have you been testing on a branch with OPENRGB_PROTOCOL_VERSION set to 5?

>>> from openrgb import OpenRGBClient
>>> cli = OpenRGBClient()
>>> cli.rescan()

Assuming that this works without breaking anything else, I'd be fine with merging before the rest of the v5 changes come in.

My only other concern is that rest of the python API is fairly careful about calling update regularly to maintain a correct internal state (unless the fast parameter is used). For the sake of consistency, I might want to have the current behavior gated behind a fast=True flag.

This raises the fairly difficult question of what to do by default, because immediately calling update within the function returns an empty device list as openrgb is mid-rescan. Would we want it to block until the rescan is complete and then update? I don't think that would even be possible without an SDK change. Open to ideas here.

I'd probably be fine with this being a special case (no fast param, state-breaking by default) for now, as long as an appropriate warning was included in the docstring. Later on we could revisit the complicated case by adding a block param or something.

[ThanhCN0]

Ahhhh you're right, I did have OPENRGB_PROTOCOL_VERSION set to 5 while testing something.
From my perspective, since manually triggering a rescan from OpenRGB would also be stake-breaking, I've had to call update() later on anyways.
I'll add a warning to the docstring, feel free to suggest or push your own.