Closed quantumira closed 9 months ago
Yes, I think the better move should be to remove the eeread
and eewrite
commands completely. It's already not The blink(1) mk1 is unsupported (if you have one and would like an upgrade to a mk3, contact us)
Those commands have not been in the blink1-tool
help page for many years and you have to go searching for them to use them.
Sorry, my repro steps were clear enough and confusing. And I found that it's --readnotes
brokes the device instead of --eeread
.
Here's the more experiments:
1)
--eeread
is okay with mk2 device:
# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:204
# b1t --eeread 1
eeread: addr 0x01 = 00
# b1t --eeread 2
eeread: addr 0x02 = 00
# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:204
# b1t --on
set dev:0:0 to rgb:0xff,0xff,0xff over 300 msec
# b1t --off
set dev:0:0 to rgb:0x00,0x00,0x00 over 300 msec
2)
Command --readnotes
brokes it:
# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:204
# b1t --readnotes
0:
1:
2:
3:
4:
5:
6:
7:
8:
9:
# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:-4848
# b1t --on
set dev:0:0 to rgb:0xff,0xff,0xff over 300 msec
error on fadeToRGBForDevices
# b1t --off
set dev:0:0 to rgb:0x00,0x00,0x00 over 300 msec
error on fadeToRGBForDevices
3) After reconnecting the device, it works normally:
# b1t --list
blink(1) list:
id:0 - serialnum:20005601 (mk2) fw version:204
# b1t --on
set dev:0:0 to rgb:0xff,0xff,0xff over 300 msec
# b1t --off
set dev:0:0 to rgb:0x00,0x00,0x00 over 300 msec
@todbot Maybe it's a bug in the firmware?
I'm encountering an issue with the blink(1) mk2 device, where when it attempts to perform a command that is only supported by the blink(1) mk3, it causes the mk2 device to malfunction, returning abnormal results. This issue persists until the device has been power cycled.
Below is the log of commands I executed:
After reboot:
The '--eeread 1' command is not supported by the mk2 version. As a result, an error was reported or returned 0 (when it works normally). Furthermore, I experienced an error on the fadeToRGBForDevices command, which I suspect is related to the previous faulty operation. After these operations, the firmware version reported for my device appears to fluctuate erratically, which can only be corrected by power cycling the device.
I believe there should be more explicit error handling in this situation, perhaps preventing unsupported commands from running on devices that do not support them, to prevent this erroneous behavior.