Use TSL2561 and RTC ds1307 using a different bus

Novocaine85 commented 3 years ago

If you need support: Please post on https://www.reddit.com/r/crankshaft/ as this is a bug tracker, not a support forum.

Note: Reporting issues not based on official published builds will be closed without any comment.

What phone do you have? Poco F3
What OS version? Android 11 / Miui 12.5.6 Global
What crankshaft version? Alpha-7.4 2021-09-22
Steps to reproduce the bug, if you're planning to report a bug. Please indicate whether the bug is always repoducible. On my RPI I have the RTC ds1307 using the regular pins (vcc, gnd, scl, sda) and using a dtoverlay (dtoverlay=i2c-gpio,bus=2,i2c_gpio_sda=17,i2c_gpio_scl=27) on config.txt, i'm using the TSL2561 connected to the pins as per dtoverlay. Changed TSL_I2C_BUS to 2 on crankshaft_env.sh but TSL2561 is not recognized.

Please provide any further information that you might find helpful if available.


pi@CRANKSHAFT-NG:~ $ crankshaft i2ccheck 39
Crankshaft Management Tool v2.4.0 is executing command...

No device found.

Done. pi@CRANKSHAFT-NG:~ $ crankshaft i2ccheck 68 Crankshaft Management Tool v2.4.0 is executing command...

Device 0x68 found and in use by another process.

Done.

pi@CRANKSHAFT-NG:~ $ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- pi@CRANKSHAFT-NG:~ $ sudo i2cdetect -y 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- 39 -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- pi@CRANKSHAFT-NG:~ $



[debug.zip](https://github.com/opencardev/crankshaft/files/7577397/debug.zip)

Thanks for any advice.

techdev5521 commented 3 years ago

This is a wonderfully informative bug report -- thanky you!

I'm working on an unrelated TSL2561 issue #515 and from that work I believe I know what is happening here. First I'll explain how things should work then why i think they aren't.

How Things Should Work

On boot, there are two services that run relating to I2C and the light sensor:

i2ccheck.service: Checks for various I2C devices.
lightsensor.service: Monitors light sensor and updaes day/night mode + brightness.

The Problem

i2ccheck.service calls /opt/crankshaft/service_i2ccheck.sh to look for I2C devices but assumed all devices are on bus 1. https://github.com/opencardev/crankshaft/blob/cbb8e7995c8a3e9edc632b5ad2cf70f29342e283/stage3/03-crankshaft-base/files/opt/crankshaft/service_i2ccheck.sh#L48

Later, lightsensor.service call /opt/crankshaft/service_lightsensor.py which correct gets the light sensor bus from the /boot/crankshaft/crankshaft_env.sh or /opt/crankshaft/crankshaft_default_env.sh in that order. However, this service seems to fail or not start unless i2ccheck.service detects a device. https://github.com/opencardev/crankshaft/blob/cbb8e7995c8a3e9edc632b5ad2cf70f29342e283/stage3/03-crankshaft-base/files/opt/crankshaft/service_lightsensor.py#L26 https://github.com/opencardev/crankshaft/blob/cbb8e7995c8a3e9edc632b5ad2cf70f29342e283/stage3/03-crankshaft-base/files/opt/crankshaft/service_lightsensor.py#L10-L20

Potential Solution

The files associated with i2ccheck.service should account for potential custom I2C busses. The implementation method isn't clear to me though.

matt2005 commented 3 years ago

The service needs editing to support bus 1 and 2. i2ccheck

I can take a look in a few days, but feel free to submit a PR if you get it working

techdev5521 commented 3 years ago

Hard coding buses 1 and 2 solves this particular problem however if someone were to make a bus on any port greater than 2 then we run into the same issue.

It may be more robust to first build a list of the enabled buses then check each of those buses for devices. The list of buses could theoretically be built by listing files in /dev/ that match the regex pattern ^i2c-* where the characters matching the * are the bus number. Then, all bus numbers are scanned whether they're physical or virtual, sequential or random.

matt2005 commented 3 years ago

That's what I was thinking 👍

matt2005 commented 3 years ago

I'm thinking it would be better to add a var in the crankshaft_env for i2c_rtcbus and fix the script to use that, that way it can hide the dtoverlay setup as it's handled by scripts.

opencardev / crankshaft