• A
    andrewh

    Hi Philip

    I'm back from 4 weeks holiday and following up on this. It occurred with several mangoes in a box of 10, so unlikely to be battery dislodgement. I have powered up a few mangoes that have been sitting around a while to reproduce the issue, but so far they have all held their date/time. Have you had any other reports of mangoes losing their date/time?

    Andrew

    posted in Mango Automation read more
  • A
    andrewh

    Is there any way to upgrade to a specific version? eg 3.5.6?

    posted in How-To read more
  • A
    andrewh

    Thanks Philip
    I should have mentioned that I did use hwclock -w to set the hardware clock. A power disconnect of a couple of days has then lost the date. We will try new batteries. Do you have some idea of how long the backup batteries should last? I expect the total time disconnected from power is the most important measure. I would have thought it would be a couple of years?

    posted in Mango Automation read more
  • A
    andrewh

    We have recently had 2 fairly new MangoeES's whose hardware clock and system time have reverted to Jan 2000 after they have been unplugged for a day or two. We are planning to try replacement of the button cell battery that presumably powers the hardware clock when power is disconnected. Maybe we have a batch with a bad batch of backup batteries? Any thoughts?

    posted in Mango Automation read more
  • A
    andrewh

    @phildunlap Hi Phil

    Here is the output from one of the older mangoes that DOES exhibit the problem:

    mango@mangoES3047:~$sudo tail -n 50 /var/mail/mail
    [sudo] password for mango:
    Envelope-to: root@mangoes
    Delivery-date: Thu, 13 Jun 2019 17:15:02 +0800
    Received: from root by mangoES3047 with local (Exim 4.84)
    (envelope-from root@mangoes)
    id 1hbLp0-0003k9-7R
    for root@mangoes; Thu, 13 Jun 2019 17:15:02 +0800
    From: root@mangoes (Cron Daemon)
    To: root@mangoes
    Subject: Cron root@mangoES3047 /usr/sbin/systemInfo/getAll
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit
    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <HOME=/root>
    X-Cron-Env: <PATH=/usr/bin:/bin>
    X-Cron-Env: <LOGNAME=root>
    Message-Id: E1hbLp0-0003k9-7R@mangoES3047
    Date: Thu, 13 Jun 2019 17:15:02 +0800

    • Dir=/opt/info/
    • LogFile=systemInfo-new.txt
    • Together=/opt/info/systemInfo-new.txt
      ++ uname -m
    • arch=armv7l
    • [[ armv7l == \a\r\m\v\7\l ]]
      ++ mount
      ++ grep 'on / type'
      ++ awk '{print $1}'
    • DiskName=/dev/mmcblk0p2
    • echo '########DISK##########'
    • echo -ne 'Disk Name: '
    • echo /dev/mmcblk0p2
    • echo -ne 'Disk Total Size: '
    • df -m /
    • tail -1
    • awk '{print $2}'
    • echo -ne 'Disk Space Used: '
    • df -m /
    • tail -1
    • awk '{print $3}'
    • echo -ne 'Disk Space Left: '
    • df -m /
    • tail -1
    • awk '{print $4}'
    • echo -ne 'Disk Percent Used: '
    • df -m /
    • tail -1
    • awk '{print $5}'
      /usr/sbin/systemInfo/getAll: line 10: /usr/sbin/systemInfo/timeAlive: No such file or directory

    mango@mangoES3047:~$

    I tried running this frequently for a minute or so - it looks like an entry is added every 30 seconds.

    And here is the output for a new Mango that does NOT exhibit the problem (date is old):
    mango@mangoES3546:/etc/rc1.d$sudo tail -n 50 /var/mail/mail
    [sudo] password for mango:
    Return-path: root@mangoes
    Envelope-to: root@mangoes
    Delivery-date: Fri, 30 Mar 2018 12:36:32 -0600
    Received: from root by mangoes with local (Exim 4.84_2)
    (envelope-from root@mangoes)
    id 1f1yt6-0004zh-CB
    for root@mangoes; Fri, 30 Mar 2018 12:36:32 -0600
    From: root@mangoes (Cron Daemon)
    To: root@mangoes
    Subject: Cron root@mangoes (sleep 30; [ -x /usr/sbin/systemInfo/cronRunner ] & & /usr/sbin/systemInfo/cronRunner);
    MIME-Version: 1.0
    Content-Type: text/plain; charset=UTF-8
    Content-Transfer-Encoding: 8bit
    X-Cron-Env: <SHELL=/bin/sh>
    X-Cron-Env: <HOME=/root>
    X-Cron-Env: <PATH=/usr/bin:/bin>
    X-Cron-Env: <LOGNAME=root>
    Message-Id: E1f1yt6-0004zh-CB@mangoes
    Date: Fri, 30 Mar 2018 12:36:32 -0600

    • Dir=/opt/info/
    • LogFile=systemInfo-new.txt
    • Together=/opt/info/systemInfo-new.txt
      ++ uname -m
    • arch=armv7l
    • [[ armv7l == \a\r\m\v\7\l ]]
      ++ mount
      ++ grep 'on / type'
      ++ awk '{print $1}'
    • DiskName=/dev/mmcblk0p2
    • echo '########DISK##########'
    • echo -ne 'Disk Name: '
    • echo /dev/mmcblk0p2
    • echo -ne 'Disk Total Size: '
    • df -m /
    • tail -1
    • awk '{print $2}'
    • echo -ne 'Disk Space Used: '
    • df -m /
    • tail -1
    • awk '{print $3}'
    • echo -ne 'Disk Space Left: '
    • df -m /
    • tail -1
    • awk '{print $4}'
    • echo -ne 'Disk Percent Used: '
    • df -m /
    • tail -1
    • awk '{print $5}'

    mango@mangoES3546:/etc/rc1.d$tail -n 50 /var/mail/mail

    The cron job looks OK:

    mango@mangoES3047:/etc/cron.d$more system-info

    Regular cron jobs for the system-info package

            • root [ -x /usr/sbin/systemInfo/cronRunner ] && /usr/sbin/systemInfo/cr
              onRunner >/dev/null 2>&1;
            • root (sleep 30; [ -x /usr/sbin/systemInfo/cronRunner ] && /usr/sbin/sy
              stemInfo/cronRunner) >/dev/null 2>&1;
              0 0,6,12,18 * * * /usr/sbin/systemInfo/packages;
              mango@mangoES3047:/etc/cron.d$

    I compared this to the file on the newer mango, and the only difference I can see is the addition of 'root ' before the path in the last line.
    ie, it's "#0 0,6,12,18 * * * root /usr/sbin/systemInfo/packages;

    Shall I try adding this?

    posted in Mango Automation read more
  • A
    andrewh

    We have 6 older mangoES'es (8GB) that we started using a couple of years ago and have been updated to v3.5.6. I noticed that one of them was running out of disk space yesterday and discovered the file /var/mail/mail was about 750MB. I checked this forum and discovered this topic. So I deleted the 'mail' file from all 6 mangoES devices, saving around 750MB on each.
    I have checked again today, and the 'mail' files have been recreated and they are already up to 3.3MB on each device I deleted the file from. If this continues, the files will be over 1GB within a year, which is a very large chunk of the 8GB available. I don't want to have to manually delete these files every few months.
    Can you please confirm whether there is a permanent fix?

    posted in Mango Automation read more
  • A
    andrewh

    I checked the USB key and it does NOT have a /MangoES folder. I checked another key and it does have the folder. I have created a /MangoES folder on the key and will try again tomorrow. I'll let you know what happens.

    posted in Mango feedback read more
  • A
    andrewh

    Mango software version (core): 3.5.6 (current at 28/5/2019)

    I have tried to change a couple of MangoES's from Static IP (on eth0, IPv4) to DHCP. When I plug in the USB stick, the LED's flash on then off. I then power cycle the device, but the settings aren't changed. I have successfully used the USB stick to change from dhcp to static, so I know the process works in general. I am using the same file - '\script-enabled\networking.properties'. The read_me file on the drive has an example for changing to static, but not one for changing to DHCP. It looks pretty straightforward - I believe I have followed the syntax rules in the READ_ME file, but can't get it to work. If I go into System Settings -> MangoES configuration on the old UI, I can manually change to dchp without a problem. I checked the mango log files, but couldn't see anything logged about this. I have attached screenshots of files and config I'm using.

    The settings I'm starting with:
    0_1559264292575_Before - static IP.JPG

    The file I'm using to change to dhcp - does NOT work:
    0_1559264628935_change-to-dhcp - this does NOT work.JPG

    Another file I have tried with more fields - still doesn't work:
    0_1559264638262_change-to-dhcp with all fields - this does NOT work.JPG

    This is a file I use to change the other way (ie to a static address) - it works fine:
    0_1559264644829_change-to-static IP - this works.JPG

    posted in Mango feedback read more
  • A
    andrewh

    When attempting to display a dashboard containing a graph for one or more data points, and a data point has a large amount of data to display based on the date/time range chosen (eg 30 second samples for 2 months), it is necessary to select a rollup type to avoid the browser overloading with too much data. "Simplify with target" generally works well, although in this situation, the server often takes more than 30 seconds to calculate the data points and the browser times out after 30 seconds. The dashboard then hangs, and the graph is not displayed or refreshed.
    In chrome, using Developer Tools -> Network, the status of the web service call changed to '(cancelled) after 30 seconds and Size = 0B.
    In Firefox, the call shows a result if it returns within 30 seconds, but never updates or shows a result if it hasn't returned within 30 seconds.
    See screenshots.
    My research indicates we should be able to change the default timeout in Firefox, although I haven't found which setting this is.
    I don't believe this can be changed in Chrome.

    I am looking into changing the data point default to Simplify with tolerance, which seems to be faster, but I would still like the graph to work where the data takes more than 30 seconds to retrieve from the server.

    Can anyone advise a way to get around the 30 second limit, or even display an error message asking the user to select a shorter time frame or something?

    Screenshots (Firefox then Chrome):

    0_1548811991810_REST timeout in Firefox.PNG 1_1548812400603_REST timeout in Chrome.jpg 0_1548812400602_REST call.PNG

    posted in User help read more