Updated EON control scripts

ARGON EON DISCUSSION
42

What operating system are you using?

The error:

bus = smbus.SMBus(1)

Means that there is no access for that operation to succeed… this could be a number of issue (incorrectly configured system, system that has things locked down more, etc).

Not knowing the operating system you are using, makes it impossible to help…

sudo argon-config
--------------------------
Argon Configuration Tool
Version 2203003
--------------------------

Choose Option:
  1. Configure IR
  2. Configure RTC and/or Schedule
  3. Uninstall

  0. Exit
Enter Number (0-3):2
----------------------------
Argon RTC Configuration Tool
----------------------------
RTC Time: 2024-01-24 16:47:35
Choose from the list:
  1. Update RTC Time
  2. Configure Startup/Shutdown Schedules

  0. Exit
Enter Number (0-2):1
Matching RTC Time to System Time...
RTC Time: 2024-01-24 16:47:40
----------------------------
Argon RTC Configuration Tool
----------------------------
RTC Time: 2024-01-24 16:47:40
Choose from the list:
  1. Update RTC Time
  2. Configure Startup/Shutdown Schedules

  0. Exit
Enter Number (0-2):0
44

Oh, sorry. I’m on Debian 11 bullseye

45

So I just modified my /boot/config.txt to add:

dtoverlay=i2c-rtc,pcf8563

And now I get access failures via the "getRTCdatetime() function in argoneond.py.

So… modifying the config.txt file while it makes some thing work, appears to break the argon code.

Debian 11 has issues with the SMBus object creation… there is a library (I forgot which one) missing.

46

So… That’s it ?

I don’t really understand what can i do then… I just want to make it work, normally.

47

It really comes down to… what do you want to have working? What exact feature? The Real time clock? The RTC and the ability to automatically shutdown at a specific time, and restart at a specific time?

When you modify the config file to include:

dtoverlay=i2c-rtc,pcf8563

That prevents the python scripts from accessing the RTC… I’m not sure why. (yet).

MY recommendation would be to try and contact Argon… and be nice…

48

Hi,

Did this get added? Im having the same issue.

Thanks
S

50

Oh wow… I just saw that Bookworm is up and running? I think that means now that OMV7 is out, we can install that and try it out.

Btw, what is everyone’s drive layout? I have 2x8tb 3.5", 2x2tb 2.5 (spinning drive) and a M2.SSD on a USB adapter for my OS internally).

51

Not really sure… I’ll have to take some time and review it

52

I have not because it causes other issues.

53

please forget what I wrote … was a wrong assumption of me.

54

I did a little research because I was interested in knowing the cause. The overlay activates the kernel driver/module for communication with the RTC (0x51 ?). This is blocking access from other scripts to the same I2C address. I think, If you use

i2cdetect -y 1

you should get “UU” for this device as the confirmation. The user has to decide for himself what he wants to use: argoneon script OR direct kernel support. It is not possible to do both at the same time.

EDIT
By the way, there seems to be some progress in the scripts from Argon since the begin of the year. The only difference between argon1.sh and argoneon.sh is, if the EON / fanhat support is enabled by default.

55

Ah… .I am responding months later, lol. Sorry I didn’t see the question. Luckily, I have recently re-done my NAS devices at home, including my EON. I have installed Bookworm and OMV7. I used the script from the official location, was that the one that was updated? It seems to be working, but I haven’t tried all the config that I did last time. Fan gets pretty loud again, I’ll have to remember what I did and readust the curve.

I had no problem during the install. If the latest script is not at the official argon location, can you remind me where it is again? I’ve learned a bit since I started this whole process. I have my USB NVME adapter (housing the OS), passing through SMART details now, which is an improvement. I have moved to running MergerFS and SnapRAID for my NAS, exposed as a Samba share. I’m not going to run the same containers as I was running last time (Pi was slightly underpowered for those), so I have to come up with something to run. My 8GB or RAM is mostly underutilized at the moment. :slight_smile: