[BUG] Extra IO - PCA9685 - i2c address range is too limited so I cannot reach my LU9685 board

[pubdc]

Describe the bug
When I select a new device "Extra IO - PCA9685" (16 port PWM breakout - servos control), the dropdown allows selection of the i2c address from 0x40 to 0x7E. That covers the adafruit/PCA9685 chip but omits the higher range used by the very similar LU9685 chips (very cheap on ali, default address is 0x80 and above). Could you please increase the range in the drop-down by 1 more bit ?

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Devices'
2. Click on 'Add' and select "Extra IO - PCA9685"
3. Scroll down to 'i2c options' > i2c address
4. See error : max is 0x7E instead of 0xFF

Expected behavior
I would expect the max to be 0xFF

Screenshots

Used platform (please complete the following information):

• ESP type: ESP8266
• Build version: ESP_Easy_mega_20241221_normal_ESP8266_4M1M
• Build set normal

Platform Specifics (when applicable, please complete the following information):

• Flash size: 4M
• Brand/Model:
• Browser + OS [Firefox Linux]

Additional context
I have been using ESPeasy for over 10y now. Love it !! Thank you very much.

[TD-er]

Added a fix: #5217
GH Actions test build: https://github.com/letscontrolit/ESPEasy/actions/runs/12623972223

I extended the range to include 0x7F.
Or do you need a range of 0x40 ... 0xFF? This would be extremely odd as you only use 7 bits for the address and the last bit is read/write direction.
If you really need such a large list, can you please show the I2C scan result page with the device connected?
Some datasheets refer to the 8-bit addresses, which of course then always be an even number as you need to use the 'base' address and add one for the other communication direction.

If we really need such a long list, maybe we should just add a numerical input there instead of a large selection list.

P.S.
And glad to see long-time users still actively updating their devices :)

[pubdc]

Dear TD-er, its 0x80 (or 128) for the board I use, its an LU9685 board, looks just like the PCA9685 they are all over aliexpress and usually on black PCB. I have tested that in a number of scripts. But the i2c test on EASPeasy doesnt detect it (it works though : it detects my SHT41 on 0x44). Does that test go to 0x80 or does it also stop at 0x7F ? Not sure what maximum is good for the config of the i2c address in ESPEASY, but obviously 0x80 would offer me 1 board so 16 servos, it would work just fine but as it often goes : more is better. Greetings from Belgium !

[pubdc]

[TD-er]

The test does stop at 127 as far as I remember.
Have to check the rest of the code to see whether it will work or not as I suspect some places where I2C addresses are kept might be int8_t and thus will cause issues.

That's something that will take a bit longer to look into.
However I can extend the I2C scanner already so you can see if those devices will be found.

[TD-er]

No idea if this will work, or even successfully build.
But here is the GH Actions build for 8 bit I2C addresses: https://github.com/letscontrolit/ESPEasy/actions/runs/12642318395

[tonhuisman]

Hm, maybe this board requires 10-bit addressing? But that's not supported yet.

[TD-er]

I did some searching, but could not find any datasheet on this chip.
However on this AliExpress page for the board there are some suggested resistor placements to set I2C addresses below 0x80.

Like I mentioned before some datasheets refer to the I2C address including the read/write direction bit.
This is really confusing.
However since the formula given is only resulting in even addresses, I think the mentioned address is including the read/write bit.

Can you pull A0...A4 to GND and see if it shows up on address 0x3E (dec. 62)?

[tonhuisman]

AFAICS, these Ax pads should be pulled/connected to VCC (= 1, default pulled down to GND via 4k7 resistor), so the calculations will work to form an address 🤔

[pubdc]

So when I run a test on i2c discovery indeed the module responds to 0x10 (16) as well as 0x90 (144) when I bridge A4 and when I also bridge A3 it responds to 0x18 (24) and 0x98 (152). With or without the bridging it also keeps responding to 0x00 and 0x80 all call address.
That's great news in that we can probably avoid that 10-bit addressing topic, but now instead of me request being to widen the i2c address range at the top end, I am begging for it to be lowered at the bottom end :-) As you spotted I could move up to 0x3E max (62), but the current list starts 2 higher at 0x40 (64). Obviously at 62 there would be room for just 1 unit, so maybe 50 or 60 ?
Many thanks for you swift response and guidance, I am learning a lot here !

[TD-er]

So I will revert the changes to have it to scan for addresses > 127 as that simply cannot/shouldn't work.
Internally the address is shifted 1 bit and then stored in an eight bit register/variable.

I can extend the range. But maybe it is then better to have just a numeric field as having a combobox with 64 values is not really a good solution from an UX point of view.

I will also search for what is special about address 0 as that's explicitly not included in the I2C scanner and I don't know why.