[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.

[TD-er]

Found this overview on Adafruit site about devices per I2C address.
https://learn.adafruit.com/i2c-addresses/the-list
Also lists the purpose of some specific addresses.

[pubdc]

Yes 0x00 is "general call" or "all call", a little bit like 'broadcast' and any & all units can/should/must (not sure about this, I think it is can not must) respond.

so with all A0-A4 bridges active I confirm only reaching 0x1F or 31 (so not 0x3E as per the datasheet). Hence changing to a numerical entry that allows any number from 1 to 127 would seem to me to offer best flexibility. Thank you again for all the hard work !

[tonhuisman]

That 0x3E is indeed the 'left-shifted' address, used by some manufacturers.
The Arduino Wire I2C library expects addresses in the 0x01..0x7F range, so the usable range for this board is 0x01..0x1F (0x00 being the 'broadcast' address), effectively allowing for 31 boards to be used.
This 7-bit addressing scheme is used for all things I2C related in ESPEasy, as it's the most commonly used scheme.

[TD-er]

Yep, I don't think we will ever support 10-bit addressing for I2C, as I don't recall to ever have seen a chip supporting 10 bit and not 7/8 bit addressing.
I wonder when we will see broad adoption of I3C. The ESP32-P4 does already support it. (Arduino/ESP-IDF not yet though)

[tonhuisman]

Had a quick look at the datasheet of the PCA9685, but, despite the somewhat similar type name, I can find no similarities to the command list shown above. That's probably the reason there is no overlap in the I2C addresses, as this is no in-place replacement for the PCA9685.
Any manufacturer claiming the LU9685 to be 'compatible' with a PCA9685 is at least stretching the truth, or just plain lying 😨
Functional similarities are there, but that's about it.

There is no reasonable possibility that ESPEasy plugin P022 Extra IO - PCA9685 will work with this LU9685, that chip/board will require its own plugin. (No plans to support this, for now.)

Found only a few, non-exhaustive, code examples for this chip, one simple Arduino example that uses serial communication, and this example seems to be usable for a single purpose only.
And there's a fun project of creating a servo controlled spider on Instructables.
@pubdc Maybe this could help to make use of these boards?

[TD-er]

I also had a look at the very very limited number of code examples on GitHub.
Indeed the chip does not look to be compatible and only usable for servos.
I also read in the comments of one of the very few videos on YouTube about this chip, that it will only output 2.5V signals when powered via 3V3. Not all servo's will work with such a low signal level.

However the implementation of the calls to set the servo outputs is extremely simple.
So Ton and I are now discussing whether we should make a new plugin for it.

[TD-er]

OK, I think you can guess what the outcome is of the discussion Ton and I had...

See: #5218

Can you try this GH Actions build?
https://github.com/letscontrolit/ESPEasy/actions/runs/12673972121

Currently there is only a single command implemented:

 lu9685,servo,<pin>,<angle>
 lu9685,enable,<pin>
 lu9685,disable,<pin>
 lu9685,setrange,<startpin>,<startVarIndex>,<nrPins>

To disable a pin, you can give -1 as angle.

When <pin> is set to "all", the command applies to all pins.

lu9685,setrange can set a range of pins using a range of system variables.
If a variable in a range has not been set, that pin will be disabled.

The plugin is included in "Climate" and "Collection G" builds and of course the "MAX" builds.
N.B. Only for ESP32 builds as we will not add new plugins to standard builds on ESP8266.