Cannot Access Hardware Clock via any known method

[danowitz]

I have seen this error since I started using piBeacon. And I have search high and low for an answer and can't seem to figure out why I keep getting this. Has anyone else seen this message?

Thanks
Joel

[Hackencrash]

I don’t think it’s an error, I think it’s a statement. rPi’s don’t have hardware clocks unless you buy the module and battery and stick it on as a hat.

You are right though I think the message could be a little less invasive.


Sent from my iPhone using Tapatalk

[kw123]

The plugin has an option to install / use the hardware clock. It might be that it was enabled once and now it is looking for it.

I will check how to un do that.

Besides the messages there should be no problem


Sent from my iPhone using Tapatalk

[danowitz]

I have set the correct settings in the config for the pibeacon "No HWClock". This fills the output from the device and it seems to render it non-responsive to indigo as well. Also when I use the "restart NTP connection to get time from internet" button on the "Send Config/Restart/PGM/Sound/... to rPI server" dialog I get "sh: 1: refreshNTP: not found".

[kw123]

it looks as if the regular clock was uninstalled....

here is what master.py is supposed to do to reinstall the regular clock:

Code: Select all

   if (findString("dtoverlay=i2c-rtc,ds1307",   "/boot/config.txt") !=2 and 
            findString("dtoverlay=i2c-rtc,ds3231",   "/boot/config.txt") !=2 ) : 
            G.useRTC = useRTCnew
            return 

        removefromFile("dtoverlay=i2c-rtc,ds3231",  "/boot/config.txt")
        removefromFile("dtoverlay=i2c-rtc,ds1307",  "/boot/config.txt")
        removefromFile("/sbin/hwclock -s",          "/etc/rc.local" )
        # in /lib/udev/hwclock-set REMOVE # infront of 
        #if [ -e /run/systemd/system ] ; then
        # exit 0
        #fi
        uncommentOrAdd("if [ -e /run/systemd/system ]", "/lib/udev/hwclock-set", before="",nLines =3)
        os.system("sudo chmod a+x  /lib/udev/hwclock-set")
        os.system("apt-get install fake-hwclock") 

===

so could you do :

remove dtoverlay=i2c-rtc,ds3231 from file /boot/config.txt
remove /sbin/hwclock -s from "/etc/rc.local
with sudo nano filename

and file /lib/udev/hwclock-set should look like:

Code: Select all

#!/bin/sh
# Reset the System Clock to UTC if the hardware clock from which it
# was copied by the kernel was in localtime.

dev=$1

if [ -e /run/systemd/system ] ; then
    exit 0
fi

if [ -e /run/udev/hwclock-set ]; then
    exit 0
fi

if [ -f /etc/default/rcS ] ; then
    . /etc/default/rcS
fi

# These defaults are user-overridable in /etc/default/hwclock
BADYEAR=no
HWCLOCKACCESS=yes
HWCLOCKPARS=
HCTOSYS_DEVICE=rtc0
if [ -f /etc/default/hwclock ] ; then
    . /etc/default/hwclock
fi

if [ yes = "$BADYEAR" ] ; then
    /sbin/hwclock --rtc=$dev --systz --badyear
    /sbin/hwclock --rtc=$dev --hctosys --badyear
else
    /sbin/hwclock --rtc=$dev --systz
    /sbin/hwclock --rtc=$dev --hctosys
fi

# Note 'touch' may not be available in initramfs
> /run/udev/hwclock-set

then do:

Code: Select all

sudo chmod a+x  /lib/udev/hwclock-set

and

Code: Select all

sudo apt-get install fake-hwclock

to reinstall regular clock .

I actually really tested well install l HW clock , and may be once to remove it ..

or redo the SSD and push the regular config/pgm to the RPI.
The IP number etc should be all ok.

Karl

[danowitz]

I opened up the files you specified and the lines that you said to remove all started with hashtag #....they were commented out. I did however go ahead and remove the exact text strings from the files and saved. Then verified that the file "/lib/udev/hwclock-set" was the same as you posted above. I then ran the chmod and finally ran the apt-get install fake-hwclock. It returned the following:

Code: Select all

sudo apt-get install fake-hwclock
Reading package lists... Done
Building dependency tree       
Reading state information... Done
fake-hwclock is already the newest version (0.11).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I then rebooted the rPI. No luck. I will re-create the SSD, then document the exact steps I perform during the config of the rPI and see exactly when this hwclock error seems to come back.

[kw123]

thanks for your help.

Karl

[kw123]

BEFORE you overwrite the SSD, could I get the parameters file? i would like to to look at the line with useRTC=....

it is also in /Users/yourid/indigo/piBeacon/interfaceFiles/parameters.x on your mac -- with x = the RPI #

Karl

[danowitz]

Karl,

So I wiped the microSD and was able to reproduce the issue. But this is with the existing device object created in indigo. So I deleted the device in indigo, then cleared out the rPI in the initial setup screen. Re-imaged the microSD. This time I did not open the created device in indigo until I had completed all the setup steps called out on the main how to create an microSD blog post. This time it seemed to have worked. I did take a screenshot of the initial load of the device dialog once I had setup the rPI and configured it (ie. expand disk, timezone, change pass, and change hostname). It is below.

2018-05-10_22-58-30.jpg (137.86 KiB) Viewed 2800 times

Also attached are the parameters files you requested. I didn't get your message until after I had deleted the device in Indigo, however, Synology Cloud Station Server keeps 23 versions of my files now (this was implemented after I was loosing piBeacon devices after upgrades). So I went and hunted down an old version that would have been active when I was having the HWClock errors. The only large difference I see in the files is the extra json data for the sensors.

Thanks for bouncing ideas! My only take away on this is...don't open the indigo device until after all the setup of the rPI has been completed. My next issue is around the usage of "myprogram.py" and "mysensors.py". I will open a new topic