Addendum 2022-02-11:
There seem to be more situations that cause i2cdriver to lock up unrelated to the scan command. Whenever I reprogram my Teensy (which includes the device resetting, causing some amount of noise on the i2c bus) I have to power cycle the I2Cdriver because it locks up hard (the I2Cdriver display shows some amount of red circles with "!" inside) and will not respond to any commands. This is very annoying because obviously I'm doing a lot of reprogramming of my Teensy and there's really no good reason for the i2cdriver to lock up just because there's a little bit of noise on the i2c line for a few moments.
I noticed that when I do a device scan (d command) while the I2Cdriver is connected to my breadboard (which at present has a Teensy 3.2 and a 24AA256 EEPROM connected to the I2Cbus with 4.7kOhm pullups) but the breadboard is not connected to power the I2CDriver locks up and I need to unplug and replug it to get it to anything again. Or alternatively if I plug in the breadboard, then the I2Cdriver's scan finishes, too.
I noticed this because the Python GUI wouldn't start and I dug deeper into what it does and then I saw that it does a "d" command and analysed it a bit more. It's not a big deal once you know about it, but since I figure it's not that uncommon for people to plug in and start stuff in a different order at times it would be good to catch this condition at some point because otherwise it looks like sometimes the GUI works and sometimes it doesn't.
Addendum 2022-02-11: There seem to be more situations that cause i2cdriver to lock up unrelated to the scan command. Whenever I reprogram my Teensy (which includes the device resetting, causing some amount of noise on the i2c bus) I have to power cycle the I2Cdriver because it locks up hard (the I2Cdriver display shows some amount of red circles with "!" inside) and will not respond to any commands. This is very annoying because obviously I'm doing a lot of reprogramming of my Teensy and there's really no good reason for the i2cdriver to lock up just because there's a little bit of noise on the i2c line for a few moments.
I noticed that when I do a device scan (d command) while the I2Cdriver is connected to my breadboard (which at present has a Teensy 3.2 and a 24AA256 EEPROM connected to the I2Cbus with 4.7kOhm pullups) but the breadboard is not connected to power the I2CDriver locks up and I need to unplug and replug it to get it to anything again. Or alternatively if I plug in the breadboard, then the I2Cdriver's scan finishes, too. I noticed this because the Python GUI wouldn't start and I dug deeper into what it does and then I saw that it does a "d" command and analysed it a bit more. It's not a big deal once you know about it, but since I figure it's not that uncommon for people to plug in and start stuff in a different order at times it would be good to catch this condition at some point because otherwise it looks like sometimes the GUI works and sometimes it doesn't.