I logged a defect/bug in deCONZ and in GCFFlasher a fortnight ago
but didn’t post a note to the forum at the time, which might explain why it is about to go stale, if nobody knows about. Should I be automatically post to this forum if I add something to GitHub issues?
Description of the logged issue follows
The Devices List shown when deCONZ starts contains 4 entries on my Windows 10 machine. One of these is my Conbee II and is thus expected, but the other 3 are unexpected Conbee devices. I’ve never had Conbee devices on my computer or system ever.
deCONZ autojoins to my Conbee II device so this is not a significant issue.
I didn’t think anything of it until today when I had need to check the Com port that my ConBee II is connected to, ahead of flashing Firmware. I knew it was COM7 but I checked it with GCFFlasher -l and got the following table
- GCFFlasher V3_17 (c) dresden elektronik ingenieurtechnik gmbh*
- Path | Vendor | Product | Serial | Type*
- .\COM4 | 0x0403 | 0x6015 | PA2U9D23A | ConBee*
- .\COM6 | 0x0403 | 0x6015 | US2RETFYA | ConBee*
- .\COM3 | 0x0403 | 0x6015 | DN033EKNA | ConBee*
- .\COM5 | 0x0403 | 0x6001 | AK08TPBAA | Generic FTDI*
- .\COM7 | 0x1CF1 | 0x0030 | DE2456287 | ConBee II*
It contains my ConBee II as expected on COM7, but it shows ConBee on 3 of the other COM Ports that I use. None of these have a ConBee. Code used by GCFFlasher and deCONZ is clearly being mistaken by these ports.
Ports 3, 4 and 6 contain FTDI USB-Serial Convertors (all 0x0403 / 0x6015 in the table) attached to Observatory Dome, a Powerbox Hub and a Telescope respectively), all totally different equipment and using different make of USB-Serial convertor but possibly the same FTDI chipset.
Port 5 also contains an FTDI USB-Serial Convertor ( 0x0403 / 0x6001 in table) connected to a Focuser