Closed ysard closed 2 years ago
undera
commented
2 years ago The original LED peripheral code did not contain any functions for subscribing to get sensor data. After your change that introduced "sensor properties", you have added one. It seems that LED should not have that property, as it does not support getting the LED state...
If I am wrong, please point me to the place, where old implementation were accessing that information.
ysard
commented
2 years ago Properties are just bindings of pre-existing functions; the old code is here:
I may be misinterpreting the API but to me it means that this data can be obtained from the hub via get_sensor_data().
Subscribing to this color data is showed on the old doc :
LED
Example:
print("ATTACH callback")
def callback(*args):
print("Color has changed:", args)
myhub.led.subscribe(callback)
print("led set to red")
myhub.led.set_color(9)
print("led set to green")
myhub.led.set_color(6)
print("current color - mode 0", myhub.led.get_sensor_data(0))
print("current color - mode 1", myhub.led.get_sensor_data(1))Result:
ATTACH callback
led set to red
led set to green
current color - mode 0 (0,)
Color has changed: (0,)
current color - mode 1 (0, 0, 0)
Color has changed: (0, 0, 0)Indeed, I can see that it's the explicit access via get_sensor_data() that triggers the callback and that the callback showed
in the doc is never called otherwise.
If these functions (get_sensor_data() and _decode_port_data()) shouldn't be used in this class, maybe they should be overwritten to raise something like "NotImplementedError". And the doc should be updated to remove any callback reference.
All this to avoid misuse.
I can propose a PR to fix all of this, according to your choice.
Some review of other projects:
Returns: tuple (int r,int g,int b) each has a value between 0 and 255. Only if no arguments are given.
Note: => I'm more likely to believe the unofficial doc than the partial and out of date Lego one.
undera
commented
2 years ago Thanks for the thorough investigation.
I'm starting to remember that in my early experiments I saw that LED peripheral does send some data back, thus I have included the code to decode the messages. It is highly likely that HW sends those messages, but it's a sort of "incomplete" functionality on HW side.
When I've done "capabilities" scan on Hub's peripherals, some undocumented sensor modes come out. I tried to include them all into the library, even if it's a not documented (by LEGO) functionality.
I guess we can just put a note in documentation, saying that sensor data getting from LED does not produce meaningful results.
ysard
commented
2 years ago Thanks for the feedback, you're totally right; similarly, the headlight device brightness recovery shouldn't work either as it's not documented but it does... The PR should fix that;
I was mistaken because the description of the 2 devices is similar: => no input_modes, 1, some output_modes for both
LEDRGB:
modes: {'mode_count': 2, 'input_modes': [], 'output_modes': [{'Mode': 0, 'Name': 'COL O', 'Raw range': [0.0, 10.0], 'Percent range': [0.0, 100.0], 'SI value range': [0.0, 10.0], 'Units': '', 'Mapping': {'input': [], 'output': ['Discrete [0, 1, 2, 3]', 'Supports Functional Mapping 2.0+']}, 'Value encoding': {'datasets': 1, 'type': '8 bit', 'total_figures': 1, 'decimals': 0}}, {'Mode': 1, 'Name': 'RGB O', 'Raw range': [0.0, 255.0], 'Percent range': [0.0, 100.0], 'SI value range': [0.0, 255.0], 'Units': '', 'Mapping': {'input': [], 'output': ['Absolute [min..max]']}, 'Value encoding': {'datasets': 3, 'type': '8 bit', 'total_figures': 3, 'decimals': 0}}], 'capabilities': {'logically_combinable': False, 'synchronizable': False, 'can_output': True, 'can_input': False}Headlight:
modes: {'mode_count': 1, 'input_modes': [], 'output_modes': [{'Mode': 0, 'Name': 'LPF2-LIGHT', 'Raw range': [-10.0, 10.0], 'Percent range': [-100.0, 100.0], 'SI value range': [-10.0, 10.0], 'Units': '', 'Mapping': {'input': [], 'output': ['Relative [-1..1]']}, 'Value encoding': {'datasets': 1, 'type': '8 bit', 'total_figures': 1, 'decimals': 0}}], 'capabilities': {'logically_combinable': False, 'synchronizable': False, 'can_output': True, 'can_input': False},
Hi, I have an issue with this code (on Technic Hub):
The color code obtained through a callback or with explicit access is always '0'. The code used to change the color is ok (the correct color is displayed on the hub). It seems that the received message is always the following one:
MsgPortValueSingle({'payload': b'00', 'port': 50})What can go wrong with the lib ?
Log on stdout: