Atlas EC Disappears After 8.16.0 Upgrade

Been running issue-free for quite a while. Went to upgrade today and it seemed to go well. My Atlas Ph sensor on the same i2c bus as my EC sensor still works, but the EC does not. i2c detects the sensor at the correct address. On query, the little LED on the EC board flashes red.

Running Python 3.9.2 on a Raspberry Pi. All of this was working until I did the software upgrade.

cat /proc/version:

Linux version 6.1.21-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023

What else can I provide to help figure this out?? Should I revert to a previous version in the meantime?

Thanks in advance.

Doh - should have included log:

2024-10-02 13:46:27,351 - ERROR - mycodo.inputs.atlas_ec_6896aca9 - InputModule raised an exception when taking a reading: unsupported operand type(s) for -: ‘NoneType’ and ‘int’

The error suggests the None is the measurement being returned by the sensor board (nothing returned, that is). Have you completely disconnected the sensor and reconnected it (complete power cycle)?

I powered down the Pi and reseated the board. Is that wat you mean? I also swapped in another board that is configured the same way (i2c addr) and it behaved the same.

I did the upgrade remotely, so I doubt I damaged anything physically to cause this.

Thanks for your question.

No, disconnect meaning remove the wires and reconnect.

There’s no reason why it would stop working after a software upgrade to something completely separate from it.

Do you have a microcontroller you can test that it works with?

Yes, it is surprising that it would start failing due to this software update. Maybe one of the dependencies introduced a regression?

My wires are soldered to the carrier board and screwed into a terminal block. I reseated all 4 of those, tried a new carrier board, and a different EC board.

Are you asking about trying another rPI to see if that makes a difference, even though I have a working Ph sensor on the same bus? I’ll do it, but want to make sure I understand you since this is a decent amount of work.

Thanks again!

To test the sensor, you should isolate it to one device, preferably something basic, like a microcontroller. Have the only thing connected to the microcontroller be the sensor being tested. A Pi has an ARM chip and runs Linux, and is not a microcontroller. ATMega chips programmed in Arduino is what I’m referring to.

Have you attempted the factory reset procedure for the sensor board?

I do not have a microcontroller. I have more than one of most things (hardware), so I will do some troubleshooting that way, which is crude. I looked at the data sheet, and it looks like a reset is a message and not pins to tie together (like moving it to i2c). Does Mycodo have any kind of terminal interface to devices to talk to them directly? Is there another way to do that?

I am still troubled by the fact that after years of stable operation, this decided to happen on the exact time I upgraded the software. But I can accept that it is coincidence.

Thanks again.

Yes, run:

/opt/Mycodo/env/bin/python /opt/Mycodo/mycodo/devices/atlas_scientific_i2c.py

1 Like

I am still trying to understand how to interpret the data to see if it’s valid, but the EC (at 64/100) looks like it’s not corrupted… Just a quick update alongside the Ph (at 63/99). Nothing in Mycodo for EC.

Enter command: 99:R
(‘success’, ‘\x016.070\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00’)
Enter command: 100:R
(‘success’, ‘\x01799.2,432\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00’)
Enter command:

2024-10-02 19:31:40,549 - ERROR - mycodo.inputs.atlas_ec_6896aca9 - InputModule raised an exception when taking a reading: unsupported operand type(s) for -: ‘NoneType’ and ‘int’

Change the log line in the Input module from self.logger.error to self.logger.exception, save, deactivate and reactivate the input, and it will log the entire exception traceback.

You should also enable debug mode for the input to generate more log output (this should have been the first thing you did, but I forgot to mention it).

Fair point about debugging! I have had so few challenges so far I never needed it. Can you please clarify what the inout module is? I’m fine making the change, but don’t know where the file is. FYI, here is the debug log:

2024-10-02 19:59:07,304 - ERROR - mycodo.inputs.atlas_ec_6896aca9 - InputModule raised an exception when taking a reading: unsupported operand type(s) for -: ‘NoneType’ and ‘int’
Traceback (most recent call last):
File “/opt/Mycodo/mycodo/inputs/base_input.py”, line 123, in read
self._measurements = self.get_measurement()
File “/opt/Mycodo/mycodo/inputs/atlas_ec.py”, line 265, in get_measurement
out_value = convert_from_x_to_y_unit(
File “/opt/Mycodo/mycodo/inputs/sensorutils.py”, line 65, in convert_from_x_to_y_unit
return float(‘{0:.5f}’.format(eval(replaced_str)))
File “”, line 1, in
TypeError: unsupported operand type(s) for -: ‘NoneType’ and ‘int’

/opt/Mycodo/mycodo/inputs/atlas_ec.py

I would add a log line with the output value to see exactly what the sensor is returning.

I think I got this. For both Ph and EC, I had a temperature sensor configured to provide temperature readings for Ph and EC. That sensor is offline currently (has been for a while now). When I changed the configuration of EC and Ph to have no external temp setting, things started working again. I don’t know if the upgrade changed behavior of this, but I’m back!

Thanks for everything.

It’s been 9 months since the last release (it’s usually not this long), so I don’t know either if it’s changed. It’s at least something that shouldn’t prevent the Input from working, since a sanity check for the external temperature value should be performed. Thanks for letting me know, I’ll take a look at that soon. Glad it’s now working and you figured out the issue.

1 Like

Wondering if I should create an issue on this one. Behavior seems pretty reliable to me. If the temperature sensor for which another sensor is configured (e.g. EC) fails, it takes the dependent sensor with it in that it (EC in this example) is read as 0.

I just committed a fix that hasn’t been tested. Can you upgrade to master and test?

Thank you. Yes, the EC now works when the configured external temp sensor is not available. When I test the same thing with Ph, it does not work correctly as EC now does. Ph is not available if its configured external temp sensor is not working. I hope this helps and apologies that I didn’t make it clear that this affects both Ph and EC.

That’s a different Input. Only the EC sensor was changed for testing.

I can use the EC fix as a guide and submit a PR for Ph if you’d like. Otherwise, I can wait for a fix when it happens.